Every change needs two plans

In construction and infrastructure projects, nobody starts work without a schedule, a budget and a risk register. When an organisation decides to change how it works, with a new system, a new structure or a new way of managing projects, it does the same: a plan, milestones and a launch date.

That is the first plan: the delivery plan. What we will build or change, when, and at what cost.

In my work in my experiance, I have seen many change projects deliver their first plan exactly on time, and still fail. The system works, the training is done, the final report says "complete", yet people are still working the old way.

The reason is that these projects had no second plan: the people plan.

What does the first plan measure?

The first plan measures what we deliver. Is the system installed? Were the training sessions held? Has the new guide been issued?

Those questions matter, but they are all about outputs. None of them answers the question the project started with: has the way people work actually changed?

A project delivers new tools. Change only happens when people choose to use them.

What goes into a people plan?

A people plan is not another heavy document. It is a short set of questions, answered as seriously as the questions in the schedule:

• Who is affected? Not "all staff", but specific groups, each with something to lose and something to gain.
• What do we need each group to do differently? A clear, observable behaviour, not a slogan.
• Who will lead the change in each team? Usually the line manager, not the project team.
• How will we know the change has happened? Measures of behaviour, not of activity.
• When do we step back support? Only once the new habits have settled, not when the contract ends.

Link the two plans in one schedule

The biggest mistake is keeping the two plans in separate files: the schedule with the PMO, the communication plan with HR. Then the system slips two weeks, and the launch email still goes out on the original date.

Put the people activities in the same schedule: briefings, manager training, adoption checkpoints. Tie them to the project milestones, so that when one moves, the other moves with it.

Measure adoption the way you measure progress

In project controls we always compare planned against actual. We can do the same with change: what share of teams should be working the new way this month, and what share actually are?

The gap between the two is the "adoption variance". If it is negative, the project is behind, even if every line of the schedule is green.

Summary