Insights

Engaged SCM | Operational Excellence Series

Go-live is the easiest milestone in a technology project to celebrate, and the easiest one to misread. The system going live tells you the technology is operational. It tells you nothing about whether the organization is actually going to use it the way it was designed.

Implemented Is Not Adopted

Go-live day looks like success. The system is in production. Data has migrated. The project team gathers for a final review, the sponsor thanks everyone for their work, and the implementation partner moves on to the next client.

Three months later, a different picture emerges. Supervisors on one shift run the new process exactly as designed. Supervisors on another shift have quietly built a workaround because the new steps slow them down during a rush. A warehouse team still keeps a shadow spreadsheet next to the system, just in case. Support tickets taper off, not because problems went away, but because people stopped reporting them and found their own path around the system instead.

These issues do not necessarily mean the software has failed, and the causes are likely intertwined. What they show is that technical implementation alone does not ensure operational adoption. The missing piece is usually operational.

That gap has a name. We call it the Capability Adoption Gap. A system can be fully implemented, and its users fully trained, and still not be adopted. Implemented means the technology is live, users are provisioned, and transactions process correctly. Capable means people can run the process confidently under real conditions, not just complete a training session. Adopted means every shift, on every site, follows the process the way it was designed, consistently, without a supervisor standing over their shoulder to make sure it happens.

Most project closeout reports blur these together. Live gets reported as adopted, and trained gets reported as capable. The distance between what was delivered and what is happening on the floor is where the return on a technology investment actually lives or dies.

Two Versions of Go-Live

Every technology project has a technical go-live and an operational go-live, and they rarely happen on the same day.

The technical go-live is the one everyone plans for. The system is in production. Integrations are firing. Data has been migrated and validated. The help desk is fielding tickets. This is the milestone that shows up on the project timeline, the one that gets celebrated in a town hall.

The operational go-live is different, and far less visible. It happens when floor teams are competent and confident on the new process, not just trained on it. It happens when standard work is documented, followed consistently, and reinforced by frontline leaders. It happens when performance is being tracked against real targets, when deviations get caught and corrected instead of quietly absorbed, and when the organization has a routine for improving the process instead of just running it.

In a well-managed implementation, these two milestones converge quickly. In most organizations, the technical go-live happens on schedule and the operational go-live never fully happens at all. It gets declared. It does not get achieved.

Why the Capability Adoption Gap Forms

The Capability Adoption Gap is not a people problem or a training problem in isolation. It is structural, and it is built into how most technology projects are scoped.

Implementation contracts often define go-live, plus a short warranty period, as the finish line. The internal project team, often the organization's best operational talent pulled temporarily off the floor, returns to their day jobs or gets reassigned once the system is live. Training happened weeks or months earlier, frequently before the configuration was final and before teams could apply it to real, messy, day-to-day work.

Once the project closes, ownership of what happens next is often unclear.  IT owns keeping the system running, not whether people use it correctly. Operations owns hitting today's production numbers, not building new habits across every shift. The vendor is available for support tickets, not for coaching a frontline supervisor through a process that has quietly drifted.

Everyone assumes someone else is watching adoption. In most organizations, nobody is.

The research points the same direction. A 2024 study in the Journal of Business Research analyzed 120 research articles on digital transformation failure published over 28 years. Citing earlier reports, its authors note that more than 80% of digital transformation initiatives end in failure, and that the risk is highest during early adoption and the post-implementation phase, even in well-resourced organizations. They also found that very little research examines what happens after implementation.

The reasons the study catalogs go well beyond the software. Its management category alone includes lack of adequate guidelines, lack of proper training, lack of top management readiness, resistance to change, and ineffective communication. Most of those are unlikely to be fixed by the system alone.  

The Cost of Declaring Victory Too Early

The consequences rarely show up immediately, which is part of what makes them dangerous. They accumulate. Each one also carries a price, and none of those prices appear on the project budget. The table below shows where each consequence reaches the bottom line and how to estimate it using numbers most operations already track.

Here is what that math looks like at a single distribution site. This example is illustrative. Every figure in it is an assumption, not a client result.

Twelve people each spend three hours a week keeping shadow spreadsheets alive. At a loaded labor rate of $38 an hour, that is about $71,000 a year. Forecasts built on inconsistent data lead the site to carry 3% more safety stock on $20 million of inventory. At a 20% annual carrying cost, that adds about $120,000 a year.

That is roughly $191,000 a year, or more than $570,000 over a three-year payback window, before counting a single error, a single expedited shipment, or a single departure.

The same study lists an inability to calculate total cost among the factors behind failed transformations. The cost of the Capability Adoption Gap does not appear on the project budget, which is one reason it rarely gets calculated. It does not appear in a project closeout report either. It shows up a year later, when finance asks why the business case never fully materialized, and nobody in the room can point to exactly where the value went.

What Closes the Gap

Initial improvements are not the same as sustained results. Getting a process working once, in a workshop or during a go-live cutover, is not the same as an organization that keeps working that way six months later without anyone reminding them to.

Closing the Capability Adoption Gap takes four things, and none of them are optional.

1. Standard work has to be built at the floor level, in the language people actually use, not written into a manual that sits in a folder nobody opens.  

2. Frontline leaders need to be equipped to coach their teams through the new process, not just enforce it, because a supervisor who understands why a step exists catches deviation before it becomes habit.  

3. Accountability has to be structural, with performance tracked against real targets and reviewed on a set cadence, not left to informal spot checks.  

4. The organization needs a continuous improvement rhythm that keeps running after the consultants and the implementation partner leave, because the process that was right on day one is rarely still the right process a year in.

Training completion measures attendance. Capability is confirmed by watching people run real work, at real speed, to standard, and by coaching the gaps that show up.

The result is a more capable team. Improvements that continue after the project is complete, driven by people who understand the process well enough to keep making it better.

Go-Live Is the Beginning of the Return, Not the End of the Project

The financial case that justified the technology investment does not get realized on go-live day. It gets realized, or it does not, in the months and years that follow, based entirely on whether the organization did the work to make the new way of working stick.

Technology readiness gets most of the attention before a project starts. Operational readiness after go-live gets almost none, even though it determines whether the investment pays for itself. That imbalance is worth correcting, because the system going live is not the finish line leadership treats it as. It is the starting gun for the work that actually determines whether the investment was worth making.

Where to Start

Go-live is not the moment to walk away. It is the moment the real work begins.

Our Operational Excellence and Frontline Capability work is built for exactly this phase. We help organizations establish standard work at the floor level, build frontline leaders who can coach their teams through it, put accountability structures in place, and create a continuous improvement cadence that keeps delivering value long after the project team has moved on.

A Change and Adoption Lab gives leadership teams a structured half day to pressure-test whether a recent or upcoming go-live has a real adoption plan behind it, and to walk out with a clear path instead of another status update.

If your organization has recently gone live, or is planning to, the better question is not whether the system works. It is whether your operation is ready to actually run on it.

About the Author

Brent Willett is Founding Principal of Engaged SCM Inc., a supply chain advisory firm that helps asset-heavy industrial organizations make better operational and technology decisions, then shows up to deliver them.

Brent is a Chartered Professional Accountant with senior advisory experience at Deloitte and EY. He is the former CEO of Supply Chain Canada (Alberta Institute) and currently serves as a strategic advisor to the Alberta Logistics Centre of Excellence.

Connect with Brent on LinkedIn.

‍