When to Short-Circuit a Failing Platform Project (and Explain It)

Why a Failing Platform Project Keeps Going

A failing platform project rarely fails loudly. It does not collapse on a single dramatic day. Instead, it drifts. A milestone slips here, a scope change lands there, and a vendor workaround quietly becomes permanent. Because each step looks small, nobody calls the project a failure. Yet the risk keeps compounding underneath.

Several forces keep a struggling project alive. First, sunk cost weighs heavily — leaders who have already spent two million dollars hesitate to “waste” it by stopping. Second, optimism takes over, because the next sprint always promises to fix things. Third, politics intrudes, since the executive who championed the platform does not want to be wrong in public.

Researchers call this pattern escalation of commitment, and they have studied it for decades. The classic Harvard Business Review analysis of why managers struggle to pull the plug on a troubled project still describes most stalled initiatives accurately. As a result, the decision to stop almost never happens on its own. Someone has to force it — and that someone is usually the CIO.

The Warning Signs of a Failing Platform Project

So how do you tell an ordinarily hard project from a failing platform project? The difference shows up in patterns, not single events. Specifically, watch for these five signals.

• The platform fights the use case. Your team spends more time working around the product than configuring it. Every requirement seems to need a custom extension.
• Timelines reset without new scope. The deadline moves twice, yet the requirements have not grown. That gap is unmanaged risk surfacing.
• The vendor’s answer is always the next module. Each problem meets another license or add-on, rather than a fix to what you already bought.
• Security or compliance keeps blocking go-live. For an AI or enterprise search project especially, an unsolved permission model is not a detail. It is a stop signal.
• Nobody can state the business outcome anymore. The team talks about features and tickets, not the productivity or revenue result the project was meant to deliver.

One signal alone is normal on any complex initiative. However, three or more at once means the project’s risk is now growing faster than its progress. That is the moment to act, not the moment to wait for the next status report.

Short-Circuit, Pivot, or Push Through: A Decision Framework

Stopping is not the only alternative to pushing forward. In practice, a troubled initiative usually offers three honest paths, and a CIO should name all three out loud.

1. Push through. Choose this only when the platform itself is sound and the problem is execution — a fixable team, process, or scope issue. Here the fix is management attention, not a new platform.
2. Pivot. Keep the parts that work and change the parts that do not. You might re-scope to a smaller first release, swap one component, or change the integration approach. Pivoting preserves real investment while cutting the risk.
3. Short-circuit. Stop the current path deliberately, before more budget converts into more risk. Short-circuiting is not abandonment. Instead, it ends one approach so a better one can begin.

To choose between them, ask a single question. If we started today, knowing what we now know, would we buy this platform again? When the honest answer is no, you are no longer pushing through a hard project — you are funding a failing platform project. In that case, pivot or short-circuit instead.

How Platform Risk Compounds When You Wait

Delay is never neutral. Every month a troubled project continues, three kinds of risk grow at the same time.

• Financial risk. More budget gets committed, and more of it becomes unrecoverable. Studies of large IT projects consistently find they overrun budgets and underdeliver value the longer they run.
• Technical risk. Temporary workarounds harden into permanent architecture. The longer they live, the more expensive they become to unwind.
• Organizational risk. Your best engineers burn out on work they privately know is failing. Meanwhile, your credibility with the board erodes with every quiet slip.

The evidence here is well documented. McKinsey’s research on large-scale IT projects shows how badly they tend to drift. In the same way, the hidden costs of a failed implementation rarely appear on the original budget line.

This is the core argument for acting early. The cost of stopping is visible and finite today. By contrast, the cost of waiting is invisible and compounding. Therefore, a decision delayed is not a decision avoided. It is simply a more expensive version of the same decision.

How to Talk to Your Board About Stopping the Project

The decision is only half the job. How you communicate the end of a failing platform project decides whether the board sees disciplined leadership or a failure to manage. Use these five moves.

1. Lead with the forward decision, not the autopsy. Open with the smarter path, not a list of what went wrong. After all, the board funds the future, not the past.
2. Quantify the risk of continuing. Show the projected cost and exposure of pushing through, side by side with the cost of stopping. Make the expensive option the visible one.
3. Bring the alternative fully formed. Never present a stop without a next step. Instead, arrive with the pivot plan or replacement approach already scoped and costed.
4. Own it without drama. State plainly what the team learned and what changed. Confidence, rather than apology, is what reassures a board.
5. Protect the team. Frame it as a platform-and-fit decision, not individual blame. You want your best people energized for the next path, not defensive about the last one.

Above all, give the board a recommendation, not a dilemma. Directors respect a CIO who has already done the analysis and is asking them to confirm a clear call. In short, you are not delivering bad news. You are demonstrating control.

Reframe It: Stopping a Failing Platform Project Is Risk Management

The word “failure” does the most damage here, so reframe it deliberately. Choosing to stop a failing platform project is not a project failure. Rather, it is risk management working exactly as intended.

Consider how every other part of the enterprise behaves. A portfolio manager exits a losing position. An insurer caps its exposure. A board retires an underperforming product line. None of that counts as failure — all of it counts as discipline. IT governance deserves the same standard. Indeed, project governance guidance from bodies such as the Project Management Institute treats a deliberate, evidence-based stop as a marker of mature oversight.

The real failure looks different. It is letting a doomed project run quietly for another year because nobody wanted an uncomfortable conversation. By contrast, the CIO who short-circuits early protects budget, talent, and board credibility all at once.

How Sengo Helps CIOs Make the Call

Making this call is far easier with a neutral party in the room. Sengo gives CIOs an honest, vendor-neutral read on whether a struggling platform project should push through, pivot, or stop.

We are an official implementation partner of the major CMS, DXP, and AI-enablement platforms — yet we never sell one as a default answer. That independence is the point. Because of it, we can assess your platform on its merits, model the risk of each path, and help you evaluate your platform stack without a vendor’s thumb on the scale. For AI and enterprise search work specifically, our Coveo expertise means we know precisely where these projects tend to stall.

We have guided enterprises such as iA Financial Group, Cirque du Soleil, and LCI Education through high-stakes platform decisions, in both French and English. So if a failing platform project is keeping you up at night, remember the costliest move is to wait. Let’s review it together and find the shortest path back to solid ground.