Change management

When a service is new or changes, the people who use it, and the staff who work with it, have to change how they do things. Change management is the work of helping them make that shift, so the service is taken up and used, and does not stall because people carry on the old way.

This is the people side of a change. The technical side, getting a change safely into production, is releasing changes. Change management is about making people aware of the change, willing to make it, able to do it, and supported to keep it going.

The Government of Canada treats adoption as what makes or breaks a digital shift, set out in the GC Information Management Strategy.

Diagram: Releasing the change and Change management converge on the people who use it; when both reach them, the change gets used.

Two tracks, one outcome

Releasing a change and managing a change are two different jobs aimed at the same people:

  1. Releasing the change is the technical side: getting the new thing built and running in production.
  2. Change management is the people side: getting the users ready and willing to work the new way.

The two run in parallel.

Both have to reach the same users, or the change does not take:

  • Released, but not managed. The new screen goes live on the Wednesday, but the people who use it were never told, never trained, and carry on with their old workaround. The change exists and no one uses it.
  • Managed, but not released. People are trained and ready for something that never went live, so there is nothing there to use.

The change is only used when both sides reach the same people.

What good looks like

  • There is a change strategy with a clear purpose: what is changing, and why.

  • The people affected are involved early, before the change reaches them.

  • Users and staff know what the change means for them, in concrete terms.

  • Training and support are in place so people can actually use the new way, with practice and help at hand.

  • Adoption is measured, and the change is reinforced until the old way is gone.

  • Someone owns the change, with named roles and a timeline.

The cost of skipping it

A change can be delivered perfectly and still fail, because the people it was built for carry on the old way.

When the people side is skipped, the cost is real:

  • The old way lingers. People keep using the system or process they know, and the change never takes hold.
  • Two systems run at once. The old and the new run in parallel, at double the cost and effort, sometimes for years.
  • The benefits never arrive. The service was funded to deliver an outcome; without adoption, the money is spent and the outcome does not come.
  • Trust erodes. A botched rollout makes the next change harder, because people learned that change means disruption with no payoff.

The Government of Canada treats adoption as what makes or breaks a digital shift, in the GC Information Management Strategy.

A closer look

A change succeeds one person at a time. The widely used ADKAR model names the five stages each person moves through, and a change stalls at whichever one is skipped.

Whose job it is

A change is delivered by several people, and it fails when no one owns the adoption.

  • The change lead or sponsor plans the adoption, communicates it, and drives it through.
  • Managers of the affected teams carry their own people through the change day to day.
  • The service team builds the change and the supports around it: the training, the guidance, the smoother path.
  • The department's change management community is a shared resource the team draws on for templates and lessons learned.
  • The business owner of the application owns the outcome, funds the change work, and backs it visibly so people take it seriously.

Comparison

Two ways to manage a change

Pax

Meet Pax. They planned the people side of the change from the start:

  • set a clear purpose and involved the affected teams while the system was still being shaped
  • showed each team what changed for them, and trained them before go-live
  • measured how many had moved across, and kept support on hand
  • retired the old system on a set date once people were ready

The result: the teams switched, the old way was gone, and the service delivered what it was meant to.

What Change management looks like in each phase

Change management changes shape across the life of a service.

Plan the change early.

Work out who the change affects and what it means for them.

Write a change strategy with a clear purpose and named roles, and involve the affected people while there is still time to shape it.

A change planned in from the start is one people are ready for.

The official instruments behind change management

Everything official this subject brings with it, and where in a service's life each one comes up. The full detail, including who does the work and what the business owner personally does, is in the table on the home page.

  • Service in both official languagesEvery serviceStanding duty

    The duty to offer and deliver the service in English and French, equally and at the same time. For a digital service this covers the interface, the content, notifications, error messages, and the human support behind it. Quality has to be equal, so a translated afterthought does not meet it.

    • DiscoveryCheck
    • AlphaGather
    • BetaFillSubmit
    • GrowthKeep current
    • MaturityKeep current
  • Publishing under the canada.ca brandOnly ifStanding duty

    The rules for anything the public sees: the domain, the global header and footer, the Government of Canada signature and wordmark, the mandatory page templates, the information architecture, and the content style guide. They are mandatory, and they constrain what a service can look like and where it can live.

    • AlphaCheckGather
    • BetaSubmitSign or accept
    • GrowthKeep current
    • MaturityKeep current
    • SunsetClose out

Further reading

For whether people will actually take up a change, stage by stage, Prosci's ADKAR model is the individual-adoption lens. Kotter's 8 Steps for Leading Change is the organisation-level companion: building urgency, a guiding coalition, and short-term wins. For a government, activity-level template, the US GSA M3 Playbook's task on defining a change-management approach sets up the work on a project.

See also

Assumptions this page makes

You are already working to the Government of Canada Digital Standards, design with users, iterate and improve frequently, work in the open, use open standards, address security and privacy, build in accessibility, empower staff, be good data stewards, design ethical services, and collaborate widely, and to the law on privacy, security, official languages, and accessibility. The standards say how the government works in the digital world. The six Government of Canada digital competencies say what every public servant has to be able to do to work that way, and the team page covers them. This guide builds on those.