Join Doug Rose for an in-depth discussion in this video Learning from the change, part of Project Management Foundations: Change.
Have you ever asked for something and then later regretted it? Have you ever asked for extra spicy Indian food, or downloaded an album after listening to just one song? Did you ever buy a new shirt that looked much better at the store? Everyone at one time or another has wanted to hit undo on a decision. Change requests are the same way. Sometimes a CR just doesn't accomplish what it was supposed to accomplish. Other times a CR accomplishes exactly what it was supposed to accomplish, but the change didn't help or made things worse. This is why assessing the change is an essential part of change management.
It's a time when you step back and look back at the change from front to back. You should put the assessment into the change management log. After the team finishes applying a change, you should ask these 5 questions. The first question that you want to ask is was the change successful? It might seem simple enough, but if the application criteria were unclear, this can be a real sticking point. Imagine you're creating our mobile application. A stakeholder requests a change to the application's icon. They say the icon is fuzzy so you write the acceptance criteria to "have a clear icon when the device "is held at arm's length." You make the change and the stakeholder holds their phone at arm's length and says, "The icon is clear." Is this change complete? This comes down to very clear acceptance criteria.
You might get into trouble with relative tests like arm's length and clear. You need to make sure that you can complete the change. The changes are usually complete when you can answer yes to a very simple question. Does the icon now have 25% more pixels? Did we change all the color blue on the icon to the color black? These are the changes you can easily complete. The second question is how accurate was your Triple R filter? How well did you guess whether the change was relevant, reasonable, or risky? This is the high level impact analysis or Triple R approach we discussed in a previous lesson.
Don't ask these questions again, just record how well you answered the questions the first time. You need to record any inaccurate analysis in the change management log. Maybe you didn't think the change was risky and it turned out to be very risky. It might seem counterintuitive to record your own inaccurate analysis. Remember that you're evaluating the change, and not your ability to predict the future. If it turns out that many changes are riskier than you thought, then you need to think about how you can improve your risk analysis for future projects.
The third question you should ask is one of the most difficult questions to ask in an organization. Was the change a bad idea? Bad ideas are some of the hardest things to glean out of an organization. That's because bad ideas require owners, someone made a mistake, or took a risk that didn't pan out. A lot of organizations see mistakes as a product of mismanagement, or even worse the result of someone who was not following the process. In reality most bad ideas are the opposite. They are a result of too little creative work.
A typical bad idea is an idea that was carelessly mentioned in a meeting, and it was added to the project without much thought. So it's very important to ask this question about your change. Was the change a bad idea? It'll take a lot of courage on your part to identify bad ideas, even more courage to try and get rid of them. So that brings us to our final question. Does the change need to be rolled back? I once worked for an organization that was building a web application. The change request came in because the stakeholders wanted to create an easy way for customers to create a profile.
One of the stakeholders mentioned in a meeting that it would be terrific if a customer could just drag a photograph onto the web application and have it uploaded to the profile automatically. The change required that the applications use Flash. It also limited the application to some versions of web browsers. It was a terrible change, and I should have pushed harder to try and reject the change using the Triple R approach or another change impact analysis. So we hired Flash developers and created a list of all web browsers the application should use. The momentum was definitely to keep the change in place, but I scheduled a meeting with the stakeholder to try and roll back the change.
I told the stakeholder that we were limiting the number of browsers we could use, and the picture upload was adding too much complexity to the application. The stakeholder glanced up from his email and said, "That's it?" And just like that the change was rolled back. Remember as a project manager you're responsible for the success of the project. Sometimes that will take courage to roll back changes that are just not going to work. If you confront a bad change early, you can usually prevent much more uncomfortable questions later on.
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.