It is month eleven, and the status has been green for a while. The steering committee nods along. The sponsor is pleased. Everyone in the room believes the project is healthy, because every report they have seen says so. And the project is already dead. It just has not told anyone yet.
That is the unnerving thing about a failing ERP project. It does not fall over. It keeps scheduling meetings, keeps turning things green, and quietly changes what “done” is going to mean, right up until acceptance, when everyone finds out at once.
The build is almost never wrong. It is faithful. Faithful to requirements that were never quite real.
When you are called in to rescue enough of these, the post-mortems start to rhyme. Nobody was lazy. Nobody skipped a step. The work was done well against a set of requirements that had already gone soft, months earlier, in a room where everyone was too happy to notice. Here is where it actually goes wrong, and where you can still catch it.
The first soft spotA shopping list is not a scope
The requirements sit in a spreadsheet, sorted by module. Financials. Manufacturing. Supply Chain. Maintenance. It looks organised, it looks complete, and it has already lost the plot, because nobody in your business experiences a module. They experience a customer order, and one order walks straight through half of them.
Written as modules
A tidy list of things to switch on. Every hand-off (order to shop floor, shipment to invoice, invoice to ledger) falls into the gap between two workstreams. And the gaps between workstreams are exactly where go-lives come apart.
Written as journeys
Order-to-cash. Procure-to-pay. Plan-to-produce. One person owns each journey the whole way across the modules, so the seam between manufacturing and finance has a name on it before it becomes a defect.
Point at any requirement and ask a simple thing: which journey does this serve, and who owns that journey end to end? If the honest answer is a module name, it is not a requirement yet. It is a wish, filed alphabetically.
The word that dodges“Must have” is a way of not deciding
Standard IFS covers nearly all of what a business needs before anyone touches it. The interesting 10 to 20 percent is the whole game, and it usually gets handled by writing “must have” in a column and moving on. That feels like a decision. It is the opposite of one.
“Must have” is not a decision. It is a way of avoiding one, politely, in writing.
Every gap has two prices, and both belong on the table. What it costs to close: configuration, an extension, a change to how the business works. And what it costs to leave open: a workaround, an hour a week, a quiet risk. The moment a line reads “forty thousand to build, plus a few thousand a year to keep upgrade-safe, versus twenty minutes a week in a spreadsheet,” the argument settles itself. Half the must-haves turn out to be nice-to-haves that nobody wanted to say out loud. The ones you never cost do not vanish; they wait, and come back as change requests at the worst possible moment.
Made concreteEvery gap you close has a future owner
When you decide to close a gap inside the system, you are also deciding who inherits it, because the way you build it today sets who pays at every upgrade for the next ten years. IFS gives you three doors. They look similar in a workshop. They are not the same door.
| How you close the gap | What it really is | Who pays at the next release |
|---|---|---|
| Configuration: a workflow, a rule, a value maintained on a screen | ✅ Standard | Nobody. It comes along for the ride. |
| An upgrade-safe extension: a custom field or logic through the Extensibility Framework | 🟡 Addition | Little, if it stays inside the framework, though it still needs an owner and a note. |
| A modification that reaches into the core | 🔧 Change | Someone re-applies and re-tests it every six months, for as long as it lives. |
None of these is wrong. The mistake is choosing between them by accident, in the build phase, at whichever desk the ticket happened to land on, instead of on purpose, in requirements, with the person who signs the upgrade budget in the room.
The empty chairsThe people who were not in the room
Two chairs tend to sit empty during requirements, and both bills arrive later with interest.
The first belongs to whoever actually owns the data. Migration gets filed as a technical job for the end. But which customers are still real, which parts are dead, what the costing method is per site, what “clean” even means for your item master: a consultant cannot answer any of that. If the master-data steward or the controller first shows up in month five, month five is when they discover a hundred small assumptions were made on their behalf. Some were wrong. You meet those at the first month-end after go-live.
The second belongs to the people who live the process. The fit-gap document is not paperwork; it is the treaty between what the business thinks it is getting and what is actually being built. Left unsigned, it drifts. Every “oh, we also assumed…” is a silent edit, and none of them shrink the scope. Get it signed by the process owners, not by IT. A signature turns a spectator into a co-author; it stops being our build and becomes their solution. Skip the signature and you do not avoid it. You just move it to go-live weekend, where the same conversation is called a critical defect and costs ten times more.
Decide while deciding is still cheap
In requirements, changing your mind costs an email. In build it costs a day, in testing a week, at go-live the whole quarter. Every soft spot above is the same soft spot: a decision quietly postponed to a phase where it is a hundred times more expensive to make.
Back in the steering meeting
Return to month eleven and the green report. The project was not healthy and then suddenly sick. It had been drifting since the workshop where everyone nodded, where a shopping list stood in for a scope, must-have stood in for a decision, and two chairs stayed empty. The report was green because nobody had yet asked the questions that would have turned it amber.
So ask them early, while it is still cheap to hear the answer. For every requirement: which journey does it serve and who owns it; what does closing the gap cost to build and to keep; and has the person who owns the data underneath it actually seen the assumption. Anything that cannot answer all three is not a requirement. It is a change request that has not introduced itself yet.
Catch it in requirements, not in hypercare
We run fixed-price, PRINCE2-governed IFS Cloud projects, and we are called in to rescue the ones that went green a little too long. If your requirements phase cannot survive those three questions, let’s talk before build.
Book a requirements review