GPM First
Chapter 1 of Gower Handbook of Programme Management (978-0-5660-8603-8) by Geoff Reiss, Malcolm Anthony, John Chapman, Geoff Leigh, Adrian Pyne and Paul Rayner




1.1 Welcome

Welcome to the Gower Handbook of Programme Management! The team of authors hope that you will enjoy reading this book and gain a great deal from it.

In this first chapter, you will discover some fundamentals about programme management and its relationship with both portfolio and project management. You will learn that the terms have yet to settle down and that they may have different meanings to different people in different situations.

While you may decide to read the book from start to finish, most people at some time will occasionally wish to dip into it to find guidance on specific topics. The information you seek will reflect your position, the organization in which you work and the issue you are facing. You will discover in this introduction how the author team has prepared this book to suit these differing interests and how to find the parts most valuable to you at any one time.

There is much you and your organization may take from this book in terms of knowledge, templates, concepts, systems and approaches. We hope that the programme management process outlined in Chapter 2 and the programme management improvement process in Chapter 16 will be exceptionally useful. These components, we hope, will support your desire to improve your organization’s maturity in programme management.

In the 1980s, the UK led the world in the emerging techniques for project management. In the first decade of the second millennium, the UK leads the world in programme management thinking. While the USA has developed thinking in project portfolio management through the Project Portfolio Management Standard initiative, the majority of the rest of the world has yet to generally adopt these ideas. We hope this book will help to spread the message and benefits of programme management throughout the world.


1.2 Why you Should Read this Book

This is a large book containing some lengthy chapters. The author team expects that readers will wish to dip into the content to find specific text, advice, guidance and value on a topic.

If you are working in an organization that runs a number of projects, and especially if those projects are designed to deliver change to your own organization, you will find this book very valuable.

If you are to play a role in the projects, or in the programme that bring the projects into a cohesive whole, or if you wish there were some way of thinking about your organization’s projects holistically, you will find this book essential reading.

If you are researching programme management, you will find that this book gives a great deal of knowledge as well as guidance to other sources of information.

We have attempted to show how organizations can deliver change in an efficient, organized and well-managed way so that the maximum benefit can be derived from its investments.

While we plan later editions of this book, we will not be able to maintain the pace of change in the emerging world of programme management. For this and other reasons, this book is supported by a website at, where you will find updated information and connections to other websites focusing on programme management.

In the view of the authors, programme management surrounds and supports project management. Programme management techniques aim to help organizations select portfolios of projects, establish organizational structures to support those projects and to extract maximum benefit from them. Project management, working within a programme management environment, delivers the specific products of those projects.

You should not expect this book to help you run individual projects. It will help you to select and define the best projects to undertake; to organize them in a holistic manner; to establish an environment within which projects may be consistently managed and to maximize the benefits your organization gains from them.

There are many other books that will help you to understand how to take a project from definition to delivery. The Gower Handbook of Project Management (Turner and Simister, 2000) is one of them.

This book is divided into four parts:

  1. Introduction to programme management: Starts by introducing the topic, the terminology and basic concepts. It then proposes a complete lifecycle for delivering maximum benefit from investment in organizational change.

  2. A supporting infrastructure: Describes the techniques and support infrastructure that will be required to deliver efficient organizational change.

  3. Programme management maturity: Describes ways of measuring and improving an organization’s ability to deliver effective change.

    Appendices: Practical and usable references to other sources of information.


While a team of six authors worked on this book, it is not simply a collection of essays. The author team worked together to design and create the content and to agree on a general layout and style. The team members took responsibility for sections where their specialist knowledge was most relevant. The book therefore is the result of a number of projects, each run by a project manager, all working within a single programme managed by a programme manager. The book is not, however, written in ‘one voice’ but does to some degree reflect the style of the author or authors of each section. The author team therefore will use the term ‘we’ to refer to the authors collectively.

We hope this book meets your needs.


1.3 An Overview of Programme Management

To understand programme management it is best to understand the history of project management, so let us begin with a short trip back into recent history.

The early days of project management by computer were mostly spent on wet and windy construction sites. Among the world’s first construction projects to use personal computers and critical path planning techniques were the Clarendon Wing at Leeds General Infirmary, UK and Hope Hospital in Manchester, UK in the early 1980s. Heavy engineering and the space race drove the need to understand how massive dams, roads, missiles, satellites and hospitals would be assembled. However, engineering project managers did not consider the reason for building the particular building or plant – they simply built them for someone else.

In the 1990s, project management techniques spread out from the wet and windy site offices of heavy engineering and the laboratories of the space industries into the cosy warm offices of high-technology industries such as information technology (IT) and telecommunications.

As project management moved into the last decade of the millennium, a much larger number of relatively small projects were being planned using project management tools. A wide range of technology-led industries had adopted both the tools and philosophies that worked so well on large physical projects.

But these technology-led projects shared resources with many other projects and with the normal business-as-usual workload, so the approaches we now group under the title of programme management emerged to address these differences. While the single project model failed to address many issues, programme management offered a way to deal with the total project workload holistically.

Around the time that the Y2K bug brought a gleam to the eye of many IT people, we saw the early days of programme management and the widest ever use of project management and planning. No longer was this exclusive to construction; in fact the technology-led industries were moving away from, and considerably outnumbered, construction users.

As the new millennium dawned, a world of resource-centric programme management started to emerge where there is much greater involvement for the team members than for the resources of the engineering worksite. Personal plans and timesheets started to form a key component of most planning systems and the Internet provided web-based tools enabling international project teams to cooperate without geographical barriers.

Governance had by this time become a popular theme as the number of projects created a need to ensure that they all follow some key processes consistently. As an example of a simple process: all projects should have a properly approved project initiation document (PID) that lays out what that project aims to achieve. PRINCE2 provided a framework for good governance.

Industry and Government began to ‘do their projects right’ but wondered if they were doing the right projects.

As the first decade of the third millennium advanced, the most significant developments lay in the emerging brand of tools and techniques that help organizations select the best projects to undertake. While some organizations still suffer from interminable delays, many organizations have improved their ability to deliver on time. But there is very little confidence among Chief Executive Offices (CEOs) and Chief Financial Officers (CFOs) that the best possible investments are being selected.

The reason for this is that the majority of today’s projects are those designed to change the host organization and to deliver benefits – what we today call change programmes. The scarcity of resource will always limit the organization’s ability to deliver change and this makes it vital for every organization to spend a little time selecting those programmes of work that will deliver the greatest benefit. That might imply selecting the development of new products or services, the relocation of facilities or rationalization of processes to improve service levels.

IT departments felt a cold wind of change and quickly perceived the need to be seen to be delivering value, so we saw a number of IT-led change programmes. From IT, both people and ideas moved into the business arena so that today we see a plethora of organization-led change programmes.

The Project Selection and Benefit Management initiative led by ProgM – the programme management specific interest group of the Association for Project Management (see Appendix B for contact details) – is a part of the drive to a new era where programme managers in both the public and private sectors will model and monitor projects in terms their benefits.

This attitude received wide support from industrial leaders and senior members of government alike. Here is a quotation from the ‘Improving Programme and Project Delivery (IPPD)’ report from the UK Government’s Office of Public Service Reform (OPSR):

That’s why the implementation of this report is so important. I am pleased that one of its key recommendations – establishing Programme and Project Management ‘centres of excellence’ within departments – has already been endorsed by the Cabinet.

Achieving this requires clear leadership from the top and better delivery on the ground. Better programme and project management (PPM) in the Civil Service has a key role to play. Of course these new centres must recruit the right people, develop programme management skills, and promote the delivery culture. I welcome the commitment to training for change and development opportunities on offer to civil servants to fulfil these requirements. (Tony Blair, UK Prime Minister, OPSR, 2003, Foreword)


Another quote comes from the same report:

Delivery is top of the Government’s agenda and better programme and project management (PPM) will improve the Civil Service capability and capacity to deliver. Research conducted by the Office of Public Services Reform (OPSR) and CMPS [now the National School of Government] shows that increasingly PPM techniques are successfully being applied to policy development and delivery, as well as traditional procurement tasks. (OPSR, 2003, Foreword)


References to these reports and other websites are included in Part IV of this book.

The government has encapsulated the relationships between change, programme and project management into a single diagram (see Figure 1.1).

Figure 1.1 The role of programme and project management Encapsulated


To learn more about the UK government initiative ‘Improving Programme and Project Delivery by Creating Departmental ‘Centres of Excellence’, visit the website from which the Figure 1.1 has been taken:


1.3.1 Definitions

Here are two definitions of programme management.

  • Programme management is the orchestration of organizational change.

  • Programme management is the coordinated management of a portfolio of projects that change organizations to achieve benefits that are of strategic importance.

The first is succinct. The second is only slightly longer and is the UK government definition, contained within Managing Successful Programmes, a publication from the Office of Government Commerce (OCG; OCG, 2003).

Organizations trying to change and improve themselves need a new concept to provide a link between:

  • investment in organizational change

  • projects delivering the capacity to change

  • the adoption of those changes

  • harvesting the benefits of those organizational changes.


Typically, a change involves contributions from many parts of the organization. There is often a significant IT component, but there are nearly always organizational issues, training and processes that must change as well.

For example, a new product launch will involve projects in manufacturing, sales, marketing, support and transport before it can deliver its benefit of increased income.

Often there are many-to-many relationships between projects and benefits. Some projects work in synergy to deliver benefit, some provide technology platforms on which other projects deliver benefits. It is rare that a single project delivers a benefit on its own. For example, it is only when the quality control procedures, monitoring software and training projects have ended that a manufacturing organization can expect to see the expected reductions in returned goods. Only after the hospital ward has been built, the equipment installed and commissioned and the staff recruited and trained will the waiting lists be shorter.

The concepts of ‘programme’ and ‘programme management’ provide an umbrella that sits over and above projects and shows the often complex links between many projects and many benefits (see Figure 1.2).

Programme management involves in selecting the best projects in which to invest, initiating and defining those projects and deriving the maximum benefit from the change. A programme is therefore the glue that brings together projects and benefits.


1.3.2 The Programme Management Cycle

A programme management cycle should follow certain stages. This is not a one-off process but a regular review of the organization, its objectives, its current workload and expectations. The primary steps are:

  1. Define the organization’s strategy: The objectives set by the senior management are laid out in terms of strategy and, wherever possible, in numerical terms. Examples include 5 per cent increase in turnover, 10 per cent decrease in wastage, 7 per cent less accidents or 6 per cent reduction in staff turnover. While financial objectives are relatively easy to define, the balanced score card and key performance indicators (KPIs) provide mechanisms to set out non-financial objectives in measurable terms.

    Figure 1.2 Relating projects, programmes and benefits



  2. Collect and evaluate candidate programmes: The organization is encouraged to come up with ideas for change and each idea joins the list of candidates. Each candidate programme will vie with others to prove itself worthy of investment.

  3. Select and prioritize candidate programmes: Each serious candidate programme is evaluated in terms of the financial and resource investments required to deliver the change; the financial and non-financial benefits expected from the change; the risk profile and timescales and especially their alignment with the delivery of the organizations stated objectives.


All existing and potential programmes are then modelled and considered in order to make a rational choice of the most desirable programmes and yet stay within the organization’s ability to deliver the changes.

This approach is so much better than the usual highly political and emotional battles over project selection.

  1. Initiate selected programmes: New programmes of work are added to current programmes and initiated in a simple but formal manner.

  2. Define projects to deliver programmes: Once the programmes have been initiated, it is relatively easy to define and initiate the projects that will deliver the capacity for change. This is a programme management role.

  3. Initiate projects: The projects are initiated and passed to the selected project managers. They understand how each project fits into and contributes to the organization’s wider aims.

  4. Manage programmes and projects: Projects are managed by the project managers and each programme by a programme manager. All should obey appropriate and workable processes such as those laid out in PRINCE2 and Managing Successful Programmes (OGC, 2003). Ideally few, if any projects, run outside of the adopted framework.

  5. Close projects: Each project ends with a deliverable to the programme manager. A new IT system, a new production facility, a trained workforce and a safety video are examples of project deliverables.

  6. Close programmes: A programme creates a new capability by combining the deliverables of a number of projects. The programme manager hands this capability to a manager within the organization. The organization then utilizes the new capability and harvests the benefits it makes possible. For example, the organization utilizes a new warehouse and benefits through reduced transportation costs.

  7. Derive and monitor benefits: The programme management team will be involved in measuring the benefits and feeding this data back into the organization, providing the basis for the next round of projects.

This is not a one-off process, but a rolling cycle. In some organizations, the cycle time is slow – up to 5 years; in many it is as short as once a quarter.


1.3.3 The Value Path

The value path (see Figure 1.3) shows how projects create deliverables that, when combined into a programme, deliver the capability to change. Only when this capability is used by the organization is a benefit actually realized. The value path supports the programme management cycle by demonstrating the objectives at each level of a programme and project management community.

Some examples follow.

  • In a specialist organization developing tools and services for programme management, the Program Management Group plc, there are a number of overlapping programmes. Numerous software development projects are conceived to provide new tools aimed at the programme management marketplace. Each of these projects will fail to deliver benefits without the testing, technical support and training workshop projects that combine into a development programme. There are further programmes aimed at improving service levels, opening new markets and reducing running costs.

  • The Standard Chartered Bank installed a telephone network across Africa. This delivered no direct benefit, but on that backbone a number of projects delivered reduced running costs and improved service levels to bank account holders, money dealers and exchangers and other parts of the banking business.

  • Syrris, a small company specializing in drug discovery, is overrun with numbers of speculative new product development programmes, each aimed at launching a diagnostic tool to the pharmaceutical market. Each new product idea is tested in terms of the required investment, expected return and risk before joining the active workload on a ‘survival of the fittest’ basis.

  • Transport for London has a portfolio of programmes, each of which creates a component of the London transport infrastructure. These programmes combine construction, ticketing, marketing and integration projects to deliver improvements to Londoners.

Figure 1.3 The value path



1.3.4 Portfolio Management

One of the major barriers to successful change programmes is the intense personal and political emotion that is involved in programme selection. Rarely is there any degree of logic; normally selection and prioritization is the result of a highly personal battle.

Portfolio management techniques tend to reduce the intense emotional and political heat by providing a more logical programme selection process. One element of portfolio management is benefit mapping. There is often a complex many-to-many relationship between programmes and benefits and benefit mapping helps to show these relationships. This technique provides a simple mechanism of graphically showing the inter-connections between projects, programmes and benefits.

A simple diagram or table showing on one side projects and on the other benefits, with programmes in the centre, will provide a clearer view of the:

  • route to benefits

  • dependencies (between projects, deliverables, facilities and benefits)

  • distribution of budget

  • distribution of responsibility.


The diagram will provide a basis for:

  • risk management

  • programme monitoring

  • budgetary control.


A diagram is included in the worked example in Appendix C.


1.3.5 Internal vs. External Programmes

Some programme management teams think in terms of internal vs. external programmes.

Internal programmes involve:

  • a controlled environment

  • internal change, for example, change related to a new internal process, reorganization, IT systems

  • relatively low risk.


External programmes involve:

  • a less controlled environment

  • a change subject to impact from environmental effects, for example, new product launch or a marketing initiative

  • relatively high risk.


It is clear that external programmes will benefit from constant monitoring of the external marketplace or environment, as this may undermine or reinforce the case for a specific programme. A health scare may terminate a new food product programme but, equally, may reinforce the case for a drug launch programme.

To enable a rational programme selection process some key areas of definition are required for every contender programme.

To enable portfolio management decision making every programme should have, long before it is accepted into the workload, certain requisites:

  • mandate – a written statement of the purpose

  • an owner and/or sponsor

  • a list of benefits:

    • – for financial benefits:

      • ‘no change’ cost or income levels over time

      • ‘post change’ cost or income levels over time


    • – for non-financial benefits:

      • measures of strategic alignment through KPIs

      • risk estimates (schedule risk, cost risk, benefit delivery risk)

      • financial investment required

      • resource requirement.




Financial benefits can easily be derived by considering the no change/post change levels. In the case of a cost reduction exercise, it is possible to model how the cost of an operation is expected to rise over time if no change is delivered. However, the costs may be stabilized or even reduced following a change programme. An example would be the running costs of a call centre when considering a programme to outsource the service offshore. A typical graph is shown in Figure 1.4. In the example, the running costs of a certain operation are expected to grow rapidly over the next four quarters. However, a change programme is expected to deliver efficiency savings such that the running costs will reduce slightly over the same time period.

In another example, the income derived from a product can be expected to reduce over time, but programmes to market or enhance the product can help to stabilize or even increase income levels.

Comparing ‘no change’ and ‘post change’ income or expenditure levels for each programme helps provide financial comparisons of programmes.


1.3.6 A Benefit Management Cycle

Figure 1.5 summarizes the cycle described below.

Starting at the highest point on the cycle we see the strategic plans that the organization has set as its targets. There are normally simple high-level statements of the organization’s objectives. In the two stages that follow, the strategy is broken down into detailed numeric data probably using both financial and KPIs for non-financial objectives. Examples of KPIs include levels of customer retention or levels of staff turnover.

Contender programmes are then examined in terms of their impact on these KPIs and financial contribution. A group of the programmes that collectively are within the organization’s ability to deliver and accept change is selected. Once each programme is initiated, the programme management teams can identify and initiate the projects that will deliver the required outcomes. The projects then create deliverables. These deliverables are combined by the programme to create a capability within the organization. The business uses the new capabilities (for example, the new warehouse, quality control system or training) and therefore delivers the associated benefits.

Figure 1.4 A typical cost of comparison graph


Figure 1.5 High Level Benefits Management Process Model – V2


Source: ProgM; developed as part of the initiative on Programme Management

Benefits are measured and where expected benefits are no longer expected or reduced, for any reason, the programme management team reports the issue.

As benefits are actually achieved the organization changes. Measurement of these improvements leads the organization to a revised strategy and the continuation of the cycle.

The inner cycle shows how the programme management team starts with benefit definition, moves on to tracking the benefits as the team move towards benefit delivery and ends each cycle assessing the benefits actually delivered.

The report supporting this is available on the programme management website at


1.4 Definitions of Programme Management and Related Terms

The OGC is a part of the UK government and has published an important publication called Managing Successful Programmes (OGC, 2003).

The publication contains this definition of programme management:

Programme management is the coordinated management of a portfolio of projects that change organizations to achieve benefits that are of strategic importance.


This definition of programme management is concerned with the delivery of organizational change. An organization that follows this definition should have established goals at an organizational level and be running one or more programmes with the intent of striving towards those objectives. Such programmes are driven by the benefits they are expected to deliver.

Another simple definition of programme management is:

The orchestration of organizational change.


There are other meanings for the term programme management, some of which do not imply organizational change, and these are discussed in Section 1.5 below.

For comparison and positioning purposes, we offer definitions of four related topics in a programme management environment: project management, change management, benefit management and project portfolio management.


1.4.1 Project Management

Project management is the delivery of pre-defined products.

It is the purpose of project management to take a project from the definition stage to delivery of previously defined products. It is the purpose of programme management to define projects and to take the products of those projects, combine them to provide the opportunity for organizational change, integrate them into the organization and deliver benefit through change. Much of this book is concerned with the delivery of beneficial change.


1.4.2 Change Management

Change management is the management of change.

At the micro level, change management involves a set of techniques used to implant new technology and processes. These might include training, roll-out processes and the human aspects known as ‘hearts & minds’ to maximize the acceptance of changes to routine.

At the macro level, change management contains ideas about what interventions to make, making them and then reviewing how these are working.

Programme management teams can regard change management as a set of techniques that are used to support project and programme work. Change management professionals can regard programme management as a technique that is essential to the delivery side of change (see Figure 1.6).


1.4.3 Benefit Management

Benefit management is a process for the optimization or maximization of benefits from organization change programmes.

There are differing views of the role programme management plays in delivering or harvesting benefits. We regard benefit management as an important part of the programme management process.

A programme should deliver to the organization the ability to change through new systems, processes and, perhaps, physical resources such as warehouses, transport or IT. For example, a programme might deliver a warehouse and a stock control system that will reduce cost and improve customer service for a distribution company

Before benefit may be gained, these new systems and other resources must be put to use through adoption into the day-to-day management of the organization. The distribution manager must adopt the new technology, make required changes to the department’s structure and deliver the benefit by running the more efficient department.

The general term for the distribution manager in the example above, that is, the person with the role responsible for taking the new functionality and delivering the benefits, would be ‘business user’.

Figure 1.6 Relating benefit, change, programme and project management


The issue is to understand the relationship between the programme management and business user. The programme management process delivers the capability for change while the business user must utilize this capability to deliver the benefit.

The business user shares responsibility with the programme management team for adoption of these new capabilities and the delivery of benefits.

In the view of the OGC, the programme team’s responsibility ends when the new functionality is handed over and accepted by the business user.


1.4.4 Project Portfolio Management

In the USA, Australasia and some parts of northern Europe, the term ‘project portfolio management’, sometimes known simply as ‘portfolio management’, has emerged. In addition, Americans tend to use the spelling program as opposed to programme, which is UK-English usage.

There is a very considerable overlap between programme management and project portfolio management. Project portfolio management seems generally in the USA to focus on change through the development and launch of new products in the business marketplace. Project portfolio management often refers to the process of selecting and prioritizing projects of work and where that is the case, the term program management is used to refer to the execution of those projects.

In the author team’s view, new product development and launch is one type of programme management. Other equally important areas are the improvement in service levels of commercial organizations (banks and other services industries); non-commercial organizations (government operations including taxation and health) and other public services.

We propose Figure 1.7 to understand the differences between the US English and UK English use of these terms.

In US terminology, the term project portfolio management refers to the whole process of delivering change from project and program(me) selection through to benefit delivery. Once program(me)s and projects have been selected, the term program management is used to describe the process of delivering the required changes.

In UK terminology, and specifically in the UK government publications in this area, the term programme management refers to the whole process of delivering change from project and programme selection through to benefit delivery.

Please refer to the glossary in Appendix A for more definitions and terms.

Figure 1.7 The relationship between US and UK terminology



1.5 Types of Programmes

This section discusses the variety of organizations and situations described as programme management to enable readers to understand their own situations in relation to other programme management environments of which they may have little or no experience.


1.5.1 Fundamental Types of Programme

Programme management has been defined in many different ways. This is to be expected, as it means different things to different organizations.

There is one common theme to all the definitions, which we propose is the starting point.

Programme management is the management of a portfolio of projects that have something in common.

The ‘something in common’ is where all the variations come from. There are some typical common threads, which are listed below. What is important for your organization is to work out how and why you choose to group projects together. You may decide that your organization has more than one of these reasons for grouping projects into portfolios or programmes. The strategically driven programme organization 

The OGC definition of programme management is:

Programme management is the co-ordinated management of a portfolio of projects that change organizations to achieve benefits that are of strategic importance.


The OGC’s guide, Managing Successful Programmes (OGC, 2003) talks about defining the long-term objectives of the organization. Once these long-term objectives are established, the organization should identify portfolios of projects that help attain these objectives and think carefully about the benefits these projects are designed to bring about.

It advises the organization to set up structures to manage the programme and keep the strategic objectives in mind. These kinds of projects are likely to change the organization itself. Examples of such programmes include relocation and expansion programmes as well as rationalization and reorganization programmes.

In this scenario, programme management must focus on delivering the benefits the organization expects, as defined in its strategy. The multi-project income-driven programme organization

For organizations in this group, programme management is directing a portfolio of projects that benefit from a consolidated approach by maximizing the output from the resources utilized on income generating work.

Jobbing engineering companies, software houses contracting for work, architectural practices and many other types of organization run many simultaneous projects, each of which results in the delivery of a product or service to a customer. They may not contribute towards the strategic corporate goals of the host organization.

Typically, the result of such a project is an output delivered to a client for payment. The common elements of the projects are that they run simultaneously, or at least overlap with each other, they share resources and are each expected to generate some income. One project’s cancellation does not necessarily change the organization’s general direction.

The primary aim here is to manage the programme of projects to generate the maximum income for every person in the pool. Such organizations are not attempting to change themselves but may be attempting to change their clients. For example, a consultancy may deliver change to their customers by improving the client’s processes. The customer-centric programme organization

The management of a portfolio of projects within an organization for the same customer.

Consider a company performing work for many customers and with a close relationship with some of those customers. The supplier organization might have a number of projects in hand for one particular customer and appoint a programme manager to coordinate the total workload for that customer. Such a programme manager will have a team of project managers, each of which is working on one or more projects for the specific customer.

Such projects need not be linked logically, but almost certainly share the same resources. They may be carried out by different teams within the contracting organization, but probably share the same functional departments. Ideas and techniques from one group may be carried over to the other groups. Specialist resources work part time on many projects.

The focus here is similar to the first scenario but programme management will concentrate on the customer’s goals, not those of the contracting organization. Common method

A coordinated approach that applies a common method, lifecycle and set of standards to improve the capability of the project management community.

The projects in this programme may have very little in common, other than they are all in the same organization.

In this situation, programme management might want to regard this as the first improvement step, but expecting to eventually get to one of the other more mature states.


Very large programmes

And finally some organizations use the term programme management to refer to very large projects. This is especially true in USA where, for example, the Moon Landing Program included a very large number of projects, all of which aimed at the same single objective, an objective eloquently expressed by J.F. Kennedy: We aim to put a man on the surface of the moon and bring him safely back to Earth before the end of the decade’. A wide range of projects, including launchers, assembly buildings, tracking equipment, the moon lander and orbiter, plus recovery and health screening systems made up a single programme aimed at this single objective.


1.5.2 Some Differences between Programme and Project Management

Table 1.1 aims to highlight some significant differences between project and programme management in an attempt to clarify the value and purpose of each set of techniques.


1.5.3 Some Differences between Programme and Project Planning

The need for planning and control is common to all programmes and projects and some differences have been observed when comparing project and programme planning. These are included to emphasize the required changes in thinking in both the planning and management of projects and programmes and to set the scene for those moving from project to programme management.

In these terms, we have compared the techniques of project planning as found on major, physical projects with programme planning as found on a portfolio of generally smaller and less physical projects.

Table 1.1 Differences between programme and project management



Less well-defined end date, some go on forever, or until a defined organization state has been achieved

Defined start and finish dates

Focus is on delivering benefits (which may be both financial and non-financial), requires involvement after projects have ended. Every programme must directly benefit the organization in some way

Focus is on delivering products. These products will be used by the operational part of the organization, but not all of them will directly produce benefits

More complex; interface with the strategy, contain many projects, drive operational change

Simpler; only have to focus on delivering defined products

Exist in a world that is constantly changing. These changes need to be constantly monitored and their impact on the programme and its projects controlled and managed

Projects are ‘ring fenced’. Change control is a more structured and easier to control activity

Macro view; have to consider the combined effect of a portfolio of projects, which should produce synergistic benefits, but sometimes conflict with each other. A balanced view is needed, which sometimes is detrimental to a few projects in the portfolio

Micro view; only concerned with delivering what has been defined, on time, in budget and to acceptable quality. Project managers are only concerned with other projects if their project is dependent on them. They will fight against any other project that threatens the success of their own project Planning timescales

The classic use of project planning is in heavy engineering. Bridges, power stations and construction projects provided the early project management tools. Their interest is predicting the demand for resources, typically, over the next few months. Project planners calculate the number of resources that they expect to be required and a separate department hires the crews.

On heavy engineering projects, foremen and charge hands direct the individual workers on a short-term basis and this work is generally not planned by project management methods. While projects may have a shorter overall duration, programmes tend to be very long. The programme planner’s role is concerned with the long-term capacity of the organization as well as the specific plans for the next few weeks or months. Complexity

Classic engineering projects are nearly always a new challenge. Each major project presents new challenges and tools and techniques are required to help the team understand the process that would be followed to assemble the deliverable. For example, critical path analysis or the critical path method is a process of modelling a project in terms of the tasks that are required and the dependencies between those tasks. Much of critical path thinking stems from a need in the 1960s for the Polaris project team to understand the logical process of construction and assembly that would lead to a working missile.

Projects within programmes generally follow a defined and distinct pattern. Many projects are run under a methodology that precisely spells out the process in great detail. The problem in programme management is rarely one of understanding the process, but of scheduling the resources against time, other projects and non-project workloads. Multiple projects

Large engineering projects tend to be isolated. The planning problem is to maximize the efficiency of the teams of workers on the one single project. The complexities of multi-projects are not considered, as they do not exist. There is no need to think about cross-project conflicts, multi-project resource optimization or a whole host of elements that have come to the fore as project management has spread into a world where many projects progress within the same organization against a background of non-project work.

Typically, on a single project, the timescale and objectives are set contractually. The team need to know what resources will be required to achieve these goals. In the multi-project environment, the resource pool is much more stable and the team need to prioritize the work load to keep the resource fully occupied and to finish projects as early as possible. Resources

Engineering project management focuses on classes of resources. Planners tend to deal with numbers of welders, bricklayers and labourers. The histogram is a tool to demonstrate how many of a type of resource will be required and to help reduce the peak demands for each class of resource in the interests of economy.

Within programmes, planners tend to deal with individuals. There are individuals with many skills that may be used to meet the needs of the many projects. In programme management, histograms are less useful, as the requirement is to show how many hours per day a person needs to work on each project or programme. The working day

Labourers, bricklayers and welders normally work full time on the one project in which they are involved at any one time. In programmes of projects, it is very rare that anyone works full time on any one project. Many projects vie for each resource’s time with the non-project workload and other administrative jobs. Physical projects

Engineering projects allow for a simple way of achievement monitoring through simply counting the bricks or pipe-lengths; the physical achievements on the project. There is often a physical measure of progress. A relationship between what has been achieved and what remains to be achieved can often be calculated in quantitative terms. Most projects within programmes work towards non-physical deliverables. Where there are physical deliverables, measures of progress tend to be qualitative rather than quantitative. It is difficult to accurately measure progress towards a software product, a reorganization or marketing project except by an artificial measure such as metrics. Measures of achievement at the task level are rarely of any value in helping to understand the remaining work. Hence the need for timesheet recording systems that aim to measure time spent and estimates to complete.

There are exceptions to this general principle. For example, consider a training project that is a part of implementation programme, It will be possible to monitor the number of people trained and the number remaining to be trained. Quantitative measures should be used to monitor progress where they are appropriate. However, they will be normally significant parts of a programme where only qualitative measures are available. Conclusion

There is a widening gap between the management, planning and control of large engineering projects and change programmes. There is clearly a need to plan each project regardless of its nature. However, the need for planning each project in a programme is subordinate to the need to plan in light of all projects within the programme. This is especially true where projects share resources and this is normally the case in programme management.

Therefore we propose a separation of the terms project and programme planning as follows:

  • Project planning is mostly relevant to large engineering projects where physical projects are executed and where resources are only rarely shared with other projects.

  • Programme planning is mostly concerned with the planning of multiple, high-technology, non-physical projects sharing, predominately, human resources.



1.6 Change Programmes: The Focus of this Book

The focus of this book is on benefit-driven change programmes – the author team’s meaning of programme management. This includes issues that may be superfluous to those readers managing a portfolio of projects for purposes other than change, but this approach ensures that most readers will be able to find what they need.


1.7 Benefits of Programme Management

We have observed huge benefits on organizations that have adopted programme management thinking and methods. These benefits of programme management can be grouped into two broad headings. These are not mutually exclusive and many organizations have gained through both approaches.


1.7.1 Top-Down Approach

Many organizations using programme management techniques define organizational objectives and then define programmes of projects to deliver the changes – the full meaning of programme management. Such organizations benefit by:

  • choosing the projects that will deliver maximum or optimal benefit and yet are collectively within the organizations capability to deliver;

  • prioritizing those projects that deliver the greatest benefit and that most closely align with strategy;

  • eliminating the projects that will not deliver a benefit or that do not align with the organization’s strategy.


Such organizations will have Programme Boards charged with delivering specific changes to the organization and will carefully select the best projects by comparing the required investment with the expected benefits.

Such organizations will have visibility across a wide portfolio of projects and programmes and will have confidence that all initiatives are being developed in a broadly similar way with similar processes and check points.


1.7.2 Bottom-Up Approach

Here, the organization is running a portfolio of projects and feels a need to coordinate them. The organization wishes to ensure that projects are managed in a consistent manner using shared processes and procedures. Such organizations will have a Programme and Project Support Office that maintains standard forms and processes that every project should follow. There will be processes for starting and closing projects and for requesting and releasing resources for the project teams. There will be a standardized approach to reporting on the progress of each project.

Such organizations will see the benefit of programme management in the following ways:

  • there will be a consistent approach to projects that will tend to support improved delivery;

  • there will be fewer failed projects;

  • resources will be allocated to work in a rational manner such that prioritized projects meet least resource bottlenecks;

  • it will be possible to monitor all projects in a similar manner so that the programme and senior management teams will be able to take tactical decisions based on accurate data.



1.8 How to Use this Book

This book is not a cook book, but a set of guidelines or a ‘toolbox’.

Pragmatism needs to be exercised in its use, and a solution right for one place, one situation or one organization may not necessarily fit elsewhere. We cannot therefore fail to remind you to ‘bring your brain along’. Attempts to blindly apply these techniques can be ‘foolish consistency’. To quote Ralph Waldo Emerson: ‘foolish consistency is the hobgoblin of little minds!’

This book aims to cover a wide range of the key topics of programme management and recognizes that:

  • different organizations have different needs;

  • different organizations have different levels of programme management maturity;

  • there are a wide range of roles that the reader may play.


Therefore the following paragraphs lay out the content of the book so that a reader may easily locate specific content.


1.8.1 Part I: Introduction to Programme Management

  • Chapter 1 – Introduction: The chapter you are now reading.

  • Chapter 2 – The programme management process: Chapter 2 proposes an overall process for defining, communicating and delivering change – most relevant to those in a change-orientated programme management environment. It is a comprehensive and detailed examination of the programme management lifecycle from initial consideration to closure. It explains how some organizations will find it appropriate to select components of this process. Chapter 2 examines the major steps of the programme management process as follows:

    1. Start-up: Where the opportunities and approaches for change are evaluated to decide whether or not to undertake the work required to define a programme.

    2. Define programme: Where the programme is defined, documented and evaluated to create a programme definition document (PDD) and a programme business case. When the PDD and business case are approved the programme moves to step 3.

    3. Establish programme: Where the resources, infrastructure and control processes required to achieve the programme’s objectives are acquired and implemented. Also where programme team members and stakeholders are trained and informed of their roles and responsibilities.

    4. Manage programme: Where the projects comprising the programme are undertaken and outputs delivered to business users.

    5. Closure: Where, once all the programme (and its projects) deliverables have been completed and responsibility for operational control of the improved capability has been handed over to line management, and sufficient benefits measure has been completed to judge success, the programme is terminated.


Chapter 2 is designed to help an organization to establish practical processes and is therefore different to most other sections. It is brief and specific to the point of terseness.


1.8.2 Part II: A Supporting Infrastructure

To support a practical programme management lifecycle, the organization will need to set in place a number of supporting structures. The size, style and precise role of these supporting structures will vary as will the level of maturity at any specific point in time. Part II therefore explains the organizational issues and topic areas that support the process of programme management. It lists these supporting structures and explains where they relate to benefit-driven programmes and to portfolios of projects. Part II comprises the following chapters:


Part II is intended to outline the need for, style of, and alternative ways of providing the possible range of support.


1.8.3 Part III: Programme Management Maturity

Part III recognizes that every organization has achieved its own level of maturity in the key programme management functions. It recognizes that each organization has its own ambitions and requirements to improve on its maturity in these key areas.

This part explains the concept of the Programme Management Maturity Model (PMMM) in Chapter 15 and the Programme Management Improvement Process (PMIP), a process by which an organization can define its own maturity, consider and select requirements for improvement in maturity and set about delivering those improvements in Chapter 16.

The PMMM provides a widely used benchmarking process that an organization can use to evaluate its own strengths and weaknesses in 10 key areas of programme management in comparison with a wide range of other organizations that have used the same benchmarking process.

The PMIP assumes that an organization has been evaluated by use of the PMMM and wishes to improve its programme management maturity. The PMIP lays out the processes and structures that an organization should establish to achieve one of five levels in each of the ten key areas of programme management.

Therefore the PMIP allows an organization to plan the most beneficial programme management improvements it can make and a sequence of improvements over time to deliver improving programme management maturity.


1.8.4 Appendices

The appendices contain a glossary of terms, references to other sources of information and a worked example of a programme definition document.


1.9 Conclusion

We, the team of authors, sincerely hope that you will benefit from this book and be able to deliver benefit to your own organization.

You might use elements in Chapter 2 to help establish or improve the programme management process within your organization. You may find in Part II advice that will help you to support your organization’s efforts to provide an environment within which project and programmes can proceed effectively. You might use Part III to identify and plan improvements to your organization and Part IV will lead you towards other sources of help and advice.

You may use this book to develop your own skills and therefore your own effectiveness.

We, the authors, have gained a great deal from writing this book and hope you gain as much or more from reading it.


[1] PRINCE2 is a widely used methodology, sponsored by the UK Government’s Office of Government Commerce (OGC). PRINCE® is a registered trade mark of OGC.

[2] The programme office typically has a major responsibility with respect to such ‘programme-level’ functions – see Section 3.4.6 ‘Programme support’.

[3] These statistics are based upon information within the databaes of the Programme Management Maturity Model, described in Chapter 15.

[4] Key points are typically, end of Start-up stage, approve the brief; end of Define stage, approve the programme definition and permission to start first tranche; end of each tranche, permission to close that tranche and start next tranche; Closure stage, permission to close programme, see Chapter 2 ‘The programme management process’ for more details.

[5] Gateway Reviews are independent checks of major public-sector programmes organized by the UK’s OGC. Such reviews must be conducted at key stages to ensure that the programme still makes good business sense, before it proceeds to the next stage. The ‘Level 4’ Review veritifies that a programme is ready to ‘go live’ and that the Business Case still stands up. The subsequent ‘Level 5’ Review takes place after ‘go live’, to confirm that all necessary arrangements are in place to maximize the benefits achieved from the programme.

[6] ‘Getting Better Value From IT Investments’, organized by ProgM and PROMS-G, 10 April 2003, Inmarsat Conference Centre, London, UK. PROMS-G is the Project Management Special Interest Group of the British Computer Society (BCS) and ProgM is the joint Programme Management Special Interest Group of the BCS and the Association for Project Management

[7] This table is created by copying information from the Gantt chart, which has been prepared in the Microsoft Project program, into a Microsoft Excel® spreadsheet. A pivot table is way of quickly sorting large amounts of data. Its rows and columns can be rotated to show different summaries of the data, and it can display the details of areas of interest.

[8] A definition provided by the UK’s Office of Government Commerce (OGC) in its Successful Delivery Toolkit (2005).

[9] For further guidance on this technique see Vase, 1999.

[10] Change control should not be confused with organizational change management, which is the responsibility of the change manager and is discussed in Section 5.7.1 ‘The change manager’.

[11] In the UK, building societies provide savings bank and housing mortgage services to the general public. Originally they were mutually owned by their depositors and lenders, but over recent years many have converted themselves into joint stock companies or been taken over by major banks. In the USA, similar services are provided by ‘savings and loans’ organizations.

[12] Numbers in square brackets [ ] are references to documents that are identified in the List of References in Section 1.7.

[13] Of course, while a particular programme may be unique to the business unit experiencing it, the programme may have similarities with programmes undertaken elsewhere or earlier programmes undertaken within the same organization. Thus there may be pools of experienced staff who have already faced and resolved similar issues and challenges elsewhere. This is one reason why organizations engage external consultants with prior experience to play leading roles within their programmes.

[14] The web site lists 47 different interpretations of the acronym FM, including ‘Foreign Minister’, ‘Fault Management’ and ‘Filosofian Maisteri’ (the Finnish equivalent of a master’s degree).

[15] In many corporate cultures such delay would be in the interests of the programme or project, since any indication of difficulty results in a flurry of demands by senior management for meetings, information and progress reports which consume so much time and effort that the eventual delay is even greater than might otherwise have been the case.

[16] For a list of books by Maslow see For a summary of his hierarchy of needs theory and other theories of motivation see Kakabadse et al. 1987.

[17] Nowadays, creating such a portal is relatively easy. For example, ProjectPlace will allow a readymade portal to be rented. Details of ProjectPlace can be found at

[18] A number of such tools are readily available, including Survey Shack, which can be accessed via the Internet at

[19] See Chapter 2 of this handbook for a description of the various stages in the programme lifecycle.

[20] Change control should not be confused with organizational change management, which is the responsibility of the organizational change manager and is discussed in Section 5.7.1 ‘The organizational change manager’.

[21] COE Information Pack v3.1 (© Crown copyright OGC April 2004,

‘Perhaps the most significant aspect of a COE that differentiates it from a programme or project support office is the relationship it has with the department’s Management Board. A COE should provide the Management Board with strategic oversight of the department’s portfolio of programmes and projects. This “helicopter view” will bring visibility to the interrelationships and interdependencies across the portfolio and support the Management Board in its judgements and decision-making on strategic priorities and commitments.’

[22] SMART – Specific, Measurable, Actionable, Realistic, Timely.

[23] The Sarbanes–Oxley Act (2002) compelled all United States registered companies to make an annual public attestation to the completeness and effectiveness of their regimes of financial control. Basel II (International Convergence of Capital Measurement and Capital Standards: A Revised Framework) defines new regulations to be adopted by the world’s largest economies, for the calculation of capital to be held by banks and similar financial institutions. International Accounting Standards provide common approaches to corporate accounting throughout the world. All three legislative and regulatory changes are far reaching and highly complex.

[24] ‘2002 Programme Management Survey’, summary and details available from



OGC (2003) Managing Successful Programmes: Delivering Business Change in Multi-project Environments. Second edition. London: The Stationery Office.


OPSR (2003) ‘Improving Programme and Project Delivery’, available from:


Turner, J. Rodney and Simister , Stephen J. (2002) Gower Handbook of Project Management. Aldershot: Gower.

Submit your own content for publication

Submit content