I’m starting work on a book about change management for project managers – here’s an excerpt.
My favorite executive sponsor used to say, “Success is measured by results – not finishing the project!”
When project results depend on people adopting new behaviors, change management is essential to project success.
As someone who has effectively integrated change management with project management throughout my career, I appreciate how challenging it can be when you first start. In this article, I’ll answer some of the questions I hear from project managers about change management.
When should change management start?
Effective change management starts when your project starts. Change managers attend kick-off. They come to project meetings. They participate in discussions about decisions, risks, upcoming milestones, etc. They are part of your project team.
Change managers own project plan deliverables that move in parallel to your project plan. Your milestones and their milestones are aligned.
Won’t change management lead to scope creep?
It’s not scope creep if it helps you achieve your project’s objective. I’ve watched projects that didn’t include change management hit every milestone then flounder when delivered to end-users.
As one end-user said, “I feel like I came into the middle of a movie that you guys have been watching for months. You expect me to get it and I just don’t.”
Helping end-users not feel like that is one of the goals of change management. Which means you are more likely to get results with your project.
But what can change managers do before we’ve actually built our deliverable?
Their work is similar to yours, but with user adoption in mind.
During the initial phase, change managers work with executive sponsors to describe how the project objective will benefit the organization as a whole, and every stakeholder individually.
Then they’ll design their project approach, the scope of the work, and the milestones. While you’re building your deliverable, they are identifying your deliverable’s impact on people, processes, and systems outside your scope and taking steps to manage that impact.
One of my projects had the objective of increasing revenue by building a system that would enable end-users to reallocate time from an administrative task to a revenue-producing task. The second task itself was outside the scope of the technical project; but the change manager still needed a separate strategy to manage adoption of that new task. This second strategy ensured that, when the new system launched, end users were ready to start doing that second task. Otherwise, they would have clung to the first task and the project would not have met the objective of increasing revenue.
Will I have to extend my project timeline to include change management?
How long change management takes depends on the scope of your project, how much your end-users have to change their behavior, and how change-ready your organization is. One reason I’ve seen project managers perceive change management as adding time to projects, is that they start change management late.
For example, a CEO demanded that the sales team fully use a new tool within six weeks to support a series of revenue targets. The change manager offered help – no time, the executive sponsor said.
Six weeks passed, with 5% success. The CEO thumped his desk and insisted on 100% success by the next target six weeks later.
For that target, “success” dropped to 2.7%. The CEO, apoplectic, demanded full adoption within four weeks.
Then the Executive Sponsor invited the change manager to join the project team and adoption started to increase. Within four months, adoption reached 98%.
The initial decision not to do change management doubled the project length – but all the sponsor saw was that adding change management took four months.
Why do I have to invite change managers to my project team meetings?
Your decisions impact the change manager’s deliverables, especially now that Agile project management causes decisions and deliverables to evolve throughout the project timeline.
Imagine this: the Executive Sponsor decides to deliver a project a month early. (What? Never!) To hit the new timeline, the business owners, executive sponsor, and technical team defer a key component to a second phase.
Several weeks later, the business team finally reviews a change management deliverable (oops – who forgot to tell the change manager that the timeline had changed?) and discovers that, because of the deleted component, work will have be redone and won’t be ready on time.
The business team insists that they won’t go forward without that deliverable.
What does this do to your project timeline?
Will change managers want to weigh in on design decisions?
The change manager’s job is not to “weigh in” on design decisions. However, they do need to understand the decisions and assess the risks to user adoption.
When change managers listen to users, they hear feedback that you will find it helpful to have. They also identify issues and build strategies to address user confusion and push-back – helping users adopt your deliverable and meet your project objective.
Because isn’t that the true measure of your project’s success? If people actually use your project’s deliverable as intended, to reach the project’s results.