APM Introduction to

Programme Management
Second edition
APM Introduction to
Programme
Management
APM Introduction to
Programme
Management
Second edition

Association for Project Management

 Association for Project Management
Ibis House, Regent Park
Summerleys Road, Princes Risborough
Buckinghamshire
HP27 9LE

© Association for Project Management 2016

All rights reserved. No part of this public­a­tion may be repro­duced, stored in a retrieval system, or
trans­mit­ted, in any form or by any means, without the express permis­sion in writing of the
Association for Project Management. Within the UK excep­tions are allowed in respect of any fair
dealing for the purposes of research or private study, or criti­cism or review, as permit­ted under
the Copyright, Designs and Patents Act, 1988, or in the case of repro­graphic repro­duc­tion in
accord­ance with the terms of the licences issued by the Copyright Licensing Agency. Enquiries
concern­ing repro­duc­tion outside these terms and in other coun­tries should be sent to the Rights
Department, Association for Project Management at the address above.

British Library Cataloguing in Publication Data is avail­able.

Paperback ISBN: 978-1-903494-58-5
eISBN: 978-1-903494-59-2

Cover design by Fountainhead Creative Consultants

Typeset by RefineCatch Limited, Bungay, Suffolk
in 11/14 Foundary Sans
 Contents
List of figures and tables vii
Foreword viii
Acknowledgements x
Introduction and purpose of guide xi
Programme manage­ment – an over­view xii
1 Programmes and programme manage­ment 1
1.1 What is a programme? 1
1.2 What is programme manage­ment? 4
1.3 Programme manage­ment and stra­tegic direc­tion 5
1.4 How do programmes differ from projects? 7
1.5 How do programmes differ from port­fo­lios? 9
1.6 How do we run a programme? 10
1.7 Who runs a programme? 13
1.8 How programmes deliver bene­fits 15
1.9 What chal­lenges are faced? 16
2 The programme life cycle 19
2.1 A high level programme manage­ment life cycle 19
2.2 Life cycle strategy consid­er­a­tions 20
2.3 Programme life cycle governance 24
2.4 Programme concept phase 24
2.5 Programme defin­i­tion phase 26
2.6 Programme deliv­ery phase 29
2.7 Programme closure phase 37
3 Programme assess­ment 41
3.1 Models 41
3.2 Organisational governance 44
3.3 Management control 46
3.4 Benefits manage­ment 47
3.5 Stakeholder manage­ment 48
3.6 Risk manage­ment 50
3.7 Financial manage­ment 53

v
Contents

3.8 Resource manage­ment 54

3.9 Summary 55
Glossary 57
References 63
Index 65

vi
 Figures and tables
Figures
1.1 Programme manage­ment in rela­tion to organ­isa­tional strategy,
port­fo­lio manage­ment and project manage­ment 5
1.2 Programme governance, control and assur­ance over­view 11
1.3 P3M3® frame­work 12
1.4 The rela­tion­ship between projects, programmes and bene­fits 17
2.1 Programme life cycle repres­ent­a­tion 19
2.2 Change programme vs. steady-state activ­it­ies 20
2.3 Conceptual repres­ent­a­tion of programme change journey
showing valid­a­tion and veri­fic­a­tion rela­tion­ships 21
2.4 Typical programme tensions to be addressed 23
2.5 Concept phase over­view 25
2.6 Definition phase over­view 27
2.7 Tranches and projects with the deliv­ery phase 28
2.8 Delivery phase over­view 30
2.9 Closure phase over­view 38
3.1 Key stake­holder rela­tion­ships between projects, programmes
and port­fo­lios 48
3.2 Sources of programme risk 51
3.3 Programme risk sources, mech­an­isms and treat­ment processes 52

Tables
1.1 Summary of key differ­ences between programmes and projects 8
1.2 Roles and respons­ib­il­it­ies in a programme 14
2.1 Different programme life cycle stra­tegic approaches 22

vii
 Foreword

Nearly a decade ago, APM published APM Introduction to Programme

Management. At that time I had just been appoin­ted Chair of the Olympic
Delivery Authority charged with deliv­er­ing the London Olympics 2012: the
ques­tion on many people’s lips was “Does Britain have what it takes to deliver
such an ambi­tious programme given the percep­tion of perform­ance on major
public sector programmes?” The answer is one more notch in the history of
achieve­ments that this country can lay claim to.
The field of programme and project manage­ment is both as old as time itself
and also a young profes­sion. When I started my career, project manage­ment was
‘just a part of’ whatever profes­sion you happened to be in – too often with
inglori­ous consequences for deliv­ery that have lodged in the percep­tions of
many. Times have changed and now profes­sion­al­ism in project manage­ment has
made success­ful deliv­ery the expec­ted norm. Recognition that programme
manage­ment is much more than ‘just big project manage­ment’ is a relat­ively
recent concept. The success of the London 2012 Olympics, and the ‘Learning
Legacy’ shared with the world, has stim­u­lated interest and progress in this field,
most recently exem­pli­fied on Crossrail. These programmes are not so much a
pinnacle of success as the begin­ning of the greatest proposed invest­ment in
infra­struc­ture ever seen in this country. The National Infrastructure Plan sees a
forward port­fo­lio of work that will chal­lenge our global skills to deliver – a
chal­lenge we must rise to if we are to achieve the growth and prosper­ity we owe
to those who follow us.
While my career has been predom­in­antly in infra­struc­ture, the world of
programme manage­ment stretches way beyond these limit­ing bound­ar­ies.
Wherever change is required to deliver bene­fits to an organ­isa­tion or society,
there you will find a demand for programme manage­ment skills to realise the
outcomes sought rather than simply deliver constitu­ent project outputs that do
not quite achieve expect­a­tions. One can see, in the worlds of IT and defence,
examples beyond infra­struc­ture of both success and failure at programme level
that build on success­ful project deliv­ery.
This update to APM Introduction to Programme Management brings new
insights as to what programme manage­ment is all about. It is an ‘easy read’ for the

viii
 Foreword

top exec­ut­ives, for those relat­ively new to programme manage­ment who have a
thirst for know­ledge and for the project manage­ment community who should,
and need to, under­stand how their project manage­ment skills play into the
‘bigger picture’. To all of you, in whatever field you prac­tise your profes­sion, you
owe it to your clients, your successors and yourselves to make sure your work
deliv­ers the outcomes society expects from you; under­stand­ing the programme
manage­ment context in which you operate will help you achieve this.

Sir John Armitt

ix
 Acknowledgements

Sponsor: Dr Edward Wallington, chair­man, Programme

Management Specific Interest Group (ProgM SIG)
Document manager: Andrew Kelleher
Second edition authors: Andrew Gray, Andrew Kelleher, Alan Macklin CBE,
Dr Edward Wallington

Thank you to ProgM SIG members, and those from the other specific interest
groups (SIGs) who reviewed the early drafts, includ­ing: Risk SIG – Kenneth
Evans; Enabling Change SIG – Martin Taylor, Simon Williams and Elisabeth
Goodman; Portfolio Management SIG – Stephen Parrett; and ProgM SIG – Merv
Wyeth.

This second edition is also dedic­ated to the memory of Paul Rayner, past chair­man
of ProgM and the APM Programme Management Specific Interest Group, and
lead author of the first edition.

x
 Introduction and purpose
of guide

The first edition of APM Introduction to Programme Management was published

over a decade ago and this aspect of the project manage­ment profes­sion has
come a long way in that short time. The purpose of this guide is to give the reader
an insight into programme manage­ment – what a programme is, how it func­tions
and how to view it. And who is the reader? Our target audi­ence is those who
are relat­ively new to programme manage­ment: an inter­ested stake­holder seeking
to engage with a programme about to have a major impact on their life; someone
joining a programme team who wants to under­stand the funda­mental prin­ciples
of programme manage­ment; or a member of a project manage­ment team seeking
to under­stand how they should inter­act with a programme – this guide is for
you and for anyone like you. This is not a guide for programme manage­ment
experts – but for anyone less than an expert, this guide should offer you value
through its insights or through the oppor­tun­it­ies it gives you to compare your
first-hand exper­i­ences with a ‘typical’ programme, and thereby gives you the
oppor­tun­ity to chal­lenge what you see going on around you.
Programme manage­ment is not about deliv­er­ing large and complex projects;
it is about deliv­er­ing change – in the phys­ical, profes­sional, busi­ness, soci­etal
or organ­isa­tional envir­on­ment. This public­a­tion will help you to under­stand
the organ­isa­tional and stra­tegic context in which programmes exist, and the
differ­ences and rela­tion­ships between port­fo­lios, programmes, projects and
‘business-as-usual’ activ­it­ies, and it high­lights some of the keys to under­stand­ing
success­ful programme deliv­ery.
APM Introduction to Programme Management 2nd edition is divided into
three sections. Section 1 provides an over­view of programme manage­ment, and
Section 2 seeks to explain programme manage­ment from the outside looking in
through the programme manage­ment life cycle. Section 3 aims to offer the reader
some concep­tual frame­works and insight into what a programme manager should
be think­ing about in order to optim­ise the prospects of success and avoid the trap
of being drawn into another level of project manage­ment.

xi
Programme manage­ment –
an over­view

As programme manage­ment prac­ti­tion­ers engage with our expand­ing share of

the world, it becomes ever more chal­len­ging to satisfy stake­hold­ers while
deliv­er­ing value and bene­fits in a new and unfa­mil­iar global envir­on­ment.
Programme profes­sion­als find them­selves oper­at­ing in complex envir­on­ments
grap­pling with prob­lems asso­ci­ated with climate change, tech­no­lo­gical advances,
glob­al­isa­tion, sustain­able devel­op­ment, over­pop­u­la­tion, secur­ity and economic
regen­er­a­tion and growth, as well as bring­ing about change and trans­form­a­tion in
organ­isa­tional perform­ance. Meeting these chal­lenges requires a system­atic
approach, imple­men­ted in a controlled envir­on­ment that is founded on sound
prin­ciples, prac­tices and tools.
Programmes endeav­our to deliver change by bring­ing related projects and
activ­it­ies together in order to manage their rela­tion­ships, whilst main­tain­ing a
stra­tegic view of the work in order to align and coordin­ate it in support of specific
busi­ness strategies. Programmes provide a bridge connect­ing indi­vidual projects
to a rapidly chan­ging busi­ness envir­on­ment and often a constantly evolving
strategy. Programmes are there­fore a key deliv­ery mech­an­ism for stra­tegic
object­ives.
Organisations bene­fit­ing most signi­fic­antly from programme manage­ment
approaches will normally be those seeking to deliver bene­fic­ ial and sustain­able
change to an organ­isa­tion or society in line with a defined strategy. Where there
is change there will be complex­ity, uncer­tainty, risk, many inter­de­pend­en­cies to
manage and conflict­ing prior­it­ies to resolve. By employ­ing sound programme
manage­ment policy and prac­tices (as opposed to just project manage­ment)
consid­er­able advant­ages can be achieved, for example through clearer
manage­ment focus on the deliv­ery of outcomes and real­isa­tion of bene­fits.
Programme manage­ment allows the many aspects of the busi­ness envir­on­ment
to be abstrac­ted away from the indi­vidual compon­ent projects, allow­ing the
project manager to focus on deliv­er­ing the project.
Programme manage­ment is still an emer­ging discip­line for deliv­er­ing trans­
form­at­ ional change, playing a pivotal role in managing the trans­ition of the

xii
 Programme manage­ment – an over­view

solu­tions developed and delivered by projects into busi­ness oper­at­ ions to realise
bene­fits, thus provid­ing the crucial link between strategy and deliv­ery. Where
the tools, approaches and mind-sets of prac­ti­tion­ers are well developed for
project manage­ment, those for programme manage­ment are still devel­op­ing:
this is an area of oppor­tun­ity.

xiii
 1

Programmes and
programme manage­ment

1.1 What is a programme?

APM Body of Knowledge1 defines a programme as: “A group of related projects
and change manage­ment activ­it­ies that together achieve bene­fic­ ial change for an
organ­isa­tion.”
Programmes are about making lasting change in a controlled manner, so to
under­stand programmes we first need to under­stand change and change
manage­ment. APM Body of Knowledge1 states that “change manage­ment is a
struc­tured approach to moving an organ­isa­tion from the current state to the
desired future state’. This recog­nises that the conver­sion of outputs into outcomes
and bene­fits invari­ably requires some form of busi­ness or soci­etal change. Implicit
in this is the import­ance of enga­ging and influ­en­cing the indi­vidu­als (stake­hold­
ers) involved. People will respond to change in various ways, and resist­ance to
change is a natural phenomenon. Managing change in a struc­tured and controlled
manner, and in a way that promotes open dialogue with stake­hold­ers is essen­tial
if the bene­fits in a busi­ness case are to be real­ised.
The growing scale of change, the need to respond quickly to chan­ging
busi­ness envir­on­ments and the impact of new tech­no­lo­gies has led many organ­
isa­tions to adopt programmes as the means of achiev­ing organ­isa­tional and
stra­tegic change. Programmes are tempor­ary manage­ment struc­tures designed
to help organ­isa­tions to achieve specific object­ives.
The success­ful deliv­ery of change relies on a system­atic approach that
manages the rela­tion­ships, depend­en­cies and inter­faces across the organ­isa­tion.
This is integ­ral to the success­ful deliv­ery of change and the bene­fits expec­ted to
be delivered during the change and onwards once delivered. Change occurs
across multiple projects, and may incor­por­ate business-as-usual activ­it­ies within

1
APM Body of Knowledge 6th edition (2012), avail­able from the Association for Project
Management, https://www.apm.org.uk/BOK6

1
APM Introduction to Programme Management

the programme scope, and this needs to be coordin­ated to ensure success. Thus
a programme2 of change is required, and this needs to be managed to support
stra­tegic direc­tion and bene­fits real­isa­tion.

1.1.1 Features of a programme

Programmes may vary in size, type and struc­ture, and how they are applied;
however, programmes gener­ally display a similar set of char­ac­ter­ist­ics, as
follows:

n Their purpose is to deliver the capab­il­ity to make stra­tegic, signi­fic­ant or step

changes to organ­isa­tions, or to an organ­isa­tion’s busi­ness activ­it­ies, or to an
envir­on­ment that an organ­isa­tion is seeking to support – normally referred to
as, or meas­ured by, bene­fits.3
n The need for signi­fic­ant improve­ment will be consist­ent with the organ­isa­
tion’s strategy, and programmes will help to deliver elements of that strategy.
n The real­isa­tion of the desired bene­fits will be achieved only through the
coordination and success­ful comple­tion of a number of compon­ent projects
and, frequently, their incor­por­a­tion into business-as-usual.
n Different parts of an organ­isa­tion or differ­ing organ­isa­tions may be affected by
the programme.
n The overall measure of success will be determ­ined by the actual deliv­ery of
the expec­ted bene­fits, which frequently involves the use of capab­il­it­ies
or facil­it­ies created by the programme in an on-going, ‘business-as-usual’
manner.

APM Body of Knowledge states that “programmes invari­ably involve signi­fic­ant

change. This needs to be coordin­ated across multiple projects and business-as-
usual units”. This need to manage and coordin­ate a programme will be discussed
in Section 2.

2
In some coun­tries the US spelling – program – is normally used, whereas in the United Kingdom
this spelling usually refers to soft­ware instruc­tions (e.g. a ‘computer program’).
3
Sometimes bene­fits are referred to as outcomes or as busi­ness bene­fits. For brevity, the term
‘benefit’ will be used through­out this public­a­tion. Further guid­ance on bene­fits and their
manage­ment can be found in Section 3.4.

2
 Programmes and programme manage­ment

1.1.2 Types of programme

As the mech­an­isms by which organ­isa­tions deliver their strategies, programmes
are as varied as the organ­isa­tions that initi­ate them and the strategies they seek to
fulfil. There are many types of programme of change, for example related to
inform­a­tion tech­no­logy (such as rolling out a new tech­no­logy plat­form), organ­
isa­tional change (such as during a merger of two organ­isa­tions or an internal
restruc­ture), civil engin­eer­ing (such as opening a new road) or product devel­op­
ment (such as intro­du­cing a new mobile phone to the market).
Programmes of change are applied across differ­ent industry sectors, includ­ing
govern­ment, tele­com­mu­nic­a­tions, finance, trans­port, energy, manu­fac­tur­ing,
defence and util­it­ies, to name a few. As such, programme manage­ment as a
change deliv­ery mech­an­ism is now in wide­spread use, although matur­ity levels in
differ­ent sectors and differ­ent organ­isa­tional types will vary.
Programmes can also be thought of as busi­ness change or trans­form­a­tion
programmes, in that they seek to change some aspect of an organ­isa­tion, or even
the organ­isa­tion itself.

1.1.3 Other inter­pret­a­tions and uses of the term ‘programme’

The term ‘programme’ can mean differ­ent things to differ­ent people. Programmes
come in all shapes and sizes, and the term ‘programme’ is applied to many
differ­ent struc­tures. Thus its use and meaning can vary widely across industry
sectors and busi­ness cultures.
For example, in the construc­tion industry ‘programme’ often refers to the
timetable of activ­it­ies that must be completed (the sched­ule), whilst ‘programme
manage­ment’ can refer to the process of integ­rat­ing separ­ate project sched­ules.
As an example, on a large engin­eer­ing project there may be several contract­ors,
each managing a range of subcon­tract­ors – all of whom will produce their own
separ­ate sched­ules of work, referred to as ‘programmes’ – and the integ­ra­tion of
these many sched­ules into a coher­ent master sched­ule would be called
‘programme manage­ment’.
Also in the construc­tion, util­it­ies and heavy engin­eer­ing indus­tries the term
‘programme manage­ment’ is often used by contract­ing organ­isa­tions to refer to
a port­fo­lio of projects that benefit from a consist­ent or integ­rated form of
manage­ment. These projects typic­ally result in deliv­er­ables created by a
contractor for a client organ­isa­tion in exchange for payment, and there­fore the
contractor has a limited interest and influ­ence over the deliv­ery of bene­fits.

3
APM Introduction to Programme Management

1.2 What is programme manage­ment?

APM Body of Knowledge defines programme manage­ment as “the coordin­ated
manage­ment of projects and change manage­ment activ­it­ies to achieve bene­fi­cial
change”.
Although we focus on the APM Body of Knowledge defin­i­tion in this
public­at­ ion, it is worth noting that other defin­i­tions of programme manage­ment
are avail­able from bodies such as AXELOS (https://www.axelos.com/best-
practice-solutions/msp).
Because programmes are the method by which change is delivered in pursuit
of stra­tegic object­ives, programme manage­ment provides a manage­ment
inter­face between those respons­ible for decid­ing strategy and those
respons­ible for managing the compon­ent projects and other activ­it­ies.
Programmes deliver improve­ment and change that will success­fully achieve the
desired outcomes, thus estab­lish­ing the envir­on­ment for gener­at­ing bene­fits
aligned to the organ­isa­tion’s object­ives within the organ­isa­tion’s cultural and
economic envir­on­ment.
Typical programme manage­ment respons­ib­il­it­ies include:

n select­ing, initi­at­ing and monit­or­ing the compon­ent projects that make up the
programmes, includ­ing defin­ing the scope of indi­vidual projects;
n progress­ively devel­op­ing and re-validating a sound busi­ness case;
n managing the expect­a­tions of key stake­hold­ers and enga­ging their support;
n managing risks asso­ci­ated with the internal and external envir­on­ments;
n coordination between compon­ent projects and synchron­isa­tion of depend­
encies;
n managing programme change, such as cancel­ling projects or chan­ging the
scope of projects in reac­tion to changes in the organ­isa­tion’s strategy or
envir­on­ment;
n coordination of business-as-usual activ­it­ies where they fall within the defined
scope of the programme;
n identi­fy­ing, support­ing, meas­ur­ing, monit­or­ing and managing the real­isa­tion
of bene­fits.

In summary, programme manage­ment provides a layer of manage­ment, above

that of the compon­ent project manage­ment teams, focused on defin­ing, integ­rat­
ing and coordinating the projects to maxim­ise the value of the combined

4
 Programmes and programme manage­ment

Figure 1.1 Programmes in rela­tion to organ­isa­tional strategy, port­fo­lios and

projects (adapted from APM Body of Knowledge 6th edition)

deliv­er­ables of the compon­ent projects into fully usable capab­il­it­ies that may be
used to deliver the desired bene­fits and to realise stra­tegic object­ives.
For complete­ness, Figure 1.1 above shows the rela­tion­ship between
programme manage­ment, project manage­ment and port­fo­lio manage­ment. The
latter are defined as follows (defin­i­tions from APM Body of Knowledge):

n Project management is the applic­a­tion of processes, methods, know­ledge,

skills and exper­i­ence to achieve the project object­ives.
n Portfolio management is the selec­tion, prior­it­isa­tion and control of an organ­
isa­tion’s projects and programmes in line with its stra­tegic object­ives and
capa­city to deliver. The goal is to balance change initi­at­ives and business-as-
usual while optim­ising return on invest­ment.

1.3 Programme manage­ment and

stra­tegic direc­tion
Strategic plan­ning and setting the direc­tion for an organ­isa­tion is funda­ment­ally
differ­ent from oper­a­tional manage­ment. Senior managers and exec­ut­ives deal
with uncer­tainty and ambi­gu­ity as they set stra­tegic direc­tion, and then adapt this

5
APM Introduction to Programme Management

to address changes and chal­lenges in the envir­on­ment the organ­isa­tion is

oper­at­ing in and its direc­tion of travel. Whereas, at a project level, project
managers operate with clarity of purpose, for example around cost, times­cale
and quality targets as defined by the single project.
When project managers work with senior managers these differ­ences in
view­point and approach can cause fric­tion as the expect­a­tions of both parties can
be funda­ment­ally differ­ent. Programme management teams operate between
direct­ors (strategy focus) and project managers (deliv­ery focus). Programme
managers’ skills are in under­stand­ing the stra­tegic direc­tion of the organ­isa­tion,
ensur­ing that there is an align­ment of the suite of projects to support the busi­ness
object­ives, working in an uncer­tain envir­on­ment and respond­ing to change with
a constant focus on achiev­ing bene­fits.
When collec­tions of differ­ent projects are used to move an organ­isa­tion
towards a stra­tegic change, along­side business-as-usual oper­a­tions, it is more
effi­cient and bene­fi­cial to struc­ture this stra­tegic change as a programme. The
bene­fits of programme deliv­ery are discussed in Section 1.9, and include
manage­ment and align­ment of complex inter­ac­tions between the outputs of
indi­vidual projects, outcomes and bene­fits.
Having a programme manage­ment approach allows the organ­isa­tion’s senior
managers and direct­ors to focus on setting direc­tion, consid­er­ing medium and
long-term issues, whilst the programme manager will ensure that this is trans­lated
into the language of projects, manage the project managers and deliver to the
organ­isa­tion the required changes and capab­il­it­ies to enable real­isa­tion of the
desired bene­fits. In many organ­isa­tions change programmes tend to cut across
business-as-usual struc­tures. For example, a programme trans­form­ing a bank’s
oper­a­tion to internet-based services will need to inter­act with the bank’s exist­ing
vertical and func­tional struc­tures, i.e. oper­a­tions, IT, human resources (HR),
finance, market­ing and so on. The aims and object­ives of these groups may not
always be aligned and, unless such inter­ac­tions are care­fully planned in
conjunc­tion and with the cooperation of each busi­ness unit, the programme
could run into a ‘brick wall’ of non-cooperation. Planning and managing such
inter­ac­tions are a key activ­ity within programme manage­ment.
Most large organ­isa­tions can have several change programmes running
concur­rently. Therefore, the most senior levels of manage­ment need to take
seri­ously not only the ‘spon­sor­ship’ roles for indi­vidual programmes, but also
the manage­ment of the change programmes in a way that recog­nises the poten­tial
multiple points of impact on the stake­hold­ers involved. An organ­isa­tion’s
direct­ors must create the envir­on­ment in which change programmes can succeed

6
 Programmes and programme manage­ment

in deliv­er­ing outcomes and bene­fits, and hence the strategy. Business change
and programme manage­ment should there­fore be well under­stood by the most
senior manage­ment in an organ­isa­tion and be repres­en­ted at that level.

1.4 How do programmes differ

from projects?
While there is frequently overlap between programme and project manage­ment
activ­it­ies, it is wrong to regard programmes as merely large and complex
projects. They are usually larger than projects, in terms of number of staff and
dura­tion, but not neces­sar­ily so. Projects gener­ally do not include business-as-usual
activ­it­ies, whereas programmes may include (and certainly inter­act with) such
activities; inclusion of business-as-usual activities and programme composition is
generally determined by organisational policy. Programmes have a differ­ent purpose
and require differ­ent manage­ment struc­tures and skills to be success­ful.
Projects are the means to deliver specific one-off deliv­er­ables. To be success­ful,
the required deliv­er­ables must be defined in advance, with defined budgets and
timetable expect­a­tions. By contrast, programmes are the means to deliver bene­fits
or outcomes, and amongst their activ­it­ies are those needed to define and agree the
scope of the various projects that will make the achieve­ment of the desired bene­fits
possible. For example, a project might create a new ware­house, i.e. a deliv­er­able.
A ware­house on its own may seem to have little direct value, but when it is combined
with the deliv­er­ables of other projects – such as a compu­ter­ised stock-control
system, a retrained work­force, a new organ­isa­tional struc­ture, or a new staff bonus
scheme – in a programme, it can provide the capab­il­ity of supply­ing custom­ers
faster, with reduced costs and less wastage due to goods damaged in transit, which
are the bene­fits real­ised by the programme.
Success for a project is usually defined as creat­ing the required deliv­er­ables to
an adequate stand­ard, within agreed time and cost constraints. Whether the
deliv­er­able, such as a new ware­house, is success­fully used or not is not the point.
Indeed, there are many projects that have been deemed highly success­ful, as
judged by the project’s meas­ures of success, that have created deliv­er­ables that
have never actu­ally been used. Success for a programme is usually meas­ured in
terms of creat­ing a whole new capab­il­ity and, increas­ingly, the extent to which
the expec­ted bene­fits are actu­ally real­ised.
The term programme manage­ment is often used to refer to the execu­tion of a
number of projects by a contractor, for a client. It could be argued that this is not

7
APM Introduction to Programme Management

Table 1.1 Summary of key differ­ences between programmes and projects

Aspect Programmes Projects

Clarity of scope Programmes involve uncer­tainty in Projects require clearly defined

funding, range and impact. scope, budget and times­cales
(agile projects will look to fix
scope per iteration).
Clarity of Specific deliv­er­ables to be created The required deliv­er­ables are
deliv­er­ables are usually unclear at the start. usually clearly defined at the
start (agile projects will look to
fix deliverables per iteration).
Structure Separately managed projects, which A project forms a single
must be coordin­ated. The struc­ture managed entity, which is clear
may be unclear at the start and may at the start and will not usually
change through­out the life of the change signi­fic­antly during the
programme. life of the project.
Methodologies Frequently involves coordin­at­ing A single project is normally the
or approaches and managing several differ­ent respons­ib­il­ity of a single
organ­isa­tions, each of which is organ­isa­tion, working to a
respons­ible for one or more discrete single meth­od­o­logy or project
projects, and each of which may be approach.
using a differ­ent meth­od­o­logy of
project approach.
Clarity of At the start, the time and budget Projects start with a project
budgets and required will often be unclear, and initi­ation docu­ment, project
times­cales part of the role of the programme will manage­ment plan, busi­ness
be to define these. case or equi­val­ent that defines
expec­ted costs and times­cales.
Approach to Because the scope and deliv­er­ables Change to scope or desired
change are unclear, change to prior­it­ies and deliv­er­ables are gener­ally
require­ments is constant and a major subject to rigor­ous control.
feature of programmes.
Critical activ­it­ies A major element is managing people The major element is managing
and organ­isa­tional issues neces­sary the tech­no­logy or special­ist
to ensure that the new capab­il­it­ies skills neces­sary to create the
will be used to deliver the desired deliv­er­ables.
bene­fits.

Measure of The creation of useable capab­il­ity The creation of the specified

success and/or the deliv­ery of busi­ness deliv­er­ables within agreed time
bene­fits. and cost constraints.

8
 Programmes and programme manage­ment

programme manage­ment as we have defined it, and is in fact a series of unre­lated

projects which happen to share a common set of resources, and likely a common
approach and meth­od­o­logy. People have used ‘programme’ in the past, where
we would now use the term ‘port­fo­lio of projects’. Examples could include the
construc­tion of a number of water treat­ment plants for a local utility body or a
series of retail unit refur­bish­ments by a shop-fitting contractor for a retail chain.
If, however, this is a series of related projects, or coordin­ated deliv­ery of a set of
projects that, managed together achieve benefit of a stra­tegic nature, then this is
programme manage­ment – the key ques­tion is ‘are they aligned to achieve a
combined benefit’, or are they just deliv­er­ing a series of outputs.
However, this work will typic­ally form a part of a larger programme, and it is
only at that programme level that bene­fits will play a key role and be real­ised. In
the case of the water treat­ment plants, other projects to measure water quality
and improve other parts of the infra­struc­ture will combine with the treat­ment
plants to deliver the key perform­ance indic­at­ors required by the industry
regu­lator, for example. In the retail example, only when the market­ing,
manage­ment inform­a­tion systems and staff train­ing projects comple­ment the
shop refur­bish­ments will the increased income and customer satis­fac­tion bene­fits
become possible.

1.5 How do programmes differ

from port­fo­lios?
Portfolio manage­ment is the selec­tion, prior­it­isa­tion and control of an organ­isa­
tion’s projects and programmes in line with its stra­tegic object­ives and capa­city to
deliver. The goal is to balance change initi­at­ives and business-as-usual while
optim­ising return on invest­ment4. Programme manage­ment relates to the
coordinated manage­ment of a set of related projects – typic­ally where the
projects are mutu­ally depend­ent and all are needed to create the required
capab­il­ity and busi­ness bene­fits – port­fo­lio manage­ment is about the capa­city of
an organ­isa­tion to manage the total­ity of its projects and programmes, and the
choice of which projects to include in the port­fo­lio to achieve maximum benefit.
Portfolio manage­ment helps ensure that the right programmes and projects are
selec­ted in the first place and regu­larly reviewed. A port­fo­lio may include all or

4
For a defin­i­tion and further guid­ance on port­fo­lio manage­ment, see APM Body of Knowledge.
Also avail­able at http://know­ledge.apm.org.uk/bok/portfolio-management

9
APM Introduction to Programme Management

some programmes and/or projects, and be held at various levels within an organ­
isa­tion or in some parts and not others – there is no one-size-fits-all.
The linking char­ac­ter­ist­ics of a port­fo­lio lie in areas other than bene­fits. The
common factor is usually that all of the projects lie within the same organ­isa­tion
or depart­ment, and they must be financed through a common source of funding
or they need to make effi­cient use of a common pool of resources. Thus port­fo­lio
manage­ment is akin to the simil­arly named activ­ity that takes place in the finan­cial
world, where a port­fo­lio of invest­ments is managed to yield maximum returns
and capital growth with accept­able levels of risk. In such a port­fo­lio there is no
rela­tion­ship between the differ­ent stocks and shares – each invest­ment is self-
contained and is bought or sold only to achieve the object­ives of the port­fo­lio as
a whole.
Portfolio manage­ment helps ensure the effi­cient use of devel­op­ment
resources, such as busi­ness analysts, solu­tions archi­tects, web design­ers and so
on – while minim­ising costs through the elim­in­a­tion of duplic­ate manage­ment
and support activ­it­ies. It also helps to create an under­stand­ing of how the various
IT projects will contrib­ute or not to the achieve­ment of strategies of the various
busi­ness units for which they are being run – some­thing that is not always clear
with tradi­tional approaches to project manage­ment.
Portfolio manage­ment ensures that the port­fo­lio as a whole meets the organ­
isa­tion’s object­ives, with programmes and projects being added or removed
inde­pend­ently of others in the port­fo­lio. Programme manage­ment deals with
mutu­ally depend­ent projects, which should only be added to or removed if the
result improves the real­isa­tion of programme bene­fits.
Both programme and port­fo­lio manage­ment require a similar stra­tegic
aware­ness to be success­ful, with an overlap of skills, partic­u­larly those related to
organ­isa­tional empathy and flex­ib­il­ity. In many cases port­fo­lio manage­ment talent
comes from the busi­ness side of an organ­isa­tion, whereas a programme manager
tends to come from a project back­ground.

1.6 How do we run a programme?

Having a struc­tured approach to how a programme is run is import­ant to
success­ful bene­fits real­isa­tion, as well as to help stake­hold­ers to under­stand the
process they are involved in/affected by. The follow­ing ‘governance, control and
assur­ance’ diagram (Figure 1.2) provides an over­view of the programme
manage­ment envir­on­ment.

10
 Programmes and programme manage­ment

Figure 1.2 Programme governance, control and assur­ance over­view

Adapted from Driving the success­ful deliv­ery of major defence projects: Effective
control is a key factor in success­ful projects, National Audit Office, HC 30 Session
2005–2006, 20 May 2005. Provided courtesy of BMT Hi-Q Sigma Ltd.

There are a number of activ­it­ies under­taken during a programme, as shown in

Figure 1.2 in the central rect­an­gu­lar boxes. The day-to-day manage­ment of a
programme comes down to four main prin­ciples – governance, control, assur­ance
and integ­ra­tion. The first prin­ciple of governance looks to ensure that we
under­stand stake­holder object­ives and busi­ness require­ments (i.e. what do we
want to achieve) and to estab­lish the programme envir­on­ment found­a­tions.
Stakeholder object­ives and busi­ness require­ments can change over the life cycle
of the programme, so these need to be constantly engaged, considered and
adjus­ted and impacts commu­nic­ated; stake­holder engage­ment is a continu­ous
require­ment, and feeds into the change manage­ment strategy. Control is then
used to make sure the envir­on­ment is main­tained and adapted as required, that
all are clear on the struc­ture and working bound­ar­ies (both for the programme as
a whole and for its constitu­ent parts), and that progress is made and meas­ured.
Assurance provides a process to main­tain and monitor progress and to support

11
APM Introduction to Programme Management

risk-based decision making focused on success­ful deliv­ery. A final layer of

governance enables risk-based stra­tegic decision making on the programme
(and feeding into organ­isa­tional strategy), and ensures a focus on deliv­ery of
outcomes to meet stake­holder needs. These prin­ciples should not be seen as
mutu­ally exclus­ive, and that integ­ra­tion across the programme is a key prin­ciple
in its own right.
Many organ­isa­tions look to stand­ard models when trying to improve their
project and programme manage­ment prac­tice. A number of these are discussed
in the APM public­a­tion Models to Improve the Management of Projects.5
We explore the running of a programme and the programme life cycle in
Section 2. In Section 3 we explore programme assess­ment by means of concep­-
tual frame­works that focus on support­ing elements to allow a programme to
be success­ful. These frame­works high­light areas for consid­er­a­tion when running
a programme, and help define organ­isa­tional capab­il­ity to run a success­ful
programme. We explore a number of frame­works and then assess lenses of use
as defined in P3M3®6, which is a matur­ity model and provides a frame­work that

Figure 1.3 P3M3® framework

Copyright © AXELOS Limited 2016. Used under permis­sion of AXELOS Limited.
All rights reserved.
5
APM Models to Improve the Management of Projects, avail­able at – https://www.apm.org.uk/
M2IMP
6 Portfolio, Programme and Project Management Maturity Model (P3M3); see https://www.
axelos.com/best-practice-solutions/p3m3/what-is-p3m3 for further details. P3M3® is a registered
trade mark of AXELOS Limited. All rights reserved.

12
 Programmes and programme manage­ment

organ­isa­tions can use to assess their current perform­ance and plan for
improve­ment when managing and deliv­er­ing change.
Each sub-model is further broken down into seven Perspect­ives (explored in
greater detail in Section 3), each of which are import­ant to success:

n Organisational governance.
n Management control.
n Benefits manage­ment.
n Risk manage­ment.
n Stakeholder manage­ment.
n Finance manage­ment.
n Resource manage­ment.

1.7 Who runs a programme?

The success­ful deliv­ery of a programme of change is largely depend­ent on the
range of people involved in the programme, and links to the governance, control,
integ­ra­tion and assur­ance prin­ciples discussed in Section 1.6. Business change
and programme manage­ment should be well under­stood by the senior manage-
ment in an organ­isa­tion, and be repres­en­ted at that level, as the impact of
programmes on stra­tegic object­ives is crucial to busi­ness success. The role of
senior managers includes setting the culture, envir­on­ment and motiv­a­tion that
under­pins programme success. Table 1.2 provides a summary of key roles and
respons­ib­il­it­ies in a programme, and we expand on some of these below. Further
details can be found in APM Body of Knowledge and APM Competence
Framework.
The programme sponsor – also known as the senior respons­ible owner
(SRO) – selec­ted from the senior exec­ut­ive team of the organ­isa­tion, is ulti­mately
account­able for the programme, and this role should not be deleg­ated. The
sponsor owns the vision and busi­ness case for the programme, and is respons­ible
for provid­ing direc­tion and lead­er­ship for the deliv­ery and imple­ment­a­tion of the
programme, as well as being account­able for outcomes.
The programme is led by the sponsor, who chairs the programme board,
provides governance and lead­er­ship to the programme, as well as assess­ing
external factors that may influ­ence the programme, e.g. a change in strategy
or external pres­sures from other programmes or activ­it­ies, which may impact
the programme. The programme board includes the programme manager,

13
APM Introduction to Programme Management

Table 1.2 Roles and respons­ib­il­it­ies in a programme

Role Responsibility

Programme sponsor or senior Fully empowered lead­er­ship of indi­vidual

respons­ible owner programmes; owns busi­ness case and vision.
Programme manager Responsible for deliv­er­ing new capab­il­it­ies.
Business change manager Responsible for real­ising bene­fits through
embed­ding the change into business-as-usual.
Responsible for ensur­ing their own busi­ness area is
ready to use the programme’s project outputs.
Project manager Responsible for deliv­ery of project outputs within
agreed constraints.
Senior suppli­ers Represents the interests of parties involved from
supplier perspect­ive (internal or external).
Senior users Responsible for ensur­ing the needs of those that
will use outputs are met.
Communications manager Responsible for the iden­ti­fic­a­tion, analysis,
plan­ning and imple­ment­a­tion of programme
commu­nic­a­tions.
Stakeholder manager Responsible for the iden­ti­fic­at­ ion, analysis, plan­ning
and imple­ment­at­ ion of actions designed to engage
with stake­hold­ers.
Risk and issues manager Establishes, facil­it­ates and main­tains the threat,
oppor­tun­ity and issues manage­ment cycle.
Programme manage­ment office Support body for key roles, provid­ing advice,
(PMO) chal­lenge and checks.

repres­ent­at­ives from the customer and supplier (both of which could be internal
or external custom­ers or suppli­ers), busi­ness change manager(s) (who will
oversee trans­ition of the change) and others as appro­pri­ate.
The programme manager reports to the programme board on a regular basis.
The programme manager is primar­ily focused on managing rela­tions, depend­en­cies
and integ­ra­tion between the programme’s constitu­ent parts. The programme
manager is typic­ally backed by a programme manage­ment office7 (PMO), which
will support the effect­ive running of the programme (which could include train­ing,
commu­nic­a­tions, resource manage­ment and alloc­a­tion, monit­or­ing perform­ance
7
For further inform­a­tion on the role of the programme manage­ment office and the programme
infra­struc­ture, refer to APM Body of Knowledge 6th edition, Chapter 1.1.4, ‘Infrastructure’.

14
 Programmes and programme manage­ment

and progress, report­ing etc.). Further details on PMOs can be sought from the
APM Project Management Office Specific Interest Group8.
Reporting to the programme manager will be a series of project managers who
will control their indi­vidual projects as part of the programme. The programme
should also be acutely aware of stake­hold­ers asso­ci­ated with it, and many
programmes may include a stake­holder manager. A commu­nic­a­tions manager
often appears in programmes, and will be respons­ible for creat­ing and managing
a commu­nic­a­tion plan to ensure all parties (often includ­ing the public) are kept
aware and up to date with programme object­ives and progress.
For further detail in this area, refer to the APM Competence Framework9 and
APM Body of Knowledge.

1.8 How programmes deliver bene­fits

The APM Body of Knowledge states that bene­fits asso­ci­ated with stra­tegic organ­
isa­tional change are delivered through programmes of multiple-aligned projects
and change manage­ment activ­ity. Such programmes can contain complex inter­
ac­tions between the outputs of indi­vidual projects, outcomes and bene­fits.
The role of the programme is to deliver outcomes, and hence set the scene for
deliv­er­ing bene­fits, as opposed to the outputs that an indi­vidual project deliv­ers.
Gaining shared stake­holder clarity, under­stand­ing and commit­ment to the
desired outcomes is crit­ical to programme success. Wherever possible, the
programme should seek to realise meas­ur­able bene­fits early and then frequently
during its life. However, it is likely that most bene­fits will be real­ised during
business-as-usual use of the programme outcomes (e.g. a new facil­ity, new
struc­ture or new capab­il­it­ies), and likely once the programme ends. Where
bene­fits are real­ised after the programme team has been disban­ded or assigned
to new endeav­ours, respons­ib­il­ity for monit­or­ing, meas­ur­ing and real­ising the
bene­fits must be trans­ferred to an appro­pri­ate func­tion. The trans­ition plan
should be considered as part of programme plan­ning, and discussed and agreed
with the programme board and busi­ness change manager.
A crit­ical compon­ent within benefit manage­ment is the project(s) or set of
activ­it­ies needed to manage the trans­ition from the old ways of working, based
on previ­ous processes, tools and capab­il­it­ies, to the new ways. Such trans­itions

8
APM PMO SIG: see – https://www.apm.org.uk/group/apm-pmo-specific-interest-group
9
APM Competence Framework: see – https://www.apm.org.uk/compet­ence­frame­work

15
APM Introduction to Programme Management

are frequently very complex and risky. For example, they may involve the
switch-off of old systems or facil­it­ies and the switch-on of new ones accord­ing
to tight times­cales. They depend upon the commit­ment of users and line
manage­ment who are not directly under the control of the programme or any of
its compon­ent projects. Furthermore, there can be little allow­ance for failure or
delay, since service to custom­ers must continue through­out the trans­ition and,
unless a smooth trans­ition is effected, it may not be possible for the organ­isa­tion
to take advant­age of the new capab­il­it­ies and thus be able to realise the bene­fits
that the programme is inten­ded to provide.
It is import­ant to imple­ment a consist­ent approach to bene­fits manage­ment
across a programme, partic­u­larly for consist­ency of meas­ure­ment. Without a
consist­ent approach, it is diffi­cult to aggreg­ate bene­fits across multiple projects
and to assess their collect­ive impact on busi­ness perform­ance across the organ­
isa­tion. Benefits manage­ment ensures the real­isa­tion of bene­fits, and respons­ib­
il­ity for it may rest partly with the programme manage­ment team and partly with
another group, such as the main board or the organ­isa­tion’s finance func­tion. We
discuss bene­fits manage­ment further in Section 3.4.
The rela­tion­ship between projects, programmes and benefit deliv­ery is
outlined in Figure 1.4, which shows how the deliv­er­ables created by projects are
combined by programmes to create capab­il­it­ies, which are then used to realise
bene­fits.

1.9 What chal­lenges are faced?

As with any change, and related change manage­ment activ­ity, programme
manage­ment can face a number of intrinsic chal­lenges. These are all surmount­
able, espe­cially when considered continu­ously during the programme life cycle,
and through lessons learned from other programmes.
Typical chal­lenges exper­i­enced include:

n managing the complex­ity and natural tension that exists between corpor­ate
strategies, the deliv­ery mech­an­isms (i.e. projects) and the busi­ness-as-usual
envir­on­ments – this level of complex­ity can easily be under­es­tim­ated;
n gaining corpor­ate board level support to provide lead­er­ship, commit­ment and
spon­sor­ship;
n applic­a­tion of adequate strength of lead­er­ship from the programme board,
programme manager and support­ing struc­tures;

16
 Programmes and programme manage­ment

Figure 1.4 The rela­tion­ship between projects, programmes and bene­fits

n defin­ing and main­tain­ing a clear vision and a real picture (blue­print) of the
future capab­il­ity required, as well as metrics to monitor progress towards the
vision;
n main­tain­ing an adequate focus on bene­fits, which needs to be built in from the
start and monitored through­out; as well as looking to realise bene­fits as early
as possible;
n address­ing the tensions that arise between programme targets and constraints
(for example across scope, cost, time, risk, bene­fits etc.);
n trans­ition­ing the desired/neces­sary cultural changes – the people/human
element can often be over­looked;
n gaining the required levels of stake­holder engage­ment – this is partic­ul­arly
import­ant as the programme will likely deliver signi­fic­ant change, and this
needs to be under­stood and agreed;
n managing programme inter­de­pend­en­cies;
n ensur­ing a clear require­ments capture and manage­ment approach across the
programme.

The follow­ing sections provide an over­view of ‘the programme life cycle’ and
‘programme assess­ment’, which when applied, support the programme progres­
sion and help mitig­ate the above chal­lenges.

17
 2

The programme life cycle

2.1 A high level programme

manage­ment life cycle
In spite of the vari­ation in size of programmes, from a handful of people and a few
projects through to thou­sands of people on large, complex under­tak­ings, each
one can be deemed to follow a stand­ard life cycle. The key phases of this stand­ard
programme life cycle are shown in Figure 2.1.
Other repres­ent­a­tions of programme life cycles may vary in termin­o­logy for
the indi­vidual phases, but each follows the funda­mental prin­ciples of concept,
defin­i­tion, deliv­ery and closure. It should also be noted that some repres­ent­a­
tions (or organ­isa­tions) might use addi­tional sub-phases to those proposed here.
It is import­ant in life cycle terms to differ­en­ti­ate between the steady-
state oper­a­tions of a busi­ness (or of a social envir­on­ment) and the change itself.
Figure 2.2 illus­trates how a programme is aimed at intro­du­cing change, not at
running the steady-state activ­it­ies, and how these differ­ent elements align with

Figure 2.1 Programme life cycle repres­ent­a­tion (adapted from APM Body of
Knowledge, Chapter 1.1.6).

19
APM Introduction to Programme Management

Figure 2.2 Change programme vs. steady-state activ­it­ies

percep­tions of short, medium and long-term times­cales. Programmes typic­ally

develop change by step­ping through sub-divisions that facil­it­ate approval gates
and deliver incre­ments in capab­il­ity (these are known as tranches10) with result­ing
trans­itions into the busi­ness oper­a­tions (or social envir­on­ment), as illus­trated in
Figures 2.1 and 2.2.
The programme life cycle is aimed at estab­lish­ing a firm plat­form for the overall
change journey, whether this is for a busi­ness or soci­etal trans­form­a­tion, the
intro­duc­tion of a new capab­il­ity, or the launch of a new product into its oper­at­ing
envir­on­ment. Figure 2.3 shows one concep­tual descrip­tion of this journey,
illus­trat­ing the key rela­tion­ships between the busi­ness object­ives, the defin­i­tion
of the programme, the indi­vidual projects and their outputs, the programme
outputs and the result­ing bene­fits, and how these under­pin the result­ing busi­ness
perform­ance.

2.2 Life cycle strategy consid­er­at­ ions

Prior to the start of a programme, there may be a period of uncer­tainty while an
organ­isa­tion under­stands and decides that a change of some descrip­tion is required
and that some form of invest­ment in change is needed. In some cases this may be
a form­ally recog­nised stra­tegic phase of activ­it­ies (for example, it may be called a
‘genesis’, ‘found­a­tion’ or ‘pre-concept’ phase), and in others it may be less clearly

10
Tranches are covered in greater detail in Section 2.5.

20
 The programme life cycle

Figure 2.3 Conceptual repres­ent­a­tion of programme change journey

showing valid­a­tion and veri­fic­a­tion rela­tion­ships based on the Vee Model

defined or revolu­tion­ary. In theory, all organ­isa­tions should have clearly defined

and agreed busi­ness change strategies, the imple­ment­a­tion of which requires the
initi­ation of programmes. Indeed, if the organ­isa­tion is under­tak­ing programmes
within the frame­work of port­fo­lio manage­ment then the programmes will be fully
aligned with stra­tegic plans.11 Within such an envir­on­ment (or where the busi­ness
under­takes regular change or intro­duc­tion of new complex products), the busi­ness
will have defined a busi­ness change life cycle specific to its needs, and so the
indi­vidual programme life cycle will have to be aligned with this generic busi­ness
frame­work. This align­ment is an import­ant part of defin­ing a specific strategy for
the overall programme approaches, i.e. the defin­i­tion of its programme life cycle.
Another import­ant consid­er­a­tion for the programme life cycle is the selec­tion
of the approach the organ­isa­tion would like to take in the deliv­ery phase of an
indi­vidual programme (or poten­tially intro­du­cing the overall change through

For further inform­at­ ion, refer to APM Body of Knowledge 6th edition, Chapter 1.1.3, ‘Portfolio
11

manage­ment’.

21
APM Introduction to Programme Management

related programmes). Different forms of programme approaches are described

in Table 2.1.
The defin­i­tions in Table 2.1 are also applic­able to differ­ent programme phases,
or to indi­vidual tranches within the deliv­ery phase. Depending on the level of
uncer­tainty during the concept or defin­i­tion phases, it may be neces­sary to
conduct ‘discov­ery’ or ‘pilot’ projects, under­take feas­ib­il­ity studies or to create
proof-of-concept systems in order to help clarify the programme life cycle strategy.
Therefore, the ideal­ised programme life cycle shown in Figure 2.4 should be
adapted to suit the nature of the change and the envir­on­ment in which the
change is to be under­taken.

Table 2.1 Different programme life cycle stra­tegic approaches

Approach Description

Linear Where the busi­ness trans­itions to the final new state through a single
sequen­tial series of activ­it­ies each provid­ing only partial capab­il­ity (possibly
even in a single tranche). This is suit­able for stable, low-risk envir­on­ments
where the full benefit can be delivered through a single final roll-out.12
Incremental Where the trans­ition to the new state is achieved through a staged series of
smaller step changes in capab­il­ity deliv­er­ing increas­ing benefit. This is an
approach that can deliver ‘quick wins’ to help engage stake­hold­ers in an
uncer­tain envir­on­ment and build confid­ence towards the final end state, and
is well repres­en­ted within the ‘tranche’ frame­work.
Experimental Where the programme runs paral­lel activ­it­ies in order to explore high-risk
options and fall-backs, where the way forward is unclear at first. The scope
of this type of activ­ity will depend on the risk appet­ite of the organ­isa­tion –
in some circum­stances the approach may extend for the dura­tion of the
deliv­ery phase.
Evolutionary In this approach the programme takes a number of planned full trans­itions to
business-as-usual, each of which are based on user/customer feed­back from
the preced­ing trans­ition and imple­ment­a­tion. This approach can be used for
time-critical initial entry to market followed by follow-on solu­tions, but runs a
possible risk of negat­ive repu­ta­tional impacts from continu­ous changes.

12
The term ‘big bang’ is often used in these situ­ations. Depending on the circum­stances there may
be consid­er­able overlap between this defin­i­tion and that of an ‘exten­ded project’, which encom­
passes trans­ition to oper­a­tions and real­isa­tion of bene­fits.

22
 The programme life cycle

There are many permuta­tions, combin­a­tions and over­laps in life cycle strategy
defin­i­tion: the crit­ical elements are to define the way forward such that it can be
clearly commu­nic­ated to the team, the sponsor and to the other stake­hold­ers,
and under­pin the overall programme detailed defin­i­tion. This is a key programme
decision as it can have major implic­a­tions down­stream on the manage­ment style
and beha­viours.
The programme life cycle strategy should also incor­por­ate or reflect any issues
arising from an appre­ci­ation of the likely devel­op­ment meth­od­o­lo­gies used at the
project level. These may be driven by the nature of the work in those projects
and the level of threats to success­ful project conclu­sions. They also need to be
integ­rated into the wider programme envir­on­ment.
An example of this would be programmes under­taken within an agile
devel­op­ment envir­on­ment and/or where one or more projects employ agile
devel­op­ment tech­niques.13 It should be noted that an appro­pri­ate, robust and
tailored programme manage­ment envir­on­ment is entirely condu­cive and
applic­able to an agile devel­op­ment envir­on­ment.14
Finally, consid­er­a­tion must also be given to the nature and strengths of the
tensions that will be preval­ent within the programme envir­on­ment, and how the
overall programme approach may be adapted to reflect or respond to these.
Figure 2.4 illus­trates some of these tensions.

Figure 2.4 Typical programme tensions to be addressed15

13
Note that employ­ing agile devel­op­ment tech­niques in a busi­ness envir­on­ment that is not suited
to them restricts the prob­ab­il­ity of overall success. For a discus­sion of when to select agile/non-agile
project approaches, refer to The Practical Adoption of Agile Methodologies, 2015, Princes
Risborough: APM.
14
For example the AgilePgM™ frame­work, avail­able from the DSDM Consortium (www.dsdm.org).
15
Taken from Valuing Our Place in the World – Using Systems Engineering in Programme and
Project Management, Gray, A. and Richardson, K., INCOSE UK Annual Systems Engineering
Conference 2015.

23
APM Introduction to Programme Management

2.3 Programme life cycle governance

The programme life cycle provides a frame­work to support the prin­ciples of good
organ­isa­tional and programme governance.16 One of these prin­ciples is that the
programme approach should have author­isa­tion points at which the busi­ness
case, inclus­ive of strategy align­ment, cost, benefit and risk, is reviewed. These
author­isa­tion points can take the form of gateway reviews between phases, and
indi­vidual stage or gate reviews within the phases, as shown in Figure 2.1.
The exact nature of these reviews depends on the organ­isa­tion, but they
should ensure that posit­ive busi­ness decisions are taken to continue with the
programme in its current direc­tion, change direc­tion or abandon the programme
completely. The reviews also provide ideal oppor­tun­it­ies to ensure that all
governance prin­ciples are being followed.
Programme gate reviews should also occur at the end of each tranche in the
deliv­ery phase, to form­ally author­ise moving to the next tranche, assess
programme perform­ance and any benefit real­isa­tion to that point. These will also
be aligned with, and cascade up from, stage gate reviews in the indi­vidual
projects.

2.4 Programme concept17 phase

2.4.1 Purpose
The purpose of this phase is to identify a programme, its vision, aims and stra­tegic
align­ment such that clear found­a­tions are set for success­ive activ­it­ies and commu­
nic­ated to programme team members and external stake­hold­ers. This culmin­ates
in the outline busi­ness case.

2.4.2 Overview
An over­view of the concept phase activ­it­ies, inputs, outputs, controls and
support­ing mech­an­isms is given in Figure 2.5.

16
Refer also to Directing Change: A Guide to the Governance of Project Management, 2011,
Princes Risborough: APM.
17
This docu­ment uses the phase labels as defined in the APM Body of Knowledge 6th edition. This
phase is also known else­where as the ‘identification’ phase.

24
 The programme life cycle

Figure 2.5 Concept phase over­view

2.4.3 Key activ­it­ies

This phase can be initi­ated on receipt of an initial mandate (or similar form of
instruc­tion from a spon­sor­ing group) or, where no such mandate form­ally exists,
the start of the phase can be a gradual ‘morph­ing’ from other busi­ness activ­it­ies
as the initial mandate is defined. This mandate can take the form of a simple
written instruc­tion or a stra­tegic busi­ness case that outlines the desires of the
organ­isa­tion in terms of outcomes expec­ted against stra­tegic busi­ness object­
ives. Depending on the busi­ness envir­on­ment, it can be gener­ated through
organ­isa­tional busi­ness policies and plan­ning, an over­arch­ing port­fo­lio strategy
and plan, or a preced­ing ‘pre-concept’ phase.
The main aims of this phase are to confirm the programme vision and mandate,
define the programme organ­isa­tional arrange­ments, produce the programme
brief and achieve a decision on the outline busi­ness case. The programme brief
describes the basic valid­ity and viab­il­ity of the programme. It will encap­su­late the
vision, object­ives and bene­fits to be achieved, and estim­ated cost and times­cales

25
APM Introduction to Programme Management

in order to achieve those bene­fits. Risks to achiev­ing the object­ives will be

outlined, as well as various options and oppor­tun­it­ies that have been iden­ti­fied.
The programme organ­isa­tions to be defined include the governance struc­ture
(i.e. the arrange­ment of the sponsor and the programme board) and the compos­i­tion
of the programme manage­ment office (PMO). The PMO may be a stand-alone
support office, or it may be integ­rated within a wider port­fo­lio manage­ment office.
The brief, the programme arrange­ments and a plan for the Programme
defin­i­tion phase will be reviewed by the busi­ness senior manage­ment team
(which could be an exec­ut­ive board, an invest­ment commit­tee or a port­fo­lio
direc­tion group) and, if approved, the programme will then progress to the
defin­i­tion phase. Note that the senior manage­ment team may also be known as a
‘spon­sor­ing group’ (as shown in Figure 2.5).

2.4.4 Relevant Body of Knowledge sections

The follow­ing sections of APM Body of Knowledge provide further inform­a­tion
on this phase (other sections of APM Body of Knowledge can also provide
inform­a­tion):

1.1.5 Knowledge manage­ment 1.1.8 Sponsorship 1.2.3 Strategic manage­ment

1.1.6 Life cycle 1.2.1 Environment 2.1.5 Leadership

2.5 Programme defin­i­tion18 phase

2.5.1 Purpose
The purpose of the defin­i­tion phase is to estab­lish and gain approval for
the programme to proceed, and define it in such a manner that it will be
possible to coordinate its compon­ent activ­it­ies and there­fore deliver its
object­ives effect­ively.

2.5.2 Overview
An over­view of the defin­i­tion phase activ­it­ies, inputs, outputs, controls and
support­ing mech­an­isms is given in Figure 2.6.

18
Also known as an ‘initi­ation’ phase.

26
 The programme life cycle

Figure 2.6 Definition phase over­view

2.5.3 Key activ­it­ies

The main thrust of this phase is to achieve a robust defin­i­tion of the programme
such that approval can be sought by the sponsor from the busi­ness senior
manage­ment team/spon­sor­ing group for the programme to proceed. This is
achieved by gener­at­ing a busi­ness case defin­ing the object­ives, expec­ted
bene­fits, invest­ment required, costs, times­cales, risks and ability to achieve the
desired object­ives. A good break­down of the typical contents of a busi­ness case
is provided by the ‘Green Book’ from HMT 19, which describes a ‘5 Case Model’
where the busi­ness case comprises:

n a stra­tegic case – the rationale for why you need to under­take the programme;
n an economic case – the cost/benefit analysis of the avail­able options;
n a commer­cial case – the viab­il­ity of any procure­ment approach;

19
In partic­u­lar, refer to Public Sector Business Cases Using the 5 Case Model (HM Treasury Green
Book supple­ment­ary guid­ance), avail­able from https://www.gov.uk/govern­ment/public­a­tions/
the-green-book-appraisal-and-evaluation-in-central-governent [sic].

27
APM Introduction to Programme Management

n a finan­cial case – the afford­ab­il­ity of the overall programme;

n a manage­ment case – the achievab­il­ity of the programme (in terms of its
execu­tion).

The busi­ness case there­fore requires inputs such as a defin­i­tion or depic­tion of

the aspects of the future state of the busi­ness that is able to meet the object­ives
of the mandate. This defin­i­tion (often referred to as the programme blue­print)
provides a found­a­tion for the subsequent plan­ning and a focus for the programme
as a whole. The future state is defined in terms of future capab­il­it­ies, organ­isa­
tional struc­tures, person­nel (includ­ing skills and expert­ise require­ments),
processes and work­flows, phys­ical infra­struc­ture and tech­no­logy, and inform­a­
tion needed to run the busi­ness.
A key element of the busi­ness case, and the programme to follow, is the iden­ti­
fic­a­tion and analysis of the bene­fits that are expec­ted, and what activ­it­ies, outcomes
and specific outputs are needed to realise these bene­fits. Analysis of the required
bene­fits, the impact on stake­hold­ers and how best to engage and support them
and the step changes in busi­ness capab­il­ity needed to achieve the bene­fits, will
help define the deliv­ery of the overall programme. These step changes are known
as tranches, and these are aimed towards deliv­er­ing inter­me­di­ate capab­il­it­ies and
ulti­mately the real­isa­tion of bene­fits, as illus­trated in Figure 2.7.
Analysis of the programme deliv­ery require­ments will help define the projects
that are needed to deliver the neces­sary outputs. Projects can exist within

Figure 2.7 Tranches and projects within the deliv­ery phase. (Number of
tranches and projects is for illus­tra­tion only)

28
 The programme life cycle

tranches, or can span tranches (in which case they will typic­ally be broken into
project stages that align with the tranches). Each iden­ti­fied project is then defined
indi­vidu­ally and makes up an overall dossier of projects within the programme.
In addi­tion, the programme team will under­take iden­ti­fic­a­tion and analysis of
the stake­hold­ers involved in the programme, and then devise a commu­nic­a­tion
and engage­ment plan to help inter­act with these stake­hold­ers. Management of
stake­holder engage­ment is crit­ical to the success of a programme, and a key part
of the future activ­it­ies of the central programme team.
The blue­print gener­a­tion, risk analysis, bene­fits defin­i­tion and stake­holder
analysis is all carried out in paral­lel (in an iter­at­ive manner) to arrive at the busi­ness
case. During the phase the programme governance arrange­ments are also defined
and these, along with the overall manage­ment frame­work and the inform­a­tion
defined in the blue­print and busi­ness case, are used to gener­ate the programme
manage­ment plan (also known as the programme defin­i­tion docu­ment).

2.5.4 Relevant Body of Knowledge sections

The follow­ing sections of APM Body of Knowledge provide further inform­a­tion
on the elements of the defin­i­tion phase (other sections of APM Body of
Knowledge also provide inform­a­tion):

1.1.5 Knowledge 3.1.5 Planning 3.2.6 Solutions devel­op­ment

manage­ment
2.1.1 Communication 3.1.6 Stakeholder manage­ment 3.3.1 Resource schedul­ing
2.1.3 Delegation 3.2.1 Benefits manage­ment 3.3.2 Time schedul­ing
3.1.1 Business case 3.2.4 Change manage­ment 3.4.2 Funding
3.1.4 Organisation 3.2.5 Requirement manage­ment 3.4.3 Investment appraisal

2.6 Programme deliv­ery20 phase

2.6.1 Purpose
The purpose of the deliv­ery phase is to manage the programme to deliver what
has been planned – includ­ing any organ­isa­tional change and busi­ness bene­fits –
in accord­ance with agreed cost, benefit, time and resource constraints.

20
Also known as the ‘execu­tion’ phase.

29
APM Introduction to Programme Management

Figure 2.8 Delivery phase over­view

2.6.2 Overview
An over­view of the deliv­ery phase activ­it­ies, inputs, outputs, controls and
support­ing mech­an­isms is given in Figure 2.8.

2.6.3 Key activ­it­ies

Once the programme is estab­lished, the compon­ent projects are created to
produce their required outputs accord­ing to the programme manage­ment plan.
These outputs will then be combined under the control of the programme to
produce the new capab­il­it­ies/outcomes that can then be exploited to realise the
bene­fits to the organ­isa­tion and other stake­hold­ers.
These outcomes cannot be imple­men­ted without a trans­ition from the
programme to the normal working prac­tices, and this trans­ition is a crit­ical part of
the programme manage­ment activ­ity. This activ­ity is also the found­a­tion of bene­fits
real­isa­tion, where the programme works with the day-to-day busi­ness envir­on­ment
to ensure that the busi­ness case for the programme is being achieved.

30
 The programme life cycle

The follow­ing sub-sections explore more closely the activ­it­ies shown in Figure
2.7 grouped under programme deliv­ery, trans­ition and bene­fits real­isa­tion.

i. Programme deliv­ery
Establish tranches and compon­ent projects
The compon­ent projects them­selves must be estab­lished and planned in detail,
cross-checked and optim­ised for tech­nical, mana­gerial and commer­cial consist­
ency. The indi­vidual project plans, time sched­ules and other support­ing docu­
ment­a­tion should be reviewed (by the programme manager or the PMO on their
behalf) to ensure consist­ency and to identify depend­en­cies and poten­tial
conflicts.
Ideally for each project a separ­ate project manager should be appoin­ted,
although circum­stances (such as small-scale projects or projects not over­lap­ping)
may allow an indi­vidual to run separ­ate projects. Managing a project that is part
of a larger programme is differ­ent from managing a stand-alone project (for
example dealing with decisions made for the greater benefit of the wider
programme but penal­ising for the indi­vidual project), and appro­pri­ate terms of
refer­ence, identi­fy­ing differ­ent report­ing struc­tures and escal­a­tion proced­ures,
should be provided, agreed and signed off. This is done by expand­ing the
inform­a­tion on each project into separ­ate project briefs (or project initi­ation
docu­ments) and placing project-specific inform­a­tion into these docu­ments
(common inform­a­tion is held in the programme manage­ment plan/programme
defin­i­tion docu­ment).
Detailed project plans will be devised only for the tranche to be executed –
activ­it­ies within future tranches will be defined as the active tranche draws to a
close – but the programme defin­i­tion docu­ment will describe the outline
times­cales and inten­tions for future tranches. Therefore project briefs are
updated at the begin­ning of each tranche.

Coordinate plans and sched­ules

Although each compon­ent project will develop its own project plan and attend­-
ant time schedule, success­ful programme manage­ment requires these to be
coordinated, and on a rolling basis. This requires all inter­de­pend­en­cies to
be iden­ti­fied, and then the indi­vidual plans and sched­ules adjus­ted to achieve
the best possible overall comprom­ise.

31
APM Introduction to Programme Management

Once a consol­id­ated sched­ule has been agreed, with inter­de­pend­en­cies

confirmed, it is likely to need constant adjust­ment as progress and changes are
noti­fied to ensure that any delay in one compon­ent project is accom­mod­ated,
thus avoid­ing ‘knock on’ delays to other projects and thus to the deliv­ery of the
desired programme outcomes.
Through the coordinated manage­ment of the compon­ent projects, the
programme will deliver the required outputs and outcomes in the most cost-
efficient manner. Project inter­face and inter­de­pend­ency manage­ment is a key
func­tion of the programme envir­on­ment, for depend­en­cies within the programme
and across the programme bound­ary (inputs from outside the programme).

Manage risks21
As with indi­vidual projects, rigor­ous threat, issue and oppor­tun­ity manage­ment
is essen­tial. Typically, each project will main­tain its own risk register and manage
its own risks, but will escal­ate to a programme-level risk register those risks that
are beyond its control, or would have a detri­mental impact on another project, or
which could be more effect­ively managed at the programme level.22 The
programme risk register also holds risks for projects that are not yet under­way,
threats to project inter­de­pend­en­cies and programme coordination, or those
threats arising from the envir­on­ment outside the programme (see Section 3.5).
The programme team will monitor external situ­ations on behalf of the projects
(‘bound­ary scan­ning’) and escal­ate risks beyond the control or scope of the
programme to stra­tegic busi­ness or port­fo­lio manage­ment.

Manage stake­holder engage­ment and commu­nic­a­tions

While coordinating and managing the compon­ent projects within the
programme, the programme team must also develop rela­tion­ships with the
customer, users, bene­fi­ciar­ies and other stake­hold­ers, under­take consol­id­ated
analysis and coordinate the engage­ment and commu­nic­a­tions with stake­hold­ers
across the projects. Individual projects may under­take their own stake­holder
manage­ment, but it must be consist­ent and aligned with the overall programme
activ­ity.

21
Note that the term ‘risk’ in this section embraces threat, oppor­tun­ity and issue manage­ment.
22
For example, risks where the responses (actions) are dispersed across many projects.

32
 The programme life cycle

In complex envir­on­ments, such as those relat­ing to programmes, stake­holder

engage­ment should be an integ­ral compon­ent of all manage­ment activ­it­ies. It
must be part of the overall approach to gaining and then main­tain­ing the support
and cooperation of all stake­hold­ers, and must be coordinated with related
activ­it­ies such as: govern­ing the programme; commu­nic­at­ing risks and progress;
and collab­or­at­ive problem solving.

Manage programme resources and budgets23

The programme will monitor and control expendit­ures against the budgets laid
out in the busi­ness case and detailed in the programme plan. Overall programme
budgets – in terms of total fore­cast costs and times­cales – will have a degree
of uncer­tainty accord­ing to the programme matur­ity and nature of the
programme, but each current tranche should have targets set as part of the
tranche plan­ning process. The programme manager should have a programme
budget composed of:

n funds alloc­ated to on-going projects;

n funds reserved for future planned projects;
n funds alloc­ated to programme-level activ­it­ies (such as the PMO);
n funding held for programme-level risks, and any risk reserve held on behalf of
the projects;
n contin­gency held for unfore­seen events (which will typic­ally reflect the level
of programme uncer­tainty).

The contin­gency and manage­ment reserve held at the programme level may be
held on behalf of the indi­vidual projects (as well as the programme activ­it­ies), or
an amount may be alloc­ated to the projects to be managed accord­ingly within the
project (with the total across all projects plus the remain­ing reserve held by
the programme equal to the overall programme expos­ure). This depends on how
the various risks are to be owned and managed, and how the indi­vidual projects
are run. In either case it is import­ant to clarify what contin­gen­cies and reserves
are being held at which level and for what purpose, to avoid double account­ing
or gaps.

23
In this context, the term ‘budget’ covers not only finan­cial alloc­a­tions, but also times­cales and any
other para­meter that has a form of inten­ded consump­tion.

33
APM Introduction to Programme Management

Budgetary control may be exer­cised through the setting of toler­ances on time,

costs etc., where indi­vidual projects will only have to notify the programme of
any inten­ded expendit­ure outside the permit­ted vari­ation.
The setting of budgets for tranches, and the increas­ing matur­ity of forward
estim­ates from tranche to tranche, can be aligned with busi­ness finan­cial approval
cycles and processes by adjust­ing the timings of the tranches them­selves.

Report and review progress

At agreed inter­vals, consol­id­ated programme status reports should be produced.
The scope and cover­age of these will have been defined during the programme
initi­ation phase accord­ing to the needs of the programme board.
Typically such report­ing will include programme and finan­cial status reports –
based upon inform­a­tion provided by the compon­ent projects. These should be a
concise ‘snap­shot’ of the status of the programme, identi­fy­ing progress against
mile­stones and any major new risks, and concen­trat­ing on excep­tions and
depar­tures from agreed plans. A key part of such a report will be progress made
towards the deliv­ery of bene­fits. The finan­cial status report should give a summary
of the consol­id­ated costs, reven­ues, working capital and reserves of the
programme.
Producing these reports will require each project to prepare its own indi­vidual
reports and then forward these to the programme for consol­id­a­tion and review,
normally by the PMO. To ensure that mean­ing­ful results can be prepared by the
agreed dates, it will normally be neces­sary for the PMO to define and enforce a
stand­ard report­ing timetable and to provide templates in which the managers of
compon­ent projects can record their inform­a­tion. However, the programme
must be cognis­ant of, and respect, the differ­ent project envir­on­ments as indi­vidual
project report­ing will be influ­enced by the nature of the projects them­selves –
some projects may be oper­at­ing in an agile devel­op­ment envir­on­ment – but it is
the role of the programme to consol­id­ate them in a manner appro­pri­ate to the
needs of the organ­isa­tion.
In conjunc­tion with the report­ing require­ments, it is good prac­tice for the
programme board to conduct progress reviews at crit­ical points in the life of the
programme, such as the end of a design or devel­op­ment phase or imme­di­ately
before begin­ning imple­ment­a­tion/trans­ition. Such review points are usually
iden­ti­fied at programme start-up and should be iden­ti­fied in the programme
manage­ment plan. Such reviews are time-consuming, and thus adequate budgets
and resources should be provided for the programme manage­ment team to

34
 The programme life cycle

prepare for them. These reviews may take the form of ‘gate­ways’ where a formal
go/no-go decision is taken about the subsequent activ­ity.

Review and update programme plans

The programme plan and consol­id­ated sched­ule are likely to need regular
updates as a result of:

n activ­it­ies that were known to be required, such as the initi­ation of a new

project, but which could not be planned in detail at the start of the tranche;
n changes to the plans and sched­ules of exist­ing projects as a result of delay or
unex­pec­ted prob­lems and diffi­culties;
n alter­a­tions to the scope, content or compos­i­tion of the programme as a result
of change requests.

Major updates should be discussed with and agreed by the programme board.

Confirm busi­ness case viab­il­ity

The programme busi­ness case is a ‘living’ docu­ment through the life of the
programme. It will be consul­ted and reviewed (a) in the event of changes to the
programme or the envir­on­ment around the programme, or (b) in the event of
revised expec­ted bene­fits and costs arising as greater certainty is gained or
bene­fits are reviewed. At the very least it is always reviewed at the end of each
tranche to confirm the on-going viab­il­ity of the programme. If the busi­ness case
diverges signi­fic­antly from the expec­ted return from the programme then the
senior respons­ible owner should recom­mend programme termin­a­tion to the
senior manage­ment team (spon­sor­ing group).

ii Transition
Plan, under­take and confirm trans­ition
The trans­ition from programme outcomes to changes in the day-to-day busi­ness
or envir­on­ment requires careful plan­ning prior to the end of each tranche. Areas
such as staff train­ing, support arrange­ments, new processes and their perform­
ance meas­ure­ment, organ­isa­tional changes and detail­ing any new data require­
ments all have to be considered, and espe­cially how these will be intro­duced

35
APM Introduction to Programme Management

with minimum disrup­tion to the busi­ness. The trans­ition itself can only be
triggered when all areas are ready, and the prepar­a­tion and manage­ment of the
trans­ition is a key element of the respons­ib­il­it­ies of the busi­ness change managers
in the programme.
Once the outcomes have been achieved in the organ­isa­tional envir­on­ment
then the changes can be made perman­ent by remov­ing old legacy systems and
monit­or­ing the embed­ding of new prac­tices for any issues arising. Lessons from
the trans­ition and the imple­ment­a­tion of new capab­il­it­ies have to be fed back to
the programme team (in the case of inter­me­di­ate trans­itions to influ­ence ongoing
programme activ­it­ies), and to senior or port­fo­lio manage­ment teams (for ongoing
busi­ness continu­ous improve­ment and process optim­isa­tion).

iii Benefits real­isa­tion

Manage bene­fits real­isa­tion
Whilst the trans­ition activ­ity is a key point in estab­lish­ing and meas­ur­ing bene­fits,
bene­fits real­isa­tion manage­ment occurs through­out the programme deliv­ery
phase. The programme tranches (and hence programme sched­ule) are built
around the inten­ded real­isa­tion of inter­me­di­ate bene­fits, and the bene­fits
them­selves should be the basis for any key programme decisions (possibly
using tech­niques such as multi-criteria decision analysis based around the
bene­fits).
Where it is possible (and planned) initial bene­fits will be meas­ured during the
post-transition activ­ity and results fed back into the programme plan­ning for the
next tranche (or poten­tially future tranches). The results may also have an impact
on the viab­il­ity of the busi­ness case.

iv Continuous learn­ing envir­on­ment

Undertake learn­ing activ­it­ies through­out the programme
Learning, embed­ding lessons learnt and under­tak­ing improve­ments should be
continu­ous activ­it­ies through­out the life of a programme. There are also key
points at which it is import­ant to reflect on past activ­it­ies and consider what
is required to enable future success. These reviews should occur at the end
of each project and at the end of each tranche. Lessons should also be fed
back into the organ­isa­tional learn­ing envir­on­ment to help other current and
future programmes.

36
 The programme life cycle

2.6.4 Relevant APM Body of Knowledge sections

The follow­ing sections of APM Body of Knowledge provide further inform­a­tion
on the elements of the deliv­ery phase (other sections of APM Body of Knowledge
also provide inform­a­tion):

1.1.5 Knowledge 3.1.1 Business case 3.2.5 Requirements

manage­ment manage­ment

2.1.1 Communication 3.1.2 Control 3.2.6 Solutions devel­op­ment

2.1.2 Conflict resol­ut­ ion 3.1.5 Planning 3.3.1 Resource schedul­ing

2.1.3 Delegation 3.1.6 Stakeholder 3.3.2 Time schedul­ing

manage­ment

2.1.4 Influencing 3.2.1 Benefits manage­ment 3.4.1 Budgeting and cost

control

2.1.5 Leadership 3.2.2 Change control 3.5.1 Risk context

2.1.6 Negotiation 3.2.4 Change manage­ment 3.5.2 Risk tech­niques

2.1.7 Teamwork

2.7 Programme closure phase

2.7.1 Purpose
The purpose of the closure phase is to under­take all final actions and form­ally
recog­nise that the programme has completed.

2.7.2 Overview
An over­view of the closure phase activ­it­ies, inputs, outputs, controls and
support­ing mech­an­isms is given in Figure 2.9 below.

2.7.3 Key activ­it­ies

A programme will be closed either if all the outcomes required for the future
state in the blue­print have been achieved (noting that the blue­print may be
adjus­ted during the course of the programme), or if the sponsor has proposed

37
APM Introduction to Programme Management

Figure 2.9 Closure phase over­view

a prema­ture cessa­tion (for example, based on the busi­ness case no longer

being viable).
The point at which the closure phase is under­taken, and its dura­tion, will
depend upon the nature of the programme. For example, if the outcome of the
programme is the oper­a­tion of a new facil­ity, closure is likely to occur as soon as
the last project has completed and the final trans­ition has been under­taken with
the facil­ity being handed over to the line manage­ment. Alternatively, where the
programme is required to achieve a complex range of busi­ness bene­fits, there
may need to be a period of use by the customer of the new capab­il­it­ies before the
bene­fits can start to be real­ised, or expec­ted to be real­ised with suffi­cient
confid­ence. In these circum­stances there may need to be a longer period of time
between the final trans­ition and the final programme closure activ­ity.
In either case, once the programme enters the closure phase, stake­hold­ers will
first be noti­fied that the programme is about to complete, in accord­ance with the
commu­nic­a­tion plan, and elicit feed­back from these stake­hold­ers. The
programme team will then ensure that all programme docu­ment­a­tion is completed

38
 The programme life cycle

and filed in accord­ance with the relev­ant busi­ness processes. This activ­ity is often
under signi­fic­ant pres­sure as busi­nesses seek to re-allocate programme teams
early as the closure phase is erro­neously perceived to add little value, but
incom­plete or missing records will cause down­stream prob­lems, partic­ul­arly for
the new steady-state oper­a­tions or for any new related programmes.
A review of programme activ­ity and perform­ance will be under­taken. This is
an import­ant review, the purpose of which will be to verify, amongst other things,
that:

n all deliv­er­ables and capab­il­it­ies have been delivered and transitioned to normal
oper­a­tions success­fully;
n all projects have completed their own indi­vidual project clos­ures;
n all neces­sary records are now in place;
n all customer and supplier invoices have been processed;
n lessons have been reviewed and incor­por­ated into corpor­ate activ­it­ies and
processes, and other valu­able know­ledge, includ­ing an up-to-date programme
summary, has been captured.

The programme team will then provide a report to the spon­sor­ing group/port­fo­lio
deliv­ery group, which will confirm the programme closure. It is recom­men­ded
that some form of celeb­ra­tion is held to recog­nise the success of the programme
and the efforts of all those involved in the programme, and that this occurs before
the programme team is fully redeployed back into the organ­isa­tion.

2.7.4 Relevant APM Body of Knowledge sections

The follow­ing sections of the APM Body of Knowledge provide further inform­a­
tion on the elements of the closure phase (other sections of APM Body of
Knowledge also provide inform­a­tion):

1.1.5 Knowledge 2.1.5 Leadership 3.3.1 Resource schedul­ing

manage­ment

1.2.2 Operations manage­ment 3.1.6 Stakeholder manage­ment 3.4.2 Funding

1.2.3 Strategic manage­ment 3.2.5 Requirements manage­ment 3.6.2 Reviews

39
 3

Programme assess­ment

3.1 Models
Thus far we have described what a programme is and its life cycle; in this section,
we offer a range of concep­tual models that allow a programme to be assessed
through a range of lenses to estab­lish the level of confid­ence that a programme
will be success­ful. A number of models, or struc­tures, are avail­able and this guide
selects illus­trat­ive examples with no implied endorse­ment:

n Body of know­ledge.
n Programme frame­work health checks.
n Assessment models.

3.1.1 Body of know­ledge

A body of know­ledge, such as APM Body of Knowledge or PMI’s PMBOK®,
struc­tures know­ledge in a manner that allows port­fo­lios, programmes and
projects, or rather the skills required to deliver them, to be assessed. As an
example, APM Body of Knowledge describes, under the head­ings of context,
people, deliv­ery and inter­faces, the complete set of concepts, terms and activ­it­ies
that make up our profes­sional domain. The major short­com­ing of using this as a
frame­work to review a programme is the 53 separ­ate topics of know­ledge and
the absence of an estab­lished assess­ment struc­ture. Both these could be
addressed if no better model is avail­able.

3.1.2 Frameworks: Managing Success­ful Programmes

(MSP ®)24/Agile Programme Manage­ment (AgilePM®) 25
MSP ® and AgilePM ® are prob­ably the two best-known meth­od­o­lo­gies for
deliv­ery of major programmes. Both have some guiding prin­ciples that provide a
24
MSP Handbook from AXELOS https://www.axelos.com/store/book/managing-successful-
programmes. MSP® is a registered trade mark of AXELOS Limited. All rights reserved.
25
For more on the DSDM Consortium’s AgilePM ® see http://agile­pro­gram­mem­an­ager.com/

41
APM Introduction to Programme Management

health check for a programme being delivered using their meth­od­o­logy. These
frame­works are partic­ul­arly strong on the ‘soft skills’ – lead­er­ship and ‘vision­ing’.
The seven prin­ciples in MSP ® are:

1. Remaining aligned with corpor­ate strategy.

2. Learning from exper­i­ence.
3. Designing and deliv­er­ing a coher­ent capab­il­ity.
4. Adding value.
5. Focusing on the bene­fits and threats to them.
6. Envisioning and commu­nic­at­ing a better future.
7. Leading change.

The agile philo­sophy that “an agile programme deliv­ers what is required when it
is required – no more no less” is a sound approach for all programmes and is
backed by five prin­ciples to direct the atti­tude of those involved.

1. Continuous goal align­ment to busi­ness strategy.

2. Early and incre­mental bene­fits real­isa­tion.
3. Governance focused on creat­ing coher­ent capab­il­ity.
4. Decision making deleg­ated to lowest possible level.
5. Agile programmes are iter­at­ive and may contain agile and non-agile
projects.

The two sets of prin­ciples show consid­er­able overlap and all should strike a
chord with anyone involved in programme manage­ment. However, while both
afford guidance to staff in programmes, neither provides a suitable structure for
this guide to give a reflective assessment of capabilities required for programme
success.

3.1.3 Assessment models: P3M3®/programme

assess­ment matrices
In 2000, in response to the poor perform­ance of Government projects and
programmes, the Office of Government Commerce (OGC) was estab­lished to
improve deliv­ery. OGC developed a number of tools, includ­ing gateway reviews,
to drive improve­ment and one of these was a ‘meth­od­o­logy agnostic’ matur­ity
model: the port­fo­lio, programme and project manage­ment matur­ity model
(P3M3®)26. Analytical matur­ity models, such as the initial versions of P3M3®, are

42
 Programme assess­ment

often not strong on the soft skills relat­ing to lead­er­ship and the ‘vision­ary’ aspects
of managing a programme (although version 3 of P3M3®, launched in 2015,
intro­duced cross-cutting Threads within the full analysis approach to help address
this issue). But P3M3® does have the benefit of taking a consist­ent approach to
its chosen seven Perspect­ives27 across port­fo­lio, programme and project
manage­ment and thereby allow the differ­ences to be high­lighted. Furthermore,
the model can be run as a self-assessment or extern­ally assessed and provides a
progress­ive way of review­ing the matur­ity of any port­fo­lio, programme or project
in a highly repeat­able manner. Since the release of P3M3® Version 3, access
to P3M3® is primar­ily through AXELOS Accredited Consultancy Organisations
or the substan­tial self-assessment at commer­cial rates. While the basic self-
assessment is simplistic, it does offer an estab­lished, struc­tured, reflect­ive
approach.
A range of other assess­ment matrices exist, such as the one developed in
2011/12 as a research project at Cranfield School of Management.28 This work
developed six progress­ive, linked three-by-three matrices to ask simple ques­tions
around tech­no­logy, busi­ness and people aspects in order to assess the confid­ence
of programme success. The result proved useful to the 10 organ­isa­tions taking
part in the research and is widely avail­able.
Given the ‘meth­od­o­logy agnostic’ and matur­ity model concept of P3M3® that
allows applic­a­tion to organ­isa­tions as well as discrete programmes, this guide will
use P3M3® as its model to guide the reader through a reflect­ive assess­ment of
some key consid­er­a­tions in the success­ful deliv­ery of a programme. The oper­a­tion
of the matur­ity model29 will not be described here but the seven Perspect­ives will
be explained as they apply at programme level, in order to help the reader to look
at their own programmes and organ­isa­tion through these lenses. Given the
generic nature of OGC’s work, a conscious decision was taken NOT to cover the
‘tech­nical’ aspects (engin­eer­ing, medi­cine, busi­ness change etc.) of programmes
and projects. The rationale is that these (clearly) differ very widely depend­ing on
the nature of the busi­ness; the seven Perspect­ives are considered to have
wide­spread applic­a­tion to projects and programmes of all natures and using any
meth­od­o­logy.
26
P3M3® is now run by AXELOS, a private sector joint venture between Capita and the Cabinet
Office.
27
Refer to Section 3.1.2.
28
See http://www.som.cran­field.ac.uk/som/dinamic-content/media/Programme%20Assessment
%20Matrices.pdf
29
For this, refer to the AXELOS website – https://www.axelos.com/best-practice-solutions/p3m3

43
APM Introduction to Programme Management

3.2 Organisational governance

The first perspect­ive views the programme from the ‘outside looking in’ and
seeks to ensure that effect­ive struc­tures (internal and external) are estab­lished
to provide strong and effect­ive over­sight, chal­lenge and direc­tion suppor­ted
by inde­pend­ent assur­ance to ensure effi­cient and timely decision making. Too
often ‘effi­cient and timely’ decision making is comprom­ised by onerous
governance and assur­ance by entit­ies that hold author­ity without account­ab­il­ity
and feel no personal owner­ship of programme success. This perspect­ive
can be considered to have four inter­con­nec­ted dimen­sions: governance
(includ­ing the approvals regime) of the programme; assur­ance of programme
products; design of the oper­at­ing model for the programme; and the
role, respons­ib­il­it­ies, author­it­ies and account­ab­il­it­ies (R2A2) for each role in
the organ­isa­tion – which need to flow coher­ently from the deleg­a­tions in the
governance regime. Given that programmes are about real­ising benefit from
projects in business-as-usual activ­it­ies, there is a natural tension between an
organ­isa­tion optim­ised for deliv­ery of projects and one designed for deliv­er­ing
business-as-usual. Furthermore, the complex rela­tion­ship between programme
sponsor or SRO, project spon­sors, programme manager and project managers
(see also Figure 3.3) is an area frequently not well under­stood without
clear R2A2.

3.2.1 Governance
This aspect addresses how the programme is set up (rather than the
manage­ment organ­isa­tion), ensures that deleg­a­tions to and empower­ment
of the programme manage­ment organ­isa­tion is suffi­cient to enable them to
deliver, and estab­lishes the mech­an­isms through which approvals at programme
and project levels are delivered. (APM’s Directing Change: A Guide to
Governance of Project Management30 is recom­men­ded reading here). Of
partic­u­lar import­ance at programme level is the rela­tion­ship between programme
deliv­ery and the business-as-usual team who will use the outputs of the
compon­ent projects to realise programme bene­fits within routine oper­a­tions for
the busi­ness.

30
See APM public­a­tions, https://www.apm.org.uk/DirectingChange

44
 Programme assess­ment

3.2.2 Assurance
Assurance31 is the means by which decision makers gain confid­ence that the
propos­i­tions coming from the programme are sound. ‘Good’ assur­ance requires
assur­ance bodies to be inde­pend­ent of the programme while being actively
involved in provid­ing progress­ive assur­ance (rather than para­chut­ing in for
specific events) and working in a way that support programme success rather
than requir­ing ‘further work’ that does not mater­i­ally change programme
products. Assurance of any partic­ul­ar aspect of the programme should happen
once only and be under­taken by the appro­pri­ate ‘expert’. Further assur­ance
should satisfy itself as to the compet­ence of and tech­niques deployed by the
assurer rather than subject­ing the target to double jeop­ardy.

3.2.3 Organisation
Drawing a ‘wiring diagram’ is straightforward; what is less easy is the struc­tured
analysis required to identify the func­tions and services required by the
programme, how they should inter­act and what the optimum balance is between
‘project’ and ‘func­tional’ rela­tion­ships and between the programme team and
business-as-usual elements of the organ­isa­tion. Key to this is the appre­ci­ation
that a wiring diagram can only portray a simple two-dimensional line manage­ment
rela­tion­ship; in programme deliv­ery, few indi­vidu­als have exclus­ive account­ab­il­
ity to one indi­vidual for all their respons­ib­il­it­ies. Whilst the clarity provided by a
wiring diagram is neces­sary, it is not suffi­cient: and this is where a compre­hens­ive
set of R2A2 adds value.

3.2.4 Role, respons­ib­il­it­ies, author­ity and

account­ab­il­it­ies (R2A2)
Most people and organ­isa­tions are very famil­iar with a job descrip­tion that
sets out the role and respons­ib­il­it­ies for the post concerned. In the more
complex world of programme manage­ment, clarity comes with under­stand­ing
what author­ity has been deleg­ated to whom. This author­ity is limited by the
governance struc­ture set up for the programme and should not be hard wired
to a post as the deleg­a­tion should be a subject­ive judge­ment made by the

HMG’s guid­ance on assur­ance is avail­able at https://www.gov.uk/govern­ment/public­a­tions/

31

major-projects-approval-and-assurance-guidance

45
APM Introduction to Programme Management

organ­isa­tion based on the confid­ence they have in the indi­vidual’s compet­ence

and reli­ab­il­ity. Too often the ‘account­ab­il­ity’ aspect of R2A2 is confused with
the RACI meaning of account­ab­il­ity; in RACI, account­ab­il­ity refers to the
indi­vidual held to account for the activ­ity being described even though that
indi­vidual may deleg­ate respons­ib­il­ity for execut­ing the work to another party
(as named in the RACI matrix). In R2A2, being focused on the role rather than
the activ­ity, account­ab­il­ity refers to the indi­vidual/post to whom this role is
account­able for dischar­ging specific aspects of their respons­ib­il­it­ies. Frequently,
the role will be account­able to differ­ent posts for differ­ent aspects of their
respons­ib­il­it­ies. The simplest example is the project manager, who is account­able
to the project sponsor for the outputs of the project and to the programme
manager for the coher­ence of the project with other aspects of the programme.
(See Section 3.6.1 below.)

3.3 Management control

The second perspect­ive views the programme ‘from the inside’ and sets up
the control and report­ing mech­an­isms for the programme. At the heart of this
lies the programme manage­ment office (PMO) which can be a ‘thick’ or a ‘thin’
layer depend­ing on: the nature of the programme; decisions on governance;
the close­ness of inter­re­la­tion­ship between the constitu­ent projects; and the
degree of central services and control provided to, and exer­cised over, day to
day oper­a­tions. Much has been written on this topic and this guide draws
the reader’s atten­tion to other APM public­a­tions such as Planning, Scheduling,
Monitoring and Control32 for further inform­a­tion. One aspect that does
demand mention here is the imper­at­ive for manage­ment control at the
programme level to retain a systems think­ing outlook. It is very easy for
manage­ment control to dive into the detailed super­vi­sion of project activ­it­ies
and miss the true value adding aspects of the ‘whole system, whole life’ perspect­
ive. The well-proven tech­nique of earned value manage­ment (EVM)33 should
be applied at project level and used at programme level to under­stand poten­tial
impacts across the programme and, thereby, to drive programme level decision
making.

32
Published in 2015 and avail­able at https://www.apm.org.uk/Planning-Monitoring-Scheduling-
Control
33
See APM public­a­tions, https://www.apm.org.uk/EarnedValueManagement

46
 Programme assess­ment

3.4 Benefits manage­ment

Where projects are about deliv­er­ing ‘outputs’, programmes are about deliv­er­ing
‘outcomes’ and the bene­fits asso­ci­ated with incor­por­at­ing the outcomes in
business-as-usual activ­it­ies. In this respect, most programmes involve a ‘busi­ness
change’ or ‘trans­ition’ compon­ent above and beyond the deliv­ery of the
project output. Benefits manage­ment at programme level can be partic­u­larly
chal­len­ging as:

n there can be a very heavy reli­ance on custom­ers and users (both their
beha­viour and their feed­back);
n the bene­fits are often in a form that is neither easy to measure nor in the vested
interest of some stake­hold­ers to achieve;
n there is frequently a long lead time between project outputs and bene­fits real­
isa­tion during which time the baseline has moved or other factors have
impacted the outcome;
n the compar­ison is between ‘what is’ and ‘what would have been’ with some
parties having a vested interest in shaping the ‘would have been’ and others
taking the view that ‘what might have been’ is no longer relev­ant as we have
to live in the ‘world as we find it’;
n busi­ness cases are prone to over-state­ment of bene­fits in order to gain
approval.

Benefits manage­ment is often misun­der­stood or misin­ter­preted but it is a

vitally import­ant change manage­ment func­tion that demands excel­lent
commu­nic­a­tions, a robust process and sustained support from all change
stake­hold­ers during imple­ment­a­tion across the project and programme
manage­ment busi­ness land­scape so that the true impact of cost, oper­a­tional,
organ­isa­tion and/or compliance-based bene­fits can be meas­ured and real­ised.
Various APM white papers34 have been produced to aid people trying to
develop their under­stand­ing and skill in this area: pick the one most relev­ant to
your needs.

34
Given the dynamic nature of this topic, the APM Benefits SIG has opted to develop a series of
focused white papers rather than a single compre­hens­ive guide. The white papers can be found on
the APM website at https://www.apm.org.uk/white-papers

47
APM Introduction to Programme Management

3.5 Stakeholder manage­ment

Good stake­holder manage­ment in the programme arena requires the same skills
as good stake­holder manage­ment in other walks of life, using tools relev­ant to
the scale of the task – ranging from a simple two-by-two importance-by-influence
matrix to soph­ist­ic­ated stake­holder rela­tion­ship manage­ment soft­ware. While
categor­isa­tion of stake­hold­ers into: client/sponsor, user, customer, supplier,
influ­en­cer, beneficiaries, team/staff, etc, will always apply, the prin­cipal chal­lenges
for stake­holder manage­ment at programme level often arise in three areas
discussed below.

3.5.1 Intra programme

As described in Section 3.1, the rela­tion­ship between sponsor teams and deliv­ery
teams at programme and project levels within the programme requires careful
stake­holder manage­ment to ensure that project drivers and incent­ives do not
drive sub-optimal programme consequences. This is a greater risk where the
client/sponsor organ­isa­tion is not exper­i­enced at programme manage­ment and
hence sponsor/SRO rela­tion­ships are not mature. Getting the rela­tion­ships right

Figure 3.1 Key stake­holder rela­tion­ships between projects, programmes and

port­fo­lios

48
 Programme assess­ment

between the ‘corners of the square’ can be a real chal­lenge and all parties should
resist the tempta­tion to have conver­sa­tions across the diag­on­als as this cuts
across the correct governance rela­tion­ships.

3.5.2 Business-as-usual stake­hold­ers

In a highly tuned busi­ness focused on business-as-usual activ­ity and unfa­mil­iar
with programmes and projects, the chal­lenges of managing business-as-usual
stake­hold­ers can be twofold. First, the organ­isa­tional design (see Section 3.2.3)
of business-as-usual is frequently at odds with programme and project R2A2 (see
Section 3.2.4), which cut across func­tional hier­arch­ies. Second, at programme
level it is usually the business-as-usual stake­hold­ers (the target audi­ence for the
busi­ness change projects within the programme) who will be expec­ted to adapt
their way of working if the bene­fits of the programme are to be real­ised. People
will have a mix of responses to the changes, some being more enthu­si­astic than
others, and many having real concerns that it will be import­ant to surface,
consider and respond to. Any points on Elisabeth Kübler-Ross’s change curve35
would be good start­ing posi­tions to under­stand the differ­ent emotions that
people might be exper­i­en­cing.

3.5.3 External to programme

The larger and more high profile the programme, the greater the number of
‘experts’ in the topic who believe they have a crit­ical and legit­im­ate interest in it
– usually from a narrow view­point and often with very little under­stand­ing of the
basic prin­ciples of programme manage­ment. Most will believe they are able to
wield a ‘red card’ – which is why setting up the governance (Section 3.2) correctly
is a prerequis­ite for success­ful programme deliv­ery. However, the power of
‘influ­ence’ should never be under­es­tim­ated and stream­lined governance alone
is not suffi­cient to manage the key external stake­hold­ers: this takes time, effort
and a full appre­ci­ation that ‘commu­nic­a­tions’ is two-way process. The import­ance
of build­ing ‘public’ support for the programme (and the role of the media,
includ­ing social media, at the appro­pri­ate level – national, regional, neigh­bour­
hood, company-wide or at divi­sional level) should not be under­es­tim­ated: nor
should the steps that the ‘nay-sayers’ may be willing to take to under­mine the
programme.

35
Kübler-Ross, E. (1969) On Death and Dying, Routledge, ISBN 0-415-04015-9.

49
APM Introduction to Programme Management

3.6 Risk manage­ment

At every point during a programme, there will be uncer­tain events or situ­ations
that could affect the direc­tion of the programme, the achievement of desired
outcomes or the real­isa­tion of expec­ted bene­fits. These uncer­tain events or situ­
ations, and their consequences, are the risks that the programme must manage
and relate to the role of programme manage­ment in provid­ing the link between
indi­vidual projects and their stra­tegic intent. Programmes are funda­ment­ally
differ­ent from projects; as a result, risks at programme level should be viewed
differ­ently from those at project level. The descrip­tion of risk manage­ment here
delib­er­ately goes into propor­tion­ately greater detail than for the other Perspect­
ives in this section in light of the signi­fic­ance of risk manage­ment at this level.
Using projects as the funda­mental deliv­ery mech­an­ism, Figure 3.1 shows the
struc­tural rela­tion­ship that links programmes and projects within the organ­isa­
tional envir­on­ment and provides a frame­work to deliver bene­fi­cial change to
organ­isa­tions via programmes, by trans­fer­ring strategy down, whilst deliv­er­ing
capab­il­ity up. It is this organ­isa­tional envir­on­ment and the rela­tion­ship between
programmes, projects and strategy that under­pin how risks are viewed at
programme level. Major change is usually synonym­ous with complex­ity, risk,
many inter­de­pend­en­cies to manage and conflict­ing prior­it­ies to resolve. By
employ­ing a tailored approach to risk manage­ment within the programme
envir­on­ment, prac­ti­tion­ers will be better equipped to tackle increased complex­ity
and, although the estab­lished concepts of project risk manage­ment prac­tice may
be applied, the applic­a­tion of these tools may need to be differ­ent.
But how does the programme manager relate the ‘tradi­tional’ project risk
manage­ment meth­od­o­lo­gies and tools, within the context of programme risk
manage­ment? To help answer this we first need to under­stand the sources of
risk from a programme perspect­ive; Figure 3.2 high­lights poten­tial sources.
Although there are close simil­ar­it­ies between the process for expli­cit
manage­ment of indi­vidual programme risks and the well-established project risk
manage­ment process, programme risks can arise from above and below the
programme (within the organ­isa­tional context) as well as from within it and,
there­fore, the programme risk manage­ment process must tackle all of these
sources.
In summary, risks driving uncer­tainty within programmes origin­ate from:

n stra­tegic level;
n project level;

50
 Programme assess­ment

Figure 3.2 Sources of programme risk (repro­duced from Hillson, 200936)

n within the programme (derived from inter­faces between programme

compon­ents and external risks termed EXPLICIT risks);
n programme risks origin­at­ing from actual programme execu­tion termed
IMPLICIT risks;
n non-project compon­ents.

The main risk treat­ment processes and their sources are:

n aggreg­a­tion – project to programme;

n escal­a­tion – project to programme;
n deleg­a­tion – stra­tegic level to programme;
n assim­il­a­tion – from within the programme includ­ing expli­cit and impli­cit risks.

We now extend Figure 3.2 to overlay risk treat­ment processes on the programme
risk sources to see a sugges­ted meth­od­o­logy for managing programme risk

36
See Hillson, D. A. 2009. Managing Risk in Projects. Farnham, UK: Gower. ISBN 978-0-566-08867.

51
APM Introduction to Programme Management

(Figure 3.3). Much has been written on this topic and this guide draws the
reader’s atten­tion to other public­a­tions such as AXELOS’s ‘Management of
Risk’37
It is recog­nised that in project risk manage­ment, the focus is on managing
threats and oppor­tun­it­ies to the deliv­ery of project outputs. Given the focus of
programmes is on deliv­er­ing bene­fits, programme managers are likely to focus
on events that threaten bene­fits real­isa­tion and the programmes ability to deliver
change manage­ment activ­it­ies within the programme as well as the combined
impact of the project risk and risks deleg­ated from port­fo­lio or stra­tegic level.
A crit­ical compon­ent of programme-level risk manage­ment lies in the estab­
lish­ment, estim­at­ing and release (either to relev­ant projects or back to funders) of
risk funding. Human nature dictates that ‘project money will usually get spent’ – if

Risk delegation
process

Strategic
level
Delegated

Explicit Implicit
strategic
risks

risks risks

Overall programme
risk management
management
Event risk

Programme
process

process

Programme Programme
risks
level risks
project risks

Escalated and
aggregated

Risk escalation Risk aggregation

process process

Project level

Figure 3.3 Programme risk sources, mech­an­isms and treat­ment processes

37
See OGC’s Management of Risk (https://www.axelos.com/store/book/management-of-risk-
guidance-for-practitioners) and/or APM’s Project Risk Analysis Management Guide (https://
www.apm.org.uk/PRAMGuide).

52
 Programme assess­ment

it is not used to mitig­ate threats it might be util­ised to deliver addi­tional scope

reques­ted by the client; irre­spect­ive of whether this repres­ents best value for
money at higher levels. ‘Good prac­tice’ at programme level will see the programme
manager controlling the release of project risk funding to project managers using
appro­pri­ate change control with risk provi­sion held at various levels and released
accord­ingly. A partic­u­lar benefit of this approach is that the whole programme
risk provi­sion should be consid­er­ably less than the sum of all project risk
provi­sions. Furthermore, any unre­quired provi­sion can be released to the
port­fo­lio manager or client progress­ively for rein­vest­ment in the busi­ness, rather
than being hoarded until the ‘last safe moment’ when the project comes in under
budget – to the delight of some and the frus­tra­tion of others.

3.7 Financial manage­ment

While this topic recog­nises the needs of good finan­cial account­ing, the differ­en­
ti­ator here lies in getting the finan­cial account­ants to recog­nise and embrace the
needs of project account­ing. Programme finances do not follow the normal
predict­able cycle (very often annual) of busi­ness accounts and gaining recog­ni­
tion that whilst programmes can (and must) deliver annual accounts, optimum
perform­ance is not achieved by constrain­ing programmes through strict annual
metrics. In this respect, a mater­ial contri­bu­tion that the programme manage­ment
team will make is managing the finan­cial approval cycle for the busi­ness on behalf
of the constitu­ent projects in the programme.
Whilst the approval struc­ture is estab­lished under organ­isa­tional governance
(Section 3.2) and the bene­fits real­ised through bene­fits manage­ment (Section
3.4), the busi­ness case itself is developed, managed and tracked under the
finan­cial manage­ment func­tion. When change occurs – as it does on every
programme – a change impact assess­ment is required to valid­ate the impact on
the busi­ness case and take action accord­ingly.
One of the key roles of finan­cial manage­ment at programme level is setting
and deliv­er­ing the optimal struc­ture for risk and contin­gency budgets across the
programme. The natur­ally conser­vat­ive nature of good project managers
indic­ates that they will seek (and retain) a larger risk and contin­gency budget
than they are likely to require: good programme manage­ment needs to strike the
right balance and ensure that the money set aside for risk and contin­gency is
assessed across the programme so that it can be released – to projects or back to
funders – in a way that avoids tying up capital in an inef­fic­ ient manner for the

53
APM Introduction to Programme Management

busi­ness as a whole. Few will applaud a programme manager who hands back a
large lump sum of unused contin­gency at the very end of the programme.

3.8 Resource manage­ment

The seventh perspect­ive is widely acknow­ledged to have four compon­ents.

3.8.1 Human resources

The first and most widely recog­nised compon­ent is the P3M staff involved in the
enter­prise, includ­ing their compet­ence and train­ing. At programme level, this is
very much about ensur­ing that the right staff with the right skills are avail­able
and appro­pri­ately balanced across the PMO and compon­ent projects. Where
the programme exists within an endur­ing organ­isa­tion, staff devel­op­ment for
the future and succes­sion plan­ning within the programme and at port­fo­lio level
are import­ant consid­er­a­tions.

3.8.2 Supply chain

Few commer­cial/procure­ment staff appre­ci­ate being ‘subor­din­ated’ to the
second level of the Perspect­ives model but, within this concep­tual frame­work,
the supply chain (and the resources and mater­ial it brings) is but one – often
domin­ant in finan­cial and deliv­ery terms – aspect of resource manage­ment. At
programme level, supply chain manage­ment is frequently crit­ical as most
contracts are let at project level, but optimal programme deliv­ery requires
coordin­a­tion of deliv­ery (or resource deploy­ment) at programme or even port­fo­lio
level to ensure effi­cient use of such resources across the whole programme.

3.8.3 Infrastructure
The phys­ical and virtual infra­struc­ture for the programme (and the projects
within it) is a crit­ical resource that requires careful consid­er­a­tion during
programme set up at the begin­ning of the deliv­ery phase of the life cycle.
This is the bedrock on which effect­ive manage­ment control is built and
demands careful thought in terms of integ­ra­tion across projects and into
business-as-usual (both during programme deliv­ery and once incor­por­ated into
business-as-usual).

54
 Programme assess­ment

3.8.4 Information
Information in a programme is a key resource and demands careful consid­er­a­tion
of its struc­tur­ing and treat­ment – as with infra­struc­ture, effort commit­ted to this
early in the life cycle is seldom wasted. To be clear, the inform­a­tion resource is an
‘enabler’: it needs to be managed within the IT infra­struc­ture and ‘used’ within
other relev­ant Perspect­ives. But unless it is struc­tured correctly from the outset
(using prin­ciples such as ‘one version of the truth’), commu­nic­ated and followed
with discip­line, programme execu­tion will be inef­fi­cient and record keeping may
be inad­equate. Even where a programme may not be large enough to justify the
formal appoint­ment of a chief inform­a­tion officer, the role should be alloc­ated to
someone with the compet­ence and author­ity to exer­cise control in this key area.

3.9 Summary
The use of concep­tual frame­works to ‘look at’ a programme allows a reflect­ive
analysis of perform­ance and deliv­ery confid­ence. Covering all the Perspect­ives
outlined here is no guar­an­tee of programme success – but poor cover­age of any
of the topics will mater­i­ally increase the like­li­hood of failure.

55
 Glossary

Agile A family of devel­op­ment meth­od­o­lo­gies where require­ments and

solu­tions are developed iter­at­ively and incre­ment­ally through­out the life cycle.
Benefit The quan­ti­fia­ ble and meas­ur­able improve­ment result­ing from
comple­tion of deliv­er­ables that is perceived as posit­ive by a stake­holder. It will
normally have a tangible value, expressed in monet­ary terms that will justify the
invest­ment.
Benefits manage­ment The iden­ti­fic­a­tion, defin­i­tion, plan­ning, track­ing and
real­isa­tion of busi­ness bene­fits.
Benefits real­isa­tion The prac­tice of ensur­ing that bene­fits are derived from
outputs and outcomes.
Blueprint A docu­ment defin­ing and describ­ing what a programme is designed
to achieve in terms of the busi­ness and oper­a­tional vision.
Board A body that provides spon­sor­ship to a programme. The board will
repres­ent finan­cial, provider and user interests.
Brief The output of the concept phase of a programme.
Business-as-usual An organ­isa­tion’s normal, day-to-day oper­a­tions.
Business case Provides justi­fic­a­tion for under­tak­ing a programme. It
eval­u­ates the benefit, cost and risk of altern­at­ive options and provides a rationale
for the preferred solu­tion.
Business change manager The role respons­ible for bene­fits manage­ment
from iden­ti­fic­a­tion through to real­isa­tion.
Change control The process through which all requests to change the
baseline scope of a programme are captured, eval­u­ated and then approved,
rejec­ted or deferred.
Change manage­ment A struc­tured approach to moving an organ­isa­tion
from the current state to the desired future state.

57
Glossary

Closure The formal end point of a programme, either because it has been
completed or because it has been termin­ated early.
Competence frame­work A set of compet­ences and compet­en­cies that may
be used to define a role.
Concept The first phase in the programme life cycle. During this phase the
need, oppor­tun­ity or problem is confirmed, the overall feas­ib­il­ity of the work is
considered and a preferred solu­tion iden­ti­fied.
Configuration manage­ment The admin­is­trat­ive activ­it­ies concerned with
the creation, main­ten­ance, controlled change and quality control of the
programme scope.
Contingency Resource set aside for respond­ing to uniden­ti­fied risks.
Control Tracking perform­ance against agreed plans and taking correct­ive
action required to meet defined object­ives.
Definition The second phase of a programme life cycle where require­ments
are refined and the preferred solu­tion, and ways of achiev­ing it, are iden­ti­fied.
Disbenefit A consequence of change perceived as negat­ive by one or more
stake­hold­ers.
Environment The circum­stances and condi­tions within which the programme
must operate.
Financial manage­ment The process of estim­at­ing and justi­fy­ing costs in
order to secure funds, controlling expendit­ure and eval­u­at­ing outcomes.
Gate The point between phases, gates and/or tranches where a go/no-go
decision can be made about the remainder of the work.
Governance The set of policies, regu­la­tions, func­tions, processes, proced­ures
and respons­ib­il­it­ies that define the estab­lish­ment, manage­ment and control
programmes.
Handover The point in the life cycle where deliv­er­ables are handed over to
the sponsor and users.
Information manage­ment The collec­tion, storage, dissem­in­a­tion, archiv­ing
and destruc­tion of inform­a­tion. It enables teams and stake­hold­ers to use their
time, resource and expert­ise effect­ively to make decisions and to fulfil their roles.

58
 Glossary

Issue A formal issue occurs when the toler­ances of deleg­ated work are
predicted to be exceeded or have been exceeded. This trig­gers the escal­a­tion of
the issue from one level of manage­ment to the next in order to seek a solu­tion.
Leadership The ability to estab­lish vision and direc­tion, to influ­ence and align
others towards a common purpose and to empower and inspire people to achieve
success.
Lessons learned Documented exper­i­ences that can be used to improve the
future manage­ment of programmes.
Life cycle The inter-related phases of a programme, provid­ing a struc­ture for
govern­ing the progres­sion of work.
Mandate The mandate is used to enable the spon­sor­ing group to decide
whether to alloc­ate resources to fully explore the poten­tial for a programme.
Management plan A plan that sets out the policies and prin­ciples that will be
applied to the manage­ment of some aspects of the programme. Examples include
a risk manage­ment plan, a commu­nic­a­tion manage­ment plan and a quality
manage­ment plan.
Maturity model An organ­isa­tional model that describes a number of evol­u­
tion­ary stages through which an organ­isa­tion improves its manage­ment process.
Objectives Predetermined results towards which effort is direc­ted. Objectives
may be defined in terms of outputs, outcomes and/or bene­fits.
Opportunity A posit­ive risk event that, if it occurs, will have a bene­fi­cial effect
on achieve­ment of object­ives.
Optimising The fifth and last level of a typical matur­ity model where
continu­ous process improve­ment is enabled by quant­it­at­ive feed­back from the
process and from pilot­ing innov­at­ive ideas and tech­no­lo­gies.
Organisation The manage­ment struc­ture applic­able to the programme and
the organ­isa­tional envir­on­ment in which it oper­ates.
Outcome The changed circum­stances or beha­viour that results from the use
of an output.
Output The tangible or intan­gible product typic­ally delivered by a project.
Phase The major sub-di­vi­sion of a life cycle.

59
Glossary

Portfolio A group­ing of an organ­isa­tion’s projects and programmes. Portfolios

can be managed at an organ­isa­tional or func­tional level.
Product A tangible or intan­gible compon­ent of a project’s output synonym­ous
with deliv­er­able.
Programme A group of related projects and change manage­ment activ­it­ies
that together achieve bene­fi­cial change for an organ­isa­tion.
Programme manage­ment The coordin­ated manage­ment of projects and
change manage­ment activ­it­ies to achieve bene­fi­cial change.
Project A unique, tran­si­ent endeav­our under­taken to achieve planned
object­ives.
Quality The fitness for purpose or the degree of confid­ence of the outputs,
bene­fits and the processes by which they are delivered, meet stake­holder
require­ments and are fit for purpose.
Requirements manage­ment The process of captur­ing, assess­ing and
justi­fy­ing stake­holder’s wants and needs.
Resource manage­ment The acquis­i­tion and deploy­ment of the internal and
external resources required to deliver the programme.
Resources All those items required to under­take work includ­ing people,
finance and mater­i­als.
Risk The poten­tial of an action or event to impact on the achieve­ment of
object­ives.
Risk analysis An assess­ment and synthesis of risk events to gain an
under­stand­ing of their indi­vidual signi­fic­ance and their combined impact on
object­ives.
Risk event An uncer­tain event or set of circum­stances that would, if it
occurred, have an effect on the achieve­ment of one or more object­ives.
Risk manage­ment A process that allows indi­vidual risk events and overall
risk to be under­stood and managed proact­ively, optim­ising success by minim­ising
threats and maxim­ising oppor­tun­it­ies.
Risk register A docu­ment listing iden­ti­fied risk events and their corres­pond­
ing planned responses.

60
 Glossary

Schedule A timetable showing the fore­cast start and finish dates for activ­it­ies
or events within a programme.
Scope The total­ity of the outputs, outcomes and bene­fits and the work
required to produce them.
Scope manage­ment The process whereby outputs, outcomes and bene­fits
are iden­ti­fied, defined and controlled.
Setting The rela­tion­ship of the programme with its host organ­isa­tion.
Sponsorship An import­ant senior manage­ment role. The sponsor is account­
able for ensur­ing that the work is governed effect­ively and deliv­ers the object­ives
that meet iden­ti­fied needs.
Stakeholder The organ­isa­tions or people who have an interest or role in the
programme or are impacted by it.
Stakeholder manage­ment The system­atic iden­ti­fic­a­tion, analysis, plan­ning
and implic­a­tion of actions designed to engage stake­hold­ers.
Threat A negat­ive risk event; a risk event that if it occurs will have a detri­
mental effect on the object­ives.
Tranche A sub-division of the deliv­ery phase of a programme created to
facil­it­ate approval gates at suit­able points in the life cycle.
Users The group of people who are inten­ded to receive bene­fits or operate
outputs.
Vision The vision describes the future state the programme is inten­ded to
deliver.
Vee Model A sequential life cycle model used to represent the continuous
verification and validation of plans and results.

61
 References

APM EVM SIG (2008), Earned Value Management: APM Guidelines, 2nd
edition. Princes Risborough, Association for Project Management.
APM Governance SIG (2011), Directing Change: A Guide to the Governance
of Project Management. Princes Risborough, Association for Project
Management.
APM North West branch (2015), The Practical Adoption of Agile Methodologies.
Available at https://www.apm.org.uk/sites/default/files/The-Practical-
Adoption-of-Agile-Methodologies.pdf
APM PMC SIG (2015), Planning, Scheduling, Monitoring and Control: The
Practical Project Management of Time, Cost and Risk. Princes Risborough,
Association for Project Management.
APM PMO SIG (n.d.). Available at https://www.apm.org.uk/group/apm-pmo-
specific-interest-group
APM Risk SIG (2010), Project Risk Analysis and Management Guide, 2nd
edition. Princes Risborough, Association for Project Management.
Association for Project Management (2007), Models to Improve the
Management of Projects. Princes Risborough, Association for Project
Management.
Association for Project Management (2012), APM Body of Knowledge 6th
edition. Princes Risborough, Association for Project Management.
Association for Project Management (2015), APM Competence Framework, 2nd
edition. Princes Risborough. Available at https://www.apm.org.uk/competence-
framework
AXELOS (2010), Management of Risk Guidance for Practitioners, London.
AXELOS (2011), Managing Successful Programmes, London.
AXELOS (2015), Portfolio, Programme and Project Management Maturity Model
(P3M3), London.
Gray, A. and Richardson, K. (2015), Valuing Our Place in the World – Using
Systems Engineering in Programme and Project Management, INCOSE UK
Annual Systems Engineering Conference.
Hillson, D. A. (2009), Managing Risk in Projects. Farnham.

63
References

HM Treasury (2015), Public Sector Business Cases Using the 5 Case Model (HM
Treasury Green Book supple­ment­ary guid­ance). Available at https://www.
gov.uk/govern­ment/public­a­tions/the-green-book-appraisal-and-evaluation-
in-central-governent [sic].
Kübler-Ross, E. (1969), On Death and Dying. Routledge.

64
 Index
AgilePM ® methodologies 41–42 report and review progress 34–35
APM Body of Knowledge resources and budget management 33–34
closure phase 39 review and update plans 35
concept phase 26 risk management 32
conceptual models 41 stakeholders 32–33
definition phase 29 tranches and component projects 31
delivery phase 37 learning environment 36
assessment 41–55 overview 30, 30
assurance 11, 45 purpose 29
transition 35–36
benefits management 15–16, 17, 47
business-as-usual stakeholders 49 financial management 53–54
frameworks
challenges 16–17 conceptual 41–42
change management 21 P3M3® 12, 42–43
change vs. steady-state activities 20
closure phase 37–39 governance 11, 24–25, 44–46
key activities 37–39
overview 37, 38 human resources (HR) 13–15, 54
purpose 37
concept phase 24–26 information, programme 55
key activities 25–26 infrastructure, programme 54
overview 24, 25 initiation phase see definition phase
purpose 24 intra programme 48–49
control
management 46 life cycle 19–39
programme 11 high level 19–20
representation 19
definition phase 26–29, 27 strategy considerations 20–23
key activities 27–29 tensions 23
overview 26, 26
purpose 26 methodologies 41–42
delivery phase 28, 29–37 models, conceptual 41–43
benefits realisation 36 MSP ® methodologies 41–42
key activities 30–36
coordinate plans and schedules 31–32 P3M3® Framework 12, 42–43
confirm viability 35 phases

65
Index

closure 37–39 R2A2 (role, responsibilities, authority and

concept 24–26 accountabilities) 45–46
definition 26–29 resource management 54
delivery 29–37 responsibilities and roles 14, 45–46
portfolio vs. programme management 9–10 risk management 32, 50–53, 51, 52
programme roles and responsibilities 14, 45–46
definitions of 1–3
features 2 stakeholder management 32–33, 48–49, 48
types 3 strategies
programme management 4–5, 10–13, 17 approaches 5, 22
vs. portfolio management 9–10 considerations 20–23
vs. project management 7–9, 8 direction 5–7
project management 17 supply chain 54
vs. programme management 7–9, 8
public support 49 tensions 23

66
Association for Project Management

Ibis House, Regent Park Telephone +44 (0) 845 458 1944
Summerleys Road Facsimile +44 (0) 845 458 8807
Princes Risborough Email info@apm.org.uk
Buckinghamshire HP27 9LE Web www.apm.org.uk