惯性聚合 高效追踪和阅读你感兴趣的博客、新闻、科技资讯
阅读原文 在惯性聚合中打开

推荐订阅源

L
LangChain Blog
阮一峰的网络日志
阮一峰的网络日志
WordPress大学
WordPress大学
博客园 - 司徒正美
罗磊的独立博客
D
Docker
Last Week in AI
Last Week in AI
爱范儿
爱范儿
M
MIT News - Artificial intelligence
V
V2EX
Google DeepMind News
Google DeepMind News
小众软件
小众软件
Apple Machine Learning Research
Apple Machine Learning Research
Microsoft Security Blog
Microsoft Security Blog
T
Tailwind CSS Blog
MyScale Blog
MyScale Blog
V
Visual Studio Blog
博客园 - 叶小钗
B
Blog RSS Feed
A
About on SuperTechFans
F
Fortinet All Blogs
T
The Blog of Author Tim Ferriss
Martin Fowler
Martin Fowler
P
Proofpoint News Feed

DEV Community

Authentication Security Deep Dive: From Brute Force to Salted Hashing (With Java Examples) Why AI Systems Don’t Fail — They Drift Spilling beans for how i learn for exam😁"Reinforcement Learning Cheat Sheet" I Replaced Chrome with Safari for AI Browser Automation. Here's What Broke (and What Finally Worked) How Python Borrows Other People's Work The $40 Architecture: Processing 1 Billion API Requests with 99.99% Uptime Vibe Coding: A Workflow Guide (From Zero to SaaS) Most webhook security guides protect the wrong side. The scary part is delivery. Headless CMS for TanStack Start: Build a Blog with Cosmic EU Age Verification App "Hacked in 2 Minutes" — What Actually Happened Comfy Cloud’s delete function does not actually remove files Running AI Models on GPU Cloud Servers: A Beginner Guide Event-driven media intelligence with AWS Step Functions and Bedrock I scored 500 AI prompts across 8 quality dimensions — here's what broke How to Call Google Gemini API from Next.js (Free Tier, No Backend Needed) The Portal Protocol: Reclaiming Human Connection in the Age of AI How to Fix Your Team's Scattered Knowledge Problem With a Self-Hosted Forum Intro to tc Cloud Functors: A Graph-First Mental Model for the Modern Cloud Designing Multi-Tenant Backends With Both Ownership and Team Access I Built a Neumorphic CSS Library with 77+ Components — Here's What I Learned PostgreSQL Performance Optimization: Why Connection Pooling Is Critical at Scale Cómo construí un SaaS multi-rubro para gestionar expensas en Argentina con FastAPI + Vue 3 🚀 I Built an Ethical Hacking Scanner Tool – Open Source Project I Replaced /usage and /context in Claude Code With a Single Statusline A Pythonic Way to Handle Emails (IMAP/SMTP) with Auto-Discovery and AI-Ready Design I Collected 8.9 Million Polymarket Price Points — Here's What I Found About How Markets Really Move EcoTrack AI — Carbon Footprint Tracker & Dashboard Everyone's Using AI. No One Agrees How. 5 self-hosted ebook managers worth trying in 2026 Building Your First AI Agent with LangChain: From Chatbot to Autonomous Assistant
How to Audit a Program in Trouble
Asif Sheraz · 2026-06-18 · via DEV Community

The Questions Every PMO Should Ask Before Fixing Anything

Most troubled programs don't fail because people stop working.

They fail because leadership loses visibility.

Status reports stay green while milestones slip. Teams stay busy while delivery slows. Meetings continue while decisions stall. Everyone can feel something is wrong, but nobody can clearly explain what.

Over the years, I've been asked to step into programs across healthcare, government, higher education, and enterprise environments when delivery confidence had already begun to erode.

The first mistake most organizations make is jumping straight to solutions.

New governance. New tools. New reporting. New consultants.

Before you fix anything, you need to understand what is actually broken.

The goal of an audit is not to assign blame. The goal is to establish reality.

Question 1: What Problem Is This Program Actually Solving?

It sounds obvious. Usually it isn't.

Ask ten stakeholders why the program exists. If you get ten different answers, you've found a major risk.

Ask:

What business outcome is this program supposed to achieve?
How will leadership know it succeeded?
What metrics define success?
Has the objective changed since the program started?
Is everyone still solving the same problem?

When objectives drift, teams continue delivering work while moving further away from value.

That's how you end up with a program that's "complete" but doesn't matter.

Question 2: Who Actually Owns Decisions?

Many struggling programs have plenty of accountability and very little ownership.

There's a difference. Accountability is retrospective. Ownership is active. One explains what went wrong. The other prevents it.

Ask:

Who approves scope changes?
Who owns prioritization?
Who can remove organizational blockers?
What decisions are currently waiting for approval?
How long does a typical approval take?

Decision velocity is one of the fastest indicators of program health.

If decisions routinely take weeks, delivery eventually slows to match. Not because the team is slower. Because they're waiting.

Question 3: Can Anyone Explain the Critical Path?

Every major program has a handful of activities that determine success.

Most teams cannot clearly articulate them.

Ask:

What milestones absolutely cannot move?
Which dependencies threaten delivery?
What activities sit on the critical path?
What happens if a milestone slips 30 days?
Which risks would cause the greatest disruption?

If nobody can answer these confidently, the program may be operating without a true delivery strategy. You're probably watching activity instead of managing progress.

Question 4: Are Teams Delivering or Just Staying Busy?

Activity is not progress.

A full calendar is not health.

Ask:

What was completed in the last 30 days?
What business value was created?
What commitments were missed?
Why were they missed?
What is preventing faster execution?

When teams cannot connect effort to outcomes, productivity becomes an illusion. People are busy. Nothing moves.

Question 5: Is Governance Creating Clarity or Creating Noise?

Governance should accelerate decisions. Most organizations build governance structures that slow everything down.

Ask:

How many status reports are being produced?
Who actually reads them?
How many governance meetings exist?
Which meetings result in decisions?
Which reports influence action?

A common pattern in troubled programs: excessive reporting combined with declining visibility.

More documentation. Less clarity.

If your program produces five status reports and none of them drive a decision, you have a documentation problem, not a visibility problem.

The Hidden Question: What Risks Are People Avoiding?

This is often where the real audit begins.

Every troubled program has known risks. The question is whether people feel safe raising them.

Ask (in candid conversations, not in meetings):

What keeps team leaders awake at night?
What concerns are not appearing in status reports?
What assumptions are being made?
What dependencies are outside our control?
If the program failed tomorrow, what would likely be the cause?

The most valuable information rarely appears on a RAID log first.

It emerges during honest conversations, usually after hours, usually when someone finally feels safe enough to say what they actually think.

The Gap That Matters: What Does Leadership Actually Believe?

Ask leadership one set of questions. Ask delivery teams the same questions.

Leadership view:

Are we on schedule?
Are we on budget?
Are major risks under control?

Delivery team view:

Same questions.

The larger the gap between those answers, the greater the need for intervention.

Small gaps (leadership thinks 90%, team thinks 85%) are normal and manageable.

Large gaps (leadership thinks 90%, team thinks 60%) mean you have a communication problem that will become a delivery problem.

Is the Program Still Salvageable?

This is usually the question executives care about most.

In my experience, most programs are salvageable.

What makes recovery difficult is not technical complexity. It is delayed transparency.

Programs recover when organizations are willing to:

Acknowledge reality
Establish clear ownership
Make decisions quickly
Focus on outcomes instead of activity

Programs become unrecoverable when leadership continues operating from assumptions that no longer reflect the truth.

At that point, you're not managing a program. You're managing the perception of a program, and that always ends badly.

The Audit Summary

After conducting an assessment, you should have clear answers to five questions:

Do we have a shared understanding of the objective? (Not "is it documented?" — do stakeholders agree?)
Do we know who owns decisions? (One person per decision, clear authority, able to decide)
Do we understand the critical path? (What must not move? What determines success?)
Are risks visible and actively managed? (Known, discussed, with mitigation assigned)
Is governance helping execution or hindering it? (Does it accelerate decisions or create friction?)

If those can be answered confidently, recovery planning becomes straightforward.

If they cannot, no amount of tooling will solve the problem.

The Real Question

When a program is struggling, organizations usually ask:

"How do we get back on track?"

A better question is:

"Do we actually understand why we left the track?"

The quality of your diagnosis determines the quality of your recovery.

Everything else is just activity.

Originally published on my portfolio at asifsheraz.com/writing/how-to-audit-a-program-in-trouble

I write about enterprise program delivery, governance at scale, and how to finish what you start. Read more on my portfolio at asifsheraz.com/writing.

ProgramManagement #PMOGovernance #EnterpriseDelivery #ProgramDiagnosis #ProgramRecovery