Why a six-month project becomes an eighteen-month one

The project is planned for six months. In month eighteen it is still not finished.

The developer usually takes the blame. But break the delay down week by week and a different picture emerges: the engineering itself barely exceeded its plan.

The time was lost elsewhere.

Where the time goes

1. The scope was never fixed - the largest source

In a project that starts with "we will clarify as we go", a new requirement arrives every week. Each requirement adds about two weeks.

Ten additions means twenty weeks. That is five months, and it appears in no report, because each addition looks small on its own.

2. Waiting for decisions

The team asks a question: "what happens if an order is not approved?" The answer arrives a week later. Work on that part stops in the meantime.

A single project generates dozens of such questions. If each waits three days, that is over a month.

3. Late data

Migration needs the legacy database. Testing needs real data. Integration needs another system's documentation.

Each of these begins with "we will send it tomorrow" and lasts two weeks.

4. Acceptance drags

Work is delivered. The client says "we will review it". Three weeks pass.

During that time the team cannot move to the next stage, because the previous one is unapproved. Sometimes they move to another project, and coming back costs more time again.

5. Technical complexity - the smallest source

An integration proved harder than expected, the data was messy, the equipment documentation was out of date.

This is a real cause and it usually adds two to four weeks. Set against the four above, it is minor.

The arithmetic: how 24 weeks becomes 60

A worked example. Plan: 24 weeks.

24 + 46 = 70 weeks. In practice some delays overlap, so the outcome usually lands between 55 and 65 weeks.

A six-month project becomes a fourteen to sixteen-month one. And nobody set out to work badly.

How to prevent it

Each of the five sources has a specific mechanism.

All five belong in the contract. They are organisational rather than technical mechanisms - and they are what actually holds a deadline.

Who is responsible on the client side

This is the part most often skipped.

The project needs one responsible person on the client side. Their job:

• Answer a question within three working days, or find the answer
• Gather internal decisions and align the departments
• Track the data schedule
• Attend demos and give feedback
• Filter requests that fall outside the agreed scope

The last one matters. If every department sends requests straight to the team, scope grows uncontrolled. All requests should pass through one person.

That person does not need to be technical. What matters is that they can make decisions and have the time.

Warning signs visible in advance

The likelihood of an overrun can be assessed before the project even starts:

Three signs means the project will exceed plan by at least fifty per cent. Five means double.

Why the discovery stage matters

Four of the five sources are closed during discovery.

In two weeks: the process is studied, the scope is written, data sources are identified, a responsible person is named and integration requirements are verified.

After that, both the price and the timeline stop being assumptions and become calculations.

A paid discovery is normal practice. A scope written for free comes out fast and shallow, because it is unpaid work. A paid analysis is detailed, and it belongs to you - you can take it to any team.

What to do when the project has already slipped

Sometimes the overrun has already happened. Three steps help:

1. Separate the causes. Which source produced the delay - scope, decisions, data or technology. Not to assign blame, but to choose the right action.

2. Redefine the scope. Split the remaining work in two: what is needed now and what comes later. Close the first and launch it. The second becomes a separate phase.

3. Establish a weekly rhythm. A short meeting, a specific list, who does what and by when. In stalled projects communication has usually stalled too.

In summary

Projects do not overrun because code is written slowly. They overrun because decisions are made slowly and scope grows unchecked.

Practical steps:

1. Attach the scope to the contract - this closes the largest source
2. Write down the change process and do not action verbal requests
3. Appoint one responsible person on the client side
4. Agree a data schedule at the start of the project
5. Put an acceptance deadline in the contract
6. Start with discovery - it closes four sources at once