Internal software projects rarely collapse in a day. They slide: the delivery date moves a few weeks, the scope grows by a few features, the business owner gets busy with something else, and one day nobody mentions the project again. The six causes below repeat across companies, and all six can be prevented if you spot them early.

1. Nobody has the final say

This is cause number one. When each department understands the process differently, the development team cannot choose for them — so they wait, or worse, build both variants and let users decide at runtime.

Prevention: name one business decision-maker with the authority to say "we do it this way" even when a department disagrees. Write that person's name into the project document; do not let it default to "the board".

2. Scope described as features instead of outcomes

A list of "50 screens" sounds precise but cannot be measured. At acceptance, the two sides will argue about whether a screen is complete, instead of checking whether the work can be done.

Prevention: describe scope in complete business sentences. For example: "accounting can issue a payment request, through two approval levels, and export a payables report by supplier." Acceptance means running exactly that with real data.

3. Real users appear only at the end

If the people who enter the data first see the system at acceptance, you will almost certainly get large, late feedback: a missing mandatory field, too many clicks, a common situation the system cannot handle.

Prevention: let real users touch the product on a short cycle, starting from the first rough screen. Early feedback is much cheaper than correct but late feedback.

4. Exceptions left until last

Every company has exceptions: a special customer allowed to exceed the credit limit, a partially returned order, a contract signed before the project code exists. These usually surface only when testing with real data, and each one can force a structural change.

Prevention: ask directly during analysis — "last month, was there any case handled outside the process?" — and build the most common exceptions first instead of postponing them.

5. Old data treated as a small task

Many plans put data migration in the final week. In reality legacy data is dirtier than expected and reconciliation needs several rounds. While the numbers do not match, a correct system is still unusable, because nobody trusts the figures it shows.

Prevention: start trial migrations as soon as the structure is stable, run them repeatedly, and set explicit matching criteria before go-live.

6. Nobody owns the system after handover

The project ends, the delivery team leaves, and inside the company nobody is responsible for answering daily questions or approving small changes. The system drifts from reality and users quietly return to spreadsheets.

Prevention: choose the system owner before the project starts, involve them throughout, and budget annually for small changes.

Early warning signs

A sliding project is usually quieter than a healthy one. Fewer questions is not good news.

Three signals worth worrying about:

• Progress meetings shift from discussing the business to discussing the delivery date.
• Change requests rise steadily near the end, while the early phase had almost none.
• The business owner misses two working sessions in a row.

A simple way to lower the risk

Break the project into pieces small enough that each one goes into real use within a few weeks. Every release into real use is a test: do people use it, do the numbers match, did the process lose steps? A project made of small pieces already in production rarely fails completely, because the value was delivered early.