The KPIs that keep a program honest

Delivery and governance asks whether the program is moving and deciding. The workhorse is the Schedule Performance Index from earned value, earned work divided by planned work, with 0.90 as the line you don't want to cross. Next to it sits milestone hit rate, measured against the baseline dates. Dates you quietly reset last month don't count.

The one I trust most is decision aging. Count the decisions open past 14 days and track the average days to decide. The Standish Group's work on decision latency makes the case that the interval matters more than the elegance of the decision: programs that decide in days beat programs that decide in weeks. An aged-decision list, reviewed oldest first, predicts trouble earlier than any schedule metric I know, because a program that can't decide has already begun to slip. It just hasn't shown up in the plan yet.

Financial asks whether spend is buying real progress. The Cost Performance Index, earned value over actual cost, uses 0.90 as the warning line too. Decades of earned value research on large government programs carry a hard lesson: once a program passes roughly 20% complete, the cumulative CPI rarely recovers. If you're over budget at the one-fifth mark, the honest base case is that you finish over budget, so the intervention has to happen now, while the math is still open.

The number I watch even more closely is burn against accepted deliverables, which is budget spent against work the client has formally accepted, whatever the calendar says. When burn leads acceptance by ten points or more, you're paying for progress nobody has proven. That gap is the financial watermelon.

People and adoption asks whether the organization is actually coming with you. Prosci's benchmarking is blunt about the stakes. Programs with excellent change management run on or ahead of schedule about five times as often as programs with poor change management, and hold budget about one and a half times as often. All of that upside sits in the one workstream that gets raided for budget when things get tight, and Panorama's data shows fewer than a quarter of organizations put an intense focus on change management.

On or ahead of scheduleabout 5×

Holds budgetabout 1.5×

The KPIs here are training completion by role, weighted toward the go-live-critical roles instead of a flattering all-user average, super-user coverage per site, and wave readiness against gate criteria at set intervals before each cutover. Track completion for what it is, though. It measures exposure. Utilization and proficiency after go-live are the numbers that tell you whether the training took.

Data and quality asks whether what you're moving is fit to run a business on. Two field numbers have held across programs I've seen. On a recent conversion, about 10% of the "active" worker records were duplicates or carried termination dates that contradicted payroll history. Call that a spreadsheet problem and you've mislabeled it: it's payroll tax and compliance exposure riding into the new system. On another, 400 "critical" legacy reports collapsed to 90 once we checked them against the actual run logs. Nobody asked for the missing 310 again.

The KPIs are duplicate rate on priority objects, migration rehearsal variance and UAT exit quality. My rule on rehearsals: run at least three full mock loads, and by the final one you want under 2% error overall, with Finance reconciling control totals to the dollar. I treat these thresholds as exit criteria.

SI performance asks whether your integrator is earning the invoice. It's the view that never appears on the vendor's own status slide, which is exactly why it belongs on yours. Be honest about the evidence here. There's no published industry benchmark for first-pass deliverable acceptance, rework rates or consultant turnover on implementations, and no analyst tracks them. Because no one benchmarks it, the client has to instrument it.

Track first-pass acceptance, the share of deliverables accepted without rework. Track change-order velocity, SI-originated changes per month in count and dollars, and watch for the acceleration that means requirements gaps are being monetized. Track key-person turnover against the named roles in the contract. And track billed against accepted, because when billing runs ahead of acceptance, you're financing the SI's optimism.

Where the lines come from: the 0.90 lines on both performance indices and the 20% rule come from decades of earned value research on large government programs. The four SI thresholds come from my field judgment across many programs, since there's no study to take them from. Treat them as a starting position and tighten them to your context.

Everything above measures whether you'll get to go-live in one piece. The day you cut over, the questions change and so do the metrics. Delivery KPIs go quiet. Operational KPIs take their place, and they move by the hour instead of by the week. A program's real health shows up here faster than any status deck can keep up with. I've spent some of the most useful hours of my career in this phase, running a command center for a $25M Workday big-bang across HCM, Finance, Supply Chain and Payroll.

Before go-live you're asking whether you're ready. After go-live you're asking whether it's working, right now, for real people doing real work. The command center answers that on a daily scorecard, triaged several times a day in the first week and daily after that, from one queue with one set of priorities.

Most programs forget to change the instrument. They keep reporting delivery metrics into a period where delivery is over and stabilization is the only question.

Incident volume and aging

The spine of the command center is the ticket picture, pulled from your service management platform, ideally the one you already run the enterprise on. Watch total volume by severity, resolved and open, then the aging buckets that matter most: open past 24 hours, past 72 hours and past 7 days. The 7-day band is the one exit gates watch. Break it down by site and by functional area so a single struggling location or module shows up as a shape before it turns into a surprise. On the big-bang I mentioned, the command center opened first for time and scheduling, then expanded to HR, payroll, finance and supply chain as each went live. The ticket tags by functional area told us where to move people days before anyone raised a hand.

Resolution quality over raw speed

Mean time to resolve is the obvious one, total resolution time over tickets resolved. The one people forget is reopen rate, reopened tickets over resolved tickets. Below 5% is a healthy signal that fixes are sticking. A rising reopen rate during hypercare is worse news than raw volume, because you're closing tickets that reopen and the backlog you think is shrinking is about to come back. Set your severity SLAs tighter for hypercare than for steady state, and time acknowledgment separately from resolution so a fast-triaging command center isn't judged as if every fix were instant.

Adoption, measured for real

At go-live, adoption stops being a training statistic and becomes a login and usage fact: active users, web and mobile, by role and by site, doing real work in the system. Logging in once doesn't count. Prosci is refreshingly honest that there's no universal benchmark for a "good" adoption rate, so be skeptical of anyone who quotes you a magic 95%. What matters is the trend and the outliers. A department far below the others is a change management signal, and it's cheaper to fix in week one than in month three. Watch transaction throughput against the pre-go-live baseline too. If volume is far below normal, users have found a way around the system.

Transaction success, by process

This is where go-live proves itself or doesn't. The metrics translate across every system because they follow the business process.

Procure to pay

The three-way match exception rate, and the touchless or straight-through rate on invoices. The top AP teams run exception rates near 9% against an industry average around 22%, and Ardent Partners puts touchless processing at its top performers at roughly half of all invoices, with the average buyer closer to a quarter. At go-live, watch the clean-match rate trend. A sharp drop below the legacy baseline usually means a match-tolerance or master-data problem, and only rarely a user problem.

Record to report

The first month-end close on the published calendar. Expect it to run long. APQC's benchmarking puts the median monthly close at about 6.4 calendar days, with top performers under 4.8 and laggards past 10, so a first close that overruns is normal. Success shows across the first three closes as a declining pain curve. 012 days under 4.8top performers 6.4median past 10laggards

Order to cash

Order-entry accuracy, invoice generation success and cash-application match rate. Early breakage here hits revenue and customers faster than anywhere else, so it gets watched first.

Payroll

The least forgiving event in the entire program. Two numbers matter. The first is the clean net-pay match rate across the parallel runs, where you want as close to every employee inside tolerance as you can get across at least two consecutive clean cycles. The second is an on-time, accurate first live payroll. A 99% accuracy target across all pay elements is the working standard most teams hold, and any single employee's net pay moving more than about 10% period over period earns a manual review before the run releases. No metric on the program is visible to more people than the first paycheck being right.

Defect leakage and data integrity

Escaped defects, defects found in production over total defects, is the cleanest read on how good your testing actually was. Under 5% leakage is the working target. A spike in high-severity escapes into hypercare tells you the problem sat in UAT scope or test environments, so don't blame your support team for it. Underneath it all, keep reconciling. Post-migration opening balances must equal legacy closing balances, to the penny on financials. Suspense and clearing accounts used during migration have to return to zero, and climbing unposted or suspense transactions are the earliest hard signal of a mapping or interface defect. Watch them daily. By month-end it's too late to do anything but explain.

Exit on conditions

The most important discipline in hypercare is knowing when it ends, and the answer is never a date. Hypercare ends when the operating model can absorb issues through normal support, whether or not the calendar says the 4 weeks are up. Define the exit criteria before you go live and make them measurable:

• Severity-1 volume back to the steady-state baseline
• No release-related incidents older than 7 days
• Several consecutive clean days with no new critical issues
• The first close completed
• The ongoing support team showing it can resolve within SLA on its own, which is the one people skip

Gate the handoff to business as usual on that last proof. Ticket counts alone won't carry it. A compensating control that runs on heroics is deferred failure with a nicer name.