Programs and program management

Introduction to Program Management

1.1 What is a program?

The term ‘program’ can mean different things to different people. Programs come in all shapes
and sizes, and the term ‘program’ is applied to many different structures. Thus, its use and
meaning can vary widely across industry sectors and business cultures. For example, in the
construction industry ‘program’ often refers to the timetable of activities that must be completed
(the schedule), whilst ‘program management’ can refer to the process of integrating separate
project schedules. As an example, on a large engineering project there may be several
contractors, each managing a range of subcontractors – all of whom will produce their own
separate schedules of work, referred to as ‘programs’ – and the integration of these many
schedules into a coherent master schedule would be called ‘program management’.

Also in the construction, utilities and heavy engineering industries the term ‘program
management’ is often used by contracting organizations to refer to a portfolio of projects that
benefit from a consistent or integrated form of management. These projects typically result in
deliverables created by a contractor for a client organization in exchange for payment, and
therefore the contractor has a limited interest and influence over the delivery of benefits.

A program can be defined as a group of related projects and change management activities that
together achieve beneficial change for an organization.

Programs are about making lasting change in a controlled manner, so to understand programs we
first need to understand change and change management. Change management is a structured
approach to moving an organization from the current state to the desired future state. This
recognizes that the conversion of outputs into outcomes and benefits invariably requires some
form of business or societal change. Implicit in this is the importance of engaging and
influencing the individuals (stakeholders) involved. People will respond to change in various
ways, and resistance to change is a natural phenomenon. Managing change in a structured and
controlled manner and in a way that promotes open dialogue with stakeholders is essential if the
benefits in a business case are to be realized. The growing scale of change, the need to respond

1
quickly to changing business environments and the impact of new technologies has led many
organizations to adopt programs as the means of achieving an organizational strategic change.

Programs are temporary management structures designed to help organizations to achieve

specific objectives.

The successful delivery of change relies on a systematic approach that manages the relationships,
dependencies and interfaces across the organization. This is integral to the successful delivery of
change and the benefits expected to be delivered during the change and onwards once delivered.
Change occurs across multiple projects and may incorporate business-as-usual activities within
the program scope, and this needs to be coordinated to ensure success. Thus, a program of
change is required, and this needs to be managed to support strategic direction and benefits
realization.

As the mechanisms by which organizations deliver their strategies, programs are as varied as the
organizations that initiate them and the strategies they seek to fulfill. There are many types of
programs of change, for example related to information technology (such as rolling out a new
technology platform), organizational change (such as during a merger of two organizations or an
internal restructure), civil engineering (such as opening a new road) or product development
(such as introducing a new mobile phone to the market).

Programs of change are applied across different industry sectors, including government,
telecommunications, finance, transport, energy, manufacturing, defense and utilities, to name a
few. As such, program management as a change delivery mechanism is now in widespread use,
although maturity levels in different sectors and different organizational types will vary.

Programs can also be thought of as business change or transformation programs, in that they seek
to change some aspect of an organization, or even the organization itself.

Programs may vary in size, type and structure, and how they are applied; however, programs
generally display a similar set of characteristics, as follows:

 Their purpose is to deliver the capability to make strategic, significant or step changes to
organizations, or to an organization’s business activities, or to an environment that an
organization is seeking to support, normally referred to as, or measured by, benefits.

2
  The need for significant improvement will be consistent with the organization’s strategy,
and programs will help to deliver elements of that strategy.
 The realization of the desired benefits will be achieved only through the
coordination and successful completion of a number of component projects and,
frequently, their incorporation into business-as-usual.
 Different parts of an organization or differing organizations may be affected by the
program.
 The overall measure of success will be determined by the actual delivery of the expected
benefits, which frequently involves the use of capabilities or facilities created by the
program in an on-going, ‘business-as-usual’ manner.

Programs invariably involve significant change. This needs to be coordinated across multiple
projects and business-as-usual units.

1.2 What is program management?

Program management can be defined as “the coordinated management of projects and change
management activities to achieve beneficial change”.

Because programs are the method by which change is delivered in pursuit of strategic objectives,
program management provides a management interface between those responsible for deciding
strategy and those responsible for managing the component projects and other activities.
Programs deliver improvement and change that will successfully achieve the
desired outcomes, thus establishing the environment for generating benefits aligned to the
organization’s objectives within the organization’s cultural and economic environment.
Typical program management responsibilities include:

 selecting, initiating and monitoring the component projects that make up the programs,
including defining the scope of individual projects;
 progressively developing and re-validating a sound business case;
 managing the expectations of key stakeholders and engaging their support;
 managing risks associated with the internal and external environments;

3
  coordination between component projects and synchronization of dependencies;
 managing program change, such as cancelling projects or changing the scope of projects
in reaction to changes in the organization’s strategy or environment;
 coordination of business-as-usual activities where they fall within the defined scope of
the program;
 identifying, supporting, measuring, monitoring and managing the realization of benefits.

In summary, program management provides a layer of management, above that of the

component project management teams, focused on defining, integrating and coordinating the
projects to maximize the value of the combined deliverables of the component projects into fully
usable capabilities that may be used to deliver the desired benefits and to realize strategic
objectives.

1.3 Program management and strategic direction

Strategic planning and setting the direction for an organization is fundamentally different from
operational management. Senior managers and executives deal with uncertainty and ambiguity as
they set strategic direction, and then adapt this to address changes and challenges in the
environment the organization is operating in and its direction of travel. Whereas, at a project
level, project managers operate with clarity of purpose, for example around cost, timescale
and quality targets as defined by the single project.

When project managers work with senior managers these differences in viewpoint and approach
can cause friction as the expectations of both parties can be fundamentally different. Program
management teams operate between directors (strategy focus) and project managers (delivery
focus). Program managers’ skills are in understanding the strategic direction of the organization,
ensuring that there is an alignment of the suite of projects to support the business objectives,
working in an uncertain environment and responding to change with a constant focus on
achieving benefits. When collections of different projects are used to move an organization
towards a strategic change, alongside business-as-usual operations, it is more efficient and
beneficial to structure this strategic change as a program.

Having a program management approach allows the organization’s senior managers and
directors to focus on setting direction, considering medium and long-term issues, whilst the

4
program manager will ensure that this is translated into the language of projects, manage the
project managers and deliver to the organization the required changes and capabilities to enable
realization of the desired benefits. In many organizations change programs tend to cut across
business-as-usual structures. For example, a program transforming a bank’s operation to internet-
based services will need to interact with the bank’s existing vertical and functional structures, i.e.
operations, IT, human resources (HR), finance, marketing and so on. The aims and objectives of
these groups may not always be aligned and, unless such interactions are carefully planned in
conjunction and with the cooperation of each business unit, the program could run into a ‘brick
wall’ of non-cooperation. Planning and managing such interactions are a key activity within
program management.

Most large organizations can have several change programs running concurrently. Therefore, the
most senior levels of management need to take seriously not only the ‘sponsorship’ roles for
individual programs, but also the management of the change programs in a way that recognizes
the potential multiple points of impact on the stakeholders involved. An organization’s directors
must create the environment in which change programs can succeed in delivering outcomes and
benefits, and hence the strategy. Business change and program management should therefore be
well understood by the most senior management in an organization and be represented at that
level.

1.4 How do programs differ from projects?

While there is frequent overlap between program and project management activities, it is wrong
to regard programs as merely large and complex projects. They are usually larger than projects,
in terms of number of staff and duration, but not necessarily so. Projects generally do not include
business-as-usual activities, whereas programs may include (and certainly interact with) such
activities; inclusion of business-as-usual activities and program composition is generally
determined by organizational policy. Programs have a different purpose and require different
management structures and skills to be successful.

Projects are the means to deliver specific one-off deliverables. To be successful, the required
deliverables must be defined in advance, with defined budgets and timetable expectations. By
contrast, programs are the means to deliver benefits or outcomes, and amongst their activities are

5
those needed to define and agree the scope of the various projects that will make the achievement
of the desired benefits possible. For example, a project might create a new warehouse, i.e. a
deliverable. A warehouse on its own may seem to have little direct value, but when it is
combined with the deliverables of other projects – such as a computerized stock-control system,
a retrained workforce, a new organizational structure, or a new staff bonus scheme – in a
program, it can provide the capability of supplying customers faster, with reduced costs and less
wastage due to goods damaged in transit, which are the benefits realized by the program.

Success for a project is usually defined as creating the required deliverables to an adequate
standard, within agreed time and cost constraints. Whether the deliverable, such as a new
warehouse, is successfully used or not is not the point. Indeed, there are many projects that have
been deemed highly successful, as judged by the project’s measures of success, that have created
deliverables that have never actually been used. Success for a program is usually measured in
terms of creating a whole new capability and, increasingly, the extent to which the expected
benefits are actually realized.

The term program management is often used to refer to the execution of several projects by a
contractor for a client. It could be argued that this is not program management as we have
defined it and is in fact a series of unrelated projects which happen to share a common set of
resources, and likely a common approach and methodology. People have used ‘program’ in the
past, where we would now use the term ‘portfolio of projects’. Examples could include the
construction of a number of water treatment plants for a local utility body or a series of retail unit
refurbishments by a shop-fitting contractor for a retail chain. If, however, this is a series of
related projects, or coordinated delivery of a set of projects that, managed together achieve
benefit of a strategic nature, then this is program management – the key question is ‘are they
aligned to achieve a combined benefit’, or are they just delivering a series of outputs.

Project management is the application of processes, methods, knowledge, skills and experience
to achieve project objectives.

Portfolio management is the selection, prioritization and control of an organization’s projects and
programs in line with its strategic objectives and capacity to deliver. The goal is to balance
change initiatives and business-as-usual while optimizing return on investment.

6
Table 1.1 Summary of key differences between programs and projects

Aspect Programs Projects

Clarity of Programs involve uncertainty in funding, Projects require clearly defined scope,
scope range and impact. budget and timescales
Clarity of Specific deliverables to be created are The required deliverables are usually
deliverables usually unclear at the start. clearly defined at the start.
Structure Separately managed projects, which must be A project forms a single managed
coordinated. The structure may be unclear at entity, which is clear at the start and
the start and may change throughout the life will not usually change significantly
of the program. during the life of the project.
Methodologies Frequently involves coordinating and A single project is normally the
or approach managing several different organizations, responsibility of a single organization,
each of which is responsible for one or more working to a single methodology or
discrete projects, and each of which may be project approach.
using a different methodology of project
approach.
Clarity of At the start, the time and budget required will Projects start with a project initiation
budgets and often be unclear, and part of the role of the document, project management plan,
times scales program will be to define these. business case or equivalent that
defines expected costs and timescales.
Approach to Because the scope and deliverables are Change to scope or desired
change unclear, change to priorities and deliverables are generally subject to
requirements is constant and a major feature rigorous control.
of programs.
Critical A major element is managing people and The major element is managing the
activities organizational issues necessary to ensure that technology or specialist skills
the new capabilities will be used to deliver necessary to create the deliverables.
the desired benefits.
Measure of The creation of useable capability and/or the The creation of the specified
success delivery of business benefits. deliverables within agreed time and
cost constraints

1.5 How do programs differ from portfolios?

Portfolio management is the selection, prioritization and control of an organization’s projects and
programs in line with its strategic objectives and capacity to deliver. The goal is to balance
change initiatives and business-as-usual while optimizing return on investment. Program
management relates to the coordinated management of a set of related projects – typically where
the projects are mutually dependent and all are needed to create the required

7
capability and business benefits – portfolio management is about the capacity of an organization
to manage the totality of its projects and programs, and the choice of which projects to include in
the portfolio to achieve maximum benefit. Portfolio management helps ensure that the right
programs and projects are selected in the first place and regularly reviewed. A portfolio may
include all or some programs and/or projects and be held at various levels within an organization
or in some parts and not others, there is no one-size-fits-all.

The linking characteristics of a portfolio lie in areas other than benefits. The common factor is
usually that all of the projects lie within the same organization or department, and they must be
financed through a common source of funding, or they need to make efficient use of a common
pool of resources. Thus, portfolio management is akin to the similarly named activity that takes
place in the financial world, where a portfolio of investments is managed to yield maximum
returns and capital growth with acceptable levels of risk. In such a portfolio there is no
relationship between the different stocks and shares – each investment is self-contained and is
bought or sold only to achieve the objectives of the portfolio as a whole.

Portfolio management helps ensure the efficient use of development resources, such as business
analysts, solutions architects, web designers and so on – while minimizing costs through the
elimination of duplicate management and support activities. It also helps to create an
understanding of how the various IT projects will contribute or not to the achievement of
strategies of the various business units for which they are being run – something that is not
always clear with traditional approaches to project management.

Portfolio management ensures that the portfolio as a whole meets the organization’s objectives,
with programs and projects being added or removed independently of others in the portfolio.
Program management deals with mutually dependent projects, which should only be added to or
removed if the result improves the realization of program benefits.

Both program and portfolio management require a similar strategic awareness to be successful,
with an overlap of skills, particularly those related to organizational empathy and flexibility. In
many cases portfolio management talent comes from the business side of an organization,
whereas a program manager tends to come from a project background.

8
1.6 How do we run a program?

Having a structured approach to how a program is run is important to successful benefits

realization, as well as to help stakeholders to understand the process they are involved in/affected
by. The day-to-day management of a program comes down to four main principles – governance,
control, assurance and integration.

The first principle of governance looks to ensure that we understand stakeholder objectives and
business requirements (i.e. what do we want to achieve) and to establish the program
environment foundations. Stakeholder objectives and business requirements can change over the
life cycle of the program, so these need to be constantly engaged, considered and adjusted and
impacts communicated; stakeholder engagement is a continuous requirement, and feeds into the
change management strategy. Control is then used to make sure the environment is maintained
and adapted as required, that all are clear on the structure and working boundaries (both for the
program as a whole and for its constituent parts), and that progress is made and measured.

Assurance provides a process to maintain and monitor progress and to support risk-based
decision making focused on successful delivery. A final layer of governance enables risk-based
strategic decision making on the program (and feeding into organizational strategy) and ensures
a focus on delivery of outcomes to meet stakeholder needs. These principles should not be seen
as mutually exclusive, and that integration across the program is a key principle
in its own right. Many organizations look to standard models when trying to improve their
project and program management practice.

1.7 Who runs a program?

The successful delivery of a program of change is largely dependent on the range of people
involved in the program, and links to the governance, control, integration and assurance
principles. Business change and program management should be well understood by the senior
management in an organization, and be represented at that level, as the impact of programs on
strategic objectives is crucial to business success. The role of senior managers includes setting
the culture, environment and motivation that underpins program success. Table 1.2 provides a
summary of key roles and responsibilities in a program, and we expand on some of these below.
9
The program sponsor – also known as the senior responsible owner (SRO) – selected from the
senior executive team of the organization, is ultimately accountable for the program, and this role
should not be delegated. The sponsor owns the vision and business case for the program and is
responsible for providing direction and leadership for the delivery and implementation of the
program, as well as being accountable for outcomes.

The program board chaired by the sponsor, provides governance and leadership to the program,
as well as assessing external factors that may influence the program, e.g. a change in strategy or
external pressures from other programs or activities, which may impact the program. The
program board includes the program manager, representatives from the customer and supplier
(both of which could be internal or external customers or suppliers), business change manager(s)
(who will oversee transition of the change) and others as appropriate. The program manager
reports to the program board on a regular basis.

The program manager is primarily focused on managing relations, dependencies and integration
between the program’s constituent parts. The program manager is typically backed by a program
management office (PMO), which will support the effective running of the program (which
could include training, communications, resource management and allocation, monitoring
performance and progress, reporting etc.).

Reporting to the program manager will be a series of project managers who will control their
individual projects as part of the program. The program should also be acutely aware of
stakeholders associated with it, and many programs may include a stakeholder manager. A
communications manager often appears in programs and will be responsible for creating and
managing a communication plan to ensure all parties (often including the public) are kept
aware and up to date with program objectives and progress.

10
Table 1.2 Roles and responsibilities in a program

Role Responsibility
Program sponsor or
Fully empowered leadership of individual programs; owns business
senior responsible ownercase and vision.
Program manager Responsible for delivering new capabilities.
Business change manager Responsible for realizing benefits through embedding the change
into business-as-usual.
Responsible for ensuring their own business area is ready to use the
program’s project outputs.
Project manager Responsible for delivery of project outputs within agreed
constraints.
Senior suppliers Represents the interests of parties involved from supplier
perspective (internal or external).
Senior users Responsible for ensuring the needs of those that will use outputs are
met.
Communications Responsible for the identification, analysis, planning and
manager implementation of program communications.
Stakeholder manager Responsible for the identification, analysis, planning and
implementation of actions designed to engage with stake holders.
Risk and issues manager Establishes, facilitates and maintains the threat, opportunity and
issues management cycle.
Program management Support body for key roles, providing advice, challenge and checks
office (PMO)

1.8 How programs deliver benefits

The benefits associated with strategic organizational change are delivered through programs of
multiple-aligned projects and change management activity. Such programs can contain complex
interactions between the outputs of individual projects, outcomes and benefits.

The role of the program is to deliver outcomes, and hence set the scene for delivering benefits, as
opposed to the outputs that an individual project delivers. Gaining shared stakeholder clarity,
understanding and commitment to the desired outcomes is critical to program success. Wherever
possible, the program should seek to realize measurable benefits early and then frequently during
its life. However, it is likely that most benefits will be realized during business-as-usual use of
the program outcomes (e.g. a new facility, new structure or new capabilities), and likely once the

11
program ends. Where benefits are realized after the program team has been disbanded or
assigned to new endeavors, responsibility for monitoring, measuring and realizing the benefits
must be transferred to an appropriate function. The transition plan should be considered as part
of program planning and discussed and agreed with the program board and business change
manager.

A critical component within benefit management is the project(s) or set of activities needed to
manage the transition from the old ways of working, based on previous processes, tools and
capabilities, to the new ways. Such transitions are frequently very complex and risky. For
example, they may involve the switch-off of old systems or facilities and the switch-on of new
ones according to tight timescales. They depend upon the commitment of users and line
management who are not directly under the control of the program or any of its component
projects. Furthermore, there can be little allowance for failure or delay, since service to
customers must continue throughout the transition and, unless a smooth transition is effected, it
may not be possible for the organization to take advantage of the new capabilities and thus be
able to realize the benefits that the program is intended to provide.

It is important to implement a consistent approach to benefits management across a program,

particularly for consistency of measurement. Without a consistent approach, it is difficult to
aggregate benefits across multiple projects and to assess their collective impact on business
performance across the organization. Benefits management ensures the realization of benefits,
and responsibility for it may rest partly with the program management team and partly with
another group, such as the main board or the organization’s finance function.

1.9 What challenges are faced?

As with any change, and related change management activity, program management can face
several intrinsic challenges. These are all surmountable, especially when considered
continuously during the program life cycle, and through lessons learned from other programs.
Typical challenges experienced include:

 managing the complexity and natural tension that exists between corporate strategies, the
delivery mechanisms (i.e. projects) and the business-as-usual environments – this level of
complexity can easily be underestimated;

12
  gaining corporate board level support to provide leadership, commitment and
sponsorship;
 application of adequate strength of leadership from the program board, program manager
and supporting structures;
 defining and maintaining a clear vision and a real picture (blueprint) of the future
capability required, as well as metrics to monitor progress towards the vision;
 maintaining an adequate focus on benefits, which needs to be built in from the start and
monitored throughout; as well as looking to realize benefits as early as possible;
 addressing the tensions that arise between program targets and constraints
(for example across scope, cost, time, risk, benefits etc.);
 transitioning the desired/necessary cultural changes – the people/human element can
often be overlooked;
 gaining the required levels of stakeholder engagement – this is particularly important as
the program will likely deliver significant change, and this needs to be understood and
agreed;
 managing program interdependencies;
 ensuring a clear requirement capture and management approach across the program.

The program life cycle

2.1 A high level program management life cycle

Despite the variation in size of programs, from a handful of people and a few projects through to
thousands of people on large, complex undertakings, each one can be deemed to follow a
standard life cycle. Models of program life cycles may vary in terminology for the individual
phases, but each follows the fundamental principles of concept, definition, delivery and
closure. It should also be noted that some representations (reorganizations) might use additional
sub-hazes to those proposed here. It is important in life cycle terms to differentiate between the
steady-state operations of a business (or of a social environment) and the change itself.

Programs typically develop change by stepping through sub-divisions that facilitate approval
gates and deliver increments in capability (these are known as tranches) with resulting transitions

13
into the business operations (or social environment). The program life cycle is aimed at
establishing a firm platform for the overall change journey, whether this is for a business or
societal transformation, the introduction of a new capability, or the launch of a new product into
its operating environment. The conceptual description of this journey illustrates the key
relationships between the business objectives, the definition of the program, the individual
projects and their outputs, the program outputs and the resulting benefits, and how these
underpin the resulting business performance.

2.2 Life cycle strategy considerations

Prior to the start of a program, there may be a period of uncertainty while an organization
understands and decides that a change of some description is required and that some form of
investment in change is needed. In some cases, this may be a formally recognized strategic phase
of activities (for example, it may be called a ‘genesis’, ‘foundation’ or ‘pre-concept’ phase), and
in others it may be less clearly defined or revolutionary. In theory, all organizations should have
clearly defined and agreed business change strategies, the implementation of which requires the
initiation of programs. Indeed, if the organization is undertaking programs within the framework
of portfolio management, then the programs will be fully aligned with strategic plans. Within
such an environment (or where the business undertakes regular change or introduction of new
complex products), the business will have defined a business change life cycle specific to its
needs, and so the individual program life cycle will have to be aligned with this generic business
framework. This alignment is an important part of defining a specific strategy for the overall
program approaches, i.e. the definition of its program life cycle.

Another important consideration for the program life cycle is the selection of the approach the
organization would like to take in the delivery phase of an individual program (or potentially
introducing the overall change through related programs). Depending on the level of uncertainty
during the concept or definition phases, it may be necessary to conduct ‘discovery’ or ‘pilot’
projects, undertake feasibility studies or to create proof-of-concept systems in order to help
clarify the program life cycle strategy. Therefore, the idealized program life cycle should be
adapted to suit the nature of the change and the environment in which the change is to be
undertaken. Four different program life cycle strategic approaches are described below.

14
Linear: Where the business transitions to the final new state through a single sequential
series of activities each providing only partial capability (possibly even in a single
tranche). This is suitable for stable, low-risk environments where the full benefit
can be delivered through a single final roll-out.

Incremental: Where the transition to the new state is achieved through a staged series of
smaller step changes in capability delivering increasing benefit. This is an
approach that can deliver ‘quick wins’ to help engage stakeholders in an uncertain
environment and build confidence towards the final end state and is well
represented within the ‘tranche’ framework.

Experimental: Where the program runs parallel activities in order to explore high-risk options
and fall-backs, where the way forward is unclear at first. The scope of this type of
activity will depend on the risk appetite of the organization, in some
circumstances the approach may extend for the duration of the delivery phase.

Evolutionary:In this approach the program takes a number of planned full transitions to
business-as-usual, each of which are based on user/customer feedback from the
preceding transition and implementation. This approach can be used for time-
critical initial entry to market followed by follow-on solutions but runs a possible
risk of negative reputational impacts from continuous changes.

There are many permutations, combinations and overlaps in life cycle strategy definition: the
critical elements are to define the way forward such that it can be clearly communicated to the
team, the sponsor and to the other stakeholders, and underpin the overall program detailed
definition. This is a key program decision as it can have major implications downstream on the
management style and behaviors.

The program life cycle strategy should also incorporate or reflect any issues arising from an
appreciation of the likely development methodologies used at the project level. These may be
driven by the nature of the work in those projects and the level of threats to successful project
conclusions. They also need to be integrated into the wider program environment.
An example of this would be programs undertaken within an agile development environment
and/or where one or more projects employ agile development techniques. It should be noted that

15
an appropriate, robust and tailored program management environment is entirely conducive and
applicable to an agile development environment. Finally, consideration must also be given to the
nature and strengths of the tensions that will be prevalent within the program environment, and
how the overall program approach may be adapted to reflect or respond to these.

2.3 Program life cycle governance

The program life cycle provides a framework to support the principles of good organizational
and program governance. One of these principles is that the program approach should have
authorization points at which the business case, inclusive of strategy alignment, cost, benefit
and risk, is reviewed. These authorization points can take the form of gateway reviews between
phases, and individual stage or gate reviews within the phases. The exact nature of these reviews
depends on the organization, but they should ensure that positive business decisions are taken to
continue with the program in its current direction, change direction or abandon the program
completely. The reviews also provide ideal opportunities to ensure that all governance principles
are being followed. Program gate reviews should also occur at the end of each tranche in the
delivery phase, to formally authorize moving to the next tranche, assess program performance
and any benefit realization to that point. These will also be aligned with, and cascade up from,
stage gate reviews in the individual projects.

2.5 Program concept phase

This phase is also known elsewhere as the ‘identification’ phase. The purpose of this phase is to
identify a program, its vision, aims and strategic alignment such that clear foundations are set for
successive activities and communicated to program team members and external stakeholders.
This culminates in the outline business case.

Program concept phase can be initiated on receipt of an initial mandate (or similar form of
instruction from a sponsoring group) or, where no such mandate formally exists, the start of the
phase can be a gradual ‘morphing’ from other business activities as the initial mandate is
defined. This mandate can take the form of a simple written instruction or a strategic business
case that outlines the desires of the organization in terms of outcomes expected against strategic
business objectives. Depending on the business environment, it can be generated through

16
organizational business policies and planning, an overarching portfolio strategy and plan, or a
preceding ‘pre-concept’ phase.

Program Concept Phase Overview

Inputs Mandate
Business strategy
Portfolio delivery plan
Concept Phase  Appoint the program management team
activities  Define program vision and objectives
 Define key benefits to achieve
 Define overall program approach or strategy and key elements
 Identify initial treat to success
 Identify key options
 Produce program brief (outline business case)
Controls/ Portfolio delivery control
constraints Sponsoring group review
Supporting Sponsoring group, senior responsible owner, departments
Mechanisms
Outputs Confirmed mandate
Program brief
Plan for next phase
Approval for next phase
Appointment of senior responsible owner (SRO)

The main aims of program concept phase are to confirm the program vision and mandate, define
the program organizational arrangements, produce the program brief and achieve a decision on
the outline business case. The program brief describes the basic validity and viability of the
program. It will encapsulate the vision, objectives and benefits to be achieved, and estimated cost
and timescales to achieve those benefits. Risks to achieving the objectives will be outlined, as
well as various options and opportunities that have been identified. The program organizations to
be defined include the governance structure (i.e. the arrangement of the sponsor and the program

17
board) and the composition of the program management office (PMO). The PMO may be a
stand-alone support office, or it may be integrated within a wider portfolio management office.
The brief, the program arrangements and a plan for the Program definition phase will be
reviewed by the business senior management team (which could be an executive board, an
investment committee or a portfolio direction group) and, if approved, the program will then
progress to the definition phase. Note that the senior management team may also be known as a
‘sponsoring group’.

2.6 Program definition phase

The purpose of the definition phase is to establish and gain approval for the program to proceed
and define it in such a manner that it will be possible to coordinate its component activities and
therefore deliver its objectives effectively.

Program Definition Phase Overview

Inputs Conformed Mandate

Program brief
Plan for definition phase
Details of other business activities (projects, programs)
Definition  Develop the future stake definition (blueprint)
Phase activities  Identify stakeholders
 Define benefit and benefit realization plans
 Define program approach and step changes in new capabilities
(trenches)
 Identify projects and their goals
 Define business case for the program
 Define program management framework
Controls/ Portfolio delivery control
constraints SRO review of business case
Sponsoring group Approval
Supporting Sponsoring group, program board, program manager, business change
Mechanisms manager, program management office

18
Outputs Approval to start first trench
Approved business case
Blueprint
Benefits plan
Communications plan
Program plan
Risks and issues register

The main thrust of this phase is to achieve a robust definition of the program such that approval
can be sought by the sponsor from the business senior management team/sponsoring group for
the program to proceed. This is achieved by generating a business case, defining the objectives,
expected benefits, investment required, costs, timescales, risks and ability to achieve the desired
objectives. A good breakdown of the typical contents of a business case consists:

 a strategic case – the rationale for why you need to undertake the program;
 an economic case – the cost/benefit analysis of the available options;
 a commercial case – the viability of any procurement approach;
 a financial case – the affordability of the overall program;
 a management case – the achievability of the program (in terms of its execution).

The business case therefore requires inputs such as a definition or depiction of the aspects of the
future state of the business that can meet the objectives of the mandate. This definition (often
referred to as the program blueprint) provides a foundation for the subsequent planning and a
focus for the program. The future state is defined in terms of future capabilities, organizational
structures, personnel (including skills and expertise requirements), processes and workflows,
physical infrastructure and technology, and information needed to run the business. A key
element of the business case, and the program to follow, is the identification and analysis of the
benefits that are expected, and what activities, outcomes and specific outputs are needed to
realize these benefits. Analysis of the required benefits, the impact on stakeholders and how best
to engage and support them and the step changes in business capability needed to achieve the
benefits, will help define the delivery of the overall program. Analysis of the program delivery
requirements will help define the projects that are needed to deliver the necessary outputs.

19
Projects can exist within tranches or can span tranches (in which case they will typically be
broken into project stages that align with the tranches). Each identified project is then defined
individually and makes up an overall dossier of projects within the program. In addition, the
program team will undertake identification and analysis of the stakeholders involved in the
program, and then devise a communication and engagement plan to help interact with these
stakeholders. Management of stakeholder engagement is critical to the success of a program, and
a key part of the future activities of the central program team.

The blueprint generation, risk analysis, benefits definition and stakeholder analysis are all carried
out in parallel (in an iterative manner) to arrive at the business case. During the program
definition phase, the program governance arrangements are also defined and these, along with
the overall management framework and the information defined in the blueprint and business
case, are used to generate the program management plan (also known as the program definition
document).

2.7 Program delivery phase

The purpose of the delivery phase is to manage the program to deliver what has been planned,
including any organizational change and business benefits in accordance with agreed cost,
benefit, time and resource constraints.

Program Delivery Phase Overview

Inputs Approved business case

Blueprint
Benefits plan
Communications plan
Program plan
Risks and issues register
Concept Phase activities Establish trenches and component projects
Coordinate plans and schedules
Manage risks and issues
Manage stakeholders’ engagement and communications

20
 Manage program budgets
Report and review progress
Review and update program plans
Plan, undertake and confirm transitions
Manage benefits realization
Confirm business case viability
Undertake learning activity
Controls/ constraints Portfolio delivery control
Sponsor review of business case
Sponsoring group Approval
Program controls framework
Project brief and project controls
Benefit management strategy
Supporting Mechanisms Sponsoring group, program board, program manager, business
change manager, program management office
Outputs End tranche review
Forward tranche plan
Forward tranche approvals
Project output deliveries
Program outcomes achieved
New capabilities/operations in place
Performance evaluation reviews and lessons learnt

Once the program is established, the component projects are created to produce their required
outputs according to the program management plan. These outputs will then be combined under
the control of the program to produce the new capabilities/outcomes that can then be exploited to
realize the benefits to the organization and other stakeholders. These outcomes cannot be
implemented without a transition from the program to the normal working practices, and this
transition is a critical part of the program management activity. This activity is also the
foundation of benefits realization, where the program works with the day-to-day business
environment to ensure that the business case for the program is being achieved. The following

21
sub-sections explore more closely the activities grouped under program delivery, transition and
benefits realization.

Establish tranches and component projects: The component projects themselves must be
established and planned in detail, cross-checked and optimized for technical, managerial and
commercial consistency. The individual project plans, time schedules and other supporting
documentation should be reviewed by the program management to ensure consistency and to
identify dependencies and potential conflicts.

Ideally for each project a separate project manager should be appointed, although circumstances
(such as small-scale projects or projects not overlapping) may allow an individual to run separate
projects. Managing a project that is part of a larger program is different from managing a stand-
alone project (for example dealing with decisions made for the greater benefit of the wider
program but penalizing for the individual project), and appropriate terms of reference,
identifying different reporting structures and escalation procedures, should be provided, agreed
and signed off. This is done by expanding the information on each project into separate project
briefs (or project initiation documents) and placing project-specific information into these
documents (common information is held in the program management plan/program definition
document).
Detailed project plans will be devised only for the tranche to be executed activities within future
tranches will be defined as the active tranche draws to a close – but the program definition
document will describe the outline timescales and intentions for future tranches. Therefore,
project briefs are updated at the beginning of each tranche.

Coordinate plans and schedules: Although each component project will develop its own
project plan and attendant time schedule, successful program management requires these to be
coordinated, and on a rolling basis. This requires all interdependencies to be identified, and then
the individual plans and schedules adjusted to achieve the best possible overall compromise.
Once a consolidated schedule has been agreed, with interdependencies confirmed, it is likely to
need constant adjustment as progress and changes are notified to ensure that any delay in one
component project is accommodated, thus avoiding ‘knock on’ delays to other projects and thus
to the delivery of the desired program outcomes.

22
Through the coordinated management of the component projects, the program will deliver the
required outputs and outcomes in the most cost-efficient manner. Project interface and
interdependency management is a key function of the program environment, for dependencies
within the program and across the program boundary (inputs from outside the program).

Manage Risks: As with individual projects, rigorous threat, issue and opportunity management
is essential. Typically, each project will maintain its own risk register and manage its own risks
but will escalate to a program-level risk register those risks that are beyond its control, or would
have a detrimental impact on another project, or which could be more effectively managed at the
program level. The program risk register also holds risks for projects that are not yet underway,
threats to project interdependencies and program coordination, or those threats arising from the
environment outside the program. The program team will monitor external situations on behalf
of the projects (‘boundary scanning’) and escalate risks beyond the control or scope of the
program to strategic business or portfolio management.

Manage stakeholder engagement and communications: While coordinating and managing the
component projects within the program, the program team must also develop relationships with
the customer, users, beneficiaries and other stakeholders, undertake consolidated analysis and
coordinate the engagement and communications with stakeholders across the projects. Individual
projects may undertake their own stakeholder management, but it must be consistent and aligned
with the overall program activity. In complex environments, such as those relating to programs,
stakeholder engagement should be an integral component of all management activities. It must
be part of the overall approach to gaining and then maintaining the support and cooperation of all
stakeholders and must be coordinated with related activities such as: governing the program;
communicating risks and progress; and collaborative problem solving.

Manage program resources and budgets: The program will monitor and control expenditures
against the budgets laid out in the business case and detailed in the program plan. Overall
program budgets, in terms of total forecast costs and timescales, will have a degree of
uncertainty according to the program maturity and nature of the program, but each current
tranche should have targets set as part of the tranche planning process. The program manager
should have a program budget composed of:

23
  funds allocated to on-going projects;
 funds reserved for future planned projects;
 funds allocated to program-level activities (such as the PMO);
 funding held for program-level risks, and any risk reserve held on behalf of the projects;
 contingency held for unforeseen events (which will typically reflect the level of program
uncertainty).

The contingency and management reserve held at the program level may be held on behalf of the
individual projects (as well as the program activities), or an amount may be allocated to the
projects to be managed accordingly within the project (with the total across all projects plus the
remaining reserve held by the program equal to the overall program exposure). This depends on
how the various risks are to be owned and managed, and how the individual projects are run. In
either case it is important to clarify what contingencies and reserves are being held at which level
and for what purpose, to avoid double accounting or gaps.

Budgetary control may be exercised through the setting of tolerances on time, costs etc., where
individual projects will only have to notify the program of any intended expenditure outside the
permitted variation. The setting of budgets for tranches, and the increasing maturity of forward
estimates from tranche to tranche, can be aligned with business financial approval cycles and
processes by adjusting the timings of the tranches themselves.

Report and review progress: At agreed intervals, consolidated program status reports should be
produced. The scope and coverage of these will have been defined during the program initiation
phase according to the needs of the program board. Typically, such reporting will include
program and financial status reports, based upon information provided by the component
projects. These should be a concise ‘snapshot’ of the status of the program, identifying progress
against milestones and any major new risks, and concentrating on exceptions and departures
from agreed plans. A key part of such a report will be progress made towards the delivery of
benefits. The financial status report should give a summary of the consolidated costs, revenues,
working capital and reserves of the program.

Producing these reports will require each project to prepare its own individual reports and then
forward these to the program for consolidation and review, normally by the PMO. To ensure that

24
meaningful results can be prepared by the agreed dates, it will normally be necessary for the
PMO to define and enforce a standard reporting timetable and to provide templates in which the
managers of component projects can record their information. However, the program must be
cognizant of, and respect, the different project environments as individual project reporting will
be influenced by the nature of the projects themselves, some projects may be operating in an
agile development environment, but it is the role of the program to consolidate them in a manner
appropriate to the needs of the organization.

In conjunction with the reporting requirements, it is good practice for the program board to
conduct progress reviews at critical points in the life of the program, such as the end of a design
or development phase or immediately before beginning implementation/transition. Such review
points are usually identified at program start-up and should be identified in the program
management plan. Such reviews are time-consuming, and thus adequate budgets and resources
should be provided for the program management team to prepare for them. These reviews may
take the form of ‘gateways’ where a formal go/no-go decision is taken about the subsequent
activity.
Review and update program plans: The program plan and consolidated schedule are likely to
need regular updates as a result of:

 activities that were known to be required, such as the initiation of a new project, but
which could not be planned in detail at the start of the tranche;
 changes to the plans and schedules of existing projects as a result of delay or unexpected
problems and difficulties;
 alterations to the scope, content or composition of the program because of change
requests.

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

Confirm business case viability: The program business case is a ‘living’ document through the
life of the program. It will be consulted and reviewed (a) in the event of changes to the program
or the environment around the program, or (b) in the event of revised expected benefits and costs
arising as greater certainty is gained or benefits are reviewed. At the very least it is always
reviewed at the end of each tranche to confirm the on-going viability of the program. If the

25
business case diverges significantly from the expected return from the program, then the senior
responsible owner should recommend program termination to the management team.

Plan, undertake and confirm transition: The transition from program outcomes to changes in
the day-to-day business or environment requires careful planning prior to the end of each
tranche. Areas such as staff training, support arrangements, new processes and their performance
measurement, organizational changes and detailing any new data requirements all have to be
considered, and especially how these will be introduced with minimum disruption to the
business. The transition itself can only be triggered when all areas are ready, and the preparation
and management of the transition is a key element of the responsibilities of the business change
managers in the program.

Once the outcomes have been achieved in the organizational environment then the changes can
be made permanent by removing old legacy systems and monitoring the embedding of new
practices for any issues arising. Lessons from the transition and the implementation of new
capabilities have to be fed back to the program team (in the case of intermediate transitions to
influence ongoing program activities), and to senior or portfolio management teams (for ongoing
business continuous improvement and process optimization).

Manage benefits realization: Whilst the transition activity is a key point in establishing and
measuring benefits, benefits realization management occurs throughout the program delivery
phase. The program tranches (and hence program schedule) are built around the intended
realization of intermediate benefits, and the benefits themselves should be the basis for any key
program decisions (possibly using techniques such as multi-criteria decision analysis based
around the benefits). Where it is possible (and planned) initial benefits will be measured during
the post-transition activity and results fed back into the program planning for the next tranche (or
potentially future tranches). The results may also have an impact on the viability of the business
case.
Undertake learning activities throughout the program: Learning, embedding lessons learnt
and undertaking improvements should be continuous activities throughout the life of a program.
There are also key points at which it is important to reflect on past activities and consider what is
required to enable future success. These reviews should occur at the end of each project and at

26
the end of each tranche. Lessons should also be fed back into the organizational learning
environment to help other current and future programs.

2.7 Program closure phase

The purpose of the closure phase is to undertake all final actions and formally recognize that the
program has completed.

A program will be closed either if all the outcomes required for the future state in the blueprint
have been achieved (noting that the blueprint may be adjusted during the course of the program),
or if the sponsor has proposed a premature cessation (for example, based on the business case no
longer being viable). The point at which the closure phase is undertaken, and its duration, will
depend upon the nature of the program. For example, if the outcome of the program is the
operation of a new facility, closure is likely to occur as soon as the last project has completed
and the final transition has been undertaken with the facility being handed over to the line
management. Alternatively, where the program is required to achieve a complex range of
business benefits, there may need to be a period of use by the customer of the new capabilities
before the benefits can start to be realized or expected to be realized with sufficient confidence.
In these circumstances there may need to be a longer period of time between the final transition
and the final program closure activity. In either case, once the program enters the closure phase,
stakeholders will first be notified that the program is about to complete, in accordance with the
communication plan, and elicit feedback from these stakeholders. The program team will then
ensure that all program documentation is completed and filed in accordance with the relevant
business processes. This activity is often under significant pressure as businesses seek to re-
allocate program teams early as the closure phase is erroneously perceived to add little value, but
incomplete or missing records will cause downstream problems, particularly for the new steady-
state operations or for any new related programs.

A review of program activity and performance will be undertaken. The purpose of which will be
to verify, amongst other things, that:

 all deliverables and capabilities have been delivered and transitioned to normal
operations successfully;
 all projects have completed their own individual project closures;

27
  all necessary records are now in place;
 all customer and supplier invoices have been processed;
 lessons have been reviewed and incorporated into corporate activities and processes, and
other valuable knowledge, including an up-to-date program summary, has been captured.

The program team will then provide a report to the sponsoring group/portfolio delivery group,
which will confirm the program closure. It is recommended that some form of celebration is held
to recognize the success of the program and the efforts of all those involved in the program, and
that this occurs before the program team is fully redeployed back into the organization.

During program life cycle the program may have a number of projects start and complete,
overlapping efforts, transitions to operational control, and the realization of multiple benefits as
each project is completed. Ensuring that the program follows the life cycle through the whole
process is crucial to success. A program that is not transitioned to operational management at the
end is still considered a failure, even when the program benefits are delivered and all projects,
initiatives, and operational activities are completed. Ensuring that as the program closes all
transitional activities are completed and confirming that each operational group has assumed
responsibilities for the management of services are as crucial to success as delivering initial
benefits or project completion.

3. Major program Management Domains

Program management follows five main domains as an approach: (1) strategy alignment, (2)
program benefits management, (3) program stakeholder engagement, (4) program governance,
and (5) program risk management. These five domains permeate everything a program manager
is responsible for, from ensuring that expectations are clearly communicated to delivering
benefits on time and in a cost-effective manner.

These five domains drive the decision making and process for program management to ensure
that program managers focus on the high-level deliverables and the leveraging of resources
across projects, operations, and the program’s high-level benefits. Program governance,
stakeholder management, and benefit management are critical success factors for a program
manager to establish his or her authority over and to contribute to the success of a program.

28
Without effective leadership skills, a program manager can easily alienate groups and decrease
the potential for effective communication. The program manager must know the program inside
and out and must ensure that all benefits are identified and understood; must communicate when
benefits are realized, what the value of those benefits is to the stakeholder community, or
overcome concerns if not achieved; must ensure that stakeholders have a chance to address their
concerns and be heard on the issues facing the program; and must ensure that projects stay
focused on providing the results necessary for the program to achieve its objectives.

3.1 Strategy Alignment

Strategy alignment is the process through which the program is initially and continuously aligned
with the defined strategic objectives of the organization. The program alignment should have
been performed to ensure that the program is contributing to the strategic objectives and that the
contribution is tangible and measurable. A program aligned with the strategic initiatives of the
organization will contribute to the achievement of the organizational goals and will help the
organization to move in the direction deemed most effective by the executive management team.

3.2 Program Benefit Management

Where projects are about delivering ‘outputs’, programs are about delivering ‘outcomes’ and the
benefits associated with incorporating the outcomes in business-as-usual activities. In this
respect, most programs involve a ‘business change’ or ‘transition’ component above and beyond
the delivery of the project output.

Benefit management is the identification, realization, and communication of tangible benefits

that the program will deliver or has delivered to the stakeholder community. The benefits of a
program are most likely to be lost or forgotten with time and the general impact of delivery if
they are not regularly communicated and validated. It is the sustaining of long-term benefits and
the realization of these benefits that the program manager is directly responsible for. The
program manager is ultimately responsible for ensuring that the benefits are useful, aligned with
the organizational objectives, communicated throughout the organization, and when realized,
validated to ensure that the benefits met the needs as intended.

29
Therefore, the program manager must be capable of envisioning the future state, providing a gap
analysis between the current and future, and ensuring that stakeholders and program team
members all recognize and see the value of the future state. A program that is undertaken with no
tangible benefits has little support from the organization and will often be challenged on the
basis of cost, organizational impact, and resource consumption. A program with a large number
of benefits will receive a vast amount of support and resources to ensure that it is able to achieve
established goals. At the same time, the greater the benefits the more pressure to deliver in a
timely manner and to require communication of what has been realized and what benefits are
still pending.

For any and all efforts, the program manager must be able to step up as a leader to the
community and to be able to align main points with benefits so that stakeholders can recognize
that the future state will be a better one and are prepared to deal with any temporary pain points
while waiting for the new set of benefits that will be an outcome of the effort. The pain points
that the stakeholder community experiences must be real and identified with an established root
cause that the program will undertake to solve.

A successful program will also leverage the program and project teams to work together in the
development of a solution. The environment created by the program manager will determine the
level of personal contribution, investment, and innovation that the team delivers as a whole. The
program manager must ensure that every team member clearly understands the benefits of the
program and the future state, and is on the same page working toward the same vision. Without
this, teams will head in disparate and sometimes opposite directions, burning time, resources,
and dollars without tangible benefits. Thus, as the responsible party for benefit management, not
only must the program manager define the environment, but he or she also must be someone who
can envision the future and must be an exceptional communicator to ensure that everyone
involved with the program, whether a contributor or user, is following the same vision and
overall expectations.

Stakeholders need to have clarity in what will be forthcoming, when things will occur, and when
they will receive information. Without this, the program soon becomes a “black box,” which is
often resented by those waiting for benefits. Regardless of the technical or managerial
knowledge of the stakeholder community, there is an expectation that they will be capable of

30
observing some level of progress. Often this progress can be demonstrated through tangible
achievements, but there are times, especially early on in a program, where the progress is more
intangible. The program manager must be able to effectively communicate progress and schedule
throughout each stage of the effort. Stakeholders need to know not only what the status is but
when they will hear additional status updates and the form that communication will take.

Benefits management is often misunderstood or misinterpreted but it is a vitally important

change management function that demands excellent communications, a robust process and
sustained support from all change stakeholders during implementation across the project and
program management business landscape so that the true impact of cost, operational,
organization and/or compliance-based benefits can be measured and realized.

Benefits management at program level can be particularly challenging. There can be a very
heavy reliance on customers and users (both their behavior and their feedback); the benefits are
often in a form that is neither easy to measure nor in the vested interest of some stakeholders to
achieve; there is frequently a long lead time between project outputs and benefits realization
during which time the baseline has moved or other factors have impacted the outcome.
Moreover, the comparison 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 relevant as we have to live in the ‘world as we find it’. Business
cases are prone to over-statement of benefits in order to gain approval.

3.3 Program Stakeholder Engagement

Stakeholders are a crucial element to the success of a program and are not just the program
sponsor or executives. The stakeholder community can come from the public at large,
commuters on a high-traffic road, or even homeowners in an area where a new business is being
added. The program manager must clearly identify the stakeholders of the program and also
ensure that stakeholders clearly understand what the program scope is. Expectations that are not
directly aligned with the program deliverables will create a level of frustration and cause a loss
of support for the effort. Communicating the program expectations in terms of features,
functionality, schedule, cost, and quality must be an ongoing dialogue validating that
stakeholders clearly understand what is proposed and how the program will meet needs.

31
In working with various stakeholder communities, not only must the program managers be able
to communicate, they must also be beyond reproach in the information they communicate.
Program managers cannot be inconsistent or illogical or demonstrate a lack of knowledge. They
must be aware at all times of the statuses of many projects, efforts, and tasks. They must be able
to participate at any level as challenges are brought to them by the project managers on the team,
including the progress of the effort, technical challenges, financial issues, and resource concerns.
Honesty and reliability work together to build trust, and it is the trust of the stakeholder
community that is crucial to success. A program manager communicating progress who is not
trusted is not believable, and therefore the progress, program status, financial estimates, and risk
identification all become questionable. The focus of stakeholder management is to maintain
communications and ensure that the stakeholders will benefit from the program, achieve
satisfaction, and that the expectations are managed.

32
The above figure shows four levels of stakeholder management based on the interest level of the
stakeholder and the leverage that it has over the outcome. The lowest quadrant of monitor is used
for those stakeholders who will be impacted by the program but do not have direct influence and
a minimal interest in the program. Program sponsors will have the highest interest and power
over the program and must have expectations managed to ensure that the program meets their
expectations and success can be achieved. An executive-level interest in the program may be
limited, but success is also measured against the level of satisfaction that is achieved. If an
executive determines that the program will not meet expectations or generate a proper return on
investment, the effort may be canceled or modified to meet the desired return.

The reality is that all programs have good days and bad days. There are times when risks are
realized, issues are encountered, and the unexpected occurs, causing tremendous concern for the
program outcome. Yet a program manager will need to communicate openly and honestly the
good and bad of the program regardless of the potential outcry from the stakeholder community.
The news must be put into context and balanced between the fears of failure and the realities of
issues encountered. Therefore, the program manager must be courageous in communicating
issues by offering potential strategies to overcome the challenges as well as avoiding
cheerleading when the effort appears to be firing on all cylinders. In other words, communicate
good news quickly and bad news immediately.

At the same time, the program manager is responsible for the work performed by the teams that
he or she manages. In the event that an issue or problem occurs, the program manager must
assume responsibility for the issues encountered and ensure that the team is defended where
necessary, thereby maintaining control of the effort. It can often be painful to stand up to
executive managers with bad news, but a program manager who takes responsibility for failure
and passes success on to the team creates an environment of internal trust, confidence,
innovation, and success. This motto, “failure is mine, success is the team’s, and failure is not an
option”, helps to create an environment where the team can operate with best efforts and not fear
reprisals or attacks in the event of a problem. It also fosters the overall level of communication
and ensures that the program manager is aware of the facts, good or bad, and has the ammunition
to clearly brief stakeholders. The team that is protected by management becomes more willing to
innovate and create, knowing full well that they will not be “punished” for attempting to solve

33
challenges. The safe environment coming out of this leadership style, regardless of the
organizational culture, encourages greater internal communication and contributions, eliminating
hostile or toxic traits such as finger-pointing, sabotaging, withholding information, and focusing
on personal success over organizational.

The traits of courage and expertise lead to a level of confidence that a program manager can
achieve with team members and stakeholders. Stakeholders who are concerned about program
success will look to the program manager to instill confidence in the objectives. In addition, team
members will be more successful following someone leading the team who is confident in the
approach. Uncertainty, fear, and anxiety will come across as a lack of belief in the program and
potential benefits. This negative will feed the community’s concerns, and when issues are
encountered, the stakeholder community will immediately interpret its concerns as valid. On the
other hand, a leader who demonstrates confidence in the team, program objectives, potential
benefits, and technical approach, and evangelizes the solution will generate a following of
stakeholders who begin to believe that success is achievable.

Good stakeholder management in the program arena requires the same skills as good stakeholder
management in other walks of life, using tools relevant to the scale of the task – ranging from a
simple two-by-two importance-by-influence matrix to sophisticated stakeholder relationship
management software. While categorization of stakeholders into: client/sponsor, user, customer,
supplier, influencer, beneficiaries, team/staff, etc, will always apply, the principal challenges for
stakeholder management at program level often arise in three areas discussed below.

Intra program: The relationship between sponsor teams and delivery teams at program and
project levels within the program requires careful stakeholder management to ensure that project
drivers and incentives do not drive sub-optimal program consequences. This is a greater risk
where the client/sponsor organization is not experienced at program management and hence
sponsor relationships are not mature.

Business-as-usual stakeholders: In a highly tuned business focused on business-as-usual

activity and unfamiliar with programs and projects, the challenges of managing business-as-usual
stakeholders can be twofold. First, the organizational design of business-as-usual is frequently at
odds with program and project, which cut across functional hierarchies. Second, at program level

34
it is usually the business-as-usual stakeholders (the target audience for the business change
projects within the program) who will be expected to adapt their way of working if the benefits
of the program are to be realized. People will have a mix of responses to the changes, some being
more enthusiastic than others, and many having real concerns that it will be important to surface,
consider and respond to.

External to program: The larger and more high profile the program, the greater the number of
‘experts’ in the topic who believe they have a critical and legitimate interest in it – usually from a
narrow viewpoint and often with very little understanding of the basic principles of program
management. The power of ‘influence’ should never be underestimated and streamlined
governance alone is not sufficient to manage the key external stakeholders: this takes time, effort
and a full appreciation that ‘communications’ is a two-way process. The importance of building
‘public’ support for the program (and the role of the media, including social media, at the
appropriate level – national, regional, neighborhood, company-wide or at divisional level) should
not be underestimated.

3.4 Program Governance

One aspect that is critical is the assurance that critical information required is available and that
program and project processes are complied with. Skipping over critical process areas of
governance because of project momentum is a sure way of creating program failure. A program
is a combination of smaller component efforts (projects) and non-project work that when
combined offer a greater benefit than managing each project alone. Therefore, project managers
and team members must comply with processes such as schedule management, financial
management, performance measurement, and project reporting to support effective program
management and provide the foundation by which the effort can eliminate redundancy, disparate
efforts, and disconnects between projects.

This aspect addresses how the program is set up (rather than the management organization),
ensures that delegations to and empowerment of the program management organization is
sufficient to enable them to deliver, and establishes the mechanisms through which approvals at
program and project levels are delivered. Of particular importance at program level is the

35
relationship between program delivery and the business-as-usual team who will use the outputs
of the component projects to realize program benefits within routine operations for the business.

Governance requires clarity of Role, responsibilities, authority and accountabilities (R2A2).

Most people and organizations are very familiar with a job description that sets out the role and
responsibilities for the post concerned. In the more complex world of program management,
clarity comes with understanding what authority has been delegated to whom. This authority is
limited by the governance structure set up for the program and should not be hard wired
to a post as the delegation should be a subjective judgment made by the organization based on
the confidence they have in the individual’s competence and reliability. Too often the
‘accountability’ refers to the individual held to account for the activity being described even
though that individual may delegate responsibility for executing the work to another party. In
R2A2, being focused on the role rather than the activity, accountability refers to the
individual/post to whom this role is accountable for discharging specific aspects of their
responsibilities. Frequently, the role will be accountable to different posts for different aspects of
their responsibilities. The simplest example is the project manager, who is accountable to the
project sponsor for the outputs of the project and to the program manager for the coherence of
the project with other aspects of the program.

3.5 Risk management

At every point during a program, there will be uncertain events or situations that could affect the
direction of the program, the achievement of desired outcomes or the realization of expected
benefits. These uncertain events or situations, and their consequences, are the risks that the
program must manage and relate to the role of program management in providing the link
between individual projects and their strategic intent. Programs are fundamentally different from
projects; as a result, risks at program level should be viewed differently from those at project
level.

Major change is usually synonymous with complexity, risk, many inter dependencies to manage
and conflicting priorities to resolve. By employing a tailored approach to risk management
within the program environment, practitioners will be better equipped to tackle increased
complexity and, although the established concepts of project risk management practice may be

36
applied, the application of these tools may need to be different. But how does the program
manager relate the ‘traditional’ project risk management methodologies and tools, within the
context of program risk management? Although there are close similarities between the process
for explicit management of individual program risks and the well-established project risk
management process, program risks can arise from above and below the program (within the
organizational context) as well as from within it and, therefore, the program risk management
process must tackle all sources.

It is recognized that in project risk management, the focus is on managing threats and
opportunities to the delivery of project outputs. Given the focus of programs is on delivering
benefits, program managers are likely to focus on events that threaten benefits realization and the
programs ability to deliver change management activities within the program as well as the
combined impact of the project risk and risks delegated from portfolio or strategic level.
A critical component of program-level risk management lies in the establishment, estimating and
release of risk funding. Human nature dictates that ‘project money will usually get spent’ – if it is
not used to mitigate threats it might be utilized to deliver additional scope requested by the
client; irrespective of whether this represents best value for money at higher levels. ‘Good
practice’ at program level will see the program manager controlling the release of project risk
funding to project managers using appropriate change control with risk provision held at various
levels and released accordingly.

3.6 Resource management

Financial management: Program finances do not follow the normal predictable cycle (very
often annual) of business accounts and gaining recognition that whilst programs can (and must)
deliver annual accounts, optimum performance is not achieved by constraining programs through
strict annual metrics. In this respect, a material contribution that the program management team
will make is managing the financial approval cycle for the business on behalf of the constituent
projects in the program. One of the key roles of financial management at program level is setting
and delivering the optimal structure for risk and contingency budgets across the program. The
naturally conservative nature of good project managers indicates that they will seek (and retain) a
larger risk and contingency budget than they are likely to require: good program management
needs to strike the right balance and ensure that the money set aside for risk and contingency is

37
assessed across the program so that it can be released – to projects or back to funders – in a way
that avoids tying up capital in an inefficient manner for the business as a whole. Few will
applaud a program manager who hands back a large lump sum of unused contingency at the very
end of the program.

Human resources: At program level, this is very much about ensuring that the right staff with
the right skills are available and appropriately balanced across the PMO and component projects.
Where the program exists within an enduring organization, staff development for the future and
succession planning within the program and at portfolio level are important considerations.

Supply chain: At program level, supply chain management is frequently critical as most
contracts are let at project level, but optimal program delivery requires coordination of delivery
(or resource deployment) at program or even portfolio level to ensure efficient use of such
resources across the whole program.

Infrastructure: The physical and virtual infrastructure for the program (and the projects within
it) is a critical resource that requires careful consideration during program set up at the beginning
of the delivery phase of the life cycle. This is the bedrock on which effective management
control is built and demands careful thought in terms of integration across projects and into
business-as-usual (both during program delivery and once incorporated into business-as-usual).

Information: Information in a program is a key resource and demands careful consideration of

its structuring and treatment. To be clear, the information resource is an ‘enabler’: it needs to be
managed within the IT infrastructure and ‘used’ within other relevant perspectives. Even where a
program may not be large enough to justify the formal appointment of a chief information
officer, the role should be allocated to someone with the competence and authority to exercise
control in this key area.

38