Many IT projects still fail despite modern methodologies
The tech world moved from waterfall models to Agile, from rigid timelines to fast sprints. Teams are working in shorter cycles, delivering in weeks instead of months. But here’s the reality, a significant number of IT projects still don’t succeed.
What does failure look like today? It’s not systems crashing or hardware breaking. It’s more subtle and more expensive: projects that don’t generate the expected return, tools people don’t adopt, rollouts that land too late to matter. You can build clean code, but if the result doesn’t tie into a business goal, it’s wasted effort.
PMI’s 2025 Pulse of the Profession reports that about 20% of enterprise projects don’t meet business goals. That’s one in five. The situation is even sharper in AI: MIT’s “The GenAI Divide: State of AI in Business 2025” reports that 95% of generative AI pilots fail to bring financial returns in their first six months.
It’s clear: speed and iteration aren’t enough on their own. You need impact. You need alignment between what’s being built and what the business needs. Otherwise, you’re just accelerating toward the wrong outcome.
Lack of project management expertise continues to undermine delivery
Professional project management is foundational. Yet too often, small and midsize projects get handed to people without the training or tools to manage them. Companies assign analysts or team leads to handle critical work without the structure, process knowledge, or time they need to do it right.
This isn’t a training issue; it’s a structural one. Project managers with real experience don’t just manage a schedule. They forecast risks, align resources, enforce discipline across teams, and protect timelines from unnecessary changes. They know when to be flexible, and when to be firm. That’s what delivery looks like at scale.
Eric Bloom, Executive Director at the IT Management and Leadership Institute, points out the consequences: when small projects are run by non-specialists, scope expands, commitments drift, and oversight disappears. And contrary to how many organizations operate, small projects aren’t less critical, they’re often interconnected with larger systems and objectives. If they fail, they create ripple effects upstream.
Executives must face a basic fact: trained project managers increase the probability of success. The return on that capability is direct, measurable, and strategically significant. If you’re spending millions on development, spending proportionally on project leadership is not a luxury. It’s required.
Misalignment between IT initiatives and business objectives undermines success
Too often, companies launch tech initiatives without a clear destination in mind. A shiny new tool or trend commands attention, and executives say, “Let’s do something with this.” The result? Projects driven by excitement, not strategy. That’s a direct path to wasted time and unmet expectations.
The right way: start with a business objective. Identify a problem worth solving. Then define what success means, financially, operationally, or otherwise, and only then choose the technology. This sounds basic, but according to experts, it still doesn’t happen often enough.
Kathleen Walch, Director of AI Engagement and Community at the Project Management Institute, says organizations still adopt tools before they define the need they’re solving. This is visible in AI deployments, where projects are launched without a tight strategy, leading to outputs that don’t move business metrics.
Thomas Phelps IV, CIO of Laserfiche and board member at the SIM Research Institute, emphasizes a key fix: businesses must treat the business case as a living document. Revisiting it regularly, not just after go-live, ensures that the project continues to support the evolving landscape. Markets shift, goals adjust. Your project should too.
Executives should lead with discipline here. If a project can’t point to a business result or has no clear metric tied to outcomes, it’s either not ready or it shouldn’t happen.
Absence of clear business ownership diminishes project accountability
Success in tech projects doesn’t belong to IT alone. When no one on the business side takes real ownership, accountability disappears. That’s a major problem.
Projects without a business owner often fail to tie into operations. Resources aren’t committed when needed. Process changes don’t happen on schedule. And when the system is live, teams don’t adopt it, not because the technology doesn’t work, but because the business wasn’t ready to operate differently.
Eric Stettler, Partner in the Technology Transformation practice at Kearney, said it plainly: business projects led solely by CIOs become a tail-wagging-the-dog scenario. The IT function can enable a process, but it shouldn’t be asked to design and enforce operational execution across the business.
That role belongs to a clear leader on the business side, someone who is accountable from start to finish. They should own the problem, control the budget, and have the authority to drive decisions that impact their part of the organization.
For executives, this shift means asking a basic but critical question at the outset of any project: who owns this on the business side? If that person doesn’t exist or isn’t engaged, the risk of failure increases sharply.
Insufficient sponsor engagement leads to oversight and misdirection
Business sponsors are often identified early in a project, but too many step back once execution begins. They attend occasional status updates, glance at dashboards, and move on. That’s not engagement, it’s observation. And it leaves projects exposed.
Sponsors who don’t actively engage miss early warning signals. They don’t build direct relationships with project teams. When teams hesitate to escalate problems due to lack of trust or accessibility, small issues become costly blockers. Critical decisions get delayed. Course corrections don’t happen in time.
Eric Stettler, Partner at Kearney, points out that limited sponsor involvement leads to missed opportunities for influence when it matters most. Sponsors need to do more than look at green status indicators, they should be on the ground enough to question assumptions, validate progress, and support the team when they hit resistance.
This doesn’t mean micromanaging. It means being strategically attentive. A credible executive sponsor should conduct spot checks, directly review updates, and ensure they’re helping, not just reporting. When teams view the sponsor as an active partner rather than a figurehead, transparency increases, and issues surface faster.
Executives need to reset the norm here. Sponsorship isn’t symbolic. It’s operational. If a project matters strategically, the sponsor should spend the time to make sure it succeeds.
Inadequate stakeholder involvement results in missed requirements and reduced adoption
Excluding key stakeholders during the planning and execution phases causes more than friction, it leads to failed outcomes. Entire business units may be caught off guard, not because they resisted change, but because they were never brought into the conversation.
When stakeholders aren’t consulted early, project teams miss important business requirements, ignore regulatory needs, or overlook how day-to-day users will interact with the solution. The result is a project that, while technically complete, doesn’t reflect real business operations. Adoption drops. Resistance grows.
Krista Phillips, PMP and President of PMI’s Pikes Peak Regional Chapter, shared a clear example: one multinational corporation missed an entire division during a major platform rollout. That business unit had no idea the change was coming, leading to confusion, lack of adoption, and a project that had to retroactively adjust its scope.
This is avoidable. Stakeholder mapping isn’t optional. It must be comprehensive and validated across departments, especially in complex or global organizations. Every affected team should have representation early, and continuously, during development.
For executives, the takeaway is direct: don’t assume alignment. Confirm it. Push project leaders to validate who’s at the table from day one. Confirm that operational voices, not just senior managers, are engaged. That creates clarity, reduces rework, and increases the likelihood of real adoption when the switch flips.
Inadequate resource planning and inexperienced teams drive project failures
Most tech leaders underestimate what it really takes to deliver. Not in terms of ambition, but in resourcing. Many assume they can ramp up expertise later or borrow talent midstream when complexity increases. That’s not how execution works.
Accurate resource planning needs to happen early, before approvals, before kickoff. You need clear estimates on time, specialization, availability, and cost. Most importantly, the people assigned need to stay committed from start to finish. Project momentum breaks when key contributors are pulled out mid-project to solve unrelated problems.
Thomas Phelps IV, CIO at Laserfiche, observed that many failures trace back to project managers who have certifications but lack real delivery experience. They miss details like how timeline slippage directly translates to budget overrun, especially when consulting teams or vendors are involved.
Eric Stettler, Partner at Kearney, added a critical point: most organizations expect to “plug in” experienced talent if things go wrong. In practice, that talent usually isn’t available. Skilled contractors and internal experts are booked months in advance. Waiting for them kills velocity when it’s needed most.
Sanjeev Vohra, Chief Technology and Innovation Officer at Genpact, emphasized that estimating resource needs becomes even harder with AI and emerging tech. Available skills are rare. Without precision in scope and hiring, it’s easy to overpromise and underdeliver.
For executives, this is a planning discipline. Don’t approve a project without seeing the full staffing model. Look beyond titles, validate capability, availability, and delivery history. The investment upfront is worth the cost of avoiding breakdowns later.
Neglecting change management limits adoption and reduces project value
Technology implementation is just the surface. Most project failures today happen not because the software is broken, but because people don’t change how they work. That’s a leadership issue, not a platform issue.
Change management isn’t just communication. It’s a structured set of activities that align people, incentives, and workflows to operate differently. That includes training, feedback loops, transition support, and a visible case for why the change matters. When it’s rushed or done late, people revert to old habits. Adoption stalls.
Nick Kramer, Principal for Applied Solutions at SSA & Co., has seen more failures tied to weak change management than bad tech. He stressed that projects need someone focused on execution and transformation, not just deployment. Change agents understand resistance patterns. They identify blockers and remove them with practical action, not hope.
Too many executives dismiss this function as overhead. It’s not. Without change enablement, even well-designed systems don’t deliver expected ROI.
If you’re funding a project, fund the change team. Expect a strategy for employee transition, not just IT cutovers. Make someone responsible for outcomes beyond go-live. That’s how value gets realized, not just built.
Final thoughts
Failure in IT isn’t a technology issue anymore, it’s a leadership issue. The tools work. The code runs. What breaks are the fundamentals: clear ownership, strategic alignment, strong oversight, and the ability to lead people through change.
You don’t need more frameworks or process layers. You need accountability where it matters. Assign real business owners. Fund experienced project managers. Involve every stakeholder early. And don’t just deploy tech, manage the change that comes with it.
If you’re signing off on multimillion-dollar projects, make sure they’re tied to specific business outcomes. Make sure the right people are driving them. And make sure you’re ready to step in when it counts. That’s how you shift the numbers. That’s how you stop avoidable failure.
