The real cost of not canceling anything

Every roadmap I’ve reviewed was a faithful record of what a company decided to start. Almost none records what it decided to stop.

That absence is one of the most expensive habits in enterprise technology, and the CIO is usually the person who pays for it.

Starting a project is easy to celebrate. Someone gets a launch, a budget line, a moment in front of the executive team. Stopping one looks like conceding the original bet was wrong, so the project stays on the list, half-funded and steadily draining the people assigned to it. Nothing comes off, because taking something off requires a decision no one above the CIO wants to own.

I sat in on a quarterly planning meeting with a mid-market client last year. Fourteen initiatives were on the board. Partway through, someone proposed a fifteenth, and three heads nodded before the sentence was finished. The CIO asked the only question that mattered. If this goes on, what comes off? No one answered. Everyone knew the honest answer, and no one at the table had the authority or the appetite to retire something a colleague had sponsored, so the fifteenth was added with no change to headcount. Everyone in the room knew the math had just gotten worse.

That meeting was ordinary, which is exactly how roadmap inflation happens. One more initiative is approved, nothing is retired, and the organization gradually accepts a promise it no longer has the capacity to keep. The stopping problem lives in that exact moment, when adding is easy and subtracting has no owner.

What executives often underestimate is that a bloated roadmap does not fail all at once. A capable team can absorb it for a while. People stretch, priorities shift, and the good ones find a way to keep the important things moving. The cost stays hidden, which is exactly why it grows.

Then the bill comes due, and it comes due in a specific order.

Delivery slows first. Every project that should have stopped is still consuming people, attention, and budget, and the initiatives that matter most now compete with ones that no one has the nerve to cancel. Your best engineers split their focus across work that will never ship and work that has to ship. The team’s finite capacity is spread across an infinite list of work.

The executive team reads slow delivery as an IT performance problem, rarely connecting it to their own unwillingness to stop anything, and that slowdown erodes trust. The CIO takes the reputation hit for a call the business never made.

Eventually, the best people leave. Few strong engineers want to spend their careers maintaining projects that should have died two years ago. They can tell the difference between work that ships and work that exists to avoid an uncomfortable conversation. With the client I mentioned, the most senior engineer on the team resigned within six months. In his exit conversation, he was precise about why. He was tired of being busy with things that did not matter and being measured as though they did.

That is the true cost of not canceling: the slow loss of speed and credibility, and of the people who made delivery possible in the first place.

I want to be careful about where the blame goes, because the usual advice points it in the wrong direction. The CIO is told to prioritize better, as though sharper sequencing could fix what’s actually a missing decision. Prioritization assumes someone above the CIO is willing to name what the company will no longer do. When that choice has no owner, the CIO is left managing finite bandwidth against a list that only grows, and no amount of sequencing discipline fixes a list that is structurally allowed to expand forever.

The strongest technology organizations I have seen treat stopping as a real executive decision, with a named owner and on the record. They place the candidates for cancellation on the same slide as the candidates for funding and ask which sponsor will retire their project so that a higher-priority one can move forward. The discomfort is evidence that the right conversation is finally happening. It forces the decision into the open and puts the ownership where it belongs: with the people above the CIO.

A technology leader can’t manufacture capacity, but can refuse to let the roadmap pretend capacity is infinite. Bring the kill list to the planning meeting, and make stopping someone's job, on the record, with a name attached.

Years ago, a coach taught me that only two things are worth a leader's time: increasing revenue and decreasing costs. Canceling a project that has stopped earning its place is the second one, and it deserves the same regard we give to launching something new. We celebrate launching projects and tolerate keeping the wrong ones alive, even though deciding what not to do is every bit as important as deciding what to start. 

‍

Scott Smeester is the founder of CIO Mastermind, which helps CIOs and senior technology leaders with executive alignment, decision-making, and turning technology investment into business value. He started his first technology company in 1995 and has spent the decades since building companies and translating between the executive suite and the IT organization.