Based on different studies and surveys, it has been found that a good 60-70% of IT projects fail and only a lucky minority is able to reach fruition. Success here is being defined as the delivery of the agreed upon requirements while adhering to the proposed schedule and budget. One of the key reasons for project failure is a sub-standard requirement analysis. An activity as upstream in the Software Development Lifecycle (SDLC) as requirements gathering and analysis is crucial to the success of any IT engagement. Ensuring a meticulous execution of this phase is bound to have a positive impact on the downstream activity leading to high quality deliverables and a higher level of customer satisfaction. Failure to do so can translate to higher costs, delayed completion and strained customer relationships.
Gathering from my experience in implementing technology solutions for global clients, I have observed that there are quite a few potential pitfalls and some best practices, which if kept in mind, can save a lot of effort, time and money. As much as these are best practices for customers, they also do have relevance to service providers implementing the solution:
- Don’t bother about the implementation details or related challenges while discussing requirements: People with development backgrounds or experience tend to think about implementation details during the requirements discussions. Why is this considered a problem? The suggestions that follow could be biased towards easier implementations or solutions that they are comfortable with and not necessarily the ones that best address the clients’ needs. Think of the Business Analyst (BA) as a genie who can get you anything and send your wish-list to him/her. Moral of the story – You might want to/have to interact with the technical/solution architects during this phase to check on the feasibility of the requirements while gathering and analyzing them but you should not get biased towards their opinion.
- Requirement documentation sans technical details: This kind of situation arises when the client has some technical knowledge and while discussing the high level requirements, they suggest technical specifications which then may get documented along with the requirements. This will cause bigger trouble if the knowledge is cursory and /or the discussions are incomplete. It is thus a BA’s responsibility to keep such discussions at bay and strive to focus on business needs confined to a non-technical paradigm. To put it straight, there is no place for technical frameworks, tools, technology etc. related information in business requirement document (BRD)! The high and low level design document prepared by an architect will take care of these.
- Be open to experiments; explore new formats / templates for documenting requirements: Different strokes for different folks. One way of documenting requirements may not suit all kinds of projects. The nature of the solution to be developed and delivery methodology should be considered before finalizing an approach. For example, if you are looking for a mobile app or a website where there are a lot of UI components, flow diagrams / prototypes can enhance the development team’s comprehension a lot more than written requirements. Alternately, if you have decided on following the agile delivery model, you might prefer user stories over the conventional use case descriptions.
- Clear and detailed requirements: Ownership for this one lies equally with the client and the BA. Documented requirements should be unambiguous and close ended. Intent should be to specify granular level details, leaving nothing to the imagination of the developers. There should be no scope for multiple interpretations or implementations. All permutations and combinations should be explored and discussed before the requirements are communicated to the development and QA team for their feedback and implementation.
- Make sure that you freeze both requirements and scope before the development starts: More often than not, schedules for IT engagements aren’t very flexible as the clients themselves are under pressure from their investors or their leadership team. In such situations, timely requirements sign off becomes very important in ensuring on-time delivery. Ideally, requirements sign off is the cue for the development team to kick in. Late sign-offs squeeze the planned development time, impact the code quality, increase the chances of schedule slippage and put the development team under stress.
- Guard against too much of volatility: Failure in following point# 5 leads to this challenge which is most commonly observed in the IT services engagements when the changes are requested in the later stages of development. While the intention of doing so is obviously to make a better product; what we need to understand is it is of paramount importance to allocate sufficient bandwidth for process compliance. The problem is not so much with the changes, as these may be inevitable in many cases. Problems arise if these changes aren’t managed properly.
- Adopting agile methodology wherein development takes place in short bursts could be one solution: Change Control is another process to avoid ill effects of volatility in requirements i.e. Document revision, versioning, analyzing changes for their impact on the entire system, revising estimates if required, etc. can ward off any negative impact on the deliverable. Whereas, introducing unplanned changes can hit the end product’s quality because of poor code quality or insufficient unit / integration / regression testing.
Apart from these, succinct and timely communication is one of the most important ingredients for preparing great requirements. It requires synergy between all of the stakeholders involved. This list might not be exhaustive and given the number of variables that impact delivery of IT solutions, a great requirements analysis might not ensure great success by itself. Nevertheless, watching out for these can bring you closer to a favorable outcome. The benefits of a good job done at this stage are sure to percolate to the following phases. Someone said it right – “A good start is half the job done”. I would love to hear your experiences and thoughts on this!