4UPM Study Guide

Yo u r road to success
Your road to success
LEVEL 4
PROJECT
MANAGEMENT
BE •
• A
OF
IDE
FICI
GU
L
STUDY
abeuk.com
A
© ABE 2017
All rights reserved. No part of this publication may be reproduced or

transmitted in any form or by any means, electronic or mechanical, including
photocopying and recording, or held within any information storage and
retrieval system, without permission in writing from the publisher or under
licence from the Copyright Licensing Agency Limited. Further details of such
licences (for reprographic reproduction) may be obtained from the Copyright
Licensing Agency Limited, Barnard’s Inn, 86 Fetter Lane, London EC4A 1EN.
This study guide is supplied for study by the original purchaser only and must
not be sold, lent, hired or given to anyone else.
Every attempt has been made to ensure the accuracy of this study guide;
however, no liability can be accepted for any loss incurred in any way
whatsoever by any person relying solely on the information contained within
it. The study guide has been produced solely for the purpose of professional
qualification study and should not be taken as definitive of the legal position.
Specific advice should always be obtained before undertaking any investment.
ABE cannot be held responsible for the content of any website mentioned in
this book.
ISBN: 978-1-911550-14-3
Copyright © ABE 2017

First published in 2017 by ABE
5th Floor, CI Tower, St. Georges Square, New Malden, Surrey, KT3 4TE, UK
www.abeuk.com
All facts are correct at time of publication.
Author: William Wright BCom MSc MBA

Reviewer: Colin Linton MRes MBA PGCHE DipM DipFS FCIB FCIM FCIPS
FCIEA FHEA FInstLM
Editorial and project management by Haremi Ltd.

Typesetting by York Publishing Solutions Pvt. Ltd., INDIA
Every effort has been made to trace all copyright holders, but if any have
been inadvertently overlooked, the Publishers will be pleased to make the
necessary arrangements at the first opportunity.
The rights of William Wright to be identified as the author of this work have
been asserted by her in accordance with the Copyright, Design and Patents
Act 1998.
The publishers gratefully acknowledge permission to reproduce the following

copyright material: p2 Paul Barnwell/Shutterstock.com; p2 michaeljung/
Shutterstock.com; p11 Machmarsky/Shutterstock.com; p11 michaeljung/
Shutterstock; p20 Visual Cortex/Shutterstock.com; p23 Boudikka/
Shutterstock.com; p34 My Life Graphic/Shutterstock.com; p56 fotoinfot/
Shutterstock.com; p58 Pete Spiro/Shutterstock.com; p77 leungchopan/
Shutterstock.com
ii © ABE
Contents
Using your study guide iv
Chapter 1 Understanding the Project Life Cycle and Other Key Concepts 2
1.1 The project life-cycle model3

1.2 The project business case9
1.3 Work breakdown structure17
1.4 Project risk management22
Chapter 2 Creating an Effective Project Plan 28
2.1 Project planning with network diagrams29

2.2 Project planning with Gantt charts35
2.3 Applying critical path analysis37
2.4 Calculating start and finish dates40
Chapter 3 Resource-based Project Budgets 50
3.1 Project resources51

3.2 Top-down and bottom-up project budgets54
3.3 Time-based and fixed-price resources56
3.4 Estimating the costs for a project57
Chapter 4 Tracking and Controlling Live Projects 62
4.1 Progress tracking – baseline plan and approved budget 63

4.2 Comparing planned progress with actual progress66
4.3 Finding ways to recover lost progress73
4.4 Project management software systems75
Guidance
78
Glossary
82
© ABE iii
Using your study guide
Welcome to the study guide Level 4 Project Management, designed to support those completing
an ABE Level 4 Diploma.
Below is an overview of the elements of learning and related key capabilities (taken from the
published syllabus), designed to support learners in assessing their own skillsets in terms of
employability, and in creating their own personal development plans.
Element of learning Key capabilities developed
Element 1: The project life • Knowledge of the core concept and application of the
cycle project life cycle
• Ability to identify potential risks
Project management, planning, application of simple metrics
Element 2: Project planning Development of practical planning skills for a project

Network diagrams, Gantt charts, critical path analysis, planning
Element 3: Project budgets Development of practical budgeting skills for a project

Identifying resources, setting budgets, calculating cost
Element 4: Project tracking Development of tracking and control skills for a project.
Using plans and budgets, monitoring progress, tactics for
recovering lost time, options for use of project management
software
This study guide follows the order of the syllabus, which is the basis for your studies. Each chapter
starts by listing the syllabus learning outcome covered and the assessment criteria.
iv © ABE
L4 descriptor
Knowledge descriptor (the holder…) Skills descriptor (the holder can…)
• Has practical, theoretical or technical • Identify, adapt and use appropriate
knowledge and understanding of a subject cognitive and practical skills to inform
or field of work to address problems that actions and address problems that are
are well defined but complex and non- complex and non-routine while normally
routine. fairly well-defined.
• Can analyse, interpret and evaluate relevant • Review the effectiveness and
information and ideas. appropriateness of methods, actions and
• Is aware of the nature of approximate scope results.
of the area of study or work.
• Has an informed awareness of different
perspectives or approaches within the area
of study or work.
Contained within the chapters of the study guide are a number of features which we hope will
enhance your studies:
‘Over to you’: activities for you to complete, using the space provided.
ase studies: realistic business scenarios to reinforce and test your understanding of what
C
you have read.
REVISION
‘Revision on the go’: use your phone camera to capture these key pieces of learning, then
on the go
save them on your phone to use as revision notes.
‘Need to know’: key pieces of information that are highlighted in the text.
Examples: illustrating points made in the text to show how it works in practice.
Tables, graphs and charts: to bring data to life.
Reading list: identifying resources for further study, including Emerald articles (which will be
available in your online student resources).
Source/quotation information to cast further light on the subject from industry sources.
Highlighted words throughout and glossary terms at the end of the book.
Note
Website addresses current as of June 2017.
© ABE v
Chapter 1
Understanding the Project
Life Cycle and Other
Key Concepts
Introduction
History is full of stories about projects that failed to achieve what
was expected. In the world of industry and commerce, it is almost
impossible to find an experienced manager that has not come
across a failed business project of some description.
Some people take a pragmatic view that it is unreasonable to

expect every single project to be a complete success, but it is
generally accepted that too many projects fail in some aspect/s.
This is often down to a factor or combination of factors that could
and should have been anticipated well in advance, and sensible
measures should have been put in place to deal with these factors.
A further challenge faced by project managers is that they are

generally highly visible – unlike other business professionals their
results can be seen and reviewed by many people at all levels of
the organisation.
Learning outcome
On completing the chapter, you will be able to:
1 Discuss the concept of the project life cycle in a variety of business organisations
and contexts
Assessment criteria
1 Discuss the concept of the project life cycle in a variety of business organisations and contexts
1.1 Explain the sequential stages of the project management life cycle and the activities
which are carried out at each stage
1.2 Explain the concept of a project business case based on a set of basic cost and revenue
inputs, including the application of some simple metrics such as return on capital,
payback and net present value
1.3 Discuss the concept of a work breakdown structure
1.4 Discuss the risks that may emerge on a major project © ABE
Level 4
Project Management
1.1 The project life-cycle model

The concept of a project
Having a clear definition of what constitutes a ‘project’ is valuable because it would be a serious
mistake in business to manage a relatively modest activity as a project when it would be far better
handled as a regular operational job.
Similarly, significant initiatives that organisations attempt to assign to individuals as part of their
regular professional duties are unlikely to be very successful. Complex time-bound initiatives are
very often better managed as discrete projects.
So, since knowing the difference is valuable, first consider some established definitions.
A ‘project’ is defined by the Project Management Institute (PMI) along the following lines:
The basic purpose of a business organisation is to perform work of some description. Work may be
categorised as either operations or projects. These activities share many characteristics. They are:
• performed by people, often in control of machines/tools;
• constrained by limited resources;
• planned, executed and controlled;
• undertaken in coordination with others.
However, operations and projects differ primarily in that operations are ongoing and repetitive in
nature, while projects are temporary and unique.
PMI have elaborated their definition as follows:
Temporary means that every project has a definite beginning

and a definite end. The end is reached when the project’s objectives have
been achieved, or when it becomes clear that the objectives will not or cannot
be met, and the project is terminated. Temporary does not necessarily mean
short in duration; many projects last for several years. In every case, however,
the duration of a project is finite; projects are not ongoing efforts.
Projects involve doing something which has not been done before and which is, therefore, unique.
A product or service may be unique even if the category it belongs to is large. For example, many
thousands of large office buildings have been developed, but each individual facility is unique –
© ABE 3
Chapter 1 Understanding the Project Life Cycle and Other Key Concepts
different design, location, contractors, and so on. The presence of seemingly repetitive elements
does not change the fundamental uniqueness.
OVER TO YOU
Activity 1: Project or not?
Decide whether the following initiatives and schemes should (or should not) be
undertaken as a formal project.
A head office relocation for an insurance group, involving new office facilities for all 250 staff.
The launch of a new online/mail order service for a bed manufacturing company.
A specialist boat building company in South Africa makes luxury motor yachts for a small
market, building about one per month. A new order is received from a client in the Middle East.
Running a political campaign.
A nationwide immunisation programme which will put in place procedures to immunise every
child in the country as they reach the age of three.
Frequently there is no clear cut approach and much will depend on the culture of the organisation.
However, as a general guide:
• An office move for 250 staff is likely to be a significant time-constrained activity and is best
managed as a project.
• Similarly, a launch of an online service for a manufacturer is likely to be ‘mission critical’ and
necessitates the discipline of a project management approach.
• With regard to the luxury boats, it may depend on the degree of homogeneity. If every yacht
is significantly different in design and engineering, each may justify a separate project. If not, a
traditional production management approach with appropriate quality systems may be optimal –
rather than the expense of forming a new project for each and every boat.
• Providing a political campaign is not open-ended, the intense time-constrained demands and
limited resources make it a good candidate to be a ‘project’.
• By definition, a project cannot be open-ended so it is highly unlikely that a long-term
immunisation programme should be managed as a project.
The Iron Triangle

The three factors that always influence every project are known as the Iron Triangle (Figure 1):
Quality
Cost Time
Figure 1: The Iron Triangle REVISION

on the go
4 © ABE
Understanding the Project Life Cycle and Other Key Concepts Chapter 1
A package of work only qualifies as a ‘project’ if it is has clearly designated limits with regard to
time (a deadline for delivery), cost (a budget or financial limits) and quality (a succinct technical
specification of the end product or deliverable). In some interpretations, the quality dimension
is referred to as ‘scope’.
Once the three parameters are properly analysed and defined, a project manager and team may
then be tasked to plan and deliver whatever it is that the business is demanding. The outcome
of the project can then be measured and appraised in comparison with the original three
parameters. In short:
• Did the project team deliver by the deadline agreed?
• Did they spend no more than the amount of money agreed?
• Did the quality of the project deliverables meet our expectations? Was it ‘fit for purpose’ and
did it add value to our business?
Getting a yes to all three questions is often very difficult because the three factors are often related
to each other. For example, if a project manager wants to keep the project on schedule, they might
have to pay overtime or hire extra staff for a period, which will cost extra money and may lead to
overspending the budget. Some project managers make cost savings by simplifying the quality of
the product, which may lead to the project staying within budget but the end users (customers)
being disappointed with the outcome.
At times, project management can be a tough job as often project managers may start to think that
there is no way to keep everyone happy. All too often, different business organisations will prioritise
different elements of the Iron Triangle, and a project manager will soon be in trouble if they fail to
understand these priorities.
OVER TO YOU
Activity 2: Iron Triangle
Consider the dimensions of the Iron Triangle with respect to the following projects,
and in each case identify which dimension is likely to be the most important influence
on the project:
The installation and commissioning of new radiotherapy equipment in a specialist cancer

hospital.
A new sports stadium and training facilities for the next Olympic Games.
A software project for a struggling business being carried out under the terms of a
fixed-price contract.
Quality is an elusive concept to define, and the problem is worth considering within the context
of project management and the Iron Triangle. The definition of ‘quality’ continues to evolve and
has different meanings in different contexts. In general, the word enjoys positive connotations; for
example, a Rolls-Royce car may be widely considered a quality automobile. To define quality purely in
terms of product excellence is difficult due to personal perceptions of what constitutes ‘excellence’.
Price may also be a determining factor. For example, it could be argued that in fact Honda produce
a better quality car than Rolls-Royce because a Honda car is so much cheaper and better value for
money. However, perceptions of quality are of little use to project managers. They need a precise
and objective definition of the deliverables of the project (often known as a ‘specification’).
© ABE 5
Time and cost are generally much easier to understand. Projects will be time constrained (they have
a completion deadline) and have a cost constraint (a budget has been set in advance).
And then things may get worse!

Even if a project manager is quietly confident that the three constraints of the Iron Triangle can be
achieved, unanticipated external factors can also impact the project. Therefore, while it is generally
agreed that the Iron Triangle is a useful model, a degree of professional flexibility is required according
to the dominant priorities of the project and potential changes in the business environment.
Factors outside the direct control of the project manager are often the source of much frustration.
There are ‘macro’ economic factors to consider such as abrupt changes in market conditions. For
example, a project team may be engaged in building a new chemical plant. If there is long-term
demand for the product to be produced, the plant drops to the point to which it is no longer
economically feasible to complete, and for this the project manager can hardly be held responsible.
A similar effect might occur if currency exchange rates or interest rates change dramatically for
the worse. Most frustrating perhaps is when the project manager is dependent on internal parties,
external contractors or suppliers over which they have no direct control. But if these parties fail to
perform, the project manager is often held accountable.
The project life-cycle concept

It is worth noting that projects develop in different ways as time passes. In other words, there will
be a variety of different activities and challenges that will change during the course of the project.
Task repetition will be low and a good project manager will have to deal with a number of different
professional challenges at each stage of the project.
As projects generally go through a sequence of similar stages, the concept of a ‘life cycle’ was
developed to map out the sequential stages of a project and identify the specific management
challenges that need to be dealt with at each point.
NEED TO KNOW
One well-known project life-cycle model has five stages: initiation, planning,
execution, control and completion (IPECC).
REVISION
on the go
Note that projects can emerge from different circumstances. A business may wish to invest in a
new capital asset to generate extra revenue. Alternatively, there may be cost pressures arising in
their market and a project is required to reduce production or operating costs. Relocating a factory
would be an example of this. Once the idea emerges, senior management will demand further
details before even thinking about giving the go-ahead.
A business case will be required to demonstrate how the benefits of the project will be greater
than all the costs that will be incurred. The initial scope of the project may be broken down into a
work breakdown structure (WBS) to demonstrate that the project manager and colleagues
have a sound understanding of the work scope. All the potential risks will need to be considered.
All these activities (and more) are covered during the initiation stage of a project. Many businesses
will demand that all this information is captured in a Project Initiation Document (PID) which will
have to be approved in a formal manner before any further action can be taken.
6 © ABE
OVER TO YOU
Activity 3: PID
Using internet-based research or any other sources, find out what is meant by the
term ‘project initiation document’ or PID. Note that the purpose may vary from
organisation to organisation. Determine the purpose, value and typical structure/
contents of a typical PID. This knowledge will underpin your understanding of this
topic. Make your notes here.
As the project concept begins to take shape, three key questions will need to be answered:
• How long will the project take?
• How much will it cost?
• Have the deliverables been properly specified?
If you are going to respond to these questions in a professional manner, you will generally require:
• a plan
• a budget
• a functional specification (which will vary according to the nature of the project)
In the IPECC model, creating these documents is considered to be the planning stage. Coming
up with credible answers to the three questions is far from easy but is very important. Acceptable
answers may well result in a ‘green light’ for the project to go ahead; the planning then stops and
the plan, budget and specification are all ‘baselined’.
Baseline
Understanding what is meant by a baseline is important. In simple terms, all it means is that
a final version of the project schedule and the project budget (and the plan) are frozen and are
not to be changed without senior management approval.
Why? Because as work commences on the project, week-by-week progress and spending
can then be compared with the baseline. This is important because without a
baseline it would be impossible to know whether the project was proceeding as
planned and keeping to the budget. This is part of the ‘control’ stage and is
covered further in Chapter 4. REVISION
on the go
When work on the project starts it enters its execution phase. The project manager needs to
ensure that the team stay focused on the original plan, specification and budget, as well as the
day-to-day work.
© ABE 7
Hence the need for a control stage to ensure that all the project work is focused on achieving
what was agreed at the outset in the PID and subsequent documents such as plan, budget and
specification. Any differences need to be identified quickly so that action can be taken. Any risks
identified at the beginning of the project also need to be monitored and action taken if necessary.
Finally, project managers know how difficult it is to drive projects through to a successful finish.
It can be very challenging. Sometimes the project team are enjoying the project so much that
they simply do not want it to end! Scope creep can be present where the work required keeps
expanding to keep the team busy. The project may have also hired some freelance staff who are
paid by the hour or day. Unless these staff have a job lined up after the project, they may have an
interest in working on the project for as long as possible.
At the other extreme, the project may have been a difficult and stressful experience. Problems may
have been ‘brushed under the carpet’ and will only come to light at the very end, which then takes
much longer than planned. Key staff may start drifting away to focus on new projects.
The scale of these challenges means that the project life cycle has a final completion stage. In
addition to driving the project through to the finish and ensuring the deliverables are fit for purpose
and acceptable to the clients, the project manager is also expected to evaluate the experience and
pass on the lessons learned to other projects. What worked well? What were the biggest issues?
Which tasks took longer than expected? What should be done differently next time?
Alternative project life-cycle models

It is worth remembering that there is not just one project life-cycle model to which all researchers
and practitioners refer. Instead there are several different models, all based on the same principles
but with some key differences.
OVER TO YOU
Activity 4: Project life-cycle models
Using the internet or any other resources at your disposal, research the following
project life-cycle models, and make notes about the similarities and differences of
each model, compared to the generic IPECC model. Finally, note down what IPECC
stands for, without checking back in the text!
Meredith and Mantel – three-stage model
Maylor – four-stage model
Frigenti and Cominos – five-stage model
IPECC stands for…
8 © ABE
Summary
Project work is very different to ‘business as usual’. Projects always change in nature as they
progress. For example, the challenge of getting a project off the ground and getting buy-in and
momentum at the beginning is different to the work of completing, handing over the end products,
and review/evaluation. Some challenges persist throughout, such as maintaining the business case
and stakeholder management, but most challenges vary as the project moves through its project
life cycle.
There are several different views of the project life cycle, each with strengths and weaknesses. It can
be used to define a process very clearly (Frigenti and Cominos), it can be a framework for risk and
quality management (Meredith and Mantel), or it can be an overview of the activity in four different
phases (Maylor). These views overlap and can be linked, but offer different value.
Understanding the different phases of the project life cycle makes it easier for project managers to
focus on the immediate challenge and ensures key aspects of tasks are not neglected at any point.
OVER TO YOU
Activity 5: Selecting a project life-cycle model
Based on your understanding of the project life-cycle models, select the model that
you find most logical and identify the key tasks and challenges which will be faced by
the project manager and the project team at each stage of the life cycle. What skills
are likely to be required at each stage?
1.2 The project business case

A ‘business case’ means setting out in business terms the basic financial rationale for the project.
It is a justification for the project in terms of measurable future benefits, and why the projected
benefits are anticipated to exceed the costs, and by when and how much. It may also include the
risk and resource implications.
It is a mistake to try to avoid this preliminary analysis since it is essential in terms of delivering a
successful project. If the numbers do not ‘stack up’, the business rationale for undertaking the
project is lost and the sponsors will either refuse to give the ‘go-ahead’ or insist that the project
is stopped if it has already started. In business, there are few things worse than watching a project
lose money. So, the financial aspects (the business case) are never to be ignored or neglected.
© ABE 9
Proficiency in project management requires a wide range of different skills to be applied at different
stages of the project.
What needs to be researched?

Firstly, all the high level projected costs of the project need to be researched. Chapter 3 covers
the process for a detailed resource-based approach to project costing but very often this level
of professional detail is not feasible at this embryonic stage of the project. However, this fact is
never a good enough excuse for avoiding the cost challenge completely. Some credible projected
estimates of cost are required. Fortunately, competent contractors can often help out, as can
experienced colleagues that have undertaken similar endeavours in the past.
Secondly, all the anticipated benefits of the project need to be quantified into financial terms. This
can be very challenging because so often future project benefits can be defined in broad, rational
terms but not easily quantified.
For example, a university college might spend US$10,000 on the design and launch of a new
website. The benefits of such a project would be clear to most people, but justifying that their value
is worth more than $10,000 is likely to leave a project manager in difficulty.
Perhaps the only thing worse is if the project has already begun and you have no idea of the overall
budget required.
Estimating high level costs

Estimating the overall cost of a future project may be difficult but is never impossible. If you can
define something with any reasonable degree of clarity, someone will be motivated (or pressured)
to come up with an approximate cost.
For example, consider estimating the total cost of a new one hundred-room hotel based on some
outline architectural designs. This is not an easy task, but if you phone some competent building
contractors, you are almost always going to get a favourable response as they detect the possibility
of new business. Even if you make it crystal clear that at this stage you are only working on the
outline business case, you should try to get a chance to talk it through with a possible contractor
face-to-face where you might pick up helpful input such as similar projects they have undertaken
and for what cost. It is also useful to have more than one input to compare and contrast in the light
of your proposals.
Even if this main contractor scenario is not appropriate, the fundamental principle still applies, i.e. if
your organisation is considering spending a significant amount of money, it is not unreasonable to
expect someone to have to create a realistic projection of all the money required. You will usually
find that if the business case is approved, a much greater degree of cost detail will be demanded –
as covered later.
Quantifying high level benefits

As indicated, high level benefits of the project should be converted into financial terms, even if this
is difficult. For example, the benefits of a new college website might be quantified in part by its
ability to attract more students. If student fees were $8000 per annum, an extra 20 students each
year would generate $160,000, and this would go a long way to justifying the project investment.
The key is to quantify and record, not try to rely on subjective statements such as, ‘it will help to
recruit more students.’
The following project scenario is included to explain the basis of this approach.
10 © ABE
CASE STUDY
A new dam
A private sector energy company is contemplating a
new project to build a small dam. The benefits would
be to create a water reservoir for the residents of the
cities and towns in the region and create electricity
through water-driven turbines.
It is anticipated that the construction work will be
funded in full by a loan from a major bank. It will
take one year for a civil contractor to build and once
it is finished, operation and maintenance costs are
estimated to be $1m p.a.
Environmentalists and some local people protest that
the project will flood a large area of farmland, and
force the resettlement of local farmers. A budget of $6m
has been proposed to compensate people for resettlement (which would be paid immediately).
The bank loan is to be paid back in three equal annual instalments of $12m (which includes
interest). The first payment is due at the end of the first year (i.e. when the dam is completed).
Once built, financial benefits from the dam are estimated to be $10m p.a. (for electricity
generation) and $4m p.a. (for water supply). Both are then expected to rise year on year by 5% p.a.
as demand for electricity and water increases in the region.
After five years of operation, ownership of the dam will transfer to the local government authority.
OVER TO YOU
Activity 6: A new dam
Using the information in the case study, create a business case for the dam project.
The company discount rate is 10%.
Setting out the year-by-year table

Once quantified, the financial elements (costs and revenues) of the project should be presented year-
by-year in a tabular format to show the relative timings. An extra column should be included at the
beginning of the table to represent upfront costs (those that occur in advance of the main project).
© ABE 11
You know that the dam project will take one year to build (Year 1), followed by five years of
operation. ‘Year 0’ is for the upfront costs.
Year 0 Year 1 Year 2 Year 3 Year 4 Year 5 Year 6

Costs
Benefits
Table 1: Year-by-year table template for six years REVISION

on the go
Starting with the costs, the $6m for resettlement compensation is the easiest to understand.
All of it is to be paid out at the beginning of the project – in Year 0. Secondly, the loan
repayments are quite straightforward. The information states that there will be three equal
payments of $12m starting at the end of Year 1. Finally, there will be operating costs of $1m p.a.,
which will commence in Year 2 (because the dam is being built during Year 1) and then carry on
throughout the life of the project.
Costs Year 0 Year 1 Year 2 Year 3 Year 4 Year 5 Year 6

Relocation 6.0
Loan 12.0 12.0 12.0
Operations 1.0 1.0 1.0 1.0 1.0
Table 2: Year-by-year table template – costs REVISION

on the go
Now we need to look at the positive cash flow benefits from the project – the year-by-year benefits.
Like any big construction project, it is unlikely that the project will deliver any significant revenues
until it is completed.
Therefore, the first benefits will start to appear from Year 2 onwards (the dam is being built in
Year 1) (Table 3).
Benefits Year 0 Year 1 Year 2 Year 3 Year 4 Year 5 Year 6

Electricity 10.0 10.5 11.0 11.6 12.2
Water 4.0 4.2 4.4 4.6 4.8
Table 3: Year-by-year table template – benefits REVISION

on the go
12 © ABE
Note that only one or possibly two decimal places are required. Having done this, the final stage in
the business case table is to put all the costs and benefits together, and add a total at the bottom
of each column (Table 4):
Costs Year 0 Year 1 Year 2 Year 3 Year 4 Year 5 Year 6
Relocation 6.0
Loan 12.0 12.0 12.0
Operations 1.0 1.0 1.0 1.0 1.0
Benefits
Electricity 10.0 10.5 11.0 11.6 12.2
Water 4.0 4.2 4.4 4.6 4.8
Net cash flow

−6.0 −12.0 1.0 1.7 14.4 15.2 16.0
(benefits−costs)
Table 4: Project cash flows REVISION

on the go
Now we have a clear analysis set out in a format that business professionals can consider properly,
often in the light of competing project priorities. It can also serve as the basis for further informative
appraisal calculations.
Appraisal techniques: a practical summary

By looking at the sequence of yearly net cash flows at the bottom of Table 4, you should be able to
form a basic overview of this project.
If all the high level financial projections are reasonably accurate and reliable – but the main positive
revenue streams will not be forthcoming until say after Year 3 – this may or may not be acceptable
to the project sponsor according to a range of other business considerations.
To amplify this analysis there are three main project appraisal techniques that can be applied to the
year-by-year figures:
Return on capital
In return on capital you add up all the positive cash flows (48.3) and divide by the negative
outgoing cash flows (18.0). In this case that equals 2.68.
This can be expressed as a return of 268% in terms of the investment required at the start of
the project. In other words, for every $1 invested at the outset or early stages the company will
receive $2.68 back by the end of the venture. This looks good in theory, but this calculation takes
no account of the timing of those returns, which is a key consideration for anyone, particularly an
investment professional or competent project manager.
© ABE 13
Payback
This is the easiest technique to understand, if not quite so easy to calculate. The payback metric is
based on the very simple common-sense concept ‘Precisely how long will it take before we get all
our money back?’
The dam scenario requires an immediate payment of $6m followed by another $12m at the end
of Year 1 ($18m total). Things then start to improve with small positive cash flows starting during
Year 2 ($1m). If we calculate cumulative year-on-year cash flows (Table 5), we can see that the
payback point does not occur until some point in Year 5 (before this, the project had still spent
more money than it had earned). After this point in time, the project starts to generate surplus
funds (‘profits’) and demonstrates its financial viability.
Net cash flow –6.0 –12.0 1.0 1.7 14.4 15.2 16.0
Cumulative –6.0 –18.0 –17.0 –15.3 –0.9 14.3 30.3
Table 5: Payback period REVISION

on the go
This seems straightforward enough. However, simply stating ‘we get our investment back
during Year 5’ is not sufficiently precise. Therefore, a final calculation is required to determine
the precise point during Year 5 that we get our money back.
A = the last period (year) with a negative cumulative cash flow = Year 4
B = the absolute value of cumulative cash flow at the end of period A = 0.9
C = the total cash flow during the period after A = 15.2
Payback period = A + (B/C) = 4 + (0.9/15.2) = 4.06 years (two decimal places)
You can multiply the 0.06 by 365 to state the payback point as 4 years and 22 days.
Net present value

Net present value (NPV) requires you to understand the time value of money.
Firstly, if you are owed $10,000 and had a choice between being paid today or in 12 months time,
you’d pick today. What if you owed someone else $10,000? You would generally choose to wait
as long as possible before paying. Even if you couldn’t find a way to use the money creatively in
your business, you could just deposit the money in a bank for a year and receive some interest
in a risk-free scenario. Successful businesses can often find a way to achieve a greater return on
funds than basic bank interest.
So, the further away positive cash flows are in time, the less they are worth in terms of the monetary
value of today (and vice versa). That is the essence of NPV.
So how do you calculate the NPV of a positive cash flow of $10,000 that is one year (12 months)
away? One way of doing this is to take the prevailing discount (interest) rate, convert it into a
decimal and add it to 1. This becomes the denominator so take the future cash flow total and divide
by this value for every year that you have to wait for it.
14 © ABE
For example, if the discount rate was 5%, this equates to a decimal value of 0.05. Add 1 and you
get 1.05. Take the $10,000 and divide by 1.05. This equates to $9523.81. You can also use discount
tables to calculate this. You should achieve exactly the same result.
So the equivalent value (NPV) of $10,000 due in one year’s time is worth $9523.81 today (based on
a discount rate of 5%).
What about cash flows that are more than one year into the future? Divide by the denominator
(1.05) multiple times – divide once for each year in the future.
So, for example, a positive cash flow of $5000 is not forthcoming until the end of Year 3 and the
discount rate is 8%. Firstly, the denominator is 1.08. Then divide $5000 by this value three times,
i.e. $5000 divided by 1.08 = $4629.63. Then $4629.63 divided by 1.08 = $4286.69. Then $4286.69
divided by 1.08 = $3969.16.
In other words, the NPV of $5000 to be received in three years’ time (using a discount rate of 8%) is
$3969.16. Very often the decimals (16 cents) are not required.
These NPV calculations can be applied (in Table 6) to the dam scenario. The discount rate is
declared to be 10%, so we divide by 1.1 for each year into the future. (So for Year 4, for example,
remember to divide four times.)
Net cash flow −6.0 −12.0 1.0 1.7 14.4 15.2 16.0
NPV −6.0 −10.9 0.8 1.3 9.8 9.4 9.0
Table 6: NPV calculation REVISION

on the go
Now we can see that the large cash flows from Year 4 onwards are worth considerably less in
today’s money (NPV). The negative outgoings in Year 1 are also less, reflecting the fact that it is
advantageous to be able to wait a while before incurring that cost.
Finally, we can total all seven NPV values, which equals 13.4 in this example.
Even with the future cash flows discounted into today’s values, the dam project should still
generate a positive total cash flow of $13.4m, which may be acceptable. This can be compared with
alternative project investments if a decision is required.
Additional detail for the business case

These techniques are not too complex once you’ve practised them a few times. However, the reality
is that future cash flows (positive and negative) are most likely someone’s estimate or best guess. So
all the associated calculations, no matter how accurate in a mathematical sense, are only as reliable
as the input values. Business professionals know this instinctively, and rather than just accept outputs
such as NPV figures at face value, will rapidly search for elaboration and justification for all the
projected cash flows, together with an assessment of all the attendant risks.
For example, if someone pitched a business proposition to you, based on you investing $10,000
now, and in return you would receive $3000 at the end of every year for five years, you would
© ABE 15
be unlikely to jump at the chance. Instead, you would probably say ‘Tell me more about it.’ In
other words, you’d ask for all the important details so that you can assess the credibility and risks
associated with the venture.
Therefore, if you are preparing a solid business case, you should anticipate the inevitable demand
for extra detail in advance and supply it. Investors will demand more than just estimates of costs
and benefits. In short, the bigger the project, the more detailed research will be demanded by the
investors before they agree to proceed and fund the project.
Final thoughts on the business case

The production of the business case is so important that it needs to be re-evaluated frequently over
the full life cycle of the project. This is because the business environment may well change during
the project, which may have a major financial impact – positive or negative.
OVER TO YOU
Activity 7: Romsat project business case
Romsat is a technology company considering whether to proceed with a new project

to design, build, launch and operate a new commercial satellite.
If it decides to go ahead, it will need 11 months to design and build the satellite.
Launching will then take one month and from that point the company can gain sales
revenues by charging clients to broadcast from the satellite.
The Romsat marketing manager expects that once the satellite is operational (after
launching) they will sign contracts with six clients each of which will pay $1.2m p.a.
Revenues will then grow by 10% each year.
Romsat engineers believe the satellite will have a four-year life after it is launched
into orbit.
If the company decides to proceed with the project, the following costs will be
incurred:
• operating licence fee $2m – payable immediately;
• design, build and launch costs $8.5m – payable at the end of Year 1;
• operating costs $1.5m p.a. – payable after the launch.
Using only the financial information provided in the scenario, create a table setting
out the costs and benefits to show a year-by-year breakdown of all the cash flows.
Apply whatever metrics you feel are appropriate to the annual cash flows to determine
whether or not the project will be profitable. The company cost of capital is 5%. Show
your workings and comment on the outcomes.
Explain why the development of a sound business case is critical to any project being
carried out by a commercial business organisation such as Romsat.
16 © ABE
1.3 Work breakdown structure

A project WBS is a work-oriented grouping of project work elements shown in a graphical hierarchy
in order to define, organise and subdivide the total work scope of a project.
The main benefit of a WBS is to simplify the overall scope of work in the project and break it up
into a logical structure that can be more easily understood.
For example, consider the challenge of designing and constructing an offshore production platform – a
complex engineering project with many different systems, technologies and processes. It needs to be
broken down into pieces – eight in this case (Figure 2).
F
C E
D G
Figure 2: Platform broken into pieces REVISION

on the go
Suddenly the technical challenge is not quite so daunting. A specialist engineering team
can be assigned to each component and then each component is broken down further
into its various systems, each system being regarded as a work package.
When all the various systems are delivered, they can be assembled into the eight components, and finally
the eight components come together to form the entire platform. Some ‘hook-up’ work is required to
connect the components and finally you have an offshore platform that produces oil for several years.
© ABE 17
Overview and process

A good WBS is the cornerstone of effective project planning, execution, control and reporting.
All the work contained within the WBS is to be identified, estimated, scheduled and budgeted.
All the project components are formed into a logical hierarchy which defines the total project scope.
A WBS is deliverable oriented and each descending level within the hierarchy represents an
increasingly detailed definition of a WBS component.
In addition to capturing the full scope of work, it is also a helpful basis for a high level cost estimate
for the project. Instead of trying to estimate the cost of the whole project (which could be very
inaccurate) costs can be estimated for all the lower level work packages and then ‘rolled up’ to give
a much more accurate estimate for the entire project.
Understanding man-hours
When the WBS has been broken down to the work package level it should be possible to understand
exactly what the package of work entails and make a rough estimate of the man-hours required.
Note that man-hours are not a measure of duration. They are a measure of the work required.
In the following example, the project WBS has been broken down into six main components, and
each component has been broken down further into work packages using a logical numbering
system (Figure 3).
Oil Refinery Project
1. Conceptual Design 4. Project Administration
1.1 Conceptual Design 4.1 Project Control

1.2 Criteria Development 4.2 Records Management
4.3 Support Services
4.4 Engineering
4.5 Independent Construction
Cost Estimate
2. Design 5. Systems Development
2.1 Definitive Design 5.1 Process Development

2.2 CADD Consultant 5.2 Design Support
2.3 Engineering Support 5.3 Plant Liaison
5.4 Computer/Control
System Development
3. Construction 6. Startup
3.1 Construction Preparation 6.1 Test Preparation

3.2 Building 6.2 Test Performance
3.3 Process & Service 6.3 Manuals
3.4 Construction Inspection 6.4 Integrated Testing
Figure 3: Oil refinery project WBS REVISION

on the go
18 © ABE
The man-hours for each work package are provided, and have been subtotalled at the component
level (Table 7).
WBS code Title Man-hours
1 Conceptual design 7000

1.1 Conceptual design 5000
1.2 Criteria development 2000
2 Design 41500
2.1 Definitive design 22000
2.2 CADD consultant 4500
2.3 Engineering support 15000
3 Construction 289500
3.1 Construction preparation 12000
3.2 Building 264000
3.3 Process and service systems 9500
3.4 Construction inspection 4000
4 Project administration 26300
4.1 Project control 7600
4.2 Records management 2500
4.3 Support services 9500
4.4 Engineering 6600
4.5 Independent construction cost estimate 1000
5 Systems development 8900
5.1 Process development 3400
5.2 Design support 1800
5.3 Plant liaison 2200
5.4 Computer/Control system development 1500
6 Start-up 5800
6.1 Test preparation 800
6.2 Test performance 3200
6.3 Manuals 1200
6.4 Integrated testing 600
Table 7: Man-hours calculation REVISION

on the go
© ABE 19
Firstly, all the top-level components could be totalled to give 379,000 man-hours for the project.
If the project manager estimates the average man-hour cost for each component, more useful
information can be found out.
Average man-hour Total estimated

Code Component Total man-hours
cost ($) cost ($)
1 Conceptual Design 75 7000 525000
2 Design 65 41500 2697500
3 Construction 40 289500 11580000
4 Project Administration 32 26300 841600
5 Systems Development 72 8900 640800
6 Start-up 65 5800 377000
16661900
Table 8: Man-hours cost calculation REVISION

on the go
Ignoring the possibility of any fixed costs, we can see that the high level budget estimate
(Table 8) is nearly $16.7m. This is useful information, especially at an early stage when the
business case is being prepared and sponsors are demanding some form of estimate to consider.
CASE STUDY
Moshono School budget
Moshono is a small, fictitious township of 10,000
people. There are three primary schools serving
the local population whose fees are beyond the
means of the poorest residents.
In response, a small group of local people became
the trustees of a charity to build and operate a
fourth primary school in Moshono, intended to
accommodate at least 200 local children who
would otherwise have no chance of a basic
education. Although a local landowner donated
a suitable plot of land, securing sufficient funds
to build the school was a problem from the outset. Fortunately, after contacting numerous
organisations, the East African Education Trust (EAET) agreed to help.
After careful inspection of the site and the first drawings for the school, EAET allocated a grant
of $50,000. At this point, the EAET made it very clear in writing that no further funds would be
available beyond the $50,000.
Enthused by their success in obtaining the funding, the trustees of the charity empowered an
experienced architect to analyse the full scope of the project using a WBS diagram (Figure 4).
20 © ABE
School Building
6.0 Playground
1.0 Preparation 2.0 Earth Works 3.0 Site preparation 4.0 Construction work 5.0 Decorating
and Lawn
1.1 Finalise design 2.1 Clear site 3.1 Lay electrics 4.1 Erect walls 5.1 Exterior paintwork 6.1 Lay paving slabs
1.2 Planning permission 2.2 Trenches for cables 3.2 Lay pipes for drains 4.2 Build roof 5.2 Interior paintwork 6.2 Play area and lawns
1.3 Select supplier 2.3 Drains 1.3 Lay pipes for water 4.3 Doors and windows 5.3 Interior lighting 6.3 Perimeter fencing
2.3 Excavate play area 3.4 Backfill trenches 4.4 Kitchen and toilets 5.4 Floor coverings
2.5 Remove soil from site 3.5 Lay base for play area 4.5 Install electrical supply
3.6 Lay base for building
Figure 4: WBS diagram created by the architect – Moshono School
In addition, he estimated the man-hours required for each work package (Table 9):
Work Man- Work Man- Work Man- Work Man- Work Man-
package hours package hours package hours package hours package hours
2.1 100 3.1 100 4.1 300 5.1 100 6.1 150
2.2 150 3.2 150 4.2 300 5.2 100 6.2 100
2.3 100 3.3 150 4.3 150 5.3 50 6.3 100
2.4 100 3.4 200 4.4 150 5.4 100
2.5 50 3.5 100 4.5 100
3.6 200
Table 9: Man-hours for each work package
The architect assumed that all the work for component 1.0 Preparation would be carried out by
his firm for a fixed fee of $1500.
He also estimated an extra sum of $20,000 would be required for all the materials for all the
work packages.
After consulting with some local business people in the construction industry, he estimated
that each man-hour of work on the project across all the WBS components (2–6) would cost an
average of $8.00.
OVER TO YOU
Activity 8: Moshono School budget
Using the information provided in the case study, calculate a preliminary budget
estimate for the whole project.
When you have finished, check your answer against the guidance provided at the end of the
study guide.
© ABE 21
1.4 Project risk management

Good project managers will spend time worrying about possible risks and finding ways to either
make sure they do not happen, or if this is not possible, putting in place appropriate contingency
measures and plans for if they do.
Compromising the viability or performance of the project by neglecting a significant risk or risks
which could and should have been identified and addressed is hardly indicative of managerial
competence. In other words, ‘bad news’ should never arrive out of the blue as an unpleasant
surprise; the possibility should have been identified and analysed, with contingencies and responses
prepared and put in place well in advance.
Defining risk management

Firstly, let us consider the regular definition of the term ‘risk management’. Project risk
management is all about using intelligence, experience and research to find proactive strategies to
deal with risks, preferably as a preventive measure.
It is important to understand the simple five-stage risk management process, which should be led
by the project manager and draw on the input of as many colleagues as possible.
1 Identify all potential risks which might impact the project by using a risk register (or risk log).
2 Assess each risk in terms of the potential impact on the project.
3 Assess each risk in terms of the likelihood of occurrence.
4 Devise, document, implement and monitor an appropriate response for each risk.
5 Review stages 1–4 on a regular basis.
Risk identification and the risk log

Of the entire risk management process, identification is arguably the easiest. Through a
combination of experience, consultations, reference to checklists, monitoring and project
managerial common sense, a list of potential risks can be developed. This is best undertaken as a
vigorous initial exercise (in parallel with planning) complemented by a series of continuous reviews
over the life cycle of the project. It supports the concept of a ‘risk log’ recommended by several
22 © ABE
methodologies including PRINCE2. The risk log is a document listing all potential risks (and
subsequent treatments), widely accessible by project staff and, frequently, other external parties
such as the project board and sponsors.
It should be noted that the risk log should be managed as a dynamic document, frequently revisited and
updated, with new and amended risks as they develop over the life cycle of the project. Good practice
suggests that anyone connected with the project should be able to raise potential risks for analysis.
NEED TO KNOW
A risk log usually includes the following:
Unique number Date of last update Countermeasure(s)
Risk type Description Owner
Author Likelihood Status
Date identified Severity of effect (impact) REVISION
on the go
Whether or not a project follows this structure precisely is not critical. What is vital is that a
documented approach is instigated from the earliest stages of the project. In terms of what risk
information to include, a guiding principle is: ‘When in doubt don’t leave it out.’ Failing to identify
a major risk well in advance could well have very serious consequences.
Experience from similar projects in the past is extremely valuable at this point. You should try to
build a strong working relationship with your colleagues and other project contacts, and ask the
question: ‘Is there anything I should be wary of here?’
CASE STUDY
Website project
A large UK-based construction company has invested the
equivalent of $500m to establish a subsidiary company
in Spain with the intention of building 10 vacation resorts
along its southern coast, close to regional airports. The
company has borrowed heavily and it is imperative that
the venture proves successful. The resorts are aimed at
the lower end of the market and will offer a range of
simple low cost apartments on a timeshare basis.
An innovative IT project has been launched to support

the business strategy: a website will be developed to enable interested buyers – probably from
Northern Europe – to take a virtual tour around any apartment of interest, view live webcams
from the resorts, and crucially be able to bid on any apartment using a sophisticated online
auction process. Market research indicated that this was the best way to attain maximum
revenue from the new resorts, and traditional selling mechanisms were discounted.
The company’s IT manager was put in charge of the project with a substantial budget. She
sought out two experienced, expensive freelance software experts who had worked together
successfully before. No references were checked but after three months they appeared to be
making good progress, regularly flying back and forward between London and the resorts in
Spain. No documentation was produced by the experts, or requested, as they were far too busy
with software development work.
© ABE 23
OVER TO YOU
Activity 9: Website project
What do you think are the key risks to the project described in the case study? How
would you deal with them?
Ranking each risk with a matrix

In rough terms, a risk of high impact but low probability should be accorded approximately the
same attention as a risk of relatively low impact but high probability. The risk management matrix is
a simple grid with one axis representing the potential impact of a risk and the other the likelihood
(probability) of the risk happening.
Figure 5 shows a 5 × 5 risk matrix in which red typically represents risks of the greatest concern
(significance) and green the least, allowing you to prioritise the risks. A risk placed into the upper
right cell (high likelihood and high impact) would be of high importance and demand immediate
attention, while risks in the lower left cell would be of less immediate interest. The colours are
assigned by multiplying the likelihood by the impact, with the largest resultant values being red,
and so on.
4
risk occurring
Likelihood of
1 2 3 4 5
Impact if risk does occur
Figure 5: The 5 × 5 matrix REVISION

on the go
24 © ABE
OVER TO YOU
Activity 10: Risk rating for hospital IT project
As part of the risk analysis phase of a major hospital IT project, the project manager
compiled the following list of significant risks.
Risk 1. The in-house team may experience technical difficulties, overrun on time and
this will impact patient care. (LIKELIHOOD: 3) (IMPACT: 5)
Risk 2. Due to delays and the need to bring in a considerable number of freelance
programmers, the costs of the project may exceed the available budget.
(LIKELIHOOD: 1) (IMPACT: 1)
Risk 3. The original system designers may leave the employment of the hospital.
(LIKELIHOOD: 3) (IMPACT: 3)
Risk 4. The new system may not integrate properly with other medical information
systems. (LIKELIHOOD: 5) (IMPACT: 3)
Risk 5. The team may develop the wrong functions and properties based on an
inadequate specification. (LIKELIHOOD: 5) (IMPACT: 5)
Using a 5 × 5 risk matrix, prioritise the risks identified by the project manager.
When you have finished, check your answer against the guidance provided at the end of the
chapter.
Devising responses to risks

There are five distinct responses to a risk:
• acceptance • transference
• prevention • contingency planning
• reduction
Agreeing a way to deal with a risk is essential even if the response is a straightforward acceptance
of the risk.
Acceptance
In a sense, this is the inevitable default option: do nothing and accept the risk without any further action
or provision. A decision to adopt this option should only follow a full and frank discussion, and it should
be accompanied by a firm commitment to continual and diligent risk monitoring. The project has no
protection in place for this risk, and should the probability of occurrence or potential impact suddenly
increase for any reason, the project manager and senior team must be appraised immediately.
© ABE 25
Prevention
In some risk cases, options are available to the project to prevent the risk from ever occurring at all.
‘Is it possible to take measures to stop this from happening?’ being the initial response to any risk
identified. Occasionally a low cost preventive solution can be readily devised; however, more likely is
that risk prevention will create significant costs, thereby triggering the need for a cost–benefit analysis.
Reduction
Reduction might apply to both the likelihood of the risk occurring and the potential impact of the
risk. Reducing either, or preferably both, would normally be attractive to the project unless the
measures proposed necessitate prohibitive expense.
Transference
This involves the contractual transfer of a defined risk to another party, either to an insurance company or
a contractor. Such opportunities should always be considered especially where the impact is significant,
and the risk is well defined and completely outside the control of the project team.
Contingency planning
In cases where prevention, reduction or transference are not available on a cost-effective basis,
contingency planning is likely to be a superior option to mere acceptance. This will require management
time devoted to anticipating the full impact of a particular risk happening, and devising a set of coherent
plans to address every aspect of the situation, including appropriate financial provisions. All of these
must be well documented and, depending on circumstances, tested. Clearly this exercise cannot be
undertaken effectively in isolation – wide consultations are required.
OVER TO YOU
Activity 11: Radio system project
A regional police force has decided to embark on a project to replace their radio
system. The following is an incomplete extract from the risk register for the project:
1.1 Project manager resigns suddenly in the middle of the project.
1.2 The preferred technology supplier is at risk of insolvency.
1.3 Technology costs rise due to exchange rate changes.
1.4 A serious accident occurs during construction of new radio masts.
1.5 The new radio system does not work properly in the nearby mountains.
For each risk shown on the register, suggest one appropriate method of treatment for
that risk. This is a subjective area and your response may well be different to that of
some other students. The challenge is to think of anything that could mitigate the risk,
rather than just hoping it does not happen.
26 © ABE
OVER TO YOU
Activity 12: Moshono School risks
Review the information already provided about the Moshono School project.
Create a list of all the possible risks that could occur before, during and after the
construction of the school. For example, you should consider risks relating to time,
cost, people, regulations, materials, weather, etc. Think what practical measures you
could put in place to deal with these risks. Make your notes here.
© ABE 27
Chapter 2
Creating an Effective
Project Plan
Introduction
Being able to plan a project effectively is a core skill required by all project managers.
It could be said that planning is the professional domain of the planning engineer, which is
frequently an early stage in a project management career. However, the majority of project
managers come into a leadership role from a different direction, typically as a technical or
business specialist moving into project-based work. Professionals like these need to learn all
the basic planning tools and techniques in order to complement their discipline knowledge,
and to address any major gaps in their personal skills set.
Learning outcome
2 Develop a project plan based on a set of input data
Assessment criteria
2 Develop a project plan based on a set of input data
2.1 Construct a network diagram from a set of tasks
2.2 Develop a simple Gantt chart from a set of tasks
2.3 Apply critical path analysis to determine the planned duration of a project
2.4 Calculate the start and finish dates of a project and its tasks
© ABE
Level 4
Project Management
2.1 Project planning with network diagrams

Fundamentals
The first fundamental concept to grasp is that any ‘project’ can be broken down into a number of
individual component ‘tasks’. Some plans, books and project management software packages
may refer to such tasks as ‘activities’, but for simplicity and consistency we will stick to ‘tasks’. The sum
of all tasks should equal the full work scope of the project. No part of the project can be excluded. In
other words, when all the project tasks are complete, the project itself is complete.
So the first step is to divide the entire project work scope into a logical set of tasks (activities).
This immediately raises the question: How many tasks should I end up with?
The number of tasks will depend on the scale of the project but each task should be well defined,
able to be understood, resourced and costed separately, and carried out as a discrete package of
work. Any previous planning experience helps to achieve this balance. A task designated ‘Phase
1 Construction work’ is almost certainly too high level, vague and generalised to be of any real
practical value – the realistic likelihood is that the ‘Phase 1’ work scope needs to be chopped up
further to enable its component tasks to be identified and managed effectively.
However, do not gravitate to the other extreme and try to define a project as an absurd number
of ‘micro-tasks’. In terms of a house-building example, such micro-tasks might include ‘install
washbasin’, ‘install shower cubicle’, ‘install lighting’, etc. rather than a much more realistic ‘fit-out
bathroom’. As a general rule, the scope of a task should be small enough to be easily measurable
yet large enough to be worthy of management attention.
In the house-building example, the project/site manager might well be interested in knowing
whether the plumber was installing all the bathroom facilities on schedule but almost certainly not
interested in all the individual bathroom items.
Tasks may well be dependent on others (e.g. it is not possible to commence Task C before Task
B is complete) but the work defined as Task C must not be integrated or duplicated in any way
with the defined Task B work. The issue of sequencing tasks comes later under network logic
and predecessors.
For assessment purposes, you are less likely to have to break a project down into its component
tasks; you are more likely to be provided with a project to analyse which has already been broken
down into a list of tasks.
© ABE 29
Chapter 2 Creating an Effective Project Plan
The five basic steps of planning

Planning can be broken down into five basic steps:
1 Identify all the separate tasks that need to be undertaken as part of the project
(generally provided to you).
2 Estimate the time it will take to complete each task (also provided).
3 Identify the logical order in which each task must be completed (also provided).
4 Construct a network diagram.
5 Calculate the planned project duration and other pieces of useful project planning and
management information (see Chapter 2).
Example project
Consider a simplified house-building project that we can break down into eight tasks and assign a
reference code (in this case, number) to (Table 1). Then estimate the time required for each task.
Task Description Duration (working days)
1 Design house 20
2 Lay foundations 12
3 Erect walls 20
4 Build roof 18
5 Electrical work 15
6 Plumbing 12
7 Painting 14
8 Fit carpets 5
Table 1: House-building tasks and estimated duration REVISION

on the go
20 working days is the same as four weeks because weekends are usually ignored. On larger
and longer projects, the durations of tasks may well be estimated in weeks.
Step 3 requires us to analyse the order or sequence of tasks – what comes first, what follows, what
tasks must be done before another can start, etc. In real life, analysing this correctly does require
some knowledge of the work being carried out, but in a study environment all this is done for you.
The usual way of doing this is to state the predecessors for each task (Table 2), except for the task/s
that start the project because no predecessors will come before them. The word ‘predecessor’
means something that came before another thing.
30 © ABE
Creating an Effective Project Plan Chapter 2
Task Description Duration Predecessor
1 Design house 20d –
2 Lay foundations 12d 1
3 Erect walls 20d 2
4 Build roof 18d 3
5 Electrical work 15d 3
6 Plumbing 12d 3
7 Painting 14d 5, 6
8 Fit carpets 5d 4, 7
Table 2: Predecessors for house-building task (d = working day/s) REVISION

on the go
Note that it is perfectly acceptable for a task to have more than one predecessor, as do
Tasks 7 and 8 in this example.
Network diagrams
In Step 4, we need to draw an accurate network diagram based on the table of inputs provided. We
will be adopting the modern precedence notation for this – each task will be represented by a box,
and the sequence (order) of boxes will be shown by arrows, for example:
Task 1 Task 2
Design house Lay foundations
20 days 12 days
Figure 1: Network diagram – Part A REVISION

on the go
Note that the first box starts on the left and the sequence flows from left to right across
the page – not top to bottom.
Secondly, you may come across some textbooks that show the tasks represented as arrows rather
than boxes. This is called activity-on-arrow notation and can work well, but it is more complicated
and confusing without giving you any extra benefits.
Thirdly, some sources will expect you to pack a lot more detail into each task box, such as
additional information that has not been calculated yet. However, let us keep things simple and
stick with the boxes as shown.
© ABE 31
Task 3 follows Task 2 (i.e. Task 2 is the predecessor of Task 3), and then Tasks 4, 5 and 6 all follow
Task 3. So we have three boxes all following Task 3.
Task 4
Build roof
18 days
Task 1 Task 2 Task 3 Task 5

Design house Lay foundations Erect walls Electrical work
20 days 12 days 20 days 15 days
Task 6
Plumbing
12 days
Figure 2: Network diagram – Part B REVISION

on the go
We can see that Task 7 has two predecessors – Tasks 5 and 6 – and that Task 8 also has two
predecessors – Tasks 4 and 7. We need to represent these properly with arrows as shown.
Task 4
Build roof
18 days
Task 8
Fit carpets
5 days
Task 7
Painting
14 days
Task 6
Plumbing
12 days
Figure 3: Network diagram – Part C REVISION

on the go
Finally, we have a completed network diagram which represents a plan for the project. Most
professionals prefer to work with visual diagrams rather than wordy descriptions.
Larger projects
The network diagram for a more complicated project, such as a long railway tunnel, would have
many more tasks, with numerous sequences (paths) running in parallel or concurrently. However, the
underlying planning theory is exactly the same as for the simpler house example.
32 © ABE
OVER TO YOU
Activity 1: Planning the Moshono School project
Enthused by their success in obtaining the funding required, the trustees of the charity
empowered an experienced architect to draw up a project plan based on the WBS. The
basic network logic of the school construction phase was drafted as set out in Table 3.
Task Description Duration (weeks) Predecessor
1 Site levelling 1w –
2 Lay foundations 2w 1
3 Erect classrooms 6w 2
4 School offices 2w 3
5 Lay drainage 2w 2
6 Build dormitories 3w 5
7 Build kitchen 1w 5
8 Fit electrical services 2w 4,6,7
9 Internal decorating 1w 8
10 Erect perimeter fencing 4w 1
11 Project completion 0d 9,10
Only weekdays would be worked, not weekends
Table 3: network logic for the school construction phase
With careful reference to this table, create a network diagram for the school project.
If you have access to user-friendly computer tools such as PowerPoint, Paint or a

similar graphics package, that would be ideal. If not, creating a very neat diagram
with paper, pencil, ruler, and eraser can work just as well.
Remember, neatness and clarity are very important. A poor quality diagram will lead
to errors in subsequent analyses.
© ABE 33
CASE STUDY
Blitz Alloys
Blitz Alloys is a small company producing specialist alloy wheels for cars.
The board has decided to relocate manufacturing operations to China.
The move will entail a small team of Blitz design engineers relocating
to China. They will be situated in a new office building adjacent to the
factory. The production director has drawn up a schedule of activities for
the relocation as shown in Table 4:
Task Description Duration (days) Predecessor
A Complete Project Initiation Document 5 none
B Develop specification of new site 10 A
C Identify staff who will relocate to China 5 A
D Install communications at new site 5 B
E New contract signed by staff 0 C
F Install hardware/software at new site 10 D
G Install furniture at new site 10 B
H Integrate resources at new site 15 G, F, E
I New site fully operational 0 H
Table 4: Schedule of activities
OVER TO YOU
Activity 2: Blitz Alloys
Using the information provided in Table 4, create a network diagram for the Blitz
Alloys project.
34 © ABE
Don’t worry if you see tasks with a duration of 0 days (Task E and Task I).
The technical name for these tasks is milestones. A milestone is used to mark a significant
event in the life cycle of a project. These points may signal events such as a project
start and end date, a contract being signed, a need for external review or a
major event such as a factory starting production for the first time. REVISION
on the go
2.2 Project planning with Gantt charts

A Gantt chart is just a different representation of exactly the same data as is shown in a network
diagram and they are often used by project managers. You need to understand them and be able
to create them if required.
In a Gantt chart, each task is represented by a horizontal bar. The length of the bar shows the
duration of the task. The upper axis shows a timescale for the project, so the position of the bar
indicates the planned start and the planned finish of each task.
Let us start at the top with the basic upper axis:
Timescale shown in working days

Task Description 5 10 15 20 25 30 35 40 45 50 55 60 65 70 75 80 85 90
Figure 4: Gantt chart – Part A REVISION

on the go
Using the earlier house-building project as an example, add in one task at a time, starting
with Task 1 Design house (20 days).

1 Design house
Figure 5: Gantt chart – Part B REVISION

on the go
From the information provided, we can see that Task 2 follows Task 1 and has a planned duration
of 12 days. So the start of the Task 2 bar starts at the end of the Task 1 bar. In a similar fashion,
Task 3 follows Task 2.
© ABE 35

1 Design house
2 Lay foundations
3 Erect walls
Figure 6: Gantt chart – Part C REVISION

on the go
Task 4, Task 5 and Task 6 all follow after the end of Task 3.
Task 7 follows both Tasks 5 and 6, which means that the start of Task 7 must be aligned with the
latest finish point of Tasks 5 and 6.

1 Design house
2 Lay foundations
3 Erect walls
4 Build roof
5 Electrical work
6 Plumbing
7 Painting
8 Fit carpets
Figure 7: Gantt chart – Part D REVISION

on the go
Similarly, Task 8 follows both Tasks 4 and 7, so the start of Task 8 is aligned with the latest
finish point of Tasks 4 and 7.

1 Design house
2 Lay foundations
3 Erect walls
4 Build roof
5 Electrical work
6 Plumbing
7 Painting
8 Fit carpets
Figure 8: Gantt chart – Part E REVISION

on the go
Note that the timescale does not always have to be calibrated in working days. It could be
weeks or it could be a calendar type timescale showing the months and dates.
36 © ABE
OVER TO YOU
Activity 3: Moshono School Gantt chart
Using whatever tools you prefer, create a Gantt chart for the Moshono School project.
The upper axis of the Gantt chart should be a simple timescale calibrated in weeks –
Week 1, Week 2, etc.
OVER TO YOU
Activity 4: Blitz Alloys Gantt chart
The chief executive of Blitz Alloys is not familiar with the use of a network diagram to
review the project plan. She has demanded a Gantt chart instead. Create a Gantt chart
from the information already provided.
2.3 Applying critical path analysis

Identifying the critical path
In critical path analysis (CPA) we refer to a network diagram and find the longest path from any
start point (task) to any end point (task).
Using the house-building example we can see that there are three paths to get from Tasks 1 to 8:
through Tasks 1-2-3-4-8, Tasks 1-2-3-5-7-8 and Tasks 1-2-3-6-7-8.
© ABE 37
Task 4
Build roof
18 days
Task 8
Fit carpets
5 days
Task 7
Painting
14 days
Task 6
Plumbing
12 days
Figure 9: Network diagram – house-building project REVISION

on the go
The second option 1-2-3-5-7-8, which totals 86 days, is longer in terms of duration than
the other two paths, and is thus the ‘critical path’.
It is slightly more challenging with a more complex network, more tasks and several paths but the
principle is the same – focus on all possible paths and find the longest one. For highly complex
networks involving hundreds of concurrent tasks, project management software will help.
It is recommended to take a red pen and highlight the critical path on the network diagram. This is
a global diagramming convention, i.e. red in project management denotes criticality.
Planned durations
One benefit of doing this is to calculate the planned duration of the project – 86 days. This is the
planned duration and is not certain.
Why else is the critical path so important?

It is important because those critical tasks are key to the project time schedule. If they take any longer
than expected, the overall planned duration and project end date will be immediately affected by
the same delay. Hence, the important word, critical. Every project manager should be aware of which
tasks are critical and which are not in order to focus on the critical tasks and do everything to get
them started and finished on time. If a critical task is delayed, the only way to complete the project on
time is probably to steal some time from subsequent critical tasks (which is never easy).
You can look at it the other way around. The completion of tasks not on the critical path (usually
called non-critical) may be delayed for an amount of time without impacting the overall project
end date. The length of the permissible delay/tolerance for each non-critical task depends
on the relationship with the surrounding critical tasks and how long they are all likely to take.
This permissible delay is usually called float (or slack) and is also of considerable interest to a
competent project manager.
What if there are two or more paths that have the same (longest) duration?
It is possible to have two critical paths and this happens quite often. The critical path may change
during the execution of the project because task durations may well be different to what was first
planned. But this is not a disaster if you understand the simple principles outlined previously and
know how to react and deal with it.
38 © ABE
For the Blitz Alloys activity in Chapter 1 you should have created a simple network diagram similar
to this:
Task D Task F
10 days 10 days
Task B
10 days
Task G Task H Task I
10 days 15 days 0 days
Task A
5 days
Task C Task E
5 days 0 days
Figure 10: Network diagram – Blitz Alloys project REVISION

on the go
You should be able to see that there are three paths through the network from start to finish:
A-B-D-F-H-I with a duration of 45 days, A-B-G-H-I with a duration of 40 days and A-C-E-H-I with a
duration of 25 days.
So, the critical path runs through Tasks A-B-D-F-H-I and this project has a planned duration of 45
days (or nine weeks).
OVER TO YOU
Activity 5: Moshono School critical path
Using the network diagram created for the Moshono School project in Activity 1 in
this chapter, identify which tasks lie on the critical path and therefore calculate the
planned duration (in working days) of the project.
OVER TO YOU
Activity 6: Critical tasks in the Blitz Alloys project
Before agreeing to proceed with the relocation project, the chief executive wants to
know which of the project tasks are critical, and the planned duration of the project.
Analyse the network diagram created previously and supply this information.
© ABE 39
2.4 Calculating start and finish dates

Let us imagine we are involved as the fee-paying client on a significant project. From this
perspective, three particular aspects will be of paramount interest to us, which takes us back to the
Iron Triangle. These impact every project and can be summed up in the following questions.
1 How much will it eventually cost us?
2 When will all the work start – and more importantly – when will it be finished?
3 Will the project products be fit for purpose when we finally take delivery of them?
This section addresses the principle of time analysis raised by Question 2 (Question 1 is related to
costs, budgets and resources, and Question 3 relates to quality – these are covered in subsequent
sections). If you have done careful, diligent work creating a network diagram and CPA, finding the
right answer to Question 2 should not cause any serious difficulties.
If you know the planned duration of the project (from the critical path) together with the start date,
it is straightforward to pick up a calendar and figure out the planned finish date. For example, if
a project is analysed to have a planned duration of 30 working days (six weeks) and is planned to
start on Monday 6 March, it is easy to see from a calendar that the planned finish should be Friday
14 April.
Alternatively, if preferred we can work backwards from a target delivery date. For example, if the
target completion date of the same project is Friday 30 June, we can pick up the calendar again,
count back six weeks and figure out that the project needs to start no later than Monday 22 May.
Thirdly, we can also consider the planned start and finish dates of all the individual project tasks –
not just the entire project. Providing we have a neat and accurate network diagram to work with
(and a calendar), we can start with the first task and work steadily through the network figuring out
the planned start and planned finish date of every task.
This might take a while if the network has lots of tasks, but the benefits may well be worth all the
work. This kind of detail is useful when scaled up and applied to a real business project. Let us
consider a more substantial project as an example.
In Figure 9, the simplified plan for the building of the new house, you might disagree with the
network logic (is it wise to start any electrical work before the roof is completely finished?) but as
before, just accept it for now as a simple example.
Applying CPA, we saw that the critical path runs through Tasks 1-2-3-5-7-8 and has a planned
duration of 86 working days.
Once you know the planned duration, you should be able to work out the planned finish date for
the project (if the project start date is known to you or assumed). A planned start and finish date for
each task is also easily calculated, with the aid of a calendar or suitable software.
Let us pick a nominal project start date of 5 January, which happens to be a Monday. This is the
precise day on which Task 1 should start. So as the planned duration of Task 1 is known (20 days –
four weeks) it should be fairly clear that Task 1 should be finished at the end of the working day on
Friday 30 January. Remember: it is assumed there will be no weekend working.
Knowing this we can calculate the planned start of Task 2 as being Monday 2 February. And
so on, working our way from left to right until we reach the end. This is otherwise known as a
‘forward pass’.
40 © ABE
Some tasks, such as Task 7, are dependent on two or more predecessors and cannot start until all
predecessors are complete. Task 7 is thus scheduled to start on Wednesday 8 April after the later of
its two predecessors (Task 5), which finishes on Tuesday 7 April.
Task 4
Build roof
Wed 18 Mar
Fri 10 Apr Task 8
Fit carpets
Tue 28 Apr
Task 1 Task 2 Task 3 Task 5 Mon 4 May
Design Foundations Erect walls Electrics
Mon 5 Jan Mon 2 Feb Wed 18 Feb Wed 18 Mar
Fri 30 Jan Tue 17 Feb Tue 17 Mar Tue 7 Apr Task 7
Painting
Wed 8 Apr
Task 6 Mon 27 Apr
Plumbing
Wed 18 Mar
Thu 2 Apr
Figure 11: Network diagram for a new house with planned start/finish dates REVISION
on the go
You can see that the project is planned to finish around 5 p.m. on Monday 4 May. This provides
a plan for everyone to engage with, and challenge, as a means to manage all the important
week-by-week work on the project. This has a lot of practical advantages.
For example, if the Painting work is to be subcontracted, the project manager will be able to
advise the Painting contractor that they are likely to be required on site from Wednesday 8 April
and are expected to be finished and gone by Monday 27 April. If the contractor responds by
saying that they are very busy on other jobs and cannot start until Monday 13 April, you can
still take an assertive stance and say ‘That is only acceptable to me as long as you are still 100%
finished by Monday 27 April. If you cannot guarantee that, we will have to engage another firm
for this task.’ (If the terms in any contract allow.)
Why such a tough message? Because Painting is a critical task (it is on the critical path). If it is not
completed on schedule, it will immediately delay the start of the final critical task (Fit carpets) and
jeopardise the timely completion of the entire project.
A slightly different approach can be taken when discussing non-critical tasks such as Task 4 (Build
roof). If at some point the foreman/forewoman in charge of this roof work complains ‘Whoever
thought we could do all this work in 18 days? No way will it all get done by Friday 10 April,’ rather
than get into an unproductive argument, the foreman could be asked to provide the date when the
roof will be finished. Let us imagine the response is ‘Not before Wednesday 22 April at the earliest.’
Now you can use your knowledge of the project plan in a professional manner. Task 8 is dependent
on Task 4 but Task 8 is not scheduled to start until Tuesday 28 April (as it also depends on the
completion of the critical Task 7). So as long as the roof (Task 4) is finished before Tuesday 28 April,
you could live with this change.
Clearly if any of the task durations change (either as adjustments to the plan or due to project
events as they take place), the subsequent task dates may alter. This brings us to the final step in
the CPA process.
© ABE 41
Options for constraints: lag and lead times

It is also worth allocating time to consider the nature of logical network constraints, and the options
available to the astute planner. You should already be well aware that constraints are represented by
lines (or arrows) connecting the tasks, and are an essential planning concept enabling the creation of
basic network logic. Network diagrams and Gantt charts could not exist without such relations.
Now in their simplistic sense, a constraint line from Task A to Task B just means that Task B cannot
start before Task A has finished. And so on throughout the network.
However, reality tends to intervene occasionally. Consider the possibility of an enforced time
lag between tasks. A good example is the relationship between plastering and painting tasks
in a house renovation project. Painting certainly follows plastering, but it is not a great idea to
paint walls and ceilings unless the plaster is bone dry – a process usually taking at least a week
depending on the prevailing climate and other factors.
You could of course accommodate this factor by extending the duration of the plastering task by
the requisite drying out time but this is unrealistic and potentially costly if plasterers are being
hired for the duration of the task. The correct solution, supported by Microsoft Project and similar
software packages, is to specify a lag parameter of the appropriate duration against the constraint.
In this example, the lag would be five working days.
This will cause the planned start date of the succeeding task to be based on the planned finish date
of the predecessor plus the defined lag. Another reasonable example would be the need for a lag
between a milestone (event) called ‘Issue of Tender Documents’ and the following task ‘Review of
Tender Submissions’. The duration of the lag would of course be the time allowed for contractors to
respond with their tenders, for example four weeks.
Note also that the converse of a lag may occur, especially when tasks have been defined at a
reasonably high level. For example, consider the real-world relationship between ‘systems analysis’ and
‘systems design’ tasks on an IT development project. Although most plans would have design work
following logically in sequence behind analysis, 9 times out of 10 some design work would commence
before the systems analysis activities were 100% complete. This would almost certainly be realistic and
professional but might contradict the explicit sequence of the tasks on the planning network.
In this case, setting a lead time on the constraint is appropriate. For example, a one-week lead
against the constraint will mean that the succeeding task will be scheduled to start one week before
the end of the preceding task. This could be realistic and useful.
OVER TO YOU
Activity 7: Moshono School target finish date
The Moshono School trustees began to be concerned that the time required to build
the school was slipping away. At a project meeting in mid-May, it was pointed out
that the school (and thus project) must be complete by the end of August in order to
accommodate the first cohort of students expected to start the school year in early
September. If this target date could not be achieved, the start of the academic year
would be delayed.
All involved knew that the earliest possible start date for the project was 1 June.
Using the original plan (network diagram) (Activity 1, Chapter 2), assess whether the
target finish date of 31 August should be achievable. Show your working and be able
to explain your analysis.
42 © ABE
CASE STUDY
Blitz Alloys
The project was scheduled to commence on Monday 5 April. Note that all days quoted are
working days (i.e. five days equates to one week as weekends will not be worked). Ignore the
possibility of any holidays. Refer to the calendar in Figure 12.
The chief executive was planning to visit the new site in China on the Thursday after the project
had finished to evaluate the change in working practices. Identify the scheduled date for her visit.
There was also some concern about the limited time allowed for Task C. How many days (if any)
could Task C be delayed without delaying the completion of the project?
Apr May Jun

S M T W T F S S M T W T F S S M T W T F S
1 2 3 1 1 2 3 4 5
4 5 6 7 8 9 10 2 3 4 5 6 7 8 6 7 8 9 10 11 12
11 12 13 14 15 16 17 9 10 11 12 13 14 15 13 14 15 16 17 18 19
18 19 20 21 22 23 24 16 17 18 19 20 21 22 20 21 22 23 24 25 26
25 26 27 28 29 30 23 24 25 26 27 28 29 27 28 29 30
30 31
Figure 12: Calendar
Finding ways to save time

There is more to being a successful project manager than producing a basic project plan and a
simple budget. Only professional project managers have the talent, experience and determination
to recognise a first draft solution for what it is and then set to work in a search for the optimal
solution for the project.
Most will cheerfully regard as inevitable the fact that the initial plan, resource schedule and
budget calculations will require fine tuning, if not major reworking, to isolate the best approach,
disregarding all credible alternatives. This implies a significant amount of hard work, focus and
application, but the demonstrable improvements, benefits and confidence that result are invariably
worth the effort.
© ABE 43
The inevitable balance of the Iron Triangle returns to dominate this thinking; for example, it may
be feasible to reduce the project timescale to some extent by throwing plenty of extra resources
at it, or perhaps save a certain amount of money by relaxing all the initial and demanding time
constraints. Similarly, changes to project quality levels and/or the scope of work will also impact
time and cost calculations.
The key challenge is of course to analyse and engineer measurable improvements without incurring
any significant negative impacts on the balancing Iron Triangle parameters. Holding two of the three
parameters constant but improving the third is often a very demanding project management challenge.
Optimising the schedule

Is the overall duration of the project plan unnecessarily long? Reducing the overall duration may
already be a requirement if the current version of the plan does not meet the project deadline
acceptable to the end user clients.
Even if the current version of the plan appears reasonable, and all the key milestones, especially
completion, fall within designated target dates, a thorough review is rarely a waste of management
or professional time. It is almost always possible to find improvements if you look for them with a
professional attitude.
Involving colleagues at all levels, inside and outside the project team, is generally a smart move at this
point. Colleagues will come up with suggestions that you will miss (and vice versa). As a general rule,
any suggestion is to be welcomed – it can always be disregarded politely if it is not worth pursuing.
A checklist of possible options to consider in this respect follows.
Target the critical path

The critical path determines the overall duration of the project, so if a project manager needs to
reduce the overall duration, time savings must be found on the critical path tasks.
Or put the other way around, there is little or no benefit in finding savings on non-critical tasks
because if that is all you have, the critical path will remain exactly the same, and the overall duration
of the project will be unchanged.
As outlined previously, a clear network diagram is important because if the durations of the tasks
start changing, it is possible that the critical path will change. Consider the example in Figure 13.
Task 4
Build roof
18 days
Task 8
Fit carpets
5 days
Task 7
Painting
14 days
Task 6
Plumbing
12 days
Figure 13: Critical path REVISION

on the go
44 © ABE
The critical path runs through 1-2-3-5-7-8 and the total duration of the tasks on this path is 86 days,
which is the planned duration of the project.
Now consider the possibility that the project manager has found a way to save 10 days on Task 5
and a way to save another 5 days on Task 7. A total of 15 days.
Now the network diagram has changed and the critical path runs through 1-2-3-4-8 and gives a
planned project duration of 75 days (Figure 14). This is a significant saving on the original plan
(86 − 75 = 11 days saved) but not as much as the 15 days saved on Tasks 5 and 7.
Task 4
Build roof
18 days
Task 8
Fit carpets
5 days
Task 7
Painting
9 days
Task 6
Plumbing
12 days
Figure 14: New critical path REVISION

on the go
When options are found to reduce the durations of critical tasks, you need to double check
that the critical path has not changed.
Review individual task durations

So, it is generally good practice to revisit and challenge the basis of all the existing estimates for
task durations, especially those on the critical path (i.e. directly affecting the overall duration and
key dates on the project). The primary objective is to double check and confirm each individual
duration estimate to eliminate any unnecessary delays. A review of this nature may provoke lively
arguments if it is not conducted in a consultative style and if the project staff concerned interpret
the review of their estimated durations of tasks as a challenge to their professionalism.
Experienced managers should be aware of any sensitive issues, but the core objectives of the project
should override any other priorities, and the project manager is entitled to require subordinate staff to
defend any and all estimates.
The ‘critical chain’ approach to project management identifies the tendency for most people to add
an extra ‘buffer’ when estimating the duration of their own tasks, and this has negative implications
for the duration of the project.
Analyse the network logic

A careful examination of the existing network logic (predecessors) should be undertaken to
seek and explore potential improvements – often linked to simplifying the logic as it stands, and
promoting task concurrency and flexibility. Planners should consider adjusting task relationships
to allow more tasks to run concurrently (at the same time) where feasible rather than in a strict
© ABE 45
sequential order. Frequently, planners opt for a ‘safety first’ approach and build in too many finish-
to-start relationships between tasks that may, to some extent, overlap in the course of the project.
In any event, high performing project staff applying professional common sense may in fact defy
restrictive finish-to-start network logic and execute – or perhaps commence – tasks well ahead of
schedule. A good example in construction environments is of diligent site foremen, having hit a
snag on current tasks, assigning tradesmen and labourers to commence useful preparatory work on
future tasks rather than have them standing idle until the snag is resolved.
Rationalise the number of tasks

It may be that a set of related tasks has been defined at a lower level of detail than is strictly
necessary and that that approach has resulted in a longer (aggregated) duration. In such cases it
may be feasible to combine the tasks concerned, with the key objective being to agree a reduction
in the overall duration without any significant downside. Consultation with the project staff affected
is essential.
Set longer working hours

It is possible to define a standard working day longer than the eight-hour day / five-day week norm.
This adjustment should in theory reduce the duration of all the project tasks in the plan thus pulling
forward the project completion date.
In the real world, however, such a simplistic option may have serious and undesirable implications.
Firstly, it is hardly likely to be popular among the staff affected (except perhaps those engaged on
hourly rates and/or overtime) and there may be awkward contractual issues to resolve. Secondly,
the simplistic, linear productivity gains may not happen. For example, would a tired engineer
working later every day deliver more than the same person on a comfortable eight-hour day?
This decline in productivity over time is often evidenced with IT and software professionals;
once mental fatigue sets in after several hours of focused concentration, an exponential decline
in performance may often result. Occasional 12-hour days and worked weekends may well be
necessary, even expected, on a busy project but a series of very long working days is unlikely to
deliver a commensurate increase in brain performance. After several hours, little of further value
may be achieved that day and the staff concerned may have spent their time more usefully at home
resting in anticipation of the following day’s work.
Increase task resources to reduce durations

For tasks with a quantity of resources assigned (typically people), it is certainly possible to add
extra resources in order to bring about a commensurate change in duration. Three options may
be considered:
• increase the quantity of resource units allocated to the task (on the basis that more resources
should lead to a decrease in duration);
• increase the general availability of the resource/s (seek additional resources – typically people or
equipment – where the quantity is currently capped);
• assign overtime work hours to the resource (which may not be as simple as it sounds).
Unless the nature of the task means that its duration is not directly related to the amount of
resource applied, this is reasonable to consider if on balance the costs of the additional resources
are worth the benefits of a shortened duration.
46 © ABE
But the nature of many tasks, from various industries, dictates the effect of diminishing benefits as
more and more resources are applied. The overhead of the extra supervisory work may become
impracticable and/or physical constraints on the number of resources that can be accommodated
at the project site may become an issue. In construction environments, adequate health and safety
precautions may also curtail resource quantities.
Consider subcontractors
Another option that is often deployed by experienced project managers is to outsource some of
the work to reputable subcontractors rather than trying to do everything in-house. Bringing in
outside expertise and experience is a common tactic normally well worth considering even though
it might require some extra money. Expert subcontractors may achieve improvements in not just
time, but cost and quality too.
Worked example
A project has been planned using the network diagram in Figure 15 with the critical path shown in
red (A-C-G-L-N). The planned duration is 36 weeks.
Task F Task J Task K

8w 4w 4w
Task A Task C Task G

4w 6w 12w
Task L Task N
6w 8w
Task B Task D Task H
2w 2w 2w
Task E Task I Task M

4w 6w 6w
Figure 15: Example – network diagram with critical path REVISION

on the go
Savings in time are possible as shown by these four identified options:

• Task K Up to two weeks
• Task L Up to four weeks
• Task M Up to three weeks
• Task N Up to three weeks
The options relating to Tasks L and N are of interest first because they are on the critical path. The
final Task N is particularly useful because it is on every possible path through the project network.
By reducing N by three weeks (from eight to five) the critical path would not change but would be
reduced to 33 weeks (Figure 16).
© ABE 47

8w 4w 4w

4w 6w 12w
Task L Task N
6w 8w
2w 2w 2w

4w 6w 6w
Figure 16: Example – critical path (reduced) REVISION

on the go
If we also reduce critical Task L by the maximum four weeks (down from six to two weeks),
the critical path changes (Figure 17).

8w 4w 2w

4w 6w 12w
Task L Task N
2w 5w
2w 2w 2w

4w 6w 6w
Figure 17: Example – critical path (further reduced) REVISION

on the go
The new critical path is through Tasks A-C-F-J-K-N (31 weeks), while the previous path through
A-C-G-L-N is 29 weeks.
Saving another two weeks from Task K is also a good idea. This means that there are now two
critical paths through the network, each of 29 weeks (Figure 18). The project manager has been
able to save seven weeks in total.
48 © ABE

8w 4w 2w

4w 6w 12w
Task L Task N
2w 5w
2w 2w 2w

4w 6w 6w
Figure 18: Example – two critical paths REVISION

on the go
Task M does not appear on any critical path so it may be pointless and a waste of money
to adopt that time-saving option.
OVER TO YOU
Activity 8: Moshono School time-saving options
In response to concerns about the Moshono School project taking longer than three
months and not being finished before the start of the school term in September, the
trustees asked everyone concerned to revisit the project plans and determine whether
there were any options for saving time, money or preferably both. This exercise was
duly completed and the options set out in this table were submitted to the trustees
shortly before the end of May.
Option Detail
The project could use a simpler fence design using barbed wire instead of wood.
A
There would be no cost saving but Task 10 could be done in half the time.
Extra labourers could be hired to help with the relatively simple task (Classrooms).
B This would cost the project an extra fixed sum of $5,500 but result in a saving of
3 weeks on Task 3.
C The school could be constructed without the benefit of an electricity supply.
Most of the work associated withTask 8 (Electrical Services) could be subcontracted.
D
This would cost an extra fixed sum of $2,500 but save one week on Task 8.
Poor quality construction materials could be sourced from alternative suppliers
E
saving $5,000.
With reference to the original network diagram created for this project, analyse which
of the five options should be accepted and which should be rejected. Remember you
can select as many or as few as you wish.
© ABE 49
Chapter 3
Resource-based
Project Budgets
Introduction
This chapter builds on a basic planning concept – the creation of a planning network comprised
of individual tasks and logical constraints. The basic principle is that once a project plan has been
created (i.e. the logical sequence of tasks), the thoughts of a competent project manager should
focus very swiftly on the resources required to execute the project.
In other words, a coherent set of jobs (tasks) has been specified in a logical sequence but the next
step is to determine whether or not we might have a problem finding all the things we need to do
the work planned. And even if we can find everything we need – at the right time – do we have a
sufficient budget?
Firstly, we have to define all the resources required, which is simply a list of everything we need.
When this is done properly on a task-by-task basis, we can examine the list and be in a good
position to identify any areas of difficulty. Such difficulties may include, for example, not having
enough resources available at a certain point, or people being required in two places at the same
time, or specialist resources being very hard to find.
Learning outcome
3 Calculate a resource-based budget for a project based on a set of inputs
Assessment criteria
3 Calculate a resource-based budget for a project based on a set of inputs
3.1 Explain the variety of resources needed by a project
3.2 Explain what is meant by top-down and bottom-up project budgets
3.3 Calculate the cost of time-related and fixed-price resources
3.4 Calculate all resource costs to arrive at a bottom-up project budget
© ABE
Level 4
Project Management
3.1 Project resources

Fundamentals
The word ‘resource’ means different things to different people in different contexts. A formal
dictionary definition of a resource might be something like: a means to achieve a specific end; an
available supply of something; or perhaps an attribute that can be of some use. In the context of
project management, a resource is simply something required for the execution of a set task.
Let us consider two examples:
1 A sales presentation task generally requires the following resources:
• room
• presenter
Without these two basic resources, the presentation cannot be carried out, unless the presentation
is taking place in the open air or using some form of virtual presenter. Additional resources
might well include a power supply, whiteboard, handouts, projector, set of PowerPoint slides,
etc. Note that the audience does not count as a resource in this context – they are not essential
for the presentation task to proceed and are much more like the client or end user of the sales
presentation task.
Now consider a set of resources defined at the project level:

2 A railway construction project may need the following resources (to be assigned to one or
more tasks):
• engineers, surveyors, technicians, labourers
• specialist rolling stock, trucks, cranes
• steel rails, gravel, sleepers, cement
• fixed amounts of cash funds to pay specialist subcontractors
Tasks usually require more than just one resource type.
Resource categories
The railway project example leads to a useful observation that resources can be segregated
logically into four distinct categories:
• human resources (people)
• materials
© ABE 51
Chapter 3 Resource-based Project Budgets
• equipment and premises/facilities

• finance for subcontracts
This constitutes the first resource checklist for the project manager – have we assessed accurately
all the resource requirements in each and every category? Have we forgotten anything?
Human resources
Successful project managers know that the quality of their project team is paramount: securing the
services of motivated, competent and reliable professionals will have an extremely positive influence
on the outcome (and vice versa). This knowledge should translate into a sharp focus on all the critical
human resources required for the project and making sure that the right staff can be found.
Project staff are drawn from sources internal or external to the organisation, each with various
pros and cons. Internal sources generally involve the secondment of employees at various levels
from their regular posts or departments to the project for a fixed duration. Where salaried staff
are seconded to a project team, according to prevailing policies on transfer pricing, the host
department are often reimbursed for the services of those staff, typically on a monthly cost basis.
External professionals are often resourced through employment agencies specialising in the supply
of temporary contract staff for a fixed term period (which is often very helpful for a project). The term
‘secondment’ may be used in this context as well, but the agency is typically acting only as a convenient
employment business that takes the person onto their books only for the duration of the project. They
pay the person according to an agreed time-related schedule of rates (e.g. $100/day) and invoice the
project on a similar basis (e.g. $130/day). Naturally the rate charged by the agency to the project is
higher than that paid to the person, with the difference representing the agency’s profit margin on the
deal.
Materials
For the majority of IT and general business projects, material (consumable) resources often
represent a minor category of resource requirements. However, this is clearly not the case on
major construction projects, where material resources (e.g. steel) may well represent a significant
proportion of the entire project budget. On such projects the material resource requirements
need very careful estimation and management; frequently specialist professionals such as quantity
surveyors will be engaged for this purpose alone.
Quantities, costs, quality and delivery arrangements are four of the key parameters to assess, and
these are often complex and outside the range of the planning engineer. In such circumstances
the planning function is usually limited to information gathering and quantity/cost-related input to
a project management system. Most material resources are usually specified and purchased on a
fixed-price basis (rather than related to task or project duration).
Equipment and premises/facilities

With certain similarities to materials, basic equipment resources are not normally a critical aspect for
a business project apart from major construction projects. Equipment can be hired and paid for on a
time-related basis (e.g. a mobile crane hired for 21 days at $350/day), a lump sum basis (e.g. a two-year
project requiring 24 office computers at a one-off cost of $500 each), or occasionally a combination of
these elements (e.g. leased office accommodation requiring the project to pay a lump sum up front for
refurbishment prior to occupation paid on a time-related basis).
In the former case, attention must be taken to differentiate between time and work, and plans
made accordingly. A mobile crane will still cost the project $350/day whether or not it is idle or
active on the site. Such a situation may be exacerbated by a strict contract hire period, i.e. the
52 © ABE
Resource-based Project Budgets Chapter 3
crane must be returned at the end of the 21-day hire period so a failure to achieve all the tasks
requiring the crane during this period may be problematic, and/or very expensive.
In the second case, where equipment is to be resourced on a straightforward lump sum fixed-cost basis,
some care must be taken to ensure that all costs have been assessed properly. For example, significant
maintenance costs and insurances associated with technical equipment are often overlooked.
Financial resources for subcontracts

Any significant project will involve subcontracted elements to some degree, i.e. external parties
contracted to undertake specific work packages which it is clearly not in the interests of the project
to carry out in-house. Examples might include printing, landscaping, security, legal services,
catering, non-destructive testing, etc. Either the project does not have the specialist skills available
or experienced subcontractors have developed their professional services to a level of efficiency
which the project could not match.
Training task example

Let us imagine you are working on a major systems project which is going to finish with some
training for the clients. The training is of a specialist nature and cannot be carried out by any
member of the project team. You are asked to take personal responsibility for this task even though
you are not very experienced.
Firstly, you talk to the senior developer, who tells you that a good company to carry out the training
is IQT Consulting.
You contact them and they are delighted to help. They advise you that the training schedule should
take 10 days (two working weeks) and that two of their experienced training consultants should be
assigned to the task.
They also tell you that you will be responsible for arranging a suitable training room with a good
laptop computer for every delegate, reliable Wi-Fi access in the room and a set of hard copy
training manuals for each delegate. They email you with PDF versions of the set of training manuals.
Secondly, you talk to the project client who tells you that a maximum of 16 delegates will be
required to attend the training course. This is good to know, but you do not have a room at the
project offices big enough to accommodate all these people.
The senior developer does not see this as a problem. ‘Just book a suitable room at the Hilton,’ she
suggests, referring to the hotel nearest to the project office.
After confirming there are no other resources required, you create a diagram for the task. The
senior developer advises that you need to add the quantities of each resource, which you then add
in (Figure 1).
Training room
16 Training in hotel
manuals (big enough for 16)
System Training 10 days
2 Training IT services
consultants (16 laptops)
Figure 1: Training diagram REVISION

on the go
© ABE 53
The senior developer sees that you know exactly what you need and tells you to show it to the
project manager.
The project manager looks at the information you have researched and says ‘OK, but how much will
all this cost?’
3.2 Top-down and bottom-up project budgets

Once all of the requisite resources are identified and quantified for a specific task, it is reasonably
straightforward to find the prices for everything you need and develop a total budget cost for the task.
If you have a ‘shopping list’ with every item properly specified and the quantity of every item
required is clear, it should not be too difficult to find out the different prices for all the items and
‘price up’ your shopping list.
The project management term for this is ‘resource-based budgeting’ or ‘bottom-up budgeting’
because you are starting from the bottom and working upwards to calculate a budget for each task.
You will eventually create a budget for the entire project.
Once you have done all this, if the resources and costs are subsequently challenged in search of
savings, all the information you need (the details) will be available.
Bottom-up cost estimating

The resource-based approach to costing is essentially a ‘bottom-up’ method, where resource detail is
added to the lowest project elements (usually individual tasks) and then priced up item by item to create
an overall budget for the project. This aids effective tracking and control as the project is executed.
The professional challenge of mastering resource-based costing on projects is far easier if you
have followed the structured step-by-step project management approach. In other words, if
you have developed a credible plan and considered carefully all the resource requirements
separately and ahead of all the associated cost implications, you are in a strong position.
Proceeding to calculate all the project resource costs (and an overall budget total for the
project) is often quite straightforward.
Alternative costing approaches: ‘top-down’

The bottom-up method is not the only approach. In certain business environments, a top-down
approach to budgets may be imposed, often by prevailing market conditions. The hard reality of
the marketplace imposes cost restrictions on a potential project. A senior manager may comment,
for example, that ‘If this project can’t be achieved for $3.5 million, it is simply not worth doing.’
One would imagine that a comment of that nature (and the $3.5m in particular) was made on the
back of careful business analysis and market research, i.e. that the products of the project must be
delivered for less than a certain amount or the overall value of the consequent business benefits will
not exceed the costs.
In such circumstances, it would be tempting for a project manager to abandon any disciplined
approach to resourcing and costing, lose sight of all the important detail and proceed on the basis
that everything will be fine as long as we stay within a total project cost of $3.5m. This is true, but
project managers still need to work through the details.
All the bottom-up resource-based details, managed correctly, will tell the project manager whether
or not staying within the confines of a stipulated budgetary figure (such as $3.5m) is feasible and a
realistic proposition.
They also provide a sound basis for a vigorous planned versus actual cost monitoring and control
regime, as covered in Chapter 4.
54 © ABE
The training task

Let us revisit the systems training task. The project manager is demanding to know how much it
will cost so you contact IQT Consulting who inform you that their professional fees for the training
consultants are $1200 per consultant per day.
Your next call is to the Hilton Hotel, who are delighted to hear from you and advise that they have
the perfect training room available, which can accommodate up to 20 delegates at a discount
rate of just $450 per day, which includes morning coffee, a buffet lunch and afternoon teas for the
delegates and trainers. High quality Wi-Fi is guaranteed.
Your third call is to a local printer who advises that they can produce 16 sets of all the operating
manuals for a total fixed cost of $3500.
Your final call is to a local IT Services company who will rent out 16 high specification laptops for
$225 per laptop per month (minimum rental period: one month).
Training room in hotel

16 Training manuals (big enough for 16)
($3500 in total) ($450 per day)
System training 10 days
($1200 per day ($225 per laptop)
per consultant)
Figure 2: Training diagram with costs

REVISION
on the go
Finding this information was much easier than you expected and you add it into the training
diagram (Figure 2). But the senior developer was not surprised. ‘You are a potential customer,’
she says, ‘of course they are going to help you out with cost estimates. They want your business.
Now, how much will it all cost?’
OVER TO YOU
Activity 1: Total budget cost calculation
Based on the information in Figure 2, calculate a total budget cost for this task.
You can check your answer against the guidance provided at the end of the study guide.
© ABE 55
3.3 Time-based and fixed-price resources

You should have noticed from the training example that resources need to be considered as either
time-based or fixed cost.
Time-based in this context implies that the resource cost is directly proportional to the time period
the resource is assigned to the project – often via a fixed hourly or daily rate. People are very
often a critical time-based resource on projects. Other time-based resources such as project office
accommodation are often quantified on a monthly or quarterly basis.
Fixed cost means that the resource quantity and therefore the cost is fixed at the outset of the
project. Examples of fixed-cost resources might include construction materials, items of capital
equipment, and lump sum subcontract work; any resource item for which the quantity is not related
directly to the duration of the related task or project.
OVER TO YOU
Activity 2: Time-based or fixed-cost resources?
Consider the following resources required for a large-scale supply chain management
(SCM) system project, and decide whether they should be treated as time-based or
fixed cost. The project is being managed in-house.
The services of a specialist SCM consultant

The acquisition of computer hardware
Telephony services for the project team
Off-site office accommodation for the team
Software licences for the SCM system
CASE STUDY
E-commerce project
The plan for Phase A of a project for the development

of a sophisticated e-commerce application calls for
the mobilisation of a team leader (staff) and 6 analyst
programmers (contract).
The phase has been estimated to require 20 weeks

in total, and the cost of the human resources has
been estimated as follows:
Team leader: (no charge to the project)
Senior analyst/programmer (×2): $50/hour
Junior analyst/programmer (×4): $40/hour
56 © ABE
Standard 40-hour weeks are expected to be worked by all the Phase A team.
Sariah has been selected in the role of Phase A team leader, and is immediately challenging
the proposed team composition. As an alternative to the six team members she proposes the
following team resourced through different employment agencies:
Rose at $70/hour
Tamwa at $450/day
Charlie at $480/day
These are all experienced (and expensive) e-commerce developers who have worked
successfully with Sariah on similar projects in the past. She also wants to hire Ken in an
administrative capacity at a cost of $750/week.
OVER TO YOU
Activity 3: E-commerce scenario
Analyse the specific financial implications of Sariah’s proposals – will they be cheaper
or more expensive than the original plan?
Consider the non-financial benefits, risks and issues if Sariah’s proposal is approved.
3.4 Estimating the costs for a project

You might think that if you have estimated all the costs of every task on a project, you can add them
all together to create a total budget for the entire project. Unfortunately, it is not quite as simple as
that, because some costs may not be related directly to individual tasks but to the entire project.
To account for these costs, all the same principles still apply: identify the individual resources
required for the project, quantify them, price them and calculate the overall cost.
CASE STUDY
Customer relationship management system upgrade
A company has decided to upgrade its customer relationship management (CRM) system and will
need to employ a number of consultants on short-term contracts. The consultants will only charge
fees for the time they are engaged on tasks. The project is planned as follows (see Table 1):
© ABE 57
Duration Predecessor Human Resources

Task Description
(days) tasks (C = consultants required)
1 Requirements analysis 10 – 2C
2 Evaluation of packages 20 1 2C
3 Package selection 5 2 2C
4 Software procurement 10 3 1C
5 Hardware installation 5 3 1C
6 Package customisation 25 4,5 2C
7 Reports programming 10 6 2C
8 Documentation 5 6 1C
9 System testing 10 7,8 2C
10 System handover 5 9 2C
Table 1: Project tasks and plan
In addition to the consultants, a project manager will be employed for the entire duration of the
project. Each consultant will cost $400 per day worked, and the project manager will cost $500
per day worked.
OVER TO YOU
Activity 4: CRM upgrade
Calculate the total cost of the consultants and the project manager.
CASE STUDY
E-tendering website
A project manager working for a university is

responsible for the construction of a $1m building
complex on campus.
The strategy calls for the award of a single construction

management contract via a formal bidding process. To
reduce the amount of paper generated and distributed,
the project manager proposes the development of
a secure website to facilitate the electronic transfer
of project information, particularly with regard to the
contracting process.
58 © ABE
Potential contractors would access the site and be able to download the appropriate set of
documents specific to their interest and role. Printing costs would be borne by each company
rather than the project.
Three months before communications open with all potential contractors and professional firms
seeking to work on the project, the project manager presents the website proposal to the project
board. Attracted by the bold e-business vision and potential cost savings, the board ask how
much the website would cost.
‘No more than about $5000’ came the confident reply. ‘In any event, much less than the savings
we will make by not printing and distributing the various documents.’ Based on this advice the
website initiative was approved by the board.
OVER TO YOU
Activity 5: E-tendering website
Criticise this top-down approach to budgeting. What are the risks?
Finding ways to save money

It should be clear that the Iron Triangle factors are interrelated and interdependent; for example,
if the project duration can be shortened, there may be an immediate cost benefit as expensive
human resources are required for a shorter amount of time. In an alternative scenario, if a decrease
in the duration of the project can only be achieved at a high cost (e.g. the assignment of extra,
expensive short-term resources), this expense must be measured against the anticipated benefits.
It may also be rational to use a combination of tactics to reduce overall project costs. For
example, to stay within a designated budget the project manager may decide to reduce the
number of resources assigned to a task, cut the amount of work on another task, and combine
other tasks into a single task. If the cost of the project is deemed more important than other
competing objectives, it may be necessary to reduce the scope of the project by deleting tasks or
reducing the scope of work.
Careful consideration will often identify many possible ways to save costs. A checklist relating to
potential cost savings follows.
Challenge the initial resource estimates

For some tasks, it may be possible to revisit the basis of the original resource estimates and
challenge the original quantities and qualities assigned. The project manager is entitled to review
and challenge every task-based resource estimate to satisfy themselves that the proposed plan
and schedule of resource requirements is as ‘tight’ and as realistic as possible, with the absolute
minimum of superfluous (and costly) resources. Individual specialist or management personnel
can often cost a project in excess of $100,000 p.a. when the full package of costs is calculated, so
agreeing a manpower reduction of just one person is a significant saving.
© ABE 59
Negotiate market manpower rates for contractors

Cost rates for freelance contract professionals (i.e. their price) may fluctuate rather more than some
project managers realise. It is important that clients understand the mechanisms of the market and
do not underestimate the extent of their purchasing power.
The market for supplying professional human resources on a contract basis is simple and efficient.
There are three parties involved – client (project), contractor (person) and agency – and if the needs
and priorities of each can be satisfied, a deal can be struck. Essentially the contractor works for, but
is not employed by, the client. Instead the client pays the agency an agreed hourly or daily fee for
the services of the contractor, and the agency pays the contractor fees on a similar basis. Naturally
there is a difference – occasionally a big difference – between the two fees, this representing the
gross profit margin for the agency.
The challenge is for the contractor to maximise their pay rate, the agency to maximise their profit
margin, and the client to minimise their financial exposure without compromising on the quality of
the person required. All these aspects are flexible to a degree, and the client should be prepared
to flex their financial powers in the process whenever appropriate. This normally applies when the
personal quality and professional experience of the contractor in question is not paramount; in
such circumstances searching for other candidates via other agencies is usually a good tactic. Not
only will new, credible options develop but the high ‘non-negotiable’ rates quoted for the original
resource may suddenly become much more flexible.
Plan resources over longer periods

This is a very important tactic for most projects to consider. The longer the commitment the project
can make to the mobilisation of a person, the lower the rate it can expect. The principle is based on
common sense but it is intriguing how many projects fail to fully exploit the savings potential.
For example, if you hire a car for a week it may cost X. Hire the same car for a month and it will cost
much less than 4 × X. Firstly, the car hire company is saving significant transaction and overhead
costs, and secondly, they are usually content to accept a lower weekly profit margin partially
because they do not have the risk of their car lying idle during that period.
Similar principles apply to hiring human resources. Invite a freelance project professional to relocate
to a far-away location for just a month and a natural reluctance to accept this for just a month’s
fees (followed by the demands of a new job search) will translate reasonably into a quote for much
higher fees. Invite that same person for a six-month assignment and the scenario becomes much
more attractive to them. Not only is the longer assignment deemed worthwhile in a subjective
sense, but real practical issues such as the cost of accommodation can be tackled more assertively,
all leading to the acceptance of lower, more reasonable fees.
So clearly, projects should avoid the mobilisation of resources on a short-term basis unless
absolutely essential and in accordance with the project plan. However, time-based resources
should also not be engaged for any longer than is necessary. The worst-case scenario, often
involving consultants, is the short-term engagement of staff on very high day rates whose project
assignments are then continually extended.
Ensure a competitive bidding environment for subcontracts

For any project operating in a competitive commercial environment (as opposed to a remote
location) the team should take full advantage of the cost savings that may be available through
professional procurement practices and competitive bidding. Again, the power of the project as the
client entity should not be underestimated: highly specialised services aside, suppliers always need
clients more than clients need suppliers.
60 © ABE
This implies that with some diligent research, careful paperwork and a modest amount of legal
expertise, projects can engage with all manner of local contractors in a search for the best
combination of low cost and high quality. The aggregated savings in particular can be significant,
but inevitably such savings are not achieved without time and effort on behalf of the project.
Challenge all project overheads

In the same way that overheads can stifle and often kill new start-up businesses, the level of
overheads incurred by a project team can often have a disproportionate effect on the overall costs
incurred by the project. These are defined as costs which do not have a direct bearing on the
tasks comprising the work scope of the project, but are to a practical extent, unavoidable. Such
overheads might include accommodation charges (plus energy, rates, security, cleaning services,
etc.), office equipment (furniture, telephony, photocopiers, computers, etc.), transport and a host of
continuous costs such as telephone bills, maintenance and travel expenses.
While in most cases unavoidable, this does not imply that these costs should not be challenged
and minimised by the project or the sponsors. For example, a prestigious standard of office
accommodation for the project team, over and above the norm for the industry, is normally cause
for legitimate criticism by the project sponsors unless mitigating circumstances are present such as
favourable rates agreed on a short-term lease. Other policies such as the provision of company cars
and overnight expenses need to be settled and harmonised with prevailing norms and regulations,
and a balance found between extravagance and unnecessary cost slashing.
OVER TO YOU
Activity 6: System training task
Training room in hotel
16 Training manuals (big enough for 16)
($3500 in total) ($450 per day)
System training 10 days
($1200 per day ($225 per laptop)
per consultant)
Even though the figures are accurate, the project manager is not happy with the
proposed budget of $35,600.
The project manager demands that the costs be revised to no more than $20,000.
Consider just how you might achieve this considerable cost saving.
© ABE 61
Chapter 4
Tracking and Controlling
Live Projects
Introduction
Competent project planning and budgeting are without doubt valuable skills, but proficiency
in project management involves more than being able to plan effectively and come up with a
realistic budget.
Experienced project managers know that they need to deliver the outcomes of the project in
accordance with the key parameters set out in the initiation stage: cost, delivery dates and the
overall quality of the deliverables. Project managers are measured not on how well they can plan,
but how well they can execute and deliver. Professional competence in the stages preceding this
chapter only counts towards making a successful execution much more likely.
Learning outcome
4 Discuss how a project could be monitored and controlled during the execution phase
Assessment criteria
4 Discuss how a project could be monitored and controlled during the execution phase
4.1 Explain the concept of a baseline plan and an approved budget
4.2 Calculate the difference between planned and actual progress
4.3 Explain a range of tactics that could be used to recover lost time
4.4 Discuss how project management software can be used to plan and monitor a project
© ABE
Level 4
Project Management
4.1 Progress tracking – baseline plan and

approved budget
The basic tracking process
Talent and competence in the project execution stage implies the ability to track how well the
project is progressing combined with the ability and inclination to take decisive action and
make timely interventions as required. Equally important is knowing when to step back and give
competent subordinates the opportunity, authority and resources to do their job effectively, rather
than micro-managing them. That implies that the project manager has an effective information
system (not necessarily computer-based) that can supply answers to the following type of questions:
What progress should we have achieved by now?

What progress have we actually achieved?
These questions are generally followed in quick succession by two others:
How much should we have spent by now?

How much money have we actually spent?
We also look at a possible fifth question: Are we sure that all the work being carried out is to the
right level of quality?
With respect to the first four questions, you should bear in mind that you may well be called upon
to answer them on a regular basis – even every week. If you try to accomplish this informally just
before a project progress meeting by talking to a few colleagues or sending a few emails, it is
very unlikely to work. A much better approach is to design and implement a reliable system that
provides the answers.
Such a system requires as a minimum two key pieces of information – a baseline plan and a
baseline budget. The word ‘baseline’ implies a final version of the plan or budget that has been
officially approved and frozen – no further changes will be permitted unless there are exceptional
circumstances. Progress and spending can then be compared with the plan and budget to answer
the key questions outlined.
The key to understanding all this potential complexity is simplicity. Project managers need to define
simple tracking systems that provide information that is easy to understand and then use it to measure
© ABE 63
Chapter 4 Tracking and Controlling Live Projects
planned versus actual figures, celebrate success and deal assertively with problems at the earliest
opportunity. In terms of process/theory, tracking a project is a straightforward five-step process:
1 Create a baseline plan (generally in the form of a Gantt chart and budget).
2 Periodically update the plan with task-based progress and record all the costs incurred
(e.g. weekly).
3 Instigate a programme of formal quality reviews to assure the quality of project deliverables.
4 Compare the baseline with the updated plan to determine how closely current progress and
costs match the original plan – to act as a trigger for Step 5.
5 Implement appropriate strategies and tactics to address real and projected variances outside
designated tolerances.
This approach is related closely to the principle of project management by exception: an effective
project manager only needs to address problematic situations. Conversely when all is definitely
going well the project manager can relax and congratulate all the subordinates responsible.
If an early warning system is not implemented – and variances between planned and actual
performance are suppressed (inadvertently or deliberately) – the probability of project failure in some,
if not multiple, respects increases significantly. The key is to know whether things are going well or
not. And the first step is answering the first question outlined in the introduction to this chapter:
What progress should we have achieved by now?
If you have created a Gantt chart for the project, the answer is right there in front of your eyes.
Tracking progress with a Gantt chart

By using a Gantt chart – an intuitive format for project planning and tracking – even quite complex
projects can be represented and understood with a minimum of effort.
For the sake of simplicity, consider a six-week IT project consisting of just four concurrent tasks
(Figure 1):
Task Task Name Duration 1 2 3 4 5 6

1 Analysis and design 5 weeks
2 Database configuration 3 weeks
3 Interface development 4 weeks
4 Management reporting 3 weeks
Figure 1: Gantt chart with TimeNow line REVISION

on the go
If the current date at which progress is being assessed (‘TimeNow’) is at the end of week 3 (as
shown by the vertical line in Figure 1), we should be able to deduce the planned progress for each
task at this point:
Task 1 – 60%
You should be able to see that three weeks of work should have been completed out of a five-week
schedule. (3/5) × 100 = 60
64 © ABE
Tracking and Controlling Live Projects Chapter 4
Task 2 – approx. 67%

Two weeks of work should have been completed out of a three-week task. (2/3) × 100 = approx. 67
Task 3 – 25%
One week of work should have been completed out of a four-week task. (1/4) × 100 = 25
Task 4 – 0%
No work was planned to have started on Task 4 by this time.
This does not tell us what the actual progress is for each task, but it does tell us what the planned
progress should be at any point.
Another point to note is that this approach assumes that progress is achieved in a simple linear fashion.
For example, if Task 3 is planned to take four weeks, we are assuming that 25% of progress will be
achieved each week. This may not always be the case, but it is reasonable for the purposes of
most comparisons.
OVER TO YOU
Activity 1: Gantt chart review
An offshore oil platform development project has been planned with the following
Gantt chart.
Task Module Jan Feb Mar Apr May Jun Jul Aug
A Structure
B Cellar deck
C Accommodation
D Process module
E Drilling module
F Helideck
G Flare boom
A review meeting is being held on 1 April and you have been asked to determine the
planned progress for each task at this point. As a hint, draw a red vertical line at the
point of the review – at the end of March / beginning of April.
Analyse the chart and advise the project team as to the planned % progress for each
task at this point in time.
Guidance is provided in the next section.
Summary
Knowing what the percentage progress on each task should have been at any point during the project
is just the start. But it is important because it is the first step towards being able to assess whether
real progress is as it should be – or whether any interventions and remedial actions are required.
© ABE 65
4.2 Comparing planned progress with actual

progress
The previous section and activity should have given you the insight needed to determine the
planned progress for any project task based on the interpretation of a simple Gantt chart (Figure 2).
It is often a good idea to annotate the Gantt chart with a vertical line as shown below:
Task Module Jan Feb Mar Apr May Jun Jul Aug
A Structure
B Cellar deck
C Accommodation
D Process module
E Drilling module
F Helideck
G Flare boom
Figure 2: Offshore project – planned progress REVISION

on the go
• Task A should be finished (100%)

• Task B should be halfway through – two months out of four – 50%
• Task C should be 20% (one month out of five)
• Tasks D, E, F, G – 0% (they were not planned to have started by this time)
So, having determined the planned progress for each task now we need to consider the next question:
What progress have we actually achieved?
Tracking task progress

Finding out actual progress rarely involves Gantt charts or calculations – it means going out of your
office, talking to the various colleagues responsible and finding out what is happening on each task
in progress.
The simplest approach to tracking planned versus actual progress on project tasks is simply to
monitor the actual start and finish dates of each task and compare them with the planned dates.
Advantages to this method include valuable simplicity, transparency and objectivity. With this
approach, there are three status values available for all tasks:
Not started: actual start and finish date values both vacant (0%)
In progress: actual start date completed but the actual finish date vacant
Complete: actual start and finish date values completed (100%)
The result should be that there is no scope for subjective assessments about task progress, the
likelihood of misunderstandings is small, and the effort/cost of collecting the necessary status
information for each task is low. However, the drawbacks are significant, and often compelling.
Constrained by this modest set of progress data, incisive progress analysis on the part of project
managers is limited to a set of simple questions such as:
66 © ABE
Which tasks should have started by now but have not?

How many tasks are currently in progress?
Which tasks should have finished by now but have not?
How many incomplete tasks are left to finish the project?
This is useful information but is not sufficient, especially if there are substantial tasks in progress and
the project manager needs to know more detail than just ‘this task is currently in progress’.
Progress tracking using per cent (%) complete values

Isolating a per cent complete value for each task has the huge advantage of simplicity and
facilitates widespread understanding among the project team and any other interested parties.
For example, if an engineer responsible for a particular task advises that the task is 50% complete,
it should be clear to all including the project manager that the task is halfway through.
So recording actual per cent complete values is the preferred approach to the assessment of task
progress. The timely collation of this information will also lead to the calculation of an overall
percentage complete value for the entire project: a figure normally of extreme interest to the
project manager, board and clients. Failure to determine a credible value for this measure is not
generally an option because without this information these questions cannot be answered:
Which live tasks are currently running behind schedule?

Which critical tasks are not expected to complete on schedule?
Which critical tasks are falling behind schedule and could cause a major delay?
Which tasks are currently ahead of schedule (yielding the possibility of transferring resources to
problematic areas)?
Without the information to provide answers to such useful questions, the manager of any significant
project is in a precarious position and probably has only themselves to blame for not anticipating these
information needs and failing to put in place the necessary procedures and systems to support them.
Let us go back to the offshore project for an example. The engineers responsible for the various
tasks report the following actual progress up to the end of March:
• The Structure (A) was completed on time.
• The Cellar deck (B) work has gone well. Now 60% complete.
• Accommodation (C) is estimated as 15% complete.
• The Process module (D) is 10% complete.
• No other progress has been achieved.
Now we can perform some very useful comparisons (Table 1).
Task Module Planned % Actual % Variance (Actual–Planned %)
A Structure 100 100 0
B Cellar deck 50 60 10
C Accommodation 20 15 −5
D Process module 0 10 10
© ABE 67
Task Module Planned % Actual % Variance (Actual–Planned %)
E Drilling module 0 0 –
F Helideck 0 0 –
G Flare boom 0 0 –
Table 1: Planned and actual progress – offshore project REVISION

on the go
Task A is finished (as it should be), Task B is 10% ahead of schedule, Task C is 5% behind
schedule and Task D is 10% ahead (it started early). No progress was reported on the other tasks,
which is not at all surprising as none of them were expected to start by this time (31 March).
Armed with this information, you should be able to see how useful this is. Task A is history. Tasks B
and D seem to be in good shape, but there is some cause for concern on Task C.
There is no need to get too worried because the work for Task C is planned over five months
(March to July inclusive) so there is – in theory – plenty of time left to recover the lost progress.
But it is important to be aware of the situation early so that if remedial actions are necessary such
as switching resources to Task C from Task B or perhaps from Task D, this action can be taken at an
early stage.
Finding actual progress for each task

How do we calculate the actual progress values?
Generally, you don’t. You have to go and find these out, which on occasion can be much easier
said than done. Assuming this information can be found, it is easy to represent in a simple table as
shown in Table 1.
Alternatively, some project managers will prefer to annotate their Gantt charts. In the IT project
example, the progress values are shown to the right of each task and a dark ribbon has been
inserted in the middle of each task bar to indicate actual progress (Figure 3):
Task Task Name Duration 1 2 3 4 5 6 7

1 Analysis and design 5 weeks 50%
2 Database configuration 3 weeks 70%
3 Interface development 4 weeks 15%
4 Management reporting 3 weeks 10%
Figure 3: Gantt chart with TimeNow line and actual progress REVISION
on the go
Those tasks with the dark progress ribbon behind (to the left of) the TimeNow line
(i.e. Tasks 1 and 3) are not good news. This is in contrast to Tasks 2 and 4, which are registering
slightly better progress than was planned at this stage.
68 © ABE
At this point, the project manager should be focused on Tasks 1 and 3 because they are behind
schedule. In contrast, the teams working on Tasks 2 and 4 are both slightly ahead of schedule.
OVER TO YOU
Activity 2: Office building project
A large office building is under construction in New York. The project has been
planned as 11 high level tasks as follows:
Task Budget ($m) Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec
Foundations 2.2
Steel erection 9.4
Concrete works 7.8
Carpentry work 2.5
Masonry work 6.0
Roofing 4.0
Building finishes 5.8
Elevators 1.3
Plumbing 1.8
Electrical 2.4
HVAC 1.8
On 1 July, a senior management team arrived to review progress, and the following
actual progress information was compiled:
• Foundations and Steel erection were completed on time (100%).
• The Concrete works have gone well and now stand at 70% complete.
• Carpentry work and Masonry work are both 40% complete.
• Roofing was delayed due to problems with the crane, and progress stands at 60%.
• Building finishes is now 33% complete and the Elevators work is 25% complete.
• No other tasks have started.
• (HVAC stands for heating, ventilation and air conditioning.)
• Assuming the current date is 1 July, compare planned and actual progress for each
task on the project.
Guidance is provided in the next section.
© ABE 69
Comparing planned spending with actual spending

If you have been entrusted with a significant business project to manage and deliver, you will
probably have been provided with the budget and the necessary financial resources for which you
will be accountable.
How much should we have spent by now?
How much money have we actually spent?
Once you have found out the answers to both questions it is straightforward to analyse the
situation, identify areas of concern and, if necessary, take appropriate (cost-saving) actions.
The second question is easier, providing you have a simple system that measures all spending at the
task level rather than the project level.
The first part can be slightly more difficult because there are two choices in terms of analysis:
What you should have spent at this moment according to the time elapsed, or
What you should have spent according to the amount of progress achieved.
The New York office building

In Activity 2, you should have first annotated the Gantt chart as follows (the review date was 1 July)
(Figure 4).
Task Budget ($m) Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec
Foundations 2.2
Steel erection 9.4
Concrete works 7.8
Carpentry work 2.5
Masonry work 6.0
Roofing 4.0
Building finishes 5.8
Elevators 1.3
Plumbing 1.8
Electrical 2.4
HVAC 1.8
Figure 4: Activity 2 Gantt chart REVISION

on the go
Working down through each task on the chart we should be able to determine the
planned % values for each task bearing in mind the review point (the red line).
70 © ABE
Task Planned % Actual % Variance
Foundations 100 100 0
Steel erection 100 100 0
Concrete works 60 70 10
Carpentry work 29 40 11
Masonry work 67 40 −27
Roofing 80 60 −20
Building finishes 25 33 8
Elevators 0 25 25
Plumbing 0 0 0
Electrical 14 0 −14
HVAC 0 0 0
Table 2: Planned and actual progress – office building REVISION

on the go
The Actual % values shown in Table 2 are copied from the information given in Activity 2
(the bullet points) and the variance is simply Actual % minus Planned %.
Now let us turn to the sensitive issue of cost (spending).
Firstly, you need to know what should have been spent. You need to multiply the budget value for
each task by the Actual % value for each task (Table 3).
Task Budget ($m) Actual % Expected spend ($m)
Foundations 2.2 100 2.2
Steel erection 9.4 100 9.4
Concrete works 7.8 70 5.5
Carpentry work 2.5 40 1.0
Masonry work 6.0 40 2.4
Roofing 4.0 60 2.4
Building finishes 5.8 33 1.9
Elevators 1.3 25 0.3
© ABE 71
Task Budget ($m) Actual % Expected spend ($m)
Plumbing 1.8 0 0.0
Electrical 2.4 0 0.0
HVAC 1.8 0 0.0
TOTAL 45.0 25.1
Table 3: Expected spend – office building REVISION

on the go
Then you are advised that actual spending to date has been incurred on the following tasks
and you enter these values into Table 4:
Foundations ($2.7m), Steel erection ($8.7m), Concrete works ($12.7m), Carpentry work ($1.4m),
Masonry work ($4.7m), Roofing ($3.9m), Building finishes ($6.7m) , Elevators ($1.7m) and Electrical
($0.2). No other expenditure has taken place on Plumbing or HVAC.
Expected spend Actual spend Variance

Task
($m) ($m) ($m)
Foundations 2.2 2.7 −0.5
Steel erection 9.4 8.7 0.7
Concrete works 5.5 12.7 −7.2
Carpentry work 1.0 1.4 −0.4
Masonry work 2.4 4.7 −2.3
Roofing 2.4 3.9 −1.5
Building finishes 1.9 6.7 −4.8
Elevators 0.3 1.7 −1.4
Plumbing 0.0 0 0.0
Electrical 0.0 0.2 −0.2
HVAC 0.0 0 0.0
TOTAL 25.1 42.7 −17.6
Table 4: Expected spending, actual spending and the difference (variance). REVISION
on the go
72 © ABE
This analysis gives serious cause for concern. A glance at the bottom line shows that at this point,
we were expecting $25.1m to have been spent (bearing in mind the progress achieved) but the
project has in fact spent a staggering $42.7m, considerably more ($17.6m) than was expected.
The main problems (the largest differences/variances between expected and actual spend) lie with
Concrete works and Building finishes.
This approach assumes that the pattern of spending is on a consistent linear basis over the course
of a task, and the reality is that certain tasks may spend more towards the beginning of the task
than at the end. The purchase of construction materials would be a good example.
But the key point running through this entire unit remains. A project manager needs simple,
accurate information that they can use to determine the general health of their project and where
necessary identify problem tasks at an early stage. If problems emerge, early interventions can be
made. Without the comparative information available to review, this basic strategy is not possible.
4.3 Finding ways to recover lost progress

Over-optimistic project managers may be inclined to neglect this subject on the grounds of being
unnecessarily pessimistic; why waste valuable management time considering tactics for corrective
action if such uncomfortable options can best be avoided in the first place?
The real world is rarely straightforward and any number of factors, internal and external, expected
and random, can jolt the performance of a project to a point at which progress falls behind
schedule and a decisive intervention of some description is necessary.
The first step towards dealing with this situation is to know about it. In other words, having the
information necessary to know that the project is behind schedule, or possibly spending too much.
These issues have been covered in the preceding sections.
Therefore, if one or more tasks are falling behind schedule and it is clear that there is no chance
of recovering the time lost, the thoughts of a project manager must focus on actions to deal with
this situation.
Deploy extra resources

In some project cultures this is termed ‘crashing a task’, i.e. throwing additional resources (usually
people) at a poorly performing task with the objective of at least stabilising the position if not
recovering the progress lost. Quite often these extra resources can be brought in on a short-term
contract basis so they are deployed on a ‘quick in/quick out’ basis but it is also possible that they
could be transferred from other projects or tasks which may be ahead of schedule. This is a common
and well-proven tactic but it may incur at least two negative effects.
Firstly, the project takes an immediate financial hit especially if the additional resources are not
already mobilised on the project. Secondly, there is no guarantee that the assignment of extra
resources will have a direct linear impact on productivity; this is highly dependent on the nature
of the project tasks and the resources. For example, if a project to design and develop a highly
sophisticated software system experiences problems on certain modules, simply hiring extra
programmers is unlikely to yield any immediate benefits until they have had sufficient time to
familiarise themselves intimately with the work scope. In contrast, a residential building project
falling behind schedule for lack of carpentry skills is more likely to experience a rapid positive effect
if additional, experienced carpenters are hired under the guidance of a good foreman.
© ABE 73
Redeploy talented resources

A common alternative or complement to the previous tactic is to redeploy existing resources
(typically people) with the objective of assigning the most talented individuals to the most difficult
and demanding tasks. If this is feasible, it avoids the twin pitfalls of having to induct new project
staff too rapidly and, where necessary, finding large amounts of extra money at short notice. It may
also be possible to negotiate longer working hours for the more talented staff, probably with the
need for some form of overtime attached.
The only potential downside of the redeployment tactic, which must be managed carefully by the
project manager, is the implication for motivation and performance. In some business cultures the
accolade ‘troubleshooter’ or ‘safe pair of hands’ is to be sought after (preferably with rewards to
follow); in other cultures, staff may resent and actively resist any reassignment to problematic and/
or frustrating tasks because they perceive no personal benefits at all.
Identify and exploit successful tasks

Naturally the focus of corrective action falls upon tasks that are performing poorly and threatening
the outcome of the entire project. In contrast, the project manager should also make time to assess
the performance of the tasks that are going well. This recommendation contradicts, to some extent,
a prior suggestion that project managers should establish an excellent information system and
only intervene where variances indicate problems. However, in the unusual circumstances of tasks
recording actual progress way ahead of schedule, a skilled project manager may want to explore
the situation in more depth.
Three explanations exist in this situation. Firstly, the task may have been significantly over-resourced
in the first place. Secondly, the complexity and/or scale of the scope of work of the task may have
been over-estimated. Finally, the team assigned to the task may have worked far more effectively
and productively than first projected, and deserve credit accordingly.
In all but the last case, the project manager is entitled to ask searching questions about the
accuracy of the planned estimates for the task, but rather than seek out targets for criticism, a more
positive tactic could be considered – the careful reassignment of individual resources from ‘easy’
tasks into problem areas.
Reduce or change the project work scope

It may be possible to renegotiate the complexity or scope of the project deliverables while still
being acceptable to the client, sponsor and other key stakeholders. However, this may only
be feasible if the initial objectives of the project were seen as slightly over-ambitious from the
outset. In such a scenario, reducing the scope to a logical ‘fall-back’ position may be realistic and
acceptable, depending on how much time and money has been used to date.
A change in scope may also lead to a change in the delivery schedule, which might be advantageous
to a project experiencing difficulties with the current expectations.
Outsourcing work packages

Some project managers attempt to do too much work in-house (by the project team) when the
superior solution may be to engage competent and experienced subcontractors. Pursuing this
policy may result in substantial transaction costs (e.g. the paperwork required to engage with a
subcontractor and monitoring thereafter) but the benefits in terms of time saved might be well
worth it. Providing the price is right, experts in their field can often get things done much quicker
than regular members of a project team.
74 © ABE
OVER TO YOU
Activity 3: Recovering lost progress
If applicable, think of a project that you’ve managed where you needed to find a way
to recover lost progress. What did you do? Why did you choose that tactic? How
successful were you?
If you haven’t found yourself in this situation before, spend time making some revision
notes on the common tactics that you have read about here and where they work best.
4.4 Project management software systems

This section covers the types of software applications designed specifically to support project
management processes.
Prior to 1990, the market for project management software was targeted by numerous software
vendors offering a bewildering variety of products to suit all budgets, operating systems,
integration options and personal preferences. Then in April 1990, Microsoft launched version 1 of a
rudimentary Windows-based application program imaginatively called ‘Project’. It was first available
on huge 5.25” floppy disks and required one megabyte of memory.
Microsoft’s initial marketing strategy for Microsoft Project was a combination of cost leadership
allied with user friendliness, based on a standardised Windows interface. Unlike competing
products in the early 1990s, little technical/programming knowledge was required to drive the
menu-driven application, which at the time was regarded by some project planners as a limitation.
Any widespread reluctance to adopt Project did not last long once Microsoft added power and
flexibility without compromising the established virtues of price and user friendliness. And when
the Visual Basic tools and database integration options were added to the Microsoft Project 98
release in 1997, adopting the package became a compelling choice for the vast majority of project
management practitioners. There are many other packages that perform similar functions, but
Microsoft Project still dominates this market today.
The core functions of the software support multiple activities over the project life cycle:
© ABE 75
Planning
Project management software can help in the production of detailed project planning
documentation, to update project plans and to produce reports. A user-friendly interface makes
it easy for anyone with some basic planning knowledge to create and subsequently amend and
improve a project plan based on a Gantt chart format (default) or a network diagram.
The software will not perform the planning function but it does make it very easy to create a
plan based on some preparatory work. Once the plan is created a range of project management
information, such as planned duration, start and finish dates, float, etc. is calculated automatically.
Resources and costs

The software facilitates resource planning, which should enable the most effective use of the
various resources, ensuring the project has the correct staff levels, equipment and material at the
right time. Once a basic plan has been created, resource requirements can be added at the task
level (fixed or time related). Once resource costs are also defined, the software will calculate a
range of budget costs for the project. The graphics report options will provide visual displays of the
usage and availability of resources.
Optimising
The software can also offer contingency planning and ‘what if’ analyses, allowing the review and
communication of different scenarios. The familiar Windows environment makes it easy for any user
to take a copy of the current project plan and test out alternative solutions in the search for time
or cost optimisation. Any changes decided upon will automatically create new schedules for the
project which can be communicated quickly to participants and stakeholders.
Tracking and control

Once a final version of the project plan is defined, this may be baselined to serve as the formal
plan against which actual progress and cost expenditure may be monitored. A range of charts
and graphs (Gantt charts, etc.) are available to show planned progress against actual progress.
Numerous tabular reports can also be generated, such as tasks that are behind schedule, tasks in
progress, etc. The financial/budget and control features of project software will assist at the various
stages of the project life cycle, so that actual costs can be compared with budget costs, at both the
level of individual tasks and for the project as a whole. The software can reschedule and re-baseline
project plans if progress falls too far behind.
Reporting
The production of high quality graphical reports such as Gantt charts has become an expected
output from packages such as Microsoft Project. In addition, a wide range of text-based tabular
reports is available, which can be selected and customised to the needs of the recipient group.
The quality of the documentation is high, and reports can be extracted and shared with the project
team and other interested stakeholders such as the project sponsor. This will be of considerable
help in reporting on progress to the different project stakeholders in a professional manner and will
encourage and facilitate constant progress checking.
76 © ABE
Summary
It is perfectly possible to manage projects effectively without the use of project management
software systems, providing the project manager is competent with all the core tools and
techniques. In fact on major projects, the only major applications used by managers may be email
and Skype, as specialists will be responsible for the day-to-day operation of project management
and financial systems. However, the advantages of all the features outlined in this text, not least in
terms of productivity, make it more and more likely that contemporary project managers will not
only choose to adopt project management systems but also take a hands-on role in their operation.
What is crucial to remember is that software systems, no matter how powerful and user-friendly, will
not manage a project. All they can do is support a competent manager.
© ABE 77
Guidance
Guidance
Guidance for Chapter 1, Activity 8: Moshono School budget

There are three inputs to the preliminary budget calculation:
• $1500 for man-hour fees (work package 1.0)
Unit Man-hours
• $20,000 for materials (across all work packages)
2 500
• Man-hour fees (work packages 2.0 to 6.0)
The latter are calculated as follows based on the man-hours 3 900
estimated by the architect:
4 1000
Cost per man-hour (estimated by the architect) = $8.00
5 350
Total estimated cost for man-hours = Total man-hours × cost
per man-hour = 3100 x $8.00 = $24,800 6 350
The total expected costs for the project are the fixed costs plus Total 3100
the man-hour costs:
$1500 + $20,000 + $24,800 = $46,300
This is within the $50,000 grant that is available.
However, remember that the three inputs into the budget are only estimates and the actual costs
may vary from these values.
Guidance for Chapter 1, Activity 10:

Risk rating for hospital IT project
5 R4 R5
The risks can be mapped into a 5 × 5 matrix according
to the impact and likelihood (probability) combinations: 4
risk occurring
Likelihood of
It can be seen that Risk 1, Risk 4 and Risk 5 are red 3 R3 R1

and thus of greatest concern and require immediate
attention, while Risk 2 is of low concern and may not 2
require action, and Risk 3 is of medium concern.
1 R2
1 2 3 4 5
Impact if risk does occur
Guidance for Chapter 3, Activity 1:

Total budget cost calculation
Cost per Subtotal

Resource Quantity
unit ($) (Quantity × Cost per unit) ($)
Training consultant 2 consultants × 10 days 1200 24000
Room hire in hotel 10 days 450 4500
1 (fixed fee for all 16
Training manuals manuals) 3500 3500
Hire of laptops 16 laptops 225 3600
TOTAL BUDGET
35600
COST ($)
78 © ABE
Guidance
Guidance for Chapter 3, Activity 2: Time-based or fixed-cost

resources
Consultants (and other contract staff) are usually engaged on a time-related basis, i.e. so much per
hour or per day.
Hardware acquisition should not be affected by time. It should have been properly analysed,
researched and a fixed-cost provision determined.
Telephone charges are often very difficult to estimate accurately but are almost certainly related to
time and the size of the project team.
Temporary office accommodation is usually arranged as a time-based resource – an amount per

month for example. Occasionally a lump sum provision will be negotiated for a specific time period.
Although the basis of software licences can vary between vendors, the nature of the cost is usually
related to the number of licences required (fixed) rather than any time-based formula. Projects
should carefully research the number required and determine a fixed-cost provision.
Guidance for Chapter 3, Activity 3: E-commerce scenario

Budget costs for the team, based on original plan:
Rate p/h Hours Subtotal ($)

Role (A) Number (B) Weeks (E)
($) (C) p/w (D) (B × C × D × E)
Team leader (no charge) 1 n/a
Senior analyst/
2 50.00 40 20 80000
programmer
Junior analyst/
4 40.00 40 20 128000
programmer
TOTAL 208000
Alternative budget costs based on Sariah’s alternative team structure:
Number Rate p/h Rate p/d Rate p/w Weeks Subtotal

Role (A)
(B) ($) (C) ($) (D) ($) (E) (F) ($) (E × F)
Team leader 1 n/a
Rose 1 70.00 560 2800 20 56000
Tamwa 1 450 2250 20 45000
Charlie 1 480 2400 20 48000
Ken 1 750 20 15000
TOTAL 164000
Note: eight hours per day; five days per week; 40 hours per week.
© ABE 79
Guidance
So, on the strength of the financial analysis alone, Sariah’s proposal seems to represent the
potential for a saving of $44,000 ($208,000−$164,000).
The team apparently work well together and have a track record of completing successful projects
in the past. Reassembling a successful project team seems to be a perfectly sound approach (rather
than recruiting a brand-new group). In addition, Sariah does not appear to have challenged the
proposed duration of 20 weeks so this appears to be feasible with her proposed smaller team.
However, it appears that as Ken is in a non-technical capacity, the number of technical specialists
working on the team has been reduced from six to three – with Rose in a lead or senior role. Apart
from the initial observation – can a smaller team deliver the required project deliverables to the
required quality within the stipulated time frame – a secondary issue must be the risk concerned
with the availability of the personnel. What would happen if one or more of the designated
personnel left the project suddenly?
Guidance for Chapter 3, Activity 4: CRM upgrade

Firstly, calculate the total consultant days in a new column in the table.
Human resources
Duration Total consultant
Task Description (C = consultants
(days) days per task
required)
1 Requirements analysis 10 2C 20
2 Evaluation of packages 20 2C 40
3 Package selection 5 2C 10
4 Software procurement 10 1C 10
5 Hardware installation 5 1C 5
6 Package customisation 25 2C 50
7 Reports programming 10 2C 20
8 Documentation 5 1C 5
9 System testing 10 2C 20
10 System handover 5 2C 10
TOTAL 190
The total consultant days required for the project is 190. So, if the consultants are chargeable
to the project at an inclusive rate of $400/day, the total cost of the consultants’ charges will be
190 × $400 = $76,000
To understand the cost of the project manager we need to know the planned duration of the
project. This requires the application of CPA as covered in Section 2.2.
The critical path of the project is 1-2-3-4-6-7-9-10, with task durations of 10-20-5-10-25-10-10-
5 days = 95 working days (19 weeks), which is the planned duration of the project. The project
manager will therefore cost 95 × $500 = $47,500.
The total cost of the consultants and project manager will therefore be $76,000 + $47,500 =
$123,500.
80 © ABE
Guidance
Guidance for Chapter 3, Activity 5: E-tendering website

The information provided suggests that the project manager has come up with the figure of $5000
rapidly with no bottom-up cost analysis and research. This figure may turn out to be woefully
inadequate, costing much more than first anticipated, taking longer and delivering less in benefits
than hoped for.
Faced with such a situation, the board would be wise to demand some justification for the
figure of $5000. A detailed cost–benefit analysis would be appropriate for this potentially complex
web project.
© ABE 81
Glossary
Glossary
Baseline A baseline is a plan (schedule), Network diagram A diagram showing the
budget or specification that has been officially logical sequence of tasks in a project, flowing
approved and ‘frozen’ by senior management from left to right. Each task is represented by a
and clients. Progress and spending can be box, and arrows are used to denote the logical
compared against it as the project develops. sequence of tasks. It can be used to identify
the milestones and critical path of a project and
Budget The precise amount of money set to schedule, organise and monitor tasks. Also
aside to fund a project. Generally calculated in known as a precedence diagram, a network
advance, and approved in a formal process by chart and logic diagram.
senior management and project stakeholders.
Net present value (NPV) An estimate
Business case A formal document recording that helps business organisations determine
the business justification for undertaking a the financial benefits of long-term projects.
project. It explains how the benefits (in financial It compares the value of all future cash flows
terms) are projected to exceed the costs over a in today’s money to assess the benefits and
specified time period. enable comparisons with projects having
different cash flow patterns.
Constraints Various factors and limits that
will need to be considered during the planning Payback Used within business case
phase, for example resources, deadlines and calculations, payback represents the amount
dependencies. of time required before the returns from an
investment (the project) repay the original
Critical path The critical path is the sequence capital outlay. The shorter it is, the better.
of tasks through a project network with the
longest duration path. The critical tasks on this Plan This has different meanings depending
path must be completed on time for the entire on the business context. In this unit, plan
project to be completed on schedule. means a time-based schedule of tasks that
show the planned delivery of the project,
Deliverable A tangible or intangible object including key dates.
to be produced by the project and handed over
to the client or operations team. Predecessor A preceding task within a
project network. Tasks may have more than one
Discount rate The interest rate a company predecessor.
expects to earn on its investments in a year.
PRINCE2 An approach to project management
Float The time a particular task can be released in 1996 as a generic project
delayed without delaying the entire project. management methodology. It provides a well-
Tasks on the critical path have no float. defined set of carefully documented methods,
based on processes and sub-processes, for
Gantt chart A tool that presents and tracks managing projects within a variety of business
tasks over time. It takes the form of a horizontal
sectors. The extreme depth of detail and direction
bar chart (one bar per task) with the timescale
is seen by many as a key advantage but by others
at the top of the chart. In some formats, task
as a limitation.
progress is indicated by a ribbon inside each bar.
Project management software A computer
IPECC model A well-known project life- software package, usually installed on a laptop
cycle model consisting of five stages: initiation,
or accessed online, to support all the activities
planning, execution, control and completion.
undertaken by the project manager over the
course of the project life cycle. Microsoft Project
Milestone A key event during the life
is perhaps the most notable, although many
of a project, usually completing a project
competing products are available.
deliverable or other noteworthy achievement.
Often regarded as a zero duration task (as it is
technically an event not a package of work).
82 © ABE
Glossary
Project manager The person who has Scope creep The uncontrolled growth of the
overall responsibility for the successful planning, project scope resulting from constant changes
execution, tracking and closure of a project. to the specification or requirements without
consideration of the impact on resources or
Resources Anything needed to complete timescale.
the project, often categorised into people
(manpower), equipment, materials and funds. Specification A technical and comprehensive
written definition of the project deliverable/s.
Return on capital A simple metric often used Developed in advance and then approved by
during business case calculations. The projected senior management and stakeholders, it informs
returns of a project are totalled and divided by all concerned precisely what the project is
the sum of the outgoings required – and often setting out to deliver.
expressed as a percentage. It takes no account
of the time periods involved. It should not be Sponsor The person who has financial
confused with the traditional accounting metric authority over the project, provides funding,
return on capital employed. approves scope changes, and provides high
level direction.
Risks External events outside the direct
control of the project that may well have a Stakeholder Any party (person or business
negative impact if they occur. The significance organisation), internal or external to an
of a risk refers to the combined likelihood that organisation, that has an interest in a project or
the event will occur and the impact if the event will be affected by its deliverables. Their relative
does occur. power and interest is often compared to that of
other stakeholders.
Risk management A formal and professional
approach to managing project risks that Work breakdown structure (WBS) A
includes risk identification, risk quantification, hierarchical (pyramid) structure of all the
response development and controls. deliverables (work packages) that need to
be performed to complete a project. It is a
Scope The overall definition of what the common project management tool and the
project should achieve and a specific description preliminary basis for project planning.
of what the outcome should be.
© ABE 83

4UPM Study Guide

Uploaded by

Copyright:

Available Formats

4UPM Study Guide

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

4UPM Study Guide

Uploaded by

Copyright:

Available Formats

Yo u r road to success

Your road to success

All rights reserved. No part of this publication may be reproduced or

Copyright © ABE 2017

All facts are correct at time of publication.

Author: William Wright BCom MSc MBA

Editorial and project management by Haremi Ltd.

The publishers gratefully acknowledge permission to reproduce the following

1.1 The project life-cycle model3

Chapter 2 Creating an Effective Project Plan 28

2.1 Project planning with network diagrams29

Chapter 3 Resource-based Project Budgets 50

3.1 Project resources51

Chapter 4 Tracking and Controlling Live Projects 62

4.1 Progress tracking – baseline plan and approved budget 63

Element of learning Key capabilities developed

Element 2: Project planning Development of practical planning skills for a project

Element 3: Project budgets Development of practical budgeting skills for a project

Some people take a pragmatic view that it is unreasonable to

A further challenge faced by project managers is that they are

1.1 The project life-cycle model

PMI have elaborated their definition as follows:

Temporary means that every project has a definite beginning

The Iron Triangle

Figure 1: The Iron Triangle REVISION

The installation and commissioning of new radiotherapy equipment in a specialist cancer

And then things may get worse!

The project life-cycle concept

Alternative project life-cycle models

Meredith and Mantel – three-stage model

Maylor – four-stage model

Frigenti and Cominos – five-stage model

IPECC stands for…

1.2 The project business case

What needs to be researched?

Estimating high level costs

Quantifying high level benefits

Setting out the year-by-year table

Year 0 Year 1 Year 2 Year 3 Year 4 Year 5 Year 6

Table 1: Year-by-year table template for six years REVISION

Costs Year 0 Year 1 Year 2 Year 3 Year 4 Year 5 Year 6

Operations 1.0 1.0 1.0 1.0 1.0

Table 2: Year-by-year table template – costs REVISION

Benefits Year 0 Year 1 Year 2 Year 3 Year 4 Year 5 Year 6

Table 3: Year-by-year table template – benefits REVISION

Costs Year 0 Year 1 Year 2 Year 3 Year 4 Year 5 Year 6

Loan 12.0 12.0 12.0

Operations 1.0 1.0 1.0 1.0 1.0

Electricity 10.0 10.5 11.0 11.6 12.2

Water 4.0 4.2 4.4 4.6 4.8

Net cash flow

Table 4: Project cash flows REVISION

Appraisal techniques: a practical summary

Year 0 Year 1 Year 2 Year 3 Year 4 Year 5 Year 6

Cumulative –6.0 –18.0 –17.0 –15.3 –0.9 14.3 30.3

Table 5: Payback period REVISION

C = the total cash flow during the period after A = 15.2

Payback period = A + (B/C) = 4 + (0.9/15.2) = 4.06 years (two decimal places)

Net present value

Year 0 Year 1 Year 2 Year 3 Year 4 Year 5 Year 6

1.1 The project life-cycle model3

Chapter 2 Creating an Effective Project Plan 28

2.1 Project planning with network diagrams29

Chapter 3 Resource-based Project Budgets 50

3.1 Project resources51

Chapter 4 Tracking and Controlling Live Projects 62

4.1 Progress tracking – baseline plan and approved budget 63