How to Recover a Struggling Program: Governance, Innovation and AI

Turning a failing program around before the board loses confidence

How Governance, Innovation, and Applied AI combine to convert red programmes into on-time, on-budget delivery

GOVERNANCE Restore truth and decision rhythm

INNOVATION Redesign the operating model

APPLIED AI Shorten signal-to-decision time

CORE MESSAGE

Governance restores trust. Innovation removes structural drift. Applied AI helps keep the gap from reopening.

Executive snapshot

A practical recovery framework for leaders who need to restore control, credibility, and delivery performance - without confusing activity with progress.

60% -> <15% Schedule overrun Government infrastructure program	40% -> <10% Budget overrun Same recovery program
+35% On-time delivery Enterprise delivery portfolio	28% -> <8% Average delivery overrun Delivery COE implementation

Disclaimer : Practitioner-reported outcomes from programs personally governed; not controlled-study results or performance guarantees.

CORE PROPOSITION

Recover in sequence: establish the truth, stabilise governance, redesign the delivery model, then add AI where structured evidence can improve decisions.

Most programs do not fail in a single dramatic moment. They drift. A schedule slips by two weeks, then four. A vendor dependency turns into a standing agenda item. A steering committee starts asking the same question three months running: "when will this be back on track?" PMI's 2024 Pulse of the Profession reported an average project performance rate of 73.8%. The practical lesson is not that every underperforming program is beyond repair; many are suffering from governance failure rather than delivery impossibility.

Over 30+ years leading programs across Defense, Government, Telecom, and IT Services, I have taken on more than one program that arrived on my desk already red - behind schedule, over budget, and with a steering committee that had stopped trusting the status report. In every case, the fix was not a single silver bullet. It was three levers pulled together: structural governance discipline, deliberate innovation in how the delivery model works, and - more recently - applied AI as a decision-support layer. This article sets out that playbook, without naming specific clients, but with the actual numbers those three levers have produced.

What a failing program looks like from the inside

Before the playbook, it's worth being precise about the symptom set, because the diagnosis determines the treatment. In my experience, a program heading for recovery usually shows some combination of:

• Baseline drift - the schedule and budget on paper no longer reflect the schedule and budget in reality, and nobody can say exactly when the two diverged.

• Escalation lag - problems reach the steering committee weeks after site or vendor teams already knew about them.

• Change-request leakage - scope changes happen informally, without being priced, tracked, or approved, quietly eroding margin.

• Action rot - the same risks and action items appear on the RAID log meeting after meeting, unresolved.

• Trust erosion - the board starts asking for evidence instead of accepting status commentary, which is a sign governance credibility is already gone.

None of these are fixed by working harder inside the existing process. They are fixed by changing the process.

The three-lever recovery model

Lever 1: Governance - rebuilding the operating rhythm

PURPOSE

Rebuild an evidence-based operating rhythm so risk, ownership, and decisions move at the speed of the program.

Governance recovery starts with structure, not authority. A program manager who simply asks harder questions in the same weekly call does not fix drift; a program that redesigns how information flows, how risk is escalated, and how decisions get made does.

In practice, this has meant:

• Rebuilding governance cadence around evidence rather than narrative - RAG status backed by source data (burn rate, milestone completion, defect counts) rather than a manager's subjective read.

• Tightening RAID discipline - every risk and action has a named owner, a due date, and an escalation trigger; no item is allowed to sit unresolved past its threshold without automatically surfacing to the next level.

• Redesigning escalation pathways - site- and vendor-level problems reach decision-makers in days, not the following month's steering committee.

• Rebuilding executive reporting - the board sees a decision-ready pack instead of an activity summary.

A decision-ready pack is not a longer status report - it is a defined, standing set of components, refreshed every cycle:

• Schedule and cost variance - measured against the re-baselined plan, not the original one.

• Threshold breaches - risks and actions that have breached their escalation threshold, with owner and required decision.

• Change-control and commercial exposure - approved, pending, and disputed change requests.

• Project Health Analytics rating - where the AI layer described in Lever 3 is in place, a consolidated, evidence-linked read on programme health rather than a single manager's RAG call.

• Client-sentiment trend - again where Lever 3 is in place, because stakeholder confidence is itself a leading indicator, not just a byproduct of good delivery.

Even before an AI layer exists, the pack should be structured to receive those last two inputs - governance discipline defines the slots; Lever 3 fills them with continuously updated evidence rather than a quarterly survey.

PRACTITIONER OUTCOME

On a large government infrastructure programme, the governance rebuild reduced schedule overrun from 60% to under 15% and budget overrun from 40% to under 10% - without changing the underlying scope or delivery team. The lever was structure, not more resources.

On a separate enterprise delivery organisation where I built a Delivery Centre of Excellence from scratch over 18 months, the same governance discipline - standardised cadence, escalation pathways, and reporting - improved on-time delivery by 35%+ across the active portfolio, and reduced average delivery overrun from 28% to under 8%.

Lever 2: Innovation - redesigning the delivery model, not just monitoring it

PURPOSE

Remove the structural cause of drift by changing how work is planned, owned, sequenced, and commercially controlled.

Governance discipline stabilises a program. It does not, by itself, make the delivery model better. The second lever is innovation in how work gets planned, resourced, and commercially managed - changes to the operating model itself, independent of any tooling.

Examples from my own practice:

• Change-control redesign. Converting informal, unbilled scope changes into a disciplined change-request process - turning what was previously commercial leakage into monetised change requests. This alone drove 22% year-on-year account growth on an active INR 200+ Cr portfolio, without adding new logo revenue.

• Capability building over dependency. Mentoring delivery managers to self-sufficiency rather than routing every decision upward, which reduces the bottleneck that most commonly causes escalation lag in a stressed program.

Capability building deserves to be called out as a formal sub-step, not folded quietly into "innovation" as a nice-to-have. Once a program is stabilised under the new governance cadence, the redesigned operating model only holds if the people running it have the skills to run it without reverting to old habits under pressure. Skip this step and the same risks and actions that defined the original "action rot" symptom tend to reappear within a quarter or two - not because the process was wrong, but because nobody was capable of sustaining it once the recovery team moved on.

• Multi-vendor coordination models. On a fourteen-state, multi-vendor telecom infrastructure rollout, the innovation was a single point of commercial and schedule accountability across vendors who previously reported independently - closing the gaps where delay typically hides. That programme closed with zero penalty triggers.

• Compliance-led migration sequencing. On a government data-centre modernisation programme migrating 100+ legacy applications, sequencing the migration around Safe-to-Host (STH) compliance rather than technical convenience avoided rework that would otherwise have cascaded into schedule risk - and the transition to managed services delivered the programme at 22% lower client opex, with zero penalty.

None of this required new technology. It required rethinking where risk actually lived in the delivery model and redesigning around it.

Lever 3: Applied AI - compressing the distance between signal and decision

PURPOSE

Use AI as a decision-support layer that reduces operational noise and brings emerging risk to leaders sooner.

The first two levers close most of the gap. The third is newer, and it is where I believe governance is heading next: using AI not to replace governance judgement, but to shorten the time between a risk emerging and a decision-maker seeing evidence of it - and to remove the manual noise that keeps teams from getting to that evidence in the first place.

In a recovering program, a large share of delivery capacity is consumed by volume rather than by value: hundreds of tickets and issues that are really the same underlying problem reported five different ways, status updates that require someone to manually chase five teams, and risks that get discovered only after they have already become incidents. This is where applied AI has produced the most concrete, day-to-day impact in my practice:

• Ticket consolidation. Rather than a support or delivery team triaging every ticket individually, AI-assisted clustering groups duplicate or related tickets - the same root cause reported by different sites, vendors, or users - into a single consolidated issue. This removes a large share of the noise that otherwise buries a recovering program's operations team.

• Auto ticket closure. For well-understood, recurring issue patterns with a known fix, AI-assisted workflows can validate resolution and close the ticket automatically, freeing delivery teams to focus on issues that actually need judgement.

• Prediction and remediation. Rather than waiting for a threshold breach, predictive models flag budget burn, schedule slippage, or quality patterns trending toward a breach - with a suggested remediation path attached, so the escalation arrives with a decision option, not just a warning.

• Root-cause analysis (RCA) to prevent recurrence. AI-assisted RCA looks across historical incidents and issues to identify the small number of root causes generating the majority of recurring problems, so governance can fix the cause once instead of re-solving the same symptom every reporting cycle.

• Auto-escalation for project overruns. Instead of an overrun surfacing at the next scheduled steering committee, threshold-based auto-escalation pushes the signal to the right decision-maker the moment cost or schedule variance crosses a defined tolerance - collapsing weeks of discovery lag into days.

• Prediction of project success. Using historical patterns of similar programs, AI-assisted models can produce an early, evidence-based read on the probability a program lands on time and on budget - giving the steering committee a leading indicator instead of relying solely on lagging RAG status.

Trustworthy inputs, not just trustworthy intentions. None of the above works without a direct, explicit link back to Lever 1. The standardised RAID logs, defect counts, and burn-rate data that governance discipline produces are not just useful context for the AI layer - they are the mandatory training input for the clustering and prediction models described above. A model trained on inconsistent, informally kept logs will cluster the wrong tickets, predict the wrong breaches, and produce exactly the "confident noise" this article warns against. The sequence matters: governance produces the clean signal first; AI compresses the time it takes that signal to reach a decision-maker second. Reversing the order is the most common way AI-in-governance pilots fail.

Escalation should follow evidence, not narrative - including sentiment evidence. Auto-escalation triggers should not be limited to cost and schedule variance. Where client-sentiment analysis is in place, a sustained negative sentiment trend in stakeholder communication should trigger escalation in its own right, even when technical milestone status still reads green. Escalation lag is often not a delay in the numbers - it is a delay in someone admitting the numbers no longer reflect how the client actually feels about the programme. Sentiment divergence from the official narrative is itself a governance signal, and it should be wired into the same escalation pathway as a budget or schedule breach, not treated as a separate, softer conversation.

These issues can be addressed either way - through a paid platform or by developing a purpose-built in-house tool - and both routes have a place depending on the program's scale and data sensitivity. A Project Health Analytics capability, whether bought or built, converts scattered project signals - status commentary, RAID entries, stakeholder communication, and client feedback - into a consolidated, AI-assisted programme health rating with auto-escalation and early risk detection built in. A companion client-sentiment analysis layer reads stakeholder communication for signs of dissatisfaction well before they surface formally in a steering committee. The benefit either route delivers is the same: leadership gets something a status report alone cannot provide - a consolidated, evidence-linked view of where a program actually stands, refreshed continuously rather than once a reporting cycle. That continuous visibility is what allows decisions to be made while there is still time to act on them, and it is where the measurable improvement in both client sentiment and delivery productivity tends to come from.

The point of these tools is never to produce a score or an auto-closed ticket the board accepts on faith. It is to surface where the evidence disagrees with the narrative - a status report that says "green" against a sentiment signal, a burn-rate trend, or a recurring RCA pattern that says otherwise - so the governance conversation starts from evidence rather than assurance.

WHAT AI IS REALLY DOING

Applied AI's real value in governance is compression: turning a three-week discovery lag into a same-week signal, while freeing delivery capacity from repetitive triage for the judgement calls that actually move a program.

Disclaimer : I write about AI generally: this is practitioner-reported, from organisation experience, not a controlled study - the same caveat I would apply to any vendor case study. And it works only as well as the underlying data discipline the first two levers already established; AI layered onto ungoverned tickets, status reports, or RAID logs just produces confident noise faster, not fewer overruns.

A five-step recovery sequence

Distilled from the programmes above, the sequence that has worked consistently is:

1. Diagnose without blame. Establish the real baseline - actual schedule, actual spend, actual scope - separate from what the last status report claimed. Most recovery failures start with skipping this step and building a new plan on an unreliable base.

2. Stabilise the governance cadence first. Before optimising anything, get RAID discipline, escalation triggers, and reporting rhythm working reliably. A well-run cadence on an imperfect plan outperforms an ambitious plan run chaotically.

3. Redesign the operating model where risk actually lives - and build the capability to run it. Fix the specific structural gap - change control, vendor accountability, resourcing model - that caused the drift in the first place, not a generic process overhaul, and deliberately transfer the skills to sustain it to the people who will still be on the program after the recovery effort ends. A redesigned model with no one capable of running it reverts within a quarter.

4. Layer in AI-assisted evidence once the data is trustworthy. Only once governance produces clean, structured signals - the same RAID, defect, and burn-rate data standardised in Step 2 - does an AI layer add value; added earlier, it just accelerates bad data.

5. Institutionalise through a Delivery Centre of Excellence; do not just recover the one program. Convert the recovery into standard operating discipline by standing up, or feeding into, a formal COE. The governance cadence, capability-building model, and decision-ready pack format from this recovery become the default for every program in the portfolio, not a one-off fix. This is what turns a single recovery into sustained, portfolio-wide improvement, rather than a repeatable rescue exercise.

What these numbers are - and are not

In the interest of the same evidence discipline I apply to AI claims generally: these are outcomes from programs I personally governed, not a controlled experiment, and they should not be read as a guarantee that the same levers will produce identical percentages on a different program with different constraints. What I would defend as generalisable is the sequence - diagnose, stabilise governance, redesign the model, then layer in AI - because it addresses causes in the order they actually compound, rather than treating symptoms in isolation.

"The board does not need optimism. It needs actionable evidence."The board does nneed optimism. It needs actionable evidence."

Governance restores trust. Innovation removes the structural cause of drift. Applied AI keeps the gap from reopening.

Governance restores trust. Innovation removes the structural cause of drift. Applied AI keeps the gap from reopening.

A program in trouble rarely needs a more confident program manager. It needs a governance structure that surfaces the truth early, an operating model redesigned around where the risk actually sits, and - increasingly - an evidence layer that compresses the time between something going wrong and someone finding out. Together, that is what turns a red program back to green - and keeps it there.

Source

• Project Management Institute (2024). The Future of Project Work: Pulse of the Profession 2024. The report states an average project performance rate of 73.8% across respondents.

About the author

Arunava Chakravarty is an Independent Consultant and Strategic Advisor working across Program & Delivery Advisory, PMO/COE Design, Program Recovery, and Governance Advisory. He brings 30+ years of enterprise leadership experience across Defense, Government, Telecom, and IT Services.