Beruflich Dokumente
Kultur Dokumente
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.
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
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.
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.
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.
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.
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
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.
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.
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.
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.
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.
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.
Planning
You will carry out the planning processes in any phase
and at any time during the project.
Implementing
You will carry out the implementing processes in any
phase and at any time during the project.
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
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.
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.
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.
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
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.
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.
The client should confirm that there are realistic plans in place to achieve or improve on the
benefits shown in the original business case.
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.
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.
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.
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
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.
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.
Project started
An idea or problem has been identified which may mean a project has to be carried out.
Project registered
You have a unique code within the company systems and are using it to track the project.
Placing contracts
You have placed contracts for the deliverables described in the detailed designs. These contracts
could be for internal and external suppliers.
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.
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
t
p t io
ity
n
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.
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.
Inception phase
Assumptions &
Time & cost
constraints
Client Review
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.
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.
Client confirmed
Feasibility phase
From Inception phase
Client requirementsdefinition
Initial business case
Feasibility phase plan
Recommended
option Investment appraisal
Selected option
Client review
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.
Project manager
The project manager's role is to identify and lead the team in exploring whether the client’s
requirements can be met.
As well as the responsibilities that continue throughout the project, specific responsibilities in this
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.
Feasibility report
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
Client review
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.
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.
As well as the responsibilities that continue throughout the project, specific responsibilities in this
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
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.
As well as the responsibilities that continue throughout the project, specific responsibilities in this
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.
Project launch
Detailed design
Procurement
Development
Integration
Testing
Install deliverables
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’ .
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.
As well as the responsibilities that continue throughout the project, specific responsibilities in
these phases include:
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.
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.
As well as the responsibilities that continue throughout the project, specific responsibilities in
these phases include:
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.
Pilot phase
From Development and Installation
phases
Deliverables ready for use
Changes and
Deliverables used in
improvements
operational environment
to deliverables
Client review
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.
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.
As well as the responsibilities that continue throughout the project, specific responsibilities in this
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.
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.
As well as the responsibilities that continue throughout the project, specific responsibilities in this
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.
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
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.
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.
As well as the responsibilities that continue throughout the project, specific responsibilities in this
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.
As well as the responsibilities that continue throughout the project, specific responsibilities in this
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.
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
Closure report
are arrangements for
Final review
monitoring benefits
Record and
communicate
lessons learned
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.
Project manager
As well as the responsibilities that continue throughout the project, specific responsibilities in this
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.
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.
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
Estimate costs
Analyse network
ü
Optimise resources
OFFICE MOVE
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
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
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.
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.
Standards
You can prepare detailed estimates from standard cost books, for example, standard labour rates.
Erect Fit
partitions electrics
Pack Unpack
Move crates
crates crates
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
A A
B B
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
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
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
Decorate crates crates
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
Decorate crates crates
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
11 3 13 19 2 20
Lay carpet
Fit electrics 21 1 21 22 1 22
1 10 10 14 5 18
19 F 20 Move Unpack
Erect LS F LF
Decorate crates crates
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
Fit electrics 21 1 21 22 1 22
1 10 10 14 5 18
19 F 20 Move Unpack
Erect 11 F 13
Decorate crates crates
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
Fit electrics 21 1 21 22 1 22
1 10 10 14 5 18
19 0 20 Move Unpack
Erect 11 0 13
Decorate crates crates
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.
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.
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)
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
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.
2. Check
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.
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.
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
: You can get more information from the project management intranet site.
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.
Time
Schedule variance
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.
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.
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.
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.
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.
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.
: You can get more information from the project management intranet site.
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.
BRIDGE
17 Prepare
surface
01 Excavate 07 Excavate 10 Prepare 13 Prepare
04 Sink piles
foundations foundations groundwork groundwork 18 Lay tarmac
1 0 60 61 0 90 91 0 190
1 60 60 61 30 90 91 100 190
1 F 60 61 0 90 91 0 190
£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.
You can now plot total figures for BCWS, ACWP and BCWP to give a picture of cost and
schedule progress against the plan.
£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%
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 1
«Period 5
CPI
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
You have received the following information from the contractors and work package managers.
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.
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.
BCWP for each period £77 500 £77 500 £5 500 £7 000 £7 000
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.
Cost and schedule progress up to period 10
£600 000
BCWS so far
£400 000
£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
Schedule variance (SV) so far -£80 500 -£27 000 -£44 500 -£60 500 -£125 500
SV% = SV ÷ BCWS
Schedule variance (SV)% so far -24% -7% -12% -15% -26%
CV = BCWP ÷ ACWP
Cost variance (CV) so far -£27 500 -£20 000 -£94 500 -£117 500 -£145 500
CV% = CV ÷ BCWP
Cost variance (CV) % so far -10% -6% -22% -25% -29%
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.
SPI 1
«Period 10
«Period 5
CPI
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.
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).
Time left calculation
= (Original planned duration - Time spent so far) ÷ SPI
= (320 days - 100 days) ÷ 0.74
= 297 days
Total time for the project calculation
= Time left + Time spent so far
= 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)).
TCPI(BAC) calculation
= (BAC - BCWP so far) ÷ (BAC - ACWP so far)
= (£1 455 000 - £354 500) ÷ (£1 455 000 - £500 000)
= 1.15
TCPI(EAC) calculation
= (BAC - BCWP so far) ÷ (EAC - ACWP so far)
= (£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
You have received the following information from the contractors and work package managers.
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.
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 b/fwd 11 12 13 14 15
Budgeted cost of work scheduled figures from the cost plan
BCWS for each period £71 000 £71 000 £31 000 £31 000 £51 000
Total BCWS £480 000 £551 000 £622 000 £654 000 £685 000 £736 000
Actual costs reported by the Budget Controller
ACWP for each period £75 000 £75 000 £55 000 £48 000 £35 000
Total ACWP £500 000 £575 000 £650 000 £705 000 £753 000 £788 000
BCWP calculations from period 15 summary report
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
BCWP for each period £82 700 £84 800 £74 500 £50 500 £58 000
Total BCWP £354 500 £437 000 £522 000 £597 000 £647 000 £705 000
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
Schedule variance (SV) so far -£113 800 -£100 300 -£57 200 -£38 000 -£31 300
SV% = SV ÷ BCWS
Schedule variance (SV)% so far -21% -16% -9% -6% -4%
CV = BCWP - ACWP
Cost variance (CV) so far -£137 800 -£128 000 -£108 500 -£106 000 -£83 000
CV% = CV ÷ BCWP
Cost variance (CV) % so far -24% -20% -15% -14% -11%
Again a graph of the cost variances and the schedule variances shows the picture a little clearer.
Schedule variance and cost variance progress up to period 15
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.
SPI calculation CPI calculation
= BCWP ÷ BCWS = BCWP ÷ ACWP
= £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.
Cost and schedule performance indicators
up to periods 5, 10 and 15
Ahead of schedule Ahead of schedule
but over budget and under budget
SPI 1 «Period 15
«Period 10
«Period 5
CPI
Forecasting
You can use what you have so far to help forecast the likely outcome of the project. As a first
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).
Time left calculation
= (Original planned duration - Time spent so far) ÷ SPI
= (320 days - 150 days) ÷ 0.96
= 177 days
Total time for the project calculation
= Time left + Time spent so far
= 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)).
TCPI(BAC) calculation
= (BAC - BCWP so far) ÷ (BAC - ACWP so far)
= (£1 455,000 - £705 000) ÷(£1 455 000 - £788 000)
= 1.12
TCPI(EAC) calculation
= (BAC - BCWP so far) ÷ (EAC - ACWP so far)
= (£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.
: You can get more information from the project management intranet site.
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.
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
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.
: You can get more information from the project management intranet site.
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.
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.
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.
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.
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
Prioritise risks
Identify risk owners
Close project
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.
BRIDGE
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.
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.
Time
The longer an activity, the less confidence you can place on how long it will take.
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
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.
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.
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%)
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
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.
Rare Probable
High
catastrophe disaster
IMPACT
Medium
Unlikely Recurring
Low
minor niggle
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.
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.
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.
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
50
-50
Time to complete the project
-75
-100
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 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%
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
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.
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.
: You can get more information from the project management intranet site.
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.
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.
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.
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.
: You can get more information from the project management intranet site.
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.
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.
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.
Project Management Handbook - Page 157
© British Telecommunications plc 2000
Tools & techniques - Mobilisation and maintaining momentum
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.
: You can get more information from the project management intranet site.
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.
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.
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
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.
: You can get more information from the project management intranet site.
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.
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.
Generate alternatives
Rank alternatives
Produce report
Implement
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.
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.
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.
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.
: You can get more information from the project management intranet site.
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.
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.
& See Tools and techniques - Value management (page 165)
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.
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.
: You can get more information from the project management intranet site.
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.
: You can get more information from the project management intranet site.
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.
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.
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
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.
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.
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.
: You can get more information from the project management intranet site.
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.
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)
: You can get more information from the project management intranet site.
: You can get more information from the project management intranet site.
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.”
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.
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.
: You can get more information from the project management intranet site.
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.
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.
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.
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.
: You can get more information from the project management intranet site.
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
: You can get more information from the project management intranet site.
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.
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.
: You can get more information from the project management intranet site.
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.
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.
: You can get more information from the project management intranet site.
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.
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.
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.
Reference documents
You should list all reference documents, stating where they came from, the version and where
they can be found.
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.
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.
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.
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.
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.
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.
: You can get more information from the project management intranet site.
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.
: You can get more information from the project management intranet site.
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.
: You can get more information from the project management intranet site.
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.
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.
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.
& You can get more information from the project management intranet site.