Stop Managing Programs Like Big Projects
Updated: 2 days ago
Why program leadership is a different management system, and how to run it
A program is not a project with more projects underneath it. It is a different management problem, and it needs a different management system.
By Arunava Chakravarty
Independent Consultant & Strategic Advisor | PMP
Program Recovery | PMO/COE Design | Governance Advisory
Executive Summary
Organisations routinely promote a strong project manager into a program role and hand them more of the same: a bigger budget, more workstreams, a larger steering committee. The result is not program management. It is an oversized project, managed the same way and failing in the same places, at greater cost.
A project asks whether the agreed deliverable arrived on time, on budget and to specification. A program asks whether deliverables, adoption and organisational change are together producing the outcome the investment was made for. These are different management problems. They need a different operating model, not a bigger version of the same one.
Replace “Are we on track?” with “Are we creating the outcome we invested for?” and see which of your reports can no longer answer it.
Prefer to watch instead?
Progrms are not simply large projects
Part 1 of 3
Part 2 of 3
Part 3 of 3
Five messages for senior leaders
1 Manage the whole chain | Delivery creates capability. Only adoption and business change turn capability into benefit. |
2 Lead across methods | Standardise the outcome and the guardrails, not the execution mechanics of Agile, SAFe, Lean, predictive and hybrid teams. |
3 Govern by decision | Every significant decision needs one decider, a deadline and a clear route for escalation. |
4 Measure value early | Benefits often lag. Leading indicators with agreed thresholds provide earlier warning. |
5 Own the white space | The failures that matter most happen between projects, suppliers and contracts, where nobody is accountable by default. |
This paper sets out fourteen shifts from project to program thinking, the practical tools that make them operational, a diagnostic for spotting a program quietly run as a big project, and a seven-rule playbook.
Why More Project Management Is Not Program Management
The budget grows, workstreams multiply, the steering committee enlarges and the integrated plan runs to thousands of activities. The organisation assumes it is now doing program management. It is not.
PMI’s Standard for Program Management, Fifth Edition (2024) frames programs as coordinating related work so that it creates greater benefits than managing the components independently, whatever delivery method is used. The fifth edition adds
Collaboration as a performance domain, a sign that success depends on how components and stakeholders work together, not only on how each performs.
Two roles, two questions
Project manager: “Are we delivering what we committed to deliver?” This can be answered from a project plan.
Program Director: “Are all these moving parts collectively creating the outcome the organisation invested for?” This can only be answered by looking across plans, teams, suppliers and the business itself.
The program value chain
STRATEGY → INVESTMENT → CAPABILITY → BUSINESS CHANGE → ADOPTION → OUTCOME → BENEFIT → VALUE
The value chain connects investment and delivery to business change, adoption, outcomes and realised benefits. A break at any link can leave a technically complete program without its intended value.
Delivery creates capability. Capability must be adopted and exploited before most benefits can be realised. PMI’s Benefits Realization Management: A Practice Guide (2019) takes the same view: benefits are identified, delivered and sustained, not calculated once at closure. The Program Director manages the integrity of the entire chain. A capability nobody adopts, a process nobody redesigned or a benefit nobody owns is as fatal as a late deliverable, and far less visible in a status report.
The common response to complexity is aggregation: twenty plans become one giant plan, twenty RAID logs become one enormous register, twenty reports become a forty-page dashboard.
Aggregation is not integration. Combining project data produces a larger pile of project-level views, not a program-level one.
The Fourteen Shifts
Each row is a change in instinct: what a strong project manager does naturally, what the program level requires instead, the question that tells you which mode you are in, and the practical move that makes the shift real.
# | From → To | The question to ask | The program move |
1 | Deliverables → Outcomes and benefits | What changes because we delivered this? | Every component names the benefit it serves and a business owner accountable for it |
2 | Dependency list → Dependency architecture | What happens elsewhere if this moves? | Record what each milestone enables and what a slip costs in benefit terms |
3 | Protect the baseline → Optimise the whole | Would we approve this component today? | At each gate, bring a recommendation: accelerate, resize, merge, redirect or stop |
4 | Control change → Navigate change | Has the environment changed enough to change our response? | Hold quarterly assumption reviews; every significant change cites its evidence |
5 | Allocate resources → Make enterprise trade-offs | Where should scarce capability go? | Track the six to eight constraining capabilities; give one person cross-project authority |
6 | Project risks → Systemic risk | Can risk propagate across boundaries? | Cluster risks by root cause; assign owners to risks that cross boundaries |
7 | Manage stakeholders → Align competing interests | Whose incentives conflict? | Map conflicts of interest; settle the big ones at sponsor level |
8 | Governance as reporting → Decision architecture | Who can decide what, and how quickly? | Track decision latency; make at least half of each steering agenda decisions |
9 | Protect scope → Protect strategic coherence | Does this work still belong in the program? | Review traceability quarterly; flag orphan components and orphan benefits |
10 | Deliver technology → Create capability | Can the business actually operate differently? | Define “capability ready” to include people and process; gate go-live on business readiness |
11 | Critical path → Multiple paths to value | Which path is constraining value? | Name the limiting path each quarter and redirect effort there |
12 | Milestones → Leading indicators | Are we moving toward benefit before the lagging result appears? | Define an indicator at each stage of the chain before build begins |
13 | Manage suppliers → Govern an ecosystem | Who owns what happens between contractual boundaries? | Name an owner for every seam |
14 | Optimise components → Optimise the system | Would we make this choice if the whole program were one project with one budget? | Align project success measures with program outcomes |
Three shifts where programs fail quietly
Dependencies form loops that no project can see (Shift 2). Applications wait for network segmentation, which waits for the security architecture, which waits for identity controls, which wait for the application integrations. Every project can honestly report Green while the integrated outcome becomes less likely. A dependency list records relationships. A dependency architecture explains consequences, such as a six-week identity slip that moves a legacy shutdown, breaches a supplier exit date and pushes a benefit into the next financial year.
The program exists to protect value, not yesterday’s plan (Shift 3). A project may still deliver exactly what was approved two years ago while a merger, a regulation or a new platform has made it redundant. Holding the baseline looks disciplined at project level. At program level, spending money because the old baseline exists is irrational.
Locally rational decisions add up to a poor outcome (Shift 14). The network team finishes early by trimming segmentation design and the rework lands on applications. The cloud team optimises cost per workload with a platform that complicates security. Every scorecard is green and the outcome is worse than if each team had done a little less well for itself.
Leading Across Different Ways of Working
A modern program may run an Agile product team, a predictive data-centre migration, wave-based infrastructure rollouts, continuously delivered security work, milestone-based vendor implementations and fixed-deadline regulatory work at the same time. Forcing them to work identically creates more problems than it solves.
Create enough integration, governance and visibility across different ways of working that the overall outcome remains coherent. Govern the outcome consistently without forcing the execution mechanics to be identical.
Agile. Autonomy in how a team delivers is not independence from architecture, data, suppliers or adoption. Program visibility must include outcomes, release readiness, cross-team dependencies and flow, not just percent complete.
SAFe. Lean Portfolio Management replaces project-by-project funding with persistent funding of value streams, controlled by Lean budgets and guardrails. Governance does not disappear; control moves to decentralised execution within explicit guardrails. Where that model is adopted, program governance should align with the enterprise funding arrangements.
Lean. The focus is the horizontal flow of value across organisational boundaries. The Lean Enterprise Institute notes the value-stream manager is accountable for a stream whose money, assets and people belong to other functions. Program Directors sit in exactly this position, which is why explicit decision rights matter.
Hybrid. A study in PMI’s Project Management Journal (Gemino, Horner Reich and Serrador, 2021) of 477 projects found 52% used hybrid approaches. Hybrid and Agile delivered higher stakeholder success than traditional approaches while matching them on budget, time, scope and quality.
One program view sits above very different component practices:
Program concern | Predictive component | Agile component | Hybrid program view |
Planning | Baseline schedule | Backlog, iterations, releases | Integrated outcome roadmap |
Scope | Controlled baseline | Evolving backlog | Strategic boundaries and benefit guardrails |
Progress | Milestones | Working capability, flow | Outcome readiness |
Change | Change control | Backlog reprioritisation | Impact on program value and dependencies |
Funding | Project budget | Value-stream capacity | Investment optimisation |
Risk | Project RAID | Continuous risk management | Systemic risk architecture |
Governance | Gates and tolerances | Decentralised decisions | Decision rights plus guardrails |
Success | Delivery plus outcome | Value plus customer outcome | Benefits and enterprise value |
Making Enterprise Trade-offs Explicit
Three strategic initiatives need the same enterprise architect in the same quarter, and all three are “priority one”. The architect cannot provide 150% capacity. This is not a scheduling problem. It is a governance problem. If no decision is taken, the organisation has merely distributed the same unavailable person across several optimistic spreadsheets.
Step one: make the conflict visible
A resource contention matrix lists the six to eight capabilities that genuinely constrain the program (security architects, integration test environments, finance SMEs, change and training capacity), plots demand against capacity by quarter from all project plans, and puts every overload to a person with cross-project authority as a decision, not a discussion.
Step two: decide on a common frame
A trade-off scorecard rates each contested component against eight factors, where 5 always means the strongest case for the scarce capability now: strategic criticality, benefit at risk, regulatory or contractual constraint, dependency leverage, delay recoverability, absence of alternatives, cost of delay and risk exposure. Weights are agreed in advance, and the priority score is the weighted sum.
Component competing for one architect | Weighted score (max 5.0) | What the score does not show |
A: Identity design | 3.8 | Highest dependency leverage; unblocks the most downstream work |
C: Data migration design | 3.4 | Immovable regulatory date and an unrecoverable delay |
B: Cloud landing zone | 3.0 | Lowest regulatory pressure; most flexible to re-sequence |
Illustrative data. Weights and ratings should be agreed by your own sponsors.
Because Data migration design carries a fixed regulatory date, a leader might reasonably ring-fence a window of the architect’s time for it regardless of rank. The scorecard did not make that decision. It made the trade-off visible, so it can be taken openly, recorded and explained to the sponsors who lost out.
Agree the weights before the conflict, not during it. Let the score support judgement, not replace it. Record the decision, the decision-maker and what was traded.
Governing Through Decisions
Information is not governance. A seventy-page deck that identifies five unresolved decisions achieves nothing if nobody has the authority, information or willingness to make them. Effective governance answers five questions:
What needs a decision? Separate decisions from updates on every agenda.
Who owns it? One decider, not a committee.
What can they decide alone? Delegated authority within explicit guardrails.
What triggers escalation? A defined test, not instinct (below).
By when? Track decision latency: a program where decisions take six weeks is slow however fast its teams work.
Two failures mirror each other: over-centralisation, where every decision goes upward and executives become bottlenecks, and fragmentation, where every component decides locally and nobody assesses the collective impact. The aim is decision-making at the lowest sensible level, bounded by explicit guardrails.
Decision rights across levels
R = recommends, D = decides, C = consulted, I = informed. Thresholds should follow your organisation’s delegated authorities.
Decision | Team | Program Director | Steering Committee | Sponsor / Board |
Delivery change within tolerance | D | I | – | – |
Change affecting another component | R | D | I if material | – |
Cross-project resource reallocation | C | D | I | – |
Material benefit reduction | R | R | D within mandate | D if beyond mandate |
Budget increase beyond tolerance | – | R | R, D within delegation | D where required |
Legally permitted compliance exception | R | C | C | D |
Program termination | C | R | R | D |
Routine Agile backlog reprioritisation | D | I | – | – |
The escalation test
Raise an issue to program level if the answer to any of these is yes:
REACH | Does it affect another project, a shared resource or a shared supplier? |
BENEFIT | Does it threaten a committed benefit or its start date? |
AUTHORITY | Is the decision outside delegated authority? |
TIME | Has it stayed unresolved beyond the agreed time limit? |
WHOLE | Would the right answer change if we optimised the program rather than one project? |
An escalation should arrive with a recommendation and a deadline, and end in one of three outcomes: decide, direct, or defer to the steering committee with a date.
Some escalation is created by complexity and needs a decision at the right level. Some is created by fear of accountability and needs a clearer mandate, plus an honest conversation about what happens when a delegated decision turns out to be wrong.
The same system-level lens applies elsewhere. Cluster risks by root cause (twenty Amber risks in twenty registers may share one cause and form a single Red exposure). Negotiate conflicts of incentive at sponsor level rather than communicating them away. Protect strategic coherence by asking “does this still belong in the program?” rather than “is it in scope?”.
Measuring Value Before It Arrives
The path to value is not the path to delivery
A project schedule can contain several critical and near-critical paths. A program must also coordinate technology, data, regulatory, commercial, business readiness and adoption paths, all feeding the path to benefits. Technology may be ready in Q2 while the process redesign and training that unlock the benefit land in Q4. Accelerating the technology alone may then add cost without advancing benefits.
The test is simple: for each path, date the earliest point at which it would allow value to begin. The latest date is the constraint, and its plan deserves attention first. A 20,000-line integrated schedule offers enormous detail and little insight. A Program Director needs enough detail to understand causality and enough altitude to see the whole system, on one page.
The leading-indicator chain
Program reporting naturally counts what is easy: servers migrated, applications deployed, training sessions delivered. These describe what the program did, not whether the benefit is becoming more or less likely. By the time a financial figure shows a problem, the behaviour behind it is established and expensive to change.
READINESS → ADOPTION → OPERATIONAL PERFORMANCE → INTERMEDIATE OUTCOME → LAGGING BENEFIT → VALUE CONFIRMED
Readiness, adoption and operational performance provide early signals. Realised benefits and confirmed value provide later evidence; the classification depends on what each measure is intended to predict.
PMI’s 2024 project-success research, covering nearly 10,000 people in 139 countries, defined success as delivering value worth the effort and expense. Only 48% of respondents rated their latest project or program as successful, 40% as mixed and 12% as failures. The final question moves from “Did we deliver?” to “Was it worth it?”.
A leading indicator nobody has agreed how to act on is decoration. The early-warning system adds thresholds and an owner to every stage, shown here for a CRM program:
Stage | Indicator | On track | Red trigger | Who acts |
Readiness | Customer records meeting data-quality standard | 95%+ at go-live | Below 85% | Change lead |
Adoption | Weekly active users vs target | 80% by week 8 | Below 60%, or any region below 50% | Business unit head |
Operational performance | Opportunities logged in CRM, not spreadsheets | 90% by week 12 | Below 70% | Process owner |
Intermediate outcome | Lead-to-opportunity conversion | +3 points by month 6 | Below +1 point | Business owner |
Lagging benefit | Forecast mid-market churn (target 11%) | 11% or better | Above 12.5% | Benefit owner |
Value confirmed | Benefit vs investment, effort and risk | Business case holds | Below hurdle return at a gate | Sponsor |
Illustrative thresholds. Set your own from the approved business case.
In this illustrative scenario, at week 8 data quality is 96% (on track), but adoption is 58% overall, with two regions at 41% and 47%. Adoption is Red. This signals a risk to the churn target several months before the later outcome measure can confirm whether the benefit has been affected.
A leading indicator is a hypothesis about how value is created. Test it. If adoption hits target and nothing moves, the causal chain is broken. And remember: logins are not usage, and training attendance is not readiness.
Benefits as a managed asset
A benefit behaves like an asset only when it is owned, triggered and backed by a pre-agreed response. The benefits register is a single owned record reviewed every governance cycle, not a business-case spreadsheet reopened at closure. Each benefit carries a named business owner (not the program manager), baseline and target, measure and data owner, leading indicators, enabling components, required business change, disbenefits to monitor, triggers from the early-warning system, a corrective action with owner and deadline, and evidence-backed confidence.
A benefit with no named business owner is not counted in the business case. A benefit with no enabling component is a gap in the program.
Because the corrective action is written in advance, a breached threshold reaches the steering committee as a response to approve, not a problem to discover. That is how early warning shortens decision latency.
Governing the White Space Between Contracts
Enterprise programs depend on several suppliers at once, yet the customer experiences one outcome. Every supplier can meet its own SLA while the end-to-end service fails, and each will point, correctly, at its contract. Contracts define what each party must deliver; only deliberate collaboration produces the outcome that no single contract covers. The gap between responsibility and authority is widest at the seams.
The seam register gives every boundary one named owner and a mechanism. Settle these before the first supplier goes live, not during an incident:
Seam | Owner | Mechanism |
Interfaces between components | Program architecture lead | Interface agreements signed before build |
Cross-supplier testing | Program test manager | One integrated test plan with shared exit criteria |
End-to-end incidents | Service integration owner | Joint incident process: engage first, settle cause afterwards |
Interim financial responsibility | Program Director with Commercial | Rule agreed in every contract, reconciled afterwards |
Architectural disputes | Architecture authority | Decision within an agreed time limit |
Shared environments and change windows | Release and environment manager | One change calendar for all parties |
The outcome itself | Program Director with business owner | Outcome-linked commercial incentives |
The commercial side matters as much. Supplier management optimises each relationship. Program leadership also orchestrates the ecosystem, with incentives tied to end-to-end results, joint-working obligations and dispute resolution that does not wait for the contract.
Assessing Program System Health
Sometimes Project A must accept a disadvantage so the program succeeds: a specialist moves to unblock three workstreams, a deployment is delayed because the organisation cannot absorb two major changes at once, a simpler technical option is chosen because the superior one creates disproportionate integration complexity. Each looks inefficient locally and may be entirely rational globally.
A mature program review does not need every operational metric. It needs the evidence required to make decisions, organised around seven layers:
Layer | The review question | Evidence in the pack |
Strategy | Are we still solving the right problem? | Would-we-approve-it-today test; spend vs forecast benefit |
Benefits | Are benefits becoming more or less likely? | Register with confidence rating and trend |
Capabilities | Can the organisation absorb and use the change? | Readiness and adoption by unit; change load |
Delivery ecosystem | Do releases and supplier incentives support the outcome? | Release progress; seam register; commercial position |
System integration | Which dependencies, clashes and systemic risks threaten the outcome? | Dependency chain; contention matrix; risks by root cause |
Governance | Which decisions are needed, from whom, by when? | Decision log with latency; escalations by route |
Evidence | What changed since the last cycle? | Early-warning view; changes in the period |
Delivery is still in the pack, but it is no longer the whole conversation. Redesign the steering pack around these layers and remove any page that does not lead to a decision.
What This Asks of the Program Director
The skills that earned the promotion (planning, financial control, risk management, delivery discipline) remain essential. Program leadership adds demands that project management did not develop:
Added demand | Why the program level requires it |
Systems thinking | Cause and effect cross project boundaries |
Benefits thinking | Delivery does not guarantee value |
Strategic judgement | Yesterday’s plan may no longer deserve funding |
Commercial thinking | Suppliers optimise contracts; the organisation needs outcomes |
Political awareness and negotiation | Programs redistribute resources and authority |
Ambiguity tolerance | Not everything can be defined years in advance |
Decision architecture | The leader cannot personally make every decision |
Selective abstraction | See the system without drowning in detail |
The largest change is psychological. A project manager is rewarded for solving problems. A Program Director builds a system in which the right people solve the right problems at the right level. One who keeps solving everything personally becomes the program’s biggest bottleneck.
Give the new Program Director decision rights on day one, pair them with a senior business benefit owner, and judge them on outcomes as well as delivery.
Diagnostic for an Oversized Project
Count the statements that are true of your program today. Each maps to one shift. This is an informal discussion tool, not a validated assessment; the score bands below are indicative.
Status is reported project by project; nobody reports on outcomes or benefits between reviews.
Dependencies live in a list, and nobody can say what a slip would cost in benefit terms.
Baselines are defended although strategy, regulation or the operating model has moved.
Changes are judged on cost, time and scope, not on their effect on value.
Scarce specialists are scheduled project by project; conflicts go to whoever escalates loudest.
Risks are logged per project; nobody owns risks that cross boundaries or share a root cause.
Stakeholder plans describe communication, not conflicting incentives.
The steering committee mostly receives updates; decisions wait for the next meeting.
Work continues, or has been added, with no traceable link to a benefit.
“Delivered” means technically accepted; business readiness is not part of the definition.
The plan has one critical path, to delivery; nobody can say what is constraining value.
Benefits are measured at the end; there are no leading indicators for adoption.
Suppliers are managed one by one; nobody owns the seams between them.
Every project scorecard is green, yet the business cannot say what is better.
Ticks | What it suggests |
0 to 3 | Largely run as a program. Fix the remaining items before they compound. |
4 to 8 | Drifting toward an oversized project. Pick the three that hurt most and start with the matching tools. |
9 to 14 | An oversized project with a program label. Start with Shift 1 (outcomes), Shift 8 (decision rights) and Shift 12 (leading indicators). |
The Program Management Playbook
1 Govern outcomes. Every capability connects visibly to an outcome and a benefit with a named business owner.
2 Manage dependencies as a system. Understand the consequences of a slip, not just the relationship.
3 Allocate capacity deliberately. If priorities exceed capacity, force the trade-off into governance and record it.
4 Decentralise within guardrails. Do not let governance become a permission queue.
5 Measure benefits early. Leading indicators with thresholds and pre-agreed responses.
6 Allow different methods. Agile, predictive, vendor and hybrid components coexist under common outcomes and guardrails.
7 Optimise the whole. Successful components do not guarantee a successful program.
Project management provides disciplined execution within components. Program management provides coherence across components. Both are necessary, and neither substitutes for the other.
Conclusion
Complexity produces a predictable response: more projects generate more reports, more dependencies larger schedules, more suppliers more governance meetings. The organisation answers complexity with more management machinery, which is exactly the oversized-project pattern. Program leadership is understanding the system well enough to know where control matters, where autonomy matters, where decisions matter, where resources should move and where the benefit chain is weakening.
The project manager asks, “Are we delivering the thing correctly?” The Program Director asks, “Are we delivering the right combination of things?” And eventually the most uncomfortable question of all:
Given what we know today, should we still be doing what we decided to do two years ago?
So when someone moves from a project to a program, the question should not be “Can you manage something bigger?” It should be “Can you manage differently?”
About the author
Independent Consultant and Strategic Advisor with 30+ years of enterprise program and delivery leadership across Defense, Government, Telecom and IT Services. Advises CXOs, PMO heads and delivery leaders on governance recovery, PMO/COE design, program turnaround, commercial control and executive decision support. PMP certified.
Watch and read more on program governance, delivery transformation and risk on YouTube and LinkedIn.
Reference Points
PMI, The Standard for Program Management, Fifth Edition (2024)
PMI, Benefits Realization Management: A Practice Guide (2019)
Comments