The Old Way Is Broken: Why Traditional Project Management Fails

The Old Way Is Broken: Why Traditional Project Management Fails

The year was 2013, and the United States government had just launched Healthcare.gov, a website that was supposed to be the digital gateway to the Affordable Care Act. The project had a budget of $840 million. It had been in development for over two years. It had involved hundreds of contractors and thousands of meetings. And on the day it launched, it collapsed under the weight of its own ambition, serving fewer than 1% of its intended users and crashing repeatedly for weeks afterward.

If you were one of the millions of Americans trying to sign up for health insurance that October, you probably remember the frustration firsthand. The page would load. You'd click on something. You'd wait. And then, more often than not, you'd get an error message. Sometimes the website would just freeze. Sometimes it would tell you that you had successfully completed a step you hadn't actually completed. It was, by any reasonable measure, a spectacular failure.

But here's what makes Healthcare.gov truly interesting for our story: it wasn't a failure of effort. Nobody sat around twiddling their thumbs while millions of dollars burned. The contractors worked long hours. The government officials held countless meetings. Progress reports were filed. Milestones were tracked. The project followed every rule of traditional project management that organizations had been using for decades.

And it still failed. Spectacularly. Publicly. Expensively.

This isn't an isolated incident. Healthcare.gov belongs to a long and distinguished list of project management disasters—projects that followed the rules, respected the methods, and still produced results ranging from disappointing to catastrophic. Understanding why this happens is the first step toward understanding why the world needed something different. And that something different is what this book is about.

---

What Traditional Project Management Actually Looks Like

Before we can understand why the old ways fail, we need to understand what those old ways actually are. The dominant approach to managing projects for most of the twentieth century—and indeed well into the twenty-first—is called the waterfall methodology.

The waterfall model gets its name from the way water cascades down a series of steps, moving irrevocably from one level to the next. In project management terms, this means organizing work into distinct, sequential phases, where each phase must be completed before the next one begins.

The typical waterfall project looks something like this:

Phase 1: Requirements Gathering — You figure out exactly what needs to be built. You write lengthy documents describing every feature, every screen, every button. You interview stakeholders, conduct research, and produce a comprehensive specification.

Phase 2: Design — You create detailed designs based on those requirements. Architects draw blueprints. Designers create mockups. Engineers plan the technical architecture. Everything is planned down to the last detail.

Phase 3: Implementation — The actual building begins. Developers write code. Workers construct buildings. Teams execute the plan created in the previous phases.

Phase 4: Testing — Once everything is built, you check it. You verify that what was produced matches what was specified. You look for bugs, defects, and deviations from the plan.

Phase 5: Deployment — You release the product. It goes live. Customers start using it.

Phase 6: Maintenance — You fix problems that arise, make small improvements, and keep the lights on.

The fundamental assumption underlying waterfall is that you can know, at the beginning of a project, what you need to build at the end. You gather requirements upfront, design everything in advance, and then execute that plan without significant changes. The further you move through the phases, the harder and more expensive it becomes to go back and change something.

```mermaid graph LR A[Requirements] --> B[Design] B --> C[Implementation] C --> D[Testing] D --> E[Deployment] E --> F[Maintenance]

style A fill:#e1f5fe style B fill:#e1f5fe style C fill:#e1f5fe style D fill:#e1f5fe style E fill:#e1f5fe style F fill:#e1f5fe ```

This approach made sense when the world moved more slowly. When you were building a bridge in the 1950s, you needed to know what kind of bridge you were building before you started pouring concrete. You couldn't change the design halfway through construction. The materials were expensive. The timelines were long. And once the bridge was up, it needed to stay up.

Software, it turns out, is nothing like a bridge.

---

The Promise: Order, Control, and Predictability

Traditional project management sells a compelling vision. It promises that with enough planning, enough documentation, and enough oversight, you can know in advance exactly what a project will cost, how long it will take, and what it will produce. You can hold stakeholders' feet to the fire by pointing to the signed specification. You can track progress with neat charts showing percentage completion. You can assign blame when things go wrong by checking who deviated from the plan.

For organizations that have to report to boards, satisfy auditors, and answer to shareholders, this kind of predictability is enormously appealing. The waterfall model gives them something tangible to point to: a requirements document, a project plan, a Gantt chart. It makes abstract work feel concrete and manageable.

And for a long time, this approach worked well enough. When the pace of change was slower, when competitors were more local, and when customers had fewer alternatives, you could spend two years building a product and release it knowing that the world wouldn't have changed too much in the interim. You could plan for the future because the future looked a lot like the present.

The trouble is, that world doesn't exist anymore.

---

The Reality: When the Waterfall Runs Dry

Let's go back to Healthcare.gov. Why did such a well-funded, well-staffed project fail so miserably?

The official post-mortems identified many contributing factors: inadequate load testing, last-minute changes to requirements, poor coordination between contractors, and a launch date driven by political pressure rather than technical readiness. But at a deeper level, Healthcare.gov suffered from a problem endemic to waterfall projects: the people building the system had no real understanding of how it would actually be used until users tried to use it.

By the time the website launched, millions of Americans were suddenly trying to access it simultaneously. They came with different browsers, different internet speeds, different levels of technical sophistication. They asked questions the designers hadn't anticipated. They encountered edge cases nobody had planned for. They did things with the website that no requirements document had described, because real humans rarely behave the way specifications assume they will.

The waterfall model has no good mechanism for handling this reality. In waterfall, you gather requirements at the beginning, build according to those requirements, and test to verify compliance with those requirements. But what if the requirements were wrong? What if the world changed between when you wrote them and when you finished building? What if users want something different than what you thought they wanted?

In the waterfall model, the answer is expensive and painful: you wait for the next release cycle, if there is one.

Healthcare.gov wasn't alone. In 2014, the United Kingdom's National Health Service abandoned a £10 billion IT program that had been underway for over a decade. The program was supposed to modernize the NHS's computer systems, allowing doctors and nurses across the country to access patient records electronically. Instead, it produced delays,