I left corporate delivery roles after a program that hit every number on the sheet. Budget, schedule, scope, the steering committee signed off, everyone shook hands. Six weeks later I heard the same team was quietly rebuilding half of what we'd just shipped, because the thing that got approved wasn't the thing that actually worked on the floor. Nobody had lied in the status report. They'd just stopped writing down the parts that didn't fit the format.
That's the version of failure nobody puts in a case study. A program can close green and still leave an organization worse positioned than before it started, because the people who knew where the seams were got trained, over years, to stop mentioning them.
Green on paper, wrong underneath
PMI's 2025 Pulse of the Profession put a number on this that matched what I'd been watching for two decades: organizations waste an average of 11.4 cents of every project dollar on poor performance, close to $2 trillion a year globally. The gap isn't mostly incompetence. It's programs that technically close while the underlying operation absorbs a cost nobody billed for.
The same report found something sharper underneath that number. Projects led by people with strong business acumen, not just schedule discipline, fail 8% of the time versus 11% for everyone else. That's a 27% relative difference, and high performers waste 28 times less money than low performers doing ostensibly the same job. The delta isn't process maturity. It's whether the person running the program is allowed to say the plan is wrong before the plan finishes failing.
The pattern across three employers
I ran delivery at Caja Robotics on large-scale fulfillment rollouts, then BriefCam on multi-year enterprise and government implementations, then HTS on vehicle-recognition systems. Different industries, different clients, same shape of problem showing up on a schedule. Somewhere around month four of a troubled program, a report internally nicknamed "the gremlin list" would start circulating, the exceptions nobody had assigned an owner to. It never had more than nine or ten lines. It also never got shorter on its own.
What I kept noticing wasn't that the hardware was broken or the vendor was late. It was that the org chart had a slot for someone whose whole job was protecting the delivery date, and no slot for someone whose job was saying the date was fiction. Employed inside the company, I could raise that. I couldn't be that person, because my paycheck depended on the date holding.
So I left. Not out of frustration with any single program. Out of running the same diagnosis often enough that staying inside would have meant continuing to write reports I already knew were half true.
What actually changes when the fix comes from outside
- An outside program lead has no promotion riding on the current plan surviving contact with reality.
- They can name the gremlin list in the steering meeting instead of the hallway.
- Because they weren't in the room when the original plan got approved, they don't need it to have been right.
- Their contract ends. That alone changes what people are willing to tell them in week two.
None of that requires more talent than the internal team already has. It requires someone whose job doesn't depend on the current story being true.
Signs a program needs an outside read, not another internal update
- The status report has looked the same for three cycles running, even though the underlying work clearly hasn't.
- There's a known list of open exceptions that nobody owns by name.
- The person closest to the problem has stopped bringing it up in the meeting where it would matter.
- Every fix proposed keeps the original deadline intact, whether or not that deadline still makes sense.
- Leadership already suspects the plan is wrong and is waiting for permission to say so out loud.
Tell me where you're stuck
If a program on your desk looks fine on the report and wrong on the floor, that gap is exactly what I get called in to close.
Tell me where you're stuck