Planning and Control - Lectures

MSC PROJECT MANAGEMENT :: STUDENT COURSE NOTES (Certificate)
Project Planning and

Control
University of Aberdeen
School of Engineering
Tutors: Mr. Mike Sevenoaks (Campus)

Dr. Robin Henderson (Distance Learning)
Session 2007/2008
UNIVERSITY OF ABERDEEN
MSC PROJECT MANAGEMENT
CONTENTS
1.0
2.0
COURSE INTRODUCTION.................................................................................................................. 4
1.1
COURSE AIMS .................................................................................................................. 4
1.2
THE LEARNING CYCLE ..................................................................................................... 4
1.3
COURSE LOGISTICS .......................................................................................................... 5
1.4
ASSESSMENT .................................................................................................................... 6
1.5
COURSE BOOKS................................................................................................................ 6
SESSION 1:.............................................................................................................................................. 7
2.1
WHAT IS PROJECT MANAGEMENT? ................................................................................... 7
ACTIVITY 2.1................................................................................................................................... 8
2.2.
WHY DO ORGANISATIONS CHOOSE TO DO PROJECTS?....................................................... 8
ACTIVITY 2.2 A................................................................................................................................ 9

ACTIVITY 2.2 B .............................................................................................................................. 11
2.3
PROJECT STAKEHOLDERS ............................................................................................... 11
ACTIVITY 2.3................................................................................................................................. 13
2.4
PROJECT SUCCESS .......................................................................................................... 13
ACTIVITY 2.4................................................................................................................................. 14
2.5
3.0
SUMMARY ...................................................................................................................... 15
SESSION 2 SCOPE DEFINITION AND PROJECT ESTIMATING .............................................. 16

3.1.
INTRODUCTION .............................................................................................................. 16
3.2
PROJECT OBJECTIVES AND SCOPE .................................................................................. 16
3.4.
ESTIMATING ACCURACY ................................................................................................ 19
3.5.
WORK BREAKDOWN STRUCTURES (WBS)..................................................................... 21
3.6.
FROM THE WBS TO THE ESTIMATE ................................................................................ 25

3.6.1
Work Study and Standard Work Norms .......................................... 25
The Steps In Making A Time Study................................................................... 26

STANDARD TIMES ......................................................................................................................... 27
ACTIVITY 3.6.1A ........................................................................................................................... 29
ACTIVITY 3.6.1B WORK NORMS ................................................................................................... 30
3.6.2
The Learning Curve Effect.............................................................. 30
ACTIVITY 3.6.2.............................................................................................................................. 33
3.6.3
CTRs ............................................................................................... 33
ACTIVITY 3.6.3.............................................................................................................................. 33
3.6
3.6.4
Parametric Estimating.................................................................... 36
3.6.5
Completing the estimate.................................................................. 36
CONTRACTUAL AGREEMENTS ........................................................................................ 37

Fixed Price / Lump Sum ................................................................................... 38
PAGE 1
PROJECT MANAGEMENT ESSENTIALS 2
Schedule of Rates / Cost Reimbursable ............................................................ 39

Bills of Quantities............................................................................................. 39
PRICING PROJECTS ........................................................................................................................ 39
3.7
4.0
SUMMARY ...................................................................................................................... 40
SESSION 3 DETAILED PLANNING .............................................................................................. 41

4.1.
INTRODUCTION .............................................................................................................. 41
4.2.
ORIGINS OF NETWORK PLANNING .................................................................................. 41
4.3.
THE NETWORK PLANNING PROCEDURE ......................................................................... 42
ACTIVITY-ON-NODE (AON) NETWORKS ...................................................................................... 67
4.4.
PERT ............................................................................................................................. 68
4.5
SUMMARY ...................................................................................................................... 69
SESSION 4 - PUTTING THE PLAN INTO ACTION...................................................................... 70

5.1.
INTRODUCTION .............................................................................................................. 70
5.2 PROJECT EXECUTION PLANS (PEP) ......................................................................................... 70

5.2.1 Project Definition and Brief .................................................................... 70
5.2.2 Roles and Responsibilities....................................................................... 70
5.2.3 Quality Assurance planning .................................................................... 70
5.2.4 Safety Management ................................................................................. 70
5.2.5 Human Resource Management ............................................................... 71
5.2.6 Communication Management Plan ......................................................... 71
5.2.7 Information and Knowledge management plan....................................... 71
5.2.8 Programme and cost management plan .................................................. 71
5.3 BENEFITS OF PEPS .................................................................................................................. 72
5.4 DOCUMENT CONTROL ............................................................................................................. 73
5.4.1 Ensure Correct Version........................................................................... 73
5.4.2 Ensure Availability of Correct Version .................................................. 73
5.4.3 Authorisation of Changes........................................................................ 74
5.4.4 Audit Trail of Document Changes........................................................... 74
5.4.5 Knowledge Management ......................................................................... 74
5.4.6 Document Control & IT Systems............................................................. 74
5.5 CHOOSING A DOCUMENT CONTROL PROCEDURE ...................................................................... 74
5.6 KEY INFORMATION REQUIRED FOR DOCUMENT REGISTER ...................................................... 75
5.7 CONFIGURATION MANAGEMENT ............................................................................................. 75
6 SESSION 5 PROJECT CONTROL............................................................................................................... 78
6.1.
INTRODUCTION .............................................................................................................. 78
6.2.
MEASUREMENT OF PROGRESS ........................................................................................ 78

6.2.1The use of data capture proformas........................................................... 79
6.2.2 The use of written reporting. ................................................................... 79
6.2.3 Asking the right questions ....................................................................... 79
PAGE 2
PROJECT PLANNING AND CONTROL
6.2.4 Accuracy of reporting.............................................................................. 79

6.2.5 Knowledge capture.................................................................................. 79
6.2.6 Timely capture of data............................................................................. 79
6.2.7 Highlight reports ..................................................................................... 80
6.2.8 Management of reporting........................................................................ 80
6.2.9 Evaluation of progress ............................................................................ 80
6.3 EARNED VALUE ANALYSIS (EVA)............................................................................................ 81
6.3.1Time variance (TV)................................................................................... 83
6.3.2 Accounting Variance (AV)....................................................................... 83
6.3.3 Cost Variance (CV) ................................................................................. 83
6.3.4 Schedule Variance (SV)........................................................................... 84
6.3.5 Earned Value Performance Indicators.................................................... 84
6.4. OTHER PERFORMANCE INDICATORS ....................................................................................... 87
6.5. PROJECT REPORTING .............................................................................................................. 89
6.6 SUMMARY ............................................................................................................................... 90
7 SESSION 6 PROJECT DECISION MAKING ............................................................................................. 91
7.1. INTRODUCTION ....................................................................................................................... 91
ACTIVITY ...................................................................................................................................... 91
7.2. CRASHING THE NETWORK ...................................................................................................... 91
7.3 CAUSAL MAPPING ................................................................................................................... 94
7.4 SCENARIO ANALYSIS ............................................................................................................... 95
7.5 SPECIFIC SUGGESTIONS FOR BRINGING THE PROJECT BACK ON SCHEDULE AND BUDGET.......... 97
7.5.1 Act Early.................................................................................................. 97
7.5.2 Gain Commitment ................................................................................... 98
7.5.3 Assign extra resources. ........................................................................... 98
7.5.4 Make better use of resources................................................................... 99
7.5.5 Job and Knock......................................................................................... 99
7.5.6 No Blame Cultures .................................................................................. 99
7.5.7 Expectation Management ........................................................................ 99
7.5.8 Involving the stakeholders..................................................................... 100
7.5.9 Update The Plans .................................................................................. 100
7.5.10 Monitor the Control Methods.............................................................. 100
7.5.11 Enhance Productivity of Your Resources ............................................ 100
7.6 SUMMARY ............................................................................................................................. 101
APPENDIX FINAL ASSESSMENT............................................................................................................... 102
PAGE 3
1.0
Course Introduction
1.1
Course Aims
Welcome to the Project Planning and Control Module of the University of Aberdeens MSc
programme. This module focuses primarily on the development of project plans and the
use of these plans to control projects. Throughout the module many of the elements which
are introduced will be familiar to those involved in projects but hopefully what the course
materials will do is illuminate the processes involved and also provide a deeper
understanding of what is involved in the development and use of plans.
1.2
The Learning Cycle
In order to facilitate this learning process the intention is to make use of a learning model
called Kolbs learning cycle [1] that is shown below.
Most of you starting this course will have experiences of project management both from the
workplace and from your own personal life. What Kolbs cycle suggests is that you should
reflect on this experience to draw out the good and bad aspects of the experience what
went well and what went wrong. At this stage it is important to focus on not just the task (i.e.
we didnt deliver the project on time) but also the process by which the task was performed
(i.e. the team did not work well together because of problems with the decision making).
PAGE 4
This thinking process may suggest a better way of achieving the goal and hence an
opportunity to improve the way you or your organisation operates. In this situation it is then
important to act, to try out the new method, to test whether or not it gives positive results.
This will provide a further experience on which to reflect and hence continue learning. In
order to facilitate the reflection process, throughout the course notes there are specific
questions which will ask you to reflect on your practise and also on your company. The best
resource you have available to you on this course are each other so posting the outcomes
from these questions on the discussion board should benefit everybody in the class (this is
however not compulsory). In a similar way the assessments will ask you to reflect on
situations which you encounter at work. The aim of this is not only to make the assessments
more specific to each individuals circumstances but also to test not just the knowledge you
gain from the course notes but also the application of this knowledge.
1.3
Course Logistics
The course consists of a number of separate work packages. Each of these work packages
can be found in this booklet. Whilst all material is provided at the start of the programme it is
recommended that you work through them in the following order:
Session 1:
Setting the context
Session 2:
Scope and Estimating
Session 3:
Detailed Planning
Session 4:
Plans to execution
Session 5:
Project control
Session 6:
Project decision making
Each work package will be taught according to the programme calendar which is available
through WebCT. Should you wish to proceed with later work packages before their teaching
dates you can, however tutor support will only be available from the starting date of that work
package.
As you progress through the module you will see many activities highlighted. These are
within the course to help you reflect and internalise the learning you have obtained from the
course notes and it is recommended that you spend sometime doing the exercises.
PAGE 5
1.4
Assessment
This course is solely assessed by continual assessment there is no examination.

Each of the assessments is designed to draw upon your experience and encourage
reflection on the topic of interest.
1.5
Word limits are provided and these should be adhered to (over large
submissions will be penalised).
The dates and the assessments are to be found within the course calendar.
Late submissions, unless previously agreed with the course tutor will be
penalised.
Assessments which are submitted early will not be marked until after the due
date. Assessments which are submitted on time will be returned to you with
feedback within 3 weeks of submission (or at least one week prior to the next
assignment).
Course Books
Details of the course textbooks can be found on the module information page. A brief
outline of each textbook, and its use on the course, is outlined below.
MBA Handbook (Shelia Cameron): Starting an MSc course whilst still in

employment is a challenge, especially if you have not formally studied for a
number of years. This book introduces you to a wide range of skills that will
help you progress through your studies including report writing, time
management and exam skills.
Project Planning and Control (Rory Burke): This is an easy to read book
which explains many areas relating to project management (it covers most of
the material covered in this course) and will also be useful in the next module
on the course (Project Planning and Control)
Handbook of Project Management (Rodney Turner): This text covers a wide

range of project management issues and will not only support your learning
on this module but also in future modules. Whilst not essential to completing
this module it will provide a useful reference book throughout your MSc
studies.
You may already have some other project management books there are certainly enough
available. As you progress through the MSc course you will want to expose yourself to the
thinking of as many writers on the topics covered and therefore making use of any additional
materials you have (as well as resources on the internet) is encouraged.
PAGE 6
2.0
Session 1:
This introductory session aims to:

oEncourage you to think about what constitutes project management in your
organisation
oThink about why organisations undertake projects
oThink about what makes project successful.
2.1
What is project management?
Project management seems commonplace in todays society. You only have to pick up a
copy of a recruitment page of any national newspaper and you will see many jobs requesting
project management experience.
However, what is implied by the phrase project
management varies widely between industries and sectors. For example in some
organisations the delivery of a project by writing a to-do list with dates attached may be
regarded as project management whilst in another organisation Project Managers may be
senior members of staff with a dedicated project team including planners, engineers, IT
specialists, admin support and the project might look like a small company. The latter
scenario represents what can be regarded as professional project management and it will be
the elements relating to this professional approach that will be covered in this module.
Looking within the literature we start to find definitions of project management and projects:
(Project Management is) The application of knowledge, skills, tools and techniques to
project activities in order to meet stakeholders needs and expectations from a project
..the process of integrating everything that needs to be done as the project evolves through
its life cycle in order to meet the project objectives
The two quotations start to put some flesh onto the bones of what project management
entails. The first quote highlights a number of specific elements:
oGantt charts, network diagrams, earned value analysis are some of the tools and
techniques available to the project manager. These tools and techniques deal with the
harder issues relating to project management and are commonly found in most project
management text books.
PAGE 7
oThere is however more to project management than the use of tools and techniques
with the skills and knowledge of the project manager being key to the successful
delivery of the project. These skills and knowledge will include knowing what to do
when something is going wrong with the project, people skills, leadership and being able
to look beyond the details of the project to view the bigger picture.
oStakeholders expectations are also highlighted within this definition. Whilst the
stakeholders are often viewed as the organization delivering the project and the
customer, there are many more stakeholders than these and often the influence of
stakeholders can significantly impact the success of the project. This is especially
important for public sector projects and those that might attract significant media
attention.
So project management encompasses a wide range of elements and all of these must be
dealt with in order to manage the projects effectively.
Activity 2.1
Based upon the discussions above how would you rate your organisation in terms of
its approach to project management? If you had to give it a mark out of 10 what
would it be and how would you go about justifying this assessment.
2.2.
Why do organisations choose to do projects?
Traditional project management focuses on the interface between the contractor and the
customer and how, through successful management of a contract, the contractor can make
a profit whilst ensuring customer satisfaction.
This has traditionally been represented
through the cost-time-quality triangle (sometimes referred to as the iron triangle) that defines
within this framework a successful project.
PAGE 8
COST
TIME
QUALITY
Figure 1: The traditional cost-time-quality triangle of project success.
Therefore the delivery of the project within schedule, within the initial budget and at the
appropriate quality level would define a successful project. However as organisations start
to do more and more of their business through delivering projects (you will often hear
organisations saying that their business is delivering projects), both internal and external to
the organisation, the paradigm, which describes a successful project, is starting to change.
Activity 2.2 a
What would constitute a successful project for your organisation?
Write down some of the objectives that your organisation would be looking for from a
project.
You have probably written down delivery on time, cost and quality as the being the key
objectives for projects. Depending upon which sector and industry you work within you may
have included other success factors. Within the offshore and construction industries safety
is now regarded as a key objective whilst in the public sector delivering service
improvements is often the key objective. In no particular order some of the other objectives
that many organisations are looking for from the delivery of projects include:
PAGE 9
oDevelopment of new products or markets. For example an organisation might take on

a project at a loss-making price if it allows the organisation to develop a new market
where there is growth potential in the future.
oDevelopment of new working relationships with organisations.
This could include
relationships with clients or with suppliers and partners in the project.
oDelivery of increased profit margins for the organisation

oDevelopment of new knowledge within the organisation either through the development
of staff or through the acquisition of knowledge from your client or partner organisations.
oIncreased efficiency in the delivery of future projects.

Whilst there are many objectives and strategies that the organisation may be pursuing the
challenge is to ensure that the project delivers the appropriate elements of the organisations
strategy. Ensuring that this linkage is in place is perhaps more important in large
organisations where the power distance between the managers developing organisational
strategy and the staff working on projects is greater. A common problem is that at the
project initiation phase the project is well aligned with the organisation but as the project
progresses a divergence occurs as illustrated in Figure 2. This could result from a number
of factors including:
oThe organisational strategy changing during the duration of the project?
oThe client shaping the objectives of the project after initial definition resulting in a
change in goals for the project.
Organisational Strategy
Project
Strategy
Organisational Strategy
Project
Strategy
Figure 2: Deviation between project and organisation strategy.
Therefore when going through the definition and project planning stages it is important to
think about how the project that you are undertaking will fit with the organisations strategy
and its definitions of project success.
PAGE 10
Activity 2.2 b
Think about some projects that have recently occurred within your organisation.
How well do these projects fit with the organisations strategy? If the project did not
fit with the organisations strategy why did the organisation choose to take on the
project? If you do not know what the strategy of your organisation is and what it
expects projects to deliver ask around and try to determine what it is.
2.3
Project Stakeholders
Having started to think about why organisations would choose to undertake projects it is
then useful to spread the net further and examine the wider body of people interested in the
project. This wider body of individuals are referred to as the project stakeholders and if you
remember back to the definition of project management (meeting stakeholders
expectations) they play a key role in influencing the success of projects. A stakeholder can
be defined as:
Any individual or organisation that has interest in the performance or
outcome of the project
Ignoring one stakeholder can be very detrimental to the success of the project. A good
example of this was Shells failure to consult with or consider Greenpeace as a stakeholder
within the project to dispose of the Brent Spar platform. The initial plan was to dispose of the
platform by sinking it in the Atlantic Ocean. However following direct action by Greenpeace
and boycotting of petrol stations across Europe, Shell changed plans and ended up
dismantling the platform. Whilst they had considered this option, it had not been deemed to
be the most environmentally friendly solution.
PAGE 11
As a framework for identifying the role of the stakeholders of a project it is first necessary to
identify them. This should be performed in as open a manner as possible in order to identify
as wide a group of stakeholders as possible. It is then useful to ask the following questions
of each stakeholder:
What resources do they bring to the project (time, finance, people, influence)?
What do they expect in return (cash, support)?
How much influence do they have in setting
oThe outcomes of the project?
oHow these are achieved?
How can the stakeholders be managed (information, financial incentives)?
Are their conflicts between the interests of stakeholders?
The influence of the stakeholders on the project can then be assessed by use of mapping
tools. The stakeholders can be mapped on a space defined by a number of choices of axis
including:
oPower versus Interest (how much power do they have compared to the amount of
interest they are likely to show in the project)
Power to define the criteria versus power to affect the operations. This mapping
process (first proposed by Winstanley) results in four quadrants as illustrated below.
Although this technique was originally developed for organisational stakeholders it
provides a useful framework for understanding the stakeholders in projects.
Power to influence criteria
Criteria Power
Disem powered
Comprehensive power
Operational Power
Power to influence operations
PAGE 12
Figure 3: The Winstanley stakeholder matrix.
Once you have mapped the stakeholders it is usually possible to find groupings of
stakeholders. For example it is common to find a group of stakeholders who have significant
criteria power but little operational power (common amongst these are governments and
regulatory bodies) and groupings of disempowered stakeholders.
Each particular grouping of stakeholder requires management by different methods. For

example those stakeholders who are disempowered may have little influence on the project
but communicating to them what are the aims, objectives and progress of the project
represents a positive method of managing this group. An excellent example of this is the
management of lower grade staff during an organisational change process where they have
little operational or criteria power but the change process will usually be less problematic if
they are kept informed.
Activity 2.3
Take a project that is currently being executed at your organisation. Using the
framework described assess the stakeholders and try to identify how they are being
managed. Are there stakeholders who are not being considered by the project at this
point in time?
2.4
Project Success
Following on from the discussions above leads us to the point where we can start to reexamine the concept of project success in a structured framework. Within the literature
there has been a significant amount of debate relating to project success and what
constitutes a successful project. Recent work published in the academic literature suggests
that there are two basic approaches to defining project success. The first of these is
founded in the traditions of project management and is referred to as a Universalistic
approach to defining project success. In this approach the traditional success factors are
cost, time and quality and it is argued that this approach leads to:
A historical approach to defining project success always looking back at the project and
not looking forward to the opportunities and benefits which might accrue from the project.
PAGE 13
Short-term focussed organisations. Organisations which focus solely on profit rather

than on more sustainable growth are said to be short term in their focus. Similarly if a
project is solely focussed on short term aims it seems reasonable that opportunities for
sustained growth will be missed by the organisation.
Internally focussed organisations which focus on how well the project is delivered from
the organisations viewpoint and not from that of the client and other stakeholders.
The alternative approach to project success is referred to as being Multidimensional and
addresses these issues by focussing on long term opportunities resulting from the project
and through being externally focussed. Within this multidimensional approach the success
factors are categorised as shown in the table below.
Category
Measure of Success
Project Efficiency
Schedule
Budget
Impact
customer
on
the Benefits accrued to the

(financial and psychological)
customer
Customer satisfaction
Business Success
Return on Investment
Market Growth
Preparing
future
for
the Development of new products

Development of new Technology
Development of new markets
Development of new relationships
Whatever approach your organisation takes to defining project success, it is important to

clearly outline what constitutes success prior to kicking off the project, as the whole process
of project development will be dependent upon the definition of project success.
Activity 2.4
PAGE 14
For the following projects what would be your key success criteria for the specific
project and what would be the strategic objectives that you would want to obtain
through undertaking the project?
An onshore wind-farm construction business developing its first ever offshore
wind-farm.
An engineering company delivering a project for a regular client for whom they
have delivered a similar project in the past.
2.5
Summary
In the project environment today the traditional project success factors of cost, time and
quality still apply but are supplemented by additional success factors including the
development of relationships and knowledge. With the increase in competition in most
markets leveraging these relationships and knowledge is likely to provide the most
sustainable forms of competitive advantage and therefore when considering the definition of
a project it is important to ensure that these objectives are included in the project definition.
PAGE 15
3.0 Session 2 Scope Definition and Project Estimating

3.1.
Introduction
The definition of the project scope can have a significant impact on the success of the
project whilst the initial estimate of the project, if incorrect, can have a huge impact on the
real and perceived success of the project. You do not need to look any further than many
projects carried out within the public eye to realise this.
In recent times, the Scottish
Parliament has highlighted these problems with significant scope changes occurring
combined with a poorly developed estimate leading to the poor perception of the project.
This session therefore aims to:
Introduce you to issues surrounding the definition (and subsequent control) of scope
Provide you with frameworks for project estimating.
3.2
Project Objectives and Scope
In session 1 we discussed organisational strategy and how projects must interrelate with this
strategy in order to deliver the organisational goals. The first stage in defining a project is
therefore to develop the objectives of the project. These objectives are likely to be at a high
level and will reflect the organisations view of a successful project and therefore may not be
overly project specific but could relate to the issues such as profit, learning and growth.
Having defined the objective of the project it is now possible to think about how the
organisation is going to meet these objectives in a much more detailed manner that will
relate to actual specifics of the project. The starting point for this process is to define the
scope of the project. The scope not only defines the boundaries of the project but will also
define the basis on which the project will be assessed when complete and will form the basis
of contractual arrangements on the project. When developing the project scope it is
important that this is agreed with the key stakeholder groups prior to further work. By
ensuring client approval at this stage it may be possible to avoid difficulties if conflicts occur
later on in the project in relation to the exact agreement during the definition phases.
One of the most common problems for projects is scope definitions which are either not well
defined or poorly understood. This can lead to poor project performance especially with
regard to schedule and budget, leading to reduced profitability on the project for a
contracting organisation or significantly increased cost to the client.
PAGE 16
Activity 3.2 Project Objectives and Scope

Consider the scenarios outlined below. What are the implications to the client and
the contractor based upon changes to the scope?
The client puts out a tender, complete with initial scope, on a fixed price
contractual basis. The contractor who wins the contract has bid for the work
based upon this scope (and often with qualifications attached to the scope) and
starts work on this basis. At some stage through the project it becomes clear that
key elements required to meet the project objective have been omitted from the
scope and the contractor informs the client. What options does the client have?
A contractor takes on a fixed price contract which has been won on the basis of
a poorly defined scope which is vague as regards the details. The contractor
discovers half way through the project that the effort required to complete the
work will be significantly greater than initially estimated. What are the implications
for the contractor?
Post your viewpoints on the WebCT forum.
As you will hopefully be able to see from the previous activity the effects of scope definition
can have a significant impact on the project performance. Similarly once the project is up
and running, changing scopes on projects can lead to significant wasted effort, increased
costs associated with changes and poor schedule delivery. This phenomenon where the
scope continuously increases is often referred to as scope creep and it is therefore important
to have a process in place to manage any changes to the scope. Methods to manage
changes in scope include:
At an early stage in the project putting into place a process that freezes the scope.
It is this scope that the estimating and planning activities are based against and
provides the framework for measuring future scope changes against. If the scope is
not frozen then the end result is a series of plans with no baseline against which to
compare them.
Ensuring that only specific people are allowed to formally agree scope changes and
that these are built into the contractual process. Common methods to ensure that
this is done in a structured manner include Variation Orders and Site Work Orders.
Ensuring that within the scope change process that a number of checks are made
against the change. Key amongst these checks are that the:
o Scope change is actually beneficial to the project. Depending upon the
culture of the organisation which you work within, changes of scope can often
occur as a result of internal politics and may not benefit the outcome of the
project.
o individuals are aware of the implications of the requested changes. Often
elements are added towards the end of the project that, if they had been
included early within the project would have not have caused significant
impact. However, towards the end of the project, a small change may have a
significant impact on the budget or schedule performance. The classic
example of this is IT projects where at the design phase the inclusion of an
element may be simple whilst at the end of the project it may involve
PAGE 17
redesigning significant amounts of the structure of the deliverable. It is

therefore important to make a check on the impact of the change on the
overall project performance to ensure that the decision to introduce the scope
change is made within an environment which is as fully informed as possible.
3.3
Project Estimation
The estimating process is crucial to the project. It is the outputs from the estimating process
that will feed into decision making process that will include go/no-go decisions and pricing of
the project. It is therefore necessary, once you have a defined scope, to start to make initial
estimates regarding the duration and the cost of the project. It is important to note that the
two of these are linked, with the duration estimates being a key input into the cost estimating
process.
Many organisations have their own clearly defined procedures relating to the estimating
process, and indeed some large organisations have individuals whose primary role is to
develop time and cost estimates for projects. This section outlines some of the
considerations which need to be made when developing estimates and also specific
methods of estimating.
The principal purpose of time (duration) estimating is to determine how long it will take to
complete a project. It follows that we cannot determine how long an entire project will take
to complete unless we know how long each of its constituent parts will take. A project is
therefore broken down into manageable tasks. This breaking down process is known as the
Work Breakdown Structure (WBS). The purpose of estimating is to assess how long it will
take to complete each of these tasks, preferably by the application of specific tried and
tested techniques. It is then possible to establish the overall duration of each phase of a
project and thus identify the overall project duration. Any task inadvertently left out during
the estimating period will result in an underestimate for the project as a whole. This in turn
will obviously jeopardise accurate time scale and resource scheduling. In many cases the
forgotten work will have to be paid for from the expected profits. Many organisations with
substantial project management experience develop sophisticated estimating techniques.
These may involve check lists although it is unlikely that the check list would be simple to
construct.
Cost estimating involves developing an approximation of the cost of the resources needed to
complete the projects activities. By assessing the length of time an individual task will take
to complete and knowing how much a unit of time costs for any resource it will be possible to
assess how much each individual task, and hence the overall project will cost. Hence, the
principal data input to the cost estimating process are:
Resource rates
Duration estimates
PAGE 18
The procedures, accounting policy and systems employed by the project team are important
aspects of the success of the estimating process.
The data outputs from the cost estimating process are:
oCost estimates
oSupporting detail
oA cost management plan
This is most easily depicted by the following figure (after Hamilton)
Cost Estimates
Resource Rates
Activity Duration
estimates
Cost
Estimating
Supporting Detail
Cost management plan
3.4.
Estimating Accuracy
An accurate estimate of project costs provides a proper basis for management, i.e. project
management control. Ideally such estimates should be based on a well-defined project
specification. A well-defined project specification will also be helpful in developing the
project task list upon which the estimate and the planning network are based. The degree of
estimating accuracy achieved will determine the element of risk taken in pricing decisions
and the effectiveness of the subsequent working cost budgets and resource schedules.
It is usual to allocate a class to an estimate that employs a level of accuracy commensurate

with the purpose of the estimate. For instance, less effort in developing the estimate is
appropriate to the conceptual study of a possible project than any of its later phases.
Similarly, it would be foolhardy to proceed with the construction phase of a large project
unless the estimate was based on values with small tolerances. This leads to the concepts
of estimating classes where the accuracy of the estimate will often increase as the project
progresses as shown in the figure below.
PAGE 19
Estimating predicts the final outlay associated with a task and identifies the associated
resources. However, not all the parameters and conditions may be known when the
estimate is prepared. That is not to say that the estimate preparation should be delayed
until all the facts are available. In instances where assumptions are made when performing
the estimate, it is usual to record these assumptions and as the project progresses to check
the validity of these assumptions. Obviously, if the assumptions do not hold later within the
project, then the final total is likely to deviate from the estimate.
The required accuracy of a single item in the estimate can be calculated using a
mathematical theorem called the binomial theorem. The binomial theorem states that an
individual workpackage estimate (e%) can be calculated from
e% = E %
S
s
where E% is the required overall estimate accuracy, S is the overall size (usually cost or
duration) of the project and s is the estimated size of the individual workpackage. If we
PAGE 20
apply this to a project with an overall value of 500,000 and a workpackage estimated at
50,000 for a range of required overall estimate accuracies we can calculate the following
required workpackage required accuracy.
E%
e%
50
158.1139
20
63.24555
10
31.62278
15.81139
When estimating it is important to realise that the cost of estimating increases significantly as
the accuracy required increases. Turner has estimated that to prepare an estimate of
between 2 to 5% accuracy will involve of the order of 5-10% of the overall project cost. This
figure only includes the tangible costs to the organisation of developing estimates and
tenders and recent research has indicated that there are significant intangible costs attached
to the estimating and tendering process including work place stress.
3.5.
Work Breakdown Structures (WBS)
At the heart of formal project management is the process of identifying in a structured

manner the activities that are required in order to complete the project scope. The key tool
in achieving this is the Work Breakdown Structure that provides a framework for organising
how the activities will be organised and recorded.
The first challenge in developing the WBS is to determine the level of accuracy that you
require at the task level. During the initial phases of the project (for example during the
conceptual design phase) it is unlikely that there are sufficient details available to identify all
the tasks required during the construction phase. However, there are likely to be common
elements from other projects that would allow the construction phase to be loosely specified
at this stage. As the amount of detail available increases then the WBS can be developed
further to include this.
In an ideal world each task should be selected so that it is small enough to be visualised as
a complete entity for estimating purposes. On the other hand, the size of a task must be
large enough to represent a measurable part of the whole project. The design and
manufacture of each sub-assembly from a main piece of equipment might rank for
consideration as a task, whilst the final assembly of all those sub-assemblies into one whole
main assembly could be regarded as another. If the project were to build a water dam
serving a large part of Africa, a stand alone task would not be open next bag of cement as
PAGE 21
this would result in many very small tasks which would not form a measurable part of the
project.
Common factors that affect the level of appropriate detail include:

The perceived risk of the activity. For example if you are certain (perhaps through prior
experience) that the design would take 10 days then a single level may be an appropriate
amount of detail. If you were uncertain of the time to perform the design it would be
appropriate to break it down into more identifiable tasks. The benefit of doing this is that, as
the tasks get smaller, it usually becomes easier to estimate how long the task will take.
The acceptable number of man-hours. Some organisations will specify that a single
identifiable task should have no more than (for example) 80hrs attached to it. If this were not
the case the organisations procedures would then specify a greater level of detail.
The level of control required. As the number of tasks becomes greater and as detail is
introduced it is easier to see what has to be done and what has already been done. For
example in studying this module the task list could be simply complete module. A more
appropriate level of detail would include Session 1/2/3 etc. and Assessment 1/2/3. Then as
project manager you can see exactly where the project is at a given date and exercise
control based on this information.
As the tasks get smaller and smaller there is a cost attached to the management and
planning of this tasks. It is therefore often not cost efficient to manage at a micro level of
detail and the benefits of breaking down the activities in terms of control must be weighed up
against the increased costs attached to this.
If you wish to empower your staff and provide them with a feeling of ownership for a section
of the project excessive breakdown of activities can hinder this process.
If you plan only at a high level, you risk extending the project timescale by not introducing
flexibility about how activities are scheduled. For example if you plan based upon three
large phases (say design, construction, and commission) then you limit yourself to
completing each of these phases before moving onto the next phase. Planning at a greater
level of detail will allow you to identify alternative linkages within the plan and provides more
flexibility in terms of how you plan. For example you may be able to identify elements of the
design phase which once complete can allow construction to start prior to completion of the
whole design.
As a general rule your WBS should breakdown activities to the level at which you are going
to schedule and control the project.
There are two common ways of developing WBS structures. The first of these is to start with
the project and break it down into smaller sections that encompass a logical grouping of
activities. If these groupings of activities are linked within a timeline framework they are
often referred to as phases. You would then split these large groupings into smaller
groupings and so on until you reach the level of activity at which you wish to plan. This is
referred to as a top-down approach.
An alternative approach to the top-down approach is the bottomup approach where you
brainstorm the activities that would be required to complete the project and subsequently
PAGE 22
make groupings of the activities. The approach you take will depend mainly upon personal
preferences.
As an example we will develop a generic WBS for the design of an engineering component
consisting of two parts. At the highest level the WBS could be split into:
1.Identify product requirements
2.Conceptual design
3.Detailed Design
Each of these high level activities could then be split into a number of smaller activities. So
the WBS could become:
oIdentify product requirements
1.
Technical Specification
2.
Manufacturing limitations
3.
Identify Cost limitations
oConceptual design
1.
Idea generation
2.
Idea selection
oDetailed Design
1.
Design Calculations
2.
Develop initial detailed drawings
3.
Design Verification
These smaller elements could then be broken down into even smaller elements. If we take
the detailed design element it could for example be broken down into:
Detailed Design
1.
Design Calculations
1.
Part A
2.
Part B
2. Develop initial detailed drawings

1.
Part A
2.
Part B
PAGE 23
3.
3.
Assembly drawing
Design Verification
The indented list approach to the WBS is commonly used within planning software although
WBS are also sometimes shown as below.
Projec t
Identify Product
Require me nts
Technical
Specifications
Conceptual
Design
Manufacturing
Limitations
Idea
Ge neration
Idea
Selection
Detailed
Design
Design
Calculations
Part A
Initial Detailed
Drawings
Design
Verif ic ation
Part B
This process of systematically breaking down the activities into smaller and smaller activities
provides a structure by which to order the plan. On large projects if an approach like this is
not used then it is possible to generate a long list of activities with little or no structure which
results in difficulties in managing the project when it is under way as well as raising issues
when scheduling the project.
There is no reason why it should not be possible to devise a comprehensive numbering (or
alpha - numeric) system which ties in with (or replaces/ becomes) the companys own code
and drawing numbering system. Certainly the cost code aspect should be taken up if at all
possible; the drawing numbers may be more difficult to establish. If one comprehensive
scheme can be set up, much cross-referencing will be saved as the project continues and
there should be a substantial reduction in the possibility of clerical errors.
Other Breakdown Structures

When identifying each task, it is clear that many of the tasks will fall under a natural header
or group and that there may be more than one set of logical structures which could be used
to break the work down. These other groups commonly include:
cost breakdown structures where the breakdown is performed by cost centre
organisational breakdown structures where the breakdown is performed on a basis of which
part of the organisation (or individual) is responsible for each work package.
location breakdown structures when the project is operating on multiple sites
contract breakdown structures to identify what individual contractors are responsible for
PAGE 24
product breakdown structures for complex products where the identifier would refer to
specific parts of a product (e.g. chassis and engines).
There are some advantages (including improved control and reporting) in maintaining
multiple breakdown structures. The use of these should however be balanced against the
increased cost/time involved in maintaining them.
Activity 3.5
Take a project which you are currently working on. Develop the WBS for this project
(or an element of this project) and develop a further breakdown structure (cost /
organisational / product) for this project.
3.6.
From the WBS to the Estimate
Once the WBS has been developed it is possible to start to move towards developing the
estimate for the project. By including elements such as the time estimate and unit pricing
rates a detailed cost estimate can be developed. The challenge though is to decide how
long an activity might take to complete, and what resources that activity will require to an
acceptable degree of accuracy. A number of methods are commonly used to do this
including:
Norms
Parametric Estimating
CTRs
3.6.1
Work Study and Standard Work Norms
Norms are used within many industries to provide standard estimates of how long a task will
take. Based upon these norms the estimate is then developed. Some organisations have
very rigidly developed sets of norms that are applied to project activities and through
comparison of actual time to complete activities the norms are continually updated.
However many organisations also use norms, but not explicitly, with individuals intuitively
developing norms for activities. Some industry sectors also have standard norms (especially
the construction industry) that are applied across the sector.
Work study is a generic term for the techniques, particularly method study and work
measurement, which are used in the examination of human work in all its contexts, and
which leads systematically to the investigation of all the factors which affect the efficiency
and economy of the situation being reviewed, in order to effect improvement. This approach
can also lead to the development of norms. This topic although not usually forming part of
the portfolio of skills employed by estimating personnel provides an important and useful
background to estimating and the establishment of work norms in particular.
PAGE 25
Method study is the systematic recording and critical examination of existing and proposed
ways of doing work, as a means of developing and applying easier and more effective
methods and reducing costs. Method study can be applied to any category of resource.
Work measurement (or a time study) is the application of techniques designed to establish
the time for a qualified worker to carry out a specified job at a defined level of performance.
It is usually applied to tasks of a repetitive nature
The Steps In Making A Time Study

Once the work to be measured has been selected the making of a time study usually
consists of the following eight steps: -
oObtaining and recording all the information available about the job, the operator and the
surrounding conditions, which is likely to affect the carrying out of the work.
oRecording a complete description of the method, breaking down the operation into
elements. This is likened to the Work Breakdown Structure that is established in a project
environment where the elements would be known as tasks.
oExamining the detailed breakdown to ensure that the most effective method and motions
are being used.
oMeasuring and recording the time taken by the operator to perform each element of the
operation.
oAt the same time assessing the effective speed of the working of the operative in relation to
the observers concept of the rate corresponding to standard rating (see the table below).
oExtending the observed times to basic times

oDetermining the allowances to be made over and above the basic time for the operation.
oDetermining the standard time for the operation
Standard time = (time taken * (rate /100)) + allowances
PAGE 26
British Standard
DESCRIPTION
Comparable
SCALE
Walking speed*
0 - 100
(m/h)
(km/h)
No activity
50
Very slow; clumsy, fumbling movements

operator appears half asleep with no
interest in job
3.2
75
Steady,
deliberate,
unhurried 3
performance, as of a worker not on
piecework but under proper supervision
looks slow, but time is not being
intentionally
wasted
while
under
observation.
4.8
100 Std rating
Brisk, businesslike performance ,as of 4

an average qualified worker on
piecework; necessary standard of quality
and accuracy achieved with confidence.
125
Very fast. operator exhibits a high 5

degree of assurance, dexterity and coordination of movement, well above that
of an average trained worker
8.0
150
Exceptionally fast requires intense effort 6

and concentration, and is unlikely to be
kept up for long periods; a virtuoso
performance only achieved by a few
outstanding workers.
9.7
6.4
Standard Times
An example is used to illustrate how standard time might be established for an inspection
activity. The task list for the activity is assumed to be: A.Pick up PCB from in box, remove bubble wrap and visually inspect for obvious flaws.
B.Put into clamp and measure transistor values.
C.Record transistor value in log sheet
D.Solder on ID tag
E.Carefully place PCB in bubble wrap and place in out box
PAGE 27
Additional activities might be for

F.Fetch new box of cards from storage area
G.Place card in Faulty box
The person conducting the work study would record the task and develop a time study sheet
as shown below:
TIME STUDY RECORD
DEPT
NAME
DATE
OPERATION
TAKEN BY
Time
Rate
1.17
80
0.83
90
0.21
85
0.14
85
0.15
90
0.73
85
0.74
85
0.21
90
Study started 08:50
PAGE 28
Stnd
0.14
85
0.15
75
0.64
80
0.73
90
0.74
85
Discussion with Supervisor
3.44
0.17
75
Opened new roll of solder wire
0.48
75
0.19
80
0.81
85
And so the sheet would continue to be filled and then carried on with continuation sheets for
about an hour. When the study is complete, the times and ratings are extended by
multiplying together to get a standardised times that in turn are statistically analysed.
Several further studies are undertaken until the standard deviation converges to a preestablished acceptance level. Contingency and relaxation (usually 2% and 10%
respectively) times are added as a percentage and a standard time per PCB established.
This routine is repeated for each design of PCB and a table of values issued. It will be
readily appreciated that standard work norms in an engineering design and construction
oriented discipline could be established in a similar way. For example many organisations
use industry standard norms or norms which the organisation has specifically developed to
cover activities ranging from the development of engineering drawings through to the
welding of pipes.
Activity 3.6.1a
Develop a time study sheet and try and estimate the standard time for a task at your
work that is repetitive. How well does this tie in with what you actually achieve (you
may want to get someone to help you with this).
PAGE 29
Activity 3.6.1b Work Norms

As a simple example of the implementation of work norms consider a joiner laying
floorboards in a room. The room has dimensions of 6m by 3.1m with two door ways.
Each of the boards is 0.3m wide by 2m long. The standard times for each of the
required activities is given below.
Offloading boards from truck to room 2 minutes per 5 boards.

Laying a single board 4 minutes
Cutting a board to fit 2 minutes
Fitting boards around a door way 15 minutes / doorway.
Using the above data calculate how long the floor will take to lay. Put your answer up
in the bulletin board and see who can work out the quickest way to put the floor
down!
3.6.2
The Learning Curve Effect
Watching a skilled crafts person at work shows how a highly intricate task can be learned
and carried out so that it is made to look easy. Gaining such a level of skill requires years of
training and practice (and many mistakes). A project rarely has such an opportunity to gain
advantage through repetition. There will however, be repetitive elements to any activity,
particularly during the execution phase. Where this occurs, the time taken each time the
task is carried out will decrease as the person becomes familiar with the methods.
Subsequent improvements in speed are seen to become smaller over time as shown below.
In order to take account of this in activity duration estimation an empirical relationship can be
developed to aid the planner. This relationship is usually of the form
Yx = kx n
where:
x is the number of times the task has been carried out
Yx is the time taken to carry out the task the xth time
k = time taken to carry out the task the first time
PAGE 30
n = log b / log 2 where b = learning rate
Example
A team is set up to carry out a quality audit of ten departments. The first audit takes four
days, as the auditors are unfamiliar with the procedures. The second audit takes three.
After a period of time, the minimum audit time is reached, and very little further improvement
is seen. We can plot this progression as shown in Fig. 4.7
4.5
4
3.5
Time
3
2.5
2
1.5
1
0.5
0
0
10
12
No of times activity completed
If we wish to find out how long the eighth audit will take, we need to calculate the learning
rate, b. The following values can be assigned from the above information:
x = the number of times the task has been carried out = 2
Yx = time taken to carry out the task the xth time = 3
k = time taken to carry out the task the first time = 4
PAGE 31
n can be therefore be calculated as demonstrated below
4 x (2)n
2n
3
4
n log 2
log (3/4)
-0.1249
0.30103
log b
log 2
-0.414
log b
-0.1249
0.75
From this we can say that the project has a 75 per cent learning curve. This can also be
seen intuitively, as another way of expressing the learning curve is to say that every time the
total number of audits completed doubles, the time taken for the last audit will be the
learning percentage multiplied by the original time. In this case as the number of audits
doubled from 1 to 2, the time decreased from 4 to 3. The percentage is therefore 3/4 = 75
per cent. As the number of times the audit is done increases, the times taken will decrease
as shown below.
PAGE 32
Audit no.
Time taken (days)
2.54
2.25
2.05
1.90
1.78
1.69
Activity 3.6.2
The tensile testing of rubber specimens has a learning coefficient of 0.9. If it takes 10
minutes to test the first specimen, estimate how long it will take to test a batch of 15
specimens. To help you with the calculations you may wish to create a simple
spreadsheet.
3.6.3
CTRs
A Cost Time Resource (CTR) sheet hinges around deliverables, particularly of a

documentary type. Examples include:
Reports
Design calculations
Studies
Drawings
A CTR estimate is developed from the WBS. The required resources for each activity are
noted against each deliverable. The stages of production of the deliverable have estimated
work input allocated, usually in man-hours. Examples include:
oIssued for Comment
oIssued for InterDisciplinary Check (IDC)
oIssued for Implementation
A further feature of the CTR is that input requirements such as:
oOther documents
oReference drawings
are recorded. It is likely that a CTR will exist for each of the input requirements also.
Activity 3.6.3
Activity: If you are involved in the Engineering design process and do not already use
CTR you may want to try developing a CTR for an activity that you are working on at
present. If you do not work in Engineering design how might this approach be
modified for your business.
PAGE 33
The activities and their stages of completion are reported against regularly as a control
function with predetermined awards being allocated for each stage of completion. Activities
such as acceptance by some other disciplines or the client will have time values allocated to
them but not necessarily resources. The following example represents a CTR for assessing
pre-design options for a chemical plant process and issuing a report. The format shown is
typical of that used in engineering construction design.
Cost Time Resource Sheet
Client
Report :
Project
Page :
Contract
Date
CTR No :
Title
Start
Revision :
PO Ref. :
Finish :
Scope:
Inputs:
PAGE 34
Deliverables:
Assumptions:
Resource Requirements, Hours & Rates
Total CTR value
PAGE 35
3.6.4
Parametric Estimating
The process of parametric estimating is similar to norms in that a specific activity is
estimated based upon a predetermined formulae. This type of estimating is commonly used
in the development of order of magnitude estimates (about 25%) within the construction
industry. For example an organisation will know how much on average a square metre of
internal space costs to construct. Based upon the required floor space and other factors
(parameters), equations would be used to determine an estimated cost and completion time
for the construction. Further details on this approach to estimation can be found at
http://cost.jsc.nasa.gov/PCEHHTML/pceh.htm
3.6.5
Completing the estimate
The final stage in the cost estimating is to bring the information which you have gathered
from across the organisation and from subcontractors together to complete the estimate. It
is important that a standard approach should be taken throughout an organisation from one
project to another. By the accrual of project estimates according to a standard procedure,
comparisons can readily be made between estimates for the same task. Thus a statistical
analysis will be possible adding to the professionalism and efficiency of an organisation
through the judicial use of historical information. Observance of company policy on cost
rates and costing methods as well as the determination of project working budgets impose
an obligation on the project manager to ensure that estimates are set down in a standard
and logical manner.
This need for consistency means that many organisations use a standard estimating form.
Such forms are designed around the special needs of any particular company and would
take account of their own particular planning networks and accounting systems. Project
estimating forms can be designed to suit the estimating levels previously described. It is
normal to devote a row to each task. Clearly tasks that are categorised can be gathered
together and presented on the same sheet. Many attempts to design estimating (and other)
forms fail because they are over ambitious. There is of course no need to provide a column
for every possible contingency and there may be a case for leaving one or more columns
blank for allocation to special or seldom used activities. For instance, special tooling does
not require individual treatment on an estimating form since it can be treated as an ordinary
task when it is part of a project.
An exemplar estimating form is not provided here. It is a simple task to make a model sheet
on a spreadsheet although many organisation are moving towards a more dynamic link
between the project planning software, estimating and progress reporting.
Activity 3.6.5
For a project that you are currently (or have been recently involved in) was an
estimating form used? Did the use of a form aid the estimation process? Develop an
estimation form, using MS Excel, for a relatively simple project.
PAGE 36
There are several options available as to how to present information such as wage (or
salary) rates and overheads. The extension of time estimates to cost estimates can either
be applied by performing the multiplication of each time estimate by the appropriate rate or
leaving the extension until the estimating process has been reduced to summaries. Labour
or machine time is the fundamental for all estimates; conversion to financial value is a
derivative.
Similarly, overheads and profit can be added in any one or combination of several ways. For
example the project secretarys time may be estimated and costed separately, as may the
document controller and so on. Alternatively their burden can be cumulatively considered
and applied within a single overhead charge or percentage. By the same token the
expected profit can be applied as a single figure based upon what the Company considers to
be fair reward. This may or may not take into account the profit from other projects.
Alternatively the profit may be applied mathematically as a percentage of the project total.
In the materials section of the project estimating form, columns can be included to those
needed for the direct cost of each task. Overheads and profit can be applied directly to the
purchase price of materials in order to recover the cost of sourcing and the preparation of
documentation and control. A popular alternative is to recover material administration
expenses along with general labour overheads.
3.6
Contractual Agreements
In a commercial environment when developing an estimate and pricing for the project the
contracting strategy which is utilised will have an impact on the estimated cost of the project
to the client. The major elements of the cost of executing work on behalf of a Client can be
summarised as
The cost of the time for direct labour to carry out the scope of work
The cost of materials, plant and consumables
The cost of capital equipment which might include the cost of the means of providing a
conversion process, equipment maintenance, its running costs and such considerations
as depreciation.
The cost of indirect expenses such as training or transportation
The cost of overheads such as management, financial and legal support and other non
direct staff
When these costs have been identified, it is necessary to address the legal agreement under
which the work is to be undertaken, in other words, the contract that will exist between the
contractor and the client. Dependent upon which industry you are working within there are
PAGE 37
likely to be different contracting strategies which are predominately used.

common types of contract are:
The most
Fixed Price / Lump Sum

Schedule of Rates / Cost Reimbursable (Fixed / % Fee)
Bills of Quantities
Design and build (and operate)
Each of these has advantages and disadvantages for both the contractor and the client. In
particular it is possible to identify the risk/incentives to both parties for these operating
strategies. This is illustrated below
Design, Build and Operate

Clients
flexibility
Design and Build

Fixed Price
Partnership
Costs + Fixed Fee
Costs + % Fee
Clients Risk
Contractors
incentive
The contract interaction is based on long term and short term objectives on the part of both.
In the short term, which can be considered the narrow view, the contractor has a desire to
build its workload whilst the client has a desire to get the best quality at the lowest possible
price. The long-term objective of the contractor is to maintain a sound and developing
organisation which provides as good a return as is possible to the owners, investors and
work force. The long-term objective of the client is to have the contract competed on time,
within budget and to the required level of quality. It also has a need to be able to continue
its own sphere of operations, which will usually depend on the completion of work by
contractors.
The principal features of three types of contract are discussed very briefly below as they are
dealt with in great depth in a later module.
Fixed Price / Lump Sum
Fixed price / lump sum contracts mean that the client knows what the final cost will be before
awarding the work but that is heavily dependent upon having issued an extremely accurate
scope of work to the contractor to price. In the event that extra work transpires for whatever
reason after the work has commenced, the contractor will be able to charge extra
reimbursement for that work and the pitfalls will be fairly obvious. The trick for the contractor
at bid stage is to be sure that the price provides adequate reward without being greater than
any other competitors submitted price. It should also be noted that on a fixed price contract
the rates (e.g. day rates) applied by the contractor are likely to be higher than those imposed
PAGE 38
on a reimbursable contract. This increase in cost can be regarded as the contractor building
an element of contingency into the project in case of anything not going to plan.
Schedule of Rates / Cost Reimbursable
It is common for a contractor to submit or negotiate a complete set of rates that enable the
work to be invoiced as it progresses. This type of contract is useful if the scope of work
cannot be accurately defined before the work commences. It is, of course, necessary to
establish rates to cover the provision of all the services, even if only to specify that items
purchased will be invoiced at the same price as they were purchased by the contractor with
a fair handling charge added on.
Bills of Quantities
Bills of quantities are the domain of the quantity surveyor. Their science has been
developed over many years. They are used extensively in the construction and building
industry. They are established by issuing a complete breakdown of the project in terms of
each physical part of the work, providing such detail as quantity, location and dimension.
The contractor then adds the invoice price required to complete each item of the specified
quantities and an additional price for each item in the event that the quantity changes.
Pricing Projects
The basic relationship between price, cost and profit can be expressed in a number of ways:
cost + profit
Price
price - profit
Cost
price - cost
Profit
Which one applies depends on whether price, cost or profit is fixed first. These differences
can be explained as follows:
In the first case, the price is fixed through legislation for example, or in the case of a
target costing system, through market analysis;
In the second, the cost is fixed, generally through contract purchase which guarantees
that goods will be supplied to you at a particular price. This fixes your costs, whilst your
selling price and profits can be varied;
Some agreements state the profit that a company is allowed to make through the
system known as cost-plus pricing.
PAGE 39
3.7
Summary
By the end of this session you should:

Be able to describe classes of estimate and specify when specific classes are appropriate
Understand the need for well defined work break down structures
Develop work breakdown structures for your own projects
Appreciate the role of alternative breakdown structures
Be able to develop and undertake a work study
Calculate task duration using work norms
Estimate the reduction of duration of repetitive tasks given the required data
Be able to describe CTR methods
Be able to discuss a range of contracting strategies and the benefits of these.
PAGE 40
4.0
Session 3 Detailed Planning
4.1.
Introduction
This chapter introduces the process of the planning using the Critical Path Method of Project
Planning. This is the most commonly used method of project planning and through a simple
example the principles behind the critical path method are introduced.
4.2.
Origins of Network Planning
Both the Critical Path Method (CPM) and the Programme Evaluation and Review Technique
(PERT) were developed in America in the 1950s. CPM was initially developed by the Du
Pont Company, for the planning and controlling of the maintenance of chemical processing
plants. This proved to be so successful (at one site, downtime for maintenance was reduced
by 37%) that the method soon found applications in other types of project work. PERT was
devised by the US Navy to co-ordinate the activities of the many contractors engaged in one
of the most complex projects ever undertaken until that time, the development of the Polaris
missile. It is claimed that by using PERT, the programme was completed some two years
earlier than would otherwise have been the case. Both techniques employ the same basic
methodology, the representation of project activities as a network of lines and nodes. The
main difference between them is that PERT allows probabilistic estimates of activity
durations.
The general emphasis of these methods is usually on how quickly a task can be performed.
But, as well as time, we also want to monitor the control of other resources in order to bring
the project in on schedule and budget. Hence we are concerned with managing:
Time
Human Resources
Equipment and machinery
Cash
Clearly there must be a trade off between time and resources with generally high levels of
resource leading to shorter project durations. The smoothing of resources (discussed later)
will lead to better economy, especially when considered with cash flow constraints.
PAGE 41
4.3.
The Network Planning Procedure
The project network is a key part of the planning stages and from this project network the
basic elements of the project plan including the Gantt chart and resource profiles are
derived. The British Standards Institute defines the project network as:
"A diagram representing the events, activities and their inter-dependence"
It should be remembered that the network represents a plan and it can therefore be updated
and improved with time.
A project, or part of a project, can be divided and continuously (almost) sub-divided into
Events that are single points in time identifying the beginning or end of an activity.
These are hard to give names to.
Activities that take time to complete but are easy to name and required resources can
be shown.
There are two conventions used when developing graphical representation of networks.
Activity on Arrow (AOA) networks represent the events as circles (nodes on the network)
and the activities are shown as arrows (branches of the network). Alternatively we can use
Activity on Node Analysis (AON) where the activities occur at the nodes. The selection of
technique is simply a matter of choice although the AON method offers some advantages
over the AOA method. AON is usually the method selected for analysis on a computer (for
example Microsoft Project utilises this method), principally because the analysis data can be
easily displayed within the node. The MSc course does not address Activity on Arrow in any
great depth. You are however encouraged to investigate further by reading about it in
almost any textbook on Project Management.
In general project networks are usually developed using the aid of a project management
computer package (a tutorial for Microsoft project is provided within the course materials).
Therefore the aim of this section of the course is to ensure that you understand what the
package is doing behind the scenes.
In the table below the basic steps of the CPM technique (extended to include resourcing and
S-Curves) are outlined, before each of them is considered in detail. It is important to note
that this is an iterative process and that each stage will impact on later and earlier stages in
the process and therefore it should be remembered that each of these stages overlap
significantly.
1
Define Project
List Activities
PAGE 42
Clearly identify the goal of the project, and the conditions

which will signify both the start of the project and its
satisfactory completion
Identify those activities, connecting the start and end of the
project, which it is judged appropriate to schedule and control.
This activity list is commonly derived from the lowest levels
developed within the Work Breakdown Structure.
Establish
precedence
Relationships
Construct Network
Estimate Activity
Durations
Make Forward
Pass
Make Backward
Pass
Calculate floats
Identify Critical
Path(s)
10
Prepare Activity
Data Table
11
Schedule Activities
12
Resource Activities
13
Develop the
Project S-Curve
14
Monitor Progress
For each activity, identify those other activities, if any, which

must be completed before the activity in question can begin.
This information will probably be presented on a project
activity chart.
Represent the project activities and their precedence
relationships by a network of nodes.
For CPM a single estimate is made for each activity in the
network. For PERT, three estimates are made: optimistic,
pessimistic and most likely times.
Beginning with the starting node and ending with the last
node, determine the earliest start and finish times for each
node. This step determines the expected completion time for
the project.
Moving back through the network from the last node,
determine the latest time for each node.
For each activity in the network calculate its total float and free
float. Float indicates the amount by which an activity may be
delayed without delaying project completion.
This is the chain of activities which determines the duration of
the project. At this stage it may be necessary to alter the
project plan if a completion deadline is to be met.
This table presents a description of each activity, its node
references, duration, earliest and latest start times, earliest
and latest finish times, total float and free float. This is an
extension of the project activity chart.
Planned start and finish times for each activity are chosen,
and presented on Gantt chart.
At this stage the resources for each activity should be
specified and any overloading on resourcing identified. By the
process of resource smoothing, resource overload may be
mitigated although again this will have an impact on the
project plan
After the plan has been developed, the project S-Curve which
tracks the cash spend or man-hours utilised throughout the
project can be developed. This will often form the basis of
project control.
As the project is implemented, actual progress is compared to
the plan. If required and possible, corrective action may be
initiated. This is covered in detail in session 4.
In order to demonstrate the development of a project plan the following outline project
definition will be utilised as an example for the development of a resourced project plan.
PAGE 43
Project Definition
A Company has ordered a piece of equipment from a supplier of special-purpose
machines. The suppliers plant is sited in another country, and the machine, having
been constructed there, is currently undergoing proving trials. The project concerns
the transport of the machine from the suppliers plant to the company, and installing it
in a predetermined position in the companys plant. The project start will be signalled
by a telephone call from the companys representative at the proving trails, indicating
that the machine has completed the trials successfully. The project will be deemed to
be complete when the machine is installed and running satisfactorily at the
companys plant.
Step 2: List Activities

In practice this step in the procedure may present some difficulty. The problem is that of the
resolution which is appropriate in identifying the projects constituent activities. If a coarse
resolution is applied to our example, the project might be considered to comprise only two
activities: transport machine, and install machine. At the other extreme a fine resolution
might identify thousands of short duration activities making up the project.
Normally, the over-riding consideration in choosing a level of resolution will be the
economic implications of the number of activities specified. If there are too many, then the
resources required for scheduling them and monitoring their progress will incur costs which
outweigh any benefits obtained by employing such fine detail.
In the first instance it is probably best to err on the side of coarseness, later modifying the
network to provide finer detail where required. This is demonstrated under 9 Identify Critical
Path, where the project plan is modified to obtain a reduction in the duration of the project
by defining the project activities at a finer level.
For this example, the initial activity list is as follows: oClear site
oDig foundations
oProcure foundation materials
oLay concrete foundations
oTransport machine
oInstall machine
oInstall electricity supply
oConnect machine to supply, and run
Step 3: Establish Precedence Relationships
Three activities may commence when the project is initiated. The site, in the companys
plant, where the machine is to be installed, may be cleared of any equipment or materials
currently sited there. The sand, aggregate and cement required for the machines
PAGE 44
foundations may be purchased. The transport of the machine from the suppliers plant may
be initiated.
The digging of the foundations cannot begin until the clearing of the site is complete, and the
laying of the foundations cannot start before the foundations have been dug, and the
materials have been procured. The installation of the machine must wait until the machine
has arrived, and the foundations are complete. However, whilst the installation of the
electricity supply to the site can only begin when the foundations have been laid, it does not
require the presence of the machine. Finally, once both machine and electricity supply have
been installed, the machine may be connected to the supply and set running.
If the activities are labelled (A to H) these precedence relationships may be set alongside
the list of activities, as follows:
Activity ID
Activity
A
B
C
D
E
F
G
H
Clear Site
Dig Foundations
Procure Foundation Materials
Lay concrete foundations
Transport Machine
Install Machine
Install Electric supply
Connect machine to supply and
run
Immediate
Predecessors
Start
A
Start
B,C
Start
D,E
D
F,G
This type of precedence relationship, where one activity must be finished before the next
activity can start (referred to as a finish to start relationship (FS)) is the simplest type of
relationship that is used in the network planning process. There are however a number of
other relationships which are used.
Start Start
(SS)
Finish Finish
(FF)
Start Finish
(SF)
The activity cannot start until its predecessor has started.

This type of relationship can be used to compress the
overall project duration by not insisting that one activity is
completed before the next activity (which uses some of
the previous activities inputs) is started.
The activity cannot finish until its predecessor has
finished. For example you cannot finish painting a
structure before the structure is completely fabricated
however you can start painting the structure before
construction is completed.
The activity cannot finish until its predecessor has
started.
These relationships are often represented graphically as shown below.
PAGE 45
B
A
finish to start
B
A
start to start
B
A
finish to finish
B
A
start to finish
When deciding upon the precedence relationship it is also important to decide whether there
are any leads and lags between the activities that effectively make the relationship between
the activities have a positive or negative duration (the relationships usually have a duration
of zero). For example there might be an item which must be procured on a project, which
from the date of the order being submitted will take 12 weeks to arrive. One method to show
this on a project network would be to have an activity that has a duration of 12 weeks
entitled procure X. This however is a distortion of reality as during this 12 week activity
there will be no resource committed and therefore a better method would be to represent this
through a lag from the order being placed to order being received as shown below.
Order
FS + 12wks
Receive
Leads and lags can be used with the more complex relationships (such as start-start
relationships) to represent more complex relationships on projects. For example imagine a
domestic underground gas pipe-laying project to lay 5 km of pipe. You are unlikely to dig the
5kms of trench prior to laying any of the pipes. A more realistic method would be to be
trenching 2 days in advance of the pipe laying. This could be represented by a start-to-start
relationship with a lag of 2 days as shown below.
Trench
Lay
PAGE 46
Step 4: Develop the project network

The activity-on-node convention (AON) is used. Noting from the activity list that three
activities may start on initiation of the project, we can draw these activities into the network
as shown below.
A
C
E
Returning to the list, we find that only one activity, B is dependent on A. This allows us to
place activity B into the network, where a line from activity A to activity B indicates the
precedence. We then find that B and C are the immediate predecessors of a single activity,
D; no other activities are directly dependent on either B or C. The lines from B and C can
therefore be drawn to activity D. When an activity has two or more predecessors it is
referred to as a merge event.
E
Activities G and F are dependent upon activity D. These activities are therefore placed in
the network with individual lines connecting them to activity D. When an activity has two
activities that are dependent upon it, the creation of two paths through the network is
referred to as a burst event. Note that activity F is also dependent upon activity E and
therefore a line is also drawn connecting these two activities as shown below.
A
C
G
D
F
The completion of the precedence network is straightforward, and is shown below
PAGE 47
G
H
D
F
Step 5: Estimate Activity Durations

Each activity is now considered, and an estimate made of how long it will take to complete.
Where the activity is similar to one carried out on an earlier project, it is likely that an
accurate estimate can be readily made. Where an activity is to be carried out which is of a
type not experienced before, it may be difficult to establish a single estimate of its duration
with any confidence. In such circumstances, the three-estimate probabilistic approach of
PERT might be worth considering. For more details on estimating activity durations you
should refer back to session 2.
For our example, we will assume that single-estimate values for the activity durations are
obtained without difficulty.
Activity ID
A
B
C
D
E
F
G
H
Activity
Clear Site
Dig Foundations
Procure Foundation Materials
Transport Machine
Install Machine
Install Electric supply
run
Duration
2
3
2
3
10
4
4
2
Analysing The Network

The aim of analysing the network is to calculate the earliest time that activities can start, the
latest time that activities can start if the project is to be completed on time and the critical
path through the network. Although for a small project as shown above the procedure may
seem simple, a structured method is required when the project increases in complexity.
Step 6: Make Forward Pass
The first stage in analysing the network is to calculate, based upon the activity durations, the
earliest any individual activity can start (ES) and the earliest any activity can finish (EF).
This earliest start is calculated by moving through the network from the first activities to the
last activities. This procedure is referred to as a forward pass. This can either be done by
adding an extra column to the table above or by using a standard format for each activity
PAGE 48
node on the network into which the data is entered. The latter approach is more simple and
allows easier checking and therefore is utilised here.
The standard format for the activity box is shown below where LS and LF refer to late start
and late finish (see next section for how to calculate these).
Duration EF
ES
Activity
LS
Float
LF
Care should be taken when interpreting software package outputs as they may well not be
the same as this where in doubt check. For example the standard format used in MS
Project is
Activity A
Start: 1/10/02
ID: 1
Finish: 1/10/02
Dur: 1 day
Res:
Beginning with activities with no predecessors (A C E) enter the earliest start in the top left
quadrant of the node. This entry might be a known calendar date, but for our purpose 0 will
be entered to represent the beginning of the first day of the project. The earliest finish date
is calculated by adding the duration to the ES. Therefore the earliest finish of Activities A, C
and E are 2 ,2 and 10 respectively.
EF = ES + Duration
Calculation of the earliest start for activity B is simple as there is only one predecessor,
activity A. Therefore the ES for activity B is the same as the EF for activity A. Therefore
activity B has an ES of 2 and an EF of 5. The calculation of the ES of activity D is slightly
more complicated. This activity has two predecessors B and C. The ES of activity D is the
greater of the two EFs of the predecessors. Therefore as B has an EF of 5 and C has a EF
of 2 then the ES of activity D is 5. The simple rule is that at a merge event the ES of the
activity is the latest EF of its predecessors. This information can be entered into the network
as shown below.
0
A
LS
0
Float
2
B
LF
LS
Float
LF
C
LS
0
Float
LF
10
10
LS
Float
LF
E
LS
Float
LF
Following this logical approach the ES and EF times of the other activities in the network can
be calculated. As D is Gs only direct predecessor the ES of G is the same as the EF of D
PAGE 49
and is therefore 8. Activity F has two direct predecessors, D and E. The situation is the
same as at activity D a merge activity. We therefore select the latest EF of the
predecessors D and E. Therefore the ES of activity F is 10. The completed network is
shown below.
0
A
LS
0
Float
2
LF
LS
Float
LS
LF
C
LS
0
Float
LF
10
10
Float
12
Float
LF
14
D
LS
Float
16
H
LF
LS
10
E
LS
4
G
Float
LF
14
F
LF
LS
Float
LF
From the network it can be seen that with estimated activity durations the minimum time to
complete the project is 16 days.
Step 7: Backward Pass
A similar procedure is now carried out to determine the latest start (LS) and finish (LF) times
for each activity with these being entered in the appropriate position. In this case we begin
with the final node and work backwards towards the project start seeking the longest path
back to the activity being considered.
Obviously, the latest finish time for activity H will be the duration of the project 16 days.
The latest start time can then be simply calculated by taking the activity duration away from
the latest finish time (LS = LF Duration). Therefore the LS for activity H is 14. If we now
consider activity G, the latest finish time for this activity will be the latest start time of the
activity following it. Therefore the LF for G is 14 which gives the LS of 10. Similarly for
activity F the LF will be 14 giving an LS of 10.
Moving backwards through the network we can now consider node D. As the late start time
for both of its successors is the same then it is clear that the latest finish time of this activity
is 10 and therefore its latest start time is 7. If we had the case where the LS of activities G
and F were different we would simply take the lower LF of the two activities. In the same
way we can work back through the network to complete the LF and LS of all the activities.
Activity 4.3
Before turning the page calculate the LS and LF of the remaining activities in the
project network.
PAGE 50
A
2
0
Float
2
Float
Float
10
10
Float
12
Float
14
14
D
7
Float
16
H
10
10
14
10
E
0
4
G
C
5
Float
16
14
F
10
10
Float
14
Step 8: Calculate Floats

The float of an activity is the amount of flexibility that there is in when an activity takes place.
We have used the term float here however some variation may be encountered in
terminology in further reading on this subject. Some textbooks use the term slack instead
of float whereas other texts have different meaning for slack
Consider activity C. It may start as early as the first day of the project, or finish as late as the
end of day 7. That is, provided the activity takes place within this 7-day period the project
completion time will not be jeopardised. Since the duration of the activity is only two days,
the timing of the activity can vary (or float) by 5 days.
This float, the activitys total float, is calculated as the maximum time available minus the
duration of the activity or more formally
Float = LS ES
or
Float = LF - EF
We can therefore easily calculate the total float for each activity and this is shown below.
0
A
2
0
10
7
5
C
5
10
0
12
14
14
D
7
10
16
H
10
14
10
E
0
4
G
16
14
F
10
10
14
The total float for activity D is calculated to be 2 days. However, it should be appreciated
that this float is shared with activity C. If all of activity Cs total float is consumed, either by
scheduling it for latest finish or by the activity taking longer than estimated, then the total
float of D will also be used up. The free float of an activity allows this to be quantified it is
defined as the amount by which the activity may slip, without affecting the total float of
subsequent activities. This information can be useful when scheduling or monitoring the
progress of non-critical activities.
PAGE 51
The total float and free float for each of the project activities are listed here.
ID
A
B
C
D
E
F
G
H
Activity
Clear site
Dig foundations
Procure foundation material
Transport machine
Install machine
Install electricity supply
Connect machine to supply and run
Float
Free Total
0
2
0
2
3
5
0
2
0
0
0
0
2
2
0
0
Step 9: Identify Critical Path

Notice that there are three activities (E, F and H) which have no float. They form the longest
chain of activities, the critical path, which determines the expected duration of the project. If
any of these activities takes longer than estimated, then the project completion time will be
extended accordingly. It is usual to highlight the critical path on the project network.
0
A
2
0
10
7
5
C
5
10
0
12
14
14
D
7
10
16
H
10
14
10
Critical Path
E
0
4
G
16
14
10
10
14
Often it is found that the expected project duration is longer than desired. If the project
duration is to be reduced to an acceptable time, the critical path must be shortened.
Typically this will be achieved by allocating additional resources to certain of the critical
activities, thereby reducing their durations. For example, activity F might be reduced from
four days to, say, three days by allocating more personnel to the activity, or possibly by
hiring more productive (but probably more expensive) equipment for the installation of the
machine. However, as we shall see, for a given reduction in project completion time, other
initially non-critical activities may also have to be shortened. Alternatively, after more
detailed consideration (i.e. finer resolution) of the critical activities it may be possible to
restructure the project to reduce its duration.
For our example we will use a combination of restructuring the project and allocating
additional resources. Such a technique is known as crashing and the cost analysis of this
is covered in detail later.
Restructuring the project
If any attempt is made to shorten the project it would be probably best to examine activity E.
It has a duration much longer than the majority of the activities and it lies on the critical path.
PAGE 52
When activity E is examined closely, it is found that it entails dismantling the machine into
major components (shown below), at the suppliers factory, before transporting them.
For the expense of an additional transport, the time for activity E can be reduced, as follows.
Firstly, dismantle the power unit (pu) and control cabinet (cc), which takes one day, before
transporting them, taking six days. When they arrive at the companys plant they can be
installed in two days. Whilst the power unit and control cabinet are being transported, the
machine frame (mf) and fixture (f) can be dismantled (two days). They can then be
transported (six days) and installed (two days). The project activity chart for this
restructured project is shown below.
Activity
Description
A
B
C
D
E1
E2
E3
E4
F1
F2
G
H
Clear site
Dig foundations
Procure foundation material
Dismantle PU and CC
Transport PU and CC
Dismantle MF + F
Transport MF + F
Install PU and CC
Install MF + F
Install electricity supply
run
Duration
(Days)
2
3
2
3
1
6
2
6
2
2
4
2
Immediate
Predecessors
Start
A
Start
B,C
Start
E1
E1
E3
D,E2
D, E4
D
F1,F2,G
Activity
Before turning the page draw the new network for yourself and check the durations of
the activities. Has the duration of the project changed?
PAGE 53
The restructured network is shown above. A new critical path has arisen (A-B-D-G-H), with
an expected completion time of 14 days, two days less than before.
Alternative dependencies
All of the networks developed up to this point have used the most simple type of
dependency which is referred to as the finish to start dependency. That is, for an activity to
start the previous activity must be finished. For many project activities this type of
dependency is suitable but at times it is useful to utilise alternative types of dependencies
and also to include leads and lags between the activities.
Step 10: Prepare Project Activity Chart
To assist in the scheduling and subsequent progress-monitoring of the project, a table of key
activity information can now be drawn up.
Activity
Dur
Pred
ES
EF
LS
LF
Float
A
B
C
D
E1
E2
E3
E4
F1
F2
G
H
2
3
2
3
1
6
2
6
2
2
4
2
Start
A
Start
B,C
Start
E1
E1
E3
D,E2
D, E4
D
F1,F2,G
0
2
0
5
0
1
1
3
8
9
8
12
2
5
2
8
1
7
3
9
10
11
12
14
0
2
3
5
1
4
2
4
10
10
8
12
2
5
5
8
2
10
4
10
12
12
12
14
0
0
3
0
1
3
1
1
2
1
0
0
PAGE 54
Free
Float
0
0
3
0
0
1
0
0
2
1
0
0
Step 11: Schedule Activities

It now remains for target dates to be set for the start and finish of each activity. For
example, activity C can start at any time between the beginning of day 1 and the end of day
3. Generally, activities are scheduled to start as early as possible (all other things being
equal), since any float available will then give the maximum protection if the activity takes
longer than was originally estimated.
Sometimes, particularly when very large capital investments are involved, activities may be
scheduled to finish close to the latest finish time. This risk is taken to save substantial
interest charges on the capital being invested. For example, a module of a nuclear power
station may cost many million of pounds, and its construction activities may have float
measured in years. Some activities may contend for the same scarce resources to carry
them out. It may be possible to ease this contention by scheduling some of the non-critical
activities to start somewhat later than the earliest start. This can be seen in the Gantt chart
which follows (Figure 4.22), where all of the activities are scheduled for earliest start, except
activity F2. This activity is scheduled to start at the beginning of day 11 to avoid contention
with activity F1, which requires the same category of installation personnel. This technique
is resource smoothing which is covered in more detail later in this session.
It is common to include the float on the Gantt chart to indicate which activities have the
potential to slip. This is shown below where the narrower lines indicate the float.
PAGE 55
In projects it is often necessary to impose constraints on specific activities. For example

there may be activities that cannot start before a certain date (for example availability of
equipment or resource) or activities that must be finished by specific dates (including the
overall project). Most project management software systems allow the inclusion of
constraints with MS Project offering start no earlier/later/on and finish no earlier/ no later /on
constraints. These can be used usefully although overuse of constraints in the planning
process can overly constrain the plan that you develop and limit the ability of the plan to be
flexed to optimise it.
Step 12: Resource Allocation and Smoothing
In the ideal world, when a project was planned, the plan would result in all resources being
uniformly utilised. However, projects are generally like the proverbial No 9 bus - nothing for
ages then three come along together. The result is that time is wasted when resources are
under-utilised, and projects run late because the resource is needed by three projects
simultaneously. The project manager does have a degree of control over this by considering
loading on each resource throughout a period. This would ordinarily be a laborious task but
has been considerably eased by the use of project management software.
The allocation of tasks to a project team can be eased by the use of a responsibility matrix.
Where there are clear skills requirements for tasks, these should be met first, with the less
constrained resources matched to the remaining tasks. A responsibility matrix is shown
below.
PAGE 56
Activity
Person
C
D
PX
T
PX
PX
PX
PX
X
X
10
PD
X
X
PX
PX
PX
D
I
X: Executes the task

D: Makes decisions solely
d: Makes decisions jointly
P: Manages progress
C: Must be consulted
I: Must be informed
T: Provides on the job

tuition
A: Available to advise
The previous sections have shown that the process of developing the plan so far have
entailed:
oEstablishing the WBS
oAllocate activity durations and resources
oPrepare a project network (AOA or AON)
oDraw a Gantt chart
oDraw a resource histogram
On the face of it the accomplishment of these steps should be straightforward but for
anything other than the simplest projects, it will not be as easy as that. It is inevitable that
there will be constraints. Having drafted the network in the most logical and cost effective
sequence it is possible that further examination of available resources will reveal shortfalls.
It may also be possible to aggregate and balance resources to minimise their utilisation
without affecting the Total Project Time (TPT). Adjusting resources so that the project
completion date can be met whilst respecting early and late values is known as Resource
Levelling. If, however, it is not possible to schedule activities within the constraints of
available resources while maintaining nodal earliest and latest values, extension of the TPT
may be inevitable. This process is known as Resource Restrained levelling.
During the early stage of the planning and estimating phase the required resources are
identified as part of the process of allocating estimated activity durations. The resource
PAGE 57
requirements are subsequently developed for the project; but this is based upon each
activity commencing on its earliest start date. It is however possible to balance resource
allocations by considering activities based on a later commencement date up to the latest
start date. This process is known as Resource Loading.
Resource levelling attempts to minimise resource-category fluctuations on a day to day
basis. Clearly, resource levelling is a stepwise process, undertaken in the sequence: Network > Gantt > Histogram
In order to demonstrate the process of resource levelling consider the following project
activity chart.
ACT
A
B
C
D
E
F
G
H
I
Duration
5
3
6
5
3
5
3
2
3
Dependencies
Start
Start
Start
A
A,B
D
E
F,G
C,G
Resources
4
4
4
3
2
4
3
3
3
Activity 4.3.b
In order to perform the process of resource levelling it is necessary to develop the
project network, the network calculations and the Gantt chart. If you feel unsure
about generating these please take the time just now to work through this project
following the process outlined earlier in the session.
PAGE 58
The activity on node network for the project is as shown below
H
B
From this network and the network calculations the Gantt chart can be developed as shown
below based upon earliest starts for all activities.
Activity
Day
9
10
11
12
13
14
15
16
17
A
B
C
D
E
F
G
H
I
Critical Path
Based on ES
Float
The resources required in this example are taken as being of the same type but further
columns could be added for further categories or resource; human, plant and equipment.
Within this example only one type of resource is considered for clarity.
Whilst the Gantt chart could have been drawn for latest start/latest finish, it is conventional to
address resource allocation on the earliest nodal values at this stage. Based upon the ES
for an activity the resource histogram is developed in the following way. For each day of the
project identify which activities (assuming ES) are active. Tabulate the resources required
on each day of the project based upon this information.
PAGE 59
Activity
A
B
C
D
E
F
G
H
I
Total
1
4
4
4
2
4
4
4
3
4
4
4
4
4
5
4
4
3
2
3
2
3
2
Day
9 10 11 12 13 14 15 16
12 12 12
17
4
3
3
7
3
7
3
7
The resource histogram is simply a graphical representation of this data (with the output
from MS Project shown below).
In order to illustrate the levelling process we make the assumption that a constraint is
imposed on the available resources of eight operatives. It is clear from the Resource
Histogram that the availability is exceeded. It is possible though to re-schedule the activities
within the nodal value constraints. Another observation from the first draft resource
histogram is that there is an under utilisation of resources on days 7, 8 and 9 and it may not
be possible to downsize the project team until day 10 and then re-establish the previous
level. Even without the over allocation of resource this uneven usage of resources is not
desirable for a number of reasons:
PAGE 60
oThe management of uneven resource loadings is significantly more time consuming

than the management of constant resources.
oStaff who work constantly on a single project are more likely to be productive than staff
dipping in and out of projects. This relates to both the amount of information that these
staff may have about the project (i.e. getting up to speed) as well as motivation issues
relating to ownership of the project.
oIt may well not be economical to have uneven loading of staff resulting from transport
issues (a significant constraint in the offshore industry), requirements for lengthy safety
inductions (in the Nuclear industry a site safety induction can easily last 3 days) or
through the increase costs associated with the use of short term contractors.
In order to start the levelling process we start by making the assumption that activities that
lie on the critical path are fixed both in terms of timing and resource allocation. They are
therefore put on the next draft of the histogram first, as shown.
9
8
Resource Usage
7
6
5
4
3
A
F
H
1
0
1
10 11 12 13 14 15 16 17
Day
Now consider activity B which has a float of 6 days, and must be finished by project day 9
and requires a total of 12 operatives (3 days at 4 per day). We can also make use of float in
activity C to move whole days worth of resources around (i.e. assume that the number of
resources required must be available on any particular day the activity is occurring). Doing
this (by moving B and C) gives at best
PAGE 61
Avaliable resource
8
C
7
Resource Usage
C
G
5
G
I
I
3
A
F
H
1
0
1
10 11 12 13 14 15 16 17
Day
The resulting resource histogram shows that the imposed resources constraint has still not
been met and in this example it will not be possible to achieve that without modifying some
of the non critical path activities and possibly some of the critical path activities also. Clearly
one viable option is to reconsider the work pattern for activity C. If two workers could be
used on 2 days to complete the work that will require 4 people for 1 day then it would be
possible to meet the resource constraints. A further method to attain the required resource
constraints is by extending the total project time (TPT) by a minimal amount. If we were to
extend the project by 1 day (giving a total project time of 18 days) the resource over
utilisation would be easily rectified.
To summarise, there will be two considerations to be accounted for when levelling
resources.
The project TPT must be adhered to, in which case the maximum required resources
allocation would require a degree of flexibility. This is Time-Constrained Levelling.
The available resources are finite and cannot be sensibly extended. When non-Critical
Path activities have been re-scheduled the only option left may be to extend Critical Path
activities with the attendant increase in TPT. This is known as Resource Constraint
Levelling.
PAGE 62
Step 13: Develop the S-Curve

A recognised method of measuring performance is by establishing a planned S-curve and
then plotting actual performance on the same graph. A number of choices are available as
to which variable is plotted on the S-curve. One of the most popular methods is to plot
percentage completion against project elapsed time. Other options include cumulative costs
and cumulative resource quantities both against project elapsed time. For example, the
project team may have cash flow data available to it. Consequently, if it is known how much
project resources cost and it is known know how much has been spent and at say week eight,
spending is more or less what was expected by week eight, it is clear that the project is
progressing satisfactorily. Consider the following graph generated from planned and actual
project data: -
Cumulative Project Costs

120
Time Now Planned
100
% Budget
80
60
`
40
Actual
20
0
0
10
20
30
40
50
Time (Weeks)
This is exceptionally good news for the PMT; or is it? The under-spend may be because of
delays caused by weather or lack of production and the programme may in fact be
substantially behind schedule. Therefore the graph may well be wrong. However it may well
be right. Consequently, all that can be said is that it provides inconclusive information that
can be addressed by the use of earned value analysis which is detailed in session 5.
Nevertheless, S-Curves can be an extremely useful tool to the Project Manger provided they
are not taken at first sight.
The following section describes in detail the steps that are gone through to establish an Scurve that shows planned values. The illustration is most easily presented by referring to a
Gantt chart; in this example case it is kept simple and minimal. The following project activity
chart describes the example project.
PAGE 63
ID
Duration
A
B
C
D
E
F
5
10
12
10
6
9
Predecessors
Resource
1
2,4
3
1
2
3
3
2
1
Man days
5
20
36
30
12
9
If we construct the Gantt chart for this project based upon the ES of each activity it is as
shown below. Attached to each day on the Gantt chart are the resource usage of that day
(this assumes that resource is used linearly across the activity) which allows us to calculate
the total resource usage for any day of the project and the cumulative resource usage for the
project.
1
1
2
3
2
1
2
3
3
1
2
3
4
1
2
3
a
b
c
d
e
f
Total Men Each Day
6
5
1
2
3
6
2
3
3
7
2
3
3
8
2
3
3
9
2
3
3
10
Day
11 12
13
14
15
2
3
3
3
3
3
3
16
17
18
19
20
21
2
1
2
1
2
1
2
1
2
1
2
1
24
30
38
46
54
62
70
76
82
86
90
94
97
10
0
10
3
10
6
10
9
11
2
Cumulative total
6
12
18
The cumulative number of man-days through time can be plotted as an S-curve as shown
below.
PAGE 64
120
Cumulative Resource USage
100
80
60
40
20
0
1
9 10 11 12 13 14 15 16 17 18 19 20 21
Tim e
It is obviously a simple task to convert this to a percentage usage of resource throughout the
project (to do this you simply divide through by the total resource usage which in this case is
112). It is also common to show S-Curves in terms of the cashflow of the project. This
allows the inclusion of procured items as wells as the resource usage. In order to illustrate
this let us assume that the resource available to the project incurs a cost of 225/day and
that on days 15 and 20 of the project payments are made, of 5000 and 12,000 to
subcontractors for delivery of materials. We can now generate the overall project S-curve
based upon this data as shown below.
PAGE 65
Project Day
Daily resource
Resource Cost
2400
2400
12
4800
4800
18
7200
7200
24
9600
9600
30
12000
12000
38
15200
15200
46
18400
18400
54
21600
21600
62
24800
24800
10
70
28000
28000
11
76
30400
30400
12
82
32800
32800
13
86
34400
34400
14
90
36000
36000
15
94
37600
16
97
38800
43800
17
100
40000
45000
18
103
41200
46200
19
106
42400
47400
20
109
43600
21
112
44800
PAGE 66
Additional Costs
5000
12000
Total Cost
42600
55600
61800
70000
Planned Project Cashflow ()
60000
50000
40000
30000
20000
10000
0
1
10 11 12 13 14 15 16 17 18 19 20 21
Time
The S-Curve as shown above is often referred to as the Budgeted Cost of Work Scheduled
(BCWS) and is used extensively in project control when earned value analysis (described in
session 4) is utilised.
Activity-On-Node (AON) Networks
There is an alternative to activity-on-node (AON) networks which is referred to as activity-onarrow network representation. The arrows represent activities, and the nodes represent
distinct events. The procedure is however similar to that already described. The figure that
follows is the AOA equivalent of the AON network presented for the restructured project
described earlier in the session. Notice that, with this representation, there are less arrows
however there is a need to introduce dummy activities (--- lines) to maintain the logic.
The choice between AOA and AON representations is likely to be a matter of personal
preference.
PAGE 67
Critical Path Method Summary

The extensive discussions above outline the process that you would go through in
developing a project plan based upon the critical path method. It is worthwhile noting that
the plan that you produce is only as good as the information you put into the plan and
therefore whilst the overall process is relatively simple, the actual development of the inputs
for the plan are more difficult than the actual development of the plan.
4.4.
PERT
The previous discussions have focussed on the use of the critical path method of project
planning. There are however a number of alternative methods of project planning including
the milestone plan methods described in session 2 and the technique called Programme
Evaluation and Review Technique (PERT).
In some projects, difficulty may be experienced in obtaining estimates of activity durations.
For example, the manager responsible for the research and development activities required
to launch a new product may be unwilling to commit to deterministic estimates. This is not
unreasonable, since these activities may involve the solution of problems that cannot be
foreseen at the outset. However, the same manager is likely to respond positively to the
following three questions:
oHow long is the activity likely to take if no unforeseen problems arise? (Optimistic
Time (a))
oHow long is the activity likely to take if everything that can go wrong does go wrong?
(Pessimistic Time(c))
oBetween these extremes what do you think is the most likely duration for the activity?
(Most Likely Time (b))
The PERT procedure then makes the arbitrary assumption that the activity duration exhibits
a skewed probability distribution, the beta distribution. This distribution is depicted below.
frequency
Most likely
optimistic
pessimistic
time
The mean of this distribution is taken as the expected activity duration, and is used in the
subsequent network calculations (as in CPM). In this context the mean is often referred to
as the expected activity duration and is given by
expected activity duration = (a+4b+c) / 6
variance = (c-a)2 / 6
PAGE 68
It is claimed that the variance of the project completion time is well-approximated by simply
summing the variances of the critical path activities. This assumes that the activity durations
are distributed independently of each other, which may be unrealistic in many
circumstances. For example, in a construction project many of the outdoor activities will be
influenced by the same adverse weather conditions. A common result of using PERT is
that the overall duration of the project becomes extended. This is the result of difference
between the pessimistic estimate and the most likely estimate being greater than the
difference between the most likely and the optimistic estimates.
Planning software is available to help with the application of PERT. MS Project has PERT
facilities but individuals are also encouraged to examine Pertmaster
(www.pertmaster.com).
4.5
Summary
This session has focussed on the detailed mechanics of developing a project plan using the
critical path method. You should however note that the development of a project network
and related Gantt charts and Histograms does not constitute the development of a full
project plan and within the completed plan there will be many other elements such as details
on progress reporting, project communication, knowledge management and the like. These
issues are dealt with in the context of developing a project execution plan in the next session
PAGE 69
Session 4 - Putting the Plan into Action
5.1.
Introduction
Session 3 outlined the stages involved in the development of a detailed plan for the work
which will be required to be undertaken in order to deliver the project. However this plan
(which will usually be captured within project management software) only represents one
element of the plan that is required for the project to progress smoothly. This session
outlines other issues that might be addressed during the planning phase which are aimed at
making the detailed plan work. For example document and risk management systems would
be regarded by the majority of project managers as being essential for project delivery,
however the details of the strategies which will be used to undertake these key activities
would not be included within the programme. This session is therefore developed around
the development of a project execution plan.
5.2 Project Execution Plans (PEP)

Project execution plans are documents that capture many elements about the project, some
of which are included within the more detailed plan developed in session 3. Whilst there is
no standard set format for a project execution plan (although many organisations do have
set standards for internal project execution plans) there are a number of common elements
within most project execution plans. The more common elements are described below.
5.2.1 Project Definition and Brief

The project definition and brief outlines the scope of the project as discussed in session 2.
This will typically be a high level summary of the project supported by detailed
documentation which will be present within other sections of the project execution plan.
5.2.2 Roles and Responsibilities

It is common within most project execution plans to provide an indication of the roles that
individuals will take on within the project. The inclusion of a section such as this has a
number of benefits. Firstly it provides clarity to all involved in the project as to who is
responsible for what. This should lead to improved staff performance (lack of clarity about
role is commonly cited as being detrimental to motivation) and empowerment of your staff.
Secondly, clarity regarding roles and responsibilities has benefits during the management of
issues as the role definitions should clearly state who should deputise for key roles during
times of emergency.
5.2.3 Quality Assurance planning

This element of the pan should outline the approaches taken within the project to manage
the quality. It will commonly build on company wide procedures which may be adapted to fit
with the specific context of the project.
5.2.4 Safety Management

On every project there will be a requirement to produce a safety management plan. Many
companies will have generic safety procedures but what the project execution plan should
do is to tailor these procedures for the project. For example, if the project involves working
in contaminated areas of a plant, the safety procedures relevant to working in contaminated
areas should be included within the plan along with site specific details.
PAGE 70
5.2.5 Human Resource Management

If we think back to Session 1 and recognise that issues relating to human resources are
important for organisation success then it is clear that a project should think about how it is
going to manage its human resources. Issues which might be covered within the human
resource elements would include recruitment of staff, training and development of staff, team
development (team building) and performance management. Some of these issues will be
of greater importance than others depending upon the nature of the industry within which
you are operating. Where the number of contract staff is high the focus is likely to be on
recruitment and performance management, whilst in projects primarily resourced from
permanent staff training and development are likely to be regarded as higher priorities.
5.2.6 Communication Management Plan

In projects with many stakeholders and large project teams it is beneficial to have
considered how you are going to communicate with the stakeholders throughout the project.
This is discussed further in session 5 and therefore will not be discussed in any great detail
here.
5.2.7 Information and Knowledge management plan

The PEP should specify how information on the project will be managed and how the
maximum benefits of knowledge development can be obtained through careful management
of the project. Information management in the form of document control is discussed later in
this session so is not discussed here but it is worth spending a few minutes considering the
capturing of knowledge on projects. Knowledge can be differentiated from information on
the basis that knowledge requires learning takes place when information is translated into
knowledge. For example this document is information until you read it at which point it
becomes knowledge where your specific context and viewpoint will shape your knowledge.
To capture knowledge you need to not only capture the documents but also the tacit
knowledge which is the knowledge which resides within individuals and is not often written
down. To check this as a concept think about how much of what you know you have ever
written down? Therefore knowledge management processes do not only involve document
management systems but also process such as work shadowing, team development events,
and workshops (such as lessons learnt and risk). This is a topic which is dealt with in more
detail in a later module.
5.2.8 Programme and cost management plan

These elements of the plan deal with the more standard project management elements of
the project. What does the programme (effectively the document developed through the
process described in Session 3) look like and how is the project going to be controlled
against the schedule and the project budget. This document will outline process relating to
project reporting and detail the control measures in place to ensure budget compliance.
This plan will also detail how any changes in scope are to be managed as discussed in
Session 2.
This initial plan is commonly referred to as the baseline plan and as such the baseline plan
should remain fixed throughout the project. There is often a temptation on projects for the
plan to be continually updated and modified in such a way that the project is always on
schedule and budget because the goalposts of the project continually move. There are a
number of issues which need to be considered within the plan for management of the
baseline:
PAGE 71
If the project is running significantly behind schedule or over budget then sticking rigidly to
the baseline plan may become very de-motivating for staff on the project. If you think about
a team working on the project and they continually find themselves meeting targets and
deadlines it is going to be very demoralising. When significantly behind budget and
schedule the original plan may also not be useful in providing accurate control due to it not
reflecting what could now be achieved. In this instance the project manager may choose to
put into place a new plan for control and monitoring of the project. However the baseline
configuration should be remembered as this will indicate the performance of the project
against the original objectives.
Often new work and scope may be added to the project. This will have an impact on the
plan in that the new work is likely to lead to increased costs and project duration. When
adding this additional work the aim is to not modify the baseline for existing work but to
reflect the new scope within the original baseline framework.
The baseline plan will usually be utilised for cost control on the project. Where the plan is
modified (i.e. changing hours/resource between activities) the plan should be updated to
reflect this as otherwise there is the potential for overspend on the original activities to which
the budget was originally allocated.
5.2.9 Risk Management Plan
Risk plays an integral part in project management and the effective project manager is the
manager who effectively manages the risks which arise as the project progresses. The risk
management plan will typically consist of the risk register and supporting documentation
which detail the expected project risks and how these risks will be managed throughout the
project. A typical risk register will include the following information:
Description of the risk
The owner of the risk
Priority (which may be linked to an impact and likelihood rating)
Mitigation strategy which should include what should be done, by whom and by
when.
Actions undertaken to control the risk to date
Next review date for the risk
The details of the risk management plan will vary depending upon the scale of the project
from simple risk identification and prioritisation through to the use of software tools to
analyse the risks inherent in the project.
5.2.10 Contract and procurement plan
The contract and procurement plan details how the contractors on the project will be
managed (for example who is responsible for delivery of contracted elements) and how
procurement is to be managed. This might include elements such as the processes for
management of subcontractors through to detailing of the processes to be used in procuring
items (for example the use of reverse auctions or pre-qualification processes).
5.3 Benefits of PEPS

Each of your own organisations will define PEPs differently and you may find extra areas are
added to the PEP with other areas excluded.
PAGE 72
The above discussion regarding the development of a project execution plan may at first
pass appear to add significant amounts of paperwork to the delivery of the project and could
be argued to add little value. The key benefits of PEPs actually accrue from the process of
developing the PEP and the thought process which the development of a PEP will require.
For example, many projects suffer from a syndrome which could best be referred to as
ready, fire, aim where the project gets under way without developing coherent plans for
anything unrelated to the actual task. The process of developing the PEP should help
resolve issues regarding the management and execution of the project at an early stage in
the project before mistakes are made. It also provides a useful communication tool with
which to engage team members.
Some key elements of the PEP are likely to change as the project progresses. For example
at the outline bid stage the PEP is unlikely to be sufficiently detailed to encompass all the
required elements at a level of detail that would be used whilst the project is being executed.
This detail would be added as the project progresses and therefore the PEP should be
regarded as a live document which evolves as the project progresses.
Activity 5.3
Examine the development of project execution plans within your own organisation.
What elements are included in the project execution plans and which of those listed
above are not? How well maintained are the PEPS? If you were to make
recommendations based upon the discussion above regarding the PEPs within your
organisation what would they be??
5.4 Document Control

One key element of project implementation is ensuring that a coherent and robust document
control systems is put into place to manage the documents that are developed on the
project. Controlling the documentation is essential for a number of reasons including:
5.4.1 Ensure Correct Version

Ensuring that individuals are working with the correct version of a document.
Most people will have experienced a situation in which they have utilised an out of date
document. For example on a recent consulting project the author of these course materials
was supplied an out of date product drawing by the client and it was only after several days
effort (and an initial report) that the client noted that the product in the report did not
resemble the current product!
5.4.2 Ensure Availability of Correct Version

Ensuring that the project documentation is readily available to those who require it so that
they do not waste time waiting looking for documentation.
If information is located where only one individual can obtain it (for example an individual
hard drive) then there is an inherent risk that the information will not be available to the
whole project team, which in the case of illness or technical failure, could delay the delivery
of the project.
PAGE 73
5.4.3 Authorisation of Changes

Making sure that only specified individuals can change specific documents.
For example changes to scope documents and programmes will often require authorisation
from a senior member of the team prior to reissue.
5.4.4 Audit Trail of Document Changes

The provision of a clear audit trail and reduction in disputes relating to issuing of incorrect
documentation.
In many organisations there is an expectation that an audit trail will exist which will capture
the development of the project. Document control systems allow for the documentation
within the project to be captured and to provide this audit trail. This audit trail can be useful
if there are disputes surrounding documents (such as the issue regarding the product
drawing described above) as without a clear system tracing documentation can be difficult.
Provision of a clear audit trail is especially important for projects involving joint ventures or
those performed within the public sector. In these cases the auditing of the project will have
more impact than an internal review of project progress.
5.4.5 Knowledge Management

The information (and to some extent the knowledge) developed on the project will often be
represented through the documents developed on the project.
These documents give the organisation a useful source of information from which to build
knowledge and develop increased competitive strategies and thus a coherent document
control process can aid this information and knowledge development process. For example
a coherent document strategy should allow future projects to obtain information (e.g. risk
management plan) for previous projects to be obtained easily.
5.4.6 Document Control & IT Systems

With the increasing use of IT the storage of documentation is no longer dependent upon the
use of paper archives and the document control process can be streamlined through the use
of IT systems.
These IT systems however create problems of their own and thus setting up a document
control system should not be regarded as something that can be left to chance.
5.5 Choosing a document control procedure

The approach taken to manage documents on projects will vary significantly depending upon
the organisation and the nature of the project. For example on a small project a suitable
document control procedure may involve a central (shared) directory with a clear structure in
which documents are stored. If using this approach there are a number of issues which
should be addressed including developing a document register, standard templates and
document naming conventions. At the other end of the scale, on large projects, the
document control process may involve dedicated project document controllers whose role on
the project is to manage the documents developed by the project. Often where dedicated
documents controllers are employed, IT based document management systems are utilised
http://www.tokairo.com/,
http://www.documentum.com/
and
(for
example
see
http://www.isixsigma.com/offsite.asp?A=Fr&Url=http://www.qualitydigest.com/feb00/html/doc
bg.html).
PAGE 74
Activity 5.5
Examine how your organisation goes about managing its documents. What methods
does it employ at present?
5.6 Key information required for Document Register

If we pick up on a couple of the issues described previously, namely the document register
and the standard document templates then it is useful to consider what should be included
within these. Standard documents should contain a number of key pieces of information:
The author (Document Custodian)
The project to which it pertains (i.e. the Project)
The type of document it is.
A unique registered identification mark
The date of issue
A revision identifier
This information should ideally be included within the document register. Within the
document register it is also a good idea to have a more detailed description of the document
(i.e. more than a file name) in order to help other members of the project find the relevant
documents when required.
5.7 Configuration Management

An extension of the concept of document management is configuration management. This
not only tracks the products (and as such documents are considered products of the project)
but also the impact that one product has on other elements of the project. In order to
explore this let us consider the case of designing an engineering product consisting of a
number of components. If we change the drawings of one component then it is likely that we
will need to change a number of other drawings. Within configuration management the
control system not only records the information held within the document control system but
also reflects the items that need to be updated when an element of the project changes.
Therefore in the case of designing an engineering product, in a configuration management
system, the drawings which would need to be changed as a result of changing a drawing
would be recorded in the system as the configuration items associated with the drawing that
was changed as shown in the table below.
Configuration
item
DRWG/BC160
3
Current
Version
Rev 4
Owner
Impacts on
RH
SCHED/PJ98
Rev2
SB
DRWG/XC234
DRWG/XC237
SCHED/PJ98
BUD/PJ98
QPLAN/PJ98
For more information on configuration management you may want to visit

http://www.icmhq.com/ which details configuration management models and provides
examples of implementation.
5.8 Managing resources across the organisation
PAGE 75
One of the greatest challenges with projects is that many of the tools described so far
assume that there is only one project operating at anyone time within the organisation. For
the vast majority of organisations this is not the case with many projects operating in parallel
with each other. When you have multiple projects operating in parallel there is a need to
manage your resources in a manner which not only maximises the utilisation of the resource
but also the effectiveness of that utilisation. Maximisation of utilisation is concerned with
ensuring that all of the staff are producing useful work on a project (or the resources
functional responsibilities) at any given time. Effectiveness of the resource utilisation relates
to not only ensuring that each resource is allocated but that the resource is the best
resource for the job.
The challenges that project managers will face within the organisation in achieving the goals
of maximised utilisation and effectiveness will depend upon the nature of the organisation.
In organisations with large projects the resource may be dedicated to the project and this
therefore reduces one of the degrees of complexity in resource utilisation. However, many
projects are likely to share resource with other projects and in these situations the resource
utilisation problem becomes very complex.
Activity 5.7
Examine how your organisation goes about managing its resources over multiple
projects. How does your organisation manage the resource pool across multiple
projects? What problems are there in the management of the resource pool? How
might these problems be overcome?
Some of the issues that you might have identified could include:
The organisation does not fully understanding its resource pool in terms of
capabilities and how the resource pool could be better utilised. One method, which is
commonly utilised, is the development of a skills database (based around clearly
defined competencies) which allows the project manager to select resources with the
capability to undertake the required tasks.
No processes and systems being in place to track overall resource utilisation within
the organisation. For example an organisation which does not use time sheets or
where the discipline surrounding what you book your time to is lax, may have no
formal system in place to manage resource utilisation.
The problem can appear so complex that the organisation does not have the in-house
knowledge and capability to implement a system. For example in order to optimise the
resources over multiple projects, complex computer algorithms are required and even with
the use of these algorithms there is no guarantee that the resource usage can be optimised.
Cultural issues surrounding senior members of staff protecting their own resource pool and
not willing to share it with other members of the organisation. This is commonly referred to
as empire building and can result in staff not being released to work on a project even if
they are not being effectively utilised. This is sometimes overcome by dedicated processes
to help the project manager obtain the required resources. However, the most common
method of resolution involves negotiation between individuals within the organisation.
Computer models which are developed to aid resource optimisation therefore only provide a
first pass optimisation and release of resources may require further effort by the project
manager.
Perhaps the greatest challenge that organisations have in terms of managing multiple
projects within the organisation is in the development of a smooth interface between the
PAGE 76
project planning tools and the overall organisational systems. One approach to overcoming
this problem is through the development of an integrated management system which aims to
link the project management planning system (such as MS Project and P3) to an
organisational wide resource pool as shown below (adapted from Turner).
Client
Requirements
Resource
Pool
Planning
System
Resource
availability
Management
Systems
Whilst in graphical form the system would appear to be relatively simple the challenge is that
the linkages in the systems will usually be specific and unique for any given organisation and
as such many of the integrated project management systems which have been developed
are bespoke to specific organisations. Exploring this topic in more depth through examining
the particular issues for your organisation is one of the options for the final assessment of
this module.
5.9 Summary
Defining how the project will be managed across a wide spectrum of management areas
coupled with a cohesive document control system will not only aid the planning of the project
but also the execution of the project. Within the development of these plans it is not only the
output of the process (the project execution plan) that is important but also the thinking that
occurs within the development of the project execution plan. Within this phase of the project
it is also important to consider how the project will interface with other elements of the
organisation especially regarding resource utilisation. This interface may require the
development of a bespoke integrated system to maximise the performance of the
organisation as a whole.
PAGE 77
6 Session 5 Project Control

6.1.
Introduction
The previous sections of this module have so far focussed on the estimation and planning
phases of the project lifecycle. This session focuses on the implementation phase of the
project and the necessity for clear project control methods. The aim of project control is to:
Review actual performance and performance trends to analyse cause and effect.
Forecast and evaluate potential variations prior to their occurrence so that preventive
action can be implemented.
It is therefore important to consider issues including progress reporting, data analysis and
decision making in order to ensure adequate control and successful completion of the
project.
The project control cycle can be regarded as a continuing loop consisting of three key
elements.
Measuring. It is important to have a system in place which allows for accurate
measurement of progress and performance. This measurement system should be capable
of indicating when variations are occurring against the plan and allow for corrective action to
be taken.
Reporting. It is essential to have a system in place to report progress to the wider project
community. This reporting system will allow dissemination of information regarding progress
to the project team and key stakeholders.
Control Actions. If variations to the plan are noted then it is important to be able to take
actions in order to maximise opportunities that may arise and to reduce the issues
surrounding poor progress.
This session considers the first two elements with the control actions being discussed in the
final section of the course.
6.2.
Measurement of progress
The process of progress reporting is essential to the project management process in order
for the project to be controlled effectively. The aims of the progress reporting process are to:
Identify activities which are slipping
Identify areas where additional resource might help
Identify unexpected conflicts on resource
Keep critical activities on track
Monitor project costs carefully
Enable the project plan to be updated when necessary
The first challenge to address when setting up a progress reporting system is to identify how
you are going to capture the data that you require to control the project. Too much data will
leave the project management team drowning under piles of paper with insufficient time to
input the data to the system. An alternative scenario is where the PMT is given insufficient
data to make an informed judgement of the progress of the project. It is therefore important
to balance the levels of data provided with the usefulness of that data. In considering the
amount of detail required in progress reporting it is also important to consider the financial
impacts of progress reporting as too much data collection will obviously have significant
costs to the project which are not reflected in the benefits accrued to the project. Some
standard approaches to progress reporting include:
PAGE 78
6.2.1The use of data capture proformas.

The proformas should be structured in a similar way to the initial time estimating proforma or
work breakdown structure to ensure:
Improved accuracy. If the task is reported directly against the WBS then the
accuracy of reporting should be enhanced. If reporting occurs against multiple
activities then problems within specific activities could be hidden by this global
reporting approach.
less scope for misinterpretation as it reduces the problems of booking work against
alternative WBS codes
6.2.2 The use of written reporting.

On many projects there is a tendency to report progress in an ad-hoc manner often through
verbal reports. Whilst this provides some means of progress measurement it is preferable
that progress is reported in writing as:
It eradicates the problem of forgetfulness. If progress is reported verbally then a
written record should be made of this.
Again there is less scope for misinterpretation as a formal record is put in place.
Indeed human psychology is often such that individuals may over report progress
verbally but when asked to commit to this to paper are less likely to over report.
For many projects the client will have the ability to request to see the project
documents, for example on reimbursable projects and on projects involving joint
ventures. Depending upon the sector the requirements for reporting will differ and
with stringent requirements for reporting on public service contracts. Therefore
providing progress reports in writing provides a clear audit trail.
6.2.3 Asking the right questions

When developing the progress reporting methods the question that you are asking should be
pertinent and relevant, as it is important to obtain the buy in of the project team in the
progress reporting process. If the PMT view the questions as irrelevant they will be less
motivated and committed to the reporting process. Within this it is also important to ensure
that staff understand why the information being collected is being collected. If they do not
understand the end use of the data (for example forward planning resources over multiple
projects) then it is unlikely that will take the necessary care when developing progress
reports.
6.2.4 Accuracy of reporting

A higher level of accuracy is required for activities on the critical path as rapid identification
of problems with these activities allows a better chance of bringing the project back under
control.
6.2.5 Knowledge capture

Whilst assessing the degree of progress and spend relative to the budget provides key
elements of any progress reporting mechanism it is also important to capture knowledge (the
whys) relating to deviations from plan in order for the project to benefit the organisation in
the longer term.
6.2.6 Timely capture of data

It is vital that the data is obtained in a timely manner. If information is collected on a weekly
basis for a fast track project of only 15 weeks duration the project could be 7% behind
schedule before the project manager is aware of any problems! One approach to reduce
PAGE 79
problems relating to the late arrival of information is the use of daily meetings to capture the
important elements on projects. Whilst the prospect of a daily meeting may put people off,
the approach taken within lean project management is to have short (10 minutes maximum)
meetings every morning to capture progress and to discuss issues. This addresses
problems associated with long scale deadlines and has been used within a number of
organisations to great effect.
6.2.7 Highlight reports

One approach to progress reporting is through the use of highlight reports. This approach
which is used extensively within the PRINCEII methodology, focuses reporting on activities
which have gone better and worse than planned. This allows the progress reporting efforts
to be focussed on these activities and offers potential benefits in terms of capturing more
knowledge about these elements.
6.2.8 Management of reporting

Many of the issues described above are now managed by integrated and web based project
management systems. For example Microsoft Project can be mounted in a web based
environment allowing individuals to directly report progress on the system. Whilst these
systems address many of the mechanistic elements relating to progress reporting (i.e. the
effort of inputting progress into the plan) it is important to consider how you are going to
utilise these systems, what is the required information to be captured and when the reporting
should take place.
6.2.9 Evaluation of progress

When evaluating the progress of a project it is important to view the data that is provided
with some degree of scepticism. How often when you have been asked Have you finished
it yet? have you replied very nearly when there is in fact a lot still to complete.
Overestimating the amount of work completed is a fact of human nature and therefore a
number of approaches are commonly used when assessing the progress:
The activity can only be 75% complete prior to it being 100% complete. This
technique avoids the problem of activities being reported as very nearly complete for
long periods of time.
Another common technique is the 0 50 100% rule. If the work has not been
started it is obviously 0% complete. When it actually starts, no matter if it is 10% or
90% complete it is reported as 50% complete and only moves to 100% complete
when it is actually signed off. Whilst this may seem crude, on projects where there
are many activities happening in parallel the averaging process will result in a
reasonable estimation of the actual position of the project. This also prevents
individuals focussing in to great detail in estimating accuracy of progress (e.g.
86.92% complete) when for each activity all that is actually required is an
approximate estimate.
Appropriate methods of data collection will allow the project manager to illustrate progress in
a number of formats. One very commonly method utilised for illustrating progress is to use
the project Gantt Chart and highlight on this the progress to date. This is illustrated below
for a plan developed using MS Project.
PAGE 80
Whilst this approach to showing progress is visual and readily understood by most
individuals it is subject to a great deal of interpretation. For example if one activity is behind
schedule and another activity is ahead of schedule what is the overall progress on the
project? This problem is exacerbated when the activities outlined on the detailed plan are of
different values, effort and duration. If this is the case interpretation of the overall progress
from a reporting Gantt chart is extremely difficult. Similarly if progress is measured against
the project S-curve there are subjective decisions to be made as discussed in Session 3.
What is required is therefore a more systematic method to assess overall progress and this
is offered by the Earned Value technique.
6.3 Earned Value Analysis (EVA)

Earned value analysis is a process that normalises progress against the planned progress.
To start to get to grips with EVA first of all consider the example below:
Activity 6.3
A company has been awarded a contract to replace the glass in 20 bus shelters. The
estimated cost of replacing the glass is 2000/bus shelter with a schedule of 2 bus
shelters per day. The overall budget of the project is therefore 40,000 with a
schedule estimate of 10 days (this assumes no learning curve effects).
5 days through the project the project team reports that they have spent 20,000 of
the project budget. This would imply that the project is 50% complete as they have
spent half of the project budget. However when you ask how many bus shelters they
have completed you discover that they have finished 8 of the bus shelters.
Within earned value analysis the Earned value completed by this project is 16,000.
That is 8 bus shelters at 2000 per shelter. This earned value can then be used as
the basis of the analysis of schedule and budget.
Examining the earned value against the scheduled value indicates that the project is
behind schedule and comparison against the actual costs reveals that the project at
this stage is 4,000 over budget.
Whilst the example provided is very simple a similar approach can be used to evaluate
progress on much more complex projects with many simultaneously ongoing activities. This
formalised process is known as Earned Value and the calculation procedure is outlined
below. It is first worth differentiating between the level of effort and the measurable effort on
the project.
PAGE 81
Measurable effort focuses on discrete activities with a defined period for completion with the
project management plan which upon completion produces tangible results. Level of effort
focus on activities which do not lend themselves into subdivision into discrete, planned
increments of work. The effort for these activities is generally ongoing and / or spread over
several of the "Measurable Effort" category of activity. Examples include project support
activities and project control activities.
The earned value analysis definitions that follow refer to "Measurable Effort". The "Level of
Effort" which accompanies these activities can be included or not, provided a standard
approach is adopted throughout.
The earned value analysis can be performed on:
The entire project
A work package forming part of the project
An individual task
A group of selected tasks such as
All those tasks for a particular discipline
All those tasks in a particular area

In the development of earned value analysis calculations it is useful to develop a standard
list of definitions for use in the calculations. The basic parameters utilised are outlined
below.
BCAC
BCWS
PC
BCWP
ACWP
Budgeted Cost At Completion

The total budgeted cost of an activity when it is completed
Budgeted Cost of Work Scheduled
Budgeted amount of cost for work scheduled to be performed in a
given period. This is the value shown on the baseline project Scurve.
Percentage Complete
How much of the work on a given activity which has been completed
Budgeted Cost of Work Performed
Budgeted amount of cost for completed work within a given time
period.
This is sometimes referred to as Earned Value. It is
calculated from an estimate of the percentage completed (PC) of an
activity and the BCAC.
BCWP = PC x BCAC
Actual Cost of Work Performed
Amount reported as actually expended in completing the work
accomplished within a given time period.
It is useful to note where the data for these activities stems from. The BCAC and the BCWS
are defined during the project planning process and as such refer to the baseline planned
costs for the activities. It is obviously imperative that the progress reporting system which is
put into place captures the costs incurred on the project (the ACWP) and the Percentage
Completed to date. This can present problems in project control as there may be significant
lags between the actual costs being formalised (for example through submission of the
invoice) and the costs being incurred at a project level.
PAGE 82
Having collected the data it is necessary to analyse the data to make decisions based upon
this data. The simplest approach is to compare the BCWS with the BCWP. This
comparison will indicate if the project is ahead of schedule (BCWP > BCWS) or behind
schedule (BCWP< BCWS). Similarly the comparison of the ACWP with the BCWP will
indicate the budget position (ACWP>BCWP then over schedule).
In order to formalize this comparison process there are a wide number of variances and
performance indicators which can be calculated as described below.
6.3.1Time variance (TV)

This is the difference in time between the Status Date (i.e. the date at which the information
has been gathered) and the time at which the BCWS is equal to the BCWP at some future /
past status date. It is therefore a measure of how late or early a project is running and gives
an impression of how the project is moving compared to its schedule.
6.3.2 Accounting Variance (AV)

This is the difference between the budgeted cost of the work scheduled and the actual cost
of the work performed to date. Whilst the accounting variance does shed some light on the
position relative to budget it is not actually a useful reporting measure as it measures the
spend relative to the schedule and not to the actual work performed.
BCWS
Accounting Variance
ACWP
Time Variance
BCWP
time now
time
6.3.3 Cost Variance (CV)

The cost variance is a measure of the difference between the BCWP and the ACWP and
gives a much better indication of the financial performance of the project than the accounting
variance.
CV
BCWP ACWP
If the cost variance is positive then the project is below budget (i.e. performing well) whilst if
the cost variance is negative then the project is over budget. This is a much better
measurement of the performance than the AV.
PAGE 83
6.3.4 Schedule Variance (SV)

The schedule variance is the difference between the BCWP and the BCWS.
SV
BCWP - BCWS
If the SV is positive then the project is ahead of schedule, whilst if the SV is negative then the
project is behind schedule.
BCWS
Cost Variance
ACWP
Schedule Variance
BCWP
time now
time
6.3.5 Earned Value Performance Indicators

The variances described above are represented as costs or in the case of time variances,
actual project days. Whilst these figures are useful it is common to convert these variances to
percentage values in order to produce simply interpreted statements. The two standard
performance indicators are the schedule performance indicator (SPI) and the cost
performance indicator (CPI).
CPI =
CV
BCWP
SPI =
SV
BCWS
It is common practise to track the performance indicators over the project duration. It is usual
to find that at the start of the project that the indicators will vary significantly but over time they
will usually settle down and provide a good representation of the project performance. Within
the performance indicators the project manager will be looking for trends. For example if the
CPI is consistently less than one then this would indicate that the project is likely to deliver
over budget. If the CPI constantly reduces then there is a chance that an element of the
project had not been included in the project estimate or that a specific element of the project is
consistently under performing. Through analysis of the CPI / SPI at the overall project and
activity level the project manager should be able to identify areas where interventions are
required in order to bring the project back on schedule or budget.
PAGE 84
You should be careful when calculating the CPI/SPI for the overall project that you do this
based upon the sum of the BSWP,ACWP and BCWS of each activity. If you take the
approach of averaging the CPI and SPI over a wide number of project activities you are likely
to distort the true project CPI/SPI as the size of the activities would not be reflected in the
averaging process.
Activity 6.3.5 Earned Performance Indicators

Thinking about a project which you have been involved in and decide what elements
are likely to cause the CPI and SPI to vary. What situations are likely to result in an
CPI/SPI of greater or less than 1? Post your thoughts on this in the WebCT forum.
6.3.6 Worked Example

As a simple example of Earned Value Analysis consider the following information.
Activity
100
200
300
Total
BCAC
100
400
1200
1700
BCWS
100
400
800
1300
PC
100%
75%
90%
BCWP
Status
To calculate the BCWP we simple multiply the percentage complete (PC) by the BCWS.
Doing so gives the following results.
Activity
100
200
300
Total
BCAC
100
400
1200
1700
BCWS
100
400
800
1300
PC
100%
75%
90%
BCWP
100
300
1080
Status
To determine the schedule status at any given time compare the BCWP with the BCWS (you
are effectively calculating the SV). It can be seen that:
Activity 100 is complete.
Activity 200 is behind schedule as the BCWP is less than the BCWS (SV<0).
Activity 300 is ahead of schedule as the BCWP is greater than the BCWS (SV>0).
If we calculate the BCWP of the project as a whole it can be seen that the BCWP is 1480
and therefore overall the project is ahead of schedule.
Activity
100
200
300
Total
BCAC
100
400
1200
1700
PAGE 85
BCWS
100
400
800
1300
PC
100%
75%
90%
BCWP
100
300
1080
1480
Status
Completed
Behind
Ahead
Ahead
The use of earned value analysis gives the project manager the opportunity to look ahead
and based upon the performance indicators assesses the final costs of the project. The
simplest way to do this is to use the overall project CPI and SPI to calculate the final cost of
the project using:
FCAC =
FPT =
BCAC
CPI
EPT
SPI
where FCAC is the forecast cost at completion of the project, FPT is the forecast project
duration and EPT is the estimated project completion (based upon the baseline estimate).
Whilst these calculations can be useful they do provide make a number of assumptions:
That the project will continue to perform as it is currently doing. Therefore if there is a trend
within the CPI/SPI the analysis will not take this into account. A more complex method of
estimating the CPI/SPI would be forecast based upon any trends in the CPI/SPI the final
CPI/SPI and based the calculations based upon this.
With the lags in reporting the forecasts may not take into account any recent activity on the
project and will not take into account any recent decisions that the project manager may
have taken.
PAGE 86
Activity
The project costs associated with a project have been identified and are tabulated in
the table given below. From these costs develop the S-curve for the project.
Project Month
Direct Costs ()
Manpower
(Hours)
1
100,000
700
2
60,000
500
3
70,000
600
4
40,000
400
5
20,000
600
Manpower
is charged0at an average of 351000
/ hour
6
Overhead
costs
are
35%
of
manpower
costs.
7
0
1000
8
10,000
800
9
5,000
300
Usage
As project manager you have been collecting data on a monthly basis relating to the
progress of the project and you have collected the following information for the
project up to month 5. Calculate the CPI / SPI for the project. From this data analyse
whether the project is under or over performing and trends in the project
performance. Do think the project is going to come in on/over budget? Estimate the
final project cost.
Month
1
2
3
4
5
BCWP
133,000
200,000
280,000
360,000
440,000
ACWP
120,000
190,000
290,000
370,000
480,000
6.4. Other Performance Indicators

More and more within the project environment there is a drive to measure more than can be
obtained from earned value. Earned value methods give good insights into budget
performance and schedule (through for example the use of the performance indicators CPI
and SPI). If we think back to Session 1 it is clear that the definition of project success is
much wider than just budget and schedule and therefore it is necessary to have other
performance indicators which relate to the elements of the organisational strategy. So what
might these performance indicators be?
PAGE 87
Activity
Think about the organisational success factors which you identified in Session1. How
might these organisation success factors be translated into a project performance
indicator? What challenges may you face in developing these performance
indicators?
In trying to answer the questions in the last activity some of the performance indicators that
you might require would be measures relating to:
Cost
Schedule
Safety
Project profitability
Risk measures
Human resource issues
Development of knowledge
Customer satisfaction
Environmental performance
In thinking about developing performance indicators to measure these you may have come
across a number of issues:
The more performance indicators that you include in a project, the more effort you
will need to expend on measuring these performance indicators. Within each
organisation there will be a balance between the usefulness of the information
compared with the cost of developing the information.
Some of the measures may be relatively objective. For example performance
indicators relating to safety and environmental performance could be expressed as
the number of incidents in standard categories relating to the severity of the incident.
Similarly cost, schedule and profitability should be readily measured. However
issues such as HR issues (e.g. team morale) and customer satisfaction will often
require a more subjective approach to measure performance. This subjective
approach can cause problems in that by its nature it is open to interpretation.
Measures can be taken to make these subjective measures more objective (e.g.
customer satisfaction surveys, staff climate surveys) but again the cost of
implementing these can be prohibitive.
As the project environment changes, with different emphasis on success, it is likely
that these wider performance indicators will permeate through more and more
projects. It is not unheard of for some projects to have over 40 performance
indicators and within these it is inevitable that there will be a hierarchy with some
indicators being more important than others. This leads to the separation of Key
Performance Indicators (KPIs) and other performance indicators. As a general rule
of thumb you should avoid having more than 15 KPIs on a project.
PAGE 88
Another issue to consider is whether the indicators that you are using would be classed as
leading or lagging indicators. The simplest way to think about leading and lagging indicators
is to consider the following two performance indicators:
% of safety risk assessments performed
Number of safety related incidents
The first of these indicators would be regarded as a leading indicator in that it will indicate
the potential future performance. A high result on this indicator would be likely to lead to a
low number of incidents and as such this indicator can be used to estimate future
performance. The second indicator tracks performance of events which have occurred and
as such only records historical performance. It is useful to have leading indicators as these
can prevent poor performance on the project if monitored carefully.
6.5. Project Reporting

The use of earned value and performance indicators allows the project manager to collect
information about the status of the project. Having collected this information it is important
that there exists a structured process for disseminating this information to the various
stakeholder groups. It is likely that each stakeholder group will be interested in different
elements of the project and therefore the reporting should be tailored to the different
stakeholder groups. For example the project team will benefit by having a degree of detail
within the reports produced. It is however unlikely that senior management will require this
level of detail and as such an overview of performance should be sufficient in most cases.
So in developing the reporting mechanism it is important to think about:
How frequently do I need to communicate progress to this stakeholder group and
what should this communication include?
What does the project hope to achieve through the communication? This might
include increased stakeholder buy in, visibility and support of the project within the
organisation and the increased motivation of project staff.
What format is most appropriate for disseminating the information? How much are
individuals going to read and how might this information be best conveyed?
The format you choose for project communication may range from short meetings with the
project team on a regular basis through to more formal engagement processes for local
communities where the project may have a significant impact (e.g. decommissioning of a
Nuclear power station).
A common method of reporting progress at a high level is through the use of a traffic light
system. For each KPI (or performance indicator) a range of acceptable performance will be
decided upon (e.g. the CPI may be acceptable if it is between 0.9 and 1.1). This range of
performance would then be denoted by an amber indicator and with performance below this
level being denoted by a red symbol and performance above this range being denoted by a
green symbol as shown below. This type of reporting mechanism has the benefit that it is
readily understood and can be interpreted quickly. This approach can also be used to
indicate actions required (e.g. the updating of key project documentation).
PAGE 89
CPI
SPI
Client Relationship
Status of safety plan
% of staff hours utilised
6.6 Summary
Progress reporting is essential to enable the project manager to control the project
effectively. When implementing a reporting mechanism the project manager must consider
how technology can be utilised to aid with reporting, the exact information that is required,
and how the information collected will be fed back to the project team. The use of earned
value analysis helps with the analysis of project data although the traditional performance
indicators of CPI and SPI are now commonly two of many performance indicators relating to
the wider performance of the project.
PAGE 90
7 Session 6 Project Decision Making

7.1. Introduction
The previous session described the development of the first stages of the control loop
(measuring and reporting). If the project team is doing its job then these elements of the
control loop will have been designed in such a way that if there are deviations from the plan
then these are highlighted in a timely fashion so that decisions can be made. The questions
that arise are then:
What decisions are available to the project in order to bring the project back on
schedule?
How can these decisions be reached?
This final session of the Project Planning and Control module examines a number of
possible options that are available for recovering a project and also a number of decision
making techniques that could be utilised to help understand the nature of the project and to
generate solutions to any problems which might be encountered. It should be noted that the
same approaches could also be applied to maximise any opportunities that arise as the
project progresses.
Activity
Before progressing, think about projects with which you have been involved.
What problems were encountered on the project? What were the signals that
indicated there was a problem? What methods were utilised to overcome the
problems?
7.2. Crashing the Network

One of the most common techniques used with project management is referred to as
crashing the network. This can be used at the start of a project when you cannot complete
the project activities within a given timescale (and hence need to redesign the project) or
later on in the project when you are behind schedule as a method to bring the project back
on schedule. The technique of network crashing is designed to identify which activities
could have there durations shortened (crashed) at the minimum cost to the project. There
are a number of ways that activities can be shortened:
provide an incentive for the work to be completed early - this has been done to great
effect on contracts for road repair on major motorways in the UK.
add additional resources such as extra people or machine capacity, provide
overtime, additional contracts, etc.;
parallel activities - reduce the risk of over-run by providing parallel means of
obtaining an output;
With most activities there is a limit as to how much they can be shortened (crashed) as
physical limits are reached, for example the drying time of concrete in construction projects
PAGE 91
or the number of people who can work on one activity at any one time. A good example of
this relates to bed space on offshore platforms which effectively limits the amount of
resource available to perform activities at any given time.
The trade-off between cost and time must be balanced such that the minimum cost schedule
is achieved, i.e. the activities are crashed in a systematic way - those that cost the least
being the first to be crashed. The following sequence should be followed once the critical
path has been established.
7.2.1 In order to crash the network you should first of all collect the following data for each
activity:
The normal time an activity takes (tn)
The normal cost of the activity (Cn)
The shortest duration of the activity (tc). This could be a result of issues like
unavoidable raw material lead times or physical processes such as paint drying. This
is often referred to as the crash point.
An estimate of the cost to achieve the shortest duration (Cc).
7.2.2 You then calculate the cost per unit time to crash each activity. This is a measure of
how much each unit of time that will be saved will cost. Obviously in many activities this
relationship may be non-linear but for simplicity the relationship between cost and time will
be assumed to be linear in these calculations.
Cost / unit time =
Cc
tn tc
7.2.3 In order to reduce the duration of the project you will need to select activities that are
on the critical path that can have their duration shortened. Selecting non-critical activities
will not reduce the duration of the project and therefore at this stage these activities are
discounted from the analysis. In selecting activities you will want to select those with the
lowest cost/unit time as these will give you the most cost effective time savings. So select
the cheapest critical activity and reduce the duration of this by one unit of time. When doing
this be aware of parallel activities which might appear to be of low cost to reduce in duration
but may require the simultaneous crashing of other activities.
7.2.4 By reducing the duration of the activity by one unit you may have changed the critical
path of the project. You should therefore recalculate the project network.
7.2.5 If the total time needs shortening further, go to back to step 3 and keep on reducing
the critical activities durations by 1 until you obtain the required project duration. Whilst
doing this you should keep track of which activities have been reduced and the overall cost
implications of reducing these activities.
This Time Cost Trade-off technique known as Crashing is best demonstrated by an
example. A project (for which you are project manager) to install network cabling has
identified that the project duration needs to be shortened by 2 days. The following activities
have been identified to be on the critical path, and the estimated costs are shown in the
table below. Based upon the information contained in columns B-F (this is the information
listed in item 1 above) it is a simple task to calculate the additional cost and the cost/unit
time.
PAGE 92
Critical
Activity
Normal
Duration
Crash
Point
Time
Gained
Normal
Cost
Crash
Cost
Add. Cost
G=F-E
Cost
/Time
H=G/D
75
155
80
26.7
15
10
175
320
145
29
145
205
60
60
With this information it is clear that the most ecomonical method of reducing the project
duration would be through crashing activity K. You would then need to reduce the duration
of activity K by 1 and recheck the critical path. If reducing the duration of K by 1 removes it
from the critical path you should then crash a different activity. Obviously, if activity K is
removed from the critical path and activity L and M remain then you would reduce the
duration of activity L before reducing the duration of activity M.
Activity 7.2
The initial project activity chart for a project is shown below. Using a network
crashing procedure (based upon the information below) decide what the optimum
project plan is to achieve a project duration of 24 weeks.
Task ID
A
B
C
D
E
F
G
H
I
J
Activity
C
D
E
I
J
Predecessors
Select Location for laboratory
Identify
High
Pressure-High
Temperature equipment supplier
Development of test system 1
Development of test system 2
Clear and Refit laboratory
Install Ventilation and Air conditioning
Install Test Systems
Install Safety Screens
Commissioning
Official Launch
Shortest
duration
10
10
8
4
3
PAGE 93
Duration
(weeks)
4
2
B
B
A
E
CDE
FG
H
H
15
15
10
1
3
2
7
5
Possible Normal cost

30,000
35,000
10,000
7,000
6,000
Shortened cost
45,000
50,000
14,000
13,000
21,000
7.3 Causal Mapping

Crashing the network is a specific approach developed for project management in order to
make decisions based upon project information. Other techniques can be borrowed from
more general management and can be highly useful on projects. The first of these
approaches to be discussed here is a technique called causal mapping. In session 1 we
discussed projects with relation to the general business and subsequently in session 4 we
discussed some of the issues relating to managing multiple projects in a single organisation.
From this you may begin to see the project as being an element within a system which is
dynamic and ever changing. Causal mapping is a tool that is borrowed from systems
thinking (see for example The Fifth Discipline Field book Senge et al) which encourages
managers to think about the system within which they are managing.
Activity 7.3 a
To get you thinking about systems and organisations take a number of objects and
lay them out on your desk so that each object is equidistant to two other objects.
Now move one of the objects and move the other objects so that the objects are
again equidistant to the objects to which they were initially equidistant. Observe what
happens to the other objects. Think about how this analogy relates to organisations.
You will hopefully have noted from this simple exercise that moving one element of
the system results in many more elements of the system moving, demonstrating the
interdependency of the system.
The starting point for causal mapping is the understanding of the basic relationships
between elements of the system. If we take the example of adding more staff to the project
in order to meet a time scale then a causal map can start to be developed. For example:
Increasing resources may lead to reduced project duration
Increasing resource could lead to increased costs (dependent upon contract terms)
Reduced project duration could lead to an increased likelihood of future work from
this client
Increasing resources could lead to reduced resources on other projects.
Increased resourcing could lead to reduced stress for existing workers.
This reduced stress could reduce costs associated with sickness pay
From the list above you will have started to get a feel for how one decision can have an
impact across a system. The causal map tries to capture this using a diagram which reflects
these interrelationships.
The starting point for developing the causal map within the context of project control is a
single issue which needs or a decision that needs to be made. Based upon this starting
point the implications of undertaking the decision can be explored through a series of arrows
that represent the relationships between the elements. Many people also annotate their
map using + or signs to indicate the nature of the relationship. If we take the example
above the causal map developed from this is shown below:
PAGE 94
Duration
Resource
Future Work
Stress
Costs
Profit
Other Projects
It is important to note that when you are developing causal maps you are capturing a single
view of the system (These maps are sometimes referred to as cognitive maps as they
capture one persons thinking). It is therefore quite common for these maps to be developed
as a group process to capture a team view of the interconnectedness of the system.
So where does causal mapping fit in with the decision making process? At one end of the
scale the causal map can be developed into a mathematical model that would resemble a
complex form of network crashing. Whilst this might provide a rational decision making tool
the relationships are often too subjective to be mapped effectively mathematically. These
situations are often referred to as management messes and within these situations it is
difficult for the manager to evaluate the options within a truly rational framework. In these
situations the manager may make a sub-optimal decision which will not necessarily be the
best way to achieve the outcome but does provide a decision when finding the optimal
decision may be overly time consuming.
The real strength of causal maps as a decision making tool lies in helping the project
manager understand the system within which they are operating and as a result understand
the potential impacts of the decision that they are considering within the systems context.
Activity 7.3.b
Take an issue that is relevant to your current project and develop a causal map
based upon this issue. Think about the implications and knock on effects of this
issue for the project and also for the organisation. What insights about the project
does this provide you with?
7.4 Scenario Analysis

Scenario Analysis is a tool that allows managers to develop a number of solutions to
problems and by the analysis of each of the scenarios develop a better understanding of the
decisions that they make. For example a decision relating to the effectiveness of residential
traffic calming may well depend upon the decision to upgrade other local roads or the
introduction of new bus services. By examining a range of scenarios within a structured
framework it is likely that more effective solutions will be developed.
Scenario analysis has been utilised in many organisations to understand what the future
may look like. For example Shell have utilised scenarios for many years to examine the
PAGE 95
range of future markets and environments in which Shell may operate within the future (for
more details see http://www.shell.com/home/Framework?siteId=aboutshellen&FC2=&FC3=/aboutshellen/html/iwgen/our_strategy/shell_global_scenarios/dir_global_scenarios_07112
006.html).
There are a number of key benefits offered by scenario analysis but perhaps the most
compelling in a project environment is the relaxation of the mental models within which the
project manager is operating. Mental models define the boundaries within which the project
manager is operating for example the project is running behind schedule so increasing
the resource on the project would help the project get back on schedule would be a mental
model. By examining different scenarios for the project the mental models of the project
manager can be relaxed allowing more creative solutions to problems to be examined. This
is illustrated below where the shaded section represents the area within which we routinely
examine the options that are available to us as a result of our mental models. The unshaded area represents other options which we do not routinely examine. Examining
possibilities which lie outside our current mental models can bring significant benefits to the
project, but can also be uncomfortable for those involved in the decision making process as
utilising these other options may challenge behaviours and custom and practice within the
organisation.
future possibilities
present
Activity 7.4
Think about the organisation within which you work. What mental models are
prevalent within the organisation? How do these mental models limit the approaches
that are taken towards problem solving?
So how do you go about developing scenarios? A simple framework is described below.

Identify what the possible environments within which the project might be operating
within in the future? For example it could be one in which there are tensions
between the client and the contractor, or one where the relations are very good. It
could be an environment where cost savings are driving changes being made to the
PAGE 96
project. Once you have identified a number of possible environments it may be

possible to cluster these together.
Understand the drivers that might encourage these future environments on the
project to occur. Here you are looking to select factors which are:
o Potentially important
o Uncertain or unpredictable
o Likely to impact on the success of the project.
As an example a key driver for the development of tensions between the
client and the contractor could revolve around the delivery of milestone elements or a
personality clash between the project manager and the clients project sponsor.
Develop strategies to deal with these future environments and to manage the project
to maximise the positive elements of any future environment and reduce the risks
associated with the negative elements of the future environment.
This process shares a lot in common with project risk management with the key
differences being the identification of a range of future possibilities and from these future
possibilities developing an understanding of what could happen on the project.
So how does this help with project decision making? Well if at any given time on a project
you can look forward to the range of possibilities which might occur then you are beginning
to make decisions not just on what is going to happen tomorrow on the project but what may
happen in the future. So this technique helps with answering the question what implications
will todays decision have on the range of future environments within which the project will be
operating?
Activity 7.4
Think about a current project on which you are working. What range of future
possible environments can you envisage for the project? How might this affect the
management of the project from the planning through to the execution of the project.
How might these future possible environments shape the decisions that you make
today?
7.5 Specific suggestions for bringing the project back on schedule

and budget
If through the data you have obtained combined with techniques such as Earned Value
Analysis you come to the conclusion that the project is behind schedule or over budget there
are a number of methods that could be utilised to bring the project back on to schedule. It
should however be noted that the choice of techniques will be different within each project
dependent upon the nature of the problems being experienced, relationships with the project
stakeholders and the cost implications of problems. When using these techniques you
should also think about the implications of any decisions as part of the system within which
you are operating using techniques such as causal mapping.
7.5.1 Act Early

The sooner the project manger acts the better chance he has of bringing the project back
under control. A response in week 32 of a 35 week project is unlikely to bring a turnaround
in the fortunes of a project while corrective action at week 12 could bring a satisfactory
PAGE 97
conclusion to the project. Remember that the influence of the project manager falls off
drastically as the project progresses (shown below). The other benefit of acting early is that
issues have a tendency to escalate and that an issue which would have been relatively
simple to manage when it emerged becomes far more difficult to manage as it escalates.
Examples of this include issues relating not only to schedule, quality and budget but also to
stakeholder interactions and the development of appropriate control process.
Accumulated
effort and cost
Cost
of change
Level of influence
planning
implementation
completion
7.5.2 Gain Commitment

The first stage to developing appropriate project control is to gain the commitment of all of
those involved in the project. Changes in the plan that are imposed on individuals are
unlikely to gain commitment and the team members may feel that they are getting dumped
on. Some basic rules when implementing changes to the project plan are therefore:
Speak to the person who is actually going to perform the work. Find out if they think
they can actually deliver to the modified plan or whether this is unreasonable.
Explain to them why the change in plan is necessary and what the implications of not
picking up the performance could be. These implications could range from an
unhappy customer to the company going out of business.
7.5.3 Assign extra resources.

If you have under utilised resources in another part of the project team the performance of
the project could be increased by assigning these resources to the areas that are behind
schedule. When assigning extra resources it is important to remember that the project may
actually be delayed as staff that are familiar with the task are diverted from doing the work in
order to train-up the new staff. This relates to the learning curve effect mentioned in
session 2 and as such adding resources is only effective when the correct resources are
added.
PAGE 98
7.5.4 Make better use of resources

Some key physical resources may be impeding the progress of the project. This physical
resource may range from a specific piece of manufacturing equipment through to a
specialised piece of design software. If the plant is working standard hours then the
resource may only be utilised for 8 out of 24 hours. Instigating a shift pattern for the use of
this resource in the short term may give you the opportunity to bring the project back on
schedule.
7.5.5 Job and Knock

A specific technique which can be used is referred to as Job and Knock when you have
finished the job you can knock off (finish). This may be relevant where one key component
is holding up the project. Encouraging the team members who are working on this element
of the project to finish early by providing them with time off when they finish can help bring
the time of delivery down. An example of this is where a piece of design work is required to
be completed prior to the procurement stages. For example consider a project where the
design stage started 2 days late and consequently the procurement will start late unless 2
days can be saved from the design stage. Making the offer to the members of the design
team that if they finish the work early they can get a 4 day weekend may well motivate them
to work overtime or more productively during the week.
7.5.6 No Blame Cultures

In order to maintain control it is important that when poor progress is reported that the
individual who reports poor progress in not blamed. Take for example the individual who
informs his manager that the report he is working on which was supposed to be finished by
the end of the afternoon will not be ready till the following week. If the manager castigates
the individual badly then it is likely he will not inform of the poor progress in future until the
deliverable is already late.
No blame cultures are commonly discussed within management texts today with many
organisations claiming to have a no blame culture. Whilst this approach is commendable for
a number of reasons, including building the trust and commitment of staff, the rhetoric is
rarely matched by actions. You might want to think about the culture within your
organisation and examine situations where projects are behind schedule (or over budget)
and examine the attitudes to blame.
7.5.7 Expectation Management

If you as project manager are aware that the deliverable is likely to be late it is worth
considering whether or not to inform the customer of this matter. Take an example of the
assessments that you submit on the course. The tutor is more likely to be sympathetic if you
inform him in advance of the fact that your submission is going to be late whereas late
delivery can annoy the tutor as well as meaning that your work may not get marked until the
tutors next scheduled marking day. A similar situation often exists with clients and informing
them of late delivery will:
Help their planning cycle. A delay of one week may not have serious implications if
they are informed with sufficient notice of the delay. This will allow the other
organisations involved within the project to reschedule their plans and thus minimise
cost to the client resulting from resources being booked but not utilised on the job.
Avoid confrontation at the point of delivery.
Build trust between you and the customer
PAGE 99
7.5.8 Involving the stakeholders

Often in projects there will be overruns on both cost and budget that could have serious
implications. In these situations it is worth considering re-evaluating the project scope with
the project sponsor. It may well be that specific items in the scope are essential to the
customer and certain items are less important. In these situations, you are in effect, looking
at the methods to reduce the project scope and to therefore limit the damage. For example
the client may require the installation of a computer network with the primary goal to get
everybody back on-line as quickly as possible. It will probably be less critical whether all the
network printers are working and that all staff members have their old emails transferred to
the new system. Asking the client these priorities may help you deliver the project to near
client satisfaction. This is particular useful in situations when the project is both limited by
time and resources and there is no obvious solution to solving the problem.
This approach may have serious implications for your organisation including
Reduced contract values and potential loss of profit margin
Loss of reputation
These, however, may be less severe than not managing to deliver the project or delivering it
so late that the project is useless to the client. In performing this type of hatchet job on the
project scope you should consider the effects on all the stakeholders and an indication of
where balances may be found could be obtained by using the Winstanley Stakeholder power
analysis described in Session 1.
7.5.9 Update The Plans

It is important to remember that a plan is just that a plan. When things are going well, you
would not stop work for a week because you were ahead of schedule you would modify
the plan to take account of your improved performance and press on with the project. In a
similar way when things are going badly the plan should be modified to reflect the problems
in order to allow you a better understanding of the problems that you face in bringing the
project back under control. You should, however, not forget the initial baseline project plan
and progress should still be monitored against this plan as well as the modified plan.
7.5.10 Monitor the Control Methods

The project control methods which you put in place are only as good as the utilisation of the
control methods. For example it is common to see steps in the reported progress on the
project which relate to the actual reporting of progress in the control system (for example P3
or MS Project). If the project is running behind schedule or over budget you may want to
consider modifying the control methods employed. For example you may choose to update
the frequency of reporting of items which are behind schedule to increase the information
that you as project manager have with respect to this task. You may similarly decide to
tighten the financial controls on tasks that are running significantly over budget.
7.5.11 Enhance Productivity of Your Resources

The productive work that is performed on projects is usually linked to human endeavour and
as such the management of your human resources within the project may be key to driving
your project back on to schedule and budget. The issues relating to human resources
elements of project management are dealt with elsewhere on the MSc programme but a few
elements are highlighted here.
Recognising the role of staff and rewarding commitment and good performance can
have a significant impact on the performance of the individual and as a result, the
PAGE 100
project. Common methods include using praise where it is due and offering
incentives (which can be financial or otherwise).
Clear communication with the project team can have a significant impact on the
performance of the project. If a project team member is aware of progress on the
project then they are likely to adapt their behaviour to fit the environment within which
they are working. For example if a project is behind schedule and staff are aware of
this, they can look for methods to enhance the delivery of the project. If they are not
aware of the situation then there is less of a driver for them to change and modify
their behaviours.
Motivation of your project staff is key. Within other modules you will have been (or
will be in the future) made aware of motivation models such as Maslows Hierarchy of
Needs and Herzbergs two-factor theory. Taking these models on board and
examining how you can motivate the staff on your project on an individual basis could
enhance the productivity of your staff.
7.6 Summary
The previous sections have highlighted possible options that are available in order to
enhance the project delivery. Before making project decisions it is however useful to
examine these in the light of the system within which you are working in and examine the full
range of options that you have available to the project. Eleanor Roosevelt is often quoted as
saying If you do what you have always done, you will get what you have always got and
this is as true for the project environment as any other environment using methods which
have not enhanced delivery in the past are unlikely to enhance delivery in the future.
Final Activity 7.6

Think back to the project you considered in the first exercise of this session. Reexamine this project utilising the tools discussed within this session. Are there
elements and decisions that you would approach differently following on from the
discussions within this session? What would they be and what benefits would these
alternative approaches bring?
Post your findings to Webct.
PAGE 101
Appendix Final Assessment

The final assessment is a project that aims to integrate many of the elements of the course.
You have a choice of two topics developing a plan for a wind farm or developing a
proposal for an integrated project management system.
Primary School Project

The Estimating, Planning and Project Control module introduces many tools and techniques
that are essential to successful project managers. This project provides a practical
opportunity to employ the individual skills learned by applying them to a single project. The
project is to build a primary school (for children aged approximately 5 12 years) near to
where you live.
It is your task as the project manager to develop a plan for this project. You do not however
need to concern yourself overly with the technical details of the construction but with the
process of developing a robust project plan for the delivery of this project. Therefore, as an
example, if you find it impossible to work out how long something takes or how much it
costs, make an assumption and use it within your project plan. The main aim of the project
is for you to demonstrate your skills at developing (and maybe modifying!) a project plan.
The discussion forum should be used for sharing ideas and concepts however the final
submission should be an individual effort. The final submission should consist of a Project
execution plan for the project and should be no more than 4000 words in length (or 35 pages
maximum). Any supplementary information can be included as appendices.
This task will also test your capability at retrieving information. There is a significant amount
of information available on the internet which you may want to utilise. You may also want to
consider looking in local libraries. It is appropriate within this module to use PM software
although you should be aware that the assessor is only be able to access MS Project files.
You will also want to consider how you will demonstrate your project planning skills and at
times may want to provide a commentary explaining why you have chosen to do things in
the way that you have.
Finally, good luck with the project. Your tutor will be able to help out with specific questions
which should be raised on the forum relating to PM and some issues of planning schools.
However, the key to success is in your assessment is ensuring you explain what you have
done and why you have taken the action you have.
PAGE 102

Planning and Control - Lectures

Transféré par

Informations du document

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Planning and Control - Lectures

Transféré par

Droits d'auteur :

Formats disponibles

MSC PROJECT MANAGEMENT :: STUDENT COURSE NOTES (Certificate)

Project Planning and

Tutors: Mr. Mike Sevenoaks (Campus)

MSC PROJECT MANAGEMENT

COURSE AIMS .................................................................................................................. 4

THE LEARNING CYCLE ..................................................................................................... 4

COURSE LOGISTICS .......................................................................................................... 5

WHAT IS PROJECT MANAGEMENT? ................................................................................... 7

WHY DO ORGANISATIONS CHOOSE TO DO PROJECTS?....................................................... 8

ACTIVITY 2.2 A................................................................................................................................ 9

PROJECT STAKEHOLDERS ............................................................................................... 11

PROJECT SUCCESS .......................................................................................................... 13

SESSION 2 SCOPE DEFINITION AND PROJECT ESTIMATING .............................................. 16

PROJECT OBJECTIVES AND SCOPE .................................................................................. 16

ESTIMATING ACCURACY ................................................................................................ 19

WORK BREAKDOWN STRUCTURES (WBS)..................................................................... 21

FROM THE WBS TO THE ESTIMATE ................................................................................ 25

Work Study and Standard Work Norms .......................................... 25

The Steps In Making A Time Study................................................................... 26

The Learning Curve Effect.............................................................. 30

Completing the estimate.................................................................. 36

CONTRACTUAL AGREEMENTS ........................................................................................ 37

PROJECT MANAGEMENT ESSENTIALS 2

MSC PROJECT MANAGEMENT

Schedule of Rates / Cost Reimbursable ............................................................ 39

SESSION 3 DETAILED PLANNING .............................................................................................. 41

ORIGINS OF NETWORK PLANNING .................................................................................. 41

THE NETWORK PLANNING PROCEDURE ......................................................................... 42

ACTIVITY-ON-NODE (AON) NETWORKS ...................................................................................... 67

SESSION 4 - PUTTING THE PLAN INTO ACTION...................................................................... 70

5.2 PROJECT EXECUTION PLANS (PEP) ......................................................................................... 70

MEASUREMENT OF PROGRESS ........................................................................................ 78

PROJECT PLANNING AND CONTROL

MSC PROJECT MANAGEMENT

6.2.4 Accuracy of reporting.............................................................................. 79

PROJECT PLANNING AND CONTROL

MSC PROJECT MANAGEMENT

The Learning Cycle

PROJECT PLANNING AND CONTROL

MSC PROJECT MANAGEMENT

Setting the context

Scope and Estimating

Project decision making

PROJECT PLANNING AND CONTROL

MSC PROJECT MANAGEMENT

This course is solely assessed by continual assessment there is no examination.

MBA Handbook (Shelia Cameron): Starting an MSc course whilst still in

Handbook of Project Management (Rodney Turner): This text covers a wide

PROJECT PLANNING AND CONTROL

MSC PROJECT MANAGEMENT

This introductory session aims to:

What is project management?

PROJECT PLANNING AND CONTROL

MSC PROJECT MANAGEMENT

Why do organisations choose to do projects?

PROJECT PLANNING AND CONTROL

MSC PROJECT MANAGEMENT

Figure 1: The traditional cost-time-quality triangle of project success.

PROJECT PLANNING AND CONTROL

MSC PROJECT MANAGEMENT

oDevelopment of new products or markets. For example an organisation might take on

oDevelopment of new working relationships with organisations.

This could include

relationships with clients or with suppliers and partners in the project.