42 Project and Prgogramme Management Manuals Recommended Practice

You might also like

Download as pdf or txt
Download as pdf or txt
You are on page 1of 199

Project and Programme

Management Manuals
Recommended Practice
Welcome
Welcome to the Pathfinder Project and
 Programme Management Manuals and the
material which supports both of these documents.

 The information contained within this folder sets out the
Mott MacDonald recommended approach to Project or
 Programme Management for staff and teams undertaking
a Project or Programme Management role on behalf of a
 client.

 In other words it has been developed to address the


colloquial question “what is the Mott MacDonald way?”
 I hope that you find it useful and that with time, feedback

 and commentary, it will evolve into an ever more useful


tool to be used by Mott MacDonald PPM Practitioners

 across the Group.

David Phillips,
Practice Leader Project and Programme Management

Feedback and comments on these documents are welcome and


should be addressed to dave.phillips@mottmac.com.

MAX/OTC/PF/002/02
tabs.qxp 21/10/2009 09:29 Page 1

Preface
1. Preface
Preface           
The information contained within this folder sets out Mott
MacDonald’s recommended practice for Project and Programme
Management. This information itself sits within a wider resource of
Project and Programme Management material, collectively known
as Pathfinder and hosted on the Mott MacDonald Intranet (MiMi).

The Project Management Manual has a supporting document that


provides Project Governance Guidelines. The Programme
Management Manual depends on both of these documents and
adds the techniques and processes specific to programme
management. In addition to hard copy, all manuals are published
within the “Methods” segment of the Pathfinder site, as illustrated
in Figure 1 below.

Good Practice

Programme
People
Management Methods
Manual

Project Training Tools


Management
Manual

Project Governance Collaboration Marketing


Guidelines

Professional Bodies

Figure 1 Document relationships and location within Pathfinder

The Project Management Practice applies to Mott MacDonald’s


operations across all four regions and it is therefore necessary to
ensure a global perspective as far as possible. For this reason the
practice is based on the Guide to the Project Management Body of
Knowledge (PMBOK Guide) 4th edition published by the American
Project Management Institute (PMI).

MAX/OTC/PF/002/02
There are many similarities between this and the Body of
Knowledge published by the UK Association for Project
Management (APM) and in some cases APM practice is used (and
noted as such). The recommended practice has been developed in
conjunction with staff from University College London who
provided a further level of independent input and expert review.

The Programme Management Practice has also been developed


primarily based on the recommendations and processes of the
American Project Management Institute (PMI) as set down in its
Standard for Program Management 2nd edition. Additional reference
is also made to The Office of Government Commerce’s Managing
Successful Programmes 3rd edition (MSP), as well as incorporating
Mott MacDonald experience with independent review by staff from
University College London.

Scope and Interface with Mott MacDonald QES

The Project and Programme Management Practice is aimed at


assignments undertaken by Mott MacDonald where staff are
providing a project or programme management service direct to the
client e.g. acting as project managers. It provides guidance to staff
and ensures a consistent approach.

It gives clients confidence, based on internationally recognised


best practice.

The Practice is not specifically aimed at staff undertaking the


internal project manager’s role defined by the Mott MacDonald QES,
as for many assignments such a complete practice would be
excessive. However, some of the components of the Practice may
be helpful, especially where the size of the assignment is especially
large.

The Project and Programme Management Recommended Practice


is not mandatory. However, it is a requirement of the Mott
MacDonald QES that the method for undertaking the services is set

MAX/OTC/PF/002/02
out in the MM Project Plan Of Work (PPW), whether that be a client
mandated system (which is often the case) or the Mott MacDonald
Practice. Modifications are acceptable, but again this needs to be
stated in the PPW with a rationale.

Project Governance guidelines

The purpose of these guidelines is to explain good practice in


respect of project governance. A project manager and his team
should expect to operate within a client environment where a
governance structure in line with these guidelines is present. Where
this is not the case then the guidelines will allow the project
manager to discuss with the client the need or otherwise for
additional processes and controls.

Guidelines, procedures and templates

The Project and Programme Management Manuals provide links to


additional documents such as guidelines, example procedures,
templates etc. They are intended to help practitioners’ level of
understanding and to get a head start on producing the documents
for their own project or programme.

         

MAX/OTC/PF/002/02
tabs.qxp 21/10/2009 09:29 Page 2

Project Management
2. Project

Manual
Management
Manual
Project Management
Manual
Project management manual – recommended practice

Pathfinder

Project Management Manual


recommended practice
October2009
MAX/OTC/PF/003

Issue and Revision Record


Rev Date Originators Editor Checker Approver Description

G Williams First formal


1.0 15-01-09 M Wallace M Carden D Phillips
D Woolven issue.
R Grant Second
2.0 30-09-09 D Woolven V Hughes D Phillips
G Holmes formal issue.
D Woolven V Hughes D Phillips D Phillips Minor
2.1 30-10-09 additions and
formatting

This document has been prepared for the titled Mott MacDonald accepts no responsibility or
purpose and should not be relied upon or used liability for this document to any party other than
for any other purpose without an independent the person by whom it was commissioned.
check being carried out as to its suitability and
prior written authority of Mott MacDonald being To the extent that this document is based on
obtained. Mott MacDonald accepts no information supplied by other parties, Mott
responsibility or liability for the consequence of MacDonald accepts no liability for any loss or
this document being used for a purpose other damage suffered, whether contractual or tortious,
than the purposes for which it was stemming from any conclusions based on data
commissioned. Any person using or relying on supplied by parties other than Mott MacDonald
the document for such other purpose agrees, and used by Mott MacDonald in preparing this
and will by such use or reliance be taken to document.
confirm his agreement to indemnify Mott
MacDonald for any alleged loss or damage
resulting therefrom.

Mott MacDonald, Mott MacDonald House, 8-10 Sydenham Road, Croydon, CR20 2EE
T +44 (0)20 8774 2000
F +44 (0)20 8681 5706

i Issue 2.1 - October 2009 MAX/OTC/PF/003/02


Project management manual – recommended practice

Preface
This Project Management Manual is aimed at assignments undertaken by Mott
MacDonald where staff are providing a project management service direct to
the client e.g. acting as Project Managers. It provides guidance to staff and
ensures a consistent approach. It gives clients confidence in the quality of
the service, being based on internationally recognised best practice.

The Practice is not specifically aimed at staff undertaking the internal project
manager’s role defined by the Mott MacDonald QES, as for many assignments
such a complete practice would be excessive. However, some of the
components of the Practice may be helpful, especially where the size of the
assignment is especially large.

The Project Management Manual is not mandatory. However, it is a


requirement of the Mott MacDonald QES that the method for undertaking the
services is set out in the MM Project Plan of Work (PPW), whether that be a
client mandated system (which is often the case) or the Mott MacDonald
Practice. Modifications are acceptable, and should be stated in the PPW with a
rationale.

i Issue 2.1 - October 2009 MAX/OTC/PF/003/02


Project management manual – recommended practice

How to use this manual


This manual is split into sections which align with the American Project
Management Institute Body of Knowledge (PMI-BOK) process groups:

Æ Initiation
Æ Planning
Æ Execution
Æ Monitoring & Controlling
Æ Closing

The page headers provide an indication of the stage of the process the
section relates to

Furthermore each section has a graphic which illustrates which stage of the
process it relates to

ii Issue 2.1 - October 2009 MAX/OTC/PF/003/02


Project management manual – recommended practice

Using templates from the manual


Pathfinder Logo
A small Pathfinder logo ( ) indicates that a template (or
guide) can be accessed for this item. The number indicted in
brackets alongside the side logo is the document reference of
the template.

The templates or guidelines can be accessed by clicking on


the number in brackets next to the Pathfinder logo. This will
then hyperlink to the template document located within PiMS
and opens within the PiMS document viewer. From here there
is an option to Open/Download the document for use.

Guides
The guides that can be accessed act as further background reading
and contain more details on topics than the templates.

Templates
The templates will assist in the production of outputs and
contain a contents list with summary guidance on what each
section should contain which is shown within square
brackets. The formatting of the templates can be adopted for
your own plans or Pathfinder logos can be removed or
substituted for client logos.

Good Practice Section on Pathfinder


The templates and guides that can be
accessed from this document are also
available through the Good Practice
section on the Pathfinder site.

Real life examples can also be found


located under the Good Practice section of
the Pathfinder. However, although these
serve as a excellent examples, they do not
strictly follow this manual in terms of their
content as in many cases they pre-date
Pathfinder.

Please note that for later issues of this document, additional active
links will be implemented to include real life examples which have
followed the templates from the Project Management Manual.

iii Issue 2.1 - October 2009 MAX/OTC/PF/003/02


Project management manual – recommended practice

Chapters

1 Overview 1.1
1.1 Introduction ................................................................................. 1.1
1.2 Scope.......................................................................................... 1.1
1.3 Objectives ................................................................................... 1.2
1.4 What is a Project? ....................................................................... 1.2
1.5 What is Project Management? .................................................... 1.4
1.6 Use of the Project Management Process by Practitioners.......... 1.5
1.7 Key Project Participants .............................................................. 1.6
1.8 Health, Safety and Environment ................................................. 1.6
1.9 References.................................................................................. 1.7

2 The Project Management Process 2.1


2.1 Process Groups .......................................................................... 2.1
2.2 Project Integration Management ................................................. 2.2
2.3 Gateway Reviews ....................................................................... 2.3
2.4 General Tools and Techniques ................................................... 2.4

3 Initiation Process Group 3.2


3.1 Project Charter ............................................................................ 3.2
3.2 Preliminary Scope Statement ..................................................... 3.5

4 Planning Process Group 4.1


4.1 Project Management Plan........................................................... 4.1
4.1.1 Scope Management Plan 4.3
4.1.2 Time Management Plan 4.6
4.1.3 Cost Management Plan 4.9
4.1.4 Quality Management Plan 4.11
4.1.5 Human Resources Management Plan 4.13
4.1.6 Communications Management Plan 4.15
4.1.7 Risk Management Plan 4.17
4.1.8 Issues Management Plan 4.20
4.1.9 Procurement Management Plan 4.22

iv Issue 2.1 - October 2009 MAX/OTC/PF/003/02


Project management manual – recommended practice

5 Execution Process Group 5.1


5.1 Direct & Manage Project Execution ............................................ 5.1

6 Monitoring & Controlling Process Group 6.1


6.1 Monitor & Control Project Work................................................... 6.1
6.1.1 Scope Management 6.3
6.1.2 Time Management 6.4
6.1.3 Cost Management 6.5
6.1.4 Quality Management 6.6
6.1.5 Human Resources Management 6.7
6.1.6 Communications Management 6.8
6.1.7 Risk Management 6.9
6.1.8 Procurement Management 6.10
6.1.9 Change Control 6.11
6.1.10 Issue Management 6.13

7 Closing Process Group 7.1


7.1 Close Project............................................................................... 7.1

v Issue 2.1 - October 2009 MAX/OTC/PF/003/02


Project management manual – recommended practice

1 Overview
1.1 Introduction
This manual provides guidance in the application of project

“ This manual provides


guidance in the
application of project
management techniques and acts as an aid to participants in
capital projects* in understanding the structure and
implementation of a project and their role in ensuring its success.
management
techniques… It describes Project Management processes and defines their

” application to ensure that the functional and technical


requirements of any project are met. The adoption of these
processes helps to ensure that the scope is managed, cost is
controlled, the schedule is achieved, risk is managed and quality
is consistently maintained.

* It should be noted that the principles which are outlined in this manual were
developed within the context of capital projects, however many of the techniques
are applicable to other types of project (such as: business change, education
programmes, health programmes etc.)

1.2 Scope
This manual is aimed at Mott MacDonald staff who are required to

“ This manual is aimed


at Mott MacDonald
staff who are required
undertake Project Management activities on behalf of a client and
has applicability across all sectors in which the Group operates. It
follows the recommendations and processes developed by the
to undertake Project
American Project Management Institute (PMI) as set down in its
Management activities
Guide to the PM Body of Knowledge (PMI-BOK, Fourth Edition).
on behalf of a client …

” These processes are internationally recognised and are more


widely adopted globally than those of the UK’s Association for
Project Management Body of Knowledge (APM-BOK, Fifth Edition
2006). It should be noted, however, that there are many
similarities between the two and many concepts are shared.

1.1 Issue 2.1 - October 2009 MAX/OTC/PF/003/02


Project management manual – recommended practice

The principles of project management are universal and the


understanding of the processes set down in this manual will allow
participants in a project, whether in the UK, USA or elsewhere, to
better understand what leads to a successful outcome to a
project.

1.3 Objectives
This manual has been prepared to assist the Mott MacDonald
Group and it’s staff in:

“ A key objective is to
provide a common
Mott MacDonald
■ Understanding the processes required to ensure the
successful management of a project from its inception to
completion.

approach… ■ Providing a common Mott MacDonald approach which staff

” can draw upon to develop their skills and competence and


equip them for the Project Management role.

■ Reviewing our client’s processes against a common practice


to identify areas which may increase the risk of project failure
(and hence risk to our reputation and fee).

■ Implementing a disciplined Project Management process,


where this is part of our role.

■ Establishing an effective project planning process.

■ Exercising effective control on the design and development


process.

■ Exercising effective control on the implementation phase of a


project through to its close.

■ Having a knowledge bank from which solutions can be drawn.

1.4 What is a Project?


A project is a temporary endeavour undertaken to create a unique

“ A Project is a
temporary endeavour
undertaken to create a
product, service or result in order to achieve a specific business
benefit or objective. When the objective is achieved the project is
disbanded. Most projects are undertaken to create a lasting
unique product, service outcome while the project itself is temporary as it has a definite
or result (PMI-BOK) beginning and a definite end. A project creates unique

” 1.2 Issue 2.1 - October 2009 MAX/OTC/PF/003/02


Project management manual – recommended practice

deliverables, which can be products, services or results.

Projects develop progressively as more detail becomes available.

“ A well documented
change control process
can significantly reduce
Scope is described in broad terms early in the project but is
refined as the project team develops a better understanding of the
risk to a project … project’s objectives and deliverables. Scope change of any

” magnitude should be identified and quantified for its impact on


schedule and cost of a project. A well documented change
control process can significantly reduce risk to a project and

“ A project has a lifecycle


which is the path and
sequence through the
ensure additional unexpected costs are identified and recovered.

A project has a lifecycle, which is the path and sequence through

various activities required the various activities to produce the final product. This should not
to produce the final be confused with the term ‘life span’ which is used to describe the

product life of the product as illustrated by Figure 1.

Figure 1 Product Life Span vs Project Life Cycle

The project lifecycle covers the tasks of specifying and designing

“ Decisions taken during


the concept phase of a
project need to ensure
a product through to its testing and handover into operational use.

Whole Life Costing plays a big part in both the project life cycle

that whole life costs and the product life span. Decisions taken during the concept

are taken into phase of a project need to ensure that whole life costs are taken

account … into account when choosing the preferred option for the project.


1.3 Issue 2.1 - October 2009 MAX/OTC/PF/003/02
Project management manual – recommended practice

1.5 What is Project Management?


Project Management is the professional discipline with

“ Project Management is
the application of
knowledge, skills, tools
responsibility for the management of a project as opposed to for
example those disciplines undertaking the design, construction,
manufacturing functions. The project management process is one
and techniques to of the Knowledge Areas developed by the Project Management
project activities to Institute known as Project Integration Management.
meet project
Project Management is applied throughout the project lifecycle
requirements
(PMI-BOK)
” from concept through to handover. It comprises the management
of all that is involved in achieving the project objectives safely,
within agreed time, cost, schedule, quality and other performance
criteria within the relevant codes of conduct and legal
constraints/requirements.

Project Management provides the single point of integrated


responsibility needed to ensure that everything on the project is
managed effectively as shown in Figure 2.

Constraints
Time, cost, quality,
technical and other
performance
parameters, legal,
environmental, etc.

Input Output
Business need, Management of the Project deliverables,
problem or Project and/or services,
opportunity change

Mechanisms
People, tools and
techniques,
equipment,
organisation

Figure 2 Project Management Process (© APM-BOK)

Whatever the title of the person managing the project, they are
more likely to be successful when there is clear accountability for
its successful conclusion.

1.4 Issue 2.1 - October 2009 MAX/OTC/PF/003/02


Project management manual – recommended practice

Project Management relies on the progressive application of


Project Management processes to achieve the desired objectives.

“ The concept behind


Project Management is
simply to ‘Plan the
The concept behind Project Management is simply to ‘Plan the
work and work the Plan’. This involves the bringing together and
working with the project planners and the technologists in
work and work the
workshops or brainstorming sessions to achieve a consensus for
Plan’.

” the way forward within the constraints of time, cost and resource.

Figure 3 summarises this process in to a Plan, Do, Check, Act


cycle where each part of the cycle feeds into the next until the
process is finished.

Figure 3 The Plan, Do, Check, Act Cycle

1.6 Use of the Project Management Process


by Practitioners
Project Management practitioners should be familiar with all

“ Practitioners should be aspects of this manual as well as the other material in the
familiar with all aspects Pathfinder resource. However, their attention is particularly drawn
of this manual as well to Section 2 of this manual - The Project Management Process,
as the other material in which provides a guide as to how a project is implemented and
the Pathfinder controlled. When charged with responsibility for the project
resource… management, these processes should be adopted to help ensure

” the successful outcome of our projects.

1.5 Issue 2.1 - October 2009 MAX/OTC/PF/003/02


Project management manual – recommended practice

1.7 Key Project Participants


The manual makes reference to a number of participants in a
project. Whilst each client may wish to establish arrangements
which are particular to their business, the manual provides
guidance on best practice which will be reflected in most client’s
organisations.

The roles of the key participants are outlined below and set down
in detail in the Project Governance Guidelines:

■ Project Board: The Project Board will be the


group responsible for the initiation and strategic
direction of the project.

■ Project Sponsor: The Project Sponsor is the


representative appointed to act on Project
Board’s behalf to ensure that the outturn of the
project matches the approved brief.

■ Project Manager: Is the person responsible for


ensuring that the project is delivered on time, to
budget and to the required quality standard
(within agreed specifications).

1.8 Health and Safety


A primary responsibility of a Project Manager is ensuring that all
aspects of the project are carried out in a manner that provides a
healthy and safe environment for those working on the project,
those affected by the project, and those that will work or maintain
the facilities provided by the project.

In planning and executing the project the Project Manager needs


to take account of:

■ The client’s Health and Safety policies and arrangements,


■ Mott MacDonald’s Health and Safety processes embedded
within the QES system,
■ Statutory regulations that pertain within the industrial sector in
which the programme is being executed,
■ Good working practices in relation to the well being and
treatment of work colleagues.

1.6 Issue 2.1 - October 2009 MAX/OTC/PF/003/02


Project management manual – recommended practice

1.9 Environment and Sustainability


It is the duty of the Project Manager to ensure that the
environment is protected from harm as a result of the activities of
the project, during manufacture and construction. The Project
Manager also has a responsibility to ensure that the project
design(s), once operational, allow for environmental protection.

Similarly the Project Manager has a duty to consider the needs for
sustainable development in bringing about the changes required
by the project, both during the design and build stages but also
through into operation, maintenance and final decommissioning.

In planning and executing the project, the Project Manager needs


to take account of:

■ The client’s Environmental policies and arrangements,


■ The client’s Sustainability objectives and guidelines,
■ Mott MacDonald’s Environmental management processes as
embedded with the QES system,
■ Mott MacDonald’s guidance on sustainable development on
the company intranet led by the Group Sustainability
Champion,
■ Statutory regulations that pertain within the industrial sector in
which the programme is being executed,
■ Good working practices in relation to protection of the
environment and sustainable development.

1.10 References
This manual and supporting documents adopt the processes and
terminology of the PMI as set out in:
► A guide to the Project Management Body of Knowledge
(PMI-BOK), 4th Edition, 2008, ISBN: 1933890517
Reference has also been made to the following:
► Association for Project Management Body of Knowledge
(APM-BOK), Fifth Edition, 2006, ISBN: 1903494133 Note1
In addition the following documents have assisted in the
construction of this Project Management Manual:
► Office of Government Commerce (OGC) UK, Gateway
Publications
► CIOB Code of Practice for Project Management in
Note 1: The APMBoK is available as a licensed electronic
copy through the Methods section on Pathfinder.
Construction and Development, Third Edition, Blackwell, 2002

1.7 Issue 2.1 - October 2009 MAX/OTC/PF/003/02


Project Management Manual – recommended practice

2 The Project Management Process


2.1 Process Groups
Projects use processes as tools to drive the project forward. A

“ Projects use processes


as tools to drive the
project forward
process is “a series of actions bringing about a result”. Project
Management processes can be organized into five groups of one
or more processes each (defined by the PMI-BOK) as shown in

” Figure 4 below.

Project Integration Management – Process Groups

Monitoring
Initiation Planning Execution & Closing
Controlling
Figure 4 Project Management Process Groups

The process groups are linked by the results they produce − the
result or outcome of one becomes an input to another.
Figure 5 illustrates the interaction of the five process groups which
takes a project through initiation, implementation, completion and
hand-back to the End User.
The interactions among the groups may be straightforward and
well-understood, or they may be subtle and uncertain. For
example, scope change will almost always affect project cost, but
it may or may not affect team morale or product quality. These
interactions often require trade-offs with performance in one area
being enhanced only by sacrificing performance in another.
Successful Project Management requires active management of
these interactions.
Therefore, repeating the initiation process at the start of each
phase helps to keep the project focused on the business need it
was undertaken to address. It should also help ensure that the
project is halted if the business need no longer exists or if the
project is unlikely to satisfy that need.
Whilst the governance arrangement will vary from project to
project good practice requires that a number of key roles be
established to oversee a project. This manual assumes that the
Figure 5 Process Group client will establish a Project Board (or equivalent) at the outset of
Interactions the project to oversee the management of the project and accept
its output at completion.

2.1 Issue 2.1 - October 2009 MAX/OTC/PF/003/02


Project Management Manual – recommended practice

The Project Board acts as ‘Owner’ to ensure that the outturn of


the project matches the original brief in terms of its intended
output and the parameters set for time, cost and quality.

“ Ownership of the
project is normally with
the Project Sponsor
The Project Board responds to the Client’s policy directives
(emanating from senior company executives) which require the
implementation of a project in order to achieve a required
outcome. The full duties of the Project Board are set down in the

” Project Governance Guidelines which support this manual. It


should be noted that the size of the Project Board will depend
upon the size of the client organisation as well as the scale of the
project. In some instances the Project Board may only have two
members (Project Sponsor and Project Manager).
Within the Project Board ownership of the project is normally with
the Project Sponsor. The Project Sponsor will be involved from
the start of the project and ensures that it is actively reviewed.
The role of the Project Sponsor is also set down in the Project
Governance Guidelines.

2.2 Project Integration Management

Figure 6 Project Integration Management Processes

The Project Management process, defined by PMI as Project


Integration Management, defines the methodology for

“ Project Integration
Management is an
umbrella term covering
implementation of the management of a project. This process is
shown in Figure 6 above.
Project Integration Management is an umbrella term covering the
key processes which will help ensure a successful project
the key processes outcome. It involves the interaction of the various project
which will help ensure management processes, allows the project team to concentrate
resources, affect choices and deal with issues before they
a successful project become critical. It also coordinates work to ensure expectations
outcome. are managed, stakeholder requirements are achieved and the

” project is brought to a successful conclusion.


During the development of the Project Charter, and the
subsequent project phases, the client’s internal governance

2.2 Issue 2.1 - October 2009 MAX/OTC/PF/003/02


Project Management Manual – recommended practice

policies must be complied with.


The project will also need to comply with internal and external
influences that include, but are not limited to the following:
■ Government and industry standards,

■ Client’s existing facilities and capital equipment ,

■ Existing human resources and personnel administration,

■ Marketplace conditions,

■ Risk tolerance,

■ Commercial databases,

■ Project management information systems, including


scheduling tools, configuration management and
document management systems.

The Project Manager and members of the project team need to


take these factors into consideration when deciding on the project
approach.

2.3 Gateway Reviews


Gateway reviews are an established mechanism for providing
independent assessments of the status of projects at various key
stages.

Reviews are carried out by those not having a direct involvement

“ Gateway reviews are an


established mechanism
for providing independent
in the day to day management of the project. It is recommended
that where there is high risk due to large sums of money being
involved or where there is high complexity that external
independent reviewers are used. The role of reviewers is to
assessments …… provide detached challenge to the aspects under consideration to

” ensure the achievability and robustness of the proposals.

It is recommended that an approach similar to that developed by


OGC should be adopted as this enhances the approach proposed
by PMI. [www.ogc.gov.uk/what_is_ogc_gateway_review.asp]

In summary, OGC define 5 stages of review throughout the


project lifecycle as follows:

Gateway 1: Business Justification


Gateway 2: Delivery Strategy
Gateway 3: Investment Decision
Gateway 4: Readiness for Service
Gateway 5: Operations Review & Benefits Realisation

Gateway Zero: Strategic Assessment is for Programmes, which is


discussed in the Pathfinder Programme Management Manual.

The following diagram suggests how the OGC gateways can be

2.3 Issue 2.1 - October 2009 MAX/OTC/PF/003/02


Project Management Manual – recommended practice

mapped onto the Process Groups.

[Note: OGC’s gateway process is mandatory on UK government


funded projects and programmes].

Figure 7 Project Gateway Review Process

2.4 General Tools and Techniques


In addition to the Templates included in the Project Management
Manual there are many tools and techniques available to the
project manager to assist in the planning, execution and control of
a project. The General Tools and Techniques Guide contains
information on the most commonly used tools and techniques.
There are numerous others and their use will be largely
dependent on the project team’s past experience.

The General Tools and Techniques Guide follows the project


management process of initiation, planning, execution, monitoring
and control and contains methods of evaluating data and
decisions, methods for building the essential process for
managing the project tools and reporting techniques to ensure all
project related matters are recorded.

Tools and Techniques


■ ‘General Tools and Techniques’ Guide (007)

2.4 Issue 2.1 - October 2009 MAX/OTC/PF/003/02


Project Management Manual – recommended practice

3 Initiation Process Group


The Project Initiation Process develops the Project Charter and the Preliminary Scope Statement to
facilitate the authorisation to proceed with the project.

3.1 Project Charter


Outline The Project Charter starts the project process off as shown in
Figure 8.

Figure 8 Develop Project Charter

This process starts with the establishment of the objectives of the


project to meet the requirements of the client’s Business Plan,
then the evaluation of these objectives to develop a concept for
the project and the subsequent preparation of the Project Charter.

“ Once endorsed by the The Project Charter outlines the high level business case for the
project. It includes:
Project Board, the
■ the project objectives,
Project Charter is the
authority for the project ■ a list of requirements that satisfy the End User, Project
Board and other Stakeholder’s needs and expectations,
to commence...

” ■


outline scope,

budget,

■ a summary milestone schedule based on the estimated


timescale,

■ risks identified so far,

■ an outline investment appraisal setting down the expected


benefits, affordability and source of finance.

Once endorsed by the Project Board, the Project Charter is the


authority for the project to commence; it is also the authority for
the Project Sponsor to assign resources to the project.

3.2 Issue 2.1 - October 2009 MAX/OTC/PF/003/02


Project Management Manual – recommended practice

When This process sits outside the actual project and is used to allocate
project funding. Its main aim is to obtain the authorisation of the
Project Board for the commencement of the project and to confirm
the Project Manager and relevant authorities.

By whom The Project Sponsor is responsible for generating the Project


Charter.

Inputs ■ Project governance guidelines


■ Client’s commercial processes
■ Client’s business plan

Tools and Techniques ■ Project selection methods: Generated by priorities identified in


the Client’s Business Plan.
■ Project Management methodology: As set down in this manual
■ Expert judgement

Process

c Assign the Project Manager


Identify the designated Project Manager.

d Detail the Project Manager’s Authority


Project Board to identify how much authority the Project Manager
has, including any cost or schedule tolerances that may have
been set.

e Develop the Outline Business Case


Prepare the Business Case to include the project objectives,
outline scope and milestone schedule.

f Develop the Summary Budget


Calculate an outline budget including an allowance for known
risks and contingency. Allow both for capital cost and operating
expenditure including cost of the project management and client
teams.

g Record the Known Stakeholder Influences


Identify any known stakeholders at this stage. Identify their
involvement, wants and needs, how they can influence the project
and is that influence positive or negative.

h Detail the Quality Expectations


Detail the End User’s quality expectations, what will satisfy the
End User when it comes to handing over the products? It is useful
to document this early on so everyone understands what the
project is aiming to produce.

i Assumptions and Constraints


Document any known assumptions or constraints at this stage,
either organisational or environmental.

3.3 Issue 2.1 - October 2009 MAX/OTC/PF/003/02


Project Management Manual – recommended practice

j Record the Identified Risks


Record the risks identified to date in the risk register

An overview of the process is shown in Figure 9 below.

Any Tolerance set


1) Assign the Project
2) Authority Manager Outline Cost
Estimates
Project Managers
Level of Authority
Risks Identified

3) Outline Business
4) Budget Case Project Objectives

Outline Scope

Project Charter
6) Quality 5) Identify known Outline Schedule Summary Milestone
What Project is Expectations Stateholders Schedule
Aiming to Produce

Environmental
7) Identify
8) Risks Constraints

Organisational

Figure 9 Project Charter Overview

Outputs
 ■ Project Charter (009)

Next Steps Once the Project Charter has been authorised, the Preliminary
Scope Statement can be developed.

3.4 Issue 2.1 - October 2009 MAX/OTC/PF/003/02


Project Management Manual – recommended practice

3.2 Preliminary Scope Statement


Outline The Preliminary Scope Statement is part of the initiating process
group as shown in Figure 10 and sets out what needs to be
accomplished in terms of project requirements and scope.

Figure 10 Develop Preliminary Scope Statement

The Preliminary Scope Statement defines the project objectives


and deliverables, the boundaries of the project, the acceptance

“ The Preliminary Scope methods and high-level scope control.


Statement should The Preliminary Scope Statement should include an initial view of
include an initial view the work required to achieve the project objectives in the form of a
Statement of Work (SOW).
of the work required to
achieve the project The Preliminary Scope Statement should take account of any
external factors like the Client’s policies and guidelines, lessons
objectives... learned from previous projects and other sources together with

” information on project management information systems and


resource pool.

The Preliminary Scope Statement must contain sufficient


information to allow the Project Board to make a decision as to
whether the project is viable or not.

When This process is used to define the project/project phase and what
needs to be accomplished. In multi-phase projects this process
validates or refines the scope for each phase.

By whom
Project Manager

Inputs ■ Project Charter


■ Project Governance Guidelines
■ Client’s Commercial processes

Tools and Techniques ■ Project Management methodology: as set down in this manual
■ Expert Judgement.

3.5 Issue 2.1 - October 2009 MAX/OTC/PF/003/02


Project Management Manual – recommended practice

Process

c Outline the Project Objectives


Provide the quantifiable criteria that must be met for the project to
be considered successful. Project objectives must include cost,
schedule and quality measures.

d Detail the Project Deliverables


Provide a description of the major deliverables that must be
produced to complete the project.

e Determine the Scope Boundaries (including


constraints and assumptions)
Details of any constraints or assumptions are recorded. These
establish the boundaries of the project, set dates for completing
certain activities or an assumption that certain resources will be
available.

f Record End User Acceptance Criteria


Details of the End User’s acceptance criteria are recorded as far
as it is known. This is an early view and may be refined during
the Planning Process Group activities.

g Update Known Risks


Update the risks identified in the Project Charter with any further
risks that have been identified.

h Prepare the Initial Work Breakdown Structure (WBS)


Compile a high level WBS based on the information available.

i Produce a Summary Cost Estimate


Compile a summary cost estimate based on the available
information together with previous knowledge and experience
from similar projects or undertakings. An allowance should be
made for project risks and contingency.

j Detail the Initial Project Organisation


Start to compile an organisation chart and populate it with known
project team members. A previous project organisation chart may
be useful as an initial framework.

k Detail the Configuration Management Requirements


Begin to detail the configuration management requirements
including the change control process. At this stage it may be just
setting up the project identification system, setting the file
structure and opening the files.

An overview of the process is shown in Figure 11 below.

3.6 Issue 2.1 - October 2009 MAX/OTC/PF/003/02


Project Management Manual – recommended practice

2) Project and 1) Project and


Product Deliverables Product Objectives
Requirements
capture
List Constraints

4) End‐user
Acceptance Criteria 3) Scope Boundaries

List Assumptions

6) Initial WBS Preliminary Scope 5) Known Risks


Statement
8) Initial Project 7) Summary Cost
Organisation Estimate

Set‐up Project
9) Configuration Identification Identification System
Management
Requirements
Capturing, Storing & Open Files
Accessing
Information

Set‐up File Structure


Verification &
auditing

Change Control
Process

Figure 11 Preliminary Scope Statement Overview

Outputs
 ■ Preliminary Scope Statement (010)

Next Steps With the approval of the Preliminary Scope Statement the
Initiation Process Group is complete and the Planning Process
Group starts.

3.7 Issue 2.1 - October 2009 MAX/OTC/PF/003/02


Project Management Manual – recommended practice

4 Planning Process Group


The Planning Process Group is concerned with producing the Project Management Plan
(PMP) and subsidiary plans.

4.1 Project Management Plan


Outline The Project Management Plan (PMP) is an invaluable source of
reference for all associated with the project. The PMP is the
output of the Planning Process Group as shown in Figure 12 and
defines goals and objectives, roles and responsibilities,
organisation, scope of the project and how the project will be
executed, monitored, controlled and closed.

Project Integration Management

Monitoring &
Initiation Planning Execution Closing
Controlling
Process Group Process Group Process Group Process Group
Process Group

Prelim.
Project Project Management Direct & Manage Monitor & Control
Scope Close Project
Charter Plan (PMP) Project Execution Project Work
Statement

Scope Time Cost Quality HR Comms. Risk Issues Procurement


Management Management Management Management Management Management Management Management Management
Plan Plan Plan Plan Plan Plan Plan Plan Plan

Figure 12 Project Management Plan

“ The Project Management


Plan (PMP) is an invaluable
source of reference for all
The PMP comprises a number of subsidiary plans, as shown in
Figure 12 and is a living document, produced by the Project
Manager and updated and revised throughout the life of the
project. The level of detail contained is determined by the Project
associated with the project Manager; however, it needs to be sufficiently detailed to manage

When
” the project effectively.

This process is used to define, integrate and consolidate all the


subsidiary plans into the PMP.

By whom
Project Manager

4.1 Issue 2.1 - October 2009 MAX/OTC/PF/003/02


Project Management Manual – recommended practice

Inputs ■ Project Governance Guidelines


■ Project Charter
■ Preliminary Scope Statement
■ Project Management Processes for:
■ Scope
■ Time
■ Cost
■ Quality
■ Human Resource
■ Communications
■ Risk
■ Issues
■ Procurement
■ Client’s commercial processes

Tools and Techniques ■ Project Management methodology: as set down in this manual
■ Expert Judgement.

Process

Develop PMP subsidiary plans in accordance with the


c
following sections of this manual

d Compile the PMP

Outputs
 ■ Project Management Plan (011)

Next Steps Prepare the subsidiary plans and compile into a single PMP. Once
this is complete the project is prepared for moving to the
execution phase.

4.2 Issue 2.1 - October 2009 MAX/OTC/PF/003/02


Project Management Manual – recommended practice

4.1.1 Scope Management Plan

Outline The Scope Management Plan details how the project scope will
be defined, verified and controlled and how the Work Breakdown

“ The Scope
Management Plan
details how the project
Structure (WBS) will be created. It refines and develops the
Preliminary Scope Statement into a detailed scope statement to
assist in project decisions in the future.
The Scope Management Plan contains a definition of the
scope will be defined, objectives and includes what the project is trying to achieve in
terms of scope, the products to be produced, the acceptance
verified and
criteria for those products together with any constraints and
controlled... assumptions.

When
” This process is part of developing the PMP. It can be a stand-
alone document as an appendix to the PMP or the detail can be
combined within the PMP itself. The Scope Management Plan
defines what work is required, and only the work that is required,
to complete the project successfully.

By whom
Project Manager (with input from the project team)

Inputs ■ Project Charter


■ Preliminary Scope Statement
■ Project Governance Guidelines pertaining to scope
management
■ Approved Change Requests to the project scope
■ Procurement Management Plan

Tools and Techniques ■ Expert Judgement.


■ Templates, Forms and Standards.
■ Product Analysis: Project Manager to assess need for value
management techniques and input from technical consultants.
■ Alternatives identification: By brain storming and lateral
thinking.
■ Stakeholder analysis: Develop stakeholder map.
■ Work breakdown structure templates.
■ Inspection: Acceptance testing by End User Department.
■ Change control system.

4.3 Issue 2.1 - October 2009 MAX/OTC/PF/003/02


Project Management Manual – recommended practice

Process

c Scope Planning
Detail how the project scope will be defined, verified and
controlled and how the WBS will be created. The detail from the
Preliminary Scope Statement together with information on the
size, complexity, procurement method and importance of the
project should determine how much detail and control to apply.

d Define the Scope


Develop the Preliminary Scope Statement into a detailed scope
statement that will assist in project decisions in the future. Define
the objectives and include what the project is trying to achieve in
terms of scope, the products to be produced, the acceptance
criteria for those products together with any constraints and
assumptions. Include information on funding limitations, cost
estimates, risks, milestones and configuration requirements.

e Create WBS
Create the WBS, including information on the project deliverables
and an outline of the work required to produce them. Ensure the
deliverables are broken down into more manageable components
(called work packages). The Project Management team
determine the level of decomposition depending on factors like,
how complex is the project, how many phases are there, etc. The
decomposition level chosen should be sufficient to allow the
project team to manage work effectively. Careful note should also
be taken of the procurement approach as this is likely to influence
the WBS.

f Validate the Scope


Obtain formal end-user acceptance that the project scope has
been completed and project products defined. The Project Board
should agree the formal system for product acceptance.

g Produce Change Control Procedure and Control the


Scope
Ensure all subsequent changes to the scope are processed
through the Change Control Procedure.

An overview of the process is shown in Figure 13 below.

4.4 Issue 2.1 - October 2009 MAX/OTC/PF/003/02


Project Management Manual – recommended practice

Figure 13 Scope Management Plan

Outputs
 ■ Scope Management Plan
■ Scope Definition
(012)

■ WBS
■ Product Acceptance Criteria
■ Change Control Procedure

4.5 Issue 2.1 - October 2009 MAX/OTC/PF/003/02


Project Management Manual – recommended practice

4.1.2 Time Management Plan

Outline Once the project starts, the progress information has to be


entered against the project plan and evaluated. This plan
contains information on the project activities identified so far, the

“ The project schedule is


the underlying
structure behind all the
sequencing of those activities, the resources to be employed and
the duration of these activities. All of these elements are then
used to develop the project schedule. When all concerned accept
the schedule, it is frozen and a baseline created for future
Project Management reference. This baseline schedule becomes the basis for
techniques measuring project performance. The project schedule is the


underlying structure behind all the Project Management
techniques.

When This process takes the output from the Scope Management Plan
and uses that information to develop the project schedule that will
be used to measure project performance.

By whom
Project Manager and project scheduler (where available)

Inputs ■ Scope Management Plan:


■ Approved Change Requests to the project schedule
■ Procurement Management Plan

Tools and Techniques ■ Activity Definition


■ Expert Judgement.
■ Templates – Use activity list from a previous project to
generate activity template.
■ Activity Sequencing
■ Networking Method – Appropriate method to be selected
by Project Manager and scheduler.
■ Resource Estimating
■ Expert judgement.
■ Duration Estimating
■ Analogous estimating – Use information from previous
similar projects.
■ Reserve analysis – The use of contingency or time
reserves is to be agreed with the client.
■ Schedule Development
■ Appropriate method to be selected by Project Manager
and scheduler, as a minimum likely to include a linked bar
chart. Other methods such as network diagrams can also
be considered in addition.

4.6 Issue 2.1 - October 2009 MAX/OTC/PF/003/02


Project Management Manual – recommended practice

Process

c Define the Activities to be Performed


Produce a list of activities to be performed together with attributes
such as constraints and assumptions, successors and
predecessors, resource requirements, relevant dates and a list of
milestones that are firstly required by the contract and secondly as
a project requirement.

d Sequence these Activities


Produce schedule network diagrams to display the schedule
activities and their logical relationships. Produce a narrative to
accompany these diagrams explaining the approach used.
Update activity list and activity attributes to include any changes
as a result of this sequencing step.

e Estimate the Resources Required


Determine the type and quantity of resources required for each
scheduled activity and include any changes into the activity list
and activity attributes. Produce a resource breakdown structure
identifying the category and type of resource. Compile a resource
calendar to show working hours and availability of resources.

f Estimate the Duration of the Activities to be


Performed
Determine the likely number of work periods for each scheduled
activity.

g Develop the Project Schedule


Using the information generated in Steps 1-4, together with the
risks identified to date, to develop the project schedule. The
schedule should normally be represented as a milestone or
summary schedule together with a detailed schedule with logical
relationships. The latter should show start and finish dates for
each scheduled activity and the resources required for each of
these activities if these have been confirmed.

h Schedule Control
Use the schedule to monitor performance and provide progress
reports.

An overview of the process is shown in Figure 14 below.

4.7 Issue 2.1 - October 2009 MAX/OTC/PF/003/02


Project Management Manual – recommended practice

Relevant dates
Activity list Statement of Work
Constraints &
assumptions

Resources

1) Activity Definition Leads and lags


Logical
relationships
Activity Attributes
Predecessor
activities

Successor activities
Mandatory
Milestone list
Optional
Precedence
Precedence Diagram Method
Schedule Network relationships
2) Sequencing Diagrams Activity on Arrow
Leads & lags

3) Resource
Estimating Working and non
Resource Calendar working days,
resource availability
Resource Table
Details of resources
Estimating required to carry out
4) Duration Resources, work
Time activities
Estimating effort and work
Management Alternative options
periods required to
Plan complete an activity Resource Published cost
estimates rates

Bottom-up
Activities Attributes estimating

Activities list
5) Develop
Resource Analogous
Schedule
Requirements estimating
Activity duration Parametric
estimates estimating

Constraints or Reserve analysis


assumptions
3 point estimating
Section 6) Monitor & Risk Register
Association Line 6) Schedule Control Control Project Work

Figure 14 Time Management Plan

Outputs
 ■ Time Management Plan (013)
■ Activity Milestone List
■ Sequencing Narrative
■ Network Diagrams
■ Resource breakdown and calendar
■ Project Schedule

4.8 Issue 2.1 - October 2009 MAX/OTC/PF/003/02


Project Management Manual – recommended practice

4.1.3 Cost Management Plan

Outline The Cost Management Plan is primarily concerned with estimating


the cost of the resources needed to complete schedule activities

“ It is necessary to then totalling these costs to produce a cost baseline through


which the project budget can be managed and controlled. It also
produce a cost considers the effect of project decisions on the cost of using,
baseline through which maintaining and supporting the project deliverable(s) throughout
their life; this is often called whole life-cycle costing. The Cost
the project budget can Management Plan also includes a consideration of project risks,
be managed and contingency reserves, stakeholder requirements and earned value
analysis.
controlled

When
” This process takes the output from the Scope and Time
Management Plan processes and uses that information to
estimate, manage and control the costs of the project.

By whom Project Manager with commercial managers and estimators


(where available)

Inputs ■ Scope Management Plan


■ Project Schedule
■ Staff Management Plan
■ Risk Register
■ Project Contracts
■ Project Governance Guidelines
■ Approved Change Requests
■ Commercial Databases

Tools and Techniques ■ Estimating Techniques – Appropriate method to be selected


by Project Manager with estimating support.
■ Reserve analysis – The use of contingency or time reserves to
be agreed with the Project Sponsor.
■ Resource cost rates – Rates derived from resource cost rates
based on staff cost per hour & material costs, cost rate
quotations and commercial databases.
■ Vendor bid analysis - Analyse vendor bids against known cost
rates.
■ Funding Requirements – The amount of total and periodic
funding required to meet the requirements of the cost baseline
(plus contingency reserves) and the expected cash flow.

4.9 Issue 2.1 - October 2009 MAX/OTC/PF/003/02


Project Management Manual – recommended practice

Process

c Estimate the Cost of the Project


Aggregate the cost of the project using estimating techniques.
These techniques should draw on inputs from the PMP subsidiary
plans, (scope, time, risk, etc) and information from the
marketplace conditions and commercial databases.

d Produce a Cost Baseline for Measuring Project


Performance
Use the total of estimated costs together with any management
reserves, contingencies and funding limitations imposed, to
produce the cost baseline with which to set project funding and
cash-flow requirements.

e Determine the Cost Control Measures to be Used


Consider using earned value management to measure project
performance. Use forecasting to understand the further costs
required for completion.

An overview of the process is shown in Figure 15 below.

Establish a baseline Estimating


of project costs Techniques:
Analogous
Parametric
Bottom-up/
Synthetic Marketplace
1) Cost Estimating 3 Point Estimating Conditions

Lessons Learned
Log

Risks
Inputs from PMP
Cost Subsiduary plans
Resources
Management
Plan Commercial
Databases Schedule

Scope
Historical Data
2) Cost Budgeting Total of Estimated
Costs
Cost Baseline
Management
Reserve

Scheduling work to
Funding limit regulate
reconcilitiation expenditure

Section 6) Monitor &


3) Cost Control Control Project Work
Contingency Risk Contingency
Association Line

Figure 15 Cost Management Plan

Outputs
 ■ Cost Management Plan (014)
■ Project Cost Breakdown (Cost Book)
■ Project Cost Baseline
■ Cost control and monitoring measures

4.10 Issue 2.1 - October 2009 MAX/OTC/PF/003/02


Project Management Manual – recommended practice

4.1.4 Quality Management Plan

Outline The Quality Management Plan contains details on how quality will
be planned, assured and controlled on the project. Quality
planning identifies the procedures and activities that the project


Quality planning identifies the
procedures and activities that team uses to define, plan and execute for quality. Project quality
the project team uses to define, assurance addresses the management of project quality and the
plan and execute for quality products to be produced.

When
” This process takes the quality requirements from the Scope
Management Plan and uses that information to plan the way in
which quality will be managed, assured and controlled on the
project.

By whom
Project Manager and quality manager (where available)

Inputs ■ Scope Management Plan


■ Project Governance Guidelines
■ Approved Change Requests

Tools and Techniques ■ Quality Planning – Cost Benefit analysis, benchmarking and
cost of quality techniques are used during the planning phase.
■ Quality Assurance – Using audits and process analysis.
■ Quality Control – Using cause & effect diagrams, control
charts, flowcharts, histograms, Pareto diagrams, scatter
diagrams, quality inspections and defect repair reviews to
ensure the correct level of control is implemented.

Process

c Plan the Approach to Quality Management


Determine the quality standards to be used and how the project
will satisfy them

d Determine how the Approach in Step 1 will be


Achieved
Compile a plan of quality audits and process reviews to ensure
the plan is successfully implemented and quality standards are
maintained

Identify the Monitoring and Control Functions

4.11 Issue 2.1 - October 2009 MAX/OTC/PF/003/02


Project Management Manual – recommended practice

e
Monitor project results to ensure they comply with the quality
standards set and determine the intervention measures required
to ensure unsatisfactory performance is eliminated.

An overview of the process is shown in Figure 14 below.

Quality Checklists

Reliability
Quality
Management Quality Metrics Failure rate

Defect Density
Rules, Regulations,
Standards,
Guidelines
Benchmarking
Quality
1) Quality Planning Cost Benefit
Management Analysis
Plan Process
Improvements
Cost of quality

Force field analysis

Quality Baseline Quality objectives

Section 5) Direct &


2) Quality Assurance Manage Project
Execution

Section 6) Monitor &


3) Quality Control Control Project Work

Figure 16 Quality Management Plan

Outputs
 ■ Quality Management Plan (015)

4.12 Issue 2.1 - October 2009 MAX/OTC/PF/003/02


Project Management Manual – recommended practice

4.1.5 Human Resources Management Plan

Outline The Human Resource Management Plan is concerned with


planning the human resources required for the project, obtaining

“ It is important to consider how


the resource will be developed
into a cohesive team
those resources, developing them into a cohesive team,
managing the team’s performance, coordinating any changes and
resolving any issues.

When
” This process takes the resource requirements from the Time
Management Plan and uses the information to plan the project
team, acquire the team members, develop the team and monitor
the team’s performance

By whom
Project Manager and Human Resources Department

Inputs ■ Time Management Plan (resource requirements)


■ Roles & Responsibilities
■ Organisational Charts
■ Staff Assignments
■ Work Performance Information
■ Performance Reports
■ Project Governance Guidelines
■ Approved Change Requests

Tools and Techniques ■ Human Resource Planning – Networking, both within Mott
MacDonald, wider industry and client/partner organisations to
understand staffing management options. Use in-house
organisational charts and job descriptions to formulate the
team
■ Acquire Project Team – Working with HR and other managers
within Mott MacDonald/Client/Partner/Consultants and the
wider industry to acquire the right resources for the project.
■ Develop Project Team – Formulating the training plan, team
building and recognition and rewards that will motivate the
project team
■ Manage Project Team - Managing the team through
observation and performance appraisals. Resolving conflicts
and recording issues in the HR records.

4.13 Issue 2.1 - October 2009 MAX/OTC/PF/003/02


Project Management Manual – recommended practice

Process

c Plan the Approach to Human Resource Management


Detail the roles and responsibilities of the project team members,
including any authority and tolerance levels. Produce the project
organisation chart.

d Put the Project Team Together


Select team members with the right mix of skills to achieve the
project objectives. Take account of any personal circumstances
that may affect their performance and ultimately the project’s
goals.

e Develop the Team


Develop the training, team building and rewards/recognitions
activities. Consider things like co-location. Carry out regular
assessment to measure the team’s effectiveness.

f Manage the Project Team


Ensure regular appraisals are carried out, resolve conflicts without
disrupting the project work, record issues in the HR records.

An overview of the process is shown in Figure 17 below.

Location Resource
histograms

Composition
Resource table
Stakeholder
Influences
HR
Management Lessons Learned
1) HR Planning
Plan
Organisation Chart

Roles and Responsibility


Resonsibilities Assigned Matrix

2/3) Acquire & Section 5) Direct &


Develop Project Team Manage Project
Execution

4) Manage Project Section 5) Direct &


Team Manage Project
Execution

Figure 17 Human Resources Management Plan

Outputs
 ■ Human Resources Management Plan
■ Staffing Management Plan
(016)

■ Project Responsibilities Matrix


■ Project Organisation Chart

4.14 Issue 2.1 - October 2009 MAX/OTC/PF/003/02


Project Management Manual – recommended practice

4.1.6 Communications Management Plan

Outline The Communications Management Plan details the requirements


for ensuring that the generation, collection, distribution, storage,

“ Provides the processes for


ensuring the link between
people and information is
available for successful
communications.
retrieval and disposal of project information is carried out in a
timely manner. It provides the processes for ensuring the link
between people and information is available for successful
communications.

When
” This process is developed in the early stages of the project to
ensure everyone involved understands the lines and methods of
communication.

By whom
Project Manager

Inputs ■ Time Management Plan (resource requirements)


■ Roles & Responsibilities
■ Organisational Charts
■ Staff Assignments
■ Work Performance Information
■ Performance Reports
■ Project Governance Guidelines
■ Approved Change Requests

Tools and Techniques ■ Communications Planning – Using requirements analysis and


detailing the communications technology to be used.
■ Information Distribution – Identifying the communication skills
of the project team. Using systems for gathering and retrieval
of information. Developing distribution methods for all key
project outputs.
■ Performance Reporting – Identifying presentation tools,
dashboard reports etc. Carrying out regular status review
meetings. Using common time and cost reporting systems.
■ Managing Stakeholders – Ensuring stakeholder
communications are effective and record and deal with issues.

Process

c Plan Communications Management


Carry out a stakeholder management workshop to understand
stakeholder communications requirements. Decide how this
information will be transmitted and received.

4.15 Issue 2.1 - October 2009 MAX/OTC/PF/003/02


Project Management Manual – recommended practice

d Decide on Distribution Methods


Set up a document management system to facilitate retrieval and
storage of project information. Decide the format of information to
be disseminated.

e Decide how Performance will be Reported


Set up reporting systems and meeting schedules. Decide on how
information will be presented.

f Manage the Stakeholders


Regularly check that stakeholder communications are effective.
Resolve any issues quickly, they do not go away.

An overview of the process is shown in Figure 18 below.

Frequency

How will it be
communicated
Stakeholder
requirements Stakeholder
Workshop Who will receive it
Who is responsible
Organisational for communicating
Process assets Procedures information

Guidelines What information,


content and format
Communications
Lessons Learned Equipment

Enterprise Client Structure &


1) Communications Environmental
Planning Culture
Comms. Factors
Management Government &
Plan Industry Standards
2) Information Section 5) Direct &
Distribution Manage Project Project
Execution Management
Information
Systems
3) Performance Section 6) Monitor &
Reporting Control Project Work

4) Managing Section 6) Monitor &


Stakeholders Control Project Work

Figure 18 Communications Management Plan

Outputs
 ■ Communications Management Plan
■ Stakeholder Analysis
(017)

■ Project Reports
■ Meetings Calendar
■ Meeting Agenda & Minutes
■ Document Control

4.16 Issue 2.1 - October 2009 MAX/OTC/PF/003/02


Project Management Manual – recommended practice

4.1.7 Risk Management Plan

Outline Risk management is about managing uncertainty, both the threats


to the project objectives, as well as the opportunities for
increasing the chances of achieving these objectives. A risk can

“ Risk management is about


managing uncertainty, both in
relation to threats and
opportunities
have more than one cause and more than one impact. Project
risk management is about planning, identifying, analysing,
responding, monitoring and controlling risk and opportunity


throughout the project lifecycle.

When This process is developed in the early stages of the project to


identify those risks that may have a positive or negative impact on
the project

By whom
Project Manager with risk manager (where available)

Inputs ■ Project Management Plan (Cost, Schedule and Quality)


■ Project Scope Statement
■ Risk Register
■ Project Governance Guidelines

Tools and Techniques ■ Risk Planning – Understanding client’s attitude to risk, the risk
roles and responsibilities and what methodology that will be
used.
■ Risk Identification – Identifying risks through brainstorming,
interviews, cause and effect, SWOT, root cause identification
and historical data.
■ Qualitative Risk Analysis – Using risk and probability impact
assessments and matrices to understand their possible
impact. Assessing the quality of the data, the risk urgency,
then categorising the risks.
■ Quantitative Risk Analysis – Using modelling and data
assessment techniques as appropriate.
■ Risk Response – Deciding on the risk and opportunity
response strategy to be employed such as introducing risk
contingency reserves to respond to perceived threats;
contingency is subject to the Project Board approval.
■ Risk Monitoring & Control – Carrying out risk reviews and
audits, performing trend analysis, measuring technical
performance and reviewing contingency reserves.

4.17 Issue 2.1 - October 2009 MAX/OTC/PF/003/02


Project Management Manual – recommended practice

Process

c Compile the Risk Management Plan


Include the definition of risk, methods to be used, roles and
responsibilities, risk budget, how risks will be tracked and
reported. Determine the probability and impact scales to be used.

d Identify the Risks


Carry out a risk workshop together with interviews and other
techniques to identify risks and then record them in the risk
register.

e Carry out Qualitative Risk Analysis


Using the scaling agreed in Step 1, assess the risks/opportunities
and record results in the risk register.

f Carry out Quantitative Risk Analysis


Subject those high risks identified in Step 3 to further analysis to
understand the potential effect on cost and schedule. Record
results in the risk register.

g Risk Response
Decide on the response to the risks identified and record in the
risk register.

h Monitor and Control the Risks


Carry out regular reviews of the risks and update the risk register
with any changes identified. Manage the risk contingency.

An overview of the process is shown in Figure 19 below.

4.18 Issue 2.1 - October 2009 MAX/OTC/PF/003/02


Project Management Manual – recommended practice

Risk Attitude

Roles &
Historical Data
Responsibilities

Cause & Effect


1) Risk Planning Diagrams
Methodology

SWOT Analysis
Other Identification
Techniques
Root Cause
2) Risk
Identification
Identification Risk Workshop

Inteviews Pre Definition


Risk Report Risks
Management Risk Register
Plan
3) Qualitative Risk Plot Probability
Analysis
Risk Matrix
Plot Impact

Sensitivity
Analysis
Expected Monetary Avoid
Value
4) Quantitative Risk Three Point Transfer
Analysis Estimating Threats
Desision Tree Mitigate
Analysis
Monte-carlo
Simulation
Exploit
5) Response
Planning Opportunities Share
Association Line

Enhance
6) Risk Monitoring &
Section 6) Monitor &
Control Control Project Work

Figure 19 Risk Management Plan

Outputs
 ■ Risk Management Plan (018)
■ Risk Management Procedure
■ Risk Register
■ Risk Identification Pro-forma

4.19 Issue 2.1 - October 2009 MAX/OTC/PF/003/02


Project Management Manual – recommended practice

4.1.8 Issues Management Plan

Outline Issues can arise from any aspect of a project and need to be
effectively managed in order to prevent or minimise their impact
on a project’s delivery.

“ The Issues Management Plan


defines a process for dealing
efficiently with unexpected
occurrences
The Issues Management Plan defines a process for dealing
efficiently with unexpected occurrences. This process needs to
clarify how issues are identified, assessed, and a course of action


developed to resolve them. The responsibilities of ownership and
resolution of issues needs to be determined.

When This process is developed in the early stages of the project to


establish a process for identifying and managing issues.

By whom
Project Manager with Risk Manager (where available).

Inputs ■ Project Management Plan (Cost, Schedule and Quality)


■ Project Scope Statement
■ Project Governance Guidelines
■ Risk Management Plan

Tools and Techniques ■ Expert judgement


■ Project Management processes: as set down in this manual

Process

c Issue Identification, Recording & Assessment


Develop a process that defines how issues which cannot be
resolved by day-to-day management are captured and recorded
on a Project Issues Log. These issues need to be reviewed in
order to assess their potential for disrupting the progress of the
project.

d Issue Resolution
Note: Issues Develop a process for resolving those issues that have been
management is taken identified as damaging to the project. This process involves
from the APM-BOK as assigning ownership of each issue and for assigning responsibility
it is not specifically for managing the resolution. Where a resolution strategy involves
described by PMI-BOK a significant change to the way a project is being implemented, or
requires urgent executive attention, then a governance
escalation policy needs to have been developed.

4.20 Issue 2.1 - October 2009 MAX/OTC/PF/003/02


Project Management Manual – recommended practice

Outputs
 ■ Issues Management Plan
■ Issues Log
(020)

4.21 Issue 2.1 - October 2009 MAX/OTC/PF/003/02


Project Management Manual – recommended practice

4.1.9 Procurement Management Plan

Outline The Procurement Management Plan sets out the processes


required to acquire the products and services required from
outside the project team to perform the required work. It includes

“ There is an important link


between procurement strategy
and scope/WBS planning
the procurement strategy to be used, details how suppliers (or
contractors) will be selected and appointed, and how the various
contracts will be administered.

When
” This process is used to determine the contractual approach to the
project and the management of contracts.

By whom Project Manager and commercial manager (if available), with


contract terms and conditions overseen/supported by legal and
procurement specialists.

Inputs ■ Project Management Plan (Cost, Schedule and Quality)


■ Project Scope Statement
■ WBS
■ Project Governance Guidelines

Tools and Techniques ■ Acquisition Planning – ‘Make or Buy’ analysis, selecting


contract types and expert judgement on contracting are all
used.
■ Contract Planning – Use the client’s commercial management
processes if available or seek advice from Project Team and
legal specialists.
■ Request Suppliers Responses – Use advertising, in-house
qualified supplier lists and contractor meetings.
■ Select Suppliers – Use evaluation techniques such as
independent estimating, rating systems, screening, weighting,
negotiation and expert judgement.
■ Contract Administration – use performance reviews,
inspections, audits, payment systems, change control and a
system for claims administration.

Process

c Plan the Acquisitions


Decide whether the work will be done by the client’s framework
suppliers or by contractors identified by open tendering. Consider
the best type of contract for the circumstances, e.g. one that will
have an appropriate amount of risk exposure.
d Plan the Contracting Approach

4.22 Issue 2.1 - October 2009 MAX/OTC/PF/003/02


Project Management Manual – recommended practice

Use standard contracts where possible to reduce any possible


ambiguity.

e Request Tender Pre-qualification Responses


Submit project requirements to the marketplace for response,
either through general advertising or the use of a more selective
approach by using qualified supplier lists or contractor meetings.

f Select the Preferred Suppliers


Put a robust and transparent system of selection in place. Use
techniques that are fully documented and meet both corporate
and regional governance requirements.

g Administer the Contract


Put in place an audit and inspection regime that will be based on
performance. Consider linking part of the supplier’s payment to
performance (i.e. meeting time/cost/quality targets).

h Close the Contract


Ensure that all the requirements of the project have been met and
the project can be closed. Record the successes and failures in
the Project Closure Report for future reference

An overview of the process is shown in Figure 20 below.

In-house
Deliverables
Traditional
Fixed Price, Lump
Sump
Make
Design & Build
1) Plan Purchases
& Acquisitions
Time & Material
Buy
Contract
Construction
Management
Cost Reimbursable
Evaluation Criteria

Procurement Management
Management Prepare Statement of Work
2) Plan Contracting Procurement
Plan Documents Provide Sufficient
Information to allow
What the Project
the supplier to
Team will deliver
respond
3) Request Supplier Section 5) Direct &
Manage Project How the contract
Response
Execution will be managed

Section 5) Direct &


4) Select Suppliers Manage Project
Execution

5) Contract
Section 6) Monitor &
Administration Control Project Work

Section 7) Close
6) Contract Closure Project

Figure 20 Procurement Management Plan

4.23 Issue 2.1 - October 2009 MAX/OTC/PF/003/02


Project Management Manual – recommended practice

Outputs
 ■ Procurement Management Plan (019)

■ Procurement Documents Checklist


■ Evaluation Criteria Approval Checklist
■ Contract Documentation
■ Award Recommendation Form

4.24 Issue 2.1 - October 2009 MAX/OTC/PF/003/02


Project Management Manual – recommended practice

5 Execution Process Group


The Executing Process Group is concerned with carrying out the works defined in the Programme
Management Plan (PgMP) and its subsidiary plans to achieve the programme outcomes.

5.1 Direct & Manage Project Execution


Outline The process uses the scope defined in the Programme Brief as a
baseline then ensures that any changes or corrective actions
required are approved then implemented. The process integrates

“ The process integrates the


projects, people and other
resources necessary to carry
out the programme
the projects, people and other resources necessary to carry out
the programme in accordance with the PgMP to ensure that
governance, benefits realisation, stakeholder management and

” management of finance is effectively carried out.

Figure 21 Direct & Manage Programme Execution

When These processes are used to manage programme work from the
end of the planning phase to the closure of the programme.

By whom Programme Manager supported by the PMO.

Inputs • Programme Management Plan


• Client’s governance guidelines
• Legal & environmental factors
• Regulatory requirements

Tools and Techniques • Programme Management processes: as set down in this


manual
• Expert judgement
• Techniques as set down in this Manual

Process

c Assemble the Project Team


Put together the project team with the right skills for the work in
hand.

5.1 Issue 2.1 - October 2009 MAX/OTC/PF/003/02


Project Management Manual – recommended practice

d Develop the Project Team


Build team cohesion to enhance their performance.

e Information Distribution
Ensure that information is distributed to stakeholders in a timely
manner using the methods of communication agreed in the
stakeholder management process. Ensure the project records are
managed through the established document management system
to provide configuration control.

f Request Bidder Responses


Obtain information, quotations, bids offers or proposals from
potential suppliers.

g Select Supplier(s)
Review the offers, select the preferred supplier then negotiate a
contract for the work.

h Perform Quality Assurance


Ensure all processes are in place to meet the project
requirements such as inspections, audits, deliverable reviews, etc.

i Direct & Manage Project Work


Ensure the technical and organisational resources execute the
work in line with the processes defined in the PMP. Ensure the
deliverables are produced according to the PMP and information
on these deliverables and the work needed to produce them are
input into the performance reporting process.

An overview of the process is shown in Figure 22 below.

5.2 Issue 2.1 - October 2009 MAX/OTC/PF/003/02


Project Management Manual – recommended practice

1) Acquire Project Negotiating project


Team team members

Has Staff movement


plan been prepared
Human Resource
Management
Have Staff
Assignments been
2) Develop Project
sent out
Team
Regular meetings
Has the requirement
Team building for consultants/
Implementing contractors been
Corrective actions considered
7) Direct & Manage Training requirements
Project Work
Direct & Manage Project Implementing Change Project Gound Rules
Execution Requests
Co‐location of team
Organizational
Quality Management Staff Recognition Improvements
Technical
6) Quality Assurance
Problems and
Monitoring Quality Process Analysis constraints
Communications against the plan Root Cause Analysis
Management
Quality Audits Random
3) Information
Distibution
Scheduled
Procurement
Management

5) Select Suppliers
Supplier Evaluation
Contract Negotiations
4) Request Bidder
Association Line Responses Contract award
List of Potential
Bidders
Pre bid meeting
Bidder Shortlist

Figure 22 Directing & Managing Work

Outputs
 ■ Clear understanding of project scope and quality
requirements.
■ Informed and well coordinated project team.
■ Informed and supportive stakeholders.
■ Committed suppliers with a proper understanding of their
contractual liabilities.
■ Adequate resources to ensure efficient completion of the
project.
■ Comprehensive records of the execution process to allow
future audit as may be required by the client.
■ Project outputs delivered successfully in accordance with PMP
and the Project Charter.

Next Steps Once the coincident processes of Execution and Monitoring &
Controlling are completed then the project can move onto the
Closing process group.

5.3 Issue 2.1 - October 2009 MAX/OTC/PF/003/02


Project Management Manual – recommended practice

6 Monitoring & Controlling Process Group


The Monitoring and Controlling Process Group contains those continuous processes
required to monitor performance, anticipate problems and take corrective action when
required.

6.1 Monitor & Control Project Work


Outline Monitoring is performed during project execution to provide early
indication as to whether corrective or preventative actions are

“ Monitoring is performed required. The project activities are monitored against the PMP
and performance baseline to identify possible variances in order
during project execution to to bring them back in line with the goals of the PMP. It also seeks
provide early indication as to control the changes to the project to ensure that only approved
changes are implemented. When variances result in changes to
to whether corrective or the project objectives the appropriate Project Management
preventative actions are process or processes within the planning group are updated within
the PMP. These variances can result in changes to resources,
required budget or schedule objectives.

Figure 23 Monitor & Control Project Work

When These processes are used to monitor and control project work
from the planning phase to project close.

By whom
Project Manager

Inputs ■ Project Management Plan


■ Client’s commercial processes
■ Project Governance Guidelines

6.1 Issue 2.1 - October 2009 MAX/OTC/PF/003/02


Project Management Manual – recommended practice

Tools and Techniques ■ Outlined in Project Management Plan

Process

c See following subsections

Outputs
 ■ Scope Management
■ Schedule Control
■ Cost Control
■ Quality Control
■ Human Resources Management
■ Communications Management
■ Risk Control
■ Contract Administration
■ Change Control
■ Issue Management Process

Next Steps Once the coincident processes of Execution and Monitoring &
Controlling are completed then the project can move onto the
Closing process group.

6.2 Issue 2.1 - October 2009 MAX/OTC/PF/003/02


Project Management Manual – recommended practice

6.1.1 Scope Management

Process

c Verify the Project Deliverables


Introduce a formal method of acceptance for project deliverables.
Consider a validation and verification process that accepts
deliverables as soon as they are complete.

d Monitor the Project Schedule


Constantly monitor the schedule to identify any potential out of
scope activities.

e Control Changes to Project Scope


Ensure any changes to the project scope are documented and
controlled through configuration control and change control
systems.

An overview of the process is shown in Figure 24 below.

Figure 24 Scope Management

6.3 Issue 2.1 - October 2009 MAX/OTC/PF/003/02


Project Management Manual – recommended practice

6.1.2 Time Management

Process

c Monitor Schedule Performance


Consider the use of earned value management and forecasting to
measure schedule performance. Compare target dates with
actual and forecast dates to detect any deviations. Use
comparison bar charts on the schedule to monitor planned work
with actual work performed.

d Control Updates Through Progress Reports


Use a common template for progress reporting to ensure
consistency.

An overview of the process is shown in Figure 25 below.

Figure 25 Time Management

6.4 Issue 2.1 - October 2009 MAX/OTC/PF/003/02


Project Management Manual – recommended practice

6.1.3 Cost Management

Process

c Monitor Costs Against the Cost Baseline


Consider using earned value management to monitor project
costs against the baseline. Use forecasting to monitor future
project costs and cash-flow.

d Action Changes Through the Change Control System


Only implement cost changes approved through the change
control system.

An overview of the process is shown in Figure 26 below.

Cost Baseline

Comparision of planned work, the


1) Costs are actual cost of that work and what
monitored against Earned Value work was actually accomplished
the Cost Baseline Cost &
Management
Performance
Report

Cost Cost Control


Management Forecasting
Used to predict Estimate to
2) All cost changes Complete activity, work package &
are actioned Estimate at Completion
through the Change
Control System

Figure 26 Cost Management

6.5 Issue 2.1 - October 2009 MAX/OTC/PF/003/02


Project Management Manual – recommended practice

6.1.4 Quality Management

Process

c Carry out Quality Audits


Put an audit plan in place to monitor the delivery of the project
requirements. Carry out unscheduled audits to monitor
performance.

d Put an Acceptance Testing Regime in Place


Decide the quality control measurements to be used. Put in place
processes to monitor corrective actions and defect repair.

Plan a Systematic Validation and Verification


e
Process
Plan the processes by which compliance to the quality standards
will be verified. Plan the validation required for acceptance of
deliverables.

An overview of the process is shown in Figure 27 below.

Control Charts

Flowcharts
Monitors results for Quality Control
compliance to Tools
3) Verification & quality standards
Validation set Histograms

Quality Quality Control


Pareto Charts
Management Planned
1) Quality Audits

Unplanned Scatter Diagrams


2) Acceptance
testing
Run Charts, etc
Corrective action
process Cause & Effect
Diagrams

Figure 27 Quality Management

6.6 Issue 2.1 - October 2009 MAX/OTC/PF/003/02


Project Management Manual – recommended practice

6.1.5 Human Resources Management

Process

c Set up a Performance Monitoring Regime


Carry out performance appraisals at regular intervals to monitor
the team’s performance.

d Manage the Reporting Chain Interfaces


Manage the interface for team members with a dual reporting
chain.

e Manage Conflict
Reduce the possibility of conflict by ensuring that good lines of
communications are open. Ensure project team roles are clearly
defined.

f Staffing Issues
Record all issues in the HR records. Record changes to the
project team through the change control system.

An overview of the process is shown in Figure 28 below.

Figure 28 Human Resources Management

6.7 Issue 2.1 - October 2009 MAX/OTC/PF/003/02


Project Management Manual – recommended practice

6.1.6 Communications Management

Process

c Manage Stakeholders
Ensure communications are in place to satisfy stakeholder
requirements and resolve any issues. Ensure all stakeholder
issues have a nominated owner together with a resolution date.

d Report Project Performance


Decide on the project metrics to be used. Decide on the methods
of collection and distribution of performance information.

An overview of the process is shown in Figure 29 below.

Issue Owner

Resolution Date
Stakeholder Issues

Cost
1) Stakeholder
Management
Actions

Quality

Comms. Resource
Management
Performance
Scope
Metrics Future Performance
Time Forecasts
2) Performance
Reporting

Recommended
Corrective Actions

Reporting Formats Lessons Learned

Approved Changes

Figure 29 Communications Management

6.8 Issue 2.1 - October 2009 MAX/OTC/PF/003/02


Project Management Manual – recommended practice

6.1.7 Risk Management

Process

c Carry out Regular Risk Reviews


Review the Risk Register on a regular basis and record any
changes. Ensue risk contingency is controlled and risk responses
monitored to ensure their continued effectiveness.

d Identify any New Risks


Encourage project members to report anything they consider as a
risk.

An overview of the process is shown in Figure 30 below.

Record Changes

Monitor Risk
Contingency
1) Carry out regular
risk reviews
Review Risk
Risk Monitoring & Responses
Risk Control
Management
2) Identification of
new risks Risk Audits

Figure 30 Risk Management

6.9 Issue 2.1 - October 2009 MAX/OTC/PF/003/02


Project Management Manual – recommended practice

6.1.8 Procurement Management

Process

c Carry out Inspections and Audit


Review supplier performance through inspections and audits as
defined in the contract.

d Carry out Performance Reviews


Regularly review supplier’s performance to see if control
measures are required to make adjustments. Note that
performance could be either successes or failures.

e Record all Correspondence


Keep a record of all correspondence. Make written records of all
oral communications on contractual matters.

f Manage Contract Claims


Manage claims arising under the contract in accordance therewith
and control through the change control process.

g Authorise Payments
Authorise payments as per the contract.

An overview of the process is shown in Figure 31 below.

Figure 31 Procurement Management

6.10 Issue 2.1 - October 2009 MAX/OTC/PF/003/02


Project Management Manual – recommended practice

6.1.9 Change Control

Process

c Identification
Identify that a change is needed either as a result of an
opportunity for the client to improve the project or as a result of a
change in circumstances which require a change to ensure the
completion of the project.

d Change Review and Approval


Analyse the identified changes to ensure that the revisions to the
project’s scope, cost, budget, schedule and quality requirements
are understood. Assemble/coordinate change requests and
recommend corrective and preventative actions that are
necessary to ensure the completion of the project. Changes to be
presented to and approved by the Project Board.

e Managing the Changes


Control the flow of change requests. Instruct the Project Team to
implement the approved changes to the project’s revised scope,
cost, budget, schedule and quality requirements. Ensure only
approved changes are incorporated into project products or
services.

f Maintain the Project Baselines


Ensure baseline integrity is maintained by updating the approved
project scope, programme, budget and risk schedule.

An overview of the process is shown in Figure 32 below.

6.11 Issue 2.1 - October 2009 MAX/OTC/PF/003/02


Project Management Manual – recommended practice

Opportunity to
improve project

Change in client Change in business


requirements need

1) Identification
Response to
unforeseen or
contingency event

Change in project
circumstances Response to
identified risk event

Establish impact on
scope and quality

2) Change review & Establish impact on Submission to


approval programme Project Board

Change Establish impact on


Control cost Negotiate/agree
cost and
programme impact
of change with
suppliers
3) Managing
approved changes Instruct project
team

Devise revised
requirements from
suppliers

Update project
scope

4) Maintaining Update project


integrity of the budget Establish new
baseline project baseline
Update project
programme

Update risk register

Figure 32 Change Control

6.12 Issue 2.1 - October 2009 MAX/OTC/PF/003/02


Project Management Manual – recommended practice

6.1.10 Issues Management

Process

c Identification and Recording


Issues (any threat to the project objectives which cannot be
resolved by the Project Manager) can be identified at any stage of
a project and should be recorded on the project Issue Log.

d Review and Assessment


Analyse identified issues to assess the threat that they pose to the
project’s scope, budget, schedule and quality requirements are
understood.

e Escalate Appropriately
Assemble all information relating to each issue and present to the
Project Sponsor and Project Board for their review and action.
Project Manager to ensure that all escalated issues are addressed
appropriately, however, only approved actions are to be
undertaken.

f Manage Response
Note: Issues Ensure that approved actions are undertaken in response to
management is taken project issues.
from the APM-BOK as it
is not specifically An overview of the process is shown in Figure 33 below.
described by PMI-BOK

1) Identify and Record issues on


Record project Issue log

Review all
information relating Budget
to each issue
2) Review and
assess Schedule
Assess the potential
Issues impact of the issue
Management Scope
Submission to
3) Escalate Project Sponsor and
Appropriately Project Board Quality

4) Manage Implement agreed


Response actions and monitor

Figure 33 Issues Management

J
6.13 Issue 2.1 - October 2009 MAX/OTC/PF/003/02
Project Management Manual – recommended practice I P E M C
Closing

7 Closing Process Group


The Closing Process is the final phase of the Project Integration Management process.

7.1 Close Project


Outline The project or project phase closes when all the objectives
contained within the PMP have been achieved and all the
deliverables have been formally accepted by the End User so that
the Project Board can declare the project or project phase closed.
This forms the last Process Group within the overall Project
Integration Management process, as set out in Figure 34 below.

Figure 34 Close Project

“ It is the duty of the Project


Manager to demonstrate to the
Project Sponsor and Board that
It is the duty of the Project Manager to demonstrate to the Project
Sponsor and Project Board that the PMP has been delivered and
that project closure has been implemented.
Project closure is the handover to the End User and involves two
the PMP has been delivered key elements; administrative closure and contract closure.
and that project closure has Administrative closure requires production of a Closedown Report
which will include remedial actions, warranty periods,
been implemented.
recommendations for future work, etc.

” Contract closure deals with those activities required to bring the


contract to an orderly close. Identify open issues and future
arrangement for management of closure. This may be sometime
after administrative closure especially if there are unresolved
claims issues.

When This process is used to close the project or project phase

By whom
Project Manager

Inputs ■ Project Charter


■ Project Management Plan
■ Contract Documentation

7.1 Issue 2.1 - October 2009 MAX/OTC/PF/003/02


Project Management Manual – recommended practice I P E M C
Closing

■ Project Governance Guidelines

Tools and Techniques ■ Expert judgement

Process

c Bring the Project to Administrative Closure


Ensure all the project objectives have been met and the project
deliverables have been accepted. Confirm the operational and
support arrangements in place. Document the lessons learned,
archive all records and produce a Close Down Report. Seek
project closure from the Project Board based on an End User
Acceptance Statement.

d Bring the Contract to a Close


Agree the resolution of any open issues and settle contract.
An overview of the process is shown in Figure 35 below.

Lessons Learned

Follow‐on actions
1) Administrative
Closure Close Down Report Are the arrangements
for operations and
support in place

Have all the


End Users acceptance deliverables been
Close Project statement accepted

Review completion
against Project
2) Contract Closure
Charter
Bringing Contract to
an orderly close
Archiving Project
Records

Post Project Review

Figure 35 Project Closure

Outputs
 ■ Close Down Report (021)

■ Lessons learned
■ End User Acceptance Statement
■ Contract Closure

7.2 Issue 2.1 - October 2009 MAX/OTC/PF/003/02


tabs.qxp 21/10/2009 09:29 Page 3

3. Project
Governance
Guidelines

Project Goveranance
Guidelines
Project Governance
Guidelines
Project Governance – Guidelines

Pathfinder

Project Governance
guidelines
January 2009

MAX/OTC/PF/004

Issue and Revision Record


Rev Date Originators Editor Checker Approver Description
G Williams

M Wallace M Carden D Phillips First formal


1.0 15-01-09
D Woolven issue.

This document has been prepared for the Mott MacDonald accepts no
titled purpose and should not be relied responsibility or liability for this document
upon or used for any other purpose without to any party other than the person by
an independent check being carried out as whom it was commissioned.
to its suitability and prior written authority
of Mott MacDonald being obtained. Mott To the extent that this document is based
MacDonald accepts no responsibility or on information supplied by other parties,
liability for the consequence of this Mott MacDonald accepts no liability for
document being used for a purpose other any loss or damage suffered, whether
than the purposes for which it was contractual or tortious, stemming from
commissioned. Any person using or relying any conclusions based on data supplied
on the document for such other purpose by parties other than Mott MacDonald
agrees, and will by such use or reliance be and used by Mott MacDonald in
taken to confirm his agreement to preparing this document.
indemnify Mott MacDonald for any alleged
loss or damage resulting therefrom.

Mott MacDonald, Mott MacDonald House, 8-10 Sydenham Road, Croydon, CR20 2EE
T +44 (0)20 8774 2000
F +44 (0)20 8681 5706

ii Issue 1.0 - January 2009 MAX/OTC/PF/004/01


Project Governance – Guidelines

Preface
These Project Governance Guidelines are aimed at assignments undertaken by
Mott MacDonald where staff are providing a project management service direct
to the client e.g. acting as Project Managers. Its purpose is to explain good
practice in respect of Project Governance. It gives clients confidence in the
quality of the service, being based on internationally recognised best practice.

The Project Governance Guidelines complement the Project Management


Manual and are not mandatory, however, a Project Manager should expect to
operate within a client environment where a governance structure in line with
these guidelines is present. Where this is not the case then the guidelines will
allow the project manager to discuss with the client the need or otherwise for
additional processes and controls.

iii Issue 1.0 - January 2009 MAX/OTC/PF/004/01


Project Governance – Guidelines

Chapters

1 Introduction 1.1
1.1 Objective 1.1
1.2 Purpose 1.1
1.3 Scope 1.1

2 Project Governance 2.1


2.1 Project Sponsor 2.1
2.2 Project Board 2.1
2.3 Project Life Cycle and Funding Process 2.2

3 Roles & Responsibilities 3.1


3.1 Project Sponsor 3.1
3.2 Project Board 3.2
3.3 Project Manager 3.3

iv Issue 1.0 - January 2009 MAX/OTC/PF/004/01


Project Governance – Guidelines

1 Introduction
1.1 Objective
The objective of the Project Governance Guidelines is to set out
simple good practice with regard to governance and oversight of
projects.

1.2 Purpose
These guidelines are to help Mott MacDonald staff, undertaking
Project Management assignments on behalf of clients, to
understand the governance structure in which they might be
expected to operate.

1.3 Scope
The Project Governance Guidelines complement the Project
Management Manual and are not mandatory, however, a Project
Manager should expect to operate within a client environment
where a governance structure in line with these guidelines is
present. Where this is not the case then the guidelines will allow
the project manager to discuss with the client the need or
otherwise for additional processes and controls.

1.1 Issue 1.0 - January 2009 MAX/OTC/PF/004/01


Project Governance – Guidelines

2 Project Governance

2.1 Project Sponsor


All projects require a ‘Sponsor’ to ensure that the outturn of the

“ All projects require a project matches the approved brief in terms of its intended output
and the parameters set for time, cost and quality. The client
Sponsor should appoint a Project Sponsor to act on its behalf in overseeing

” the project day to day activities.


So as to facilitate the efficient implementation of the project the
client will delegate levels of authority to the Project Sponsor, who
may in turn delegate levels of authority to the Project Manager.
It is the responsibility of the Project Sponsor to ensure that
corporate governance checks and balances are applied to the
Project Manager and his team. The sponsor should also ensure
that a Project Board is established.

2.2 Project Board


The Project Board will be the group responsible for the initiation
and strategic direction of the project. The Project Board will act

“ The Project Board will


act collectively as the
owner of the project…
collectively as the owner of the project and is chaired by a
representative of the client. The Project Board sanctions the start


of the project authorises changes and accepts closure of the
project.
Given the need to ensure the active involvement of key
stakeholders the Project Board should be structured so that all of
the important functions of the client and key stakeholders are
represented on the Board.
The Project Board needs to be appointed no later than the
finalisation of the Project Charter so as to review the outline
definition of the project and to consider and authorise
development of the Preliminary Scope Statement on the basis of
agreement as to:
■ The main benefits
■ The likely cost
■ The proposed start date and duration.

2.1 Issue 1.0 - January 2009 MAX/OTC/PF/004/01


Project Governance – Guidelines

2.3 Project Life Cycle and Funding Process

Figure 1 Project Life Cycle and Funding process

The project life cycle and funding process is shown in Figure 1.


This describes the integrated process flow required to ensure a
structured approach to project management and It illustrates the
necessary steps and the funding process to be followed to
authorise and deliver a project.

2.2 Issue 1.0 - January 2009 MAX/OTC/PF/004/01


Project Governance – Guidelines

3 Roles & Responsibilities


The following job descriptions relate to the principal parties to a project.

3.1 Project Sponsor


Role ■ Initiates the Project Charter.
■ Arranges for the Project Board to be established.
■ Oversees the progress of the project and reacts to any
strategic issues.

Responsibilities ■ Overall direction of the project.


■ Coordinating End-User requirement (project output)
■ Contributing to strategy, policy and procedure.
■ Budgetary control of the project.
■ Driving and managing organisational change.
■ Communicating with key stakeholders.
■ Managing and leading the client’s staff.
■ Acts as the champion of the project within the client
organisation.

3.1 Issue 1.0 - January 2009 MAX/OTC/PF/004/01


Project Governance – Guidelines

3.2 Project Board


Role ■ The group responsible for setting the strategic direction of the
project.
■ Members of the Project Board are appointed by the client but
should include the Project Sponsor and the Project Manager
■ The Project Board sanctions the start of the project, authorises
changes and accepts closure of the project.
■ The Project Board ensures the active involvement of key
stakeholders and other client support functions
■ The Project Board will appoint the Project Sponsor as its
representative to act on its behalf on a day to day basis.
■ The Project Board will delegate levels of authority to the
Project Sponsor and Project Manager.

Responsibilities ■ Monitors compliance with corporate policies and corporate


governance requirements.
■ Is accountable for achievement of the project’s planned
benefits.
■ Ensures resolution of issues escalated by the Project Sponsor.
■ Authorises key organisational/commercial decisions for the
project.
■ Assures availability of essential client resources for projects.
■ Approves the budget and decides tolerances.
■ Gives consent to award of contracts.
■ Ensures other client departments provide effective support to
the project as required to ensure a successful outcome

3.2 Issue 1.0 - January 2009 MAX/OTC/PF/004/01


Project Governance – Guidelines

3.3 Project Manager


Role ■ The person responsible for ensuring that the project is
delivered on time, to budget and to the required quality
standard (within agreed specifications).
■ The person responsible for leading the Project Team
■ The Project Manager ensures that the project is adequately
resourced and the project staff are sufficiently trained to carry
out their duties. The Project Manager is also responsible for
reporting project progress to the Project Board through the
Project Sponsor.

Responsibilities ■ Develops Project Charter and Preliminary Scope Statement in


liaison with the Project Sponsor
■ Prioritising Project goals with other ongoing projects (via the
Project Sponsor where necessary)
■ Ensuring adequate project staff and suppliers are available for
the execution of the project
■ Identifying project training needs.
■ Managing and leading the project team.
■ Ensuring project planning and control including the following
are introduced onto the project:
■ Developing and maintaining a detailed Project Management Plan.
■ Recording and managing project issues and escalating where
necessary.
■ Managing the project budget.
■ Providing status reports to the Project Sponsor and Project Board.
■ Resolving cross functional issues at project level.
■ Managing project change control and escalating issues where
necessary.
■ Managing project progress and performance.
■ Managing supplier input within the defined budget.
■ Assuring that the design specification receives final approval.
■ Working closely with End Users to ensure the project meets
the business needs.
■ Definition and management of the End User acceptance
programme.
■ Managing project evaluation.
■ Leading the risk management process needed to serve the
needs of the project.
■ Carrying out risk management assessments, evaluations &
identify planned responses.
■ Facilitating risk & opportunity management workshops.
■ Developing and maintain project risk registers.
■ Undertaking Project Closure Processes and liaise with End
User

3.3 Issue 1.0 - January 2009 MAX/OTC/PF/004/01


tabs.qxp 21/10/2009 09:29 Page 4

4. Programme
Management
Manual

Programme Management
Manual
Programme Management
Manual
Programme Management Manual – recommended practice

Pathfinder

Programme Management Manual


recommended practice
October 2009
MAX/OTC/PF/005

Issue and Revision Record


Rev Date Originators Editor Checker Approver Description
1.0 30-10-09 D Woolven V Hughes L Birkenhead D Phillips First formal
issue.

D Phillips

This document has been prepared for the Mott MacDonald accepts no
titled purpose and should not be relied responsibility or liability for this document
upon or used for any other purpose without to any party other than the person by
an independent check being carried out as whom it was commissioned.
to its suitability and prior written authority
of Mott MacDonald being obtained. Mott To the extent that this document is based
MacDonald accepts no responsibility or on information supplied by other parties,
liability for the consequence of this Mott MacDonald accepts no liability for
document being used for a purpose other any loss or damage suffered, whether
than the purposes for which it was contractual or tortious, stemming from
commissioned. Any person using or relying any conclusions based on data supplied
on the document for such other purpose by parties other than Mott MacDonald
agrees, and will by such use or reliance be and used by Mott MacDonald in
taken to confirm his agreement to preparing this document.
indemnify Mott MacDonald for any alleged
loss or damage resulting therefrom.

Mott MacDonald, Mott MacDonald House, 8-10 Sydenham Road, Croydon, CR20 2EE
T +44 (0)20 8774 2000
F +44 (0)20 8681 5706

MAX/OTC/PF/005/01
Programme Management Manual – recommended practice

Preface
This Programme Management Manual is aimed at assignments undertaken
by Mott MacDonald where staff are providing a programme management
service direct to the client e.g. acting as Programme Managers. It provides
guidance to staff and ensures a consistent approach. It gives clients
confidence in the quality of the service, being based on internationally
recognised best practice.

The Programme Management Manual is not mandatory. However, it is a


requirement of the Mott MacDonald QES that the method for undertaking
the services is set out in the MM Project Plan of Work (PPW), whether that
be a client mandated system (which is sometimes the case) or the Mott
MacDonald Practice. Modifications are acceptable, and should be stated in
the PPW with a rationale.

ii Issue 1.0 - October 2009 MAX/OTC/PF/005/01


Programme Management Manual – recommended practice

Chapters

1 Overview 1.1
1.1 Introduction ................................................................................. 1.1
1.2 Scope.......................................................................................... 1.1
1.3 Objectives ................................................................................... 1.2
1.4 What is a Programme? ............................................................... 1.2
1.5 What is Programme Management? ............................................ 1.3
1.6 Relationship of Projects, Programmes and Portfolios................. 1.4
1.7 Use of the Programme Management Process by Practitioners .. 1.5
1.8 Key Programme Participants ...................................................... 1.5
1.9 Programme Management Themes ............................................. 1.6
1.9.1 Governance 1.6
1.9.2 Benefits Realisation 1.7
1.9.3 Stakeholder Management 1.8
1.9.4 Funding 1.9
1.10 Universal Lessons Learnt ........................................................... 1.9
1.11 Health and Safety ..................................................................... 1.10
1.12 Environment and Sustainability................................................. 1.10
1.13 References................................................................................ 1.11

2 The Programme Management Process 2.1


2.1 Programme Integration Management – The Process Groups .... 2.1
2.2 Gateway Reviews ....................................................................... 2.2

3 Initiating Process Group 3.1


3.1 Programme Brief ......................................................................... 3.1
3.2 Programme Preparation Plan ..................................................... 3.4

4 Planning Process Group 4.1


4.1 Programme Management Plan ................................................... 4.1
4.2 Programme Governance Plan .................................................... 4.3
4.3 Programme Organisation & Resource Management Plan .......... 4.5
4.4 Monitoring, Controlling & Reporting Plan .................................... 4.7

iii Issue 1.0 - October 2009 MAX/OTC/PF/005/01


Programme Management Manual – recommended practice

4.5 Programme Risk Management Plan ........................................... 4.9


4.6 Programme Issues Management Plan...................................... 4.10
4.7 Programme Change Management Plan ................................... 4.12
4.8 Programme Benefits Realisation Plan ...................................... 4.14
4.9 Programme Scope Management Plan ...................................... 4.16
4.10 Programme QES Plan .............................................................. 4.17
4.11 Programme Schedule Management Plan ................................. 4.19
4.12 Interfaces with Other Projects ................................................... 4.20
4.13 Lessons Learnt ......................................................................... 4.22
4.14 Programme Contingency Planning ........................................... 4.24
4.15 Programme Transition Planning ............................................... 4.26
4.16 Programme Stakeholder Management Plan ............................. 4.28
4.17 Programme Funding Management Plan ................................... 4.30
4.18 Programme Cost Management Plan......................................... 4.32
4.19 Programme Procurement and Contract Management Plan ...... 4.33

5 Executing Process Group 5.1


5.1 Direct & Manage Programme Execution..................................... 5.1

6 Monitoring & Controlling Process Group 6.1


6.1 Monitor & Control Programme Work ........................................... 6.1
6.1.1 Performance Reporting 6.3
6.1.2 Scope Control 6.3
6.1.3 Schedule Control 6.4
6.1.4 Financial Management 6.4
6.1.5 Stakeholder Expectations Management 6.5
6.1.6 Risk Management 6.5
6.1.7 Procurement and Contract Control 6.6
6.1.8 Issues Management 6.6
6.1.9 Change Management 6.7
6.1.10 Governance Oversight 6.7
6.1.11 Benefits Management 6.8
6.1.12 QES 6.8

7 Closing Process Group 7.1


7.1 Close Programme ....................................................................... 7.1

iv Issue 1.0 - October 2009 MAX/OTC/PF/005/01


Programme Management Manual – recommended practice

1 Overview
1.1 Introduction
This manual provides guidance in the application of programme

“ This manual provides


guidance in the
application of programme
management techniques and acts as an aid to participants in
programmes of works involving capital projects* in understanding
the structure and implementation of a programme of works and
management
their role in ensuring its success.
techniques…

” It describes programme management processes and defines their


application so as to ensure that the outcomes and benefits of an
organisation’s strategic change are achieved. The adoption of
these processes helps ensure that effective governance and
financial control leads to the realisation of the anticipated benefits.

* It should be noted that the principles which are outlined in this manual were
developed within the context of capital programmes of work, however many of the
techniques are applicable to any other types of programmes where organisations
are seeking to achieve benefits from a strategic change to their operation.

1.2 Scope
This manual is aimed at Mott MacDonald staff who are tasked

“ This manual is aimed at


Mott MacDonald staff
who are required to
with programme management activities on behalf of a client and
has applicability across all sectors in which the Group operates. It
follows the recommendations and processes developed by the
undertake programme
American Project Management Institute [PMI] as set down in its
management activities on
Standard for Program Management (Second Edition). Further
behalf of a client …

” reference, particularly in relation to benefits realisation, has been


made to The Office of Government Commerce’s Managing
Successful Programmes (Third Edition) [MSP].

The majority of the principles of programme management are


universal and the understanding of the processes set down in this
manual will allow participants in a programme, whether in the UK,
USA, or elsewhere, to better understand what leads to a

1.1 Issue 1.0 - October 2009 MAX/OTC/PF/005/01


Programme Management Manual – recommended practice

successful outcome to a programme of works.

1.3 Objectives
This manual has been prepared to assist the Mott MacDonald
Group and its staff in:

“ A key objective is to provide


a common Mott MacDonald
approach…
■ Understanding the processes required to ensure the
successful management of a programme of works from its
inception to completion,

” ■ Providing a common Mott MacDonald approach which


staff can draw upon to develop their skills and
competence, and equip them for the programme
management role,
■ Reviewing our clients’ processes against best practice to
identify areas where enhancement would add value and
reduce risk,
■ Implementing a disciplined programme management
process, where this is part of our role, and in particular
exercising effective control of
■ Governance
■ Funding
■ Benefits Realisation
■ Stakeholders
■ Having a knowledge bank from which solutions can be
drawn.

1.4 What is a Programme?

“ A program is a group of
related projects managed in a
coordinated way to obtain
A programme comprises not just the group of related projects that
are going to deliver the outputs required by the client but also the
set of resources necessary to effectively direct and manage the
benefits and control not overall programme of works.
available from managing them
Like projects, a programme is a temporary organisational
individually.


(PMI – Standard for Program
Management)
structure but with a lifespan longer than that of individual projects.
During the life cycle of a programme, a number of projects, or
components, are defined, initiated, planned, executed, monitored
and controlled, and closed.

1.2 Issue 1.0 - October 2009 MAX/OTC/PF/005/01


Programme Management Manual – recommended practice

A programme should deliver outcomes and benefits to the client


…a set of related projects and
activities … to deliver that are greater than the sum of the outputs from individual
outcomes and benefits related projects. It is possible that some of the components of a
to the organisation’s strategic programme are business-as-usual activities of the client’s
objectives. organisation.


(OGC)


A group of related projects,….,
Definitions by PMI, OGC and APM reveal common distinctive
that together achieve a
features, namely; they are of a strategic nature, consist of related
beneficial change of a strategic
projects and deliver benefits.


nature for an organisation.
(APM)

1.5 What is Programme Management?


Projects that comprise a programme are related through having a


Program management is the common outcome or because they contribute to a collective
centralised coordinated capability. Projects that are unrelated and only deliver their own
management of a program to isolated output should be considered as being a portfolio of
achieve the program’s projects rather than a programme of works.
strategic objectives and
Programme management provides a coordinated approach to the
benefits.


(PMI – Standard for Program
Management)
outcome of related projects. It is concerned with identifying and
managing the interdependencies between related projects.
Programme management provides a level of governance that can

“ Program management provides address complexity, risk and conflicting priorities and resources
a framework for managing across the projects. It establishes a control framework that divides
related projects considering key the programme up into manageable endeavours, called projects,
factors such as strategic components or tranches.
benefits, coordinated planning,
MSP states that programme management aligns three critical
complex interdependencies,
organisational elements; corporate strategy, delivery mechanisms
deliverable integration, and
for change, and the business-as-usual environment. Programme
optimized pacing.


(PMI – Standard for Program
Management)
management balances the tension that exists between these
elements to achieve the best outcome for the client.

1.3 Issue 1.0 - October 2009 MAX/OTC/PF/005/01


Programme Management Manual – recommended practice

1.6 Relationship of Projects, Programmes and


Portfolios
PMI define a project as “a temporary endeavour undertaken to

“ In understanding program
management, it is important to
distinguish between project
create a unique product, service or result. With its management
focused on the “application of knowledge, skills, tools and
techniques to project activities” that will facilitate the successful
management, portfolio achievement of the project’s outputs.
management, and program
A programme is described as comprising “multiple related projects
management.


(PMI – Standard for Program
Management)
that are initiated during the program’s life cycle and are managed
in a coordinated fashion”. The programme management structure
applies reporting and monitoring requirements across projects and

“ The program management


structure does not involve
itself directly in the
ensures coordination. The Programme Manager retains overall
responsibility for achievement of the programme outcomes and

management of individual relies on the individual project managers for delivery of the

projects, this responsibility component parts.

being delegated to project A portfolio is a grouping of endeavours that can be projects,


managers, but is concerned programmes or indeed portfolios, and which can be either related
principally with the or unrelated to each other. They are grouped together purely in
coordination between order to have a common, coordinating management structure.
projects. Often this is a corporate organisational convenience.

” The hierarchy between portfolios, programmes and projects is


illustrated in Figure 1 below.

Portfolio

Portfolio Projects Programmes

Programmes Projects Programmes Projects Other Work

Projects Projects Projects


Figure 1 Relationship of Portfolios, Programmes, and Projects
st
Based on PMI Standard for Program Management (1 Edition)

1.4 Issue 1.0 - October 2009 MAX/OTC/PF/005/01


Programme Management Manual – recommended practice

1.7 Use of the Programme Management


Process by Practitioners
Programme management practitioners should be familiar with all

“ Practitioners should be
familiar with all
aspects of this manual
aspects of this manual as well as the other material in the
Pathfinder1 resource. However, their particular attention is drawn
to Section 2 of this manual – The Programme Management
as well as the other Process, which provides a guide as to how a programme is
material in the implemented and controlled. When charged with responsibility for
Pathfinder resource….

” programme management, these processes should be adopted to


help ensure the successful outcome of our programmes.

1.8 Key Programme Participants


This manual makes reference to a number of participants to a
programme as defined below:

■ Programme Board: The group responsible for the initiation


of a programme and for providing strategic direction during
the life of the works.
■ Programme Sponsor: The individual given the authority to
act on behalf of the Programme Board to ensure the
successful outcome of the programme.
■ Programme Manager: The individual with the overall
responsibility for the management of a programme of
works.
■ Programme Management Team: A team of staff reporting
to the Programme Manager and utilised by the Programme
Manager in delivery of the programme objectives. They
may be part time or full time, and may have other reporting
lines.
■ Programme Management Office (PMO): A unit that
provides the technical and administrative support
necessary to allow the Programme Manager to successfully
manage the programme.
It is the duty of the Programme Manager to deliver the programme
outcomes as defined by the Sponsor and a strong relationship
between these two roles is particularly important.

1
Pathfinder is the Mott MacDonald Knowledge Centre for the Project and
Programme Management Practice and is located on MiMi, the Group internet.

1.5 Issue 1.0 - October 2009 MAX/OTC/PF/005/01


Programme Management Manual – recommended practice

1.9 Programme Management Themes


A commonality emerges from programme management best
practice which distinguishes programme management from
project management, namely the pivotal importance of 4 major
themes that run throughout the whole life cycle of programmes:

■ Governance
■ Benefits realisation
■ Stakeholder management
■ Funding
These themes are instrumental in providing direction to the
management of programmes and are embedded in the
processes set out in this manual.

1.9.1 Governance
Collectively the programme management structure provides

“ Governance is the
control framework
through which
governance to programmes. Governance encompasses not just
the control and ownership of the programme, but also ensures
that the programme acknowledges the control framework of the
programs deliver their client organisation.
change objectives……


(PMI – Standard for Program
Management)
Governance also ensures that the management of the programme
adjusts to any changing organisational strategies.

Across the programme life cycle governance check-points in the


form of gateway reviews should be carried out to monitor
progress.

The management of project-related activity, which can involve


project management, programme management and portfolio
management, can only be effectively carried out when it
acknowledges the characteristics of client organisation’s
operational management, and when it fits within the client’s
strategic planning and policy (see Figure 2 overleaf)

1.6 Issue 1.0 - October 2009 MAX/OTC/PF/005/01


Programme Management Manual – recommended practice

Organisational Governance

Strategic Planning & Policy

Management by Projects

Portfolio Management

Programme
Management of Management
Operations

Project Management

Processes, Tools &


Metrics

Figure 2 Governance Context


st
Based on PMI Standard for Program Management (1 Edition)

1.9.2 Benefits Realisation


As benefits are the reasons for carrying out programmes of work


A benefit is the
then Programme Benefits Realisation must be a crucial aspect of
measurable
the programme management effort.
improvement resulting
from an outcome…. Management of benefits realisation is a process that continues

“ ”
PMI identifies a 4 stage
process involving benefits
throughout the programme life cycle. PMI identifies a 4 stage
process involving benefits identification, benefits analysis and
planning, benefits realisation and benefits transition. Benefits must
identification, benefits be clearly linked to strategic outcomes. As each project or
analysis and planning, component of the programme is initiated the benefits to be
benefits realisation and delivered by it must be clearly defined in the business case.
benefits transition.

” As individual projects are completed the actual benefits realised


should be recorded and measured against the anticipated
benefits.

1.7 Issue 1.0 - October 2009 MAX/OTC/PF/005/01


Programme Management Manual – recommended practice

Figure 3 below shows how benefits realisation maps onto the five
process groups in the life cycle of a programme.

Figure 3 Programme Benefits Management

1.9.3 Stakeholder Management


Stakeholders are defined by PMI as “those individuals or
organisations whose interests may be affected by the program

“ Stakeholder
management is an
important factor in
outcomes, either positively or negatively”. Stakeholders have a
critical influence on the outcome of programmes and, because it
cannot be assumed that they all view the programme favourably,
implementing successful their management is a major aspect of the Programme Manager’s
organisational change.


role throughout the duration of the programme. In particular
(PMI – Standard for Program existing stakeholder relationships at the start of a programme
Management)
need to be understood and accommodated.

The wider scope of programmes means that programme


stakeholder management extends beyond that usually considered
by projects; involving interdependencies between projects and
aspects wider than the client’s organisation.

Successful stakeholder engagement is essential to implementing


organisational change.

1.8 Issue 1.0 - October 2009 MAX/OTC/PF/005/01


Programme Management Manual – recommended practice

1.9.4 Funding
As the costs involved in carrying out programmes, in comparison

“ Management of the
funding throughout the
programme life cycle
to projects, is likely to be very high then it is essential to address
the overall financial environment as early in the programme life
cycle as possible.
is a core responsibility
Establishing a programme funding framework allows the client
of the Programme
organisation to be aware of the scale of monies to be expended
Manager….

” and timing of finance requirements. The Programme Manager


needs to ensure the client organisation is fully aware of its
financial obligations and exposure.

Management of funding throughout the programme life cycle is a


core responsibility of the Programme Manager.

1.10 Universal Lessons Learnt


Good programme management practice requires that lessons are

“ Part of programme
management is lessons learnt
from previous work.
learnt from previous activities and applied where relevant to the
current programme. These lessons can be at individual,
programme, organisation, sector or practice level. A good source

” at practice level comes from the body of work carried out in the
UK by the Office of Government Commerce, who have identified
seven features that characterise successful programmes (or lack
of these features is found in programmes that fail). Please refer to
the OGC website and the MSP guidance for full details of these
universal lessons, a summary of which is set out below:

■ Remaining aligned with corporate strategy - The outcomes


of a programme need to be regularly reviewed against the
developing business direction and aspirations of the client
organisation.
■ Leading change - Effective leadership is essential for the
successful delivery of a major transformational change
programme.
■ Envisioning and communicating a better future - The
Programme Manager should develop a clear vision of what the
future will be like after the delivery of the programme benefits,
and this should be communicated to the key stakeholders.
■ Focusing on the benefits and threats to them - A
programme’s success is gauged by its achievement of the

1.9 Issue 1.0 - October 2009 MAX/OTC/PF/005/01


Programme Management Manual – recommended practice

proposed benefits. An important aspect of programme


management is therefore the managing of threats which may
adversely affect benefits realisation.
■ Adding value - A programme must contribute a value that is
greater than that being provided by the individual component
projects.
■ Designing and delivering a coherent capability - A
programme needs to closely integrate component projects
towards delivering the outcomes into the client’s operations
with the minimum of disruption.
■ Learning from experience - As a programme progresses
through its life it is essential to reflect upon and take notice of
lessons being learnt from its performance.

1.11 Health and Safety


A primary responsibility of a Programme Manager is ensuring that
all aspects of the programme are carried out in a manner that
provides a healthy and safe environment for those working on the
programme and its component projects, those affected by the
programme, and those that will work or maintain the facilities
provided by the programme.

In planning and executing the programme the Programme


Manager needs to take account of:

■ The client’s Health and Safety policies and arrangements,


■ Mott MacDonald’s Health and Safety processes embedded
within the QES system,
■ Statutory regulations that pertain within the industrial sector in
which the programme is being executed,
■ Good working practices in relation to the well being and
treatment of work colleagues.

1.12 Environment and Sustainability


It is the duty of the Programme Manager to ensure that the
environment is protected from harm as a result of the activities of
the programme, and all its sub-components, during manufacture
and construction. The Programme Manager also has a
responsibility to ensure that the component project designs, once
operational, allow for environmental protection.

1.10 Issue 1.0 - October 2009 MAX/OTC/PF/005/01


Programme Management Manual – recommended practice

Similarly the Programme Manager has a duty to consider the


needs for sustainable development in bringing about the changes
required by the programme, both during the design and build
stages but also through into operation, maintenance and final
decommissioning.

In planning and executing the programme the Programme


Manager needs to take account of:

■ The client’s Environmental policies and arrangements,


■ The client’s Sustainability objectives and guidelines
■ Mott MacDonald’s Environmental management processes as
embedded with the QES system,
■ Mott MacDonald’s guidance on sustainable development on
the company intranet led by the Group Sustainability
Champion,
■ Statutory regulations that pertain within the industrial sector in
which the programme is being executed,
■ Good working practices in relation to protection of the
environment and sustainable development.

1.13 References
This manual and supporting documents adopt the processes and
terminology of the PMI as set out in:
► The Standard for Program Management, 2nd Edition, 2008.
ISBN 978-1-933890-52-4
► The Standard for Program Management, 1st Edition, 2006.
ISBN 978-1-930699-54-0
Reference has also been made to the following:
► Office of Government Commerce, Managing Successful
Programmes, 3rd Edition, 2007. ISBN: 987-0-11-331040-1
► Association for Project Management, Introduction to
Programme Management, 2007. ISBN: 978-1-903494-63-9

1.11 Issue 1.0 - October 2009 MAX/OTC/PF/005/01


Programme Management Manual – recommended practice I P E M C

2 The Programme Management Process


2.1 Programme Integration Management –
The Process Groups

“ Programmes use
processes as tools to
drive delivery forward
Programme Integration Management is an umbrella term that is
used by PMI to cover all the knowledge area processes used to
help ensure the successful outcome of a programme by effective
management.

” Programmes use processes as tools to drive co-ordinated delivery


forward. A process is “a series of actions bringing about a result”.
Programme management processes can be organised into five
groups of one or more processes each (defined by the PMI
Standard for Program Management) as shown in Figure 4 below.

Figure 4 Programme Integration Management Process Groups

The process groups align with the life cycle of a programme as


described below. The process groups are linked by the results
they produce – the result or outcome of one becomes an input to
another.

Initiating Process Group


The Initiating Process, by developing the Programme Brief and
the Programme Preparation Plan, confirms the need for the
programme, defines the programme’s expected outcomes, and its
governance structure.

Planning Process Group


The Planning Process is concerned with producing the
Figure 5 Process Group Programme Management Plan and its subsidiary plans, which
Interactions outlines the best approach to delivering the benefits and scope
that the programme has to been set up to provide.

2.1 Issue 1.0 - October 2009 MAX/OTC/PF/005/01


Programme Management Manual – recommended practice I P E M C

Executing Process Group


The Executing Process is concerned with assembling the
resources necessary to carry out the works defined in the
Programme Management Plan to deliver the required benefits.
Monitoring & Controlling Process Group
The Monitoring & Controlling Process, which runs in parallel with
execution, contains the continuous processes required to monitor
performance, anticipate problems and implement corrective action
when required.
Closing Process Group
The Closing Process is the final phase of Programme Integration
Management and formally accepts a product, service or benefit
and brings component projects, and finally, the programme to a
close.

2.2 Gateway Reviews


Gateway reviews are an established mechanism for providing
independent assessments of the status of projects and
programmes at various key stages. They are a critical governance
control.
Reviews are carried out by those not having a direct involvement
in the day to day management of the programme. It is
recommended that where there is high risk due to large
investment being involved, or where there is high complexity, that
external independent reviewers are used. On many projects or
programmes it may be adequate for the PMO (if it exists) to act as
reviewers. The role of reviewers is to provide constructive
challenge to the aspects under consideration to verify the
achievability and robustness of the proposals.
It is recommended that an approach similar to that developed by
OGC2 should be adopted as this adds to the approach proposed
by PMI. For full details refer to the OGC website at:
www.ogc.gov.uk/what_is_ogc_gateway_review.asp
In summary, OGC define 5 types of reviews for projects (refer to
Project Management Manual section 2.3), but only one for
programmes. They recommend that a Type 0: Strategic
Assessment is carried out at various key decision points during
the life cycle of the programme.
To demonstrate good practice, it is recommended that gateway
reviews be executed on programmes at the following stages:
■ At the end of the initiating process to confirm the programme
can proceed to setup,
■ At the end of the planning process to confirm the programme

2
OGC’s gateway process is mandatory on UK government funded projects
and programmes

2.2 Issue 1.0 - October 2009 MAX/OTC/PF/005/01


Programme Management Manual – recommended practice I P E M C

can commence delivery,


■ Periodic strategic reassessments during the delivery phase,
■ Final review of benefits realisation to allow programme
closure.
OGC have also recently introduced a Starting Gate Review, which
addresses deliverability of new policy. Such a review, if carried
out, is likely to be undertaken prior to engagement of the
Programme Manager, but its findings will be an important input to
the Initiating phase.

Figure 6 below shows how these strategic assessments map onto


the five process groups.

Programme Integration Management

Monitoring &
Initiating Planning Executing Closing
Controlling
Process Group Process Group Process Group Process Group
Process Group

Programme Programme
Programme Direct & Manage Monitor & Control Programme Closure
Brief
Preparation Management Plan
Plan Programme Execution Programme Work Report
(PgMP)

Starting Gate

Review 0: Approval to initiate programme

Review 0: Approval to commence delivery

Review 0: Periodic strategic reassessments

Review 0: Final review of


benefits realisation

Figure 6 Programme Gateway Review Process

2.3 Issue 1.0 - October 2009 MAX/OTC/PF/005/01


Programme Management Manual – recommended practice

3 Initiating Process Group


The Programme Initiating Process confirms the need for the programme and defines the
programme’s expected outcomes, through development of the Programme Brief and Programme
Preparation Plan.

3.1 Programme Brief


Outline The Programme Brief starts the programme process off as shown
in Figure 7 below.

Figure 7 Develop Programme Brief

In some situations, prior to initiating the programme, the client will


have prepared a Programme Mandate. This is a high level
statement of the outcomes required from a programme; in some
organisations it may be referred to as a strategic business case.
When a Programme Mandate exists this is used as guidance to

“ Once endorsed by the


Programme Board, the
Programme Brief
commence the Initiating Process by converting the concept of the
requirements into a realisable business proposition.

The Programme Brief summarises the outline business case for


highlights the the programme and includes:

conditions for the ■ outline vision statement


achievability of the ■ programme objectives


proposed outcomes. ■ programme benefits
■ outline scope
■ identification of the risks & issues
■ outline estimate of costs
■ outline estimate of timescale
■ identification of the known stakeholders
■ funding strategy

Once endorsed by the Programme Board, the Programme Brief


highlights the conditions for the achievability of the proposed
outcomes and provides the framework for the development of

3.1 Issue 1.0 - October 2009 MAX/OTC/PF/005/01


Programme Management Manual – recommended practice

further detailed planning.

When Preparation of the Programme Brief is the first activity of the


programme management process. It confirms the nature and
scope of the programme that will be required in order to realise
the proposed outcomes.

By whom The Programme Sponsor has ultimate responsibility for approving


the Programme Brief, but often it is drafted jointly with the
Programme Manager and his team.

Inputs ■ Programme Mandate (if available)


■ Starting Gate Review (if undertaken)
■ Existing projects
■ Client organisation’s business plan.

Tools and Techniques ■ Programme management methodology as set down in this


manual
■ Expert judgement
■ Cost/benefit analyses

Process

c Assign the Programme Board


Identify the constituent members of the Programme Board.

d Assign the Programme Manager


Identify the designated Programme Manager.

e Develop the Outline Vision Statement


Prepare a clear statement which articulates the future desired
state to be created by the programme. This is a key
communication document for obtaining the positive engagement
of stakeholders.

f Develop the Outline Business Case


Prepare the Outline Business Case to include consideration of the
programme objectives, benefits, scope, risks and issues, costs,
affordability, value for money and timescale.

g Identify stakeholders
Identify the known stakeholders; clarifying their involvement,
wants and needs, and their ability to influence the outcome of the
programme.

h Develop a Funding Strategy


Detail the anticipated order of, and likely timing profile of, costs.
Identify the potential sources of funding. It is essential the
Programme Board is aware of the full extent of funding obligations
the programme will demand.

3.2 Issue 1.0 - October 2009 MAX/OTC/PF/005/01


Programme Management Manual – recommended practice

An overview of the process is shown in Figure 8 below.

1) Assign Programme
Board

Strategic Objectives

2) Assign Programme
Manager
Expected Benefits Programme Mandate

Fit with other 3) Outline Vision


Initiatives Programme Brief Statement Objectives

Existing Projects Benefits

4) Outline Business Outline Scope


Client organisation’s
Case
Business Plan
Identify Risks/Issues

Affordability
5) Identify
Stakeholders Value for money
Outline Costs
‐capital
‐operational

6) Funding Strategy Outline Timescale

Figure 8 Programme Brief Overview

Outputs
 ■ Programme Brief

Next Steps Following the Programme Board’s approval of the Programme


Brief, the Programme Preparation Plan is produced outlining how
the Planning Process stage will be undertaken.

3.3 Issue 1.0 - October 2009 MAX/OTC/PF/005/01


Programme Management Manual – recommended practice

3.2 Programme Preparation Plan


Outline Production of the Programme Preparation Plan is the second
stage of the Initiating Process as shown in Figure 9 below and
sets out what will be undertaken during the Planning Process and
how this work will be carried out.

Figure 9 Develop Programme Preparation Plan

Before committing substantial resource to the Planning Process


the Programme Sponsor will instigate the production of a
Programme Preparation Plan. This plan will define what is to be
developed during the planning phase, and indications of the cost
and time for carrying it out.

“ Once endorsed by the


Programme Board, the
Programme Brief
The Programme Preparation Plan will consider:

■ boundaries of the planning process


highlights the ■ deliverables of the planning process
conditions for the ■ timescale required for the planning process
achievability of the ■ principles of governance and controls


proposed outcomes. ■ team required for the planning process
■ cost of the planning process

Endorsement by the Programme Board will trigger the assembly


of a programme management team which will commence the
detailed planning of how the programme will be implemented and
the required outcomes realised.

When Following on from sanctioning of the Programme Brief the


production of the Programme Preparation Plan concludes the
initiating process.

By whom The Programme Sponsor has ultimate responsibility for approving


the Programme Preparation Plan, but the document will be drafted
by the Programme Manager (if in post).

3.4 Issue 1.0 - October 2009 MAX/OTC/PF/005/01


Programme Management Manual – recommended practice

Inputs ■ Programme Brief


■ Existing corporate governance policies

Tools and Techniques ■ Programme management methodology as set down in this


manual
■ Expert judgement

Process

c Define the Boundaries of the Planning Process


Establish the scope of what will be considered during the Planning
Process.

d Determine the Deliverables of the Planning Process


Identify and describe the major deliverables that will result from
the Planning Process.

e Determine the Timescale of the Planning Process


Estimate the likely timescale that will be required for carrying out
the Planning Process.

f Establish the Principles of Governance & Controls


Define the nature of the governance and the extent of controls
that will apply during the Planning Process, and consider the
impacts these may have on the process.

g Define the Team Required for the Planning Process


Define the skills and expertise needed to effectively carry out the
Planning Process, and determine the team structure that will be
required. Identify personnel that may undertake key roles.

h Establish the Costs of the Planning Process


From the resource requirement and the estimated timescale,
determine the likely cost of carrying out the Planning Process.

An overview of the process is shown in Figure 10 overleaf.

3.5 Issue 1.0 - October 2009 MAX/OTC/PF/005/01


Programme Management Manual – recommended practice

Figure 10 Programme Brief Overview

Outputs
 ■ Programme Preparation Plan

Next Steps With the approval of the Programme Preparation Plan the
Initiating Process is complete and the Planning Process starts.

3.6 Issue 1.0 - October 2009 MAX/OTC/PF/005/01


Programme Management Manual – recommended practice I P E M C
Planning

4 Planning Process Group


The Planning Process Group is concerned with producing the Programme Management Plan
(PgMP) and its subsidiary plans.

4.1 Programme Management Plan


Outline The Programme Management Plan (PgMP) is an essential source
of reference for all associated with a programme. The PgMP is the
output of the Planning Process Group, as shown in Figure 11
below, and defines the outcomes and benefits, roles and
responsibilities, organisation, scope of the programme and how
the programme will be executed, monitored, controlled and
closed.

Figure 11 Programme Management Plan

4.1 Issue 1.0 - October 2009 MAX/OTC/PF/005/01


Programme Management Manual – recommended practice I P E M C
Planning

The PgMP is comprised of a number of subsidiary plans, as


shown in Figure 11 opposite, produced by the Programme

“ As the level of expenditure


associated with
programmes is usually
Manager and is a live document which is updated and revised
throughout the life of the programme. As the level of expenditure
associated with programmes is usually substantial then the level
of detail and effort given to the PgMP needs to reflect this level of
substantial then the level of importance.
detail and effort given to the On many programmes it is likely that during the initiating and
PgMP needs to reflect this planning processes that there will be ongoing discussions about
the exact extent and nature of the scope of work necessary to


level of importance achieve the programme outcomes. At some point in order to allow
an approval to proceed to execution, the scope must become
agreed, frozen and baselined. From this point any further
variations to scope will be subject to the discipline of a formal
change management process.

When The PgMP is the consolidation of all the subsidiary plans


produced during the Planning Process.

By whom
Programme Manager

Inputs ■ Programme Brief


■ Programme Preparation Plan
■ Details of associated projects and programmes
■ Lessons learnt from previous programmes

Tools and Techniques ■ Programme Management processes as set down in this


manual
■ Expert judgement

Process

Develop the PgMP subsidiary plans in accordance


c
with the following sections of this manual

d Compile the Programme Management Plan

Outputs
 ■ Programme Management Plan

Next Steps Prepare the subsidiary plans and compile into a single PgMP.
Once the PgMP is endorsed the programme is ready to move to
the Executing Process as well as the Monitoring and Controlling
Process which operates in parallel.

4.2 Issue 1.0 - October 2009 MAX/OTC/PF/005/01


Programme Management Manual – recommended practice I P E M C
Planning

4.2 Programme Governance Plan

Outline Governance is one of the 4 principal themes running through


programme management.


The Programme
Governance Plan For governance to be effective across the whole programme it is
essential to have a detailed governance framework.
establishes the principles
and structure to be adopted The Programme Governance Plan establishes the principles and
structure to be adopted for governance. It describes the
for governance governance goals, structure, roles and responsibilities and the

When
” logistics for establishing the governance process.

This process is part of the development of the Programme


Management Plan.

By whom Programme Manager with input from Programme Sponsor.

Inputs ■ Programme Brief


■ Programme Preparation Plan
■ Client’s governance guidelines
■ Legal & environmental factors
■ Regulatory requirements

Tools and Techniques ■ Expert judgement


■ Programme Management processes as set down in this
manual

Process

c Governance Goals
Define the governance goals for the programme, and for its
component projects, and determine how these will be monitored
and achieved.

d Governance Structure & Composition


Define the governance structure and who will comprise this
structure. Consider the requirement for steering committees,
advisory boards, and specialist external consultants. Outline how
governance will be implemented.

4.3 Issue 1.0 - October 2009 MAX/OTC/PF/005/01


Programme Management Manual – recommended practice I P E M C
Planning

e Governance Role & Responsibilities


Detail the role of each member of the governance structure,
together with defining responsibilities, levels of authority and
accountability.

f Gateway Reviews
Verify the phasing of gateway reviews in relation to the key stages
of the programme and the initiation, monitoring and closing of
projects, propose level of independence required and the
methodology to be used.

g Performance Reviews
Determine a regime for regular reviews of the progress being
achieved against programme outcomes. Performance reviewing
will involve carrying out reviews of each individual project. (See
also section 4.4)

h Component Initiation
Establish the criteria to be considered as part of the process for
initiating new projects that will contribute to the achievement of a
programme’s outcomes and benefits.

Outputs
 ■ Programme Governance Plan

4.4 Issue 1.0 - October 2009 MAX/OTC/PF/005/01


Programme Management Manual – recommended practice I P E M C
Planning

4.3 Programme Organisation & Resource


Management Plan

Outline Programme management is responsible for ensuring an adequate


level of resource is available throughout the life cycle of a
programme. This responsibility is focused on the provision of the
resource both at programme and individual component project
levels. Day-to-day management of project-based resource is the
responsibility of project managers. Whereas the resource
requirement for programme management will remain relatively
constant the requirement at project level will vary substantially
throughout both project and programme life cycle.

The Programme Resource Management Plan sets out the


process for ensuring the necessary level of resources (staff,
facilities, equipment and funding) are provided to the programme
when required.

When This process is part of the development of the Programme


Management Plan.

By whom Programme Manager with input from Programme Sponsor and


other programme team members.

Inputs ■ Programme Brief


■ Programme Preparation Plan
■ Programme Governance Plan
■ Programme Benefits Realisation Plan
■ Programme Scope Management Plan

Tools and Techniques ■ Expert judgement


■ Programme Management processes as set down in this
manual
■ RACI (Responsible, Accountable, Consulted, Informed) Charts

Process

c Develop Organisation Chart


Identify and develop the organisational structure of the team

4.5 Issue 1.0 - October 2009 MAX/OTC/PF/005/01


Programme Management Manual – recommended practice I P E M C
Planning

necessary to deliver the programme. Be mindful of the


governance arrangements and reporting lines for staff.

d Define Roles
Detail the roles and responsibilities of each of the key posts set
out in the organisation chart.

e Confirm Resources Requirement


Determine the type and extent of resources required to undertake
a programme. These will include resources at both the
programme and individual component project levels. The staffing
requirement will reflect the roles identified in the organisation
chart. Define the skills and competency required for these roles.

4 Resource Availability
Review the suitability and availability of potential candidates for
key roles. The Programme Manager is responsible for selecting
and appointing project managers to head individual component
projects and staff for the programme management team. Review
the suitability and availability of facilities and equipment required
to support programme and project staff. Confirm the source and
availability of funding for the resources identified.

5 Resources Management
Outline the procedures related to the management of key staff;
including aspects such as induction, performance appraisals,
training and development, health and safety, transfer and
redeployment, and termination of employment. Outline the
procedures for the day-to-day management of facilities and
equipment.

Outputs
 ■ Programme Organisation & Resources Management Plan

4.6 Issue 1.0 - October 2009 MAX/OTC/PF/005/01


Programme Management Manual – recommended practice I P E M C
Planning

4.4 Monitoring, Controlling & Reporting Plan

Outline Throughout the programme life cycle an essential element of


programme management is the assessment and reporting of
performance being achieved towards the programme’s outcomes.

“ …..an essential element of


programme management is
the assessment and
Those with a responsibility for programme governance need to be
regularly reviewing the requirement to implement any corrective or
preventive action that may be necessary to maintain progress
towards achievement of the outcomes.
reporting of performance
being achieved towards the The Monitoring, Controlling & Reporting Plan establishes the
structure and detailed processes to be used to measure the


programme’s outcomes. progression of the programme, for making assessments of overall
trends and taking any necessary corrective actions. It also
addresses the arrangement for assembling performance
information into clear, coherent reports of the overall status of a
programme’s performance and for determining appropriate
distribution to stakeholders and the programme team.

When This process is part of the development of the Programme


Management Plan.

By whom Programme Manager with input from Programme Sponsor and


other programme team members.

Inputs ■ Programme Brief


■ Programme Preparation Plan
■ Programme Governance Plan
■ Client’s governance guidelines

Tools and Techniques ■ Expert judgement


■ Programme Management processes as set down in this
manual
■ Earned value management

Process

c Programme Performance Reports


Detail the format for reporting the progress of individual
component projects and of the overall programme. Aspects
covered will include time schedule status, cost budget status,
risks, issues, resource issues, project initiation and closure, and
benefits already realised.

4.7 Issue 1.0 - October 2009 MAX/OTC/PF/005/01


Programme Management Manual – recommended practice I P E M C
Planning

d Programme Reporting Cycle


Define the reporting structure and cycle to be imposed on the
programme and component projects, and determine the content
and level of detail of reports to be distributed to different
stakeholders.

e Performance Measurement
Establish the appropriate mechanism to be adopted for the
monitoring and measuring of performance and determine the
techniques to be utilised in assessing performance. Ascertain
which areas are to be assessed; these will include time, cost,
quality as well as movement in risks and issues. The performance
levels achieved should be projected forwards in order to forecast
potential impacts on a programme’s outcomes.

f Corrective Actions
Determine the limits of acceptable variances from the plan and
formulate an escalation process.

Outputs
 ■ Programme Monitoring, Controlling & Reporting Plan

4.8 Issue 1.0 - October 2009 MAX/OTC/PF/005/01


Programme Management Manual – recommended practice I P E M C
Planning

4.5 Programme Risk Management Plan

Outline Risk management is about managing uncertainty, both the threats


to the programme outcomes, as well as the opportunities for

“ The Programme Risk


Management Plan determines
the approach to be adopted in
increasing the chances of achieving these objectives.
The Programme Risk Management Plan determines the approach
to be adopted in relation to identifying and managing risks that
may impact the achievability of the programme’s benefits.
relation to identifying and
Risk drivers will include those related to the external and internal
managing risks that may impact environment of the client organisation, those created by aspects
the achievability of the of the management of the programme, those generated by
individual component projects, and those related to the operation
programme’s benefits


of programme deliverables.

When This process is part of the development of the Programme


Management Plan.

By whom Programme Manager with input from Programme Sponsor and


other programme team members.

Inputs ■ Programme Brief


■ Programme Preparation Plan
■ Programme Governance Plan

Tools and Techniques Refer to the Risk Management section of the Project
Management Manual.

Process

} Refer to the Risk Management section of the Project Management


Manual.

Outputs
 ■ Programme Risk Management Plan

4.9 Issue 1.0 - October 2009 MAX/OTC/PF/005/01


Programme Management Manual – recommended practice I P E M C
Planning

4.6 Programme Issues Management Plan

Outline Issues can arise from any aspect of a programme and need to be
effectively managed in order to prevent or minimise their impact
on a programme’s outcomes.


The Programme Issues
Management Plan defines a The Programme Issues Management Plan defines a process for
process for dealing efficiently dealing efficiently with concerns that threaten the programme
objectives and are outside the direct control of the Programme
with unexpected occurrences Manager. This process needs to clarify how issues are identified,

” assessed, and a course of action developed to resolve them. The


responsibilities of ownership and resolution of issues needs to be
determined.
Note: Risks should not be confused with issues. Risks are
uncertain, in that they may not occur, whereas issues have
occurred.

When This process is part of the development of the Programme


Management Plan.

By whom Programme Manager with input from other programme team


members.

Inputs ■ Programme Brief


■ Programme Preparation Plan
■ Programme Governance Plan

Tools and Techniques ■ Expert judgement


■ Programme Management processes as set down in this
manual

Process

c Issue Identification, Recording & Assessment


Develop a process that defines how issues which cannot be
resolved by day-to-day management are captured and recorded
on a Programme Issues Log. These issues need to be reviewed in
order to assess their potential for disrupting the progress of the
programme.

4.10 Issue 1.0 - October 2009 MAX/OTC/PF/005/01


Programme Management Manual – recommended practice I P E M C
Planning

d Issue Resolution
Develop a process for resolving those issues that have been
identified as damaging to the programme. This process involves
assigning ownership of each issue and for assigning responsibility
for managing the resolution. Where a resolution strategy involves
a significant change to the way a programme is being
implemented, or requires urgent executive attention, then a
governance escalation policy needs to have been developed.

Outputs
 ■ Programme Issues Management Plan

4.11 Issue 1.0 - October 2009 MAX/OTC/PF/005/01


Programme Management Manual – recommended practice I P E M C
Planning

4.7 Programme Change Management Plan

Outline
The long timescale of the life cycle of programmes means that
some element of change to the works being implemented is


…. sets out the process
almost inevitable. Changes can emanate from many sources and
for ensuring the potential for many reasons. Uncoordinated adoption of change has the
impact of all requests for potential to rapidly lead to confusion and cause overruns to time
and cost.
changes are
systematically The Programme Manager is responsible for managing the
introduction of change into the programme in a controlled manner
considered ….

” that minimises any disruption.

The Programme Change Management Plan sets out the process


for ensuring the potential impact of all requests for changes are
systematically considered and all approved changes are
effectively incorporated into the programme.

Changes can be at individual project level, across a number of


projects or at the programme level. Changes at single project level
are managed by project managers. Change across multiple
projects needs to be controlled at the programme level, or at least
initially at the programme level. All changes, at whatever level,
need to be captured in programme level reporting, even if only in
summary form.

When This process is part of the development of the Programme


Management Plan.

By whom Programme Manager with input from Programme Sponsor and


other programme team members.

Inputs ■ Programme Brief


■ Programme Preparation Plan
■ Programme Governance Plan
■ Monitoring, Controlling & Reporting Plan
■ Programme Scope Management Plan
■ Client’s governance guidelines

Tools and Techniques Refer to the Change Management section of the Project
Management Manual.

4.12 Issue 1.0 - October 2009 MAX/OTC/PF/005/01


Programme Management Manual – recommended practice I P E M C
Planning

Process

Refer to the Risk Management section of the Project Management


}
Manual.

Outputs
 ■ Programme Change Management Plan

4.13 Issue 1.0 - October 2009 MAX/OTC/PF/005/01


Programme Management Manual – recommended practice I P E M C
Planning

4.8 Programme Benefits Realisation Plan

Outline Benefits realisation is one of the 4 principal themes running


through programme management.

“ Benefits realisation is
concerned with defining the
benefits that are required by
Benefits realisation is concerned with defining the benefits that are
required by the client, and formalising how the outcomes will be
delivered to secure these benefits.

the client, and formalising The Programme Benefits Realisation Plan defines the benefits,
how the outcomes will be establishes the boundaries, provides clear direction, and sets out
a roadmap for achieving the changes required by a programme.
delivered to secure these The identification and definition of the benefits needs to be closely
benefits. related to the business strategy and objectives of the client

When
” organisation.

This process is part of the development of the Programme


Management Plan.

By whom Programme Manager with input from Programme Sponsor and


other programme team members.

Inputs ■ Programme Brief


■ Programme Preparation Plan
■ Programme Governance Plan

Tools and Techniques ■ Expert judgement


■ Programme Management processes as set down in this
manual

Process

c Identify & Define Business Benefits


Determine the expected benefits to result from the outcomes
brought about by a programme. Align these benefits with the
business strategy of the client organisation and assess the value
and organisational impact of the programme. This is often
captured in a Business Case document.

4.14 Issue 1.0 - October 2009 MAX/OTC/PF/005/01


Programme Management Manual – recommended practice I P E M C
Planning

d Determine Benefit Metrics


As effective management of benefits realisation depends on
benefits being quantifiable and measureable then targets for
benefits need to be established that are specific, achievable and
are time-related. Develop procedures defining how benefits will be
measured. Not all benefits are obviously tangible and setting
measures for these will require particularly careful consideration.

e Relate Benefits to Projects


Determine the individual component projects that are necessary in
order to realise the required benefits and allocate clear ownership
for realising benefits. The scope of these component projects is
addressed by the Programme Scope Management Plan.

f Produce a Benefits Realisation Plan


Develop a plan which confirms all the benefits arising from a
programme, and which defines their dependencies and the
timescale for their delivery. Preparation of Benefit Profiles and a
Benefits Map will assist production of this plan. The plan should
also outline the process for assessing at certain points in a
programme’s life cycle the benefits actually achieved against
those planned.

Outputs
 ■ Benefits Realisation Plan including:
■ Benefits Profiles
■ Benefits Map

4.15 Issue 1.0 - October 2009 MAX/OTC/PF/005/01


Programme Management Manual – recommended practice I P E M C
Planning

4.9 Programme Scope Management Plan

Outline The Programme Scope Management Plan details how the


programme components will be defined, verified and controlled. It

“ The Programme Scope


Management Plan details how
the programme will be defined,
verified and controlled.
contains a definition of the objectives and includes what the
programme is trying to achieve in terms of scope, the products to
be produced, and the acceptance criteria for those products,
together with any constraints and assumptions.

When ” This process is part of the development of the Programme


Management Plan.

By whom Programme Manager with input from Programme Sponsor and


other programme team members.

Inputs ■ Programme Brief


■ Programme Preparation Plan
■ Programme Governance Plan
■ Programme Benefits Realisation Plan

Tools and Techniques Refer to the Scope Management section of the Project
Management Manual.

Process

Refer to the Scope Management section of the Project


}
Management Manual.

Outputs
 ■ Scope Management Plan

4.16 Issue 1.0 - October 2009 MAX/OTC/PF/005/01


Programme Management Manual – recommended practice I P E M C
Planning

4.10 Programme QES Plan

Outline The Quality, Environmental & Safety Plan details how quality will
be planned, assured and controlled on a programme whilst
ensuring the programme works are carried out in an
environmentally sustainable and safe manner.

Quality assurance addresses both the management of the


programme quality and the products to be produced.

When This process is part of the development of the Programme


Management Plan.

By whom Programme Manager with input from Programme Sponsor and


other programme team members.

Inputs ■ Programme Brief


■ Programme Preparation Plan
■ Client’s QES processes
■ MM QES processes

Tools and Techniques Refer to the QES section of the Project Management Manual.

Process

Refer to the Scope Management section of the Project


}
Management Manual.

In addition, the Programme QES Plan should specifically define


the processes related to the maintenance and control of
programme information, this includes:

c Identify Scope of Programme Information


Determine type and nature of programme information that will be
generated and need to be managed.

2 Develop Process for Managing Information


Develop processes and procedures for the maintenance and
control of different types of programme information.

4.17 Issue 1.0 - October 2009 MAX/OTC/PF/005/01


Programme Management Manual – recommended practice I P E M C
Planning

3 Roles & Responsibilities


Determine roles and responsibilities in relation to information
management.

Confirm Systems to be Used for Information


4
Management
Determine the systems that will be adopted for the storage and
retrieval of programme information.

5 Configuration Management
Define the protocols to be adopted for terminology, referencing,
baselining, version control, distribution and archiving.

6 Security Arrangements
Consider the confidentially sensitivity of information and extent of
accessibility to information. Determine arrangements to ensure
security of programme information.

Outputs
 ■ QES Plan (including programme information management)

4.18 Issue 1.0 - October 2009 MAX/OTC/PF/005/01


Programme Management Manual – recommended practice I P E M C
Planning

4.11 Programme Schedule Management Plan

Outline The Programme Schedule Management Plan provides the overall


framework of a programme’s timescale and defines how progress

“ The Programme Schedule


Management Plan provides the
overall framework of a
against the schedule is to be monitored and reported.

The programme schedule defines the durations and sequencing


of those individual component projects that are necessary to
programme’s timescale and deliver a programme’s outcomes. The schedule should highlight
those component project’s milestones that represent either a
defines how progress against the
deliverable to a programme or an interdependency to other
schedule is to be monitored and projects. The schedule will develop its level of detail as the
programme life cycle develops.
reported.

When
” This process is part of the development of the Programme
Management Plan.

By whom Programme Manager with input from Programme Sponsor and


other programme team members.

Inputs ■ Programme Brief


■ Programme Preparation Plan
■ Programme Governance Plan
■ Programme Benefits Realisation Plan
■ Programme Scope Plan

Tools and Techniques Refer to the Schedule Management section of the Project
Management Manual.

Process

Refer to the Schedule Management section of the Project


}
Management Manual.

Outputs
 ■ Schedule Management Plan including:
■ Programme Schedule

4.19 Issue 1.0 - October 2009 MAX/OTC/PF/005/01


Programme Management Manual – recommended practice I P E M C
Planning

4.12 Interfaces with Other Projects

Outline Programme management involves dealing with all the interfaces


between not only the programme’s component projects but with
those associated projects and certain operational activities of the

“ Programme management involves


dealing with all the interfaces
between not only the programme’s
client. A Programme Manager needs to have an understanding of
the scope and deliverables of these and of how they relate to the
programme.

component projects but with those The Programme Manager and Programme Sponsor need to work
associated projects and certain together to develop this understanding and to make sure the client
organisation fully understands the potential impact of a
operational activities of the client. programme on their existing business.

When
” This process is part of the development of the Programme
Management Plan.

By whom Programme Manager with input from Programme Sponsor and


other programme team members.

Inputs ■ Programme Brief


■ Client organisation’s Business Plan
■ Client programmes and projects portfolio
■ Programme Stakeholder Management Plan

Tools and Techniques ■ Expert judgement


■ Programme Management processes as set down in this
manual

Process

c Identify all Associated Project & Operational Activity


Clarify with the client any projects or operational activities that
have an association with, or could have an impact on, the
proposed programme. Understand the scope, deliverables, and
timing of these projects or activities. This includes projects or
interfaces with 3rd parties.

4.20 Issue 1.0 - October 2009 MAX/OTC/PF/005/01


Programme Management Manual – recommended practice I P E M C
Planning

d Determine any Relationships and Interdependencies


Define the nature of any relationships and interdependencies that
exist between any associated projects and operational activities,
and the proposed programme.

Monitoring Progress of Associated Project &


e
Operational Activity
Establish with the client a mechanism for monitoring the progress
of any associated projects and operational activity, in order to be
able to assess the impact of any variances on the programme.

Outputs
 ■ Programme Interfaces Plan

4.21 Issue 1.0 - October 2009 MAX/OTC/PF/005/01


Programme Management Manual – recommended practice I P E M C
Planning

4.13 Lessons Learnt

Outline Lessons learnt logs are a valuable source of knowledge about


causes of failure and of recommendations for improved


Lessons learnt logs are a valuable
performance. It is therefore advantageous to give some time
source of knowledge about causes during the Planning Process to the consideration of any lessons
of failure and of recommendations learnt from similar or relevant experiences of the programme team
for improved performance. or the client’s organisation.

When
” This process is part of the development of the Programme
Management Plan.

By whom Programme Manager with input from Programme Sponsor, other


programme team members, key stakeholders from other relevant
programmes.

Inputs ■ Lessons learnt from previous client programmes


■ Lessons learnt from the industrial sector
■ Generic lessons learnt (i.e. as published by OGC)

Tools and Techniques ■ Expert judgement


■ Programme Management processes as set down in this
manual

Process

c Learning from Previous Programmes


Where the client has undertaken previous programmes identify
any reviews undertaken such as OGC gateways and set out how
the recommendations (where applicable) have been considered
by the current programme. Arrange meetings with external
stakeholders that may have relevant experience and knowledge
from their own lessons learnt process. Highlight those stakeholder
issues that should be acknowledged in the proposed programme.

d Lessons Learnt Process


Develop a process for capturing lessons learnt from individual
component projects and feeding the knowledge back into the
other projects throughout the programme life cycle.

4.22 Issue 1.0 - October 2009 MAX/OTC/PF/005/01


Programme Management Manual – recommended practice I P E M C
Planning

e Lessons Learnt Log


Develop a process for finally reviewing lessons learnt and for
producing a completed log as part of the Closing Process.

Outputs
 ■ Programme Lessons Learnt Plan

4.23 Issue 1.0 - October 2009 MAX/OTC/PF/005/01


Programme Management Manual – recommended practice I P E M C
Planning

4.14 Programme Contingency Planning

Outline If a programme is being carried out in an environment that has


high uncertainty or that is technologically or organisationally

“ Contingency planning is the activity


of developing an approach that
enables substantial change to be
complex then there is a need to have a strategy in place for
dealing with unexpected change, the ‘unknown unknowns’.

Contingency planning is the activity of developing an approach


incorporated into a programme that enables substantial change to be incorporated into a
without losing focus or impetus programme without it losing focus or impetus.

When
” This process is part of the development of the Programme
Management Plan.

By whom Programme Manager with input from Programme Sponsor, other


programme team members, key stakeholders from other relevant
programmes.

Inputs ■ Programme Brief


■ Programme Preparation Plan
■ Programme Interfaces Plan
■ Programme Benefits Realisation Plan

Tools and Techniques ■ Expert judgement


■ Programme Management processes as set down in this
manual
■ Scenario planning
■ Risk techniques

Process

c Assess Potential for Change


Carry out a review to ascertain the degree of uncertainty and
complexity of the client’s operational environment and of the
nature of the programme to determine the potential for significant
change.

d Identify Potential Areas for Change


Review with Programme Sponsor and key stakeholders any
potential areas that might be susceptible to change.

4.24 Issue 1.0 - October 2009 MAX/OTC/PF/005/01


Programme Management Manual – recommended practice I P E M C
Planning

e Scenario Identification & Planning


Consider the likely situation and consequences that might exist if
the identified potential changes were to come about. Develop high
level proposals for dealing with the impact on the proposed
programme of these scenarios

4 Process for Dealing with Change


Develop a process for detecting early warning of potential
changes and for assessing the likely impact of the changes on
programme management, outcomes and benefits. Consider a
strategy of policy decisions and measures for introducing
significant changes into a programme.

5 Contingency Reserves
Develop a policy for establishing a programme contingency
reserve reflecting the degree of probability and extent of change
that may occur during a programme’s life cycle.

Outputs
 ■ Programme Contingency Plan, including
o Programme Contingency Reserve

4.25 Issue 1.0 - October 2009 MAX/OTC/PF/005/01


Programme Management Manual – recommended practice I P E M C
Planning

4.15 Programme Transition Planning

Outline Transition planning is the process of incorporating the deliverables


of a programme into a fully functional aspect of a client’s
business.

“ Transition planning is the


process of incorporating the
deliverables of a programme
Whilst for a Programme Manager the focus of transition planning
is on the successful delivery of various project outputs, and the
progressive achievement of the programme’s objectives and
outcomes, for the client the focus is much more on preparing their
into a fully functional aspect organisation for the change to be brought about by the
of a client’s business. programme, and for managing the successful incorporation of the

” change into a new way of working. Successful transition, and


actual realisation of benefits, therefore relies on the active
involvement of a client Business Change Manager.

When This process is part of the development of the Programme


Management Plan.

By whom Programme Manager, Programme Sponsor and representative


from the client’s business operations such as a Business Change
Manager.

Inputs ■ Programme Brief


■ Programme Preparation Plan
■ Programme Governance Plan
■ Programme Benefits Realisation Plan
■ Programme Interfaces Plan

Tools and Techniques ■ Expert judgement


Programme Management processes as set down in this
manual

Process

c Component Outputs Transition


Devise a process for the delivery and handover of individual
component projects to a client and which includes the interface
with the client’s Business Change Manager.

d Review of Benefits Realisation


Establish a process for obtaining feedback on whether projects
are delivering their intended outcomes and are realising the
anticipated benefits.

4.26 Issue 1.0 - October 2009 MAX/OTC/PF/005/01


Programme Management Manual – recommended practice I P E M C
Planning

e Benefit Rectification Plan


If required, devise a strategy for realising the shortfall in benefits
by adjusting the outputs from another project or by initiating a new
project.

Outputs
 ■ Programme Transition Plan
■ Programme Benefit Rectification Plan

4.27 Issue 1.0 - October 2009 MAX/OTC/PF/005/01


Programme Management Manual – recommended practice I P E M C
Planning

4.16 Programme Stakeholder Management


Plan

Outline Stakeholder management is one of the 4 principal themes running


through programme management. Stakeholders are both
individuals and organisations who are affected or have an

“ influence on the programme.


….it is likely that
stakeholders from the
Due to the wider scope of programmes, stakeholder management
client organisation are is likely to involve a larger number of stakeholders than projects.
likely to exert a greater Also it is likely that stakeholders from the client organisation are
likely to exert a greater influence on the actual or perceived
influence on the actual or success of the programme outcome. Full engagement with
perceived success of the stakeholders is therefore a fundamental aspect of programme
management and will occupy a substantial proportion of a
programme outcome. Programme Manager’s time.

” The Stakeholder Management Plan sets out the process that will
be implemented to ensure effective stakeholder engagement and
communication.

When This process is part of the development of the Programme


Management Plan.

By whom Programme Manager and Programme Sponsor.

Inputs ■ Programme Brief


■ Programme Preparation Plan
■ Programme Governance Plan
■ Programme Benefits Realisation Plan
■ Programme Scope Plan
■ Programme Interfaces Plan
■ Programme Risk Management Plan

Tools and Techniques ■ Expert judgement


■ Programme Management processes as set down in this
manual
■ Stakeholder analysis

4.28 Issue 1.0 - October 2009 MAX/OTC/PF/005/01


Programme Management Manual – recommended practice I P E M C
Planning

Process

c Identify Stakeholders
Review the scope and nature of the programme in order to identify
all the stakeholders either involved or affected by the programme
and its outcomes. As the stakeholders will change during the life
cycle of the programme the identification process needs to be
regularly reviewed.

d Analyse Stakeholders
A profile for each stakeholder needs to be developed to help
determine their interest, attitude, and influence towards the
proposed programme. Preparation of a Power/Interest Matrix will
establish the relative importance of stakeholders and will help to
formulate the engagement strategy. It may be useful to group
together stakeholders into certain categories.

e Determine Stakeholder Engagement Strategy


Determine how the programme will engage with the stakeholders;
this will involve decisions on what is to be communicated, the
nature of the communication and its purpose, the timing of the
communication, and roles and responsibilities for carrying out the
engagement.

f Develop Communications Plan


Determine the methods and format of providing regular
communication regarding progress on the programme to
stakeholders. Ensure that major milestones are recognised and
allow for proactive media briefings where this is part of the
engagement strategy.

Develop Process for Assessing Effectiveness of


5
Engagement
Due to the long timescales likely to be involved in programmes it
will not be adequate to wait until the end of tranches or the
programme to find out about the effectiveness of the stakeholder
engagement. It is therefore essential to have regular, and perhaps
independent, checks on the success of the communication with
stakeholders.

Outputs
 ■ Stakeholder Management Plan including:
■ Stakeholder Profiles
■ Power/Interest Matrix
■ Stakeholder Engagement Strategy
■ Programme Communications Management Plan

4.29 Issue 1.0 - October 2009 MAX/OTC/PF/005/01


Programme Management Manual – recommended practice I P E M C
Planning

4.17 Programme Funding Management Plan

Outline Funding management is one of the 4 principal themes running


through programme management.

“ The Programme Funding


Management Plan
considers the overall
As typically programme costs are very large and the funding gap
between expenditure and benefits realisation very long then the
development of a funding framework is fundamentally important
for effective programme management.
financial environment in
The Programme Funding Management Plan considers the overall
which the programme will financial environment in which the programme will operate; it
operate. involves determining the overall cost profile of developing and

” executing the programme together with confirmation of the


funding structure, and the sources from which the client will
secure funding.

Funding for programmes is often provided by external sources


and because of the large sums involved funders will become key
stakeholders in the programme.

When This process is part of the development of the Programme


Management Plan.

By whom Programme Manager, Programme Sponsor and the client’s


finance staff.

Inputs ■ Client Business Plan


■ Client Investment Authorisation process
■ Programme Brief
■ Programme Preparation Plan
■ Programme Governance Plan
■ Programme Benefits Realisation Plan
■ Programme Risk Management Plan
■ Programme Scope Management Plan
■ Programme Schedule Management Plan

Tools and Techniques ■ Expert judgement


■ Programme Management processes as set down in this
manual
■ Funding methods
■ Programme financial analysis

4.30 Issue 1.0 - October 2009 MAX/OTC/PF/005/01


Programme Management Manual – recommended practice I P E M C
Planning

Process

c Consider Funding Options


Review with the client the various methods and potential sources
of funding for the programme.

d Funding Structure
Confirm with the client the source and availability of funding for
the programme. Determine any constraints on the implementation
of the programme imposed by any conditions of the funding
structure.

e Develop an Expenditure Profile


Develop a high level budget and cash flow forecast integrating the
likely costs of individual component projects together with the
costs of managing at the programme level.

f Develop a Funding Cash flow Profile


Develop a cash flow profile establishing the extent and timing of
the funding required to carry out the programme in accordance
with the PgMP. Consider any income flows arising from benefits
as they are realised during a programme’s life cycle.

g Potential Financial Risks


Consider potential risks that may impact aspects of the financial
management of the programme, such as exchange rate
fluctuations, interest rate changes, price inflation and insolvencies.

h Financial Management Process


Develop policies and processes for the financial management of
the programme; including authorisation levels, client approvals,
monitoring and reporting.

Outputs
 ■ Programme Funding Management Plan
■ Financial models as required

4.31 Issue 1.0 - October 2009 MAX/OTC/PF/005/01


Programme Management Manual – recommended practice I P E M C
Planning

4.18 Programme Cost Management Plan

Outline The Cost Management Plan is primarily concerned with estimating


the cost of the resources needed to complete schedule activities
of individual component projects then totalling these costs to

“ It is necessary to produce
a cost baseline through
which the project budget
produce a cost baseline through which the project budget can be
managed and controlled.

It also considers the effect of project decisions on the cost of


can be managed and using, maintaining and supporting the project deliverable(s)
throughout their life; this is often called whole life-cycle costing.
controlled. The Cost Management Plan also includes consideration of project

” risks, contingency reserves, stakeholder requirements and earned


value analysis.

When This process is part of the development of the Programme


Management Plan.

By whom Programme Manager with input from Programme Sponsor, and


other programme team members.

Inputs ■ Programme Brief


■ Programme Preparation Plan
■ Programme Scope Management Plan
■ Programme Benefits Realisation Plan
■ Programme Schedule Management Plan
■ Programme Funding Management Plan

Tools and Techniques Refer to the Cost Management section of the Project
Management Manual.

Process

Refer to the Cost Management section of the Project


}
Management Manual.

Outputs
 ■ Programme Cost Management Plan

4.32 Issue 1.0 - October 2009 MAX/OTC/PF/005/01


Programme Management Manual – recommended practice I P E M C
Planning

4.19 Programme Procurement and Contract


Management Plan

Outline The Procurement and Contract Management Plan sets out the
processes required to acquire the products and services required
from outside the programme team to perform the required work.


…..sets out the processes
required to acquire the products It includes the procurement strategy to be used, details how
and services required from suppliers (or contractors) will be selected and appointed, and how
the various contracts will be administered.
outside the project team to
perform the required work. The majority of contracts within a programme will actually be

” procured by the projects, but within a framework set by the


programme.

When This process is part of the development of the Programme


Management Plan.

By whom Programme Manager with input from Programme Sponsor and


programme team members.

Inputs ■ Programme Brief


■ Programme Preparation Plan
■ Programme Scope Management Plan
■ Programme Benefits Realisation Plan
■ Programme Schedule Management Plan
■ Programme Funding Management Plan
■ Programme Cost Management Plan

Tools and Techniques Refer to the Procurement Management section of the Project
Management Manual.

Process
Refer to the Procurement Management section of the Project
}
Management Manual.

In addition, the following Contract Management activities should


be addressed:

4.33 Issue 1.0 - October 2009 MAX/OTC/PF/005/01


Programme Management Manual – recommended practice I P E M C
Planning

c Contract Selection
Provide advice on the selection of an appropriate form of contract
and develop programme specific terms and conditions. Provide
advice on any amendments that are required to standard forms.
Ensure client is aware of obligations of the contract being
proposed.

d Placing Contracts
Ensure all bids and appointments reflect the conditions and
obligations of the contract. Ensure that all deliverables are clearly
defined.

e Changes to Contract
Ensure any changes to a contract are properly recorded and
administered.

f Administer Contract Requirements


Ensure the programme management team effectively administer
the requirements of a contract.

g Closure of a Contract
Ensure all the obligations of a contract are satisfied and properly
administer its closure.

Outputs
 ■ Programme Procurement and Contract Management Plan

4.34 Issue 1.0 - October 2009 MAX/OTC/PF/005/01


Programme Management Manual – recommended practice

5 Executing Process Group


The Executing Process Group is concerned with carrying out the works defined in the Programme
Management Plan (PgMP) and its subsidiary plans to achieve the programme outcomes.

5.1 Direct & Manage Programme Execution

Outline The process uses the scope defined in the Programme Brief as a
baseline then ensures that any changes or corrective actions


The process integrates the required are approved then implemented. The process integrates
projects, people and other the projects, people and other resources necessary to carry out
the programme in accordance with the PgMP to ensure that
resources necessary to carry governance, benefits realisation, stakeholder management and
out the programme. funding is effectively carried out.

Figure 12 Direct & Manage Programme Execution

When These processes are used to manage programme work from the
end of the planning phase to the closure of the programme.

By whom Programme Management Team.

Inputs ■ Programme Management Plan


■ Client’s governance guidelines
■ Legal & environmental factors
■ Regulatory requirements

Tools and Techniques ■ Programme Management processes as set down in this


manual
■ Expert judgement
■ Techniques as set down in this Manual

Process

c Manage Programme Team Resource


Assemble and develop the programme management team and
select the project managers for component projects. Ensure both

5.1 Issue 1.0 - October 2009 MAX/OTC/PF/005/01


Programme Management Manual – recommended practice

the programme and project levels have adequate levels of


resource.

d Manage Programme Scope


Ensure programme activity reflects the scope agreed in the
Programme Brief. Initiate component projects necessary to
achieve the programme scope and benefits.

e Manage Component Project Interfaces


Ensure component projects are integrated and their
interrelationships and interdependencies are known and
managed.

f Engage Programme Stakeholders


Maintain regular communication with the programme stakeholders
in order to manage their expectations and keep their positive
engagement.

g Information Distribution
Ensure information is distributed to the programme team and to
stakeholders in a timely manner. Ensure the programme records
are managed through the adopted document management
system.

h Procurement of Suppliers
Manage the process for requesting bids, bid preparation, bid
appraisal, contract negotiation and contract award.

i Direct & Manage Programme Execution


Ensure the programme progresses in accordance with the
processes set out in the PgMP.

An overview of the process is shown in Figure 13 overleaf.

5.2 Issue 1.0 - October 2009 MAX/OTC/PF/005/01


Programme Management Manual – recommended practice

Selection of team
members

Hold regular team


meetings

Team building

Assemble & Develop Training requirements


the Programme Team

1) Manage Programme Staff recognition


Resource

Select Project Determine Co-location of team


Members requirement
Initiate Component Review availability of
2) Manage Programme Projects project managers
Scope
Selection &
appointment process
Implement Corrective
& Preventative Consider external
Actions sourcing
3) Manage Component
Project Interfaces Manage integration
between component
projects

Manage engagement
with stakeholders
4) Engage Programme Maintain Programme
Direct & Manage Stakeholders Records
Programme Execution
Distribute Information
to Stakeholders

5) Information Distribute information


Distribution to Programme Team

Request Bids

6) Manage Procurement Bid Preparation


of Suppliers
Bid Appraisal

Contract Negotiation

7) Direct & Manage Contract Award


Programme Execution Ensure programme processes in Process Analysis
accordance with PgMP
Progress Audits

Quality Audits

Figure 13 Directing & Managing Work

Outputs
 ■ Clear understanding of programme scope and quality
requirements
■ Informed and well supported programme and project teams
■ Informed and engaged stakeholders
■ Committed suppliers with a proper understanding of their
contractual liabilities
■ Adequate resources to ensure efficient completion of the
programme
■ Comprehensive records of the execution process to allow
future audits as required by the client

5.3 Issue 1.0 - October 2009 MAX/OTC/PF/005/01


Programme Management Manual – recommended practice

■ Programme outcomes delivered successfully in accordance


with the Programme Brief and PgMP.

Next Steps Once the coincident processes of Executing and Monitoring and
Controlling are completed then the programme can move to the
Closing Process group.

5.4 Issue 1.0 - October 2009 MAX/OTC/PF/005/01


Programme Management Manual – recommended practice

6 Monitoring & Controlling Process Group


The Monitoring & Controlling Process Group contains those continuous processes required to
monitor performance, anticipate problems and implement corrective action when required.

6.1 Monitor & Control Programme Work


Outline The progress of component projects needs to be monitored to
ensure compliance with the PgMP in order that the proposed

“ The progress of component


projects needs to be monitored to
ensure compliance with the PgMP
outcomes are achieved. Monitoring is performed during
programme execution to provide early indication as to whether
corrective or preventative actions are required to ensure
programme benefits will be realised.
in order that the proposed
The Process Group also controls any changes that are to be
outcomes are achieved. introduced to the programme. Updates to the PgMP will be

” required for any change or action that impact programme


outcomes.

Programme Integration Management

Monitoring &
Initiating Planning Executing Closing
Controlling
Process Group Process Group Process Group Process Group
Process Group

Programme
Programme Programme Management Direct & Manage Monitor & Control Programme Closure
Preparation
Brief Plan (PgMP) Programme Execution Programme Work Report
Plan

Perform‐ Procurement
Scope Schedule Financials Stakeholders Risk & Contract
Issues Change Governance Benefits QES
ance

Figure 14 Monitor & Control Programme Work

When These processes are used to monitor and control programme


work from the planning phase to programme close.

By whom Programme Management Team

Inputs ■ Programme Management Plan

Tools and Techniques ■ Programme Management processes as set down in this


manual
■ Expert judgement

6.1 Issue 1.0 - October 2009 MAX/OTC/PF/005/01


Programme Management Manual – recommended practice

Process

c See following subsections

Outputs
 ■ Ongoing review and reporting of the following aspects and
corrective action where required:
o Performance
o Scope Control
o Schedule Control
o Financial Management
o Stakeholder Expectations Management
o Risk Management
o Procurement and Contract Control
o Issues Management
o Change Management
o Governance Oversight
o Benefits Management

Next Steps Once the coincident processes of Executing and Monitoring and
Controlling are completed then the programme can move to the
Closing Process group.

6.2 Issue 1.0 - October 2009 MAX/OTC/PF/005/01


Programme Management Manual – recommended practice

6.1.1 Performance Reporting

Process

c Monitor Progress of Programme Execution


Review the performance of component projects and determine the
progress status for the whole programme.

d Programme Performance Analysis


Predict the impact of current performance on likelihood of
achieving the proposed programme outcomes.

e Prepare Performance Reports


Prepare reports stating what work has been achieved, the status
of work in progress, and any key risks and issues. Clarify any
changes being considered. Distribute reports to client, programme
team members and other stakeholders.

6.1.2 Scope Control

Process

c Verify Component Project Deliverables


Develop a formal process for acceptance of project deliverables,
which will include quality, safety and environmental aspects.
Consider a validation and verification process that accepts
deliverables as soon as they are complete.

d Monitor Component Project Interfaces


Identify interrelated interfaces and activities, and ensure that
these are managed.

e Control Changes to Programme Scope


Ensure any changes to programme scope are documented and
controlled through configuration and change management
systems.

6.3 Issue 1.0 - October 2009 MAX/OTC/PF/005/01


Programme Management Manual – recommended practice

6.1.3 Schedule Control

Process

c Monitor Schedule Performance


Track the achievement of key milestone dates.

d Maintain Programme Master Schedule


Prepare and maintain an up-to-date master schedule for the
programme that incorporates schedules from individual
component projects.

e Correct Schedule Variances


Initiate corrective actions to rectify variances to schedules in order
to safeguard programme outcomes.

6.1.4 Financial Management

Process

c Ensure Availability of Programme Funding


Ensure the client is aware of their funding obligations and funding
is available in accordance with the funding cash flow profile.
Regularly review the funding cash flow profile against the
programme’s progress.

d Maintain Contract Payments


Ensure the payment obligations of contracts are maintained.

e Close Component Project Budgets


As component projects reach their conclusion supervise the
closure of their financial budgets. Ensure any unspent monies are
returned to the programme budget.

f Update Programme Budget


As changes are formally implemented or corrective actions are
instructed appropriate costs need to be included in the
programme budget. Update the risk contingency allowance as a

6.4 Issue 1.0 - October 2009 MAX/OTC/PF/005/01


Programme Management Manual – recommended practice

result of ongoing programme risk management process.

g Forecast Financial Status at Closure


At regular intervals consider the likely forecasted outturn cost of
executing the programme. Review with the client this cost against
the anticipated benefits arising from the programme and update
the business case as required.

6.1.5 Stakeholder Expectations Management

Perform‐ Procurement
Scope Schedule Financials Stakeholders Risk & Contract
Issues Change Governance Benefits QES
ance

Process

c Review Stakeholders
Ensure that regular reviews of the stakeholders are carried out, in
order to continually assess changes to their interest and influence,
and to identify new stakeholders. Update stakeholder profiles,
stakeholder matrix, and the Stakeholder Management Plan.

d Review Communication with Stakeholders


Ensure that stakeholders are receiving regular and appropriate
information on the development of the programme. Initiate any
required changes to the Stakeholder Management Plan.

e Assess Effectiveness of Stakeholder Engagement


Regularly liaise with key stakeholders to assess the success of
matching their expectations in relation to the programme.
Consider using external reviewers to gauge true effectiveness and
note stakeholder comments under existing processes, such as
OGC Gateway Reviews. Initiate any changes required to the
Stakeholder Management Plan.

6.1.6 Risk Management

Process

c Identify New Risks


Continually review the environment in which the programme is
operating in order to detect new potential risks or risk drivers.

6.5 Issue 1.0 - October 2009 MAX/OTC/PF/005/01


Programme Management Manual – recommended practice

d Monitor Risk Management Process


Continually monitor the programme risk management process to
ensure the impact of risks are being effectively mitigated.

e Lessons Learnt Database


Document any lessons learnt from the risk management process
and review these in relation to remaining programme activity.
Make available any lessons learnt for the Closing Process Group.

6.1.7 Procurement and Contract Control

Process

c Monitor Procurement Management


Regularly carry out audits to ensure procurement management is
being executed in accordance with the procurement and
governance processes set out in the Procurement Management
Plan.

d Monitor Contract Closures


Ensure that contracts are closed down in accordance with the
processes set out in the Procurement and Contract Management
Plan.

6.1.8 Issues Management

Process

c Monitor Issues Management Process


Continually monitor the programme and component projects
issues management processes to ensure that issues are being
effectively identified and resolved.

d Lessons Learnt Database


Document any lessons learnt from the issues management
process and review these in relation to remaining programme

6.6 Issue 1.0 - October 2009 MAX/OTC/PF/005/01


Programme Management Manual – recommended practice

activity. Make available any lessons learnt for the Closing Process
Group.

6.1.9 Change Management

Perform‐ Procurement
Scope Schedule Financials Stakeholders Risk & Contract
Issues Change Governance Benefits QES
ance

Process

c Coordinate Changes Across the Programme


Control the change management process across the whole
programme in order to ensure appropriate governance is applied
to the implementation of proposed changes.

d Review the Implementation of Changes


Regularly review the implementation of approved change requests
to ensure compliance with the change management processes set
out in the PgMP.

e Maintain the Change Request Register


Ensure the progress of all change requests are documented in the
Change Request Register, and that the funding source of all
approved changes are adequate and are recorded in the
Programme Budget.

6.1.10 Governance Oversight

Process

Provide Governance Oversight & Control to the


c
Programme
Throughout the life cycle of the programme ensure by thorough
and comprehensive reviews that all activities related to the
programme are subject to governance oversight and control.

d Maintain Updates to Governance Plan


Regularly review the effectiveness of the governance framework.
Identify and implement any improvements to the governance
framework, and document these changes as updates to the
Governance Plan.

6.7 Issue 1.0 - October 2009 MAX/OTC/PF/005/01


Programme Management Manual – recommended practice

6.1.11 Benefits Management

Process

c Report on Benefits Realisation


Ensure that the reports and metrics defined in the Benefits
Realisation Plan are regularly reported to the programme
management team. Ensure the client and other stakeholders are
kept informed of the progressive achievement of the expected
benefits.

d Business Case Updates


Update the business case to reflect the benefits being realised.

e Lessons Learnt Database


Document any lessons learnt from the benefits realisation process
and review these in relation to remaining programme activity.
Make available any lessons learnt for the Closing Process Group.

6.1.12 QES

Process

c Monitor Compliance with QES


Review the performance of component projects with the Quality,
Environmental and Safety systems under which they are
operating. Monitor compliance with Sustainability objectives where
these have been applied.

d Analyse QES Performance


Look at the QES (and sustainability) performance across all the
component projects making up the programme. Identify trends,
areas of concern and areas of good practice.

e Prepare QES Audit Reports


Prepare QES (and sustainability) reports that summarise the
levels of compliance, comment on trends, recommend areas for
improvement, identify good practice and lessons learnt and how
they should be applied across the programme.

6.8 Issue 1.0 - October 2009 MAX/OTC/PF/005/01


Programme Management Manual – recommended practice I P E M C
Closing

7 Closing Process Group


The Closing Process Group is the final phase of the Programme Integration Management process
and involves the formal acceptance of a product, service or benefit, and brings component
projects, and finally, a programme to a close.

7.1 Close Programme


Outline At the point where all component projects are completed, a
gateway review establishes that all the programme outcomes
have been delivered and that the programme needs to be brought

“ At the point where all


component projects are
completed, a gateway review
to a formal and controlled closure.

Programmes may also be terminated at any stage as a


consequence of changing circumstances; these may be funding
shortfalls, changing conditions making the programme
establishes that all the
unnecessary, or changing conditions making the programme not
programme outcomes have viable, i.e. the business case no longer justifies the investment.
Certain closing activities will also occur during the life of the
been delivered and that the
programme as component projects complete.
programme needs to be
brought to a formal and As the benefits resulting from a programme may take some time
to be fully realised there needs to be arrangements put in place
controlled closure. for a future review of the state of benefits realisation after the

” closure of the programme.

Figure 15 Programme Closure Report

When This process is used to close the programme life cycle.

By whom Programme Manager supported by the Programme Management


Team.

Inputs ■ Programme Brief


■ Programme Management Plan
■ Client’s governance guidelines
■ Performance Reports

7.1 Issue 1.0 - October 2009 MAX/OTC/PF/005/01


Programme Management Manual – recommended practice I P E M C
Closing

Tools and Techniques ■ Programme Management processes as set down in this


manual
■ Expert judgement

Process

c Review Programme Status


Ensure all component projects are complete and have delivered
their objectives. Review the performance of the programme and
establish the benefits realised.

d Update & Close Programme Information


Update all programme documentation and close all logs.

3 Identify Residual Issues & Actions


Identify any residual issues and actions outstanding from the
programme that need further attention by other programmes or
projects.

4 Finalise All Contracts


Confirm that all contracts have been formally closed and all
obligations have been fulfilled.

5 Archive Programme Information


Ensure the archiving of all programme information. Ensure
compliance with any corporate or legislative requirements for
storage of information.

6 Ensure Customer Support


As the products delivered by projects are transferred to a client’s
operations function, ensure that all necessary product support,
service management or customer support is in place. Ensure that
residual risks are properly identified and transferred to the client’s
operations.

7 Provide Lessons Learnt Knowledge Base


Assemble a lessons learnt knowledge base that can inform future
programme or project activity by the client.

8 Close Programme Budget


Carry out final budget reconciliation and prepare final financial
report.

9 Disband Programme Structure & Team


Arrange for the progressive termination of involvement of the
programme team members.

Dispose of Facilities & Equipment


In relation to the disbanding of the programme team dispose of all
the facilities and equipment that has been utilised to support the
programme.

An overview of the process is shown in Figure 16 overleaf.

7.2 Issue 1.0 - October 2009 MAX/OTC/PF/005/01


Programme Management Manual – recommended practice I P E M C
Closing

Ensure all projects are complete

Establish benefits realised


Identify benefits that require future
measurement
Review performance over programme life
1) Review cycle
Programme Status
Prepare closure report

Incorporate final information from projects


2) Update & Close
Final updates of programme logs
Programme
Information Review programme information to
identify any outstanding issues
Issue recommendadtions to client
3) Identify Confirm any further actions
Residual Issues & necessary
Actions Check all contractual obligations have been met

Check all contracts are formally closed


Incorporate final account information into
programme budget
4) Finalise All
Contracts
Record any outstanding issues

Confirm method of storage


Establish any client or legeslative
5) Archive
requirement for storage
Programme
Information Oversee archiving process Review with client arrangements on
completed projects
Inform client archiving is complete
Programme Closure Confirm any further support required

Report 6) Ensure
Arrange further support required
Customer Support Review support provided by contracts
Ensure proper transfer of residual risks
to operator
7) Provide Review lessons learnt logs from
Lessons Learnt completed projects
Knowledge Base Review knowledge base with client/
stakeholders
Assemble lessons learnt knowledge base
8) Close Review lessons learnt log from
Programme programme
Budget Prepare final financial statement
Review financial statement with client/
stakeholders

9) Disband Carry out final budget reconcilliation


Plan the timing of disbanding of
Programme
team
Structure & Team
Advise team members of
displacement timing
Advise any suppliers/consultants of
10) Dispose of Plan the timing of disposal of termination of contracts
Facilities & facilities etc Progressive disband programme
Equipment team
Advise suppliers of
termination arrangements
Manage disposal of facilities
etc.

Figure 16 Programme Closure

Outputs
 ■ Programme Closure Report including:
■ Benefits Realisation Final Report
■ Archived programme information
■ Client customer support structure
■ Closed Contracts
■ Lessons Learnt
■ Residual Actions Report
■ Closed Programme Budget

7.3 Issue 1.0 - October 2009 MAX/OTC/PF/005/01


tabs.qxp 21/10/2009 09:30 Page 5

5. Glossary

Glossary
Glossary
Glossary

Glossary
 The following is an extract from the PMI-BOK covering definition of terms
and acronyms that Mott MacDonald staff may encounter in undertaking
Project and Programme Management (PPM) activities. If terms cannot be
 found within this extract then reference should be made to the full


glossary contained within the PMI-BOK or alternatively the glossary within

 the APM-BOK.

1. Common Acronyms
AC Actual Cost
ACWP Actual Cost of Work Performed
AD Activity Description
ADM Arrow Diagramming Method
AE Apportioned Effort
AF Actual Finish date
AOA Activity-on-Arrow
AON Activity-on-Node
AS Actual Start date
BAC Budget at Completion
BCWP Budgeted Cost of Work Performed
BCWS Budgeted Cost of Work Scheduled
BOM Bill Of Materials
CA Control Account
CAP Control Account Plan
CCB Change Control Board
COQ Cost of Quality
CPF Cost-Plus-Fee
CPFF Cost-Plus-Fixed-Fee
CPI Cost Performance Index
CPIF Cost-Plus-Incentive-Fee
CPM Critical Path Method
CPPC Cost-Plus-Percentage of Cost

i Issue 2.0 - September 2009 MAX/OTC/PF/006/02


Glossary

CV Cost Variance
CWBS Contract Work Breakdown Structure
DD Data Date
DU Duration
DUR Duration
EAC Estimate at Completion
EF Early Finish date
EMV Expected Monetary Value
ES Early Start date
ETC Estimate to Complete
EV Earned Value
EVM Earned Value Management
EVT Earned Value Technique
FF Finish-to-Finish
FF Free Float
FFP Firm-Fixed-Price
FMEA Failure Mode and Effect Analysis
FPIF Fixed-Price-Incentive-Fee
FS Finish-to-Start
IFB Invitation for Bid
LF Late Finish date
LOE Level of Effort
LS Late Start date
OBS Organizational Breakdown Structure
OD Original Duration
PC Percent Complete
PCT Percent Complete
PDM Precedence Diagramming Method
PF Planned Finish date
PM Project Management
PM Project Manager
PMBOK® Project Management Body of Knowledge
PMIS Project Management Information System
PMO Program Management Office
PMO Project Management Office
PMP® Project Management Professional
PS Planned Start date
PSWBS Project Summary Work Breakdown Structure

ii Issue 2.0 - September 2009 MAX/OTC/PF/006/02


Glossary

PV Planned Value
QA Quality Assurance
QC Quality Control
RAM Responsibility Assignment Matrix
RBS Resource Breakdown Structure
RBS Risk Breakdown Structure
RD Remaining Duration
RFP Request for Proposal
RFQ Request for Quotation
SF Scheduled Finish date
SF Start-to-Finish
SOW Statement of Work
SPI Schedule Performance Index
SS Scheduled Start date
SS Start-to-Start
SV Schedule Variance
SWOT Strengths, Weaknesses, Opportunities, and Threats
TC Target Completion date Glossary
TF Target Finish date
TF Total Float
T&M Time and Material
TQM Total Quality Management
TS Target Start date
VE Value Engineering
WBS Work Breakdown Structure

2. Other Acronyms
The following additional acronyms are used within this manual:

APM Association for Project Management


OGC Office of Government Commerce
PMI Project Management Institute

iii Issue 2.0 - September 2009 MAX/OTC/PF/006/02


Glossary

3. Definitions
Many of the words defined here have broader, and in some cases different,
dictionary definitions. The definitions use the following conventions:

■ In some cases, a single glossary term consists of multiple words


(e.g., risk response planning).
■ In many cases, there are multiple, consecutive glossary terms
within a given definition. For example, duration estimate denotes
two separate glossary entries, one for “duration” and another for
“estimate.”
■ When synonyms are included, no definition is given and the reader
is directed to the preferred term (i.e., see preferred term).
■ Related terms that are not synonyms are cross-referenced at the
end of the definition (i.e., see also related term).

Acceptance Criteria. Those criteria, including performance requirements and


essential conditions, which must be met before project
deliverables are accepted.

Activity. A component of work performed during the course of a


project. See also schedule activity.

Activity Attributes. [Output/Input]. Multiple attributes associated with each


schedule activity that can be included within the activity
list. Activity attributes include activity codes, predecessor
activities, successor activities, logical relationships,
leads and lags, resource requirements, imposed dates,
constraints, and assumptions.

Activity Code. One or more numerical or text values that identify


characteristics of the work or in some way categorize the
schedule activity that allows filtering and ordering of
activities within reports.

Activity Definition. [Process]. The process of identifying the specific


schedule activities that need to be performed to produce
the various project deliverables.

Activity Description A short phrase or label for each schedule activity used in
(AD). conjunction with an activity identifier to differentiate that
project schedule activity from other schedule activities.
The activity description normally describes the scope of
work of the schedule activity.

Activity Identifier. A short unique numeric or text identification assigned to


each schedule activity to differentiate that project

iv Issue 2.0 - September 2009 MAX/OTC/PF/006/02


Glossary

activity* from other activities. Typically unique within any


one project schedule network diagram.

Activity List. [Output/Input]. A documented tabulation of schedule


activities that shows the activity description, activity
identifier, and a sufficiently detailed scope of work
description so project team members understand what
work is to be performed.

Activity-on-Arrow (AOA). See arrow diagramming method.

Activity-on-Node (AON). See precedence diagramming method.

Activity Resource [Process]. The process of estimating the types and


Estimating. quantities of resources required to perform each
schedule activity.

Activity Sequencing. [Process]. The process of identifying and documenting


dependencies among schedule activities.

Actual Cost (AC). Total costs actually incurred and recorded in


accomplishing work performed during a given time period
for a schedule activity or work breakdown structure
component. Actual cost can sometimes be direct labor
hours alone, direct costs alone, or all costs including
indirect costs. Also referred to as the actual cost of work
performed (ACWP). See also earned value management
and earned value technique.

Actual Cost of Work See actual cost (AC).


Performed (ACWP).

Actual Duration. The time in calendar units between the actual start date of
the schedule activity and either the data date of the
project schedule if the schedule activity is in progress or
the actual finish date if the schedule activity is complete.

Actual Finish Date (AF). The point in time that work actually ended on a schedule
activity. (Note: In some application areas, the schedule
activity is considered “finished” when work is
“substantially complete.”)

Actual Start Date (AS). The point in time that work actually started on a schedule
activity.

Analogous Estimating. [Technique]. An estimating technique that uses the


values of parameters, such as scope, cost, budget, and
duration or measures of scale such as size, weight, and
complexity from a previous, similar activity as the basis
for estimating the same parameter or measure for a future
activity. It is frequently used to estimate a parameter
when there is a limited amount of detailed information
about the project (e.g., in the early phases). Analogous
estimating is a form of expert judgment. Analogous
estimating is most reliable when the previous activities
are similar in fact and not just in appearance, and the
project team members preparing the estimates have the

v Issue 2.0 - September 2009 MAX/OTC/PF/006/02


Glossary

needed expertise.

Apportioned Effort (AE). Effort applied to project work that is not readily divisible
into discrete efforts for that work, but which is related in
direct proportion to measurable discrete work efforts.
Contrast with discrete effort.

Approved Change [Output/Input]. A change request that has been processed


Request. through the integrated change control process and
approved. Contrast with requested change

Arrow Diagramming [Technique]. A schedule network diagramming technique


Method (ADM). in which schedule activities are represented by arrows.
The tail of the arrow represents the start, and the head
represents the finish of the schedule activity. (The length
of the arrow does not represent the expected duration of
the schedule activity.) Schedule activities are connected
at points called nodes (usually drawn as small circles) to
illustrate the sequence in which the schedule activities
are expected to be performed. See also precedence
diagramming method.

As-of Date. See data date.

Assumptions Analysis. [Technique]. A technique that explores the accuracy of


assumptions and identifies risks to the project from
inaccuracy, inconsistency, or incompleteness of
assumptions.

Backward Pass. The calculation of late finish dates and late start dates for
the uncompleted portions of all schedule activities.
Determined by working backwards through the schedule
network logic from the project’s end date. The end date
may be calculated in a forward pass or set by the
customer or sponsor. See also schedule network
analysis.

Bar Chart. [Tool]. A graphic display of schedule-related information.


In the typical bar chart, schedule activities or work
breakdown structure components are listed down the left
side of the chart, dates are shown across the top, and
activity durations are shown as date-placed horizontal
bars. Also called a Gantt chart.

Baseline. The approved time phased plan (for a project, a work


breakdown structure component, a work package, or a
schedule activity), plus or minus approved project scope,
cost, schedule, and technical changes. Generally refers to
the current baseline, but may refer to the original or some
other baseline. Usually used with a modifier (e.g., cost
baseline, schedule baseline, performance measurement
baseline, technical baseline). See also performance
measurement baseline.

Bill of Materials (BOM). A documented formal hierarchical tabulation of the


physical assemblies, subassemblies, and components
needed to fabricate a product.

vi Issue 2.0 - September 2009 MAX/OTC/PF/006/02


Glossary

Bottom-up Estimating. [Technique]. A method of estimating a component of


work. The work is decomposed into more detail. An
estimate is prepared of what is needed to meet the
requirements of each of the lower, more detailed pieces
of work, and these estimates are then aggregated into a
total quantity for the component of work. The accuracy of
bottom-up estimating is driven by the size and complexity
of the work identified at the lower levels. Generally
smaller work scopes increase the accuracy of the
estimates.

Brainstorming. [Technique]. A general data gathering and creativity


technique that can be used to identify risks, ideas, or
solutions to issues by using a group of team members or
subject-matter experts. Typically, a brainstorming
session is structured so that each participant’s ideas are
recorded for later analysis.

Budget at Completion The sum of all the budget values established for the work
(BAC). to be performed on a project or a work breakdown
structure component or a schedule activity. The total
planned value for the project.

Budgeted Cost of Work See earned value (EV).


Performed (BCWP).

Budgeted Cost of Work See planned value (PV).


Scheduled (BCWS).

Buffer. See reserve.

Calendar Unit. The smallest unit of time used in scheduling the project.
Calendar units are generally in hours, days, or weeks, but
can also be in quarter years, months, shifts, or even in
minutes.

Change Control. Identifying, documenting, approving or rejecting, and


controlling changes to the project baselines*.

Change Control Board A formally constituted group of stakeholders responsible


(CCB). for reviewing, evaluating, approving, delaying, or
rejecting changes to the project, with all decisions and
recommendations being recorded.

Change Control System. [Tool]. A collection of formal documented procedures that


define how project deliverables and documentation will
be controlled, changed, and approved. In most
application areas the change control system is a subset
of the configuration management system.

Change Request. Requests to expand or reduce the project scope, modify


policies, processes, plans, or procedures, modify costs
or budgets, or revise schedules. Requests for a change
can be direct or indirect, externally or internally initiated,
and legally or contractually mandated or optional. Only
formally documented requested changes are processed
and only approved change requests are implemented.

vii Issue 2.0 - September 2009 MAX/OTC/PF/006/02


Glossary

Chart of Accounts. [Tool]. Any numbering system used to monitor project


costs* by category (e.g., labor, supplies, materials, and
equipment). The project chart of accounts is usually
based upon the corporate chart of accounts of the
primary performing organization. Contrast with code of
accounts.

Charter. See project charter.

Claim. A request, demand, or assertion of rights by a seller


against a buyer, or vice versa, for consideration,
compensation, or payment under the terms of a legally
binding contract, such as for a disputed change.

Closing Processes. [Process Group]. Those processes performed to formally


terminate all activities of a project or phase, and transfer
the completed product to others or close a cancelled
project.

Code of Accounts. [Tool]. Any numbering system used to uniquely identify


each component of the work breakdown structure.
Contrast with chart of accounts.

Common Cause. A source of variation that is inherent in the system and


predictable. On a control chart, it appears as part of the
random process variation (i.e., variation from a process
that would be considered normal or not unusual), and is
indicated by a random pattern of points within the control
limits. Also referred to as random cause. Contrast with
special cause.

Communication [Output/Input]. The document that describes: the


Management Plan. communications needs and expectations for the project;
how and in what format information will be
communicated; when and where each communication will
be made; and who is responsible for providing each type
of communication. A communication management plan
can be formal or informal, highly detailed or broadly
framed, based on the requirements of the project
stakeholders. The communication management plan is
contained in, or is a subsidiary plan of, the project
management plan.

Communications [Process]. The process of determining the information


Planning. and communications needs of the project stakeholders:
who they are, what is their level of interest and influence
on the project, who needs what information, when will
they need it, and how it will be given to them.

Configuration [Tool]. A subsystem of the overall project management


Management System. system. It is a collection of formal documented
procedures used to apply technical and administrative
direction and surveillance to: identify and document the
functional and physical characteristics of a product,
result, service, or component; control any changes to
such characteristics; record and report each change and
its implementation status; and support the audit of the

viii Issue 2.0 - September 2009 MAX/OTC/PF/006/02


Glossary

products, results, or components to verify conformance


to requirements. It includes the documentation, tracking
systems, and defined approval levels necessary for
authorizing and controlling changes. In most application
areas, the configuration management system includes the
change control system.

Contingency. See reserve.

Contingency Allowance. See reserve.

Contingency Reserve. [Output/Input]. The amount of funds, budget, or time


needed above the estimate to reduce the risk of overruns
of project objectives to a level acceptable to the
organization.

Contract Administration. [Process]. The process of managing the contract and the
relationship between the buyer and seller, reviewing and
documenting how a seller is performing or has performed
to establish required corrective actions and provide a
basis for future relationships with the seller, managing
contract related changes and, when appropriate,
managing the contractual relationship with the outside
buyer of the project.

Contract Closure. [Process]. The process of completing and settling the


contract, including resolution of any open items and
closing each contract.

Contract Management [Output/Input]. The document that describes how a


Plan. specific contract will be administered and can include
items such as required documentation delivery and
performance requirements. A contract management plan
can be formal or informal, highly detailed or broadly
framed, based on the requirements in the contract. Each
contract management plan is a subsidiary plan of the
project management plan.

Contract Statement of [Output/Input]. A narrative description of products,


Work (SOW). services, or results to be supplied under contract.

Contract Work [Output/Input]. A portion of the work breakdown structure


Breakdown Structure for the project developed and maintained by a seller
contracting to provide a subproject or project component.
(CWBS).

Control. [Technique]. Comparing actual performance with planned


performance, analyzing variances, assessing trends to
effect process improvements, evaluating possible
alternatives, and recommending appropriate corrective
action as needed.

Control Account (CA). [Tool]. A management control point where the integration
of scope, budget, actual cost, and schedule takes place,
and where the measurement of performance will occur.
Control accounts are placed at selected management
points (specific components at selected levels) of the

ix Issue 2.0 - September 2009 MAX/OTC/PF/006/02


Glossary

work breakdown structure. Each control account may


include one or more work packages, but each work
package may be associated with only one control
account. Each control account is associated with a
specific single organizational component in the
organizational breakdown structure (OBS). Previously
called a Cost Account. See also work package.

Control Account Plan [Tool]. A plan for all the work and effort to be performed
(CAP). in a control account. Each CAP has a definitive statement
of work, schedule, and time-phased budget. Previously
called a Cost Account Plan.

Control Chart [Tool]. A graphic display of process data over time and against
established control limits, and that has a centerline that
assists in detecting a trend of plotted values toward
either control limit.

Control Limits. The area composed of three standard deviations on either


side of the centerline, or mean, of a normal distribution of
data plotted on a control chart that reflects the expected
variation in the data. See also specification limits.

Corrective Action. Documented direction for executing the project work to


bring expected future performance of the project work in
line with the project management plan.

Cost Budgeting. [Process]. The process of aggregating the estimated


costs of individual activities or work packages to
establish a cost baseline.

Cost Control. [Process]. The process of influencing the factors that


create variances, and controlling changes to the project
budget.

Cost Estimating. [Process]. The process of developing an approximation of


the cost of the resources needed to complete project
activities*.

Cost Management Plan. [Output/Input]. The document that sets out the format and
establishes the activities and criteria for planning,
structuring, and controlling the project costs. A cost
management plan can be formal or informal, highly
detailed or broadly framed, based on the requirements of
the project stakeholders. The cost management plan is
contained in, or is a subsidiary plan, of the project
management plan.

Cost of Quality (COQ). [Technique]. Determining the costs incurred to ensure


quality. Prevention and appraisal costs (cost of
conformance) include costs for quality planning, quality
control (QC), and quality assurance to ensure compliance
to requirements (i.e., training, QC systems, etc.). Failure
costs (cost of non-conformance) include costs to rework
products, components, or processes that are non-
compliant, costs of warranty work and waste, and loss of
reputation.

x Issue 2.0 - September 2009 MAX/OTC/PF/006/02


Glossary

Cost Performance Index A measure of cost efficiency on a project. It is the ratio of


(CPI). earned value (EV) to actual costs (AC). CPI = EV divided
by AC. A value equal to or greater than one indicates a
favorable condition and a value less than one indicates
an unfavorable condition.

Cost-Plus-Fee (CPF). A type of cost reimbursable contract where the buyer


reimburses the seller for seller’s allowable costs for
performing the contract work and seller also receives a
fee calculated as an agreed upon percentage of the costs.
The fee varies with the actual cost.

Cost-Plus-Fixed-Fee A type of cost-reimbursable contract where the buyer


(CPFF) Contract. reimburses the seller for the seller’s allowable costs
(allowable costs are defined by the contract) plus a fixed
amount of profit (fee).

Cost-Plus-Incentive-Fee A type of cost-reimbursable contract where the buyer


(CPIF) Contract. reimburses the seller for the seller’s allowable costs
(allowable costs are defined by the contract), and the
seller earns its profit if it meets defined performance
criteria.

Cost-Plus-Percentage of See cost-plus-fee.


Cost (CPPC).

Cost-Reimbursable A type of contract involving payment (reimbursement) by


Contract. the buyer to the seller for the seller’s actual costs, plus a
fee typically representing seller’s profit. Costs are usually
classified as direct costs or indirect costs. Direct costs
are costs incurred for the exclusive benefit of the project,
such as salaries of full-time project staff. Indirect costs,
also called overhead and general and administrative cost,
are costs allocated to the project by the performing
organization as a cost of doing business, such as salaries
of management indirectly involved in the project, and
cost of electric utilities for the office. Indirect costs are
usually calculated as a percentage of direct costs. Cost-
reimbursable contracts often include incentive clauses
where, if the seller meets or exceeds selected project
objectives, such as schedule targets or total cost, then
the seller receives from the buyer an incentive or bonus
payment.

Cost Variance (CV). A measure of cost performance on a project. It is the


algebraic difference between earned value (EV) and actual
cost (AC). CV = EV minus AC. A positive value indicates a
favorable condition and a negative value indicates an
unfavorable condition.

Crashing. [Technique]. A specific type of project schedule


compression technique performed by taking action to
decrease the total project schedule duration* after
analyzing a number of alternatives to determine how to
get the maximum schedule duration compression for the
least additional cost. Typical approaches for crashing a
schedule include reducing schedule activity durations

xi Issue 2.0 - September 2009 MAX/OTC/PF/006/02


Glossary

and increasing the assignment of resources on schedule


activities. See schedule compression and see also fast
tracking.

Create WBS (Work [Process]. The process of subdividing the major project
Breakdown Structure). deliverables and project work into smaller, more
manageable components.

Critical Activity. Any schedule activity on a critical path in a project


schedule. Most commonly determined by using the
critical path method. Although some activities are
“critical,” in the dictionary sense, without being on the
critical path, this meaning is seldom used in the project
context.

Critical Chain Method. [Technique]. A schedule network analysis technique* that


modifies the project schedule to account for limited
resources. The critical chain method mixes deterministic
and probabilistic approaches to schedule network
analysis.

Critical Path. [Output/Input]. Generally, but not always, the sequence of


schedule activities that determines the duration of the
project. Generally, it is the longest path through the
project. However, a critical path can end, as an example,
on a schedule milestone that is in the middle of the
project schedule and that has a finish-no-later-than
imposed date schedule constraint. See also critical path
method.

Critical Path Method [Technique]. A schedule network analysis technique*


(CPM). used to determine the amount of scheduling flexibility
(the amount of float) on various logical network paths in
the project schedule network, and to determine the
minimum total project duration. Early start and finish
dates* are calculated by means of a forward pass, using a
specified start date. Late start and finish dates* are
calculated by means of a backward pass, starting from a
specified completion date, which sometimes is the
project early finish date determined during the forward
pass calculation.

Current Finish Date. The current estimate of the point in time when a schedule
activity will be completed, where the estimate reflects any
reported work progress. See also scheduled finish date
and baseline finish date.

Current Start Date. The current estimate of the point in time when a schedule
activity will begin, where the estimate reflects any
reported work progress. See also scheduled start date
and baseline start date.

Data Date (DD). The date up to or through which the project’s reporting
system has provided actual status and accomplishments.
In some reporting systems, the status information for the
data date is included in the past and in some systems the
status information is in the future. Also called as-of date

xii Issue 2.0 - September 2009 MAX/OTC/PF/006/02


Glossary

and time-now date.

Decision Tree Analysis. [Technique]. The decision tree is a diagram that describes
a decision under consideration and the implications of
choosing one or another of the available alternatives. It is
used when some future scenarios or outcomes of actions
are uncertain. It incorporates probabilities and the costs
or rewards of each logical path of events and future
decisions, and uses expected monetary value analysis to
help the organization identify the relative values of
alternate actions. See also expected monetary value
analysis.

Decomposition. [Technique]. A planning technique that subdivides the


project scope and project deliverables into smaller, more
manageable components, until the project work
associated with accomplishing the project scope and
providing the deliverables is defined in sufficient detail to
support executing, monitoring, and controlling the work.

Delphi Technique. [Technique]. An information gathering technique used as


a way to reach a consensus of experts on a subject.
Experts on the subject participate in this technique
anonymously. A facilitator uses a questionnaire to solicit
ideas about the important project points related to the
subject. The responses are summarized and are then re-
circulated to the experts for further comment. Consensus
may be reached in a few rounds of this process. The
Delphi technique helps reduce bias in the data and keeps
any one person from having undue influence on the
outcome.

Dependency. See logical relationship.

Design Review. [Technique]. A management technique used for


evaluating a proposed design to ensure that the design of
the system or product meets the customer requirements,
or to assure that the design will perform successfully, can
be produced, and can be maintained.

Discrete Effort. Work effort that is directly identifiable to the completion


of specific work breakdown structure components and
deliverables, and that can be directly planned and
measured. Contrast with apportioned effort.

Dummy Activity. A schedule activity of zero duration used to show a


logical relationship in the arrow diagramming method.
Dummy activities are used when logical relationships
cannot be completely or correctly described with
schedule activity arrows. Dummy activities are generally
shown graphically as a dashed line headed by an arrow.

Duration (DU or DUR). The total number of work periods (not including holidays
or other nonworking periods) required to complete a
schedule activity or work breakdown structure
component. Usually expressed as workdays or
workweeks. Sometimes incorrectly equated with elapsed

xiii Issue 2.0 - September 2009 MAX/OTC/PF/006/02


Glossary

time. Contrast with effort. See also original duration,


remaining duration, and actual duration.

Early Finish Date (EF). In the critical path method, the earliest possible point in
time on which the uncompleted portions of a schedule
activity (or the project) can finish, based on the schedule
network logic, the data date, and any schedule
constraints. Early finish dates can change as the project
progresses and as changes are made to the project
management plan.

Early Start Date (ES). In the critical path method, the earliest possible point in
time on which the uncompleted portions of a schedule
activity (or the project) can start, based on the schedule
network logic, the data date, and any schedule
constraints. Early start dates can change as the project
progresses and as changes are made to the project
management plan.

Earned Value (EV). The value of completed work expressed in terms of the
approved budget assigned to that work for a schedule
activity or work breakdown structure component. Also
referred to as the budgeted cost of work performed
(BCWP).

Earned Value A management methodology for integrating scope,


Management (EVM). schedule, and resources, and for objectively measuring
project performance and progress. Performance is
measured by determining the budgeted cost of work
performed (i.e., earned value) and comparing it to the
actual cost of work performed (i.e., actual cost). Progress
is measured by comparing the earned value to the
planned value.

Earned Value Technique [Technique]. A specific technique for measuring the


(EVT) performance of work for a work breakdown structure
component, control account, or project. Also referred to
as the earning rules and crediting method.

Effort. The number of labor units required to complete a


schedule activity or work breakdown structure
component. Usually expressed as staff hours, staff days,
or staff weeks. Contrast with duration.

Enterprise [Output/Input]. Any or all external environmental factors


Environmental Factors. and internal organizational environmental factors that
surround or influence the project’s success. These
factors are from any or all of the enterprises involved in
the project, and include organizational culture and
structure, infrastructure, existing resources, commercial
databases, market conditions, and project management
software.

Estimate. [Output/Input]. A quantitative assessment of the likely


amount or outcome. Usually applied to project costs,
resources, effort, and durations and is usually preceded
by a modifier (i.e., preliminary, conceptual, feasibility,

xiv Issue 2.0 - September 2009 MAX/OTC/PF/006/02


Glossary

order-of-magnitude, definitive). It should always include


some indication of accuracy (e.g., ±x percent).

Estimate at Completion [Output/Input]. The expected total cost of a schedule


(EAC). activity, a work breakdown structure component, or the
project when the defined scope of work will be
completed. EAC is equal to the actual cost (AC) plus the
estimate to complete (ETC) for all of the remaining work.
EAC = AC plus ETC. The EAC may be calculated based on
performance to date or estimated by the project team
based on other factors, in which case it is often referred
to as the latest revised estimate. See also earned value
technique and estimate to complete.

Estimate to Complete [Output/Input]. The expected cost needed to complete all


(ETC). the remaining work for a schedule activity, work
breakdown structure component, or the project. See also
earned value technique and estimate at completion.

Exception Report. Document that includes only major variations from the
plan (rather than all variations).

Executing Processes. [Process Group]. Those processes performed to


complete the work defined in the project management
plan to accomplish the project’s objectives defined in the
project scope statement.

Expected Monetary A statistical technique that calculates the average


Value (EMV). outcome when the future includes scenarios that may or
may not happen. A common use of this technique is
within decision tree analysis. Modeling and simulation are
recommended for cost and schedule risk analysis
because it is more powerful and less subject to
misapplication than expected monetary value analysis.

Expert Judgment. [Technique]. Judgment provided based upon expertise in


an application area, knowledge area, discipline, industry,
etc. as appropriate for the activity being performed. Such
expertise may be provided by any group or person with
specialized education, knowledge, skill, experience, or
training, and is available from many sources, including:
other units within the performing organization;
consultants; stakeholders, including customers;
professional and technical associations; and industry
groups.

Failure Mode and Effect [Technique]. An analytical procedure in which each


Analysis (FMEA). potential failure mode in every component of a product is
analyzed to determine its effect on the reliability of that
component and, by itself or in combination with other
possible failure modes, on the reliability of the product or
system and on the required function of the component; or
the examination of a product (at the system and/or lower
levels) for all ways that a failure may occur. For each
potential failure, an estimate is made of its effect on the
total system and of its impact. In addition, a review is
undertaken of the action planned to minimize the

xv Issue 2.0 - September 2009 MAX/OTC/PF/006/02


Glossary

probability of failure and to minimize its effects.

Fast Tracking. [Technique]. A specific project schedule compression


technique that changes network logic to overlap phases
that would normally be done in sequence, such as the
design phase and construction phase, or to perform
schedule activities in parallel. See schedule compression
and see also crashing.

Finish Date. A point in time associated with a schedule activity’s


completion. Usually qualified by one of the following:
actual, planned, estimated, scheduled, early, late,
baseline, target, or current.

Finish-to-Finish (FF). The logical relationship where completion of work of the


successor activity cannot finish until the completion of
work of the predecessor activity. See also logical
relationship.

Finish-to-Start (FS). The logical relationship where initiation of work of the


successor activity depends upon the completion of work
of the predecessor activity. See also logical relationship.

Firm-Fixed-Price (FFP) A type of fixed price contract where the buyer pays the
Contract. seller a set amount (as defined by the contract),
regardless of the seller’s costs.

Fixed-Price-Incentive- A type of contract where the buyer pays the seller a set
Fee (FPIF) Contract. amount (as defined by the contract), and the seller can
earn an additional amount if the seller meets defined
performance criteria.

Fixed-Price or Lump- A type of contract involving a fixed total price for a well-
Sum Contract. defined product. Fixed-price contracts may also include
incentives for meeting or exceeding selected project
objectives, such as schedule targets. The simplest form
of a fixed price contract is a purchase order.

Float. Also called slack. See total float and see also free float.

Flowcharting. [Technique]. The depiction in a diagram format of the


inputs, process actions, and outputs of one or more
processes within a system.

Forecasts. Estimates or predictions of conditions and events in the


project’s future based on information and knowledge
available at the time of the forecast. Forecasts are
updated and reissued based on work performance
information provided as the project is executed. The
information is based on the project’s past performance
and expected future performance, and includes
information that could impact the project in the future,
such as estimate at completion and estimate to complete.

Forward Pass. The calculation of the early start and early finish dates for
the uncompleted portions of all network activities. See
also schedule network analysis and backward pass.

xvi Issue 2.0 - September 2009 MAX/OTC/PF/006/02


Glossary

Free Float (FF). The amount of time that a schedule activity can be
delayed without delaying the early start of any
immediately following schedule activities. See also total
float.

Gantt Chart. See bar chart.

Hammock Activity. See summary activity.

Human Resource [Process]. The process of identifying and documenting


Planning. project roles, responsibilities and reporting relationships,
as well as creating the staffing management plan.

Imposed Date. A fixed date imposed on a schedule activity or schedule


milestone, usually in the form of a “start no earlier than”
and “finish no later than” date.

Influence Diagram. [Tool]. Graphical representation of situations showing


causal influences, time ordering of events, and other
relationships among variables and outcomes.

Influencer. Persons or groups that are not directly related to the


acquisition or use of the project’s product, but, due to
their position in the customer organization*, can
influence, positively or negatively, the course of the
project.

Initiating Processes. [Process Group]. Those processes performed to


authorize and define the scope of a new phase or project
or that can result in the continuation of halted project
work. A large number of the initiating processes are
typically done outside the project’s scope of control by
the organization, program, or portfolio processes and
those processes provide input to the project’s initiating
processes group.

Initiator. A person or organization that has both the ability and


authority to start a project.

Input. [Process Input]. Any item, whether internal or external to


the project that is required by a process before that
process proceeds. May be an output from a predecessor
process.

Inspection. [Technique]. Examining or measuring to verify whether an


activity, component, product, result or service conforms
to specified requirements.

Integrated. Interrelated, interconnected, interlocked, or meshed


components blended and unified into a functioning or
unified whole.

Integrated Change [Process]. The process of reviewing all change requests,


Control. approving changes and controlling changes to
deliverables and organizational process assets.

Issue. A point or matter in question or in dispute, or a point or


matter that is not settled and is under discussion or over

xvii Issue 2.0 - September 2009 MAX/OTC/PF/006/02


Glossary

which there are opposing views or disagreements.

Lag. [Technique]. A modification of a logical relationship that


directs a delay in the successor activity. For example, in a
finish-to-start dependency with a ten-day lag, the
successor activity cannot start until ten days after the
predecessor activity has finished. See also lead.

Late Finish Date (LF). In the critical path method, the latest possible point in
time that a schedule activity may be completed based
upon the schedule network logic, the project completion
date, and any constraints assigned to the schedule
activities without violating a schedule constraint or
delaying the project completion date. The late finish dates
are determined during the backward pass calculation of
the project schedule network.

Late Start Date (LS). In the critical path method, the latest possible point in
time that a schedule activity may begin based upon the
schedule network logic, the project completion date, and
any constraints assigned to the schedule activities
without violating a schedule constraint or delaying the
project completion date. The late start dates are
determined during the backward pass calculation of the
project schedule network.

Latest Revised See estimate at completion.


Estimate.

Lead. [Technique]. A modification of a logical relationship that


allows an acceleration of the successor activity. For
example, in a finish-to-start dependency with a ten-day
lead, the successor activity can start ten days before the
predecessor activity has finished. See also lag. A
negative lead is equivalent to a positive lag.

Lessons Learned. [Output/Input]. The learning gained from the process of


performing the project. Lessons learned may be identified
at any point. Also considered a project record, to be
included in the lessons learned knowledge base.

Lessons Learned A store of historical information and lessons learned


Knowledge Base. about both the outcomes of previous project selection
decisions and previous project performance.

Level of Effort (LOE). Support-type activity (e.g., seller or customer liaison,


project cost accounting, project management, etc.) that
does not readily lend itself to measurement of discrete
accomplishment. It is generally characterized by a
uniform rate of work performance over a period of time
determined by the activities supported.

Leveling. See resource leveling.

Life Cycle. See project life cycle.

Log. A document used to record and describe or denote

xviii Issue 2.0 - September 2009 MAX/OTC/PF/006/02


Glossary

selected items identified during execution of a process or


activity. Usually used with a modifier, such as issue,
quality control, action, or defect.

Logic. See network logic.

Logic Diagram. See project schedule network diagram.

Logical Relationship. A dependency between two project schedule activities, or


between a project schedule activity and a schedule
milestone. See also precedence relationship. The four
possible types of logical relationships are: Finish-to-
Start; Finish-to-Finish; Start-to-Start; and Start-to-Finish.

Master Schedule [Tool]. A summary-level project schedule that identifies


the major deliverables and work breakdown structure
components and key schedule milestones. See also
milestone schedule.

Matrix Organization. Any organizational structure in which the project


manager shares responsibility with the functional
managers for assigning priorities and for directing the
work of persons assigned to the project.

Methodology. A system of practices, techniques, procedures, and rules


used by those who work in a discipline.

Milestone. A significant point or event in the project. See also


schedule milestone.

Milestone Schedule. [Tool]. A summary-level schedule that identifies the major


schedule milestones. See also master schedule.

Monitoring and [Process Group]. Those processes performed to measure


Controlling Processes. and monitor project execution* so that corrective action
can be taken when necessary to control the execution of
the phase or project.

Monte Carlo Analysis. A technique that computes, or iterates, the project cost or
project schedule many times using input values selected
at random from probability distributions of possible costs
or durations, to calculate a distribution of possible total
project cost or completion dates.

Near-Critical Activity. A schedule activity that has low total float. The concept of
near-critical is equally applicable to a schedule activity or
schedule network path. The limit below which total float is
considered near critical is subject to expert judgment and
varies from project to project.

Network. See project schedule network diagram.

Network Analysis. See schedule network analysis.

Network Logic. The collection of schedule activity dependencies that


makes up a project schedule network diagram.

Network Loop. A schedule network path that passes the same node

xix Issue 2.0 - September 2009 MAX/OTC/PF/006/02


Glossary

twice. Network loops cannot be analyzed using traditional


schedule network analysis techniques such as critical
path method.

Network Open End. A schedule activity without any predecessor activities or


successor activities creating an unintended break in a
schedule network path. Network open ends are usually
caused by missing logical relationships.

Network Path. Any continuous series of schedule activities connected


with logical relationships in a project schedule network
diagram.

Networking. [Technique]. Developing relationships with persons who


may be able to assist in the achievement of objectives
and responsibilities.

Node. One of the defining points of a schedule network; a


junction point joined to some or all of the other
dependency lines. See also arrow diagramming method
and precedence diagramming method.

Opportunity. A condition or situation favorable to the project, a


positive set of circumstances, a positive set of events, a
risk that will have a positive impact on project objectives,
or a possibility for positive changes. Contrast with threat.

Organization Chart. [Tool]. A method for depicting interrelationships among a


group of persons working together toward a common
objective.

Organizational [Tool]. A hierarchically organized depiction of the project


Breakdown Structure organization arranged so as to relate the work packages
to the performing organizational units. (Sometimes OBS
(OBS). is written as Organization Breakdown Structure with the
same definition.)

Organizational Process [Output/Input]. Any or all process related assets, from any
Assets. or all of the organizations involved in the project that are
or can be used to influence the project’s success. These
process assets include formal and informal plans,
policies, procedures, and guidelines. The process assets
also include the organizations’ knowledge bases such as
lessons learned and historical information.

Original Duration (OD). The activity duration originally assigned to a schedule


activity and not updated as progress is reported on the
activity. Typically used for comparison with actual
duration and remaining duration when reporting schedule
progress.

Output. [Process Output]. A product, result, or service generated


by a process. May be an input to a successor process.

Parametric Estimating. [Technique]. An estimating technique that uses a


statistical relationship between historical data and other
variables (e.g., square footage in construction, lines of
code in software development) to calculate an estimate

xx Issue 2.0 - September 2009 MAX/OTC/PF/006/02


Glossary

for activity parameters, such as scope, cost, budget, and


duration. This technique can produce higher levels of
accuracy depending upon the sophistication and the
underlying data built into the model. An example for the
cost parameter is multiplying the planned quantity of
work to be performed by the historical cost per unit to
obtain the estimated cost.

Pareto Chart. [Tool]. A histogram, ordered by frequency of occurrence,


that shows how many results were generated by each
identified cause.

Path Convergence. The merging or joining of parallel schedule network paths


into the same node in a project schedule network
diagram. Path convergence is characterized by a
schedule activity with more than one predecessor
activity.

Path Divergence. Extending or generating parallel schedule network paths


from the same node in a project schedule network
diagram. Path divergence is characterized by a schedule
activity with more than one successor activity.

Percent Complete (PC or An estimate, expressed as a percent, of the amount of


PCT). work that has been completed on an activity or a work
breakdown structure component.

Performance An approved plan for the project work against which


Measurement Baseline. project execution is compared and deviations are
measured for management control. The performance
measurement baseline typically integrates scope,
schedule, and cost parameters of a project, but may also
include technical and quality parameters.

Performance Reporting. [Process]. The process of collecting and distributing


performance information. This includes status reporting,
progress measurement, and forecasting.

Performance Reports. [Output/Input]. Documents and presentations that provide


organized and summarized work performance
information, earned value management parameters and
calculations, and analyses of project work progress and
status. Common formats for performance reports include
bar charts, S-curves, histograms, tables, and project
schedule network diagram showing current schedule
status.

Planned Finish Date See scheduled finish date.


(PF).

Planned Start Date (PS). See scheduled start date.

Planned Value (PV). The authorized budget assigned to the scheduled work to
be accomplished for a schedule activity or work
breakdown structure component. Also referred to as the
budgeted cost of work scheduled (BCWS).

xxi Issue 2.0 - September 2009 MAX/OTC/PF/006/02


Glossary

Planning Package. A WBS component below the control account with known
work content but without detailed schedule activities. See
also control account.

Planning Processes. [Process Group]. Those processes performed to define


and mature the project scope, develop the project
management plan, and identify and schedule the project
activities* that occur within the project.

Portfolio. A collection of projects or programs and other work that


are grouped together to facilitate effective management of
that work to meet strategic business objectives. The
projects or programs of the portfolio may not necessarily
be interdependent or directly related.

Portfolio Management. [Technique]. The centralized management of one or more


portfolios, which includes identifying, prioritizing,
authorizing, managing, and controlling projects,
programs, and other related work, to achieve specific
strategic business objectives.

Position Description. [Tool]. An explanation of a project team member’s roles


and responsibilities.

Practice. A specific type of professional or management activity


that contributes to the execution of a process and that
may employ one or more techniques and tools.

Precedence [Technique]. A schedule network diagramming technique


Diagramming Method in which schedule activities are represented by boxes (or
nodes). Schedule activities are graphically linked by one
(PDM). or more logical relationships to show the sequence in
which the activities are to be performed.

Precedence The term used in the precedence diagramming method


Relationship. for a logical relationship. In current usage, however,
precedence relationship, logical relationship, and
dependency are widely used interchangeably, regardless
of the diagramming method used.

Predecessor Activity. The schedule activity that determines when the logical
successor activity can begin or end.

Preventive Action. Documented direction to perform an activity that can


reduce the probability of negative consequences
associated with project risks*.

Probability and Impact [Tool]. A common way to determine whether a risk is


Matrix. considered low, moderate, or high by combining the two
dimensions of a risk: its probability of occurrence, and its
impact on objectives if it occurs.

Procurement [Output/Input]. Those documents utilized in bid and


Documents. proposal activities, which include buyer’s Invitation for
Bid, Invitation for Negotiations, Request for Information,
Request for Quotation, Request for Proposal and seller’s
responses.

xxii Issue 2.0 - September 2009 MAX/OTC/PF/006/02


Glossary

Procurement [Output/Input]. The document that describes how


Management Plan. procurement processes from developing procurement
documentation through contract closure will be managed.

Product Life Cycle. A collection of generally sequential, non-overlapping


product phases* whose name and number are determined
by the manufacturing and control needs of the
organization. The last product life cycle phase for a
product is generally the product’s deterioration and
death. Generally, a project life cycle is contained within
one or more product life cycles.

Program. A group of related projects managed in a coordinated way


to obtain benefits and control not available from
managing them individually. Programs may include
elements of related work outside of the scope of the
discrete projects in the program.

Program Management. The centralized coordinated management of a program to


achieve the program's strategic objectives and benefits.

Program Management The centralized management of a particular program or


Office (PMO). programs such that corporate benefit is realized by the
sharing of resources, methodologies, tools, and
techniques, and related high-level project management
focus. See also project management office.

Progressive Elaboration [Technique]. Continuously improving and detailing a plan


as more detailed and specific information and more
accurate estimates become available as the project
progresses, and thereby producing more accurate and
complete plans that result from the successive iterations
of the planning process.

Project. A temporary endeavor undertaken to create a unique


product, service, or result.

Project Calendar. A calendar of working days or shifts that establishes


those dates on which schedule activities are worked and
nonworking days that determine those dates on which
schedule activities are idle. Typically defines holidays,
weekends and shift hours. See also resource calendar.

Project Charter. [Output/Input]. A document issued by the project initiator


or sponsor that formally authorizes the existence of a
project, and provides the project manager with the
authority to apply organizational resources to project
activities.

Project Initiation. Launching a process that can result in the authorization


and scope definition of a new project.

Project Life Cycle. A collection of generally sequential project phases whose


name and number are determined by the control needs of
the organization or organizations involved in the project.
A life cycle can be documented with a methodology.

Project Management The application of knowledge, skills, tools, and

xxiii Issue 2.0 - September 2009 MAX/OTC/PF/006/02


Glossary

(PM). techniques to project activities* to meet the project


requirements.

Project Management An inclusive term that describes the sum of knowledge


Body of Knowledge. within the profession of project management. As with
other professions such as law, medicine, and accounting,
the body of knowledge rests with the practitioners and
academics that apply and advance it. The complete
project management body of knowledge includes proven
traditional practices that are widely applied and
innovative practices that are emerging in the profession.
The body of knowledge includes both published and
unpublished material. The PMBOK is constantly evolving.

Project Management [Tool]. An information system consisting of the tools and


Information System. techniques used to gather, integrate, and disseminate the
outputs of project management processes. It is used to
support all aspects of the project from initiating through
closing, and can include both manual and automated
systems.

Project Management An identified area of project management defined by its


Knowledge Area. knowledge requirements and described in terms of its
component processes, practices, inputs, outputs, tools,
and techniques.

Project Management An organizational body or entity assigned various


Office (PMO). responsibilities related to the centralized and coordinated
management of those projects under its domain. The
responsibilities of a PMO can range from providing
project management support functions to actually being
responsible for the direct management of a project. See
also program management office.

Project Management [Output/Input]. A formal, approved document that defines


Plan. how the projected is executed, monitored and controlled.
It may be summary or detailed and may be composed of
one or more subsidiary management plans and other
planning documents.

Project Management One of the 44 processes, unique to project management


Process. and described in the PMBOK® Guide.

Project Management A logical grouping of the project management processes


Process Group. described in the PMBOK® Guide. The project
management process groups include initiating
processes, planning processes, executing processes,
monitoring and controlling processes, and closing
processes. Collectively, these five groups are required for
any project, have clear internal dependencies, and must
be performed in the same sequence on each project,
independent of the application area or the specifics of the
applied project life cycle. Project management process
groups are not project phases.

Project Management A person certified as a PMP® by the Project Management


Professional (PMP®). Institute (PMI®).

xxiv Issue 2.0 - September 2009 MAX/OTC/PF/006/02


Glossary

Project Management [Tool]. A class of computer software applications


Software. specifically designed to aid the project management team
with planning, monitoring, and controlling the project,
including: cost estimating, scheduling, communications,
collaboration, configuration management, document
control, records management, and risk analysis.

Project Management [Tool]. The aggregation of the processes, tools,


System. techniques, methodologies, resources, and procedures to
manage a project. The system is documented in the
project management plan and its content will vary
depending upon the application area, organizational
influence, complexity of the project, and the availability of
existing systems. A project management system, which
can be formal or informal, aids a project manager in
effectively guiding a project to completion. A project
management system is a set of processes and the related
monitoring and control functions that are consolidated
and combined into a functioning, unified whole.

Project Management The members of the project team who are directly
Team. involved in project management activities. On some
smaller projects, the project management team may
include virtually all of the project team members.

Project Manager (PM). The person assigned by the performing organization to


achieve the project objectives*.

Project Organization [Output/Input]. A document that graphically depicts the


Chart. project team members and their interrelationships for a
specific project.

Project Phase. A collection of logically related project activities*, usually


culminating in the completion of a major deliverable.
Project phases (also called phases) are mainly completed
sequentially, but can overlap in some project situations.
Phases can be subdivided into subphases and then
components; this hierarchy, if the project or portions of
the project are divided into phases, is contained in the
work breakdown structure. A project phase is a
component of a project life cycle. A project phase is not a
project management process group*.

Project Process Groups. The five process groups required for any project that
have clear dependencies and that are required to be
performed in the same sequence on each project,
independent of the application area or the specifics of the
applied project life cycle. The process groups are
initiating, planning, executing, monitoring and
controlling, and closing.

Project Schedule. [Output/Input]. The planned dates for performing


schedule activities and the planned dates for meeting
schedule milestones.

Project Schedule [Output/Input]. Any schematic display of the logical


Network Diagram. relationships among the project schedule activities.

xxv Issue 2.0 - September 2009 MAX/OTC/PF/006/02


Glossary

Always drawn from left to right to reflect project work


chronology.

Project Scope. The work that must be performed to deliver a product,


service, or result with the specified features and
functions.

Project Scope [Output/Input]. The document that describes how the


Management Plan. project scope will be defined, developed, and verified and
how the work breakdown structure will be created and
defined, and that provides guidance on how the project
scope will be managed and controlled by the project
management team. It is contained in or is a subsidiary
plan of the project management plan. The project scope
management plan can be informal and broadly framed, or
formal and highly detailed, based on the needs of the
project.

Project Scope [Output/Input]. The narrative description of the project


Statement. scope, including major deliverables, project objectives,
project assumptions, project constraints, and a statement
of work, that provides a documented basis for making
future project decisions and for confirming or developing
a common understanding of project scope among the
stakeholders. The definition of the project scope – what
needs to be accomplished.

Project Summary Work [Tool]. A work breakdown structure for the project that is
Breakdown Structure only developed down to the subproject level of detail
within some legs of the WBS, and where the detail of
(PSWBS). those subprojects are provided by use of contract work
breakdown structures.

Project Team. All the project team members, including the project
management team, the project manager and, for some
projects, the project sponsor.

Project Team Members. The persons who report either directly or indirectly to the
project manager, and who are responsible for performing
project work as a regular part of their assigned duties.

Projectized Any organizational structure in which the project


Organization. manager has full authority to assign priorities, apply
resources, and direct the work of persons assigned to the
project.

Qualitative Risk [Process]. The process of prioritizing risks for


Analysis. subsequent further analysis or action by assessing and
combining their probability of occurrence and impact.

Quality Management [Output/Input]. The quality management plan describes


Plan. how the project management team will implement the
performing organization’s quality policy. The quality
management plan is a component or a subsidiary plan of
the project management plan. The quality management
plan may be formal or informal, highly detailed, or broadly
framed, based on the requirements of the project.

xxvi Issue 2.0 - September 2009 MAX/OTC/PF/006/02


Glossary

Quality Planning. [Process]. The process of identifying which quality


standards are relevant to the project and determining how
to satisfy them.

Quantitative Risk [Process]. The process of numerically analyzing the effect


Analysis. on overall project objectives of identified risks.

Regulation. Requirements imposed by a governmental body. These


requirements can establish product, process or service
characteristics—including applicable administrative
provisions—that have government-mandated compliance.

Reliability. The probability of a product performing its intended


function under specific conditions for a given period of
time.

Remaining Duration The time in calendar units, between the data date of the
(RD). project schedule and the finish date of a schedule activity
that has an actual start date. This represents the time
needed to complete a schedule activity where the work is
in progress.

Request for Information. A type of procurement document whereby the buyer


requests a potential seller to provide various pieces of
information related to a product or service or seller
capability.

Request for Proposal A type of procurement document used to request


(RFP). proposals from prospective sellers of products or
services. In some application areas, it may have a
narrower or more specific meaning.

Request for Quotation A type of procurement document used to request price


(RFQ). quotations from prospective sellers of common or
standard products or services. Sometimes used in place
of request for proposal and in some application areas, it
may have a narrower or more specific meaning.

Request Seller [Process]. The process of obtaining information,


Responses. quotations, bids, offers, or proposals, as appropriate.

Requested Change. [Output/Input]. A formally documented change request


that is submitted for approval to the integrated change
control process. Contrast with approved change request.

Reserve. A provision in the project management plan to mitigate


cost and/or schedule risk. Often used with a modifier
(e.g., management reserve, contingency reserve) to
provide further detail on what types of risk are meant to
be mitigated. The specific meaning of the modified term
varies by application area.

Reserve Analysis. [Technique]. An analytical technique to determine the


essential features and relationships of components in the
project management plan to establish a reserve for the
schedule duration, budget, estimated cost, or funds for a
project.

xxvii Issue 2.0 - September 2009 MAX/OTC/PF/006/02


Glossary

Residual Risk. A risk that remains after risk responses have been
implemented.

Resource. Skilled human resources (specific disciplines either


individually or in crews or teams), equipment, services,
supplies, commodities, materiel, budgets, or funds.

Resource Breakdown A hierarchical structure of resources by resource


Structure (RBS). category and resource type used in resource leveling
schedules and to develop resource-limited schedules,
and which may be used to identify and analyze project
human resource assignments.

Resource Calendar. A calendar of working days and nonworking days that


determines those dates on which each specific resource
is idle or can be active. Typically defines resource
specific holidays and resource availability periods. See
also project calendar.

Resource-Constrained See resource-limited schedule.


Schedule.

Resource Histogram. A bar chart showing the amount of time that a resource is
scheduled to work over a series of time periods.
Resource availability may be depicted as a line for
comparison purposes. Contrasting bars may show actual
amounts of resource used as the project progresses.

Resource Levelling. [Technique]. Any form of schedule network analysis in


which scheduling decisions (start and finish dates) are
driven by resource constraints (e.g., limited resource
availability or difficult-to-manage changes in resource
availability levels).

Resource-Limited A project schedule whose schedule activity, scheduled


Schedule. start dates and scheduled finish dates reflect expected
resource availability. A resource-limited schedule does
not have any early or late start or finish dates. The
resource-limited schedule total float is determined by
calculating the difference between the critical path
method late finish date* and the resource-limited
scheduled finish date. Sometimes called resource-
constrained schedule. See also resource leveling.

Resource Planning. See activity resource estimating.

Responsibility [Tool]. A structure that relates the project organizational


Assignment Matrix breakdown structure to the work breakdown structure to
help ensure that each component of the project’s scope
(RAM). of work is assigned to a responsible person.

Retainage. A portion of a contract payment that is withheld until


contract completion to ensure full performance of the
contract terms.

Risk. An uncertain event or condition that, if it occurs, has a


positive or negative effect on a project’s objectives. See
also risk category and risk breakdown structure.

xxviii Issue 2.0 - September 2009 MAX/OTC/PF/006/02


Glossary

Risk Acceptance. [Technique]. A risk response planning technique* that


indicates that the project team has decided not to change
the project management plan to deal with a risk, or is
unable to identify any other suitable response strategy.

Risk Avoidance. [Technique]. A risk response planning technique* for a


threat that creates changes to the project management
plan that are meant to either eliminate the risk or to
protect the project objectives from its impact. Generally,
risk avoidance involves relaxing the time, cost, scope, or
quality objectives.

Risk Breakdown [Tool]. A hierarchically organized depiction of the


Structure (RBS). identified project risks* arranged by risk category and
subcategory that identifies the various areas and causes
of potential risks. The risk breakdown structure is often
tailored to specific project types.

Risk Category. A group of potential causes of risk. Risk causes may be


grouped into categories such as technical, external,
organizational, environmental, or project management. A
category may include subcategories such as technical
maturity, weather, or aggressive estimating. See also risk
breakdown structure.

Risk Database. A repository that provides for the collection,


maintenance, and analysis of data gathered and used in
the risk management processes.

Risk Identification. [Process]. The process of determining which risks might


affect the project and documenting their characteristics.

Risk Management Plan. [Output/Input]. The document describing how project risk
management will be structured and performed on the
project. It is contained in or is a subsidiary plan of the
project management plan. The risk management plan can
be informal and broadly framed, or formal and highly
detailed, based on the needs of the project. Information in
the risk management plan varies by application area and
project size. The risk management plan is different from
the risk register that contains the list of project risks, the
results of risk analysis, and the risk responses.

Risk Management [Process]. The process of deciding how to approach,


Planning. plan, and execute risk management activities for a
project.

Risk Mitigation. [Technique]. A risk response planning technique*


associated with threats that seeks to reduce the
probability of occurrence or impact of a risk to below an
acceptable threshold.

Risk Monitoring and [Process]. The process of tracking identified risks,


Control.. monitoring residual risks, identifying new risks, executing
risk response plans, and evaluating their effectiveness
throughout the project life cycle.

Risk Register. [Output/Input]. The document containing the results of

xxix Issue 2.0 - September 2009 MAX/OTC/PF/006/02


Glossary

the qualitative risk analysis, quantitative risk analysis,


and risk response planning. The risk register details all
identified risks, including description, category, cause,
probability of occurring, impact(s) on objectives,
proposed responses, owners, and current status. The risk
register is a component of the project management plan.

Risk Response Planning. [Process]. The process of developing options and actions
to enhance opportunities and to reduce threats to project
objectives.

Risk Transference. [Technique]. A risk response planning technique* that


shifts the impact of a threat to a third party, together with
ownership of the response.

Rolling Wave Planning. [Technique]. A form of progressive elaboration planning


where the work to be accomplished in the near term is
planned in detail at a low level of the work breakdown
structure, while the work far in the future is planned at a
relatively high level of the work breakdown structure, but
the detailed planning of the work to be performed within
another one or two periods in the near future is done as
work is being completed during the current period.

Root Cause Analysis. [Technique]. An analytical technique used to determine


the basic underlying reason that causes a variance or a
defect or a risk. A root cause may underlie more than one
variance or defect or risk.

Schedule. See project schedule and see also schedule model.

Schedule Activity. A discrete scheduled component of work performed


during the course of a project. A schedule activity
normally has an estimated duration, an estimated cost,
and estimated resource requirements. Schedule activities
are connected to other schedule activities or schedule
milestones with logical relationships, and are
decomposed from work packages.

Schedule Analysis. See schedule network analysis.

Schedule Compression. [Technique]. Shortening the project schedule duration


without reducing the project scope. See also crashing
and fast tracking.

Schedule Control. [Process]. The process of controlling changes to the


project schedule.

Schedule Development. [Process]. The process of analyzing schedule activity


sequences, schedule activity durations, resource
requirements, and schedule constraints to create the
project schedule.

Schedule Management [Output/Input]. The document that establishes criteria and


Plan. the activities for developing and controlling the project
schedule. It is contained in, or is a subsidiary plan of, the
project management plan. The schedule management
plan may be formal or informal, highly detailed or broadly

xxx Issue 2.0 - September 2009 MAX/OTC/PF/006/02


Glossary

framed, based on the needs of the project.

Schedule Milestone. A significant event in the project schedule, such as an


event restraining future work or marking the completion
of a major deliverable. A schedule milestone has zero
duration. Sometimes called a milestone activity. See also
milestone.

Schedule Model. [Tool]. A model used in conjunction with manual methods


or project management software to perform schedule
network analysis to generate the project schedule for use
in managing the execution of a project. See also project
schedule.

Schedule Network [Technique]. The technique of identifying early and late


Analysis. start dates*, as well as early and late finish dates*, for the
uncompleted portions of project schedule activities. See
also critical path method, critical chain method, what-if
analysis, and resource leveling.

Schedule Performance A measure of schedule efficiency on a project. It is the


Index (SPI). ratio of earned value (EV) to planned value (PV). The SPI =
EV divided by PV. An SPI equal to or greater than one
indicates a favorable condition and a value of less than
one indicates an unfavorable condition. See also earned
value management.

Schedule Variance (SV). A measure of schedule performance on a project. It is the


algebraic difference between the earned value (EV) and
the planned value (PV). SV = EV minus PV. See also
earned value management.

Scheduled Finish Date The point in time that work was scheduled to finish on a
(SF). schedule activity. The scheduled finish date is normally
within the range of dates delimited by the early finish date
and the late finish date. It may reflect resource leveling of
scarce resources. Sometimes called planned finish date.

Scheduled Start Date The point in time that work was scheduled to start on a
(SS). schedule activity. The scheduled start date is normally
within the range of dates delimited by the early start date
and the late start date. It may reflect resource leveling of
scarce resources. Sometimes called planned start date.

Scope. The sum of the products, services, and results to be


provided as a project. See also project scope and product
scope.

Scope Baseline. See baseline.

Scope Change. Any change to the project scope. A scope change almost
always requires an adjustment to the project cost or
schedule.

Scope Control. [Process]. The process of controlling changes to the


project scope.

Scope Creep. Adding features and functionality (project scope) without

xxxi Issue 2.0 - September 2009 MAX/OTC/PF/006/02


Glossary

addressing the effects on time, costs, and resources, or


without customer approval.

Scope Definition. [Process]. The process of developing a detailed project


scope statement as the basis for future project decisions.

Scope Planning. [Process]. The process of creating a project scope


management plan.

Scope Verification. [Process]. The process of formalizing acceptance of the


completed project deliverables.

S-Curve. Graphic display of cumulative costs, labor hours,


percentage of work, or other quantities, plotted against
time. The name derives from the S-like shape of the curve
(flatter at the beginning and end, steeper in the middle)
produced on a project that starts slowly, accelerates, and
then tails off. Also a term for the cumulative likelihood
distribution that is a result of a simulation, a tool of
quantitative risk analysis.

Secondary Risk. A risk that arises as a direct result of implementing a risk


response.

Sensitivity Analysis. A quantitative risk analysis and modeling technique used


to help determine which risks have the most potential
impact on the project. It examines the extent to which the
uncertainty of each project element affects the objective
being examined when all other uncertain elements are
held at their baseline values. The typical display of results
is in the form of a tornado diagram.

Should-Cost Estimate. An estimate of the cost of a product or service used to


provide an assessment of the reasonableness of a
prospective seller’s proposed cost.

Simulation. A simulation uses a project model that translates the


uncertainties specified at a detailed level into their
potential impact on objectives that are expressed at the
level of the total project. Project simulations use
computer models and estimates of risk, usually
expressed as a probability distribution of possible costs
or durations at a detailed work level, and are typically
performed using Monte Carlo analysis.

Slack. See total float and free float.

Special Cause. A source of variation that is not inherent in the system, is


not predictable, and is intermittent. It can be assigned to
a defect in the system. On a control chart, points beyond
the control limits, or non-random patterns within the
control limits, indicate it. Also referred to as assignable
cause. Contrast with common cause.

Specification. A document that specifies, in a complete, precise,


verifiable manner, the requirements, design, behavior, or
other characteristics of a system, component, product,
result, or service and, often, the procedures for

xxxii Issue 2.0 - September 2009 MAX/OTC/PF/006/02


Glossary

determining whether these provisions have been


satisfied. Examples are: requirement specification, design
specification, product specification, and test
specification.

Specification Limits. The area, on either side of the centerline, or mean, of data
plotted on a control chart that meets the customer’s
requirements for a product or service. This area may be
greater than or less than the area defined by the control
limits. See also control limits.

Sponsor. The person or group that provides the financial


resources, in cash or in kind, for the project.

Staffing Management [Process]. The document that describes when and how
Plan. human resource requirements will be met. It is contained
in, or is a subsidiary plan of, the project management
plan. The staffing management plan can be informal and
broadly framed, or formal and highly detailed, based on
the needs of the project. Information in the staffing
management plan varies by application area and project
size.

Stakeholder. Persons and organizations such as customers, sponsors,


performing organization and the public, that are actively
involved in the project, or whose interests may be
positively or negatively affected by execution or
completion of the project. They may also exert influence
over the project and its deliverables.

Standard. A document established by consensus and approved by a


recognized body that provides, for common and repeated
use, rules, guidelines or characteristics for activities or
their results, aimed at the achievement of the optimum
degree of order in a given context.

Start Date. A point in time associated with a schedule activity’s start,


usually qualified by one of the following: actual, planned,
estimated, scheduled, early, late, target, baseline, or
current.

Start-to-Finish (SF). The logical relationship where completion of the


successor schedule activity is dependent upon the
initiation of the predecessor schedule activity. See also
logical relationship.

Start-to-Start (SS). The logical relationship where initiation of the work of the
successor schedule activity depends upon the initiation
of the work of the predecessor schedule activity. See also
logical relationship.

Statement of Work A narrative description of products, services, or results to


(SOW). be supplied.

Strengths, Weaknesses, This information gathering technique examines the


Opportunities and project from the perspective of each project’s strengths,
weaknesses, opportunities, and threats to increase the
Threats (SWOT)

xxxiii Issue 2.0 - September 2009 MAX/OTC/PF/006/02


Glossary

Analysis. breadth of the risks considered by risk management.

Subnetwork. A subdivision (fragment) of a project schedule network


diagram, usually representing a subproject or a work
package. Often used to illustrate or study some potential
or proposed schedule condition, such as changes in
preferential schedule logic or project scope.

Subphase. A subdivision of a phase.

Subproject. A smaller portion of the overall project created when a


project is subdivided into more manageable components
or pieces. Subprojects are usually represented in the
work breakdown structure. A subproject can be referred
to as a project, managed as a project, and acquired from
a seller. May be referred to as a subnetwork in a project
schedule network diagram.

Successor. See successor activity.

Successor Activity. The schedule activity that follows a predecessor activity,


as determined by their logical relationship.

Summary Activity. A group of related schedule activities aggregated at some


summary level, and displayed/reported as a single activity
at that summary level. See also subproject and
subnetwork.

System. An integrated set of regularly interacting or


interdependent components created to accomplish a
defined objective, with defined and maintained
relationships among its components, and the whole
producing or operating better than the simple sum of its
components. Systems may be either physically process
based or management process based, or more commonly
a combination of both. Systems for project management
are composed of project management processes,
techniques, methodologies, and tools operated by the
project management team.

Target Completion Date An imposed date that constrains or otherwise modifies


(TC). the schedule network analysis.

Target Finish Date (TF). The date that work is planned (targeted) to finish on a
schedule activity.

Target Schedule. A schedule adopted for comparison purposes during


schedule network analysis, which can be different from
the baseline schedule. See also baseline.

Target Start Date (TS). The date that work is planned (targeted) to start on a
schedule activity.

Task. A term for work whose meaning and placement within a


structured plan for project work varies by the application
area, industry, and brand of project management
software.

xxxiv Issue 2.0 - September 2009 MAX/OTC/PF/006/02


Glossary

Technical Performance [Technique]. A performance measurement technique that


Measurement. compares technical accomplishments during project
execution to the project management plan’s schedule of
planned technical achievements. It may use key technical
parameters of the product produced by the project as a
quality metric. The achieved metric values are part of the
work performance information.

Template. A partially complete document in a predefined format that


provides a defined structure for collecting, organizing
and presenting information and data. Templates are often
based upon documents created during prior projects.
Templates can reduce the effort needed to perform work
and increase the consistency of results.

Threat. A condition or situation unfavorable to the project, a


negative set of circumstances, a negative set of events, a
risk that will have a negative impact on a project objective
if it occurs, or a possibility for negative changes. Contrast
with opportunity.

Three-Point Estimate. [Technique]. An analytical technique that uses three cost


or duration estimates to represent the optimistic, most
likely, and pessimistic scenarios. This technique is
applied to improve the accuracy of the estimates of cost
or duration when the underlying activity or cost
component is uncertain.

Threshold. A cost, time, quality, technical, or resource value used as


a parameter, and which may be included in product
specifications. Crossing the threshold should trigger
some action, such as generating an exception report.

Time and Material (T&M) A type of contract that is a hybrid contractual


Contract. arrangement containing aspects of both cost-
reimbursable and fixed-price contracts. Time and material
contracts resemble cost-reimbursable type arrangements
in that they have no definitive end, because the full value
of the arrangement is not defined at the time of the award.
Thus, time and material contracts can grow in contract
value as if they were cost-reimbursable-type
arrangements. Conversely, time and material
arrangements can also resemble fixed-price
arrangements. For example, the unit rates are preset by
the buyer and seller, when both parties agree on the rates
for the category of senior engineers.

Time-Now Date. See data date.

Time-Scaled Schedule [Tool]. Any project schedule network diagram drawn in


Network Diagram. such a way that the positioning and length of the
schedule activity represents its duration. Essentially, it is
a bar chart that includes schedule network logic.

Tool. Something tangible, such as a template or software


program, used in performing an activity to produce a
product or result.

xxxv Issue 2.0 - September 2009 MAX/OTC/PF/006/02


Glossary

Total Float (TF). The total amount of time that a schedule activity may be
delayed from its early start date without delaying the
project finish date, or violating a schedule constraint.
Calculated using the critical path method technique and
determining the difference between the early finish dates
and late finish dates. See also free float.

Total Quality [Technique]. A common approach to implementing a


Management (TQM). quality improvement program within an organization.

Trend Analysis. [Technique]. An analytical technique that uses


mathematical models to forecast future outcomes based
on historical results. It is a method of determining the
variance from a baseline of a budget, cost, schedule, or
scope parameter by using prior progress reporting
periods’ data and projecting how much that parameter’s
variance from baseline might be at some future point in
the project if no changes are made in executing the
project.

Triggers. Indications that a risk has occurred or is about to occur.


Triggers may be discovered in the risk identification
process and watched in the risk monitoring and control
process. Triggers are sometimes called risk symptoms or
warning signs.

Triple Constraint. A framework for evaluating competing demands. The


triple constraint is often depicted as a triangle where one
of the sides or one of the corners represent one of the
parameters being managed by the project team.

Validation. [Technique]. The technique of evaluating a component or


product during or at the end of a phase or project to
ensure it complies with the specified requirements.
Contrast with verification.

Value Engineering (VE). A creative approach used to optimize project life cycle
costs, save time, increase profits, improve quality,
expand market share, solve problems, and/or use
resources more effectively.

Variance. A quantifiable deviation, departure, or divergence away


from a known baseline or expected value.

Variance Analysis. [Technique]. A method for resolving the total variance in


the set of scope, cost, and schedule variables into
specific component variances that are associated with
defined factors affecting the scope, cost, and schedule
variables.

Verification. [Technique]. The technique of evaluating a component or


product at the end of a phase or project to assure or
confirm it satisfies the conditions imposed. Contrast with
validation.

Virtual Team. A group of persons with a shared objective who fulfill


their roles with little or no time spent meeting face to

xxxvi Issue 2.0 - September 2009 MAX/OTC/PF/006/02


Glossary

face. Various forms of technology are often used to


facilitate communication among team members. Virtual
teams can be comprised of persons separated by great
distances.

War Room. A room used for project conferences and planning, often
displaying charts of cost, schedule status, and other key
project data.

Work. Sustained physical or mental effort, exertion, or exercise


of skill to overcome obstacles and achieve an objective.

Work Authorization [Technique]. A permission and direction, typically written,


to begin work on a specific schedule activity or work
package or control account. It is a method for sanctioning
project work to ensure that the work is done by the
identified organization, at the right time, and in the proper
sequence.

Work Authorization [Tool]. A subsystem of the overall project management


System. system. It is a collection of formal documented
procedures that defines how project work will be
authorized (committed) to ensure that the work is done by
the identified organization, at the right time, and in the
proper sequence. It includes the steps, documents,
tracking system, and defined approval levels needed to
issue work authorizations.

Work Breakdown [Output/Input]. A deliverable-oriented hierarchical


Structure (WBS). decomposition of the work to be executed by the project
team to accomplish the project objectives and create the
required deliverables. It organizes and defines the total
scope of the project. Each descending level represents an
increasingly detailed definition of the project work. The
WBS is decomposed into work packages. The deliverable
orientation of the hierarchy includes both internal and
external deliverables. See also work package, control
account, contract work breakdown structure, and project
summary work breakdown structure.

Work Breakdown An entry in the work breakdown structure that can be at


Structure. any level.

Work Breakdown [Output/Input]. A document that describes each


Structure Diction. component in the work breakdown structure (WBS). For
each WBS component, the WBS dictionary includes a
brief definition of the scope or statement of work, defined
deliverable(s), a list of associated activities, and a list of
milestones. Other information may include: responsible
organization, start and end dates, resources required, an
estimate of cost, charge number, contract information,
quality requirements, and technical references to
facilitate performance of the work.

Work Item. Term no longer in common usage. See activity and


schedule activity.

xxxvii Issue 2.0 - September 2009 MAX/OTC/PF/006/02


Glossary

Work Package. A deliverable or project work component at the lowest


level of each branch of the work breakdown structure.
The work package includes the schedule activities and
schedule milestones required to complete the work
package deliverable or project work component. See also
control account.

Work Performance [Output/Input]. Information and data, on the status of the


Information. project schedule activities being performed to
accomplish the project work, collected as part of the
direct and manage project execution processes*.
Information includes: status of deliverables;
implementation status for change requests, corrective
actions, preventive actions, and defect repairs;
forecasted estimates to complete; reported percent of
work physically completed; achieved value of technical
performance measures; start and finish dates of schedule
activities.

Workaround. [Technique]. A response to a negative risk that has


occurred. Distinguished from contingency plan in that a
workaround is not planned in advance of the occurrence
of the risk event.

xxxviii Issue 2.0 - September 2009 MAX/OTC/PF/006/02

You might also like