Running a program, not a big project: outcomes, tranches and the pace of change

Some changes are too large, too interconnected or too uncertain to manage as a single project. Replacing a business system while redesigning the processes that use it, moving to a new site while changing how the warehouse operates, or launching a product range that needs new tooling, new suppliers and new sales channels all involve several streams of work that depend on each other and on people changing how they work. Treating such a change as one very large project usually ends badly. The plan becomes enormous, the scope keeps shifting and the organisation is asked to absorb everything at once at go-live.

This is the territory of program management. A program is a temporary structure that coordinates several related projects and other activities to deliver outcomes and benefits that none of them could deliver alone. The idea is widely used in government and large organisations, but its core logic is useful at any scale: manage the change as a sequence of steps, each delivering a usable improvement, with a deliberate pause to check that the business has absorbed it and that the remaining work still makes sense.

This article explains, in general terms, what distinguishes a program from a project and from a portfolio, when a group of projects deserves program management, how tranches structure change into manageable steps, the governance roles that make programs work and the common reasons they fail. It is general information that draws on widely used program management concepts.

Project, program and portfolio

The three terms are often used loosely. In their most useful sense they describe different management questions.

A project delivers things: a building, a system, a machine, a product design. A program uses those things to change how the organisation works, and it is judged by whether that change produces the intended benefits. The when the project succeeds and the strategy fails article explains why delivering outputs does not guarantee the outcome they were meant to support.

When a group of projects deserves a program

Not every collection of projects is a program. Grouping unrelated projects under a program label adds governance without adding value. A program is usually justified when most of the following are true:

• A shared outcome. The projects contribute to one significant change, such as a new operating model or a new market position.
• Strong interdependencies. The projects depend on each other’s outputs, share resources or must be sequenced carefully.
• Business change. Delivering the outputs is not enough; people, processes and organisation must change to realise the benefits.
• Uncertainty about the path. The end state is clear in outline, but the best route will become clearer as the work proceeds.
• Duration. The change unfolds over a period long enough that strategy, technology or the market may shift along the way.

Where projects are independent and each delivers its own benefits, portfolio management, which decides what to fund and in what order, is usually enough.

Tranches: change in steps the business can absorb

A tranche is a group of projects and activities that together deliver a step change in capability, after which the organisation can operate in a new, stable state and begin realising benefits. Programs are structured as a sequence of tranches rather than a single long build towards one go-live.

Tranches serve several purposes:

• They deliver benefits early. Each tranche ends with something usable, so value starts flowing before the whole program is complete.
• They limit the change load. People can absorb only so much change at once. A tranche gives time to stabilise new ways of working before the next step.
• They create decision points. The end of each tranche is a natural moment to ask whether the program should continue as planned, change direction or stop.
• They retire risk progressively. Early tranches can be designed to test the riskiest assumptions while the investment is still small.
• They maintain momentum and support. Visible progress helps sustain sponsorship over a long change.

Designing tranches well

Good tranche design starts from the end state and works backwards. Useful principles include:

• Each tranche should leave the organisation in a workable state. If the program stopped after any tranche, the business should still function and ideally be better off.
• Front-load learning. Where an assumption is critical and uncertain, test it early, for example through a pilot site or product line.
• Balance quick benefits with foundations. Some early work is foundational, such as data clean-up or a core system, and produces little visible benefit. Pair it with improvements users will notice.
• Respect operational cycles. Avoid placing major transitions in peak trading periods, end-of-financial-year processing or critical shutdowns.
• Allow stabilisation time. Plan a period after each transition for support, fixes and learning before the next wave.
• Keep tranches short enough to steer. Long tranches lose the benefit of regular decision points.

The end-of-tranche review

Each tranche should end with a deliberate review, not just a celebration. Typical questions include:

• Have the planned capabilities been delivered and are they being used?
• Are early benefits appearing, and are the measures working?
• What did we learn about cost, time, risk and the organisation’s capacity to change?
• Does the business case for the remaining tranches still hold?
• Has the strategy, market or technology changed in ways that should change the plan?
• Should the program continue as planned, be reshaped or be stopped?

Treating this review as a genuine decision point is what distinguishes a program from a long project with milestones.

Describing the destination

Programs need a clear description of the future state, sometimes called a blueprint or target operating model. It describes how the organisation will work after the change in terms of processes, organisation, technology, information and, where relevant, facilities and suppliers. Without it, projects optimise their own outputs and the pieces do not fit together.

A benefits map is a complementary tool. It traces the chain from project outputs, through the capabilities they enable and the changes in behaviour or performance that follow, to the benefits and finally the strategic objectives. Benefits maps are useful because they reveal assumptions: for example, that a new scheduling system will reduce overtime only if supervisors actually schedule differently. The benefits move after approval article explains why benefits need active management as circumstances change.

Governance roles that make programs work

Program governance does not need to be elaborate, but certain roles matter:

• Program sponsor, sometimes called the senior responsible owner. An executive accountable for the program achieving its outcomes and benefits, with enough authority to resolve conflicts across functions.
• Program manager. Responsible for coordinating the projects, managing dependencies, risks and resources across them and delivering the capabilities.
• Business change leads. Managers from the operating areas who prepare their teams, lead the transition to new ways of working and own the benefits in their areas.
• Program board. A small group, chaired by the sponsor, that makes program-level decisions, including those at the end of each tranche.

The business change leads are the role most often missing. Without them, the program delivers capability that nobody adopts. The delivered is not adopted article covers how to make adoption happen.

Managing across projects

The program manager’s distinctive work lies in the spaces between projects:

• Dependencies. Tracking which outputs each project needs from others, and when, so delays are visible early.
• Interfaces. Making sure systems, processes and responsibilities connect correctly where projects meet.
• Shared resources. Allocating scarce people and facilities across projects according to program priorities.
• Program-level risks. Risks that no single project owns, such as the organisation’s capacity to absorb change.
• Consistency. Common data, standards and design principles across projects.
• Change control. Assessing changes for their effect on the whole program, not just one project.

Closing a program properly

Programs end when the planned capabilities are in place and the business can realise the remaining benefits without program support, or when the board decides the remaining work no longer justifies the investment. Either way, the ending deserves as much care as the start.

A good program closure confirms that each capability has been handed over to a named business owner, that support arrangements are in place, that benefits measurement will continue after the program team disbands and that outstanding risks and issues have owners. It also captures lessons about pace, sequencing and change capacity, which are often the most valuable lessons for the next major change. Programs that simply fade away, with team members drifting to other work and nobody responsible for the benefits, tend to lose a large share of the value they were created to deliver.

Stopping early is not failure if it is a deliberate decision based on evidence. A program that ends after two of three tranches, because the market changed and the final step no longer made sense, may have served the organisation far better than one that pressed on regardless.

A worked example

This is an illustrative example. The business, figures and events are hypothetical.

A distributor of building products with three warehouses plans to replace its ageing inventory system, introduce barcode scanning, move to a single regional warehouse and offer customers online ordering. The total budget is $2.4 million over two years. The first plan treats it as one project with a single go-live, consolidating the warehouses and switching on the new system on the same weekend.

The leadership team reframes it as a program with three tranches. Tranche 1 (six months) replaces the inventory system and introduces scanning in the largest warehouse only, while the others continue on the old process. It also cleans the product data. Tranche 2 (eight months) rolls scanning out to the other warehouses, stabilises operations and fits out the new regional warehouse. Tranche 3 (six months) consolidates stock into the regional warehouse and launches online ordering.

At the end of tranche 1, the review finds that scanning has reduced picking errors in the pilot warehouse, but that data quality problems took longer to fix than planned and staff needed more training than expected. The board increases training in tranche 2 and moves the online ordering launch back by two months, so that it does not coincide with the busiest trading period. Benefits begin in the first year, and the business never has to absorb a new system, a new process and a new building all at once.

How this applies to a small Australian business

A small business may never use the word “program”, but the principles apply whenever a change involves several connected pieces of work:

• Name the outcome. Describe what the business will do differently and what benefit it expects, not just what will be delivered.
• Break the change into steps. Plan two or three stages, each leaving the business in a stable, improved state.
• Pilot first. Try new systems or processes in one area before rolling them out.
• Pause between steps. Review what was learned and whether the next step still makes sense.
• Give someone the business side. A manager responsible for adoption and benefits is as important as whoever manages delivery.
• Watch the change load. Avoid stacking several major changes on the same people at the same time.

Common mistakes

• Calling unrelated projects a program. It adds overhead without coordination benefits.
• One big go-live. Concentrating all change into a single event maximises risk and disruption.
• Tranches without decisions. End-of-tranche reviews that never change anything are milestones, not tranches.
• No description of the end state. Projects deliver pieces that do not fit together.
• No business ownership. The program delivers capability that nobody takes responsibility for using.
• Ignoring the organisation’s capacity. Change fatigue undermines adoption and benefits.
• Measuring outputs only. A program measured on delivery alone cannot tell whether it succeeded.

Frequently asked questions

Is a program just a large project? No. A large project delivers a defined output. A program coordinates several projects and business changes to achieve an outcome, and expects its path to change as it learns.

How long should a tranche be? Long enough to deliver a meaningful step change and short enough to steer. Many organisations use periods of several months, but the right length depends on the change.

Who should own the benefits? The managers of the business areas where the benefits appear, supported by the program, not the program manager alone.

Questions to ask

• What outcome are these projects meant to achieve together, and how will we know?
• Do they depend on each other strongly enough to need coordinated management?
• How could we break the change into steps that each leave the business stable and better off?
• What are the riskiest assumptions, and can an early tranche test them?
• Who is accountable for the outcome, and who will lead adoption in each area?
• What will we decide at the end of each tranche, and who will decide it?
• Can the people affected absorb the planned pace of change?

Bringing it together

A program is the right structure when several related projects and business changes must work together to achieve an outcome. Its distinctive tools are a clear description of the future state, a benefits map that exposes assumptions, governance that includes the business owners of change, and above all tranches: steps that deliver usable capability, allow the business to stabilise and create genuine decision points. Running a large change as a program rather than a single big project delivers benefits sooner, limits disruption and keeps the organisation able to change direction when the evidence says it should.

---

Source: KEVOS editorial notes. Examples and figures in this article are illustrations.