QA APMP Pre-Course Handbook v2.0

APMP Certificate in
Project Management
Student Pre-course
Handbook
APMP Pre-course Student Handbook v0.1
Electronic APMP Pre-course Handbook V2.0
Contents
Introduction .................................................................................................... 3
1
Project Management in Context .............................................................. 4

1.1
Project Management APM Body of Knowledge (BoK) Topic 1.1 ..... 4
1.2
Programme Management - BoK Topic 1.2 ........................................ 7
1.3
Portfolio Management - BoK Topic 1.3 .............................................. 9
1.4
Project Context - BoK Topic 1.4 ...................................................... 10
1.5
Project Sponsorship - BoK Topic 1.5 ............................................... 11
1.6
Project Office - BoK Topic 1.6 ......................................................... 12
Planning the Strategy ............................................................................ 15

2.1
Project Success and Benefits Management - BoK Topic 2.1 ........... 15
2.2
Stakeholder Management - BoK Topic 2.2 ...................................... 18
2.4
Project Management Plan - BoK Topic 2.4 ...................................... 19
2.5
Project Risk Management - BoK Topic 2.5 ...................................... 21
2.6
Project Quality Management - BoK Topic 2.6 .................................. 24
2.7
Health, Safety and Environmental Management - BoK Topic 2.7 .... 27
Executing the Strategy .......................................................................... 31

3.1
Scope Management - BoK Topic 3.1 ............................................... 31
3.2
Scheduling - BoK Topic 3.2 ............................................................. 36
3.3
Resource Management - BoK Topic 3.3.......................................... 42
3.4
Budgeting and Cost Management - BoK Topic 3.4 .......................... 45
3.5
Change Control - BoK Topic 3.5...................................................... 47
3.6
Earned Value Management - BoK Topic 3.6 ................................... 51
3.7
Information Management and Reporting - BoK Topic 3.7 ................ 57
3.8
Issue Management - BoK Topic 3.8 ................................................ 59
Techniques ........................................................................................... 62
4.1
Requirements Management - BoK Topic 4.1 ................................... 62
4.3
Estimating - BoK Topic 4.3 .............................................................. 63
4.7
Configuration Management - BoK Topic 4.7 .................................... 64
Business and Commercial..................................................................... 68

5.1
Business Case - BoK Topic 5.1 ....................................................... 68
5.4
Procurement - BoK Topic 5.4 .......................................................... 73
Organisation and Governance............................................................... 80

6.1
Project Life Cycles - BoK Topic 6.1 ................................................. 80
6.5
Handover and Closeout - BoK Topic 6.5 ......................................... 82

Page 1

6.6
Project Reviews - BoK Topic 6.6 ..................................................... 84
6.7
Organisation Structure - BoK Topic 6.7 ........................................... 86
6.8
Organisational Roles - BoK Topic 6.8.............................................. 90
6.9
Methods and Procedures - BoK Topic 6.9 ....................................... 91
6.10
7
Governance of a Project - BoK Topic 6.10 ................................... 93
People and the Profession .................................................................... 97

7.1
Communication - BoK Topic 7.1 ...................................................... 97
7.2
Teamwork - BoK Topic 7.2 .............................................................. 99
7.3
Leadership - BoK Topic 7.3 ........................................................... 106
7.4
Conflict Management - BoK Topic 7.4 ........................................... 114
7.5
Negotiation - BoK Topic 7.5 .......................................................... 121
Practise Quizzes
Section One Quiz
13
Section Two Quiz
29
Section Three Quiz
60
Section Four Quiz
66
Section Five Quiz
78
Section Six Quiz
95
Section Seven Quiz
122
Section Quiz Answers
126
Page 2
Introduction
The purpose of this workbook is to assist you in preparing for your APMP course. Ask
anyone who has attended an APMP course and they will tell you how intense the course is.
These pre-reads have been produced by QA to assist in your preparation for the course and
thus enhance your learning and understanding and improve your chances of a good result.
They are sufficiently detailed to give you an overview of (and in some areas additional
information over and above) the 37 APMP Syllabus areas and to use in your pre-course
preparation, during the course and as part of your evening revision along with the course
materials (if you are reading this electronically you may wish to print off a hard copy for the
course).
At the end of each of the seven Sections there are a number of multiple choice questions for
you to tackle to test your understanding of those topic areas. You will find an Answer Grid at
the end of the reading material.
Whilst there is no particular recommendation on how long you spend reading, or on the
order in which the material must be read, it is suggested you read the material in the
fortnight prior to your course attendance, and that you allow AT LEAST 2 hours reading for
each Section.
Please note that the APM Body of Knowledge, upon which the course and this prereading are based, is not a structured methodology. Rather it is a collation of
principles and processes that support effective project management. Any number of
techniques and tools could be used to apply these principles and therefore the preread and the course materials should not be seen as the only way to do things! The
pre-read may offer a different viewpoint to that offered by the course trainer, this is
deliberate, the aim of this being to offer you alternative approaches to consider.
Page 3
1 Project Management in Context

1.1
Project Management APM Body of Knowledge (BoK) Topic 1.1
1.1.1 Definition
Unique process, consisting of a set of coordinated and controlled activities with start and
finish dates, undertaken to achieve an objective conforming to specific requirements,
including the constraints of time, cost and resources.
(BS6079)
1.1.2 BoK Definition of Project Management

Project management is the process by which projects are defined, planned, monitored,
controlled and delivered such that the agreed benefits are realised. Projects are unique,
transient endeavours undertaken to achieve a desired outcome. Projects bring about change
and project management is recognised as the most efficient way of managing such change.
1.1.3 Project Management Process

The BoK describes the Project Management Process as shown below in Figure 1.1.1.
This comprises:
An Input
The element that triggers a project this could be a problem, a new business opportunity, a
legislative change or some other driver for change.
An Output
This describes the outputs or deliverables that the project will produce, often known as a
product or products. These products could be new business services or some other form of
organisational change. In any event all projects produce some sort of change within an
organisation.
The input is managed by Project Management to produce the output and is affected by:
Constraints
These are the things within which the project team must operate, e.g. time, cost, quality,
technical and other performance parameters, legal environment etc.
Mechanisms
To assist the delivery of the outputs within the constraints there are a number of
mechanisms that the Project Manager has at her/his disposal to manage the project. These
include the people, techniques and tools, equipment and organisation that comprise the
Project Team and its supporting environment.
Page 4

Figure 1.1.1 - The Overall Project Management Process
Constraints
Constraints
Time,
Time,cost,
cost,quality,
quality,
technical
technicaland
andother
other
performance
performanceparameters,
parameters,
legal,
legal,environment,
environment,etc.
etc.
Input
Input
Business
Businessneed,
need,problem
problem
or
oropportunity
opportunity
Management
Managementof
ofthe
the
Project
Project
Output
Output
Project
Projectdeliverables,
deliverables,
and/or
and/orservices,
services,
change
change
Mechanisms
Mechanisms
People,
People,techniques
techniquesand
and
tools,
equipment,
tools, equipment,
organisation
organisation
Project Management can be described in terms of 4 generic processes that are applied to
the project as a whole and to each phase of the project life cycle (see Topic 6.1):
Starting or initiation
This process ensures that the project or phase has a sound basis upon which to
proceed. For the project, the business case will be established at this time and the
reasons for undertaking the project need to be clearly understood by all. There will be
an initial analysis of stakeholders and risk and then a small team can be formed to take
the project forward
Defining and planning

In this process, for the project, the Project Management Plan (PMP) will be developed
(see Topic 2.4). The project team will prepare the plans for the project or phase,
developing the work undertaken during Starting. Once this is completed the project or
phase will be fully understood and the funds released so the work can be undertaken.
Monitoring and control

This is where the project team will spend most of its time. It covers three main areas
giving out work and receiving advice of its completion, sending and receiving progress
reports (monitoring) and taking appropriate action based on the content (control) and
finally monitoring and controlling change to the project. This tends to be an iterative
process as the project moves from stage to stage or phase to phase.
Learning and closing process

The project comes to a close when the deliverables will be handed over and the project
brought to an end. A key activity to be undertaken at this time is to evaluate how the
project was managed, what went well, what didnt go so well and what could be done
differently in the future. Whilst these are typically end of project activities they should be
undertaken at each major review point to ensure that there is a process of continuous
improvement being undertaken throughout the projects life-cycle.
1.1.4 Supporting Elements

There are a number of elements which support the general Project Management processes.
Briefly these are:
Page 5

Quality Assurance
The process that ensures the Quality Plan developed for the project is being implemented.
Basically, QA is checking the checkers.
Configuration Management
The discipline whereby all the products/deliverables of the project are recorded and kept
under version control. This also includes Change Control.
Risk Management
An essential ingredient for project success is the detailed identification, assessment,
evaluation, mitigation and management of risk.
Procurement
Procurement is an integral part of Project Management and requires particular skills,
especially within the areas of contract and law.
Financial Control
Cost control within the project is crucial. At a minimum the Project Manager will be required
to report actual spend against planned spend and be able to forecast spend within the next
phase and for the remainder of the project.
People Skills
This will involve establishing the team, communications to staff at all organisational levels
and negotiation skills to name but a few.
1.1.5 Project Management vs Business as Usual

Project Management techniques and processes enable the Project Manager to manage
time, cost, scope, quality, performance and risk in order to implement change within the
business. This differs from managing the normal operational activities (business as usual) of
the organisation.
Typically, techniques for managing projects are focussed on:
responding to change
dynamic multi discipline teams
delivering products to time, cost and quality in order to produce benefit
flexible approach to working methods
taking some risks.
On the other hand business as usual is focussed on:
optimising repetitive process
functional team containing related disciplines
maintaining/improving quality
reducing costs
reducing risk
using the products of the project to generate benefits.
Page 6
1.2
Programme Management - BoK Topic 1.2
1.2.1 BoK Definition of Programme Management

Programme management is the co-ordinated management of related projects, which may
include related business-as-usual activities that together achieve a beneficial change of a
strategic nature for an organisation. What constitutes a programme will vary across
industries and business sectors but there are core programme management processes.
1.2.2 Programme Management Processes

Within Programmes each project is inter-dependent upon another and each will contribute to
the overall benefit that justifies the programme. Some projects may be infrastructure
projects. These are projects that dont make a direct contribution to the benefit, but without
them the programme would fail. An example of this would be a project to install a
communications network within an organisation. In its own right this generates no direct
benefit. However, until it is implemented the company will not be able to run the new
applications that do deliver benefits.
When managing a programme, changes and risk at project level must be considered for
escalation to the programme.
There are few, if any, strict definitions of a programme. What differentiates a sub-project
from a project or a project from a programme is rather vague. For example a programme
concerned with building a hospital, or a new international airport terminal may be viewed as
a programme or as a super-project. The underlying definition of programme
management usually contains reference to some element of strategic change as a result of
undertaking the work. This is not usually the case for projects. Timescales also play a part
many projects last for less than 2 years whist most programmes continue for 3 5 years,
sometimes longer. Irrespective of the definitions you use there are a number of key
processes used in programme management.
It is normal for the Project Managers to report to the Programme Manager. The Project
Managers will normally have a degree of autonomy, but will inevitably be subject to common
restraints imposed to support the overall objectives of the programme.
The Programme Manager will be responsible for the allocation of resources to the Project
Managers and the link between the project portfolio and the parent organisations objectives.
Programme management brings with it a risk that more than one level of business change
management may lead to confusion. The manager of the programme will have to take this
into account and be prepared to address any conflicting project objectives and disputes over
shared resources. The management, direction and objectives of the programme will
inevitably influence each of its constituent projects.
Programme management processes concentrate on benefits management and stakeholder
involvement. The production of deliverables or outputs is left to the project managers.
Example process flow:
A project will deliver an output (product) to the programme
The programme takes the output and implements it in the business (the transition
process)
The business experiences some change in process or staff behaviour, which is known as
the outcome.
As a result of the outcome the business is now able to generate benefits.
Page 7

This is a key difference between programme and projects.
Projects produce outputs, programme produce outcomes and generate benefits. Benefits
will be realised during the programme life-cycle and continue to managed once the
programme has closed.
1.2.3 Advantages of Programme Management

Programmes are focussed on delivering strategic change and realisation of benefits.
Programme management offers its projects many of the benefits associated with sharing
scarce resources and economies of scale.
Some of the functions performed by support staff within projects may be undertaken at
programme level for all projects within the programme, e.g. IT systems support and
Configuration Management etc.
A single member of staff may be made responsible for collating all the information
associated with a particular project management task such as risk management. As a
result, the effort required to maintain risk logs across projects will be reduced. This specific
example has the additional benefit of maintaining an alertness to risks associated with
project dependencies and risks which may be common across a number of projects.
There will be a reduction in the number of subject matter experts required across the
programme. This will have the effect of reducing costs. However, it will also have what is
perhaps a more important benefit, in that it will allow the sharing of individuals with scarce
skills across several related projects within the programme.
Centralised support services ensure consistency in the tools, procedures and methods being
used.
1.2.4 Disadvantages of Programme Management

Where projects are geographically dispersed, the benefits of the centralised support services
etc. associated with managing a programme will be significantly reduced. Their
effectiveness is also likely to suffer.
Support staff have to be alert to the duality of their role, their obligations to the programme
and their project.
If a number of projects require the same specialist expertise, resource conflicts may arise.
Page 8
1.3
Portfolio Management - BoK Topic 1.3
1.3.1 BoK Definition of Portfolio Management

Portfolio management is the selection and management of all of an organisations projects,
programmes and related business-as-usual activities taking into account resource
constraints. A portfolio is a group of projects and programmes carried out under the
sponsorship of an organisation. Portfolios can be managed at an organisational, programme
or functional level.
1.3.2 Portfolio Management

Figure 1.3.1 - Inter-relationships between portfolios, programme and projects
Strategic objectives
and targets
Strategic Benefits
Programme
management
Project
management
Programme
Programme11
Project A
Project B
Programme
Programme22
Project C
Project D
Project E
Portfolio
management
SubProject
A1
SubProject
A2
Business as Usual
In its simplest form an organisation would have a single portfolio containing one or more
programmes supporting its strategic vision. Each programme is then broken down into
projects which will be undertaken in addition to the normal operations of the organisation.
Management of the relationships between the programmes, projects and BAU is normally
the responsibility of a senior management team within the organisation concerned.
Key tasks will be to monitor resource requirements across the 3 strands, ensure that the
programmes continue to support the strategy and to ensure that benefits are realised. In
particular the portfolio management team will be concerned with the interdependencies
between programmes and projects in terms of scarce resources, balance within the portfolio
of risk and return, timing of outputs and managing capacity bottlenecks where more than one
project requires the same resource(s) at the same time.
It is probable in many large organisations that whilst there might be an overarching strategy
each function may have its own portfolio. For example the Sales and Marketing Department
may have a number of programmes running which support their strategic sales vision, each
spawning a number of projects whilst they continue to manage the BAU.
At the same time the Operations Dept may have a similar portfolio to manage.
Page 9
1.4
Project Context - BoK Topic 1.4
1.4.1 BoK Definition of Project Context

Project context refers to the environment within which a project is undertaken. Projects do
not exist in a vacuum and an appreciation of the context within which the project is being
performed will assist those involved in project management to deliver a project.
1.4.2 Project Context

Projects are about the implementation of change, usually in step form, within an
organisational/business environment. As such all projects need to be established within
their own particular context both internally and externally.
The changes essentially fall into two categories:
Technical
Involves change to the technology, physical environment of the organisation as a result of
engineering work, IT work, hardware, software, networks etc.
Cultural
Involves change to the organisation, such as skills, attitudes, values, management
processes, structure etc.
The vast majority of projects are a combination of both types. It is often more difficult to
cope with cultural change than technical change, e.g. the second runway at Manchester
Airport, on the face of it a purely technical project, but one which aroused intense feeling
about the environment e.g. cultural issues.
To assist with the assessment of the projects strategic setting it is often useful to conduct a
PESTLE analysis.
Political
The current/potential impact of global, national, local or organisational political pressure.
Economical
The current/potential impact of global, national, local or organisational economic factors.
Sociological
The current/potential impact of societys composition, culture, behaviour attitudes, abilities
and expectations.
Technical
The current /potential impact of advances in technology.
Legal
The current/potential impact of global, national or local legislation.
Environmental
The current/potential impact of the project and the changed organisation on the environment.
A PESTLE analysis can be used to identify potential threats and opportunities and will assist
with the successful management of the project.
Page 10
1.5
Project Sponsorship - BoK Topic 1.5
1.5.1 BoK Definition of Project Sponsorship

Project sponsorship is an active senior management role, responsible for identifying the
business need, problem or opportunity. The sponsor ensures the project remains a viable
proposition and that benefits are realised, resolving any issues outside the control of the
project manager.
1.5.2 The Project Sponsor

This is perhaps the most important role in any project. S/he is responsible for the project, its
business case, budget and the resulting achievement of benefits. The sponsor is the
primary risk taker and will chair the steering group.
Accordingly, a sponsor is normally a senior manager within an organisation and must be
empowered to make decisions by the corporate management. It is important that whoever
takes the role must have the capability and the time available to commit to the project. The
sponsor should ideally stay with the project throughout its life-cycle.
Many large projects cross organisational boundaries and as such internal politics can
become an issue for the project. Therefore, the sponsor must have sufficient authority to
cross these boundaries and engage the stakeholders to ensure that they all support the aims
of the project.
The project manager is accountable to the sponsor and regular communication between
them is vital to success. This should not be confined to formal reporting but should include
informal contact throughout.
Figure 1.5.1 details the role of the sponsor throughout the life-cycle.
Figure 1.5.1 Sponsors role across the life-cycle
Concept
Establish context
Agree team
Provide resource
State benefits
Contribute to and
sign off the
Business case
Definition
Provide guidance
Contribute to the
PMP
Sign off the PMP
Implementation
Receive reports
Make decisions
Chair steering
group
Chair reviews
Monitor change
Prepare for
benefits realisation
Handover and
closeout
Accept
deliverables
Agree outstanding
work
Sign off reports
Ensure plans for
benefits realisation
are in place
Page 11
1.6
Project Office - BoK Topic 1.6
1.6.1 BoK Definition of Project Office

A project office serves the organisations project management needs. A project office can
range from simple support functions for the project manager to being responsible for linking
corporate strategy to project execution.
1.6.2 Role of the Project Office

In all but the smallest of projects there will be a significant amount of administration to be
undertaken. Without any support this falls to the Project Manager to complete and can
easily result in one of two outcomes; the administration is left whilst the PM concentrates on
day to day management, or the PM gets the admin done at the expense of the day to day
management. Alternatively, the PM works lots of overtime!
This is where the role of the basic project office comes in. It can be some administrative
support, maybe 2 or 3 days a week and the person taking the role assists the PM with
administration, completion of minutes of meetings, maintaining the schedule, receiving and
analysing reports and so forth. Because this is a part time function at this level it is often
difficult to justify in terms of headcount and resources available. It is for this reason that
many organisations have established a formal Project Support Office (PSO) function.
A PSO is a group of perhaps 5 or 6 staff that supports several projects between them. As
the peak demand for administration varies the staff are able to cross project boundaries and
assist where required.
Typical responsibilities of a PSO include:
Operate a filing system for several projects
Operate a configuration management system
Be a centre of expertise for:

o
Estimating techniques
Planning and control software
Risk analysis methods and software
Preparation of plans
Project reporting
Assurance of the process
Maintain logs for risks, issues and changes.
In some organisations the PSO is combined with a Programme Support Office and becomes
a Programme and Project Support Office (PPSO). At the programme level the role is often
expanded to cover the governance of the project, and staff in these units often act as
deputy managers.
Whatever arrangements are made in the project it important that the project documentation
is not overlooked as it forms an important audit trail throughout the project life-cycle.
Page 12
Section One Project Management in Context

1,
Which of the following is a typical characteristic of a project?
a)
Repetitive
b)
Stable, unchanging team
c)
Goal driven
d)
Constant, unchanging environment
2.
Which of the following is best suited to be line managed?
a)
Building a bridge
b)
Developing a tin-opener
c)
Buying a car
d)
Manufacturing car batteries
3.
Which of the following best describes the overall aim of project management?
a)
To eliminate risk
b)
Adhere precisely to the original specification
c)
Ensure the original budget is met
d)
Achieve the success factors described in the Business Case
4.
Which of the following constitute a programme?
a)
A group of otherwise unrelated projects sharing resources
b)
A large and complex project
c)
A group of projects sharing a common business purpose
d)
Maintaining Business operations
5.
What are considered by a PESTLE analysis?
a)
Political, Economic, Sociological, Technical, Legal, Environmental
b)
Personnel, Economic, Safety, Technical, Legal, Estimating
c)
Political, Ecological, Safety, Technical, Lifecycle, Environmental
d)
Personnel, Ecological, Sociological, Training, Lifecycle, Estimating
Page 13

6.
List 3 benefits of using Programme Management
a)
b)
c)
7.
Portfolio Management takes into account what type of constraint when
selecting and managing projects, programmes and business as usual?
a)
8.
In which Phase should an analysis of Project Context first be carried out?
a)
9.
Which management product is owned by the Project Sponsor?
a)
10.
What post project activity is the Project Sponsor responsible for?
a)
Page 14
2 Planning the Strategy

2.1
Project Success and Benefits Management - BoK Topic 2.1
2.1.1 BoK Definition of Project Success and Benefits Management

Project success is the satisfaction of stakeholder needs and is measured by the success
criteria as identified and agreed at the start of the project. Benefits management is the
identification of the benefits at an organisational level and the monitoring and realisation of
those benefits.
2.1.2 General
The succes of a project will be judged by many people, including:
The client/sponsor
The project manager and project team
The users
The customer
There are many examples of projects which appear to have failed, especially in the public
sector as these often reach the headlines. However, just because a project has exceeded
its original budget does not mean it has failed. It may appear so but if the additional spend
has been authorised and benefits can still be realised, can it really be judged a failure?
To judge success it is necessary that there be some objective criteria. Once these criteria,
and the associated Key Performance Indicators, have been set then the project manager
will aim ensure that they can be achieved.
2.1.3 Project Success Criteria

Specifically these revolve around time, cost, quality/performance and the customers
requirements. Budgets and timescales are often set in advance - the requirements and
associated acceptance criteria can be difficult to pin down. What makes the deliverable
acceptable to the customer?
2.1.4 Project Success Factors

Research has indicated that there are five key factors which can be established against
which success can be measured:
Project Objectives
clearly identified within the project plans and kept to throughout the work
Project Personnel
the project manager and the project team must be competent
Support from Above
the project must be supported by top management
Resources
time, money, material and people must be sufficient to do the job
Communication and Control
Page 15

communications channels up, down and across the project are established with clear
mechanisms for feedback on performance.
Other factors conducive to project success would include:
A plan - good and managed, replan when required
Time to plan - very important, often difficult to find
The right sized work packages suited to the team and measurable
2.1.5 Key Performance Indicators

The BoK defines Key Performance Indicators (KPIs) as measures of success criteria and
goes on to say that Tracking KPIs ensures that the project is progressing towards
achievement of success criteria, enabling corrective action to be taken. The KPI must be
carefully chosen to be suitable measures of the projects success and they must be clear
and unambiguous.
2.1.6 Benefits Management

The benefits are those things, tangible or intangible, that justify the time, money and
resources that are spent on delivering a project. If there are no benefits then, ideally, there
should be no project. If the benefits disappear, for whatever reason then the project should
be stopped. The benefits should be monitored and maintained throughout the life-cycle of
the project and efforts made to realise them once the project products have been delivered.
However, in many projects, this is overlooked and the projects continue when no benefits
can be identified.
2.1.7 Benefits Process

Project Phase
Relationship to benefits
Concept
Business benefits are identified by the sponsor and

encapsulated within the business case
Definition
The benefits are further refined and the business case updated.
The PMP is produced which describes how the project will
deliver the products that will enable the benefits to be realised.
Implementation The benefits are benchmarked. Figures are collected that relate
to each benefit so that a similar exercise can be undertaken
during realisation which will enable a comparison to be made.
As more becomes known about the project and its outputs
further benefits are identified if possible and the existing benefits
are monitored to ensure that the claims are still valid.
Handover and
Close Out
The sponsor accepts the products and makes sure that plans
are in place for the benefits to be realised.
Operations
The sponsor ensures that the operational or BAU staff

undertake the necessary activities to realise the benefits, e.g. if
the new product was to allow a reduction in staff numbers then
the appropriate numbers of staff should be re-deployed. If the
product was to enable increased sales then the sales figures
should be monitored to check that the benefits have been
realised. If not then action should be taken.
Page 16
2.1.8 Defining Benefits

Benefits should be measurable. Benefits can be categorised as shown below in figure 2.1.1.
Figure 2.1.1 Benefit Categories
Relate to
Non-financial
objectives
Indirect
e.g.
better image
staff morale
customer service i.e.
improved market perception
Direct (non-financial)
e.g.
greater accuracy
increased employee efficiency
customer service
increased speed of response
Relate to
Financial
objectives
Intangible
Tangible
Direct (financial)
e.g.
staff reductions
increased revenue
accommodation costs
There are many types of benefits and ideally the benefits should fall into the tangible
category and therefore be easier to justify. However, benefits that fall into the intangible
category are also useful and may well indicate areas where cultural change may be required
within the organisation. This could represent considerable challenges to realise these
benefits.
Each benefit identified must be carefully and precisely stated and it is useful to test the
benefits against the DOAM criteria:
DESCRIPTION
o
OBSERVATION
o
What differences should be noticeable between pre- and post-project?
ATTRIBUTION
o
What precisely is this benefit?
Where will this benefit arise?
MEASUREMENT
o
How will the achievement of the benefit be measured?
Page 17
2.2
Stakeholder Management - BoK Topic 2.2
2.2.1 BoK Definition of Stakeholder Management

Stakeholder management is the systematic identification, analysis and planning of actions to
communicate with, negotiate with and influence stakeholders. Stakeholders are all those
who have an interest or role in the project or are impacted by the project.
2.2.2 Stakeholder Management

Key stakeholders should be identified early within the project life cycle, mapped and
analysed.
This will involve a number of steps:
1. Identify the stakeholders, perhaps through a workshop or other brainstorming activity.
2. For each stakeholder identified, establish their main interest in the project e.g. time,
cost, scope, benefit or quality. Not only will this help to identify how stakeholders are
likely to react in the future but will show what the stakeholders see as the main driver
of the project. For example if the analysis shows a majority of ticks against quality
and none against cost it would show that the main driver is quality and cost is not a
key issue.
3. For each stakeholder identified establish their power and interest rating. It should
also be established whether s/he has a positive or negative attitude towards the
project.
4. The results of the power/interest analysis can be plotted on a grid as shown in
figure 2.2.1 below.
Figure 2.2.1 Stakeholder mapping
The information relating to main interest area that was gathered earlier can now be used as
a basis of the communications plan, as it will show the type of information each stakeholder
(group) requires. The analysis could also be used to identify the role the stakeholder should
take, if any, on the project team. It may also assist with identification of key risks associated
with stakeholders.
Page 18
2.4
Project Management Plan - BoK Topic 2.4
2.4.1 BoK definition of Project Management Plan

The project management plan brings together all the plans for a project. The purpose of the
project management plan (PMP) is to document the outcomes of the planning process and
to provide the reference document for managing the project. The project management plan
is owned by the project manager.
2.4.2 Project Management Plan

The Project Management Plan (PMP) is the key document which contains all the key
information for the project. It is sometimes known as the Project Initiation Documentation
(PID) in Prince 2, the Project Strategy Plan or the Project Execution Plan (PEP).
Basically, the PMP documents the what, why, when, how, where, who, how much
and what if of the project.
The PMP is owned by the Project Manager and it must be approved by the project team and
the project sponsor. It must have the commitment of all concerned.
The purpose of the PMP is to provide a basis upon which the project can be managed and
its success judged.
It has two primary purposes:
it ensures that the project has a sound basis upon which to proceed before asking the
sponsor and other stakeholders to make major commitment to the project
it provides a base document against which the project management team can assess
progress, change management issues and the ongoing viability of the project.
BS 6079-1: 2002 states that a basic project management plan should contain the following
sections:
a) Introduction and summary
This part of the PMP should include the following information:
Project name, reference number, issue number and date
PMP Contents
Name of sponsor
Summary of objectives and the approach proposed to achieve them
Summary of completion (acceptance) criteria
List of amendments and short summary of each
References to mandates, governance standards etc
Guidance for performing the work, for example, procurement strategy, risk
management strategy, contract management, organisation structure etc
Document circulation and contacts list
List of associate contracts
Reference to the business case upon which the project was authorised.
Page 19

b) Commitment acceptance (for task owner commitments and project managers
acceptance of them)
This includes the task owners commitments and the PMs acceptance of these
commitments. This should be achieved by signing the appropriate WBS reference.
This would include any caveats made by the task owners.
c) Project Work Breakdown Structure (WBS)
The WBS is a hierarchical description of the tasks that will form the project schedule.
At project level the WBS should indicate the areas of work for the task owners so that
they can develop the WBS into a task level breakdown. This graphical
representation reduces the risk of overlooking something and helps to define the
amount of work involved. (It is discussed further in Section 3 Executing the
Strategy).
The WBS dictionary is a list of all the tasks along with a short description of each. It
will also include a glossary of task definitions and will enable users to locate tasks
quickly.
d) Schedule
The schedule is a Gantt (or bar) chart, perhaps supported by a critical path network.
It provides a view of the tasks against a calendar (and the network shows the
dependencies between them).
e) Statement of Work (SOW)
The SOW includes a description of the work, the person accountable for the work, a
list of key deliverables, timescales, schedule of dependencies, cost schedule, risk
assessment, performance measures, description of the work content and reporting
requirements.
At the level of the PMP this may relate to the project but each subsidiary work area
and further sub-division into the individual tasks will all require a SOW at the
appropriate level.
In summary, the PMP is not a trivial document; neither will it be completed quickly. It is,
however, the basis for a successful project and must be baselined, placed under
configuration management and updated throughout the project.
Page 20
2.5
Project Risk Management - BoK Topic 2.5
2.5.1 BoK Definition of Project Risk Management

Project risk management is a structured process that allows individual risk events and
overall project risk to be understood and managed proactively, optimising project success by
minimising threats and maximising opportunities.
2.5.2 More Definitions

(From the Project Risk Analysis and Management Guide 2nd edition)
o Risk event ..is an uncertain event or set of circumstances that, should it occur,
will have an effect on achievement of one or more of the projects objectives
o Project risk..is the exposure of stakeholders to the consequences of variations in

outcome.
Additionally, a differentiation should be made between threats and opportunities:
o Threat is a risk event that has a negative impact

o
Opportunity is a risk event that has a positive impact.
2.5.3 Risk Management Process

The risk management process identified is shown below in figure 2.5.1.
Initiate
Assess
Plan responses
Manage processes
Identify
Implement responses
Figure 2.5.1 - Risk Management Process
Each element of the cycle is defined within the slides.
Page 21
2.5.4 Qualitative Risk Identification & Assessment Techniques

There are several qualitative risk management techniques including:
Assumptions analysis
Constraints analysis
Check lists
Prompt lists
Workshops/Brainstorming/SWOT analysis
Probability-Impact (P-I) tables
Interviews.
2.5.5 Risk Planning Strategies

Once risks have been identified, their individual importance assessed and their combined
effect on achievement of project objectives analysed, it is necessary to decide how to
respond appropriately. Risk control techniques fall into four groups, aiming to avoid
uncertainty, transfer ownership, reduce exposure or absorb individual risk. These are
outlined below.
Risk Avoidance
Measures designed to avoid uncertainty include:
Clarifying requirements and objectives.
Improving channels of communications.
Obtaining information from external sources.
Acquiring expertise.
Changing the direction or strategy for project implementation.
Reducing the scope of the project.
Adopting a familiar approach for implementation.
Using proven methods, tools and techniques.
Risk Transfer
It may be appropriate to transfer ownership and liability for a risk to another party outside the
project. It should be recognised that it may not be possible to transfer all aspects of a risk.
For example, financial liability may be transferred to a supplier via cost penalties, but the
project will retain the performance impact if supplied equipment is late or non-compliant.
Methods for risk transfer include:
Financial instruments such as insurance, performance bonds, warranties or

guarantees.
Renegotiation of contract conditions to pass the risk back to the customer.
Subcontracting risks to suppliers.
Entering into risk-sharing joint ventures or client-contractor teaming arrangements
Considering other contractual forms such as target-cost incentivisation.
Page 22

Risk Reduction
There are many strategies for reducing risk exposure, and the bulk of risk control activity is
focused on this objective. Risk reduction techniques aim to:
Reduce the probability of occurrence by targeting trigger conditions
Reduce the potential severity of impact by targeting impact drivers
Tackle the common causes of risk by identifying generic responses
Include targeted contingency or risk budgets, applied to high-risk areas, and with
identification of specific release conditions when the contingency amount may be
used.
Risk Acceptance
It is not usually possible to remove all risk from a project, and strategies must be adopted to
control risks that cannot be avoided, transferred or cost-effectively reduced. These may
include:
Routine risk monitoring and reporting
Regular risk reviews and updates
Feedback of risk information into project planning and strategy
Efficient infrastructure support for the risk process
Continued commitment to proactive risk management
Page 23
2.6
Project Quality Management - BoK Topic 2.6
2.6.1 BoK Definition of Project Quality Management

Project quality management is the discipline that is applied to ensure that both the outputs of
the project and the processes by which the outputs are delivered meet the required needs of
stakeholders. Quality is broadly defined as fitness for purpose or more narrowly as the
degree of conformance of the outputs and process.
2.6.2 Principles of Quality Management

Quality management is the process of ensuring that the quality expected by the customer is
achieved. It encompasses all the project management activities that determine and
implement the Projects Quality Plan.
2.6.3 Quality Management Systems

QMS: A Quality Management System with an organisational structure, procedures and
processes to implement quality management. Both the Customer and the Supplier may have
quality systems. The project may have to use one of these quality systems or an agreed
mixture of both.
QP: Quality Planning establishes the objectives and requirements for quality and lays out
the activities for the application of the quality system. The quality approach for the whole
project is defined in the Project Quality Plan (itself a part of the PMP). It is important that the
Customers quality expectations are understood and documented prior to project
commencement. This is done in Mobilisation. The Quality Plan specifies in detail the
required quality activities and resources, with the associated detailed quality criteria.
QA: Quality Assurance sets up the quality system and is the means of assuring that the
quality system operates to achieve an end product which meets quality and customer
requirements. It creates and maintains the quality system, audits and evaluates it. A quality
assurance function may be set up separately from, and independent of, the organisations
project and operational activities. Its purpose is to monitor the use of the quality system
across all projects within the corporate body. If such an independent body does not exist, the
project assurance function within the project will assume the quality assurance role.
QC: Quality Control is the means of ensuring that products meet the quality criteria specified
for them. Quality control is about examining deliverables/products to determine that they
meet requirements.
We should examine the principles behind a quality check to provide:
A structured approach to the examination of subjective and objective quality criteria
Early identification of defects - a platform for improvement with attendant reduction in the
costs of the final product
A test of completion - once they have successfully passed Quality Review, an objective
measurement for management progress control is provided; progress is measured by
product delivery
A means for all vested interests to work together to improve product quality
For personnel to commit to that product, as ownership of the product is shared between
Quality Review participants
A means to check for defects in standards and methods chosen for the project -leading
towards standards improvements.
Page 24
2.6.4 Quality Management Tools

Bearing in mind that project management is systemic (the separate parts inter-relate) it is not
surprising that we have already examined some quality tools in Risk Management.
Audits: a review of the project, its management, standards and procedures. An internal
body, such as project support office, or an external auditor, can undertake the audit
depending on the situation. The aim of the audit is to assist the team to undertake the
project in a controlled manner that will aid the project to deliver right first time. The auditor
will prepare a report documenting the results of the audit and if non-conformances are noted
will normally give a date by which they should be rectified. This will often include a date for a
re-assessment.
Ishakawa Diagrams (Cause and Effect Analysis): These are also known as fishbone
diagrams where there is an effect, and a range of possible causes sorted into categories
with factors on each bone emanating from the central backbone. In a quality situation the
quality problem would be the head and factors that contribute to the problem would be
categorised and added to the bones. It may be useful to use another technique known as
the Five Whys when identifying causes. This simple technique is very like the inquisitive
child that continually asks why? Research has shown that if you ask why something has
occurred and then when given an answer, you ask why again you will, after 5 iterations have
got to the root cause.
As an example take checkout queues in supermarkets being too long.
Why? Because the operator cant check the goods through fast enough
Why? Because the operator doesnt understand the systems
Why? Because training has not been given
In this example 3 whys were enough to get to root cause of the problem staff training.
In some cases two or three more iterations may be required.
Once this has been completed a further analysis will be required to see which bone or
group of bones would have the most effect if fixed. This could be achieved using a
Pareto analysis.
Pareto Analysis: Vilfredo Pareto was an Italian economist who, in 1906, observed that
twenty percent of the Italian population owned eighty percent of the country's total wealth.
Ever since then, Pareto's observation has been used in a variety of ways, and is often
referred to as the 80-20 Rule, the "Vital Few and Trivial Many Rule.", or simply Pareto's
Principle.
It is of particular interest to us here in that it is a reminder that just a few causes account for
most of the effect in a Cause and Effect Diagram. When you have carried out a Cause and
Effect analysis your next step should be to identify and work on the vital few causes.
Thus it is possible to identify those problems (the 20%) that if fixed will have the most effect
(the 80%).
Sampling: This is a quality control technique and is used to check that products meet the
quality criteria specified. For example, in a manufacturing environment the products will be
checked every 100 runs.
100% testing: This quality control technique does exactly what it says everything is tested.
For example an installation of telephone sockets in a large building may mean that 10,000
outlets are installed. The client may want all to be tested. However, as this number includes
Page 25

a number of spares and allows for growth it may be that sampling may be a more cost
effective and adequate approach.
Inspection: Similar to audit but requires the physical inspection of the products to see that
they conform to the criteria specified. It may well be supported by data from other activities
such as sampling or 100% testing.
Control Charts: These are used to record historical quality control data, perhaps from
sampling and, in common with many monitoring activities, will enable the user to identify
trends, either good or bad. If a negative trend has been identified, one of the other
techniques can be used to identify its cause and then corrective action taken.
2.6.5 Cost of Quality

There is a balance between providing high standards which are expensive to maintain but
produce low error rates, and low standards which cost nothing but have a high cost in
rectification and rework.
This is shown graphically below and the minimum cost is the balance. However, in most
projects the aim would not be to achieve the minimum cost but somewhere to the left of the
point shown as we would expect to have slighter higher standards and be prepared to pay
extra for them.
Figure 2.6.1 The Cost of Quality
Minimum Cost
Total Cost
Cost
Cost of Failures
Cost of Control
Low
High
Number of Mistakes
Standards
High
Low
Page 26
2.7
Health, Safety and Environmental Management - BoK Topic 2.7
2.7.1 BoK Definition of Health, Safety and Environmental Management

Health, safety and environmental management is the process of determining and applying
appropriate standards and methods to minimise the likelihood of accidents, injuries or
environmental impact both during the project and during the operation of its deliverables.
2.7.2 Health & Safety Legislation

All employers have a general Duty of Care under common law to take whatever steps are
necessary to ensure the health, safety and welfare of their employees and in particular to
provide:
A safe place of work
Safe means of access to that place of work
Safe system of work
Adequate materials
Competent fellow employees
Protection from unnecessary risk of injury.
2.7.3 [Extracts from ] The Health & Safety at Work etc. Act General Duties
General duties of employers to their employees.
2. (1) It shall be the duty of every employer to ensure, so far as is reasonably practicable, the
health, safety and welfare at work of all his employees.
(2) Without prejudice to the generality of an employer's duty under the preceding subsection,
the matters to which that duty extends include in particular
(A) the provision and maintenance of plant and systems of work that are, so far as is
reasonably practicable, safe and without risks to health;
(B) arrangements for ensuring, so far as is reasonably practicable, safety and absence of
risks to health in connection with the use, handling, storage and transport of articles and
substances;
(C) the provision of such information, instruction, training and supervision as is necessary to
ensure, so far as is reasonably practicable, the health and safety at work of his employees;
(D) so far as is reasonably practicable as regards any place of work under the employer's
control, the maintenance of it in a condition that is safe and without risks to health and the
provision and maintenance of means of access to and egress from it that are safe and
without such risks;
(E) the provision and maintenance of a working environment for his employees that is, so far
as is reasonably practicable, safe, without risks to health, and adequate as regards facilities
and arrangements for their welfare at work.
General duty of persons in control of certain premises in relation to harmful
emissions into atmosphere.
5. (1) It shall be the duty of the person having control of any premises of a class prescribed
for the purposes of section 1(1)(D) to us the best practicable means for preventing the
emission into the atmosphere from the premises of noxious or offensive substances and for
rendering harmless and inoffensive such substances as may be so emitted.
Page 27

General duties of employees at work.
7. It shall be the duty of every employee while at work
(A) to take reasonable care for the health and safety of himself and of other persons who
may be affected by his acts or omissions at work; and
(B) as regards any duty or requirement imposed on his employer or any other person by or
under any of the relevant statutory provisions, to co-operate with him so far as is necessary
to enable that duty or requirement to be performed or complied with.
2.7.4 Other Important Health & Safety Legislation

The most significant piece of health and safety legislation which has originated in Brussels
(to date), is the Management of Health & Safety at Work Regulations (MHSWR). MHSWR
(together with the Approved Code of Practice), requires all employers and self-employed
persons to carry out risk assessments and implement adequate arrangements for the
following health and safety related issues:
Planning (i.e. adopting a systematic approach for the identification of priorities and the
objectives)
Organising (i.e. putting an effective structure in place to ensure that there is progressive
improvement)
Controlling (i.e. making sure decisions are implemented quickly and effectively)
Monitoring and reviewing.
MHSWR and the five associated Regulations are often referred to as the European Six
Pack:
Management of Health & Safety at Work Regulations
The Workplace (Health, Safety & Welfare) Regulations
Use of Work Equipment Regulations
Personal Protective Equipment at Work Regulations
Manual Handling Regulations
Health & Safety (Display Screen Equipment) Regulations
Health & Safety (First Aid) Regulations.
RIDDOR
The Reporting of Injuries, Diseases and Dangerous Occurrences Regulations , referred to as
RIDDOR, requires employers to report specific injuries to people at work. It simplifies the
need to report accidents to members of the public in any workplace and lists reportable
diseases and dangerous occurrences.
Page 28
Section Two Planning the Strategy

1.
Success criteria should be developed as part of:
a)
Detailed planning
b)
The Work Breakdown Structure
c)
The Business Case
d)
Risk Management
2.
A Project Management Plan:
a)
Is not owned by the project team
b)
Excludes procurement
c)
Includes the What, Why, How, When, How Much, and Who of the project
d)
Is developed by the Sponsor
3.
Which of the following is a strategy for mitigating risk?
a)
Reduction
b)
Smoothing
c)
Assessment
d)
Identification
4.
Which of the following is a correct and complete definition of project risk?
a)
An event which causes uncertainty
b)
An uncertainty which if it occurs would affect project objectives
c)
A threat to human health and safety
d)
The impact of changes in requirement
5.
What does Project Quality Management consist of?
a)
Quality Planning, Project Assurance, Quality Control, Continuous Improvement
b)
Quality Assurance, Quality Audit, Quality Control, Continuous Improvement
c)
Quality Planning, Quality Assurance, Quality Control, Continuous Improvement
d)
Quality Assurance, Quality Planning, Quality Audit, Continuous Improvement
Page 29

6.
Which 3 things do Project Success Criteria normally revolve around?
a)
b)
c)
Who owns the Project Management Plan?
a)
8.
What are the elements of the Risk Management Process?
a)
b)
c)
d)
e)
f)
9.
What is a broad definition of Quality in a project?
a)
10.
In which Phase of the project is the Project Management Plan created?
a)
Page 30
3 Executing the Strategy

3.1
Scope Management - BoK Topic 3.1
3.1.1 BoK Definition of Scope Management

Scope management is the process by which the deliverables and work to produce them are
identified and defined. Identification and definition of the scope must describe what the
project will include and what it will not include, i.e. what is in and out of scope.
3.1.2 Process
When a project is started there is always a significant amount of planning work to be
completed. This will involve establishing what is required, the deliverables, the phases of
work, what activities and tasks are required, how much will it cost and who is going to do it.
The use of breakdown structures will assist the project manger to bring order to this.
We will consider 4 breakdown structures and the resulting responsibility assignment matrix.
With all breakdown structures there is no absolute way of constructing them, for example
you may have a product specification of requirements which is split into sub products for
each element, e.g. module 1, module 2. Alternatively, each module may have a sub
product specification of requirements.
3.1.3 Product Breakdown Structure

The Product Breakdown Structure consists of a hierarchy of Products (also known as
deliverables or outputs). The PBS is used to break the ultimate product of the project into
smaller and smaller components, usually about three levels, after which one often starts to
introduce verbs into the description and has therefore left products and moved into activities.
For example consider a project to produce a landscaped garden. The PBS may look like:
Landscaped Garden
Documents
Group (A)
Specification
(A1)
Site
Description
(A2)
Buildings
Group (B)
Garden
Group (B1)
Site
Group (B2)
Shed
(B1.1)
Patio
(B1.2)
Design
(A3)
Garden
Group (C)
BBQ
(B1.3)
Horticulture
Group (C1)
Cleared
Site
(B2.1)
Marked
Out
Layout
(B2.2)
Pond
(B1.4)
Tools
Group (C2)
Lawn
(C1.1)
Flower
Beds
(C1.2)
Power
Tools
(C2.1)
Hand
Tools
(C2.2)
Vegetable
Area
(C1.3)
Figure 3.1.1 Product Breakdown Structure

Note each of the products is systematically referenced with a unique alpha-numeric
reference e.g. Shed would be referenced B.1.1. The numbering system will remain constant
throughout the project and should be used constantly across all the tools, e.g. networks,
Gantt charts, schedule.
The key benefits of using Product Breakdown Structures are:
Page 31

Defines the scope of the project
Focuses the team on what is going to be produced
Forces the team to think of the product content, e.g. if it is a database, what type, how
many records, what is the record format etc.
What quality criteria will be applied to the product, how will it be reviewed and what skills
are required to undertake the review. This is the key, and most important element of the
PBS.
Having produced a PBS it is possible to produce a Product Flow Diagram (PFD) that shows
the order in which the products are created.
To build the products will require the team members to undertake a number of activities and
tasks. This results in a Work Breakdown Structure.
3.1.4 Work Breakdown Structure

Constructed in exactly the same manner as the PBS the WBS will almost exclusively use
verbs in its descriptions. As an example take the landscaped garden and break one
element down further, in this case the site description:
Figure 3.1.2 Work Breakdown Structure
Site
Description
(A2)
Go to site
(A2.1)
Measure site
(A2.2)
Draw Site
Plan (A2.3)
Write Site
visit report
(A2.4)
Write Site
Description
(A2.5)
Whilst the top level remains as a product the subsidiary levels are now activities and
describe what needs to be done to produce, for example the site description got to site,
measure the site, draw a plan, write a visit report and write the site description.
Each element of the WBS can be numbered and this numbering will remain constant
throughout the project.
The key benefits of the WBS are:
Again helps to define the scope of the project
Forces the team to think through the production process
Forms the basis for precedence networks and estimating
Defines the work content
The WBS is fundamental to the production of a suitable schedule
Forms the basis of Earned Value calculations by defining the base data for effort,
materials and other resources.
Once a WBS has been completed it will become necessary to assign the work to the teams
or personnel responsible for undertaking the work. The first step is to produce an
organisation breakdown structure.
Page 32
3.1.5 Organisation Breakdown Structure

A typical organisation breakdown structure is shown below. It will be different for each
project.
Figure 3.1.3 Organisation Breakdown Structure
Project
Manager
Team Manager
Design
Team Manager
Procurement
Team Manager
Testing
Team Manager
Implementation
Senior
Designer
Buyer 1
Chief
Tester
Support
Engineer 1
Trainee
Designer
Buyer 2
Assistant
Tester
Support
Engineer 2
Warehouse
Manager
Contracts
Manager
3.1.6 Cost Breakdown Structure

Cost breakdown is a very straightforward process which can become extremely complex in
operation. The amount of detail required within a CBS will depend on the nature of the
project and the accounting processes within your organisation. For example, do you record
time? If so, are costs transferred between departments? Will the work be completed by a
contractor? If so what sort of contract and payment method is being used, e.g. time and
materials, fixed price, bill of quantities, monthly payment?
Basically however, the process is:
Allocate costs to each activity (from WBS/PBS) taking into account;
Labour
Materials, Plant and equipment
Subcontract
Management
Overhead and administration
Fees and taxation
Inflation
Other contingency
Allocate to a Cost Centre
The resulting Cost Breakdown Structure output is often recorded in a sophisticated
accounting system such as SAP, which will produce cost reports for management action.
Having produced these structures it is necessary to relate one to the other, in particular the
WBS (or PBS) to the OBS to produce a:
Page 33
3.1.7 Responsibility Assignment Matrix

This is a cross reference between tasks on the WBS (or products on the PBS) and the staff
on the OBS. There are two acronyms that may be used to document varying degrees of
involvement and responsibility; RACI or PARIS, or a combination of both to suit your needs:
RACI
Responsibility - This person, or group, will be doing the work
Accountability - This person (and only one) will be accountable for the work being done; i.e.
the buck stops here!
Consultation (communication) - A person or group of people who communicate or consult
with the doers, e.g. the testers may contribute towards the work of the researchers
Information - A person or group who needs to be kept informed of progress throughout the
task.
PARIS
Performs - This person, or group will be doing the work
Approves - This person or group, approves the final product
Reviews (or is notified) - The group or person reviewing the product as it is produced
Inputs (contributes to) - A person or group of people who communicate or consult with the
doers, e.g. the testers may contribute towards the work of the researchers
Supports - The person or group of people who provide help and assistance to the
performers or support the process.
An example matrix is shown below:
Figure 3.1.4 - Example of Responsibility Assignment Matrix using PARIS
Code
A1.1
A1.2
A1.3
B1.1
B1.2
B1.3
B1.5
Activity Description
Design Module 1
Design Module 2
Design Integration Routine
Select Suppliers
Prepare Contract Documents
Issue Tender
Review Tender
Team Mgr
Design
R
R
R
Senior
Designer
P
P
P
Trainee
Designer
I
I
I
Team Mgr
Procurement Buyer 1
I/R
P
R
Buyer 2
Contracts
Manager
P
P
S
A
3.1.8 Breakdown Structure Relationships

Breakdown structures are related to each other. It can be argued that to produce a PBS or
WBS will first need some form of team to be developed therefore some form of OBS is
required to get the planning process started.
The next step is to produce a PBS and this in itself may well identify products that require
specialise expertise incorporating into the team hence the OBS will be updated.
Once the PBS is completed a WBS will be produced to identify the tasks required to build
the products. Again the OBS may well be enhanced as the full skills requirement of the
project is identified. As the WBS is produced the CBS can be started and then finalised
when the RAM is produced and the staff types and charges known.
Page 34

The refined OBS and the WBS are related to produce a RAM, which then enables a full CBS
to be produced.
Figure 3.1.5 Relationship between Breakdown Structures
OBS
RAM
PBS
WBS
CBS
3.1.9 Work Package

A work package is a generic term given to the information passed to a team member in order
that s/he may complete a piece of work. This may be a simple instruction to complete a
simple task and therefore be informal or at the other extreme may cover the issuing of a
complex contract for a large piece of work, in which case it will be formal and extensive.
It will contain a SOW, reporting requirements, time, cost and quality information and any
other information necessary for the completion of the work.
3.1.10 Scope Baseline

It is essential that the scope of the project is baselined. A baseline is a snapshot, position or
situation that is recorded. Once baselined an item cannot be changed unless formal change
control is established. In this case future changes must pass through change control, the
effect of change must be analysed and, if the change is authorised, then the newly agreed
scope will be baselined at the next version number. The original baseline remains
unchanged. This provides an audit trail throughout the project showing how and why the
scope has altered since the project was initially planned..
Page 35
3.2
Scheduling - BoK Topic 3.2
3.2.1 BoK Definition of Scheduling

Scheduling is the process used to determine the overall project duration and when activities
and events are planned to happen. This includes identification of activities and their logical
dependencies, and estimation of activity durations, taking into account requirements and
availability of resources.
3.2.2 The Scheduling process

Underpinning the process is the establishment of the product requirements in the PBS,
followed by the activities and tasks established with a WBS. The identification of
dependencies between the activities leads to a network diagram.
The effort involved in the activities and their forecast duration need to be estimated.
Included within estimating is risk analysis, although this could, and should, be started as
soon as possible in the process.
Applying the duration estimates to the network diagram leads to a critical path, which when
resourced will result in a project schedule.
However, this is not a simple staircase but rather a keep fit exercise as to produce an
acceptable schedule it is often necessary to run up and down the stairway several times!
New products and tasks are often identified further up the stairway as the project is
understood in more detail and this necessitates going back down to add them into the
appropriate structure. Risk management activities can also affect the number of products
and tasks.
3.2.3 Networks: Activity on Node

It is best practice to understand the project environment, content and scope through the
WBS. The relationships between activities is normally represented by networks. We will
use Activity on Node (AoN) as this is most commonly used.
The Node shown below describes attributes in the positions shown as defined by the British
Standards. (Software Tools allow us to modify the positions and add and/or subtract other
attributes if we wish).
Figure 3.2.2 Node Definition
Earliest Start
Time
Duration
Earliest
Finish Time
Actiity Number, Activity Description,

Resources Required
Latest Start
Time
Total Float
Latest Finish
Time
The table below shows seven activities with durations and dependencies after the Project
Management Team have analysed the project.
Page 36

Activity
A
B
C
D
E
F
G
Duration
1
2
4
3
8
9
7
Dependency
A
A
B,C
A
E
D,F
Basic Rules:
FORWARD PASS (Top Row)
Add Duration to Earliest Start to determine Earliest Finish
If more than one predecessor: FORWARD PASS HIGH.
BACKWARD PASS (Bottom Row)
Take the Earliest Finish Time to be the Project End Date and drop it into the Latest Finish
Time of the Node.
Subtract Duration from Latest Finish to determine Latest Start
If more than one successor: BACKWARD PASS LOW.
Figure 3.2.3 Example Network
1
2
3
B
13 12 15
0
0
1
A
0
FF 2
4
5
C
11 10 15
3
8
D
15 10 18
8
E
0
9
F
0
FF 10
18
18
18
18
7
G
0
25
25
Float (or Slack) represents how much flexibility the Project Manager has in executing
network tasks. Float ALWAYS pertains to an Activity.
TOTAL FLOAT is the amount of delay an activity can absorb before it delays the END OF
THE PROJECT. Normal practice, used in this course, places the Total Float in the centre
box along the bottom row of a node.
FREE FLOAT is the amount of delay an activity can absorb before it delays the START of
the NEXT ACTIVITY. Free Float has no standard position in the node BUT, as it represents
a factor between adjacent nodes we will place it there. Again in the example above Activity
B shows that it can be delayed by up to 2 units of time before it affects its successor activity.
Similarly, Activity D can be delayed by 10 units of time before it affects Activity G. (NB in this
case Free Float and Total Float for Activity D are the same).
Page 37

The CRITICAL PATH is the path joining nodes of ZERO TOTAL FLOAT. In the example
above it is A-E-F-G.
3.2.4 Gantt Charts: Scheduling

If we ignore potential resource conflicts then we can move swiftly from the Network to the
Schedule. Clearly the CRITICAL PATH is immovable. We may choose to force non-critical
activities always to default to the earliest dates in the plans.
Figure 3.2.7 Gantt Chart
Day
9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25
Activity
A
B
C
D
E
F
G
3.2.5 Software Tools

There are many project management software tools. They allow data to be input against
projects by tasks. Assuming that sufficient information is available the user can see distinct
(and tailorable) views, including:
Gantt View
Network
Calendar
Resource (Person by Person usage, database of personnel, rates, groupings etc.)
Usage (Total resource commitment by day).
3.2.6 Advantages and Disadvantages of Software Tools

Advantages
Allow for consistent input techniques and provide tailorable standard outputs
Can accommodate large-scale projects and multiple (linked) projects
Facilitate what if? scenarios
Allow filtering for multiple viewpoints and purposes (reports)
Allow maintenance of an agreed baseline
Provide simple configuration management of plans
Can separate plan from actual
Can accommodate
input tables
Gantt charts
resource tables
networks.
Page 38

Disadvantages
There is no single panacea. Some are designed to help with simple and single projects.
Others with multiple complex projects. The former often have a friendly interface whilst
the latter are specialist tools for the experienced user only
We can be seduced by technology
GIGO or garbage in: garbage out.
Appropriateness. Simple projects do not NEED complex tools.
Customer and supplier may have differing toolsets
The PMP must address communications between interested parties
We must ensure common agreement on data definitions.
3.2.7 Milestone Planning

A milestone is merely an event (normally of management significance) which tells the Project
Management Team that there should be significant and measurable progress. Milestones
are often associated with decision points. Figure 3.2.8 shows a milestone chart.
Figure 3.2.8 Milestone Chart
Forecast/Actual Weeks
0
12
16
20
24
28
32
36
40
44
48
52
56
60
64
68
72
76
80
0
1
Key
2
3
Date Milestone
Forecasted this
period/Actual
Date
4
5
Forecast Date
for Milestone
Completion
6
7
Monitoring
Period
8
Original
Milestone
Forecast Date
9
10
11
Completion Line
12
13
14
15
16
17
18
19
20
A milestone chart is formed by plotting plan time across the top of the chart and real time
down the side as monitoring periods. In the example above the monitoring periods occur
every 4 weeks. By plotting the monitoring period against plan time the completion line is
created. This represents time in the project. The milestones are scheduled at the top of the
chart and each monitoring period the date for the milestone is plotted. The points in the
future are shown with a different symbol. The resulting charts are extremely useful for senior
management as they provide, at a glance, a view of how well the project is progressing.
Page 39

The charts have four basic shapes as shown and discussed below.
Figure 3.2.9 Milestone Chart Interpretation 1
Forec as t/Ac tual W eeks
0
12
16
20
24
28
32
36
40
44
48
52
56
60
64
68
72
76
80
0
1
Key
2
3
4
5
6
7
8
Monitoring
Period
9
10
Completion Line
11
12
13
14
15
16
17
18
19
20
In this project something clearly happened between monitoring periods 3 and 4 to cause a 6week delay in the project perhaps a change was authorised? In any event the situation
came under control again and no further slippage occurred.
0
12
16
20
24
28
32
36
40
44
48
52
56
60
64
68
72
76
80
0
1
Key
2
3
4
5
6
7
8
Monitoring
Period
9
10
11
Completion Line
12
13
14
15
16
17
18
19
20
This chart has been prepared at monitoring period 5 (note the different shapes of the
forecast dates). The chart shows significant slippage on the middle two milestones and yet
the end date remains unchanged. As all milestones ultimately link to the final milestone this
should be challenged as it would seem unlikely that any project could contain that amount of
delay and yet still complete on time.
Page 40

0
12
16
20
24
28
32
36
40
44
48
52
56
60
64
68
72
76
80
0
1
Key
2
3
4
5
6
7
8
Monitoring
Period
9
10
Completion Line
11
12
13
14
15
16
17
18
19
20
This is a classic case of just too late. The milestone has been forecasted as on time until
just before it completes when it slips a month. This is often due to poor reporting from the
teams where the team has reported what the PM wants to hear rather than the actual state
of progress. Action should be taken to encourage the teams to report accurately and
honestly throughout the project.
0
12
16
20
24
28
32
36
40
44
48
52
56
60
64
68
72
76
80
0
1
Key
2
3
4
5
6
7
8
Monitoring
Period
9
10
11
Completion Line
12
13
14
15
16
17
18
19
20
This project is out of control!
Page 41
3.3
Resource Management - BoK Topic 3.3
3.3.1 BoK Definition of Resource Management

Resource management identifies and assigns resources to activities so that the project is
undertaken using appropriate levels of resources and within an acceptable duration.
Resource allocation, smoothing, levelling and scheduling are techniques used to determine
and manage appropriate levels of resources.
3.3.2 Resource Types

There are two basic types of resources used on projects:
Replenishable: when used up, future supplies can be obtained. E.g. money, materials.
Re-usable: When finished with they can be used elsewhere. E.g. staff, accommodation,
infrastructure.
Resources must be brought into the project at the appropriate time to bring the optimum
efficiency. For example, just in time deliveries improve cashflow as goods dont need to be
paid for before they are required, storage space and security do not have to be considered.
On the other hand there is always the risk that they may arrive just too late.
When resources are allocated to tasks they are usually scheduled as soon as possible and
the aggregation of resources is called a resource histogram. This will show the peaks and
troughs in resource demand and it is often advantageous to reduce peaks and fill troughs to
get optimum resource usage. This is known as resource smoothing or resource levelling.
3.3.3 Resource Smoothing

Resource smoothing is used when the time is critical and the end date should not be missed.
In this instance the available float is used to move tasks within their float to obtain the
smoothest histogram. The down side of this is that as the float is used so the risk of not
completing the project on time is increased. However, assuming the resources have the
capability for the work concerned the time taken for team communication is reduced within a
smaller team resulting in lower costs.
Figures 3.3.1 and 3.3.2 below indicate this technique.
Figure 3.3.1 Resource Smoothing before
Day
1
1
2
1
4
2
6
2
8
2
G
B
G
B
G
B
10
11
12
13
14
15
16
17
18
19
10 12 15 18 20 22 24 25 26 27
2 2 3 3 2 2 2 1 1 1
F F
G G G G G H H
B B C C C C C C D D
28
1
29
1
30 31
1
1
Activity A
Activity B
Activity C
Activity D
Activity E
Activity F
Activity G
Activity H
Cumulative Resources
Total Resource/Day
Resource 3
Resource 2
Resource 1
Page 42

Figure 3.3.2 Resource Smoothing after
Day
10
11
12
13
14
15
16
17
18
19
1
1
2
1
4
2
6
2
8
2
10 12 14 16 18 20 22 24 26 27 28 29 30 31
2 2 2 2 2 2 2 2 2 1 1 1 1 1
G
B
G
B
G
B
G
B
Activity A
Activity B
Activity C
Activity D
Activity E
Activity F
Activity G
Activity H
Total Resource/Day
Resource 3
Resource 2
Resource 1
G
B
G
C
G
C
G
C
H
C
H
C
F
C
F
D
3.3.4 Resource Levelling

If, however, the project is resource limited then there may be insufficient resources available
to complete the work as initially planned. In this case resource levelling techniques must be
used. Again this does assume that resources have the capability to undertake all the works.
The tasks are moved to reduce the resources required, but this often results in the end date
moving out in time.
Figures 3.3.3 and 3.3.4 below indicate this technique.
Figure 3.3.3 Resource Levelling before
Day
1
1
2
1
4
2
6
2
8
2
G
B
G
B
G
B
10
11
12
13
14
15
16
17
18
19
Activity A
Activity B
Activity C
Activity D
Activity E
Activity F
Activity G
Activity H
Total Resource/Day
10 12 15 18 21 24 26 27 28 29 30 31 32 33
2 2 3 3 3 3 2 1 1 1 1 1 1 1
F F F F
G G G G G H H
B B C C C C C C D D E E E E
Resource 3
Resource 2
Resource 1
Figure 3.3.4 Resource Levelling after

Day
10
11
12
13
14
15
16
17
18
19
20
1
1
2
1
4
2
6
2
8
2
10
2
12
2
14
2
16
2
18
2
20
2
22
2
24
2
26
2
28
2
29
1
30
1
31
1
32
1
33
1
G
B
G
B
G
B
G
B
G
B
G
C
G
C
G
C
H
C
H
C
F
C
F
D
F
D
Activity A
Activity B
Activity C
Activity D
Activity E
Activity F
Activity G
Activity H
Total Resource/Day
Resource 3
Resource 2
Resource 1
Page 43
3.3.5 Cumulative Resource Curve

By plotting the cumulative utilisation of resources against time an S is produced (shown in
figure 3.3.5 below). This is the basis of earned value calculations and represents planned
costs.
Figure 3.3.5 Cumulative Resource Curve
1
10
11
12
13
14
15
16
17
18
19
32
30
28
24
22
20
18
16
14
12
10
8
6
4
2
0
Total Resource/Day
Resource 3
Resource 2
Resource 1
1
1
2
1
4
2
6
2
8
2
10
2
12
2
G
B
G
B
G
B
G
B
G
B
15
3
F
G
C
18
3
F
G
C
20
2
22
2
24
2
25
1
26
1
27
1
28
1
29
1
30
1
31
1
G
C
H
C
H
C
Page 44
3.4
Budgeting and Cost Management - BoK Topic 3.4
3.4.1 BoK Definition of Budgeting and Cost Management

Budgeting and cost management is the estimating of costs and the setting of an agreed
budget, and the management of actual and forecast costs against that budget.
3.4.2 Cost Management

In the beginning we have a Plan. The plan will allow the Project Manager to group activities
or products into Statements of Work (SOW) or Work Packages. These, in turn, need to be
agreed including the cost and duration of the work. The Project Managers reasoning for
allocation of work will come from a Responsibility Assignment Matrix through an
understanding of the work and the skills of the teams. If the teams are contractors then
there will normally be a formal contract.
The art-cum-science of Estimating is addressed in Topic 4.3. It applies just as much to cost
as to time. It will be shown that accuracy improves as the understanding of the project
increases. Part of this understanding relates to the definition of the deliverables and their
aggregation into Statements of Work i.e. Work Packages.
3.4.3 Elements of Cost

Prime Costs (or Direct Costs relating to Project activity) may include:
Project Management Costs including salaries and expenses for specialists
Project Labour Costs including salaries and expenses of staff working on specialist
deliverables
Material Costs including materials embedded in the deliverables and enabling products
Equipment Costs including design, support and manufacturing and any specific plant for
the project.
These costs are the responsibility of the Project Manager.
Overheads (or Indirect Costs) may include:
Organisation salaries including a share of the pay and facilities for the organisations
Senior Staff and universal staff, such as personnel and overall administration not wholly
attributed to specific projects.
Organisation costs including a share of such factors as rent/rates and non-project training.
These costs may be included in an Overhead Recovery Rate which the organisation will
calculate and pass to Project Managers when overall costs are being assessed for the
project.
Profits may take into account any risks which have been accepted by the project. For
example, in the MODs Landing Platform Dock (Replacement) project (LPD[R]) - replacing
the ageing HMS FEARLESS and INTREPID - the single tender bid from VSEL originally had
a price reduction of 160 million (from an original 1995 bid of 589 million), due to (14
month) negotiations which reduced VSELs risks in terms of design liaison, moderation of
standards (from military to a military/civil mix) and a reduction of profits through a shorter
guarantee and transfer of some systems as Government Furnished Equipment.
It is in all parties interests to ensure that the project affords opportunity for success from all
stakeholders perceptions.
Page 45
3.4.4 Investment Appraisals and Cost - Benefit analysis

If we have a Business Case, Investment Appraisal including Discounted Cash Flow, and
include intangible benefits in addition to the financial hard numbers then we dont forget
about it as soon as the project gets underway.
During the life of the project there will be changes, either through encountering technical
difficulties or budgetary ones. In any event the justification for starting will need to be
checked at intervals for continuing viability.
In much the same way as we have Schedule, Optimistic and Pessimistic estimates in Time
Management, we have the same technique in Cost Management. This is known as Three
Point Estimating, and will be addressed in the RISK area.
Value For Money and Whole Life Cycle Costs
We have already considered that intangible benefits will allow an appraisal of Value for
Money. Many projects have a significantly long operations phase and will incur vast costs
in this period. Hence it is essential for the Project Manager to address the whole life cycle
costs (or full-life costs, or through life costs).
3.4.5 Cost Allocation

Projects exist in a real world of customers and suppliers with Prime Contractors and SubContractors.
If the deliverable(s) from a Statement of Work or Work Package are associated with a Firm
Price then the customer will be isolated from any variance from planned cost. But within
the project environment it will be important to some group(s) on the supply side.
Other costs will be incurred by the customer side, such as provision of personnel or other
resources for, say, trials and acceptance - and customer-side project management.
CHANGE IS INEVITABLE. At many or all levels there will be changes to the project. Any/all
changes will have an impact on one or more of Performance, Time and Cost. Therefore, an
understanding of how we address Change, both functionally and contractually is essential
(and should be documented in the PMP).
3.4.6 Cost Control by Budget

Primary Cost Control can be achieved through concepts such as Earned Value, but all
project managers must ensure that payments are not made unless the deliverables have
been accepted.
Page 46
3.5
Change Control - BoK Topic 3.5
3.5.1 BoK Definition of Change Control

Change control is the process that ensures that all changes made to a projects baselined
scope, time, cost and quality objectives or agreed benefits are identified, evaluated,
approved, rejected or deferred.
3.5.2 Formal Control of Changes

Changes to specification or scope can potentially ruin any project unless they are carefully
controlled. But, change is inevitable - whether it be to specifications, business need or
Business Case. The control of change requires assessment of the impact of potential
changes, their importance, their cost, and an informed decision by management on whether
to include them or not. Any approved changes must be reflected in any necessary
corresponding change to schedule and budget.
Customer-based changes may emanate from increasing awareness of business need,
market changes, intelligence of competitor performance, new technical opportunities or
emergent problems.
3.5.3 What is a Change?

Change can be defined as external or internal. External changes relate to changes to the
project deliverables, requested, and paid for, by the client. The initial proposal for change
may be identified by a member of the project team who identifies where a change may be
beneficial to the final configuration of the product.
Internal change is confined to the internal work of the project, often not requiring consultation
with the client, because the change does not change the final deliverable. For example, it
may be required to correct mistakes in the design, or make improvements to designs
previously thought completed.
Funded:
The customer requests and pays for the change. These changes often disrupt the flow of
the work and result in increased contractors costs. This is an opportunity for the contractor
to re-negotiate the overall contract prices and possibly increase the profits. These are
normally documented as Contract Variation Orders or Project Variations
Unfunded:
Changes introduced by the contractor. The contractor will have to pay for the change and
any waste, effort, schedule amendments etc. For these reasons the contractor is usually
wary of introducing this type of change.
3.5.4 Change Control Process

The Project Manager must address the Change Control Process (and include it in the PMP).
A sample change control process is given in Figure 3.5.1 below:
Page 47

Figure 3.5.1 A Change Control Process
Identify need
for change
Submit to
Change
Authority
Raise
Request
PM Analyses
Change
Authority
Review
Change
Authority
Decide
Communicate
Decision
There must be a balance between the advantage achieved by incorporating the change and
the time, cost and risk of implementing it.
Questions which should be asked about the change request include:
Is it possible?
Is it customer requested, or self inflicted?
If not customer requested, is it really necessary?
What is the cost?
Who will pay?
How will progress be affected?
What are the risks?
What is the effect on the Business Case?
How will safety, reliability and performance be affected?
Will it affect work completed?
What documentation needs to change?
Should (and can) the change wait until after the current project ends?
The Change Control system must also be in the PMP. All potential changes must be treated
fairly and consistently. The effect of the initial Change Request may not really be a change
or it may be a valid change to the specification of requirements, or a suggestion to improve
one or more of the projects products.
Fairness and consistency is achieved by ensuring that the input is logged into the Change
Control system.
The person who submitted the request will have declared their own interpretation of
importance. The result of the impact analysis may prioritise changes.
One coding structure might be:
Page 48

Essential: the final product will not work without this change
Important: its absence would be very inconvenient, although a work-around is possible for
a while
Nice-to-have: not vital
Cosmetic: of no functional importance
Not a Change.
The Change Control system would also have to record the Change Authoritys decision for
Change Requests. These may be:
Authorise change as requested
Limited approval
Refer back for clarification or alternative solution
Reject with reasons.
As we have asked the question, What would have to change? our system should be able to
review all requests pertaining to the What once it has been agreed to change it. Thus, nice
to have and cosmetic changes may be achieved as beneficiaries of Essentials or
Importants.
3.5.5 Funding Change

Contingency. The APM define Contingency as The planned allotment of time and cost or
other resources for unforeseeable risks within a project. Something held in reserve for the
unknown. It is not appropriate to use the contingency fund for funding change requests.
Changes should be funded from a separate change budget which may be included within
the contact as a Provisional or Prime Cost sum.
In some cases the proposer of the change may provide the funding. In all events there
should be a business justification for spending money and altering the agreed project.
3.5.6 Uncontrolled Change

Uncontrolled change tends towards anarchy whilst the project scale and scope could expand
exponentially. Success, therefore although eagerly anticipated by all those who have
proposed meaningful change ever recedes into the distance.
Change Control is not about saying NO! But there will be impacts on Time, Cost, Morale,
Quality and Safety - even if we have control. Without control we have not analysed the
impact, are unaware of risks.
Apart from the adage If/when we fail we can always do it again (not recommended) we
may find:
A loss of project status (and team morale)
Invalid work
Exponential increase in errors/re-work
Disappointment of the sponsor
Alarm from the user
Financial loss all round
Page 49

Litigation
A culture of failure.
3.5.7 Change Forms

However change is viewed within a project there needs to be an audit trail available. This is
achieved by the use of a change log and change request forms.
The change request form will vary from industry to industry and project to project and may
be known as a Variation to Contract, a Request for Architects Instruction, Engineering
Request Form or Change Request Form. The request should contain the following elements
as a minimum:
Date raised
Author
Priority
Description of change
Impact of change
Reason for change
Date required
Source of funds
This information should be kept in the log, which would contain the following information,
again as a minimum:
Change number
Date raised
Description of change
Impact analysis
Reason for change
Priority following analysis
Decision
Date implemented
Funding source
Page 50
3.6
Earned Value Management - BoK Topic 3.6
3.6.1 BoK Definition of Earned Value Management

Earned value management (EVM) is a project control process based on a structured
approach to planning, cost collection and performance measurement. It facilitates the
integration of project scope, time and cost objectives and the establishment of a baseline
plan for performance measurement.
3.6.2 Status Reporting

There is a need in all projects to report their status and forecast future performance. One
method of providing this information is to use Earned Value. This is a cost based model to
compare three elements:
Compare
Known as
Acronym
what I planned to do
Planned costs
PC
what I did
Earned value
EV
what I paid
Actual Costs
AC
3.6.3 Earned Value Analysis

Earned value analysis is the process of comparing these three basic values (above) with the
budget for the project and the planned project duration to form a view of when the project will
complete and how much it will cost. Not only is it used on a project basis but also it can be
used on a subset of the projects activities to monitor their progress and as a result help to
define the controlling action that may be required.
As an example, take the project shown below in figure 3.6.1.
Figure 3.6.1 Earned Value Example Project
At the e nd of W e e
Activity
A
B
C
D
E
F
G
Tota l
Pre de ce ssor
A
A
C
A
E
F
Dura tion
(Da ys)
5
10
15
10
25
5
5
Me n /
Da y
1
2
2
2
1
3
2
Budge t
(Dura tion*
Me n/Da y)
5
20
30
20
25
15
10
125
The network derived from this table is shown in figure 3.6.2 below.
Page 51

Figure 3.6.2 Network
0
5
A
0
30
5
15
5
5
10
B
25
15
15
C
10
20
20
30
30
25
E
0
30
30
30
30
40
10
D
10
30
40
0
40
END
40
0
40
5
F
0
35
35
35
35
40
5
G
0
40
40
This gives a Gantt chart and resource histogram as shown in figure 3.6.3 below.
Figure 3.6.3 Gantt Chart and Histogram
1
1
A
B
C
D
E
F
G
2
1
3
1
4
1
5
1
10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40
2
2
2
2
2
2
2
2
2
2
2
2
2
2
2
2
2
2
2
2
2
1
2
1
2
1
2
1
2
1
2
1
2
1
2
1
2
1
2
1
3
3
2
Cumulative
Man Days
1
1
2
1
3
1
4
1
5
1
5
4
3
2
1
And the resulting Planned Costs curve is given in figure 3.6.4.

Figure 3.6.4 Planned Costs
Project` "S" Curve
140
120
Cumulative M an Days
100
80
60
40
20
0
1
10 15 20 25 30 35 40 45 50 55 58 61 64 67 70 73 76 79 82 85 88 91 94 97 100 103 106 109 112 115 117 119 121 123 125
5 5 5 5 5 5 5 5 5 5 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 2 2 2 2 2
9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40
Day
Page 52

After 4 week s the reported progress on the project is given by the table below in figure 3.6.5
Figure 3.6.5 Project after 4 weeks
At the end of Week 4
Activity
A
B
C
D
E
F
G
Duration
(Days)
5
10
15
10
25
5
5
Men /
Day
1
2
2
2
1
3
2
Budget
(Duration*
%
Men/Day) Complete
5
100
20
100
30
90
20
25
30
15
10
Total
125
Actual
Costs
(Man
Days)
6
21
30
15
72
3.6.4 Earned Value

The Earned Value for the tasks is derived by the following formula:
EV = %complete x Budget for the task
This results in EV for each task, as shown in figure 3.6.6
Figure 3.6.6 Earned Value
Activity
A
B
C
D
E
F
G
Dura tion
(Da ys)
5
10
15
10
25
5
5
Tota l
Me n /
Da y
1
2
2
2
1
3
2
At the e nd of W e e k 4
Actua l
Ea rne d
Costs
Va lue
Budge t
(Dura tion*
(Ma n
(%C *
%
Me n/Da y) Com ple te
Da ys)
Budge t)
5
100
6
5
20
100
21
20
30
90
30
27
20
25
30
15
7.5
15
10
125
72
59.5
The total figure for the project is given by totalling the EV for each task.
It can be seen that the project has spent 72 man days, has an Earned Value of 59.5 man
days and from the Planned Costs curve above, at day 20, has a planned cost of 70 man
days.
What does this mean?
Comparing Earned Value with Actual Costs we can see that we have spent more than we
budgeted, to achieve the value we have earned, so we are going to be over budget.
Page 53

Comparing Earned Value with Planned Costs we can see that we have not earned as much
as we should have by now so we are going to be late.
Both of these deductions assume that things will carry on as they are, which of course may
not be the case.
3.6.5 CPI and Efficiency

It is possible to work out a Cost Performance Index which compares Earned Value with
Actual Costs. If this is greater than 1 then it means that the project will come in under
budget i.e. good value for money, whereas a CPI less than 1 would indicate that the project
will be over budget i.e. not such good value for money.
CPI is calculated by the following formula:
CPI = Earned Value/Actual Costs.
If this is expressed as a percentage it is known as the Efficiency.
This is shown on a task by task basis in figure 3.6.7 below. By taking the total EV figure and
comparing it with the total AC figure it is possible to calculate the total figure for the project.
Do not add CPIs and average them out.
Figure 3.6.7 CPI & Efficiency (task by task)
A t th e e n d o f W e e k 4
A ctivity
A
B
C
D
E
F
G
D u ra tio n
(D a ys)
5
10
15
10
25
5
5
Men /
Da y
1
2
2
2
1
3
2
T o ta l
Budge t
(D u ra tio n *
M e n /D a y)
5
20
30
20
25
15
10
125
%
C o m p le te
100
100
90
A ctu a l
C o sts
(M a n
D a ys)
6
21
30
Ea rn e d
V a lu e
(%C *
B u d g e t)
5
20
27
CP I
(V a l/A ct)
0.83
0.95
0.90
Efficie n cy
(C P I *
100%)
83%
95%
90%
30
15
7.5
0.50
50%
72
59.5
0.83
83%
3.6.6 SPI
Schedule Performance Index (cost) SPI is a comparison of Earned Value (EV) and Planned
Costs (PC). A figure greater than 1 means that the project will complete earlier than planned
i.e. we are getting our value faster than planned. A figure less than 1 indicates the project
will be late i.e. we are not getting our value fast enough.
SPI (cost) = EV/PC
In our example above the SPI for the project is 59.5/70 = 0.85
3.6.7 Variances
It is possible to calculate two variances cost and schedule. These are used, like the indices
to monitor trends and can be plotted month on month. They are calculated as follows:
CV = EV AC
SV = EV PC
A positive CV indicates that we are getting more value for money and will be under budget
and vice versa.
Page 54

A positive SV indicates we are getting value faster than planned and will finish early and vice
versa.
In our project these are calculated as follows:
CV = 59.5 72 = -12.5 man days
This indicates that we have paid 12.5 man days more than we budgeted for the value we
have earned.
SV = 59.5 70 = -10.5 man days
This indicates that, to date, we have earned 10.5 man days worth of work less than we
planned.
3.6.8 Out-turn Cost and Duration

The out-turn costs and duration for the project can be derived as follows:
Final Cost = Budgeted Cost/CPI
Final Project Duration = Planned Duration/SPI (cost)
In our project these are:
Final Cost = 125/0.83 = 151 man days
Final Project Duration = 40/0.85 = 47 days
3.6.9 Percentage Complete

Percentage complete is given by the following:
%C = (EV/BAC) * 100%
In our project this is:
%C = (59.5/125) * 100% = 47.6%
3.6.10 Curves
It is usual to plot PC, EV and AC on the same graph and to extrapolate the curves for EV
and AC to estimate final cost and project duration.
This is shown in figure 3.6.8.
The EV curve is extrapolated until it meets the Budget Curve when the project will be
complete i.e. have 100% of its value.
A line is dropped vertically to the x-axis (time) and this represents the end time of the project.
The AC curve is then extrapolated to meet the vertical line and this intersection reflected on
the y-axis (cost) will show the out-turn cost of the project.
The S curves can be developed for standard tasks and these used as the basis for future
projects and associated estimating. Additionally, the standard curves may be factored to
take into account the skills of the labour force.
Page 55

Figure 3.6.8 Curves
Approx
47 days
Final Cost = 151 md
Budgeted Cost = 125 md
Actual Costs = 72 md
Planned Costs = 70 md
Earned Value = 59.5 md
Now = 4 weeks
Planned Project Duration = 40 days
3.6.11 Words of Caution

Carefully code work to prevent erroneous reporting of overheads
Work packages will be coded via the CBS. It is important that these packages are clearly
defined to avoid staff booking overhead time to work packages as productive work. Codes
must be available for non-productive work if Earned Value Analysis is to be useful.
Compare apples with apples
Take care when comparing progress on different tasks using EV to ensure that the tasks are
similar in nature and content
Exclude ongoing management activities for a truer picture
Ongoing management activities should be assigned as overhead when using EV to prevent
distortion of the overall picture.
Do not compare one team against another
Take care when making predictions on future progress if different teams are being used.
One team may be much more efficient than another. Similarly, one task may prove
especially difficult and may significantly skew the figures. These tasks may be best
excluded from the analysis in terms of predicting the future.
Aggregation of S curves may give a false picture
Aggregating S curves for different aspects of the project and using these to predict end
dates and costs may give a false picture as discussed above, under comparison of one team
to another.
Re-estimate tasks with particularly poor performance prior to producing forecasts
The reasons given for poor performance on tasks need to be fully understood. Whatever the
reason, take corrective action, assign the work to date as complete and produce a new
schedule (and Planned Costs) for the remaining work. This will give a much more accurate
picture of events.
Page 56
3.7
Information Management and Reporting - BoK Topic 3.7
3.7.1 BoK Definition of Information Management and Reporting

Information management is the collection, storage, dissemination, archiving and appropriate
destruction of project information. Information reporting takes information and presents it in
an appropriate format that includes the formal communication of project information to
stakeholders.
3.7.2 Project Communication

Communication is vital to:
Ensure everyone knows what they are supposed to be doing
Increase the commitment of team members
Encourage interest in the project
Enable team members to identify with their project/programme/organisation etc.
Facilitate change
Avoid costly communication failures
Personal development and growth.
Generally, people only give of their best if they fully understand the decisions that affect
them and the reasoning behind those decisions. Both they and the project will benefit further
if they have a sound understanding of their roles and the benefits both they and the
organisation will accrue as a result of their efforts. Consequently, a major contributor to the
effectiveness of the project environment is the communication system working within it.
However:
Good project communications need to include everyone involved in the project. The
existence of a formal communications policy suggests that management is aware of the
importance of effective communication and its impact upon projects.
3.7.3 Project Reporting

So far, we have demonstrated the need for, and the benefits of effective communication. In
order to be effective, a communications policy must address the more complex (and often
contentious) subject of what to communicate to whom.
A useful starting point is to identify all of the projects stakeholders:
Project Team
Directly influenced groups
Indirectly influenced groups
They each have their own specific communication or reporting requirements
In terms of information, which may be specified under the provisions of relevant
legislation and/or Codes of Practice etc.
In terms of presentation: amount of information; complexity; style; language;
distribution/access; etc.
Within the project environment, there are also the additional reporting requirements brought
about by the various project control mechanisms designed to ensure that the project:
Is producing products which meet the defined Acceptance Criteria
Page 57

Is being carried out to schedule and in accordance with its resources and cost plans
Is managed in a way which identifies, reports and addresses problems
Remains viable (against its business case).
At the level of the project, reporting requirements will be specified in the projects
communications policy or the project plan, which will identify the level of reporting, the
periodicity of time driven reports and the triggers for event driven reporting activities. For
example:
End Stage Assessments (has the stage been successful?) - event driven
Highlight Reports (regular progress reports during a stage) - time driven
Exception Reports (problems encountered/anticipated) - event driven
Project Closure Reports - event driven.
At the task or Work Package level, define any reports required to fulfil contractual
obligations, or needed to provide the Project Manager with the information necessary to
control the work.
The following information is relevant:
Schedule status - the task owner may be required to report the estimated time of
completion for each task.
Cost Status - the task owner should report the actual expenditure and the committed
expenditure to date for each task.
Status of quality progress - the task owner should report any changes that might affect
the form, fit or function of the task deliverables.
Risk exposure system -reporting any changes in the status of any identified threats to the
achievement of tasks, together with any new threats or opportunities.
Exception reporting - defined triggers will require the task owner to report variations to
forecast time and cost and suggest recovery actions.
3.7.4 Document Distribution Systems

A project cannot be managed efficiently and its project team cannot be effective unless the
projects assets are properly managed. The assets of a project include all of the products
that it develops. These include the intellectual property that arises and both the information
needed to manage the project and to inform its various stakeholders.
Proper documentation control requires that configuration control practices are implemented
and applied to reports and other communications media (brochures; mail shots; press
releases etc.). It also requires an effective, auditable, document distribution system. The
controlled issue of project information helps to ensure that everyone is using the correct
version and minimises the risk of co-ordination failures and mistakes.
Page 58
3.8
Issue Management - BoK Topic 3.8
3.8.1 BoK Definition of Issue Management

Issue management is the process by which concerns that threaten the project objectives and
cannot be resolved by the project manager are identified and addressed to remove the
threats they pose.
3.8.2 Terminology
Issue management is essentially straightforward and refers to logging as issues those
matters that the project manager is unable to resolve and, if left unresolved, will cause the
project to fail. As such they require escalation to the project sponsor and/or the steering
group for resolution.
However, the range of definitions that are in common use within projects complicates this
and for our purpose we shall use the definition above.
In PRINCE2TM a Project Issue is a term defined to cover change requests, questions,
problems, concerns and issues, it is important therefore to get the definitions agreed and
communicated to al stakeholders before the project starts.
3.8.3 Issue Management

All issues should be logged and analysed and the resultant analysis escalated to the
appropriate stakeholder(s) for action. As a matter of course this should always include the
project sponsor.
The Issue Log should contain at least the following information:
Unique Identifier
Date raised
Description
Evaluation
Owner
Date of escalation
Resolution
Date of resolution
Status
Date of last review
Comments
A key field above is that of owner the person who is responsible for resolving the issue.
The project manager should review issues on a regular basis and where adequate and
timely resolution is not made then further escalation to the project sponsor must be made.
Page 59
Section Three Executing the Strategy

1,
Why are Product Breakdown Structures developed?
a)
They identify everything the project must create or produce
b)
They identify the resource requirements for the project
c)
They detail the order in which the products must be delivered
d)
They identify the skills required for the creation of the products
2.
Which one of the following characteristics applies to a Project Milestone?
a)
It can be easily exchanged
b)
It has a specified duration
c)
It represents a collection of activities
d)
It represents a well-defined event
3.
Free Float is:
a)
Only defined in activity on node networks
b)
The time by which an activity can be delayed without affecting the next activity
c)
Also known as total float
d)
Only determined by using a computer planning package
4.
How is Schedule Performance Index (SPI) computed?
a)
PC/EV
b)
EV - PC
c)
EV/PC
d)
Planned Duration/EV
5.
Change Control:
a)
Is only applicable to projects with physical deliverables
b)
Must be applied on all projects
c)
Is not cost effective on small projects
d)
Is the responsibility of the Business Sponsor
Page 60

6.
Which 2 Breakdown structures combine to form the Responsibility Assignment
Matrix?
a)
7.
If the Earliest Finish of the final activity of a network is 20 days then what
would the Latest Finish be?
a)
8.
Which resource management technique takes into account the need to
maintain a critical end date?
a)
9.
What 3 elements is Earned Value Management based upon?
a)
b)
c)
10.
An information management system comprises which 5 elements?
a)
b)
c)
d)
e)
Page 61
4 Techniques
4.1
Requirements Management - BoK Topic 4.1
4.1.1 BoK Definition of Requirements Management

Requirements management is the process of capturing, analysing and testing the
documented statement of stakeholder and user wants and needs. Requirements are a
statement of the need that a project has to satisfy, and should be comprehensive, clear, well
structured, traceable and testable.
4.1.2 Requirements Principles

Requirements are the basis for the project they describe what the customer wants and are
used as a platform for the solution and the way in which that solution is provided. If
requirements are not adequately determined and maintained then there will be an excessive
amount of changes necessary and this will inevitably lead to cost and time overruns.
4.1.3 The Process

Initially, the user requirements will be generated during the concept phase. This will
comprise a high level view of the stakeholders wants and will not necessarily describe what
is actually needed. As the project moves into the definition stage and more is known about
the solution the requirements will be revisited and refined to ensure that they are realistic
and that they will be adequately satisfied by the solution.
During implementation the solution will be tested and the requirement will form a basis for
these tests and finally during operations the solution will be seen to satisfy the requirements.
4.1.4 Requirements Management

Essentially this comprises three key elements:
Capture, where they are discovered, structured and documented along with any
relevant acceptance criteria.
Analysis, where they are assessed and prioritised in accordance with the needs of
the business and the projects priorities.
Testing, where the views of different stakeholders need to be considered and the
requirements tested against them to ensure that they are comprehensive and
accurate and if met will satisfy the diverse stakeholder groupings.
4.1.5 Structure
The requirements should be documented and structured such that the value, priority,
timescales and process are clear for each requirement.
Value represents the amount of benefit that will accrue from the requirement and could be
used to assess its priority to the other requirements.
The timescale associated with the requirement should reflect the timescales of the business,
i.e. when must this requirement be satisfied if the business is to meet its strategic aims and
finally the process describes the means by which the requirements will be satisfied, i.e. the
solution or project approach.
Page 62
4.3
Estimating - BoK Topic 4.3
4.3.1 BoK Definition of Estimating

Estimating uses a range of tools and techniques to produce estimates. An estimate is an
approximation of project time and cost targets that is refined throughout the project life cycle.
4.3.2 Methods of Estimating

We have already seen that we can aid understanding and planning by Breakdown
techniques in planning. By inference we may assume that planning estimates gain more
credibility as we understand the decomposed complexity of the whole. But, accuracy also
depends on factors such as haste, understanding, methods and skills.
4.3.3 The Concept Phase

Here we make ball-park estimates, which we expect to have a low confidence factor. They
are often hastily arrived at, based on reasonable understanding and on the estimators
experience rather than any particular method. No definitive accuracy range is appropriate
but a range of 20-50% may be valid. This may be termed SUBJECTIVE estimating.
4.3.4 The Definition Phase

Before we embark on the project there are many features of the project that need to be
explored. We MUST satisfy the business of the viability of the project is with the Business
Case (which looks at COST and TIME). The aim of the Project Manager will be to compare
Costs with Benefits. We have more time and can use this time to compare the subject
project with others with similarities. Each will need a separate estimate. Assuming that we
have some valid comparative data we may improve our estimating confidence to, say, 1020%. This may be termed a COMPARATIVE estimate.
4.3.5 The Implementation Phase

Before funds and resources are committed the business needs a high confidence factor in
the viability of the project and so would be seeking a most accurate set of estimates. A
target of 2-5% may be valid. We may have a level of understanding, based on data
gathered at earlier phases, which can be modelled in some way. The model may be an
empirical formula, it may be a function of a series of variables, or even derived from
sophisticated computing power with Artificial Intelligence. The use of modelling is called
PARAMETRIC estimating.
4.3.6 Three Point Estimating (PERT)

PERT (Program Evaluation and Review Technique) is used to establish a network for the
project based on a weighted estimate. Three estimates for each task are given the lowest,
highest and most likely. Using the formula:
Duration = (lowest + highest + 4 x most likely)/6
This will give an estimate that is weighted toward the most likely but factors in an amount of
uncertainty. This is likely to give a more representative view of the out-turn timescales and
costs of the project. This technique would most likely be undertaken using a software tool.
Page 63
4.7
Configuration Management - BoK Topic 4.7
4.7.1 BoK Definition of Configuration Management

Configuration management comprises the technical and administrative activities concerned
with the creation, maintenance and controlled change of the configuration throughout the
project life cycle.
4.7.2 Functions of Configuration Management

Its so easy to say YES to requests for change. But all change affects performance,
consumes resource, therefore changing costs and impacting time. No organisation can be
fully efficient or effective unless it manages its assets - including its projects. Project assets
have to be managed. These are the deliverables and enabling products. The name for the
combined set of these assets is a configuration. The configuration of the final deliverable of
the project is the sum total of its products.
In the context of project management the purpose of Configuration Management is to:
Identify
Track
Protect the projects products (configuration items).
Configuration Item. A Configuration Item is merely any object brought under configuration
control.
Configuration Management consists of five basic functions:
Planning: deciding what level of Configuration Management will be required by the
project and planning how this level is to be achieved
Identification: specifying and identifying all components of the final product
Control: the ability to agree and freeze configuration items, and then to make changes
only with the agreement of appropriate named authorities
Status Accounting: the recording and reporting of all current and historical data
concerned with each configuration item
Verification: a series of reviews and audits to ensure that there is conformity between
the projects products and the authorised state of configuration items as registered in the
Configuration Management records.
Configuration Management is not optional. If more than one version of a product has been
created, then Configuration Management is being performed. It is just a question of how well
it is being done.
4.7.3 Roles & Responsibilities

The person looking after the Configuration is known as the Configuration Librarian. This
important role is often part of the Project Office function. It is a role which will continue after
the project has been implemented and continue through to the final disposal of the product
after it has been scrapped.
Major tasks for the Configuration Librarian are:
To control the receipt, identification, storage and issue of all project products
To provide information on the status of all products.
Page 64

Additionally, the Configuration Librarian will have a number of other responsibilities
including:
Assist the Project Manager to produce the Configuration Management Plan, part of the
Quality Plan and included within the Project Management Plan
Create libraries and storage areas
Create identification and administration scheme
Assist with the identification of products
Maintain records
Produce reports
Liaise with other Configuration Librarians.
There is a very close link between Change Control and Configuration Management. Usually,
products are baselined after which they can only change after the Change Control Process
has been undertaken. This process is influenced by, and often undertaken by the
Configuration Librarian in the first instance.
Page 65
Section Four Techniques

1.
Configuration Management:
a)
Is mandatory on projects
b)
Is applicable only when projects have tangible products
c)
Is only relevant to programmes never to projects
d)
Is applicable only to project documentation
2.
Which of the following is NOT an estimating method?
a)
Parametric
b)
Weighted index
c)
Analytical (bottom-up)
d)
Comparative
3.
Estimates are most likely to be exceeded if there:
a)
Are uncontrolled changes
b)
Are changes in project personnel
c)
Are no quality assurance functions
d)
Is an unsatisfactory cash flow
4.
Configuration Management is the responsibility of:
a)
The individuals of the team
b)
The Client
c)
The Project Manager
d)
The Operations Manager
5.
What will help in the ultimate acceptance of the project?
a)
Identifying Risks associated with a plan
b)
Agreeing the requirements with the Customer
c)
Establishing tolerance levels
d)
Follow-on Action Recommendations
Page 66

6.
Requirements Management comprises what 3 key elements?
a)
b)
c)
7.
What is the formula used to calculate a PERT estimate?
a)
8.
What are the 5 functions of Configuration Management?
a)
b)
c)
d)
e)
9.
What approach to estimating uses the Work Breakdown Structure as its basis?
a)
10.
Whose wants and needs are captured in Requirements Management?
a)
Page 67
5 Business and Commercial

5.1
Business Case - BoK Topic 5.1
5.1.1 BoK Definition of Business Case

The business case provides justification for undertaking a project, in terms of evaluating the
benefit, cost and risk of alternative options and rationale for the preferred solution. Its
purpose is to obtain management commitment and approval for investment in the project.
The business case is owned by the sponsor.
5.1.2 Business Case

The business case is one of the most important documents to be produced within the
project. It will be part of the Project Management Plan. It documents the justification for the
project stating why the forecast effort and time is worthwhile. Once the project is underway
the business case will be reviewed to ensure that the project remains viable. Typically, this
review will be formalised at regular investment gates. For organisations using PRINCE2
this will be at stage boundaries during the end stage assessment.
The business case will also be reviewed when considering change requests.
A business case should include an outline of the projects objectives, deliverables, time,
cost, technical, safety, quality and other performance requirements, and the major risks and
upside opportunities (benefits).
It may also include information on the competitive impact, resource requirements,
organisational impacts, key performance indicators and critical success factors of the project
and its outcomes.
The business case will be a key input into the benefits review.
The projects sponsor will own the business case and will be responsible for ensuring its
ongoing integrity. The project manager is often required to produce and maintain the
business case, which will be located within the Project Management Plan and kept under
version control (configuration management).
Many projects have at least 2 business cases, one belonging to the customer, the other
belonging to the suppliers and contractors. It is the customers business case that is used to
make decisions on the on going viability of the project. The customers business case is
concerned with value for money whilst those of the Suppliers are concerned with profit.
5.1.3 Typical Contents

Most if not all organisations will have their own standards that describe the content of the
business case. .
Thus the contents may include the following items:
Background and reasons
Goals and objectives
Options
Key deliverables
Scope
Exclusions
Page 68
Stakeholder analysis
Organisation structure
Assumptions
Risks
Issues
Dependencies
Investment appraisal
Benefits and outline realisation plan
Evaluation.
5.1.4 Investment Appraisals and Cost-Benefit Analysis

In order to get started the business will need to satisfy itself that it is progressing down the
right path - even checking that it should be embarking on such an enterprise. This is
normally done through the Business Case, within which we will see an investment appraisal
considering business (not necessarily technical) options in order to justify the project.
There is no point in requesting the business to choose if there is no real choice. All options
(business or technical) must be valid and achievable. As a benchmark it is normal to include
the do nothing option to demonstrate the consequences of doing nothing (rarely
inconsequential).
Although money talks it is not the only factor with voice. It may be necessary to compare
dissimilar factors as part of a value engineering exercise. If so the metrics of capability must
be real (and repeatable).
It is also important to consider the costs of operating the product and any associated
income, as well as the project related costs. This is often referred to as through life
management planning
5.1.5 Business Options

If, as is normal, there are many potential solutions to a business problem, we need to have
means of comparison between options. We can compare technical capabilities and different
methods, possibilities covering different costs and associated benefits, and different periods
of expenditure and income.
5.1.6 Comparison of costs

Payback
This is the simplest form of comparison and purely states when the investment is paid back.
It takes no account of the value of money or ongoing cashflow but is a quick and simple way
of comparing a number of options. It is often used for short-term projects such as seasonal
goods, fashion etc.
But, this may not take into account the costs associated with raising finance. Most project
environments demand a full Investment Appraisal to combine financial costs and benefits
alongside alternative technical capabilities.
DCF and NPV
Discounted Cash Flow (DCF) and Net Present Value (NPV) are the essence of the financial
elements of an Investment Appraisal.
Page 69

This technique takes into account the value of money. Consider, for a moment, a world with
zero inflation. You have decided to invest 20m in a new venture over 5 years. There are
three payment options:
(1) Pay 20m now
(2) Pay 4m per annum for five years
(3) Pay 20m on delivery (in five years).
Your financial intuition should indicate that Option 3 is best for you (and worst for your
supplier). Option 1 is worst for you; and Option 2 falls some way in between.
To make a true comparison (in our inflation-free world) we need to know how much money I
need to invest now to achieve each payment option.
Looking now at Option 3. How much would I have to invest now to have 20m in five years
time (a lot less than 20m)?
Option 2. How much would I need to invest NOW to be able to pay 4m each year?
Option 1 is my baseline because that is 20m now.
It depends on the interest rate. Say its 5%. Then we use Compound Interest to calculate
n
the Discount Factor. The discount factor is 1/(1+r) where r is the discount rate (here
assumed to be 5%) and n is the year (current year is zero).
Year
Discount factor for 5%
0
1
Option 1 M
(Pay Now)
20.00
20.00
Option 2 M
(Instalments)
4.00
4.00
1
0.952
2
0.907
3
0.864
4
0.823
NPV
20.00
4.00
3.81
Option 3 M
(Pay on Delivery)
4.00
3.63
4.00
3.46
4.00
3.29
18.18
20.00
16.45
16.45
So, comparing intuition with our calculations:

(1) The pay now option costs us 20m now.
(2) The instalments option would require us to invest 18.184m NOW in order to meet the
payment schedule.
(3) The pay on delivery option only requires an investment of 17.277m NOW in order to
meet the future payment. OR - the Net Present Value for Option 3 is 17,277m.
We can use this powerful technique to compare options where the development periods and
operations periods are dissimilar.
Options Discussion
Do Nothing. Let us imagine that we have a situation where an existing system will incur
extra costs of maintenance, as its use is extended beyond its original design life. The
system cannot generate any income, as it is not in the current paradigm. If we assume a
discount rate of 10% (reverse compound interest) then we may have a table as shown
below.
Page 70
DO NOTHING (Additional Costs of Maintaining Current System)

0
1
1
0.909
2
0.826
3
0.751
Expenditure
Acquisition
Running
Total
Discounted Total
0.00
0.00
0.00
0.00
0.00
0.00
0.00
0.00
0.00
0.00
0.00
0.00
0.00
-800.00
-800.00
-601.05
Income
Discounted Total
0.00
0.00
0.00
0.00
0.00
0.00
0.00
0.00
DCF @ 10%
4
0.683
5
0.621
Totals
6
0.564
7
0.513
0.00
0.00
0.00
0.00
-900.00 -1,000.00 -1,100.00 -1,500.00
-900.00 -1,000.00 -1,100.00 -1,500.00
-614.71 -620.92 -620.92 -769.74
0.00
0.00
0.00
0.00
0.00
0.00
0.00
-5,300.00
-5,300.00
-3,227.34
0.00
0.00
NPV
0.00
0.00
-3,227.34
We can see that the cost at todays value is 3227.34 compared to the calculated cost of
5300.
The Project Manager should produce more than one viable option for the business. Here we
have chosen two options.
Option A is for a project taking four years with the cashflow being calculated over a seven
year term. Although it replaces the original system it is only marginally more cost effective.
It may however, have significant intangible benefits.
PROJECT A
DCF @ 10%
Totals
0
1
1
0.909
Expenditure
Acquisition
-1,200.00 -1,200.00
Running
0.00
0.00
Total
-1,200.00 -1,200.00
Discounted Total -1,200.00 -1,090.91
Income
Discounted Total
0.00
0.00
2
0.826
3
0.751
4
0.683
5
0.621
6
0.564
7
0.513
-800.00 -800.00 -800.00

0.00
0.00
0.00
0.00 -600.00 1,000.00 -1,000.00 -1,000.00 -1,000.00
-800.00 -1,400.00
200.00 -1,000.00 -1,000.00 -1,000.00
-661.16 -1,051.84
136.60 -620.92 -564.47 -513.16
0.00
0.00
0.00
0.00
0.00
0.00
0.00 1,500.00 2,500.00 3,000.00

0.00
931.38 1,411.18 1,539.47
NPV
-4,800.00
-2,600.00
-7,400.00
-5,565.86
7,000.00
3,882.04
-1,683.82 Option
B is a shorter, simpler, project that takes less time, costs less, and has, on the face of it, a
decreasing annual earning power. But it is significantly better financially, and may have
comparable intangible benefits.
PROJECT B
Totals
0
1
1
0.909
2
0.826
3
0.751
4
0.683
5
0.621
6
0.564
7
0.513
Expenditure
Acquisition
Running
Total
Discounted Total
-1,000.00
0.00
-1,000.00
-1,000.00
-1,500.00
0.00
-1,500.00
-1,363.64
-2,500.00
0.00
-2,500.00
-2,066.12
0.00
-800.00
-800.00
-601.05
0.00
-800.00
-800.00
-546.41
0.00
-800.00
-800.00
-496.74
0.00
-800.00
-800.00
-451.58
0.00
-800.00
-800.00
-410.53
-5,000.00
-4,000.00
-9,000.00
-6,936.06
Income
Discounted Total
0.00
0.00
0.00
0.00
0.00 3,000.00 2,500.00 2,100.00 1,900.00 1,400.00

0.00 2,253.94 1,707.53 1,303.93 1,072.50 718.42
10,900.00
7,056.33
DCF @ 10%
NPV
120.28
Page 71

Internal Rate of Return
This is an extension of DCF and NPV. IRR is the Discount Rate which gives an NPV of
zero. It is calculated by iteration using different rates and the results can be plotted on a
graph as in Figure 5.1.1 (the vertical axis represents the NPV and the horizontal axis
represents the discount rate used):
Figure 5.1.1 Internal Rate of Return
300
200
NPV
100
0
-100
10 12 14 16 18 20 22 24
-200
-300
-400
Discount Rate
This shows the IRR to be approximately 14%. If that is greater than the market rate then the
project will show a profit and is worth undertaking, whilst if the IRR is less than the market
rate then the project will operate at a loss.
Summary
These three methods indicate ways of financially justifying a project, comparing projects or
comparing options for a single project:
Payback Period
DCF and NPV
IRR.
They do not take into account inflation although it is possible to undertake DCF calculations
with different factors to take into account the forecast inflation rate.
Neither do they take account of the technical merit, or otherwise, risks and associated
business benefits. The justification for undertaking the project will be made by considering
all of these items and the weights allocated to each aspect will be dependent on the type of
project and the associated business drivers.
Page 72
5.4
Procurement - BoK Topic 5.4
5.4.1 BoK Definition of Procurement

Procurement is the process by which the resources (goods and services) required by a
project are acquired. It includes development of the procurement strategy, preparation of
contracts, selection and acquisition of suppliers, and management of the contracts.
5.4.2 The Process of Procurement

The basic steps involved in procurement are:
Establish the user's need
Survey the market place
Specify a realistic requirement
Seek tenders for supply
Assess tenders and choose supplier
Accept the goods into service (commissioning)
Support the equipment during use (storage; maintenance; repair; training; etc.)
Decommission and dispose of redundant equipment.
Due to the large sums of money involved, major acquisitions, particularly those that involve
new or emergent technologies, are likely to adopt a phased approach that ensures that
requirements are appropriately defined; procurement (and hence project) related risks are
adequately addressed; and formal approvals are obtained.
5.4.3 Acquisition Strategies

The acquisition of goods and services can be a complex undertaking and can introduce
additional project risks. Consequently, careful attention needs to be given to the selection of
the most appropriate procurement (or acquisition) strategy.
The chosen strategy should identify the scope of the work and provide a schedule of key
dates for each stage of the procurement process. As a result, the strategy needs to be
developed and agreed at an early stage of the project planning process. There is no generic
right solution. However, the PMP and Business Case should specify the optimal solution
once the alternatives have been explored and are understood.
The strategy should be capable of adequately controlling any risks associated with the
particular procurement activity and ensure that procurement actions are timely, within cost
budgets, and deliver value for money.
Options include:
The Five Fundamental Phases defined in the British Standard Guide to Project
Management (BS 6079 : 1996) - Conception; Feasibility; Implementation; Operation &
Termination. This approach seeks to manage risk and uncertainty throughout the
procurement process and is likely to be most appropriate where the initial requirement is
vague or uncertain and significant development activity is likely to be required.
Off the Shelf Buys - Requirement Specification; Market Survey; (Production); In-service &
Disposal. This approach is quicker and will generally expose the project to fewer risks.
The goods or materials will probably already have been proved reliable, and the project
Page 73

can benefit from economies of larger scale production runs. Unfortunately, there may be
difficulties in integrating such equipment into larger systems.
Key Point Specifications - Requirement Specification; Market Survey; Design &
Development; Production; In-service & Disposal. This method assumes that requirements
can be met by adapting existing designs. Over a period of time the extent of the
adaptation required to meet the projects requirements is determined as a result of an
iterative dialogue with potential suppliers. At the end of this process it should be possible
to specify the requirement using only the minimum essential features, the Key (or
Cardinal) points.
Partnering Arrangements where all parties make an investment in the achievement of a
mutually beneficial outcome. The main aim of partnering is for all parties to achieve their
objectives. It is often known as alliancing. Both parties share information and ideas to
improve performance over the contact or range of contacts.
One Comprehensive Contract. This is possibly the simplest form of contact where one
supplier is responsible for everything required by the project. Commonly known as
turnkey, or, design and construct. For the customer the main risk is that the project
depends on the performance of a single supplier. The customer is required to define all
that the supplier has to produce. Unless the work is routine and the risks small then both
parties responsibilities and liabilities should be clearly defined.
Parallel Contracts. This is common in many industries for providing goods and services.
The customer obtains the products from a range of specialist supplier and the customer
communicates directly with the supplier concerned. This is a logical approach if the
requirements are disparate and one specialist has limited capabilities and/or knowledge
in relation to the size and content of the work.
Sub-Contracts. In many contracts it is unlikely that one single supplier, or even smaller
specialists will have the capability to undertake everything that is required. In this
instance the main supplier may sub-contract part of he work to another supplier. It is
normal for the customer to communicate with sub-contractors via the main supplier. It is
usual for the customer to impose limits on the number and type of sub-contracts that can
be implemented.
5.4.4 Contractor Selection

To ensure that a supplier is likely to deliver what is required, a check on the following should
be made: satisfactory previous performance, resources, reputation and interest in further
work. For large, complex, risky or novel projects, formal pre-qualification of interested
suppliers should be carried out.
5.4.5 Pre-Qualification
Pre-qualification should be a systematic and objective process which provides a shortlist of
satisfactory suppliers from a list of potential bidders. The APM1 recommends the following
factors to be considered:
Organisation
Financial
Experience
Management
1 Contract Strategy for Successful Project Management, Association for Project Management (1998)
Page 74

Performance
A measurable, essential minimum standard or benchmark for each factor relevant to the
project should be decided in advance. Potential bidders who do not achieve the benchmark
in every factor should be eliminated before proceeding to comparisons. For comparison
purposes the factors can be weighted according to their importance to the project. Prequalification should be completed before inviting bids/prices to avoid wasting time
considering an attractively priced bid from a bidder unfit to be given the contract.
5.4.6 Formal Competition

The essential elements of a formal competition are:
Invitation to Tender (ITT)
Tenders (offers of contract)
Evaluation
Acceptance.
5.4.7 Contracts
A contract is a legally binding agreement, normally arising as a result of an offer and
unqualified acceptance, but a number of other requirements must be satisfied before an
agreement can be legally binding:
Under English law, there must be consideration (unless the contract is by deed), that is,
an exchange of money, service, or goods etc.
Parties must have an intention to create legal relations
Parties must have the capacity to contract (excludes minors, the mentally incapable, the
drunk and corporations other than those created by royal charter2)
The agreement must comply with any formal legal requirements
The agreement itself must be legal
The agreement must not be rendered void either by some common law or statute or by
some inherent defect.
In general, no particular formality is required for the creation of a valid contract. Contracts
may be oral, written, or a combination of both oral and written forms. Alternatively, they may
be implied from conduct.
5.4.8 Types of Pricing

There are various types of pricing which offer varying degrees of flexibility and risk to both
customer and supplier.
Firm price
No variation on price
Fixed price
2 A corporation incorporated by royal charter has full contractual capacity. However, a statutory corporation (e.g. a local
council) has power to contract with the objective for which it was incorporated. Other contracts are ultra vires and void.
Page 75

Scope for variation is built into the terms of the contract. For example, the price may be
fixed against variations in, for example, the Retail Price Index or a commodity price index
pertinent to the project.
Target price
Any savings or additional liabilities are shared (may be capped)
Maximum price
An upper payment limit is imposed
Cost plus
Cost plus is used for paying contractors for all legitimate and authorised work. It is based on
the customer paying the supplier for all work undertaken and all costs incurred. This can be
on a fixed set of rates and can include a percentage on top for profit. Often known as time
and materials pricing and is often used for emergency works where the total liability is limited
and it is not possible to accurately specify the requirement. The costs incurred should be
regularly reviewed to stop them getting out of hand.
Activity schedules/milestone/planned payment systems
In this arrangement payment is made through a series of lump sums, paid when the supplier
has completed defined stages of the project. In these contracts the supplier has an incentive
to offer a realistic time and cost model and incentive to achieve the programme; the
customer can compare cash flow differences with the bid and the breakdown of the contact
into a series of lump sums makes it easier to predict the cost effects of variations.
Unit rate based
In these contracts payment is based upon e.g. prices or rates per unit of work done, or
pieces erected. It is useful if the precise number of items is uncertain at the time of inviting
bids. It gives greater flexibility to the customer but does increase the risk of the project
exceeding the cost targets.
Special pricing
Some compound method
NAPNOC
No Acceptable Price NO Contract, used in some areas of the public sector when involved
in single source contracting. A price is agreed prior to any formal contract negotiation.
5.4.9 Contract Planning

Clearly contracts should not be entered into lightly. The following APM 3 check list will aid
effective contract planning:
Choose the terms of a contract logically, depending on the nature of the work, its
certainty, its urgency, the motivation of all parties and other factors such as the
relationship between an investment in new plant and systems already in use
Plan how it will end before you start
Anticipate what can go wrong, apply risk management and allocate risks to best stimulate
their control
Be aware of how a contract is created and how it can be discharged
Contract Strategy for Successful Project Management, Association for Project Management (1998)
Page 76

Define the rights and obligations of all parties
Say what you mean
Specify only what you can test
Agree criteria for satisfactory performance
Decide what terms of payment are effective
Choose suppliers of goods or services who will best serve the interests of the project.
5.4.10 Contract Management

Once agreed, a contract must be carefully managed. The following APM4 check list will aid
effective contract management:
A contract should be a means to an end, not a playground for special interests
Establish control of the contract through a single manager who has experience of the
potential conflicts of interest that can arise and the authority to decide how to void
problems
Assess your suppliers managers real power over resources
Study the contract. Note the obligations and rights of all parties
Recognise that objectives and priorities change during most contracts
Control variations and take proper advantage of potential variations
Keep records and notes of reasons for decisions. Use routine headings
Distinguish between legal rights and project interests.
Contract Strategy for Successful Project Management, Association for Project Management (1998)
Page 77
Section Five Business and Commercial
2.
1.
Which of the following is NOT a heading in a projects Business Case?
a)
Benefits
b)
Investment Appraisal
c)
Project Management Team
d)
Options considered
Which of the following would be more associated with the Business Case rather than
the Project Management Plan?
a)
Milestones
b)
Project costs
c)
Document distribution schedule
d)
Reference to standards
3.
An Investment Appraisal provides:
a)
A consistent, structured approach to investment decision making
b)
The timing of significant purchases
c)
The cost of product maintenance
d)
A sound base for creating the Project Management Plan
4.
The pricing method most likely to be used when clearly defined goods are
procured is:
a)
Fixed price
b)
Cost Reimbursement
c)
Maximum price
d)
Target price
5.
Which of the following is part of a Procurement strategy?
a)
Use of Discounted cash flow
b)
Pareto Analysis
c)
Application of an Ansoff matrix
d)
Decision to use Competitive tendering
Page 78

6.
What does the Business Case provide?
a)
7.
What 2 things does an investment appraisal compare?
a)
b)
8.
Which is the most simplistic investment appraisal technique?
a)
9.
Which out of Firm and Fixed pricing is the most rigid?
a)
10.
Who is responsible for writing the Business Case?
a)
Page 79
6 Organisation and Governance

6.1
Project Life Cycles - BoK Topic 6.1
6.1.1 BoK Definition of a Project Life Cycle

Project life cycles consist of a number of distinct phases. All projects follow a life cycle and
life cycles will differ across industries and business sectors. A life cycle allows the project to
be considered as a sequence of phases which provides the structure and approach for
progressively delivering the required outputs.
6.1.2 Why break the project into a life cycle of phases and/or stages?
Projects are established to achieve specified business benefits or objectives. They are
therefore temporary, with defined start and end dates. When the work has been completed,
the project is disbanded. In order to achieve its objectives, projects go though a number of
phases, collectively known as the Project Life Cycle.
In large complex projects, which require the commitment of substantial resources, the
phases should be formally identified and separated. Adopting a phased approach will
facilitate the planning, control and co-ordination necessary to effectively manage such
projects. For small projects, the project phases are usually less formal, however, control and
co-ordination is likely to be more effective where they have been identified within the Project
Management Plan (PMP).
6.1.3 Basic Project Life Cycle and Extended Project Life Cycle
Project Life Cycles can be discussed in terms of Project Life Cycle and Extended (Product)
Life Cycle as shown in the Figure 6.1.1.
Figure 6.1.1 Project and Extended Life Cycles
Extended life-cycle
Project life-cycle
Concept
X
# Definition
X
Implementation
#
X
Business
Case
PMP
Design
Build
Handover
# & closeout
Operations
#
Termination
X Project evaluation review

# Gate review
Post-project review
Benefits realisation review
The Extended Life-cycle is also known as the Product Life-cycle and there is often confusion
between Product, Project and Extended Life-cycle. BS6079-1: 2002 defines the extended
lifecycle as the project whole life-cycle. There are any variations on the theme of project
phases, these reflect the organisation and industry sector concerned. In many organisations
Page 80

phases of the extended life-cycle can be projects in their own right e.g. there may be a
feasibility study which is run as a project.
6.1.4 Concept
Concept is the first phase of the project life-cycle and it is here that the need, problem or
opportunity is confirmed and investigated. The feasibility of the project is assessed and if
found to be acceptable the project proceeds into Definition. The main output of the concept
phase is the Business Case. The business case will continue to be developed during
definition.
6.1.5 Definition
Definition is the second phase of the project life cycle. During this phase he preferred
solution is further evaluated and optimised. Often an iterative process, definition can affect
requirements and the projects scope, time, cost and quality objectives. As part of this phase
the project management plan (PMP) is produced and the resources required during the
implementation phase will be identified.
6.1.6 Implementation
Implementation is the third phase of the project life cycle, during which the project
management plan (PMP) is executed, monitored and controlled. In this phase the design is
finalised and used to build the deliverables.
6.1.7 Handover and closeout

Handover and closeout is the final phase in the project life cycle. During this phase final
project deliverables are handed over to the sponsor and users. Closeout is the process of
finalising all project matters, carrying out final project reviews, archiving project information
and redeploying the team.
6.1.8 Phase Review and Approval and Go/ No-Go Decisions

Phase reviews assess whether the project is worthy of continuation and whether risks are
manageable. They approve the expenditure of resources to continue with the project. The
project must go through this step in order to continue. The phase reviews should have welldefined entry criteria, review objectives and an agenda for each review. In addition to an
agenda, it is useful to define which process outputs are needed to support the review or
should be inspected in preparation for the review.
6.1.9 Stages
Stages is a term often used to define smaller intervals within a phase. For example an
implementation phase may last for 18 months and this could be further sub-divided into 6
stages.
This will give the sponsor and steering group more control of the project and they would be
expected to review the project at the end of each stage and approve the funds for the next
stage. This limits risk, allows further work to be planned with the knowledge of earlier
stages, lessons learned can be incorporated in future work and in extreme cases can allow
the project to be terminated in the event of future estimates becoming unrealistic.
Page 81
6.5
Handover and Closeout - BoK Topic 6.5
6.5.1 BoK Definition of Handover and Closeout

Handover and closeout is the fourth and final phase in the project life cycle. During this
phase final project deliverables are handed over to the sponsor and users. Closeout is the
process of finalising all project matters, carrying out final project reviews, archiving project
information and redeploying the project team.
6.5.2 Managing Handover and Closeout

The link between project closeout and customer satisfaction with the project effort is obvious.
The customers concern at this stage is: are you about to hand me a deliverable that meets
my needs and is operable and maintainable? Ideally everything is under control as projects
close out: specifications satisfied, deadline dates met and budgets on target.
Good, systematic closeouts ensure that:
Loose ends are tied up
The project remains under control to the end
Paperwork is properly done and filed
Records are maintained
Contractual obligations are fulfilled
Customer satisfaction is maximised.
6.5.3 Handover to Client/User/Operations

The outcome of many projects is a working system to be handed over to some organisation
to operate. As the project nears completion the prospective operation and maintenance
managers are likely to take a progressively greater interest and should be encouraged to do
so by the project manager.
In preparation for Handover, several things should be considered:
Preparation of Documentation
Systems
User manuals
Training material
Maintenance documents
Budget reports
Operations and Maintenance
Testing
Involvement of Customers
Support
Customer Training
Developing and Testing Material
Delivering Material
Page 82

Checklist of Work
Review and Ensure Completion
Customer Acceptance Test.
6.5.4 Formally Closing the Project

The project manager needs to obtain from the client a formal acceptance that the contract
has been fulfilled. In order to achieve this, acceptance criteria and project deliverables need
to have been well defined. Informal contracts and loose specifications can make this
extremely difficult.
Acceptance need not necessarily be 100 percent. The client may accept that the project has
been completed, but with reservations. The project team may then deal these with over an
agreed time-scale.
Customers will want to review overall project performance, in particular, performance against
the promises contained in the contract.
Page 83
6.6
Project Reviews - BoK Topic 6.6
6.6.1 BoK Definition of Project Reviews

Project reviews take place throughout the project life cycle to check the likely or actual
achievement of the objectives specified in the project management plan (PMP) and the
benefits detailed in the business case. Additional reviews will take place following handover
and closeout to ensure that the benefits are being realised by the organisation.
6.6.2 Project Evaluation Review

These reviews are additional to the normal monitoring and control points within a project.
They are often undertaken by some form of assurance function and their purpose is to
discover whether, or not, the project is being managed correctly. They should be included in
the project schedule by the project manager and they will use the project management plan
as their base document.
Typically, a project evaluation review will:
Evaluate the use of project management processes
Review the use of the organisations project management method (if one exists) and any
tailoring of that method
Evaluate any lessons learned, their recording and implementation
Raise concerns and advocate/agree corrective actions
Review the likely success of the project
Validate progress against the plan
Consider stakeholder relationships and perceptions
Review the use of risk management.
In other words the project evaluation review will concentrate on how well the project is being
managed.
6.6.3 Gate Reviews

Typically undertaken at the end of a phase a gate review is a point where the senior
management in an organisation assure themselves that the project is worthwhile. It will
concentrate on the viability of the project based on the work to date, the outcome of the
project evaluation reviews and any other relevant organisational standards.
6.6.4 Audits
Normally undertaken by an independent body, internal or external to the organisation an
audit is similar to a project evaluation review. Its objective is to provide (senior)
management with assurance that the project is being managed correctly. Audits can be
undertaken by a project support office should one exist.
6.6.5 Post Project Reviews

These are an operation review of how well the project was managed. It should be concluded
prior to formal closure of the project. It can be considered as the final project evaluation
review, except that it has an historical perspective.
It should focus on how the project performed in terms of cost, schedule adherence and
delivery of specification. Its report should be widely distributed; recipients may include:
Page 84

Project Sponsor
Project Manager
Project Team
Key Stakeholders.
The essential outcome is to make lessons learnt available to all.
6.6.6 Benefits Review

Between three to six months after the project has been closed a formal review should be
undertaken to determine whether the project has met its stated objectives or is on course to
meet them. It is important that the review is considered from the differing viewpoints of the
various stakeholders involved, e.g.:
Project sponsor
Benefiting functions and units
Operational users
Third parties
Customers.
The benefits review will probably be initiated by the project sponsor and should result in
action plans for improvement where necessary and help in the achievement of the benefits if
they have not been realised already.
There may be the need for a series of benefits reviews to collect data showing a trend of
benefits realisation.
Page 85
6.7
Organisation Structure - BoK Topic 6.7
6.7.1 BoK Definition of Organisation Structure

The organisation structure is the organisational environment within which the project takes
place. The organisation structure defines the reporting and decision making hierarchy of an
organisation and how project management operates within it.
6.7.2 Organisational Structures

The three basic kinds of structure are functional, project and matrix. The design of the
structure should take account of cultural and environmental influences and that it may
change as the project evolves through its life cycle. The systems and procedures required to
make an organisation work are an integral element of organisation design, as is a proper
understanding of the different roles of the project sponsor and the project manager.
Organisational structures influence both interpersonal relationships and relationships
between larger groupings of individuals within the workplace. Where a person sits within an
organisation is likely to dictate the level of responsibility that may be incurred by a particular
individual and their authority to make decisions. Authority should be commensurate with
responsibility. Therefore, it is important when defining the project organisation to consider
these relationships and to ensure that the appropriate levels of personnel are chosen. As an
example, the sponsor must be empowered to administer the budget; the project manager
must be empowered to authorise work and to sign off completed items.
Accountability is the summation of both responsibility and authority.
6.7.3 Functional Organisations

The functional form of organisation is considered to be the most traditional of the
organisational structures. It is likely to be based upon a division of responsibilities into
specialist departments or functions, together with their associated vertical management
hierarchy. Projects are normally managed from within one of the functional departments.
The functional form of organisation remains prevalent within the public sector and amongst
large utilities, particularly those that continue to enjoy monopoly status
Functional Organisation Structure
Figure 6.7.1 Functional Organisation Structure
Organisation
Executive
Human Resources
Directorate
Operations
Directorate
Finance
Directorate
Training
Department
Electrical Maintenance
Department
Purchasing
Department
Personnel
Department
Mechanical Maintenance
Department
Accounts
Department
Production
Department
Technical
Support
Features of Functional Organisations

Hierarchical form of management
Functional managers may have project and line management responsibilities
Project and functional managers normally agree targets and define responsibilities
Page 86

The organisation tends to be bureaucratic
There are likely to be well-established lines of communications (tram lines?).
Advantages of Functional Organisations
In theory, a high level of staff flexibility can be achieved. However, the bureaucratic
nature of many such organisations prevents this
The functional departments provide a professional home for technical expertise and
continued professional development
The functional department normally provides a well established career path
In theory, a functional department can react faster to problems within its functional remit.
Disadvantages of Functional Organisations
Within a functional department the client is less likely to be the primary focus of attention
The client may fall between departments
Responsibilities may be difficult to define when projects are undertaken across
departments. Consequently, there is significant scope for co-ordination failures
Departmental priorities may conflict with project priorities
Departmental work may take precedence over project work
Extended lines of communication between individuals working in different departments
(Chinese Walls and Chinese Whispers syndromes).
6.7.4 Matrix Organisations

The matrix form of organisation is considered by many to be the most natural form of
project organisation. However, there are those who suggest that this form of organisation
does not facilitate project work at all. In theory, a matrix organisation attempts to support
effective project management by formalising the informal links between projects and the
organisations specialist functions. This facilitates communication at the operational level.
Figure 6.7.2 Matrix Organisation Structure
Features of Matrix Organisations

Project managers have project responsibility
Functional managers have functional (line) management responsibilities
Several projects may be provided with resources by the same functional departments
Page 87

Personnel with much sought after specialist skills may be shared with other projects.
Advantages of Matrix Organisations
A single point of responsibility for the project facilitating a rapid response to client needs
Projects can draw on the entire resources of the parent organisation. Resources can be
shared by a number of projects
The arrangement facilitates consistency of approach across projects. Corporate policies,
strategies and procedures apply
The matrix structure can be tailored to the particular needs of the project
The functional departments continue to provide a professional home for technical
expertise and continued professional development
The functional department continues to provide a well established career path.
Disadvantages of Matrix Organisations
Authority and responsibility may become separated.
Sharing resources can lead to conflict between the department and the project; and
between projects.
Responsibilities may be difficult to define when projects are undertaken across
departments. Consequently, there is significant scope for co-ordination failures.
Individual team members have divided loyalties.
Management and technical responsibilities are divided
Functional departments may be reluctant to surrender their best personnel to projects.
6.7.5 Project Organisations

The pure project form of organisation is similar in shape to the functional organisation. It
differs in that it enables projects to operate outside of a formal functional structure. As a
result, resources may be dedicated to one project and the project team may exist as an
Integrated Project Management Team.
Project Organisation Structure
Figure 6.7.3 Project Organisation Structure
Organisation
Executive
Portfolio
Manager(s)
ProjectA
Project B
Project C
Features of Project Organisations

Project managers have overall project and line management responsibilities
There is a dedicated project team and a distinct project identity
Project managers normally agree targets and refine individual responsibilities with the cooperation of their team.
Page 88

Advantages of Project Organisations
Team members report directly to the project manager (who conducts his teams staff
appraisals)
The whole team is customer focused and aware of their responsibilities and their
individual contribution to the successful outcome of the project
A mature self-directed team is normally highly motivated and very task orientated
Responses to customer requests and enquiries can be made quickly and efficiently
because communication channels and processes are well established
Communication within the team is efficient and less bureaucratic in nature
Information can be easily shared between team members.
Disadvantages of Project Organisations
When projects are run concurrently there may be a tendency to duplicate effort
There may be a propensity to stockpile equipment and specialist staff
The project may become isolated from the bigger picture view
A project cannot offer continuity of employment
Lacking significant scope for longer term professional development and promotion
Temporarily unassigned staff may lack direction and feel frustrated
6.7.6 The Organisational Continuum

Figure 6.7.4 Organisational Continuum
Relative authority
Relative project authority
Relative functional authority
PM has no
authority
Functional with
limited project
authority
Equal dual
authority
Matrix
PM has complete
authority
Project with
limited functional
authority
Figure 6.7.4 shows that the more project-oriented an organisation is, the more authority the
project manager has compared to the functional manager.
Even within a single organisation the positioning of the project and its manager on the
continuum may change with some projects being handled within a function with the authority
resting with the functional manager, whilst some strategic and complex projects may have a
dedicated project team with the project manager having complete authority.
Page 89
6.8
Organisational Roles - BoK Topic 6.8
6.8.1 BoK Definition of Organisational Roles

Organisational roles are the roles performed by individuals or groups in a project. Both roles
and responsibilities within projects must be defined to address the transient and unique
nature of projects and to ensure that clear accountabilities can be assigned.
6.8.2 Common Roles and Responsibilities

An organisations structure (Functional, Matrix, Project or variant) is likely to influence the
way it manages its projects. Consequently, project structures will vary from organisation to
organisation.
The following roles are commonplace within many project organisations:
Sponsor
Individual or body for whom the project is undertaken
Is the primary risk taker
Owns the Business Case
Project Manager
Individual given authority and responsibility for the project
Manages achievement of specific objectives
Project Office/Project Administrator
Ranges from simple support function for the project manager to being responsible for
linking corporate strategy to project execution
Project Team Member
Individual, group or organisation responsible to Project Manager
Undertakes project tasks
User
Individual or body
For whom the projects products are created
Stakeholder
Person or group of people
Has a vested interest in, and can affect and/or be affected by the project
Quality Manager
Ensures the project satisfies the needs for which it was undertaken
Resource Manager
Person responsible for provision of resources for the project
Procurement Manager
Acquires goods or services from outside the project area
Page 90
6.9
Methods and Procedures - BoK Topic 6.9
6.9.1 BoK Definition of Methods and Procedures

Methods and procedures detail the standard practices to be used for managing projects
throughout a life cycle. Methods provide a consistent framework within which project
management is performed. Procedures cover individual aspects of project management
practice and form an integral part of a method.
6.9.2 Purpose of a Method

The purpose of a structured method for project management delivery within an organisation
is to provide:
A common language
Common forms
Structure
Rigour
Disciplined processes
Repeatability
6.9.3 Method Content

Many organisations have their own methodology tailored to suit their project environment,
e.g. Symantec have a methodology written to support their IT development life-cycle.
Most, if not all, methods are based around a beginning, middle and end type of approach.
Typically, the beginning covers the start-up and initiation of the project during which the
business case and the PMP are developed. The PMP is known by many different names
such as Project Initiation Document (PID), Project Definition Document (PDD), Project
Scoping Document (PSD) and so forth. In any event it covers the areas defined by the PMP.
In the middle the method covers the allocation of work, monitoring (sending and receiving
information) and control (taking action), and change control. Normally, the middle is split
into a number of phases or stages to enable greater control. At the end of each stage there
is normally reference back to the project sponsor and/or steering group for authorisation to
proceed to the next stage. At this point the ongoing viability of the project is confirmed.
Finally, the end covers the handover and acceptance of the deliverables or products) to
both the customer and the support groups, reflection on the way in which the project was
managed (post project review) and preparation for the benefits review.
Many organisations either use PRINCE2TM as written or have used PRINCE2TM as a basis
for developing their own method.
The key to successful use of a method is tailoring. One size does not fit all in project
management. Each project is different and the method must be tailored to suit. Some
projects are small and can be managed informally with only key decisions being
documented, whilst others are very complex and require much rigour, discipline and
formality if they are not to run out of control. The trick is to get the balance between too
formal and too informal correct.
Page 91
6.9.4 Advantages of Structured Methods

Personnel across all projects in an organisation use the same names for the same roles,
reviews, documents etc. so there is no need to learn a new language when personnel move
from one project to another.
The method will have been created from years of experience and will represent best
practice.
There is no need to reinvent the wheel, e.g. standard forms exist, so time and cost are not
wasted.
The parent organisation can compare the justification of project proposals and the
performance of projects thanks to standard documentation and reporting.
6.9.5 Potential Disadvantages of Structured Methods

The method can be implemented with too much rigour and instead of being a means to and
end the method becomes an end in itself.
Personnel do not understand the language of the method.
Senior management do not understand their responsibilities within the method and the
project.
Terminology varies between methods, which can give rise to confusion.
Staff are not adequately trained in the method and its use.
The method falls into disuse due to the problems above.
Page 92
6.10 Governance of a Project - BoK Topic 6.10

6.10.1 BoK Definition of Governance of a Project
Governance of project management (GoPM) concerns those areas of corporate governance
that are specifically related to project activities. Effective governance of project management
ensures that an organisations project portfolio is aligned to the organisations objectives, is
delivered efficiently and is sustainable.
6.10.2 Overview of Governance

Codes of Conduct covering the way in which an organisation is managed have been defined,
aimed primarily at listed companies. The intention of these is to ensure that shareholders
investments are protected from poor or fraudulent management.
The code is equally applicable to smaller concerns but in a less formal manner. Furthermore
it is essential that projects are equally well governed and a subset of the corporate code is
applicable at the project level.
This covers 4 components:
Portfolio direction
Project sponsorship
Project management effectiveness and efficiency
Disclosure and reporting.
6.10.3 Governance Principles

There are eleven principles of governance which are applicable to projects:
The board has overall responsibility for governance of project management.
The roles, responsibilities and performance criteria for the governance of project
management are clearly defined.
Disciplined governance arrangements, supported by appropriate methods and controls,

are applied throughout the project life cycle.
A coherent and supportive relationship is demonstrated between the overall business

strategy and the project portfolio.
All projects have an approved plan containing authorisation points at which the business
case is reviewed and approved. Decisions made at authorisation points are recorded
and communicated.
Members of delegated authorisation bodies have sufficient representation, competence,

authority and resources to enable them to make appropriate decisions.
The project business case is supported by relevant and realistic information that provides
a reliable basis for making authorisation decisions.
The board or its delegated agents decide when independent scrutiny of projects and
project management systems is required, and implement such scrutiny accordingly.
There are clearly defined criteria for reporting project status and for the escalation of
risks and issues to the levels required by the organisation.
The organisation fosters a culture of improvement and of frank internal disclosure of

project information.
Page 93
Project stakeholders are engaged at a level that is commensurate with their importance
to the organisation and in a manner that fosters trust.
Establishing whether these principles are being applied to each of the four components can
be achieved by undertaking an audit of the four areas using a series of probing questions
(contained on the APM publication Governance of Project Management).
6.10.4 Portfolio direction

This component seeks to ensure that all projects are identified within the one portfolio. This
portfolio should be evaluated and directed mindful of the organisations aims and constraints.
6.10.5 Project sponsorship

This component seeks to ensure that project sponsorship is the effective link between the
organisations senior executive body and the management of the project. The sponsoring
role has decision making, directing and representational accountabilities.
Project sponsors are variously titled, for example Senior Responsible Owner, and may be
located at different levels in organisations. Project sponsors are the route through which
project managers directly report and from which project managers obtain their formal
authority, remit and decisions. Sponsors own the project business case.
Competent project sponsorship is of great benefit to even the best project managers.
6.10.6 Project Management Effectiveness and Efficiency

This component seeks to ensure that the teams responsible for projects are capable of
achieving the objectives that are defined at project approval points. Project team capability is
driven by a number of factors, including the skills and experience of project leaders, the
resources available to them and the tools and processes they are able to deploy. The board
and project sponsors should take these factors into account when assessing the
effectiveness of their project teams and identifying improvement priorities.
Efficient project management requires effective delegation that allows decisions to be made
at a level that is consistent with the organisations system for internal control.
6.10.7 Disclosure and reporting

This component seeks to ensure that the content of project reports will provide timely,
relevant and reliable information that supports the organisations decision making processes,
without fostering a culture of micro-management. It is important for the organisation to
distinguish between key drivers of success and key indicators of success; an effective
reporting process will therefore include measures of both.
An efficient reporting process will minimise the reporting burden throughout the organisation
without compromising effectiveness.
A culture of open and honest disclosure is a key requirement for effective reporting. Where
internal or external pressures pose threats to this, independent verification of information
should be required. Such threats are frequently present prior to major project approvals or
when projects start to encounter serious difficulties. Disclosure should be extended to all
stakeholders to the extent that they have a legitimate interest in project information.
Page 94
Section Six Organisation and Governance

1.
In the APM generic project Life-Cycle Concept, Definition, ...? ... , Handover
and Closeout the missing phase is:
a)
Implementation
b)
Planning
c)
Stakeholder Analysis
d)
Controlling
2.
When is a Benefits Realisation review held?
a)
When a measurement of the achievement of the benefits can be made
b)
Six months after project closure
c)
When the project starts making a return on its investment
d)
When the first problem is encountered in operational use
3.
Which of the following is NOT an organisational form?
a)
Matrix
b)
Project
c)
Triangular
d)
Functional
4.
Which of the following is an example of a method?
a)
BS 6079-1:2000
b)
PRINCE2
c)
ISO 100006:1997
d)
The APM Body of Knowledge
5.
You should not delegate if:
a)
You could do the job better yourself
b)
It would be quicker if you did it yourself
c)
The task has been specifically delegated to you
d)
You particularly like this type of work
Page 95

6.
What type of Review would be held at regular intervals throughout a Phase?
a)
7.
In addition to the 4 Project Life Cycle Phases, the extended Life Cycle contains
2 further phases, what are these?
a)
b)
8.
In addition to the Project Sponsor and Project Manager list 4 roles that may be
involved in a project
a)
b)
c)
d)
9.
What are the 4 components of Governance of Project Management?
a)
b)
c)
d)
10.
In which Phase is the Post-Project Review carried out?
a)
Page 96
7 People and the Profession

7.1
Communication - BoK Topic 7.1
7.1.1 BoK Definition of Communication

Communication is the giving, receiving, processing and interpretation of information.
Information can be conveyed verbally, non-verbally, actively, passively, formally, informally,
consciously or unconsciously.
7.1.2 Forms of Communication

We cannot not communicate (the double negative is intentional). Communication is not
simply about what we say or write, everything we do communicates something to someone.
For example, it is claimed that only 7% of the communication during a conversation is
effected through the words [Birdwhistle (1970)]. The other 93% is the product of the voice
itself (38%) and body language (55%). To an experienced observer even our posture can
communicate our state of well being.
Within a project environment it is often necessary to communicate and gain an appreciation
of complex information, for example: data; diagrams; drawings; and plans. These situations
lend themselves to the use of pictorial representation, which is far more effective than lists,
tables, text or verbal descriptions.
7.1.3 The Communication Process

Effective communication results in mutual understanding. That is, the person who received
the communication interprets it and the actions it implies in the way the sender originally
intended.
The process is summarised below:
Step 1 - the Sender encodes the message
Step 2 - the Sender transmits the message
Step 3 - the Receiver decodes the message
Step 4 - the Receiver encodes feedback
Step 5 - the Receiver transmits feedback
Step 6 - the Sender decodes the feedback (and responds).
Within the project environment, the outcome is co-operation based upon a common
understanding of the objectives or task to be completed.
Unfortunately, communication is not always effective.
7.1.4 Barriers to Communication

Perception barriers
Perception barriers occur because individuals can view the same message in different ways.
Factors influencing perception include the individuals level of education and region of
experience. Problems here can be minimised by using words which have precise meaning.
Personality and interests
Personality and interests, such as the likes and dislikes of individuals, affect
communications. People tend to listen carefully to topics of interest but turn a deaf ear to
unfamiliar or boring topics.
Page 97

Attitudes, emotions and prejudices
Attitudes, emotions and prejudices warp our sense of interpretation. Individuals who are
fearful or have strong love or hate emotions will tend to protect themselves by distorting the
communication process. Strong emotions rob individuals of their ability to comprehend.
7.1.5 Listening and Feedback

Unfortunately, many people listen to respond rather than listen to understand. As a result,
they tend to formulate their response based upon their own viewpoint and dont take the
views being expressed by the speakers into account. Predictably, this leads to
misunderstanding.
When team members feel they are being listened to and understood and that others respect
what they have to say, they are much more likely to reciprocate.
Characteristically, team members who practice active listening:
Pay attention to the whole of the message
Avoid interruptions and dont jump to conclusions
Respect the sender and seek to interpret the message from the perspective of the sender
Check to make sure they are interpreting the message correctly.
Your posture, facial expressions, interruptions and the tone of your voice all provide the
speaker with feedback (you cannot not communicate!). An active listener takes a conscious
decision to understand the speaker and seeks clarification by testing their understanding
while, at the same time, maintaining respect for the speaker. In situations where this is done
well, it helps both parties to achieve a common understanding. When it is done badly, it can
have the opposite effect.
Effective communication skills take time to develop. Effective communicators achieve their
high level of skill by reflecting and learning from both their successes and their disappointing
experiences. They always remember:
The response you get is the meaning of your communication.
7.1.6 The Communications Plan

Within any project it is imperative that the communications needs of the stakeholders are
clearly stated. The form for this statement is the communications plan, which will form part
of the PMP and will be prepared following the stakeholder analysis.
Its content will vary from organisation to organisation but typically will include the following:
Stakeholder list including name, title, postal address, email and telephone number
Stakeholder involvement
Reports/information required
Report/information provider
Format of the communication
Frequency of the communication
It is important that the internal stakeholders (i.e. the project team) are included within this
document.
Page 98
7.2
Teamwork - BoK Topic 7.2
7.2.1 BoK Definition of Teamwork

Teamwork is when people work collaboratively towards a common goal as distinct from
other ways that individuals can work within a group.
7.2.2 Teams
It is highly unlikely that any one individual will have the knowledge and skills required to
undertake all of the activities that are found necessary to successfully complete a modern
project. A team based approach is much more likely to be successful because an effective
team will apply its collective knowledge, skills and experience to the problems in order to
arrive at a more robust solution (the sum is greater than the parts). Consequently, teams
and teamwork are best suited to situations where there is a need to provide insight and
generate commitment and ideas.
Teams are therefore most likely to be effective for:
Identifying potential problems
Identifying possible causes of a problem
Identifying alternative solutions
Evaluating the effects of solutions
Choosing between solutions
Preparing plans and implementing solutions.
Effective teams share a common purpose and are:
Task orientated
Co-ordinated
Mutually supportive
Accountable to each other
Comprised of individuals with complimentary skills.
7.2.3 Building a Team

Teamwork is both an attitude and a set of actions. All the stakeholders gain something from
a co-operative working environment, particularly individual team members, who achieve
significant personal benefit from being part of a team.
The process of team building can be summarised into the following four stages:
Select the right team (Roles? Size? Skills?)
Make it work
Keep it working
Make it better.
Unfortunately, team working does not come naturally to everyone. Building an effective
team is rewarding, but it is a time consuming and sometimes frustrating undertaking. An
effective team is one built upon mutual trust, access to the information and resources
needed to complete the delegated tasks.
Page 99
7.2.4 Tuckmans Team Development Model

A group of people brought together for the first time in order to achieve a defined set of
objectives is unlikely to instantly coalesce into a cohesive working unit. Effective team
working develops over time. During that period a lot of learning and development takes
place and the team collectively goes through a number of developmental phases, referred to
in 1965 by Bruce Tuckman as Forming, Storming, Norming and Performing. Latterly, for
completeness within a project management environment, an Adjourning stage has been
included. These are presented as Figure 7.2.1, together with their main characteristics and
alternative naming conventions.
Stage 1: Forming
This initial stage establishes the foundations upon which the team is constructed or
developed. Typically, team members are unsure of both their individual objectives and the
overall team objectives. They therefore look to each other and the leader for direction and
guidance.
Stage 2: Storming
During this stage team members begin to understand the task, and may perhaps realise that
it is more difficult than they imagined. They are likely to be uncertain about their own
individual objectives and become defensive. If not well managed, competition between team
members may give rise to conflict.
Stage 3: Norming
During this third stage, team members begin to identify with the team and reconcile their
differences. They begin to realise that if the team succeeds they all succeed and if the team
fails they all fail. As a result, competitive relationships become more co-operative and team
members begin to learn from each other.
Stage 4: Performing
At this stage, team members have reconciled most of their differences and communicate
openly within the team. They should now be committed to one another and their objective.
As a result, a lot of work gets done, quickly and efficiently (i.e. the sum is now greater than
the parts).
Stage 5: Adjourning/Mourning
This stage is about learning from experience. Both the organisation and individuals have a
lot to gain from this stage, for example, maintenance of the corporate knowledge base,
updating CVs and Continuous Professional Development (CPD).
Unfortunately, some teams never seem to get past the second stage. Those that do
manage to progress to the fourth (and fifth) stage will, if permitted, tend to become self
directed in nature and consequently require a more hands off management approach.
7.2.5 Selecting the Right Team

A team should ideally include people who have experienced the problem, individuals who
may be involved with the solution and specialists with relevant skills. For example:
Technical experts (e.g. IT, Telecoms, Engineers etc.)
Planners
Contracts staff
Finance staff
Page 100

Quality specialists and auditors
Risk management specialists
Logistics support specialists.
7.2.6 Belbins Team Roles

Unfortunately however, selecting the right people is likely to be more complicated than
simply identifying the required specialists and expecting them to work together as a team.
Everyone tends to have personal preferences about the way they go about their work and
interact with others. Within a team working environment these preferences may be
constructive and enhance the effectiveness of the team. Alternatively, they may be lead to
disharmony and reduce the effectiveness of both the team and the individual(s) concerned
(square pegs in round holes). To be effective, the team must be able to work together as a
cohesive unit.
In the 1970s Meredith Belbin used business games to develop a way of describing the team
roles assumed by individuals working together in a team working environment.
As a result of his work he identified nine distinct team roles. These are summarised in
Figure 7.2.2.
He concluded that successful teams required a balanced mix of roles.
There is no best team role; everyone is different, but everyone has a preferred team role, a
secondary team role; that they assume when working with someone with a greater
preference, and a role (or roles) they should try to avoid.
Figure 7.2.2 Belbins Team Roles
Role
Traits
Plant
Creative, imaginative, unorthodox. Solves difficult problems.
Resource
Investigator
Extrovert, enthusiastic, communicative. Explores opportunities

and develops contacts.
Co-ordinator
Mature, confident, a good chairperson. Clarifies goals,

promotes decision making and delegates well.
Shaper
Challenging, dynamic and thrives on pressure. Has the drive

and courage to overcome obstacles.
Monitor
Evaluator
Sober, strategic and discerning. Sees all the options. Judges

accurately.
Team Worker
Co-operative, mild, perceptive and diplomatic. Listens, builds,

averts friction and calms the waters.
Implementer
Disciplined, reliable, conservative and efficient. Turns ideas

into practical actions.
Completer
Painstaking, conscientious, anxious. Searches out errors and

omissions. Delivers on time.
Specialist
Single-minded, self starting and dedicated. Provides

knowledge and skills in rare supply.
A much more comprehensive description of each role and the function of each within a
team environment are provided in 7.2.7 to 7.2.15.
Page 101
7.2.7 Plants
Characteristics
Plants are innovators and inventors and are likely to be highly creative. They provide the
seeds and ideas which produce major developments. Usually they prefer to operate by
themselves at some distance from the other members of the team, using their imagination
and often working in an unorthodox way. They tend to be introverted and react strongly to
criticism and praise. Their ideas may often be radical and may lack practical constraint.
They are independent, clever and original and may be weak in communicating with other
people on a different wave length.
Function
The main use of a Plant is to generate new proposals and to solve complex problems. Plants
are often needed in the initial stages of a project or when a project is failing to progress.
Plants have usually made their mark as founders of companies or as originators of new
products.
Too many Plants in one organisation, however, may be counter-productive as they tend to
spend their time reinforcing their own ideas and engaging each other in combat.
7.2.8 Resource Investigators

Characteristics
Resource Investigators are often enthusiastic, quick-off-the-mark extroverts. They are good
at communicating with people both inside and outside the company. They are natural
negotiators and are adept at exploring new opportunities and developing contacts. Although
not a great source of original ideas, the Resource Investigator is effective when it comes to
picking up other people's ideas and developing them. As the name suggests, they are
skilled at finding out what is available and what can be done. They usually receive a warm
reception from others because of their own outgoing nature.
Resource Investigators have relaxed personalities with a strong inquisitive sense and a
readiness to see the possibilities in anything new. However, unless they remain stimulated
by others, their enthusiasm rapidly fades.
Function
Resource Investigators are good at exploring and reporting back on ideas, developments or
resources outside the group.
They are the best people to set up external contacts and to carry out any subsequent
negotiations.
They have an ability to think on their feet and to probe others for information.
7.2.9 Co-ordinators
Characteristics
The distinguishing feature of Co-ordinators is their ability to cause others to work towards
shared goals. Mature, trusting and confident, they delegate readily. In interpersonal
relations they are quick to spot individual talents and to use them in the pursuit of group
objectives. While Co-ordinators are not necessarily the cleverest members of a team, they
have a broad and worldly outlook and generally command respect.
Function
Page 102

Co-ordinators are well placed when put in charge of a team of people with diverse skills and
personal characteristics. They perform better in dealing with colleagues of near or equal rank
than in directing junior subordinates. Their motto might well be consultation with control
and they usually believe in tackling problems calmly. In some firms Co-ordinators are
inclined to clash with Shapers due to their contrasting management styles.
Co-ordinators are referred to as Chairmen in Management Teams.
7.2.10 Shapers
Characteristics
Shapers are highly motivated people with a lot of nervous energy and a great need for
achievement. Usually they are aggressive extroverts and possess strong drive. Shapers like
to challenge others and their concern is to win. They like to lead and to push others into
action. If obstacles arise, they will find a way round. Headstrong and assertive, they tend to
show strong emotional response to any form of disappointment or frustration.
Shapers are single-minded and argumentative and may lack interpersonal understanding.
The Shaper role is the most competitive team role.
Function
Shapers generally make good managers because they generate action and thrive under
pressure. They are excellent at sparking life into a team and are very useful in groups where
political complications are apt to slow things down; Shapers are inclined to rise above
problems of this kind and forge ahead regardless. They are well suited to making necessary
changes and do not mind taking unpopular decisions. As the name implies, they try to
impose some shape or pattern on group discussion or activities. They are probably the most
effective members of a team in guaranteeing positive action.
7.2.11 Monitor Evaluators

Characteristics
Monitor Evaluators are serious-minded, prudent individuals with a built-in immunity to being
over-enthusiastic. They are slow in making decisions preferring to think things over. Usually
they have a high critical thinking ability. They have a capacity for shrewd judgements that
take all factors into account. A good Monitor Evaluator is seldom wrong.
Function
Monitor Evaluators are best suited to analysing problems and evaluating ideas and
suggestions. They are very good at weighing up the pros and cons of options. To many
outsiders a Monitor Evaluator may appear as dry, boring or even over critical. Some people
are surprised that they become managers. Nevertheless, many Monitor Evaluators occupy
strategic posts and thrive in high-level appointments. In some jobs success or failure hinges
on a relatively small number of crunch decisions. This is ideal territory for a Monitor
Evaluator; for the man who is never wrong is the one who scores in the end.
7.2.12 Team Workers

Characteristics
Team Workers are the most supportive members of a team. They are mild, sociable and
concerned about others. They have a great capacity for flexibility and adapting to different
situations and people. Team Workers are perceptive and diplomatic. They are good
listeners and are generally popular members of a group. They operate with sensitivity at
work, but they may be indecisive in crunch situations.
Page 103

Function
The role of the Team Worker is to prevent interpersonal problems arising within a team and
thus allow all team members to contribute effectively. Not liking friction, they will go to great
lengths to avoid it. It is not uncommon for Team Workers to become senior managers
especially if line managers are dominated by Shapers. This creates a climate in which the
diplomatic and perceptive skills of a TW become real assets, especially under a managerial
regime where conflicts are liable to arise or to be artificially suppressed. TW managers are
seen as a threat to no one and therefore the most accepted and favoured people to serve
under. Team Workers have a lubricating effect on teams. Morale is better and people seem
to co-operate better when they are around.
7.2.13 Implementers
Characteristics
Implementers have practical common sense and a good deal of self-control and discipline.
They favour hard work and tackle problems in a systematic fashion. On a wider front the
Implementer is typically a person whose loyalty and interest lie with the Company and who is
less concerned with the pursuit of self-interest. However, Implementers may lack
spontaneity and show signs of rigidity.
Function
Implementers are useful to an organisation because of their reliability and capacity for
application. They succeed because they are efficient and because they have a sense of
what is feasible and relevant. It is said that many executives only do the jobs they wish to do
and neglect those tasks which they find distasteful. By contrast, an Implementer will do what
needs to be done. Good Implementers often progress to high management positions by
virtue of good organisational skills and competency in tackling necessary tasks.
7.2.14 Completer - Finishers

Characteristics
Completer-Finishers have a great capacity for follow through and attention to detail. They
are unlikely to start anything that they cannot finish. They are motivated by internal anxiety,
yet outwardly they may appear unruffled. Typically, they are introverted and require little in
the way of external stimulus or incentive. Completer-Finishers can be intolerant of those with
a casual disposition. They are not often keen on delegating; preferring to tackle all tasks
themselves.
Function
Completer-Finishers are invaluable where tasks demand close concentration and a high
degree of accuracy. They foster a sense of urgency within a team and are good at meeting
schedules. In management they excel by the high standards to which they aspire, and by
their concern for precision, attention to detail and follow-through.
7.2.15 Specialists
Characteristics
Specialists are dedicated individuals who pride themselves on acquiring technical skills and
specialised knowledge. Their priorities centre on maintaining professional standards and on
furthering and defending their own field. While they show great pride in their own subject,
they usually lack interest in other peoples. Eventually, the Specialist becomes the expert by
sheer commitment along a narrow front. There are few people who have either the singlemindedness or the aptitude to become a first-class Specialist.
Page 104

Function
Specialists have an indispensable part to play in some teams, for they provide the rare skill
upon which the firms service or product is based. As managers, they command support
because they know more about their subject than anyone else and can usually be called
upon to make decisions based on in-depth experience.
7.2.16 Strengths & Weaknesses

Unfortunately, in the real world, few Project Managers are given the luxury of choosing their
ideal team. Project Managers often inherit teams, and those charged with the task of
establishing a team from scratch are likely to be constrained by the parent organisations
personnel policies and, perhaps, organisational politics.
Despite this, an understanding of team roles and personal preferences does benefit the
Project Manager. It can lead to more effective allocation of tasks and it provides him or her
with a common language that helps when discussing individual performances in a team
working environment, and may support the identification of personal development needs.
7.2.17 Team Size

The appropriate team size depends on a number of factors:
How many people are required to do the work necessary to complete the project
The number of technical disciplines required by the various project undertakings
The manageable (or containable) level of conflict within the team.
There is no ideal team size. Teams that grow too much tend to subdivide around
charismatic characters or influencers. It is suggested, consistent with Belbin, that a team
size of between five or ten people is appropriate. There are nine team roles and we all have
a primary and secondary preference, suggesting a team size of between five and nine.
Page 105
7.3
Leadership - BoK Topic 7.3
7.3.1 BoK Definition of Leadership

Leadership is the ability to establish vision and direction, to influence and align others
towards a common purpose, and to empower and inspire people to achieve project success.
It enables the project to proceed in an environment of change and uncertainty.
7.3.2 Leadership
Unfortunately, there is no simple recipe for effective leadership. Despite the best efforts of
the many researchers who have studied the subject domain, leadership remains an
intangible quality with no clear definition. This is illustrated by Figure 7.3.1, which lists the 11
most popular leadership expectations identified by a sample of senior managers:
Figure 7.3.1 Leadership Expectations
Leadership Expectations
Honest
Broad minded
Competent
Courageous
Forward looking
Straightforward
Inspiring
Imaginative
Intelligent
Dependable
Fair
[Best Practice Magazine (1994)]
Each expectation, by itself, is an admirable quality in a leader; together they represent an

almost impossible ideal. Most people will have experienced good leaders who do not have
all of these characteristics; some may have experienced a poor leader that does.
Consequently, Leadership is often thought of as being a combination of learned techniques
and personal traits.
7.3.3 Hersey and Blanchards Situational Leadership Theory

A situational leadership theory helpful to managers in diagnosing the demands of their
situation has been developed as a result of extensive research. This theory is based on the
amount of direction (task behaviour) and the amount of socio-emotional support (relationship
behaviour) a leader must provide given the situation and the level of maturity of the follower
or group.
Task Behaviour and Relationship Behaviour
The recognition of task and relationship as two critical dimensions of a leaders behaviour
has been an important part of management research over the last several decades. These
two dimensions have been labelled various things ranging from autocratic and democratic,
to employee-oriented and production-oriented.For some time, it was believed that task and
relationship were either/or styles of leadership and, therefore, could be shown as a
continuum, moving from very authoritarian leader behaviour (task) at one end to very
democratic leader behaviour (relationship) at the other.
In more recent years, the idea that task and relationship were either/or leadership styles has
been dispelled. In particular, extensive leadership studies in Ohio State University
questioned this assumption and proved it wrong.By spending time actually observing the
Page 106

behaviour of leaders in a wide variety of situations, the Ohio State staff found that they could
classify most of the activities of leaders into two distinct and different behaviour categories or
dimensions. They named these two dimensions Initiating Structure (task behaviour) and
Consideration (relationship behaviour). Definition of these two dimensions follows:
Task behaviour is the extent to which a leader engages in one-way communication by
explaining what each follower is to do as well as when, where and how tasks are to be
accomplished. Relationship behaviour is the extent to which a leader engages in two-way
communication by providing socio-emotional support, psychological strokes, and facilitating
behaviours.
In the leadership studies mentioned, the Ohio State staff found that leadership styles tended
to vary considerably. The behaviour of some leaders was characterised mainly by directing
activities for their followers in terms of task accomplishment, while other leaders
concentrated on providing socio-emotional support in terms of personal relationships
between themselves and their followers. Still other leaders had styles characterised by both
task and relationship behaviour. There were even some leaders whose behaviour tended to
provide little task or relationship for their followers. No dominant style appeared. Instead,
various combinations were evident. Thus, it was determined that task and relationship are
not either/or leadership styles.
Since research in the past several decades has clearly supported the contention that there is
no best style of leadership, any of the four basic styles may be effective or ineffective
depending on the situation. Situational Leadership Theory is based upon an interplay
among (1) the amount of direction (task behaviour) a leader gives, (2) the amount of socioemotional support (relationship behaviour) a leader provides, and (3) the maturity level that
followers exhibit on a specific task, function or objective that the leader is attempting to
accomplish through the individual or group (followers).
Level of Maturity
Maturity is defined in Situational Leadership Theory as the capacity to set high but attainable
goals (achievement-motivation), willingness and ability to take responsibility, and education
and/or experience of an individual or group. These variables of maturity should be
considered only in relation to a specific task to be performed. That is to say, an individual or
group is not mature or immature in any total sense; people tend to have varying degrees of
maturity depending on the specific task, function or objective that a leader is attempting to
accomplish through their efforts.
Thus, a sales representative may be very mature in the way he or she approaches calls but
may not demonstrate the same degree of maturity in developing and writing customer
proposals. As a result, it may be quite appropriate for this individuals manager to provide
little direction and help on sales call activities, yet provide a great deal of direction and close
supervision over the individuals proposal writing activity.
The Basic Concept
According to Situational Leadership Theory, as the level of maturity of the follower continues
to increase in terms of accomplishing a specific task, the leader should begin to reduce task
behaviour and increase relationship behaviour. This should be the case until the individual
or group reaches a moderate level of maturity. As the follower begins to move into an above
average level of maturity, it becomes appropriate for the leader to decrease not only task
behaviour but relationship behaviour as well. Now the follower is not only mature in terms of
the performance of the task but also is psychologically mature.
Since the follower can provide his or her own strokes and reinforcement, a great deal of
socio-emotional support from the leader is no longer necessary. People at this maturity level
Page 107

see a reduction of close supervision and an increase in delegation by the leader as a
positive indication of trust and confidence. Thus, Situational Leadership Theory focuses on
the appropriateness of and effectiveness of leadership styles, according to the task relevant
maturity of the follower(s).
Style of leader v Maturity of followers
High
Low Task
High Relationship
(S3)
Relationship behaviour
Providing Supportive Behaviour
Figure 7.3.3 Situational Leadership Model
g
tin
a
ip
rtic
a
P
Se
llin
g
High Task
High Relationship
(S2)
ng
ati
g
le
De
Te
llin
g
Low Task
Low Relationship
(S4)
High Task
Low Relationship
(S1)
High
Low
Task behaviour
Providing Directive Behaviour

M4
M3
M2
M1
Figure 7.3.3 attempts to portray the relationship between task relevant maturity and the
appropriate leadership styles to be used as the follower moves from immaturity to maturity.
As indicated, the leader should keep in mind that the diagram represents two different
phenomena.
The appropriate leadership style (style of leader) for given levels of follower maturity is
portrayed by a curvilinear function in the four leadership quadrants.
The maturity level of the individual or group being supervised (maturity of followers) is
depicted below the leadership model as a continuum ranging from immature to mature.
In referring to the leadership styles in the model, we will use the following shorthand
designations:
high task low relationship referred to as leader behaviour style S1:
high task high relationship as leader behaviour style S2:
high relationship low task behaviour as leader behaviour style S3:
low relationship low task behaviour as style S4.
In terms of follower maturity, it is not simply a question of being mature or immature but a
question of degree.
As can be seen in the diagram, some benchmarks of maturity can be provided for
determining appropriate leadership style by dividing the maturity continuum into four levels of
maturity.
Page 108
low levels of task relevant maturity are referred to as maturity level M1;
low to moderate as maturity level M2;
moderate to high as maturity level M3;
high levels of task relevant as maturity level M4.
Application
What does the bell-shaped curve in the style of leader portion of the model mean? It means
that as the maturity level of ones followers develops along the maturity continuum from
immature to mature, the appropriate style of leadership moves accordingly along the
curvilinear function.
Determining Appropriate Style
To determine what leadership style is appropriate to use in a given situation, one must first
determine the maturity level of the follower in relation to the specific task that the leader is
attempting to accomplish through the followers efforts. Once this maturity level is identified,
the appropriate leadership style can be determined by constructing a right angle (90 degree
angle) from the point on the continuum that identifies the maturity level of the follower to a
point where it intersects on the curvilinear function in the style of leader portion of the model.
The quadrant in which that intersection takes place suggests the appropriate style to be
used by the leader in that situation with a follower of that maturity level.
Thus Situational Leadership Theory contends that in working with people who are low in
maturity (M1) in terms of accomplishing a specific task, a high task/low relationship style
(S1) has the highest probability of success; in dealing with people who are of low to
moderate maturity (M2), a moderate structure and socio-emotional style (S2) appears to be
most appropriate; while in working with people who are of moderate to high maturity in terms
of accomplishing a specific task, a high relationship/low task style (S3) has the highest
probability of success; and finally a low relationship/low task style (S4) has the highest
probability of success in working with people of high task relevant maturity (M4).
High task/low relationship leader behaviour (S1) is referred to as telling because this style is
characterised by one-way communication in which the leader defines the roles of followers
and tells them what, how, when and where to do various tasks.
High task/high relationship leader behaviour (S2) is referred to as selling because with this
style most of the direction is still provided by the leader. He or she also attempts through
two-way communication and socio-emotional support to get the follower(s) psychologically to
buy into decisions that have to be made.
High relationship/low task behaviour (S3) is referred to as participating because with this
style the leader and follower(s) now share in decision making through a two-way
communication and much facilitating behaviour from the leader since the follower(s) have
the ability and knowledge to do the task.
Low relationship/low task behaviour (S4) is labelled delegating because the style involves
letting follower(s) run their own show. The leader delegates since the follower(s) are high in
maturity, both being willing and able to take responsibility for directing their own behaviour.
Modifying Levels of Maturity
In attempting to improve the maturity of followers who have not taken much responsibility in
the past, a leader must be careful not to increase socio-emotional support (relationship
behaviour) too rapidly. If this is done, the followers may view the leader as becoming a soft
touch. Thus the leader must develop followers slowly using a little less task behaviour and
a little more relationship behaviour as followers mature.
Page 109

When an individuals performance is low, one cannot expect drastic changes overnight. For
more desirable behaviour to be obtained, a leader must reward as quickly as possible the
slightest appropriate behaviour exhibited by the individual in the desired direction and
continue this process as the individuals behaviour comes closer and closer to the leaders
expectations of good performance.
This is a behaviour modification concept. For example, if a leader wants to improve the
maturity level of a follower so this follower will assume significantly more responsibility, the
leaders best bet initially is to reduce a little of the direction (task behaviour) by giving the
follower an opportunity to assume some increased responsibility. If this responsibility is well
handled, the leader should reinforce this behaviour with increases in relationship behaviour.
This is a two-step process: first, reduction in direction and, if adequate performance follows,
second, increase in socio-emotional support as reinforcement. This process should continue
until the follower is assuming significant responsibility and performing as an individual of
moderate maturity.
This does not mean that the individuals work will have less direction, but the direction will
now be internally imposed by the follower rather than externally imposed by the leader.
When this process occurs, followers are not only able to provide their own direction for many
of the activities in which they engage, but also begin to be able to provide their own
satisfaction for interpersonal and emotional needs.
At this stage followers are positively reinforced for accomplishments by the leader not
looking over their shoulder and by the leader leaving them more and more on their own. It is
not that there is less mutual trust and friendship (in fact, there is more) but it takes less direct
effort on the leaders part to prove it with mature followers.
Although this theory seems to suggest a basic style for different levels of maturity, it is not
quite that simple. When followers begin to behave less maturely, for whatever reason e.g.
crisis at home, change in work technology, etc. it becomes appropriate and necessary for
leaders to adjust their behaviour backward through the bell-shaped curve to meet the
present maturity level of the follower(s).
For example, take a subordinate who is presently working well without much supervision.
Suppose, suddenly, a family crisis begins to affect this persons performance on the job. In
this situation, it might very well be appropriate for the manager to increase moderately both
direction and support until the subordinate regains composure.
Take another example of a teacher who was highly motivated and competent (M4) and
therefore could be left on his own. Suppose he is promoted to principal. While it may have
been appropriate to leave him alone (S4) as a teacher, now that he is a principal, a task for
which he has little experience, it may be appropriate for his supervisor to change styles by
first providing more socio-emotional support and then increasing the direction and
supervision of his activities (Style 4 to Style 3 to Style 2). This high task-high relationship
style should continue until the person is able to grasp the new responsibilities. At that time,
a movement back from Style 2 through Style 3 to Style 4 would be appropriate. Starting off
using the same leadership style that was successful while he was a teacher may now prove
ineffective because it is inappropriate for the needs of this situation.
In summary, effective leaders must know their staff well enough to meet their ever changing
abilities and demands on them. It should be remembered that over time followers as
individuals and as groups develop their own patterns of behaviour and ways of operating, i.e.
norms, customs, etc. A leader may use a specific style for the work group as a group, that
leader may quite often have to behave differently with individual followers because they are
at different levels of maturity. Whether working with a group or an individual, changes in
Page 110

leadership style from S1 to S2, S3 and S4 must be gradual! It is a result of planned growth
and the creation of mutual trust and respect.
7.3.4 Motivation
Motivation is generally described as the drive within people that leads them to take certain
actions and not take others. From this definition, it could be inferred that motivation is
internal and consequently, it is not really possible to motivate people. As a result, all that a
manager or team leader can do is provide opportunities to release the potential that already
exists within their people.
Here is a list of some motivators with a related management activity (in parentheses), which
is likely to draw on the motivating force within people:
Having a clear objective or goal to work towards (job clarification, appraisals)
Satisfaction from a sense of achievement (agreeing realistic and achievable personal
objectives)
Tackling and solving problems (delegating and training)
A sense of involvement (delegating and communicating)
Recognition of results achieved (appraisal and communications)
The sense of a job well done (appraisal and communications)
Doing new things (clarifying jobs and setting objectives)
Completing tasks (clarifying jobs, setting objectives and appraisal)
Team work and fulfilling your role in a group (clarifying jobs, delegating and
communicating)
A sense of responsibility (clarifying jobs, setting objectives and delegating)
Leading others (delegating).
Historically, a great deal of research has been undertaken by psychologists in an attempt to
answer the question:
Why do people work?

The outcome supports the hypothesis that people have an emotional need for a sense of
security and a sense of recognition and will work so that certain goals can be achieved,
which in turn satisfy those needs.
7.3.5 Maslows Hierarchy of Needs

Maslow expressed this concept in terms of a hierarchy of needs. He identified five levels:
Level 1
- physiological needs for food and shelter
Level 2
- safety needs for security and order
Level 3
- social needs for group identity and relationships
Level 4
- esteem needs for achievement, recognition, challenge and responsibility
Level 5
- self fulfilment needs for individual advancement and growth.
Maslows Hierarchy of Needs is usually presented as in Figure 7.3.4.
Page 111

Figure 7.3.4 Maslows Hierarchy of Needs
Self
Actualisation
Esteem
(respect, power, etc.)
Affiliation
(love, affection, friendship, etc.)
Safety
(job security, pension, health & safety etc.)
Physiological
(food, clothing, shelter, etc.)
This can be adapted for a project situation to give a hierarchy such as that portrayed in
figure 7.3.5.
Figure 7.3.5 Project Hierarchy of needs.
Success
Recognition
of effort
Team building
Processes, procedures,
safety instructions
Site facilities, welfare, offices infrastructure
Page 112
7.3.6 Herzbergs Hygiene-Motivation Theory

The first three levels of Maslows hierarchy are concerned with Extrinsic Factors. That is,
the working environment, not with the content of the work. Herzberg called these hygiene
factors and they have the following attributes:
They are not a potent source of satisfaction
Their absence is the cause of dissatisfaction
Their impact on attitudes is relatively short-lived
They are inflationary.
This is why the carrot and stick approach doesnt work for very long.
Factors predominantly associated with satisfying higher order needs tend to be Intrinsic
Factors, that is, those concerned with the content of the work. They have the effect of
motivating higher performance.
Herzberg called these motivators and they have the following attributes:
Their absence is less likely to cause complaint or dissatisfaction
Their absence causes a lack of satisfaction which leads to apathy and lack of interest and
initiative
Their presence is likely to be highly motivational.
Herzberg suggests the need for a two-pronged approach which:
Removes factors which distract from performance, for example:
discriminatory promotion policies
unfair salary systems
poor working conditions
poor management
Seeks out ways which enable employees to get more recognition, challenge, selffulfilment and satisfaction from their work.
Page 113
7.4
Conflict Management - BoK Topic 7.4
7.4.1 BoK Definition of Conflict Management

Conflict management is the process of identifying and addressing differences that if
unmanaged would affect project objectives. Effective conflict management prevents
differences becoming destructive elements in a project.
7.4.2 The Nature of Conflict

Conflict is a process that begins when one party perceives that another party has negatively
affected or is about to negatively affect something that the first party cares about.
There are a number of themes underlying this definition:
Conflict must be perceived by the parties (whether or not it exists is a perception issue)
There must be an opposition or an incompatibility
There must be an interaction if it is to become an inter-party conflict.
Within a team environment, conflict is likely to occur when members are too closed minded
to compromise, or someone wants to have their own way. This suggests that conflict is
somewhat negative in nature and something to be avoided. However, it should be
remembered that a well managed conflict situation may lead to a positive outcome,
particularly within a problem solving environment.
7.4.3 Sources of Conflict in Projects

The seven most potent sources of conflict in projects are:
Conflict over project priorities
The views of project participants often differ over the sequence of activities and tasks that
should be undertaken to achieve successful project completion. Conflict over priorities may
occur not only between the project team and other support groups but also within the team.
Conflict over administrative procedures
A number of administrative-oriented conflicts may develop over how the project will be
managed, e.g. the definition of the project managers reporting relationships, definition of
responsibilities, interface relationships, operational requirements, plan of execution,
negotiated work agreements with other groups, and procedures for administrative support.
Conflict over technical opinions and performance trade-offs
In technology-oriented projects, disagreements may arise over technical issues,
performance specifications, technical trade-offs, and means to achieve performance.
Conflict over manpower resources
Conflicts may arise around the staffing of the project team with personnel from other
functional areas or from the desire to use another departments personnel for support even
though the personnel remain under the authority of their functional or staff superiors.
Conflict over cost
Frequently, conflict may develop over cost estimates from support areas regarding various
project work packages. For example, the funds allocated by a project manager to a
functional support group might be perceived as insufficient for the support requested.
Page 114

Conflict over schedules
Disagreements may develop around the timing, sequencing, and scheduling of project
related tasks.
Personality conflict
Disagreements may tend to centre on interpersonal differences rather than on technical
issues. Conflicts often are ego-centred.
7.4.4 Conflict and the Project Life Cycle

Thamhain and Wilemon found that the relative intensity of the types of conflict listed above
varied during the life of a project. The most intense sources of conflict at each stage were as
follows (listed in decreasing order of intensity for each stage):
At the project formation
1. Priorities
2. Procedures
3. Schedules
4. Manpower
5. Cost
6. Technical
7. Personality
At the early project phases
1. Priorities
2. Schedules
3. Procedures
4. Technical
5. Manpower
6. Personality
7. Cost
During the main project
1. Schedules
2. Technical
3. Manpower
4. Priorities
5. Procedures
6. Cost
7. Personality
Toward the end of the project
1.
2.
3.
4.
5.
6.
7.
Schedules
Personality
Manpower
Priorities
Cost
Technical
Procedures.
7.4.5 Avoiding Conflict

Effective project managers realise that conflicts are inevitable. Conflict may be reduced if
intensive planning is undertaken prior to the actual launch of the project. Planning can help
the project manager anticipate many potential sources of conflict before they occur. The
Page 115

rankings listed above will be a useful aid to prioritising effort. There will, however, be
situations which defy forecasting.
7.4.6 Dealing with Conflict

There are, of course, both constructive and disruptive methods of dealing with conflict. The
value of conflict in a problem-solving discussion is only likely to be realised if the participants
have the skills necessary to handle the situation. Learning how to disagree productively is
essential to effective problem solving in team working environments.
Within a mature self-directed team, members are likely to take joint responsibility for
resolving conflict between members. Conflict between the team and non-performing
individuals may be similarly resolved. Consequently, in ideal situations, conflict situations
will only involve the leader or others in the organisation if the team finds itself unable to
resolve the problem itself.
Treat conflict like a pilot treats turbulence: expect and anticipate difficulties, problems and
challenges; start looking for solutions.
Use diplomatic confrontation when expressing differences. Always attack the problem not
the person and create an ally, not an opponent.
When there is a problem, dont try to hide it. Acknowledge the team has problems and
differences, but dont belabour them. Try to move quickly from identifying the what and
why and determine how to solve the problem.
Look out for personal agendas. One of the biggest problems faced by many teams arises
when individual, self serving agendas rise above the team agenda. The leader has to strive
to refocus the team while dealing with the problem.
7.4.7 Conflict Management Process

Conflict management can be approached as a step-by-step process as follows:
Diagnose the cause not the symptoms
Consult other team members to determine why the person concerned isnt co-operating or
performing. Reasons may include personal problems, failure to relate to new team members
or boredom.
Discuss the issue
When a problem is identified, involve the person(s) concerned; be clear and honest about
issues and identify supporting evidence.
Either take ownership or obtain commitment from the individual(s) concerned
The problem needs to be owned by the individual(s) best equipped to remedy the problem.
If the cause of the problem is the team, the team leader needs to be prepared to take
ownership.
Agree the behaviour(s) that will change
Ensure that non-performing team members are involved in and commit to resolving the
problem.
Reinforce
Recognise performance improvements and support further improvement planning.
Remove from the team
Page 116

Remember that not everyone is suited to working in a team based working environment.
Non-team workers may have a lot to contribute to the success of the organisation if
managed appropriately.
Exit from the organisation
This should always be a last resort. It is fraught with difficulty for everyone involved.
7.4.8 Conflict Handling Modes

Kenneth Thomas, in the Handbook of Industrial & Organisational Psychology (1975)
suggested that in situations where the concerns of two people appear to be incompatible,
that is in Conflict Situations, a person's behaviour can be interpreted in terms of two basic
dimensions:
The extent to which the individual attempts to satisfy his own concerns
The extent to which the individual attempts to satisfy the other persons concerns.
These two basic dimensions of behaviour can be used to define five basic conflict handling
modes as shown in Figure 7.4.1.
Figure 7.4.1 - Conflict Handling Modes Thomas
Extent of
attempts
to satisfy
own
concerns
Competing
Collaborating
Compromising
Avoiding
Accommodating
Extent of attempts to satisfy others concerns
7.4.9 Conflict Handling Modes Competing

An individual pursues his own concerns at the other person's expense.
This is a power oriented mode in which an individual uses whatever power seems
appropriate to win his or her own position, for example: ability to argue; rank/position;
economic sanctions; etc. Competing might mean "standing up for your rights" or defending
a position which you believe is correct. Alternatively, it may be simply about trying to win.
7.4.10 Conflict Handling Modes Collaborating

Collaborating involves an attempt to work with the other person to find some solution which
fully satisfies the concerns of both individuals. It means digging into an issue to identify the
underlying concerns in order to find an alternative which meets both sets of concerns.
Collaborating might take the form of exploring a disagreement to learn from each other's
insights, concluding to resolve some condition which would otherwise have them competing
for resources, or confronting and trying to find a creative solution to an interpersonal
problem.
7.4.11 Conflict Handling Modes - Compromising

The objective is to find some expedient, mutually acceptable solution which partially satisfies
both parties.
Page 117

Compromising falls on a middle ground between competing and accommodating. It gives up
more than competing but less than accommodating. Likewise, it addresses an issue more
directly than avoiding, but doesn't explore it in as much depth as collaborating. It might
mean splitting the differences, making concessions, or seeking the middle ground .
7.4.12 Conflict Handling Modes Avoiding

The individual does not immediately pursue his or her own concerns or those of the other
person. The individual concerned does not address the conflict.
Avoiding might take the form of diplomatically sidestepping an issue, postponing an issue or
simply withdrawing from a threatening situation.
7.4.13 Conflict Handling Modes Accommodating

When accommodating, an individual neglects his or her own concerns in order to satisfy the
concerns of the other person; there is an element of self-sacrifice in this mode.
Accommodating might take the form of selfless generosity or charity, obeying another
person's order when one would prefer not to, or yielding to another's point of view.
7.4.14 Uses of different styles

Each of us is capable of using all five conflict-handling modes. None of us can be
characterised as having a single, rigid style of dealing with conflict. However, individuals
inevitably use some modes better than others and therefore tend to rely upon their
preferred or more natural modes more heavily than others.
Note that there is no best mode. Each represents a set of useful social skills which may be
more or less useful in particular situations.
As a result, it may be inferred that the effectiveness of a given conflict handling mode
depends upon the requirements of the specific conflict situation and the skill with which the
mode or modes are used.
Competing
When quick, decisive action is vital, for example, during emergencies.
On important issues where unpopular courses of action need implementing, for example,
when cost cutting, enforcing unpopular rules or enforcing discipline.
On issues vital to company welfare when you know you're right.
When a manager is over reliant on this mode, subordinates may learn that it's unwise to
disagree and may give up trying to influence the manager concerned. This is likely to isolate
the manager from valuable sources of information and deny the manager the benefit of his
or her subordinates knowledge and experience.
In addition, subordinates may be afraid to admit ignorance and uncertainty and they are less
likely to ask for information and feedback. As a result, they are less likely to be able to learn.
Managers who are unskilled in the use of this mode or uncomfortable with the idea of using it
may be unaware of the power they have. This may hinder their effectiveness by restricting
their influence. Sometimes concerns for others' feelings or anxieties about the use of power
cause them to vacillate, which may mean postponing the decision and adding to the
suffering and/or resentment of others.
Collaborating
To find an integrative solution when two or more sets of concerns are too important to be
compromised.
Page 118

When the objective is to learn, for example, when an individual wishes to test his or her own
assumptions and understand the views of others.
To merge insights from people with different perspectives on a problem.
To gain commitment by incorporating others concerns into a consensual decision.
To work through hard feelings which have been interfering with an interpersonal relationship.
The exploratory and tentative nature of some collaborative behaviour may make it easy for
others to disregard ones collaborative overtures. Consequently, unscrupulous individuals
may be tempted to take advantage of the trust and openness of those who have a tendency
to overuse this mode.
Individuals who overuse this mode may have a tendency to spend too much time discussing
trivial issues that do not deserve the time and attention lavished upon them. The over-use of
collaboration and consensual decision making sometimes represents a desire to minimise
risk by diffusing responsibility for a decision or by postponing action.
Managers who tend to avoid this mode may find it difficult to see differences as opportunities
for joint gain, miss out on learning opportunities and fail to benefit from the experience of
others when seeking solutions to problems. They may also find that subordinates tend to be
generally uncommitted to their decisions or policies because they feel their concerns are not
being given sufficient consideration.
Compromising
When goals are moderately important but not worth the effort or potential disruption of more
challenging modes.
When two opponents with equal power are strongly committed to mutually exclusive aims.
To achieve temporary settlements to complex issues.
To arrive at expedient solutions under time pressure.
As a backup mode when collaboration or competition fails to be successful.
When overused, the inevitable emphasis on bargaining and trading that is associated with
this mode can create a climate of cynicism. Such a climate might undermine interpersonal
trust and deflect attention away from the merits of the issues being discussed.
Individuals who have a tendency to be over reliant on this mode often concentrate so heavily
upon the practicalities and tactics of a compromise that they sometimes lose sight of the
larger issues such as principles, values, long-term objectives and company welfare etc. As
a result, they may feel that they are too sensitive or embarrassed to be effective in
bargaining situations. They may also find it hard to make concessions. Without this safety
valve, they may have trouble getting gracefully out of mutually destructive arguments, power
struggles, etc.
Avoiding
When an issue is trivial, of only passing importance, or when other more important issues
are pressing.
When an individual perceives they have no chance of satisfying their concerns, for example,
when they have little influence or are frustrated by something which would be very difficult to
change (national politics; government policy, someone's personality, etc.).
When the potential damage of confronting a conflict outweighs the benefits of its resolution.
To let people cool down and reduce tensions to a productive level in order to regain
perspective and composure.
Page 119

When gathering more information outweighs the advantages of an immediate decision.
When others can resolve the conflict more effectively.
When the issue seems tangential or symptomatic of a more basic issue.
People who overuse this mode can sometimes devote a disproportionate amount of energy
to caution and the avoidance of issues and colleagues may have trouble getting their views
and inputs. It may often appear as if people are "Walking on eggshells". As a result,
decisions on important issues may be made by default. It would be much more effective if
the person concerned faced up to the issues and actively sought a satisfactory resolution.
Those who have a low predilection for this mode may find that they have a tendency towards
hurting peoples feelings or stirring up hostilities. They may therefore find that they need to
exercise more discretion in confronting issues or more tact in framing issues in nonthreatening ways (tact is partially the art of avoiding potentially disruptive aspects of an
issue).
In order to avoid becoming overwhelmed by their workload, they may find that they need to
devote more time to setting priorities and deciding which issues are relatively unimportant
and perhaps delegating them to others.
Accommodating
When an individual realises that they are wrong it allows them to hear the other persons
views and learn from others, and to show them they are reasonable.
To build up credits for later issues which are more important.
When continued competition would only damage ones cause, for example, when losing.
When preserving harmony and avoiding disruption are especially important.
To aid in the managerial development of subordinates by allowing them to experiment and
learn from their own mistakes.
Those whose predilection for this mode is too high may feel that their ideas and concerns
are not getting the attention they deserve. Deferring too much to the concerns of others can
deprive them of influence, respect and recognition. It can also deprive their organisation of
their potential.
Managers who are too accommodating may find that discipline may be too lax. Whilst
recognising that discipline for its own sake is likely to be of little value, there are often rules,
procedures and assignments whose implementation is crucial for the success of the team or
the organisation.
An unwillingness to accommodate the views of others can manifest itself in a lack of
goodwill. Individuals who are reluctant to use this mode may be viewed by others as
unreasonable, they are likely to have trouble admitting when they are wrong and often fail to
recognise legitimate exceptions to rules. They dont know when to give up.
Accommodations on minor issues which are important to others are gestures of goodwill.
Page 120
7.5
Negotiation - BoK Topic 7.5
7.5.1 BoK Definition of Negotiation

Negotiation is a search for agreement, seeking acceptance, consensus and alignment of
views. Negotiation in a project can take place on an informal basis throughout the project life
cycle, or on a formal basis such as during procurement, and between signatories to a
contract.
7.5.2 What is Negotiation?

A negotiation should be a forum for the efficient transaction of business where all parties to
the event (i.e. the Negotiating Partners), are able to fulfil their respective undertakings. The
most successful negotiation achieves a mutually acceptable, or win-win outcome, which
leaves all parties to the negotiation sufficiently content with the outcome to continue the
relationship or further strengthen and develop it over time.
7.5.3 The Need for Negotiation in Project Management

Project managers need to negotiate with a number of different parties over a number of
different issues throughout the project life cycle, such as the following:
Issue
Parties with whom Project Manager must Negotiate
Resources
Senior managers, line managers, sponsor, senior

management
Schedules
Team members, sponsor, line manager
Priorities
Senior managers, sponsor, team members, other project

managers, client
Standards /
Quality
Sponsor, project board, assurance team, team members
Procedures
Team members, line managers, sponsors, senior

management
Costs
Specialists, team members, finance, sponsor, senior

management, line management
People
Team members, line managers
7.5.4 Planning for Negotiation

Skilled negotiators, who consistently achieve successful outcomes from their negotiations,
have learned that effective negotiations are the outcome of highly developed negotiating
skills coupled with thorough preparation and care around the negotiating table. Time spent in
preparation is seldom wasted. It enables the negotiator to:
Understand the issue/problem
Study relevant reference/briefing material
Learn about their opponents and try to identify their objectives and potential strategies
(there should be no surprises)
Define his or her teams negotiating strategy
Allocate meeting roles and responsibilities (note taker; observer; subject matter expert;
etc.)
Page 121

Define their own objectives and priorities.
7.5.5 Tradables
During the planning process negotiators need to identify and prioritise their tradables prior
to the negotiation where trading takes place and concessions are made.
Tradables may include any or all of the following:
Price
Technical performance
reliability
mean time before failure
change requests
help lines
after sales support
guarantees
support costs
Trials and testing
who pays?
location?
who provides the facilities/manpower?
what information is going made available to whom?
Delivery schedule
rate of production
transportation costs/packaging
storage.
7.5.6 Structure of Negotiations

The direction of a structured negotiation will be driven by the agenda, normally agreed prior
to the substantive meeting by all of those concerned. The meeting itself is likely to have a
simple structure:
Personal introductions
Each party will set out their respective position
Negotiations will ensue (i.e. Proposing & Counter Proposing)
Agreement will be reached
The meeting will move on to the next item or the meeting will be concluded
Agreements will be summarised, follow up actions agreed and the meeting finalised.
7.5.7 Good Negotiation Practice

During the negotiation phase concessions will inevitably be required. However, dont be
rushed into making concessions simply to fill periods of silence and dont worry about
Page 122

deadlock. It should be remembered that a good negotiator seldom, if ever, concedes
anything without getting something in return and consistently observes good negotiation
practice, that is, he or she will:
Open with high demands
Stick close to his or her demands
Make a few small concessions
Make progressively smaller concessions.
Remember that effective negotiation skills take time to develop and need practice. Expertise
in the technical aspects of the subject matter under discussion is useful, but not sufficient by
itself. Highly developed interpersonal skills are also required by negotiators wishing to
achieve consistently successful outcomes:
Listen carefully to what is said.
Seek clarification and ask questions rather than making statements all of the time.
Ask open questions rather than closed questions which simply require a yes or no
answer.
Do not try to score personal points.
Take care when tempted to take advantage of any division in the opposing team (your
negotiating partners). It may have the effect of unifying them or it may lead to the early
cessation of the negotiation.
Use appropriate language, avoiding the use of jargon and Three Letter Acronyms (TLAs).
Treat everyone with respect and equanimity.
Dont let yourself be rushed into a hasty decision; if it appears you are being forced into
concessions, the best plan is to slow the pace of the meeting.
For your own benefit, it is recommended that you always have someone in your team to
record the key decisions, any follow up actions and note who is responsible to carrying them
out. Put any points of agreement in writing and issue to both sides.
Once the negotiation has concluded, take the time to de-brief your negotiating team and
learn from the experience.
Page 123
Section Seven People and the Profession

1.
Which of the following would NOT contribute to effective teamwork?
a)
Setting and agreeing clear team objectives
b)
Micro-management
c)
Clear and open communication
d)
Ensuring support and trust amongst team members
2.
Which of the following could be thought of as a Hygiene Factor?
a)
Professional achievement
b)
Professional recognition
c)
Responsibility
d)
Nice working conditions
3.
Which of the following would be a principle of an effective leader?
a)
Ability to adapt their leadership style to different situations
b)
Being autocratic/dictatorial
c)
Letting the team lead themselves
d)
Arranging team building sessions
4.
Which of the following is NOT a conflict resolution strategy?
a)
Forcing
b)
Compromise
c)
Problem-solving
d)
Levelling
5.
Which of the following is NOT a step in a typical negotiation process?
a)
Preparation/Planning
b)
Proposing the offer
c)
Contract Management
d)
Agreement
Page 124

6.
What does Maslow say about a satisfied need?
a)
7.
A leader is engaging with a very experienced, confident member of their team.
What sector of the Hersey and Blanchard model are they likely to be in?
a)
8.
What is the final stage of the Tuckman Team Development model?
a)
9.
Which Belbin role type has characteristics such as extrovert; highly
motivated; strongly driven?
a)
10.
What is the first step of a negotiation process?
a)
Page 125
Section Quiz Answers

Section
One
Project Management in Context
From: Benefits Management, Transition Management, Resource

Management, Strategic Change, Consistency of Approach, Management
of Project Interdependencies, Governance
Resource Constraints
Concept
Business Case
10
Benefits Realisation Reviews
Section
Two
Planning the Strategy
6
7
8
9
10
a) Time; b) Cost; c) Quality

Project Manager
a) Initiate; b) Identify; c) Assess; d) Plan Responses; e) Implement
Responses; f0 Manage Process
Fitness for Purpose
Definition
Section
Three
Executing the Strategy
Page 126
Work Breakdown Structure & Organisation Breakdown Structure
20 Days
Smoothing
Cost Collection; Performance Measurement; Structured Planning
10
a) Collection; b) Storage; c) Dissemination; d) Archiving; e) Destruction
Section
Four
Techniques
a) Capture; b) Analyse; c) Test
L + H + (4 x M) divided 6
8
9
10
a) Planning; b) Identification; c) Storage; d) Status Accounting; e)

Verification/Audit
Analytical (Bottom-Up) Estimating
Stakeholder and User
Section
Five
Business & Commercial
Justification for the Project
a) Costs; b) Benefits
Payback Period
Firm (Fixed is inflation proofed, Firm is not)
10
Project Manager in reality although Sponsor may!
Page 127
Section
Six
Organisation and Governance
Project Evaluation Review
7
8
9
10
Section
Seven
a) Operations; b) Termination
From: User Rep; Supplier Rep; Project Office; Team Manager; Team Member;
Programme Manager; Procurement Manager
a) Portfolio Direction; b) Project Sponsorship; c) Project Management
Effectiveness & Efficiency; d) Disclosure & Reporting
Handover & Closeout
People & the Profession
A satisfied need CEASES TO MOTIVATE
S4
Adjourning (Mourning)
Shaper
10
Preparation (Planning)
Page 128

QA APMP Pre-Course Handbook v2.0

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

QA APMP Pre-Course Handbook v2.0

Uploaded by

Copyright:

Available Formats

APMP Certificate in

APMP Pre-course Student Handbook v0.1

Electronic APMP Pre-course Handbook V2.0

Project Management in Context .............................................................. 4

Project Management APM Body of Knowledge (BoK) Topic 1.1 ..... 4

Programme Management - BoK Topic 1.2 ........................................ 7

Portfolio Management - BoK Topic 1.3 .............................................. 9

Project Context - BoK Topic 1.4 ...................................................... 10

Project Sponsorship - BoK Topic 1.5 ............................................... 11

Project Office - BoK Topic 1.6 ......................................................... 12

Planning the Strategy ............................................................................ 15

Project Success and Benefits Management - BoK Topic 2.1 ........... 15

Stakeholder Management - BoK Topic 2.2 ...................................... 18

Project Management Plan - BoK Topic 2.4 ...................................... 19

Project Risk Management - BoK Topic 2.5 ...................................... 21

Project Quality Management - BoK Topic 2.6 .................................. 24

Health, Safety and Environmental Management - BoK Topic 2.7 .... 27

Executing the Strategy .......................................................................... 31

Scope Management - BoK Topic 3.1 ............................................... 31

Scheduling - BoK Topic 3.2 ............................................................. 36

Resource Management - BoK Topic 3.3.......................................... 42

Budgeting and Cost Management - BoK Topic 3.4 .......................... 45

Change Control - BoK Topic 3.5...................................................... 47

Earned Value Management - BoK Topic 3.6 ................................... 51

Information Management and Reporting - BoK Topic 3.7 ................ 57

Issue Management - BoK Topic 3.8 ................................................ 59

Requirements Management - BoK Topic 4.1 ................................... 62

Estimating - BoK Topic 4.3 .............................................................. 63

Configuration Management - BoK Topic 4.7 .................................... 64

Business and Commercial..................................................................... 68

Business Case - BoK Topic 5.1 ....................................................... 68

Procurement - BoK Topic 5.4 .......................................................... 73

Organisation and Governance............................................................... 80

Project Life Cycles - BoK Topic 6.1 ................................................. 80

Handover and Closeout - BoK Topic 6.5 ......................................... 82

Electronic APMP Pre-course Handbook V2.0

Project Reviews - BoK Topic 6.6 ..................................................... 84

Organisation Structure - BoK Topic 6.7 ........................................... 86

Organisational Roles - BoK Topic 6.8.............................................. 90

Methods and Procedures - BoK Topic 6.9 ....................................... 91

Governance of a Project - BoK Topic 6.10 ................................... 93

People and the Profession .................................................................... 97

Communication - BoK Topic 7.1 ...................................................... 97

Teamwork - BoK Topic 7.2 .............................................................. 99

Leadership - BoK Topic 7.3 ........................................................... 106

Conflict Management - BoK Topic 7.4 ........................................... 114

Negotiation - BoK Topic 7.5 .......................................................... 121

Section Two Quiz

Section Three Quiz

Section Four Quiz

Section Five Quiz

Section Six Quiz

Section Seven Quiz

Section Quiz Answers

Electronic APMP Pre-course Handbook V2.0

Electronic APMP Pre-course Handbook V2.0

1 Project Management in Context

Project Management APM Body of Knowledge (BoK) Topic 1.1

1.1.2 BoK Definition of Project Management

1.1.3 Project Management Process

Electronic APMP Pre-course Handbook V2.0

Defining and planning