Category: Emotional Intelligence


Solutions Architect -vs- Senior Principal Consultant

Filed under: Emotional Intelligence, Enterprise Architecture, Random Work Day Thoughts — Leave a comment
December 19, 2009

There are well known discrepancies in the software industry as to the definition of a Solutions Architect and a Senior Principal Consultant. Depending on what type of organization you speak to, you might get completely different answers to this question.

According to Wikipedia;

A Solutions Architect in Enterprise Architecture is a practitioner in the field of Solution Architecture.[1]

The role title has a wider meaning in relation to solving problems, but is more often used in the narrower domain of Technical architecture – the context for the remainder of this definition. In this context, the Solutions Architect is a very experienced architect with cross-domain, cross-functional and cross-industry expertise. He/she outlines solution architecture descriptions, then monitors and governs their implementation.

The role of “Solutions Architect” requires knowledge and skills that are both broad and deep. To be effective the Solutions Architect must have experience on multiple Hardware and Software Environments and be comfortable with complex heterogeneous systems environments. The Solutions Architect is often a highly seasoned senior technocrat who has led multiple projects through the Software development process or Systems Development Life Cycle (SDLC), and has usually performed in a variety of different roles in that life cycle. The person needs an ability to share and communicate ideas both verbally and in writing to executive staff, business sponsors, and technical resources in clear concise language that is the parlance of each group.”

Strangely Wikipedia does not have a definition for Senior Principal Consultant.   So based on the fact that I have been one for a number of years I have developed my own definition.

A Senior Principal Consultant is a practitioner of Software Solutions Architectures. Providing consulting services to clients, with a broad range of industry experience and knowledge.

This role requires the individual  to be the lead architect, designing implementation architectures as well as defining the development and roll out strategy.   The Senior Principal Consultant must work with multiple layers of an organization, from executes, to business stakeholders, to technical teams and be successful working in all circles.  They must be able to to communicate ideas to all levels and obtain buy in from both the business and technical organizations for their solution architectural designs.

This person must also poses a deep understanding of the business domain as well as the technologies used to solve the different business problems.  A typical Senior Principal Consultant is involved in all phases of a project lifespan from initial requirements gathering, architectural design, task break down, development (where they often act as a software architect and developer), testing, and then eventually roll-out into production.

After reading these two definitions it’s easy to see the confusion in our industry.  Both require depth of knowledge within the business and technical domains.  Both roles require the ability to articulate an architecture to project stakeholders, as well as technical audiences.   Where they differ however, and this is the key, is that the Senior Principal Consultant is more hands on, rather than removed from the implementation.

With that said however, most Solutions Architects I know also love working within the technology space so that they can gain a full understanding of it’s capabilities.  The difference though is that a Solutions Architect is not actually expected to perform the work needed to construct the solution.  They are simply responsible for directing the technical teams, who task it is to build the solution.

My bottom line however, is that the type of person needed for both positions is effectively the same with only minor differences relating to the types of tasks that are performed on a day to day basis.

Tags: , , , , , ,
Comment

Are most Information Technology Architects more Managers or Technologists? Is the 50/50 balance really possible?

Filed under: Consulting, Emotional Intelligence, Enterprise Architecture — Leave a comment
November 15, 2009

IT Architecture is the evolution of a career, in that it takes years of experience designing, building, and rolling out systems that match a set of criteria.   The hardest part as I have detailed in previous posts is not the technology however, but matching the technology to the requirements.   Knowing which questions to ask at the right time, so that you can flush out more from your clients and customers than just a set of screen shots, or a bullet point list of hardware requirements.  The Architect must take a broader outlook then this, always having in the back of their mind what other factors could be impacting the solution, or strategy that have not been communicated.

I recently posted this question on LinkedIn and got a few key responses I wanted to highlight here.

IT architects are visionaries, coaches, team leaders, business-to-technical liaisons, computer scientists, and industry experts. – OpenGroup.com

I believe that a crucial role of a Solution Architect is to act as the link between business stakeholders and technology experts. You need to exchange ideas effectively with both groups and need significant technical and business understanding for this to be possible, without necessariy being an expert in either area yourself. Typically, architects come from a business background and acquire technical knowledge or come from a techincal background and acquire business understanding. In my experience, the latter case is more common and architects are therefore more likely to lean to the technical.  – Paul Harris – CRM and Integration Consultant

In short, the Architect is the only guy in the room who has decent street cred with the Development and Marketing folks. He’s diplomatic and savvy when it matters, and can think very critically about architecture and applying technology where it counts.  AD Kent – Managing Partner at DocuConsulting

As all three quotes explain, the Architect is the link between business and technology, which means that he or she has to be able to communicate and build relationships with both sides.   For instance, if the Architect is in a meeting with the CFO of an organization, project and operational cost are important. It is important to communicate how the given project or strategy will cut costs to the organization.  If you don’t know hard numbers, be prepared to at least communicate in terms of hours spent in the current environment to generate output, and how a new architecture, system, or solution, will cut that down over time.   Many CFO’s can calculate simple math in their head, and when they hear “reduction in hours to produce” they know your talking in terms of savings to the company.    The better your statistics are, the more inclined they are to support your initiative.

This conversation is completely different than the one you would have with engineers and developers.  When communicating with these folks, you must similarly direct your conversation to something that matters to them.  Performance, Design, Quality, Extensibility, Importance to the organization, are all characteristics of an Architectural knowledge base.   It’s also important as the Open Group states, to coach, mentor, and encourage your teams as part of the production endeavor.

So in short, the answer to the overriding question is yes.  The Architect must be someone who can operate with many different hats and gain the respect of peers, those reporting to them, management, and even sales and marketing.   This is often a result of many years of experience in all facets of business technology, and a general understanding of what each component of the business requires to be successful.

Tags:
Comment

Turning a Frustrated Customer into a Reference

Filed under: Consulting, Emotional Intelligence — Leave a comment
October 27, 2009

Have you ever walked into a new customer and realized immediately that they don’t like you?  Not you personally, but your company in general .

If you’re an consultant for a software company this is an all to common occurrence.    You see, before most customers are given the opportunity to speak with you, they have been through experiences with other members of your company.   Sometimes those are pleasant,  but sometimes –  They have dealt with Sales guys who have promised them the world, but have not delivered.  They have dealt with Support managers who have spoken pleasantly with them and said they “understand” but have not been given the power to pressure PD to fix their issues.   They might even have dealt with Product Development engineers who responded with the most horrible of quotations, “well why do you want to do that?”

After years of dealing with this situation, I have developed an approach and a philosophy that  I use to turn these customers into our biggest fans!

  1. The Customer is always right.   This is very cliché, and probably over used.  However this doesn’t mean that when you believe the client is making a mistake in their approach to a problem you shouldn’t speak up.  What it means is that ultimately they own the solution.  They support it long term, and it is their issues that you are trying to solve.   At the end of the day, they have the final say.   I like to present possible solution scenarios to the client, arguing the positive and negative to each approach, and then let them make the final decision.
  2. Never promise anything you can’t deliver.   Don’t tell the customer that you will get PD to fix a problem if you can’t.  This will just lead to more frustration by the client, and put you on their ‘unhappy with’ list.
  3. Understand and hear their frustration.   Most customers just want a sympathetic ear.    They want to know someone is listening to them, and that their frustrations are validated.
  4. Workaround Workaround Workaround.   Your getting paid to come up with solutions.   Sometimes these solutions are not the way “things should work” but are a stop gap until a better solution can be provided.   Customers will respect your ability to  come up with ideas to handle the given situation.
  5. Always have a list of their problems with you.  I like to keep a notebook with issues my customers have run across.    I will pull this notebook out from time to time and think about a good solid solution that may be provided.  This also keeps this customer fresh in my mind, and helps me bring up ideas when in general discussions with other members of my company.
  6. Success – This is the most important way to turn a frustrated customer into a reference.    Every successful project you are able to complete with a client, will make them bigger and bigger fans of your company.  Sometimes this means doing whatever it takes to make the project work.  Sometimes you will act as PM, sometimes an architect, sometimes a troubleshooter, sometimes a developer.   Successful projects lead to opportunities, and opportunities lead towards reoccurring revenue.
  7. Connect with your customer on a personal level.   Remember your client had hired you to be apart of their team.   While you might always be somewhat of an outsider, your skill set is why they have agreed to have you “point them in the right direction”.    So relax, your customer wants to like you… let them.

 

Tags:
Comment

Getting To Know Your Customers – The Interview Process

Filed under: Emotional Intelligence — Leave a comment
October 17, 2009

A few weeks ago I spent 3 days at a customer site getting to “know” them.   It was a positive experience,  so I thought it might be a good idea to go through what I was trying to accomplish, and what you should prepare for when you go on site.

First and foremost you need to be prepared to be interviewed.  Not the type of interviews where they ask you 20 questions out of the back of a Java book, or ask you about specific relational database concepts.   No instead they will ask you about every idea they have, every problem encountered with your software, and they will listen and watch and learn about you.   This to me is an enjoyable experience because I have a secret.  I know more about the subject at hand than they do.   I also know that saying almost anything in response to a question makes you seem intelligent.

What you say.. saying anything makes you sound like you are intelligent?  It is widely known in most business development studies that frequent talkers are perceived as more intelligent and competent.  I don’t mean by this, that you should talk over everyone, or talk down to people when you can, what I mean is that if you have an answer for everything.. even if that answer is, “I will get back to you,” you appear to the client as a very intelligent person.  One word of warning.. if you use the phrase “I will get back to you,” write this down and make sure you follow up!

But you’re not the only person who is being interviewed.  You also must interview the client.   Ask them questions about their architecture.   Ask them, though be careful not to sound condescending, why they made certain choices.   Listen to their responses and get a feel for what they know, and how they talk.  Yes, the words clients use to describe things are important.  You must when speaking about a certain subject use their words in your dialog so that they have a better understanding of your ideas.   For instance, while working in my last position, the company I worked for went through 2 different acquisitions, over a period of 2 years.   Even after we changed our name from a small company to a large multinational corporation, people still referred to our software with the original company’s name.   So to be clear in what I was talking about, I did as well.  Also get a feel for the political landscape; by understanding  such things as who can get what done, who do you contact when you need something from the client, who owns the project, which factors are working against you,  and which factors are working in your favor.

During the lunch breaks this client asked me to go to lunch with them.  Never ever turn this opportunity down, no matter how much work you have to do.   This is a good opportunity for you to talk about other things not related to the given project.  Open up and let them get to know you.  If they ask what your philosophy is on running projects or implementing software tell them.   If they want to know what life is like back at the ranch, let them know.    This builds trust with your customers and they will find themselves relying on you more because of this.

Always be prepared to demo something.   Even if it’s a few lines of code that say hello world in the corner of your app… customers like to see stuff.  It helps convey your ideas, and get the customer on board with what you feel is the direction they should go in.  Also along this idea, your friend is the white board.  This is a requirement for any meeting I attend.   I sit near them, and often look to them as an aid in explaining my ideas.  Conveying your ideas on a white board is the most important UML skill you can have.

After establishing trust, respect, and a clear vision of what you’re about, the client will often ask you which direction they should go in.   Whatever you do, and this is probably the most important thing I can tell you, do not back away from this question.   I often use this as a recap.  I try to lay out exactly what I heard from them as best I can.  I make sure I look at each person in the room while explaining what concepts, ideas, and issues I heard and saw while meeting with them.    I try to reiterate the actual phrases that people used, and associate names with those phrases.  Once I have laid out my summary, and no one has any lingering questions, I then detail my direction for the project.

I like to make decisions..  some consultants/architects/project managers that I have worked with in the past were really good at dodging the bullet.   This isn’t how I work.   Personally I believe that the trust, respect and reliance, you have spent days gaining with the customer, gives you a power to push the project in the correct direction.  If you are sure enough about your abilities, and you have enough experience; you should feel confident enough at this point to layout the next steps that the project team members should do.

Tags: , , ,
Comment

How do you know you have the right team?

Filed under: Emotional Intelligence — 1 Comment
August 18, 2009

One of my favorite things to do these days is pose wide open questions on Linkedin and review the responses.  Most times folks on that site give well thought out answers to those questions and I learn a great deal from them.    My latest question is; how do you know you have the right team?

The reason why I asked this question in this generic manor is because I wanted people to think about the teams they are on, or have been apart of and what made them work.   I wasn’t looking for anything specific.  Just general thoughts on what makes a team effective.  It didn’t matter to me if the team in question was a baseball team or an executive team trying to solve business problems. 

Here was the best answer – Thanks Octavio Ballesta

These are the steps that you should take into consideration from the perspective of a Team Leader for having the right team:

1. I make sure that from a personal perspective, everyone of the members of the team have a clear understanding about the rationality that justifies the project, and that at the same time, they are positively motivated and engaged to excel to work as world-class professionals.

2. From an organizational perspective, I make an extra effort to make sure that multidisciplinary teams belonging to different functional departments are able to get rid from a restrictive mindset exclusively oriented to functional issues to work by focusing in a systemic way of thinking that is fundamental in assuring success during the execution of organizational projects with high complexity and deep transformational impact.

3. From an organizational viewpoint is crucial to ensure that a transformational project will succeed, to get the sponsorship and explicit support from Senior Management, as is advisable in projects that could have a profound impact over corporate culture, organizational climate and company´s processes.

4. To ensure that the team will perform cohesively and with harmony during the project life cycle, I make my best effort to encourage a micro climate of open communication, a collaborative workplace technologically-driven and application of policies of Knowledge Management, that should be implicitly supported and encouraged by both, CEO and Top Managers.

5. It is instrumental provide the means in assuring operational excellence during project execution. Such a tactic usually signifies that this team will enjoy from the support of different departments such as HR and Technology to ensure so a flawless execution, and at the same time, compliance with the corporate policies and the standards of technology that are substantive to the organization.

6. The synergy among the members of a multidisciplinary team is a key factor in assuring that this group will feel true motivation and engagement to make an extra effort during project execution. Considering that high-performance teams are the result of mixing professionals with different experiences, degrees of seniority and disparate interests, is a wise practice instil within the team a culture of mentorship, where more experienced professionals share their knowledge, experiences and tips with junior professionals.

7. With the aim of providing unequivocal elements of strategic alignment, needed to ensure that operational execution is aligned with business strategy, I am always willing to schedule periodical meetings with one of more of the incumbent Top Managers to discuss and analyse elements of strategic alignment to assure an outstanding project execution.

8. As a key factor to preserve the motivation and commitment of the team, in working hard and excel regardless of what would be the perspectives that could be faced, I am generous and expressive when is time of recognizing the merits of the team as a whole; we celebrate all the goals relevant for a successful project execution, and we are humble enough to learn from failure, and decide after internalizing these experiences, grow as both professionals and individuals.

9. When a new professional must to be incorporated to the team is crucial ensure that this professional will have an excellent fit with the systems of values, policies and principles that are inherent to the organizational culture.

10. In the instances where a project will generate important innovation is advisable to hire expert consultants to assume the role of coaches, as a valid resource to ensure the transference of innovative practices to enrich both the organizational culture and company´s processes.

Tags:
Comment

What Characteristics Do You Need To Be A Good Architect?

Filed under: Emotional Intelligence — 3 Comments
August 17, 2009

My IASA meetings are giving me a lot of material to blog about, and to tell you the truth this weeks meeting was no exception.   Today I want to talk to you about what characteristics you need to exhibit if you want to be a successful architect.

Communication is the most important aspect of your job as an architect.   Without the ability to listen and understand the problem space, as well as communicate your ideas for solving those problems, you’re absolutely sunk.

To be successful in your job, you must be able to communicate with your stakeholders, customers, and technicians on 3 levels, using the well known learning paradigm.  Some people learn by listening to verbal communication,  some learn through written communication, while others learn through visual communication.  To get your ideas successfully through to those following your lead, you must communicate on all three levels.

Understanding, and demonstrating you understand the business and how it works is the second most important aspect of your job.  Without this displayed understanding your customers will never gain confidence in your ability to solve their problems.

The successful architect must be also have an unending thirst for knowledge, and the ability to extract from the customer or stakeholders what he or she wants.   The more you know about your customer, the closer the solution will be to their needs.   Certain examples of this are the ability to ask probing questions, the ability to demo and get feedback, and the ability to involve your customers and stakeholder in the product development lifestyle with many opportunities to contribute.

The ability to apply software/hardware solutions – an inherently abstract concept – to the problem space is vital to being a successful architect.   You must be able to take the business problem, and abstract it into a software design, and implement the most appropriate technology.   This is key, don’t be a technology bigot.

Manage your time effectively.    Stay within your estimated time to complete the project.   We all know things arise that you cannot anticipate during the course of a project.  However, with enough experience you can make your estimates reflect many of the possible problems that come up.  Experienced architects over time develop personal formulas that they use when given an estimate taking into account unforeseen issues.  If the anticipated unforeseen issues do not come up, make sure your work is turned in under budget.  Your stakeholders will get a good feeling about you when you show that you are committed enough to the outcome that your willing to also keep the costs down.

An insatiable desire to learn.  The world of technology and business is constantly changing.   As an architect you must always make sure your toolbox is changing with the times.  Invariably you will be in a meeting with someone who will ask you about a given technological or business concept and you will need to be prepared to handle it.

Flexibility – businesses change get over it.   We are not building bridges where the physics are constant, the distance is known, and the theory has been proven over 1k years.   We are doing – dare I say – something inherently more difficult and that is modeling human behavior.   This increases the level of difficulty while at the same time, gives you the ability to ask your clients and stakeholders what it is they actually want, and if your getting it right.

Comment

How do you know you’re developing what your customers want?

Filed under: Consulting, Emotional Intelligence — Leave a comment
August 11, 2009

I spent an hour last week talking to a couple of developers who are the main people behind a particular product.  I won’t name the product or the company, but let’s just say I have been personally working with this product on site with many different clients for the better part of 8 years.  The question I asked them is this..  “How do you know your developing what your customers want?”

Before I get to their response, let me say this.  I kind of set them up.  So let me give you a bit of background.   The product in question is being rewritten from the ground up.   So the architecture is changing.  But the architecture it self is not really of concern to me.   If they decide to use the MVC pattern with ADF that means as much to me as if they decided to build JSPs on top of hibernate objects using Axis to expose some web services.   What I care about is what happens when I take that product on site and have to make it work in front of the customers.

First of all let me say, I love working with customers.  I love the stress and the invigorating feeling of getting a idea to work, while the customer is breathing over my neck asking me when it’s going to be ready.  I don’t know, maybe I am an adrenaline junky, or maybe I just like to make people happy when they see the product working with their data.   But this part of my job is my most favorite.

With that said, I like to keep the happiness going.   I want to know that the idea I had to solve their business problem using the software they bought, is not only going to work, but is also going to make them happy long term.  I don’t want them turning around next week, and telling other people within their organization how disappointed they are.

So my focus has always been on the end game, and this always leads me to have the following questions floating around in my head.   What will happen when I leave this customer and they are no longer are paying consulting fees.  Will they be able to handle support for the installed solution?   Will they be frustrated by the software?    Do they feel as if their user base will appreciate how the solution improves their job?     In order to satisfy my questions I tend to spend a lot of time talking with the customer beyond what is required of me.

Other than the typical requirements gathering process, some of the questions that I like to pose to my customers when I am working with them.

  • What is the most frustrating part of this implementation?
  • What is the one feature you wish we could have that would make your job easier?
  • Tell me what are your users like?  (this one leads to really interesting thoughts.)  I typically follow up with what are their daily jobs like?
  • What complaints have you gotten from your user base so far during testing? (the responses here are also very different – a new blog posting someday)

So back to my original question.   The answer I got, did not surprise me.  It was a simple “I don’t know.”    Most development shops depend on a few people to tell them what the customers want.  And they code to those requirements.    This is the less costly, easiest way to go about performing development.. so it has it’s advantages.   However I don’t think it works well, and the answer to my question proved it.

This has to change.

Tags:
Comment

Emotional Intelligence in Software Development

Filed under: Emotional Intelligence, Project Management — 5 Comments
August 4, 2009

In software development today, the folks developing most software programs are not the same people interacting with the users of the end product.   This often times leads to software that misses the mark when it comes to expected functionality or application flow, because it is hard to understand what someone wants when you don’t know them.

With most Software firms, as software ages, requests come in from customers either through support channels or through sales and marketing.    These requests are logged against a companies bug and feature database and are later accessed by the development teams.  A typical developer logs into either an issues database, or a feature request list, selects the feature or the bug to work on, assigns himself or herself to the problem, then proceeds to work on the problem.    If there is a question about the bug or feature, the developer will contact someone in support/marketing/sales/consulting for an explanation.    Those they contact  will give their interpretation of the feature and the developer will code to that explanation.

Today in essence customer facing people in sales, marketing, and support drive functionality within the products.    This makes sense in today’s world as these are the people closest to the customer.  They have the most experience listening to customer concerns, business scenarios, and hurdles to make the given business a success.  In IT departments in most large corporations these are the Project Managers, and Business Analysts.  However what if there was a better way?   What if we freed our development teams to just find out for themselves what is the requested feature or bug?  What if we allowed them to call the customers directly and ask them what was meant by their request?  What if we allowed them to run screen shots, and demo’s through the customer in question.  Then what?  I believe you will have two outcomes.

  • You will improve the emotional intelligence of your development teams.
  • Your software will be a lot closer to meeting the needs of the market.

First of all what is emotional intelligence?  Wikipedia tells us this;

Emotional Intelligence (EI) describes the ability, capacity, skill or, in the case of the trait EI model, a self-perceived ability, to identify, assess, and manage the emotions of one’s self, of others, and of groups[1].

What abilities does someone with emotional intelligence poses?

  1. Perceiving emotions — the ability to detect and decipher emotions in faces, pictures, voices, and cultural artifacts- including the ability to identify one’s own emotions. Perceiving emotions represents a basic aspect of emotional intelligence, as it makes all other processing of emotional information possible.
  2. Using emotions — the ability to harness emotions to facilitate various cognitive activities, such as thinking and problem solving. The emotionally intelligent person can capitalize fully upon his or her changing moods in order to best fit the task at hand.
  3. Understanding emotions — the ability to comprehend emotion language and to appreciate complicated relationships among emotions. For example, understanding emotions encompasses the ability to be sensitive to slight variations between emotions, and the ability to recognize and describe how emotions evolve over time.
  4. Managing emotions — the ability to regulate emotions in both ourselves and in others. Therefore, the emotionally intelligent person can harness emotions, even negative ones, and manage them to achieve intended goals.

In other words, someone with emotional intelligence has the able to fully understand the person or persons they are talking to.  They know the right questions to ask, and how to ask them, in order to get more information out of the people in question.  They also know how to gain the trust of others so to make those they are interacting with more comfortable, and willing to share.  These abilities are not something we are born with.  It takes time, energy, and a willingness to learn and interact with people, in order to learn them.  Most of all, a persons EQ can develop over time from simply interacting with other people.

However in today’s development shops developers spend most of their time interacting with software, and are completely detached from the world at large.    Because of this, they rarely get the opportunity to interact with customers.   Management mandates that customers – and sometimes consultants – don’t contact developers directly and that developers don’t contact the customers.

The most important aspect of software development is not which technology you choose, or the amount of lines of code you write, but whether the customer is going to be happy with what you produce.    How close you get to their vision and goal sets should be the ultimate goal of any software development project.

But by limiting the interaction our developers have with customers we limit their ability to know what the customer really wants.  For every layer of interpretive explanation, marketing->sales->product manager->project manager->developer you add risk to the process of getting the initial requirement correct.   For example; ever play that game where 20 people sit around a camp fire, and tell stories around the circle?  The first person tells a story to the second person, the second to the third, and so on.  By the time that story gets around to the 20th person it’s completely different than it was at the begging.   Well this game illustrates how people work.   Every experience consisting of sound, audio, or touch invokes different emotions and thoughts within each person, because  we all have our own vocabularies and experiences to draw from.  These thoughts and emotions are then communicated differently to the next person.

Well if we deny our developers the ability to interact with the source, how can we ever expect them to fully understand the requirements or gain Emotional Intelligence?   We can’t, which I think is how companies die, as their software gets further and further away from the actual business need.

The closer your development teams are to the actual need, the closer the developed product will be to the customers needs.  This doesn’t mean that there is no need for marketing, sales, and support, and  yes you will still have to manage time, scope, and development cycles, be they agile scrum based sprints or waterfall type methods.   However the more connected your development teams are to the needs of the customers, the more they will be able to interpret the requests, and anticipate future needs as they develop because they will understand the requests better.

Ultimately your products will be better, your development teams EQ’s will be higher, your design sessions will be better because everyone has the right information, and your customers will come back to you for more.

Tags:
Comment

Software Development Is Not Like Building a Car – Part III

Filed under: Emotional Intelligence, Project Management — Leave a comment
July 16, 2009

When implementing a project whose team is made up of customer employees, and vendor consultants, there are to be honest many competing agendas in forming that team.  The customer wishes to keep costs down, and utilize the consultants for as few hours as possible and still get the job done.   The Vendor wants their consultants to be vital to the success of the project and to be key players, thus causing the customer to rely on the consultants for a longer period of time.

It’s all money driven from a management perspective.  However despite all that, often times the team members could care less.  Their goal set is always different than those worrying about contracts and costs.   The successful implementation of the project is what is the most important to both consultants and customer employees.   So no matter what the overriding agenda is from management, typical team dynamics are always the same as if everyone worked for the same company.

So given this, why aren’t more mixed implementation teams using Agile development rather than the Waterfall method?

From my experience, teams aren’t using Agile for a few key reasons.

  • Change – Customers and Vendors do not want to change how they have been structuring contracts for years, which they view as a tried and true method.
  • Having two deliverables; Requirement Study, and Finished Product, is much easier to manage than having many deliverables. (Sprints)
  • A perception by the customer that using the Agile methodology will result in longer project times, and therefore higher costs paid to the vendor.
  • Worry by many that the overall goal set of the project is not understood with the Agile methodology so you can’t properly estimate the overall cost of the project.
  • Trust – Most managers do not trust vendor provided consultants.
These are all valid concerns, so how do we in the software industry alleviate them?

I think it is going to take a little more than just getting a few more evangelists into our industry.    Most of the above points deals with fear and trust.  Fear that something might not work is most often times more important than the know ledge that something won’t exactly work well.   So how do we as developers, implementation experts, project managers, and sales people convince the customer and our own vendors to accept this new way of doing it?    First and foremost I believe it’s up to the project teams to prove to management and sales that this  leads to happier customers.   Happier customers tend to purchase more products, and likely will invest in more services as well.   Secondly, we have to begin to think differently.  It is so easy to fall back on the old “document what your going to do, then go do it philosophy” that thinking in the Agile mode becomes an after thought.

So how to we as project teams begin to think differently?

I think it’s important that we all come to some consensus that software development and architecture design is not a process that has been perfected over thousands of years.   It’s a relatively infantile field in regards to physical construction disciplines in that one can say it’s only been around for 60 some years, and that improvement is possible.

If we all agree to this philosophy, then maybe we can begin to feel as if improvement can be made, through a new more flexible methodology.

Also I think it’s important to fully grasp the concept of what Agile is and how it improves team work, and better more directed delivery of solutions.

I would also recommend reading anything by Scott W. Ambler of IBM.  The guy is a very good speaker and accomplished writer.

see, you don’t get any of my responses from yahoo pidgin

Tags: , ,
Comment

Software Development Is Not Like Building a Car – Part II

Filed under: Emotional Intelligence, Project Management — Leave a comment
July 11, 2009

The most common questions asked by my peers and managers regarding Agile software development is this.  What is it, how can it benefit me, and how can it cut my costs down?

So what is Agile Software Development?

Agile software development refers to a group of software development methodologies based on iterative development, where requirements and solutions evolve through collaboration between self-organizing cross-functional teams. The term was coined in the year 2001 when the Agile Manifesto was formulated.  – Wikipedia on Agile Software Development

What this means is this.  The Agile methodology allows for the design and construction of software to be more nimble and accepting of change.   As requirements change, people change, or business needs change over time, the team can refocus it’s effort on a new goal, more aligned with the strategic plan of the organization.   Like a military unit in war, when the general says march to point A initially, but then when you’re half way there, says march to point C instead, this methodology allows for development teams to have the flexibility to operate in the world in which businesses operate today.  It’s hard to plan 12, 24 or even 36 months out, because in most instances knowledge of what business environmental factors will be in place that far out is so unknown.

There are many specific agile development methods.  Most promote development iterations, teamwork, collaboration, and process adaptability throughout the life-cycle of the project. – Wikipedia on Agile Software Development

When we describe teamwork during an Agile methodology construction, we do not just mean the teams of developers and their project managers.   We also mean the stakeholders, and the end users as well.   Constant feedback, and involvement from these people, the key consumers of the end product, will help the development team drift closer to a successful, useful, and better aligned system.

What about costs?

Costs are a little different for the Agile methodology.  One must not think in terms of long term project costs, though this is somewhat  important, but the cost it takes to build each component, and if it is better to spend money one step at a time, with concrete results or simply write one big check and wait.   The difference between Agile and Waterfall regarding costs, have to do with what needs to be asked for up front.   The typical Waterfall project will go through these steps;   obtain a general idea of how long the project will take, and projection of costs.  Go ask for funding.   Start the project by doing a requirements gathering.  If this changes the length of the project go ask for more money.  If money is granted, then the teams begin the process of design, implementation, verification, and maintenance.    At any point in time, if the team runs out of funding, they will go with hat in hand and ask for more funding.  Each time funding is requested, the requester has nothing to show for the other monies that have been spent, except to say we are making progress.  Often times  a project plan will be used to illustrate progress, which will represent a virtual set of goals, with graphs showing estimated tasks, and percentage completion   This is a lot different than building a house or a car or a bridge.   A consumer of these products can see and touch them so even without being an engineer of any kind, they can make a judgment about progress.  If a bridge is half done, the consumer knows it’s not yet safe to use, but it looks like it’s half done.  If a car doesn’t have it’s engine yet, but it has a body, and 4 wheels and a steering wheel, consumers know this car can’t run but the construction teams are making progress.

In software development a stake holder needs to see screen, flow of data, or movement of parts to feel as if progress is being made.    Agile unlike Waterfall lends itself to this, by breaking the project down into iterations, which involve creating a concrete benchmark that will be achieved within the given time line, then acting upon that.   At the end of each iteration the stakeholders and end users can be shown real progress.    If the end result does not meet the new business reality, because the iterations tend to be short lived time frames and tackle small chunks of the overall system, it’s very easy to adjust the iteration’s work product.

The Agile methodology allows for project finalization to occur at the end of any iteration.  But unlike the  Waterfall method, at the end of each iteration you typically have a working product.   It might not be what was originally envisioned, but it is never the less a working system.   This allows the stakeholders to choose between funding additional work or going live with the product as it stands at the end of the iteration.   That flexibility is key to controlling costs with Agile.   I believe it’s better to allow your customer (and stakeholders are our most important customer) to be free to make that choice.

So if you’re a consulting organization, how can this work?

To be continued….

Tags: , ,
Comment
Follow

Get every new post delivered to your Inbox.