Many project failures are caused by poor requirements gathering techniques. These blunders cause three separate problems for the project and each one can increase the project’s cost and duration and lower the users’ or clients’ satisfaction. Every week stakeholders submit requests for new or modified requirements because
- The project deliverables are not meeting their needs
- The project manager disagrees with stakeholders about whether certain features and functionality are included in the project’s scope of work.
Sometimes these problems are minor annoyances. Other times they’re expensive and hard to correct. Here are the classic errors you should not make when gathering stakeholders’ requirements. Requirements Main Page
Requirements Gathering Blunder #1: Secret Requirements Meetings
Some project managers think that the assembly of project requirements and specifications should be done in secret so there is no interference from users. They believe the requirements gathering process is more efficient when it’s done by technical experts, not the users or the clients. Their reasoning is that the users/clients don’t know anything about the technology at the heart of the project. So why waste time explaining it to them? The PM and technical experts will develop the requirements quickly and efficiently and then explain the results of their work to the users/client. This thinking is often based on war stories of previous battles over requirements and project deliverables with the same users/clients. The attendees at the secret requirements meetings also want to avoid listening and learning about the users/clients’ business requirements. They hope to apply their technical expertise very narrowly and give the users/clients an elegant technical solution.
These secret requirements meetings sometimes get the active support of executives who want to start work quickly and not waste a lot of time on meetings and paperwork. They also don’t want to give the users/clients control of the project by letting them specify the requirements and deliverables.
The consequence of this approach is a great deal of conflict and, most importantly, a lot of wasted time and money. The project team will undoubtedly produce deliverables that don’t meet the users/clients’ needs or lead to improvement in performance. Unfortunately, this is a downward spiral that organizations often repeat.
Requirements Gathering Blunder #2: Requirements are Just Technical Specifications
In the second blunder, the project team experts produce a complex list of requirements and specifications that the user/client is asked to sign off on and approve. For some odd reason, the project manager believes this process will protect them from criticism if the user is unhappy with the project deliverables. In the real world, the conversations go something like this:
Dissatisfied User: “These deliverables are not giving us what we told you we needed! They do not meet the needs of our business. We told you what we wanted and you have not given it to us. This crap is useless!”
Project Manager: “But you signed off on the technical specifications and requirements that we gave you. I have a document right here and that’s what we delivered.”
Dissatisfied user: “We had absolutely no idea what that technical gobbledygook meant. We told you what we needed to improve customer service and you have not given us the tools we need.”
Project manager: “I have the signed document right here.”
Dissatisfied user: “Good. You can show it to my boss when I tell him about all the time and money you’ve wasted turning out garbage.”
The advantage the PM perceives from compiling the list of requirements and technical specifications is that it saves the project manager and team from listening to and understanding the stakeholders business and the business problems they want to solve. Obviously, that is not an advantage. Project managers need to aim the project deliverables at the customer’s business needs, not at a sheet of technical specifications. Unfortunately, project managers often combine blunder #2 with blunder #1. Then the projects resemble the trench warfare of World War I.
Requirements Gathering Blunder #3: Let’s Make Up a Shopping List
This blunder is friendlier and happier, at least initially, than the preceding choices. But the project result is similar. These blundering project managers approach requirements gathering as if they were making up a shopping list. They go around and ask the stakeholders and other people what they want, then add it to the list. Several bad things happen with this approach. First, they tend to miss requirements and find out they’re missing after they have started work. That causes delays. Second, people add things that may be good ideas but aren’t needed to produce the scope. That wastes time and money. Third, people get in the habit of adding things to the project without justification. And that never stops, even after the PM has begun to execute the project plan.
So the PM gets many change requests people expect him to add. They’re disappointed if they are not. The PM must do a good job limiting what is included in the project plan based on a clearly defined scope. Overruns are the result when they don’t. If people think they can add things to the project plan whenever they wish, the project will suffer from scope creep. This means its duration and budget will grow every week. That’s when the stakeholders and other people become unhappy.
Requirements Gathering Best Practice: Prototyping
Another way to gather requirements is by prototyping, which may or may not be a blunder. With this technique, the project team does some requirements gathering, then goes to work, and produces the initial project deliverables. Then the user/client evaluates the prototype and tells the project team about the prototype’s flaws. The team goes back to work to fix those issues. Then they produce another prototype for the user/client to evaluate, and the cycle goes on. Project managers use prototyping with certain types of projects. It’s most often used in software development where the cost of making changes to the prototype is not too expensive. They also use prototyping in manufacturing, depending on the cost of each iteration. Prototyping can take a great deal of both the user/client’s and the project team’s time, depending on the number of iterations. The arguments in support of prototyping are that it encourages continuous contact between the user/client and the project team. Proponents say this produces a higher quality result and a shorter development cycle. On the other hand, prototyping can create a situation where the project team works on the effort forever. That’s because the user’s requirements change every time they look at a prototype. More on Prototyping
Requirements Gathering Best Practices
The right way to handle requirements gathering is to have a crystal-clear scope of the project deliverable and the major deliverables that lead to it. Each of these deliverables is defined with an acceptance criteria so you are not dealing with a vague “to do” list. The entire requirements gathering process should be constrained by these criteria which are objectively measurable. Then the user/client justifies their requirements by showing the PM why they are necessary to produce the specified deliverables. If a stakeholder can’t link a requirement to a deliverable, it’s not included it in the project plan.
Let’s look at an example. This company has lots of complaints about their service. Many are tied to the fact that 20% of the customers have to call back repeatedly to get their problem resolved. So you will start by working with the project sponsor to define the acceptance criteria for improvements in the company’s telephone and web-based customer service process. You come up with acceptance criteria for the scope which is “Fewer than 3% of customers have to contact us a second time about the same problem.”
Next you work with the sponsor & senior stakeholders to detail the high level deliverables that are required to move the company from where it is now to the scope definition. That is, to go from 20% of the customers to fewer than 3% of the customers have to call back a second time about the same problem. Those high-level deliverables are:
- Customer service system provides 18 months of customer transaction and complaint history in less than five seconds
- Customer service cubicles have an average peak noise level of 72 dB
- 95% of the customer service reps can answer the top 30 inquiries in less than 45 seconds
- Customer service hourly staffing creates maximum workloads of 85% of capacity.
The above acceptance criteria give you the tools to constrain the requirements gathering. You link every requirement with one of those major deliverables or the lower level deliverables that support it. You keep track of who requests each deliverable and the performance commitment they made.
You work on requirements gathering at the beginning of your project planning phase. The requirements are necessary for many other project management tasks. You can gather your project requirements very simply or have a much more elaborate requirements process where you track the originator of each requirement and tie it to their performance commitments.
A very common mistake when gathering requirements is to treat the process as simply making a list of everything everybody wants. This tends to keep people happy because they can add anything they wish to the project. However, you will suffer the consequences of stakeholders adding additional requirements every week. This is the classic form of scope creep where you continue to add new features, bells and whistles to the project. This process also substantially increases the project failure rate. That’s because you usually will not get additional time or resources to fulfill those requirements. So the project will be late and over budget.
Requirements Gathering: Step-by-Step
- Immediately after the sponsor approves the scope, you use the information about the identified stakeholders to conduct initial requirements gathering meetings.
- You meet with the stakeholders to discuss their requirements for producing the major deliverables of the project. You are not compiling a wish list. Instead, the discussion focuses on each of the major deliverables and what is required to produce them.
- You put every suggested requirement through a test of whether it is necessary to produce one of the project’s deliverables. If the requirement is a good idea, but not necessary to achieve the project’s scope, it is not included.
- You meet with as many stakeholders as possible with the intent of unearthing all potential requirements. Many of these requirements will not be included in the project plan. However, it is good to identify them during the beginning of the planning process rather than finding out about them late in the project.
- For every requirement that is included in the project plan, you complete the requirements register, which documents the individual who is accountable for the requirement. This documentation maintains traceability back to the originator of every requirement in the plan.
- When you and sponsor have considered all of the requirements and either accepted or rejected them, you and team can proceed to the development of the work breakdown structure.
You can learn how to gather and manage project requirements in our customized, online courses. You work individually with your instructor and have as many phone calls and video conferences as you need. The Project Management Basics course, #101, teaches you a step-by-step process and how to use MS Project® software to make your job easier. We also offer this Basics course for IT, construction, healthcare and consulting project managers.