Collect Requirements

User-requirementsThis process is as important and vital for the whole project as laying a proper foundation is for the building. Weak or incomplete requirements collection results in a project finishing, if it finishes at all, with cost, scope and schedule much above the estimates and budget. All the subsequent processes in the planning phase depend upon the requirements collected at this point. Projects having properly documented and collected requirements have very high completion and success rate.The real success is to deliver the project within performance baselines, not just completing.

Although the high-level requirements are already mentioned in the project charter, this process involves gathering specific inputs and requirements from ALL stakeholders. This process is so critical that sometimes even a single missed requirement can result in a total project failure or at least can cause significant changes in the project. There are different ways of collecting the requirements, as per the circumstances and situations, which are briefly described below:

Interviewing: The project manager along with his team, business analysts mostly, conduct interviews with stakeholders to gather requirements for a specific element of the project. These interviews can be conducted individually or in a group. This technique helps in getting requirements specific to individual elements of the project and sometimes it becomes tedious to sort them out to ensure that there is no repetition.

Focus Groups: This is similar to conducting group interviews with the difference that individuals from the same field/department are gathered together so the discussion remains focused on a particular portion of the project. All the group members are ideally subject experts and share their opinions with each other. The focus groups are managed by a moderator, project manager or any of the project team member.

Facilitated Workshops: The stakeholder with different perspective about a particular element, e-g. designers and end users, are brought together to discuss the different aspects of the requirements. The end result is mostly the consensus about the requirements for that particular element.

Brainstorming: The idea is to gather people to think like a group, altogether on one idea to solve a problem or determine the scope. An idea is presented in front of the group and the inputs from everyone generates new ideas or requirements. Only the relevant and workable things are noted and agreed upon in the end.

Delphi Technique: Don’t be haunted by the term. It is very simple to understand and this is how it works; a request for information is sent to subject experts anonymously. Their response is compiled together and sent again to everyone. The process is repeated until the consensus is reached.

A few more as mentioned in various articles about collecting requirements are mind maps, affinity diagrams, questionnaires and surveys, observation, prototypes, etc. No matter what technique you adopt as per your need, the end result should be a compilation of requirements as complete as possible. As discussed earlier, a comprehensive Collect Requirements process will help you avoid unforeseen risks, unwanted changes, delays, cost overrun, etc. and will help you complete your project within the project baselines.

On a lighter note, though most of you must have seen this, have a look at the following image of a flawed requirements collection process:

projectcartoon