4squareviews

=The first project management process in the Scope Knowledge Area is process 5.1, Collect Requirements.

I have always felt that the title of this process is somewhat misleading, because you have to do more than collect the requirements; you must make sure they all get along well with each other and that there are no conflicts between them.

This post will explain the importance of requirements and how to do more than collect them, but rather how to manage them.

1. Requirements

The PMBOK® Guide definition (somewhat paraphrased) of requirements is the following:

Requirements are the conditions or capabilities of the deliverables of a project. They reflect the needs, wants, and expectations of the sponsor, customers and other stakeholders, and should be quantified and documented.

2. Requirements and Change Requests

The theme of this group of posts on scope management is to help a project manager prevent scope creep. Another way to put this is that it helps a project manager prevent unnecessary changes.

Rita Mulcahy’s PMP Exam prep guide stressed that the first principle of change requests is that they should be avoided whenever possible. The second principle of change requests is that if they do occur, it is best to have them occur as early as possible in the project, because they became increasingly more expensive to implement as the project goes forward.

Let’s go into the first principle a little bit more. Why do change requests occur? If we knew the root causes of change requests, we might have a better chance in avoiding them. There are three reasons: a) requirements were not all uncovered and harmonized during the initiating process, b) the project management plan was not sufficiently detailed, and c) risk analysis was not carried out thoroughly enough. The first of these reasons has to do with requirements, which is what I will concentrate on in this post.

3. Example from auto industry: bumper design

Let me give you an example from the auto industry. A certain car company decides it is going to re-design the bumper so that it is better from a functional point of view AND from a manufacturing point of view. Better functionality specifically means that it performs better on the 5-mph crash test that is mandated by the National Highway Traffic and Safety Administration or NHTSA. Notice how the requirement is quantified, one of the things that PMBOK stresses in its definition.

The requirement from the manufacturing point of view means that it takes the worker on the assembly line less than 5 minutes to secure the bumper on the car as it goes through the line.

Fig. 1 Requirements for bumper design (hypothetical example)

Let’s assume that, according to the engineers, the first two requirements dictate that the bumper should be one solid assembly. It will absorb the shock better and be easier to assemble because there is only one component to the assembly.

However, the engineers say the third requirement dictates AGAINST there being one solid assembly for the following reason: if every time you have a dent to your bumper, you have to replace the entire assembly and not just the portion that is dented, that will cause the repair costs to go up. So if you have a solid assembly, you may not be below the median, but towards the top of the estimates that the Insurance Institute for Highway Safety (IIHS) puts out every year. Higher repair costs means higher insurance rates.

NOTE: Please note that the requirements are all quantified. One crucial question to ask a stakeholder who gives you a requirement is to say: how will we be able to test that the requirement has been satisfied? If they can’t think of a quantifiable “pass” test for the requirement, then the requirement has not been sufficiently thought through.

So now we are in a situation where requirements 1 and 2 together conflict with requirement 3. Now if the project proceeded with only requirements 1 and 2 being known, and requirement 3 was uncovered towards the end of the project, you might have to start the design all over from scratch.

My hope in this post is to illustrate the importance of uncovering all requirements, prioritizing them, harmonizing them, and documenting them..

4. Uncovering Requirements

In order to uncover all the requirements, you need to involve all the stakeholders. This process is amenable to brainstorming techniques where you try to encourage members of the project team to collaborate and think of all possible requirements. To do this, it is not just important to have a process, but an attitude of openness, which John Cleese in his talk on creativity calls the open mode. For details, see my summary of his talk in my May 27, 2012 blog post.

https://4squareviews.com/2012/05/27/john-cleese-on-creativity-part-1/

5. Prioritizing Requirements

For a large project, you may get so many requirements that it may be close to impossible to accommodate them all. In this case, you must prioritize the requirements, with the priority going something like this:

Fig. 2 Priority of Requirements

Those requirements that are specified in the Statement of Work (what was the business need and/or strategic objective of the project) have priority as seen by the smallest, darkest circle. The SOW is the “seed” of the project, often given by a buyer to a supplier in the form of a contract or procurement document such as a Request for Proposal.

Those requirements that are specified in the Project Charter, which is the organization’s scope “blueprint”, if you will, have the next highest priority.

Those requirements that are specified in the Project Scope Statement, the more detailed description of scope developed during the Planning Process, have the next highesr priority.

There are other project constraints, exclusions, etc. which are contained in the Project Scope Statement have the least priority.

6. Harmonizing of Requirements

As in the example of the bumper design, there may be requirements which conflict which each other, and these need to be negotiated with the stakeholders involved. One of the ways of resolving the conflict is to find out which of the requirements is more central to the core of the product scope as expressed in the business case or analysis of the Statement of Work.

7. Documenting Requirements

There is something called a requirement traceability matrix which takes each of the design features of the product and relates it to the requirements or objectives of the project.

This is part of the requirement management plan; another part documents who is responsible for which requirement, for signing off on it at the end of the project when the deliverable is sent to the customer for approval, etc.

The more completely this is done during the project management planning process, the less likely it is to get unpleasant surprises or previously unrecognized requirements popping up during the course of the project.

And that is one important way to prevent your project from having unnecessary changes.

Filed under: Uncategorized |