When system acceptance won't get signed, the problem usually isn't the system

The system is live and the floor is using it, yet the acceptance sign-off keeps slipping.

By the end, the problem usually isn’t the system. It’s three things that should have been settled long before: acceptance criteria that were never set at kickoff, requirements that keep growing, and a business leader who changed.

This post covers three things: how to get from go-live to acceptance, which metrics acceptance looks at, and what to do when nobody will sign.

1. From go-live to acceptance: start small, open up in stages

We go through four steps:

• Cutover: the system officially takes over
• Trial production: pick trial orders, from few to many
• Full switch: once trial production runs smoothly, every order goes through the new system
• Final acceptance

Trial production is the critical stretch. Start with one line or one warehouse, get it running smoothly, then expand; don’t bring every line up at once. Orders go from few to many: when there are few orders, a problem has a small impact and can be traced order by order.

During this period, warehouse, production line, purchasing, planning and the support functions are learning to work together. Which handover is rough, whose documents arrive late: this is when it all shows up. Every issue that surfaces needs an order number, an owner and a deadline, and after it’s fixed someone has to go back and verify it. “It’s fixed” on its own doesn’t count.

There’s no fixed number of weeks for trial production; it depends on the project. The bar isn’t that time is up; it’s that the teams have actually settled in.

2. System acceptance looks at five metrics, with thresholds set at kickoff

We look at these five at acceptance:

• Document and delivery accuracy: are the documents right, and were deliveries wrong or missing
• System availability: the share of time the system is usable, and how much downtime there is
• Outbound efficiency or takt achieved: can outbound keep up with the line
• Issue-list closure rate: of the issues raised since go-live, how many are closed
• Function completion rate: of the functions originally confirmed, how many are done

The two that cause the most arguments are issue-list closure and function completion: which issues count as issues, which functions count as originally confirmed. Different definitions, and the numbers end up far apart.

What matters most isn’t the metrics themselves. It’s that the thresholds for these five go into the acceptance criteria at project kickoff. Negotiate them just before acceptance, and every party counts in the way that suits them: the business points to open issues, the vendor points to delivered functions, and neither convinces the other.

3. What to do when acceptance won’t get signed, and three traps

Our acceptance is signed by three parties: the business department, the key users, and management. As the previous post said, one sentence from a key user outweighs ten from you. Once they agree, the business department signs more easily.

When the business won’t sign, don’t push. Find out why first: functions not finished, the project delayed, or something else. Different causes, different fixes. If functions aren’t finished, list what’s left with completion dates. If it’s a delay, lay out the reason and the new dates.

When acceptance drags on and on, it’s usually one of three traps:

• No acceptance criteria at kickoff: at acceptance everyone measures their own way, and it’s meeting after meeting
• Scope creep: new requirements keep coming in during trial production, the scope keeps growing, and the acceptance line keeps moving back. Log and assess new requirements first; whatever can go into the next phase goes into the next phase
• A new business leader: the new leader sees the original requirements differently, changes have to be raised again, and things already confirmed get renegotiated

The last two traps rest on the first: only when criteria and requirements were written down and signed at kickoff do you have something to stand on when requirements grow or the leader changes.

---

When the business leader changes mid-project, does the new one honor requirements the old one signed?