Insights
We are usually called in at the point where a programme has just turned red, and almost every time the same thing is true: it had been in trouble for months. The signals were there. They were simply not the sort of thing that shows up in a status report.
By Christopher Fagan
Here are the five we see most often, in roughly the order they appear.
A large programme that has never reported amber is not a well run programme. It is a programme where nobody feels able to raise a problem. Real delivery produces genuine difficulties, and healthy governance surfaces them early enough to act. Unbroken green over many months usually means issues are being managed inside the delivery team until they become too large to hide.
Ask when the last amber was and what happened to the person who raised it. The answer tells you a great deal.
Requirements get added, integrations get discovered, a country gets brought forward. If the go live date has not moved in response, either the plan had enormous contingency in it, which is rare, or something has been quietly deferred.
The test is simple. Ask what has been descoped to absorb the additions, and ask to see it written down. If nobody can name what came out, nothing came out, and the date is now fiction.
Data is the single most reliable predictor of ERP outcomes and the most consistently underestimated workstream. The warning sign is not a data problem, it is the absence of one. If nobody has run a full volume trial load, if reconciliation rules are still being written, if the business has not yet rejected a set of migrated records, then the data workstream has not started in any meaningful sense regardless of what the plan says.
Ask how many full dress rehearsals are planned and how many have happened. The answer is often zero and one respectively.
Look at the plan and measure the distance between the end of build and go live. Then ask what happens to that gap when build slips by four weeks, which it will. On most troubled programmes, testing is the shock absorber for every other delay, which means the phase designed to find problems is the phase guaranteed to be shortened.
A programme that protects its test window, in writing, with a named person empowered to defend it, is a programme in reasonable health.
This one is counterintuitive. Serious operational involvement produces friction. Finance disputes the chart of accounts, operations objects to a process, someone escalates about a report they cannot lose. That friction is engagement, and it is what makes adoption possible.
Silence from the business usually means the programme is being run by IT and the systems integrator, and that the people who will have to use the system on day one have not yet looked at it properly. They will look at it during user acceptance testing, and at that point everything they find becomes a change request against a plan with no room in it.
Get an independent read, and get it from someone who reports to the sponsor rather than to the programme. It usually takes two to three weeks. The value is not the report. The value is that a re baselined plan produced now costs a fraction of a failed go live, and it is still early enough for the answer to be a plan change rather than a recovery.
We do this work regularly. See delivery excellence and ERP implementation consulting, or get in touch.
If any of this is live for you right now, the senior people who wrote it are the people you would work with.