IT project management has changed considerably. Agile development, shorter delivery cycles, cloud platforms, automation and, increasingly, artificial intelligence have given teams tools that previous generations of project managers could only have imagined.
Yet technology projects still go wrong.
The problem is not necessarily that the software fails to work. Modern project failure is often less dramatic and more expensive: a system is delivered but produces little business value, arrives too late, costs substantially more than expected, fails to gain adoption, or solves a problem that is no longer particularly important.
Recent research suggests that complexity is becoming a major part of the problem. The Project Management Institute's 2026 Pulse of the Profession report found that 31% of complex projects failed to achieve the full scope of their intended benefits. PMI also found that project professionals who managed complexity effectively were substantially more likely to report successful outcomes.
This makes the familiar question, "Why do IT projects fail?", slightly misleading. Increasingly, the better question is why organisations continue to create conditions in which otherwise viable projects struggle to succeed.
Success is often poorly defined from the start
A project can be on time and within budget while still being unsuccessful.
If the organisation has not established what business outcome the project is supposed to produce, conventional project measurements can create a false sense of progress. Teams may successfully complete milestones, close tickets and deliver features without being able to demonstrate that any of those activities improved the organisation.
Useful success criteria need to go beyond delivery dates. Depending on the project, they might include reduced processing time, lower operating costs, improved customer retention, fewer incidents, increased capacity, better regulatory compliance or measurable employee adoption.
Those outcomes also need an owner. A project without someone accountable for achieving its business benefit can easily become an exercise in delivering technology for its own sake.
Business alignment is not the same as business ownership
IT departments have spent years working more closely with their business counterparts, but alignment alone does not guarantee success.
A technology team can thoroughly understand a business objective and still be unable to deliver it if the business itself does not take responsibility for the changes required around the technology.
An ERP implementation, for example, is rarely just an IT installation. It may require departments to change workflows, standardise data, abandon familiar processes, retrain staff and accept new responsibilities. Those decisions cannot realistically be delegated to the IT department.
Successful projects therefore need active business ownership rather than occasional executive approval. Sponsors must be available to resolve conflicts, secure resources and make decisions when the project encounters issues that cannot be solved by the technical team.
Decision-making can become a hidden bottleneck
Projects frequently lose time while waiting for decisions.
A technical team might require approval for a design change, clarification of a business requirement or a decision between competing priorities. If nobody has clear authority to make that decision, the project can stall while meetings, escalations and approval chains accumulate.
The delay is sometimes blamed on project execution even though the project team has little control over it.
Governance should therefore establish decision rights before they are needed. Teams should know who can approve scope changes, who owns particular business processes, which decisions can be made within the project team and which genuinely require executive involvement.
Good governance is not simply a collection of reporting meetings. Its purpose is to allow informed decisions to be made at the appropriate level and at a speed that matches the project.
Too many projects compete for the same people
Another persistent problem is the gap between an organisation's project ambitions and the resources actually available to deliver them.
It is relatively easy to approve another initiative. It is much harder to create additional experienced architects, engineers, analysts, security specialists, subject-matter experts and business representatives.
As more projects are launched, the same people are often divided between them. An employee assigned to five initiatives is not necessarily providing five projects with useful capacity. Context switching, meetings, competing deadlines and emergency work can consume a significant amount of that person's time.
This is partly a resource-management problem, but it is also a prioritisation problem. Senior management has to decide which projects matter enough to receive scarce people and which projects should be delayed, reduced or cancelled.
Attempting to make every initiative a priority usually results in none of them receiving genuine priority.
Project management itself remains a specialist skill
Large transformation programmes generally receive formal project-management support. Smaller technology initiatives are more likely to be handed to a business analyst, engineer, team leader or other employee alongside their normal responsibilities.
That can work, but technical expertise does not automatically translate into project-management expertise.
A capable project manager has to coordinate dependencies, identify risks, manage stakeholders, track resources, control changes to scope and recognise when seemingly minor delays are beginning to affect the wider programme.
The role also requires time. Giving project-management responsibility to someone without reducing their existing workload effectively treats management of the project as an administrative side task.
Stakeholders discovered late become expensive stakeholders
Large IT systems rarely affect only the people who requested them.
Finance, security, legal, compliance, operations, customer service, data teams and external partners may all have requirements that are not obvious during the project's initial planning.
Leaving one of those groups out does not eliminate its requirements. It merely postpones their discovery.
Late discoveries are particularly expensive because they can require completed work to be redesigned. A security requirement identified during architecture planning may be straightforward; the same requirement discovered immediately before deployment can delay the entire release.
Stakeholder analysis should therefore be treated as an ongoing activity rather than a list produced at the start of the project and then forgotten.
Change management is part of delivery
A technically successful deployment can still fail if the people expected to use it continue working in the old way.
This is one of the clearest differences between installing technology and delivering business change.
Change management is sometimes reduced to sending announcements, producing training material and telling employees when a new system will go live. Effective change management goes further. It considers how roles will change, why people might resist the new process, what incentives reinforce existing behaviour and whether managers themselves are supporting the change.
Research published by change-management specialist Prosci has found a relationship between effective change management and projects meeting their objectives, schedules and budgets. As with other vendor research, the findings should be interpreted in that context, but the underlying point is consistent with broader project experience: deployment and adoption are not the same thing.
AI makes some project work faster, but not necessarily easier
Artificial intelligence is introducing a newer complication.
Project teams can now use AI tools to help draft requirements, produce documentation, analyse information, generate code, create schedules and perform other tasks much faster than before.
That speed can be valuable, but it creates two risks.
The first is accuracy. AI-generated work can contain incorrect assumptions, invented information or subtle inconsistencies that appear plausible during a quick review. The faster an organisation generates material, the more disciplined its validation process needs to become.
The second is a mismatch between machine speed and human capacity.
Generating code, documents or analysis more quickly does not mean that architecture reviews, security assessments, testing, approvals and business decisions can accelerate at the same rate. AI can simply move the bottleneck to another part of the delivery process.
This makes assumptions that AI will automatically allow projects to be delivered with dramatically fewer people particularly risky. Productivity improvements in one activity do not necessarily translate directly into equivalent reductions across an entire project.
Complexity compounds rather than remaining isolated
The most useful addition to the traditional discussion of project failure comes from recent PMI research into complex projects.
PMI describes modern projects as increasingly affected by interconnected organisational, technological, regulatory and human factors. Its 2026 research found that 97% of project professionals had managed at least one complex project during the previous year, while 81% believed projects had become more complex in recent years.
This matters because project problems rarely occur independently.
An unclear requirement can trigger a delayed decision. The delay can create a resource conflict. The resource conflict can force a schedule change. The schedule change can affect another department, which introduces a new requirement. By the time the project dashboard turns red, the original problem may be difficult to identify.
Managing such projects therefore requires more than following a methodology correctly. Teams need to understand the relationships between stakeholders, decisions, dependencies, resources and expected outcomes.
The industry's old lessons have not disappeared
Many of these problems are not new.
Research by McKinsey and the University of Oxford, published in 2012, examined more than 5,400 IT projects and found substantial cost overruns and lost business value among large initiatives. Because that study is now more than a decade old, its figures should not be presented as a measurement of today's IT project failure rate.
Its broader findings remain instructive, however. The researchers identified problems involving strategy, stakeholders, project teams and technical complexity, many of which closely resemble the problems organisations continue to report today.
That continuity suggests that the industry's difficulty is not primarily a shortage of new methodologies.
Waterfall gave way to agile practices. Infrastructure moved into the cloud. Collaboration tools improved. Automation expanded and AI arrived. Each development changed how projects could be delivered, but none removed the need for clear objectives, realistic resources, accountable owners, capable management and timely decisions.
Reducing project failure requires fewer assumptions
There is no single process that guarantees a successful IT project, particularly when the work is complex. There are, however, several questions that expose weaknesses before they become expensive.
- What measurable business outcome is the project expected to produce?
- Who is personally accountable for that outcome?
- Does the project have the people and skills it actually requires?
- Which initiative loses priority if this one becomes urgent?
- Have all affected stakeholders been identified?
- Who has authority to make time-sensitive decisions?
- How will employees be encouraged and supported to adopt the resulting change?
- Where is AI genuinely reducing work, and where is it merely moving work elsewhere?
- What assumptions would cause the business case to fail if they proved incorrect?
These questions are less exciting than a new framework or an AI-powered project-management tool, but they address the conditions in which projects actually succeed or fail.
The central lesson is that an IT project is rarely just an IT project. It is an organisational change programme that happens to involve technology. Treating it that way from the beginning is one of the best defences against discovering, months or years later, that the technology was delivered but the intended result was not.
No comments:
Post a Comment