Join Doug Rose for an in-depth discussion in this video Keeping the change from creating more changes, part of Project Management Foundations: Change.
Have you ever gone to the grocery store to just get a bag of nacho chips and soda? You make the trip to the store for just these 2 items. But then when you get home, you realize you've bought chips, salsa, milk, cheese, and cereal. A very similar thing can happen with changes to your project. A change that was added to your project can lead to other changes. Much like the way adding chips to your cart usually leads to salsa. A runaway change is a change the leads to many unexpected changes.
Runaway changes like adding items to your cart. You start thinking there's just 1 change. But then the new change leads to other changes. Which leads to even more changes. The danger of runaway change is that your project will become so large that it blows through its budget, or even worse, never gets delivered. Your project will have a set budget and it won't take long for these changes to overwhelm your cash reserves. There are 3 things you should do to limit these runaway changes. The first is to make sure that you have clear language in your change requests.
You can take the change request back to your stakeholder and rewrite them for clarity. There are some words you should watch out for in your requests. Especially words that lack clarity. Stay away from words like: slow, fuzzy, big, small, ugly, or broken. A good candidate for a runaway change is a request that says something like, "This application is loading slowly." After you make the application a little faster, another request will come in that says, "Still too slow." Then another that says, "Much faster, "but can we speed it up even more?" These types of changes can runaway and have you adding server resources or other un-budgeted additions.
Each change should be written very clearly so you can balance the change against your project's constraints. The second way to prevent runaway change is to divide each change into tasks. Each change should have a set list of things to do. A change request is a pain point for the user. It's like saying, "I keep dropping my phone." A task is a specific fix for the pain point. The task might be, give the user a phone case with a handle or buy pants with bigger pockets.
Let's look at your mobile application project. You might get a change request that says, "I can't start the application on my iPhone." The request is using very clear language but it's not a specific task. You'll want to go back to the user who submitted the request and get more information to create tasks for this request. You might even need to know the version of the iPhone, the application, or the operating system. They you can create a specific task that says, "Investigate bug that causes the application "to crash on iPhone version 10, operating system 11, "software version 12." When working on a change request, you want the developers to have the discipline to create these tasks.
If they just dive into the request you might never have an estimate for how long the change will take. Or when the change will end. The final way to limit runaway changes is to evaluate each change as if there were no other changes. Sometimes projects can be frustrating for customers. They might submit a change request like, "Software doesn't run on my iPhone." Then another request that says, "It also doesn't work on my iPad." It might be tempting to combine these change requests into 1 big change. A request that says something like, "This customer is having trouble "with their iOS devices." If you do that then you are in danger of creating a runaway change.
The estimated task list to get the customer's iPad could be longer than the fix for an iPhone. If you don't view this request independently then you might miss and easy fix, or make an easy fix that much more difficult. Be sure to go back to the customer or stakeholder if a change request comes in that refers to an earlier change. You can certainly use the information to create development tasks for the later change but you need to estimate and understand the change as an independent, new request. Remember that you have to evaluate each change against the scope, budget, and schedule.
So even if the change is closely related, you need to be sure that there's enough time and money left to make the fix. If you watch out for these challenges, you should be able to control your runaway changes. The clearer the change, the more likely you are to avoid them.
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.