Change management is the work after go-live

Most projects celebrate on launch day. The system is live, the training sessions are done, and the project team moves on. Three months later, half the team is back on the old spreadsheet, the new tool holds incomplete data, and the business case quietly fails to show up.

The system usually worked. The change did not.

Two well-known models, one shared lesson

There are many frameworks for organizational change. Two of the most widely used are John Kotter's eight-step process, from his 1996 book Leading Change, and Prosci's ADKAR model, which describes change at the level of the individual: Awareness, Desire, Knowledge, Ability and Reinforcement.

They differ in emphasis, but they agree on something projects often forget. Knowing how to use a new system is only one step. People also need to understand why it is changing, want to make the switch, be able to do it under real working conditions, and keep doing it after the project team has gone. Training covers one of those five.

Plan for the people before launch

For each group affected by the change, write down a few things before go-live:

• what they do today, and what they will do differently afterwards,
• what they lose, even if it seems small: a familiar shortcut, a report they relied on, some control over their own work,
• who they trust and listen to, which is often a team lead rather than a project sponsor,
• and how you will know they have changed, in a number you can track.

That last point turns change management from good intentions into something you can manage. For a field team switching to a new app, it might be the share of jobs closed in the app on the same day. For a finance team, the share of invoices processed without the old workaround.

Make the first weeks easy

The weeks right after launch decide whether a change sticks. A few things help more than anything else.

Put support where the work happens. A help desk in another building is less useful than someone sitting with the team for the first week, or a named person on each shift who can answer questions.

Fix the small irritations quickly. A missing field, a slow screen or a confusing label can push people back to the old way within days. A visible list of issues, with owners and dates, shows people they are being heard.

Switch off the old way when the new way is ready. If the old spreadsheet stays available forever, some people will keep using it.

Track adoption every week

Review the adoption numbers weekly with the team leads who own them, for at least the first two or three months. Look at them by team and by site as well as in total. One team struggling usually has a specific reason, and it is often easy to fix once you know.

Count adoption as part of done

The simplest change you can make is in how projects define success. A release is finished when the people using it have changed how they work, and the numbers show it. That is how we define it in our management consulting and customer experience work.

Where to start

For your next launch, pick one adoption number per team and agree who reviews it each week. That alone will tell you more about whether the change worked than the go-live date ever will.