One of the key phases on every project is requirements gathering from the users. If the project manager does a bad job gathering the users’ requirements, they’ll get change requests every week for features or deliverables. The users will say things like, “I found some more things that were “missing” from your project plan. If you don’t add them to your plan I will go to my boss.”
These changes add time and costs, make the users unhappy and damage the PM’s credibility. Making changes to a project plan is not a problem. But it is a problem if the necessary changes to the budget and finish date aren’t approved by the project sponsor. The way to avoid this problem is by using good requirements gathering techniques during the project planning phase. Then the user’s change request will be expressed like this, “I want to add to the requirements I gave you during planning. Tell me what the impact is on cost and the completion date.” Good project managers receive this type of change requests. And they are able to handle them so the user is pleased and, as importantly, the sponsor increases the project’s approved budget and duration. Requirements Gathering Best Practices
Requirements Gathering Examples
Here is the key difference between the two approaches. In the first situation above, the requirements belong to the project manger. In the second situation, the requirements belong to the user. Let’s look at a simple example to understand what creates that difference.
The goal of the project is to “Reduce Error Rates.” An unskilled project manger would meet with the users and ask what they need to reduce error rates. Then that PM would create a long list of things the users want. The users view the requirements as belonging to the project manager. So they feel free to add to the list each week. It’s like each of the users sat on Santa’s lap and gave him their Christmas wish list.
On the other hand, a skilled project manager would first get the sponsor to define the project scope. It must be stated in measurable terms like, “The error rate on customer orders is less than 1.5%.” Then the PM and the sponsor would break the project scope down into major deliverables. These major deliverables are the responsibility of each of the user managers. An example could be that one of the user managers is accountable for reducing errors in their department from 3% to 1%.
The project manager would meet with each user manager and ask, “What do you need to reduce your departmental error rate to 1.5%?” One manager might list new systems. Another might need more people. And another might list modifications to the training classes. The project manager would record each manager’s requirements and link them to the project goal of “The error rate on customer orders is less than 1.5%.” In this process, each of the user managers “owns” the requirements they gave to the project manager. Requirements Gathering by Prototype