The strategy was approved in the spring. Funding is available. A vendor has been engaged, the kickoff happened and the workstreams are reporting progress.
Eighteen months later, the program is neither clearly failed nor meaningfully finished.
I have seen versions of this in telecom, SaaS and private equity. The problem is not always the strategy, nor is it usually a lack of capable people. More often, the program has no reliable way to connect the work being done with the outcome the organization expected.
Several warning signs tend to appear.
Every workstream is green, but the outcome is late
A stalled program can have an owner for every component and no one maintaining the integrated view.
The vendor delivers against its statement of work. Technology manages the platform. The business continues to operate. The PMO collects status and applies its standards. Each group may be able to show that its own commitments are on track.
But the promised outcome depends on what happens between those groups.
Does the vendor's solution match the operating process? Will the business be ready when the technology is released? Has a platform decision created a constraint for another initiative? Are training, data, support and cutover plans moving to the same date?
The executive sponsor should remain accountable for the business outcome. The program lead needs to connect the workstreams, maintain the integrated forecast and put unresolved trade-offs in front of that sponsor.
A status meeting in which every workstream is green while the program remains late is not evidence of good health. It usually means the workstreams are being assessed separately from the result they are supposed to produce.
Decisions are moving more slowly than the work
Teams can continue working while an important decision remains unresolved. That can make a program look productive even as it accumulates rework.
A question appears at the working level. It is discussed, deferred, escalated and eventually placed on an executive agenda. By the time it reaches the decision maker, much of the original context has been lost. The question arrives without clear options or a recommendation, so the executive reasonably asks for more analysis.
Meanwhile, the team has made assumptions so it can keep moving.
This is often described as executive indecision. In my experience, the executive has frequently been given a question that is not ready to decide.
A useful decision request identifies:
- what must be decided;
- why it is needed now;
- the available options and consequences;
- the program team's recommendation;
- who has the authority to decide.
Material decisions should also remain in a written record. I use a running log that records the decision, owner, date and rationale. If new evidence changes the decision, a new entry supersedes it without deleting the original.
That prevents the program from repeatedly reopening settled questions without acknowledging what changed.
Technical verification is being treated as business acceptance
A vendor completes its tests and the status report says the solution is done. Several weeks later, the business is still running the old process beside the new one.
The system may work as specified. That does not mean the organization is ready to depend on it.
Technical verification and business acceptance answer different questions:
- Does the solution perform according to the agreed requirements?
- Is the business prepared to operate with it and accept the result?
A vendor can provide evidence for the first question. The accountable business owner must answer the second.
That means acceptance cannot be left until the end of testing. The program should establish in advance who will sign, what evidence they require, how exceptions will be handled and who will own the process after handover.
Without that separation, “done” becomes a technical status rather than an operational reality.
Governance makes it easier to continue than to stop
Most program controls are designed to track progress toward the existing plan. Far fewer create a sensible way to question whether part of the plan still deserves to proceed.
On a recent engagement, a proof of concept exposed the cost and maintainability of a proposed reporting build. Delivering it would have required recreating proprietary reporting logic outside the source platform. It was technically possible, but the evidence no longer supported the original approach.
The vendor was already mobilized and the work appeared on the roadmap. Continuing would have been easier than reopening the decision.
Instead, we documented the findings, presented the available options and recommended redirecting the roadmap. The executives agreed.
That was not a failure of delivery. The proof of concept had done its job by revealing something the organization needed to know before committing further effort.
A healthy program needs an off-ramp. Governance should define not only what allows work to proceed, but also what evidence would justify pausing, changing or stopping it.
A short diagnostic for a stalled program
When a program is moving but its outcome is not, I start with four questions:
- Who is accountable for the business outcome, and who maintains the integrated view on that person's behalf?
- Which material decision has been open the longest, and what is preventing it from being decided?
- Who will accept the result, and what evidence will they use?
- What new evidence would cause the organization to change or stop the current plan?
Unclear answers do not necessarily mean the program needs a new methodology or more reporting. They usually point to a specific gap in ownership, decision flow, acceptance or governance.
Put that gap on the page first. The next decision is often easier to see from there.
Darryl Kwan is the founder and principal of Factum Partners. He leads technology and operating transformation from assessment through delivery.