Project Services Pty Ltd

UNDERSTANDING PROGRAMS AND

PROJECTS
OH, THERE'S A DIFFERENCE!

Presented at

22 - 24 February 2010
Melbourne Convention Centre
Melbourne, Australia

Patrick Weaver PMP, FAICD, FCIOB,

Director, Mosaic Projects Pty Ltd

For more papers see:

https://mosaicprojects.com.au/PMKI-ORG.php

Mosaic Project Services Pty Ltd

PO Box 5150
South Melbourne VIC 3205 Australia
Tel: +613 9696 8684
Email: [email protected]
Web: www.mosaicprojects.com.au
 Understanding Programs and Projects

Abstract
Projects and Programs are different; and this difference has been ignored or confused by too many people
for too long. From the very beginnings of modern project management, the terms have been used
interchangeably; for example, the Manhattan Project to create two completely different atom bombs
involved numerous major elements such as the construction of factories and the operation of those plants.
The Manhattan Project was by all modern definitions a full blown program of work. This confusion in
terms continues in many quarters to the current day.

The publicised failures of a number of so-called major projects, particularly in the Defence and ICT
arenas would appear to be caused by the clients attempting to procure a complex program of work
(frequently involving significant elements of R&D) as a simple ‘fixed price’ projects in a perversely
misguided attempt to offload risk1.

This paper will:

• Describe the differences between projects and programs based on the PMI Standards.
• Define the key differences between managing a project and managing a program.
• Focus on setting and managing realistic expectations on the part of key stakeholders for a
program compared to a project in terms of expected levels of change and the risk profiles.
• Briefly review the PgMP qualification framework for Program Managers and demonstrate how its
structure supports the objective of effective program management.

Introduction
The difference between Projects and Programs has been ignored or confused for too long. At the most
basic level, a project is created to deliver a specified output as efficiently as possible (PMI, 2008a).
Programs focus on the coordination of a number of related projects and other activities, over time, to
deliver outcomes that benefit the organisation (PMI 2008b).

At more sophisticated levels, these differing objectives fundamentally alter the management of change,
risk, and communication. The challenge facing organisations is to recognise the difference between a
project and a program and then apply the optimum management approach. Whilst it is absolutely possible
and often desirable to contract a project to an independent third party (eg, the developer of a shopping
complex can easily contract the building of the centre to a construction company), it is virtually
impossible to effectively contract out the program management role, the program manager has to be an
integral part of the organisation’s strategic business management team.

Despite the best efforts of PMI, OGC and a range of other organisations, the confusion between projects
and programs continues in many quarters to the current day. Most disaster relief efforts are described as
‘projects’ when in fact they are an on-going program of work to realise a benefit (ie, a return to
normality). Disaster relief ‘programs’ include projects and elements of operational work and adapt as
times and circumstances change. In these circumstances, program management is about maximising the
benefits realised with constrained resources in a changing environment. Project management is focused
on the efficient creation of a defined deliverable (eg, re-building a school).

1 For more on which party carries the ultimate risk of a project failing see: The Meaning of Risk in an Uncertain World
- https://mosaicprojects.com.au/PDF_Papers/P040_The_Meaning_of_Risk_in_an_Uncertain_World.pdf

2 of 17 www.mosaicprojects.com.au
Originally published as a part of 2010 PMI Global Congress Proceedings – Melbourne Australia
 Understanding Programs and Projects

A more worrying recent trend has been for organisations to start classifying quite simple projects as
‘programs’ in an apparent attempt to avoid the necessity of defining the specific ‘product, service or
result’ they need. Whilst the degree of difficulty in determining the deliverable may alter the project’s
strategy and approach, a project remains a project! If the performing organisation / client cannot tell the
project manager what they want, the project is unlikely to succeed and changing its name to a ‘program’
won’t help.

The boundary that needs to be drawn much more sharply, and the focus of this paper, is between projects
that are initiated to create a known deliverable and then shut down and programs that are initiated to
create a change and/or realise benefit(s) for the host organisation, adapting to circumstances as conditions
change and using projects to create individual deliverables within the overall matrix of the program.

Defining the Differences – Project or Program

The Defining Standards

Both PMI and the Office for Government Commerce (OGC) in the UK agree that organisations have one
or more portfolios of projects and each portfolio contains a number of programs and projects. Portfolio
management focuses on selecting the optimum mix of projects and programs the organisation should
undertake based on its available funding and resources. Program management focuses on the coordination
of a number of related projects over time to deliver outcomes that benefit the organisation and projects are
about the efficient delivery of a defined output.

Figure1 Projects, Programs and Portfolios

PMI Standards
The definition of a project contained in A Guide to the Project Management Body of Knowledge 4th
Edition, p5 (PMI, 2008a) is: “a temporary endeavour undertaken to create a unique project service or
result”. Projects are temporary and close down on the completion of the work they were chartered to
deliver.

The definition of a program contained in The Standard for Program Management 2nd Edition Glossary, p
312 (PMI. 2008b) is: “A group of related projects managed in a coordinated way to obtain benefits and

3 of 17 www.mosaicprojects.com.au
Originally published as a part of 2010 PMI Global Congress Proceedings – Melbourne Australia
 Understanding Programs and Projects

control not available from managing them individually. Programs may contain elements of work outside
of the scope of the discrete projects in the program.”

OGC Standards
The OGC has very similar views embedded in its methodologies. PRINCE2 defines the management of
projects and the Managing Successful Programmes (MSP) methodology defines a program as: “A
portfolio of projects and activities that are coordinated and managed as a unit such that they achieve
outcomes and realise benefits” (OGC, 2003, p126).

Figure 2, The MSP program management structure

Standardisation
As can be seen from above, the definition of a program is consistent. Programs involve the coordinated
management of two or more projects to achieve benefits that would otherwise not be obtained. The
defined objective of a program, the realisation of benefits, is very different to the standard definitions of a
project that focus on the efficient delivery of products, services or results; ie, deliverables. A regularly
used short description of the differences is that projects are focused on the efficient creation of outputs;
programs are focused on delivering outcomes.

The Four Dimensions of a Project or Program

There are four basic dimensions to every project or program:

• Its inherent size usually measured in terms of value;
• The degree of technical difficulty in creating the output;
• The complexity of the relationships (‘small p’ politics) with the stakeholders; and
• The degree of uncertainty involved in the work.

The difference between how complicated the work is and its complexity is that managing complicated
work (ie, work with a high level of technical difficulty) is achievable by implementing appropriate
systems such as quality management and configuration management. The consequences of technical
difficulty are definable, predictable and manageable provided people with the necessary skills and
experience are available. The essence of complexity is that the future is inherently unpredictable and the

4 of 17 www.mosaicprojects.com.au
Originally published as a part of 2010 PMI Global Congress Proceedings – Melbourne Australia
 Understanding Programs and Projects

reactions of people to each other within the project or program’s network of relationships are nonlinear.
The responses/reactions of stakeholders to the work and consequences of any interaction or
communication are not predictable on a linear scale2.

Project Size
The size of the project or program will impact the degree of difficulty in achieving its objectives but large
projects are not necessarily complicated or complex. There are projects in Australia to shift millions of
cubic meters of ‘overburden’ from mine sites with expenditures rising to several $million per day but the
work is inherently simple (excavating, trucking and dumping dirt), and the relationships in and around the
project are relatively straight forward. The management challenges are essentially in the area of logistics.
One only has to contrast this type of mega-project with the difficulties of successfully delivering a small
program to instigate a culture change within an established bureaucracy (say introducing a new timesheet
system with supporting software) to appreciate size is only one dimension of a project or program.

Size Does Matter

Large projects, eg the construction of a major shopping centre, can easily be larger than a small program,
eg reorganising the business processes of a department. As the size of a project or program increases the
flavour of issues surrounding its management will tend to change. The two major differences to be
expected are:

a) ‘Money can't buy friends but it can get you a better class of enemy3’ – the size of the project is
likely to make external stakeholder management more important. Increasing the scale of a
project or program is unlikely to significantly change the supportiveness of supporters but may
well galvanise the interest and reactions of opponents.

b) Stakeholder management issues within the project or program are likely to emerge as major
issues – a small team or 3 or 4 people will generally resolve issues if well lead. A team of 300 or
400 people will require significant formal processes as well as leadership, motivation, etc.

Major projects certainly exist and it is quite feasible for a large project to be bigger than a small program.
Organisations such as the UK’s Major Projects Association4 have been focusing on the skills and
knowhow needed to run large projects since the 1980s. The challenge facing organisations is to know the
difference between a major project and a program and then apply the optimum management approach.

Technical Difficulty (degree of complication)

Complicated high tech projects and programs are inherently more difficult to manage than technically
simple projects and program. The nature of the technical difficulties and the degree of certainty largely
depend on how well understood the work is. Bleeding edge research has a far higher level of uncertainty
associated with every aspect of its management than work of similar technical difficulty that has been
undertaken several times before. The degree of understanding of both the work’s characteristics and the
way it will be accomplished on the part of the client is as important to the success of the endeavour as the
understanding of the team. The lower the levels of knowledge and understanding, the more difficult it is
to achieve a successful result.

Complexity = Stakeholder Relationships

Complexity Theory has become a broad platform for the investigation of complex interdisciplinary
situations and helps understand the social behaviours of teams and the networks of people involved in and

2 For more on the difference between complicated work and complexity see: A Simple View of ‘Complexity’ in Project
Management - https://mosaicprojects.com.au/PDF_Papers/P070_A_Simple_View_of_Complexity.pdf
3 Spike Milligan, 1918 - 2002

4 See http://www.majorprojects.org/

5 of 17 www.mosaicprojects.com.au
Originally published as a part of 2010 PMI Global Congress Proceedings – Melbourne Australia
 Understanding Programs and Projects

around a project. These ideas apply equally to small in-house projects as to large complicated programs.
In this regard, complexity is not a synonym for complicated or large.

Complexity Theory has developed from and includes the earlier field of study known as Chaos Theory.
Complexity Theory can be defined as the study of how order and patterns arise from apparently chaotic
systems and conversely how complex behaviour and structures emerge from simple underlying rules
(Cooke-Davies, Cicmil, Crawford, Richardson. 2007). Some of these ideas appear directly relevant to
understanding project and program management from a stakeholder relationship perspective and are
generally more important in program management (Weaver, 2007).

Uncertainty
The degree of uncertainty associated with the desired output from the team’s endeavours has a major
impact on the management of the project or program. This is different to the issues around bleeding edge
projects discussed above. When a bleeding edge project has a clearly defined end point you are on a quest
the challenge is finding the optimum route to the end. When the end point is unclear you are either
making a movie – the process are well known but the outcome is uncertain or on a ‘walk in the fog’
where neither the route nor the outcome are defined.

The less certain the client is of its requirements, the greater the uncertainty associated with delivering a
successful project or program and the greater the effort required from the team to work with the client to
evolve a clear understanding of what’s required for success. This is not an issue as long as all of the
stakeholders appreciate they are on a journey to initially determine what success looks like, and then
deliver the required results. Problems occur if expectations are couched in terms of achieving an ‘on time,
on budget’ delivery when the requirements are not defined and the expected benefits are unclear.

Project / Program Typology

Figure 3, Project Typology

6 of 17 www.mosaicprojects.com.au
Originally published as a part of 2010 PMI Global Congress Proceedings – Melbourne Australia
 Understanding Programs and Projects

One of the more established ways of describing projects is a typology that maps the interaction of
uncertainty and technical difficulty. Knowing both ‘what to do’ and ‘how to do it’; or more importantly
knowing how much you know about these two elements. The typology describes four types of project
based on these criteria: ‘painting by numbers’, quests, ‘making a movie’ and ‘lost in the fog’. It was
developed by Eddie Obeng (1994) in the Project Leader’s Secret Handbook and asks two questions:
• Are you clear about what to do (the outcome to be achieved)?
• Do you know how to do it (processes, methods, experience)?

Painting by Numbers
Traditional project management works well when both ‘what’s to be done’ and ‘how to do it’ are well
understood by all key stakeholders including the client and the project team. Closed projects (panting by
numbers) can be fully defined, estimated and planned. There are low levels of uncertainty and ambiguity;
risks are largely known and manageable. Value is largely achieved by delivering the requirements on time
and on budget.

A typical software program of this type would be installing a standard software upgrade across a large
organisation based in several different cities and with several operating divisions.

Going on a Quest
In these projects and programs, the objective is clear but the way to achieve the objective is uncertain. At
the end of the day, success or failure is clear cut; the objective has been achieved (or not). The challenge
is optimising the way forward. Process and system improvements tend to fall into this category. The
objective is to reduce processing time by 20% – this is easily measured at completion. The difficulty is
knowing what is the best way to achieve the objective.

Before committing major resources to the main part of the work adequate time has to be allowed to
prototype solutions and test options before a final design solution can be determined and then
implemented. The project or program needs to be developed in phases with go/no go gateways as the
design is firmed up. There are risks associated with any creative design process and most software
developments are ‘quests’ requiring creative solutions to identified problems to achieve the desired
objective.

Making a Movie
In these projects the tools and techniques are well known but the final outcome is uncertain. Only after
completion can the results be measured and success or failure be determined. Most culture changes and
marketing initiatives (and making movies) are in this category. The tools to be used including: training,
communicating and advertising, are well known and the traditional (if not optimal) mix of techniques
understood for most situations. What no one can predict is if the ‘public’ will acclaim the final result,
merely accept the final result or dump the final result.

Traditional project management is not enough in these projects; there is a continual need to measure
results, feedback information and adapt the mix of activities to optimize the likelihood of success. The
key value measurement is attempting to answer the question is it worth spending more or should we cut
and run? Efficient stakeholder communication and relationship management is crucial. Whilst there will
be some outstanding successes (block busters) and some total flops most projects and programs in this
category finish somewhere in the middle. The art is spending just enough effort to achieve an acceptable
outcome – dealing with shades of grey.

7 of 17 www.mosaicprojects.com.au
Originally published as a part of 2010 PMI Global Congress Proceedings – Melbourne Australia
 Understanding Programs and Projects

Lost in the Fog

I actually prefer Prof. Rodney Turner’s version ‘a walk in the fog’. This classification is a journey
towards a desired new state. Whilst the problem can be described, no one is sure of the optimum solution
or outcome, or how best to achieve it. The only option is to proceed carefully, stop at regular intervals to
check exactly where you are and re-plan the way forward. Exactly the way you navigate through a thick
fog. Both ambiguity and uncertainty are high.

Effective management is about making sure at each ‘stop point’ the value achieved to date is locked in
and then refocus on the next increment. Management is both easy and difficult. It is easy because there is
no point in setting fixed plans (you have no idea what to plan). It is difficult because decisions on value
and whether to stop or continue are subjective and need to be made in a collaborative environment of
trust.

Traditional measures of success such as on-time and on-budget are largely meaningless; typically there
are no statistics to base this type of measure on. Consequently these projects are the realm of cost
reimbursable contracts and partnerships; stakeholder relationship management5, and a clear understanding
of value are the only effective tools for building to a successful outcome. Agile software development is
ideal for this type of project. Each iteration builds new capability and value and the learning provides a
platform for the next iteration of development.

The Dimensional Overview

None of these ‘dimensional factors’ differentiate projects from programs, whilst most programs are likely
to be larger, more complex and less certain than most projects the key differentiator between a program
and a project is, as described in the PMI and OGC Standards above, their objective. Programs are focused
on realising benefits through the coordinated management of a group of projects and other work; projects
are focused on delivering a defined output. One of the major roles of a program manager is to initiate
projects to create the outputs the program needs to deliver its intended outcomes.

Types of Program

In addition to the degrees of certainty/uncertainty in ‘what’ and ‘how’ used by Obeng above, programs
can be created to achieve significantly different organisational objectives. The Global Alliance for Project
Performance Standards (GAPPS) has defined three basic types of program:
• Multi-Project Programs: focused on managing several projects in parallel to deliver coordinated
support for a new business objective. Project origination and termination is generally external to
the program (by business or Portfolio management).
• Strategic Programs: focused on achieving business change or strategic outcomes, involving many
projects running both sequentially and in parallel with early outputs and outcomes influencing
decisions about later projects; the program is a “learning organization”. Project origination and
termination is generally internal to the program; Portfolio management approves the program’s
budget.
• Operational Programs: focused on minimize negative impact on, and supporting, the ongoing
business of the organisation. Facilities maintenance projects for a major item of infrastructure (eg,
a rail system) fall into this category; the key measure of success is budget -v- actual impact on
operations. Project origination and termination is generally external to the program (by business
or Portfolio management).

5 For more on stakeholder management see: https://mosaicprojects.com.au/PMKI-TPI-075.php

8 of 17 www.mosaicprojects.com.au
Originally published as a part of 2010 PMI Global Congress Proceedings – Melbourne Australia
 Understanding Programs and Projects

The GAPPS (2006) framework6 clearly differentiates the three program types outlined above from a
major project; and although most programs in most application areas should fit clearly into one category,
recognises some programs may have characteristics from multiple categories.

Key Differences between Projects and Programs

Determining if the work to be undertaken is a project or a program is important because it will determine
what management approach to use. Attempting to manage a program as a project can lead to failure, or at
best sub-optimal outcomes.

Programs generally have a multiplicity of requirements, deliverables, customers, stakeholders,

departments and interfacing organisations interacting with the work. The following checklist can help
determine the difference (adapted from Duggal, 2009):
1. Is the associated change wide-ranging, and designed to achieve a strategic business objective?
2. Are there multiple deliverables staggered over a period of time?
3. Is the timescale loose and flexible focused towards achievement of benefits, rather than meeting
strict deadlines alone?
4. Is the scope fluid and are dynamic changes expected?
5. Is there a lot of ambiguity and uncertainty?
6. Is it at a departmental or higher level?
7. Are benefits expected to be delivered incrementally during the lifespan of the initiative?

The first two questions are key, projects are best if there is one primary goal for the project to focus on
delivering; multiple goals are best dealt with by way of a program with a series of projects each focusing
on a particular goal.

The remaining questions are secondary, and the criteria that separate projects from programs are not
always clear cut. The building works for the 2012 Olympics are being managed as a multi-project
program of works; multiple projects managed in a coordinated way. Whereas a construction project to
build a major export oil refinery in Saudi Arabia due for completion in 2013 and with a similar
construction value to the Olympics is being managed as a single major project despite many of the
packages exceeding US$1 billion.

Using the criteria above the reasons for the different decisions becomes clearer:
Olympics Oil
Refinery
- The associated change is wide-ranging, and designed to achieve a Yes Yes
strategic business objective.
- There are multiple deliverables staggered over a period of time. Yes No
- The timescale is relatively loose and flexible focused towards No No
achievement of benefits, rather than meeting strict deadlines.
- The scope is relatively fluid and dynamic changes are expected to ?? No
optimise outcomes.
- There are relatively high levels of ambiguity and uncertainty (particularly ?? No

6 Download the GAPPS framework from https://mosaicprojects.com.au/PDF-Gen/GAPPS-Program-Typology.pdf

9 of 17 www.mosaicprojects.com.au
Originally published as a part of 2010 PMI Global Congress Proceedings – Melbourne Australia
 Understanding Programs and Projects

at the beginning, focused on how the business objective can best be

achieved).
- The work is complex and multi-disciplinary. Yes Yes
- Management is at a departmental level or higher. Yes Yes
- The benefits are expected to be delivered incrementally during the ?? No
lifespan of the initiative.

The Olympics has a significantly higher number of ‘Yes’ or possible/partial ‘??’ criteria (the intention is
to progressively open and test venues) than the oil refinery but neither are 100% definitive. Provided the
skills are available within an organisation if there is any doubt, the problems caused by managing a major
project as a program are far fewer than the problems caused by trying to manage a program of work as a
project.

The Differences in Managing Projects and Programs

In many respects, the management of projects and programs appears similar. Both are selected via the
portfolio management processes on the basis they support or enable one or more of the organisation’s key
strategic initiatives. Both are initiated, planned, executed and closed with on-going monitoring and
controlling during their life cycle. And both apply common processes such as time, risk and
communication management.

However, there are distinctly different themes and focuses in managing projects and programs which have
major consequences on the style of management:
• A successful project is delivered ‘on time and on budget’ whereas a program should be focused
on the overall benefits being created, taking more time or spending more money to deliver
increased benefits can be a good outcome; ‘value’ is the driver rather than budget.
• Project managers focus on producing the optimum deliverable. Program managers focus on
integrating the deliverables into the organisation’s operations to reap the maximum benefit from
using the deliverables.
• Stakeholder management is a far more complex and important issue for program managers as
most benefits are only realisable in the future. Project managers should be working within a more
constrained framework.
• The risk management framework of a project should be largely definable. The risk management
profile of a program is open ended and heavily influenced by external factors.

These differences require distinctly different management focus:

Program Management Project Management
Focuses on the vision of the program architecture – Focuses on the detail, planning and managing the
design, prioritise and align the projects to create work to deliver your component of the overall vision
the vision.
Is strategic, focused on the big picture and the Is tactical, focused on delivering the specified
implementation of a strategy to realise benefits outputs on time and on budget.
Requires management and coordination with an Requires leadership and facilitation to achieve the
overall business focus. projects technical objectives.

10 of 17 www.mosaicprojects.com.au
Originally published as a part of 2010 PMI Global Congress Proceedings – Melbourne Australia
 Understanding Programs and Projects

The three key management themes that form the framework for PMI’s program management standard are
Benefits Management, Program Governance and Stakeholders Management. Whereas, projects are
managed in line with project management good practice defined in the PMBOK® Guide and focus on
minimising unnecessary change.

A few of the key differences in management approach are highlighted below:

Managing uncertainty:
• The project view – seek certainty before commencing execution.
• The program view – expect uncertainty as the world changes and impacts on the organisation.

Managing change:
• The project view – seek to minimise unnecessary change. Projects change management focuses
on the change of scope, and its consequences (time, cost, risk, quality).
• The program view – embrace change to future works to maximise the benefits delivered to the
organisation whilst maintaining stability for current projects. Program management focuses on
the change of strategic outcomes. Changes to current projects are designed to maximise the
benefit contribution of the project deliverables to enhance the final program outcomes.

Managing risk:
• The project view – seek to minimise undefined risks by locking in benefits and mitigating threats.
• The program view – expect undefined risks to occur. Maintain adequate contingencies for future
occurrences and actively seek new opportunities to create value. Program risk can be quite
different from project risk; a stakeholder who is assessed as only a moderate risk on each of the 5
projects within a program may be seen in aggregate as a high program risk because if the risk
associated with the stakeholder occurs all of the program’s projects are impacted.

Managing stakeholders and communication:

• The project view – seek to align stakeholders with the project’s objective.
• The program view – engage with stakeholders and use the relationships to map future possibilities
focused on maximising long term value to the organisation.

Managing the schedule:

• The project view – seek to encompass 100% of the work within the schedule at an appropriate
level of detail for controlling the work.
• The program view – incorporate the project schedules at a summary level and manage the gaps
and interfaces between the projects. Focus on interdependencies and the medium to long term
future. Interdependencies are critical; the slipping of a minor deliverable in one project may have
major consequences in another that is dependant on it. All interdependencies should be mapped
and the precise form of the deliverable defined. Information from the detailed project schedules
should be rolled up into the program schedule on a regular basis to maintain alignment.

Taken overall, project management is based on systems thinking, processes, inputs, outputs and
predictability. Whilst the concept of complexity thinking is important to the practice of project

11 of 17 www.mosaicprojects.com.au
Originally published as a part of 2010 PMI Global Congress Proceedings – Melbourne Australia
 Understanding Programs and Projects

management, complexity is central to program management. Creativity and the emergence of new ideas
to maximise opportunities are critical aspects of program management7.

An important program management role is the sourcing and allocating of scarce resources to the projects
within the program based on the overall priorities of the program, not the project. This requires
standardised resource management systems within the projects and the developing of a culture that
focuses the individual project managers on the overall good of the program in preference to their specific
project’s needs. Rewards and recognition should go to the project manager’s who gave up some key
resources and finished late as a consequence if their sacrifice benefitted the overall program.

Whilst ‘controls’ or at least the measurement of performance against plan have a role in both projects and
programs, the importance of controlling is significantly lower in program management than project
management8. In both spheres the importance of controlling is overrated and the value of leadership and
governance underrated. However, whilst project managers can survive in a controls focused environment,
program managers cannot control the day to day operations for several projects, they have to be leaders
that inspire their project managers to achieve the objectives of the overall program.

Setting and Managing Senior Management’s Expectations

A key challenge facing project and program management professionals is managing the expectation of
senior managers. Unrealistic expectations are unlikely to be realised and creating realistic expectations in
senior management thinking requires a sustained process of education and communication.

Realistic expectations of a project should include reasonably high levels of certainty in terms of time,
cost, scope, risk and quality. And importantly, the level of certainty should progressively increase as the
project moves through its life cycle. The skill of a project manager is identifying ambiguity and
uncertainty and then seeking to remove or resolve the causes. The more uncertain the work, the more
likely program management approaches will deliver better outcomes for the organisation.

Realistic expectations of a program are based around achieving the maximum value from the overall
endeavour. The program manager should be expected to balance relatively short term stability and
certainty needed for the current projects with flexibility and value management to optimise longer term
outcomes. In this sense value management is not a cost cutting exercise; rather the balancing of any value
proposition though ‘the eye of the stakeholder’ – this is rarely solely constrained by either time or cost.
The program manager should be capably of creating a vision of the future for his/her colleagues on the
executive management team and helping them to help the program be successful.

Value Management

Effective value management is a key part of effective program management and requires an
understanding of what is valuable to the organisation. To realise a benefit, the outcomes from the program
need to support a strategic objective of the organisation. Therefore, the processes to initiate a project
within the program should have as a basic consideration its alignment with the organisations strategic
objectives.

Whilst the value chain starts with a project being initiated to create a new product, service or result, the
new output by itself cannot deliver a benefit to the organisation. The program’s management, in
7 For more on complexity see: A Simple View of ‘Complexity’ in Project Management -
https://mosaicprojects.com.au/PDF_Papers/P070_A_Simple_View_of_Complexity.pdf
8 See Project Controls in the C21 – What works / What’s fiction -
https://mosaicprojects.com.au/PDF_Papers/P083_Project_Controls_in_the_C21.pdf

12 of 17 www.mosaicprojects.com.au
Originally published as a part of 2010 PMI Global Congress Proceedings – Melbourne Australia
 Understanding Programs and Projects

collaboration with the organisation’s management has to make effective use of the output to realise a
benefit. It is the organisation’s management that manages the organisation and these people need to
change the way the organisation works to use the new capability to realise the intended benefit.

Assuming strategic alignment is achieved, the realised benefits should translate into real value. The
challenge is often quantifying value – the concept of ‘value drivers’ helps. Value drivers allow the benefit
to be quantified either financially or by other less tangible means.
In the current economic climate, organisations are finding operating capital in short supply. Therefore the
value of a new process to accelerate the organisation’s billing cycle can be measured at several levels:
• The output from the activity to develop the new billing process is simply the new process – this
has no value
• Once the organisation’s management starts using the new process the
measurable outcome is a reduction in the billing cycle from (say) 45 days
to 30 days.
• The benefit of this reduction in the billing cycle could be a reduction in
operating capital needs of $500,000.
• The value of this reduction is $500,000 at 12% interest = $60,000 per
annum.

The above example may also trigger additional value by allowing the capital to be
redeployed into another profit generating activity, improving customer
relationships, and potentially reducing bad debts.

The challenge of program management is identifying and communicating the value

drivers to all levels of the organisation’s management involved in the activity so
that valuable decisions are made in preference to knee jerk gut-reactions focused
on short term, easy to measure metrics. Value is created by meeting the strategic
needs of the organisation’s stakeholders – this requires careful analysis and
understanding of who they are and what are their real requirements; ie, effective
stakeholder management.

Project managers can quickly describe success in terms of the project deliverable,
program managers need to be able to convey a much more subtle message
effectively. In the above example, if the project is overrunning budget by $20,000
which option is better?
• Is it better to reduce scope and only achieve a 5 day reduction in billing
Figure 4, the time and recover the $20,000? This would reduce the annualised saving
Value Chain
by $40,000 (two thirds).
• Slow the project down and achieve savings by reduced overtime etc if the delivery is delayed by
2 months. The likely saving is $10,000 (ie, the project will still overrun by $10,000), but the
annualised cost of 2 months loss of interest is also $10,000 (one sixth of $60,000)
• Keep going and absorb the additional costs??

From a value perspective, the option to reduce scope is clearly not effective; the organisation would spend
$40,000 in additional interest in the first year to save $20,000; unless there are opportunities to recover
the value in later projects. The other two options preserve value, which is best choice depends on the
availability of funds to finance the work.

13 of 17 www.mosaicprojects.com.au
Originally published as a part of 2010 PMI Global Congress Proceedings – Melbourne Australia
 Understanding Programs and Projects

The Leadership Ladder for Project and Program Managers

The book, The Leadership Pipeline (Charan, Drotter, Noel, 2001) describes the transitions between 6
levels of leadership:
• From managing oneself to managing others – the move to a team leader’s role.
• From managing others to managing managers – the move to a project leadership role.
• From managing managers to managing a function – the move to taking responsibility for the
performance of an area of the business (possibly major project management).
• From functional manager to business manager – the move to a program management role focused
on achieving strategic goals and objectives.
• From business manager to group manager – responsible for a whole line of business and
developing strategic goals.
• From group manager to enterprise manager – a ‘C’ suite executive responsible for setting the
overall strategy of the organisation.

As can be seen from this brief extract, the first step is the biggest; the move from being a good worker to
a good team leader who helps others to work to their optimum requires a quantum change in thinking.

The progression from team leader to junior project manager to project manager simply involves
developing the same skills to a higher level and learning to take one’s hands off of the day to day work of
the project.

However, the jump from project leadership to program leadership for project managers will frequently
bypass the ‘functional management’ level. Very few organisations run major projects with internal teams
of sub-project managers, etc. The differences in skills needed are huge and learning program management
on-the-job can be very hard work. Because of these skill differences, many program managers are drafted
from functional management (but then have to learn about projects).

Neither option is ideal; organisations seeking to implement effective program management should invest
in designing a career path to move managers from their current roles into program management roles.

Project and Program Governance

Governance is different to both controlling and leading the work of a project or program. Governance is a
process of putting in place policies and procedures that provide an acceptable level of assurance the work
of the project/program conforms with the objectives outlined in its Charter and other key organisational
policies. This involves aligning the interests of the organisations directors, its programme and project
teams and the wider stakeholder community and forms part of the organisation’s overall corporate
governance. Corporate governance (including project and program governance) provides the structure
through which the objectives of the company are set, and the means of attaining those objectives and
monitoring performance are determined9.

From an organisational perspective, the difference between the governance of projects and programs is
minimal; projects and programs are chartered, sponsored, monitored and reviewed in similar ways. The
only difference, discussed above, is the degree of stability expected of forward work projections.

9 For more on Governance see: https://mosaicprojects.com.au/PMKI-ORG.php

14 of 17 www.mosaicprojects.com.au
Originally published as a part of 2010 PMI Global Congress Proceedings – Melbourne Australia
 Understanding Programs and Projects

However, the governance of the projects within a program place a range of specific responsibilities onto
the program management team. Some of the key project governance activities likely to be performed by
the program manager include:
• Chartering the project.
• Sponsoring the project (the program manager may be the project sponsor, or would need to work
collaboratively with the senior manager appointed as the sponsor)10.
• Creating and setting the project strategy in consort with the project manager.
• Monitoring all aspects of the performance of the project including quality, time, cost, scope and
risk (usually through a dedicated PgMO11).
• Ensuring continued project alignment with the overall program objective (as adjusted). If
necessary terminating projects that no longer align with the program’s objectives.
• Consolidating information for reporting to higher level governance bodies.

This need to be part of the organisations governance processes, responsible for the governance of project
work is one of the key differences between managing a major project and managing a program of work.
The major project manager needs to conform with and support the organisations governance policies; the
program manager needs to implement the policies in an appropriate way for the work of the program.

PMOs can play an important governance role. A Program Management Office PgMO will frequently
provide a range of key functions including over sighting the performance of the projects within the
program, acting as a repository for lessons learned on the early project to the benefit of later projects,
managing the overall program schedules and other functions, providing the link between the organisations
strategy and the work of the projects and supporting the overall corporate governance processes within
the program. The PgMO should be a key conduit translating project data into executive management
information11.

Program Management and the PgMP Qualification Framework

From the discussions above, it should be apparent program management is not a natural extension of
project management; for most project managers it is a career change. Project managers manage
technicians and subcontractors. Program managers manage project managers and collaborate with other
senior managers as part of the organisation’s senior management team focused on the strategic delivery of
value.

These basic differences are recognised in the PMI certification structure:

• The PMP credential is focused on project management knowledge and some general management
knowledge. Whilst there is a need for 3 years experience directing and leading project activities,
this is a relatively low threshold to achieve.
• The PgMP credential has a much stronger focus on experience and the ability of the candidate to
manage relationships with key stakeholders. A sound knowledge of program management is
required but this is one third of the overall assessment. The candidate needs to demonstrate a
strong background in program management and receive a favourable assessment from a range of
people in a multi-rater assessment.

10 For more on the role of the sponsor (or Senior Responsible Owner, SRO) see:
https://mosaicprojects.com.au/PMKI-ORG-015.php#Process2
11 For more on PgMO’s and PMO’s see: https://mosaicprojects.com.au/PMKI-ORG-045.php

15 of 17 www.mosaicprojects.com.au
Originally published as a part of 2010 PMI Global Congress Proceedings – Melbourne Australia
 Understanding Programs and Projects

The natural career progression for a project manager is to bigger, more complicated and more critical
projects. Becoming a program manager is a significant career change that needs to be recognised as such
and properly managed and supported by the person and the organisation.

Conclusion
Programs are not big projects, they are different! The key difference is in the focus of the management
effort; project management is focused on creating a deliverable as efficiently as possible, program
management is focused on maximising the benefits realised by the organisation.

The key difference between a project and a program of works can be described as:
a) Projects are about delivering a product to meet stakeholder needs and expectations with unnecessary
change minimised. The key element in project management is efficiency.
b) Programs are about delivering benefits to the organisation within defined constraints and in alignment
with its strategic objectives. Changing the elements within a program to maximise benefits actually
realised, and maintaining alignment with changing strategic objectives is essential. The key focus of
program management is in the delivery of value, working in consort with the operational and strategic
elements of the organisation.

The processes, skills and competencies needed to manage a program to deliver benefits are now well
understood and described in standards published by PMI and OGC and knowledgeable program managers
can seek formal accreditation as PgMP from PMI or MSP Practitioners from OGC.

What is needed now is for organisational management to recognise the differences and make effective use
of both program and project management to create a strategic advantage for their organisation. Using
project management processes to deliver a program generally will not work despite many of the tools
being superficially similar.

____________________________

References
A Guide to the Project Management Body of Knowledge 4th Edition (2008a). Project Management Institute,
Pennsylvania, USA
The Standard for Program Management 2nd Edition (2008b). Project Management Institute, Pennsylvania, USA
Managing Successful Programs (2003). Office for Government Commerce, London, UK.
Charan, R., Drotter, S., Noel, J. (2001). The Leadership Pipeline, How to build the leadership-powered company.
John Wiley & Sons, New York.
Cooke-Davies, T., Cicmil, S., Crawford, L., Richardson, K. (2007). We’re Not In Kansas Anymore, Toto: Mapping
the Strange Landscape of Complexity Theory, and its Relationship to Project Management. Project
Management Journal, Vol 38, No. 2, 50-61
Duggal, J.S. (2009) Harvard Management Communication Letter 2(4). Retrieved from PMI Community Post articles
(2009). http://www.pmi.org/eNews/Post/2009_08-14/NLU-Project-orProgram-You-Decide.html
GAPPS. (2006) GAPPS Program Typology. Retrieved from (2009):
http://www.globalpmstandards.org/index.php/program-manager-standards/defining-program-types.html
Obeng, E. (1994) Project Leader’s Secret Handbook Financial times Prentice Hall, London.

16 of 17 www.mosaicprojects.com.au
Originally published as a part of 2010 PMI Global Congress Proceedings – Melbourne Australia
 Understanding Programs and Projects

Weaver, P. (2007) A Simple View of ‘Complexity’ in Project Management. Downloaded from

https://mosaicprojects.com.au/PDF_Papers/P070_A_Simple_View_of_Complexity.pdf 14th Nov. 2009

____________________________

First Published 23rd February 2010 – Augmented and Updated

Downloaded from Mosaic’s PMKI

Free Library.

For more papers focused on Program Management see:

https://mosaicprojects.com.au/PMKI-ORG-030.php

Or visit our PMKI home page at:

https://mosaicprojects.com.au/PMKI.php

Creative Commons Attribution 3.0 Unported License.

Attribution: Mosaic Project Services Pty Ltd, downloaded from

https://mosaicprojects.com.au/PMKI.php

17 of 17 www.mosaicprojects.com.au
Originally published as a part of 2010 PMI Global Congress Proceedings – Melbourne Australia