In previous article we were in the initiation phase where we discussed about Project charter and Stakeholder identification. Now we are moving to Planning phase of Project life cycle. As Saying goes “Failure to Plan is planning to Failure”. In this we plan for the planning of project.
Collect requirement phase is part of Scope Management Knowledge area as per PMI PMBOK 5 guide. This is the process to know & document the clear understanding needs of stakeholders whole project success is directly influenced by how much care we have taken in capturing & managing requirement. It’s about managing customer expectation. Through requirement we can determine the end deliver of the project & how to address specific requirements of client.
This is second most important process after stakeholder identification process. Reason for majority of failed project is insufficient or wrong requirement captured.
What generally happens is Business Analyst (BA) gathers and captures the requirement. Project team translate those to technical requirement and the implementation starts. If there is any lacking in the captured requirement then there will be problem as client might not accept the delivers or may not even ready to pay. So Project team has to implement the additional requirement without any extra payment. So that may cause the performing organisation financial losses, reputational loss or even legal suit depending upon the project criticality.
Key Benefit of collect requirement is that it provides the base on which scope of the project is defined and managed.
So let’s talk about the process collect requirement in terms of its input, tools & techniques and Output.
Main inputs in context of our discussion so far are stakeholder register which provide information stakeholder requirements, expectations and concerns and Project Charter that provides high level description of the product, service or result of the project.
Tools & Techniques:
- Interviews: Talk to stakeholder directly using prepared or spontaneous questions and record their answers.
- Focus Groups: Discuss with pre-qualified stakeholder and SME to und understand their views and expectations from the proposed project.
- Facilitated Workshop: conduct interactive session to bring key stakeholders together to define product or project requirements. This is a good way to define cross-functional requirements and differences.
- Group Creative Technique: you can use several creative techniques to identify project requirements like
- Brainstorming: This technique allows you to collect multiple ideas. As saying good way to get best idea is to get lots of idea. This technique helps in that. Just remember you don’t judge or disqualify any idea from any member in this technique no matter how impractical or improbable that may sound.
- Nominal group Technique: This technique used voting process to rank the ideas generated in brainstorming session to prioritize and further brainstormed.
- Affinity diagram: In this technique ideas are classified into groups for review and analyses.
- Group Decision making technique. This technique is used to prioritize and classify project requirements in a group. You are probably familiar with these techniques namely:
- Unanimity: Here everyone agrees on single course of actions.
- Majority: A decision is reached with support obtained from 50% of participants.
- Plurality: Here decision is reached whereby the largest group decides. Largest group need not be 50%.
- Dictatorship: Here one individual makes the decision. This is not ideal but sometimes helpful when the consensus is not achieved among the group.
- Prototype: In this a working model is provided to get early feedback on requirement and understanding.
- Benchmarking: This technique is about comparing the practices, process of comparable organisation.
- Observation: Also known as “job shadowing” is an excellent technique to see what could be the requirements. It’s usually done externally by an observer viewing business expert performing a job to uncover hidden requirements.
- Documents Analyses: This used to elicit requirements by analysing existing documents & identifying information relevant to requirements. E.g. Business plan, marketing literature, Process flow, Business rules & policies, problem logs.
There are two outputs from the process of collect requirements.
1 Requirement Document:
This document describes how individual requirements meet the business need of the project. Before being baseline requirement needs to be measurable and testable, traceable, complete and acceptable to key stakeholders.
Components of Requirements can include but are not limited to:
- Business requirements: Business and Project Objectives, Business rules, guiding principle.
- Stakeholder requirements: stakeholder communication and reporting requirements, impacts to other entities inside or outside of performing organisation.
- Solution requirements: Functional and non-functional requirements, technical and standard compliance, support and training requirements, quality requirements, reporting requirements.
- Project requirements: Acceptance criteria, level of service, performance, safety , compliance.
- Transition requirements
- Requirement assumptions, dependencies and constraints.
2. Requirement traceability matrix: This document is a grid that contains requirements from their origin to their deliverables. Through this document we can trace where and why each deliverable is worked and delivered may be its in designed, implemented or testing phase and hence can be updated during other planning phase processes. Its format could be
Id | requirement desc| Business object|project Objective|Designed|developed|tested|
This concludes our discussion of PMI ‘Collect requirement’ process. In next discussion we will stay in the Planning phase and will talk about ‘Define Scope’ process.