Effective Requirements Planning
Why do I need to plan?
When I think of requirements, a picture of Mr. Potato Head comes to mind. There are a bunch of pieces and an infinite number of ways to put the pieces together. You need an approach for building the requirements specification.
- Ineffective BA techniques
- Inability to respond to project evolution in an organized manner
- Missed timelines
- Forgotten sections of requirements
- Lack of alignment between the capacity of the team and the schedule
As Dwight D. Eisenhower said “In preparing for battle, I have always found that plans are useless but planning is indispensable”. Additionally, a requirements effort is a journey that you as the BA are leading a team along. If you don’t have a solid plan how can you communicate a clear vision to your team and gain their commitment?
In the BABOK, “Plan Business Analysis Approach” is the 1st task in the 1st knowledge area “Business Analysis Planning and Monitoring”. This highlighting that this task is the place to start when developing requirements. But so often we have no time to plan upfront. Our PM comes to us and says I need the requirements done in 2 weeks. As good team players we get them done but then pay the price by constantly changing the requirements since they were not done right. We all know the cost of poor requirements to IT organizations. Per the Standish Group Reports1, only 32% of IT projects are successful and 20% of the features / functions delivered are used regularly. Multiple studies have traced these IT failures to poor requirements definition.
Therefore, I am proposing we as BAs need to embrace the need to plan and to sell this to our PMs. I hope this article give you the background you need to develop a solid Requirements Approach and the ammunition to sell this to your PM.
A Requirements Approach allows you as a BA to:
- Select the best methodologies and techniques for requirements development based on the needs of the project and stakeholders
- Develop consistent requirements
- Gain commitments from all stakeholders to provide necessary time and input
- Respond to project evolution in an organized manner
- Clearly communicate BA commitments and establish a BA contract with IT and business stakeholders
But it is not all about the BA benefiting! Developing a solid Requirements Approach benefits the entire team. For Project Manager, the Requirements Approach can be the basis for developing detailed, accurate project plans. For Business Partners, the Requirements Approach provides visibility which sets clear expectations and fosters a collaborative environment. For the QA professionals on the team, the Requirements Approach provides insight into the requirement deliverables so the testing efforts can be proactively planned at the start of the project.
The Lead Business Analyst develops the approach and collaborated with the other BAs on the project, the PM and the business partners to refine the approach so it meets everyone’s needs and incorporates the team’s diverse perspectives. The Requirements Approach should be an official project deliverable but does not have to be a 100 page document. A short document or a PowerPoint is sufficient. The goal is to think through the approach and get team buy-in, therefore right-size the deliverable to meet this goal.
How do I create a Requirements Approach?
A Requirements Approach is a roadmap for the developing requirements for a project. The Roadmap should cover all phases of requirements development:
Planning – Develop a plan for gathering and communicating requirements.
Eliciting and Validating – Extract information to prepare to document the requirements.
Documenting – Collate, author, and publish requirements to stakeholders.
Approving – Secure acceptance of the requirements from the stakeholders.
The following components should be defined for the Planning phase in the Requirements Approach:
- Scope – Clearly define what is in scope for the requirements development effort and enumerate out of scope items. Note, this is not the scope of the project which should be clearly outlined in a different document.
- Assumptions, Dependencies and Risks – List all things that effect or constrain the requirements development effort.
- Standards – Define the industry, company and divisional standards guiding this effort.
- Requirements Development Team – Define roles (both IT and business) and individuals that fill these roles.
- Requirements Development Communication Plan – Define communications to be sent regarding requirements development to keep key stakeholders informed on progress. The key stakeholders are those defined during stakeholder analysis.
- Requirements Development Project Plan – Key factors that affect the requirements development project plan such as BA resource constraints along with high level timelines and resources for the requirements development effort. A link to the requirements development project plan is also included.
- Requirements Change Management – Define how changes to the requirements will be handled.
- Methodology – This is the core of the requirements approach since it clearly defines how the requirements development effort will be structured.
Let’s discuss the methodology component in more detail. In the methodology component, the following should be defined:
- SDLC methodology (Agile, Waterfall, Iterative, etc.)
- Types of requirements to be developed (Business, System, Analytics, Integration, etc.)
- Steps for defining each type of requirement
- Tools, techniques and details for each step
To help make this more real, here is an example of a Methodology section from a real life project:
The Planning section is the bulk of the Requirements Approach. The table below shows the components for the other 3 phases:
That covers the components of a Requirements Approach. Just remember, this is not a once and done artifact! Get your initial approach defined but be ready to continuously refine as the needs of the project and team evolve.
Finally, use your tools to enforce your requirements approach:
Good luck with planning a successful requirements development effort.
Don’t forget to leave your comments below.
1. Chaos Study 2009 – www1.standishgroup.com/index.php
2. BABOK v2.0 2009 – http://www.iiba.org/BABOK-Guide.aspx
Resources for Related Topics:
– Stakeholder Analysis – BABOK v2.0 Section 2.2
– Communication Plan – BABOK v2.0 Section 2.4
– Work Breakdown Structure – BABOK v2.0 Section 22.214.171.124