Not subscribed? Sign up to get it in your inbox every week.
⚙ Hi {{first_name_tally|Operator}},
October 1, 2013. Healthcare.gov goes live. Four million people try to log in. Six succeed.
Not six thousand. Six people. Out of four million attempts. A 99.99985% failure rate on the most scrutinized government technology project in a decade.
The post-mortem blamed "poor project management." The GAO cited "inadequate technical assessment." Consultants pointed to "insufficient coordination." All technically true. All missing the point.
The real failure happened eighteen months earlier, in a conference room where nobody had the guts to say: "We will not integrate real-time data from 36 state systems, the IRS, DHS, and hundreds of insurance providers by October 2013."
Every stakeholder got a yes. Every feature request got approved. Every political demand got accommodated. The project manager inherited a scope that grew like a tumor, authority that didn't exist, and a deadline set by Congress.
When the site crashed, they blamed the project manager.
This pattern repeats everywhere. Denver Airport: 2,100 design changes, 16 months late, $560 million over. Sydney Opera House: 14x over budget, no defined scope. The FBI's Virtual Case File: $170 million, zero working software, 400+ change requests.
Every billion dollars in project spend bleeds $97 million to scope creep. Forty-nine percent of projects experience it.
But we keep calling this a planning problem.
It's not. It's a spine problem.
- Rameel
PRESENTED BY THE BOTTLENECK
Stop Being the Team’s Firefighter. Start Acting Like Their Future COO
Your calendar is full. Your brain is fried. And somehow, your work still flies under the radar.
Here’s the truth: You don’t get promoted for working more. You get promoted for fixing what’s broken.
Bottleneck Breakers is the system I used to:
– Trim 20 hours of busywork a week
– Fix the stuff that actually moved the needle
– And earn a COO title before I turned 30
🧠 No video lectures. Just drop-in systems that make you undeniable when promotion season hits.
Why Systems Expand by Default (And Why That's Your Problem)
Scope expansion isn't an anomaly requiring explanation. It's the default state of every system.
The Second Law of Thermodynamics doesn't care about your roadmap. It states that isolated systems naturally evolve from order to disorder—entropy increases over time. Without active energy input to maintain structure, things fall apart.
Organizations are open systems (they exchange resources with their environment), which means they can temporarily resist entropy. But "temporarily" and "resist" are the operative words. The natural state is expansion, accumulation, and eventual collapse. Constraint requires continuous force. Growth is the path of least resistance.
This isn't philosophical. It's measurable in three studies I read over the weekend (I'm a dork):
Parkinson's Law (1955): British Admiralty study showed that between 1914 and 1928, Navy ships dropped by two-thirds and personnel by one-third, yet dockyard officials and clerks increased 5-6% annually. The number of officials and the quantity of work "are not related to each other." Bureaucracies grow independent of workload because: (1) managers multiply subordinates, not rivals, and (2) officials make work for each other.
Peter Klimek's 2009 study in Journal of Statistical Mechanics found that decision-making groups have a critical "coefficient of inefficiency" around 20 members—beyond that, effectiveness collapses. Administrative bodies modeled as open systems show that without constraints, bureaucracies grow while per-person output drops.
Brooks' Law (1975): "Adding manpower to a late software project makes it later." Why? Because if you have n workers, you have (n² - n) / 2 communication paths. A team of 10 has 45 communication channels. A team of 50 has 1,225. The coordination cost grows combinatorially while productivity per person decreases.
The pattern is universal: without explicit boundaries, systems consume available resources, generate internal complexity, and collapse under coordination costs. Scope creep isn't a bug. It's thermodynamics.
The Political Reality: Why Your Project Manager Can't Save You
Here's what operators hate acknowledging: project managers cannot control scope. They don't have the organizational authority. This isn't about competence—it's structural.
A 2019 Northumbria University study of 70 project managers in oil and gas construction analyzed 201 historical projects and found that project managers' inability to say "no" was a primary driver of scope creep. But let's be precise. The study doesn't say PMs were too weak. It says they lacked the authority to refuse.
PMI research confirms: "When PMs are expected to produce change through projects, they often lack the authority needed to 'make it happen.'" When project managers try to control scope, "they assume the responsibility of the project owner" without corresponding power.
Here's what this looks like operationally:
Healthcare.gov, 2013: One month before launch, the White House mandated user registration before browsing—a major architectural change. Project managers raised concerns about timeline. Concerns were overruled. Multiple contractors, each reporting to different stakeholders, made decisions without coordinating. The project manager at CGI Federal had nominal authority but no actual power to say "that change violates our integration architecture."
The GAO found: "Constant and abrupt policy changes contributed toward a high level of uncertainty, which significantly affected project direction and ability to plan effectively."
Translation: political pressure created continuous scope expansion, project managers couldn't refuse, and when it failed they got blamed.
Chaco Canyon Consulting research documents "scopemonging"—intentional political manipulation of project scope. One political actor expands scope to attack a rival. Troubled projects expand scope to acquire healthier sibling projects, hiding problems. In public sector work with many stakeholders, "each will have influence on project scope and funding decisions," creating a tragedy of the commons where everyone adds priorities and nobody cuts.
Project managers are politicians negotiating with stakeholders they can't refuse. They inherit responsibility without authority. When leaders don't establish and defend boundaries, the project manager becomes the organizational punching bag—accountable for failures caused by leaders who lacked the spine to say no.
Scope creep happens because saying "no" to powerful stakeholders has social and political costs that project managers cannot absorb.
Only executives can. And most won't.
The Leaders Who Had Spine
The difference between project success and catastrophe isn't better Gantt charts. It's leaders willing to defend boundaries against stakeholder pressure.
Steve Jobs, Apple (1997): Product line from 350 to 10. A 97% cut. The company was weeks from bankruptcy. Jobs didn't optimize. He amputated.
At the 1997 WWDC, Jobs told teams: "I know some of you spent a lot of time working on stuff that we put a bullet in the head of. I apologize. But Apple suffered for several years from lousy engineering management."
His philosophy: "People think focus means saying yes to the thing you've got to focus on. But that's not what it means at all. It means saying no to the hundred other good ideas. I'm actually as proud of the things we haven't done as the things I have done. Innovation is saying 'no' to 1,000 things."
When advising Nike CEO Mark Parker, Jobs said: "Nike makes some of the best products in the world. But you also make a lot of crap. Just get rid of the crappy stuff and focus on the good stuff."
The outcome: Apple transformed from near-bankruptcy to one of the most valuable companies in history.
Jobs emphasized that saying no "pisses people off." He did it anyway. That's the spine part.
The contrasting failures:
Denver Airport leadership couldn't refuse United's 2,100 design changes → 16 months late, $4.8 billion total cost.
Healthcare.gov leadership couldn't control politically-driven scope expansion → 99% failure rate on launch, $2.1 billion spent.
Sydney Opera House leadership allowed unlimited quality goals without boundaries → 14x over budget, 10 years late.
In each case, technical teams were competent. Leadership spine was absent.
What This Means Monday Morning
Scope creep isn't a project management failure. It's a leadership boundary failure.
The next time someone pitches adding a feature, expanding a timeline, or looping in another team, your job isn't to optimize how you say yes. It's to have the spine to say: "That's not what this project is."
Three moves:
1. Define exclusions before inclusions.
Before your next project kickoff, spend 2x as long defining what you won't do as what you will. Get sign-off on exclusions. Make them visible. Revisit them weekly.
When someone asks to add scope, point to the exclusion list. Make them justify why this violates the boundary you agreed to protect.
2. Shield your project manager.
Your PM can't enforce boundaries without your authority. When stakeholders pressure for scope expansion, handle it yourself. Don't delegate boundary negotiations.
If United Airlines demands 2,100 design changes, you—not your PM—tell them no. If the White House wants architectural changes one month before launch, you—not your PM—push back or adjust the timeline.
Your PM can manage the project. Only you can defend it.
3. Model saying no.
Jobs didn't hide the 350→10 cut. He announced it at WWDC and told teams, "I apologize, I feel your pain."
Bezos publicly talks about his three-decisions-per-day rule.
When you visibly say no to attractive opportunities, you give your team permission to do the same. When you only say yes, they learn that boundaries don't really exist.
The uncomfortable truth: saying no pisses people off. You'll disappoint stakeholders. You'll frustrate ambitious team members. You'll leave money on the table.
You'll also ship on time, stay on budget, and avoid becoming the next Healthcare.gov case study.
The $97 million question isn't whether you can ship on time. It's whether you have the spine to tell your biggest stakeholder: "That's not what this project is."
Most leaders won't. That's why most projects fail.
