Most projects don’t fail with a bang. Contrary to popular belief, projects don’t crash on launch day or trigger some dramatic escalation. More often, they slide into failure quietly, signed off as complete, technically delivered, procedurally successful. The system goes live;
The roadmap is closed out;
The team moves on. The system goes live; The roadmap is closed out; The team moves on. And then people start adjusting. Users find workarounds. Operations inherit edge cases. Performance is “acceptable” until it isn’t. Known issues are re-labelled as future improvements and quietly pushed out of view. Delivered on time.
Delivered on budget.
Delivered — technically. Delivered on time. Delivered on budget. Delivered — technically. I’ve spent a large part of my career inside projects like this. Digital platforms, enterprise systems, operational technology — often tied to real-world environments where downtime, failure, or poor adoption actually mattered. Not theory. Not sandbox environments. Live systems with consequences. And the longer I’ve done this, the clearer one thing has become: “On time and on budget” isn’t success. It’s the minimum standard we’ve normalised. “On time and on budget” isn’t success. It’s the minimum standard we’ve normalised. “On time and on budget” isn’t success. It’s the minimum standard we’ve normalised. The moment it becomes the goal, the project stops being about outcomes and starts being about protection. The moment it becomes the goal, the project stops being about outcomes and starts being about protection. Time and cost are appealing because they’re neat. They fit cleanly into reports. They give executives something solid to point at when the work underneath is messy, abstract, and hard to see. They’re also a convenient substitute for harder conversations. You can hit every milestone and still deliver something that struggles the moment real users touch it. Something that technically meets requirements but ignores how people actually operate. Something that passed testing but buckles under real load. Something that locks in decisions everyone quietly knows will be a problem later. None of that shows up in a schedule. Once dates become sacred, behaviour shifts. Decisions get delayed because changing course would mean rework. Known problems are documented rather than resolved. Technical compromises are justified as temporary, even when everyone knows they won’t be. Progress looks good on paper. Velocity looks healthy. Dashboards stay green. But that sense of control is often cosmetic. Instead of asking whether the solution still makes sense, teams start asking whether it still fits the plan. Instead of challenging assumptions, they defend them. Instead of surfacing uncomfortable truths, they manage the story. That’s how projects drift. Not off schedule — off purpose. That’s how projects drift. Not off schedule — off purpose. Modern delivery environments are especially good at creating the illusion of completion. Code ships. Features are toggled on. Release notes go out. Everyone moves to the next thing. Meanwhile, adoption stalls. Support tickets climb. Performance tuning gets deferred. Integration pain is handed to operations. Ownership quietly evaporates. The project is “done”.The product very clearly isn’t. And once the delivery team has rolled off, those problems don’t disappear — they settle in. The best projects I’ve worked on were rarely the cleanest. They changed direction when reality shifted. They revisited decisions that no longer held up. They acknowledged trade-offs instead of pretending they didn’t exist. What they had wasn’t a perfect plan. It was clarity. Clear ownership.Clear decision rights.Clear accountability when choices had consequences. Time and budget still mattered — but they followed good decisions. They weren’t used to avoid them. So why does this definition of success persist? Because it’s safe. It allows organisations to declare victory without looking too closely. It allows leaders to rely on process rather than judgement. It allows complexity to hide behind delivery artefacts. When success is procedural, responsibility becomes optional. If the release happened, the project must have worked. Reality tends to disagree — just not immediately. Every serious project reaches a point where the plan stops matching reality. Requirements evolve. Dependencies collide. Assumptions break. Trade-offs become unavoidable. That’s the moment that actually decides the outcome. Not the sprint review.Not the milestone report.Not the final status update. But whether someone is willing to make a decision when the information is incomplete and the consequences are real. Most projects don’t fail because they’re too complex. They fail because no one wants to own the decision to change course. Over time, I’ve found it more useful to ask different questions. Does this still solve the problem we set out to address?
Who actually owns this once the project team is gone?
What compromises have we accepted, knowingly or otherwise?
Are we optimising for delivery, or for what happens afterwards?
If we stopped today, would this still be worth releasing? Does this still solve the problem we set out to address? Who actually owns this once the project team is gone? What compromises have we accepted, knowingly or otherwise? Are we optimising for delivery, or for what happens afterwards? If we stopped today, would this still be worth releasing? They’re not neat questions. They don’t fit into dashboards. They don’t always have comfortable answers. But they’re far more honest. I’ve never seen a genuinely successful project where time and cost were the obsession. I have seen plenty where clarity, accountability, and decision-making mattered far more — and where time and budget followed as a consequence, not a target. If your definition of success begins and ends with “on time and on budget,” you’re not delivering outcomes. You’re delivering closure. And systems have a habit of revealing the difference.

Dash

Why “On Time and On Budget” Is the Wrong Goal

About Author

Comments

TOPICS

THIS ARTICLE WAS FEATURED IN

Related Stories

How to Prepare a Winning Project for a Roadmap

The Code That Built a City: Solving the 33-Year Mystery Behind Google’s Málaga Hub

Architecture and Digital Platforms in Complex Organisations

Build/Buy/Partner

Digital Platforms or Digital Products | An Entrepreneur’s Dilemma

How Are Digital Talent Development Platforms Incentivizing Sports communities?

How to Prepare a Winning Project for a Roadmap

The Code That Built a City: Solving the 33-Year Mystery Behind Google’s Málaga Hub

Architecture and Digital Platforms in Complex Organisations

Build/Buy/Partner

Digital Platforms or Digital Products | An Entrepreneur’s Dilemma

How Are Digital Talent Development Platforms Incentivizing Sports communities?

Light-Mode

Classic

Newspaper

Minty

Dark-Mode

Neon Noir

Minty

HN StartUps