Why do IT projects stall? It's rarely the technology

Capable teams can work for a long time without delivering. Usually it isn't the technology – it's ownership, requirements and a shared definition of done.

Dotun Ogunkanmi · 2026-11-04 · 4 min read

When an IT project drags on, people almost always look for the fault in the technology. The wrong platform, the wrong architecture, the wrong vendor or too little skill in the team. Sometimes that's true. But in most of the delayed projects I have seen, including the ones I have stood in the middle of myself, technology has rarely been the real problem.

A pattern that keeps coming back

The pattern often looks something like this. A capable development team sees the business's problems and wants to solve them. The team comes up with ideas, builds for a long stretch and shows the result when it feels finished. Then it turns out the solution doesn't quite fit – the needs have changed, or they only ever applied to part of the business. The team rebuilds, the scope grows, and nobody can say exactly when anything is done.

What makes the pattern hard is that everyone is doing their best. The developers work hard and want to make a difference. The business is busy delivering to its customers. Management is waiting for results. And still nothing moves, and after a while frustration builds up on all sides, making it even harder to work together.

In-house development needs someone who commissions it

The core issue is nearly always the same: the organisation expects the same from in-house development as from an off-the-shelf system – that something is delivered and works. But when you build your own, the business isn't just a user. It is the customer and the owner. It needs to help define which needs to solve, set priorities, test, and speak up early.

That capability – commissioning and owning development – rarely appears on its own. It isn't about unwillingness. It's just that nobody has usually explained that it's needed, or given anyone the time and mandate for it.

Three principles that usually untangle it

What helps is rarely technical. It starts with the leadership and the managers who own the business, and with three principles:

1. Development is a cycle, not a race with a finish line. You release something, learn from it and improve. That requires the business to be involved all the way, not just at the start and the end.
2. The business owns what is built. Every solution needs a clear owner in the business who defines the needs, sets priorities and accepts the delivery.
3. Standardise before you digitalise. You can't build good software for a business where every customer or department gets its own variant. What you want to digitalise has to be defined first.

It also helps when development and IT operations work under one leadership. When the people who build and the people who run have different managers and different goals, the handovers often become the weakest link.

A shared definition of done

The single most effective tool I know is also the simplest: management, the business and development writing down together what must work before a solution is put into use – and what can wait for the next version. Who accepts the delivery? How do we know it works? What is explicitly not included?

Once that agreement exists, the discussion stops being about who is right and starts being about what is missing. I have seen solutions that had been stuck for a long time go live within a few months once that piece fell into place.

The launch is only half the job

A solution being ready doesn't mean it's being used. Often many people have to learn a new way of working – sometimes including people at partners and subcontractors who aren't employed by the company. That takes an accountable manager in the business, a plan for training and follow-up, and a culture of giving feedback instead of giving up when something doesn't work straight away. That deserves an article of its own.

Five signs your project has stalled for the wrong reasons

• The team builds solutions it has come up with itself, and shows them to the business only when they are "finished".
• Nobody in the business can say who owns the solution and prioritises the next step.
• There is no shared, written definition of when a delivery is done.
• Every customer or department expects its own version of the solution.
• Development and operations have different managers and rarely talk to each other.

If you recognise two or more of them, new technology, more developers or a new vendor will rarely help. What's needed is ownership, prioritisation and a shared language between the business and IT.

Technology is usually the easy part

When a project has stalled, it's tempting to look for someone to blame. But usually it isn't about individuals – it's about a way of working where nobody has been given clear responsibility for the whole. With clear ownership, a shared definition of done and a leadership that takes on its role, the same people can deliver in a few months what used to take years.