Why Do Large IT Infrastructure Projects Fail Even When the Technology Selection Is Correct?
A network refresh, a data centre migration or a security rebuild can go wrong even when every product on the bill of materials was the right call. The firewall is the right firewall. The cloud platform is the right platform. The project still runs late, goes over budget, or never delivers the benefit it was approved for.
That is not bad luck. Studies of IT project outcomes keep reaching the same conclusion: the technology choice is rarely what separates projects that work from projects that fail. This article sets out what the latest evidence says, where infrastructure projects break in practice, and what Indian IT teams should check before their next phase.
The short version
What is the problem? Large IT projects still miss their goals at a high rate. PMI's 2026 Pulse of the Profession found that 31% of complex projects fail to deliver the full scope of the benefits they were meant to deliver.
Is it mainly a technology problem? No. The causes that practitioners and researchers name most often are unclear success measures, no accountable business owner, weak sponsorship, poor prioritization, slow decisions and weak change management.
How bad can it get? In the best-known study of large IT projects, McKinsey and the University of Oxford found that projects with budgets above $15 million ran 45% over budget on average, 7% over time, and delivered 56% less value than predicted. That study is from 2012, so treat it as a benchmark for scale, not a current rate.
Has it improved? Not much. A January 2026 research update in the PM World Journal found that IT project success rates have barely moved in recent years, even though technical capability has expanded.
What should you do first? Write down what success means in measurable terms. Name one owner for the whole outcome, not one per vendor. Then check that the plan covers the period after go-live, not only the deployment.
What the research actually says
McKinsey also defines a "black swan" project as one that overruns its budget by more than 200%, and says the worst cases reach 400%.
We have left out failure-rate figures that we could not trace to a primary or clearly attributed source.
Why the numbers do not match across sources
Readers comparing these studies will see figures that look contradictory. An 80% success rate in one report and a 31% failure rate in another do not mean one of them is wrong. They measure different things.
PMI's 2025 figure counts whether enterprise projects met their business goals.
PMI's 2026 figure looks only at complex projects and asks whether they delivered the full scope of intended benefits.
McKinsey and Oxford measured large IT projects against their original budget, schedule and predicted value, and report averages.
Older "success" definitions count only on-time, on-budget, in-scope delivery. CIO.com notes that practitioners now define failure more broadly: not delivering expected benefits in the expected timeframe, finishing so late the result is obsolete, or building something users refuse to adopt.
For your own tracking, pick one definition of success before the project starts and measure against it. Do not borrow a headline percentage.
Why "we chose the right technology" gives false confidence
Technology selection is the most visible part of a large project. It has RFPs, vendor demos, proof-of-concept results and reference calls. It also has a clear answer, so it feels like the most important decision.
That visibility is the trap. It pulls leadership attention toward the part of the project with the clearest answer, and away from the parts the research keeps linking to failure: who owns the outcome, how decisions get made, how change is managed, and who runs the system afterwards. Those parts are harder to demo and easier to under-resource.
One consultant quoted by CIO.com, Nick Kramer of SSA & Co., says he has seen more projects fail because of poor change management than because of poor technology implementation. That is one practitioner's view, not a measured statistic, but it matches the pattern in the studies above.
The conclusion below is our analysis, not a finding of any single study: a project can pass vendor selection with a technically excellent choice and still fail, because nobody was tracking whether the rollout plan, the adoption effort and the post-go-live operating model were sound.
Which projects are most exposed
Exposure depends on how the project is organized, not only on its size.
Multi-vendor, multi-site programmes. Network, security, cloud and hardware are each handled by a different party, and nobody owns how the pieces fit together.
Migrations to cloud or hybrid environments. IBM's 2026 Cost of a Data Breach Report for India lists cloud migration among the top three factors that raise breach costs, alongside shadow AI and regulatory non-compliance.
Projects that touch regulated or personal data. Rules that nobody mapped at the start have a habit of showing up at the audit instead.
Projects staffed thinly on the assumption that AI will save time. Noah Fletcher of West Monroe told CIO.com that executives often overestimate the time and resource savings AI brings, then ask for faster delivery with fewer people.
Small and mid-size projects run by someone without project management training. Eric Bloom of the IT Management and Leadership Institute told CIO.com these projects are often handed to a business analyst who has neither the experience nor the time for the role.
A single-vendor, like-for-like refresh with a trained project manager and a clear business owner sits at the low-risk end. Even there, the questions in section 8 are worth asking.
Where infrastructure projects actually break
These eight failure points come from CIO.com’s August 2026 review and the research above, applied here to infrastructure work.
1. Success is not defined. Projects launch without concrete, measurable targets. George Reed, CIO at auntEDNA.ai, argues that no project should be approved without them. “Deploy a new firewall at every branch” is an activity. “Every branch covered by one policy, with changes approved and logged centrally” is an outcome.
2. No accountable business owner. Even when IT is aligned with business goals, a project can fail if no business leader is accountable. Eric Stettler of Kearney says the business has to decide to operate differently. The CIO cannot do that alone.
3. Sponsorship exists only on paper. Lenka Pincot, chief of staff to the CEO at PMI, says sponsors need to be actively involved, not just reading dashboards. She adds that for a business project with an IT component, the sponsors should be the CIO and someone from the business.
4. The current state was never properly assessed. This one is our reading rather than a cited finding. If the inventory of devices, versions, dependencies and data flows is incomplete, the "right" technology is being chosen against an inaccurate picture.
5. Stakeholders are missing. Project manager Krista Phillips describes a multinational rollout that left one division completely unaware of the work. Teams rarely miss a whole division, but security, compliance, network operations and application owners are often brought in late. Their requirements then arrive as change requests.
6. Decisions are slow. Rick Catalano of AMIGO says that too often nobody is empowered to decide, and project managers wait for answers and then get asked why things are late. A decision-rights matrix in the governance model fixes this.
7. Too many projects, weak prioritization. Fletcher says prioritization governance is frequently ineffective, so too many people work on too many things and several projects suffer at once.
8. Change management and Day 2 operations come last. Change management is often reduced to a communications plan, Kramer says. For infrastructure, add the operating model: who monitors, who patches, who answers the call at 2 a.m. A deployment with no run model decays after go-live. This part of the point is our analysis.
Why a project that looks fine can still be at risk
A late project is the visible cost. The less visible one is a project stuck half-finished, with production running on a mix of old and new components and security controls that have not caught up.
The numbers show how expensive that can be. McKinsey's black swan projects overrun by more than 200%. IBM puts the average data breach in India at INR 25.5 crore in 2026, up 15.9% from INR 22 crore a year earlier, a figure released on 3 August 2026. Cloud migration is one of the top three drivers of higher breach cost in India.
IBM's India findings also point to what might be helpful. Offensive security testing, such as red teaming and penetration testing, was the biggest cost-reducing factor, cutting average breach cost by about INR 2.47 crore. Breaches cost INR 31.6 crore on average at organizations with no security automation, against INR 21.3 crore at those using it extensively.
Our reading: migrations and rebuilds are the moments when logging gaps, open management interfaces and rushed exceptions appear. Security testing should be a scheduled item in the plan before go-live, not something added when the project is already over budget.
What to check before your next phase gate
Start with the questions that cost nothing.
Ask the sponsor for the outcome in one sentence, with a measure. If three people give three answers, pause the phase gate until they agree.
Name one owner for the end-to-end outcome. Write down decision rights and a maximum turnaround time for decisions.
Re-run the current-state inventory. Cover every device, software version, dependency and data flow, including colocation and disaster recovery sites.
Check the stakeholder list. Confirm that security, compliance, network operations, application owners and finance have each signed off the requirements.
Test the resourcing assumption. Where the plan counts on AI or automation to cut effort, ask for pilot results before accepting the saving.
Review the change plan. Who is trained, by when, who owns adoption, and what is the rollback if adoption fails.
Confirm logging and incident paths are in the design. Device and access logs should reach a central collector with synchronized clocks, and retention should meet the longest rule that applies to you.
Define Day 2 before go-live. Monitoring, patching, escalation levels, support hours and maintenance contracts should all be agreed in advance.
Schedule security testing before go-live. Vulnerability assessment and penetration testing belong in the project plan with their own dates.
Set re-evaluation points. Phelps, CIO of Laserfiche, told CIO.com that the business case should be approved and then re-evaluated as the project progresses. Decide now at which milestones you will do it, and what result would stop the project.
The compliance angle for Indian organizations
An infrastructure project that goes live without logging and reporting built in creates a regulatory gap on day one.
Under the CERT-In Directions of 28 April 2022, covered entities must report specified cyber incidents within six hours of noticing them and keep ICT logs for a rolling 180 days.
The Digital Personal Data Protection act Rules, 2025 were provided on 13 November 2025. They are being phased in: the core operational obligations, including breach notification and security safeguards, apply from 13 May 2027, which is 18 months after notification. Under the Rules, a data fiduciary must inform the Data Protection Board of a personal data breach without delay, and follow with a detailed report within 72 hours. The Rules also require minimum one-year retention of certain logs and processing records. BDO India's summary of the Act lists penalties of up to INR 200 crore for failing to notify a breach.
The practical link to project design is simple. Infrastructure being built now will go live shortly before or inside that window. If the design cannot produce a log trail, a breach timeline and a record of access, the gap is built in. Sector regulators such as RBI and SEBI add their own requirements for regulated entities, so check which apply to you.
NS3's services support technical readiness and are not legal advice. Take advice from counsel on how the rules apply to your organization.
What happens next
These are forecasts and our own reading, not facts.
Compliance work will land on the same calendar as modernization. With DPDP core obligations due on 13 May 2027, expect network, logging and data-retention work to compete with modernization programmes for the same teams. That raises the importance of prioritization, which is already a common failure point.
Plans will keep getting more optimistic. AI-assisted scoping and scheduling makes plans quicker to produce. CIO.com's review warns that AI output can look good while carrying small errors, and that leaders may expect faster delivery with fewer people. Expect more under-resourced projects.
Failure rates will stay stubborn. The January 2026 research update found success rates stagnating despite better technology. The teams that improve will get there through governance, ownership and operations, not through better tools.
How NS3TechSolutions Helps Enterprises Avoid These Failures
Most of the failure points sit before and after technology selection, not in it. NS3TechSolutions works in enterprise networking, network security, cloud and managed infrastructure services, and runs engagements through six phases: Assess, Architect, Implement, Secure, Operate and Optimize. The company does not start with a product. It starts with the business requirement, the operational challenge and the security risk.
In practice, teams can use NS3 for:
IT and network assessments and cybersecurity assessments that build an accurate picture before architecture decisions are made.
Architecture and solution design tied to the business requirement identified in assessment, not to a preferred product.
Migration and cloud integration planning, including sequencing and rollback.
Implementation across network, security, infrastructure and cloud by one accountable team, working with multiple OEMs, so the pieces are integrated rather than handed between vendors.
24x7 SOC and NOC coverage, L1 to L3 support and AMC contracts after go-live, so Day 2 operations are covered from the start.
Training and knowledge transfer, so your own team can run what was built.
One limit is worth stating. No partner can replace the business owner and the active sponsor on your side. Those roles stay with you. What a partner can remove is the fragmented ownership between vendors and the gap between deployment and operations.
Quick checklist
[ ] Success defined in measurable terms and agreed by the sponsor
[ ] One accountable owner for the end-to-end outcome
[ ] Active business sponsor named, with time committed
[ ] Current-state inventory complete, including DR and colocation sites
[ ] Security, compliance, network operations and application owners signed off requirements
[ ] Decision rights and turnaround times written down
[ ] Staffing plan tested against real effort, especially any assumed AI savings
[ ] Change management and training plan with an adoption owner
[ ] Logging, retention and incident-reporting paths designed in
[ ] Day 2 operating model agreed before go-live
[ ] Security testing scheduled before go-live
[ ] Re-evaluation milestones and stop criteria recorded
FAQ
Q. Does this mean technology selection does not matter?
A. No. A wrong architecture will cause problems. The research shows that governance, ownership, change management and operations account for more failures than technology fit, and they usually get less attention than the vendor decision.
Q. Is the 70% IT project failure rate correct?
A. CIO.com's August 2026 review says that figure dates back several years and is unreliable today. Current estimates run from about a third to as high as 70%, and PMI's 2026 report puts failure to deliver full intended benefits at 31% for complex projects.
Q. What counts as failure?
A. Practitioners quoted by CIO.com define it as not delivering the expected benefits in the expected timeframe. It can also mean a project that produces no return, finishes too late to be useful, or builds something users will not adopt.
Q. Who should own an infrastructure project, just IT or the business?
A. Both. PMI's Lenka Pincot told CIO.com that for a business project with an IT component, sponsors should be the CIO and someone from the business. The business owner is accountable for process change and adoption.
Q. Do the DPDP Rules affect my infrastructure project?
A. The core obligations apply from 13 May 2027. If your project handles personal data, design logging, access records and breach-reporting paths now rather than retrofitting them. Take legal advice on how the Rules apply to you.
Q. When should Day 2 operations be planned?
A. Before go-live, in the same phase as architecture. Decide who monitors, who patches, what the support levels are and how escalation works while the design can still change.
The decision to make now
The real question is not whether your team has picked the right technology. It is whether anyone owns the outcome end to end, whether success has been defined in numbers, and whether the plan survives contact with the day after go-live. Organizations that can answer those three in a meeting this week are treating the project as an operating change. The rest are treating it as a purchase, and the research suggests that is where large projects go wrong.
Sources- http://auntEDNA.ai, CIO.com