Home Page > Publications > Challenges of Requirements Gathering And A Viable Alternative

Challenges of Requirements Gathering And A Viable Alternative

Many mid-market clients may be comfortable with fixed price contracts, because IT Directors are a risk averse breed that like to know how much of the budget is spent and by when. This engagement model relies heavily on the waterfall methodology where 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. Given the challenges business face in terms of gathering requirements effectively and continuously changing environment (requirements), fixed price contracts often end up creating friction between clients and service providers. We have seen cases where clients ended up paying more due to the contingency the service provider needed to include in the contract as a safety buffer. This article will review some of the challenges with gathering requirements and a possible alternative engagement model.

All clients think they are strong communicators, and every service provider believes they have the listening skills of an auditor of a congressional hearing, yet according to Gartner about 60-70% of projects run late or become more costly due to poor requirements gathering. Both parties are partially to blame as they are very eager to start the project with minimal checks, the client because they want the project delivered ASAP and the service provider wants to start invoicing, so rarely do requirements documents get the level of in-depth feedback & analysis needed to clarify differences in scope and understanding. So six months down the line the real trouble starts since many requirements were not identified and flagged. Before outsourcing, that level of detail up front did not matter as the business person could just bully the internal IT resource into making the changes, but that doesn't work in an outsourced scenario.

Here are some of the common challenges with requirements gathering which both clients and service providers can benefit from addressing early on.

Business Conditions Are Forever Changing
The pace at which businesses have to adapt often renders requirements gathered even a few months prior, obsolete. When the first software version arrives, the service provider may have completed exactly what was specified 6 months back, but the business has moved on and may describe the project as a failure. This can be avoided if the milestones are set with more frequent releases. Another issue with long development cycle times is that both client and service provider resources may change. In these cases, anything could be subject to re-interpretation and misunderstandings from both sides.

Requirements Are Bogged Down In Features
One of the most common mistakes about requirements gathering is that it focuses too often on specific functionalities and features and not on addressing the business problems. As commented on Sourcingmag.com "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 Do Not Know What Is Possible & Vendors Are Afraid To Tell
Many clients do not know what is possible, and they focus instead on analysing the limitations of existing applications. Users may not be aware of what is possible with new technology, and the service provider may be afraid of opening Pandora's box. Rather than describe requirements in terms of business problems they're trying to solve, service providers sometimes focus solely on the technical solution. This can be a big disadvantage to both sides, as a supplier's business and industry knowledge could result in simpler technical solutions that provide a bigger business impact.

Communication & Language
The prioritisation and specific nature of requirements often vary across a project's stakeholders. Different interpretations often get discovered too late in the development life cycle, when changes can entail significant cost and effort. Building a prototype during requirements gathering can often help settle any difference in understanding.

Agile methodologies like Scrum and EX (Extreme Programming) address many of the common issues in the requirements gathering phase.

- Early releases allow the software developers to interact with the clients to validate their understanding of the business problems the client is trying to solve.
- Clients or users get to realise and visualise what is possible, and it helps with participation and buy-in, very often big IT projects are seen as not ever being achievable since the user has to wait 6-12 months to see anything.
- Prototyping and frequent releases enable early fixes and identifying problems in understanding requirements before it becomes too costly to change.
- Frequent releases allow business users to change their minds and incorporate what they actually require.

Since many mid-market companies prefer fix-priced projects, our recommendation is they should run a pilot agile development project with a time and materials model and a cap on the total price, preserving the interests of both the client and service provider. If this results in a successful delivery they can scale up the delivery model to some larger IT project, it would not be a surprise if your organisation achieve higher customer satisfaction and potentially less cost for development efforts as minimal rework is required.

Quick Contact Form
Company Name
Contact Name *
Telephone Number *
Email Address *
Message