What Makes a Software Project Fail in the First Year

The launch is not the finish line

There is a particular kind of disappointment that software teams talk about with some reluctance. The build went fine. Nobody was cruel, the money arrived on time, and the go-live was calm. Then the following year went wrong. Feature requests piled up and nothing felt finished. The original team had moved on. The system was in use by a fraction of the people it was built for, and nobody could say precisely what it was doing.

Nothing dramatic happened. That is what makes this failure mode hard to name. It arrives as a slow loss of usefulness rather than a collapse, and by the time it is obvious, the sunk cost is too large to walk away from and too small to justify another rewrite.

The causes are consistent enough to describe. In order of how often we see them.

Nobody owns any of it

The most common single cause is an absence of a person whose job is to be accountable for the system succeeding. The sponsor signs off the budget, the project manager owns the schedule, the developers own the code, and the operations team owns the uptime. The outcome belongs to nobody.

You can see this in what happens six months after launch. Requests arrive and are prioritised by whoever is most senior in the room, which tends to favour the loudest internal interest rather than the largest commercial benefit. Two teams need the same data differently and neither can be told no, because there is no mechanism for deciding and no single person with authority to decide. Everything is agreed, nothing is prioritised.

This is a governance failure and it is nearly impossible to fix technically. A project without an accountable owner will drift, and the drift is usually towards more features rather than towards more usefulness, because features are visible and usefulness is not.

The system solves a problem people had, not the one they have

Requirements collected before launch tend to describe a process as it runs on an organisation chart. Within a year that process has changed, and the software has not. Every workaround becomes permanent. Staff build spreadsheets alongside the system because it cannot produce the one thing their manager needs. Two sources of truth exist for the same data, and nobody agrees which is authoritative.

The expensive part is that these workarounds usually hold real business logic in them. When someone eventually leaves, the institution loses the answer, and the only record was a spreadsheet on a laptop. This is how systems acquire the kind of dependency that makes a rebuild frightening rather than merely worthwhile.

You can reduce the damage by insisting on a review of the actual process at a fixed point after go-live, with the people doing the work rather than the people who approved the scope. What they tell you will not match the specification, and that gap is the real requirements document.

Nobody ever used most of it

Large internal systems are built for an organisation, not for the people in it. Permission models and workflow rules are designed to accommodate every possible user, and the result is a product where the common case requires eleven clicks and the edge case was anticipated.

Adoption is usually treated as a training problem. It is not. If the majority of your users need the system twice a month, the interface will not save it, because the cost of a task is paid every time it is performed. Frequently used workflows have to be short or the system will be circumvented, and this is a design constraint that needs to be identified during the build rather than discovered afterwards.

There is a worse version of this: the system is used constantly by a few people and avoided by everybody else, because the few are the ones who were consulted. When that happens, the data becomes incomplete, and incomplete data makes the reports less useful for everyone, including the committed users.

The technical debt was never on anyone’s list

Deliberate shortcuts are a reasonable commercial decision when they are visible. The version that is dangerous is the shortcut nobody recorded. Spare a day rather than build an import routine. Use an admin panel instead of a script. Copy a query into a report because the tool could not do it properly.

Each of those took less than an hour. Six months later, the report runs on a hand-written query that nobody fully understands, in a database schema that exists because of an export nobody has run since. It works, so nobody touches it, and eventually it breaks in a way that requires reconstructing the assumptions from memory.

Deferral is the real source of debt. Deliberate debt is a decision somebody can explain. Deferred debt is a pile of small decisions made under deadline pressure, and it is only visible if someone is paid to look for it. Our infrastructure and delivery consulting work includes this kind of assessment because the alternative is usually a rebuild triggered by an outage rather than by a decision.

The knowledge left with the people who built it

This is the failure that ends careers and contracts. If one person understands how the billing job works, or how the customer records get reconciled nightly, or why the retry logic has a hard-coded delay in it, then that person cannot take a holiday, cannot leave, and cannot be replaced cheaply.

Documentation written after launch is usually thin. The knowledge that matters is not in the code, it is in the set of decisions that were made and the reasons. Why this table is denormalised. Why this validation is deliberately skipped for legacy imports. What the correct order of operations is when a payment fails halfway through.

The test is whether a competent developer who did not build the system could make a change safely, without asking anyone. Most systems cannot pass that test in the first year, and it is almost never tested. We have made documenting decisions rather than just code a standard expectation on our custom development engagements, because it is cheap while the people are available and impossible to reconstruct afterwards.

Support lapsed quietly

Many systems have a fixed price for the first period of support after launch and nothing after. The end of that period arrives without ceremony. Nobody receives a reminder, because the reminder is the supplier’s job and the supplier has done theirs.

It is a strange arrangement that everyone involved understands and nobody challenges. The client is usually pleased that the initial cost was lower than expected, and quietly resentful nine months later when the same small fix comes with an invoice attached.

After that point, every future change is priced as new work, usually at a higher rate, usually by somebody new. Small fixes get deferred because they are not urgent, which means the system keeps running on workarounds. Within another year the codebase contains modifications nobody would have signed off on and the original design decisions have been obscured.

The remedy is dull and works: agree the support arrangement and its cost before launch, so that nobody has to make a purchase decision about keeping something working. See what a maintenance arrangement should contain in our support and maintenance service.

Nobody looked at what the data was doing

Internal systems accumulate records. Nobody checks whether the nightly job actually completed. Nobody notices that a table has grown from forty thousand rows to four million and that queries have started timing out. Nobody compares the number of orders in the system to the number in the finance ledger.

Data problems are silent by nature. A page that errors tells you immediately. A database that is quietly wrong tells you in next year’s audit, or never. The cheapest protection is boring: scheduled checks on volume, failed jobs and reconciliation totals, with somebody who is required to read the results.

This is the same discipline as monitoring and backup applied to the data rather than the server, and it catches the class of failure that server monitoring cannot see at all. SmartEdge IT Solutions builds these checks in during the build because they are trivial to add while the data flow is understood and awkward to retrofit once it is not.

What actually prevents this

None of these failures need more engineering effort to avoid. They need a few decisions made in advance and a few things written down.

• Name one person accountable for outcomes, with time and budget for it, and make it part of their job rather than an addition to it.
• Book a process review at ninety days after launch with the actual users, and treat the differences from the specification as requirements.
• Decide, before launch, which workflows are the common case, and insist they are short.
• Ask for the shortcuts to be listed. A supplier who will produce that list is supplying something you can plan for.
• Get the decisions documented while the people who made them are available.
• Agree what happens to support and what it costs, before the free period ends.
• Set up data checks from week one, not after the first incident.

Every one of these is cheaper than the failure. The reason they are skipped is that they all cost attention in the first month of a project, when attention is the scarcest thing available, and they pay out in the second year, when attention is hard to find.

SmartEdge IT Solutions puts as many of them as the client wants into the launch itself rather than treating them as an optional extra, because the whole argument is about what happens after the invoice stops. The way we set out our approach makes that the part of the job we are actually being paid to do.

If a project has just been delivered somewhere else and you are inside the first year now, the useful exercise is not a rewrite. It is a fortnight of asking the people who use the system what they do outside it, what they stopped doing, and who decided that. Those three questions surface almost all of the causes above, and they surface them before the sunk cost has grown further.