Introduction

The previous article discussed the reasons for scope change and how to recognize when changes may be on the horizon. The key question that it did not address is “how”. How does the team manage change? This article revisits scope change by answering the question of how to manage change.

Lola again whirled into the coffee shop. Her briefcase was stuffed with various documents, including one she had received that morning – a request to change the key deliverable of her project. She was supposed to be developing a database application to track existing donors of the agency for which she works. One of her team members suggested that she also track potential donors to the agency.

Her question during this visit to the coffee shop was how to make a project change.

Should You Change?

My first question during this visit to the coffee shop was whether she should make a project change. Including potential donors is a good idea, and would definitely help the agency. However, there are many things that would help the agency, and how do you choose among them? There needs to be more objective criteria for identifying which to pursue.

Before making a change, project managers should ask themselves the following questions:

Does it support the project objective?

• Recall the “why” of the project. Why are you doing the project? Will making the change support that objective?
• Lola is delivering the project to make communications with existing donors more efficient. Including potential donors does not support the “why” of the project.

Does it support the strategic objectives of the organization?

• Even more important than the objectives of the project are the objectives of the agency. The project team should discuss with senior management whether the change will support the organization’s strategic objectives. If it does, they will have to decide whether it is important enough to change the project scope. More importantly, if the requested change does not support the organization’s strategic objectives, the project team should give serious consideration to its importance.
• Lola’s agency developed a three-year strategic plan that included aggressively expanding its donor base. Including potential donors as well as those who have already donated would significantly increase the agency’s ability to meet the goal to increase its donor base.

What is the cost-benefit ratio?

• Cost-benefit ratio is basically a comparison of the cost against the benefit. A good ratio is one in which something that costs little will produce much benefit. A bad ratio is one in which something that costs a lot will produce little benefit. Ask yourself whether the benefit produced by a scope change is worth the cost.
• Lola’s programmer investigated what it would require to add potential donors to the database. He would have to make a few changes to the application, modify a few fields in the database, and add some reports. He estimated that it would total about four days of work. It would benefit the project by creating a database that would support a key aspect of the organization’s strategic plan. Lola decided that there was an excellent cost-benefit ratio.

After thinking about the above questions, Lola decided to make the change and asked about the next steps.

Tips for Making Project Changes

There are three easy steps to change: unfreeze, change, and refreeze.

1. Unfreeze

• Until now, the project has been relatively static. The team and other stakeholders know what the project is about and have been working towards accomplishing it. The project has been “frozen”. Unfreezing the project means getting people ready for the change. Small changes may go relatively unnoticed, but significant changes will require good communication, re-communicating potentially new objectives, and getting people ready for something new.
• Lola’s change was relatively small – just four more days of work. But it also required a shift in project focus. Not only were those who donated to the agency going to be included in the database, but so too were potential donors. Lola “unfroze” the project by meeting with her project team, communicating what the change would be, and identifying why it was important. She did the same with the executive director and other key project stakeholders.

2. Change

• After you have primed the pump to make change possible, it is time to jump in. Identify the impact the change will have. How will it affect the budget? How will it affect the schedule? Does the project charter need to change? Making the change means identifying the impact on all of these and officially telling everyone what that is. It is basically setting the ball in motion.
• Lola identified that the change would require four extra days of development time, and that the project charter would need to be changed to reflect that potential donors would also be included in the database. She made the change to her project plan and also amended the project charter to reflect the increased scope. She then met with the project team again to discuss the new plan with them. She put the change in motion.

3. Refreeze

• The final step is “refreezing” the project documentation. Once the change has been made and the project documentation is updated, everyone needs to have the latest versions to use as their guide. The project team also needs to remind key stakeholders about how the project has changed. It is also wise to revisit the changes at the next project status meeting just to ensure that everyone is following the same plan.
• Lola keeps a shared folder on the server where all the latest documentation is kept. She replaced the old versions with the new ones, and then e-mailed the new ones to the project team. She held a meeting with the executive director to let her know that the change had been initiated and to reiterate the purpose of including potential donors in the database.

Unfreeze, change, and refreeze is a simple methodology for initiating the change in a project. The most difficult, and most important aspect of this process is communication. Ensure that everyone is well aware of the reason for the change and how it will impact their own work.

Summary

If there is one lesson that you take away from this article, it is to fully consider the change before making it. My own experience is that the decision to change is not often well thought out. The decision is often made rather whimsically without considering whether it will benefit the project or without understanding the consequences. Change just for change sake can be detrimental to the project.

This article also gives you a quick and easy methodology for making the change. You may have found it an intuitive approach. That’s good…because it is! The most important part is ensuring that the documentation is updated and that everybody knows about the change. I cannot stress enough the importance of good communication. It can mean the difference between project success and…well…something we would rather not consider.

Good luck! You are well on your way to project management fame!

Blair Witzel (blair@mcdoane.com) is a member of the Project Management Institute and a consultant with McDonnell Doane + Associates, an information management and technology firm focusing on the not-for-profit and public sectors. His work centres on managing multi-project portfolios and working with organizations to develop project management methodologies to more effectively deliver projects.