Understanding Customer Requirements

For any project to be a success, understanding the customer requirements and being able to map it correctly with the deliverables is the key. Customer requirements form the foundation on which the entire project is built. If the requirements are not understood, then a Project Manager (PM) has started on a wrong foot and is surely headed towards a disaster! Understanding customer requirements, which is formally known as the "Requirement Gathering" process, involves interacting with people and hence a PM has to possess excellent interpersonal skills and has to be good at managing stakeholders' expectations. Stakeholder management is such an important subject that the Project Management Institute has introduced a new knowledge area for "Stakeholder Management" in its latest edition of the Project Management Body of Knowledge (PMBOK)!

Requirement gathering is a part of the Planning Process Group as per the PMBOK, which means the requirements have to be collected, analysed and understood properly even before the project execution begins. We all know that the nature of any project is such that it keeps evolving as and how the project progresses. Similarly the requirements are also never 100% refined in the beginning of the project and they evolve as the project progresses. Typically, the requirements that a PM gets from the customer is a set of high level requirements that usually define the scope of the project. The requirements then have to be refined further by ensuring that the person responsible for collecting and analysing the requirements (typically, a Business Analyst) understands the requirements to the finest detail. PM has the overall responsibility of tracking the progress of the entire requirement gathering activity as per the project plan and also checking relevant documentation follows the requirement gathering. To ensure that all the requirements are gathered properly, including technical requirements, the BA needs to have a sound knowledge about the customer's business, though he/she is not expected to be the subject matter expert. A bit of technical backgound also helps. Having sound knowledge about the customer's business helps the BA to ask right questions to the customer during requirement gathering. The knowledge can be acquired either by broadly studying the customer's business processes OR by previous exeperiences of working on similar projects. Having no knowledge at all of customer's business may hamper the requirement gathering process since there are chances of BA missing out on finer details of the requirement. Even the confidence level of the customer in such cases is low, since the customer is not sure if the requirements will be understood properly and if the project deliverables will be mapped to the requirements correctly. In case if the BA is newly appointed, without any prior experience OR is new to the customer's business, it becomes PM's perogative to ensure that the BA gets enough knowledge about the customer's business from the inhouse subject matter expert, before the BA gets on to the requirement gathering activity.

The requirement gathering process.

We will not be discussing any of the methods for requirement gathering, since there is enough information available online about it. Best place to read about the same is the PMBOK. What we will be discussing here is important pointers to remember while gathering requirements. These pointers are applicable to both, BAs and PMs.

1. First and the foremost, do not go for requirement gathering empty minded. What I mean here is, do enough study of the high level requirements that customer must have already communicated, the scope of the project, the goal(s) and the objectives that the project needs to achieve, the pain points that the project needs to address and finally, the broad understanding of customer's business.
2. Secondly, do not assume anything. Assumptions are good to have, since they show that you have done your homework before coming for collecting requirements. But remember, the only person to confirm whether your assumptions are correct, is the customer. So ask the right questions to the customer and do not leave anything on your assumptions.
3. You cannot ask the customer to narrate the entire story while you just do a job of taking notes. That will leave a very bad impression with the customer and he will assume that you are merely there to do a stenographer's job. Customer expects you to get engaged in a fruitful discussion, that will show your understanding of his business and the homework you have done. Remember, your insights into customer's business and suggested improvements thereof will prove much more valuable than the actual project deliverable.
4. Being a BA puts you in a position where you understand most of the requirements (assuming you have done enough homework as mentioned in point No. 1 above) even without explicitly being elaborated by the customer. In that case it's always better to document the requirements where you need specific clarifications and understanding and go prepared for the requirement gathering discussions. That will not only save a lot of time and effort on your part, but it will also keep the discussions focused. When the discussions are open, they tend to go off track and thereby waste a lot of valuable time and effort.
5. Always ensure that the requirements given by the customer are within the scope of work. There might be situations where you may not be able to ascertain at that very moment if the requirement is outside the scope. In such scenarios, mark those requirements separately and discuss the same internally with the PM and the Project Sponsor. This is important because the Project Sponsor has the final authority to approve or reject any requirements that do not fall with the scope of work and the PM has the responsibility of communicating the same to the Customer.
6. All the requirements gathered have to be documented in an AS IS format. Also, once the requirements are documented, the BA needs to have a formal sign-off on the same, since this document provides the base reference on which further documents, such as the Functional Specifications Document (FSD) or Software Requirement Specifications (SRS) can be prepared. Going ahead, even the Requirements Traceability Matrix (RTM) can be referenced back to the Requirements Document.

Requirements documentation and tracking.

As mentioned earlier, all requirements MUST be documented at various stages of the project. Each requirement needs to be mapped to a corresponding deliverable and needs to be tracked throughout the project. The most standard way to map requirements to deliverables and track them as they progress from a requirement to a deliverable, is to maintain a Requirements Traceability Matrix (RTM). The RTM is a comprehensive map depicting each requirement throughout its journey from a stated requirement to a final deliverable. Each requirement collected passes through various stages and changes forms - from a requirement to functional speficiation to a test case to a final deliverable. At each stage, the requirement gets more elaborated and gets closer to the form of output that is expected out of that requirement. 
When the requirement is initially collected, it is documented in the form of a Requirements Document. The document plainly lists down all the requirements collected by the BA and also prioritizes each requirement. The priorities can be set in whatever form that suits the organization, viz. High, Medium, Low OR Must Have, Good To Have, Can Have OR Essential, Useful, Desirable, etc. The document also needs to ID each requirement, so that a requirement can be identified using that ID in the RTM.

Once the requirements are documented and signed off, they need to be elaborated further so that they can be handed over to the production team. Different organisations use different terminologies for this type of a document - Functional Requirements Specifications (FRS), Software Requirements Speficications (SRS), Functional Requirements Document (FRD) or Functional Specifications Document (FSD). Whatever the name, the primary objective of this document is to elaborate a requirement in such a way that the design and implementation team can work on those requirements and produce the required deliverables. This document does not necessarily need a formal approval from the customer, but nonetheless needs to be shared with the customer, so that the customer also has an understanding of what to expect from the final output. This document, too, needs to ID each functional specification mentioned in the document, so that it can be mapped against the corresponding requirement in the RTM.

After the FSD/SRS/FRD/FRS is in place and in principal accepted by the customer as well as the project sponsor and the project manager, the Quality Specialists from the Quality Control team need to pitch in. They need to come up with test cases that can validate the requirements and set a valid pass/fail criteria for each requirement from the Requirements Document. The test cases need to consider all the aspects of the Test Plan prepared during the planning stage and also need to be validated by the BA as well as the customer. Only once the BA and the customer give a formal go ahead on the test cases, can they be applied to the output produced by the design and implementation team. Each test case in the test case document has a uniques ID which is mapped against the corresponding functional specification and the requirement in the RTM.

As the project progresses, some of the requirements change. Basis the prioritization done in the earlier stages of the project and the impact of the change to the overall project scope, cost and time, the PM needs to anyways get the change approved by the CCB (Change Control Board). But if the requirements are being tracked regularly, it also helps the PM in assessing overall impact (requirement, functional specification, the test case and the corresponding deliverable already produced, if any) and in the estimation of change in the cost and timelines.

As discussed earlier, the requirements form the foundation of any project and hence the importance of documenting and tracking all the requirements till the end of the project. It has been observed that in many of the projects that fail or are loss making, requirement management takes a backseat. It is also seen as unnecessary investment from time and cost perspective by most of the organisations. What they fail to understand is unless requirements are managed and documented properly, the project team will never be able to align itself to the project requirements and thereby to the goal that the project needs to achieve. As per the global standards, any project needs to spent 10% of the project time on an average in gathering and analysing requirements. Any effort lesser than that is bound to result in poor quality deliverables not living upto the customer's expectations, and thereby causing re-work and thereby inflating project costs and timelines.

There is much more to discuss on requirement gathering, beyond the scope of this article. You can find abundant information about the topic on the websites that are dedicated to Project Management. Some of the references I have already mentioned in my previous article - "5 mistakes IT Project Managers should avoid".

Hope you enjoyed reading this post and found it informative enough for you to understand the importance of requirement gathering and management. Please feel free to voice your opinions by commenting on this post. Any suggestions/apprehensions are welcome!