Outcome three is reported as a success and lived as a failure. It is also the hardest to detect, because the
metrics a project tracks are the ones it passes: dates, budget consumption, tickets closed, licences activated.
None of those move when the work quietly happens somewhere else.
The symptom lookup table
Enter from the left, from something you can observe this week rather than from a cause you would have to already
understand. Each row names the gate that produced it, the cost now against the cost then, and the one thing to
do this week.
The cost column is an order of magnitude, not a measurement. Treat the ratio between the two halves rather than
the figures: in every row the work is the same work, and the only variable is when it is done. Nothing here is
drawn from a published study, because the studies quoted on this question do not separate these rows. The same
refusal, applied to price, is the real cost of an ERP.
The gates, and what passing one means
The published advice names the virtue and omits the procedure. “Insufficient testing” appears
everywhere; what a pilot is, who sits in it, and what counts as a pass appears nowhere. These are the gates the
table refers to, with their pass conditions.
The three documents that must exist before any vendor demo
A transaction-type inventory: every kind of transaction the business processes, with monthly volume and the
person who touches it. A current-state process walk for the five that carry the money, recorded by watching the
work rather than by asking in a meeting. An integration inventory: every system that sends or receives data
today, each with a named owner.
Decision rule. If a demo happens before these exist, it is scripted to the vendor’s happy
path and the requirements list you write afterwards is really the vendor’s feature list. That is the moment
your scope was set by someone else, and it is almost never noticed at the time.
The conference room pilot, as a gate
Pass criteria: named business users, not consultants and not the project lead, run their own end-to-end
scenarios on migrated data rather than vendor sample data. Quote to cash, purchase to pay, and a full month-end
close. Each scenario completes without a consultant touching the keyboard. The scenario list is signed by
process owners before the session.
Failure signature: a pilot where the consultant drives and the business watches is a sales demo with a
project code. It will pass, and it will tell you nothing.
Cutover reconciliation, in order
Master-record counts and mappings, then document counts and totals, then receivables and payables subledger
aging, then inventory quantity and valuation by location, then control accounts, then the trial balance,
then balance sheet and profit and loss, then an operational test.
The trade-off that matters: a trial balance can tie to the penny while warehouse, cost-centre, tax-jurisdiction
or vendor mappings are wrong. Those errors surface at the first close or the first physical count, with weeks of
transactions already sitting on top of them. “The import finished with no errors” is not a
reconciliation. The data migration checklist has the loading
order and the reconciliations that must tie.
The decision-rights register
Before configuration, list the recurring design decisions that will otherwise be made by whoever is in the
room: chart-of-accounts structure, item and customer numbering, who may override a price, what happens to a
backorder, what blocks an invoice from going out, who may reopen a closed period, which fields are mandatory at
order entry. For each one: a single named decider and a due date.
Failure signature: a decision log whose owner column reads “steering committee”. The
consultant will configure the default, and the business will discover it in testing.
Fit, fix, change, or live with it
Every gap found in the pilot goes into one of four columns, and the real cost of each is stated out loud.
| Option | What it costs | What it costs later |
|---|
| Configure | Cheap, inside standard support | Nothing ongoing |
| Customise | Build cost, once | Upgrade debt, a permanent test surface, and one person who understands it |
| Change the process | Training and political cost | Nothing ongoing |
| Live with it | Nothing today | A workaround that reappears later as a spreadsheet |
Decision rule. A customisation whose only justification is that this is how we have always
done it, with no customer-visible or regulatory reason anyone can state out loud, belongs in the
change-the-process column. The test to apply before approving one: name the person who will maintain it through
the next two upgrades, and ask your implementer, in writing, what happens to it when the vendor changes that
module. An answer that cannot be given in writing is the cost you are about to accept without pricing it.
The go or no-go rule, written before anyone wants to use it
Go live only if all four hold. Every pilot scenario passed in the last full test cycle. Opening balances
reconciled twice, on different days, by someone other than the person who loaded them. The people who do the
work each day have each personally completed their own tasks in the test system. You can name who is on the
floor for the first week and for the first close.
Any single no moves the date. Write it early, because by the time the date is in dispute the people arguing
include whoever is being paid by it.
The hypercare exit test, as a condition rather than a date
Hypercare ends when orders ship, invoices go out and the month closes within the normal number of days, for one
complete cycle, without the project team in the room. There is more on the behavioural version of that exit in
the guide on what hypercare should actually cover.
Failure signature: hypercare ended on the thirtieth, and the same three people are still answering
questions in a chat channel in March. The project is over on paper and the support cost has been reclassified as
everyone’s evenings.
The sixty-day shadow-spreadsheet count
Sixty days after go-live, walk the floor and count the spreadsheets, side trackers and paper notes people have
built since. Each one names either a process the system does not support or a report nobody built. This is the
honest adoption measure. Logins and licence counts are not, because people log in to do the one thing they must
and then leave. More than a couple of these, and the pilot did not cover the real work.
§
The mechanism the lists leave out
The published advice assumes a steering committee, a dedicated project manager and a change-management budget.
In a business of twenty to a hundred people none of that exists. The project is worked by the three people who
already know everything, in the hours after their actual jobs.
So do the arithmetic at the start, per department. Name the person who will spend the hours. State the hours a
week. State what comes off their plate to make room. If the answer is that they will fit it in, the project is a
second shift, and a second shift fails in a particular way: not dramatically, but as a slow drift of missed
interim deadlines while the public status stays green, until a busy season turns the drift into a stop. The
drift is usually visible a month or two before anyone names it, which is the only reason it is worth writing
down in advance.
This mechanism is the one we look for first in a small company, and it is the one the published lists do not
carry, because those lists were written for organisations where protecting capacity is somebody’s job. That
is an observation from practice rather than a measured rate, and it is offered as something to check against your
own project: look at the interim deadlines of the last six weeks, not at the status colour.
Who is paid by which answer
Everyone writing on this question sells one of the contracts involved, which is why the incentives never
appear. They are worth holding in mind while you read a gap list.
- Fixed fee rewards configuring to the demo and billing the gaps as change orders. The
cheapest route to the signed scope is the vendor’s standard route.
- Time and materials rewards the discovery nobody scoped. Useful work, open-ended cost.
- A reseller’s margin lives in licences, not in the process work that decides whether
the system is used.
- The consultant holding the keyboard in the pilot conceals an adoption problem until after
go-live, whatever the intention.
None of this makes anyone dishonest. It makes certain conversations unlikely, and those are exactly the
conversations in the table above.
Stopping is sometimes the right answer
A project stopped because discovery showed the processes are not stable enough to encode in software is a good
outcome counted as a failure. So is a date moved because the go or no-go rule was not met. The literature treats
every non-go-live as a defeat, and that pressure is where the real disasters come from: a date defended past the
evidence, a pilot passed on sample data, a reconciliation signed off at the trial balance.
If one of the rows above describes your week, the work is to name the skipped gate and go back through it late,
at the higher price. That is unpleasant and it is still the cheapest option available. The order the gates come
in, and the deliverable each owes the next, is in
the six stages of erpification.
If you have not started yetThe cheapest failure to avoid is the one where the business did not need
this. The readiness check is twenty scored statements, free and with no email
required, and it will tell you when the honest answer is no. If the question is really about your accounting
system, start with outgrown QuickBooks, or outgrown your process.