Mastering the project requirements

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.