Why implementations drag on. Six causes visible during the analysis

When an implementation drags on, the report usually blames technology: the integration turned out harder, the data was in worse shape than anyone thought.

That is almost always a description of the symptom rather than the cause. The real reasons show up much earlier, often by the third analysis meeting, and all six below can be spotted before anyone writes a line of configuration.

Cause 1: the scope covers everything at once

The company decides that since it is implementing anyway, it may as well sort out the lot: invoices, contracts, holidays, complaints and reporting too.

Each of those processes has different owners and different exceptions, so analysing five does not take five times as long as one; it takes considerably longer, because the dependencies between them arrive as well. The result is six months with nothing working and a steadily less patient board.

Cause 2: no decision maker, only consultation with everyone

This is the single most common cause of slippage and the hardest to say to a client's face.

If the answer to “does the manager approve this, or the director” is “we will have to consult on that”, each such answer costs two weeks. Across thirty questions the project stands still for six months, although nobody did anything wrong.

The remedy is simple and unpopular: one person with the authority to decide, who is allowed to be wrong. A wrong decision corrected quickly is cheaper than a perfect decision taken a quarter later.

Cause 3: the process is described as it ought to be

In a workshop people describe the official version, because that is what one does in front of a manager. The system gets built to that description, and then it turns out half the cases actually take a shortcut nobody mentioned.

The diagnostic sign is a process described without a single exception. No such process exists. If somebody claims theirs has none, the exceptions are handled by somebody else who is not in the room.

Cause 4: exceptions discovered after go-live

This follows directly from the previous one. Nobody asked what you do when things do not add up, so the system handles only the ideal case.

The first disputed invoice, the first credit note and the first case being worked by two people at once upend the configuration, and the fixes now land on a live system, which costs several times more than anticipating them would have.

One question worth asking in every workshop: when did you last do this differently from what you have just described, and why?

Cause 5: integration with a system nobody knows

A classic. You have to connect to something an external partner implemented eight years ago, there is no documentation, and the person who ran it left long ago.

Integration is the only part of an implementation that depends on a third party, so it should be tested first rather than last. Establishing in week one whether that system has an API at all, and who has access to it, can save a month.

Cause 6: the software rollout was planned, the people's was not

The schedule contains configuration, testing and launch. It contains no line for “people start using this”, because that is assumed to happen by itself.

It will not. For the first few weeks the new way is slower than the old one, which is normal, but it has to be anticipated and steered through. Without that the project formally finishes on time and actually drags on for months in the form of two parallel workflows.

What to do instead

The prescription is short and amounts to reversing the order: something working first, the rest of the analysis after.

1. One process to start. Ideally the most painful one, because then the benefit is visible and the project acquires defenders on its own.

2. One decision maker. By name, with authority to settle questions and with time set aside for it.

3. A short cycle. Every fortnight something clickable, even if incomplete.

4. A date for switching the old way off. Written into the schedule, not into good intentions.

The test is simple. If a month after the start nobody in the company has seen a working screen, the project is not technically late. It is badly arranged, and the delay is still on its way.