Why Do Projects Fail? What Systems Engineering Actually Fixes

Most projects don't fail because something breaks. They fail because nobody thought about how everything integrates together.

That's the thing most people get wrong about integration. They don't think about it until it's too late. The biggest, best documented version of this happened at sea. In February 2022, the US Government Accountability Office reported that the Navy's Littoral Combat Ship, a fleet designed to be fast, cheap and modular, still couldn't reliably fulfil the mission it was built for more than a decade after the first ship launched. The swappable mission modules that were the entire point of the design arrived years late. Several ships were decommissioned barely ten years into a planned 35-ship fleet. The Navy now estimates it will cost over $60 billion to operate and support the 35 ships it plans to build.

No single part failed, and the engineers were world class. The ship and the mission systems it was built to carry were run as two separate programmes, on two separate schedules, with nobody responsible for making sure they met. When the modules finally arrived, the ships they were meant to turn into minehunters and submarine hunters had already been in the water for years, doing very little.

That's the pattern behind most project failures, whether it's a warship or a website. The technology changes. The industry changes. What doesn't change is that the boundary between two teams goes unowned until integration day, and integration day is where the bill lands.

Why Projects Fail: The Integration Problem

It's a structural problem, and that makes it a people problem. Somebody has to own the boundary, and on most projects nobody has been given that job.

Most retrospectives blame the symptom: scope creep, missed deadlines, budget overruns. Those are what you see downstream. Upstream, it's almost always the same thing. No individual was named as the owner of how the parts fit together.

You can spot it once you know the shape. Scope changes get waved through one at a time, so a dozen small tweaks quietly add up to a change nobody signed off on. Teams optimise their own slice without seeing how it lands on everyone else's, and the mismatch only shows up on integration day. What the customer asked for and what's being built drift apart, because nobody is holding the two side by side.

None of that gets fixed by working harder or by another status deck. These are cracks in how the work is structured, and you don't fill a structural crack with a stand-up meeting.

The £1, £10, £100 Rule

The longer a gap goes unnoticed, the more it costs to close.

There's a well-worn rule in engineering, traced back to Barry Boehm's work on software economics. A problem that costs about £1 to fix at the requirements stage costs roughly £10 by design, and £100 or more once the thing is built and in service.

The problem doesn't grow. Finding it late is what turns it ruinous. That is the entire case for catching it early, and it's the reason everything below exists.

Systems Thinking And Systems Engineering Are Not The Same Thing

Systems thinking allows you to frame and understand complex systems. It's the habit of asking "if we move this, what else moves?" before the change ships, rather than after it has broken something three teams away. It's how you understand the problem.

Systems engineering is how you implement the answer. Applying its tools and methods is what gets you to successful integration. One is understanding. The other is delivery. A project needs both.

How an Interface Control Document Is the Key to Successful Integration

Of the tools systems engineering gives you, the interface control document is the one that does the most work on integration.

An interface control document is an agreed record of how each part talks to every other part. What connects to what, who owns each side of that connection, what passes across it, and how you prove it works. Two teams building to the same boundary actually meet at integration, because the boundary was written down and agreed before either of them started. The Littoral Combat Ship's ship-to-module boundary is exactly the kind that was never pinned down.

Two more tools sit either side of it. Requirements traceability means every requirement is tracked from the customer's original need to the test that proves it's met, with a named owner, so nothing quietly goes missing. Verification and validation means checking at every stage, not just at the end, both that you built it right and that it's the right thing.

Get these right and you catch the integration problem in a quiet planning review. Skip them and you catch it in testing, or after delivery, which is the expensive way the Littoral Combat Ship found most of its problems.

Do It Often, Not Once

There's one more thing, and it isn't a tool. It's time.

Use all of the above iteratively and recursively, as frequently as the project schedule will allow. Not once at kick off. Not once before delivery. Every time something changes, you run the check again. That's what flags a problem while it still costs £1, instead of finding it when it costs £100.

Systems Engineer vs Project Manager

"Isn't that just project management?" It's the first thing most managers ask, and it's a fair question. The answer is no. They're two different jobs, and a good project needs both.

Your project manager owns the schedule, the budget and the people. On time, on cost, everyone pulling their weight. A systems engineer owns the thing a Gantt chart can't show you, which is whether all those moving parts add up to one system that works.

You can be dead on schedule and dead on budget and still hand over something that doesn't integrate, because those are two completely different questions. One asks, are we delivering the plan? The other asks, will the plan actually work?

If You're the One Signing It Off

You don't need to write an interface control document. You do need to know whether anyone has.

Ask your leads one question at the next review: which interfaces on this project have a named owner, and which don't? If nobody can answer, the £1 problems are already in the design, and you'll be meeting them at £100 during integration.

The Bottom Line

Projects don't usually fail because people didn't care enough. They fail because nobody owned how the whole thing fit together, and by the time that shows, it's expensive to fix. Systems engineering puts someone in that seat before the gap opens instead of after.

Want a quick gut check? Take the riskiest handoff on your current project. Write down who owns each side of it, and what crosses it. If you can't, you've just found your first gap.

Get the Free Interface Control Checklist 

Nine questions that tell you whether your project is going to integrate. Are your requirements SMART? Does each one have a named owner? Is there a physical architecture with named subsystems, and does each subsystem have an owner? Is there a named interface between them, how do they connect, and what is transferred across? And how do you prove each subsystem is doing what it was meant to?

Work through them on whatever you're building right now. Every question you can't answer in writing is a gap, and gaps are where projects fail.

Download the free Interface Control Checklist

References

Boehm, B. W. (1981). Software Engineering Economics. Prentice Hall. The origin of the 1-10-100 cost escalation rule, showing how the cost of fixing a problem rises the later it is found.

U.S. Government Accountability Office (2022). Littoral Combat Ship: Actions Needed to Address Significant Operational Challenges and Implement Planned Sustainment Approach (GAO-22-105387). Washington, DC: GAO, 24 February 2022. Retrieved from https://www.gao.gov/products/gao-22-105387

INCOSE (2023). Systems Engineering Handbook, 5th edition. Wiley. The reference standard for requirements traceability, interface definition, and verification and validation.