Join Doug Rose for an in-depth discussion in this video Rejecting a change, part of Project Management Foundations: Change.
As a project manager you'll have to work to reject change requests. It may be necessary to reject the change to protect your project. Too many changes can quickly overwhelm your project, and you may never deliver. If you are more of an analyst-style project manager, you'll have the authority to reject changes. If you're a traditional project manager, you'll need to make sure someone else rejects the change. Either way, rejecting a change request is a routine part of project management. Change requests that cause the most instability are usually changes to the requirements.
As a project manager, you'll hear the term scope creep. The difference between scope change and scope creep, is decided by you or a change control board. It's easy to understand how scope creep can happen. The stakeholders usually plan the project months in advance. After work begins, the project deliverables starts to look real. The stakeholders can interact with it like a customer. Just the act of viewing the deliverable is usually enough to spark your stakeholder's creativity.
If your project is an agile project, then you depend on stakeholder creativity, but if your project is based on a project plan, then too much creativity can impact the stability of your overall project. So let's think about our mobile application project. Imagine on Monday morning your stakeholder leaves a voicemail to stop by their office. Over the weekend the stakeholder used another mobile application that had a built-in GPS. This feature allowed them to find a store based on their location. The stakeholder would like you to see how much it would cost to add this feature to the mobile application project.
So you politely nod, talk a little bit about each other's weekends, and then go back to your desk. The project required a lot of up front planning so there's not as much flexibility to have this feature added to the work load. You go through the Triple R analysis and decide that it's not a change you can easily accept. It doesn't seem reasonable, and it's too risky to add to the application. Now you go through deeper analysis to decide whether or not you should reject the change. Let's look at how the change request will affect your overall project plan. How will the change impact the scope, schedule, cost, or quality? Remember that these are the 4 corners of the couch that we talked about in an earlier lesson.
If you accept the change, the other 3 corners will have to absorb the impact of the change. That usually means balancing impact across the other 3 corners. You, or the change control board, looks back at the scope baseline. The ability to route a user based on their location is not even mentioned in the original scope so if you add this feature it would be a significant addition to the scope. You need a larger budget and a lot more time to complete the project. Now there are 2 ways you can reject the change since the change request, or CR, came from a stakeholder you may want to be delicate.
It might not be a good idea to just hand back the CR with a bright, red rejected stamp across the top. Instead, you want to use the yes, but approach. This is where you go back to the stakeholder, show them the change request, and say yes we could do this, but it would increase the budget by 140%. Or, yes we could do this, but it will make our project 6 months late. When you use the yes, but approach try to make sure that the but is appropriately scary. If the change request is scary, sometimes you can get your stakeholder to self-eliminate the request.
If you say that the change will only increase the schedule by 3 months, while it actually increases the schedule by 6 months, then you might get into trouble. You don't want the stakeholder to overrule your rejection based on the assumption it's an extra 3 months. If the project is 3 months late, they'll not remember the original change request. They'll only remember that you could not deliver the project on time. So try to make sure that the but part is a worst-case scenario.
Along the way, learn how to effectively manage your project for change requests and deal with common obstacles. Also see how to find the balance between too much and too little change—either can be threat to your project.
Lynda.com is a PMI Registered Education Provider. This course qualifies for professional development units (PDUs). To view the activity and PDU details for this course, click here.
The PMI Registered Education Provider logo is a registered mark of the Project Management Institute, Inc.
- What are project changes?
- Planning for changes
- Accepting or rejecting a change
- Understanding the risks
- Learning from your changes<br><br>
- The PMI Registered Education Provider logo is a registered mark of the Project Management Institute, Inc.