Mastering project requirements

Abstract

Requirements are gathered and managed iteratively throughout projects, at different levels and with a different focus. The best practices of the Business Analysis discipline suggest that for an effective management of requirements, the project should follow a “schema” that begins with the identification of the Business Requirements and progress with the Stakeholder, Solution and Transition Requirements (IIBA, 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, 2012, p. 112), and intends to provide the Project Managers with a very powerful frame for collecting and managing the project requirements. Keep in mind that early requirements are manifested even before the project is initiated, then during the project and eventually also after the project is closed: the Project Manager must have the capability to keep the project linked to this continuous “stream” of requirements, if the project intends to deliver high value to the business.

At Project Initiating, the Project Manager must first understand the reasons why the project has been initiated, define and share the objectives that the project will achieve, and describe 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 specific stakeholders within it) and the value that the project intends to deliver to the organization. The proper identification and documentation of these requirements will give the project the right start. Usually, these requirements are manifested before the project is initiated and feed directly into the Project Charter.

At Project Planning, requirements are usually gathered and managed at three different levels. First, the project manager must understand the needs of a specific stakeholder or class of stakeholders, and define how these stakeholders will interact with the solution. These are called “Stakeholder Requirements,” and are derived from the Business Requirements. Then, the project must define the characteristics of a solution (functional and nonfunctional) that meets both the Business and Stakeholder Requirements. These are called “Solution Requirements.” Eventually, when the technical solution is designed, the project 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 “pyramidal” approach (from Business to Stakeholder, Solution and Transition), the project will implement solutions that are linked directly to the business needs.

At Project Executing, the Solution and Transition Requirements get implemented, and the Project Manager should introduce in 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, improve the Risk Management processes and minimize the stakeholders’ resistance (PMI, 2012, p. 404). At Project Monitoring and Controlling, the Project Manager must ensure that the requirements evolve in a controlled environment. This will guarantee that change requests are managed in favor 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. When the project is closed, new needs might arise through the use of the new solution and though these requests are outside the scope of the project, some mechanisms should be implemented in order to catch and manage these requirements. Keep in mind that in order to maximize the business value, all categories of requirements (Business, Stakeholder, Solution, and Transition) should be “linked” by a red-thread: 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 organization will be implemented in a controlled environment. This link should be carefully analyzed and managed in the project.

The purpose of this article is to analyze the project management processes from the requirements management perspective, and show the critical points of the project where the Project Manager should focus attention to ensure a healthy project requirements management effort. At the end of this article, I have also defined a Project Requirements Management Maturity Model, to help project managers understand the level of maturity in addressing and managing the requirements in their project environment and define the steps for improving these processes. The topics of this presentation are addressed by the Business Analysis discipline, which can improve the project results by keeping linked both the project and business environments (Maritato, 2012, p. 1-25).

Business and projects

The motto of PMI^® is “making project management indispensable for business results.^®” This statement highlights the link between project and business value, which must be understood and managed properly by the Project Manager.

Every project begins in response to a Business Need that “describes a problem that the organization wants to (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” (IIBA, 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 span of control, it represents the core reason of the project and must be clearly understood by the Project Manager (PMI, 2012, p. 55). Although this concept sounds quite straightforward, it is not guaranteed in all projects. For example, research conducted by the PMI^® - Northern Italy Chapter (Maritato, 2012, p. 6), shows that seven out of ten PMO‘s do not reach the fifth year, because they are not able to demonstrate value to the business and are therefore terminated.

On the other hand, projects are the means through which organizational 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. Figure 1 describes this concept.

Figure 1 – Business and Projects

In order for a project to produce deliverables that fulfill the requested business benefits, it is indispensable to understand from the very the beginning the requirements for change of the organization. During Planning, these requirements must be detailed, gathered, prioritized and modeled into a set of “implementable” Stakeholder, Solution and Transition Requirements. During Execution and Monitoring and Controlling, the Project Team must “listen” continuously and carefully to the new needs that might arise from the stakeholders and control the evolution. 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 understand the limits and the new opportunities for creating more business value.

All these processes are quite complex, as business stakeholders tend to speak a “business language” rather than a “project language” and they are also accustomed to speaking in terms of “solutions” rather than “needs.” The Project Manager must recognize the need for specific competencies to address all these processes, and must be able to introduce them properly in the project environment. Requirements Management is based on the use of a mix of hard and soft skills and the application of sophisticated tools and techniques that when properly applied allow the project to stay connected with the requirements and evolve in sync with them. We can say that Project Management globally focuses mainly on the implementation of the change, while Requirements Management specifically leads the project towards the creation of business value. I call this dualism the “dynamic duo,” and it is it the engine for “Making project management indispensable for business results.^®”

The Classification of Requirements

To create value for the organization through the project, the Project Manager must understand and manage the needs of the organization and define a solution that fulfill these needs. The schema that should be followed for understanding the needs of an organization and translating them into requirements for implementation include four requirements categories (PMI, 2012, p. 112; IIBA, 2009, pp. 5-6):

1. Business Requirements describe the needs of the organization as a whole (not that of groups or stakeholders within it). This category of requirements defines the value of a solution for the enterprise/organization, the solution that will be implemented by the project. They are usually described during the Initiation process group, though the origin is usually before this stage. As these requirements represent the essence - the raison d'être - of the project, it is strongly suggested to follow a robust methodology to describe these requirements. An example of this is the Best Practice called Enterprise Analysis (IIBA, 2009, p. 81-97). These requirements feed directly into the Project Charter.
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 environment must understand the needs of the stakeholders and define the ones that will be implemented in the project. Stakeholder requirements are derived from the Business Requirements and open the way to the next two requirements categories (Solution and Transition).
3. Solution Requirements can be defined only when the two previous categories are understood. In fact, the project must first understand the business and people needs and only afterward define a solution for them. These requirements describe the characteristics of a solution (functional and non-functional) that meet the Business and Stakeholder requirements. These requirements will drive the selection and the design of the technical solution, as well as the implementation.
4. Transition Requirements are described only when the new solution is designed. The Project Manager must understand the capabilities that the project has to implement in order to facilitate the transition from the current state of the organization to a desired future state. They depend on the “readiness” of the organization to make an effective use of the new solution: in a simplistic way we can say that the “more ready” the organization, the “less Transition Requirements” are requested.

Solution and Transition Requirements describe the solution 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 would like to present an approach for mastering the requirements throughout a project. Many concepts reported here are described by the Business Analysis discipline, and have been reorganized based on my experience as Project Manager and Business Analyst. The approach described below can be applied to all requirements categories (Business, Stakeholder, Solution, Transition) and consists of five stages (see Figure 2).

Figure 2 – The Approach for Mastering the Project Requirements

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

1. Preparing

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

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

This stage is usually performed once during Initiation specifically for the Business Requirements category, and then can be repeated several times during Planning for the other requirements categories.

2. Eliciting

This stage manages the interaction with the stakeholders, in order to “elicit” 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. Elicitation means “to draw forth or bring out - something latent or potential or to call forth or draw out - as information or a response” (IIBA, 2009, p. 53). The main processes that are performed in this stage are the following:

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 a group elicitation process);
2. Executing the elicitation, capturing all that it is said by the stakeholders;
3. During the interaction with the stakeholders several 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 (by asking questions such as, did we understand properly? is there any other information which did not come out?). Anything unclear must be clarified.

This stage is usually performed once during Initiation specifically for the Business Requirements category, and then can be repeated several times during Planning and Executing for the other requirements categories.

3. Analyzing

In this stage the requirements are modeled and specified for the implementation. The main processes that are performed in this stage are the following:

1. Prioritizing requirements - to select which requirements the analysis and implementation effort will focus most. Understanding the solution “Acceptance criteria's”. Prioritization is a very challenging effort, but the effect on the project value is tremendous;
2. Modelling requirements - models are schemas that are used to map the requirements. Models are first defined and the requirements are then mapped into different formats using these models. The purpose of this process is to create a set of views of the requirements that are comprehensive, complete, consistent, and understood from all stakeholder perspectives;
3. Verifying requirements - requirements verification ensures that the modeled requirements meet the necessary standard of quality to allow them to be used effectively for the implementation. It is basically a quality control process that can reduce the amount of rework and change requests 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, or the scope must be enlarged; and
5. Documenting Assumptions and Constraints - a solution will fulfill the requirements under certain Assumptions, and this information must be captured and described as well. During the elicitation stage, the stakeholders can state also some Constraints (business, technical, project, etc.). Assumptions and Constraints must be documented in this stage, though they cannot be called Requirements.

This stage is usually performed once during Initiation specifically for the Business Requirements category, and then can be repeated several times during Planning and Executing and Monitoring and Controlling for the other requirements categories.

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 main processes that are performed in this stage are the following:

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; and
3. The issue generated by this Approval phase need to be documented and tracked for a resolution.

This stage is usually performed once during Initiation specifically for the Business Requirements category, and then can be repeated several times during Planning and Executing and Monitoring and Controlling for the other requirements categories.

5. Managing

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

1. Managing Changes to requirements - in this process are executed the procedure for managing requirements change defined in the Preparation stage. The analysis of impact for the change is performed in an Integrated Change Control environment; and
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.

Figure 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 in general.

Figure 3 – The Requirements Management Stages and Project Management Process Groups

Next, I will describe in more detail how the requirements management approach should be applied in the Project Management Process Groups, 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 at Initiating

At Initiating, the Project Manager should review the output of the process that authorized the project. This process is called “Enterprise Analysis” (IIBA, 2009, p. 81) and describes the requirements management activities necessary to identify the business needs, define a solution that meets those needs, and justify the investment necessary to deliver that solution. Enterprise Analysis follows the processes described in Figure 4.

Figure 4 – Enterprise Analysis

Enterprise Analysis is a set of sequential processes that is usually performed before the project is authorized. 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, maximizing the value of this deliverable. 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 (IIBA, 2009, p. 81). Remember that the focus of these requirements is on the organization as a whole, not the needs of specific stakeholders or groups.

The definition of the Business Need is critical for the project, as it address 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 does the business want this project?), what the business expects from a solution (the “Desired Outcome,” from a business perspective), and the root cause of the problem. The project objectives are identified here, and refined throughout the Enterprise Analysis processes. When the organization has many Business Needs, they should be prioritized.

The Capability Gaps represent the capability the project should add/change in order to address the Business Needs (how must the business change to fulfill the Business Need?). The Project Manager must understand the link between the capability gaps and the Business Needs. Some risks are identified 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, or cost constraints, or benefits considerations.

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 creation of the WBS).

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 called “Benefit Logic.” Figure 5 shows an example of Benefit Logic for a PMO project.

Figure 5 – The Benefit Logic for a PMO Project

The Benefit Logic tool provides high value information for 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 these processes, 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 starts in the proper way.

Mastering the Project Requirements at Planning

It is during Planning that Stakeholder, Solution and Transition Requirements are elicited most. The starting point are the Stakeholder Requirements, which describe the needs of a particular stakeholder or class of stakeholders and how they will interact with a solution. Stakeholder requests are often specific and contrasting to each other, which generates conflicts that must be addressed and managed. 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 directly impacts the project scope).

When Stakeholders Requirements are defined, we can derive from them the characteristics of the solution. 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 nonfunctional) that meet business requirements and stakeholder requirements. Transition Requirements are described when the new solution is designed, and they describe capabilities that the solution must have in order to facilitate the 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 Figure 6).

Figure 6 – Transition Requirements

Stakeholder, Solution and Transition Requirements must be prioritized, and the process of prioritization can follow different and sometimes mixed approaches (IIBA, 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 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. 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. The Project Manager should be aware of these challenges.

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

Figure 7 – Generic Schemas for Stakeholder, Solution and Transition Requirements

Mapping the requirements into a schema will improve the communication process and, indirectly, the level of stakeholder engagement.

Once the requirements are modeled into these schemas, a quality control should be performed. This process is called Requirements Verification. This quality control will reduce the amount of re-work during the implementation phase. The quality control is done for each single requirement (to remove ambiguity, and guarantee the testability, feasibility, correctness, independency, and atomicity of each requirement). Then it is performed 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 or Business Case; requirements that do not get validated are good candidates to be placed out of scope of the project (or the project charter must be expanded).

Requirements which are verified and validated must be communicated and approved before they are implemented. And 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 at Executing

At Executing, the Solution and Transition Requirements get implemented. The Project Manager must create a link between the implementation and the business environments, establishing some feedback mechanisms to keep the project close to the business environment during the implementation. During Executing, some requirements might need clarification, some stakeholders might change their mind, and new requirements might arise. In any case, the Project Manager must ensure that the voice of the business is proactively heard during the project execution and the new requirements are managed. This will minimize the resistance of stakeholders (PMI, 2012, 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 should be heard by the project.

Mastering the Project Requirements at Monitoring and Controlling

By following the principles of requirements management described above 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. This is certainly an important benefit for the project and for the process group.

Furthermore, the requirements’ traceability guarantees that the requested changes will be evaluated against the business requirements (business value). This makes easier to weight cost and benefits of changes and it makes also easier to obtain extra funding for change requests, if the value can be proven to the business.

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 and more straightforward. The stakeholders’ voice is heard and this will increase also their engagement.

Mastering the Project Requirements at Closing

At project Closing, those requirements that are good candidates for long-term usage by the organization must be identified and properly documented for future use. 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. For example, many projects begin without knowledge of what was done before and why some decisions were made. A lot of time is wasted in deriving what was done before, and why and how. This waste of time might be reduced with a consistent process of requirements documentation.

When the project is over, new requirements might come from the stakeholders through the use of the new solution. These requirements, which are generated outside of the project, should also be documented and managed (usually by the operation), and new needs for new projects or new releases might be identified.

The PRM (Project Requirements Management) Maturity Model

A maturity model is usually defined to create awareness on a current practice (as-is) and to understand how to progress from the current state (to-be). The following schema (see Figure 8) is derived from other proprietary maturity models and tailored to the Project Requirements specificity. The intention of this model is not to provide an exhaustive analysis on this complex topic; rather, the goal is to create awareness and solicit feedback from the organizations that are adopting a structured requirements management approach at the organization level.

Figure 8 – The PRM (Project Requirements Management) Maturity Model

1. Level PRM Initial: At this level, the project does not have a requirements management approach. Requirements are elicited continuously throughout the project, usually without a preparation stage. Analysis is done with simple models and without formal prioritization, verification and validation processes. Communication and approval are often obtained in an informal way. A huge effort is spent in Managing the requirements, where most of the Elicitation and Analysis stages are also performed. As a result, requirements are gathered in a chaotic and reactive way, and the project is usually characterized by a high volume of change requests.
2. Level PRM Managed: At this level, the project has a predefined requirements management approach, which is specific for the project, though it is not a common practice across projects in the organization. Usually Requirement Management is performed as part of the Project Management processes. Elicitation is often performed during its fundamental steps and is preceded by a Preparation stage. Analysis make use often of simple models. Prioritization, Verification and Validation are performed within the project, as well as Communication and Approval. Requirements are managed within the project. As a result, the requirements management approach is not replicated on other project initiatives. As this approach is not common culture within the organization, conflict arises and must be tracked and managed.
3. Level PRM Defined: At this level, the organization has defined a requirements management approach across projects. Templates and Procedures are defined across project initiatives, and are adopted and tailored within each single project. The efficiency and effectiveness of the requirements management processes are not measured, and there are no continuous improvement mechanisms in place.
4. Level PRM Measured: At this level, the organization has defined a requirements management approach across projects. Templates and Procedures are defined across project initiatives, and are adopted and tailored within each single project. Metrics for the process and Performance indicators for the organization are defined. Measurements are usually performed by a specific organization placed outside the project environments, which acts as a Center of Excellence for Requirement Management.
5. Level PRM Optimized: At this level, the requirements management approach is defined across projects, measured and continuously improved with robust feedback mechanisms. Requirements management templates, processes and procedures evolve throughout the company's projects.

This classification will help the organization to understand their current status. My intention is to develop a questionnaire (out of the scope of this article) that will help the organization to measure their level of maturity and implement some mechanisms for a continuous advancement in their requirements management processes.

Conclusion

Establishing a proper requirement management process will provide high value to projects. 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 project; and it will increase the maturity of the organization in creating business value through the projects.

The project manager must first understand that requirements are documented and managed at different levels, involving many stakeholders. And the schema, which include Business, Stakeholder, Solution and Transition Requirements, should be followed as best practices.

Mastering the project requirements is considered a complex endeavor, but it isn't. This article 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, to suggest to the Project Manager the most important topics he should focus his attention. 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.

Bringing a professional Requirements Management approach can significantly improve project results and lead projects towards delivering a real business value.

At the end of this article, a PRM (Project Requirements Management) maturity model is also proposed. The intention of this model is not to provide an exhaustive analysis on this complex topic; rather, the goal is to create awareness and solicit feedback from organizations that are adopting a structured requirements management approach at the organization level.