Change Management Plan vs Change Control
Two quite different disciplines share the word change, and the confusion is expensive. One is the machinery for handling alterations to what the project has committed to deliver. The other is the work of getting an organisation to adopt the result. A project can be immaculate at the first and absent at the second, deliver exactly what it promised, and change nothing at all about how anybody works.
The PMBOK® Guide Eighth Edition lists a change management plan among the artefacts a project holds in Section 4, alongside the mechanisms for controlling baselines, and keeping the two apart in your own head is the first practical step.
Two disciplines, one word
Change control governs the project's commitments. A change is raised, its effect on scope, cost, schedule, risk and quality is assessed, somebody with the authority decides, and the baselines are updated. Its purpose is that the project always knows what it has agreed to build and what any alteration cost. It is administrative in the best sense, and its quality shows up as an organisation that can answer what was agreed, by whom, and when.
Organisational change management governs adoption. It covers who has to work differently, what will make that difficult, what support they need, and how anybody will know whether it is happening. Its purpose is that the thing delivered is used as intended by people who have other pressures and a working method that currently functions. It is not administrative at all, and its quality shows up in operational data months after go-live.
What an adoption plan contains that a comms plan does not
Who has to do what differently, by group. Not the organisation in general, but the eleven claims handlers in the fast-track team who will stop doing three things and start doing two others. Change lands on specific people in specific roles, and a plan written at the level of the department cannot say what support anybody needs.
What will make it hard for each group. Losing an informal workaround that made their targets achievable, working slower for six weeks while relearning, a performance measure that still rewards the old behaviour. Most adoption failure is rational: the new way is genuinely harder for that person under their current incentives, and the plan either addresses that or it does not.
How adoption will be seen. A number, from the system or the operation, that distinguishes use from compliance: how many cases went through the new path, how many reverted, how many staff have not logged in since week three. Training attendance and survey responses measure exposure, and exposure is not adoption.
An underwriting rollout that ran on paper
An insurer replaced the tooling its commercial underwriters used to assess and price mid-market risks. The project was well run by any conventional measure. Scope was baselined, changes went through a board with a clear threshold, the final account was within two per cent, and the platform passed acceptance.
The adoption work was a communications plan: announcements, a launch session, a half-day of training for each team, and a feedback inbox. All of it happened and the attendance figures were good.
A year later the floor still ran on paper. Each underwriter kept a ring-bound workbook of rate tables and referral rules, thumbed and annotated, propped open on a stand at the desk, and the new system was used to record the decision after it had been made in the workbook. The reason was neither resistance nor poor training. The new path required four screens where the workbook required one page, the referral rules in the system did not yet cover two classes the team wrote regularly, and the team's own turnaround target had not moved, so the slower path cost them personally every day.
None of that was a project failure in change control terms. All three were adoption issues that a proper plan would have found in discovery: the screen count in a usability session, the missing rules by walking the actual case mix, and the target by asking one question of the team manager about how her people were measured.
What fixed it took four months and was mostly not software. The two missing classes were added, which was a genuine change request and went through the board correctly. The turnaround target was suspended for eight weeks and then reset. Two underwriters who had adopted early were given time to sit with others. Workbook use fell away over a quarter, and the handling data finally started to show the improvement the business case had promised a year earlier.
Where the two meet
Adoption needs discovered late become change requests. Everything the organisational work uncovers about what people actually require arrives as a potential alteration to the project, which is exactly why the discovery should happen early enough for those to be cheap. An adoption plan that starts after build is a generator of expensive change requests.
Sequence the two deliberately. Training delivered before a baseline change has to be redone, and training delivered too long before go-live is forgotten. Where the project's change control keeps moving the design, the adoption work has to be sequenced behind it, and somebody has to hold both calendars in view.
For a PMP® candidate, the thing to carry is that the two disciplines answer different questions, so a scenario where a delivered system is not being used is describing an adoption gap and not a control failure. A response that improves the change process addresses the discipline that was already working. Situations where delivery was faultless and behaviour did not move are a recurring theme in a structured PMP exam preparation course.
One question tests whether adoption is planned at all. Name the measure that will tell you, three months after go-live, whether people are using the new way. If the only available answers are training attendance and a satisfaction survey, the project has a communications plan and is relying on hope for the rest.
Interested in going further?
A project can hold its baselines perfectly and still change nothing about how the work gets done. Omega's PMP® Exam Preparation works through delivery and adoption as two separate obligations on the same project.
Both the change management plan and the control of project baselines appear in the PMBOK® Guide Eighth Edition.
Ad · Amazon affiliate link.
References
A167: Project Charter Explained: Purpose, Content and Common Misunderstandings
A168: Business Case vs Project Charter: What’s the Difference?
A169: Assumption Log vs Risk Register
A170: Decision Log: The Forgotten Project Control
A171: Change Log vs Issue Log
PMP and PMBOK are registered marks of the Project Management Institute, Inc.
