A 2003 research report from MetaGroup (since acquired by Gartner) indicates that 60%-70% of software development outsourcing failures in global 2000 companies are due to poor requirements gathering, analysis and planning. The requirements gathering phase of any project is highly deceptive, since its output is mostly written documents, not executable software. I’ll explain why.
Customers think they’re excellent communicators; service providers think they’re excellent listeners, and thus do requirement documents get produced. Rarely do requirements documents get the level of in-depth scrutiny needed to unearth gaps in precise understanding and restatement.
Reality is that most requirements documents are approved by the clients with minimal checks at the last possible minute! The real trouble starts with the first deliveries of working software, months and sometimes years down the road. Software development projects get into serious trouble at this late stage, since many of the gaps in requirements weren’t identified and flagged for correction at the requirements gathering phase.
The Challenges of Requirements Gathering
In this month’s column, I touch on some of the aspects and characteristics of requirements gathering that make it difficult. I also outline some of the ways in which agile programming methodologies address these problems upfront, so that costly mistakes can be avoided. Both software development outsourcing customers and service providers can benefit from the use of agile methodologies, especially during the requirements gathering phase of projects.
Requirements Are about Business Problems, Not about Features
One of the best ways to avoid problems during requirements gathering is to turn discussions away from the client’s description of what they need at a feature level. Clients should concentrate on the business problem they’re trying to solve. Instead, they try to be helpful and draw upon their experiences with other software applications in describing features they need. This tends to result in features that may not be compatible with each other or that are outmoded.
Users May Not Know What Is Possible
The Internet, the Web, business rule systems, document management systems, workflow systems and many other recent technologies may provide more elegant solutions to business problems a user is trying to solve than features they think of in their current applications. Users may not be aware of what is possible to be solved with their requirements if they jump into feature descriptions too soon, rather than describe requirements in terms of business problems they’re trying to solve.
Business Conditions May Change
The dot-com era proved that competitive conditions mandate software development cycles that run for only a matter of days, not months or years. The pace of change in business is so rapid these days that requirements may be invalid or may need drastic modification by the time design and development is completed. When the first software version arrives, there are always complaints from the clients such as, “This is not what I meant,” or even worse, “You should have implemented what I meant, not what was in the requirements document.” Legally, the service provider may have fulfilled its obligations, but the client’s business problem may not be solved fully, making the project a failure.
Misinterpretations of Requirements
Business culture and differences in communication styles may all lead to misinterpretations of requirements. Interpretations of “Required,” “Highly Desired” and “Desired” sets of features may be different with the client and the service provider. Interpretations of what a description means may be different with a client since those people may be more familiar with their business processes than the service provider. All these often lead to, “Oh, when I said ÔHighly Desired,’ I was expecting it in the software!” This often happens only when it is too late to do anything about it — deep in the software development and testing cycles.
Personnel Changes on Both Sides
Personnel involved with the development effort both on the client side and service provider side may change between the time you do requirements and the time the software is delivered. The people who participated in the requirements gathering phase may no longer be around. Now, everything is subject to re-interpretation and more missteps on both sides.
How do Agile Methodologies Address These Problems?
Agile methodologies such as Scrum or Extreme Programming (XP) address many of these issues that come up in the requirements gathering phase in an effective way. When it comes to concentrating on solving business problems rather than features, early releases allow the software developers to interact with the clients at earlier stages to validate and fine-tune their own understanding of the business problems the client is trying to solve.
Agile methodologies, with their frequent releases and interactions with users, allow the software developers to match business problems with recent technologies and select and showcase their use. This way, earlier on in the project, clients or users get to realize what is possible, given the speed of innovation in technology. Agile methods facilitate experimentation with new technologies.
Long, drawn out software development projects suffer from the possibility that business conditions may change between the time requirements analysis is done and the software is delivered, making the original requirements obsolete. Agile methodologies address this with frequent releases; requirements can be fine-tuned with changes in business conditions.
Misinterpretations of requirements are always brought to the surface and addressed right away when you follow agile methodologies. Early releases and prototypes allow business users or clients to change their minds about what they thought they needed and incorporate what they actually require to address their business problems. Prototyping and frequent releases enable early course corrections and fix problems in understanding requirements before it is too late.
Agile methodologies immunize both software development outsourcing clients as well as service providers against personnel turnover. Since there are always frequent releases, people on both sides can get up to speed quickly and fix their own understanding of the requirements as set out by their predecessors. If they have better or different ideas, those can be incorporated into the frequent releases, thereby smoothing out the ill effects of personnel turnover.
Implications for Outsourcing Clients and Service Providers
Many software development clients and service providers may be comfortable with fixed price contracts. All requirements are gathered in the beginning, one price is fixed for the project, and any deviations are handled using a formal change request process that may have additional financial commitment. Given the inherent problems with requirements gathering efforts as I outline in this article, fixed price contracts end up creating friction between clients and service providers in the end — most of the time.
Use of agile methodologies may dictate that the pricing model be tailored appropriately. A time and materials model with a cap on the total price may be a viable alternative, preserving the interests of both the client and service provider. All anecdotal evidence with projects that have used agile methodologies has pointed to faster, better and cheaper application development, invariably. Clients may end up with precisely the system they need, since requirements were fine-tuned with multiple releases at a price even lower than the maximum cap allowed in the contract. Service providers may end up with more business with a client that is delighted with the results!
Useful Links
Ajira
http://www.ajira.com
