Program Management Across Projects

At the start of this fictional rail operator’s recovery review, a new fare regulation was forty weeks from taking effect. The existing ticketing system could not meet it. Eleven project teams and three suppliers each reported green against their local commitments: retail screens, a fare-engine build, payment certification, and a warehouse were ready. Yet the first combined forecast put the original launch scope at week sixty-six, twenty-six weeks after the deadline. The six-month delay was a forecast against that future date, not six months of unlawful operation already elapsed.

The interface contract between the fare engine and retail channels had no accepted owner on either side. It had changed four times as a supplier refined its design and the parties worked through the first regulatory reinterpretation. Seven teams needed a shared integration environment maintained by one engineer for part of the week. Earlier integration targets had slipped without changing the project reports. The status pack showed delivered components but did not show whether the required ticketing service could work by the deadline.

APM describes program management as coordinating related projects and business-as-usual activities to achieve beneficial change. Value can arrive in increments; every project need not finish simultaneously. In this case, however, fare calculation, retail, payment, settlement, and operational controls must work together for the regulated launch scope. Program management assigns responsibility for that combined result while each project retains its own delivery and dependency obligations. The investment choices described in Ninety-Four Projects, Every One Approved establish why the work receives resources. Running the program then requires a feasible schedule, shared-capacity decisions, continuing integration, and evidence of outcomes.

Connecting project plans to a feasible program

The GOV.UK Service Manual places governance within delivery teams while recognizing the support and authority they need from service owners and senior roles. Applied here, that means named project responsibilities and a program-level route for resolving cross-project conflicts. The following arrangements are proposals for the rail operator, not an exhaustive taxonomy of program management.

Concern	Program coordination	Project responsibility	Rail operator
Schedule	Connect activities, readiness milestones, resources, and external constraints	Supply estimates, actual progress, assumptions, and recovery options	Compare the integrated forecast with the week-forty deadline
Dependencies	Maintain a shared view and resolve conflicts beyond one project’s authority	Agree what each provider and consumer must supply, verify, and communicate	Fare meaning, API versions, acceptance tests, and change notification need owners
Capability and capacity	Allocate scarce skills and environments across commitments	Include delivery, support, review, training, and rework in demand	One part-time environment engineer cannot be assumed fully available to seven teams
Outcomes and transition	Coordinate acceptance, operating readiness, and benefit evaluation	Meet agreed component criteria and contribute evidence to the combined service	A working screen or certified payment component does not establish a compliant ticketing service

A program date is a forecast derived from activity relationships and usable capacity. Include integration, testing, approvals, cutover, and operating preparation where they occur; do not add all integration time again after the last project if it is already in the plan. For a small illustrative schedule, component A finishes on day five and integrates by day seven while independent component B finishes on day ten. With sufficient separate capacity, a one-day cutover after both finishes on day eleven. Adding two integration days after day ten would instead give thirteen. Real plans also need calendars, resource conflicts, uncertainty, and the paths driving each important milestone. GAO’s schedule guidance explains these relationships. Work backward from a required date to identify what must be ready, then test whether the forward plan can actually achieve it.

A dependency can involve data, behavior, availability, or a decision. For each material relationship, record the provider, consumer, required result, acceptance evidence, relevant milestone, owner on each side, assumptions, and unresolved questions. Both sides need the same understanding; the program helps settle conflicts and assigns work that otherwise falls between plans. Keep this view current as discovery exposes new dependencies. A missing entry is not evidence of independence.

Agreeing how teams work together

Team Topologies offers three interaction modes: collaboration for a bounded period of joint discovery, X-as-a-Service for a provided and consumed capability, and facilitation for help with learning or obstacles. This vocabulary can clarify a relationship, but naming a mode neither creates a usable API contract nor proves that teams have agreed. The operator needs a shared interpretation of the fare rules, version and compatibility expectations, tests, and a change-notification path. A period of joint design followed by service consumption is one suitable arrangement. The failure was the missing agreement and verification, not the absence of a label in a register.

Limiting shared work without hiding the queue

A WIP limit limits work already in progress within a defined boundary. DORA recommends setting limits from capacity and including support, meetings, and technical debt. This counters excessive simultaneous work and switching; it does not mean that every specialist must belong to exactly one project. A specialist can support two projects through reserved, sequential sessions without doing two tasks at once. Check effort by skill and period, service commitments, interruption cost, and the ability to resolve competing requests. Dedicated staffing may help when those arrangements cannot sustain the needed flow.

For the operator’s initial policy, an item is a versioned change package accepted into the shared integration stage, ending when its agreed integration checks pass and the receiving team accepts the result. The limit is four such packages, not four teams. Blocked packages and rework remain counted while unresolved; an explicitly withdrawn package leaves with its reason recorded. A separate visible queue contains requests awaiting admission. Two full-time engineers maintain the environment and support automated checks; neither their headcount nor the number of requesting teams mathematically determines the limit of four. Package size, test duration, environment isolation, and support demand all matter. Review the initial limit against observed flow and quality.

When the limit is reached, complete or unblock admitted work before pulling another package. Record urgent work and its authorization; any permitted temporary exception must show the resulting WIP and which commitments change. Do not make the board look compliant by hiding blocked work or shifting all waiting outside the measured stage. Keep an end-to-end request-to-acceptance view alongside the stage limit. Investigate starvation or long waits before changing capacity or raising a limit merely to keep people busy.

Use value stream mapping to understand the flow and its handoffs. DORA distinguishes elapsed lead time, estimated uninterrupted process time, and percent complete and accurate (%C/A): the share of incoming work the receiver can use without rework. For this case, measure calendar days from a valid integration request to acceptance of its verified result, including the admission queue, blocked time, and rework. Report completed-item distributions and the age of still-open requests, with withdrawals visible. Assess %C/A against the receiving stage’s stated input criteria, rather than treating it as the fraction of fields filled in. A change in workload, entry rules, or missing observations can move a headline number without improving comparable work.

Planning, integration, and feedback have different cadences

SAFe’s planning interval is a timebox for an Agile Release Train’s shared objectives, typically eight to twelve weeks. Its common structure includes development iterations and an Innovation and Planning iteration, but the published overview treats that pattern as adaptable. An ART is a long-lived group of teams serving one or more solutions; it is not a synonym for a temporary program. A program can borrow coordination practices without adopting that organizational model.

Joint planning aligns known objectives, dependencies, estimates, and capacity. Participants can work together in person or remotely. Record what is agreed, what remains provisional, who will resolve it, and which dependent activity must wait for confirmation. The event creates an opportunity to find an interface gap; it cannot guarantee that every dependency is discovered before work starts. New evidence must update the plan between events.

Distinguish the planning interval from the feedback loop inside it. SAFe’s System Demo shows integrated new functionality from the most recent iteration and occurs at each iteration’s end. It is not a claim that every future feature is finished. Additional PI-end review and senior attendance can serve wider decisions. Teams still integrate and validate changes during the iteration, and release according to readiness, need, and applicable authorization. DORA’s small batches guidance warns that recombining small changes into a large downstream testing or release batch delays feedback. A regular demonstration supports inspection; it does not replace continuous integration or release evidence.

Responding when the plan changes

Assess a new change when it arrives. Establish what is affected, who may decide, what evidence is missing, and the cost of waiting. A local adjustment is different from rebuilding every team’s plan. Regular planning can consolidate changes that can safely wait, but a calendar boundary is not an approval rule. DORA’s 2024 summary links unstable organizational priorities with adverse productivity and burnout outcomes. It does not establish that withholding decisions until each PI boundary makes the resulting workload manageable.

Decision route	Condition	Action and record	Rail operator
Team decision	Within explicit delegation and required approvals, after checking actual impact	Update the backlog and relevant decision evidence; notify affected people	An isolated UI correction may qualify; absence from the dependency register is insufficient
Program coordination	Cross-team impact within the program’s authority	Assess promptly with affected owners; adjust relevant work now or record why waiting is safe	The first contract uncertainty needs coordinated investigation, not an automatic six-week wait
Authorized escalation	A required decision exceeds delegation or threatens an obligation	Present options, consequences, uncertainty, and a needed-by date; use the appropriate decision path	A later regulatory reinterpretation threatens the original launch scope and requires a sponsor decision

The governance body acts within its mandate; it does not acquire authority merely because an item is urgent or expensive. Internal approval cannot waive an external obligation. Preserve the proposed change, alternatives, decision, authority, rationale, affected acceptance criteria, and follow-up as described in scope change. Neither an unchanged budget nor an unchanged headline outcome establishes permission. Notify the people whose work depends on the decision, rather than assuming they will discover it in a log.

Dependencies are one source of risk, not a substitute for the risk view. Examine technical feasibility, supplier delivery, regulatory interpretation, costs, operating readiness, security, and expected benefits where they matter. Separate an uncertain future event from an assumption awaiting evidence and an issue that has already occurred. Give each material item an owner, impact, response, decision date, and escalation condition. The largest risk may sit within one component or between several; assess it rather than prescribing its location.

Reporting results and closing responsibly

A line of sight connects component outputs with intended outcomes and makes the contribution claim inspectable. It does not prove that the benefit will follow. A program needs delivery evidence as well as outcome evidence: integrated behavior, scope still missing, operating acceptance, forecasts, and the assumptions behind benefits. Choose a small set of headline measures with supporting detail rather than requiring exactly one KPI.

View	Evidence to report	What it does not establish alone
Project or team	Delivered and tested scope, unresolved dependencies, forecast and confidence	Local green status does not establish whole-service readiness
Program	Integrated behavior, required coverage, outstanding defects, operating readiness, cost and schedule exposure	A demonstration or one successful ticket does not validate every required route, fare, or channel
Sponsor and continuing owner	Expected and observed outcomes, benefit evidence, residual risks, decisions and continuing obligations	Meeting a launch date does not by itself establish net value or justify ending monitoring

The rail operator’s regulated launch needs agreed coverage of required routes, fares, and channels, with acceptance evidence for calculation and settlement accuracy, access, reliability, and support. Its operational measures should define transactions, observation periods, failures, and exceptions. A representative successful sale can illustrate progress, but cannot stand in for those checks. Live for a Year, Used by a Third explains how to distinguish observed change, attribution, and realized financial benefit. Track benefit claims during delivery and after deployment; the continuing owner may participate in the program and needs suitable authority and resources, not a particular organizational label.

Completion and closure require their own decisions. GovS 002 distinguishes confirming outputs and outcomes to date from documenting unmet requirements and transferring continuing responsibilities. A project may need acceptance and operational handover in addition to producing an artifact. A program can close after agreed scope is delivered or through a controlled early termination, without pretending that every forecast benefit has already materialized. Record remaining risks, actions, benefit tracking, contracts, and review dates; obtain acceptance from the receiving owners. This is a useful governance pattern for the fictional company, not a claim that the UK government standard legally binds it.

Use cross-team retrospectives to investigate recurring integration failures and assign improvements with owners. The Service Manual also recommends that senior owners engage with delivery work directly. Inspection frequency should support the decisions they need to make. Attendance at a quarterly demonstration is not a sufficient health test, and a register containing every expected field does not prove that the underlying agreements work.

Questions for a program review

• How do the activity network, resource assumptions, and current evidence support the forecast against each required date?
• Which provider and consumer obligations are agreed, which remain uncertain, and what blocks dependent use?
• What does each WIP limit count, and where can the queue, blocked work, rework, and urgent exceptions be seen?
• When were the current changes integrated and checked, and what did the latest iteration’s demonstration establish?
• Which changes need a decision now, who has authority, and why can any deferred decision safely wait?
• Which delivery and outcome claims are supported, which required scope remains, and how are open or failed cases reported?
• Who accepts operation, residual risks, and continuing benefit reviews when the program closes?

The operator’s revised plan

The recovery plan starts at week zero of the review timeline, with the regulation still due at week forty. In weeks one and two, the supplier, retail team, and a newly appointed fare specialist agree the initial interface semantics and acceptance tests. Each side receives explicit responsibilities for version compatibility, test evidence, and change notification. The environment receives two full-time engineers and the provisional four-package WIP limit. Eleven teams plan in eight-week intervals, integrate and check small changes throughout development, and demonstrate the integrated increment every two weeks. The steering committee joins the eight-week review and any earlier session needed for a decision.

The second regulatory reinterpretation arrives in week twenty-six, during the fourth eight-week interval. A coordinated impact review starts that week. The original launch scope remains infeasible by week forty, so the authorized sponsor approves deferring optional commercial features while retaining every function required for lawful ticket sales in the case’s stated scope. The fare specialist and designated assurance owners verify that distinction; the sponsor does not waive the regulation. Deferred features keep owners, revised forecasts, and review dates. Teams receive the changed contract and plan as decisions are made, rather than waiting for week thirty-two.

For the eight weeks preceding recovery, completed eligible integration requests had a median lead time of nineteen calendar days under the request-to-acceptance definition above. In weeks twenty-nine through thirty-six, the median is two days. The fictional review retains the same entry and acceptance rules, compares work by package class and size, and reports open-request ages and withdrawals beside completed items. In the baseline period, about a third of incoming packages were usable by the integration stage without input rework; %C/A continues to be tracked separately. These observations follow changes in staffing, interfaces, testing, and WIP together; they do not isolate how much any one intervention caused. A lower completed-item median would be insufficient if difficult requests were merely left waiting.

Acceptance of the required launch scope and operational readiness is complete at week thirty-seven, leaving three weeks before the week-forty effective date. Sales under the new rules begin at that date; the three-week margin refers to readiness, not to the first sale. The final pack preserves the original week-sixty-six forecast, approved scope changes, acceptance coverage, actual dates, deferred work, costs, and the remaining benefit questions. Closure includes accepted operating responsibilities and continuing reviews. The program can now explain what is ready, what changed, and what still needs evidence.

References:

• Association for Project Management, What is program management?
• GOV.UK Service Manual, Governance principles for agile service delivery (Open Government Licence v3.0)
• DORA, Work in process limits (CC BY 4.0)
• DORA, Visibility of work in the value stream (CC BY 4.0)
• DORA, Working in small batches (CC BY 4.0)
• DORA, Accelerate State of DevOps Report 2024, official summary (CC BY 4.0)
• Scaled Agile, Planning Interval (PI), public definition and overview
• Scaled Agile, Agile Release Train, public definition and overview
• Scaled Agile, System Demo, public definition and overview
• Matthew Skelton and Manuel Pais, Team Topologies, Key Concepts
• Government Project Delivery, GovS 002: Project delivery, version 2.1 (2025), sections 3.3, 6.4.8–6.4.9 and 7 (Open Government Licence v3.0)
• U.S. Government Accountability Office, Schedule Assessment Guide, GAO-16-89G (2015), resource allocation and critical paths