We Commission Systems & Equipment.
We Forget to Commission the Organization.

Here is a failure mode I've been sitting with, because it doesn't fit the story we usually tell about change.

A regulated site needed a better way to operate, monitor, and control its equipment — tighter control over changes, better accessibility, stronger compliance. Leadership identified the need. It was real and it was obvious. For once, there was no debate about whether something had to improve. Everyone, top to floor, agreed that the status quo wasn't good enough.

The project team that picked it up had deployed systems like this before, in larger and more mature facilities. So they didn't just see a box to check — they saw an opportunity to do it properly. End-to-end execution. Operators empowered to capture data at the point of work. Real attributability tying actions to batches and process steps. Tighter monitoring of progress, alarms, and events. The kind of build that doesn't just satisfy the requirement but moves the site forward a generation.

Everyone saw that plan. Everyone signed off on the design. The team ran the textbook process — change control, design, build, test. We had the change champions. We had senior leadership oversight. We were constantly pulling stakeholders in for input. By every measure of how we're taught to manage change, this was done right.

The wall came at implementation.

When it was time to put the system into the GMP environment and through testing, the response from line managers and business owners was, in effect: we don't think the site is ready for this. There's too much else going on. Too many competing initiatives. We'd have to rewrite a stack of SOPs, work instructions, and batch records. We don't have the time. We can't absorb this right now.

All of which, in hindsight, should have been obvious from the beginning. It wasn't.

So the project team is left asking the question that stings the most: did we try to do too much? Should we have stayed small — narrow scope, quick win, low disruption — and skipped the ambition entirely?

Here's what makes it more than a scoping lesson. The same leadership layer that wanted the site to slow down also wants everything digital. No manual interactions. Review by exception. Release by exception. Full integration across systems. And they don't understand why that future isn't already on the roadmap — they feel they've had plenty of time, plenty of steering forums, plenty of chances to weigh in.

Three maps, one site.

What we ended up with were three different maps of the same territory. Where the site actually was. Where senior leadership believed the site was. And where the project team knew the site needed to go — but had no authority to drive the buy-in and participation that getting there required. Three maps, one site, and no shared understanding that they didn't match.

What's left is the hard part. A system that is genuinely well built. It does everything it needs to — accurate tracking, monitoring, and control of the process. And the business owners don't want to turn it on. Too complex. Operators can't handle it. Too many systems to work in. Why didn't we integrate so there's less duplicate entry? All the classic fears, surfacing at the worst possible moment — after the build, not before it.

I keep turning over what could have changed this. How much preparation was actually possible? Was it a communication failure? Was it simply the wrong time? Did the site legitimately not have the resources to take this on? Or is it fear — of the unknown, of a thing not yet understood and therefore not yet trusted?

I want to be honest about my own assumptions. It's possible the team over-read the site's readiness and capability. It's possible we should have prepared the organization far more deliberately, far earlier — not just informed it, but built its capacity to receive what was coming. And it's possible this is just the older, harder truth: sometimes a site isn't ready for the next evolution of its own technology, and no amount of project discipline changes that.

But I'm skeptical of one part of the story.

The part that says the operators can't handle it. I've watched operators run high-speed lines while manually loading and unloading equipment, talking to an OEE system and an MES at the same time, and still keeping their records straight. They manage genuine complexity every day and do it well. So "they'll be overwhelmed" and "they'll make mistakes" don't sit right with me. That reads less like a fact about the workforce and more like a story the organization tells when it isn't ready.

And ready is the word I keep landing on. Not motivated — ready.

Understaffing, unclear direction, low process maturity, no slack to absorb change: those are real, and any one of them can sink a deployment no matter how small or sensible it is. We are very good at commissioning equipment — we'd never energize a line without confirming the utilities, the procedures, the trained people, and the named owner were in place first. We rarely extend that same discipline to the organization that has to run what we build.

What worries me looking forward is the gap this exposes. If a site struggles to absorb straightforward operator interactions with one control system, what happens when we ask it to carry full automation, review by exception, and deeply integrated systems? The ambition at the top and the readiness on the floor are drifting apart, and we keep discovering the distance only at go-live — the most expensive possible moment to learn it.

I don't have this fully resolved, and I'd rather say that than pretend otherwise. But I'm increasingly convinced the answer isn't more communication or more conviction. Readiness isn't a softer word for motivation. It's closer to architecture — something you have to build into the organization deliberately, ahead of need, before anyone can even see why they'll want it.

More on what that looks like in the next piece.