Proj Man

Project management handbook
Preface
Preface
Businesses prosper by adding value. Value is added by implementing projects. Evidence from
benchmarking shows that management of projects in all types of organisations could be
significantly improved.
This handbook describes an extensive range of project management techniques and processes.
The guidance is as relevant to a small project as it is to a major global project spanning many
years. However, the Project manager may need to tailor the techniques to suit the project. The
successful Project manager knows how to apply the techniques and methodology, so that it
benefits the project and is never perceived as getting in the way. The best Project Managers
know what to apply and when.
The BT Projects Group have produced this handbook. We have many years of experience of
managing projects. We are also active members of the Association for Project Management and
provide a representative to the British Standards Institute to help write the project management
standards for example, BS6079 - Guide to Project Management. As founder members of the
Project Management Benchmarking Network, we have drawn heavily on many of the insights
and techniques developed from that activity.
We hold Corporate Membership of the Association for Project

Management.
We are founder members of the Project Management

Benchmarking Network
As some of the diagrams in this handbook are quite complex,

Plain English Campaign’s crystal mark does not apply to the
diagrams.
Project Management Handbook

© British Telecommunications plc 2000
Table of contents
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . - Page 1
Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . - Page 3
Project management overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . - Page 5
Project management process . . . . . . . . . . . . . . . . . . . . . . . . . . . . - Page 11
Initiating . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . - Page 13
Planning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . - Page 15
Implementing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . - Page 17
Controlling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . - Page 19
Closing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . - Page 21
Supporting processes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . - Page 23
Project lifecycle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . - Page 27
Key events and activities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . - Page 28
Project roles and responsibilities . . . . . . . . . . . . . . . . . . . . . . . - Page 33
Inception phase . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . - Page 37
Feasibility phase . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . - Page 41
Definition phase . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . - Page 45
Development and installation phases . . . . . . . . . . . . . . . . . . . - Page 51
Pilot phase . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . - Page 55
Roll-out phase . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . - Page 59
Post-implementation phase . . . . . . . . . . . . . . . . . . . . . . . . . . . - Page 63
Tools and techniques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . - Page 67
Planning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . - Page 69
Work breakdown structure (WBS) . . . . . . . . . . . . . . . . . . - Page 70
Estimating . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . - Page 73
Network diagram and analysis . . . . . . . . . . . . . . . . . . . . . - Page 76
Milestones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . - Page 83
Gantt chart . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . - Page 83
Material requirements schedule . . . . . . . . . . . . . . . . . . . . - Page 83
Benefits Plan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . - Page 83
Risk management plan . . . . . . . . . . . . . . . . . . . . . . . . . . . . - Page 84
Cost plan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . - Page 84
Monitoring and control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . - Page 87
Earned value management . . . . . . . . . . . . . . . . . . . . . . . . . . . - Page 97
An example of earned value management . . . . . . . . . . . - Page 105
Change control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . - Page 125
Managing issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . - Page 127
Risk management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . - Page 131
Communications management . . . . . . . . . . . . . . . . . . . . . . . - Page 151
Mobilisation and maintaining momentum . . . . . . . . . . . . . . . - Page 155
Managing stakeholders . . . . . . . . . . . . . . . . . . . . . . . . . . . . . - Page 161
Value management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . - Page 165
Managing requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . - Page 171
Procurement and contract management . . . . . . . . . . . . . . . . - Page 175
Configuration management . . . . . . . . . . . . . . . . . . . . . . . . . - Page 179
Managing benefits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . - Page 181

Table of contents
Environmental management . . . . . . . . . . . . . . . . . . . . . . . . . - Page 185

Managing health and safety . . . . . . . . . . . . . . . . . . . . . . . . . - Page 187
Project quality management . . . . . . . . . . . . . . . . . . . . . . . . . - Page 189
Project health-check software . . . . . . . . . . . . . . . . . . . . . . . . - Page 191
Documents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . - Page 195
Project file . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . - Page 199
Client requirements definition . . . . . . . . . . . . . . . . . . . . . - Page 201
Feasibility report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . - Page 205
Project requirements definition . . . . . . . . . . . . . . . . . . . . - Page 207
Business case . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . - Page 213
Technical and operational specifications . . . . . . . . . . . . - Page 217
Work package agreements . . . . . . . . . . . . . . . . . . . . . . . - Page 219
Project closure report . . . . . . . . . . . . . . . . . . . . . . . . . . . - Page 221
Final review report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . - Page 223

Introduction
Introduction
In the last issue of this handbook we wrote about the importance of consistent and professional
project management. This new edition updates the methodology recommended for use across the
company. We take account of lessons we learned from benchmarking project management
practice and co-authoring BS6079 - Guide to project management.
This portable version of the handbook will help spread best practice and add to more successful
project outcomes. However, the project management intranet site will continue to provide extra
relevant information.
Its use is not mandatory, but it describes an approach that experience has shown works well and
which has scored consistently well in external benchmarking checks.
Getting value from the handbook

This handbook will be valuable if you are clear about what is being asked of you. Your answers
to the following questions will help to see if you are ready to use this methodology.
v What am I trying to achieve?
v How will the company and its customers benefit?
v Who wants the project done and why?
v Who will be affected and in what way?
v Who are the main players and why are they important?
You must have the answers before you set up the project.
Scope
The handbook is arranged in six main sections.
Brief explanations of the terms used in project
Definitions
management.
A brief introduction to the main ideas behind project
Project management overview
management
Project management process A quick guide to the main processes
The roles and responsibilities of the client, project
Project lifecycle manager, contractors or work package managers and
users for each phase.
Tools and techniques Project management tools and techniques.
Documents The purpose and content of the main documents.
Project Management Handbook - Page 1

Introduction
Divisional and local procedures

Because of the wide range of projects there may be circumstances when you need more detailed
and specific processes. In these cases, you should use local processes that compliment these
guidelines. Examples include procedures to cover areas such as approving and authorising
projects, controlling changes, or registering projects.
Project Management Handbook- Page 2

Definitions
Definitions
Client
The person the project is carried out for, the person taking the biggest risk who represents the
organisation sponsoring the project. The project manager reports to this person.
Change control
Monitoring, recording and assessing changes to the scope or timing of a project with the aim of
making all those involved fully aware of the effects on cost, time and performance before making
the changes.
Contractor
A person with responsibility for leading and managing a part of a project to achieve specific aims
that have been agreed with the project manager. See work package manager.
Deliverables
The items produced during and at the end of a project.
Earned value
The value of work done at any given point in a project, measured by how much was planned to
be spent to achieve it.
Programme
A group of related projects that are managed in a co-ordinated way to achieve a common
purpose to support the strategic aims of the business. This allows us to create benefits over and
above those possible if we managed the projects separately.
Programme Manager
The person who has responsibility for managing a programme to achieve benefits that meet the
strategic aims of the business.
Project
A sequence of related activities with a definite start and finish. These activities are carried out to
meet a specific set of requirements to a set cost and time and level of performance.
Project control board
The organisation which makes strategic decisions for the project, usually chaired by the client. It
represents the business, technical and user areas of the project.
Project lifecycle
A sequence of phases through which a project progresses from the original idea through to the
end of the project.

Definitions
Project management
Planning, directing and controlling all aspects of a project and motivating all those involved, to
make sure the aims of the project are achieved on time and to the cost and level of performance
set. Project management is different from other types of management in that projects only last
for a set period of time. As a result you need to build and motivate a team knowing that it will
usually be split up at the end of the project.
Project manager
The person who is responsible for leading and managing a project to achieve specific aims.
Project phase
One of a series of steps in a project that together make up the project lifecycle.
Risk
An uncertain event or set of circumstances that could affect achieving the project aims.
Stakeholder
A person or group who has an interest in the outcome of a project and the environment in which
the project applies.
Users
Groups or people who will be using the project deliverables to produce the benefits expected
from the project.
Value management
Analysing the functions of every part of a project with the focus on getting rid of and changing
anything that adds cost without adding to its function.
Work breakdown structure and work packages
The hierarchy of the work of a project, showing all the work needed to complete the project.
The lowest level in the hierarchy is made up of work packages where we can identify resources,
estimate time and costs and define deliverables. Specific people (contractors or work package
managers) own the work packages and they are responsible for defining all the activities to
complete them.
Work package manager
A person with responsibility for leading and managing a part of a project to achieve specific aims
that have been agreed with the project manager. See Contractor

Characteristics of projects
Projects are different from other work in organisations because they have a defined start and
finish. They bring about changes and deliver benefits to the business. When the project is
complete, the project manager hands over to the client who is then responsible for achieving or
improving on the benefits delivered by the project. It is this achievement of benefits that decides
whether the project is successful.
Projects:
v are unique and tend to have significant novel features;
v are risky and have an inbuilt uncertainty;
v are usually managed by a temporary team;
v can change as the work progresses; and
v are influenced by events inside and outside the organisation.
Projects are not trivial.
Characteristics of project management

Successful project management includes:
v setting clear aims;
v planning what work needs to be done;
v organising people and work;
v motivating people;
v implementing the plan;
v monitoring the work, comparing with the plan and taking action to keep on plan;
v measuring and testing the project deliverables making sure they meet the requirements
agreed with the client; and
v introducing the deliverables and making sure that they can be used to achieve the benefits.
The client is responsible for setting aims and limits within which the project has to be delivered.
They must set realistic criteria and make sure that adequate plans are produced. Senior managers
set the proposed spending limits, and test whether the expected benefits being put forward are
realistic and acceptable.
Good and adequate planning reduces the risk of changes which may lead to overspending and
delays when you are implementing the project.
Projects usually span functional and departmental boundaries. As a result you must set up an
appropriate organisation to run the project. This will usually be a temporary team led by the
project manager supported by team members with appropriate skills. Your authority needs to be
clear, all of the project stakeholders must be aware of this.

As members of the team are usually taken out of their usual jobs, motivation is very important,
particularly as the project gets nearer to its end.
During implementation the client and other members of the project control board should make
sure that proper operational procedures and controls are in place and being used and that the
proposed deliverables continue to meet the business needs. These people should insist on reports
at agreed intervals which, at least, show the current status of the project and the forecast for
finishing it in terms of cost and time. These reports will be the basis of reviews carried out with
the project manager.
The client must give clear details of the benefits and make sure that there are plans in place to
achieve them. The business case should show how you will measure and track the benefits and
who will be responsible for achieving these benefits. The project manager must make sure that
there is a detailed benefits delivery plan agreed with the client and users before handing over the
project.
Project lifecycle
We use the term ‘project lifecycle’ to describe the way in which a project progresses through a
sequence of phases from an initial idea to the end of the project.
Phases are defined by completing one or more deliverables. At the end of a phase, you should
review the deliverables and project performance and decide:
v whether to continue to the next phase;
v rework part of the phase; or
v close the project.
The lifecycle usually used in projects is made up of ten phases - eight before the project is
completed and two after.
Inception Project life-cycle phases
Feasibility
Definition
Development
Installation
Pilot
Roll-out
Post implementation
Operation
Termination
In some types of project not all phases will apply.

Project roles and responsibilities

Client
Every project must have a client who sets the requirements, focusing on what the business needs.
Responsibilities include:
v justifying and obtaining the funding;
v deciding on the relative importance of time, cost and performance
v making sure that the project is still relevant;
v championing the project (in other words, taking every chance to help the project);
v choosing and supporting the project manager;
v agreeing important documents and phases; and
v delivering benefits.
The ideal client should be politically and commercially aware and make themselves freely
available to the Project manager. They should be respected by senior managers and the project
team.
Project manager
The person who has the responsibility for managing the project to achieve specific aims. At any
one time there can only be one project manager. However, the role can be carried out by
different people at different phases of the project because the skills needed may change.
Responsibilities include:
v identifying and achieving deliverables;
v planning and carrying out the project;
v organising, motivating and leading the project team;
v communicating with everyone involved in the project;
v monitoring the progress of work packages;
v controlling change;
v managing risk; and
v reporting to the client on progress.
The ideal project manager should be open and flexible, good at coming up with ideas and
providing reasoned arguments. They should be keen but that should be balanced with some
scepticism and caution.
Project control board (PCB)

This is the organisation which makes strategic decisions about the project. The board is usually
chaired by the client, with members from the business, technical and user areas of the project. An
active and effective board should sort out issues which are outside the project manager’s
authority and control.

Contractors or work package managers

Contractors or work package managers are responsible for a clearly defined part of a project,
made up of one or more work packages or activities.
Their responsibilities include:
v planning to the level of detail needed;
v providing the right resources at the right time;
v delivering work packages according to specifications, timescales and costs agreed with the
project manager;
v meeting the reporting requirements agreed with the project manager; and
v providing guidance in their area of expertise.
Users
Those who use the deliverables of the project are responsible for providing advice on operational
requirements as early as possible in the project.
Their responsibilities include:
v agreeing acceptance criteria for deliverables;
v letting the client know about any changes which may affect the project;
v preparing the operational environment ready to receive the project deliverables; and
v using the deliverables in operations.
Benefits of project management

Good project management has proved to be the only successful way of managing change in
organisations. It allows:
v resources to be directed to the most desirable objectives;
v management’s attention to be focused on specific tasks;
v continuing commitment to deliver results from those who want to carry out the project; and
v quality and safety to be built into projects at the design stage.
Working as part of a project team is recognised as a very good way of developing individual and
team skills.
Programmes and programme management

A programme is a group of related projects that are managed in a co-ordinated way to achieve a
common purpose to support the strategic aims of the business. This allows us to create benefits
over and above those possible if we managed the projects separately.
As much of the work of the company is carried out through projects there will always be an
overlap in areas such as shared resources and aims and areas which logically depend on each
other. Programme management involves co-ordinating and managing these projects which have
a common focus.

Programmes are the bridge between projects and the strategic aims of the organisation.
Programme management includes dealing with the portfolio of projects and making sure that the
projects’ deliverables work together in operations. These aspects are outside the scope of
project management.
As projects are parts of programmes all of the tools and techniques we describe in this handbook
are relevant. To manage programmes successfully, you need to understand the techniques
thoroughly.


Project management process

The project management process applies as much to starting up a joint venture or introducing a
flexible rewards scheme as it does to designing, manufacturing and installing a
telecommunications system.
Good project management will reduce the chance of failure in terms of time, cost and
performance but this is unlikely to be achieved by just using the process alone. Managing people
and teamwork are the most important parts in managing a project successfully.
The project management process includes:
v initiating;
v planning;
v implementing;
v controlling; and
v closing.
It is supported by important other processes which include requirements management, risk
management, procurement management and value management.
The processes are repetitious and are carried out in any phase and at any time during the project.
Initiate Plan
Supporting
processes
Value management
Procurement Communications
Risk Requirements
Close Health and
Configuration Implement
safety
Quality
Control

Initiating
Initiating brings a new project about or starts a new phase of an existing project. Depending on
the project, there may be formal ways of doing this that link the project to the ongoing work of
the organisation or informal methods with just enough work carried out to meet the approval
requirements.
Planning
Planning involves producing a plan that describes project activities in terms of who does what,
when, at what cost, and to what specification with enough detail to meet your control
requirements. A meaningful project plan must be available at the start of implementation and it
must be regularly updated after that.
Implementing
Implementing is concerned with carrying out the activities in the project plan. You need to
concentrate on motivating and supporting the project team members and managing the
relationship with suppliers.
Controlling
This focuses on using the plan and the other support processes to make sure that the project goes
according to the client’s requirements.
Closing
Closing means making sure that, after the aims of any phase have been achieved or the client
decides to end the project, you write the appropriate documents and make sure that you record
useful information. The client must formally accept the deliverables after making sure that all
work has been completed correctly and satisfactorily. If you are using external contractors or
work package managers there will be specific procedures for closure.

Project management process - Initiating
Initiating
You carry out these processes in any phase and at any
time during the project.
Initiate Plan
Client’s requirements
Supporting The client is responsible for making sure that projects are
processes
Value man agement directed by the needs of the business.
Pro cureme nt Communicati ons
Require ments
Close
Risk
Health and
Configu ration Implement A client requirements definition gives details of the
safe ty
Qu alit y
business aims and outlines the product or service to be
Control delivered. However, you need to know enough about the
requirements before you can start planning and assessing
risks.
Business plans
You should clearly identify projects, the products they deliver and their expected benefits in the
business and strategic plans of the organisation.
Choosing a project
The project should support the client’s business strategy. How you chose a project should
depend on the benefits the project will deliver, for example, financial return, market share or the
public’s view of the project. You should refer to the results of previous decisions and
performance of previous projects. If initiation involves approval for the next phase of the
project, you must have information about the results of previous phases.
Authorisation to proceed from the client

The client must give you authorisation and the funding to go ahead with the project. The client
can authorise the whole project, a phase or a stage to cover specific pieces of work. Further
authorisation will usually depend on satisfactory progress and continuing to meet the business
objectives.
Establish project organisation

Organising the project involves forming the project team and getting together the procedures you
will use to manage the project. You will need to set up and lead an organisation made up of:
v a project support team;
v contractors or work package managers; and
v users.

Project management process - Initiating
In return for clear statements of your needs, you need people to be committed to timescales,
costs, quality and performance and achieving benefits.
The project team will agree the processes for managing the project, for example, change control,
managing issues, managing requirements, meeting agendas and so on. You should make sure
that roles, responsibilities and authority levels of team members are agreed and understood.

Project management process - Planning
Planning
You will carry out the planning processes in any phase
and at any time during the project.
Initiate Plan Develop a project work breakdown

Supporting
processes
Value man agement
structure
Pro cureme nt
Risk
Communicati ons
Require ments
You can break down the work of a project into a
Close Configu ration Implement
Health and
safe ty
Qu alit y
structured ‘hierarchy’, known as the work breakdown
structure (WBS). Work packages are at the lowest level
Control
in the hierarchy. The principle applies to any type of
project.
Identify named individuals for project

activities
You should identify contractors or work package managers for each work package and they will
answer to you for all activities within the work package.
Specify work packages

The contractor or work package manager for each work package should produce documents
showing:
v the work to be done;
v the individual responsible;
v what is to be produced or delivered by when and at what cost; and
v performance and acceptance criteria of deliverables.
Balance time, cost, specification and risk

You need to continually balance time, cost, performance and risk taking account of your client’s
priorities. As planning progresses you will have more information about costs, timescales and
risks. You should analyse this information to get a good understanding of the overall cost of the
project, schedule and risks.
Getting commitments to do project work

All contractors or work package managers should commit to do the work by signing a work
package agreement. The agreement shows that the work can be completed to the specification
shown in the project plan. Any work a contractor or work package manager asks a supplier or
subcontractor to do needs a similar commitment from the supplier or subcontractor. You should
be aware of the legal obligations relating to contracts and supplier selection.

Finalising agreements and plan
When you are satisfied that the plan represents the best chance of meeting the client's
requirements, you can formalise the agreements with contractors or work package managers.
How you do this will vary depending on the nature of the agreement and the project, for
example, whether it is internal or external to the organisation. Agreement means that the
contractor or work package manager agrees to provide resources as planned and you agree to
release funds, usually on condition that deliverables are successfully completed.
The project manager should be authorised by the client to agree to changes to the plan within set
limits. Any changes that fall outside these limits should be referred back to the client.
You can now use the agreed and authorised project plan to monitor and control progress of the
project.

Project management process - Implementing
Implementing
You will carry out the implementing processes in any
phase and at any time during the project.
Initiate Plan Introduction

You must make sure that the work in the project plan is
Supporting
processes
Value man agement
Pro cureme nt
carried out. You need to co-ordinate reports from
Communicati ons
Close
Risk
Implement
Health and
contractors or work package managers and analyse the
Require ments
Configu ration
safe ty
information provided. You must manage the relationship
Qu alit y
Control between contractors or work package managers to make

sure that everyone involved understands the effect of
changes, risks and so on and develops appropriate
responses. You must co-ordinate the project reports for the client as agreed in the project
requirements. You are also responsible for the security of the project plan and any information
linked to it.
Manage risks
You should assess risks throughout the project. By assessing and analysing risks, you can
identify those activities where you need to take other action to reduce any risk. You will
normally need the client's agreement if you need to follow other courses of action to manage an
otherwise unavoidable risk. You must gain the support of contractors or work package
managers for any new course of action you take. You should include any activities in the project
plan.
Motivate the team

Projects aim to achieve a definite end result so it follows that contractors or work package
managers are usually focused on project aims. You should always be seen to recognise and
reward good performance. If you communicate well with the rest of the project team, it can be a
powerful source of motivation. Well-informed people work better than those who are working in
the dark.
Negotiate
An essential requirement is the ability to negotiate effectively. Any concessions or changes
before a contract is signed will be cheaper and easier to agree than when the project has moved
into implementation. Once the project has started, the pressure on you to complete to time and
cost is continuous and contractors or work package managers may try to exploit the situation by
asking for extra money and resources to keep the project to time. You can deal with this by
making sure, at the beginning, that the scope of work in each activity or work package is clearly
defined and agreed.

Project management process - Implementing
Contractors or work package managers will be looking for opportunities to exploit the situation
and profit from the project work. You must try and convince contractors or work package
managers that they are all responsible for the success of the project and that meeting the aims of
the project becomes part of their own personal aims.

Project management process - Controlling
Controlling
You will carry out the controlling processes in any phase
and at any time during the project.
Initiate Plan
Control the project plan
All projects can change. Success generally depends on
Supporting
processes
Value man agementhow good the planning is in the first place and then how
Communicati ons
Pro cureme nt
Risk well you manage the changes. You must make sure that
Require ments
Close Implement Configu ration
Health and
safe ty you communicate changes to project aims and consequent
Qu alit y
changes to activities and work packages clearly and that

Control
you update the plans to reflect these changes. Depending
upon the effect of the change, contractors or work
package managers will need to agree the change with you.
In turn, you may have to agree the change with your client. You are responsible for the project
plan and must make sure that any changes to the plan are controlled.
Changes to the plan should follow the normal planning process. You must make sure that the
current version of the project plan reflects the existing contractual requirements in terms of time,
cost, performance and specification.
Managing project budgets

You must make sure that budgets reflect the funding and cash flow throughout the project,
particularly when the project covers more than one financial year. If you do not do this, project
funding may not be available when you need it or it may affect the budgets in other parts of the
organisation. You need to release funds to contractors or work package managers so that
project work may start. You should also make allowances for unexpected problems or small
changes in plans by holding back some of the project budget. If there is a lot of uncertainty, you
should set limits on spending for the work. The contractors or work package managers are
responsible for making sure that the costs involved in carrying out work for the project are
placed against the correct activity in the project work breakdown structure. You should make
sure that all costs for the project can be audited.
Instruct work to start, continue or stop

The structured nature of the tasks in the plan allows you to control the project by releasing or
stopping work. You may need to review the project at specific milestones throughout long-lead
time projects, to give the client and yourself the opportunity to review progress and decide
whether to continue or stop work. You will start, continue or stop work by releasing funds for
clearly specified purposes. Usually the client is responsible for formally ending the project,
including ending it early.

Project management process - Controlling
Monitor progress
Monitoring and analysing project information should allow you to deal with problems at an early
stage and take advantage of opportunities that will benefit the project.
You should set up good communications with contractors or work package managers otherwise
problems can grow out of control.
Contractors or work package managers should meet your regular reporting requirements and
submit exception reports if the progress of work moves significantly away from the plan.
Exception reports should not only explain the reasons for doing better than or failing to achieve
agreed performance, but also describe how the situation can be dealt with if necessary.
Contractors or work package managers must answer to you for completing work on time, and to
cost and specifications. They should also let you about any operational issues that may affect
other work packages. Contractors or work package managers should keep work package
information up to date, let you know about activities likely to become critical and provide new
risk assessments. Similarly, you are responsible for keeping contractors or work package
managers briefed on the status of the whole project.

Project management process - Closing
Closing
You will carry out the closing processes in any phase and
at any time during the project.
Initiate Plan
Review project documents
Supporting
processes The project team should review project performance
Value man agement
Pro cureme nt Communicati ons documents, including the planning documents that set the
Risk Require ments
Close Health and
safe ty
Configu ration Implement framework for measuring performance. Documents
Qu alit y
describing the deliverables or product of the project must
Control be available for review during closure.
Project archives
You must follow any policies on keeping information for all project documents.
Lessons learned
You should keep details of any changes, the reasons for them and the reasons behind any action
you have taken. You need to also pass this on to other parts of the organisation.
Contract documents
The contract documents that you should keep include:
v the contract itself along with all supporting schedules;
v requested and approved contract changes;
v any technical documents developed by the suppliers;
v supplier performance reports;
v testing and acceptance documents;
v financial documents such as invoices and payment records; and
v the results of any contract-related inspections.
Procurement audits
You should review the procurement process from planning through to contract administration.
You need to identify successes and failures that are worth passing on to other parts of the
organisation.
Formal acceptance and closure

You should pass formal documents showing that the client has accepted the deliverables of the
project or a phase of the project to the project team.
At the end of the project the person or organisation responsible for contract administration
should give all suppliers formal notice that the contract has been completed. Requirements for
formal acceptance and closure are usually laid out in the contract.

Project management process - Closing
The client should confirm that there are realistic plans in place to achieve or improve on the
benefits shown in the original business case.

Project management process - Supporting processes
Supporting processes
You may need to use these processes at any time during
the project and we describe them in greater detail in the
tools and techniques section of this handbook.
Initiate Plan
Managing requirements
Suppor ting
processes
Value management
This includes all activities involved in dealing with
Procurement
Risk
Communications
Requirements
requirements throughout the life of a project. As a
Close Health and
safety
Configurat ion Implement
project moves forward the knowledge of it increases and
Quality
requirements grow, change and develop to reflect this
Control increased understanding. Managing these changes is
vital to the success of any project.
Risk management
A risk is an uncertainty which could prevent you achieving the project aims or provide
opportunities to increase the possible benefits, for example, by delivering a product early. Any
prediction of future events must have a degree of uncertainty associated with it. This uncertainty
applies in every activity of a project and success depends on how well you manage this.
Value management
Managing value examines the project from a functional point of view to see whether the best
balance is found between cost and function. We create value when we achieve this. It is a way
of identifying the contribution each part makes to the overall worth of a product and then making
sure that we have achieved maximum for the lowest possible cost.
Procurement and contract management

Any project where significant external costs are involved must make sure that procurement and
contracts are managed well. A commitment to buy materials, goods or services with long lead
times may have been made before you were appointed and these commitments may have already
set the course of the project.

As well as buying the hardware, software, stores, materials, services and so on that are needed to
complete the project, procurement is also responsible for:
v transporting materials;
v storing materials;
v stock control ;
v getting rid of unwanted stock;
v hiring specialists or other services; and
v renting equipment and plant.
Contract management is an area where you must have up-to-date specialist knowledge and you
should always make sure that you have a procurement specialist present whenever you discuss
contacts.
Communications management
Managing communications is vital to the success of a project. People’s views within and outside
the project are often clouded by poor communications. This will seriously affect the motivation
of the project team.
Communicating to the people who will be affected by the project and to those who, although not
directly affected will want to know what changes are happening, is equally important.
Configuration management
Configuration management is the process of controlling changes to, and the versions of, the
different parts of the project. It controls the characteristics of a product or service through
documents, records and data. It should make sure that you only put changes and variations in
place after they are authorised. You will use configuration management throughout the life of a
project.
Change control
Change control makes sure that you identify, evaluate and authorise or reject any changes which
are likely to affect the project significantly. It also makes sure you monitor the implementation
stages. Formal procedures you will use on a project should be clear to all team members .
Formal change control benefits the client, by making sure that you consider the effects on cost
and time before you make changes. Everyone else on the project team will benefit because you
reduce any disruption caused by unnecessary changes.
Health and safety management

Any project may involve health, safety and environmental factors. So that you understand these
factors every project should include an assessment of these risks before work starts and you
should update this, as necessary, throughout the life of the project. You need to include these
assessment updates and reviews in the project plan with the dates you will carry them out..
Under Health and Safety at Work law, all employers have a duty of care for their employees and
the public.

Managing finance
Obtaining and controlling the finance for a project is a significant part of project management.
Project proposals will have to include financial information and as a project progresses your
client will need regular reports of spend against planned spend and earned value. You should
make sure that the financial expertise necessary for this is available.
Project quality management

These are the processes that make sure the project will satisfy the needs for which it was carried
out. The processes should meet local, national and international standards and guidelines.
Managing benefits
All projects support the achievement of one or more business aims and you must specify the
benefits of doing the project clearly at the beginning. It is the client’s responsibility to make sure
that benefits are achieved and they will be held responsible if the expected return is not achieved.
The client must specify the benefits properly and make sure that there are plans to achieve them.
Although you may not be responsible for measuring, tracking and achieving the benefits, you
must make it clear in the business case how it will be done and who will do it.


Project lifecycle
Project lifecycle
We us the term ‘project lifecycle’ to describe the way in which a project progresses through a
sequence of phases from an initial idea through to it being completed and operating.
Breaking the project into phases allows you to control the project better. The end of a phase
includes a review of the project deliverables and project performance to decide if the project
should continue to the next phase, rework aspects of the phase or whether you should close the
project.
Do not confuse the project lifecycle with the product lifecycle. If you carry out a project to
develop a new product, it would be one part of the product lifecycle.
The typical lifecycle has ten project phases - eight before the project ends and two after. In
some types of project not all phases will apply.
Inception Capture new ideas or opportunities and identify problems and
possible solutions.
Feasibility Show that you can meet the client ‘s requirements and identify and
evaluate the options.
Definition Define in more detail what work is needed to deliver the client's
requirements. Produce detailed plans and get financial authority for
the project.
Development Get the project to the point at which the deliverables are ready to be
installed in an operational environment.
Installation Put in place, test and prove the deliverables meet the acceptance
criteria before 'going live'.
Pilot Confirm that the project deliverables work and show that the benefits
in the business case can be achieved.
Roll-out Reproduce the project deliverables over a wider operation.
Post- Formally close the project, having handed over the deliverables for
implementation operational use and with the benefits starting to build up.
Operations The project has been completed and the project deliverables are
being used in 'business as usual' to achieve the benefits.
Termination Eventually the project deliverables will be withdrawn and operations
end. This final phase may be a major event and become a project in
its own right, for example, you may need to get rid of equipment or
withdraw a service. Any financial appraisals presented in the
business case to the authorising organisation should have included
whole-life assessments.

Project lifecycle
As a project progresses more people and resources are committed. This means spending goes
up. At the same time the options available to influence the outcome reduce as shown in the
figure below.
Total
spend
Ability to
change outcome
e nt
P il o t
ut
ib il ity
ti o n
i ti o n
a t io n
ll a tio
R o ll o
lo p m
In cep
D e f in
m en t
Fe as
In s ta
D e ve
- im p le
P o st
The points between phases provide opportunities to review the status of the project
and whether it will meet the aims shown in the business case.
The sharp increases in the rate of spending at the ends of the definition and pilot
phases make these particularly important review points.
Key events and activities

No matter what the project lifecycle is or the methodology used, benchmarking across a wide
range of industries and types of project confirms that well-managed projects go through the
series of key events and activities listed below.
Project started
An idea or problem has been identified which may mean a project has to be carried out.
Project outline determined

The project has started and developed to the point where the client has agreed an outline of the
project aims.
Initial costs and benefits estimates produced

You have produced initial estimates of costs and benefits with enough detail to include within
business budgets.

Project lifecycle
Authority and finance provided

You have set aside a budget which will cover producing detailed project plans and there is
authority for the project to draw upon it.
Project registered
You have a unique code within the company systems and are using it to track the project.
Project team identified

You have identified the major players within the project team and their working relationship.
This will normally include you, the client, contractors or work package managers, users and other
specialists.
Feasibility study carried out

You have carried out a study into the options available for satisfying the project aims and
produced a feasibility report. Risk and stakeholder assessments will have been carried out.
Preferred option selected

You have identified and recommended, to the client, the option you prefer.
Project requirements definition completed

A project requirements definition is the complete statement of a project. It outlines the tasks
specification and timing of project outputs. It contains information for senior managers to make
decisions which affect the project and provides a practical reference for project contractors or
work package managers and supporting functions.
You will have carried out detailed planning and cost and schedule estimating before this
document is produced.
Business case prepared

You have written a business case justifying the project. It will include all significant options
considered and the reasons for ignoring them in favour of the option you prefer.
Procurement plan agreed

You have agreed a plan which details the procurement approach you will take with this project.
The plan should cover milestones, tendering options and outline forms of contract if these are
different from normal standards.
Authority and financial resources agreed

You have agreed the budget and have authority for the project to spend it.
Completing detailed designs

Designs have been completed that show, in detail, how you will produce the deliverables.

Project lifecycle
Placing contracts
You have placed contracts for the deliverables described in the detailed designs. These contracts
could be for internal and external suppliers.
Project deliverables generated

The deliverables, as set out in the detailed designs, have been produced ready for testing.
Ongoing support arrangements agreed

Agreements are in place that will support the project deliverables after the project is completed.
Project deliverables inspected and tested

You have tested the project deliverables against the specifications set out in the detailed designs.
Client and users accept deliverables

The client and users have accepted that the project deliverables have been produced as agreed.
Client agrees to close the project

The client has agreed that the project's tasks are complete and it may be financially closed.
Carry out post-implementation review

The project team, including the client, carries out a review on how the project was implemented
with the aim of identifying lessons learned that will benefit future projects.
Recording lessons learned

Record and store the lessons in a way that allows future projects to learn from them.
Completing the project

The project has finished and the deliverables are being used to achieve the benefits.

Project lifecycle
The diagram below shows the key events and activities mapped to the eight project lifecycle
phases described in this handbook. The project management processes (initiating, planning,
implementing, controlling and closing) are carried out throughout the project until the benefits
start to be delivered.
Project lifecycle and key events

Client agrees to close the project
Get customer and user acceptance
Authority and financial resources

put in place for to project
Preferred option selected
Im plem
e fits
Ben
P ost -
Rollout
Provision of authority and finance
entation
I ns t
Dev
P ilo
a llat
D e fi
t
e lo p
Fea
ion
n itio
men
Ince
Record lessons learned

s ib il
Post-implementation review
n
t
p t io
ity
n
Inspect and test deliverables

g,
nin g, Support arrangements agreed
, plan trollin Generate project deliverables
ng o n t Place contracts
iati ,c por
Init enting d sup Detailed designs produced
Procurement plan agreed
le m an es Project requirements definition and business case prepared
imp losing ocess
c pr Feasibility study carried out
Team identified
Project registered
Initial estimates produced
Outline determined

Project lifecycle

Project lifecycle - Project roles and responsibilities
Project roles and responsibilities

Each project phase needs a specific set of management activities and controls, which we describe
in pages covering the phase. However, the following responsibilities apply to every phase and
continue throughout the project.
Client
The client should:
v communicate the aims, range, timescales and resources needed for the project so everyone
understands them;
v champion the project (in other words, take every chance to help the project);
v get commitment from users to deliver the benefits;
v be available to the project manager;
v chair the project control board;
v sort out conflicts arising from priorities or limits on resources either individually or through
the project control board;
v review progress against the phase and overall project plan and take important decisions;
v review the business aspects against the proposed deliverables and make sure that the benefits
are still achievable;
v review the risks and decide on a risk management strategy;
v approve changes which affect time, cost or quality of deliverables;
v carry out end-of-phase reviews to identify lessons learned and sign off each phase;
v make go and no-go decisions and formally close the project if this is appropriate; and
v report to senior managers on the progress of the project.

Project manager
The project manager should:
v review the project with the client to set roles and responsibilities, progress to-date and
project organisation;
v produce a detailed plan for completing the next phase and maintain an overall project plan.;
v communicate the plan to the team and make sure everyone understands and agrees their roles
and responsibilities;
v get the resources to put the plan into action;
v make sure that any changes to the project are handled through agreed change control
procedures;
v monitor and control progress against the phase plan and overall project plan to make sure
that aims for time, cost and quality are achieved;
v get commitment from contractors or work package managers and users to provide resources;
v make sure that contractors or work package managers and users meet their obligations;
v make sure that issues are sorted out promptly; and
v get authorisation from the client to go to the next phase.

The contractors or work package managers should:
v make sure that the project manager is fully aware of the implications of implementing the
project, including functional requirements, scope and limits;
v help the project manager to work out the expected performance and return on investment by
estimating costs, resources and timescales and identifying possible sources of risk;
v make sure that the work is fully defined, planned and costed and find the resources needed;
v manage and control the work to make sure the project is delivered to the agreed time, cost
and quality, rescheduling within the work package plan where needed;
v monitor progress on work packages and report to the project manager using the agreed
procedures;
v go to project control board or other review meetings;
v make sure that all those who are employed on the project and others within the Contractor's
business unit know about progress;
v make sure that the client and project manager know about any issues which threaten the
successful outcome of the project; and
v help the project manager to assess the effect of any proposed changes to the project.

Users
The users should:
v make sure that the client and project manager know about the implications of implementing
the project, including operational considerations, functional requirements, scope and limits;
v help the client to decide on expected performance and return on investment by estimating
benefits, and identifying possible sources of risk;
v go to project control board or other review meetings;
v make sure that all users, and any units they deal with, know about progress.
v make sure that the client and project manager know about any issues which threaten the
successful outcome of the project; and
v help the project manager to assess the effect of any proposed changes.
We cover, in detail, the specific deliverables, the processes which apply and the project team
roles and responsibilities for each lifecycle phase in the following pages.


Project lifecycle - Inception phase
Inception phase
Initial project proposal
Design & functionality

Objectives & benefits of deliverables
Assumptions &
Time & cost
constraints
Client Review
Close Proceed to Re-work this

Project next phase phase
Post-implementation Client's Requirements Definition

Initial Business Case
phase Feasibility phase plan
To Feasibility phase
The aim of this phase is to capture new ideas or opportunities and to identify problems and
possible solutions.
The phase starts with an initial project proposal and ends by producing the client's requirements
definition. You can use this document to develop an initial business case asking for approval for
the project as a whole and authorisation to cover the work needed for the feasibility or definition
phases.
Roles and responsibilities

Client
The person who begins the project may not be the client but will temporarily take on the client's
role through this phase.

As well as the responsibilities that continue throughout the project, specific responsibilities in this
phase include:
v producing a high-level statement of requirements consulting with users and reviewing the
requirements against the business strategy and plans;
v setting out, in broad terms, the effects on people, technical and operational aspects;
v reviewing the requirements against current work in progress to prevent duplication;
v estimating time and costs needed and identifying risks;
v developing an outline business case and client requirements definition and deciding whether
you need a feasibility study; and
v identifying stakeholders and forming a small team, which includes users, to steer the project
through the next phase.
Project manager
A project manager may be involved in this phase on complicated projects. However, the
responsibilities at this time are often carried out by the client.
Many of the tasks to be performed are concerned with managing ideas and will involve
individuals who may become contractors or work package managers.
Contractors or work package managers and users

phase include:
v making sure that the client and project manager realise the practical implications and
opportunities created by the project including operational considerations, functional
requirements, performance requirements, scope and scale;
v helping the client and project manager to work out the expected economic performance and
return on investment by giving estimates of cost, resources, timescales, risks and benefits and
identifying other related activities which might affect the project; and
v defining project limits, for example, timing, resources and changeover requirements.

Inception to Feasibility phase transfer checklist
Agreement from contractors to

feasibility phase resources
Overall project issues identified
Strategic risks identified
Client requirements definition

completed
Feasibility phase plan produced
Initial business case prepared
Client confirmed
Project manager appointed
Feasibility study team identified
& See Documents - Client requirements definition (page 201)

& See Documents - Project file (page 199)
& See Documents - Business case (page 213)


Project lifecycle - Feasibility phase
Feasibility phase
From Inception phase
Client requirementsdefinition
Initial business case
Feasibility phase plan
Possible options Review objectives

benefits and
assumptions
Feasible options
Recommended
option Investment appraisal
Selected option
Client review

project next phase phase
Post-implementation Provisional project requirements definition

phase Outline business case
Feasibility report
Detailed definition phase plan
Outline project plan
Provisional technical and operational specifications
To Definition phase
The aim of this phase is to see whether you can achieve the client requirements and to identify
and evaluate the options available.
The phase starts by setting up a team to identify which options could deliver the requirements
and the likely timescales and costs.
The phase ends with a feasibility report showing the options identified and recommending one of
them, a provisional project requirements definition and an outline business case to be used to gain
approval for the project.


Client
phase include:
v appointing a project manager, if one is not already appointed;
v making sure that contractors or work package managers and users are properly involved in
the feasibility study and, particularly, in reviewing the options available to meet the
requirements;
v reviewing the timescales, costs, risks and benefits associated with the options and choosing
which option to go with;
v leading an investment appraisal and producing an outline business case; and
v making sure that a provisional project requirements definition is produced.
Project manager
The project manager's role is to identify and lead the team in exploring whether the client’s
requirements can be met.
phase include:
v seeing whether the aims of the project can be met;
v producing a report that includes estimates of costs, resources, time, risks and benefits for all
options and recommending which option should be chosen; and
v developing an outline project plan and business case to support the option agreed with the
client.
Contractors or work package managers and users

Contractors or work package managers and users work with the project manager to make sure
that the practical implications of implementing each option are identified and fully considered.
phase include:
v helping to work out the expected performance and return on investment by estimating scope
of benefits, costs, resources and timescales; evaluating other related activities and assessing
the risks;
v advising on operational requirements including functional, technical and performance
specifications and restrictions, for example, security and audit;
v contributing to the choice between options by reviewing the strengths and weaknesses and
prioritising project deliverables;
v making available the resources and budget if the project is authorised; and
v confirming the expected benefits of the option you have chosen.

Feasibility - Definition phase transfer checklist
Agreement from contractors to definition

phase resources
Agreement from contractors to provisional

time, cost and specification estimates
Action plans to sort out issues
Risk management plans
Feasibility report
Outline business case
Outline project plan
Provisional specifications for selected

option
Provisional project requirements definition
& See Documents - Feasibility report (page 205)

& See Documents - Project requirements definition (page 207)
& See Documents - Technical and operational specifications (page 217)


Project lifecycle - Definition phase
Definition phase
From Feasibility phase
Provisional project requirements definition;
Outline business case; Feasibility report;
Detailed definition phase plan; Outline project plan
Provisional technical and operational specifications
Structure Work Specification Benefit

and package of achievement
organisation plans deliverables plans
Commitments and agreements
Client review

Post-implementation Project requirements definition

phase Business case
Detailed development phase plan
Test and acceptance criteria
Overall project plan
Technical and operational specifications
To Development phase
The aim of this phase is to define, in more detail, what work you need to carry out to deliver the
client requirements, how much it will cost, and when, by whom, and how the work is to be
carried out.

The phase starts by setting up a team representing everyone with an interest in the project. The
team produce a plan showing, for each work package and for the whole project:
v how long it will take;
v the benefits;
v the costs and resources needed over time;
v interdependencies, in other words, what other work packages or projects are affected;
v risks with risk management plans; and
v deliverables and major milestones.
The team develop specifications of technical, operational and user requirements and performance
levels. They need to develop testing and acceptance criteria for the deliverables of each work
package and must test that all of the project deliverables work together as expected.
During the phase, you need to finalise the organisation and processes to be used in managing the
project. This includes:
v reporting and monitoring standards;
v how you will manage changes and issues; and
v the structure and membership of committees and control boards.
The Definition phase ends by producing a project requirements definition, a business case and a
plan for the whole project. These are based on commitments from contractors or work package
managers to the planned costs and timescales and from users to the expected benefits.

Client
The client role in this phase is mainly concerned with confirming that the project will produce the
expected benefits within the time, cost and quality limits agreed.
As well as responsibilities that continue throughout the project, the client has specific
responsibilities including:
v making sure that enough time is given for planning the project and that the plans produced
are based on realistic targets;
v leading an investment appraisal, developing the business case and getting authorisation for
the project;
v getting a commitment from users to deliver the benefits shown in the business case and
project requirements definition;
v setting up a project control board involving representatives of contractors or work package
managers and users;
v reviewing the benefits delivery plan; and
v agreeing change control procedures and authority levels.

Project manager
The project manager's main responsibilities in this phase are to work with the client and lead the
team in defining the scope of the project and its deliverables, and to develop a project plan that
everyone understands and agrees.
phase include:
v making sure that everyone understands the requirements, scope, timescales and resources
needed;
v making sure that risks are identified and assessed and appropriate plans are put in place to
deal with them;
v reviewing the project with the client to set roles and responsibilities, progress and project
organisation;
v setting up administration procedures, for example, communication, filing, planning tools,
change control and managing issues;
v analysing, defining and agreeing the project in terms of a work breakdown structure;
v arranging project workshops to develop detailed work package requirements, deciding on
responsibilities, develop a project plan, agree monitoring and control mechanisms, and
getting the client to sign up to it;
v developing the structure of the organisation, reporting and monitoring standards, and other
project procedures to be used throughout the project;
v preparing review points and milestones for the rest of the project; and
v producing a project requirements definition and project plan and maintaining other project
documents, for example, project file and risk management plans

Throughout this phase, the contractors or work package managers will work as part of the
project team to make sure that the work needed to implement the project is fully defined, planned
and costed.
phase include:
v helping the project manager to produce the project plan by identifying all work packages,
agreeing important milestones, working out how long each work package will take, what it
will cost, what resources are needed, how other work packages are affected, the risk
management plans and deliverables;
v producing a plan for all the work accepted;
v making sure that all operational requirements are met, including functional and technical
specifications, testing and acceptance criteria;
v confirming that the timescale, costs and resources needed, including providing for risks and
contingencies, are fairly presented in the business case;
v confirming that the budget and resources will be available if the project is authorised; and
v agreeing the structure of the organisation, reporting and monitoring standards, and other
project procedures to be used throughout the project.

Users
Throughout this phase, the users will work as part of the project team to make sure that the
practical implications of option we have chosen are clear and the maximum benefits are gained.
phase include:
v confirming the expected economic performance and return on investment by assessing the
benefits, estimating costs and timescales, measuring the effect of other related activities and
giving details of any assumptions and constraints which apply;
v advising the project manager on operational requirements including detailed functional and
performance specifications, criteria for success and prioritising the deliverables;
v contributing to the development of the project plan, specifically including details of how the
benefits will be achieved and how we will manage risks to benefits; and
v planning the development of the longer-term operational and maintenance procedures with
the client and project manager including documents, training and changeover arrangements.

Definition - Development phase transfer checklist
Agreement from contractors to deliver work

packages to agreed time, cost and quality
Agreement from users to deliver benefits
Agreement from authorising organisationto
business case
Risk analysis complete
Risk management plans
Business case
Project requirements definition
Contract documents
Development and installation plans
Project team formed
Project control board established
Monitoring and control procedures for
schedule, cost and specification
Benefits monitoring procedures
& See Documents - Project requirements definition (page 207)

& See Documents - Work package agreements (page 219)
& See Documents - Technical and operational specifications (page 217)


Project lifecycle - Development and installation phases
Development and installation phases

From Definition phase
Business case
Test and acceptance criteria
Development
Project launch
Detailed design
Procurement
Development
Integration
Testing
Deliverables ready for installation
Install deliverables
Test and prove deliverables

Installation

Post-implementation Deliverables ready for use

Pilot and Roll-out phase plan
phase
To Pilot and Roll-out phase
Development phase
The aim of the development phase is to take the project to the point at which the deliverables are
ready to be installed and ready to use.
The phase starts with formally launching the project after it is authorised.

There may be a number of stages in this phase, for example design, testing, tendering and
procurement.
At the end of the phase the project deliverables will be ready to install and use.
Installation phase
The aim of the installation phase is to put in place and test the deliverables against the
acceptance criteria in an operational environment, before `going live'.
During the development and installation phases the project team carry out the activities in the
project and work package plans. They report progress, monitor and control costs, deliverables
and timescales, and manage any changes and issues which arise.
At the end of the installation phase the project will be ready to ‘go live’ .

Client
The client's role during these phases is to regularly review progress against the plan and take
action to help the project manager keep the project on track.
As well as the responsibilities that continue throughout the project, specific responsibilities in
these phases include:
v deciding the location and plans for any pilot sites after consulting with the project manager
and the users;
v making sure that acceptance tests for handover at the end of the installation phase have been
successful; and
v reviewing the contract strategy with the project manager so as to make sure suppliers
continue to provide high-quality performance.
Project manager
The main responsibility of the project manager in these phases is to move the project from
planning it to carrying it out. Monitoring and control becomes increasingly important and the
project manager must make sure that the project documents are kept up to date.
v putting in place agreed ways of monitoring progress against the plan;
v controlling the project plan to make sure that objectives for time, cost and quality are
achieved taking action where necessary to keep the project on track; and
v recommending a location for any pilot and making sure users know about any specific
requirements of the project team.


During these phases contractors or work package managers will be working as active members
of the project team doing the work shown in work package plans and making sure that testing
and acceptance criteria are met within and between work packages.
Users
During this phase some of the users will be working as active members of the project team to
make sure the project is delivered according to the project plan agreed during the previous phase.
v agreeing with the project manager any locations that may be needed for a pilot;
v contributing to refining the installation and pilot phase plans including preparing for installing
the project deliverables;
v training other users;
v carrying out acceptance tests;
v developing and testing operational and maintenance procedures, for example, training
documents and changeover arrangements; and
v finalising the plans for delivering and monitoring the benefits.

Development and installation - Pilot phase transfer checklist
Agreement from contractors to deliver

remaining work packages
Agreement from users to deliver
overall benefits
Plans for remaining risks
Updated business case
Updated project plan
Installation and training documents
Agreed procedures for tracking
benefits during pilot and throughout
roll-out
Representative pilot site agreed
Operational procedures produced
Training for pilot complete

Project lifecycle - Pilot phase
Pilot phase
From Development and Installation
phases
Deliverables ready for use
Changes and
Deliverables used in
improvements
operational environment
to deliverables
Proof that benefits can be

achieved as expected
Client review
Close Proceed to Redesign or

project next phase modify ?
Post-implementation Authorisation for roll-out
phase To Roll-out phase
The aim of this phase is to confirm that the project deliverables can be used in an operational
environment to prove that the benefits can be achieved. Full testing will have been done in the
installation phase.
In the case of a project with a single implementation, the pilot may include familiarising the users
with the project, fine tuning, running it alongside the existing operation, until the client and users
are confident that their needs have been met.
During the pilot the project team assess the performance of the project deliverables under proper
operational conditions. If they identify any weaknesses or areas for improvement, the lessons
should be included in any further work. However, the client may need to authorise major
modifications.
At the end of the pilot phase the client must decide whether to accept the project deliverables and
authorise any roll-out, get re-authorisation to make any changes needed or close the project.


Client
The role of the client during the pilot phase is to confirm that the benefits shown in the business
case can be achieved and that the users are confident that their needs have been met.
phase include:
v deciding whether to roll-out and put into operation, or, close down the pilot and end the
project;
v making sure that roll-out plans fully reflect lessons learned from Pilot; and
v reviewing the business case to make sure that the benefits plan is still adequate.
Project manager
The Project Manager's role during this phase will focus on users by making sure that the project
will deliver the agreed benefits.
phase include:
v introducing procedures for identifying and evaluating suggested improvements;
v confirming, with the client and users, that the requirements have been met;
v reviewing the business case with the client to decide whether roll-out should go ahead;
v making sure that detailed roll-out plans are available for future installations;
v making sure that a set of templates which show the activities needed to implement the further
roll-out projects is developed; and
v making sure that any lessons learned are put in place in the roll-out phase.

During this phase contractors or work package managers will continue to be part of the project
team and will help the users to carry out their role.
phase include:
v observing operational running to identify any shortcomings in the performance of
deliverables;
v using lessons learned in further projects;
v contributing to developing any business case for roll-out, including timescales, cost and
resources; and
v putting in place any changes needed for roll-out or operations.

Users
During this phase the users will become the main focus of the project in accepting the project
deliverables into operations.
They will confirm that the benefits are actually achievable and that we can identify and deal with
any weaknesses and areas where improvements can be made. Assuming the Pilot is successful,
they will accept the project deliverables.
phase include:
v making sure that lessons learned are included for roll-out;
v making sure that the deliverables are assessed under proper conditions, letting the client
know about any operational conditions which could not be tested;
v setting up the requirements for maintenance and support; and
v contributing to developing plans to roll-out the deliverables.
Pilot - Roll-out and operations phase transfer checklist
Agreement from contractors for any

improvements needed to meet
specifications
Agreement from users to deliver
benefits
All issues sorted out
Confirm remaining risks are
acceptable
Supplier contracts in place
Updated business case
Updated project plan
Testing and acceptance criteria
revised, if necessary
Training available
Operational and maintenance
documents complete
Support processes in place
Authority for roll-out


Project lifecycle - Roll-out phase
Roll-out phase
From Pilot phase
Deliverables proven ready for use
Improvements, changes and lessons learned from pilot
Roll-out 1
Improvements to deliverables and project methodology
Lessons captured for use on future projects
To Post implementation phase

Deliverables being used in operations
Benefits being achieved
Roll-out 2
Roll-out n
The aim of this phase is to install the project deliverables over a wider operating environment.

The phase includes a number of projects, each with its own lifecycle. Each will be based on the
pilot but will also take account of the specific operational requirements and the lessons learned
during the pilot.
The implementation should be phased, whenever possible, to reduce any risks involved and to
make the best use of the expertise developed during previous roll-out projects. As the roll-out
progresses, the roll-out project teams will develop standard templates and tools to help this
process.
The client should only authorise the roll-out phase after the pilot phase has been successful.

Client
The client must make sure that roll-out is carried out at for as little cost and risk as possible.
phase include:
v making sure that expected benefits are achieved;
v looking for opportunities to get more from the investment; and
v making sure that all roll-out projects are planned in line with the relevant templates and that
any changes to the templates are authorised through agreed procedures.
Project manager
The skills needed by the project manager are different in this phase, so the responsibility may pass
to a roll-out project manager who will co-ordinate each roll-out at the various sites.
phase include:
v monitoring and controlling the overall project;
v getting commitment to the project from operational management;
v supporting the roll-out project teams;
v making sure support is provided, for example, training and development;
v putting in place improvements learned from the pilot phase;
v reviewing achievements against the business case;
v preparing for the project team to be re-deployed;
v completing a project closure report; and
v getting the client’s agreement to close the project.

During this phase the contractor or work package manager role will be similar to that during the
development. installation and pilot phases.

phase include:
v using lessons learned from earlier work; and
v contributing to refining the roll-out phase plan.
Users
During this phase, users will begin to operate the project deliverables, and deliver the benefits
against which the project was authorised.
As well as the responsibilities that continue throughout the project, specific responsibilities in the
roll-out phase include:
v monitoring and reporting on the achievement of benefits; and
v helping the client and project manager to assess the effect of any proposed changes.
Roll-out phase checklist
Closure report for each roll-out

project
Final reviews for each roll-out

project
Budget closed for each roll-out

project
All sites installed
All handovers complete
Maintenance agreements in place
Roll-out project teams redeployed


Project lifecycle - Post-implementation phase
Post-implementation phase
From Roll-out projects
Deliverables being used in operations
Improvements, changes and lessons learned
Review performance
Roll-out 1 of deliverables
Review effectiveness
Project or programme close

of project
management
Roll-out 2 Make sure that there
Closure report
are arrangements for
Final review
monitoring benefits
Record and
communicate
lessons learned
Roll-out n Identify further

opportunities
Close expenditure
The aim of this phase is to formally close the project, having handed over the deliverables to be
used in operations and with benefits starting to show.

Formally closing the project gives the opportunity to:

v review the performance of the deliverables and how effective the project management was;
v make sure that arrangements made for monitoring the achievement of benefits are working;
v keep records of the lessons learned and pass them on to other project teams;
v recognise the contribution of team and individual efforts;
v identify further opportunities for using the investment; and
v prevent further spending on the project.
Within the three months following the end of this phase, you need to produce a project closure
report. This report is best produced at a project team workshop.

Client
The role of the client during this phase is to make sure that we achieve the benefits of the project
and that we keep a record of lessons learned.
phase include:
v reviewing and reporting on the functional performance of the deliverables and the project
management;
v reviewing and reporting on the actual spending compared with the original authorised
amounts;
v making sure that arrangements made for monitoring the achievement of benefits are working;
v closing down project budgets;

v accepting the project closure report and final review; and
v making sure that those involved in delivering the project are appropriately recognised and
rewarded.
Project manager
phase include:
v reviewing and reporting on achievements compared with aims;
v carrying out a project review with all team members to identify and record best practices to
be included in the project closure report;
v recognising contributions of the team and individuals;
v passing on lessons learned to other project managers;
v completing a project closure report; and
v making sure that team members have been re-deployed.


During this phase the contractors or work package managers will support you and the client in
producing the project closure report.
Users
The main role of the users in this phase is to achieve the benefits and to make sure that they are
built into the business plan.
The users will support you and the client in producing the project closure report and final review.
In particular the users will put forward views on whether the training and documents provided
were appropriate and comment on the performance of the project deliverables.
Post-implementation phase milestones
Project closure report completed
Final review completed
Lessons learned and

communicated
Project team suitably rewarded
& See Documents - Project closure report (page 221)

& See Documents - Final review (page 223)


Tools and techniques

This section describes the full range of project management procedures, techniques and tools.
How far you use these will depend on a number of factors, for example:
v the size and complexity of the project;
v how new the idea is;
v the experience of the project team; and
v the need to achieve the right balance between effort put in and usefulness of the output.
Although you can use the tools and techniques in all projects, you should tailor them to suit the
particular circumstances of the project.


Tools and techniques - Planning
Planning
You must have a good plan which covers the main parts of a project. You need to use it to
communicate to everybody what the project will deliver, when, by whom and at what cost. It is a
baseline against which the client can assess progress.
You should repeat the planning process, shown below, until the time and cost for the project are
acceptable and the benefits can be achieved.
Build work breakdown structure
Construct network diagram
Estimate time and resources
Estimate costs
Analyse network
Time and cost OK? û Re-assess network
ü
Optimise resources
Time and cost OK? û

ü
Benefits achievable?
û
ü
Set baseline
A project plan is usually made up of a number of parts including:

v a work breakdown structure (WBS);
v estimates;
v network diagrams and analysis;
v Gantt charts;
v milestones;
v resource schedules;
v materials requirements schedules;
v benefits plans;
v risk management plans; and
v cost plans.

Work breakdown structure (WBS)

A WBS is a hierarchical breakdown of all the work that will be needed to complete the project.
The lowest level of this breakdown is called a work package.
OFFICE MOVE
NEW OFFICES TRANSFER
Pack
LAYOUT SERVICES
crates
Move
crates
Erect Fit
partitions electrics Unpack
crates
Fit
Decorate
phones
Lay
carpet
A simple example of a work breakdown structure showing the work involved in moving
office. The items in lower case are work packages.
Producing a WBS should be a team task involving everyone who has an interest in the project.
By using the technique, you can identify all of the work of the project in a logical structure. A
WBS does not show the sequence of activities, nor when they will happen. You will only know
this when you have finished the network diagram and analysis.
Developing a WBS
The top level activity of a WBS, and the starting point, will be the project itself. You should add
lower levels to this structure by refining the areas involved in the project until you can identify
specific work packages. Not all branches of a WBS will have the same number of levels, and
there is no right or wrong number of levels to aim for. Generally, you will have been reached the
right level when a work package:
v can be passed to a named individual;
v has a specific and defined deliverable; and
v can have the length and cost reasonably estimated.
When you can do this for all branches in the structure, you can be fairly confident that you have
identified all of the work packages.

Developing a WBS is best done in a workshop involving everyone with an interest in the project.
Use Post-it® notes and a large area of wall or brown paper so that you can build and rebuild the
WBS until the team is satisfied that you have identified all the work. Team members will usually
have different ideas as to how the project should be broken down and there may be many
amendments before you produce an agreed structure.
DECORATION DECORATION
PREPARATION APPLICATION PAINTING PAPERING
Remove old
Remove old paper Hang new paper CEILING WOODWORK
paper
Hang new
Fill ceiling cracks Paint ceiling paper
Fill ceiling Smooth
Undercoat cracks woodwork
Smooth woodwork
woodwork
Undercoat
Gloss paint Paint ceiling
woodwork
woodwork
Gloss paint
woodwork
DECORATION
CEILING WOODWORK WALLS
Fill ceiling Smooth Remove old

cracks woodwork paper
Undercoat Hang new
Paint ceiling
woodwork paper
Gloss paint
woodwork
These examples show how you could create different, but equally valid, WBS
structures for redecorating. Although the number and titles of levels are different, the
lowest level (work packages) are the same in each structure.
(Post-it® is a registered trade mark of 3M)

Once you have developed the WBS you can define the work packages. This definition should
include:
v a structured reference number;
v a description;
v the name of the contractor or work package manager;
v the requirements;
v deliverables, important milestones and acceptance criteria;
v activities or tasks needed to complete the work package;
v estimates of the time it will take;
v estimates of the resources needed;
v estimates of cost; and
v risks.
The work package definitions are an essential part of the work package agreements.

Estimating
Estimating is the technique used to predict the time, cost, resources and other materials needed
to complete an activity.
Before starting a project the company needs to know whether it is worth doing. An estimate of
the costs is prepared and compared with the expected returns and this is usually sent for appraisal
and approval. The decision to go ahead is taken on the basis of these estimates.
In a bid or tender, estimates are also used to set the price and forecast the profit.
Cost estimates for the project are produced from estimates of the work needed and the resources
to be used. Many activities have costs which are a function of the time an activity takes, for
example, site security. Other costs are a function of the resource used no matter how long the
activity takes, for example, building materials.
In some public-sector contracts the customer may have the right to see the cost estimates.
Approach to estimating
You can produce cost and resource estimates using the WBS, by estimating at the lowest levels
and adding the separate lower level estimates to get estimates for the higher levels of the
breakdown. This approach will not work for timescales which you must work out from a
network diagram, taking account of the logical sequence of activities. You will get a more
accurate estimate if you estimate at lower levels of the WBS, but the lower you go the more
work you need to do.
The list of assumptions you provide with an estimate will give everyone a good idea of:
v the amount of effort that has gone into producing it;
v the amount of work that has been done in defining the project; and
v how confident you can be that the eventual outcome will match the estimate.
So that everyone you present the project to can understand the assumptions you have made in
preparing the estimates, we give each estimate a ‘class’. Each class lets everyone know the stage
the estimate is at.
We recommend you use three classes of estimate.
Class 3
v These estimates are produced in early phases of the project, often with little detailed analysis.
The project is very loosely defined and the chances of this estimate matching the eventual
outcome are slight.
Class 2
v These estimates are produced during the definition phase of the project and will be the
estimates that form the business case. There is more definition but the specifications still
need to be refined. There will still be several assumptions at this stage but the chances of
matching the eventual outcome are better.

Class 1
v These estimates are produced when the detailed design work is more or less complete and
some development has started. However, you should be aware that it is largely by chance
that the eventual outcome matches an estimate exactly. There is always an element of
uncertainty.
Contingency
If, after using all the available information and improving the level of definition for an activity,
there is still a large area of uncertainty, you need to rely on the knowledge and expertise of those
involved to produce ‘best guess’ figures. If you make an allowance for expected but, as yet,
undefined work in the work package, this is known as ‘contingency’.
You will identify and manage this contingency separately to focus attention on those parts of the
work which are not yet defined, and to make sure that you do not spend the money elsewhere.
For example, it should not be included because ‘budgets are always cut by 10%’ nor should it be
used to cover ‘running over budget’.
Contingency is especially important where, because of time limits, you need to fast track the
project definition phase.
Control estimate
The control estimate provides a baseline against which you can assess the progress of the work
package. The parts of the control estimate are:
v the amount you planned to spend for defined work in a work package; and
v the contingency to cover undefined work.
These are added together to get an authorised sum, which is the amount you are authorised to
spend.
Estimating techniques
There are various methods of estimating, most of which use information about past performance,
and these include parametric, exponential and step counting.
Parametric methods
You need to assume that all costs are a percentage of some main cost. For example, in
refurbishment projects, you can use the cost of one room of known size to work out the cost of
the overall project to an acceptable accuracy.
Exponential methods
You need to assume that cost is proportional to the size of the facility, increased to some known
power. For example, the constructive cost model (COCOMO) is sometimes used to estimate the
cost of software products. COCOMO provides a cost for each data item that will be processed
by software product. You can work out the cost of all of the items and the answer you get is
then raised to the power 1.2. So, the cost of the software product increases exponentially
according to the number of data items.

Step counting methods

You need to assume that the cost is directly related to the number of functions that the product
will carry out and how it will be produced. Industry standard formulae and tables have been
developed from observations and experience. For example, you can base costs for software
development on the number of data elements and processes.
Standards
You can prepare detailed estimates from standard cost books, for example, standard labour rates.

Network diagram and analysis

A network diagram shows the logical links between the activities shown in the work breakdown
structure. When you include estimates for the time an activity will take to complete and you
analyse the network, you can get an idea of the time the whole project will take to complete.
Analysis also highlights those activities which, if delayed, will result in a delay to the entire
project. The analysis is known as critical path analysis (CPA)
Erect Fit
partitions electrics
Fit Decorate Lay

phones office carpet
Pack Unpack
Move crates
crates crates
An example network diagram for a simple office move project.
Developing a network diagram

1 Decide on the logic of the network
Take each activity in turn, and decide which activities you must complete before it can start. As
with the WBS, you are best doing the first network diagram in a workshop including everyone
with an interest in the project. Use Post-it® notes and a large area of wall or brown paper so
that you can explore different arrangements of activities.
(Post-it ® is a registered trade mark of 3M)

You can link activities by a number of different types of logic links, the most common being the
Finish-to-Start link (FS). The types of logic link and how they are shown in a network diagram
are shown below.
A B
B
Finish to Start (FS) Start to Start (SS)

Activity B cannot start Activity B cannot start
until Activity A has finished until Activity A has started
A A
B B
Start to Finish (SF) Finish to Finish (FF)

Activity B cannot finish Activity B cannot finish
until Activity A has started until Activity A has finished
It is also possible to add time factors to links, making them more flexible. These time factors are
known as ‘lags’. For example:
A
+5
B A
days
Activity B cannot start until 5 days

+5
after Activity A has finished B
days
Activity B cannot start until 5 days

after Activity A has started
2 Include the length of activities

You will have estimated the timing of some activities at the WBS stage. You may have delayed
others until you could do more work. You must add the missing estimates of how long the
activities will take to complete before you can carry out the time analysis.

3 Critical path analysis (CPA) - Time analysis

The reasons for using CPA are:
v it allows you to work out the earliest end date for the project; and
v it highlights the critical activities and path, or paths, in the project.
‘Critical’, in network analysis, has a very specific meaning. Critical activities are those which, if
delayed, will delay the whole project. A critical path is a path through the network made up of
only critical activities. That will be the longest route through the network and the shortest time
the project will take to complete. There may be more than one critical path in a project, and the
critical path may change as you create different plans and as you carry out the project work.
The British Standards Institute has defined a standard activity box to show the information
needed for CPA.
Earliest Start Duration Earliest

Finish
Activity Number
Activity Description
Resources required
Latest Start Total Float Latest

Finish
There are three steps to working out the critical path:

v forward pass;
v backward pass; and
v float calculation.
Whether you use a day, a week or a month for the analysis remember that the start of the activity
is at the beginning of the day, week or month and the finish is at the end. So, if you decide to use
days, the first activity in the network will start at the beginning of day one. If that activity lasts
for 10 days, it will finish at the end of day ten and the next activity will start at the beginning of
day 11. This method is known as ‘day-one’ start.
Another method uses a start of zero for the first project activity and carries forward the finish of
one activity to the next activity. In other words, a 10-day activity will start at day zero and finish
at day 10. The next activity will start at day 10. This method is often used in project planning
software.
The formulae shown below uses the ‘day-one’ start method because it avoids the confusion of
the finish date of an activity being the same as the start date of any activities that follow it or
depend on it. However do not just blindly follow the formula. You need to understand it.

Forward pass
Set the earliest start (ES) of the first activity to 1.
You work out the earliest finish (EF) of the first activity.
EF = ES + Duration - 1
You work out the earliest start (ES) of each activity which immediately follows it from:
ES = EF of the latest preceding activity + 1
You can then work out the EF for the rest of the activities.
EF = ES + Duration - 1
When you have done this for all activities in the network, you will have an estimate of the time
the project will take to complete.
Backward pass
It is useful to know the latest start and latest finish of activities and we show the formulae for
working these out. Again, do not just blindly follow the formula. You must understand it. The
same principles used in working out the early start and finish apply here.
Set the latest finish (LF) of the final activity to the latest finish (LF) that you worked out for the
forward pass.
Work out the latest start (LS) of the final activity.
LS = LF - Duration + 1
You work out the latest finish (LF) of each activity which is immediately before it from:
LF = LS of the earliest activity which immediately follows it - 1
You can work out the latest start (LS) for the rest of the activities.
LS = LF - Duration + 1
Work out total float

Total float represents the time that you can delay an activity without affecting the completion
date of the project. It follows that you cannot delay activities with a total float of zero without
affecting the project’s end date. These activities are known as critical, and the path that link
them is the critical path. There may be more than one critical path.
You can work out the total float for each activity by:
Total float = LF - EF (or LS - ES)
Free float is the time that you can delay an activity without affecting any other activity. Free
float will always be less than or equal to total float, and will only be available to activities at the
end of non-critical paths through the network.

CPA Worked Example

We have redrawn the example network diagram for a simple office move using the standard
activity box layout and included the estimates of how long each activity will take.
ES 2 EF
ES 3 EF
Lay carpet
Fit electrics ES 1 EF ES 1 EF
ES 10 EF ES 5 EF
LS F LF Move Unpack
Erect LS F LF
Decorate crates crates
partitions
ES 1 EF
LS F LF
ES 2 EF LS F LF LS F LF
LS F LF
Pack
Fit phone
crates
points
LS F LF
LS F LF
1 Set the ES of the first activity to 1, and the EF to 10 (EF = ES + DU -1).

2 The ES for ‘Fit electrics’ and ‘Fit phone points’ then become 11 (ES = EF + 1).
3 EF ES 2 EF
11
Lay carpet
Fit electrics ES 1 EF ES 1 EF
1 10 10 ES 5 EF
LS F LF Move Unpack
Erect LS F LF
partitions
11 2 EF ES 1 EF
LS F LF LS F LF
LS F LF LS F LF
Pack
Fit phone
crates
points
LS F LF
LS F LF
3 You set the ES of the next activity, ‘Decorate’, to the EF of the latest preceding activity (in
other words, the highest EF value) +1. You work out the EF as before.
4 You work out the rest of the forward pass in the same way.
3 13 19 2 20
11
Lay carpet
Fit electrics 21 1 21 22 1 22
1 10 10 14 5 18
LS F LF Move Unpack
Erect LS F LF
partitions
11 2 12 19 1 19 LS F LF LS F LF
LS F LF LS F LF
Pack
Fit phone
crates
points
LS F LF
LS F LF
5 When you have completed the forward pass, you work out the backward pass by setting the
LF of the final activity equal to its EF. You work out the LS of the final activity using the
formula LF - DU + 1. The LF of the immediately preceding activity is LS -1 (in other

words, the lowest value) giving:
11 3 13 19 2 20
Lay carpet
1 10 10 14 5 18
19 F 20 Move Unpack
Erect LS F LF
partitions
19 1 19
LS F LF 11 2 12 21 F 21 22 F 22
LS F 18
Pack
Fit phone
crates
points
20 F 20
LS F LF
6 You work out the rest of the backward pass in the same way.
11 3 13 19 2 20
Lay carpet
1 10 10 14 5 18
19 F 20 Move Unpack
Erect 11 F 13
partitions
11 2 12 19 1 19 21 F 21 22 F 22
1 F 10 14 F 18
Pack
Fit phone
crates
points
20 F 20
12 F 13
7 You an now work out the float available to each activity from the formula LF - EF:
19 2 20
11 3 13
Lay carpet
1 10 10 14 5 18
19 0 20 Move Unpack
Erect 11 0 13
partitions
11 2 12 19 1 19 21 0 21 22 0 22
1 0 10 14 0 18
Pack
Fit phone
crates
points
20 1 20
12 1 13
8 The critical activities (in other words, those with zero float) and the critical path have been
highlighted.
4 Optimise project duration and cost

As a result of carrying out network analysis, you have worked out an estimated earliest project
end date. If this does not meet your need, you must look again at the way in which the project is
to be completed. You may be able to reduce the length of tasks on the critical path if the
contractors or work package managers agree. You may also be able to change the logic of the
network to do more activities at the same time. If you cannot meet the requirements within the
timescale, you must tell the client.

5 Resource schedule
The time analysis you have done so far shows how quickly you can complete a project, ignoring
possible problems with resources. However, resources are usually limited and a resource analysis
takes account of this. In order to produce an acceptable plan you may need to carry out the
resource analysis a number of times and, on a large project, you will usually use project planning
software to do this.
Levelling resources
You can change the length of project activities to make sure that you do not break any resource
limits. Change the length of each activity in turn so that there are enough resources available to
carry out the work, then do the time analysis again.
Smoothing resources
The best plan possible is produced by rescheduling non-critical activities while maintaining the
length of the project. Move the start and finish times of non-critical activities to reduce any
peaks and troughs in using the resources. Even after smoothing there will still be periods when
resources are under too much pressure because there are not enough.
Manual intervention
Analysing resources for a large project is complicated and is normally done using project
planning software. But, even after you have used resource levelling and smoothing mentioned
above, you may still need to use your initiative. For example, if you can accept a short delay or
small resource overload, you may produce an acceptable plan.
The actions that you can consider include:
v changing non-critical tasks to reduce the pressure on overloads;
v reassessing the number and type of resources;
v splitting tasks into smaller, more manageable tasks; and
v accepting the pressure on resources, and any effects such as overtime costs.
Project planning software will take the hard work out of these calculations. When you have an
actual start date for a project, the software will use estimated duration and elapsed time to work
out start and finish dates for activities. However, different software will produce different
results especially when resource scheduling.

Milestones
A milestone is an important event or point in time when a measurable achievement is due, should
have been achieved or something actually produced. Milestones do not have a length associated
with them and are usually shown in plans in a way which distinguishes them from normal
activities.
Milestones provide a powerful way of checking progress and you should spread them as evenly
as possible over the project. You should agree them with the people responsible for delivering
them.
Gantt chart
A common way of showing project activity is by using a particular type of bar chart known as
Gantt chart. This is a chart showing activities against time. You can use different bar styles to
show work in progress, completed activities and the original project plan or baseline.
Office move project plan

Days
2 4 6 8 10 12 14 16 18 20 22 24
Erect partitions
Fit electrics
Fit phone points
Decorate
Lay carpet
Pack crates
Move crates
Unpack crates
Material requirements schedule

A material requirements schedule is a plan for buying, storing and delivering the project
materials. Its purpose is to make best use of the materials and you will produce it with the help
of procurement specialists.
& See Tools and techniques - Procurement management (page 175)
Benefits Plan
The benefits are usually delivered after the project has finished. For example, you cannot benefit
from efficiency savings from a new computer system until it is put in place. The client is
responsible for achieving benefits, but the benefits will be delivered by users.
The benefits plan identifies the benefits to be delivered by the project and it shows how and when
they are expected to be achieved and how they will be measured. You should avoid

generalisations, for example, ‘efficiency savings’. Benefits should be specific and measurable
preferably in money terms.
& See Tools and techniques - Managing benefits (page 181)
Risk management plan

Risk management plans show the extra activities which you would need to carry out if identified
risks actually happened.
& See Tools and techniques - Risk management (page 131)
Cost plan
A cost plan is a forecast of spending against time. It shows the costs associated with each work
package, and is produced for the project as a whole by adding together the cost estimates of all
the work packages.
Typically, the total project costs by time creates a characteristic ‘S’ shape:
Costs
Time
Cost breakdown structure (CBS)

You can build up all estimates from individual elements. The company cost breakdown structure
will provide costs for estimating and budgeting purposes. You should use the financial expertise
available to the project when you estimate costs and design ways of controlling cost. This is
because you will need to show costs in a number of different ways.

Possible ways include being able to:

v work out estimates at any level in the WBS;
v provide project and work package summaries according to elements in the cost breakdown
structure CBS.
v provide project and work package summaries according to organisational unit;
v provide summaries based on user-defined coding structures (for example, type of work);
v produce summaries using combinations of the WBS, CBS and user-defined codes; and
v produce graphs of the estimated costs over time.
Next steps
Once the project plans have been agreed, and documented, the plan becomes the baseline against
which you will measure progress. You will need the baseline plans business case which you will
produce by the end of the Definition phase. The plan will change over time but it should always
be possible to refer back to the original baseline.
: You can get more information from the project management intranet site.


Tools and techniques - Monitoring and control
Monitoring and control

Monitoring the project involves measuring and comparing achievement against the plan. Project
control involves taking action to keep the project on course, taking advantage of beneficial
changes while reducing the effect of any negative changes. Control actions are forward looking
so that you make best use of the time and budget you have left.
The aims of monitoring and control are to:
v make sure that project aims are met and benefits achieved;
v manage how funds are released and used;
v prevent threats to the length of the project, cost, resources and the project deliverables;
v make sure that you know what is happening on the project;
v identify opportunities to reduce the cost of the deliverables and shorten the length of the
project;
v identify opportunities to increase the benefits; and
v give confidence to the client that the project is being managed well.
Who monitors and controls?

You should make sure that actions are taken when needed so that the project delivers the
requirements which have been agreed with the client.
You are responsible for setting up, by agreeing with contractors or work package managers, a
way of monitoring the progress against the plan. All project team members have a responsibility
to make sure that the project meets its aims.
The project manager’s specific responsibilities include:
v identifying and solving problems before they affect the project;
v identifying opportunities for improvement;
v reporting progress to the client; and
v adding the results of decisions to the plans and telling the project team about the revised
plans.
Contractors or work package managers have similar responsibilities at the work package level
and their procedures should meet all the monitoring and reporting standards agreed with you.

What is monitored and controlled?

Important elements to monitor and control are:
v the actual progress;
v the risks of the project;
v achieving milestones;
v the costs of the project;
v the resources needed for the project;
v the performance of the project deliverables;
v the benefits (expected and actual) against the business case; and
v driver projects and outside influences.
When to monitor and control

Monitoring and control should begin as soon as plans are available. Even in the early stages of
the project you need to monitor and control how the project plan is produced.
When you have finished the detailed project plan and development starts the rate of activity and
as a result, the rate of spending increases. A fully effective monitoring and control system must
be in place before the start of the development phase.
Level of monitoring and control

Monitoring and control is carried out at all levels in the project. The things you monitor are the
same no matter what their position in the hierarchy, but the degree of detail tends to increase at
lower levels in the work breakdown structure.
Not all activity on the project needs the same level of monitoring and control. Consider the
following when you decide on the time and effort needed.
v Activities which are critical to the success of the project.
v Activities which are on the critical paths (and remember that critical paths can change).
v Activities on which many others depend.
v Impending activities.
v Activities which cost a lot.
v Activities which take a long time (but try to split them into shorter activities).
v Activities where progress is difficult to measure.
v Activities where there is a lot of uncertainty.

Monitoring and control process

Monitoring and control is a regular process with five steps in the process
2. Check
1. Collect data 3. Analyse
5. Control 4. Report
1 Collecting data
Before you ask contractors or work package managers for information, you should consider:
v setting the timing of reports according to how important they are and the rate of change;
v using information sources and systems which are used for normal business purposes;
v limiting information to that which is necessary for effective control;
v collecting information at the lowest practical levels in the work breakdown structure;
v identifying ways of checking information from contractors or work package managers; and
v previous experiences with contractors or work package managers (for example, do they have
a good track record?).
Collect data for activities in progress or completed during the current reporting period.
You may need to be summarise data and sort it using one or more of the following breakdowns.
v Work breakdown structure - the logical breakdown of the project work for managing the
project.
v Cost breakdown structure - the different types of resources you will use.
v Organisational breakdown structure - the parts of the company carrying out work on the
project for line management reporting and budgeting.

Expenditure
There are various cost collection systems for accounting purposes. However, there may not
always be enough information to control the project and other arrangements sometimes need to
be put in place.
Collect actual costs spent (capital and current expenditure, transfers between departments for
manpower, stores, contract, and so on) and identify costs through three stages.
v What has been spent so far.
v What costs have been committed - so that you can produce better forecasts.
v What costs are about to be committed - in case you need to stop spending quickly.
Actual progress
You can usually express any actual progress in terms of the milestones achieved or percentage
complete. Achieving an appropriately chosen milestone provides a concrete measure of progress.
Expected completion dates for milestones, supported by evidence of which activities have been
completed which lead up to the milestone, are useful indicators of expected progress.
You can find the percentage complete in many ways depending on the type of work you are
measuring. Valid assessments can be based on:
v the quantity in place;
v work still to be done; and
v milestones complete.
Any assessments of percentage complete depend on individual views, but as long as the work is
broken down into small duration activities, you will reduce the scope for mistakes. You only
need to make assessments on activities in progress (activity completed = 100%, activity not
started = 0%). So, keep any planned activities as small as possible and the room for mistakes in
the overall percentage complete estimate will be smaller.
You can use the percentage complete in different ways depending on the type of resources
involved and the method of payment (type of contract) used. You will normally consider
lump-sum contracts that have been completed, and capital items that have been accepted
(whether paid for or not) as 100% complete.
2 Checking
You need to check whether the data is accurate, complete and consistent. Ask the following
questions.
v Are any expected milestone or activity completion dates supported by progress on
supporting activities?
v Does the actual and reported progress tally, in other words, have you seen the project
deliverables?
v Do the actual cost and resources used tally?
v Are the reporting periods for progress the same as those for costs and resources?
v Is spending reasonable given the progress made?
v Is the contractor or work package manager reliable, based on your previous experience of
them?

3 Analysis
Analysing the information in progress reports and using forecasting techniques will give you
some idea of the likely project cost, length and quality of project deliverables. How far you can
go with analysing and forecasting depends on the type and scale of the project. Earned value
management techniques will give you a valuable insight into performance on the project schedule
and the cost. The techniques also give indicators to help you forecast any remaining work and
expenditure.
& See Tools and techniques - Earned value management (page 97)
You should carefully check forecasts provided by contractors or work package managers to
make sure that they are realistic. An activity which has been consistently behind schedule is
unlikely to complete on time without affecting costs or the quality of project deliverables.
Remember, the last 20% can take as long as the first 80%.
4 Reporting
When you have finished the analysis you must then communicate the current state of the project
and its likely outcome. If you have a set of well thought out reports which meet the needs of the
various stakeholders, it will make this much easier.
You need reports which show the following, in terms of time, cost and quality of project
deliverables.
v What has been achieved and how close it compares with the plan.
v What should have been done but wasn’t and how you will put it back on track.
v What is still to be done and the likelihood of it being done to plan.
The client will insist on regular reports for the project control board and you will agree the style
and content of these reports during the project definition. The reports should be brief and assure
the client that aims are being met and that benefits will be achieved. Where necessary, you
should tell the client what action you have taken to put the project back under control.

Milestone reports
These are tables or charts which show planned, latest estimate and actual achievement dates for
high-level project or work package milestones. Milestone slip charts are a useful way of plotting
milestone plans, achievement and current forecasts. They give a picture of achievement so far
and the reliability of forecasts for the milestones which are left.
Planned milestones
1 2 3 4
September
November
December
February
January
October
August
March
June
April
May
July
January
February
March
April
Review dates
1
May
June Latest review
July 2
August
3
September
October
November 4
December
In the example there are four milestones planned - one each for March, May, August
and November.
When reviewed in February, Milestone 1 (due at the end of March) was delayed until
the end of April. Milestone 2 was also delayed but 3 and 4 were forecast to be
completed as planned.
Milestone 2 was delayed by another month at the March review.
The April review saw Milestone 1 completed. Milestone 2 managed to recover a month
of delay and Milestone 3 was delayed by one month.
The latest review shows milestone 2 completed one month late. Milestone 3 is back on
target and Milestone 4 is ahead of target by one month.

Earned value management reports

Analysing earned value can provide a lot of information about past, present and likely future
performance on cost and schedule. This mixture of cost and schedule information gives us much
more than a straightforward comparison of costs against budget.
& See Tools and techniques - Earned value management.
Gantt charts
Gantt charts (or bar charts) provide a way of showing when activities are carried out and how
long they take. These charts generally show original planned activities compared with actual and
current planned activities.
Office move project plan

Days
2 4 6 8 10 12 14 16 18 20 22 24
Erect partitions
Fit electrics
Fit phone points
Decorate
Lay carpet
Pack crates
Move crates
Unpack crates
Time now
Baseline plan Actual progress Latest forecast
RAG (red, amber, green) reports

These are tables or charts which show the status of activities and milestones highlighted by the
colour red, amber or green. It must be clear what each of the colours stands for. For example:
v red - could be a significant move away from the plan and action is needed or has already
been taken to sort the problem out;
v amber - could be a slight move away from the plan and action may be necessary or has
already been taken; and
v green - could be that the progress is on target.
Important points
Use exception reporting to tell people about problems as they arise so that they can begin sorting
them out without waiting for normal reporting times. You should always include, in any problem
report, a plan of action to sort the situation out.
Reports should be relevant to the person receiving them. And, you should only send them to
those who need the information. You should be absolutely clear why you are producing a report
and the person receiving it should be clear why they are receiving it (for example, whether it is
for action or for information only).

A clear report on the state of the project will satisfy the needs of many audiences. However,
avoid the temptation to tell everyone everything. You should not expect individuals to hunt for
what they need in a mass of information much of which will be irrelevant to them. On large
projects you may need a distribution plan for the reports.
5 Control
Control is about keeping the project on track. When all possible steps to do that fail, it is about
reducing the effect, as far as possible, on the project aims. Time, cost and quality of deliverables
depend on each other, in other words, changes to any one of them will usually affect one or both
of the others. Any decisions you take to recover from delays in a project may well have the
effect of reducing the quality of project deliverables and increasing the costs.
Controlling timescales
There are three main areas to consider when timescales are threatened.
Improve how resources are used

v Introduce mobile resources.
v Use overtime.
v Flexible working hours to complete tasks which are almost finished and to avoid idle time on
tasks which are not ready to start.
v Temporary teams of optimum size and composition for key tasks.
v Improve people’s skills through training.
v Change the mix of resources used.
Increase efficiency
v Make sure that the right skills are used.
v Reduce waiting time by giving people other tasks.
v Reduce non-productive time, for example, on travel.
v Explore different working methods, for example, using a production line approach.
Improve work plans
v Group similar tasks together.
v Split and overlap critical activities to reduce the time spent on them.
v Reconsider the logic behind the activity as your original assumptions may no longer be valid.

Controlling deliverables
You will have identified actual project deliverables during work package definition. You will
have more control over producing the project deliverables if you link each one to a milestone on
the plan. Options available to you for controlling deliverables include:
v changing delivery schedules if possible (but agree this with users first);
v making sure that volumes are correct;
v confirming that things have been delivered to the right place;
v making sure that you meet the specifications by formally handing over and signing off the
project deliverable.
Controlling costs
You can achieve the most significant effect on costs when you specify the project deliverables
during the feasibility and definition phases. Once production has started, it will cost a great deal
more to change the design of project deliverables to reduce costs. Similarly setting realistic target
completion dates will make the process more cost efficient. Always ask the question: `Is this
really needed as soon as possible?'
Throughout the project you should:
v keep a close watch on what is being charged to the project and by whom;
v re-examine the technical specifications for alternatives;
& See Tools and techniques - Value management (page 165)
v consider sharing the cost of development with other projects;
v review purchase timescales;
v consider other resources;
v consider other ways of working;
v reorganise tasks to get rid of overheads on resources;
v release resources when you do not need them;
v consider other suppliers and review contracts; and
v make sure you order economically.
Controlling changes
When you have analysed the options available to bring the project back on track and chosen one
(or more), you may need agreement (and sometimes a new business case) to put the changes in
place. Changes to the overall time, cost or quality of deliverables must be authorised using the
change control procedures. You will then need to add these decisions to the plans and let the
project team know.
& See Tools and techniques - Change control (page 125)
& See Tools and techniques - Managing requirements (page 171)

Conclusion
The main elements of monitoring and control are:
v only collect information that is going to be used to control the project;
v check what you are being told - go and see for yourself;
v identify and solve problems before they affect the project;
v identify opportunities for improvement;
v use appropriate ways of analysing and forecasting;
v keep reports simple but effective; and
v act to keep the project on plan to meet the aims

Tools and techniques - Earned value management
Earned value management

Earned value management is a technique which gives you and the client a fair analysis of the
performance of the project. It also gives a reliable way of predicting what the project will cost
and how long it will take.
You can use the techniques we have described at any level in the work breakdown structure,
although you will normally measure cost and performance at the lowest level (in other words,
resources being used on an activity). You will then summarise these to higher levels as
necessary. You can also use the techniques with any part of the project and over any period of
the project.
Having a realistic plan and accurate monitoring data makes the technique of earned value
management much easier than it at first may appear.
Basic terminology
Earned value management relies on three simple items of data.
v Budgeted cost of work scheduled (BCWS) - what you planned to spend.
v Budgeted cost of work performed (BCWP) - the value of the work completed based on what
you planned to spend on it.
v Actual cost of work performed (ACWP) - what you actually spent on the work completed.
From these three items you can produce a series of indicators of past performance.
v Schedule variance (SV) - this shows how close the work done is to the plan.
v Cost variance (CV) - this shows how close the actual spend is to the planned spend.
v Schedule performance indicator (SPI) - this shows how efficient the work is against the plan
so far.
v Cost performance indicator (CPI) - this shows how efficient the spend is against plan so far.
You can then use these indicators to predict future performance.
v Estimated cost to complete (ETC) - how much more you are likely to spend.
v Estimated cost at completion (EAC) - what you are likely to spend in total.
You can produce two further indicators which show the performance needed to complete the
project within the original budget or within a new estimate.

Budgeted cost of work scheduled (BCWS)

This is the original amount you planned to spend for the work scheduled to be completed. It is
also known as the cost baseline. BCWS for the whole project is also referred to as budget at
completion (BAC).
Cost
Budget at complete (BAC)
Time
A typical spend plan for a project or work package.
Budgeted cost of work performed (BCWP)

This is also known as earned value. This is the amount you originally planned to spend on the
work that has actually been completed.
A common way of working out BCWP is by multiplying the BCWS at the end of the project
(BAC) by the percentage complete so far. This is not as difficult as it might seem because we
know what we planned to spend on completed activity and we also know what we plan to spend
on activities not yet started. You only need to assess those activities in progress. And, if your
planning has been thorough, the activities will be small enough in the overall project to allow you
to be reasonably accurate.

Schedule variance (SV)

From these first two basic pieces of information (BCWS and BCWP), you can work out a
schedule variance.
Schedule variance (SV) = BCWP - BCWS [This is usually expressed as a percentage.]
The SV shows whether the work is ahead, behind or on schedule. If the value of progress
actually achieved is less than planned, the SV will be negative. If the value of progress actually
achieved is more than planned, the SV will be positive. By plotting both BCWS and BCWP on
the same graph it is easy to see the whether the work is ahead or behind schedule.
Schedule variance (BCWP - BCWS)
Cost
Schedule variance

Time
Schedule
delay
The figure above shows some progress data (BCWP). The gap between BCWP and
BCWS is the schedule variance (SV). In this case the BCWP is less than the BCWS,
showing that the work is behind schedule. In other words, this is a picture of
unacceptable performance.
Actual cost of work performed (ACWP)

The actual cost of work performed is probably the most difficult to get. To make sure that you
capture all costs for the correct work packages usually means you need the support and advice of
the finance experts on the project team. However, when you know the actual cost of work
performed, you can plot that too on the graph to give you an idea of whether the project is over
or under budget.

Cost variance (CV)

When you have the ACWP it is possible to work out a cost variance (CV).
Cost variance (CV) = BCWP - ACWP. [This is usually expressed as a percentage.]
The CV shows whether costs are over, under or on plan. If costs are greater than planned, the
CV will be negative; if less than planned it will be positive.
Cost variance (BCWP - ACWP)
Cost
Actual cost of work performed (ACWP) Cost variance

Time
The figure above now includes actual cost of work performed (ACWP) information. The
gap between ACWP and BCWP is the cost variance (CV). In this case ACWP is
greater than BCWP, showing the work is over budget. The example shows the worst
possible situation - in other words, behind schedule and over budget.
Project under control

Cost
Actual cost of work performed (ACWP)
Time
All lines following a similar course with BCWP above BCWS and ACWP below BCWS,
would suggest things were under control and going to plan. The picture would look like
the picture above.

Performance trends
Schedule and cost variances are useful for showing how close things are going to plan. If
worked out and plotted for several reporting periods, they give an idea of whether things are
improving or getting worse.
Performance trends
Zero
Schedule variance
Cost variance
Time
The figure above shows a steady drop in both SV and CV over a number of reporting
periods. Cost variance and schedule variance around the zero line would show that
things were going to plan.
There are two further indices which can help us decide whether the project or work package is
on, behind or ahead of schedule and whether it is over or under cost.
Schedule performance index (SPI)

SPI = BCWP
BCWS
A result of less than one shows the project is behind schedule; greater than one it is ahead of
schedule.

Cost performance index of efficiency (CPI)

CPI = BCWP
ACWP
A result less than one shows that the project is over budget; greater than one means that it is
within budget.
Schedule and cost performance indices
Unfavourable
Favourable
(marginal)
ahead of schedule
ahead of schedule
and under budget
but over budget
Schedule
On
performance 1 plan
index (SPI)
Unfavourable
Unfavourable (marginal)
behind schedule
behind schedule
and over budget
but under budget
1
Cost
perfomance
index (CPI)
The figure above is a useful way of representing the two indices. If they both equal 1
then the co-ordinates will appear in the ‘On plan’ box. Otherwise the co-ordinates will
appear away from the ‘on plan’ box in one of the four areas shown (for example, if CPI
and SPI are less than 1 the co-ordinates will appear in bottom left area marked
‘Unfavourable - behind schedule and over budget’).
You can work out SPI and CPI for each resource at activity level and then, if appropriate,
summarise this to any level in the WBS. They are also time-based indicators which you can work
out for the current reporting period or any other relevant period of the project.

Estimated cost to complete (ETC)

You can use the cost performance indicator to work out the ETC.
ETC = BCWS at the end of the project - BCWP so far

CPI
You can then use this to work out:
Estimated cost at complete (EAC)

EAC = EAC + ACWP so far
CPI
You can use the schedule performance indicator (SPI) to work out how long it will take to
complete any unfinished activities.
Estimated cost overrun and time slippage
Estimate at
complete
(EAC)
Cost
Forecast Forecast
extra costs
Actual cost of work performed (ACWP) Forecast

time delay

Time
We have included the projections for ACWP and the EAC figure on the cost and
performance measurement graph which now shows the estimated extra cost and time
needed to finish the project.
To complete performance indicators

You can produce two further indicators which show the performance needed to complete within
original budget or within a new estimate

TCPI(BAC) = BAC - BCWP so far

BAC - ACWP so far
TCPI(EAC) = BAC - BCWP so far
EAC - ACWP so far
A figure of 1.25 would suggest that performance will have to be 25% better than planned for the
rest of the project.
Summary
You may be put off using earned value management because of the many calculations needed but
don’t worry, they are not as complicated as they appear. The techniques, including the
somewhat strange acronyms, are included in the professional organisation’s competency
requirements. Analysing project performance is an essential part of your role. The calculations
are simple arithmetic which you can include in a spreadsheet or project planning package.
Earned value management allows you to analyse the actual cost of work in relation to the value
of work performed, hence the term ‘earned value’. However, it does not identify specific pieces
of work and so is not a substitute for the other aspects of monitoring and control.
You need to put some effort into using these techniques and, as with other aspects of monitoring
and control, you should concentrate on those areas which will benefit most.
The project manager should spend some time with the client and contractors or work package
managers at the start of the development phase of the project explaining how earned value
management will be used to report project progress. Using these techniques and producing the
graphs and indicators is a powerful way of showing that things are under control (assuming they
are of course) or identifying problems in time to deal with them.

Tools and techniques - An example of earned value management
An example of earned value management

This example shows the steps you need to carry out an earned value analysis. The example
covers
v the basic arithmetic you need to work out the various indicators;
v help on analysing the results;
v suggestions for actions you can take to control the situation based on the findings in your
analysis.
It may at first glance appear a lot of work to carry out this analysis but remember that you can do
most of the calculations in a spreadsheet or project planning package.
In the example project reporting periods are every 10 working days and you need to produce a
summary report every 5th reporting period. You will analyse summary reports for periods 5, 10
and 15 but in practice you would carry out an analysis for each intervening period.
The project
Building a bridge.
The project is planned to take 320 days and it is estimated to cost £1 455 000.
The estimated spend for each activity is spread over the time the activity expected to take.
The following plans have been produced:
v work breakdown structure;
v network diagram;
v Gantt chart; and
v cost plan.

Project work breakdown structure
BRIDGE
PIERS APPRO ACH ROADWAY

wbsA1 wbsA2 wbsA3
SO UTH CENTRAL NORTH SOUTH NORTH 16 Erect

wbsA1.1 wbsA1.2 wbsA1.3 wbsA2.1 wbs A2.2 steelwork
17 Prepare
surface
01 Excavate 07 Excavate 10 Prepare 13 Prepare
04 Sink piles
foundations foundations groundwork groundwork 18 Lay tarmac
02 Pour 05 Pour 08 Pour 11 Lay 14 Lay

concrete contr ete concr ete foundations foundations
03 Erect 06 Erect 09 Erect 12 Lay top 15 Lay top

steelwork steelwork steelwork surface surface
Project network diagram

1 60 60 61 30 90 91 100 190
01 Sth pier 02 Sth pier 03 Sth pier

foundations concrete steelwork
1 0 60 61 0 90 91 0 190
91 30 120 121 20 140 141 60 200
10 Sth app 11 Sth app 12 Sth app

groundwork foundations surface
151 60 180 181 60 200 201 60 260
1 60 60 61 30 90 91 100 190
07 Nth pier 08 Nth pier 09 Nth pier

foundations concrete steelwork
1 F 60 61 0 90 91 0 190
91 30 120 121 20 140 141 50 190
13 Nth app 14 Nth app 15 Nth app

groundwork foundations surface
161 70 190 191 70 210 211 70 260
1 30 30 31 20 50 51 120 170 191 50 240 241 20 260 261 60 320
04 Central 05 Central 06 Central 16 Road 17 Road 18 Road

piles concrete steelwork steelwork surface tarmac
21 20 50 51 20 70 71 20 190 191 0 240 241 0 260 261 0 320

Project Gantt chart
WBS Duration Total Cost Project reporting periods

Activity
code (days) £1000 5 10 15 20 25 30 35
A BRIDGE PROJECT 320 1455
A.1 PIERS 190 515
A.1.1 SOUTH 190 220
01 Excavate foundations 60 150 3 3 3 3 3 3
02 Pour concrete 30 30 111
03 Erect steelwork 100 40 0 0000 00000
A.1.2 CENTRAL 170 75

04 Sink piles 30 15 1 1 1
06 Erect steelwork 120 40 00000 0000 000
A.1.3 NORTH 190 220
07 Excavate foundations 60 150 3 3 3 3 3 3
09 Erect steelwork 100 40 0 0000 00000
A.2 APPROACHES 110 440

A.2.1 SOUTH 110 230
10 Prepare groundwork 30 90 3 33
11 Lay foundations 20 20 11
12 Lay top surface 60 120 22222 2
A.2.2 NORTH 100 210

13 Prepare groundwork 30 90 3 33
14 Lay foundations 20 20 11
15 Lay top surface 50 100 22222
A.3 ROADWAY 130 500

16 Erect steelwork 50 250 5555 5
17 Prepare surface 20 100 55
18 Lay tarmac 60 150 33 3333
Project cost plan
£2 000 000
£1 500 000
BCWS
£1 000 000
£500 000
5 10 15 20 25 30
Report periods

Period 5 report
You have received the following information from the contractors and work package managers.
Although work on the foundations for the south pier (Activity 01) started on time it has
been going slowly because of bad weather which has caused some flooding to the site.
Excavations are now 50% complete but there is another 50 days’ work to be done.
You expect work to be completed by period 10. There are likely to be delays to the
start of the remaining work on the south pier (Activities 02 and 03).
The piles for the central pier (Activity 04) were completed on schedule but concrete
pouring (Activity 05) has not yet begun because of the bad weather.
The north pier foundations (Activity 07) could not start until period 3 because the
original contractor went into liquidation and another had to be found. However, the new
contractor is performing well and it is estimated that the work is now 60% complete. At
the current rate they will finish in period 7.
The budget controller has supplied the actual costs.
From that information, and the information in the project plans, you can put together the
following table.
Earned value analysis base data

Periods 1 2 3 4 5
Budgeted cost of work scheduled figures from the cost plan
BCWS for each period £55 000 £55 000 £55 000 £60 000 £60 000
Total BCWS £55 000 £110 000 £165 000 £225 000 £285 000
Actual costs reported by the Budget Controller
ACWP for each period £30 000 £40 000 £50 000 £50 000 £55 000
Total ACWP £30 000 £70 000 £120 000 £170 000 £225 000
BCWP calculations from period 5 summary report
South pier - foundations (01) £15 000 £15 000 £15 000 £15 000 £15 000
Central pier- sink piles (04) £5 000 £5 000 £5 000
North pier - foundations (07) £30 000 £30 000 £30 000
BCWP for each period £20 000 £20 000 £50 000 £45 000 £45 000
Total BCWP £20 000 £40 000 £90 000 £135 000 £180 000

You can now plot total figures for BCWS, ACWP and BCWP to give a picture of cost and
schedule progress against the plan.
Cost and schedule progress up to period 5

£300 000
£250 000 BCWS so far
£200 000
ACWP so far
£150 000
BCWP so far
£100 000
£50 000
1 2 3 4 5
Report periods
The Budget Controller has told you that £225 000 has been spent (ACWP) against a planned
spend of £285 000 (BCWS). You might be forgiven for thinking that all is well. However, this
graph tells a bleaker picture.
The BCWP is less than BCWS, so the project is behind schedule. ACWP is more than BCWP,
so the project is also over budget. You can confirm this when you work out the schedule
variance and cost variance and plot them on the progress chart. All variances are negative which
is bad.
Periods 1 2 3 4 5
SV = BCWP - BCWS
Schedule variance (SV) so far -£35 000 -£70 000 -£75 000 -£90 000 -£105 000
SV% = SV ÷ BCWS
Schedule variance (SV)% so far -64% -64% -45% -40% -37%
CV = BCWP - ACWP
Cost variance (CV) so far -£10 000 -£30 000 -£30 000 -£35 000 -£45 000
CV% = CV ÷ BCWP
Cost variance (CV) % so far -33% -43% -25% -21% -20%

Schedule variance and cost variance progress up to period 5

100
Percentage variance
50
0
CV so far
SV so far
-50
-100
1 2 3 4 5
Report periods
To set a trend figure for forecasting you have worked out the schedule performance index (SPI)
and cost performance index (CPI) at the end of period 5.
SPI calculation CPI calculation

= BCWP ÷ BCWS = BCWP ÷ ACWP
= £180 000 ÷ £285 000 = £180 000 ÷ £225 000
= 0.6 = 0.8
Both results are less than 1 which again confirms that the project is behind schedule and
overspent.
The CPI, SPI co-ordinates on the graph below give us another way of showing progress and
performance trends and you can use this picture to show people the state of the project or work
package.
Cost and schedule performance indicators
up to period 5
Ahead of schedule Ahead of schedule
but over budget and under budget
SPI 1
«Period 5
Behind schedule Behind schedule

and over budget 1 but under budget
CPI

Analysis results so far

The project has suffered an appalling start but the trend shows a slight improvement (SV% and
CV% are better in periods 4 and 5). The progress on budget and schedule have never been on
plan and are still well short of expectations. To achieve the original time and budget forecast, the
quality (specification) of the bridge or the method of working will have to change significantly.
Forecasting
You can use what you have so far to help forecast the likely outcome of the project. As a first
step you must assume that things will continue as they are. This will paint a rather bleak picture
but unless things change it would be a reasonable assumption to make.
Using the results from the analysis it is possible to work out an estimated cost to complete (ETC)
and an estimated total cost at the end of the project (EAC).
ETC calculation
= (BCWS at the end of the project - BCWP so far) ÷ CPI
= (£1 455 000 - £180 000) ÷ 0.8
= £1 594 000
EAC calculation
= ETC + ACWP so far
= £1 594 000 + £225 000
= £1 819 000
You can also work out the estimated time the project is going to take and the total length of the
project using the schedule performance indicator (SPI).
Time left calculation
= (Original planned duration - Time spent so far) ÷ SPI
= (320 days - 50 days) ÷ 0.6
= 450 days
Total time for the project calculation
= Time left + Time spent so far
= 450 days + 50 days
= 500 days
So, if things stay the same, it is estimated that the value of the work left to do (£1,275,000) will
cost £1 594 000 to complete and the project will be £364 000 over budget (EAC-BAC). The
work left (originally planned to take 270 days) will take 450 days to complete and the project will
be 180 days late.
You have analysed the whole project and it should be clear that under performance in one area
could be masked by over performance in another. In practice you would carry out the analysis at
the activity or resource level. You may decide to choose a more representative period to work
out the trend figures SPI and CPI (for example, the trend for the past two or three periods only).

In this case you would be particularly concerned about the south pier excavations (Activity 01)
where the contractors have estimated to complete by period 7 without explaining how they are
actually going to do this. You will have done an analysis on this activity or contractor. In
practice you would carry out the analysis over a number of different activities and periods before
settling on realistic estimates for the work left to do and the costs involved.
For the purposes of this example, you should assume you have carried out a number of analyses
and settled on a new forecast of £1 490 000 for the total project cost in order to finish on time.
You will have used earned value analysis to check whether the figure was reasonable by
producing indicators which show the performance rate needed to complete within the original
budget (TCPI(BAC)) and to a revised estimate when the project is complete (TCPI(EAC)).
TCPI(BAC) calculation
= (BAC - BCWP so far) ÷ (BAC - ACWP so far)
= (£1 455 000 - £180 000) ÷(£1 455 000 - £225 000)
= 1.04
TCPI(EAC) calculation
= (BAC - BCWP so far) ÷ (EAC - ACWP so far)
= (£1 455 000 - £180 000) ÷(£1 490 000 - £225 000)
= 1.01
The TCPI indicators show that to complete the project within the original budget the remaining
work must be carried out at 104% effectiveness. And, to complete within the new estimate, the
work must be carried out at 101% effectiveness (in other words, slightly better than planned).
The revised target and the original target are both achievable at this stage as long as you change
the way the project is being done. There is enough of the project left to recover from the poor
start.

Period 10 report
The south pier foundations (Activity 01) was completed as expected in period 7 which
allowed the start of concrete pouring (Activity 02) in period 8. However, that activity is
only 15% complete and the work of erecting steel for the south pier (Activity 03) has
not yet started.
Work on the central pier steel work (Activity 06) is now well underway. The contractor
is reporting 30% complete and also forecasting completion of the central pier ahead of
schedule. The central pier concrete pouring (Activity 05) was completed in period 7.
The north pier foundations (Activity 07) managed to maintain their impressive work rate
and completed in period 7. However, the concrete pouring for the north pier (Activity
08) did not start until period 9 because the contractor on the foundations failed to report
that they had completed their activity.
From that information and the information in the project plans you can put together the following
table.

Periods b/fwd 6 7 8 9 10
Total BCWS £285 000 £338 000 £362 000 £385 000 £409 000 £480 000
Total ACWP £225 000 £285 000 £355 000 £435 000 £465 000 £500 000
South pier - foundations (01) £37 500 £37 500
South pier- pour concrete (02) £1 500 £1 500 £1 500
Central pier- pour concrete (05) £10 000 £10 000
Central pier- steel work (06) £4 000 £4 000 £4 000
North pier - foundations (07) £30 000 £30 000
North pier- pour concrete (08) £1 500 £1 500
Total BCWP £180 000 £257 500 £335 000 £340 500 £347 500 £354 500

We have added the figures for BCWS, ACWP and BCWP to the progress graph.
£600 000
£500 000 ACWP so far
BCWS so far
£400 000
£300 000 BCWP so far
£200 000
£100 000
1 2 3 4 5 6 7 8 9 10
Report periods
Although things started to improve in periods 6 and 7, the project is still behind schedule (BCWP
is less than BCWS). ACWP is still more than BCWP so the project is still over budget. Things
looked encouraging in period 7 (BCWS, BCWP and ACWP are beginning to meet).
You can confirm this when you work out the schedule variance and cost variance and plot them
on the progress chart. All variances are negative, in other words, bad.
Periods 6 7 8 9 10
SV = BCWP - BCWS
SV% = SV ÷ BCWS
CV = BCWP ÷ ACWP
CV% = CV ÷ BCWP


100
Percentage variance
50
0
SV so far
CV so far
-50
-100
1 2 3 4 5 6 7 8 9 10
Report periods
To set a trend figure for forecasting you have worked out schedule performance index (SPI) and
cost performance index (CPI) at the end of period 10.

= £354 500 ÷ £480 000 = £354 000 ÷ £500 000
= 0.74 = 0.71
Both results are less than 1 which again confirms that the project is behind schedule and
overspent.
The SPI, CPI co-ordinates on the graph below together with the figures for period 5 show that
SPI has improved but CPI has got worse between periods 5 and 10.

up to period 5 and period 10
SPI 1
«Period 10
«Period 5

CPI


The improvement continued from period 5 through to period 7 but there is now a definite trend
downwards away from plan for budget and schedule and you must turn this round quickly. It
seems that the work has speeded up (SPI is improved) but it is costing more (CPI has got
worse).
Forecasting
step you must assume that things will continue as they are.
Using the results from the analysis it is possible to work out an estimated cost to complete (ETC)
and an estimated total cost at the end of the project (EAC).
ETC calculation
= (BCWS at the end of the project - BCWP so far) ÷ CPI
= (£1 455 000 - £354 500) ÷ 0.71
= £1 550 000
EAC calculation
= ETC + ACWP so far
= £1 550 000 + £500 000
= £2 050 000
You can also work out the estimated time the project is going to take and the total length of the
project using the schedule performance indicator (SPI).
= (320 days - 100 days) ÷ 0.74
= 297 days
= 297 days + 100 days
= 397 days
It is estimated that the value of the work left to be done (£1 100 500) will cost £1 550 000 to
complete and the project will be £595 000 over budget. The remaining work (originally planned
to take 220 days) will take 297 days to complete and the project will be 77 days late.
You have spent more money to claw back time on the schedule. Compare the results with period
5.
You have carried out the analysis for the whole project and it should be clear that you can mask
under performance in one area by over performance in another. In practice you would carry out
the analysis at the activity or resource level. You may well decide to choose a more
representative period to work out the trend figures SPI and CPI (for example, the trend for the
past two or three periods only).

You have agreed to changes in working practices to speed up the building work and have
accepted design changes to the bridge roadway which will save on cost. For the purposes of this
example, you have agreed a new forecast of £1 640 000 for the total project cost in order to
finish on time. You used earned value analysis to check whether the figure was reasonable by
producing indicators which show the performance rate needed to complete within the original
budget (TCPI(BAC)) and to a new estimate when the project is finished (TCPI(EAC)).
= (£1 455 000 - £354 500) ÷ (£1 455 000 - £500 000)
= 1.15
= (£1 455 000 - £354 500) ÷(£1 640 000 - £500 000)
= 0.97
The TCPI indicators show that to complete the project within the original budget the remaining
work must be carried out at 115% effectiveness. And, to complete within the new estimate the
work must be carried out at 97% effectiveness. The new target is not particularly ambitious but
it is looking unlikely that you will complete the project within the original budget, timescale and
quality aims.

Period 15 report
Concrete pouring for the south pier foundations (Activity 02) was completed during
periods 11 and 12. The steel work for the south pier (Activity 03) started in period 13
and is now 60% complete.
The central pier was completed ahead of schedule in period 15. The contractor
responsible for the steel work for the central pier (Activity 06) increased the steel
erecting workforce by 50% in period 12 to reduce the time needed for a floating crane.
Concrete pouring for the north pier (Activity 08) was completed in period 12 and the
steel work (Activity 09) is now 60% complete.
The groundwork for the southern approach (Activity 10) was started in period 11 and
finished in period 13. The foundations for the southern approach (Activity 11) started in
period 15 and is now 60% complete.
The groundwork for the northern approach (Activity 13) was started in period 11 and
finished in period 14. The foundations for the northern approach (Activity 14) started in
period 15 and is 50% complete. The top surface for the northern approach (Activity 15)
is being fast tracked and is 20% complete.

From that information and the information in the project plans you can put together the following
table.
Periods b/fwd 11 12 13 14 15
Total BCWS £480 000 £551 000 £622 000 £654 000 £685 000 £736 000
Total ACWP £500 000 £575 000 £650 000 £705 000 £753 000 £788 000
South pier- pour concrete (02) £12 700 £12 800
South pier- steel work (03) £8 000 £8 000 £8 000
Central pier- steel work (06) £4 000 £6 000 £6 000 £6 000 £6 000
North pier- pour concrete (08) £13 500 £13 500
North pier- steel work (09) £8 000 £8 000 £8 000
South approach - groundwork (10) £30 000 £30 000 £30 000
South approach - foundations (11) £6 000 £6 000
North approach - groundwork (13) £22 500 £22 500 £22 500 £22 500
North approach - foundations (14) £10 000
North approach - top surface (15) £20 000
Total BCWP £354 500 £437 000 £522 000 £597 000 £647 000 £705 000

Plotted to the progress chart.
ACWP so far
£800 000
BCWS so far
BCWP so far
£600 000
£400 000
£200 000
5 10 15
Report periods
The picture is still bad but a great improvement over the previous report at period 10. BCWP is
less than BCWS - so behind schedule. ACWP is more than BCWP - over budget but they are a
lot closer together. ACWP is also greater than BCWS reflecting the extra costs forecast at
period 10.
You will confirm this when you work out the schedule variance and cost variance and plot them
on the progress chart. All variances are negative but all are improving.
Periods 11 12 13 14 15
SV = BCWP - BCWS
SV% = SV ÷ BCWS
CV = BCWP - ACWP
CV% = CV ÷ BCWP

Again a graph of the cost variances and the schedule variances shows the picture a little clearer.
100
Percentage variance
50
SV so far
0
CV so far
-50
-100
5 10 15
Report periods
The trend has reversed and things have improved since period 10. The project has still to report
things on plan and to budget but the variances are getting closer to the plan line. Schedule and
cost variances for the past five periods will have been very positive to have made such an effect
on the results as shown below.
Periods 11 12 13 14 15
SV = BCWP - BCWS
Schedule variance (SV) £11 700 £13 800 £43 500 £19 500 £7 000
SV% = SV / BCWS
Schedule variance (SV)% 16% 19% 138% 61% 13%
CV = BCWP - ACWP
Cost variance (CV) £7 700 £9 800 £19 500 £2 500 £23 000
CV% = CV / BCWP
Cost variance (CV) % 10% 13% 35% 5% 66%
To set a trend figure for forecasting you have worked out the schedule performance index (SPI)
and cost performance index (CPI) at the end of period 15.
= £705 000 ÷ £736 000 = £705 000 ÷ £788 000
= 0.96 = 0.89

Both results are less than 1 which confirms that the project is still behind schedule and overspent.
However, there has been a significant improvement since period 10. The actions put in place to
improve things must be working.
SPI, CPI co-ordinates on the graph below both show a marked improvement.
up to periods 5, 10 and 15
SPI 1 «Period 15
«Period 10
«Period 5

CPI

The project has made considerable improvements from period 10 through to period 15. The
project has almost recovered from the appalling start but is still behind schedule and over budget.
There will have been significant changes to the way the project had been progressing to period
10. From period 11 to period 15 the SPI and CPI are 1.37 and 1.22. (in other words, schedule
performance was 37% better than planned and cost performance was 22% better than planned)
Forecasting
step you should use the figures based on progress so far.
Using the results from the analysis you can work out the estimated cost to complete (ETC) and
an estimated total cost at the end of the project (EAC).
ETC calculation
= (BCWS at completion - BCWP so far) ÷ CPI
= (£1 455 000 - £705 000) ÷ 0.89
= £842 500
EAC calculation
= ETC + ACWP so far
= £842 500 + £788 000
= £1 630 500

You can also work out the estimated time the project is going to take and the overall length of
the project using the schedule performance indicator (SPI).
= (320 days - 150 days) ÷ 0.96
= 177 days
= 177 days + 150 days
= 327 days
You have estimated that the value of the work left to do (£750 000) will cost £842 500 to
complete and the project will be £175 500 over budget. This is much closer to the original plan
and very close to your forecast at the end of period 10. The remaining work (originally planned
to take 170 days) will take 177 days to complete and the project will be seven days late.
You agreed changes to working practices in order to speed up the building work and design
changes to the bridge roadway at the end of period 10 and they seem to have done the trick.
Compare the results with those at period 10.
In view of the increased performance over the past five reporting periods you have agreed a new
forecast of £1 560 000 for the total project cost in order to finish on time. You used earned
value analysis to check whether the figure was still reasonable by producing indicators which
show the performance rates you need to complete within the original budget (TCPI(BAC)) and
the new estimate for the total project (TCPI(EAC)).
= (£1 455,000 - £705 000) ÷(£1 455 000 - £788 000)
= 1.12
= (£1455 000 - £705 000) ÷(£1 560 000 - £788 000)
= 0.97
The TCPI indicators show that to complete the project within the original budget the work left to
do must be carried out at 112% effectiveness and to complete within the new estimate it must be
carried out at 97% effectiveness. (In other words, at slightly less than planned but well within
the rates achieved between periods 10 and 15.) The revised estimate is not particularly
ambitious. The original budget target for the project is tough but achievable.

Summary
The example we have worked through we have carried out the analysis for the whole project but
you should be clear that you can mask under performance in one area by over performance in
another. The same reports would normally be produced for smaller elements of a project, for
example:
v by groups of activities (in other words, work packages);
v by resource type;
v by project organisation; and
v for specific time periods.
The reports are much more meaningful for control purposes if you produce them at these levels
in the project.
Earned value management techniques provide indicators about project performance in financial
terms. You need to look carefully at the reasons behind the results along with other project
progress reports because the techniques do not distinguish between the specific pieces of work
completed and that which was planned to have been completed.
You will get the data you need for the analysis from contractors or work package managers who
could also carry out an earned value analysis on their work packages before sending you the data.
You may insist that they do this as part of your standard reporting procedures.

Tools and techniques - Change control
Change control
Change control means that you identify, evaluate, authorise or reject any changes which are likely
to affect the project significantly. You also monitor how they are dealt with. You should make
clear formal procedures for controlling change to all project team members.
Formally controlling change benefits the client, by making sure that you consider effects on cost,
time and quality of deliverables before you make any changes. You and everyone else on the
project team benefit because you reduce any disruption caused by unnecessary changes.
Client reviews should test the original project assumptions against the current business
environment and you should put in place any changes needed using these procedures.
Change control process

Change control involves:
v registering;
v evaluating;
v approving or rejecting; and
v implementing any changes needed to the project.
Registration
A change request should be registered with you so that the you can evaluate the possible
consequences. The person asking for the change should send a clear and complete specification
of the change with supporting documents, as appropriate.
You should keep a register of changes which will:
v allow you to work out the total effect on the project cost and timescale of changes that have
been approved or are waiting to be approved;
v provide a quick summary of the status of all change requests;
v make sure that you do not waste time on many requests for the same change;
v allow you to measure the cost of evaluating changes;
v help in the post-implementation review;
v provide pointers to areas where there is a lot of disruption due to frequent changes; and
v provide, for cases of dispute, a way of tracking why and how a change was made.
Evaluation
If you decide to go ahead with an evaluation, you should consider all options for making the
change before you recommend whether to approve or reject it. You and the person asking for

Tools and techniques - Change control
the change should consult other contractors and specialists to identify the effects of the change
in:
v costs and benefits;
v timescale;
v quality of deliverables
v resources and procurement;
v legal requirements;
v contractual commitments; and
v risk management plans.
You should record significant costs involved in evaluating the change request.
The results of the evaluation should include a recommendation to either accept or reject the
change and must be agreed by everyone affected.
Approval or rejection
Contractors or work package managers will agree changes with you if only their work package is
affected.
You must approve or reject changes which affect more than one work package but do not affect
the overall project timescale, cost or quality of deliverables.
All other changes will need the client’s agreement.
If unavoidable changes will have a significant effect, you may need to prepare a revised business
case and re-authorise the project or stop it.
Implementation
You must let everyone involved know about the plans for putting the change in place.

Tools and techniques - Managing issues
Managing issues
An issue is a problem or concern that needs to be sorted out but does not seem to be receiving
attention. The purpose is to control the way you do this for issues which could threaten the
successful outcome of the project. It is particularly important to have a way of dealing with
issues during the early stages of a project.
The procedures for managing issues should:
v encourage others to raise issues;
v concentrate attention on important issues;
v provide a focal point for monitoring the status of issues;
v add to existing lines of communication within the project; and
v be widely understood throughout the project.
They should not:
v become a bottleneck within the project;
v replace existing lines of communication;
v be bureaucratic;
v change any individual's responsibility or accountability; or
v handle issues that can be clearly sorted out by a single contractor or work package manager.
Issue manager
You should choose a team member to be the issue manager who will be responsible for:
v receiving and acknowledging details of the issue;
v assessing the effect;
v choosing someone who will be responsible for sorting the issue out;
v agreeing what classification and priority to give the issue;
v progressing and reporting until the issue is sorted out;
v making sure everyone knows how the issue has been dealt with;
v making sure everyone does as they are asked in relation to the issue; and
v keeping the issue progress log.
Procedure
There is a simple set of checkpoints for monitoring the progress of an issue from when it is raised
until it is sorted out.
1. Raise the issue.
2. Acknowledge the issue.
3. Assess the issue.
4. Decide who has responsibility.
5. Check the progress.
6. Sort the issue out.
7. Close the issue.

Raise the issue

Anyone on the project must be able to raise an issue giving details of the likely effect.
Acknowledge the issue

The issue manager should give a reference number to the person who raised the issue. The
reference number should be used in all correspondence about the issue.
The issue manager should keep a progress log so that the current status of all issues is readily
available.
Assess the issue

The issue manager should carry out an assessment by consulting with others if necessary, and
consider the following points.
v Is it within the scope of the project and relevant?
v Has the issue already been sorted out?
v Which work packages are affected?
v What priority is appropriate?
A simple classification system can help when you need to take decisions on priority, for example:
v issues which cannot be sorted out by the project team; and
v issues completely within the team's control.
Assign responsibility
The issue manager should someone who will be responsible for sorting the issue out and tell the
person who raised the issue. This responsibility should not change without the issue manager’s
approval. The appointed person should identify and report to the issue manager, all actions
needed to sort the issue out.
Progress
The Issue Manager should regularly review progress against the actions needed to sort the issue
out.
Resolution
The process for sorting the issue out will depend largely on the nature of the issue raised but
must include:
v consulting all involved;
v identifying a proposed solution;
v agreeing to the proposed solution; and
v communicating the agreed resolution.
If sorting out an issue means changes to the project plan, you should carry these out through the
normal change control procedures.

Close the issue

When you have sorted out an issue, you will need to include a statement of the actions needed in
the issue management log. The person who came up with the issue should agree that the issue
has been properly sorted out.


Tools and techniques - Risk management
Risk management
A risk is an uncertainty which could either provide opportunities to increase forecast benefits or
prevent you from achieving the project aims. Managing risk does not simply mean responding to
events when they happen, it is doing as much as possible to anticipate events and to plan and act
accordingly.
Managing risk in projects breaks down into three main areas.
Identifying the risk

Identifying risks and any obvious responses to those risks.
Evaluating the risk

Assessing the risks in order to get a better understanding of the chance of them happening and
their possible effect. It also includes choosing the appropriate responses.
Controlling the risk

Making decisions and taking action to cope with the risks.
Benefits of using project risk management

There are many benefits in managing risk in the wider business arena, for example, to make sure
that you prioritise investment opportunities, not starting ‘no-win’ projects and making sure that
budgets are realistic.
Managing risk in projects focuses on risks which can affect the outcome of the objectives which
have been set. The benefits are:
v more chances of success by facing up to realities and focusing on main threats;
v more team motivation;
v more realistic targets;
v a shared recognition of the problems facing the team and the steps being taken to deal with
these;
v more planned and less reactive working;
v better planning, giving better visibility and control;
v winning more bids on competitive tendering projects by increasing customer confidence; and
v improved future projects because documents are available which give details of lessons
learned.
By managing the risk involved in a project everyone can tell the difference between good
management and good luck, bad management and bad luck. You need an element of risk for
business success, but you must manage these risks to gain most benefit from the investment in
projects.

Managing risk focuses attention not only on the threats to a project, but also on the opportunities
that may help the project to be completed sooner, at lower cost and greater quality.
When to use project risk management

There is no specific right or wrong time to manage risk because the techniques support decision
making throughout the project. However, you will gain significant benefits during the early
phases of a project when you make major decisions and set plans for monitoring and control.
Project workshops are ideal for carrying out initial risk assessments.
The types of project or work package which benefit most from managing risk are those that:
v involve a high level of uncertainty;
v are strategically important;
v could possibly interrupt crucial revenue;
v cost a lot;
v use new technology;
v involve sensitive issues (for example, the environment); and
v involve political or regulatory issues.
How to do it
There is no single all purpose method. It is best to start simply and develop more complicated
methods only when it is sensible and cost effective.
Managing risk is a repetitive process. The aim is to improve the way you manage risks by
considering all available information and expertise. You can achieve this by:
v interviewing members of the project team;
v brainstorming with everyone with an interest;
v using personal experience; and
v reviewing past project experience using, for example, project closure reports.

You can improve on all these methods by using prompt lists which can either be general or
specific to the type of project.
Purpose Define objectives of the risk assessment
Identification
Identify top level project activities
Create risk register
Identify risks
Identify risk Identify responses
Assess likelihood and impact for each risk

Assess Assess overall effect on project
Evaluation
Prioritise risks
Identify risk owners
Choose appropriate responses

Plan response Include responses in the project plan
Implement responses
Monitor risks, causes and responses

Monitor and Control
Control
Re-assess existing risks

Re-assess effectiveness of responses
Update the risk register
Hold review meetings
Identify and assess new risks
Close project
The process of managing risk is shown in the figure above.
Defining the objectives of the assessment

It is important that everyone involved in the analysis clearly understands the aims of the analysis.
The analysis can focus on one particular type of risk such as financial or technical or it can be
broadened to cover, for example:
v assessing the overall development risk for a bid;
v choosing options for implementing the project; and
v assessing the operational risk.
All these areas are linked but generally a project or bid will have a focus of concern. You must
have set the project aims in terms of meeting a particular specification, within an overall
timescale, and within an overall cost. It is only in relation to these goals that risks arise. You
should not consider events that do not affect the project goals a risk to the project.
Time, cost and performance are often represented by a triangle. If a project is placed near one of
the corners, it shows how important that factor is. Few projects when analysed are marked at the
centre of the triangle. Positioning a project within this triangle can be a useful way of focusing

the risk analysis.

Time
Project A
Project C
Project B Specification
Cost Quality
Performance
Timing is important to project A - this may be a new product which has a lead on the
competition. An assessment should focus on risks which could affect the schedule and
opportunities for improvement.
An assessment for project B should consider risks which have a significant effect on
costs.
Identifying top-level project activities

An important step in managing risk is to identify a limited but thorough set of significant project
activities. The breakdown should contain between 10 and 20 numbered activities, cover the
whole project, and not overlap. You can use the project's summary plan, network diagram and
work breakdown structure to identify these important activities. The work breakdown structure
is particularly useful and we give an example below.
BRIDGE
PIERS APPROACH ROADWAY

wbsA1 wbsA2 wbsA3
SOUTH CENTRAL NORTH Risk 01 Risk 01

wbsA1.1 wbsA1.2 wbsA1.3 Severe weather Agency Funding
Risk 02
Contractor reliability
Risk 01 Risk 01
Flooding Risk 01 Ground condition
Risk 02 River bed problems
Ground condition

You must understand and be able to interpret each activity so that the team can correctly identify
sources of risk. You should start a risk register as soon as risks are identified. As more
information about each risk becomes available you can then record it in the risk register.
Notes on content of risk register

Description of activity The main inputs and outputs of the activity, work
function involved and factors which may affect the
start of the activity.
Type of risk What could go wrong
Causes of risk What could cause the risk to happen
Responses - The measures, if any, that you can take to prevent
Risk reduction measures or contain the risk to a minimum and where there
are options, which measures you should choose
first.
Secondary risks Any secondary risks which may arise as a result of
using preventative measures and any responses
Responses - Other activities that you could adopt to overcome
fallback plans the risk
Secondary risks Any secondary risks that may arise as a result of
adopting the fallback plan
Latest decision to The latest date you can use the fallback plan without
implement fallback plans delaying the overall project, or how long the delay
will be if it is unavoidable.
Identifying risk
There is a difference between a risk and an identified cause of that risk. For example, there may
be a risk that ‘software will be developed late’, but there may be several reasons behind that risk
which you can identify by asking ‘What can cause that?’. It is analysing the causes of risk that
will reduce the threats to the project and identify areas of opportunities .
The people who can identify risks are the various functional or technical experts. You must use
this expertise to get the most benefit from this activity.
There are many ways you can identify what cause risks. You can use:
v stakeholder analysis;
v questionnaires;
v checklists and prompt lists;
v interviews - possibly using checklists or questionnaires as a starting point;
v brainstorming;
v cause-and-effect diagrams; and
v risk questions on estimate forms - when you ask for estimates of activities, ask for the worst
case, the best case and the expected - with explanations for the different values.
Three examples of identifying risks are shown below.

Example 1 - Sources of risk - prompt list

It is useful to have a focus to help you identify risks. A number of important areas are shown
below.
Sources of risk prompt list

Time
Organisation and personnel
Degree of change
Degree of complexity
Constraints
Technical
Level of security
Technology
Management
Social
Plant and equipment
Team and resource
Economic
Test facilities
Schedule
Political
Materials and resources
Financial
Production
Labour force
Contractual
Activity duration
Overseas
Consider the first few on the list.
Time
The longer an activity, the less confidence you can place on how long it will take.
Organisation and personnel

The more people involved, the greater the chance of failure. It is usually people who
cause projects to fail. Identify the risks suggested by the number of people involved.
Identify the risks suggested by the locations involved .
The following can also increase the chances of failure.
Ÿ how the project is managed and the availability of resources;
Ÿ the environment the project is carried out in;
Ÿ how clear the aims are;
Ÿ staff morale and motivation; and
Ÿ the number of departments involved.
These all produce questions and possible sources of risk. Each project will have its
own set of organisational and personnel issues.

Degree of change
The degree of risk for each activity is related to the degree of change. The attitude
towards any change will affect the number and type of risks. Some issues that may
suggest risks are:
personnel changes;
process or procedural changes;
new systems ; and
training requirements.
Degree of complexity
Items that may affect complexity are:
Ÿ complicated technology ;
Ÿ number of different parts that need to work together ;
Ÿ number of different specialists needed; and
Ÿ scope.
Each project will have specific complexities that you need to consider.
Constraints
The limits on the project affect the possible risks. We can class restrictions in many
ways:
Ÿ Business: fixed deadlines, financial;
Ÿ Technological: whether it is compatible or not;
Ÿ Regulatory;
Ÿ Resources: manpower, skills and availability ; and
Ÿ External
Example 2 - Cause and effect diagram

Resources Planning
Wrong skill level Wrong planning tools
Poor estimation data

Low production
Non specialist planner
High error rates
Inadequate project planning EFFECT
Schedule
slipping
Inadequate test equipment Poor delivery record
Poor delivery record Poor response to variations
High level of defects Changing site access
High error rates Poor project management
Materials Contractor
Try to produce responses for the causes, for example, ‘wrong planning tools’, ‘poor
estimation data’ and so on, rather than producing responses for the effect ‘Schedule
slipping’.

It is usually possible to reduce the effects of risk by reacting to their effect. However, it is better
to concentrate on the cause and produce a response to that. Cause and effect diagrams are ideal
for identifying the possible causes of behind project risks. A single effect may be the result of a
complicated interaction of various causes. And, a single cause may add to a variety of effects of
project risks.
You may need to put together a number of cause and effect diagrams because an identified cause
may be the effect of a higher-level cause.

Example 3 - Types of risk - prompt list

Business risk Pure risk
Technical Unforeseen snags in new processes Nature Earthquake
Lack of knowledge Fire
Unproved technology Flood
Unclear or incomplete specifications
Management Industrial relations Misconduct Theft
Management structures which have not Fraud
been established Riot
Financial approval structures which have Negligence
not been established
Resources not being available
Economic Changes in economic activity Technical Breakdown of plant
Inflation Failure of safety devices
Monetary and financial policy Dangerous processes
Actions of competitors
Political Privatisation Personal Death
Nationalisation Sickness
Political unrest Injury
War
Trade restrictions
Production Interruption of production.
Change in expected costs
Restrictions on supplies of raw materials
Marketing Mistakes in forecasting
Loss of markets
Changes in consumer tastes
Financial Bad debts
Changes in availability or the cost of
credit
Pure risk is where there is only a chance of loss and you can usually insure this. However, risk to
the business means there is a chance of profit as well as loss and it usually isn't cost effective to
insure against this. It is good practice to develop specific checklists but you must realise the
possible pitfalls. Checklists should stimulate creative and constructive thought but there is the
danger that going through the checklists and completing the procedure can become an end in
itself. When you have done this, you could feel that you have now managed the risk when, in
fact, that is not the case.
Identify responses
The next stage in the process involves identifying responses for each cause of risk, and recording
the action which may be necessary. The types of responses you could identify are shown below.
v The preventative response where you take action beforehand to avoid the risk entirely.
v Reducing the likelihood of the risk happening and reducing the effect if it does.
v Setting aside time and money for a plan to deal with the effect of a risk if it does happen.
(These are alternative or other activities that you would carry out if the risk actually happens.
You will usually need to take action before the risk happens to avoid delays to the project.)
v Choosing to do nothing about the risk and accept the consequences. This may be because
the risk is so unlikely or that the other types of possible responses are not cost effective.

It is better to get a number of possible responses for each risk. While you are identifying the risk
you only need a brief description of each response. You can work out details of cost and time, if
necessary, during the assessment stage.
For each response it is useful to show what work needs to be done immediately and what needs
to be done later. There may be risks for which you cannot identify a suitable response and you
must identify resources that you will need if the risk happens. You must closely monitor these
risks. There may also be significant risks which you cannot control and in this case you need to
contact specialists for guidance, for example, treasury or insurance services.
Putting in place a response may result in creating secondary risks which you must deal with using
the same process.
Assess the likelihood and effect

At this stage of evaluation you need to decide what is and is not important. When the primary
responses and secondary risks and responses are clear, you may be able to ignore some risks
because you already have effective responses.
For each risk left, you should evaluate the effect and likelihood of it happening. Generally, those
activities, early in the project will have a greater effect downstream than later ones. You can use
a simple rating system of high, medium and low to determine the effect and likelihood of a given
risk.

The project team should agree on their definitions for each band and the table below shows a
form we suggest. There will be some overlap between these (especially time and cost).
Likelihood of occurrence
High (H) More likely to happen than not (>50%)
Medium (M) Fairly likely to occur (20% - 50%)
Low (L) Low but not impossible (0% - 20%)
Impact on schedule (time)

High (H) Causing a large delay (>30%)
Medium (M) Causing a significant slip (10% - 30%)
Low (L) Causing a small slip (0% - 10%)
Impact on cost
High (H) Large increase (>30%)
Medium (M) Significant increase (10% - 30%)
Low (L) Small increase (0% - 20%)
Impact on performance
High (H) Major shortfalls in key parameters
Medium (M) Some shortfalls in one or two areas
Low (L) A few shortfalls in secondary parameters
You should record all risks in the risk register and you need to review them regularly in case they
become significant later in the project. Many project managers have found, to their dismay, that
a risk identified as low likelihood and low impact at the start of a project and put to one side,
becomes a major problem when the project is being implemented.
The ‘Likelihood / Impact Matrix’ shown in the figure below is a compact way of showing how
important the risk is. In this case, columns represents the likelihood of the risk happening and the
rows the effect if it does.
High B
IMPACT
Medium
Low A
Low Medium High

LIKELIHOOD
The likelihood of falling when walking along a normal path is quite low and is one which
the average person would ignore (shown in the matrix as A). However, if that path is
inches from a cliff edge, the likelihood is still the same (that is, low) but the effect,
should it happen, is so catastrophic (shown in the matrix as B) that it would be sensible
to take precautions.

For each risk, first assess the likelihood of the risk happening and then assess the effect on the
project if it does. You can use the table below as a guide to people’s views of probability.
Perceptions of probabilities
Probability
Perception statement
value
You feel virtually certain that the event will happen 0.9 to 1.0
You feel strongly that that the event will happen 0.8
You are moderately certain that the event will happen 0.65
You feel that there is a better than evens chance that the event will happen 0.55
You feel that it is as likely to happen as not 0.5
You feel that there is a slightly greater chance that the event will not happen 0.45
You are moderately sure that it will not happen 0.35
You feel strongly that the event will not happen 0.2
You feel virtually certain that the event will not happen 0 to 0.10
(Most major risks should be in this area)
If the risk is 0.5 or more then include the response as an activity in the project plan
in other words, assume that it is going to happen.
Prioritising risks
When you have finished analysing the likelihood and effect you can identify those causes of risk
on which you should focus most of your attention. The project team must decide which risks to
investigate but the grid below shows the importance of risks in relation to where they appear on
the likelihood and impact matrix.
Importance of risks in the matrix
Rare Probable
High
catastrophe disaster
IMPACT
Medium
Unlikely Recurring
Low
minor niggle
Low Medium High

LIKELIHOOD
For most projects this level of assessment will be enough. For some projects, particularly if the
client asks you to carry out risk modelling, you will find some examples of risk modelling at the
end of this section.

Identifying the risk owner

When you have decided on how important the risk is, you need to identify who will have
responsibility for managing it. This person is a ‘risk owner’. You should choose someone who
is close to the source of the risk and can manage it.
Plan response
It is easier to analyse the risks and responses if you split them into three categories.
Important risks
These are risks that are placed in the top right-hand corner of the likelihood and impact matrix
which need immediate action to reduce the effect or probability, or to remove them altogether.
Recurring risks
Risks which could happen many times during the project. Although a single event may have a
low effect the combined effects of the risk happening many times may significantly disrupt the
project.
Other risks
These may be easier to analyse if you categorise them further as to whether their effect is greater
on the cost, time, or the project deliverables.
Risks which affect time may need you to reschedule the project now or some time in the future,
particularly if the activities that would be affected by the risk are on the critical or near-critical
paths.
Risks affecting costs will often be a result of the need to overcome a time or specification
problem. You should investigate a number of other courses of action and look at the costs.
You need to take immediate action on risks affecting performance of deliverables because the
basis on which the project is being done may be threatened.
You should record the agreed responses in the risk register.
Implementing responses
This may involve amending the project plans to reduce the risk, developing contingency plans to
allow you to respond rapidly if certain risks happen and setting up monitoring procedures for
important areas so that you get early warning of any risks which happen.
You should include the responses to any risk with a probability of 0.5 (50%) or more as activities
in the project plan (in other words, assume that it is going to happen). You should also include
‘Do later’ responses in the project plan. In other words, no action will be taken unless the risk
actually happens or a trigger point is reached.

Monitoring and controlling risks

You should monitor risks until there is no further possibility of them happening. You should
make sure that the risk monitoring procedures are included in the general project monitoring and
control procedures.
If something unexpected happens, it is important to confirm that it was as a result of an already
identified source in case there are secondary risks which you need to include in the risk
management plans.
You can use a risk summary sheet to simplify monitoring, reporting and reviewing.
Previous Current Date
Risk Description Likelihood Effect Strategy Owner
status status closed
Previous and current status could use red, amber, green status indicators.
Red = active and affecting the project.
Amber = active but not affecting cost or schedule.
Green = not yet active.
You should continue to manage risk throughout the project because new risks could happen.
Monitoring procedures must also record which risks actually happen and what action you have
taken. You should set up a central library of this information to provide information for future
projects.
You should enter details of each risk on the risk register which you should keep up to date
throughout the project. You can add newly-identified risks as appropriate.
Review meetings
Risk status should be a standard item at all progress meetings. Reporting the status of risks is
part of the normal reporting function, not an extra task. Evidence from project management
benchmarking suggests that how aware the client is of risk is one of the main factors behind the
success of a project.
The reviews should consider:
v responses to risks which have happened;
v risks which are about to happen;
v newly-identified risks; and
v risks which are no longer a threat.

Documents
You need clear accessible documents so that:
v everyone involved shares the same understanding of risks;
v new team members can find out about project risks;
v the knowledge is kept for future projects; and
v evidence is available that you have taken reasonable care.
As part of the closing the project, you should produce a summary showing:
v the effectiveness of the risk management strategy;
v where it was lacking; and
v what lessons we can learn for projects in the future.
Risk modelling techniques

Many statistical techniques have been developed to model the effect of risks. These techniques
are supported by specialist software, and three which are commonly used are:
v sensitivity analysis;
v probabilistic analysis; and
v decision trees.
Sensitivity analysis
You can use sensitivity analysis to work out the effect, on the whole project, of changing one of
the risk variables (for example, delay in completion date or increase in cost). It is an important
technique that highlights how the effect of a single change in one risk variable can produce a
marked difference in outcome of the project. It also shows how much a risk variable would need
to change before having a significant effect on the project.
You should carry out this analysis on several risks to see which ones have a large effect on the
project.

100
75 Demand for the product
50
25 Estimated component costs

Percentage
change 0
in NPV
-25
-50
Time to complete the project
-75
-100
-40 -20 0 +20 +40

Percentage change in variables
The figure above shows the effect of changes in three variables on the Net Present
Value (NPV) of a project. The risks of increased cost of components have little effect
on the overall NPV (a 20% increase reduces the NPV by only 5%), whereas any risks
which add to the time the project takes to complete would have a major effect the
economics of the project (a 20% increase reduces the NPV by over 30%).

Probabilistic analysis
This analysis gives the probability distribution for each risk and then considers the effect of risks
when they are combined.
Probability Probability
1 1
0.8 Estimated 0.8 Estimated

activity activity
duration duration
0.6 0.6
Risk 2
0.4 0.4
0.2 0.2 Risk 1
0 0
3 6 9 12 15 3 6 9 12 15
Time (months) Time (months)
The figure above shows the effect on the time an activity will take, which itself may be
uncertain, of two identified risks. It can be seen that the effect of Risk 1 is far less than
that of Risk 2.
The most common form of probabilistic analysis uses sampling techniques, based on Monte Carlo
simulation.
This method relies on randomly working out values based on a set probability distribution, which
is usually described by using three estimates: minimum, mean (or most likely) and maximum.
The overall outcome for the project is worked out by combining values chosen for each of the

risks.
100%
85% Upper limit (20.1)

completing within cost
80%
Probability of
60%
70%
54% Expected cost (17.2)
Confidence
41% Unadjusted cost (16.5) interval
40%
20%
15% Lower limit (13.9)
0
8 12 16 20 24 28
£ Million
The figure above shows an example of a cumulative probability distribution of

completing within cost, worked out using probabilistic cost analysis. It shows that there
is a 70% probability of the total project cost falling between £13.9 and £20 .1 million,
with the expected cost, taking into account all risks, being £17.2 million. The difference
between the unadjusted cost of £16.5 million and the expected cost is the amount
needed to cover identified risks. The expected cost is the amount you should get
authorised.

Decision trees
You can use decision trees to show the possible outcomes of a series of risks. You need to give
each separate outcome a probability value showing how likely it is to happen.
Activity 1 Activity 2 Activity 3 Sum of Component

Cost Cost Cost costs £k Prob cost £k
Prob Prob Prob
£k £k £k
10 85% 140 44.6% 62.48
30 75% Unadjusted cost
12 15% 142 7.9% 11.18
100 70%
10 85% 135 14.9% 20.08
25 25% Lowest cost
12 15% 137 2.6% 3.6
10 85% 205 19.1% 39.21

30 75%
12 15% 207 3.4% 6.99
Highest cost
165 30%
10 85% 200 6.4% 12.75
25 25%
12 15% 202 1.1% 2.27
Expected cost £158.57k
(sum of component costs)
The figure above shows an example of using a decision tree to work out the effect of
risks on the cost of a work package which is made up of three activities.
In the case of activity 1, it is expected that the cost will be £100 000. However, if an
identified risk happened, it would increase the cost to £165 000. There is a 30%
chance of this happening.
In the case of activity 2, the cost is expected to be £30 000 but there is a 25% chance
that the work can be done cheaper, at £25 000.
In the case of activity 3, it is expected that the cost will be £10 000, but there is a 15%
chance of it costing £12 000.
The lowest outcome is £135 000, with a probability of 14.9%, (based on the most
favourable outcome of each activity). The worst case is £207 000, with a probability of
3.4%, (based on the least favourable outcomes). The probability of any single outcome
is the product of each of the probabilities which give rise to the outcome. By using the
weighted probabilities of each of the eight possible outcomes, and summing the
resulting components, the expected cost of £158 570 is calculated. The unadjusted
cost of £140 000 is the result of taking no account of any of the risks, including those
which have a favourable result. The example is simplified to the extent that it assumes
no secondary effects on other activities of a risk happening. In reality this will often be
the case but the method can easily cope with it.


Tools and techniques - Communications management
Communications management
Good communications are essential to successfully implementing projects. A common
understanding of what the project is about and how different stakeholders are affected will
increase commitment and reduce any opposition to the project.
Communication is about giving people the information they need so they can do their jobs
properly, make decisions, and gain a common understanding. Information must be timely, two
way, open, honest and fair. It must also be seen in this way by the people receiving it. Both the
sent message and the received message must be the same and must be understood.
You need to establish:
v who the audience is;
v what the message is;
v when the message is to be delivered;
v how the message is to be delivered; and
v how effective the communications are.
Why communicate?
There are a number of reasons for communicating, for example:
v to gain commitment through understanding;
v to let people know about things that may affect them so that they have enough information
to do their jobs properly;
v to publicise success;
v to warn of possible pitfalls or problems;
v to provide an authoritative source of information; and
v to explain how the project links to other things that are happening in the company.

Tools & techniques - Communications management
The audience
There are many audiences to consider, often with different needs. Everyone with an interest in
the project, whether direct or indirect, will want to know what is happening.
Audience prompt list

Customers
Employees
Shareholders
Suppliers and sub-contractors
Regulator
Pressure groups
General public
Project team
Client and users
Engineering
Product line
Sales and marketing
Personnel
Research
Procurement
Finance
Policy and functional specialists
& See Tools and techniques - Managing stakeholders (page 161)
The message
Having identified the audience, you will need to consider what kind of information people need
to receive, for example:
v how they, and the way that they work, will be affected by the project;
v how the project will benefit their work and help provide quality service to customers; and
v how the project links to other projects.
Each of your different audiences will need different information. The following are two examples
which you should consider.

Tools and techniques - Communications management
Example: senior managers

v How the project fits with company strategy?
v What benefits the project will bring to their part of the organisation?
v What are the costs, resources and timescales involved?
v What organisational issues are there?
v What policy decisions need to be made?
v What commitment do you need from the senior management team?
v What is their action plan?
v How important are the communications?
Example: operational teams
v What is the project about?
v What changes will the project bring to their work?
v What areas of work will stay the same?
v What are the benefits to the business area concerned and to the whole company?
v What support that will be provided?
v What is the role of the team in putting the project in place?
When you decide what messages to communicate, include in your plan the success criteria and
how you might measure it.
The timing of messages

How you time communications is governed by the following considerations.
v Is there something important to say?
v Is action needed from those you communicate with?
v Is the project about to affect the people I communicate with?
v Is a significant milestone due?
Remember that communication involves lead times which, in the case of established channels (for
example, business newspapers, magazines and tv), are beyond your control.
The media or channels

Having defined your communication aims, what you want to communicate, when and to whom,
you should choose the most appropriate way of doing this. There are a large number of
established channels both at a company-wide and local level and communications specialists will
be able to help with this. On some projects communications will be a significant work package
which may be handled by a contractor or work package manager. However, as project manager,
you have ultimate responsibility for communications for the project.

Tools & techniques - Communications management
Effectiveness of communications
You must evaluate your communications so you can understand the effects of what you are
saying. There are many ways of getting feedback, for example, interviews, questionnaires,
surveys. You should check whether your communications are effective in three general areas.
v What has been learned?
v What was liked or disliked?
v What is still needed?
Summary
Understand your audience, their needs and their interests.
Decide what you need to communicate.
Plan the timing of your communications and remember that you often need to repeat messages.
Choose the most appropriate way of delivering your communications.
Check how effective your communications are and change your plan if necessary.
The importance of good communications cannot be over emphasised. There are experts in the
company and you should get their help.

Tools and techniques - Mobilisation and maintaining momentum
Mobilisation and maintaining momentum

There are times during all but the smallest of projects when the number of people involved
increases rapidly. When you bring significant numbers of people together for a new project, or to
join an existing one, you must make sure they quickly form an effective project team.
The information in this section is mainly aimed at the project manager, but it also applies to
contractors or work package managers who have responsibility for large work packages.
As the project progresses, you will often need to make sure that you maintain the momentum of
the whole team so that they continue to work together towards the project goals.
Maintain momentum
Number
of
people
working
Mobilisation
on
the Maintain momentum
project
Mobilisation
Maintain momentum
Mobilisation
Maintain momentum
Time
t
y
n
n
en
ilit
io
itio
tio
pt
pm
ib
lla
fin
ce
as
sta
lo
De
In
Fe
ve
In
De
Figure above shows, for a typical large project, how the size of the project team
increases during the lifecycle
Mobilisation
Joining a project team is a little like the first group exercise on a training course. A room full of
strangers, you don't know what their individual skills are, how easy they will be to get on with,
and often the objectives are not entirely clear. What you want is for someone to take control,
explain the task, identify the various skills of the members and agree appropriate roles and
responsibilities.

Tools & techniques - Mobilisation and maintaining momentum
As the project manager, you must take on this leadership role and quickly get the team up and
running in the right direction. This is a crucial stage in a project and you must get the team
enthusiastic if the project is to be successful.
You are not yet under pressure because of cost overruns or schedule delays and, by-and-large,
you have a clean sheet of paper. You can still influence events.
This is your opportunity to get the team together and make sure that everyone knows:
v the aims and requirements of the project;
v any restrictions which apply;
v how they fit into the team;
v what you are hoping they will deliver; and
v how you are going to manage the project.
Team members have the chance to tell you about issues, risks, resources and options relating to
their part of the project. The team can then start working together developing the plans and
documents for the current project phase.
The seeds of delay, cost overruns and quality shortfalls are sown in the early stages of a project
phase. By agreeing roles and responsibilities early on, it will help save time and generate
enthusiasm. The project and team members gain from this process. The benefits are that you
increase commitment and understanding and the team takes ownership of the plans and
documents developed.
Project workshops
From your meetings with the client, the work you have already carried out on the project and any
plans developed during the previous phase, you will understand the objectives, requirements and
the limits placed on you. You will know which users and specialists to consult. This will help
you understand their attitudes to the project and to identify the people you need to join the
project team.
As soon as the people you need are placed on the project, you can arrange a series of meetings
and workshops with them. The number, timing and length will depend on the scope, size and
complexity of the project.
Experience shows that the best way to get a project team moving is to hold workshops where the
team members can get to know each other and start to work on the project.

We show a suggested workshop format below.

The client and project manager
should communicate the project Introductions
objectives, requirements and
constraints and make sure that Business objectives
the whole team understands Project requirements
what is required and why. Constraints
Client / PM presentations
Assumptions
Time/Cost/Quality
The project manager and the priorities
team should work together
developing the top level work Identify high level WBS
breakdown structure and the
Lower level detail
network logic, identifying the
developed by WP teams
risks and issues which need to
be examined. They should also Identify high level
agree the roles and network logic
responsibilities of the team Lower level detail
members. developed by WP teams
Preliminary risk
The team should agree the
identification
detailed processes which will be
used for managing the project.
Agree roles &

The outputs of these workshops
should be recorded in the project responsibilities
file and communicated to the Change control
main stakeholders. Issue Management
Agree PM Risk Management
arrangements Reporting arrangements
Communications
When you are given project team members rather than choosing them yourself, it is important to
quickly understand their strengths and weaknesses and how to use their mix of skills effectively.
You should not underestimate the amount of effort you need to combine these people into an
effective project team.
Successful project management stems from good leadership and teamwork. Sharing a common
objective, getting things done and completing tasks are the results of good leadership and strong
commitment.
Maintaining momentum
Even when everyone involved is working towards a common goal, things can still go wrong but
you should make sure that the project team continues towards the goal. This is a process that
continues throughout the project.
Setting up formal procedures at the beginning and making sure that everyone understands them
will get the project off to a good start. However, you must make sure that you use procedures
and deal with action points and issues promptly. You also need to communicate changes to the
plan so everyone understands them. The project reporting and communication processes will
help team members keep in touch with events but you will often find out more by regularly
visiting the work areas.
There will be formal control requirements at the end of each phase in the project lifecycle to
make sure that you are reviewing the project against business aims and the original business case.
Project meetings
As the project evolves, you will set up various formal and informal groups.
Project control board

A well-functioning project control board, chaired by the client and including senior
representatives of contractors or work package managers and users, is one of your most
powerful allies.
The role of the project control board is to:
v sort out issues and conflicts which are beyond the control of the project team;
v make sure that the project has the resources it needs; and
v make sure that the project continues to deliver the required benefits.
Project control board members should have the authority to make decisions for their work areas.
And when they cannot sort out issues or prioritisation problems they should be clear about how
they can get the matter sorted out by someone higher in their own organisation.
Although you do not need to have a project control board for every project, you should have
them for projects which span functional or organisation boundaries. Project control boards may
also deal with a number of related projects. This may be particularly effective where, for
example, you share resources with other projects and you need to make decisions about
priorities.
The frequency of project control board meetings will depend upon the size and complexity of the
project and the lifecycle phase.
Client's progress meetings

You need to hold regular meetings with the client to make sure that the project continues to
focus on the business objectives and to alert the client to any possible problems.
From the client's point of view these meetings give them the chance to direct and find reassurance
that the project is being managed properly and that you are taking appropriate action to sort out
any problems. If the client is highly involved, it is a good sign of how important the project is
and how successful it might be.

Project team progress meetings

These meetings give you the chance to review risks and progress and to identify the root causes
of problems. The team will want to see what options are available and who will be responsible
for implementing them.
Meetings with contractors or work package managers

You should arrange meetings to add to the regular reports. You can combine meetings with the
contractors or work package managers with inspection visits if appropriate. You may need the
meetings to discuss performance and opportunities for improvement.
Because contractor or work package manager meetings may deal with contractual obligations,
you must carry them out in a formal way. You or your deputy must chair them. Take full
minutes at the meeting - do not rely only on the minutes from contractors or work package
managers.
It is important that you consult company procurement specialists about all dealings with external
contractors or work package managers or suppliers. You need to involve them in any meetings
where contractual commitment or variation to an existing contract is a possibility.


Tools and techniques - Managing stakeholders
Managing stakeholders
There are many stakeholders who will be interested in the outcome of the project. These will
include people closely associated with the project, for example, client, users, contractors or work
package managers and of course you, the project manager, and your line manager.
There may be others who, although not obvious stakeholders, are also affected by the project.
You need to be aware of the effect of any proposed change on them so you can prevent any
conflict of interests that may arise at a later stage. You should also take account of the views of
various policy and functional specialists who might influence the project.
Stakeholder prompt list

Customers
Employees
Shareholders
Suppliers and sub-contractors
Regulator
Pressure groups
General public
Project manager's manager
Project manager and core team
Client and users
Engineering
Product line
Sales and marketing
Personnel
Research
Procurement
Finance
Understanding the stakeholder interests

If you understand and achieve the technical aspects well, you may still `fail' if you do not give
enough attention to wider stakeholder issues. It is important to develop an early understanding
of the interests of the main stakeholders involved in the project and to tell the rest of the team. It
is up to you to include these interests and make sure that the stakeholders are satisfied if the
project is to be a success.

The main stakeholders and their interests are shown below.
Client
The client is mainly interested in making sure that the needs of the business are met and that the
project reflects the needs of users, the shareholders and any regulatory organisations.
Users
The users are interested in the quality of deliverables, the timeliness of delivery, the amount of
change involved and how practical implementing the deliverables will be.
Internal contractors or work package managers

These people are driven by the priorities of their own part of the organisation. They have to
prioritise conflicting demands on their resources from competing projects.
External contractors or work package managers

These people are interested in making a profit and staying in business. They hope that they may
be involved in future business with the company. If the project fails, it may lead to a loss of
reputation by them and exclusion from future work.

There are people who define and advise on for example, company policy, strategy security,
industrial relations and regulatory requirements. Their interests lie in maintaining and improving
company standards and making sure that those standards are kept.
Trade unions
Trade unions are interested in the effect any changes will have on their members. You should
make sure that where appropriate, you carry out adequate consultation. You should give the
unions reasonable detail of the scope of the project and the implementation plan. It is particularly
important that you consult the trade unions at an early stage when the proposed changes affect
working practices or locations.
Statutory bodies
There are regulations covering the industry, fair trading, and competition rules which the project
must meet. You must get specialist support in this area.
Stakeholder strategy
Identifying all the relevant stakeholders shows the boundaries of the project. It also allows you
to identify other project objectives that may be necessary if the project is to be successful.

You should assess stakeholder interests at the start of a project and again when you take any
major decisions or identify any extra stakeholders.
Getting the team to complete the table below will give a good understanding of the stakeholders
and you should be able to assess their likely current attitude and where they must move to for the
project to be successful. Know the ‘heroes and villains’ of the project.
Stakeholder attitude
Neutral - allow it to happen
Actively make it happen

Changes
Stakeholder Likely
Passively negative
needed to
Stakeholder benefits or resistance to
Actively against
achieve
Help it happen
disadvantages the changes
benefits
Using this information, you can develop strategies for managing the relationships with the various
stakeholders with the aim of making the most of opportunities and reducing threats.


Tools and techniques - Value management
Value management
Value management examines project deliverables from a functional perspective and aims to get
the most value. It provides a structured approach to examining and developing a project which
will increase the likelihood of achieving the requirements at best value for money. There are two
basic principles to follow.
1 Examine the client’s objectives and understand the functions that are needed to meet the
requirements before you try to identify solutions.
2 Involve all stakeholders and use creative techniques when you look for new, practical
solutions.
Value management focuses on improvements and monetary savings to make sure you achieve
value for money. You can do this by identifying the contribution each element makes to the
overall functional worth of a product and then making sure that you get best value for smallest
cost. The aim should be to spend the money where the client gets most value.
Value management is becoming increasingly important as international standards and guidelines
emerge. It focuses on two main areas.
Identifying the most effective set of requirements

You can assess solutions to problems by referring to the value requirements of the client. You
must fully define all the client's needs and some of them may not be clear at the beginning. You
need to evaluate changes in terms of their possible benefits. It is important to cost each of the
client's needs and wants to show how much each adds to the cost. The client can then see what
value each part has compared with the cost.
Identifying the best way of delivering requirements

You can reduce lifecycle costs by getting rid of, or substituting high-cost items, or repetitive
spending such as maintenance.
UK Treasury guidelines show that using a structured value management method typically saves
10% to 25% of a project's capital cost. However, value management does not only apply to
reducing costs. You can also use it to identify areas where increased spending is justified, for
example, to improve reliability.
You can get maximum benefit in the early stages of a project before your design proposals are
complete and contracts finalised. This would be during the feasibility phase, when ideas are
being created and you are considering alternatives. However, you should continue to focus on
improving value throughout the project .
Value management process

The process is workshop based and is best done by a team of people with an interest in the
subject, supported by someone who is independent and can help everyone through the process.

It is important to make sure you have the right mix of skills and personalities. Everyone involved
must have a good understanding of the requirements and have the authority to make decisions
for their stakeholder group.
The ideal workshop size is five to seven people, although you may need larger teams at the start
of a project if many stakeholders need to be involved.
A typical process would cover the following.
Collect information on the project
Identify the various functions
Generate alternatives
Rank alternatives
Calculate costs and benefits
Produce report
Review with Client
Implement

Collect information on the project

Before the first workshop collect information about the project so that you can work out the
objectives and deliverables. Information you need includes:
v drawings and specifications;
v current or estimated costs of parts, materials and labour;
v production quantities and rates;
v details of suppliers;
v current manufacturing methods;
v user requirements;
v market trends; and
v details of competing products.
It is important to understand the client's thoughts and visions and to get the views of users. It is
worth carrying out stakeholder assessment to highlight the objectives of those people who will be
involved in the workshop.
You can then use the information to produce the workshop agenda and associated information
pack.
Identify the various functions

You use the information relating to the project to identify the issues and functions of the whole
or parts of the project, as seen by the client, specifically:
v the basic requirements that the project must deliver to serve the client’s needs;
v the improvements that it would be nice to have over and above the basic requirements (for
example, make it easier to use, improve appearance, extend life);
v those factors that will set limits on the project, for example, regulations and codes of
practice;
v the total amount that may be spent on the project in both initial capital and lifetime costs;
v the expected period over which the client will be responsible for the deliverables of the
project, including design and construction; and
v the client's quality and performance requirements.
You will use this information to carry out the functional analysis.
Generating alternatives
In this phase the team puts forward suggestions and alternative solutions which you will need to
look at further. You should use brainstorming and other creativity tools.
Ranking alternatives
You can develop and investigate the alternatives the team comes up with for their technical
feasibility and economic viability. You will develop outline designs and estimate costs. Only
limited development can take place during the workshop and you should carry out further
development after the workshop but before you carry out an implementation review workshop.
Developing an action plan from the workshop is essential and it should show details of further
development and implementation.

Working out the costs and benefits

You should define the functions that a product performs and assess how this is accomplished and
at what price. You can best express a function as a verb and a noun, for example, ‘wash
windscreen’. You will work out the cost of each component and its percentage contribution to
the total system you are studying. Typically 80% of the cost is accounted for by 20% of the
components. This 20% is what you will focus on as it offers the greatest potential for improving
value.
The aim is to discover what it costs to accomplish each function and to show where you are
spending money. You can then assess each function for its contribution to the overall product
function. You will look carefully at components that appear to cost a large amount to carry out a
relatively trivial function. You will then identify opportunities for savings. However, it is often
the case that you are spending too little on significant functions and, if you spent more the overall
product would be significantly improved. For example, it is possible that you are not spending
enough on finish, appearance and ease of use and an improved image with easier handling would
improve sales. It may be worth spending more on better-quality key components to improve
reliability and reduce warranty claims.
Producing the report

You must produce a report confirming everyone’s role in implementing the workshop proposals.
You should show the details of any further work that is needed and include drawings,
calculations and costs, where appropriate. The report will help the client to monitor proposals as
they progress.
To finalise the report, the main people involved in the workshop, client and senior managers
should sign-off their agreement to the workshop findings, their role in the action plan and their
responsibility for making sure the implementation is successful.
Benefits of getting this sign off include:
v greater chance of putting the changes in place;
v greater team focus;
v greater project focus;
v fewer disagreements further into the project; and
v everyone takes responsibility.
Implementing
You need to develop a plan for implementing the proposals. The plan must define the
responsibilities of the workshop team members, include a realistic timetable for putting the
proposals in place and a review process to check whether the implementation is successful. You
need to identify an implementation manager to do this.
An action plan should be part of the final workshop report. This action plan is the way of
checking the development of ideas and their implementation after the workshop.

Critical success factors

Successful workshops depend on:
v the client and other decision takers being present;
v an appropriate mix of skills in the team;
v senior management taking part and providing support;
v experienced independent facilitators;
v commitment to the outcome;
v use of functional analysis;
v structured approach;
v undisturbed workshop environment; and
v agreed implementation plan from the workshop.
Other benefits
The process speeds up the way the team gets and increases mutual understanding. It is also a
good way for breaking existing perceptions, forcing people to take a fresh approach to problem
solving and helping in setting out tasks and objectives focusing on value for money. It forces
people to look at value, value for money and benefits and not just to focus on cost.
At the end of a value management study the client will not only have the benefits of value
improvement and monetary savings, but will also have gained an increased awareness of the risks
involved in the project. Responsibilities will have been allocated. Finally, the client will feel
more comfortable about where the project is currently, and where it is heading.

A simple value management example

A bus company has carried out a survey and there seems to be a significant number of
people in a particular village in the UK who would use buses if they stopped at
convenient places. The bus company has a standard package that it provides for bus
stops which includes a shelter and a lay-by. This was going to be provided but the
client decided that a value management exercise should be carried out.
The most expensive part of the project is building the lay-by but this doesn't provide
value to the customers or the bus company. It does prevent traffic hold ups but is not a
legal requirement. It may upset some car drivers but these are unlikely to be
customers of the bus company. So, the lay-bys will not be built.
The shelter is the next most expensive part of the project and does benefit customers
but there isn't any competition and as long as the buses keep to schedule, passengers
should not have to wait too long. So, the shelters will not be provided.
This just leaves a simple bus stop sign but the bus company decided that for a
three-month trial period they wouldn't provide any signs and would just stop outside a
number of local landmarks that suited the customer needs they had identified in the
initial survey. So, the bus stops will not be provided.
The bus company would still need to carry out marketing activities to let people know
about the new service but they would need to carry this out whatever option they
chose.
Summary
Many projects suffer from poor definition because not enough time and thought is given at the
earliest stages. Using these techniques allows us to evaluate requirements against the way of
achieving them as the project develops. This ensures that money and effort is spent where it is
most needed and you are delivering best value for money.
Any object that is being designed, developed or produced can be analysed, but it is best carried
out as early as practical in the project. The feasibility phase is an appropriate time to carry out
value assessment which can then review throughout the definition phase.
The best time to start value management is when design options are still open but there is enough
cost information to support decision making. It is essential that reviews you carry out and any
revisions are implemented before you commit to detailed engineering and spending money. Any
further changes will usually increase cost and time on the project.

Tools and techniques - Managing requirements
Managing requirements
One of the greatest disappointments in projects is when products do not meet the expectations of
either the client or the users. This can be due to either:
v the original requirements not being understood well enough and clearly defined at the
beginning; or
v not managing the changes to requirements during the project.
A requirements specification should contain a complete description of what the products will do
without describing how they will do it. It should be clear, verifiable, traceable, consistent with
other requirements and easy to understand. Requirements should first be specified in the client's
requirements definition and then developed through the project requirements definition and
technical and operational specifications.
Managing requirements needs good project processes right from the start in areas such as value
management, risk management and change control.
Benefits
The benefits include:
v all the stakeholders understanding the requirements;
v clearer requirement documents;
v easier ways of assessing of the effect of a change;
v an audit trail between the original requirements and the products; and
v better management of what the client and users expect.
The process
You need the following steps to manage requirements. You may need to carry out this process
several times.
Understand the requirements

Activities include gathering and analysing information, checking and prioritising requirements,
specifying requirements to the appropriate level of detail for the next phase.
Extra requirements, areas for prioritisation or areas for focus may emerge from analysing the
risks.
Value management will make sure that the functions the client needs are clearly identified.
You should include a summary of the requirements in the clients requirements definition. The
requirements will be shown in more detail in the project requirements definition and technical and
operational specifications.

Identify solutions
You should describe possible solutions and work out costs to an appropriate level of detail. You
need costs even though they may be ballpark estimates in the early stages. The client must allow
for changes to cost as more detail becomes available and it may be appropriate to budget
separately for feasibility, detailed investigation, design, and other specific activities.
Each time you do this, you should assess the options for risk. This may result in changes to
scope and redefining or rejecting of one or more options.
Success depends on making sure that you recognise and agree with the client, contractors or
work package managers and users, a joint responsibility for managing requirements. It also
depends on everyone understanding and agreeing that specifying requirements and solutions to
meet them is part of the same process, and that the specification is driven by business need.
Choose solutions
All members of the project team need to agree on and understand the possible solutions.
Choosing a solution will be based on the relative priorities for each requirement. This will help
you decide what to include in the solution and final product.
As the project progresses you will understand the requirements in more detail and the uncertainty
will reduce. This continues until the specification has enough detail to be acceptable for
definition, development, or procurement. You will need to carry out some aspects of the value
management process again to reflect any changes or extra requirements. The process is only
complete when you have successfully implemented the agreed solution the client and users have
accepted it.
There is a danger that projects choose the first or the only solution identified. It is likely that
choices will be limited by those who want to serve their own interests. You may need to make
compromises in terms of the requirements to use particular skill sets and previous solutions. If
you choose a solution before you properly understand the requirements, it is likely that it will be
wrong.
Reviewing the requirements

You should review the requirements throughout the project and use the value management
process where changes are needed.
& See Tools and techniques - Change control (page 125)
You must plan how you will put the solution in place to an appropriate level of detail. You must
involve contractors or work package managers, and users.

Check list for requirements

Requirements should meet the following criteria.
Uniquely identifiable
To get rid of any ambiguities, to spot duplicate requirements, and to improve how requirements
can be traced. Each requirement must have an agreed interpretation.
Testable
To make sure that the delivery can be agreed as acceptable or not you need to test the
requirements to confirm that the delivered product meets the requirements.
Traceable
To make sure that you can trace the requirements from the original through to what is finally
delivered.
Prioritised
You need to classify each requirement according to an agreed set of importance criteria.
Understandable
Each requirement, and its corresponding documents must be written so that it can be understood
by both technical and non-technical people.


Tools and techniques - Procurement and contract management
Procurement and contract management

For any project where significant external costs are involved you must make sure that
procurement and contracts are well managed. A commitment to buying materials, goods or
services with long lead times may have been made before a project manager is appointed and
these commitments may have already set the course of the project.
Procurement and contract management are specialist areas, supported by professionals who must
be involved in all cases. The purpose of this section is to give you an overview of the subject so
that you can make best use of the support available to you.
Procurement
As well as buying the hardware, software, stores, materials, services and so on that you need to
complete the project, procurement is also responsible for:
v organising the transport for materials;
v storing materials;
v stock control;
v getting rid of unwanted stock;
v hiring specialists or other services; and
v renting equipment and plant.
Some of these items will need lengthy tendering processes and special contracts.
There may be advantages, in terms of delivery, cost and performance by developing preferred
suppliers for major purchases, particularly for projects involving significant quantities of
particular items. You need to rank and choose suppliers according to their previous record of
quality, performance and value for money. You need a good working relationship with the
preferred supplier and the project team at all levels, so that the supplier becomes part of the
project organisation and fully understands its requirements. For the supplier this could be an
opportunity for a long-term business relationship. For the project team there is the benefit of
improved quality and reliability of supply.
You often need to visit or remind suppliers make sure they meet delivery dates. You need a
monitoring and control system that highlights actual or possible delays and the effects of late
delivery so that you can take action in good time.
You need to agree an inspection process with the supplier and make sure that documents are
kept. You should weigh the cost of inspections against the possible costs of replacing faulty
items that have been used. You, as the project manager, will need to know if a supplier fails to
meet performance and acceptance criteria, particularly if concessions or changes to specification
are needed. You may also need to agree this with the client.
Transporting items, particularly to or from overseas destinations, needs careful planning and
control. It could include clearing customs, getting transport permits, chartering vessels or
aircraft and getting the documents needed to meet export and import regulations. You may need
route surveys when you need to transport heavy or large loads. Even if you pass the
responsibility for transportation to the supplier, you need to be satisfied with the arrangements.

Contract management
Contract management is an area where you must have up-to-date specialist knowledge. You
should always make sure that a specialist is present when you discus contacts. There are seven
elements to a contract which must be in place before a contract is legally enforceable.
v Agreement - an offer and an acceptance.
v Consideration - a value.
v Intent - supplier having a reason to believe that there is intent to form a binding contract.
v Possibility - that it is possible to deliver the requirements.
v Capacity - protection for children, mentally infirm and so on.
v Genuineness of consent - contract not placed under pressure.
v Legality - purpose of the contract must be legal.
You will usually prepare a statement of purchase requirements to provide guidance to the
procurement specialists on what needs to be delivered, by when and the relative importance.
A contract is a mutually-binding agreement which means the supplier must provide a specified
product and means the purchaser must pay for it. A contract is a legal relationship where
disputes can be sorted out by a court. There are procedures defining who can sign these
agreements on behalf of the company. You need to make sure that the product or service
provided by the contract is exactly what the project needs.
There are three broad categories of contract.
Fixed price
v The fixed price or lump sum contract is an agreed fixed total price for a well-defined
product. If the product is not clearly defined, the person buying it is unlikely to get the
product they want and the supplier is likely to run up extra costs trying to provide it. Fixed
price contracts often include incentives for meeting or doing better than project objectives.
Cost reimbursable
v Cost reimbursable or cost plus contracts involve paying the supplier for the actual costs
spent plus an agreed amount of profit. Costs include direct spend which is only for the
benefit of the project and indirect costs or overheads, which are a percentage of the suppliers
general business costs to be charged to the project. Indirect costs are usually worked out as
a percentage of direct costs.

Unit price
v The unit price contract is where you pay the seller an agreed amount for each unit of service
or product and the total value of the contract is a function of the quantities needed to
complete the work.
Contract administration is a process of making sure that the supplier's performance meets
contractual requirements. On large projects an important area to focus on is managing the
relationships between the various suppliers. The nature of the contractual relationship means the
project team must be aware of the legal implications of any action taken.
You need to define payment terms within the contract and should be clearly linked to progress
made. You need to monitor suppliers' progress as part of the normal project control process.
This will include information on which products have been completed, to what extent
performance specifications are being met and what has been spent. Invoicing requirements,
including the supporting documents you need are usually defined in the contract.
Requests for change may lead to modifications to the terms of the contract or the product
description or service provided. Contested or non-agreed changes, (those where the supplier and
the project team cannot agree on the cost of the change) are likely to become claims, disputes or
appeals.
Contract terms and conditions usually say how certain aspects, such as warnings of unsatisfactory
performance and contract changes or clarifications will be communicated.
Closing a contact involves making sure that all the work was completed to the project team’s
satisfaction and as agreed. It also includes making sure that records are updated and information
is stored for future reference. The contract may include specific procedures for closing the
contract. Ending the contract early is usually a special type of contract closure and you will need
extra help from the procurement specialists and maybe the legal department. The person
responsible for contract administration should give the supplier formal written notice that the
contract has been completed. The requirements for formally accepting and closing a contract are
usually defined in the contract.


Tools and techniques - Configuration management
Configuration management
Configuration management is the process of controlling changes to, and the versions of,
components. You can control the physical and functional characteristics of a product or service
using documents, records and data. Managing configuration involves making sure that changes
and variations are put in place only after being authorised. You should carry out appropriate
configuration management throughout the project. It does not apply to all projects and you must
decide, with the agreement of the team, if it is appropriate.
Configuration management is particularly important in projects where you may be producing
several different prototypes. It controls and keeps track of the design, or configuration, of each
prototype. You will use a product based work breakdown structure to express the product as a
configuration of components. Each component is treated as a configuration in its own right,
made up of other components.
The process of managing configuration includes the following steps.
Choosing and identifying items and keeping records

Break down the system into its different parts so that you can document each one separately and
place it under change control. You will often use a product based work breakdown structure
which, at its lowest level, has the configuration items that form the project inventory (or bill of
materials). The design specification should include a complete list of configuration items.
Control
At regular intervals you should bring together all changes that have been agreed using the change
control process and change the baseline (or starting point). You can then make all further
changes against the new baseline. Once a change has been approved, the person responsible for
the item makes the change, and passes the relevant documents to configuration management.
You must then make sure that everyone with an interest gets the new specification.
Status accounting
Configuration status accounting gives information about baselines, configuration items, their
versions and specification, change proposals, problem reports, repairs and modifications. This
allows people on large rapidly changing projects to avoid using outdated versions of documents
and components. This is important for components that need to work with those from another
manufacturer. The people responsible for user acceptance tests must have the most up-to-date
version of the requirements specification so that they can test whether they have met the
performance requirements of the contract.

Tools and techniques - Configuration management
Audit and review

You will manage configuration items moving through the project using formal review processes
carried out at the end of each phase.
For example, at the end of definition, you will produce and review a technical and operational
specifications which, when approved, will be handed over to configuration management.
Similarly when a design is accepted, the design specification is handed over to configuration
management.

Tools and techniques - Managing benefits
Managing benefits
All projects support the achievement of one or more business objectives. You must clearly
specify the benefits of doing the project at the beginning. It is the client’s responsibility to make
sure that benefits are achieved and they will be held responsible if the expected return is not
achieved. The client must specify the benefits properly and make sure that there are plans to
achieve them. The business case should show how you will measure the benefits and track them
and who will be responsible for achieving them.
You can justify some types of project before all of the benefits have been specified for example,
a single benefit clearly pays for the project and provides a good enough return on the investment.
However, the aim should be to get the best possible benefit and this means you need to focus on
managing benefits throughout the project and into operations. By focusing on benefits
throughout the project you have a much better chance of achieving more than the original
business case expectations.
You, as the project manager, must make sure that you agree a firm benefits delivery plan with the
client and users.
Specifying benefits
It is essential that you involve users at the start of the project because they will deliver the
benefits. You need users to make sure that the benefits claimed are reasonable and to make sure
of their commitment to deliver. You also need to involve other stakeholders to make sure that
you explore all possibilities for getting the benefits. The overall project plan must include all of
the activities needed to deliver the benefits. For example, if achieving the benefits from a
deliverable depends on changing operational processes, the project plan must include activities
relating to developing and delivering training, and designing new processes.

The benefits from information technology and process improvement projects usually come from
improved accuracy or quality, efficiency and speed. You can look at each of these factors for the
products or processes you are developing. This approach has been found useful in starting to
identify the benefits
Inputs Process Outputs
Less manual effort in Increased productivity Less effort to produce

data entry. on performing and results.
Efficiency reporting studies
Fewer transcription Reduced risk of failure Improved quality output.

errors.
Accuracy and Improved consistency of Less rework
quality Better sample tracking work across teams
Faster data collection Improved throughput Meeting deadlines more

often
Quicker access to
Speed information Next stage
developments start
sooner
Using a matrix to categorise the expected benefits can be a useful step towards
developing the measures that you will need to monitor achievement.
Other types of project should use similar approaches. For example, developing a new product
may mean considering developing a matrix of benefit areas in terms of speed to market, market
share, improved sales, greater customer satisfaction and lower maintenance costs. If you are not
sure of the benefits, consider a pilot or prototype to help decide what benefits are achievable.
Generally projects do not achieve any benefits until after they are completed. The benefits come
from using project deliverables in operations.
Creating benefits measures

There is a tendency to measure the ‘easy’ input features. For example, ‘We have now trained
90% of staff in the new order-handling method’. However, this is not a measure of benefit.
Measuring what is produced is always more difficult. For example, ‘How many of the staff are
using the new method and what is the reduction in average handling time for an order?’ The
best measures are output measures since that is more directly linked to the benefits.
You can describe benefits in one of three ways.
v Benefits from something new.
v Benefits from doing something better.
v Benefits from something being stopped.
You can continue this analysis by deciding how clear you can be about the benefit at this point in
time.

As a minimum you must be able to see a benefit. Hopefully when it happens you will be able to
measure it. If we can give benefits values now, then it is ‘quantifiable’, and if you can turn the
values into money, you can class it as ‘financial’.
Start by agreeing with the users and other stakeholders what can be seen and then through
rigorous discussions move each benefit higher with the aim of agreeing a financial value. This
will result in a business case that is strong and your plans for delivering the benefits will be more
realistic.
New Better Stop
Financial
Quantifiable
Measurable
Observable
The row which you enter the benefit into is not a classification of the benefit but is an
assessment of how clear you can be about it now. Treat it as though you were having
to make the business case presentation immediately after filling in the chart. For
example, if the benefit is a financial saving, but today you can't say what that is in
money terms it needs to go into the ‘measurable’ row. However, if you can work out
financial figures confidently and you can name the person who will do that piece of
work, you can put it into the ‘quantifiable’ row. When they have finished and you know
the financial values, you can move it up to the ‘financial’ row.
If nothing is higher than ‘observable’ after this type of analysis, it is doubtful whether you have
done enough work to define the benefits for the business case. Charts which have the two top
rows empty are describing ‘act-of-faith’ projects. Either the business case is unsound, or you
need to do more thinking.
The benefit of this analysis comes from discussions that take place between the client, project
manager, users and the project team. The benefits will be clearer, people will be identified to be
responsible for them, and extra benefits may emerge. At the end of the analysis everyone should
understand what the benefits are and how you are going to achieve them. This can then write
these in the benefits delivery plan.
Monitor achievement
The client needs to pay particular attention to this because you and the team may have been
moved on at the end of the project. The benefits delivery plan will show how and when the

benefits are to be delivered and by whom. The client should regularly review progress against
this plan. The reviews should aim to:
v confirm which of the expected benefits you have achieved;
v confirm which of the expected benefits have not been achieved, to find out why, and to
decide if any action is possible or if you have to let the benefits go;
v identify if you have achieved any unexpected benefits, or if any unexpected disadvantages
have arisen; and
v identify any further benefits which you can now achieve and take action to achieve them.
Summary
Managing benefits is an important part of project strategy development and you should start it as
early as possible in the project.
All stakeholders should be involved early so that everyone understands the benefits and any
disadvantages are uncovered.
You will get the best possible benefit if you focus on managing benefits throughout the project.
It is particularly important to involve users early because they will deliver the benefits.
If benefits are uncertain, consider a pilot or prototype to decide what benefits you can achieve
and how to get them.
Make sure that you include all changes that affect the project in the benefits delivery plan.
The client must hold regular reviews of the benefits delivery plan and those reviews will continue
after the project ends.

Tools and techniques - Environmental management
Environmental management
Managing the environment is an increasingly important area with more and more stringent
regulations coming into force. Projects will not be authorised unless you can show that they
meet to or go beyond environmental standards and regulations.
You need to take account of environmental considerations throughout the project. For example,
in the design stage, energy efficiency and recycling may be important. When you are
implementing the project, using natural resources, waste disposal, pollution and the effect on the
local community may be important.
We are committed to preventing pollution and reducing the effect of our operations on the
environment. In particular we have stated that we will:
v meet and, where appropriate, go beyond all relevant laws and other requirements - if there
are no regulations, we will set our own rigorous standards;
v try to reduce the number of materials we use in all operations, reuse materials rather than
dispose of them whenever possible, and promote recycling and the using recycled materials;
v design energy efficiency into all new services, buildings and products and manage energy
wisely in all operations;
v reduce, wherever possible, the level of harmful gases and chemicals we produce;
v market products that are safe to use, and efficiently use resources which can be reused,
recycled or disposed of safely;
v work with suppliers to reduce the effect of their operations on the environment through a
quality purchasing policy;
v place our buildings, structures and operational plant so that we reduce visual, noise and other
effects on the local environment;
v support, through our community programme, the promotion of environmental protection by
relevant groups and organisations; and
v include environmental issues in discussions with company unions, company training
programmes and encourage all employees to use good environmental practices.
Environmental risk is having an increasing effect on how we manage projects and this is changing
all the time as our understanding of environmental effects develops and as communities and
governments become aware of their importance. While we have to carefully manage
environmental risk during the entire project, we often come across major problems at the
beginning of projects. Communicating and dealing with pressure groups is a high priority.
It is your responsibility to reduce harmful effects on the environment resulting from day-to-day
project work. If appropriate, projects should include environmental risk management and site
audits which cover how the regulations will be met, management systems, materials, releases of
gases and chemicals, managing waste, risks (including storing fuel and chemicals and
contaminated land) and effects on the local environment. Everyone should be aware of their duty
of care requirements for waste disposal.

Tools and techniques - Environmental management
You need to include financial data about environmental performance to show your commitment
to the environment.
Projects that are likely to have an effect on the environment must take account of the possible
interest and involvement from stakeholders and use the project risk management process.
& See Tools and techniques - Managing stakeholders (page 161)
& See Tools and techniques - Risk management (page 131)

Tools and techniques - Managing health and safety
Managing health and safety

Any project may involve risk to health and safety. So that you understand these risks every
project should include an assessment of these risks before work starts. You need to update this
as necessary, throughout the life of the project. You should schedule these assessment updates
and reviews in the project plan.
Under Health and Safety at Work legislation, all employers have a duty of care for their
employees and the general public. You, your employer and any designers, can be held personally
responsible if your or their negligence causes injury to anyone involved in the project. This
includes the project team while working on the project, users while operating the deliverables and
customers using the products of the project.
Your specific responsibilities are to:
v make sure that your people are properly trained and equipped to do their job;
v get and pass on appropriate safety information to your people;
v make sure that your people follow safe working practices;
v make sure that your people have and use appropriate personal protective equipment;
v make sure that your people’s tools and equipment are in good condition by carrying out
regular checks;
v identify possible dangers in the workplace and make sure you take appropriate corrective
action;
v carry out risk assessments when necessary;
v carry out any necessary safety management system checks;
v educate your people in safety awareness, especially through regular safety sessions at team
meetings;
v make sure that all accidents are reported promptly and investigated thoroughly; and
v make sure that visitors and contractors know about the company’s safety requirements.
Do not treat safety matters in a superficial way. In extreme cases, you can be prosecuted if your
actions or negligence put someone in danger or worse, cause them injury or death.

Tools and techniques - Managing health and safety

Tools and techniques - Project quality management
Project quality management

These processes should meet local, national and international standards and guidelines. Project
quality management looks at managing the project and the product of the project.
Deciding, agreeing and delivering the necessary levels of quality and grade are the project
manager’s responsibility. The project team needs to identify which quality standards are relevant
to the project and decide how to meet them. You need to review this regularly when you are
defining the requirements and planning the project.
Below we have included the definitions of quality and grade from International Standards
Organisation (ISO).
Quality
“Quality is defined as the totality of features and characteristics of a product or service that bear
on its ability to satisfy stated or implied needs.
Note 1 - In a contractual environment, needs are specified, whereas in other
environments, implied needs should be identified and defined.
Note 2 - In many instances, needs can change with time; this implies periodic revision
of specifications.
Note 3 - Needs are usually translated into features and characteristics with specified
criteria. Needs may include aspects of usability, safety, availability, reliability,
maintainability, economics and environment.
Note 4 - The term quality is not used to express a degree of excellence in a
comparative sense nor is it used in a quantitative sense for technical evaluations. In
these cases a qualifying objective shall be used. For example, use can be made of the
following terms:
a) relative quality where products or services are ranked on a relative basis in the
degree of excellence or comparative sense.
b) quality level and quality measure where precise technical evaluations are carried out
in a quantitative sense.
Note 5 - Product or service quality is influenced by many stages of interactive activities,
such as design, production or service operation and maintenance.
Note 6 - The economic achievement of satisfactory quality involves all stages of the
quality loop (quality spiral) as a whole. The contributions to quality of the various
stages within the quality loop (quality spiral) are sometimes identified separately for
emphasis. Two examples : quality attributable to design, quality attributable to
implementation.
Note 7 - In some reference sources, quality is referred to as fitness for use or fitness
for purpose or customer satisfaction or conformance to the requirements. Since these
represent only certain facets of quality, fuller explanations are usually required that
eventually lead to the concept defined above.”

Tools and techniques - Project quality management
Grade
“Grade is defined as an indicator of category or rank related to features or characteristics that
cover different sets of needs for products or services intended for the same functional use.
Note 1 - Grade reflects a planned difference in requirements or, if not planned, a
recognised difference. The emphasis is on the functional use / cost relationship.
Note 2 - A high grade article can be of inadequate quality as far as satisfying needs
and vice versa, e.g. a luxurious hotel with poor service or a small guest house with
excellent service.
Note 3 - Where grade is denoted numerically, it is common for the highest grade to be
1 and the lower grades to be 2, 3, 4, etc. Where grade is denoted by a points score,
for example by a number of stars, the lowest grade usually has the fewest points or
stars.”
Quality assurance
Quality assurance covers all the planned activities used within the quality system to provide
confidence that the project will meet the relevant quality standards. Outcomes are likely to be
quality improvements. This includes action to increase the effectiveness and efficiency of the
project to provide added benefits.
If you use the methodology in this handbook sensibly, it will mean your project management
process is of high quality.
Quality control
Quality control mainly involves monitoring the project deliverables to make sure that they meet
the relevant quality standards. However, you should also use it in terms of project performance.
The monitoring and control process outlined in this handbook is a quality control system which
focuses on time and cost. You should use it throughout the project and identify ways of getting
rid of causes of unsatisfactory results.
Statistical process control

The techniques of statistical process control, while normally used to track repetitive activities
such as those in manufacturing, can also be relevant to projects. You can develop control charts
to monitor any type of output variable, such as cost and schedule variances, how often the scope
changes, as well as the results of acceptance tests.
You will not always reject deliverables which fall outside the acceptable bounds set for quality
control. It may be better to specify rework to bring them up to the right specification. However,
reworking is a frequent cause of project overruns and the project team should make every
reasonable effort to get things right first time.

Tools and techniques - Project health-check software
Project health-check software

The work of the Project Management Benchmarking network, of which we are a founder
member, has lead to a general agreement about what is best practice in project management. We
have used this to develop a set of software tools which allow project teams to compare how their
project management practices compare with this external standard.
The tools range from a simple spreadsheet giving a quick assessment of all parts of project
management, through to more detailed spreadsheets focusing on specific techniques. It also
includes a highly-structured database tool which is designed for you to use throughout the
project.
The spreadsheets are designed to help you and the team identify the areas of project management
where you should focus improvement activity. They work by presenting a series of pointers to
best practice and difficulties which prevent best practice. Each of these is scored on a range of
‘completely true’ to ‘completely untrue’. Experience shows that it is best to start by using the
general tool to identify the weakest areas and to follow this by using the specific tools to identify
what improvements you can make.
You can download the spreadsheets from the project management intranet site.
The database tool helps you understand how the project is doing by comparing it with ‘best
practice’ throughout the project. You can benefit by using the software to produce reports on
progress, to keep a log of events and from seeing examples of best practice.
There are a number of key events in the project and you can find a definition of each in the
Project lifecycle section
1 Project started
2 Project outline determined
3 Initial costs and benefits estimates produced
4 Authority and finance provided
5 Project registered
6 Project team identified
7 Feasibility study carried out
8 Preferred option selected
9 Project requirements definition completed
10 Business case prepared
11 Procurement plan agreed
12 Authority and financial resources agreed
13 Completing detailed designs
14 Placing contracts
15 Project deliverables generated
16 Ongoing support arrangements agreed
17 Project deliverables inspected and tested
18 Client and users accept deliverables
19 Client agrees to close the project
20 Carry out post-implementation review

21 Recording lessons learned

22 Completing the project
& See Project lifecycle
Best practice is defined as a series of footprints - one at each key event throughout the project.
Each footprint defines the expected standard against six dimensions: planning, control, risk,
communications, requirements and human factors. You can see the current project status by
answering a simple questionnaire. The software will then produce, for you, a series of reports
which show how the status of your project compares with the expected standard. At the end of
the project there are questions about the outturn. This is when the actual costs and timescales
are compared with the planned.
You can use the data gathered from projects to identify which practices are most closely linked
with project success so that you can provide an updated version of best practice. We share data
with the Project Management Benchmarking network so that we can keep on top of
improvements and innovation in project management.
Planning
Project management
Benchmark
ns
0%
10
t io
Co
ic a
%
80
n tr
un
ol
mm
%
60
Co
%
40
%
20
org
H F a t io
k
an
R is
is
& n
Requirements
The footprint shows the expected level of performance against best practice when a
project is completing the feasibility study (event 7). Planning, communications and
human factors and organisation need more attention than control. By the time the
contracts are placed (event 14) all aspects should be at 100%.

After a project health check is carried out, you can plot the actual performance of your
project so that you can compare it with best practice.


Documents
Documents
A key part of everyone’s job is to make sure that you keep proper documents on the project.
You should at least keep the minimum needed to plan and manage the project effectively. Before
you produce any documents you should consider the following.
v Who is it for?
v What is its purpose?
v Will it be used?
Which documents you keep will depend on the project lifecycle phase and how complicated the
project is.
How project documents develop

As a project progresses your understanding of the requirements increases and the contents of the
documents should reflect this. For example, during the early stages the level of accuracy of
estimates of costs and timescales and the degree to which the deliverables can be specified is
likely to be very low. This is because there may be many ways in which you can meet the
objectives and each will produce different costs and benefits. When you have chosen an option,
the deliverables can be more clearly specified and the accuracy of estimates will improve.
The detailed work you do in the definition phase will reveal considerable extra information and
you should add this extra detail to the documents. Estimates of costs, benefits and timescales
should then be accurate enough for a formal business case and project plans. The project
requirements definition and technical and operational specification documents will be based on
the knowledge during the definition phase.
You will learn more about risks to the project and you should prepare plans to manage them.
Plans should always show the next phase activity in greater detail than is available for the rest of
the project. Reviews of progress against plan should show actual costs and achievements so far
as well as forecasts to complete the project.
At the end of the project, you should have accurate details of costs and timescales, and estimates
of the long-term benefits of the project. The project closure report should record lessons learnt
so that you can pass them on to improve the performance of future projects.
Document control
You need a degree of control for all documents because problems will arise if you use
out-of-date or different versions. The degree of control will depend on the type of document and
how you update and distribute it.

Documents
As a minimum all documents should contain the following.

v Privacy marking if appropriate.
v Project title.
v Document title.
v Author’s name.
v Issue date.
You will also need to consider the following if you needs configuration control or frequent
updating for example, the project plans, forecasts and the technical and operational
specifications.
v Authorisation details.
v Version control.
v Version history.
v Author details and enquiry point.
v Distribution list.
Controlled distribution is essential when many different contractors are producing components
for the project. You will sometimes need to get positive confirmation that documents you have
sent have been received and those they replace have been destroyed.
& See Tools and techniques - Configuration management
There will be times when some of the information created by a project is extremely sensitive. For
example, a project to bid for a contract not only collects confidential information about costs but
could alert our competitors to our strategy and any planned offer price. There may be customer
information involved or you may even need to give the project a code name to disguise it. You
should take appropriate steps to secure sensitive or confidential project information. This may
involve providing secure areas for the project team and controlling access to some or all of the
project information.
An Intranet site for the project which can, as a minimum, store documents is a good way of
making sure that you only use current versions of documents. However, you should take care to
make sure that you bring people’s attention to important changes.
Conclusion
You could ignore all this section with the intention of saving time and effort by just assuming that
everyone involved knows exactly what you're trying to do and why you're doing it, and
understands their role in a project without having it written down. You could assume that they
will still have this level of understanding in a few months' time when the initial enthusiasm has
worn off.
You could assume that everyone who came to your presentation heard, remembered and fully
took in everything you said. You could assume that you're doing what the client wanted, and
that you have the authority you need to spend the money.

Documents
In fact you could assume all sorts of things, but experience has shown that it's usually better to
write it down. However, you should not underestimate the amount of time and effort you need
to prepare and maintain project documents.
The following pages describe the most important project documents.
v Project file.
v Client requirements definition.
v Feasibility report.
v Project requirements definition.
v Business case.
v Technical and operational specifications.
v Work package agreements.
v Project closure report.
v Final review.

Documents

Documents - Project file
Project file
The project file is the master library of the project. It is the most important source of information
about the project and should contain enough information for a new Project manager to be able to
take over the project. It should clarify:
v objectives;
v approval and authority limits;
v benefits to stakeholders; and
v roles, responsibilities and contributions.
Typically the file would contain:
v a signed copy of the client requirements definition;
v a signed copy of the project requirements definition;
v approval and authorisation documents for example, a business case;
v risk management documents;
v project plans;
v closure reports; and
v project specific documents covering the following.
- Organisation
- Roles and responsibilities
- Change control
- Monitoring
- Managing issues
- The format and frequency of progress reports
- Standards for any documents produced
- Security policy
- Document review process
- Quality audits
- Procurement strategy
- Evidence of acceptance of deliverables
- Glossary of terms

Documents - Project file

Documents - Client requirements definition
Client requirements definition

The client requirements definition is the document which sets out what the client needs. It is the
result of developing an idea to the point where a programme or project begins to emerge. It
rarely represents a flash of inspiration on the part of the client.
The document is written by someone with detailed knowledge of the subject - not always the
client. The client requirements should be concise, clear, and unambiguous. It must focus on
project aims and benefits, top-level design features and the functionality needed. The
requirements should be challenging but stop short of a totally unrealistic wish list.
The client requirements definition is not a problem statement. If it appears to be so, then it is
likely that you have not carried out the necessary investigations. The client requirements
definition should state what is needed and must provide direction and scope for the next phase,
usually feasibility.
Contents
The list of headings that follow are suggestions to help make sure you cover the necessary
information.
v Objectives
v Description
v Business fit
v Scope
v Outline project deliverables specification
v Dependent and driver projects
v Constraints
v Assumptions
v Client authorisation
Objectives
You need to specify the objectives in terms of the benefits that will arise. There is no guarantee
that producing the project deliverables will automatically result in achieving the benefits.
The objectives and benefits should be stated in specific, measurable terms. You must support
statements like ‘improve customer satisfaction' by saying what measures will be used to
determine customer satisfaction and what targets you want to achieve.
The statement should distinguish between benefits to:
v customers;
v shareholders;
v employees; and
v other stakeholders.

Description
The description should be a summary of how the project will achieve its objectives. It should be
at a high level because you will need to explore the specific solution during a feasibility study. It
is a statement of major deliverables with a summary of how they will work.
Business fit
Most business units have vision and mission statements, and specific business objectives which
form a balanced scorecard. This section should describe how the project supports those
statements and objectives. It should cover the relationship with other projects which have similar
objectives.
Scope
The scope defines the breadth and boundaries of the project and may cover:
v geographical, for example, limited to the UK;
v physical, for example, buildings of more than 1000 metre2 ;
v organisational, for example, finance staff only;
v process, for example, telephone enquiries on sales, billing and repairs; and
v service, for example, Internet and multimedia.
Include any links with other projects and services that the project may affect and any known
future developments. In cases of possible ambiguity, the scope must also state what a project
does not include.
Outline deliverables specification

This is a set of goals for the top-level features the client needs. It should describe what is
wanted, not how you will achieve it.
The goals must be realistic and could include guidelines on:
v physical;
v maintenance;
v operational;
v capacity;
v cost; and
v quality.
You must specify the important measures and the minimum acceptance criteria but not to the nth
degree. Aim for something which is clear, unambiguous and measurable and you will not waste
time chasing unacceptable alternatives. You will refine this outline specification and expand on it
throughout the next project phases. It will eventually become the deliverables specification
within a project requirements definition.

Dependent and driver projects

Dependent projects are ones that rely on what you produce from this project for their
implementation. Driver projects are ones that this project is relying on for its own
implementation.
You should identify these projects and assess areas of risk.
Constraints
Consider the limits on the project team or specification. Examples include:
v maximum budget;
v regulations and standards;
v maintaining existing services without disruption; and
v using proprietary hardware from specific suppliers.
Assumptions
Consider assumptions that have been made in specifying the objectives and outline deliverables.
Examples include:
v economic factors (inflation, currency movements);
v market forecasts;
v technological developments; and
v regulatory requirements.
Client authorisation
When the client agrees with the document, they should sign a copy for the project file.


Documents - Feasibility report
Feasibility report
The project team will produce a feasibility report during a feasibility study. It describes the best
options available to meet the client’s requirements with recommendations on the way forward. It
should include details of the study and analysis of the technical and operational aspects for each
alternative.
A feasibility report should include:
v options which you have investigated;
v options which could deliver the client requirements;
v estimated timescales and costs for each feasible option;
v risks, assumptions, dependencies and the effect on the business of each feasible option;
v reasons why options were rejected; and
v a recommendation.
You should support the recommendation by explaining how closely it matches the requirements.
Make sure that you cover the following areas.
Feasibility Report checklist

Competitive advantage
Management of risks
Assumptions
Resource requirements and availability
Compatibility with strategic aims and policies.
Compatibility with dependent and driver projects
Ease of installation.
The environment
Statutory and regulatory
Engineering standards
Security and audit
Priorities if implementation is to be phased
Operational acceptance
Quality and reliability
Life expectancy of the asset
Flexibility and ease of upgrading

Documents - Feasibility report
You will also need much of the information you need for the feasibility report for the following
documents you produce during the feasibility phase:
v a provisional project requirements definition;
v an outline business case based on the option agreed by the client;
v a detailed plan showing the resources, time and cost estimates needed to complete the
project definition and the business case; and
v an outline plan for the whole project.

Documents - Project requirements definition

A project requirements definition is the definitive description of the project. It outlines the tasks
and timing of project outputs. It contains information for senior managers to make decisions
affecting the project and provides a practical reference for project contractors and supporting
functions.
The project requirements definition is an important document for making sure that everyone
concerned understands a project before development begins. A signed project requirements
definition may be a condition of funding further work. However, it should not treat it as an
administrative necessity. Rather it shows that the project team has done enough work in defining
the project to be confident of proposals in the business case and project plans.
Developing the project requirements definition

The client requirements definition is the source document used for developing the project
requirements definition throughout the feasibility and definition phases.
During the feasibility phase, you will examine the client’s requirements in detail and evaluate all
available options until you can recommend the preferred option to the client. You then develop
the project requirements definition from the preferred option.
The project requirements definition will develop as you learn more about the project. It is
complete when there is a project plan with enough detail to clarify the cost, content and timing of
deliverables. When the document is agreed it should be signed by the client.
The completed project requirements definition sets a baseline for the project and you should
manage any changes by using the change control process. The client requirements definition is
replaced but you should keep it as a historical document in the project file.
Purpose of the project requirements definition

The project requirements definition provides:
v an agreed statement of the project's aims and deliverables;
v a contract between the client and the project manager stating what is to be supplied, to
whom, when, and for what benefit (it is a commitment from the project manager to deliver
the project and a commitment from the client to provide the funding and resources needed);
v a baseline document for controlling a project within agreed scope (any changes must
managed using the change control process);
v support for a project business case, showing that there is a firm basis and plan for delivering
the benefits to time, cost and quality; and
v a reference against which you can review and audit a project.

Contents
The project requirements definition does not need to be a long document, but it should be
thorough. You should include any information that helps understanding. You should also refer
to other documents such as detailed specifications. The list of headings that follow are
suggestions to help make sure that you get the information you need.
v Description and objectives (developed from client requirements definition).
v Scope (developed from client requirements definition).
v Deliverables (developed from client requirements definition).
v Deliverables specification (developed from client requirements definition).
v Major milestone plans.
v Acceptance criteria and tests.
v Benefits delivery plan.
v Risks and contingency plans.
v Dependent and driver projects (developed from client requirements definition).
v Constraints (developed from client requirements definition).
v Assumptions (developed from client requirements definition).
v Change control.
v Organisation and key responsibilities.
v Contract strategy and management.
v Identification and coding.
v Reference documents.
v Agreement and authorisation.
Description and objectives

A statement of what the project is and what it will do. It should cover:
v what it replaces (if appropriate);
v the major deliverables and how they will work;
v why the change or project is necessary;
v the benefits to the customers, shareholders, and other stakeholders;
v marketing information on products or services; and
v the effect on the organisation, people and culture.
You need to state the project objectives in specific and measurable terms. You need to support
objectives such as `improve customer satisfaction' by the criteria used to measure customer
satisfaction, and the target levels you want to achieve. You should include statements of how the
project supports business objectives and how it links with any projects that are directed at similar
objectives

Scope
The scope defines the breadth and the boundaries of a project. It is developed from the client
requirements definition and it may include the following:
v geographical, for example, limited to UK;
v physical, for example, buildings of more than 1000 metre2 ;
v organisational, for example, finance staff only;
v process, for example, telephone enquiries on sales, billing and repairs; and
v service, for example, Internet and multimedia.
Include any links with other projects and services that the project may affect and any known
future developments. In cases of possible ambiguity, the scope must also show what a project
does not include.
Deliverables
A deliverable is an item or service that is to be produced to an agreed specification, on an agreed
date, at an agreed cost and to an agreed quality standard.
The project requirements definition should include a list of deliverables and statements to help
understanding.
v Who is responsible?
v When will it be ready?
v Where is it to be provided?
v What are the agreed quality standards?
v How much will it cost.
For example, the deliverables of the project might be computer software, delivering and
assembling hardware and on-site staff training.
Deliverables specification
This is a summary of the main features, performance and function of the deliverables. The
information will act as a strong pointer for design and should include enough information to
clearly understand it without going into fine detail.
The project requirements definition should contain a description of how you will produce the
deliverables and the standards each work package must achieve.
You should refer to internal and external standards. These may include:
v technical;
v quality;
v documents;
v training;
v accommodation;
v modes of operation; and
v ISO standards.

If the project is changing a process, you should provide flow charts. The deliverables
specification should highlight improvements and advantages.
You need to refer to any compatibility and configuration control requirements for example,
hardware and software compatibility and data structures.
Major milestone plan

A major milestone is a significant activity or some important event in a project. You need to
include the major milestones showing when they are due to be reached, how they are linked and
the critical path.
The number and type of milestones will depend on the content, timescales and size of a project.
It is better to include milestones which involve completing an activity because they are easier to
check, for example:
v client signs the project requirements definition;
v the specification is agreed with the supplier;
v orders are placed;
v the system is ready for customers; and
v the building is ready for use.
Acceptance criteria and tests

The tests by which you can assess the success of the project should relate directly to the
objectives and the deliverables specifications.
You need to define a clear set of acceptance tests for you to use at the end of each phase so that
the client can judge whether the project is meeting its objectives.
Some basic rules are:
v methods of testing must be unambiguous;
v criteria must be measurable; and
v you must set failure and acceptance limits.
Benefits delivery plan

All benefits that are claimed by the project need supporting plans to make sure that you achieve
them. It is not enough to claim that ‘fewer support people are needed’ without supporting the
claim with a statement on how the reduction will be managed, by whom and when.
There must be a clear statement on who is responsible for measuring, monitoring and delivering
project benefits. You will need to clearly specify the benefits and plans for achieving them in the
business case.

Risks and contingency plans

Every project has a number of factors which can affect your ability to deliver on time, control
costs and maintain the agreed level of quality. A risk is any factor which may prevent you
achieving your aims. You need to evaluate risks at the beginning of a project and review them
throughout.
For each of the risks there should be a statement showing the consequences, the likelihood of it
happening and a reference to the risk management plan.
Dependent and driver projects

Dependent projects are ones that rely on what you produce from this project for their
implementation. Driver projects are ones that this project is relying on for its own
implementation.
You should identify these projects and assess areas of risk.
Constraints
These are restrictions placed on you, the team or the specification. For example:
v the maximum budget;
v regulations and standards;
v maintaining existing services without disruption; and
v using proprietary hardware from specific suppliers.
Assumptions
You must clearly state assumptions that are fundamental to the success of the project and are
outside your control. Examples of these include:
Consider assumptions that have been made in specifying the objectives and outline deliverables.
Examples include:
v economic factors (inflation, currency movements);
v market forecasts;
v technological developments; and
v regulatory requirements.
Avoid listing ‘everyday’ problems that you have to manage for example, project team illness,
resource shortages and so on. Make plans to review the assumptions as the project progresses.

Change control
The project requirements definition should say how you will manage future proposals to change
the project. This section should include:
v who is responsible;
v the change approval limits for the project manager and client; and
v a reference to where you can find the detailed procedures.
Organisation and key responsibilities

The project requirements definition should have an organisation chart of the project management
structure together with brief descriptions of each person’s responsibilities. You need to include
important contractors or work package managers.
Contract strategy and management

It is important that you develop a contract strategy to make sure you are consistent in the way
you deal with suppliers and maintain control of budgets. This applies to all suppliers. Examples
of areas to cover include:
v the criteria for placing initial orders;
v whether you will have a single supplier or many suppliers;
v delivery and payment schedules;
v contract management to maintain delivery to time, cost and quality; and
v contractor's involvement in specifying the project objectives.
You must use the company experts in this area.
Identification and coding

You need to identify the project clearly by name and position within an overall programme (if
appropriate). Include any user-defined codes on the project and refer to the codes used for the
project's work breakdown structure.
Reference documents
You should list all reference documents, stating where they came from, the version and where
they can be found.
Agreement and authorisation

When the document is agreed it should be signed by the client and the main contractors or work
package managers involved in the project. You should keep a signed copy in the project file.

Documents - Business case
Business case
You will produce this at the end of project definition or whenever you need authority for
resources or to spend money.
A business case looks at commercial, financial, technical, operational and strategic issues such as
those listed below.
Business Case checklist

What are the objectives and how do they fit with business
strategy and plans?
How does it fit with other projects?
What is the benefit to customers?
What will be the effect on market share and competitors?
What benefits can be expected, when will they be
achieved?
Who will ensure that the benefits will be achieved and how
will they be measured?
What is the effect of the proposal on people?
What other feasible options were considered and why were
those alternatives rejected?
What are the legal and regulatory implications?
How are the intellectual property rights to be protected?
What is the contract strategy and how will we get the best
deal from suppliers?
What are the risks and how will they be managed?
How long will the project take to complete and what are the
significant measurable milestones?
How will implementation of the proposal be managed?
How much will it cost, when will we pay and when will we
get our money back?
How much profit will we make and when will we make it?
What is the authority being sought?
The level of detail should be appropriate to those who are being asked to give authority. In
general this will mean restricting the amount of technical detail and concentrating on the main
commercial issues in the written case. The person presenting the case must still be prepared to
respond, in more detail, when presenting the case.

An accepted format for a business case would be one that includes:

v a facing sheet giving the main information;
v an executive summary;
v a commercial summary; and
v appendices to support the case.
There are often strict rules governing the format of information that can be presented to
authorising organisations or bodies. The secretary of the authorising organisation will have the
details.
An example framework for the commercial summary

Introduction
This should be a background to the proposal with references to other related project authorities,
policy or strategy decisions.
Objectives
You need a brief description of the proposal, a statement of the objectives and an account of how
these fit in with the client’s objectives and priorities.
Markets and customers

This is an account of any factors which affect supply and demand, growth, pricing, competition,
market share or distribution associated with the proposal. Identify the effects on other product’s
revenues, costs and volumes if customers stop using those products in favour of the ones to be
produced by the project.
Benefits
This gives details of the benefits which stem from the proposal, together with a statement of how
you will measure and achieve them. You should be able to clearly see the effect in the financial
evaluation.
Strengths and weaknesses

This is a statement of what is needed to succeed in the market, how the proposal measures up,
and its advantages and disadvantages against the competition.
People
This is an evaluation of industrial relations considerations and how you will manage them.
Technology
This identifies the main requirements, intellectual property, and rate of change.

Alternatives
This is a statement of what other alternatives you considered, with costing for feasible options
and, briefly, why you rejected them.
Legal and regulatory considerations

This is a statement of the effects any laws and regulations might have on the project.
Procurement
This is a statement of policy and contract strategy, with details of any large contracts you will
place.
Performance
This identifies the main performance objectives for example, improving productivity, reducing the
number of failures, improving product performance. You should also include details of and how
you will measure them.
Milestones
This gives completion dates for significant activities or main events throughout the project. This
shows how you will track and report progress.
Risks
This is an assessment of the main risks (technical, commercial and others), what action you will
take to prevent them, what fallback plans you have made, and what the worst outcome is likely
to be. It also includes an explanation of any contingency that is included with the amount needed
for the project.
Assumptions
This a statement of the assumptions you have made in producing the estimates of timescales,
costs and benefits.
Financial analysis
This is an explanation of the main financial assumptions behind the financial evaluation, sensitivity
analysis, effect on our performance, profit and loss account.
Request for authority

This is a clear statement of what authority or decision is being asked of the authorising
organisation or body.


Documents - Technical and operational specifications

You will produce this for the main deliverables at various points throughout the project. You
develop these specifications in line with the increasing understanding of project needs. They
provide detailed specifications for each deliverable and must satisfy the requirements of all
functions involved in the project for the whole life of the project deliverable.
You should follow existing technical standards, practices, strategies and formats (for example,
standards for software specification). If there are no existing standards, you need to cover the
following.
Specifications checklist
Functional specification, critical success factors and
measures
Performance specification, critical success factors and
measures
Compatibility and configuration control requirements
Operational requirements
Reliability, inspection, maintenance and repair
Spares procurement during and post implementation
Design
Manufacture
Construction
Installation
Integration
Commissioning and testing
Transportation, packaging, labelling, storing and handling
Health and safety
Environment
Quality assurance and control
Statutory and regulatory
Documentation and training
Intellectual property rights
Process documentation
Glossary of terms
The documents may have different names in different parts of the company but whatever you call
them, they define the technical aspects and user operational needs of project deliverables.

Documents - Technical and operational specifications

Documents - Work package agreements
Work package agreements

Work package agreements are made between you, as the project manager, and contractors or
work package managers. The documents may have different names in different parts of the
company but whatever they are called, they give details of the cost, timescale, deliverables and
the resources that will be needed to carry out the work. They give details of your requirements
and the commitments agreed by the contractors or work package managers.
WP Agreement checklist
Description
Unique identifier (WBS code)
Scope of the work
Inputs (dependencies).
Outputs (deliverables)
Risks and contingency plans.
Reference to mandatory procedures and
instructions
Resource plan (how many, with which skills,
and when)
Acceptance criteria.
Timescales
Milestone plan
Cost plan (including details of budget holders)
Reporting arrangements for progress and costs
The agreements stay in force until you are satisfied that the work is complete. Any changes must
be managed using the change control process.

Documents - Work package agreements

Documents - Project closure report
Project closure report

You should produce a project closure report within three months of the project being
implemented. You should produce this report in a workshop where everyone with an interest is
involved. It is written for the client, the appropriate finance manager and for the benefit of future
project managers.
The report should be a short document covering the following areas.
Project background
This is a brief description of the project, the main objectives and the authorisation details.
Financial outturn
This compares the amounts authorised with the actual outturn and confirms that you have
correctly registered any fixed assets developed by the project.
Benefits
This is a statement of benefits achieved so far and refers to future benefits and the plans for
achieving them.
User acceptance
This is an assessment of whether the deliverables are acceptable. If you find improvements in
early roll-out, you should reflect these in plans for the rest of the implementation. You should
include details of those responsible for maintenance and ongoing improvements.
Lessons to be learned
This is an analysis of performance which you can use to improve the quality of future investment
decisions and managing and controlling further projects. Possible areas for comment include:
v how clear the project objectives and scope were;
v how effective the project management and team working was;
v how clear communication was during the project;
v how accurate the estimates, assumptions and modelling techniques were;
v how effective the risk management has been;
v whether the financial and other monitoring systems were adequate; and
v what the quality of deliverables was, and how it could have been improved.

Documents - Project closure report
Future opportunities
You may be able to identify opportunities to gain a further return. For example, a new product or
service which is now possible as a direct result of completing this project.
Recommended follow-up action

This includes recommendations for:
v new projects to deliver outstanding deliverables where the scope has been reduced; and
v continuous improvement.
Final review report

This is the proposed date and details of who will produce the report. The client must decide who
will be responsible for this.

Documents - Final review report
Final review report

You normally identify the person responsible for producing the final review report when you
produce the project closure report. This final review report should be sent to the appropriate
finance manager when a significant amount of the benefits have been achieved. This should be no
more than 12 months after you have finished the project. The report covers three main areas.
Functional review
This is a review of how closely the project deliverables met the specifications and acceptance
criteria.
Investment review
The investment review should show how close the financial authority was to the outturn cost and
how close the benefits achieved match those claimed in the business case. The review of benefits
will also cover the level of benefits still to come and how they will be included in targets, plans
and budgets.
Further opportunities
This is a review of opportunities that might flow from the investment now that it has been
working for some time.
Recommend follow-up action

These recommendations include:
v new projects to deliver outstanding deliverables where the scope has been reduced; and
v continuous improvement.
& You can get more information from the project management intranet site.

Documents - Final review report

Registered office:
81 Newgate Street, London, EC1A 7AJ.
Registered England NO: 1800000.

Proj Man

Diunggah oleh

Informasi Dokumen

Deskripsi Asli:

Judul Asli

Hak Cipta

Format Tersedia

Bagikan dokumen Ini

Bagikan atau Tanam Dokumen

Opsi Berbagi

Apakah menurut Anda dokumen ini bermanfaat?

Apakah konten ini tidak pantas?

Hak Cipta:

Format Tersedia

Proj Man

Diunggah oleh

Hak Cipta:

Format Tersedia

Project management handbook

We hold Corporate Membership of the Association for Project

We are founder members of the Project Management

As some of the diagrams in this handbook are quite complex,

Project Management Handbook

Project Management Handbook

Environmental management . . . . . . . . . . . . . . . . . . . . . . . . . - Page 185

Project Management Handbook

Getting value from the handbook

Project Management Handbook - Page 1

Divisional and local procedures

Project Management Handbook- Page 2

Project Management Handbook - Page 3

Project Management Handbook- Page 4

Project management overview

Characteristics of project management

Project Management Handbook - Page 5

In some types of project not all phases will apply.

Project Management Handbook- Page 6

Project roles and responsibilities

Project control board (PCB)

Project Management Handbook - Page 7

Contractors or work package managers

Benefits of project management

Programmes and programme management

Project Management Handbook- Page 8

Project Management Handbook - Page 9

Project Management Handbook- Page 10

Project management process

Project Management Handbook - Page 11

Project Management Handbook- Page 12

Authorisation to proceed from the client

Establish project organisation

Project Management Handbook - Page 13

Project Management Handbook- Page 14

Initiate Plan Develop a project work breakdown

Identify named individuals for project

Specify work packages

Balance time, cost, specification and risk

Getting commitments to do project work

Project Management Handbook - Page 15

Project Management Handbook- Page 16

Initiate Plan Introduction

Control between contractors or work package managers to make

Motivate the team

Project Management Handbook - Page 17

Project Management Handbook- Page 18

changes to activities and work packages clearly and that

Managing project budgets

Instruct work to start, continue or stop

Project Management Handbook - Page 19

Project Management Handbook- Page 20

Formal acceptance and closure

Project Management Handbook - Page 21

Project Management Handbook- Page 22

Procurement and contract management

Project Management Handbook - Page 23

Health and safety management

Project Management Handbook- Page 24

Project quality management

Project Management Handbook - Page 25

Project Management Handbook- Page 26