Essay
A deployment is not a delivered change
Technical readiness is necessary. But consequential technology change succeeds only when the organisation is ready to absorb it.
Some of the most consequential technology changes can look deceptively straightforward on a delivery plan.
The implementation is understood. Testing is complete. The change window is booked. The right people have approved it.
Technically, the change may be ready.
That does not mean the organisation is ready for it.
I have spent a significant part of my career leading teams through changes where getting the technology right was only one part of the job. Infrastructure changes, platform cutovers and other consequential technical work have repeatedly reinforced the same lesson:
A successful deployment is not the same thing as a successfully delivered change.
When the technology is the simple part
On paper, the change looked relatively contained. A vendor was responsible for implementing a new access arrangement within a very limited timeframe. There was a technical solution, a transition to manage and a defined point at which it needed to work.
In practice, the technology was probably the simplest part.
Our internal technology team spent much of its time questioning.
We challenged assumptions, tested readiness and pushed on what would happen when the expected path did not hold. Not because we expected the implementation to fail, but because confidence in a plan is very different from confidence in the organisation's ability to deal with what the plan has missed.
Around the technology sat a wide range of stakeholders with very different responsibilities.
Physical security had its requirements. Facilities had theirs. Organisational leaders were concerned with continuity and risk. Staff ultimately needed something much simpler: to arrive at work and reliably get through the door.
None of those perspectives was inherently wrong.
But they were not all asking the same question.
The delivery challenge was not choosing which stakeholder was right. It was getting those needs into the same decision.
And there was very little time to do it.
We had to establish what genuinely had to be true before proceeding, where exceptions could emerge, how people would be supported through the transition and which problems could be managed without losing confidence in the change.
Communication was part of that work, not something added at the end. Different groups needed different information at different points while still working from the same underlying understanding of what was changing, why it was changing and what would happen if things did not go as expected.
The implementation date was constrained.
That did not make the organisational complexity disappear.
It made judgement more important.
Where governance earns its place
That experience reinforced what I now expect from change governance.
Its purpose is not to move a change through an approval process.
Its purpose is to improve the decision to proceed.
Significant technical changes usually arrive with plenty of evidence of technical readiness: test results, implementation plans, recovery procedures, change records and vendor assurance.
All of that matters.
But it can also create a false sense that readiness is contained within the implementation plan.
Often the most consequential risks sit between the teams: an assumption nobody realised was an assumption, an exception that falls between responsibilities, a stakeholder consequence that appears minor from one perspective and significant from another.
That is where a CAB, steering committee or other governance point should add value.
Not by asking whether the paperwork is complete, but by creating enough useful challenge to determine whether proceeding remains the right decision.
The question is not simply, are we ready to implement?
It is, given what we now know, are we ready to move the organisation into this new state?
Those are different tests.
Delivery has an outcome
The building-access change also had a very clear measure of success.
It was not that the vendor completed the implementation.
It was not that the technology activated successfully.
It was that people could arrive afterwards and use the building safely and reliably.
That sounds obvious, yet technology delivery can easily become dominated by milestones that are simple to record: deployed, migrated, enabled, cut over, closed.
Those are implementation milestones.
They are not necessarily evidence of delivery.
The same distinction applies whether the change involves infrastructure, an enterprise platform, a digital service or something much smaller.
Deployment tells us that the technical activity has finished.
Delivery asks whether the organisation reached the state we intended.
That requires us to look beyond whether the implementation worked. Did people experience what we expected? Do operational teams understand the new state? Are support signals behaving normally? Has anything unexpected appeared around the technology? Is ownership of what happens next clear?
Three years after that access change, it remains one of the standards I apply to consequential technology delivery.
Not whether we completed the plan.
Not whether the change passed its approval gate.
Not even whether the deployment succeeded.
Whether we carried the organisation safely from one state to another.