Project Requirements: The Key to Stakeholder Management, Scope Control & Change Requests
Managing project requirements builds the foundation for:
- Effective scope and change control
- Strong support from stakeholders and users
- Finishing your project without last-minute requirements surprises.
Stakeholders are the principal focus of managing project requirements. You must continuously try to identify new stakeholders so you can process their requirements and either include or exclude them from the project. That process determines the stakeholders’ enthusiasm and support for the project. You obviously can’t include every requirement that your stakeholders think of. But if you identify your stakeholders early and their requirements that are necessary for the project, you take a big step toward avoiding those very expensive last-minute requirements. You know what I mean; they’re the unidentified requirements that leap out of the bushes late in the project and surprise you. They often delay the completion date and bust the budget. Late arriving requirements can cost up to 100 times what they would have cost if you had discovered them during project initiation. Requirements Gathering Blunders
When you guide your stakeholders through the process of identifying their requirements and quantifying the acceptance criteria for each requirement, you are “training” them for your scope control process. Once you’ve documented the requirements, you guide them through the process of evaluating whether that particular requirement is necessary to deliver the project scope the sponsor wants. If the scope does not need that requirement, it doesn’t get added to the project. While the stakeholder may be disappointed, they have had their opportunity to submit requirements and have participated in the evaluation process. Once you’ve begun to execute the project, new requirements or changes to the project scope will go through the exact same process. So you’re training the stakeholders that you’re not going to add every new requirement they come up with. In many organizations, stakeholders are used to being able to add requirements whenever they wish. The requirement evaluation process is of particular value in those environments. Collecting Requirements
Gathering requirements for your project does not involve making a long list of what everybody wants. Project managers often use that technique because it makes the users and stakeholders happy… in the beginning. The project manager can be like Santa with all the stakeholders coming to sit on Santa’s lap and describe what they want. They will also list expenditures that are good ideas/”nice to haves” or the things they didn’t get in their latest budget. The major flaw of this Santa Claus technique is that it doesn’t limit the requirements to what is necessary to produce the project scope. The unfortunate consequence is that you will be doomed to repeat it every week during the life of the project as people want to add more features and functionality to the project. Prototyping Project Requirements
Project Requirements Gathering Best Practices
The primary purpose of requirements gathering is to identify what you need to deliver the scope of the project. When you start from that perspective, you don’t add requirements that are good ideas or niceties. You’re only interested in adding requirements that are necessary to produce the scope. As a result, the process starts with defining the scope and the major deliverables that will lead to that scope from where you are now. Each of those deliverables, from the scope on down, has its acceptance criteria. It includes the lower-level deliverables that you derived by breaking down the high-level deliverables. The acceptance criteria are metrics that let you and the sponsor objectively measure if you delivered the project scope. An example of an acceptance criterion might be, “Fewer than 3% of the customers are on hold for more than 30 seconds.” That is objectively measurable and everybody will know what they will get from that deliverable. As importantly, they’ll know what they’re not going to get from the deliverable. They’re not going to get 1% of the customers on hold for more than 30 seconds. They will get 3%. This is not to say that these acceptance criteria can’t change. They can and do change during the life of the project. However, when you define your deliverables in the requirements process with objectively measureable acceptance criteria, you don’t have to argue whether a change request is or is not within the original project scope.
When requirements gathering begins, you will start with that overall project scope and 4 to 7 major deliverables that will get you there. Your next step is requirements interviews. You’ll talk to the individuals accountable for producing those high-level deliverables. You’ll find out what they need to produce the deliverable; what their requirements are for producing each one. Rather than asking the accountable individuals what they want, you’ll ask them what is required to produce that deliverable. You’re not going to add any requirement that is not necessary. This will be a very sharp departure from the Santa Claus technique many people are accustomed to. But when you take this focus, you gain two very significant benefits.
First, by breaking down the project into a hierarchy of deliverables and then identifying what you need to produce each of those deliverables, you are less likely to miss requirements. That is not to say it’s impossible. But this requirements gathering based on the scope and deliverables in the project is very effective in identifying everything you need. You avoid those last minute requirements that spring up out of the weeds near the end of the project. Surprise requirements kill the project duration and budget.
Second, when you focus on what is necessary to produce the project deliverables, you are less likely to add unnecessary “requirements” to the project. This will allow you to finish faster and spend less money to deliver the scope the sponsor wants. When you extend this requirements gathering technique to change requests, you make change control easier. When a stakeholder or user comes with something they want to add to the project, you ask why this addition is necessary to produce that stakeholder’s deliverable. This moves the discussion about a change request from a debate over the general value of the addition to a discussion of why it’s necessary to deliver the project scope. That is a more effective basis for discussing additions to the project scope. Project managers almost always lose the discussion about the “value” of the addition. The issue gets escalated over their heads or they have a very unhappy user. When you ask the user to explain why the addition is necessary for delivering the scope, the discussion is much more focused. If the stakeholder or user can’t make a case for why the addition is necessary, you have a reasonable basis for recommending that the sponsor not add it.
Project Requirements Management
Projects often fail because their project managers and sponsors have ignored the advantages of project requirements management. Some people think it sounds like an invitation to endless paperwork and pointless meetings. However, project requirements management helps you finish the project on time and within budget. That makes your stakeholders happy with the project results and with your work. If you are not doing a good job of project requirements management, you will be fighting a losing battle every week to control scope creep. Your projects will finish late and over budget and your stakeholders will not be happy.
Projects that lack project requirements management drown in scope creep. Despite the “Project Santa” adding lots of “goodies” to the project during planning, the users and stakeholders are unhappy because they spend every week arguing with you about things they feel are required. Those arguments end with the stakeholder going to their boss, who then talks to your boss, who then makes a phone call. The sponsor adds the latest “goodies” to the project without giving you an increase in the schedule or budget.
Good requirements management lets you avoid new requirements springing up every week. Instead of fighting all requirements, you should do everything you can to discover them early, during the initiation phase. Your organization probably has information about earlier projects that suffered the consequences of poor requirements management. It’s helpful to have some real-life project disasters to cite. You want the sponsor to understand that when there’s a lot of pressure to start work quickly, requirements gathering is cut short. You want your users and stakeholders to understand how you are going to manage requirements on your project. You need the sponsor, users and stakeholders to invest the time to state their requirements on the front end of the project. These people are probably in the habit of putting off their participation in requirements gathering for as long as they can. That simply ensures you can’t gather all the requirements before you start work. When new requirements arrive late in the project, they cost much more to add than they would have if you had planned for them during initiation.
To manage project requirements correctly, you need to convince the sponsor to allow sufficient time to gather them. Yes, that will mean you start the actual work later. However, when you do start work, everyone will know what is, and what is not, included in the project. That will shorten the overall duration of the project. You need to convince the sponsor that a few days or a week spent gathering requirements on the front-end is worth it because you won’t have the wasted time and money adding requirements every week.
You can learn the techniques for effectively managing your project requirements in our online project management basics course. You’ll work individually with your instructor at your schedule and pace. Take a look at the course in your specialty.
[button link=”http://188.8.131.52/~jwkdwgmy/it-project-basics-111/” style=”info” color=”red” window=”yes”]IT Projects[/button]
[button link=”http://184.108.40.206/~jwkdwgmy/project-management-basics/” size=”medium” style=”info” color=”#1e14a8″ border=”#940940″ window=”yes”]Business[/button]
[button link=”http://220.127.116.11/~jwkdwgmy/construction-project-basics-121/” style=”info” color=”red” window=”yes” bg_color=”00000000″]Construction[/button]
[button link=”http://18.104.22.168/~jwkdwgmy/healthcare-project-basics-131-2/” style=”info” color=”#1e14a8″ window=”yes” bg_color=”00000000″]Healthcare[/button]
[button link=”http://22.214.171.124/~jwkdwgmy/client-project-management/” style=”info” color=”red” window=”yes” bg_color=”00000000″]Client Projects[/button]