The twelve months before an ERP program starts decide more about its outcome than the choice of vendor or systems integrator. The work that makes a program run clean is done before the SI arrives: a named sponsor who will spend a day a week on it, a business case whose benefits are owned by the people who will deliver them, data cleanup already underway with named business staff on it, process owners whose day jobs have been covered, and a start date counted back 36 months from the day you must be live. Gartner expects more than 70% of recently implemented ERP programs to fall short of their original business case by 2027. Most of that shortfall is set before the program begins.
The readiness work maps to the warning signs it prevents
A program in trouble shows seven measurable signs about two reporting quarters before the status report changes color, as the seven warning signs sets out. Each sign has a cause that traces back to something that was, or was not, done before the SI arrived. Readiness is not a separate activity. It is the same list, read a year earlier, when fixing it is cheap.
The table below pairs each readiness task with the sign it heads off. The thresholds in the right-hand column are the rules we recommend, not study findings, so scale them to your program.
| Readiness task | What it looks like when done | The warning sign it heads off |
|---|---|---|
| Name a sponsor with real time | One executive, budget authority, one day a week | Steering committee runs short and decides nothing |
| Benefits owned by their deliverers | Each benefit signed by the manager measured on it | Scope slides to a phase 2 and benefits shrink |
| Data cleanup underway | Named business staff, record error counts falling | Mock data loads slip inside nine months of go-live |
| Process owners freed | Half their time backfilled before design starts | Owners stop attending and IT signs in their place |
| Requirements written tight | Outcomes, not a 900-row feature list, custom code capped | Signed designs get reopened after build starts |
| Contract with named key personnel | Replacement approval and data acceptance criteria | SI staff turn over and re-learn the program |
| Assurance budgeted at 1 to 2% | An independent reviewer reporting to the sponsor | Lets you read all seven signs from the records |
A named sponsor who gives the program a day a week
A program needs a sponsor who spends real time on it, not a name on a charter. The rule we recommend is one day a week, every week, from a single executive who controls the budget and can settle a cross-functional dispute without a committee. On a tier 1 program that runs three years, that is a material claim on an executive's calendar, and it should be agreed in writing before the program starts.
The sponsor is what stands between the program and the fifth warning sign, a steering committee that has stopped governing. Consider a $1B distributor whose sponsor is the CFO in title but sends a delegate to two steering meetings in three. The decisions that belong above the program manager, a scope cut, a date move, a contingency draw, get made one level down and reported as a line in a deck. The program does not know it is adrift until a milestone is missed. A sponsor who reads the records weekly catches the same drift in an afternoon.
Pick the sponsor from the side of the business that carries the most risk at go-live. For a manufacturer, that is usually operations, not IT. For a services firm, finance. The sponsor who will feel the pain of a bad cutover is the one who will spend the day a week to prevent it.
Benefits owned by the people who will deliver them
A business case is real only when each benefit has an owner who will be measured on it. A case built by finance and signed by no one who runs a process is a number, not a commitment. Gartner's finding that more than 70% of recently implemented programs miss their business case is, in large part, a finding about ownership. A benefit nobody owns is a benefit nobody delivers.
Suppose a $300M manufacturer builds a $4.5M program on $1.8M a year of benefits: $700,000 from inventory reduction, $600,000 from faster order processing, and $500,000 from closing the books in days rather than weeks. Before the program starts, each figure should carry the name of the manager who will own it, and that manager should have agreed the number is achievable with the new system. If the VP of operations will not sign for the inventory reduction, it is not a benefit. It is a hope, and it is the first thing to fall into a phase 2 with no budget line, which is the sixth warning sign.
Write the ownership into the case at approval. The test is simple. For every benefit, name the person, the baseline measure, and the date the benefit is expected to land. A benefit that fails that test does not belong in the number the board approves.
Data cleanup started a year early and owned by named staff
Data is now the leading cause of ERP schedule overruns. In its 2025 report, Panorama Consulting found that data issues had replaced resource constraints as the top reason programs run late. The work takes months, it falls on your own staff rather than the SI's, and it cannot be compressed, because the last few percent of bad records is the hard part. The only defense is to start it a year before the SI arrives.
Costbench puts data migration and cleansing at 10 to 15% of the program budget, and most of that is labor from the business, not the integrator. Name the owners now, by person, in finance for the ledger and master data, and in operations for items, customers, and asset records.
Consider an $800M distributor with 1.2 million customer and item records moving off an aging system. A year out, a sample shows 18% of item records with missing or duplicated attributes and 9% of customers with no valid tax code. At the rate a two-person team clears records, that is close to twelve months of work. A program that waits for the SI to find these errors in the first mock load has already lost the time, and the second warning sign, a mock load that slips inside nine months of go-live, is the result. Starting early turns a schedule risk into routine cleanup.
Process owners freed before design begins
The business people who will own each process must be in the room when the system that enforces it for the next fifteen years is designed. The rule we recommend is that each process owner has at least half of their time freed during design and again during testing, and that attendance is tracked by name. Below 75% attendance at design and test sessions, the business is not making the decisions, and the seventh warning sign has begun.
The freeing has to happen before design starts, not during it. A process owner whose day job is untouched will lose every scheduling conflict to the day job, and a delegate from IT will sign the design in their place. When testing reaches that process, the real owner sees the design for the first time and reopens it, which is the third warning sign feeding off the seventh.
Take a program with eight named process owners. Backfilling half of each owner's role for a six-month design window might cost a few hundred thousand dollars in contractors or temporary cover. Set that against a rescue, which Deliberate Directions, writing about NetSuite recoveries, puts at 30 to 50% of the original budget. On a $4.5M program that is $1.35M to $2.25M. Backfill is the cheapest insurance on the readiness list.
Requirements written as outcomes, not a 900-row spreadsheet
A 900-row spreadsheet of features is the most common requirements document and one of the least useful. Every serious vendor will answer "yes" or "with configuration" to almost every row, so the exercise sorts no vendor from another and tells the SI nothing about what matters. The better document is short: 100 to 150 outcome statements that say what the business needs to do, with the handful that are genuinely distinctive to your industry or your company flagged as the ones worth custom code.
Tight requirements are what hold custom code down, and custom code is the single largest cost lever a buyer controls. ERP Research finds that holding custom code under 10 to 15% of requirements saves 20 to 40% of implementation cost. A 900-row list invites the reverse, because each row the business insists on becomes a configuration or a customization, and the signed designs that rest on them are the ones reopened after build starts.
Write the requirements as the business would describe its own work. "Recognize revenue on milestone completion for fixed-price contracts" is an outcome a vendor can be measured against. "System shall support configurable revenue recognition rules" is a row every vendor passes. The first sharpens selection and the contract. The second pads both.
Selection and the contract prepared before your bargaining power narrows
Selection and contracting take six to nine months on their own, and the terms you win depend on when you negotiate them. Your bargaining power is highest before you have publicly committed to one vendor and one SI, and it narrows the moment the organization believes the decision is made. Prepare the selection and draft the contract terms you need while more than one option is still live.
Two contract terms do more than any other to prevent the warning signs. Named key personnel with replacement approval stops the fourth sign, SI staff churning through the people who made the program's decisions. Data acceptance criteria, with a stated reconciliation tolerance the controller will sign, stops the second sign by making a clean mock load a contractual condition rather than a status update. Both are far easier to win before signature than to add in a change order.
Timing matters too. In negotiations we have been part of, vendor incentives followed the vendor's quarter-end and year-end, not any customer deadline. The practical sequence is to finish selection and internal approval on your own timeline, then hold the signature for the vendor's quarter-end. The ERP readiness checklist turns the selection and contract steps into a dated list with the term to secure at each one.
Set the start date by the 36-month rule and fund assurance at 1 to 2%
A tier 1 program needs 36 months from the decision to proceed to a stable go-live, counting selection, contracting, design, build, test, and cutover. The published range runs 12 to 36 months, but the short end describes a single site in one country with standard processes. The number that decides your timeline is not the vendor's support date or the go-live you would like. It is the date 36 months before the day you must be live, and for many companies that date has already passed. The support-deadline math works through it vendor by vendor.
Count backward from the firm date, not forward from today. Suppose a regulated utility must be stable by the third quarter of 2030 to file a rate case on a 2030 test year. Thirty-six months back puts the decision in the third quarter of 2027, and a regulated program should add six to twelve months on top. A company that reads the calendar this way builds the bridge, the budget, and the sponsor's time into the plan. A company that reads it forward discovers the gap when it is too late to close without compressing testing, which is where overruns start.
Fund independent assurance at the start gate, not after the first missed milestone. The rule we recommend is 1 to 2% of the program budget set aside for a reviewer who reports to the sponsor rather than to the program. On a $9M program that is $90,000 to $180,000. Below 1%, the review cannot read the records deeply enough to contradict the SI. Above 2%, it competes with the program for money and attention. Budgeted up front, it is the mechanism that lets the sponsor read all seven warning signs from the source records while there is still time to act on them.