The Quiet Work After Approval

Technology programmes often treat approval as a milestone. Funding is secured. Governance has signed off. The architecture is accepted. The change has passed its gates. A launch date exists.

There is a natural sense that something important has been achieved, because it has. But approval only tells us that an organisation has decided a change may happen. It tells us very little about whether that change will survive contact with the organisation itself.

That work comes afterwards.

It is quieter, less visible and often much harder to celebrate. Ownership has to become clear. Support has to work. People need to understand what is changing and why. Controls need to survive real use rather than just design review. Exceptions have to be dealt with. Monitoring has to tell us something useful. Old behaviours have to become less attractive than new ones.

None of this looks as dramatic as a launch.

It is also where adoption is actually constructed.

The difference between introducing something and implementing it

This distinction is older than most of the technology we are currently trying to deploy.

In 1996, Katherine Klein and Joann Sorra described implementation as the process of achieving the appropriate and committed use of an innovation by the people expected to use it. Their point was important: acquiring or approving an innovation is not the same thing as implementing it. Implementation effectiveness depends partly on whether the organisation creates conditions that support its use.[1]

That sounds obvious until we look at how programmes are often measured.

Did we deploy it?

Did we migrate the users?

Did we enable the feature?

Did we complete training?

Did we close the project?

All of those may be legitimate delivery measures. None of them necessarily tells us whether the new capability has become part of ordinary work.

A technology can be technically live while operationally absent.

People may still use the old process. Teams may create workarounds. Support staff may quietly compensate for something that does not fit. Managers may tolerate exceptions because enforcing the new model is inconvenient. The technology exists, but the organisation has not really changed.

This is why adoption cannot simply be another line in a deployment plan.

It is the outcome of everything surrounding the technology.

The real system is larger than the technology

A useful technology programme usually starts with the thing being introduced: a platform, a tool, a process, an automation, perhaps now an AI capability.

But the operating system around it is much larger.

There are users, support teams, service owners, security controls, policies, incentives, dependencies, reporting, suppliers, training, budget, governance and existing ways of working. A change can be perfectly sensible when considered in isolation and still fail because one of those surrounding conditions makes the old behaviour easier.

Research into technology implementation has repeatedly found that context matters.

Amy Edmondson, Richard Bohmer and Gary Pisano studied 16 hospitals adopting the same new cardiac surgery technology. These were not poorly performing organisations. They were respected hospitals with strong clinical outcomes. Yet their ability to implement the technology varied considerably.

The technology itself was not enough.

The successful teams approached implementation differently. They prepared people, created opportunities to learn, experimented with new routines and reflected on what was happening rather than assuming that installation would automatically produce adoption.[2]

The setting is healthcare, and we should be careful about pretending every finding transfers perfectly into enterprise technology. But the mechanism is familiar.

A new tool frequently requires a new routine. And routines are social as much as they are technical. If the operating environment continues rewarding the previous behaviour, the previous behaviour usually survives.

Launch is not the end of implementation

One of the more useful distinctions in implementation research is between introducing something and making it routine.

Greenhalgh and colleagues, in a large systematic review of innovation in service organisations, distinguished between dissemination, implementation and sustainability. Implementation meant actively putting an innovation into use. Sustainability meant something further; the innovation becoming sufficiently embedded that it was part of normal organisational activity.[3]

That distinction matters because programmes often concentrate resources around the point of change.

Before launch, attention is intense. Risks are reviewed. Decisions are escalated. Project teams meet frequently. Communications are prepared. Senior sponsors ask for progress.

Then the launch succeeds.

The programme begins to move on.

Some of the people who understood the change best return to other work. Temporary governance disappears. Hypercare ends. Project funding closes. The organisation is left with the permanent service.

This is exactly when some of the most consequential questions become visible.

Who owns the awkward exceptions?

Who notices when use begins drifting?

Who decides whether a workaround is acceptable?

What happens when the documentation no longer matches reality?

How do new employees learn the new way of working six months after the launch campaign has disappeared?

Who is measuring whether the expected benefit happened at all?

These are not project questions anymore.

They are operating questions.

Benefits do not arrive automatically either

There is another assumption hidden inside many technology programmes: if the capability has been delivered, the benefit should follow.

Sometimes it does.

Often it requires further work.

A 2021 systematic review of benefits management in software development examined 47 relevant empirical studies. It found that organisations commonly identify and structure expected benefits early in a project, but fewer manage those benefits continuously throughout the lifecycle. The review found evidence supporting practices such as actively planning for benefits realisation, evaluating benefits and assigning responsibility for whether they are actually achieved.[4]

That seems important.

We are often very good at attaching expected benefits to a business case because approval requires them.

The organisation needs a reason to spend the money.

Perhaps the technology will save time, reduce risk, improve employee experience, lower operational cost or remove manual work.

Once funding has been approved, however, the benefit can quietly become an assumption.

The technology is delivered, therefore the benefit is considered delivered too.

But technology rarely creates value independently.

A collaboration tool does not create better collaboration because licences were assigned.

An automation does not automatically remove work if teams continue maintaining the old process alongside it.

An AI assistant does not improve productivity simply because it is available.

A new security control does not reduce risk if users consistently find ways around it.

The benefit exists only when behaviour, process and technology combine in a way that produces the intended outcome.

That is why benefits should be treated as hypotheses to be tested, not promises fulfilled by deployment.

Adoption has an operational cost

This is one of the things that gets lost when we talk about transformation.

We tend to emphasise the cost of building the new thing.

We are less precise about the cost of absorbing it.

Someone has to answer questions when people first encounter it. Someone has to maintain the knowledge articles. Someone has to deal with the edge case nobody included in the original design. Someone has to analyse incidents. Someone has to update controls when the product changes. Someone has to challenge the workaround that was supposed to last two weeks and is still there a year later.

There is also a period when the organisation is carrying both the past and the future at the same time.

Old processes have not completely disappeared. New ones are not yet stable. People know different amounts. Documentation is uneven. Exceptions accumulate.

This transition has a cost even when the implementation is successful.

Pretending otherwise simply moves that cost into operations, where it becomes harder to see.

Normalisation Process Theory, developed by Carl May and colleagues, is useful here because it treats implementation as work. New practices become embedded because people collectively make sense of them, engage with them, perform them and continue assessing whether they are working.[5]

That last part matters.

Adoption is not something done to people at launch.

It is something people continuously reproduce through ordinary work.

The quiet work is the work

This changes how I think about operational readiness.

Readiness should not mean that the project has produced the required documents and obtained the necessary signatures.

It should mean that the organisation receiving the change can realistically carry it.

Can support teams diagnose it?

Is ownership clear when something crosses organisational boundaries?

Can we see whether it is working?

Are controls usable under real conditions?

Do people understand when the new process applies and when it does not?

Can operational teams change it safely after the programme disappears?

Do the incentives surrounding the technology reinforce the behaviour we are asking for?

Have we decided what evidence would tell us that adoption is actually happening?

Those questions are harder than asking whether a service is technically ready to go live.

But they are closer to the truth. A system can be stable and still fail to become useful.

It can meet every technical acceptance criterion while creating enough friction that people work around it.

It can launch with excellent communications and quietly disappear from normal behaviour three months later.

This is why I increasingly think that one of the most useful measures of a technology programme comes after the programme itself has stopped being interesting.

What remains when the project attention disappears?

So what?

Perhaps the practical consequence is that we need to move some of our attention away from the moment of approval.

Not less governance before change. Better continuity after it.

If a capability matters enough to fund, it should matter enough to follow into ordinary use.

That means someone should still own the expected outcome after delivery. Adoption should be observable rather than assumed. Exceptions should be treated as information about where the operating model does not fit. Workarounds should be examined before they quietly become the real process. Support demand should tell us something about design quality. And benefits should be measured after people have had enough time to incorporate the change into their work.

This is especially important as organisations adopt technologies that are less deterministic than the systems that came before them.

AI will make the gap between approval and operation even more important.

Approving an AI tool does not tell us how employees will use it. A policy cannot anticipate every interaction. Controls that make sense on paper may create unexpected behaviour in practice. Different teams may discover uses that were never in the business case. Others may refuse to use it at all.

The organisation will learn what the technology actually is only after people begin living with it. Which means operations cannot simply inherit the finished answer.

Operations are part of discovering the answer.

What survives ordinary life

There is nothing wrong with celebrating approval or launch. They are real achievements.

The problem is treating them as evidence that change has happened.

Change becomes real later, when nobody is paying quite as much attention.

When the project team has moved on.

When the launch communications have disappeared.

When a new employee joins and learns the process from the people around them.

When something fails and the support team has to understand it without calling the programme.

When the exception nobody predicted arrives.

When somebody decides whether to follow the new process or take the easier route.

That is when the organisation reveals whether the change has actually taken hold.

Approval permits change. Operations determine whether change becomes real.

The quiet work after approval is not the administrative tail of transformation.

It is where transformation either becomes ordinary or quietly disappears.

Sources and further reading

[1] Klein, K.J. and Sorra, J.S. (1996) “The Challenge of Innovation Implementation,” The Academy of Management review, 21(4), pp. 1055–1080. Available at: https://doi.org/10.5465/amr.1996.9704071863.
Develops a model of implementation effectiveness centred on committed and appropriate use, implementation climate and the fit between the innovation and users' values.

[2] Edmondson, A.C., Bohmer, R.M. and Pisano, G.P. (2001) “Disrupted Routines: Team Learning and New Technology Implementation in Hospitals,” Administrative science quarterly, 46(4), pp. 685–716. Available at: https://doi.org/10.2307/3094828.
A qualitative study of 16 hospitals implementing a new cardiac surgery technology, showing substantial differences in implementation and the role of team learning, preparation, trials and reflection.

[3]GREENHALGH, T. et al. (2004) “Diffusion of Innovations in Service Organizations: Systematic Review and Recommendations,” The Milbank quarterly, 82(4), pp. 581–629. Available at: https://doi.org/10.1111/j.0887-378X.2004.00325.x.
A systematic review distinguishing diffusion, dissemination, implementation and sustainability and examining the organisational conditions affecting how innovations spread and become routine.

[4]Holgeid, K.K. et al. (2021) “Benefits management in software development: A systematic review of empirical studies,” IET software, 15(1), pp. 1–24. Available at: https://doi.org/10.1049/sfw2.12007.
A systematic review examining evidence around benefits-management practices in software development, including continuous benefits management, evaluation and responsibility for benefits realisation.

[5]May, C. and Finch, T. (2009) “Implementing, Embedding, and Integrating Practices: An Outline of Normalization Process Theory,” Sociology (Oxford), 43(3), pp. 535–554. Available at: https://doi.org/10.1177/0038038509103208.
Develops a framework for understanding the work through which practices become embedded and sustained as part of everyday organisational activity.