Agile. We run 2-week sprints with planning, daily standups, sprint demos, and retrospectives. This gives you working software every two weeks instead of waiting months for a final delivery.
Read full answerAfter delivering 200+ software projects since 2012, we have learned something uncomfortable: most IT projects do not fail because of bad code. They fail because of decisions made around the code — by leadership, by users, and by budgets.
Why do IT projects fail? In our experience, five recurring reasons cause the most damage: no buy-in from the top, skipping user acceptance testing (UAT), rejecting the technical proposal, late or missing payment, and unrealistic timelines. None of these are technical problems. They are human and commercial ones — which means every single one of them is preventable. Industry data backs this up: the Standish Group’s research has long pointed to lack of executive sponsorship as a top cause of failure, and roughly 30% of projects fail due to weak stakeholder involvement.
Here are the five reasons in detail, and exactly how to avoid each one.
1. No Buy-In From the Top
The single biggest predictor of whether a project succeeds is whether the boss actually cares.
A successful rollout almost always involves iteration, UAT, and an agile approach repeated until the system fits 100% of what the team was already doing in their day-to-day operations. Getting there takes persistence — and persistence needs a push from leadership. In most organisations, the only force strong enough to move staff out of their comfort zone and adopt something new is genuine pressure from the top.
The logic is simple: if the boss does not really care, the staff will not follow through. When that happens, testing slips, feedback dries up, and the project stalls and drifts into delay. We have seen capable teams deliver excellent software that still failed adoption — not because the build was wrong, but because nobody at the top was driving the change.
How to avoid it: Before kickoff, secure a project sponsor with real authority who treats the rollout as a priority, not a side task. Leadership does not need to attend every meeting, but it does need to set the expectation that the team will test, give feedback, and adopt the new system.
2. Treating UAT as an Afterthought
We are 100% confident in our ability to deliver — but we still strongly encourage every stakeholder and affected user to test the project at every partial release.
We work in an agile way: when each milestone or module is done, we release it for testing. That window is the best time for the related users to try it out and give feedback as quickly as possible, so we can fix issues and keep the project on track. When users skip this and wait until the final UAT round or the training session, a wave of problems and workflow gaps surfaces all at once — almost always because of an expectation mismatch between what was assumed and what people actually do.
Our experience is consistent: when users are involved early in partial-release UAT, then again in the full UAT — and in System Integration Testing (SIT) too, if the company has its own IT team — the result is a far smoother deployment and go-live. Industry research agrees that most UAT failures come from misaligned requirements and poor user involvement, not from faulty code.
This is exactly why we run an agile development process with continuous client testing built in, rather than a single big reveal at the end.
| When users test | Typical outcome |
|---|---|
| Every partial release + full UAT + SIT | Smooth deployment, few surprises at go-live |
| Only at the final UAT or training | Workflow gaps and expectation mismatches surface all at once |
| Not at all | Adoption fails even when the software works |
3. Rejecting the Technical Proposal
With 200+ projects behind us, our technical recommendations are grounded in what actually works — not guesswork.
When a system needs a revamp — because user volume has grown 100x since launch, because peak-hour load is higher than the original design assumed, or because features have been bolted on over the last five to seven years — that usually means it is due for a refactor, an upgrade, and some optimisation. Yes, this involves a portion of cost. But after the refactor or optimisation, the system normally runs well again.
The trouble starts when multiple parties get involved — an internal IT team, a third-party IT consultant — who are not the ones with hands on the actual code. They tend to drift from reality. They may blame the infrastructure and ask for more budget there, push to change the infra platform, or add features the project does not need. Meanwhile the real problem still sits underneath all of it, untouched.
For a system that is 5 to 10 years old, a measured refactor or revamp is completely normal. It typically covers:
- Supporting a higher number of concurrent users
- Upgrading old, out-of-date code versions
- Removing deprecated code
- Checking for errors after the upgrade
- Checking for usability after the upgrade
How to avoid it: Trust the team that is actually hands-on with the code. When we propose a refactor or system upgrade, it is because the data points there — and addressing the real problem is almost always cheaper than re-platforming around it. The same applies to integrating systems that have outgrown their original design.
4. Late or Missing Payment
This one is rarely discussed openly, but it is one of the most common reasons projects collapse.
A capable development team carries a high running cost, because the talent needed to complete and maintain your project is expensive to keep. Client payment is therefore crucial to the continuity of the company building your software. When payment stalls, the team that knows your project best is the first thing at risk.
At Advisory Apps we are fortunate to run multiple software products and projects that support one another, so we are not solely dependent on any single client. A vendor that depends entirely on one project is in a far more fragile position — if that one payment slips, the consequences can be devastating for both the vendor and your project.
How to avoid it: Agree on clear payment milestones tied to deliverables up front, and keep them on schedule. Predictable payment keeps the team funded, focused, and available for your project. (See our typical payment terms for how we structure this.)
5. Unrealistic Timelines
Even the best team in the world needs time to develop a complex project properly.
Based on our experience, some timelines are simply too rushed — for example, expecting a whole complex project cycle to be completed in three weeks. During development, writing code is only part of the job. We also have to test against the physical environment: kiosks, hardware, scanners, and integrations with other systems.
That last one — integration — is often the slowest part, and it is frequently out of our hands. We can move very fast, but another software company’s team may need more time to alter their system and fit our integration requirements, which means we wait on their input. Compressing the whole project into an unrealistic window does not remove this work; it just forces the team to burn unnecessary time and effort and drains the team’s health. We can usually still pull it off — but at a real cost to quality and morale.
A proper timeline produces a higher-quality output at the first UAT, which is exactly what you want: fewer defects, fewer surprises, and a faster path to a stable go-live.
The Pattern Behind All Five
Look closely and the common thread is obvious: none of these five reasons are about technology. Leadership commitment, user participation, trusting the technical plan, paying on time, and setting a realistic schedule are all decisions made by people — not problems with the build.
That is the good news. Technical risk is real, but a competent team can manage it. The reasons projects actually fail are the ones within your control as a client and partner. Get these five right, and you remove the most common causes of failure before the first line of code is written.
If you are planning a new system — or trying to rescue one that has stalled — book a free consultation with our team. We will give you an honest read on the leadership, testing, technical, and timeline factors that will make or break your project, drawing on what we have learned across 200+ deliveries since 2012. You can also browse our portfolio to see how this approach plays out in real projects.
Sources: Standish Group / Chaos Report findings via Gitnux, TestMonitor — why UAT fails.
