Effective Requirements Planning

Description

Requirements Planning is an important part of the requirements development process that is often overlooked. Requirements Planning is the brains of requirement development and enables successful execution of the requirements phase. Developing a Requirements Approach is a way to capitalize on the following benefits of effective requirements planning:

• Consistent requirements
• Accurate project plans
• A clear vision that communicates expectations and provides a collaborative environment with business partners

Learning Objectives

• Discover why a Requirements Approach makes the requirements effort successful
• Understand what should be in a Requirements Approach
• Learn how tools can be leveraged to enforce the Requirements Approach

Key Arguments

If you don’t plan before you jump into the requirements development, your ability to pick the right techniques and respond to project evolution is severely limited. 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? Effective requirements planning has many tangible benefits including consistent requirements, accurate project plans and better collaboration across the team.

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.

This same principle applies to requirement development. If you don’t plan before you jump into the requirements development, you may experience the following consequences:

• 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:

To make getting started easier, I created a template:

Good luck with planning a successful requirements development effort.

Sources:

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 2.3.4.4

Author:  Kathleen O'Brien, Associate Director of Business and Technical Analysis

Kathy is an Associate Director of Business and Technical Analysis at Merck & Co., Inc. in West Point, PA. Kathy has over 18 years of experience in information technology, with 13 years of concentration in business analysis in industries such as defense, financial, power, and pharmaceutical. In her current role, she leads requirements development and management efforts for various key initiatives in the Global Human Health IT organization, which supports sales and marketing functions. She is also an earnest contributor to various business analyst communities at Merck, including the Analysis Skills Center, which is a Center of Excellence for business analysis standards and best practices. Kathy is an active member of the Greater Philadelphia Chapter of the IIBA and is currently serving on the board as the chapter secretary.