Taken from: http://www.pmi.

org/learning/mastering-project-requirements-planning-controlling-closing-5814

Mastering the project requirements

Michele Maritato, MBA, PMP , PMI-RMP , CBAP - Partner, PMProgetti Srl
® ® ®

Abstract
Requirements are gathered and managed throughout all projects, at different levels of details. The
best practices of the Business Analysis discipline suggest that for an effective management of
requirements, the project manager should follow a “schema” that begins with the identification of
the Business Requirements and progresses with the Stakeholder, Solution and Transition
Requirements (BABOK Guide) (International Institute of Business Analysis, 2009, pp. 5-6). This
®

categorization of requirements (i.e., Business, Stakeholder, Solution, and Transition) has also
been recently adopted by the new PMBOK Guide (PMI, 2013, p. 112).
®

At project Initiating, the project manager must understand the reasons why the project has been
initiated, define the objectives that the project will achieve, and the metrics that will be used to
measure its success. These are called “Business Requirements,” which describe the needs of the
organization as a whole (not of groups or stakeholders within it) and the business value that the
project should deliver. The proper identification of these requirements will give the project the right
start.

At project Planning, requirements are gathered and managed at three different levels: first, the
project manager must understand the needs of a stakeholder or class of stakeholders, and define
how that stakeholder will interact with the solution. These are called “Stakeholder Requirements.”
Then, the project manager must understand the characteristics of a solution (functional and non-
functional) that meets both Business and Stakeholder Requirements. These are called “Solution
Requirements.” And, eventually, when the technical solution is designed, the project manager
must understand the capabilities that the solution must provide in order to facilitate the transition
from the current state of the organization to a desired future state. These are called “Transition
Requirements.” By following this schema, a high-value solution will be properly defined and
implemented.

At project Executing, the Solution and Transition Requirements get implemented, and the project
manager must introduce to the project environment some conditions for continuously listening
(“eliciting”) to the stakeholders’ voice (needs) and detecting the changes to their requirements,
throughout the project. This will ensure a smoother Validate Scope process and minimize the
resistance from stakeholders (PMI, 2013, p. 404).

At project Monitoring and Controlling, the project manager must ensure that all requirements will
evolve in a controlled environment. This will guarantee that change requests are managed in
favour of business value.

At project Closing, some of the requirements are maintained for future use and become
Organizational Process Assets. This will improve the effectiveness and efficiency of future project
initiatives.

In order to maximize the business value, all categories of requirements (Business, Stakeholder,
Solution, and Transition) should be “linked”: Solution and Transition Requirements must be
connected to and derived from the Business and Stakeholders Requirements. In this way, only the
requirements that provide value to the business needs will be implemented.

The purpose of this paper is to analyze the project management processes from the requirements
management perspective, and show the critical points where the project manager should focus the
attention for a healthy project requirements management effort. The topics of this paper are
addressed by the Business Analysis discipline, which can improve the project results by keeping
linked both the project and business environments (Maritato, 2012, pp. 1-25).

Business and Projects

PMI's brand promise states: “Making project management indispensable for business results. ” ®

This statement stresses the link between project and business value, which must be understood
and manage properly.

Every project begins in response to a Business Need that “describes a problem that the
organization is (or is likely to) face or an opportunity that it has not taken, and the desired outcome.
The business need will guide the identification and definition of possible solutions” (International
Institute of Business Analysis, 2009, p. 85). At the beginning of the project, the project manager
must understand the Business Need of the organization, and identify why a change to systems or
organizational capabilities is required. The Business Need generates a request for changing the
organization capabilities, in order to obtain benefits for the business. Though the Business Need
may be generated outside of the project's level of control (PMI, 2013, p. 55), it represents the
purpose of the project and it must be clearly understood by the project manager. Although this
concept sounds quite straightforward, it is not applied in all projects. For example, research
conducted by the PMI - Northern Italy Chapter (www.pmi-
®

nic.org/public/digitallibrary/01_AperturaMaritato2012.pdf, p. 6), shows that seven out of ten PMOs

do not reach the fifth year because they are not able to demonstrate the value to the business (i.e.,
do not understand the Business Need), and therefore are terminated.

On the other hand, projects are the means through which changes are implemented. Project
management best practices suggest that when the project is “formally authorized” it should be
planned—starting with defining “what” has to be delivered (Project Scope) and “how” (Process)—
and then carried out in order to build the project “deliverables.” Through the use of the project
deliverables the organization will obtain the expected business benefits. Exhibit 1 describes this
concept.
 Exhibit 1 – Business and projects.

In order for a project to produce deliverables that provide the requested business benefits, it is
indispensable to understand since the beginning the needs for change of the organization (and this
is not a simple task as business stakeholders always speak a “business language” not a “project
language”; furthermore, they are also used to speak in terms of “solutions” rather than “needs”).
Then the requirements must be gathered, prioritized and modelled into a set of “implementable”
Stakeholder, Solution and Transition Requirements. Then, the project is executed and controlled
and the project team must “listen,” continuously and carefully, to the new needs that might arise
from the stakeholders. And eventually, when the project is completed and the deliverables are
handed out to the business, the performances of these deliverables must be assessed, in order to
catch the limits and the opportunities for creating more business value.

It is immediate then to understand the importance of a robust Requirements Management

approach within the project management environment, for a project to deliver value to the
business—as this value is created before, during and after the project. Project management
focuses most on the implementation of the change, while Requirements Management leads the
project toward the creation of business value.

The Classification of Requirements

In order to create value for the organization through the project, the project manager must first
understand the needs of the organization and define a solution that fulfils these needs. There is a
schema that must be followed in understanding the needs of an organization and translating them
into requirements for implementation. This schema includes the following requirements categories
(PMI, 2013, p. 112; International Institute of Business Analysis, 2009, pp. 5-6):

1. Business Requirements: Describe the needs of the organization as a whole, and not of
groups or stakeholders within it. This category of requirements defines the value of a
solution—the solution that will be implemented by the project;
2. Stakeholder Requirements: Describe the needs of a particular stakeholder or class of
stakeholders and how that stakeholder will interact with a solution. The project manager
must understand the needs of the stakeholder and select the ones that will be implemented
in the project;
 3. Solution Requirements: These requirements can be defined when the two categories
mentioned before are understood. They describe the characteristics of a solution (functional
and non-functional) that meet Business Requirements and Stakeholder Requirements.
These requirements will drive either the selection or the design of the technical solution and
its implementation;
4. Transition Requirements: These requirements are described only when the new solution is
designed. The project manager must understand the capabilities that the solution must have
in order to facilitate the transition from the current state of the organization to a desired
future state. It depends on the “readiness” of the organization to make an effective use of
the new solution: the more “ready” the organization is, the less Transition Requirements are
requested.

Solution and Transition Requirements describe the solutions that will be implemented by the
project. These requirements must be traced back to the Business and Stakeholder Requirements.
Traceability is fundamental, as it guarantees that the project will implement only the requirements
that provide value to the organization.

Mastering the Project Requirements

Here I will present an approach for mastering the requirements throughout a project. Many
concepts reported are described by the Business Analysis discipline, and have been reorganized
based on my experience as project manager and business analyst. The approach described next
can be applied to all requirements categories (Business, Stakeholder, Solution, Transition) and
consists of five stages, as described in Exhibit 2.

Exhibit 2 – The approach for mastering the project requirements.

As project management is an iterative endeavour, these stages might be repeated several times
during the project, for all four requirements categories. The project manager can participate in or
execute all or part of these stages, or some stages can be assigned to other stakeholders (the
Project Team, the Business Analysts).
1. Preparing

In this stage the project manager should clarify the requirements management process and plan
for its execution. The following main processes are performed:

1. Describing at a high level the approach that will be followed for requirements management
in the project, specify team roles, deliverables, analysis techniques, the type of stakeholder
interactions;
2. Identifying and analyzing the stakeholders that will be involved in the requirements
gathering process;
3. Defining the requirements deliverables that will be produced and plan the requirements
management activities;
4. Planning the requirements communication with the stakeholders;
5. Defining and sharing with the appropriate stakeholders the procedures for Approving,
Prioritizing, Tracing, Allocating, and Managing changes to the requirements. If a repository
will be used, it should also be described in this stage.
2. Eliciting

In this stage the interaction is managed with the stakeholders, in order to identify and understand
their needs (and concerns), as well as the environment in which they work. The project manager
must make sure that the actual underlying needs are understood, rather than the stated or
superficial desires. Requirements must be “elicited,” which means “to draw forth or bring out—
something latent or potential or to call forth or draw out—as information or a response”
(International Institute of Business Analysis, 2009, p. 53). The following processes are performed:

1. Preparing each elicitation process by planning the process and preparing the material that
will support this interaction (it can be a one-to-one or group elicitation process);
2. Executing the elicitation, capturing all that it is said by the stakeholders;
3. During the interaction with the stakeholders information will come out, and the
Requirements must be distinguished from the Non-Requirements (issues, risks,
assumptions, constraints, open items, etc.). The Non-Requirements must be tracked as well
for resolution;
4. Confirming that the requirements gathered match the stakeholder needs (Did we
understand properly? Is there any other information that did not come out?).

3. Analyzing

In this stage the requirements are modelled and specified for the implementation. The following
processes are performed:

1. Prioritizing requirements—To decide on which requirements the analysis and

implementation effort will focus most. Understanding the solution “Acceptance criteria”;
2. Modelling requirements—Models are schemas that are used to map the requirements.
Models are first defined and the requirements are then mapped in different formats using
these models. The purpose of this process is to create a set of views of the requirements for
the new solution that are comprehensive, complete, consistent, and understood from all
stakeholder perspectives;
3. Verifying requirements—Requirements verification ensures that the modelled requirements
meet the necessary standard of quality to allow them to be used effectively for the
implementation. It is fundamentally a quality control process that can reduce the amount of
rework caused by low quality requirements;
4. Validating requirements—The purpose of requirements validation is to ensure that all
requirements support the delivery of value to the business. This process guarantees that all
requirements that will be implemented are linked to the business need. Requirements that
cannot be validated are good candidates to be placed out of scope;
5. Documenting Assumptions and Constraints—A solution will fulfil the requirements under
certain Assumptions, and this information must be captured and described as well. During
the elicitation stage, the stakeholders can also state some Constraints (business, technical,
project, etc.). Assumptions and Constraints must be documented in this stage, though they
cannot be called Requirements.

4. Approving

This stage involves communicating, and securing approval of requirements from those
stakeholders who have the appropriate authority. The issues that emerge during elicitation and
analysis must be managed as well. Approval of requirements may be sought at the end of a
project phase or at a number of intermediate points in the project. The following main processes
are performed:
 1. Communicating requirements—Requirements must be organized into “packages” and then
communicated effectively to the audience for approval;
2. Approving requirements—This process is performed to obtain a formal approval of the
requirements that must be implemented. It will create the Requirements Baseline;
3. The issue generated by this Approval phase need to be documented and tracked for a
resolution.

5. Managing

In this stage the changes to the requirements that might arise during the project are managed. And
at the end of each project or project phase, the requirements must be documented in a proper way
for a future re-use. The following processes are performed:

1. Managing changes to requirements—In this process the procedure for managing

requirements change defined in the Preparation stage is defined. The analysis of impact for
the change is performed in an Integrated Change Control environment;
2. Maintaining requirements for re-use—This process identifies the requirements that are good
candidates for long-term usage by the organization. These may include requirements that
an organization must meet on an ongoing basis, as well as requirements that are
implemented as part of a solution.

Exhibit 3 shows the stages for managing the requirements throughout a project and the interaction
with the Project Management Process Groups. An indication on which category of requirements is
involved in each stage is also provided, though this should be considered only at high level.

Exhibit 3 – The requirements management stages and project management process groups.

Now I will describe in more detail how the requirements management approach should be applied
in the Project Management Process Groups (Initiating, Planning, Executing, Monitoring and
Controlling, Closing), as well as the critical points that should be addressed by the project manager
in each of these process groups. In fact, there's a substantial difference in managing Business,
Stakeholder, Solution or Transition Requirements.

Mastering the Project Requirements During Initiating

At Initiating, the project manager should review the output of the process that authorized the
project. This process is called “Enterprise Analysis” (International Institute of Business Analysis,
2009, p. 81).

Enterprise Analysis describes the requirements management activities necessary to identify the
business needs, defines a solution that meets those needs, and justifies the investment necessary
to deliver that solution. Enterprise Analysis follows the process described in Exhibit 4.
 Exhibit 4 – Enterprise analysis.

Enterprise Analysis is a set of sequential processes that should be performed before the project is
authorized. But the results of this process have a heavy impact on the Project Charter structure
and contents, as well as on the process for its approval. The same processes can be followed by
the project manager for preparing the Project Charter. The Enterprise Analysis processes produce
a set of Business Requirements: the Business Need, the Capability Gaps, the Solution Approach,
the Solution Scope and the Business Case (International Institute of Business Analysis, 2009, p.
81). Remember that the subject of these requirements is the organization as a whole.

The definition of the Business Need is critical for the project, and the project manager must make
sure it is clearly understood, as it addresses directly the business value for the organization that
the project should create. It should include the statement of problem or opportunity of the
organization as a whole (why the business want this project?), what the business expects from a
solution (the “Desired Outcome”), and the root cause of the problem. When the organization has
many Business Needs, they should be prioritized. This information feeds directly into the Project
Charter.

The Capability Gaps represents the capability the project should add/change in order to address
the Business Needs. The project manager must understand the link between the Capability Gaps
and the Business Needs. Some risks are highlighted by this process.

The Solution Approach determines the most feasible solution approach for a solution. The
organization chooses one approach rather than another because of risk reasons, cost constraints,
or benefits expected. Addressing this process will provide useful information to the project and to
the Project Charter.

The Solution Scope defines the solution components and the major (high-level) releases in which
the solution will be provided. This information for the Project Charter is very valuable, as well as
the for the planning Scope Management processes (especially the WBS).

And eventually the Business Case shows the direct link between Solution Scope and the Benefit
cash flow. There's an extraordinary tool that is used to understand the link between the solution
components to the business value, it is called “Benefit Logic.” Exhibit 5 shows an example of
Benefit Logic for a project management office project.

Exhibit 5 – Benefit Logic.

Benefit Logic provides invaluable information to the project. It clearly demonstrates the link
between solution components and the business benefits. Understanding these links will drive the
Planning, Executing and Monitoring and Controlling processes: project change requests that
cannot fit into this logic are good candidates to be refused.

At the end of this process, the project manager obtains a Project Charter tightly linked to the
business needs. This will improve the stakeholder buy-in of the project, and the project will start in
the proper way.

Mastering the Project Requirements During Planning

It is during Planning that Stakeholder, Solution and Transition Requirements are understood most.
The starting point is the understanding of Stakeholder Requirements, which describe the needs of
a particular stakeholder or class of stakeholders and how that stakeholder will interact with a
solution. The stakeholders have many (often personal) requests; Stakeholder Requirements must
be traced back to the Business Requirements: if a Stakeholder Requirement cannot be referred
back to a Business Requirement, it is a good candidate to be excluded from the project (this has
an impact on the project scope).

When the Stakeholders Requirements are understood, we can derive from them the
characteristics that the solution must have to provide value to the business. We call these Solution
and Transition Requirements. Solution Requirements are identified before the technical solution is
selected and/or designed. They describe the characteristics of a solution (functional and non-
functional) that meet business requirements and stakeholder requirements. Transition
Requirements are described only when the new solution is designed, and they describe
capabilities that the solution must have in order to facilitate transition from the current state of the
enterprise to a desired future state. It depends on the “readiness” of the organization to make an
effective use of the new solution (see Exhibit 6). And these requirements must be implemented by
the project as well.

Exhibit 6 – Transition requirements.

Stakeholder, Solution and Transition Requirements must be prioritized, and the process of
prioritization can follow different (sometimes mixed) approaches (International Institute of Business
Analysis, 2009, p. 101): Business Value, Business or Technical Risk, Implementation Difficulty,
Likelihood of Success, Regulatory or Policy Compliance, Relationship to Other Requirements,
Stakeholder Agreement, and Urgency. The process of prioritization can be very time consuming
and challenging: the stakeholders will generally attempt to avoid difficult choices, fail to recognize
the necessity for making tradeoffs, or desire to rank all requirements as high priority; and the
solution development team may intentionally or unintentionally try to influence the result of the
prioritization process by overestimating the difficulty or complexity of implementing certain
requirements. This is a challenge for the project, and the project manager should be aware of it. At
the end of this process, the list of prioritized requirements should be produced.

Stakeholder, Solution and Transition Requirements then are analyzed, which means that they are
mapped into schemas. All Stakeholder, Solution and Transition Requirements can fit in at least
one of the following schemas (see Exhibit 7).

Exhibit 7 – Schemas for stakeholder, solution and transition requirements.

Mapping the requirements into the schema will improve the process of communication with the
stakeholders and the stakeholder engagement.

Once the requirements are modelled into these schemas, a quality control check should be
performed (this is called Requirements Verification). This quality control will reduce the amount of
rework during the implementation phase. The quality control check is done for each single
requirements (to remove ambiguity, and guarantee testability, feasibility, correctness,
independency, atomicity of each requirement), and for the entire set of requirements (to remove
redundancy, and guarantee consistency and completeness of the set of requirements).

After Requirements Verification, the project manager must ensure that the requirements are
validated, to ensure that they deliver value to the business. All requirements that will be
implemented must be traced back to the Business Need; requirements that do not get validated
are good candidates to be placed out of scope of the project (or the project charter must be
enlarged).

Requirements verified and validated must be communicated and approved so they can be
implemented. Before the implementation, Stakeholder, Solution and Transition Requirements are
mapped onto the technical solution components, in order to maximize the value for the business.
This activity is called “Requirements Allocation” and guarantees that the best value will be
delivered by the project to the business.

Assumptions and Constraints must be documented during Planning. This has an impact on the
project Risk Management processes.

Mastering the Project Requirements During Executing

In Executing, the Solution and Transition Requirements get implemented. The project manager
must create a link between the implementation and the business environments, establish some
feedback mechanisms to keep the project tight to the business environment during the
implementation. During Executing some requirements might need clarification, some stakeholders
might change their mind (requirements), and new requirements might be elicited. The project
manager must ensure that the voice of the business is heard during the project execution. This will
minimize the resistance from stakeholders (PMI, 2013, p. 404).

Changes to requirements might be requested, and must be documented and fed into the next
Monitoring and Controlling process group. It is the voice of the business that is heard by the
project.

Mastering the Project Requirements During Monitoring and Controlling

By following the principles of requirements management previously described in the Initiating,
Planning and Executing process groups, the project manager will obtain in general a reduction in
the number of change requests to be managed, which is definitely an important benefit for the
project.

Furthermore, the Requirements Traceability guarantees that the requested changes will be
evaluated against the business requirements (business value). This makes it easier to weight cost
and benefits of changes. It also makes it easier to obtain extra funding for change requests, if it
can be proven the value for the business. And there's also an improvement in the scope validation
process. As the business is always kept engaged in the project, the validate scope process
becomes smoother, more straightforward.
 Mastering the Project Requirements During Closing
At project Closing, those requirements that are good candidates for long-term usage by the
organization are identified and documented. These may include requirements that an organization
must meet on an ongoing basis, as well as requirements that are implemented as part of a
solution. The value that can be provided by documenting these requirements for re-use will bring
great value to the organization. Imagine the projects that start without knowing what was done
before, and why some decisions were made. A lot of time is wasted in deriving what was done
before, why and how. This waste of time might be reduced by a consistent process of
requirements documentation.

Final Words
Establishing a proper requirement management process will provide high value to the project. It
will give the project the right start; it will lead the project planning towards the creation of value for
the business; it will guarantee the voice of the business is heard throughout the entire project; it
will increase the maturity of the organization in creating business value through the projects.

The project manager must first understand that requirements are understood at different levels,
involving many stakeholders. And the schema, which includes Business, Stakeholder, Solution
and Transition Requirements, should be followed.

Mastering the project requirements is considered a complex endeavour but in fact it isn't. This
paper presented an approach to Requirements Management that includes the following stages:
Preparing, Eliciting, Analyzing, Approving and Managing. For each stage the main processes are
also described, in order to focus the effort of the project manager on the most important topics.
This approach can be used in every project, though the project manager must understand that the
approach might change throughout all project management process groups: the category of
requirements is different at Initiating and Planning, and the weight of each stage might change as
well along the project.

Bringing into the project a professional Requirements Management approach can significantly
improve the project results and lead the project in delivering a real business value.

References

Project Management Institute. (2013). A guide to the project management

body of knowledge (PMBOK guide 5th edition). Newtown Square, PA:
®

Project Management Institute.

International Institute of Business Analysis. (2009). A guide to the business

analysis body of knowledge (BABOK guide) - Version 2.0. Toronto,
®

Canada: International Institute of Business Analysis.

Maritato, M. (2011, April). Considerazioni sul project management e sulla

business analysis. OnProject, 1-3.

Maritato, M. (2012, May). Project management and business analysis: The

dynamic duo. PMI -NIC EMEA Congress.
®
Maritato, M. (2012, October). Creating a PMO business case through a
business analysis approach. PMI -NIC North America Congress.
®

Hill, G. M. (2007). The complete project management office handbook (2nd

ed.). Boca Raton, FL: Auerbach Publications.