Upload
bima-hermastho
View
75
Download
13
Embed Size (px)
Citation preview
MODUL KORPS PROJECT MANAGEMENT
KORPSMENWAINDONESIA
WidyaCastrenaDharmaSidha
HUMANCAPITALDIVISION
2016
Contents
ii
CONTENTS
Chapter 1: Project Management Introduction ............................................................................. 4
1 What is a project?........................................................................................................................................................................... 5
2 The project manager ..................................................................................................................................................................... 8
3 The project team ......................................................................................................................................................................... 12
4 Project stakeholders ................................................................................................................................................................... 19
5 Organisational context for projects ..................................................................................................................................... 21
6 Why is project management important? .......................................................................................................................... 23
7 Project success factors .............................................................................................................................................................. 24
8 A project-oriented organisation (‘POO’) ........................................................................................................................... 26
9 Projects and strategy ................................................................................................................................................................. 27
10 Structure ....................................................................................................................................................................................... 31
11 Types of projects ....................................................................................................................................................................... 33
Chapter 2: Project Feasibility Studies .......................................................................................... 39
1 Investment in project ................................................................................................................................................................. 40
2 Steps in project appraisal......................................................................................................................................................... 41
3 Methods of project appraisal ................................................................................................................................................. 51
4 Non-financial factors in a capital investment decision ............................................................................................... 52
5 The accounting rate of return (ARR) method .................................................................................................................. 53
6 The payback method ................................................................................................................................................................. 57
7 The payback and ARR methods in practice ..................................................................................................................... 60
8 Investment appraisal and cash flows .................................................................................................................................. 61
9 The time value of money ......................................................................................................................................................... 67
10 Discounted cash flow .............................................................................................................................................................. 69
11 The net present value method of project appraisal ................................................................................................... 71
12 Discounted payback ................................................................................................................................................................ 76
13 The internal rate of return method of project appraisal .......................................................................................... 79
14 NPV and IRR compared ......................................................................................................................................................... 83
15 The feasibility study report ................................................................................................................................................... 85
Chapter 3: The Project Life Cycle ................................................................................................. 87
1 The project life cycle .................................................................................................................................................................. 88
2 Management tools and techniques..................................................................................................................................... 97
3 Project management software............................................................................................................................................. 104
4 Documentation and reports ................................................................................................................................................. 106
5 Risk management...................................................................................................................................................................... 112
6 Managing stakeholders .......................................................................................................................................................... 119
7 Project resources – skills and people ................................................................................................................................ 122
Contents
iii
Chapter 4: Methods of Project Management........................................................................... 127
1 Project management approaches ...................................................................................................................................... 128
2 Core project management methodologies .................................................................................................................... 129
3 Choosing a methodology ...................................................................................................................................................... 131
4 Project management plan ..................................................................................................................................................... 132
Chapter 5: Project Management Tools and Techniques ......................................................... 142
1 Management tools and techniques................................................................................................................................... 143
2 Determining the work breakdown structure ................................................................................................................. 144
3 Sequencing work ....................................................................................................................................................................... 150
Chapter 6: Project Control and Evaluation ............................................................................... 165
1 Project monitoring .................................................................................................................................................................... 166
2 Reporting progress ................................................................................................................................................................... 167
3 The project termination decision ........................................................................................................................................ 171
4 The project report ..................................................................................................................................................................... 173
5 The outcome matrix ................................................................................................................................................................. 174
6 The post-completion audit ................................................................................................................................................... 175
7 Benefits realisation.................................................................................................................................................................... 176
8 The project scorecard .............................................................................................................................................................. 178
Chapter 1: Project Management Introduction
Page | 4
Chapter 1: Project Management Introduction
Topics covered in the chapter:
Definition of project, project management
Responsibilities of a project manager
Management of the project team
Organisational context for projects
Projects management challenges
Project success factors
Project managing strategy
Strategic project management
The project-structured organisation
Project management vs. Operations management
Managing conflict in project
Project stakeholders
Types of projects
Chapter 1: Project Management Introduction
Page | 5
1 What is a project?
To understand project management it is necessary to first define what a project is.
A Project is 'an undertaking that has a beginning and an end and is carried out to meet
established goals within cost, schedule and quality objectives'. (Haynes, Project Management)
A project often has the following characteristics:
A defined beginning and end
Resources allocated specifically to them
Intended to be done only once (although similar separate projects could be undertaken)
Follow a plan towards a clear intended end-result
Often cut across organisational and functional lines.
Alternatively a project can be defined as a series of activities aimed at bringing about clearly
specified objectives within a defined time-period and with a defined budget.1
A project should also have:
Clearly identified stakeholders, including the primary target group and the final
beneficiaries;
Clearly defined coordination, management and financing arrangements;
A monitoring and evaluation system (to support performance management); and
An appropriate level of financial and economic analysis, which indicates that the project’s
benefits will exceed its costs.
Development projects are a way of clearly defining and managing investments and change
processes. A project can vary significantly in their objectives, scope and scale.
Smaller projects might involve modest financial resources and last only a few months, whereas a
large project might involve many millions of Dollars and last for many years.
In general, the work organisations undertake involves either operations or projects. Operations
and projects are planned, controlled and executed. So how are projects distinguished from
'ordinary work'?
1 European Commission, Project Cycle Management Guidelines
Chapter 1: Project Management Introduction
Page | 6
Projects Operations
Have a defined beginning and end On-going
Have resources allocated specifically to them,
although often on a shared basis
Resources used 'full-time'
Are intended to be done only once (e.g.
organising the Year 2005 London Marathon – the
2006 event is a separate project)
A mixture of many recurring tasks
Follow a plan towards a clear intended end-result Goals and deadlines are more general
Often cut across organisational and functional
lines
Usually follows the organisation or
functional structure
Common examples of projects include:
Producing a new product, service or object
Changing the structure of an organisation
Developing or modifying a new information system
Implementing a new information system
Project management is the combination of systems, techniques, and people used to control
and monitor activities undertaken within the project. A project will be deemed successful if it
is completed at the specified level of quality, on time and within budget.
1.1 What is project management?
Project management involves co-ordinating the resources necessary to complete the project
successfully (ie on time, within budget and to specification).
Today’s highly competitive business environment forces organisations to make high-quality
products at a lower cost and in a shorter duration. Organisations therefore are increasingly using
project management because it allows you to plan and organise resources to achieve a specified
outcome within a given timeframe. The techniques of project management also help you manage
and anticipate risks in a structured manner. Surveys of organisations using project management
have shown that project management allows for better utilisation of resources, shorter
Chapter 1: Project Management Introduction
Page | 7
development times, reduced costs, interdepartmental cooperation that builds synergies across
the organisation, and a better focus on results and quality.
The objective of project management is a successful project. A project will be deemed successful
if it is completed at the specified level of quality, on time and within budget.
Objective Comment
Quality The end result should conform to the project specification. In other
words, the result should achieve what the project was supposed to do.
Budget The project should be completed without exceeding authorised
expenditure.
Timescale The progress of the project must follow the planned process, so that
the 'result' is ready for use at the agreed date. As time is money, proper
time management can help contain costs.
Whatever its size, a project’s success is based on three main criteria as shown by the following
triangle:
Your project will therefore be deemed successful if it:
Delivers the outcome with an agreed upon quality.
Does not overrun its end date.
Remains within budget (cost of resources).
Note however, that outcome, time and budget are interrelated, and during a project you may
need to do trade-offs between them. For example, if you want to get something done more
quickly, you may have to pump in more money into your project for additional resources.
1.2 The challenges of project management
Managing a project presents a variety of challenges. Some common challenges are outlined in
the following table.
Chapter 1: Project Management Introduction
Page | 8
Challenge Comment
Teambuilding The work is carried out by a team of people often from varied work and
social backgrounds. The team must 'gel' quickly and be able to
communicate effectively with each other.
Planning Many possible problems may be avoided by careful design and planning
prior to commencement of work.
Problem solving
mechanisms
There should be mechanisms within the project to enable unforeseen
problems to be resolved quickly and efficiently.
Delayed benefit There is normally no benefit from a project until the work is finished.
This means that significant expenditure is being incurred for no
immediate benefit – this can be a source of pressure.
Dealing with
specialists
Project managers often have to deal competently and realistically with
specialists at differing stages of the project.
Potential for
conflict
Projects often involve several parties with different interests. This may
lead to conflict.
Project management ensures responsibilities are clearly defined and that resources are focussed
on specific objectives. The project management process also provides a structure for
communicating within and across organisational boundaries.
All projects share similar features and follow a similar process. This has led to the development
of project management tools and techniques that can be applied to all projects, no matter
how diverse. For example, with some limitations similar processes and techniques can be applied
to whether building a major structure or implementing a company-wide computer network.
All projects require a person who is ultimately responsible for delivering the required outcome.
This person is the project manager.
2 The project manager
The person who takes ultimate responsibility for ensuring the desired result is achieved on time
and within budget is the project manager.
Some project managers have the job title 'Project Manager'. These people usually have one major
responsibility: the project. Most people in business will have 'normal work' responsibilities outside
their project goals – which may lead to conflicting demands on their time. Anybody responsible
for a project (large or small) is a project manager.
The person who takes ultimate responsibility for ensuring the desired result is achieved on time
and within budget is the Project Manager.
Chapter 1: Project Management Introduction
Page | 9
The way in which a project manager co-ordinates a project from initiation to completion, using
project management and general management techniques, is known as the Project
Management process.
2.1 Project management v operations management
The role a project manager performs is in many ways similar to those performed by other
managers. There are however some important differences, as shown in the following table.
Project manager Operations manager
Are often 'generalists' with wide-ranging
backgrounds and experience levels
Usually specialists in the areas managed
Oversee work in many functional areas Relate closely to technical tasks in their area
Facilitate, rather than supervise team members Have direct technical supervision
responsibilities
2.2 Duties of the project manager
Duties of the project manager include: Planning, teambuilding, communication, co-ordinating
project activities, monitoring and control, problem-resolution and quality control.
The duties of a project manager are summarised below.
Duty Comment
Outline planning Project planning (e.g. targets, sequencing)
• Developing project targets such as overall costs or timescale
needed (e.g. project should take 20 weeks).
• Dividing the project into activities and placing these activities into
the right sequence, often a complicated task if overlapping.
• Developing a framework for the procedures and structures, manage
the project (e.g. decide, in principle, to have weekly team meetings,
performance reviews etc.).
Detailed planning Work breakdown structure, resource requirements, network analysis for
scheduling.
Teambuilding Build cohesion and team spirit.
Communication The project manager must let superiors know what is going on, and
ensure that members of the project team are properly briefed.
Co-ordinating
project activities
Between the project team and users, and other external parties (e.g.
suppliers of hardware and software).
Chapter 1: Project Management Introduction
Page | 10
Monitoring and
control
The project manager should estimate the causes for each departure
from the standard, and take corrective measures.
Problem-resolution Even with the best planning, unforeseen problems may arise.
Quality control There is often a short-sighted trade-off between getting the project out
on time and the project's quality.
An effective project management process helps project managers maintain control of projects
and meet their responsibilities.
2.3 The responsibilities of a project manager
A project manager has responsibilities to both management and to the project team.
2.3.1 Responsibilities to management
Ensure resources are used efficiently – strike a balance between cost, time and results
Keep management informed with timely and accurate communications
Manage the project to the best of his or her ability
Behave ethically, and adhere to the organisation's policies
Maintain a customer orientation (whether the project is geared towards an internal or
external customer) – customer satisfaction is a key indicator of project success
2.3.2 Responsibilities to the project and the project team
Take action to keep the project on target for successful completion
Ensure the project team has the resources required to perform tasks assigned
Help new team members integrate into the team
Provide any support required when members leave the team either during the project or
on completion
2.4 The skills required of a project manager
Project managers require the following skills: Leadership and team building, organisational
ability, communication skills (written, spoken, presentations, meetings), some technical
knowledge of the project area and inter-personal skills.
To meet these responsibilities a project manager requires a wide range of skills. The skills required
are similar to those required when managing a wider range of responsibilities. The narrower focus
of project management means it is easier to make a judgement as to how well these skills have
been applied.
Chapter 1: Project Management Introduction
Page | 11
Type of skill How the project manager should display the type of skill
Leadership and
team building
Be enthusiastic about what the project will achieve.
Be positive (but realistic) about all aspects of the project.
Understand where the project fits into the 'big picture'.
Delegate tasks appropriately – and not take on too much personally.
Build team spirit through encouraging co-operation.
Do not be restrained by organisational structures – a high tolerance for
ambiguity (lack of clear-cut authority) will help the project manager.
Organisational Ensure all project documentation is clear and distributed to all who require
it.
Use project management tools to analyse and monitor project progress.
Communication Listen to project team members.
Use persuasion to coerce reluctant team members or stakeholders to
support the project.
Ensure management is kept informed and is never surprised.
Technical By providing (or at least providing access to) the technical expertise and
experience needed to manage the project.
Personal
Be flexible. Circumstances may develop that require a change in plan.
Show persistence. Even successful projects will encounter difficulties that
require repeated efforts to overcome.
Be creative. If one method of completing a task proves impractical a new
approach may be required.
Patience is required even in the face of tight deadlines. The 'quick-fix' may
eventually cost more time than a more thorough but initially more time-
consuming solution.
2.5 Leadership styles and project management
As in other forms of management, different project managers have different styles of leadership.
There is no 'best' leadership style, as individuals suit and react to different styles in different ways.
The key is adopting a style that suits both the project leader and the project team.
Chapter 1: Project Management Introduction
Page | 12
Managers will usually adopt a style from the range shown in the following diagram.
The leadership style adopted will affect the way decisions relating to the project are made.
Although an autocratic style may prove successful in some situations (e.g. 'simple' or 'repetitive'
projects), a more consultative style has the advantage of making team members feel more a part
of the project. This should result in greater commitment.
Not all decisions will be made in the same way. For example, decisions that do not have direct
consequences for other project personnel may be made with no (or limited) consultation. A
balance needs to be found between ensuring decisions can be made efficiently, and ensuring
adequate consultation.
The type of people that comprise the project team will influence the style adopted. For example,
professionals generally dislike being closely supervised and dictated to. (Many non-professionals
dislike this too!) Some people however prefer to follow clear, specific instructions and not have
to think for themselves.
Project management techniques encourage management by exception by identifying, from the
outset, those activities which might threaten successful completion of a project.
3 The project team
3.1 Building a project team
Project success depends to a large extent on the team members selected.
Chapter 1: Project Management Introduction
Page | 13
The Project Team comprises the people who report directly or indirectly to the project manager.
Project success depends to a large extent on the team members selected. The ideal project team
achieves project completion on time, within budget and to the required specifications – with the
minimum amount of direct supervision from the project manager.
3.1.1 Project team composition
The team will comprise individuals with differing skills and personalities. The project manager
should choose a balanced team that takes advantage of each team member's skills and
compensates elsewhere for their weaknesses.
The project team will normally be drawn from existing staff, but highly recommended outsiders
with special skills may be recruited. When building a team the project manager should ask the
following questions.
(a) What skills are required to complete each task of the project?
(b) Who has the talent and skills to complete the required tasks (whether inside or
outside the organisation)?
(c) Are the people identified available, affordable, and able to join the project team?
(d) What level of supervision will be required?
Although the composition of the project team is critical, project managers often find it is not
possible to assemble the ideal team, and have to do the best they can with the personnel
available. If the project manager feels the best available team does not possess the skills and
talent required, the project should be abandoned or delayed.
Once the team has been selected each member should be given a (probably verbal) project
briefing, outlining the overall aims of the project, and detailing the role they are expected to play.
(The role of documentation is discussed later).
3.1.2 Project team performance
The performance of the project team will be enhanced by the following.
Chapter 1: Project Management Introduction
Page | 14
Effective communication
All members being aware of the team's purpose and the role of each team member
Collaboration and creativity among team members
Trusting, supportive atmosphere in group
A commitment to meeting the agreed schedule
Innovative/creative behaviour
Team members highly interdependent, interface effectively
Capacity for conflict resolution
Results orientation
High energy levels and enthusiasm
An acceptance of change
Collaboration and interaction between team members will help ensure the skills of all team
members are utilised, and should result in 'synergistic' solutions. Formal (e.g. meetings) and
informal channels (e.g. email links, a bulletin board) of communication should be set up to
ensure this interaction takes place.
Team members should be responsible and accountable. The project manager should provide
regular updates on project progress and timely feedback on team and individual performance.
3.1.3 Effective team management
Most effective project managers display the ability to:
• Select the right people
• Connect them to the right cause
• Solve problems that arise
• Evaluate progress towards objectives
• Negotiate resolutions to conflicts
• Heal wounds inflicted by change
3.2 Managing conflict
Wherever there is a potential for conflict a process to resolve it should be established before
the conflict occurs.
It is inevitable when people from wide-ranging backgrounds combine to form a project team that
conflict will occasionally occur. Some conflicts may actually be positive, resulting in fresh ideas
and energy being input to the project. Other conflicts can be negative and have the potential to
bring the project to a standstill.
Chapter 1: Project Management Introduction
Page | 15
An open exchange of views between project personnel should be encouraged as this will help
ensure all possible courses of action and their consequences are considered. The project manager
should keep in touch with the relationships of team members and act as a conciliator if necessary.
Ideally, conflict should be harnessed for productive ends. Conflict can have positive effects such
as those listed below.
• Results in better, well thought-out ideas
• Forces people to search for new approaches
• Causes persistent problems to surface and be dealt with
• Forces people to clarify their views
• Causes tension which stimulates interest and creativity
3.2.1 Negotiation techniques
Most conflicts that arise during a project should be able to be resolved using negotiation and
resolution techniques.
When conflict occurs the project manager should avoid displaying bias and adopt a logical,
ordered approach towards achieving resolution. The following principles should be followed.
Focus on the problem, not the personalities
Define the problem carefully
Try to develop options that would result in mutual gain
Look for a wide variety of possible solutions
3.2.2 Resolution techniques
Ideally the conflict will be resolved by the parties involved agreeing on a course of action. In
cases where insufficient progress towards a resolution has occurred the project manager should
attempt to bring about a resolution.
The project manager should employ the following techniques in an attempt to resolve the
conflict.
a) Work through the problem using the negotiation techniques described above.
b) Attempt to establish a compromise – try to bring some degree of satisfaction to all
parties through give and take.
c) Try to smooth out any differences and downplay the importance of any remaining
differences.
d) Emphasise areas of agreement.
Chapter 1: Project Management Introduction
Page | 16
e) If all else fails, and resolution is vital, the project manager should force the issue and
make a decision. He or she should emphasise to all parties that their commitment to the
project is appreciated, and that the conflict should now be put behind them.
3.3 A computerised information system project team
Much of the work of a dedicated IS department is likely to be project-based. This has lead to
many organisations organising the IS department according to a flat structure that recognises
that multitalented individuals will adopt different roles at different times – rather than
occupying a particular 'status'. Staff are selected from a pool of those currently available, and
perform different roles depending upon demand.
To operate such a system the organisation needs to devise a remuneration system that recognises
skills and work done rather than status.
We cover the systems development process in depth later in this Text. In the context of explaining
the roles of analysts and programmers, developing a computer system can be divided into two
parts.
a) Designing a system to perform the tasks the user department wants to be performed –
to the user's specification. This is the task of the systems analyst.
b) Writing the software – this is the job of the programmer.
3.3.1 Systems analysts
In general terms, the tasks of the systems analyst are as follows.
Systems analysis – involves carrying out a methodical study of a current system (manual or
computerised) to establish:
a) What the current system does.
b) Whether it does what it is supposed to do.
c) What the user department would like it to do, and so what the required objectives of
the system are.
Systems design – having established what the proposed system objectives are, the next stage is
to design a system that will achieve these objectives.
Systems specification – in designing a new system, it is the task of the systems analyst to specify
the system in detail.
Chapter 1: Project Management Introduction
Page | 17
This involves identification of inputs, files, processing, output, hardware, costs, accuracy, response
times and controls.
The system design is spelled out formally in a document or manual called the systems
specification (which includes a program specification for each program in the system).
The analyst will often also have overall responsibility systems testing.
Once installed, the analyst will keep the system under review, and control system maintenance
with the co-operation of user departments.
3.3.2 Programmers
Programmers write the programs. This involves:
a) Reading the system specification and understanding it.
b) Recognising what the processing requirements of the program are, in other words,
defining the processing problem in detail.
c) Having defined and analysed the processing problem, writing the program in a
programming language.
d) Arranging for the program to be tested.
e) Identifying errors in the program and getting rid of these 'bugs' – ie debugging the
program.
f) Preparing full documentation for each program within the system.
3.4 Controlling the team
The project manager is responsible for overall control of the project team.
There are two types of control strategies related to supervision.
(a) Behaviour control deals with the behaviour of team members. In other words,
control is exercised through agreed procedures, policies and methodologies.
(b) Output control is where management attention is focused on results, more than the
way these were achieved.
Handy writes of a trust-control dilemma in which the sum of trust + control is a constant
amount:
T + C = Y
Where T = the trust the superior has in the subordinate, and the trust which the subordinate feels
the superior has in him;
C = the degree of control exercised by the superior over the subordinate;
Y = a constant, unchanging value.
Chapter 1: Project Management Introduction
Page | 18
Any increase in C leads to an equal decrease in T; that is, if the manager retains more 'control' or
authority, the subordinate will immediately recognise that he or she is being trusted less. If the
superior wishes to show more trust in the subordinate, this can only be done by reducing C, that
is by delegating more authority.
3.4.1 Span of control
Span of control or 'span of management', refers to the number of subordinates or team
members responsible to a person.
Classical theorists suggest:
a) There are physical and mental limitations to a manager's ability to control people,
relationships and activities.
b) There should be tight managerial control from the top of an organisation downward. The
span of control should be restricted to allow maximum control.
Project managers may control very large teams. On large projects management layers will be
required between the overall project manager and team members. The appropriate span of
control will depend on:
a) Ability of the manager. A good organiser and communicator will be able to control a
larger number. The manager's workload is also relevant.
b) Ability of the team members. The more experienced, able, trustworthy and well-trained
subordinates are, the easier it is to control larger numbers.
c) Nature of the task. It is easier for a supervisor to control a large number of people if
they are all doing routine, repetitive or similar tasks.
d) The geographical dispersal of the subordinates, and the communication system of the
organisation.
3.4.2 Flat management structures
The wide range of people and skills required to successfully complete a systems development
project has led to the acceptance of flat management structures being the most appropriate
for this process.
The span of control has implications for the 'shape' of a project team and of an organisation
overall. An organisation with a narrow span of control will have more levels in its management
Chapter 1: Project Management Introduction
Page | 19
hierarchy – the organisation will be narrow and tall. A tall structure reflects tighter supervision
and control, and lengthy chains of command and communication.
A team or organisation of the same size with a wide span of control will be wide and flat. The flat
organisation reflects a greater degree of delegation – the more a manager delegates, the wider
the span of control can be.
The wide range of people and skills required to successfully complete a systems development
project has led to the acceptance of flat management structures being the most appropriate for
this process.
The justification is that by empowering team members (or removing levels in hierarchies that
restrict freedom), not only will the job be done more effectively but the people who do the job
will get more out of it.
Project team members must be flexible to be able to respond quickly to specific and varied
customer demands. Team members must therefore be committed.
The following steps may help increase commitment.
a) Develop identification with the team and the project by means of:
Communications
Participation
Team member ideas
Financial bonuses
b) Ensure that people know what they have to achieve and are aware of how their
performance will be measured against agreed targets and standards.
c) Introduce a reward system, which relates at least partly to individual performance.
d) Treat team members as human beings, not machines.
4 Project stakeholders
Project stakeholders are the individuals and organisations who are involved in or may be
affected by project activities.
We have already looked at the role of the Project Manager and the Project Team. Other key
stakeholders are defined as follows.
Chapter 1: Project Management Introduction
Page | 20
Project sponsor is accountable for the resources invested into the project and responsible for
the achievement of the project's business objectives. The sponsor may be owner, financier, client
etc., or their delegate.
Project support team is a term used to designate the personnel working on a project who do
not report to the project manager administratively.
Users are the individual or group that will utilise the end product, process (system), or service
produced by the project.
Risk manager. For large projects it may be necessary to appoint someone to control the process
of identifying, classifying and quantifying the risks associated with the project.
Quality manager. For large projects it may be necessary to appoint someone to write the
quality plan and develop quality control procedures.
Project stakeholders should all be committed towards a common goal – successful project
completion. The Project Plan should be the common point of reference that states priorities and
provides cohesion.
However, the individuals and groups that comprise the stakeholders all have different roles, and
therefore are likely to have different points of view. There is therefore the potential for
disagreements between stakeholder groups.
4.1 Managing stakeholder disputes
The first step is to establish a framework to predict the potential for disputes. This involves risk
management, since an unforeseen event (a risk) has the potential to create conflict, and dispute
management – implementing dispute resolution procedures that have minimal impact on costs,
goodwill and project progress.
One approach to dispute management strategy is to organise affairs in a way that minimises
exposure to the risk of disputes. This means employing effective management techniques
throughout all areas of operation.
4.1.1 Dispute resolution processes
Resolution is the solution of a conflict. Settlement is an arrangement, which brings an end to
the conflict, but does not necessarily address the underlying causes.
Wherever there is a potential for conflict, a process to resolve it should be established before
the conflict occurs.
Chapter 1: Project Management Introduction
Page | 21
We have already discussed negotiation and resolution techniques in the context of project team
conflict. Many of the principles discussed previously can be applied to stakeholder conflicts,
although the relative positions of the stakeholders involved can complicate matters.
Conflict between project stakeholders may be resolved by:
Negotiation (perhaps with the assistance of others)
Partnering
Mediation
A third party neutral may judge or intervene to impose a solution
On very large projects a Disputes Review Board (DRB) may be formed. This may comprise
persons directly involved in the project engaged to maintain a 'watching brief' to identify and
attend upon disputes as they arise.
Usually there is a procedure in place which provides for the DRB to make an 'on the spot' decision
before a formal dispute is notified so that the project work can proceed, and that may be followed
by various rights of review at increasingly higher levels.
In practice, disputes are often resolved by the acceptance of the view of the party that has the
most financial 'clout' in the project. In such a situation mediation and negotiation may only deliver
an outcome which is a reflection of the original power imbalance.
5 Organisational context for projects
‘Every strategic initiative in a firm involves change management—and that is best accomplished
through the tools, tactics and techniques of project management…’
Project management thus becomes the enabler, the vehicle through which all strategic change
happens. The project itself is the gap filler, the bridge between what is and what will be’ (Baker,
2008).
Projects should be undertaken within the usual corporate and functional planning processes. The
objectives set at different levels will set the foundations of strategy. Project management is often
critical in ensuring that required changes are put in place.
Projects can be set at corporate level, departmental level, product level and market level or even
across departments or geographies. Top-level projects include culture change throughout the
Chapter 1: Project Management Introduction
Page | 22
organisation, new market entry or even implementation of an enterprise system. Departmental,
product and market levels could include research or promotional projects for marketers, or the
roll out of a new sales force reporting system as examples. Projects that span departments and
geographies include new product development projects.
It is clear that projects are an essential part of the business activities at all levels. The challenge
then is to prioritise and manage these appropriately to meet the organisation’s needs.
Organisations and departments typically have many projects at any given time. Projects need to
be aligned with the organisation’s strategic priorities, and prioritised to ensure that the
organisation’s resources are focused on the priorities of the organisation. However, Rad and Levin
(2008) comment that often projects appear like ‘floating’ islands and are not best integrated into
the organisation.
They recommend the use of Project Portfolio Management (PPM), which enables organisations
to select, resource and implement projects to ensure that the right projects are selected on the
basis of their benefit to the organisation, and also taking account of the organisation’s resources.
Most PPM approaches result in a prioritised list of the most important projects. The project at the
top of the list should have priority over others, and resourcing decisions should follow.
This PPM approach is not limited to new projects, but places a check on the relevance of projects
as the organisation’s strategy changes. As the portfolio term implies, this assessment must not
only apply in the original selection decision, but also review the project at key stages to test the
current alignment with the organisation’s objectives and strategy, failing which can result in early
project termination.
While the discipline of a PPM approach is perfectly logical, it must be recognised that the
outcomes are often not. If a number of projects are competing for approval at a project board or
equivalent, then the relative strength of support and positions of power of the project champions
will often influence the decision.
External conditions may have an impact – it is much harder to get approval for expenditure during
recessionary times, as otherwise important work will be cancelled or postponed.
It is often more difficult to make a case for large-scale in-house projects that do not directly relate
to profitability. For example, a company may have a series of databases within separate
departments that are not integrated. To rationalise them into a consolidated database with much
Chapter 1: Project Management Introduction
Page | 23
more potential for improving, Customer Relationship Management could give significant longer-
term returns. The problem is that it might be forgotten when a campaign shows good results that
it was the refined database that pointed the way to better targeting of new clients.
6 Why is project management important?
Professional project management started on major projects, such as new airport developments
or major industrial developments. In such instances, project managers were required to co-
ordinate and control the development process and the interaction of all players (e.g. owners,
funding agencies, developers, designers, contractors, suppliers, operators, regulatory bodies etc.).
The complex nature of these projects meant that a formal management was required.
Successful project management in this sphere led to an awareness that organisations with strong
project management were more effective than those that did not manage projects well. Project
management then developed its ‘body of knowledge’ that has since spread to all sizes of projects
across different functions and throughout organisations.
What is effective project management? Meredith and Mantell (2003) state that success or failure
of a project is based on whether they have achieved targets on:
Required performance (quality)
Cost (money invested)
Due date (delivery)
Traditionally, the key measure of success in projects is achieving the outcome. A successful
project is thus completed within the allocated time and cost and to the desired quality or results
(such as achieving a level of awareness or encouraging people to trial or specific sales results).
The three core issues – performance, cost and delivery – are clearly sound commercial issues. A
delay in the launch of a movie may mean that it misses a period when demand is traditionally
high. A delay in launching the movie in one market may result in pirated copies there. A poor-
quality soundtrack or editing of a movie may limit customers’ enjoyment and reduce the
possibility of word-of-mouth referrals. Failing in one of these areas results in loss of revenue and
customer satisfaction. Exceeding the budget will also impact on profitability.
Chapter 1: Project Management Introduction
Page | 24
6.1 Project Success
Project management’s contribution is now widely recognised as important within the functional
areas of organisations. Business initiatives, activities and campaigns often fit the above definition
of projects. Professional project management gives attention to the various players, tasks and
outcomes for their success.
The consideration of project management will first address the types of projects (activities), how
these are undertaken (people and processes) and why they do it (strategic goals and competitive
position). Success results from their effective co-ordination and integration.
6.2 Projects present some management challenges
Table: Sample project challenges table
Challenge Comment
Teambuilding The work is carried out by a team of people often from varied work and
social backgrounds. The team must 'gel' quickly and be able to
communicate effectively with each other.
Expected
problems
Expected problems should be avoided by careful design and planning
prior to commencement of work.
Unexpected
problems
There should be mechanisms within the project to enable these
problems to be resolved quickly and efficiently.
Delayed benefit There is normally no benefit until the work is finished. The 'lead-in' time
to this can cause a strain on the eventual recipient who is also faced with
increasing expenditure for no immediate benefit.
Specialists Contributions made by specialists are of differing importance at each
stage.
Potential for
conflict
Projects often involve several parties with different interests. This may
lead to conflict.
7 Project success factors
Projects, small or large, are prone to fail unless they are appropriately managed and some effort
is applied to ensure that factors that might contribute to success are present. Here are some of
the key factors.
Chapter 1: Project Management Introduction
Page | 25
Clearly defined mission and goals effectively communicated to, and understood by, all
participants.
Top management support that is visible is important in sending out the right messages
regarding the significance of the project.
Competent project manager with the necessary technical and inter-personal skills.
Well-designed operational process to ensure that work proceeds efficiently.
Competent team members with the appropriate knowledge, skills and attitudes. A good
team spirit helps to smooth the path to completion.
Sufficient resources in terms of finance, materials, people and processes.
Excellent communication ethos to ensure information is shared and there are no
misunderstandings.
Use of effective project management tools such as charts, leading edge software and
project progress meetings.
Clear client focus so that all work is done bearing in mind the needs of internal and
external customers.
Project management ensures responsibilities are clearly defined and that resources are focused
on specific objectives. The project management process also provides a structure for
communicating within and across organisational boundaries.
All projects share similar features and follow a similar process. This has led to the development
of project management tools and techniques that can be applied to all projects, no matter how
diverse. For example, with some limitations, similar processes and techniques can be applied
whether building a major structure (e.g. Terminal 5 at Heathrow Airport) or implementing a
company-wide computer network.
All projects require a person who is ultimately responsible for delivering the required outcome.
This person (whether officially given the title or not) is the project manager.
7.1 Why do projects go wrong?
Project planning is fundamental to project success. Realistic timescales and resource
requirements must be established, use of shared resources must be planned and, most
fundamental of all, jobs must be done in a sensible sequence.
Common reasons for project failure are also:
Chapter 1: Project Management Introduction
Page | 26
Poor project planning (specifically inadequate risk management and weak project plan)
A weak business case
Lack of top management involvement and support
However, even if all these aspects are satisfactory there are other potential pitfalls that the project
planner must avoid or work around. Here are some examples.
a) Unproven technology
The use of new technological developments may be a feature of any project. The range of such
developments extends from fairly routine and non-critical improvements, through major
innovations capable of transforming working practices, costs and time scales, to revolutionary
techniques that make feasible projects that were previously quite impracticable. As the practical
potential of a technical change moves from minor to major, so its potential to cause disruption if
something goes wrong with it also increases.
b) Changing client specifications
It is not unusual for clients' notions of what they want to evolve during the lifetime of the project.
However, if the work is to come in on time and on budget, they must be aware of what is
technically feasible, reasonable in their aspirations, prompt with their decisions and, ultimately,
prepared to freeze the specification so that it can be delivered.
Note that the term 'client' includes internal specifies.
c) Politics
This problem area includes politics of all kinds, from those internal to an organisation managing
its own projects, to the effect of national (and even international) politics on major undertakings.
Identification of a senior figure with a project; public interest and press hysteria; hidden agendas;
national prestige; and political dogma can all have disastrous effects on project management.
Lack of senior management support is an important political problem.
8 A project-oriented organisation (‘POO’)
A project oriented organisation (POO) is an organisation, which:
Defines ‘Management by Projects’ as an organisational strategy
Chapter 1: Project Management Introduction
Page | 27
Applies temporary organisations for the performance of complex processes
Manages a project portfolio of different project types
Has specific permanent organisations to provide integrative functions
Applies a ‘New Management Paradigm’
Has an explicit project management culture
Perceives itself as project-oriented
A project-oriented culture (‘POC’) is characterised by the existence of an explicit culture of project
management. In the POC, project management is considered as a business process, for which
there exist specific procedures and a common understanding of the performance of this process.
9 Projects and strategy
9.1 Linking projects with strategy
Grundy and Brown (2002) see three links between strategic thinking and project management.
a) Many projects are undertaken as consequences of the overall strategic planning process.
These projects may change the relationship between the organisation and its
environment or they may be aimed at major organisational change.
b) Some important projects arise on a bottom-up basis. The need for action may become
apparent for operational rather than strategic reasons: such projects must be given
careful consideration to ensure that their overall effect is congruent with the current
strategy.
c) Strategic thinking is also required at the level of the individual project, in order to avoid
the limitations that may be imposed by a narrow view of what is to be done.
9.2 Project managing strategy
Project management in its widest sense is fundamental to much strategy. This is because very
few organisations are able to do the same things in the same ways year after year. Continuing
environmental change forces many organisations to include extensive processes of adaptation
into their strategies. Business circumstances change and new conditions must be met with new
responses or initiatives. Each possible new development effectively constitutes a project in the
terms we have already discussed.
Gray and Larsen (2010) give examples, some of which are noted below.
Chapter 1: Project Management Introduction
Page | 28
a) Compression of the product life cycle: product life cycles have fallen to one to three years,
on average, and it has become necessary to achieve very short time to market with new
products if advantage is to be retained.
b) Global competition emphasises cost and quality; project management techniques are
used to achieve the new requirements.
c) Increased product complexity requires the integration of diverse technologies.
d) Management delayering has eliminated routine middle-management posts while much
work has been outsourced: such organisational change tends to be continuous and
project management techniques are required to get things done in a flexible manner.
e) Increased customer focus in the form of customised products and close service
relationships is often achieved through a project management approach.
Grundy and Brown (2002) offer an integrative analysis of this trend and suggest three reasons for
taking a project management view of strategic management.
a) Much strategy appears to develop in an incremental or fragmented way; detailed
strategic thinking may be best pursued through the medium of a strategic project or
group of projects. Project management is a way of making ad hoc strategy more
deliberate and therefore better considered.
b) Strategic implementation is more complex than strategic analysis and choice; a project
management approach, as outlined above, has an important role to play here, but must
become capable of handling more complex, ambiguous and political issues if it is to play
it effectively. When an apparent need for a project emerges, it should be screened to
ensure that it supports the overall strategy.
c) Even at the smaller, more traditional scale of project management, wider strategic
awareness is vital if project managers are to deliver what the organisation actually needs
Of course, not all new developments are recognised as worthy of project management. For
example, the installation of a new, shared printer in an office would probably be regarded as a
matter of routine, though it would no doubt have been authorised by a responsible budget holder
and installed and networked by a suitable technician. There would probably have been a small
amount of training associated with its use and maintenance and it might have been the subject
of a health and safety risk assessment. All these processes taken together look like a project, if a
very small one.
Chapter 1: Project Management Introduction
Page | 29
In contrast to the multitude of such small events, modern organisations are likely to undergo
significant change far less often, but sufficiently frequently and with developments that have
sufficiently long lives for project management to be an important aspect of strategic
implementation. Project management and change management are thus intimately linked.
An atmosphere of change and continuing development will be particularly evident in relation to
marketing; information systems and technology; organisation structure; and organisation culture.
9.3 Project management as a core competence
Project management can be a core strategic competence for many companies. This is particularly
true for companies working in such industries as consulting and construction, but it is also true
of organisations of all kinds that can benefit from Grundy and Brown's (2002) approach outlined
above. Such companies must ensure that they maintain and improve their project management
abilities if they are to continue to be commercially successful.
Kerzner (2009) describes a five-level project management maturity model of continuous
organisational improvement in the methodology of project management. Organisations should
aspire to progress to the highest level, which is a state of continuous improvement. The five levels
need not necessarily follow one another in a linear fashion: they may overlap, but the degree of
overlap allowed is reflected in the risk associated with the overall process.
Level 1 Common knowledge
The importance of project management to the organisation is understood and
training in the basic techniques and terminology is provided.
Level 2 Common processes
The processes employed successfully are standardised and developed so that
they can be used more widely, both for future projects and in concert with other
methods such as total quality management.
Level 3 Singular methodology
Project management is placed at the centre of a single corporate methodology,
achieving wide synergy and improving process control in particular. A separate
methodology may be retained for IS matters.
Level 4 Benchmarking
Chapter 1: Project Management Introduction
Page | 30
Competitive advantage is recognised as being based on process improvement
and a continuing programme of benchmarking is undertaken.
Level 5 Continuous improvement Benchmarking information is critically appraised for its
potential contribution to the improvement of the singular methodology.
Models such as Kerzner’s are a guide to progress; in particular they indicate corporate training
needs and career development routes for project managers.
9.4 Strategic project management
It is possible to move from the slightly ad hoc approach outlined above, where project
management is essentially an implementation method, to a more all-embracing theory of
strategic development. Grundy and Brown (2002) suggest that it is often appropriate for
organisations to combine project management and strategic management into a process that
they call strategic project management. This envisages strategy as a stream of projects.
9.5 The project-structured organisation
Globalisation, other aspects of rapid environmental change and, above all, the need to exploit
knowledge make the structures, processes and relationships that compose configurations vital
for strategic success.
Johnson, Scholes and Whittington (2008) identify three major groups of challenges for twenty-
first century organisation structures.
a) The rapid pace of environmental change and increased levels of environmental
uncertainty demand flexibility of organisational design.
b) The creation and exploitation of knowledge requires effective systems to link the people
who have knowledge with the applications that need it.
c) Globalisation creates new types and a new scale of technological complexity in
communication and information systems; at the same time, diversity of culture, practices
and approaches to personal relationships bring their own new problems of
organisational form.
Of these three sets of issues, the need to capture, organise and exploit knowledge is probably
the most pressing for most organisations. An important element of response to this need is
therefore an emphasis on the importance of facilitating effective processes and relationships
Chapter 1: Project Management Introduction
Page | 31
when designing structures. Johnson, Scholes and Whittington (2008) use the term configuration
to encompass these three elements.
a) Structure has its conventional meaning of organisation structure.
b) Processes drive and support people: they define how strategies are made and controlled;
and how the organisation’s people interact and implement strategy. They are
fundamental to systems of control.
c) Relationships are the connections between people within the organisation and between
those internally and those externally.
Effective processes and relationships can have varying degrees of formality and informality and
it is important that formal relationships and processes are aligned with the relevant informal ones.
It is very important to be aware that structures, processes and relationships are highly
interdependent: they have to work together intimately and consistently if the organisation is to
be successful. Here we will be concerned with structures and processes: relationships in this
model are not really relevant to project management.
10 Structure
An organisation’s formal structure reveals much about it.
a) It shows who is responsible for what.
b) It shows who communicates with whom, both in procedural practice and, to a great
extent, in less formal ways.
c) The upper levels of the structure reveal the skills the organisation values and, by
extension, the role of knowledge and skill within it.
We are concerned here with the project-structured organisation, but we will approach it via some
other forms that are relevant to it.
10.1 The functional structure
In a functional organisation structure, departments are defined by their functions, that is, the
work that they do. It is a traditional, common sense approach and many organisations are
structured like this. Primary functions in a manufacturing company might be production, sales,
finance, and general administration. Sub-departments of marketing might be selling, advertising,
distribution and warehousing.
Chapter 1: Project Management Introduction
Page | 32
Functionally structured organisations can undertake projects successfully, partly, because they
are able to provide in-depth expertise to project managers by allocating expert staff from
appropriate functions. However, such staff can suffer from lack of focus if they still have a major
functional role to play and it can be difficult to integrate their efforts properly.
Functional structures are simple and almost intuitive in their operation. However, they tend to
promote insularity of thought and even distrust between functions. Achieving full co-ordination
of the work of the various departments can be very difficult. This sort of problem leads to the
matrix structure.
10.2 The matrix structure
The matrix structure imposes an extra layer of cross-functional management on top of the
functional structure in order to improve co-operation and integration of effort by granting
authority to project managers. Typically, the superimposed structure will be concerned with
individual products or product groups. Product or brand managers may be responsible for
budgeting, sales, pricing, marketing, distribution, quality and costs for their product or product
line, but have to liaise with the R&D, production, finance, distribution, and sales departments in
order to bring the product to the market and achieve sales targets.
The product managers may each have their own marketing team; in which case the marketing
department itself would be small or non-existent. The authority of product managers may vary
from organisation to organisation.
The division of authority between product managers and functional managers must be carefully
defined. Many decisions and plans will require careful negotiation if there is to be proper
cooperation. This can result in stress, conflict and slow progress.
The matrix structure is now regarded as rather old-fashioned, since it is essentially a complex way
of retaining the basic functional structure by adding extra resources to overcome its
disadvantages. More modern approaches seek fundamental improvements and tend to focus on
processes and projects.
10.3 The team-based structure
Both team- and project-based structures use cross-functional teams. The difference is that
projects naturally come to an end and so project teams disperse.
Chapter 1: Project Management Introduction
Page | 33
A team-based structure extends the matrix structures’ use of both vertical functional links and
horizontal, activity-based ones by utilising cross-functional teams. Business processes are often
used as the basis of organisation, with each team being responsible for the processes relating to
an aspect of the business. Thus, a purchasing team might contain procurement specialists, design
and production engineers and marketing specialists, to ensure that outsourced sub-assemblies
are properly specified and contribute to brand values as well as being promptly delivered at the
right price.
10.4 The project-based structure
The project-based structure is similar to the team-based structure except that projects, by
definition, have a finite life and so, therefore, do the project teams dealing with them. Staff are
allocated to a project team as needed to deliver the project end state. This approach has been
used for many years by such organisations as civil engineers and business consultants.
A high level of motivation is common and the integration of specialist work is eased by
commitment to project delivery. Staff may work on several projects at the same time and thus
have responsibilities to several project managers.
This approach is very flexible and easy to use; it tends to complete projects quickly if the discipline
of project management is well-understood. In particular, it requires clear project definition if
control is to be effective and comprehensive project review if longer-term learning is to take
place.
However, there is a downside to project-based organisation:
It can be expensive in staff and loss of economies of scale.
Project teams can become insular, rivalries and unwilling to import expertise when
necessary.
In the project-based organisation, specialist functional departments still exist, but their role is to
support the project teams. Since the project teams are staffed from a pool of experts, the
functional structure remains intact and is not weakened by secondments to project work.
11 Types of projects
The differences between projects indicate how they should be managed. Brown (2000) sees
projects as spreading across a continuum, with complexity increasing on a number of dimensions.
These dimensions include:
Chapter 1: Project Management Introduction
Page | 34
Budget size
Time span
Human resources involved
Complexity of tasks
Cross-functional involvement
Co-ordination required
Simple projects, characterised as low budget, short term, simple tasks, within a functional domain,
would require more administrative management. Those that are more complex, with higher
budgets, often with people from different departments (and maybe organisations) and spanning
a longer term would require more sophisticated project management.
Obeng (1994) takes a related approach to characterise four distinct project environments, with
differences in process uncertainty (ie what to do) and the level of outcome uncertainty (ie what
can be achieved) and named the four resulting categories.
a) Paint by numbers – Projects are low in process and outcome uncertainty, e.g. installing
point of sale (POS) displays in retailers’ outlets. The outcome is the same – the installation
of the POS display – and the process (the way in which it is implemented) would be
similar. However, differences, such as environmental factors (e.g. existing store design),
time issues (e.g. minimising staff and customer inconvenience) and cost issues (e.g.
adaptations for a given situation) mean this is not a completely routine process. Often,
organisations have process protocols or manuals detailing core processes. These types
of projects are considered ‘hard’ projects, because of their fixed processes and clarity of
outcome.
b) Making a movie – Projects are low in process uncertainty and high in outcome
uncertainty. Producers and directors know what is involved in making the movie,
although the topic, location and people vary. However, predicting the success of the
movie is difficult. Projects such as new product or advertising campaign launches often
have a similar pattern of high costs and a high risk of failure. These projects need clear,
precise definition of outcomes, and stakeholders’ expectations must be managed
throughout the process. Timescales and budgets must be tightly controlled.
c) The quest – Projects are high in process uncertainty and low in outcome uncertainty.
These projects have focused outcomes, but it is not clear how or when this will be
achieved. Some exploratory development projects, such as AIDS cures for pharmaceutical
Chapter 1: Project Management Introduction
Page | 35
companies, are in this category. Progress and resources reviews throughout these
projects are essential to keep within cost. Further, focus is essential to keep the project
on target.
d) The foggy project – Projects are vague in what is involved and in the expected results,
so they have no set process and uncertainty outcomes. The original dot-com companies,
like boo.com and lastminute.com, were foggy projects in their development stages, with
little to guide them. Foggy projects need control over costs and level of risk. Project
managers need to manage stakeholder relationships as the project develops.
11.1 Hard and soft projects
Project management, as a management discipline, has largely been developed in a context of
engineering, where there have been well-defined, tangible objectives to be achieved. Examples
abound in the civil engineering and aircraft industries. Even where objectives have been events
rather than things, such as mounting the Olympic Games, it has been fairly clear what the desired
outcomes were and what was involved in achieving them. There is, however, a wide category of
projects for which clear-cut scope does not exist and it is difficult to see quite how to proceed.
The project sponsors are aware that something must be done, but they are not quite sure what,
precisely, it is, nor how to achieve it. The public sector could provide many illustrations, such as,
for example, a perceived need to improve secondary education. Such a mission would be subject
to extensive debate: first as to what was to be understood by ‘improve’; and, second, how to go
about the ‘improving’.
11.2 Hard and soft labels
This apparent dichotomy represented by clearly defined, engineering-oriented programmes on
the one hand and, vaguer areas of aspiration on the other has led to the use of the terms hard
and soft to label the two types of project. This usage is not confined to the sphere of project
management. Professor Mike Pidd of Lancaster University Business School in relation to
operations research (OR) says:
‘Unfortunate though these terms are, they have crept into common usage in recent years. They
are really extreme points on a spectrum ...’ (Pidd, 2010).
In hard OR, the question of problem definition is seen as relatively straightforward, and
is more a question of finding out what is going on so that some appropriate analysis can
be conducted
Chapter 1: Project Management Introduction
Page | 36
The key assumption is that this real world can be understood and (sic) a taken-for-granted way.
By contrast, in soft OR, problem definition is seem as problematic and the process of
problem structuring is regarded as crucial to the success of any soft OR. This relates to
John Dewey’s maxim that, ‘a problem well put is a problem half solved’. The world is seen
as multi-faceted, and the approaches adopted to try to understand it are interpretive or
pluralistic. Thus, problem definition is seen as something which must be negotiated
between parties who may have different interests and interpretations.’ Professor Pidd’s
remarks about problem definition are as applicable to project management as to OR. The
other insight he offers us here is the idea of hard and soft as extreme points on a
spectrum: an awareness that an apparently hard project has some soft aspects will be
very useful to the project manager, as will be an awareness of the opposite case.
11.3 Seven dimensions for analysis
Just as the overall classifications of hard and soft should be seen as ends of a spectrum, so
Crawford and Pollacks’s factors have degrees of presence in a project; they are not qualities that
are present or absent. Most of these factors are both visible in the project and in the methods
used in its management, though some are more relevant to one or the other.
a) Goal/objective clarity. The degree of definition of the goal or objectives is the first
dimension of analysis.
Clear and specific desired outcomes are typical of engineering projects, while projects
relating to research or organisational change, for example, tend to have less well-defined
objectives.
b) Goal/objective tangibility. The clarity and tangibility of project goals and objectives are
often linked and the link may be very strong indeed, as with many engineering projects,
where the objective is the construction of a physical object. However, this is not always
the case: very clear goals can relate to intangible outcomes, such as individual exam
success, while some very tangible construction objectives, for example, may be
approached via ambiguous specifications.
c) Success measures. Generally, it is easier to measure the degree of success of hard projects
than of soft ones, partly as a result of their higher degree of goal tangibility and clarity.
Quantitative performance measures are associated with hard projects and qualitative
with soft. It should not be assumed that quantitative measures are superior to qualitative
ones: each has its place. Quantitative measures are generally confined to a few variables
Chapter 1: Project Management Introduction
Page | 37
considered significant in order to minimise the cost of data capture; this does not give a
full picture. Nor are quantitative measures adequate when projects deal with qualitative
matters such as attitude, learning and morale.
d) Project permeability. The permeability of a project is the extent to which its objectives
and processes are subject to influences outside the control of the project manager. The
extent of these influences might be very limited in a short, simple project of a well-
understood type. However, larger, less well-defined projects in less well-understood
environments are likely to display considerable permeability. A good example of a factor
increasing project permeability is the use of sub-contractors: their competence and
diligence are far less subject to the control of the project manager than are those of in-
house teams.
e) Number of solution options. Hard projects will normally have one or more clearly defined
outcomes, possibly handed down by authority. Softer projects will tend to have a range
of possible outcomes that require consideration.
f) Degree of participation and practitioner role. This dimension relates specifically to the
nature of the appropriate project management practice and is dealt with below under
implementation.
g) Stakeholder expectations. Clear and logical stakeholder relationships are typical in hard
projects, where the emphasis is on efficiency and predictability. Soft projects, because of
their indeterminate nature, require a greater degree of interaction between stakeholders
in order to overcome differences of style, language, assumptions and competence. The
credibility of project staff in the eyes of stakeholders may become an issue.
11.4 Implementation considerations
The chances of making a project a success are enhanced if project management methods are
tailored to the degree of its hardness or softness. Hard and soft approaches are not mutually
exclusive and can be combined in ways that reflect the project's position on the various
dimensions.
a) Goal/objective clarity. The extent of clarity in the definition of a project's goals and
objectives affects the methods that are used to move the project forward. Well-defined
goals permit the application of techniques designed to achieve them efficiently. Where
there is goal ambiguity, effort must be deployed on consultation, learning and
Chapter 1: Project Management Introduction
Page | 38
negotiation in order to reach an adequate degree of goal definition. These processes will
almost certainly have to be continued throughout the life of the project as new
ambiguities arise and have to be dealt with. The management of the project thus entails
as much consideration of what is to be done as of how to do it.
b) Project permeability. Where project permeability is low, hard management methods that
concentrate on clear objectives and techniques are appropriate. However, where
permeability is high, a softer approach is needed. It may be necessary to deal with, for
example, bureaucratic, organisational, cultural and political influences that are capable of
affecting both objectives and methods. These influences will probably have to be dealt
with sympathetically and diplomatically. They will require a learning approach to
management and a degree of adjustment to project processes and intended outcomes
as understanding of the environment grows.
c) Number of solution options. Hard projects tend to be managed to achieve efficient
delivery of clearly defined outcomes. Softer project management methods will tend to
explore a range of methods and solutions to problems. This will be appropriate when
there is potential benefit in questioning assumptions and exploring a range of options.
Crawford and Pollack (2004) say ‘the soft paradigm emphasises learning, debate,
participation, exploration and questioning’.
d) Degree of participation and practitioner role. A soft approach to project management is
participative and collaborative, with expertise in facilitating the efforts of others being a
major competence for the project manager. By contrast, the hard project management
style tends to be based on individuals’ technical expertise in their areas of concern.
Project staff will have clearly defined roles and boundaries. This hard approach can
achieve faster project delivery, but at a potential cost in lost innovation and learning.
e) Stakeholder expectations. The implementation aspects of this dimension follow on from
the previous one. A hard management approach will tend towards command and control,
whereas a soft approach ‘has culture, meaning and value as central concerns’.
Organisations are seen as cultural systems and project success will depend on the
perceptions of the stakeholders involved.
Chapter 2: Project Feasibility Studies
Page | 39
Chapter 2: Project Feasibility Studies
Topics covered in the chapter:
Key areas of feasibility
Steps in feasibility studies
Terms of reference
Investment appraisal techniques: payback, ARR, discounted cash flow (DCF), NPV and IRR
Principal methods of evaluating the economic viability of a project
Feasibility study report
Chapter 2: Project Feasibility Studies
Page | 40
1 Investment in project
Investment is any expenditure made with the expectation of future benefits or 'returns'.
Expenditure can be divided into two categories: capital expenditure and revenue expenditure.
Commercial investment decisions are largely determined by financial considerations. (Are the
returns sufficient? Is it the cheapest option available?)
An investment decision is a decision:
(a) whether or not to undertake an investment in a particular project
(b) when there are alternative choices for an investment, selecting which of the mutually
exclusive investments to undertake
(c) when capital for spending is in short supply, deciding which investments to undertake with
the money that is available.
1.1 Investment by the commercial sector and by not-for profit organisations
For investments by commercial organisations, a major consideration is finance. An investment
should be justified in financial terms, and should not be undertaken if it is not expected to meet
the minimum financial requirements. However, non-financial considerations could influence an
investment decision. Investment by not-for-profit organisations differs from investment by
commercial organisations.
(a) Relatively few capital investments by not-for-profit organisations are made with the
intention of earning a financial return. For example, government spending on roads,
hospitals, schools, the defence forces and the police service, nuclear waste dumps and so
on are not made with an eye to profit and return. Similarly, investments by charities would
not be made with profit in mind.
(b) Rather than considering financial cost and financial benefits (if any) alone, not-for-profit
organisations will often have regard to the social costs and social benefits of investments
when making capital expenditure decisions. The social costs of building a new motorway
into a city might include the loss of people's homes, more pollution and health hazards
whereas the social benefits might include faster travel, the ability of the road to carry a
Chapter 2: Project Feasibility Studies
Page | 41
larger volume of traffic and the environmental benefits for the people in the city from
reduced traffic congestion.
The project appraisal techniques described in this chapter are based on the assumption that the
investment decision is a commercial one, and that financial considerations will therefore
predominate.
2 Steps in project appraisal
There is a need for management control over capital spending. Projects, once identified as
potential investments, should be properly evaluated and a formal proposal to invest submitted to
the managers responsible for authorising the spending. The spending should be authorised. Once
authorised, the spending on the project and benefits from the project should be monitored. After
the project has been completed, there should be a post-completion audit.
Capital expenditure proposals should go through a formal decision making and control cycle with
the following key stages.
• Identification
• Appraisal
• Proposal
• Approval and authorisation
• Implementation
• Monitoring and control
• Performance review and post completion audit
2.1 Identification
Projects originate from the identification of a problem or the opportunity to do something new.
If the issue identified matches the long-term strategic objectives of the business then an initial
proposal may be made which, if approved, will result in a formal project.
At this point management must ensure that the project is established with clear terms of
reference, an appropriate management structure and a carefully selected project team. The
project team will have to study, discuss and analyse the problem, from a number of different
Chapter 2: Project Feasibility Studies
Page | 42
aspects (e.g. technical, financial etc.) so must have the appropriate skills and authority to carry
out the task.
It is important at this stage to establish general project goals which can be developed into specific
objectives. Clear goals and objectives give team members quantifiable targets to aim for. This
should improve motivation and performance, as attempting to achieve a challenging goal is more
inspiring than simply being told ‘do your best’.
2.2 Appraisal
Appraisal has a number of elements
• Feasibility study and financial appraisal
• Risk assessment
• Finance source selection
2.2.1 Feasibility study and financial appraisal
A feasibility study undertaken by a carefully selected team covering all aspects of a project's
feasibility is a vital stage in assessing whether an investment is worthwhile. Feasibility studies are
particularly important for investments and projects that are likely to be long and complicated and
for very large projects where it will be essential to be able to develop a clear business case.
A more realistic judgement as to the overall feasibility of the project can now be made. Some
large projects may involve a pre-project feasibility study, which establishes whether it is feasible
to undertake the project at all. For complex projects, a detailed feasibility study may be required
to establish if the project can be achieved within acceptable cost and time constraints.
A feasibility study team might be appointed to carry out the study (although individuals might
be given the task in the case of smaller projects).
• Members of the team should be drawn from the departments affected by the investment.
• At least one person must have relevant detailed technical knowledge, and one other
person must be able to assess the organisational implications of the new system.
• It is possible to hire consultants to carry out the feasibility study, but their lack of
knowledge about the organisation may adversely affect the usefulness of their proposals.
Chapter 2: Project Feasibility Studies
Page | 43
• Before selecting the members of the study group, the steering committee must ensure
that they possess suitable personal qualities, e.g. the ability to be objectively critical.
There are five key areas in which a project must be feasible if it is to be selected.
• Operational feasibility – Operational feasibility is a key concern. If an investment makes
technical sense but conflicts with the way the organisation does business, the solution is
not feasible. Thus an organisation might reject a solution because it forces a change in
management responsibilities, status and chains of command, or does not suit regional
reporting structures, or because the costs of redundancies, retraining and reorganisation
are considered too high.
• Technical feasibility – The requirements, as defined in the feasibility study, must be
technically achievable. For a computer system for example, any proposed solution must be
capable of being implemented using available hardware, software and other technology.
Technical feasibility considerations could include the following.
– Volume of transactions that can be processed within a given time
– Capacity to hold files or records of a certain size
– Response times (how quickly the computer does what you ask it to)
– Number of users that can be supported without deterioration in the other criteria
• Social feasibility – An assessment of social feasibility will address a number of areas,
including the following.
– Personnel policies
– Redrawing of job specifications
– Threats to industrial relations
– Expected skills requirements
– Motivation
• Ecological feasibility – Ecological feasibility relates to environmental considerations. A
particular course of action may be rejected on the basis that it would cause too much
damage to the environment. In some markets customers may prefer to purchase
ecologically sound products. Ecological feasibility issues could include the following.
– What waste products are produced?
Chapter 2: Project Feasibility Studies
Page | 44
– How is waste disposed of?
– Is use of the product likely to damage the environment?
– Could the production process be 'cleaner'?
– How much energy does the process consume?
• Economic feasibility – Any project will have economic costs and economic benefits.
Economic feasibility has three strands.
– The benefits must justify the costs.
– The project must be the ‘best’ option from those under consideration for its
particular purpose.
– The project must compete with projects in other areas of the business for funds.
Even if it is projected to produce a positive return and satisfies all relevant criteria, it
may not be chosen because other business needs are perceived as more important.
2.2.2 The feasibility study team
A feasibility study team should be appointed to carry out the study (although individuals might
be given the task in the case of smaller projects).
(a) Members of the team should be drawn from the departments affected by the project.
(b) At least one person must have a detailed knowledge of computers and systems design (in a
small concern it may be necessary to bring in a systems analyst from outside.
(c) At least one person should have a detailed knowledge of the organisation and in particular
of the workings and staff of the departments affected. Managers with direct knowledge of
how the current system operates will know what the information needs of the system are,
and whether any proposed new system (for example an off-the-shelf software package) will
do everything that is wanted. They are also most likely to be in a position to recognize
improvements that can be made in the current system.
(d) It is possible to hire consultants to carry out the feasibility study, but their lack of knowledge
about the organisation may adversely affect the usefulness of their proposals.
Chapter 2: Project Feasibility Studies
Page | 45
(e) Before selecting the members of the study group, the steering committee must ensure that
they possess suitable personal qualities, e.g. the ability to be objectively critical.
(f) All members of the study group should ideally have some knowledge of information
technology and systems design. They should also be encouraged to read as widely as
possible and take an active interest in current innovations.
With larger projects it may well be worthwhile for a small firm to employ a professional systems
analyst and then appoint a management team to work with the analyst.
2.2.3 Identifying and selecting Information Systems projects
A planned approach is needed when identifying and selecting new information systems projects.
The following actions should be considered.
a) IS projects almost always utilise IT. IT is critical to the success of many organisations. This
means that an IT strategy should form a core part of the overall corporate strategy and should
be developed/updated whenever the organisation's strategy is reviewed or as otherwise
necessary. IT needs can then be identified in the context of overall business needs.
b) Because IT is critical, it requires adequate representation at senior management level. It is no
longer suitable for IT to be under the control of the MD, FD or computer centre manager. It
really needs a separate Board level person responsible, such as an Information Director or an
IS director. This will help to ensure that IT is given adequate consideration at strategic level.
c) The IT development can no longer function as a subsystem of accounting, administration or
finance. It should be given separate departmental or functional status in the organization
with its own reporting lines and responsibilities.
d) Once the IT department has been set up, its funding must be considered. A simplistic
approach would be to treat it as an overhead; this is simple but inefficient. There are various
approaches possible to the recovery of IT costs from user departments, and the IT
department may even operate as a commercial concern providing services to third parties at
a profit.
e) A strategic plan for the use of IT should be developed. This should take in separate elements
such as information technology and information systems. It should also acknowledge the
importance of the organisation's information resource.
Chapter 2: Project Feasibility Studies
Page | 46
f) If new computer systems are to be introduced regularly, the organisation may set up a
steering committee to oversee systems development. A steering committee can also be set
up for a one-off project. The role of the steering committee includes approving or rejecting
individual projects and where appropriate submitting projects to the Board for approval. The
composition and determination of terms of reference for the steering committee must be
agreed.
g) The approach of the organisation to individual projects must be decided. Will it follow the
traditional life cycle or will it use a methodology? Commercial methodologies impose
discipline on the development process.
h) Procedures for evaluating and monitoring performance both during and after a project need
to be put in place. Many methodologies require formal sign-off of each stage, but this does
not obviate the need for good project management or for post-implementation evaluation.
i) Details of the systems development procedures must be agreed. If a commercial
methodology is used, many of these procedures will be pre-determined. Areas to be
considered include the approach to feasibility studies, methods of cost-benefit analysis,
design specifications and conventions, development tools and techniques, reporting lines,
contents of standard invitations to tender, drawing up of supplier conditions and procedures
for testing and implementation.
2.2.4 Conducting the feasibility study
Some of the work performed at the feasibility study stage may be similar to work performed later
on in the development of the project. This is because both processes include the need to define
the current situation or problem.
A feasibility study should be carried out before undertaking an information systems project
because a new or amended system may:
a) Be complicated and costly.
b) Disrupt operations during development and implementation (e.g. staff and management
time).
c) Have far reaching consequences in a way an organisation conducts future business.
d) Impact on organisation strategy and structure.
Chapter 2: Project Feasibility Studies
Page | 47
2.2.5 Terms of reference
The terms of reference for a feasibility study group may be set out by a steering committee, the
information director or the board of directors, and might consist of:
a) To investigate and report on an existing system, its procedures and costs.
b) To define the systems requirements.
c) To establish whether these requirements are being met by the existing system.
d) To establish whether they could be met by an alternative system.
e) To specify performance criteria for the system.
f) To recommend the most suitable system to meet the system's objectives.
g) To prepare a detailed cost budget, within a specified budget limit.
h) To prepare a draft plan for implementation within a specified timescale.
i) To establish whether the hoped-for benefits could be realised.
j) To establish a detailed design, implementation and operating budget. (k) To compare
the detailed budget with the costs of the current system.
k) To set the date by which the study group must report back.
l) To decide which operational managers should be approached by the study group.
The remit of a feasibility study may be narrow or wide. The feasibility study team must engage
in a substantial effort of fact finding.
The methods available for financially appraising a proposed project are discussed below.
2.2.6 Risk assessment
At this initial stage, risks that could affect project implementation need to be carefully identified.
Once this has happened, risks need to be ranked according to their seriousness and likelihood,
and measures taken to transfer, minimise, accept or eliminate project risks. What happens to the
risk will depend on the severity of the risk and the cost of management action.
The risk situation also needs to be reviewed every time key project decisions are taken.
From the point of view of any financial risks it may be necessary to consider sensitivity or scenario
analysis (covered later).
Chapter 2: Project Feasibility Studies
Page | 48
2.2.7 Finance source selection
The alternative sources of finance available to businesses and the methods of selecting the most
appropriate one are covered later.
2.3 Proposal
Once the feasibility study has been completed, the project team should prepare a formal proposal
to put to the business executives with a recommended course of action. The contents of the
proposal will largely follow on directly from the feasibility study, the proposal being a formalised
document setting out the business case for the proposal and how it should be financed.
It is likely that the results of various studies undertaken for the feasibility study will be included
as appendices in this report, though the information may well be in a more summarised form.
The proposal must stand alone. It must provide all of the information that the executives may
need in order to come to a conclusion. It would typically start with an executive summary,
followed by the detail of the report, the conclusion and recommendations, and any appendices.
2.4 Approval and authorisation
The specific authorisation requirements will depend on the financial and strategic significance of
the proposal. Senior managers may have the authority to decide on small projects in their area.
Directors are liable to be able to authorise larger projects on their own, but for the most
significant projects approval will be required from the full board of directors.
Those making the decision must be satisfied that an appropriately-detailed evaluation has been
carried out, that the proposal meets the necessary criteria to contribute to profitability, and that
it is consistent with the overall strategy of the enterprise.
The benefits of a formal system of authorisation and monitoring are as follows.
(a) Capital expenditure projects often involve large amounts of spending and resource
utilisation. In view of their importance for a business, they should be planned, approved
and controlled with as much care as revenue spending is controlled (e.g. through
budgeting and budgetary control).
(b) A capital investment decision may be difficult to reverse. When a spending decision is
reversed, considerable costs might already have been incurred for little or no benefit.
Chapter 2: Project Feasibility Studies
Page | 49
(c) Investment decisions need to be considered in the light of strategic and tactical plans of
the company. Investment decisions should be consistent with the company's long-term
objective, which will usually be the maximisation of the wealth of shareholders. A formal
process of project appraisal and approval is a way of checking consistency with strategic
objectives.
(d) Capital projects might have an expected life of many years, and estimates of future
returns will inevitably be uncertain. Consequently, there may be a high degree of risk
and uncertainty in investment decisions. A formal appraisal procedure provides an
opportunity for assessing the risk.
2.5 Implementation
Once the decision has been made that the project will be undertaken, responsibility for the
project should be assigned to a project manager or other responsible person. The required
resources will need to be made available to this manager, who should be given specific targets
to achieve.
The project manager is concerned with co-ordinating people and other resources to carry out
the project plan and has two phases.
• Design and development
• Distribution
2.6 Monitoring and control
Monitoring and control is concerned with ensuring project objectives are met by monitoring and
measuring progress and taking corrective action when necessary.
At the start of each project, an overall project plan needs to be produced to enable the business
to monitor project delays. This should be supplemented by detailed project plans and budgets
describing the tasks, resources and links. At the initial stage, the plan needs to highlight resource
and time constraints, and also project date constraints.
Quality standards also need to be established before the project commences and ongoing quality
control procedures defined.
Managers and project monitoring committees should be kept informed of progress, with
achievements measured against the project's critical success factors being regularly reported.
Chapter 2: Project Feasibility Studies
Page | 50
Cost control systems also need to be established that will monitor actual against planned
expenditure.
Actual performance should be reviewed against the objectives identified in the project plan. If
performance is not as expected, control action will be necessary.
2.7 Performance review and post implementation audit
2.7.1 Performance review
The nature of an investment or project will determine how its success is measured. Performance
reviews will vary in content from organisation to organisation, and from investment to
investment. Organisations will need to consider carefully the following factors.
• What is evaluated
• Who decides what constitutes performance and whether it is good or bad
• Does the investment have a single clear purpose, or a number of different purposes which
will complicate the targets that are set for it
• How important will quantitative measures be and how important will qualitative measures
be
Financial measures are an important measure of many investments’ success. Organisations will
assess whether the investment is generating the expected positive cash flows and whether it is
fulfilling other targets, for example a payback period of less than a certain number of years, or a
target return on investment.
With many investments, the key success indicators are likely to be direct improvements in
production. Likely important measures here include:
• Number of customer complaints and warranty claims
• Rework
• Delivery time
• Non-productive hours
• Machine down time
• Stock-outs
Chapter 2: Project Feasibility Studies
Page | 51
Some investments will be undertaken to improve internal procedures, and will be assessed on
the basis of whether they have fulfilled the needs that prompted the investment. The performance
of a computer system for example will be evaluated on the basis of whether it meets the basic
needs to provide information of the required quality (timely, accurate, relevant to business needs,
clear etc.), or improves turnaround time for information.
2.7.2 Post completion audit
A post-completion audit is designed to identify improvements not only over the remaining life of
a specific project, but in the business's budgeting and management procedures.
A post audit or a post-completion audit is a review of the cash inflows to and outflows from a
project after it has reached the end of its life, or at least some years after it began. As far as
possible, the actual cash flows should be measured and compared with the estimates contained
in the original capital expenditure appraisal. The manager responsible for the project should be
asked to explain any significant variances.
A post-completion audit is an objective, independent assessment of the success of a capital
project in relation to plan. It covers the whole life of the project and provides feedback to
managers to aid the implementation and control of future projects.
3 Methods of project appraisal
There are several methods for the financial appraisal of a project, and evaluating whether the
project would be of value to the organisation.
(a) The accounting rate of return method (or return on investment). This method
calculates the profits that will be earned by a project and expresses these as a percentage
return on the capital invested in the project. The higher the rate of return, the higher a
project is ranked. A project might be undertaken if its expected accounting rate of return
exceeds a minimum target amount. This method of project appraisal is based on
accounting results rather than cash flows.
(b) The payback period. This method of investment appraisal calculates the length of time a
project will take to recoup the initial investment, in other words how long a project will
take to pay for itself. A capital project might not be undertaken unless it achieves payback
Chapter 2: Project Feasibility Studies
Page | 52
within a given period of time. This method of project appraisal is based on the anticipated
cash flows.
(c) A discounted cash flow (DCF) appraisal. There are three methods of project appraisal
using DCF.
(i) The net present value (NPV) method. This takes into consideration all the relevant
cash flows associated with a project over the whole of its life, and also when the cash
flows will occur. Cash flows occurring in future years are then adjusted to a 'present
value'. The process of re-valuing all project cash flows to a 'present value' is known
as discounting. The present value of benefits (revenues or savings) are then
compared with the present value of expenditures. The difference is the net present
value. If the present value of benefits exceeds the present value of costs, the project
is financially justified. If the present value of benefits is less than the present value
of costs, the project is not justified financially. The NPV method is the recommended
method of project appraisal, since it is consistent with the objective of maximising
shareholder wealth.
(ii) The internal rate of return (IRR) method. This method uses discounting arithmetic
to calculate the return expected from the project calculated on a discounted cash
flow basis.
This 'internal rate of return' for the project is then compared with the target rate of return.
The project is justified financially if the IRR of the project exceeds the target rate of return.
(iii) The discounted payback method. This method converts all the expected cash flows
from a project to a present value, and calculates how long it will take for the project
to payback the capital outlay on a discounted cash flow basis. It is similar to the non-
discounted payback method, except that it uses discounted cash flows.
4 Non-financial factors in a capital investment decision
Although capital investment decisions by commercial organisations are largely finance-driven,
non- financial factors can affect a decision. Non-financial factors include legal issues, ethical
issues, political and regulatory issues, quality issues and employee issues.
Chapter 2: Project Feasibility Studies
Page | 53
A decision maker should always bear in mind non-financial factors that affect a decision, and
you may be asked to identify these from a case described in your examination. Such 'non-
financial' factors may have indirect financial implications, at some time in the future.
Possible non-financial factors that could influence an investment decision include:
a) Legal issues. There may be a risk of legal action against the company as a result of its
investment.
b) Ethical issues. Unethical investments or actions by a company could be damaging to its
public reputation.
c) Government regulation. Investment decisions might be affected by the risk of government
regulation.
d) Political issues. A future change of government in the country concerned could affect the
future returns from an investment. Political uncertainty often has a deterrent effect on
investment decisions, persuading companies to defer their spending decisions until the
future is more certain.
e) Quality implications. Although financial objectives are important for commercial
investments, other strategic objectives may also be relevant. In particular, the perceived
quality of output produced by the company could be important for its relations with
customers. A profitable investment might therefore be turned down if there are quality
implications.
f) Personnel issues. Employees might be affected significantly by a capital investment decision,
and the impact on employee relations, motivation and working culture might need to be
considered.
5 The accounting rate of return (ARR) method
ARR = the accounting profits from the project, expressed as a percentage of the amount
invested. Typically, profit is the average annual profit and the amount invested is measured as
the average investment over the life of the project. A project would be undertaken if its
expected ARR exceeds the company's minimum required ARR. If there are two mutually
exclusive investments, the investment with the higher ARR would be chosen.
A capital investment project may be assessed using the accounting rate of return method of
appraisal. The expected accounting return on investment (ROI) or accounting rate of return
Chapter 2: Project Feasibility Studies
Page | 54
(ARR) for the project is calculated, and compared with a pre-determined minimum target
accounting rate of return. The project is justified financially if its expected ARR exceeds the
minimum target.
The accounting rate of return (ARR) measures the profitability of an investment by expressing
the expected accounting profits as a percentage of the book value of the investment. There are
several different possible formulae for its calculation.
The organisation must define ARR, and specify how it should be calculated, since various methods
are possible. A formula for calculating ARR that is common in practice is:
ARR = Estimated average profits
× 100% Estimated average investment
The average investment is the average of the investment at the start of the project and the
investment at the end of the project, allowing for depreciation of the non-current asset or assets.
For example, suppose that a capital investment will call for spending of $100,000 on a non-current
asset that will have a four year life and zero value at the end of this time, and for a working capital
investment of $20,000. The average investment would be $70,000 (half of $100,000 plus the
working capital investment of $20,000).
Another method of calculating ARR is for the figure below the line to be the total initial
investment, rather than the average investment over the life of the project.
ARR = Estimated average profits
× 100% Estimated total investment
A third method of calculating ARR is to have total expected profits above the line.
ARR = Estimated total profits
× 100% Estimated total investment
Profits are accounting profits, and are calculated after deducting a charge for depreciation of the
noncurrent asset(s).
Chapter 2: Project Feasibility Studies
Page | 55
5.1 Example: the accounting rate of return
A company has a target accounting rate of return of 20%. ARR is calculated as estimated average
annual profits over estimated average investment. The company is now considering the following
project.
Capital cost of asset $80,000
Estimated life 4
years
Estimated profit before depreciation
Year 1 $20,000
Year 2 $25,000
Year 3 $35,000
Year 4 $25,000
The capital asset would be depreciated by 25% of its cost each year, and will have no residual
value.
You are required to assess whether the project should be undertaken.
Solution
The annual profits after depreciation, and the mid-year net book value of the asset, would be as
follows.
Profit after Average ARR
Year depreciation investment
$ $
1 0
2 5,000
3 15,000
4 5,000
25,000
Average 6,250 40,000 15.625%
The project would not be undertaken because it would fail to yield the target return of 20%.
5.2 The ARR method and the comparison of mutually exclusive projects
The ARR method of capital investment appraisal can also be used to compare two or more
projects which are mutually exclusive. The project with the highest ARR would be selected,
provided that the expected ARR is higher than the company's target ARR.
Chapter 2: Project Feasibility Studies
Page | 56
Note how, in the question above as much weight was attached to cash inflows at Year 4 as to
those at Year 1, whereas the management of Bee would favour high cash inflows in the early
years. Early cash flows are less risky and they improve liquidity. For this reason, they might choose
machine X despite its lower ARR. One of the disadvantages of the ARR method is that it does not
take account of the timing of cash inflows and outflows.
5.3 The drawbacks to the ARR method of capital investment appraisal
The ARR method of capital investment appraisal has several major weaknesses.
It does not take account of the timing of the profits from an investment. For example, suppose
that investment A and investment B would both cost $1,000. Investment A would make a profit
of $100 in Years 1- 4 and a profit of $2,000 in Year 5. Investment B would make a profit of $2,000
in Year 1, and $100 in each of Years 2 - 5. If the two investments are compared by their ARR, both
would have exactly the same ARR.
It might be apparent, however, that investment B would be preferable because it provides most
of its expected returns earlier. Whenever capital is invested in a project, money is tied up until
the project begins to earn profits which pay back the investment. Money tied up in one project
cannot be invested anywhere else until the profits come in. Management should be aware of the
benefits of early repayments from an investment, which will provide the money for other
investments.
A second major weakness of investment decisions based on ARR is the lack of a clear decision
rule for deciding whether or not a project should be undertaken, based on its expected ARR. For
example, suppose an investment is expected to achieve an average accounting rate of return of,
say, 15% over the next five years. Does this suggest that the investment should be undertaken or
not? The company might set a target ARR that investments must achieve, so that if the target is,
say, 14%, a project expected to yield 15% would be undertaken. However, the choice of the ARR
target return would be subjective, lacking a rational basis. In contrast, decision methods based
on discounted cash flows (DCF), described in the next chapter, do have a rational basis for the
target rate of return. With DCF, the target return is based on the expected returns of investors in
the company, and investments are required to provide a return that is at least enough to meet
investor requirements. Accounting returns, however, are not the same as investment returns, and
a target investment return would be inappropriate for applying an ARR decision rule.
There are a number of other disadvantages with the ARR decision method.
Chapter 2: Project Feasibility Studies
Page | 57
(a) It is based on accounting profits and not cash flows. Accounting profits are subject to a
number of different possible accounting treatments.
(b) It is a relative measure rather than an absolute measure and hence takes no account of the
size of the investment.
(c) It takes no account of the length of the project.
(d) It ignores the time value of money. With the ARR method, $1 receivable in five years' time
has exactly the same value as $1 spent now. Money 'now' is actually worth more than the
same amount of money at a future date, because the money 'now' can be invested to earn
a return, whereas future money can't be invested until it is received.
There are, however, advantages to the ARR method. It is a quick and simple calculation, it involves
a familiar concept of a percentage return and it looks at the entire project life.
6 The payback method
Payback = the time required for the cash inflows from a project to recoup the cash outlays. A
project would be undertaken if its expected payback is sooner than the maximum tolerated. If
there are two mutually exclusive investments, the investment with the earlier payback would be
chosen.
The payback period is the length of time required before the total of the cash inflows received
from a project is equal to the cash outflows, and is usually expressed in years. In other words, it
is the length of time the investment takes to pay itself back.
When deciding between two or more competing projects, the usual decision is to accept the one
with the shortest payback. In the previous question (in Paragraph 6.2), machine X pays for itself
after two years and machine Y after three years. Using the payback method of investment
appraisal, machine X is preferable to machine Y.
Payback is often used as a 'first screening method'. By this, we mean that when a capital
investment project is being considered, the first question to ask is: 'How long will it take to pay
back its cost?' The organisation might have a target payback, and so it would reject any capital
project unless its payback period were less than a certain number of years.
However, a project should not be evaluated on the basis of payback alone. Payback should be a
first screening process, and if a project gets through the payback test, it ought then to be
Chapter 2: Project Feasibility Studies
Page | 58
evaluated with a more sophisticated investment appraisal technique. You should note that when
payback is calculated, we take profits before depreciation, because we are trying to estimate the
cash returns from a project and profit before depreciation is likely to be a rough approximation
of cash flows.
6.1 Example
A company is considering an investment in a project to acquire new equipment costing $80,000.
The equipment would have a five-year life and no residual value at the end of that time. The
straight-line method of depreciation is used. The expected profits after depreciation from
investing in the equipment are as follows.
Year Profit
$
1 15,000
2 15,000
3 16,000
4 24,000
5 20,000
What is the payback period for the investment?
The payback period is calculated from the cumulative annual profits before depreciation. Annual
depreciation is $16,000, and the profit before depreciation each year is found simply by adding
$16,000 the annual profit estimate.
Year
Investment
Profit before
depreciation
Cumulative profit before
depreciation
$ $ $
0 (80,000) (80,000)
1 31,000 (49,000)
2 31,000 (18,000)
3 32,000 14,000
4 40,000 54,000
5 36,000 90,000
Payback occurs when the cumulative profits stop being negative and start to be positive. This will
happen sometime during year 3. If it is assumed that profits each year arise at an even rate
throughout the course of the year, the payback period can be calculated in years and months.
Chapter 2: Project Feasibility Studies
Page | 59
Payback = Y years + [ B
x 12 months ] B + E
Where
Y = the number of complete years before payback. This is the year before the one in which
payback occurs.
B = the cumulative profits before depreciation at the beginning of the payback year, ignoring
the negative value.
E = the cumulative profits before depreciation at the end of the payback year.
In this example:
Payback = 2 years + [ 18,000
x 12 months ] (18,000 + 14,000)
= 2 years 7 months (to the nearest month).
6.2 Disadvantages of the payback method
There are a number of serious drawbacks to the payback method.
(a) The choice of a maximum payback period for an investment is arbitrary and subjective. For
example, if a company establishes a rule that projects will not be undertaken unless they pay
back within four years, where has the choice of a four year cut-off period come from?
(b) It ignores all cash flows after the end of the payback period, and so is not concerned with
the total expected returns from the investment. For example, suppose that the maximum
payback period that a company selects for its investments is four years, and it is considering
two mutually exclusive projects, X and Y, each costing $80,000. Project X would be expected
to make total profits of $100,000 and pay back within two years. Project Y would be expected
to make total profits of $500,000, but only pay back after five years. On the basis of payback
alone, project X would be preferred, despite its lower total profitability.
(c) If the objective of a company is to maximise the wealth of its shareholders, it would be wrong
to ignore the future profits from an investment after an arbitrary cut-off date for payback.
Using a payback cut-off limit is inconsistent with shareholder wealth maximisation.
Chapter 2: Project Feasibility Studies
Page | 60
(d) The payback method ignores the timing of cash flows within the payback period and the
time value of money (a concept incorporated into DCF appraisal methods). This means that
it does not take account of the fact that $1 today is worth more than $1 in one year's time.
Other disadvantages of the payback method are that:
(a) The method is unable to distinguish between projects with the same payback period.
(b) It may lead to excessive investment in short-term projects.
6.3 Advantages of the payback method
In spite of its limitations, the payback method continues to be popular, and the following points
can be made in its favour.
(a) It is simple to calculate and simple to understand, and this may be important when
management resources are limited. It is similarly helpful in communicating information
about minimum requirements to managers responsible for submitting projects.
(b) It can be used as a screening device as a first stage in eliminating obviously inappropriate
projects prior to more detailed evaluation.
(c) The fact that it tends to bias in favour of short-term projects means that it tends to minimise
uncertainty about both financial and business risk.
It can be used when there is a capital rationing situation to identify those projects which generate
additional cash for investment quickly.
7 The payback and ARR methods in practice
The ARR method fails to give any consideration to the timing of cash flows over the life of a
project, and is based on accounting profits, not cash flows. The payback method ignores the total
amount of returns from a project over its life. Both methods therefore have serious weaknesses,
and should not be used in isolation.
Despite the severe theoretical limitations of the payback method, it is widely used in practice.
There are a number of reasons for this.
(a) It is a particularly useful approach for ranking projects where a firm faces liquidity constraints
and requires a fast repayment of investments.
Chapter 2: Project Feasibility Studies
Page | 61
(b) It is appropriate in situations where risky investments are made in uncertain markets that are
subject to fast design and product changes or where future cash flows are particularly
difficult to predict.
(c) Most managers see risk as time-related: the longer the period, the greater the chance of
failure. The payback method, by concentrating on the early cash flows, therefore uses data
in which they have confidence. The justification for this is that cash flows tend to be
correlated over time and hence if cash flows are below the expected level in early years, this
pattern will often continue.
(d) The method is often used in conjunction with the NPV or IRR method and acts as a first
screening device to identify projects which are worthy of further investigation.
(e) It is easily understood by all levels of management.
(f) It provides an important summary method: how quickly will the initial investment be
recouped?
The ARR method is an unsatisfactory appraisal method, but remains popular despite its
drawbacks mentioned above. Its popularity is probably due to the fact that, compared to DCF
appraisal methods, it is more easily understood and calculated.
Although the ARR and payback methods are used in practice, they have no rational justification,
and they provide only subjective rules for making investment decisions. Since the objective of a
company should be to maximise shareholder wealth through investments, using a subjective
basis for making investment decisions is inadequate. A rational approach to investment decision-
making is provided by discounted cash flow methods of investment appraisal. These are
described in the next chapter.
8 Investment appraisal and cash flows
With the exception of the ARR method, all methods of project appraisal focus on the expected
cash flows of the project, not accounting profits. The cash flows to take into consideration are
the relevant cash flows of the project. Relevant cash flows are future cash flows arising as a
direct consequence of the investment. These may be extra revenues, extra costs, and savings in
costs or reductions in revenue.
Chapter 2: Project Feasibility Studies
Page | 62
The ARR method of project appraisal is based on accounting returns, with profits measured as
profits after deducting depreciation. In contrast, the payback method of appraisal considers cash
flows only.
An investment is the outlay of money with the expectation of getting more money back. When
evaluating an investment, it is more appropriate to consider cash flows – money spent and
received – rather than accounting profits. Accounting profits do not properly reflect investment
returns, and this is a major weakness of the ARR method of project appraisal.
Cash flows represent the economic reality of investment and returns. An investment involves the
outlay of money, in the expectation of getting more money back over the term of the investment.
A company might pay out a sum of money to invest in a new business operation with an expected
commercial life of several years. Over that period, it will expect to incur running costs to run the
business, and to receive cash from sales. The returns on the investment will be the net cash inflows
from the business operation.
In the same way, a shareholder’s investment involves paying out cash to buy shares, and the
returns are obtained in the form of dividends and the cash received from the eventual disposal
of the shares.
Accounting profits are based on the accruals concept of accounting, and do not represent the
reality of a company as a portfolio of many different investments. Instead of reporting the cash
outlay on an investment, an income statement reports a depreciation charge on capital
equipment over the economic life of the asset. Depreciation is a notional accounting charge, and
does not represent a cash flow.
Thus cash flows and not accounting profits should be used for investment appraisal and decision-
making.
8.1 Cash flows and profits compared
The cash flows involved in an investment should be measured as the relevant costs of the
investment, as explained below. However, it is useful to remember the differences between
operational cash flows and operating profit.
$
Operating profit (accounting profit) 125,000
Add back depreciation 60,000
185,000
Chapter 2: Project Feasibility Studies
Page | 63
Subtract the increase in working capital (15,000)
Net cash flow from operations 17,000
In the example above, there are two reasons why cash flows differ from the accounting profit.
(a) Depreciation is not a cash flow item, and to work out the actual cash flow depreciation has
to be added back to the accounting profit.
(b) Profit also differs from cash flow by the amount of the change in working capital in the
period. Working capital means the investment in inventories and trade receivables, less any
investment in trade payables. If there has been an increase in working capital due to larger
inventories or more receivables, cash flow will be lower than profit. If working capital has
been reduced in the period, e.g. by running down inventories, or extending credit taken
from creditors, cash flow will exceed profit.
8.2 Example
A company invests $50,000 in a new item of equipment that has an expected life of five years and
no residual value. Depreciation is charged by the straight-line method. The equipment is used to
make a new product, and sales in Year 1 produce profits of $14,000. An additional investment in
working capital of $3,000 is needed in Year 1.
The cash flows at the start of this project are as follows.
(a) Immediate outlay at the start of the first year: $50,000 on equipment.
(b) The cash profits for the first year, measured as operating profit plus depreciation added
back, is $14,000 + $10,000 depreciation = $24,000.
(c) Actual operational cash flows will not be $24,000 in Year 1, however, because of the
increase in working capital. Some of the increase in profit is ‘invested’ in inventories and
receivables. The actual cash flow is $3,000 lower.
(d) However, it is generally assumed, in investment appraisal, that an investment in working
capital occurs at the start of the year, and it is therefore treated as an initial investment
rather than, in this example, as a cash flow in Year 1.
If the start of Year 1 is called Year 0 (i.e. the end of the current year), the cash flows in this example
would be:
Chapter 2: Project Feasibility Studies
Page | 64
Year Item $
0 Purchase of equipment (50,000)
0 Additional working capital (3,000)
0 Total cash flow (53,000)
1 Cash profits 24,000
8.3 Cash flows and relevant costs
Business decisions should be based on the expected cash flows arising as a consequence of the
decision. The cash flows arising as a direct consequence of a decision are known as 'relevant
costs'.
The relevant cash flows for appraisal of a project are the changes in future cash flows that
would arise from acceptance of the project.
(a) Relevant costs are future costs. A decision is about the future; it cannot alter what has
been done already. A cost that has been incurred in the past is totally irrelevant to any
decision that is being made 'now'. Costs that have been incurred include not only costs
that have already been paid, but also costs that are the subject of legally binding contracts,
even if payments due under the contract have not yet been made. (These are known as
committed costs.)
(b) Relevant costs are cash flows.
(i) The assumption used in relevant costing is that, in the end, profits earn cash. Accounting
profits and cash flow are not the same in any period for various reasons, such as the timing
differences caused by giving credit and the accounting treatment of depreciation. In the
long run, however, a profit that is earned will eventually produce a net inflow of an equal
amount of cash. Hence when decision making we look at cash flow as a means of
measuring profits.
(ii) Only cash flow information is required. This means that costs or charges which do not
reflect additional cash spending should be ignored for the purpose of decision making.
These include depreciation charges.
(c) Relevant costs are incremental costs. A relevant cost is one which arises as a direct
consequence of a decision. Thus, only costs which will differ under some or all of the
available opportunities should be considered; relevant costs are therefore sometimes
Chapter 2: Project Feasibility Studies
Page | 65
referred to as incremental costs. For example, if an employee is expected to have no other
work to do during the next week, but will be paid his basic wage (of, say, $200 per week)
for attending work and doing nothing, his manager might decide to give him a job which
earns only $140. The net gain is $140 and the $200 is irrelevant to the decision because
although it is a future cash flow, it will be incurred anyway whether the employee is given
work or not.
Relevant costs are therefore future, incremental cash flows.
8.4 Non-relevant costs
A number of terms are used to describe costs that are irrelevant for decision making because
they are either not future cash flows or they are costs which will be incurred anyway, regardless
of the decision that is taken.
A sunk cost is a cost which has already been incurred and hence should not be taken account of
in decision making.
(a) A principle underlying decision making is that 'bygones are bygones'. In other words, what
has happened in the past is done, and cannot be undone. Management decisions can only
affect the future. In decision making, managers therefore require information about future
costs and revenues which would be affected by the decision under review, and they must
not be misled by events, costs and revenues in the past, about which they can do nothing.
A committed cost is a future cash outflow that will be incurred anyway, whatever decision is
taken now about alternative opportunities.
(b) Committed costs may exist because of contracts already entered into by the organisation
that it cannot get out of.
8.5 Working capital
You will be familiar with the concept of relevant costs already if you have studied the Performance
Management syllabus. The same principles of relevant cash flows apply to long-term investment
decisions as to short-term decision-making. However, there are some extra ‘rules’ to remember
about the timing of cash flows for long-term investment projects.
(a) A cash outlay incurred at the beginning of an investment project ('now') occurs in Year 0.
Chapter 2: Project Feasibility Studies
Page | 66
(b) Cash flows that occur evenly over the course of a year are assumed to occur all at once
at the end of the year. Receipts of $10,000 during Year 1 are therefore taken to occur at
the end of Year 1.
(c) A cash flow that occurs at the beginning of a year is taken to occur at the end of the
previous year. Therefore a cash outlay of $5,000 at the beginning of Year 2 is taken to occur
at the end of Year 1.
(d) An increase in working capital during a year should normally be treated as occurring at
the start of the year, and so is a cash outlay at the start of the year/end of the previous
year.
(e) A decrease in working capital during a year should also normally be treated as occurring
at the start of the year. However, there is an important exception to this general rule. At
the end of a project, any remaining investment in working capital is no longer required,
and working capital will therefore be reduced to zero. This reduction in working capital to
zero is treated as a cash inflow occurring at the end of the last year of the project.
8.6 Example
Bat has spent $2 million developing a new product and a further $800,000 on market research to
find out whether a market launch would be worth undertaking. The findings of the market
research were as follows.
(a) To launch the product on the market, the company would have to spend a further $800,000
on equipment. This would be depreciated over three years by the straight-line method,
and would have an estimated resale value of $200,000 at the end of this time.
(b) The product would have a life of just three years, and profits after depreciation would be
$500,000 in the first year, $600,000 in the second year and $300,000 in the third year.
(c) There would be an initial investment of $120,000 in working capital in the first year and a
further $140,000 of working capital would be needed in Year 2.
(d) Instead of investing in the product launch, the company could sell the rights to the product
to another company for $500,000.
What are the estimated cash flows from this project?
Chapter 2: Project Feasibility Studies
Page | 67
The annual depreciation charge would be $200,000. [($800,000 - $200,000)/3 years]. This should
be added back to the annual profit after depreciation, to get the cash profit for each year. The
resale value of the equipment is a cash inflow at the end of the project.
Costs already incurred are sunk costs and so irrelevant to the current investment decision. The
sunk costs in this example are the development costs of $2 million and the market research cost
of $800,000.
A decision to go ahead with the product launch will involve not just the cost of the equipment
and the working capital investment. There would also be an opportunity cost by choosing not to
sell the product rights.
Study the following cash flows carefully, and make sure that you understand how they have been
derived.
Year 0 Year 1 Year 2 Year 3
$000 $000 $000 $000
Equipment (800) 200
Sale opportunity forgone (500) (140) 260
Working capital (120)
Cash profits 700 800 500
Total cash flow (1,420) 560 800 960
9 The time value of money
DCF appraisal methods allow for the time value of money. $1 today is worth more than $1 at a
future time, because money can be reinvested to earn more money over time.
The time value of money describes the concept that the earlier cash is received, the greater
value it has to the recipient. Conversely, the later a cash payment is made, the less the cost to the
payer.
Investors put money into shares in the expectation of getting back, over time, an amount in
excess of their original investment. The idea of investing cash to make more money should be a
familiar concept to you.
Chapter 2: Project Feasibility Studies
Page | 68
If you put money into a deposit account, you will expect to get your money back with interest. If
the interest is not high enough, you will look somewhere else to invest.
In the same way, an investor buying shares expects a return in the form of dividends plus the
eventual disposal price of the shares when he decides to sell them. If the expected returns are
not high enough to justify the purchase price of the shares, he will not buy the shares, but put
his money into another investment instead.
The same principle applies to investments by companies. The cash returns from long-term
investments should be sufficient to provide an adequate return; otherwise, the investment should
not be undertaken.
The required return on an investment consists of three elements, for any investor:
(a) An opportunity cost. This is the return that could be obtained by investing in something
else. In financial management, the opportunity cost of an investment is usually expressed
in terms of the return that could be obtained by putting money into a risk-free (and
inflation-proof) investment.
(b) An amount to cover inflation. Inflation erodes the value of money over time, and an
investor will expect the return on investment to cover the effect of inflation as well as to
provide a ‘real’ return.
(c) An amount to reward the investor for the risk in the investment. Higher returns are
expected from investments with a higher risk element.
An investment return is expressed as a percentage of the amount invested for each year of
investment, in other words as a percentage amount each year. The longer the investment, the
greater the required return. This too should be a familiar idea to you. If you put cash into a deposit
account, you will expect to earn interest, and the longer you keep the money on deposit, the
more interest you will expect to earn.
We must therefore recognise that if a capital investment is to be worthwhile, it must earn at least
a minimum profit or return so that the size of the return will compensate the investor (the
business) for the length of time which the investor must wait before the profits are made. For
example, if a company could invest $60,000 now to earn revenue of $63,000 in one week's time,
a profit of $3,000 in seven days would be a very good return. If it takes three years to earn the
revenue, however, the return would be very low.
Chapter 2: Project Feasibility Studies
Page | 69
When capital expenditure projects are evaluated, it is therefore appropriate to decide whether
the investment will make enough profits to allow for the 'time value' of capital tied up. The time
value of money reflects people's time preference for $1 now over $1 at some time in the future.
DCF is an evaluation technique which takes into account the time value of money.
10 Discounted cash flow
In DCF, expected future cash flows (inflows and outflows) are converted into a present value
equivalent amount. The present value of a future cash flow is the amount that would have to be
invested now at the organisation's cost of capital to earn the future cash flow at the future time.
Discounted cash flow, or DCF for short, is an investment appraisal technique which takes into
account both the timings of cash flows and also total profitability over a project's life.
Two important points about DCF are as follows.
(a) DCF looks at the cash flows of a project, not the accounting profits. Cash flows are
considered because they show the costs and benefits of a project when they actually occur.
For example, the capital cost of a project will be the original cash outlay, and not the
notional cost of depreciation which is used to spread the capital cost over the asset's life
in the financial accounts.
(b) The timing of cash flows is taken into account by discounting them. The effect of
discounting is to give a bigger value per $1 for cash flows that occur earlier: $1 earned
after one year will be worth more than $1 earned after two years, which in turn will be
worth more than $1 earned after five years, and so on.
10.1 Compounding and discounting
Suppose that a company has $10,000 to invest, and wants to earn a return of 10% (compound
interest) on its investments. This means that if the $10,000 could be invested at 10%, the value of
the investment with interest would build up as follows.
(a) After 1 year $10,000 × (1.10) = $11,000
(b) After 2 years $10,000 × (1.10)2 = $12,100
(c) After 3 years $10,000 × (1.10)3 = $13,310 and so on.
Chapter 2: Project Feasibility Studies
Page | 70
This is compounding. The formula for the future value of an investment plus accumulated
interest after n time periods is: FV = PV (1 + r)n
where FV is the future value of the investment with interest
PV is the initial or 'present' value of the investment
r is the compound rate of return per time period, expressed as a proportion (so 10% =
0.10, 5% = 0.05 and so on)
n is the number of time periods.
Discounting starts with the future amount of a cash flow and converts it into a present value. A
present value is the amount that would need to be invested now to earn the future cash flow, if
the money is invested at the 'cost of capital'. For example, if a company expects to earn a
(compound) rate of return of 10% on its investments, how much would it need to invest now to
have the following investments?
(a) $11,000 after 1 year
(b) $12,100 after 2 years
(c) $13,310 after 3 years
The answer is $10,000 in each case, and we can calculate it by discounting. The discounting
formula to calculate the present value of a future sum of money at the end of n time periods is:
Discounting can be applied to both money receivable and also to money payable at a future date.
By discounting all payments and receipts from a capital investment to a present value, they can
be compared on a common basis at a value which takes account of when the various cash flows
will take place.
Chapter 2: Project Feasibility Studies
Page | 71
Present value can be defined as the cash equivalent 'now' of a future sum of money receivable
or payable at a future date, assuming that money 'now' can be invested at a given rate of return
(known as the 'cost of capital'). A present value is calculated by discounting the future cash flow
to its present value equivalent amount.
10.2 Discount factors
To make it easier to discount future cash flows to a present value, discount factor tables are
available.
These tables give the value of [1/(1+r)n ] for any cost of capital (value of r) and any future year
(any value of n). In your examination, you will be given any discount factors that you might need
to use to make a DCF appraisal. You will find the relevant tables at the back of this book.
Any cash flows that take place 'now', at the start of a project, take place in Year 0. The discount
factor for Year 0 is 1.0. This means simply that cash flows occurring 'now' do not need to be
discounted to convert them to a present value equivalent, because they are already at present
value.
10.3 The cost of capital
The cost of capital used in DCF is the cost of funds that a company raises and uses, and the
return that investors expect to be paid for putting funds into the company. It is therefore the
minimum return that a company should make from its own investments, to earn the cash flows
out of which investors can be paid their return. The cost of capital can therefore be measured by
studying the returns required by investors, and used to derive a discount rate for DCF analysis
and investment appraisal.
Calculating the cost of capital for a company is explained in a later chapter. For the time being,
the 'cost of capital' is assumed to be a known figure.
11 The net present value method of project appraisal
With the NPV method of project appraisal, all expected cash inflows and all expected cash
outflows from the project are discounted to a present value at the organisation's cost of capital.
The net present value is the difference between the present value of total benefits and the present
value of total costs. If the PV of benefits exceeds the PV of total costs, the NPV is positive, and the
Chapter 2: Project Feasibility Studies
Page | 72
project is expected to earn a return in excess of the organisation's cost of capital. If the PV of
benefits is less than the PV of total costs, the NPV is negative, and the project will earn a return
that is lower than the organisation's cost of capital. Projects with a positive NPV are financially
viable, but projects with a negative NPV are not.
Net present value or NPV is the value obtained by discounting all cash outflows and inflows of
a capital investment project by a chosen target rate of return or cost of capital. The sum of the
present value of all expected benefits from the project and the present value of all expected cash
outlays is the 'net' present value amount.
The NPV method compares the present value of all the cash inflows from an investment with the
present value of all the cash outflows from an investment. The NPV is thus calculated as the PV
of cash inflows minus the PV of cash outflows.
a) If the NPV is positive, it means that the cash inflows from a capital investment will yield a
return in excess of the cost of capital, and so the project should be undertaken if the cost of
capital is the organisation's target rate of return.
b) If the NPV is negative, it means that the cash inflows from a capital investment will yield a
return below the cost of capital, and so the project should not be undertaken if the cost of
capital is the organisation's target rate of return.
c) If the NPV is exactly zero, the cash inflows from a capital investment will yield a return
which is exactly the same as the cost of capital, and so if the cost of capital is the
organisation's target rate of return, the organisation will be indifferent about whether it
undertakes the project or not.
11.1 Example: NPV
Slogger is considering a capital investment, where the estimated cash flows are as follows.
Year Cash flow
$
0 (100,000)
1 60,000
2 80,000
3 40,000
4 30,000
The company's cost of capital is 15%. You are required to calculate the NPV of the project and to
assess whether it should be undertaken.
Chapter 2: Project Feasibility Studies
Page | 73
The following discount factors might be relevant.
Year Discount factor at
15%
1 0.870
2 0.756
3 0.658
4 0.572
5 0.497
6 0.432
Solution
Year Cash flow Discount factor at 15% Present value
$ $
0 (100,000) 1.000 (100,000)
1 60,000 0.870 52,200
2 80,000 0.756 60,480
3 40,000 0.658 26,320
4 30,000 0.572 17,160
Net present value 56,160
The PV of cash inflows exceeds the PV of cash outflows by $56,160, which means that the project
will earn a DCF yield in excess of 15%. It should therefore be undertaken.
11.2 Annuity discount factor tables
An annuity is a constant annual cash flow, for a number of years. An example of an annuity would
be, say, cash receipts of $50,000 a year for six years, Years 1 – 6. To save time with calculating the
present value of all the individual annual cash flows of an annuity, tables are available for the
cumulative discount factors. Annuity tables give the total of all the discount factors for each year
in Year 1 to Year n, for a given cost of capital r.
For example, the annuity factor for a cost of capital of 12% for Years 1 – 3 is 2.402. This is simply
the sum of the discount factors for Year 1, 2 and 3.
Year Discount factor at 12%
1 0.893
2 0.797
3 0.712
1 - 3 2.402 = Annuity factor at 12%, Years 1 - 3
Chapter 2: Project Feasibility Studies
Page | 74
If the amount of the annual cash flow for Years 1 – 3 is, say, $10,000 per annum, and the cost of
capital is 12%, it is quicker to calculate the present value of these cash flows in one calculation
($10,000 × 2.402 = $24,020) instead of having to calculate the present value for the cash flow in
each individual year and then add up the total.
These total discount factors could be described as 'same cash flow per annum' factors, or
'cumulative present value' factors, but the term 'annuity' factors is commonly used.
11.3 Example: NPV including use of annuity tables
IMC is considering the manufacture of a new product which would involve the use of both a new
machine (costing $150,000) and an existing machine, which cost $80,000 two years ago but has
no resale value. There is sufficient capacity on this machine, which has so far been under-utilised.
Annual profits before depreciation would be $40,000.
The project would have a five-year life, after which the new machine would have a net residual
value of $5,000.
Working capital requirements would be $10,000 in the first year, rising to $15,000 in the second
year and remaining at this level until the end of the project, when it will all be recovered. The
company's cost of capital is 10%.
You are required to assess whether the project is worthwhile.
Year Discount factor at 10%
1 0.909
2 0.826
3 0.751
4 0.683
5 0.621
1 - 5 3.791
Solution
The project requires $10,000 of working capital at the end of Year 1 and a further $5,000 at the
start of Year 2. Increases in working capital reduce the net cash flow for the period to which they
relate. When the working capital tied up in the project is 'recovered' at the end of the project, it
will provide an extra cash inflow (for example receivables will eventually be received in cash).
Chapter 2: Project Feasibility Studies
Page | 75
The historic cost of the current machine is not a relevant cost and must be ignored in the
appraisal.
The NPV is calculated as follows.
Net Discount PV of net
Year Equipment Working
capital Contribution cash flow factor cash flow
$ $ $ $ 10% $
0 (150,000) (10,000) (160,000) 1.000 (160,000)
1 (5,000) (5,000) 0.909 (4,545)
1-5 40,000 40,000 3.791 151,640
5 5,000 15,000 20,000 0.621 12,420
NPV = (485)
The NPV is negative (although not by much) and the project is therefore not recommended for
acceptance, because it fails to earn a return of 10%.
11.4 Perpetuities
A perpetuity is a constant annual cash flow that continues indefinitely (a perpetual annuity).
The present value of a perpetuity is given by:
NPV = Annual cash flow
r
where r is the discount rate, expressed as a decimal.
Thus the present value of $400 to be received annually, for ever, if the cost of capital is 8% pa, is:
PV (T1–00) $400 = 400/0.08 = $5,000
Notice that the value of the perpetuity is finite because the cash flows that arise far into the future
will have very low present values.
11.5 Strengths and weaknesses of the NPV method
The NPV method is the most valid of all the capital project appraisal methods.
(a) It recognises the time value of money, and evaluates cash flows, not accounting profits.
Chapter 2: Project Feasibility Studies
Page | 76
(b) When the cost of capital used in the appraisal is the organisation's cost of finance, a project
with a positive NPV should add to the overall value of the organisation, and (in the
case of a company) increase shareholder wealth.
The connection between NPV and creating shareholder wealth is very important, and is explained
in more detail later.
Although it is the most appropriate method of project appraisal, the NPV method does have a
drawback.
The net present value of a project is a money value. This is often difficult to understand. For
example, it is easier to understand the comment: 'Project A will earn a return of 15% per annum'
than it is to understand the comment 'Project A has an NPV of + $60,000 at a cost of capital of
10%'.
12 Discounted payback
The NPV method calculates a value for a capital project, taking into account all the expected cash
flows over the entire life of the project. A company might want capital projects to earn a positive
NPV, but also to pay back within a maximum time period. The discounted payback method is a
way of combining DCF evaluation with a minimum payback period.
The discounted payback method of project appraisal is similar to the non-discounted payback
method, except that payback is measured with the present value of cash flows.
A company might have an investment policy of undertaking projects only if:
(a) They have a positive NPV, and
(b) They pay back, in NPV terms, within a maximum time limit.
12.1 Example: discounted payback
TJ is considering two mutually-exclusive investments, Project A and Project B. It can undertake
one of them, or neither, but it cannot undertake both.
Project A would involve expenditure on a non-current asset of $60,000 and a working capital
investment of $5,000. The profits from the project, ignoring depreciation, would be:
Year Cash profit
Chapter 2: Project Feasibility Studies
Page | 77
$
1 15,000
2 20,000
3 20,000
4 25,000
5 20,000
6 15,000
7 10,000
Project B would involve expenditure on a non-current asset of $50,000 and a working capital
investment of $5,000. The profits from the project, ignoring depreciation, would be:
Year Cash profit
$
1 20,000
2 30,000
3 20,000
4 10,000
5 5,000
6 2,000
In both cases, the non-current asset would have nil residual value at the end of the project's life.
The company's cost of capital is 11%, and the discount factors are:
Year Discount factor at
11%
1 0.901
2 0.812
3 0.731
4 0.659
5 0.593
6 0.535
7 0.482
It is company policy to require projects to pay back in discounted cash flow terms within four
years.
Which project, if either, should be undertaken?
Solution
The NPV and discounted payback period for each project are calculated as follows.
Project A
Chapter 2: Project Feasibility Studies
Page | 78
Project A has the higher NPV, but does not pay back until after 4 years 4 months, which is longer
than the minimum acceptable payback period. Project B has a lower NPV but pays back within
three years, which is less than the maximum acceptable. On the basis of the investment criteria
used by this company, Project B would be undertaken.
12.2 Strengths and weaknesses of the discounted payback method
The discounted payback method of project evaluation is similar to the normal payback method,
except that it allows for the time value of money.
(a) It establishes a requirement for projects to pay back within a maximum time period,
although the maximum discounted payback is a subjective measure, for which there may
be no rational justification.
(b) It gives recognition to the fact that for many companies liquidity is important, and projects
need to provide returns fairly quickly.
(c) Unlike the non-discounted method of appraisal, it will not recommend any project for
investment unless its NPV is expected to be positive.
Chapter 2: Project Feasibility Studies
Page | 79
The main disadvantage of the discounted payback method is that, as with the non-discounted
payback method, it ignores all cash flows after payback has been reached. It does not take into
consideration all the expected cash flows from the project. In the example above, for example,
Project B is preferred even though the expected NPV from Project A is higher. By ignoring total
returns from a project, its use is not consistent with the objective of maximising shareholder
wealth.
13 The internal rate of return method of project appraisal
With the IRR method of project appraisal, the internal rate of return of the project is calculated.
This is the cost of capital at which the NPV of the project would be zero, and so is the discount
rate of return that the project is expected to earn. A project is financially viable if its IRR exceeds
the company's target rate of return (its cost of capital).
The internal rate of return (IRR) of a project is the discount rate at which the project NPV is
zero. For a 'conventional' project – initial outflow followed by net inflows – this represents the
maximum rate of return the project is able to cover before the NPV turns negative.
Using the NPV method of discounted cash flow, present values are calculated by discounting at
a target rate of return, or cost of capital, and the difference between the PV of costs and the PV
of benefits is the NPV. In contrast, the internal rate of return (IRR) method is to calculate the
exact DCF rate of return which the project is expected to achieve, in other words the rate at which
the NPV is zero.
The rule with the internal rate of return (IRR) method of project evaluation is that a project
should be undertaken if it is expected to achieve a return in excess of the company’s weighted
average cost of capital. A project that has an IRR in excess of the cost of capital must have a
positive NPV.
13.1 Estimating the IRR
Without a computer or calculator program, the calculation of the internal rate of return is made
using a hit-and-miss technique known as the interpolation method. The interpolation method
produces an estimate of the IRR, although it is not arithmetically exact.
Chapter 2: Project Feasibility Studies
Page | 80
The first step is to calculate two net present values, both as close as possible to zero, using rates
for the cost of capital which are whole numbers. Ideally, one NPV should be positive and the
other negative, although this is not essential.
Choosing rates for the cost of capital which will give an NPV close to zero (that is, rates which are
close to the actual rate of return) is a hit-and-miss exercise, and several attempts may be needed
to find satisfactory rates.
13.2 Example: the IRR method
A company is trying to decide whether to buy a machine for $80,000 which will save costs of
$20,000 per annum for five years and which will have a resale value of $10,000 at the end of Year
5. If it is the company's policy to undertake projects only if they are expected to yield a DCF return
of 10% or more, ascertain whether this project should be undertaken.
Use the following discount factors to estimate the IRR of the project.
Year Discount factor at 9% Discount factor at 12%
1 - 5 3.890 3.605
5 0.650 0.567
Solution
The IRR is the rate for the cost of capital at which the NPV = 0.
This is fairly close to zero. It is also positive, which means that the IRR is more than 9%. We can
use 9% as one of our two NPVs close to zero, although for greater accuracy, we should try 10%
or even 11% to find an NPV even closer to zero if we can. However, a discount rate of 12% will
be used here, to see what the NPV is.
Chapter 2: Project Feasibility Studies
Page | 81
This is fairly close to zero and negative. The IRR is therefore greater than 9% (positive NPV of
$4,300) but less than 12% (negative NPV of $2,230).
If we were to draw a graph of the NPV at different costs of capital of a 'typical' capital project,
with a negative cash flow at the start of the project, and positive net cash flows afterwards up to
the end of the project, it would look like Figure 1.
If we use a cost of capital where the NPV is slightly positive, and use another cost of capital where
it is slightly negative, we can estimate the IRR - where the NPV is zero - by drawing a straight line
between the two points on the graph that we have calculated.
Figure 1
Chapter 2: Project Feasibility Studies
Page | 82
Study the diagram above carefully.
(a) If we establish the NPVs at the two points P, we would estimate the IRR to be at point A.
(b) If we establish the NPVs at the two points Q, we would estimate the IRR to be at point B.
The closer our NPVs are to zero, the closer our estimate will be to the true IRR.
We shall now use the two NPV values calculated earlier to estimate the IRR. The interpolation
method assumes that the NPV rises in linear fashion between the two NPVs close to 0. The real
rate of return is therefore assumed to be on a straight line between NPV = $4,300 at 9% and NPV
= –$2,230 at 12%.
The formula to apply is as follows.
where A is the lower rate of return
B is the higher rate of return
NA is the NPV discounted at A NB is the NPV discounted at B
Let us go back to our example.
If it is company policy to undertake investments which are expected to yield 10% or more, this
project would be undertaken.
Chapter 2: Project Feasibility Studies
Page | 83
14 NPV and IRR compared
14.1 Advantages of IRR method
The main advantage of the IRR method is that the information it provides is more easily
understood by managers, especially non-financial managers. For example, it is fairly easy to
understand the meaning of the following statement.
'The project will be expected to have an initial capital outlay of $100,000, and to earn a yield of
25%. This is in excess of the target yield of 15% for investments.'
It is not so easy to understand the meaning of this statement.
'The project will cost $100,000 and have an NPV of $30,000 when discounted at the minimum
required rate of 15%.'
14.2 Disadvantages of IRR method
A major weakness of the IRR method is its failure to take account of the total value of a capital
project (the project's NPV). When there are mutually exclusive investments, the IRR method might
favour a project with a higher IRR but a lower NPV. In this case NPV should be used.
It might be tempting to confuse IRR and accounting return on capital employed (ROCE). The
accounting ROCE and the IRR are two completely different measures. If managers were given
information about both ROCE (or ARR) and IRR, it might be easy to get their relative meaning
and significance mixed up.
The IRR method ignores the relative size of investments. Both the following projects have an IRR
of 18%.
Project A Project B
$ $
Cost, year 0 350,000 35,000
Annual savings, years 1-6 100,000 10,000
Clearly, project A is bigger (ten times as big) and so more 'profitable' but if the only information
on which the projects were judged were to be their IRR of 18%, project B would be made to seem
just as beneficial as project A, which is not the case.
Chapter 2: Project Feasibility Studies
Page | 84
14.3 Mutually exclusive projects
Mutually exclusive projects are two or more projects from which only one can be chosen.
Examples include the choice of a factory location or the choice of just one of a number of
machines. The IRR and NPV methods can, however, give conflicting rankings as to which project
should be given priority. Let us suppose that a company is considering two mutually exclusive
options, option A and option B. The cash flows for each would be as follows.
The DCF yield (IRR) of option A is 20% and the yield of option B is only 18% (workings not shown.)
On a comparison of NPVs, option B would be preferred, but on a comparison of IRRs, option A
would be preferred.
The fact that A has a higher IRR than B indicates that, if the company's cost of capital were to
increase from 16%, A would yield a positive NPV for a larger range of costs than B. (It is 'less
sensitive' to increases in the discount rate).
However, at the company's actual cost of capital, B gives a higher NPV, thereby increasing
shareholder wealth by a greater amount than A.
Thus in the case of mutually exclusive projects where NPV and IRR rankings appear to conflict,
the NPV approach should be used to decide between them.
Chapter 2: Project Feasibility Studies
Page | 85
Of course, if the projects were independent all this would be irrelevant since under the NPV rule
both would be accepted and the organisation would be indifferent as to the order in which they
were accepted.
14.4 Summary of NPV and IRR comparison
(a) Both methods gives the same accept or reject decision for individual projects.
(b) The IRR method is more easily understood.
(c) NPV is simpler to calculate than IRR.
(d) IRR and accounting ROCE can be confused.
(e) IRR ignores the relative sizes of investments.
(f) NPV is the preferred method for deciding between mutually exclusive projects.
Despite the advantages of the NPV method over the IRR method, the IRR method is widely used
in practice. Even so, the NPV method is superior because it focuses on the measurement of
shareholder wealth. This point is explained below.
15 The feasibility study report
Once each area of feasibility has been investigated a number of possible projects may be put
forward. The results are included in a feasibility report.
Once each area of feasibility has been investigated a number of possible projects may be put
forward. The results of the study should be compiled into a report that makes a recommendation
regarding future action (e.g. a new system, modify the existing system, or to remain with the
status quo).
The feasibility study report may be submitted to the organisation's steering committee for
consideration or perhaps to the likely project manager (this will depend upon the size and nature
of the project and the preferences of the organisation.
A typical feasibility study report may include the following sections.
Terms of reference
Description of existing system
System requirements
Details of the proposed system(s)
Chapter 2: Project Feasibility Studies
Page | 86
Cost/benefit analysis
Development and implementation plans
Recommendations as to the preferred option
Chapter 3: The Project Life Cycle
Page | 87
Chapter 3: The Project Life Cycle
Topics covered in the chapter:
Description of the project life cycle,
Understanding of project scope,
Process of scope definition,
Determining performance drivers,
Project termination and project evaluation,
Stakeholder interests, project resources – skills and people,
Implementing a project.
Chapter 3: The Project Life Cycle
Page | 88
1 The project life cycle
A successful project relies on two activities – planning first, and then doing. These two activities
form the basis of every project.
Projects can be divided into several phases to provide better management control. Collectively
these phases comprise the project life cycle.
The term project life cycle refers to the major time periods through which any project passes.
Each period may be identified as a phase and further broken down into stages.
Although the principles of the project life cycle apply to all projects, the number and name of the
phases identified will vary depending on what the project aims to achieve, and the project model
referred to.
When studying Project Management it is convenient to give generic names to the phases of the
project life cycle. Remember though, in 'real' situations (or in examination questions!) the
model can be modified to suit circumstances.
The diagram below shows a generic model of the five main phases of a project.
As shown on the diagram, resource use (such as funds and staff hours required) is relatively low
at the start of the project, higher towards the end and then drops rapidly as the project draws to
a close.
The cost of making changes to the project increases the further into the life cycle the project has
progressed.
Chapter 3: The Project Life Cycle
Page | 89
1.1 Project phases and stages
A project typically passes through five phases: defining, planning, implementing, controlling and
completing. The number and sequence of stages of a project will vary across organisations.
Chapter 3: The Project Life Cycle
Page | 90
The phases of a project can be broken down into a number of stages. Again, the number of
stages identified varies depending on type of project and the conventions of the organisation
undertaking the project.
Chapter 3: The Project Life Cycle
Page | 91
We now will look at each of these phases and stages.
1.2 Defining Phase
The defining phase of a project is concerned with deciding whether a project should begin and
committing to do so.
1.2.1 Initiation stage
Project initiation describes the beginning of a project at which point certain management
activities are required to ensure that the project is established with clear reference terms and an
appropriate management structure.
Projects originate from someone attempting to resolve a problem, or seeing an opportunity to
do something new.
It is often not clear precisely what the problem is. The project team should study, discuss and
analyse the problem, from a number of different aspects (e.g. technical, financial).
Not all ideas will result in viable projects. A 'reality test' should be applied to all ideas. This is not
a detailed feasibility study, and is intended to eliminate only concepts that are obviously not
viable. For example, a small construction company should not waste resources investigating the
possibility of submitting a tender to build the second channel tunnel.
At the start of a project, a Project Initiation Document (PID) may be drawn up, setting out the
terms of reference for the project. Typical contents might include.
Chapter 3: The Project Life Cycle
Page | 92
(a) The business objectives. Projects should not be undertaken simply for their own sake: the
business advantages should be clearly identified and be the first point of reference when
progress is being reviewed, to make sure that the original aim is not lost sight of.
(b) Probable project objectives, stated in a general manner.
(c) The scope of the project: what it is intended to cover and what it is not.
(d) Constraints, such as maximum amount to be spent and interim and final deadlines.
(e) The ultimate customer of the project, who will resolve conflicts as they occur (for example
between two different divisions who will both be using the new system) and finally accept
it.
(f) The resources that will be used – staff, technical resources, finance.
(g) An analysis of risks inherent in the project and how they are to be avoided or reduced (for
example, the consequences of replacing the old sales ledger system and only discovering
after the event that the new one does not work).
(h) A preliminary project plan (targets, activities and so on) and details of how the project is
to be organised and managed (see the next section).
(i) Purchasing and procurement policy, perhaps specifying acceptable suppliers and
delivery details.
1.2.2 Formation stage
The formation stage involves selecting the personnel who will be involved with the project. First
to be selected is usually the Project Manager and the Project Board.
The project manager should select and build the project team.
1.2.3 Objective setting stage
Before specific objectives can be set it is necessary to establish more general project goals. Clear
goals and objectives give team members quantifiable targets to aim for. This should improve
motivation and performance, as attempting to achieve a challenging goal is more inspiring than
simply being told 'do your best.'
The overall project goal or project definition will be developed. On complex projects it is likely
that the goal will require be written in stages, with each definition being more detailed and
refined than before. The project goal might be defined in a:
Contract
Product specification
Customer's specification
A goal is a result or purpose that is determined for a project. Goals are broader than objectives.
Chapter 3: The Project Life Cycle
Page | 93
An objective is a specific project outcome required – including required resources and timing.
Project objectives define what a project must achieve for it to be judged to be complete and
successful and hence able to be closed. Benefits on the other hand may only just be starting to
appear at the end of a project and may continue to be realised long after the project has finished.
A well-defined and agreed (set of) objective(s) is a necessary pre-cursor to detailed project
planning. For the objectives to be useful as an aid to project management they must be:
Specific to the project, and within the project. For example the objective: ‘To improve
the efficiency of our interactions with customers.’ is too vague. It is really a goal shared
by a number of programmes, projects and business as usual activities. On the other hand
'To reduce the average turnaround times for enquiries from customers on subject X.' is a
much clearer indication of what the project must do. However it is not yet very
measurable.
Measurable. You need to define in as measurable and subjective terms as possible what
must be achieved. Measurability will depend on the nature of the objective and may be
in terms of such things as performance, cost, effort, % change, amount of time,
deliverables, quality levels, numbers of events, agreements, approvals, commencement
or termination of something, numbers of people/organisations, a benefit to be achieved
within the life of the project etc. The example above might be made measurable by saying
'To reduce the average turnaround times by 30% from the 2006 figure.' When setting a
measurable target you must ensure that it is achievable.
Achievable. It must be possible to achieve the objective in practical terms and also within
whatever time target has been set (see Time bound below). You might need to consider
constraints of technology, people and processes when assessing achievability. Other
things that influence achievability include: the time needed to perform consultations,
common commencement dates and the requirements of OJEU procurement process. You
should be realistic without being too conservative - project objectives will often be
challenging. Objectives must also be relevant to the bigger picture of the environment
within which the project is running. Sometimes it is only as a result of detailed planning
that it becomes clear that an objective is not achievable. If this happens during
production of the Project Initiation Document then agreement must be reached on the
revised objective. After the PID has been approved, change control must be applied so
Chapter 3: The Project Life Cycle
Page | 94
that the impact of any changes to a project's objectives are carefully assessed and
managed.
Relevant. Is the objective consistent with, and does it contribute towards, the
goal/objective at the next level up (Programme, Departmental, PSA)? Make sure the
project, or some part of it is not just there because of a whim or has been influenced by
an agenda that is not aligned with the organisation's core purpose.
Time Bound (and, perhaps trackable). It is useful to have a target date by which each
objective should be achieved. Sometimes there will be one date that applies to most or
all objectives. In other cases each project objective may require its own time frame.
Setting interim time targets may also be useful for certain types of objective. This will
make the objective trackable so that you can measure whether or not you are on course
to achieve it and hence can take early action if not. The following example is both time
bound and trackable:
'To reduce the average turnaround times to satisfy enquiries from customers on subject X by 20%
from the 2009 figure by date d1/m1/y1, and by a further 10% by d2/m2/y2.'
The SMART criteria described above should be used to check that your objectives are sufficiently
rigorous. Non-SMART objectives can lead to one or more of the following:
Insufficient information available to enable production of detailed plans as it is not clear
what the project must achieve.
Wasted effort producing multiple plans to cater for the range of possibilities allowed for
in vague objectives.
Shortage of project resources as the availability of people, skills, £, things is driven by
supply rather than planned requirement.
Project deliverables and outcomes rejected - 'That's not right! What I really need is....'
Needs of external stakeholders and other interested parties not met leading to
dissatisfaction and damage to reputations.
If you find it difficult or impossible to define your objectives in SMART terms, or it is difficult to
gain agreement on them then you must be aware of the risk this poses and hence the additional
effort the SRO and Project Manager must devote to controlling the project and to managing the
expectations of stakeholders.
Chapter 3: The Project Life Cycle
Page | 95
1.3 Planning Phase
The planning phase of a project aims to devise a workable scheme to accomplish the overall
project goal.
1.3.1 Task planning stage
After the project team is in place and project goals and objectives have been set, the project
should be broken down into manageable tasks. This process is often referred to as Work
Breakdown Structure (WBS). A brief overview of the process follows. We cover WBS in greater
detail later in this chapter.
A task is an individual unit of work that is part of the total work needed to accomplish a project.
An activity is a set of tasks that are carried out in order to create a deliverable.
A deliverable is another name for a required outcome (e.g. product, service, document etc.) from
a project.
By breaking the project down into a series of manageable tasks it is easier to determine the skills
needed to complete the project. A task list should be produced showing what tasks need to be
done and the work sequences necessary.
Building a task list for a complex project can be an involved and lengthy process. It can be difficult
deciding what constitutes a task, and where one task ends and another begins.
Tasks should be:
a) Clear. Eg Design the layout of the fixed asset depreciation schedule.
b) Self-contained. No gaps in time should be apparent on work-units grouped together to
form a task. All work-units within a task should be related.
1.3.2 Feasibility and fact finding stage
Once all the tasks have been defined a basic network diagram can be developed, together with
a complete list of resources required. Network diagrams are covered later in this chapter.
A more realistic judgement as to the feasibility of the project can now be made. Earlier feasibility
decisions, such as a pre-project feasibility study, have been fairly general. Feasibility concerns
now are more specific – such as whether initial time and cost estimates are realistic.
The activities carried out will differ depending on the nature of the project. For information
systems projects the fact finding exercise would take the form of a systems investigation.
Chapter 3: The Project Life Cycle
Page | 96
1.3.3 Position analysis, options generation and options evaluation stages
Once the current position has been clearly established options can be generated with the aim of
utilising the internal strengths identified.
The general management technique of SWOT analysis can be applied to establish the current
position, generate available options and evaluate those options.
1.4 Implementing Phase
The implementing phase is concerned with co-ordinating people and other resources to carry
out the project plan.
1.4.1 Design and development stage
The design and development stage is where the actual product, service or process that will be
the end result of the project is worked on.
The activities carried out in this stage will vary greatly depending on the type of project. For
example, in a software implementation this is when the programming of the software would take
place, in a construction project the building design would be finalised.
1.4.2 Implementation stage
After the process, service or product has been developed it will be implemented or installed so it
is available to be used.
If the project involves a new system or process, a period of parallel running alongside the existing
system or process may be carried out. This enables results to be checked, and any last-minute
problems to be ironed out before the organisation is fully reliant on the new system or process.
1.5 Controlling Phase
The controlling phase is concerned with ensuring project objectives are met by monitoring and
measuring progress and taking corrective action when necessary.
1.5.1 Review stage
Actual performance should be reviewed against the objectives identified in the project plan. If
performance is not as expected, control action will be necessary.
Chapter 3: The Project Life Cycle
Page | 97
1.6 Completing Phase
Completion involves formalising acceptance of the project and bringing it to an orderly end.
1.6.1 Completion stage
Following installation and review there should be a meeting of the Project Board to:
Check that all products are complete and delivered
Check the status of any outstanding requests for change
Check all project issues have been cleared
Approve the project completion report
Arrange for a post-implementation review
2 Management tools and techniques
Various tools and techniques are available to plan and control projects including the Project
Plan Project Budget, Work Breakdown Structure, Gantt charts, Network Analysis, Resource
Histogram and specialist software.
2.1 The Project Budget
Project budget. The amount and distribution of resources allocated to a project.
Building a project budget should be an orderly process that attempts to establish a realistic
estimate of the cost of the project. There are two main methods for establishing the project
budget; top-down and bottom-up.
2.1.1 Top-down budgeting
Top-down budgeting describes the situation where the budget is imposed 'from above'. Project
Managers are allocated a budget for the project based on an estimate made by senior
management. The figure may prove realistic, especially if similar projects have been undertaken
recently. However the technique is often used simply because it is quick, or because only a certain
level of funding is available.
Chapter 3: The Project Life Cycle
Page | 98
2.1.2 Bottom-up budgeting
In bottom-up budgeting the project manager consults the project team, and others, to calculate
a budget based on the tasks that make up the project. Work breakdown structure (WBS) is a
useful tool in this process. WBS is explained later in this section.
The budget may express all resources in monetary amounts, or may show money and other
resources – such as staff hours. A monetary budget is often used to establish the current cost
variance of the project. To establish this we need:
a) The Actual Cost of Work Performed (ACWP). This is the amount spent to date on the
project.
b) The Budgeted Cost of Work Scheduled (BCWS). The amount that was budgeted to be
spent to this point on scheduled activities.
c) The Budgeted Cost of Work Performed (BCWP). This figure is calculated by pricing the
work that has actually been done – using the same basis as the scheduled work.
BCWP – ACWP = The cost variance for the project.
BCWP – BCWS = The schedule variance for the project.
Budgets should be presented for approval and sign-off to the stakeholder who has responsibility
for the funds being used.
It may be decided that a project costs more than the value of expected benefits. If so, scrapping
the project is a perfectly valid option. In such cases the budgeting process has highlighted the
situation before too much time and effort has been spent on an unprofitable venture.
During the project actual expenditure is tracked against budget on either a separate Budget
Report, or as part of a regular Progress Report. We will be looking at project documentation
and reports later in this chapter.
2.2 Work breakdown structure (WBS)
Work breakdown structure is the analysis of the work of a project into different units or tasks.
WBS:
Chapter 3: The Project Life Cycle
Page | 99
(a) Identifies the work that must be done in the project.
(b) Determines the resources required.
(c) Sequences the work done, to allocate resources in the optimum way.
Work breakdown structure is used as a starting point for many project management functions
including budgeting and scheduling. As a simple example of WBS, wiring a house can be sub-
divided into connecting the mains, fitting light sockets and power points etc. Dealing with the
foundations involves digging, filling, area marking, damp proofing and disposal of soil.
The process of work breakdown continues until the smallest possible sub-unit is reached. Digging
the foundations for example would be analysed so that the number of labour hours needed, and
hence the cost, could be determined. Lock recommends giving each sub-unit of work a code
number to enable resources to be obtained and the work to be planned.
2.2.1 WBS and estimates of expenditure
WBS can be used in devising estimates. From the WBS it is possible to compile a complete list of
every task that is going to attract expenditure.
Collating the various costs identified with each task has several benefits:
(a) Provides a useful cost analysis for various business functions.
(b) Assists cost control.
(c) Provides evidence, in any dispute with the client, that the costs are reasonable.
Estimates (and therefore budgets) cannot be expected to be 100% accurate. Business conditions
may change, the project plan may be amended or estimates may simply prove to be incorrect.
Any estimate must be accompanied by some indication of expected accuracy.
Estimates can be improved by:
Learning from past mistakes
Ensuring sufficient design information
Ensuring as detailed a specification as possible from the customer
Properly analysing the job into its constituent units
The overall level of cost estimates will be influenced by:
Chapter 3: The Project Life Cycle
Page | 100
a) Project goals. If a high level of quality is expected costs will be higher.
b) External vendors. Some costs may need to be estimated by outside vendors. To be realistic
these people must understand exactly what would be expected of them.
c) Staff availability. If staff are unavailable, potentially expensive contractors may be required.
d) Time schedules. The quicker a task is required to be done the higher the cost is likely to be
– particularly with external suppliers.
2.3 Gantt charts
A Gantt chart, named after the engineer Henry Gantt who pioneered the procedure in the early
1900s, is a horizontal bar chart used to plan the time scale for a project and to estimate the
amount of resources required.
The Gantt chart displays the time relationships between tasks in a project. Two lines are usually
used to show the time allocated for each task, and the actual time taken.
A simple Gantt chart, illustrating some of the activities involved in a network server installation
project, follows.
Chapter 3: The Project Life Cycle
Page | 101
The chart shows that at the end of the tenth week Activity 9 is running behind schedule. More
resources may have to be allocated to this activity if the staff accommodation is to be ready in
time for the changeover to the new system.
Activity 4 had not been completed on time, and this has resulted in some disruption to the
computer installation (Activity 6), which may mean further delays in the commencement of
Activities 7 and 8.
A Gantt chart does not show the interrelationship between activities as clearly as a network
diagram (covered later in this chapter). A combination of Gantt charts and network analysis will
often be used for project planning and resource allocation.
2.4 Network analysis
Network analysis, also known as Critical Path Analysis (CPA), is a useful technique to help with
planning and controlling large projects, such as construction projects, research and development
projects and the computerisation of systems.
Network analysis requires breaking down the project into tasks with estimated durations and
establishing a logical sequence. This enables the minimum possible duration of the project to be
found.
CPA aims to ensure the progress of a project, so the project is completed in the minimum
amount of time.
It pinpoints the tasks which are on the critical path, ie those tasks which, if delayed beyond the
allotted time, would delay the completion of the project as a whole. The technique can also be
used to assist in allocating resources such as labour and equipment.
Critical path analysis is quite a simple technique. The events and activities making up the whole
project are represented in the form of a diagram. Drawing the diagram or chart involves the
following steps.
Step 1 Estimating the time needed to complete each individual activity or task that makes
up a part of the project.
Step 2 Sorting out what activities must be done one after another, and which can be done
at the same time, if required.
Step 3 Representing these in a network diagram.
Chapter 3: The Project Life Cycle
Page | 102
Step 4 Estimating the critical path, which is the longest sequence of consecutive activities
through the network.
2.4.1 The critical path
The duration of the whole project will be fixed by the time taken to complete the largest path
through the network. This path is called the critical path and activities on it are known as critical
activities.
Activities on the critical path must be started and completed on time, otherwise the total
project time will be extended.
Network analysis shows the sequence of tasks and how long they are going to take. The diagrams
are drawn from left to right. To construct a network diagram you need to know the activities
involved in a project, the expect time of each order (or precedences) of the activities.
2.4.2 Activity-on-node presentation
Network diagrams may also be drawn using Activity-on-node presentation which is similar in
style to that used by the Microsoft Project software package.
2.5 Project evaluation review technique (PERT)
Project evaluation and review technique (PERT) is a technique for allowing for uncertainty in
determining project duration. Each task is assigned a best, worst, and most probable completion
time estimate. These estimates are used to determine the average completion time. The average
times are used to establish the critical path and the standard deviation of completion times for
the entire project.
PERT is a modified form of network analysis designed to account for uncertainty. For each activity
in the project, optimistic, most likely and pessimistic estimates of times are made, on the basis of
past experience, or even guess-work. These estimates are converted into a mean time and also a
standard deviation.
Once the mean time and standard deviation of the time have been calculated for each activity, it
should be possible to do the following.
Chapter 3: The Project Life Cycle
Page | 103
a) Estimate the critical path using expected (mean) activity times.
b) Estimate the standard deviation of the total project time.
2.6 Resource histogram
A useful planning tool that shows the amount and timing of the requirement for a resource (or a
range of resources) is the resource histogram.
A resource histogram shows a view of project data in which resource requirements, usage, and
availability are shown against a time scale.
A simple resource histogram showing programmer time required on a software development
program is shown below
Some organisations add another bar (or a separate line) to the chart showing resource availability.
The chart then shows any instances when the required resource hours exceed the available hours.
Plans should then be made to either obtain further resource for these peak times, or to re-
schedule the work plan. Alternately the chart may show times when the available resource is
excessive, and should be redeployed elsewhere. An example follows.
Chapter 3: The Project Life Cycle
Page | 104
The number of workers required on the seventh day is 13. Can we re-schedule the non-critical
activities to reduce the requirement to the available level of 10? We might be able to re-arrange
activities so that we can make use of the workers available from day 9 onwards.
3 Project management software
Project management techniques are ideal candidates for computerisation. Project management
software packages have been available for a number of years. Microsoft Project and Micro Planner
X-Pert are two popular packages.
Software might be used for a number of purposes.
a) Planning
Network diagrams (showing the critical path) and Gantt charts (showing resource use) can be
produced automatically once the relevant data is entered. Packages also allow a sort of 'what if?'
analysis for initial planning, trying out different levels of resources, changing deadlines and so on
to find the best combination.
b) Estimating
As a project progresses, actual data will become known and can be entered into the package and
collected for future reference. Since many projects involve basically similar tasks (interviewing
users and so on), actual data from one project can be used to provide more accurate estimates
No. of workers available
Number of workers required to complete scheduled tasks
No. of workers
Time (days) 20
15
5 10 7
13
12
10
8
6
4
2
Chapter 3: The Project Life Cycle
Page | 105
for the next project. The software also facilitates and encourages the use of more sophisticated
estimation techniques than managers might be prepared to use if working manually.
c) Monitoring
Actual data can also be entered and used to facilitate monitoring of progress and automatically
updating the plan for the critical path and the use of resources as circumstances dictate.
d) Reporting
Software packages allow standard and tailored progress reports to be produced, printed out and
circulated to participants and senior managers at any time, usually at the touch of a button. This
helps with co-ordination of activities and project review.
3.1 What input data is required?
Most project management packages feature a process of identifying the main steps in a project,
and breaking these down further into specific tasks.
A typical project management package requires four inputs.
a) The length of time required for each activity of the project.
b) The logical relationships between each activity.
c) The resources available.
d) When the resources are available.
3.2 Advantages of project management software packages
The advantages of using project management software are summarised below.
Advantage Comment
Enables quick re-
planning
Estimates can be changed many times and a new schedule produced
almost instantly. Changes to the plan can be reflected immediately.
Document quality Well-presented plans give a professional impression and are easier
to understand.
Encourages constant
progress tracking
The project manager is able to compare actual progress against
planned progress and investigate problem areas promptly.
What if? analysis Software enables the effect of various scenarios to be calculated
quickly and easily. Many project managers conduct this type of
analysis using copies of the plan in separate computer files – leaving
the actual plan untouched.
Chapter 3: The Project Life Cycle
Page | 106
Another advantage is that the software is able to analyse and present the project information in
a number of ways. The views available within Microsoft Project are shown in the following
illustration – on the drop down menu.
3.3 Disadvantages of project management software packages
Two disadvantages of project management software are:
a) Some packages are difficult to use.
b) Some project managers become so interested in producing perfect plans that they spend
too much time producing documents and not enough time managing the project.
4 Documentation and reports
Project documentation plays an important part in project control and communication.
We will now look at the main documents and reports used in project management. The name
allocated to documents will vary across different organisations. What is constant is the need for
clear and relevant documentation that helps monitor and control the project.
Remember that reports are not a substitute for one-on-one communication. Too many (or too
lengthy) reports will result in information overload.
Chapter 3: The Project Life Cycle
Page | 107
When outlining possible content of documents some duplication of items occurs. This does not
mean that information should be repeated, but that the information may appear in one or other
of the documents depending on the format adopted by the organisation.
It is likely that the Project Initiation Document will evolve until it is ultimately incorporated into
the Project Management Plan, sometimes referred to as the Project Quality Plan.
4.1 The Project Plan
The project manager should also develop a Project Plan. In some organisations what is described
here as the Project Plan would be called the Project Management Plan. In other organisations
the Project Plan refers only to the project schedule, usually in the form of a network diagram.
The Project Plan is used to guide both project execution and project control. It outlines how the
project will be planned, monitored and implemented.
4.1.1 Contents of the Project Plan
The project plan should include:
Project objectives and how they will be achieved and verified
How any changes to the project plan are to be controlled
The management and technical procedures, and standards, to be used
Details of the quality strategy
The budget and time-scale
Safety, health and environmental policies
Inherent risks and how they will be managed
An example of a simple Project Plan / Project Management Plan is shown over the page. This
plan was produced by an American organisation – the Project Management Institute (PMI) – to
manage a project to produce formal project management principles.
The Project Plan evolves over time. A high level plan for the whole project and a detailed plan
for the current and following stage is usually produced soon after project start-up. At each
subsequent stage a detailed plan is produced for the following stage and if required, the overall
project plan is revised
4.1.2 Project Quality Plan
An important element of the overall Project Plan is the Project Quality Plan.
Chapter 3: The Project Life Cycle
Page | 108
The Project Quality Plan outlines the quality strategy to be followed and links this to any formal
quality management approach the organisation has chosen to follow.
There is no generally accepted format for a quality plan – in fact the distinction between a
project management plan and a quality plan is becoming increasingly blurred.
A Project Quality Plan may include a number of elements, for example; project overview, project
organisation and management, project requirements, development/production methods,
quality management, risk management and procurement.
For example, the organisation and management section of the Project Quality Plan would include
details of the roles and responsibilities of stakeholders involved in managing the project. This
might include members of the project board, the project sponsor, project manager, project team,
contact people in the client organisation, formal reporting procedures, planning, monitoring and
control methods.
Other sections of the Project Quality Plan will depend upon the nature of the project. For example,
a software project Quality Plan may include a section dealing with configuration management,
containing details of:
Version control – how software version numbering issues are dealt with
Change control – covering how changes are identified, evaluated and implemented correctly.
The contents of the plan will vary depending on the complexity of the project.
The contents page and introduction from a detailed Project Plan relating to a software
implementation project at a call centre follow. (These plans are shown to provide practical
examples – you do not need to learn the details of the plans – what you need for the exam is a
general understanding of possible approaches to project documentation.)
4.2 Progress report
A progress report shows the current status of the project, usually in relation to the planned
status.
The frequency and contents of progress reports will vary depending on the length of the project
and the progress being made.
Chapter 3: The Project Life Cycle
Page | 109
The report is a control tool intended to show the discrepancies between where the project is,
and where the plan says it should be.
A common form of progress uses two columns – one for planned time and expenditure and one
for actual.
Any additional content will depend on the format adopted. Some organisations include only the
'raw facts' in the report, and use these as a basis for discussion regarding reasons for variances
and action to be taken, at a project review meeting.
Other organisations (particularly those involved in long, complex projects) produce more
comprehensive progress reports, with more explanation and comment.
The progress report should also include an updated budget status – perhaps showing the cost
and schedule variance explained earlier in this chapter.
4.2.1 Milestones
The progress report should monitor progress towards key milestones.
A milestone is a significant event in the project, usually completion of a major deliverable.
Another way of monitoring progress that could be included in a progress report is a milestone
slip chart.
The milestone slip chart compares planned and actual progress towards project milestones.
Planned progress is shown on the X-axis and actual progress on the Y-axis. Where actual progress
is slower than planned progress slippage has occurred.
A milestone slip chart is shown below.
Chapter 3: The Project Life Cycle
Page | 110
On the chart above milestones are indicated by a triangle on the diagonal planned progress line.
The vertical lines that meet milestones 1 and 2 are straight – showing that these milestones were
achieved on time.
At milestone 3 some slippage has occurred. The chart shows that further slippage occurred
between milestones 3 and 4. This is shown by the fact that the vertical line for milestone 4
intersects the diagonal line further to the right of the triangle 4 than was the case for milestone
3.
4.3 Completion report
The completion report summarises the results of the project, and includes client sign-off.
On project completion the project manager will produce the Completion Report. The main
purpose of the completion report is to document (and gain client sign-off for) the end of the
project.
The report should include a summary of the project outcome. The completion report should
contain:
Chapter 3: The Project Life Cycle
Page | 111
a) Project objectives and the outcomes achieved.
b) The final project budget report showing expected and actual expenditure (If an external
client is involved this information may be sensitive – the report may exclude or 'amend'
the budget report).
c) A brief outline of time taken compared with the original schedule.
The completion report will also include provision for any on-going issues that will need to be
addressed after completion. Such issues would be related to the project, but not part of the
project. (If they are part of the project the project is not yet complete!) An example of an on-
going issue would be a procedure for any 'bugs' that become apparent after a new software
program has been tested and approved. Responsibilities and procedures relating to any such
issues should be laid down in the report.
The manager may find it useful to distribute a provisional report and request feedback. This
should ensure the version presented for client sign-off at the completion meeting is acceptable
to all parties.
A more detailed review of the project and the system follows a few months after completion, the
post completion audit.
4.4 The post-completion audit
The post-completion audit is a formal review of the project that examines the lessons that may
be learned and used for the benefit of future projects.
The audit looks at all aspects of the project with regard to two questions.
a) Did the end result of the project meet the client's expectations?
The actual design and construction of the end product Was the project
achieved on time?
Was the project completed within budget?
b) Was the management of the project as successful as it might have been, or were there
bottlenecks or problems? This review covers:
i. Problems that might occur on future projects with similar characteristics.
ii. The performance of the team individually and as a group.
In other words, any project is an opportunity to learn how to manage future projects more
effectively.
Chapter 3: The Project Life Cycle
Page | 112
The post-completion audit should involve input from the project team. A simple questionnaire
could be developed for all team members to complete, and a reasonably informal meeting held
to obtain feedback. On what went well (and why), and what didn't (and why).
With information systems projects the post-completion audit may be conducted as part of the
post implementation review (covered later in this Text). Strictly speaking, a post-completion
audit would include a detailed review of the project management process, while the post-
implementation review is concerned mainly with the resulting system.
4.4.1 Post-completion audit report
The post-completion audit report should contain the following.
a) A summary should be provided, emphasising any areas where the structures and tools used
to manage the project have been found to be unsatisfactory.
b) A review of the end result of the project should be provided, and compared against the
results expected. Reasons for any significant discrepancies between the two should be
provided, preferably with suggestions for how any future projects could prevent these
problems recurring.
c) A cost-benefit review should be included, comparing the forecast costs and benefits
identified at the time of the feasibility study with actual costs and benefits.
d) Recommendations should be made as to any steps which should be taken to improve the
project management procedures used.
4.4.2 Using post-completion audit information
Lessons learnt that relate to the way the project was managed should contribute to the smooth
running of future projects.
A starting point for any new project should be a review of the documentation of any similar
projects undertaken in the past.
5 Risk management
Risk management is concerned with identifying such and putting in place policies to eliminate
or reduce these risks.
Chapter 3: The Project Life Cycle
Page | 113
Projects and other undertakings carry an element of risk, for example the risk of an inappropriate
system being developed and implemented.
The identification of risks involves an overview of the project to establish what could go wrong,
and the consequences.
5.1 Risk management process
A risk is any area of uncertainty that represents a threat or an opportunity to the project. Most of
your attention to risk will be to avoid or reduce the likelihood of events that might cause your
project to be thrown off course. To manage and mitigate risks, you first need to identify them,
assess the likelihood of them happening and estimate the impact they might have on your
project. The identification and consideration of risk is an integral part of project management
and the successful delivery of change.
Decisions in a project or programme environment are taken based on evidence and reasoned
assumptions, but outcomes are never wholly predictable. Often, hard decisions must be taken
quickly or without complete information. However, managing risk does not mean playing it safe
at all costs. As projects deal with change, some amount of risk taking is inevitable for a project to
achieve its objectives and to take advantage of any opportunities that might surface.
Good project management aims to manage the exposure of the project to risk by driving action
to improve control of uncertainty and take steps to reduce the chance of failing to achieve the
stated objectives. A successful project manager will routinely review their exposure to risk and
the steps being taken to manage it. The SRO (Senior Responsible Owner) and if there is one, the
Project Board (includes Senior Responsible Owner, Senior User role, Senior Supplier), should be
actively engaged in the risk management process to ensure that risks are identified by members
of the project team and that emerging risks are escalated upwards as required.
Good risk management requires you to:
Clearly understand what you are trying to achieve - not always simple but very important
Focus equally on 'what could we achieve with a fair wind?' rather than just 'what might stop
us' - it helps ensure opportunities are not missed!
Risk management is not:
A science - often it is based on subjective and qualitative judgements
Chapter 3: The Project Life Cycle
Page | 114
Just about finance - it applies to all business decisions at all levels and should also consider
reputational, operational, regulatory factors
A bureaucratic exercise - as with all project management, certain decisions may be better
supported by appropriate documentation. But use common sense and remember that having
a Risk Log is not the same as managing risk.
Managing the project risks helps Project Manager to demonstrate to your SRO (Senior
Responsible Owner), Project Board, colleagues and key stakeholders that you are aware of your
challenges, have considered options appropriately, and that the project is going to deliver
successfully.
Risk management may be viewed as a six-stage process:
Stage 1 Plan risk management approach.
Stage 2 Identify and record risks, for example in a risk register.
Stage 3 Assess risks and record this assessment.
Stage 4 Plan and record risk responses.
Stage 5 Carry out risk reduction actions.
Stage 6 Review the risk management approach.
5.2 Risk assessment process
Risk identification - risks should be directly related to the project objectives and agreed by
the whole project management team and its key stakeholders. Risk management means
identifying and managing uncertainties to delivery of objectives, not managing issues that
might be constant. Focus on issues alone can lead to fire fighting. Enter details into a Risk
Log/Risk Register
Risk evaluation - what is the impact of each risk should it occur? What impact might they
have on benefits, time, cost, quality, reputation, people, etc. How likely is it that these risks
will occur? The probability and impact can both be scored, e.g. using a High/Medium/Low
scale. A Risk Profile could be used to show the overall pattern of risk.
Risk prioritisation - what is the priority of each risk? The urgency and importance of a risk
is not the same thing - deal with the urgent risks quickly, deal with the important risks
comprehensively.
Chapter 3: The Project Life Cycle
Page | 115
Risk management planning - do you have a strategy for mitigating the risks you have
identified and preventing the project from being derailed? What actions and resources will
you need to reduce the impact and/or probability of the risk happening? You might find it
useful to consider:
- How to prevent it from happening - either by putting some counter-measures in place
or putting the project in a position where it would have no impact
- How to reduce the risk - what action is needed to reduce the probability of the risk
happening and/or to reduce the impact if it does occur
- Can you transfer the risk to a third party (e.g. take out insurance) or share it in some way
(shared risk-shared gain)?
- What to do to if the risk does occur - do you need a contingency plan?
- What are the implications of accepting the risk - ensuring that all the stakeholders are
aware of the possible consequences?
Planning and resourcing - actions should be built in to the project's plans. If it has been
decided to accept a particular risk without action you may need to inform key stakeholders.
Risk monitoring - Individual risks, and the project's overall exposure to risk, must be
reviewed throughout the life of a project and where necessary actions to mitigate risks must
be changed or revisions to the project business case or assumptions must be considered, if
circumstances alter.
5.3 Contingency plan
For each risk on the risk register it should be recorded what approach will be taken to deal with
the risk.
Developing a risk contingency plan that contains strategies for risks that fall into the VH
quadrant should have priority, followed by risks falling into the two H quadrants. Following the
principle of management by exception, the most efficient way of dealing with risks outside
these quadrants may be to do nothing unless the risk presents itself.
5.4 Dealing with risk
Dealing with risk involves four strategies.
a) Avoidance: the factors which give rise to the risk are removed.
b) Reduction or mitigation: the potential for the risk cannot be removed but analysis has
enabled the identification of ways to reduce the incidence and / or the consequences.
c) Transference: the risk is passed on to someone else – or is perhaps financed by an insurer.
Chapter 3: The Project Life Cycle
Page | 116
d) Absorption: the potential risk is accepted in the hope or expectation that the incidence and
consequences can be coped with if necessary.
Risk management is a continuous process. Procedures are necessary to regularly review and
reassess the risks documented in the risk register.
5.5 Dealing with slippage
'Slippage' or slipping behind schedule is a common problem.
When a project has slipped behind schedule there are a range of options open to the project
manager. Some of these options are summarised in the following table.
Action Comment
Do nothing After considering all options it may be decided that things should be allowed
to continue as they are.
Add
resources
If capable staff are available and it is practicable to add more people to certain
tasks it may be possible to recover some lost ground. Could some work be
subcontracted?
Work
smarter
Consider whether the methods currently being used are the most suitable – for
example could prototyping be used.
Re-plan If the assumptions the original plan was based on have been proved invalid a
more realistic plan should be devised.
Reschedule A complete re-plan may not be necessary – it may be possible to recover some
time by changing the phasing of certain deliverables.
Introduce
incentives
If the main problem is team performance, incentives such as bonus payments
could be linked to work deadlines and quality.
Change the
specification
If the original objectives of the project are unrealistic given the time and money
available it may be necessary to negotiate a change in the specification.
5.5.1 Project change procedure
Some of the reactions to slippage discussed above would involve changes that would significantly
affect the overall project. Other possible causes of changes to the original project plan include:
Chapter 3: The Project Life Cycle
Page | 117
The availability of new technology
Changes in personnel
A realisation that user requirements were misunderstood
Changes in the business environment
New legislation e.g. Data protection
The earlier a change is made the less expensive it should prove. However, changes will cost time
and money and should not be undertaken lightly.
When considering a change an investigation should be conducted to discover:
The consequences of not implementing the proposed change.
The impact of the change on time, cost and quality.
The expected costs and benefits of the change.
The risks associated with the change, and with the status-quo.
The process of ensuring that proper consideration is given to the impact of proposed changes is
known as change control.
Changes will need to be implemented into the project plan and communicated to all
stakeholders.
5.6 Project implementation
The majority of the work in projects takes place within the project process. However, this section
is shorter than that for initiation. This is because many of these issues are considered in the other
resources. The first part of implementation is developing an outline plan into an integrative
project plan (Meredith and Mantell, 2003), including:
1 Overview of the objectives and scope.
2 Detailed objectives – profit, technical and competitive aspects of the project.
3 The general approach of the managerial and technical aspects of the project – how this links
or deviates from existing approaches and projects. This would include the choice of the
appropriate project management methodologies.
4 Contractual requirements – the reporting processes of all parties, the review processes,
agreements with third parties and schedules. Information on changes to the plan, including
rescheduling, the substitution of suppliers or cancellation of the contract should also be
determined.
Chapter 3: The Project Life Cycle
Page | 118
5 Schedules for the work – the components parts and key milestones in the progress of the
project. The project scope should be broken down (‘decomposed’) into parts. This depends
on the chosen work breakdown structure (WBS). At its simplest, a WBS is a structured and
itemised ‘to do’ list. Each task should be detailed, with time estimates. Timings should be
agreed by the project manager.
6 Resource issues – the detailed budget should be included, as should the project budget
monitoring process.
7 Personnel requirements – the skills required, and processes and criteria for selection of
employees, training programmes.
8 Methods and standards of evaluation – mechanisms for collecting and storing data on the
progress of the project should be determined.
9 Potential problems or assumptions – including terrorist threats, weather problems or
governmental bureaucratic factors that might be outside the project manager’s control.
10 Contingency planning – most plans have some form of contingency planning. The approach
and allowances for this is part of the main project plan.
5.7 Project termination and project evaluation
The third stage of the project management life cycle is project termination. A decision to
terminate a project occurs when one or more of the following occur:
a) A project is superseded, possibly by competitors’ actions or a new technical
development.
b) A project is ‘killed’ by management before completion, often once its internal sponsor
leaves or another initiative has greater priority or fit.
c) Projects are deprived of funds and starve to death.
d) Projects are integrated into the routine activities of an organisation.
The decision to terminate a project is not the end of the project management process, which
ends after the project evaluation. Evaluation determines how well the project met its objectives,
including time, cost and quality, and how well the needs of its stakeholders were met. Project
evaluation helps develop learning to guide future projects.
Chapter 3: The Project Life Cycle
Page | 119
Small projects may have informal reviews, but larger projects need formal reviews. Although
evaluation takes place throughout the project, an integrated evaluation at the end of the project
reflects on reasons for success and failure that may be missed in operational management.
Project audits are rigorous reviews, using a structured approach, and often undertaken by an
independent party.
5.7.1 Stakeholder interests
It is important to understand who has an interest in a project, because part of the responsibility
of the project manager is communication and the management of expectations. An initial
assessment of stakeholders should be made early in the project’s life, taking care not to ignore
those who might not approve of the project, either as a whole, or because of some aspect such
as its cost, its use of scarce talent or its side-effects. The nature and extent of each stakeholder’s
interest in, and support for (or opposition to) the project should be established as thoroughly as
possible and recorded in a stakeholder register. This will make it possible to draw on support
where available and, probably more important, anticipate and deal with stakeholder-related
problems. The project manager should be aware of the following matters for each stakeholder or
stakeholder group:
a) Goals
b) Past attitude and behaviour
c) Expected future behaviour
d) Reaction to possible future developments
6 Managing stakeholders
In order to manage stakeholder relationships you must:
Identify the stakeholders
Analyse their attitudes to, and potential need for involvement in, the project. You find it useful
to summarise this with a Stakeholder Power/Impact Matrix (see below).
Establish your stakeholder management strategy to ensure a consistent, appropriate and
cost-effective approach is adopted across the project (perhaps formalised as a Stakeholder
Management Strategy).
Identify potential approaches to engage, manage relationships and communicate (both
ways) with each stakeholder.
Chapter 3: The Project Life Cycle
Page | 120
Select the approaches that are likely to be effective cost-effective proportionate and
affordable (perhaps formalised as a Communications Plan - see below), and build them in to
the Project Plan as appropriately resourced and scheduled activities.
Execute the plan, monitor its effectiveness and revise as necessary.
6.1 Analysing the Stakeholders
For each stakeholder consider
What is their interest in the project?
How important are they to the project?
Will you be changing such things as:
The way they work (e.g. new processes, information or technology)?
Their attitudes (e.g. to customers, suppliers, employers, the public)?
The speed/productivity of their work?
The people they work with and/or communicate with?
Their level of accountability/responsibility/authority?
Chapter 3: The Project Life Cycle
Page | 121
The timing of events in their working day, or its duration?
The working environment or the location(s) of their work?
Which aspects of the project might they wish to/try to influence in some way?
How much power do they possess to influence the project in some way? (The
Power/Impact matrix may help clarify this analysis)
Are they mostly for or against the project?
Will they be involved in:
Setting/reviewing the strategy direction that triggered the programme/project?
Acting as a ‘Champion’ or ‘Ambassador’ for the project or for the change it will bring
about?
Specifying the project's outcome, benefits, scope, objectives and priorities?
Specifying project products/deliverables?
Changing the way their organisation operates in order to cater for the outcome of the
project?
Using project deliverables after the project?
Supporting and/or maintaining project deliverables after the project?
Providing specialist skills for the project (e.g. law, IT, policy, project management)?
Providing non-human resources (e.g. £, accommodation, equipment, facilities)?
Providing information/opinions/advice?
Taking decisions affecting the direction of the project (e.g. Change requests)?
Quality checking the projects deliverables/outputs?
Make sure you establish:
Who is the key day-to-day contact from within the stakeholder organisation, and who
in the project will be responsible for managing the relationship with them?
Who from within the stakeholder organisation will be the person to whom to escalate
issues that can't be dealt with day-to-day level. Who in the project will be responsible for
such escalation?
Is it clear which aspects of the project are of most interest to a particular stakeholder? (A
Stakeholder Interest Map that relates stakeholders to the aspects of the project that are
likely to be of most interest may help clarify this analysis)
Chapter 3: The Project Life Cycle
Page | 122
Decide how best to involve them:
Should they be actively involved in directing the project (e.g. as Senior Responsible
Owner, Project Board/Steering Group member)?
Should they be involved as a member of the project team doing specialist work to
7 Project resources – skills and people
7.1 The project manager
All projects require a person who is ultimately responsible for delivering the required outcome.
This person (whether officially given the title or not) is the project manager. The duties of a project
manager are summarised below.
Table: Project manager roles and responsibilities
Duty Comment
Outline planning Project planning (e.g. targets, sequencing).
Developing project targets such as overall costs or timescale
needed (e.g. project should take 20 weeks).
Dividing the project into activities and placing these activities into
the right sequence. Developing a framework for procedures and
structures, manage the project (e.g. decide, in principle, to have
weekly team meetings, performance reviews etc.).
Detailed planning Work breakdown structure, resource requirements, network analysis
for scheduling.
Teambuilding Build cohesion and team spirit.
Communication The project manager must keep supervisors informed about progress
as well as problems, and ensure that members of the project team are
properly briefed.
Co-ordinating
project activities
Between the project team and users, and other external parties (e.g.
suppliers of hardware and software).
Monitoring and
control
The project manager should estimate the causes for each departure
from the standard, and take corrective measures.
Chapter 3: The Project Life Cycle
Page | 123
Problem-
resolution
Even with the best planning, unforeseen problems may arise.
Quality control There is often a short-sighted trade-off between getting the project out
on time and the project's quality.
Risk management A key consideration is project failure and hence project risks and
potential risk areas must be identified and monitored.
Project management as a discipline developed because of a need to co-ordinate resources to
obtain desired results within a set timeframe. Common project management tasks include
establishing goals and objectives, developing a work-plan, scheduling, budgeting, co-ordinating
a team and communicating.
The project management process helps project managers maintain control of projects and meet
their responsibilities.
7.2 The responsibilities of a project manager
A project manager may be regarded as having responsibilities both to management and to the
project team.
Responsibilities to management:
(a) Ensure resources are used efficiently – strike a balance between cost, time and results.
(b) Keep management informed with timely and accurate communications about progress and
problems.
(c) Manage the project competently and take action to keep it on schedule for successful
completion.
(d) Behave ethically, and adhere to the organisation's policies.
(e) Maintain a customer orientation (whether the project is geared towards an internal or
external customer)
- customer satisfaction is a key indicator of project success.
Responsibilities to the project team:
(a) Ensure the project team has the resources required to perform tasks assigned.
Chapter 3: The Project Life Cycle
Page | 124
(b) Provide new team members with a proper briefing and help them integrate into the team.
(c) Provide any support required when members leave the team either during the project or on
completion.
(d) Listen properly to team members so that potential problems are identified and can be dealt
with as soon as possible.
7.3 The skills required of a project manager
To meet these responsibilities a project manager requires a broad range of skills. The skills
needed are similar to those necessary when managing a wider range of responsibilities. A project
manager requires excellent technical and personal capabilities. Some of the skills required are
detailed in the following table.
Table: Project manager skill set
Type of skill How the project manager should display the type of skill
Leadership and
team
Building
Be enthusiastic about what the project will achieve.
Be positive (but realistic) about all aspects of the project.
Understand where the project fits into the ‘big picture’.
Delegate tasks appropriately – and not take on too much personally.
Build team spirit through encouraging co-operation and sharing of
information.
Do not be restrained by organisational structures; a high tolerance for
ambiguity (lack of clear-cut authority) will help the project manager.
Be prepared to motivate team members and give due praise and
encouragement.
Project
administration
Ensure all project documentation is clear and distributed to all who
require it.
Use project management tools to analyse and monitor project progress.
Chapter 3: The Project Life Cycle
Page | 125
Communication Listen to project team members. Exploit good ideas whatever the source.
Use persuasion to win over reluctant team members or stakeholders to
support the project.
Ensure management is kept informed and is never surprised.
Encourage team members to share their knowledge and support each
other.
Technical By providing (or at least access to) the technical expertise and experience
needed to manage the project.
Personal Be flexible. Circumstances may develop that require a change in plan.
Show resilience. Even successful projects will encounter difficulties that
require repeated efforts to overcome.
Be creative. If one method of completing a task proves impractical a new
approach may be required.
Patience is required even in the face of tight deadlines. The ‘quickfix’ may
eventually cost further time than a more thorough but initially more
time-consuming solution.
Keep in touch with team members as their performance is key to the
success of the project.
7.4 Building a project team
Project success depends to a large extent on the team members selected. The ideal project team
achieves project completion on time, within budget and to the required specifications – with the
minimum amount of direct supervision from the project manager.
The team will comprise individuals with differing skills and personalities. The project manager
should choose a balanced team that takes advantage of each team member's skills and
compensates elsewhere for their weaknesses.
The project team will normally be drawn from existing staff, but highly recommended outsiders
with special skills may be recruited. When building a team the project manager should ask the
following questions.
Chapter 3: The Project Life Cycle
Page | 126
a) What skills are required to complete each task of the project? This list will be based on the
project goals established previously.
b) Who has the talent and skills to complete the required tasks, whether inside or outside the
organisation?
c) Are the people identified available, affordable, and able to join the project team?
d) What level of supervision will be required?
7.5 Developing the project team
Group cohesiveness is an important factor for project success. It is hoped that team members will
develop and learn from each other, and solve problems by drawing on different resources and
expertise.
The performance of the project team will be enhanced by the following.
a) Effective communication
b) All members being aware of the team's purpose and the role of each team member
c) Collaboration and creativity among team members
d) Trusting, supportive atmosphere in the group
e) A commitment to meeting the agreed schedule
f) Innovative/creative behaviour
g) Team members highly interdependent, interface effectively
h) Capacity for conflict resolution
i) Results orientation
j) High energy levels and enthusiasm
k) An acceptance of change
Collaboration and interaction will help ensure the skills of all team members are utilised, and
should result in ‘synergistic’ solutions. Formal (e.g. meetings) and informal channels (e.g. e-mail
links, a bulletin board) of communication should be set up to ensure this interaction takes place.
Chapter 4: Methods of Project Management
Page | 127
Chapter 4: Methods of Project Management
Topics covered in the chapter:
Concept of most common and popular methodologies: PRINCE/PRINCE2
Scalable methodologies and agile methodologies
Project management plan
Implementing the project management plan with a project planning template
Chapter 4: Methods of Project Management
Page | 128
1 Project management approaches
Project management approaches vary substantially, across a continuum, with the following
extremes:
Organisations have no formal methodology, which means that the project manager has all the
information and plans. Team members may be less involved or committed because they lack
information. Management may be given only limited information on progress, as reporting takes
time.
An organisation-wide methodology is applied for all projects and departments. Usually, this is a
sophisticated methodology, which prepares plans, metrics, communications tasks etc. Often,
these methodologies require training for all participants. However, an overly complex
methodology may be cumbersome for some projects, such as simple, ‘soft’ or creative projects,
and may demotivate people.
Between these extremes, there are many off-the-shelf software packages for managing projects,
including Microsoft Project. Typically, these require some training, but are not the highly specialist
project management methodologies. These packages identify the core processes and reporting
that is required in project management, and can be bought or licensed for application. Pre-
established packages are cheaper than the specialist packages. They may increase project
management efficiency by automating planning and reporting processes. In turn, this improves
effectiveness, such as reducing risks.
These packages are flexible enough to take account of a project’s unique aspects and can be
customised for any projects, but there are also ‘off-the-shelf’ software packages specifically for
marketing, IT projects.
A second option is to buy an existing methodology and customise it (or have it customised) for
a specific situation. This is generally for more sophisticated projects and project-focused
organisations. There is a fine line here between the adaptation of an existing methodology and
the development of in-house methodologies, customised for an organisation’s skills, values and
best practices. The latter are becoming less common with ever-increasing numbers of quality
project management software. Sophisticated customised packages are typically time consuming
and expensive, and staff must be trained to use these.
Chapter 4: Methods of Project Management
Page | 129
2 Core project management methodologies
Using existing methodology is increasingly common, especially in larger organisations that have
extensive project management experience. Often, job advertisements for projects managers
detail the methodology to be used, and ask for experience in using this technology.
This discussion presents features of two common process methodologies:
• PRINCE/PRINCE2
• Scalable methodology
Process methodologies are those that follow a formal planning stage, whereby processes are
determined for undertaking the project.
2.1 PRINCE/PRINCE2
PRINCE (PRojects IN Controlled Environments) methodologies are commonly used in public
sector project management, although they were originally designed for developing and
implementing information systems. It is the default methodology for public sector organisations
in the United Kingdom, and is widely used by large organisations across Europe. A related
approach is Managing Successful Programmes (MSP). Both approaches are structured, but
adaptable to different projects and programmes.
PRINCE methodologies have:
A clear management structure
Formal allocation of project roles and responsibilities
Plans for resourcing and technical issues
Control procedures
A focus on products – deliverables to the customer and project deliverables for the
management of the project
PRINCE methodologies have three separate progress assurance roles:
The business – The Business Assurance Co-ordinator (BAC) ensures that the project meets
the organisation’s mission.
The specialist – The Technical Co-ordinator is responsible for ensuring that the project does
not have technical problems.
Chapter 4: Methods of Project Management
Page | 130
The user – The User Assurance Co-ordinator represents the user throughout the process.
These different roles ensure that the various stakeholders agree that the project is satisfactory
(in terms of the cost, quality and delivery) from all perspectives.
In terms of progress planning and monitoring, PRINCE2 shows:
The project life cycle stages
Progress against plan and key user-defined decision points
Alerts for any variance from plan
In addition, PRINCE2 enables:
Management and stakeholder involvement at critical times in the project
Effective communication within the project team and other stakeholders
However, PRINCE2 has its critics, who claim it will:
Make projects longer
Increase project costs
Tie up resources
Delay payback on the project
Increase risks of failure
Read more information on PRINCE2 at http://www.prince2.com/.
2.2 Scalable methodology
Scalable methodology recognises the differences in project size, risk and complexity, and allows
a customised best practice management approach for each project. This approach builds on the
Project Management Institute’s PMBOK (Project Management Body of Knowledge), identifying
differences between minor and major projects on nine dimensions and their impact on project
management.
2.3 Agile methodologies
A change in recent years has come about owing to criticisms of the process-driven
methodologies (such as PRINCE2 and scalable methodology) because they lacked the capacity
to adapt as the project developed. New agile methodologies were developed, which allow the
project to adapt to changes in the changing environment and business challenges. Although they
are seen as contrasting with the process methodologies, they are actually considered to be ‘half-
way’ between a process methodology and no methodology.
Chapter 4: Methods of Project Management
Page | 131
Agile methodologies are defined as being:
Adaptive rather than predictive – Agile approaches welcome changes, rather than have fixed
plans.
Focused on people rather than process – Process methods focus the process set, and anyone
could implement the plans. Agile approaches recognise that people have skills that can add to
the project as it progresses.
Adaptive Project Framework (ADF): ADF is a customer-focused methodology, which is based
on being:
- Client focused and client-driven
- Frequent and early results reporting
- Focused on questioning and introspection
- Change is good, when it is moving to a better solution
ADF allows project scope to vary within defined time and cost levels. The project scope is
reviewed in several iterations, by involving the client in identifying the issues that are of most
value to the business. This means that the project changes course to deliver the maximum
business value.
This approach was developed for IT projects, after many of them failed to deliver using the
traditional and more rigid methodologies. However, its focus and flexibility make it appropriate
for projects.
3 Choosing a methodology
The choice of a project methodology is commonly set given the preferences of the
commissioning organisation.
However, if you have an open choice of methodology, you should consider the following issues
to make an informed choice:
Availability of software
Number of team members
Team member communications
Chapter 4: Methods of Project Management
Page | 132
Complexity of the task
Training required to effectively utilise the methodology
Cost of the methodology to acquire or use
4 Project management plan
The project management plan is the document that the project manager builds to describe in
more details the planning of the project and its organisation.
Without careful planning it is likely that your project will fail to achieve its objectives. In a small
project it is possible that one plan may be used to define the entire scope of work and all the
resources needed to carry out that work. For larger projects, planning will be carried out at
different levels of detail at different times. In all types and sizes of project you must be prepared
to re-plan in the light of experience.
Remember that plans are essential for ongoing project control and must be used and kept up to
date right through the life of the project.
The Project Plan will typically contain the following:
Plan Description (a brief narrative description of the plan's purpose and what it covers)
Pre-requisites (things that must be in place for the plan to succeed)
External dependencies (e.g. commitments required from outside agencies)
Planning Assumptions (e.g. availability of resources)
Gantt/Bar chart showing Stages and/or Activities
Financial budget - planned expenditure
Resource requirements (e.g. in a table produced using a spreadsheet or project planning
tool)
Requested/assigned specific resources
4.1 The steps in planning
Planning should be carried out in the order shown but bear in mind that iteration around some
or all of the steps will be necessary for all but the simplest of plans.
Make sure you understand the project's desired outcome, scope, objectives, constraints,
assumptions and the purpose and level of detail of the plan you must produce.
Define the deliverables to be created as a result of the plan.
Specify the activities necessary to develop the deliverables.
Put the activities in a logical sequence taking into account interdependencies.
Estimate resource requirements (people, skills, effort, money and other things that will
be needed to carry out each activity).
Chapter 4: Methods of Project Management
Page | 133
Estimate the timescale for each activity (e.g. elapsed duration).
Schedule the work from the target start date onwards.
Define project management progress controls and decision points.
Identify and deal with risks and uncertainties.
Document the plan.
Gain approval to proceed with the plan.
The following detailed checklist will help you through these steps.
4.2 Planning checklist
This checklist may be used when planning an entire project, a phase/stage within a project, an
activity within a stage/phase or a task that contributes towards completion of an activity. You
might also find it useful if you are applying project management techniques to help you manage
non-project work.
(a) Confirm scope and purpose of the plan
Are you clear about the purpose of the plan? (e.g.: to gain commitment and approval for a
project/stage, for day to day management and control, to establish feasibility or viability, to
define contingency arrangements)
Do you understand the objectives to be met by the plan?
Is it clear what is within the scope of the piece of work you are planning?
Are there any constraints (e.g. resource availability, mandated delivery dates)?Do you
understand the high-level structure of the plan (e.g. for a procurement stage it might be:
Specify requirements: Invite tenders: Evaluate tenders: Award contract)?
Are there any assumptions you must make in order to construct the plan?
(b) Define the deliverables
Identify the final, and any interim, deliverables required from the project
Specify for each deliverable:
- What it must contain/cover
- Who will be responsible for its development
- What it is dependant on (e.g. information, resources)
- The required quality characteristics that must be built in to it
- The types of quality checks to be applied
Chapter 4: Methods of Project Management
Page | 134
- The skills, resources, individuals needed to develop the deliverable and to apply the
quality checks
Establish the logical order for development of the deliverables (what must be developed in
sequence, what can be done in parallel).
(c) Identify and estimate activities:
Consider need to involve experts who will understand the detail of the development
processes (e.g. Policy, Lawyers, IT staff, Procurement specialists)
Identify all the activities necessary to develop each deliverable
Identify all the activities necessary to quality control each deliverable
Agree the order in which activities must be carried out
Include activities that take into account the interest of stakeholders who will use, operate and
maintain the deliverables from the project
Break down `large' activities that are difficult to estimate into sets of smaller activities of a
size you can estimate resource requirements and durations with confidence
Identify the skill types required to carry out each activity
Estimate the amount of effort and optimum numbers of individuals
Identify and estimate any non-human resources and services required
If required, calculate the estimated cost to develop each deliverable/product
Calculate the overall cost for all activities
Make sure you use appropriate units taking into account staff availability:
- e.g. 3 x policy staff each required to commit 10 days of effort for an activity and able to
work on the project for 25% of their time: total effort = 30 person days, minimum elapsed
time = 40 working days = 8 working weeks.
Make sure you have made appropriate allowances for such things as:
- Formal consultations
- Turnaround times for ministerial submissions
- ‘Dead time’ (e.g. elapsed time while ‘external’ agencies review proposals consider
recommendations, provide responses, make decisions)
- Supplier lead times
- A realistic working week (i.e. over an extended period you will not achieve 5 days of
effort per individual per working week. - a figure of 4 to 4.5 working days per week allows
Chapter 4: Methods of Project Management
Page | 135
for `non productive' activities such as attending training courses, sick leave, holidays, job
appraisal and non project meetings)
- Participation in progress meetings and quality control activities?
(d) Schedule the work and resources
Has your scheduling of activities been based on a realistic start date and does it allow for
weekends, Bank Holidays and other non-working days?
Will the resources/skills be available in sufficient quantities when you need them?
Are there any internal and/or external stakeholder tasks/events that coincide with the project
and will limit the availability of resources?
Are any individuals scheduled to work on other projects when you need them?
Will any individuals or skill/types be overloaded with project work at any time?
Have you adjusted the timing and allocation of work to spread the load evenly?
Can you meet your time constraints/target delivery dates?
Do you need to include recruitment, procurement, training or induction activities?
(e) Identify risks and design controls:
Is it clear when the SRO/ Project Board must review viability and take decisions?
Would it be sensible to break your project down into a series of separately planned stages to
minimise risk and enable SRO/ project Board control?
Have you identified key milestones? (e.g. deliverable sign-offs)
Does the plan identify formal quality controls and audit activities?
Have you identified any risks that may prevent you executing the plan and delivering:
- to the required specification and ability to deliver benefits?
- on time?
- within budget?
- without damaging the organisation's reputation?
Are you confident partner organisations and/or external suppliers will meet their
commitments in accordance with the plan?
Does your plan allow contingency (time and effort) to allow for the fact that you will identify
the need for new unplanned activities when you execute the plan?
Does the amount of contingency you have allowed reflect the degree of uncertainty you have
about the accuracy of your estimates for effort, costs, timescales?
Chapter 4: Methods of Project Management
Page | 136
Can you forecast any events in the business year which coincide with important activities in
your plan (e.g. recess, audits, end of year reporting?
Have all resource 'owners' committed to the plan?
(f) Document and gain approval for the plan
Is the plan to a form that will be understood by its audience?
Does the version of a plan for the SRO/Project Board include, as a minimum:
- Narrative describing the purpose, author(s), current status, assumptions, constraints, pre-
requisites, recommendations and next actions required
- Definition of deliverables
- Risk assessment and countermeasures
- Gantt/bar chart(s) showing a schedule of major activities.
- Resource schedules showing resource requirements against time
Does the working plan for project and team management go to a fine enough level of detail
for management and control purposes? (e.g. the lowest level of plan for day to day control
should have activities of no more than 10 elapsed days duration, allocated to a named
individual or small defined team)
Is your plan acceptable to those who must:
- provide the staff?
- provide non-human resources/services?
- commit financial resources?
- do the work to create the deliverables?
An example of a simple project management plan is shown below. This plan is able produced by
the American to manage a project to produce formal project management principles.
The project management plan evolves over time. A high-level plan for the whole project and a
detailed plan for the current and following stage is usually produced soon after project start-up.
At each subsequent stage a detailed plan is produced for the following stage and, if required, the
overall project plan is revised.
Table: Project planning template
Chapter 4: Methods of Project Management
Page | 137
Project management plan
Project name The full name of this project is ‘Project Management Principles’.
Project manager The project manager is Joe Bloggs. The project manager is authorised
to (1) initiate the project, (2) form the project team and (3) prepare
and execute plans and manage the project as necessary for successful
project completion.
Purpose/Business
need
This project addresses a need for high-level guidelines for the project
management profession through the identification and presentation
of project management principles. The project sponsor and accepting
agent is the Project Institute (PI) Standards Program Team (SPT). The
principal and beneficial customer is the membership of PI. Principles
are needed to provide high-level context and guidance for the
profession of project management. These Principles will provide
benefit from the perspectives of practice, evaluation, and
development.
Project
management
The project team will use project methodology consistent with PMI
Standards. The project is to be managed with definitive scope and
acceptance criteria fully established as the project progresses and the
product is developed.
Assumptions,
constraints and
risks
The project faces some increased risk that without a clearly prescribed
definition of a Principle, standards for product quality will be more
difficult to establish and apply. To mitigate this risk, ongoing
communication between the project team and the project sponsor on
this matter will be required.
Chapter 4: Methods of Project Management
Page | 138
Resources The PI SPT is to provide the project team with the following.
Financial. SPT will provide financial resources as available. The initial
amount for the current year is $5,000. The project manager must not
exceed the allocated amount, and notify the SPT when 75% of the
allocation has been spent.
Explanation of Standards Program. SPT will provide guidance at the
outset of the project, updates as changes occur, and clarifications as
needed.
Personnel/Volunteers. SPT will recruit volunteer team members from
within the membership of PMI through various media and liaisons.
The project team is to consist of no less than ten members, including
the project manager. General qualifications to be sought by SPT in
recruiting will be:
Mandatory
Acceptance of project plan
Demonstrated capability for strategic, generalised or intuitive
thinking
Capability to write clearly on technical subject matter for general
audiences
Capability to work co-operatively with well-developed
interpersonal skills
Be conversant in English and be able to use telephone and
internet email telecommunications
As possible
Time availability (Team members may contribute at different
levels. An average of approximately five to ten hours per month
is desired.)
Diversity (Team members collectively may represent diverse
nationalities, types of organisations or corporate structure,
business sectors, academic disciplines, and personal experience.)
Travel (As determined mutually by the project sponsor and manager,
some travel for face-to-face meetings may be requested.)
Chapter 4: Methods of Project Management
Page | 139
Approach The project will progress through the following phases.
Phase 1: Team formation – Recruit and orient volunteer team
members. Establish procedures and ground rules for group process
and decision making.
Phase 2: Subject matter clarification – Identify and clarify initial
scope and definitions of project subject matter.
Phase 3a: Exploration – Begin brainstorming (through gathering,
sharing, and discussion) of data and views in unrestricted, non-
judgemental process. Phase 3b: Selection – Conclude brainstorming
(through evaluation and acceptance or rejection) of collected data
and views. As the conclusion to this phase, the SPT will review as an
interim deliverable the selection made by the project team.
Phase 4: Development – Conduct further research and discussion to
develop accepted subject matter.
Phase 5: Articulation – Write a series of drafts to state the accepted
and developed subject matter as appropriate for the project business
need and product description.
Phase 6: Adoption – Submit product to SPT for the official PI
standards approval and adoption process. Revise product as needed.
Phase 7: Closeout – Perform closure for team and administrative
matters.
Deliver project files to SPT.
Chapter 4: Methods of Project Management
Page | 140
Communication
and reporting
The project manager and team will communicate with and report to
the PI Standards Program Team as follows.
Monthly status reports – Written monthly status and progress
reports are to include:
Work accomplished since the last report
Work planned to be performed during the next reporting period
Deliverables submitted since the last report
Deliverables planned to be submitted during the next reporting
period
Work tasks in progress and currently outside of expectations for
scope, quality, schedule or cost
Risks identified and actions taken or proposed to mitigate
Lessons learned
Summary statement for posting on PI website
Monthly resource reports – Written monthly resource reports are to
include:
Financial resources
Total funds allocated
Total funds expended to date
Estimated expenditures for the next reporting period
Estimated expenditures for entire project to completion
Milestone and critical status reports – Additional status reports are
to be submitted as mutually agreed upon by SPT and the project
manager and are to include at least the following items.
Milestone status reports are to include the same items as the monthly
status reports, summarised to cover an entire project phase period
since the last milestone report, or entire project to date.
Critical status reports are to focus on work tasks outside of
expectations and other information as requested by SPT or stipulated
by the project manager.
Acceptance The project manager will submit the final product and any interim
deliverables to the Standards Program Team (SPT) for formal
acceptance. The SPT may (1) accept the product as delivered by the
project team, or (2) return the product to the team with a statement
of specific requirements to make the product fully acceptable. The
Chapter 4: Methods of Project Management
Page | 141
acceptance decision of the SPT is to be provided to the project
manager in writing.
Change
management
Requests for change to this plan may be initiated by either the project
sponsor or the project manager. All change requests will be reviewed
and approved or rejected by a formal proceeding of the Standards
Program Team (SPT) with input and interaction with the project
manager. Decisions of the SPT will be documented and provided to
the project manager in writing. All changes will be incorporated into
this document, reflected by a new version number and date.
Table PSC Project sign-off card
Plan acceptance Signature and Date
By PMI Standards Program Team
12 July 20XX
Fred Jones – Pl Technical Research & Standards Manager
By Project Manager
20 July 20XX
Joe Bloggs – Pl member
The format and contents of a project management plan will vary depending on the organisation
involved and the complexity of the project.
Chapter 5: Project Management Tools and Techniques
Page | 142
Chapter 5: Project Management Tools and
Techniques
Topics covered in the chapter:
Management tools and techniques for project
Determining resource checklist for projects
Gantt charts, network analysis
The critical path, project evaluation review technique (PERT), resource histogram
Chapter 5: Project Management Tools and Techniques
Page | 143
1 Management tools and techniques
The techniques we discuss in this section are concerned with the fundamentals of planning
projects and controlling their progress. As with most activities, it is difficult to separate the
process of planning a project from that of controlling it: planning is likely to continue throughout
the life of the project. A baseline plan will show the following:
a) Start and end dates for the project and its major phases or activities
b) The resources needed and when they are required
c) Estimates of cost for the project and the major phases or activities
Several books report on planning mistakes, many of which come from poorly planned projects.
Good planning is essential for project success, as is clear in the 6 Ps of project management: Prior
Planning Prevents Poor Project Performance (this may be also be familiar in a rather more earthy
form).
Often, the problems start with vague or poor project definition. Typically, projects have requests
such as:
(a) Prepare a communications plan for a new product launch or
(b) Develop an improved new product development process
At one level, these seem fine. However, exploring these further highlights issues that must be
addressed before planning can be undertaken.
What sort of communications plan?
What targets – trade or consumer markets?
What timescale?
Are there any specific media to be used or avoided?
What is meant by improved?
How would this project be measured?
Initial scoping helps identify some aspects of the project, but this next stage of planning adds to
the detail for the project plan and clarifies more precisely what is involved. There is an old saying
Chapter 5: Project Management Tools and Techniques
Page | 144
that ‘the devil is in the detail’ and it is certainly true that you will have the devil of a time trying
to successfully manage a project if you fail to pay attention to detail.
The general process of project planning is the structure of this chapter.
1. Determining the work breakdown structure
2. Estimating timing and task duration
3. Determining resource requirements
4. Allocating responsibilities
5. Sequencing work
6. Developing the project schedule or network
7. Preparing the integrated planning document
The key project management tools will be identified within these headings.
2 Determining the work breakdown structure
The key element of good project plans is the work breakdown structure. WBS can be defined as:
'A Deliverable-oriented grouping of project elements that organises and defines the total work
scope of the project. Each descending level represents an increasingly detailed definition of the
project work’.
In his book Project Management: Planning and Control Techniques, Rory Burke (2003) argued a
structure that is based on the four project phases of Concept, Design, Implementation and
Handover. He contends that each of these individual phases can also be broken down into the
full four at a subproject level. Let us take the concept phase as an example. It would include within
it the original idea, but that idea would need to be checked and researched to put an overview
together. That rough design overview needs to be built into enough of a case to allow the project
to gain approval, and that is the implementation that is aimed for. Once that has been gained,
then there is a handover to those responsible for the next stage in the process.
The WBS is a structured hierarchy of the work that needs to be accomplished on a project. This
organises work in an organisational chart-type structure, with different levels showing how goals,
objectives, topics etc. can be broken down into increasingly detailed activities (see Figure WBS).
Chapter 5: Project Management Tools and Techniques
Page | 145
1. Define the needs – what do we need to allocate to the system and what do we need in return?
What do we want from the software package?
What are the IT requirements e.g. compatibility?
What does the sales team expect to get?
How will we able to fit it in to our overall processes?
We must remember that the customer is the C in CRM
What are the hardware requirements – do we need to upgrade?
2. Research the suppliers that potentially have suitable software/hardware to satisfy our needs
Shortlist those suppliers we will invite to bid after more detailed research e.g. costs,
testimonials, Product limitations.
(Note that this is only the start of the structure for illustrative purposes and it may go down
through many more levels until it is broken down into discrete work pack ages. You may also
note that the text that follows the diagram reflects the hierarchic al structure of the diagram.)
The WBS will go down through a series of levels until the project tasks produce manageable
outputs. These are called work packages. Work packages are normally viewed as being
deliverables or products at the lowest level of the WBS. Deliverables are the tangible outputs
from work, which are normally then signed off as complete. This may be a milestone – the end of
a period of work.
Chapter 5: Project Management Tools and Techniques
Page | 146
Identifying the work packages forms the foundation for developing schedules, budgets and
resource requirements, and also forms the foundation for assigning responsibilities.
Work packages can be split into activities or tasks that are used to create a workflow. These
contrast with activities and tasks, which are about what is involved in doing work.
Figure BPP looks at the process that would be involved in the purchasing of the CRM software
outlined in Figure WBS It considers a traditional purchasing of traditional physical goods with the
alternative of buying software. Again, remember that it is included as an illustration, and you may
very well see variations in your organisation.
Some people refer to the 80-hour rule to make the decision about the bottom level. The bottom
level of a WBS should identify 80 hours or fewer of work. This WBS is the foundation for the other
elements of the project plan. The project manager’s mantra states that ‘if it is not in the WBS,
Chapter 5: Project Management Tools and Techniques
Page | 147
then it is not in the plan’. Clearly, there must be attention to this for the project to be successful,
but you may well miss some issues if you are new to project management.
Seek advice from others to check that this is not a major issue.
Some key things to review concerning a WBS are:
Does the WBS go outside the scope of the project?
Does the WBS cover the entire scope of the project?
Does the WBS ultimately result in deliverables?
2.1 Dependencies and interactions
A very important aspect of project planning is the determination of dependencies and
interactions. At any level of WBS analysis, some tasks will be dependent on others; that is to say,
a dependent task cannot commence until the task upon which it depends is completed. Careful
analysis of dependencies is a major step towards a workable project plan, since it provides an
order in which things must be tackled. Sometimes, of course, the dependencies are limited and
it is possible to proceed with tasks in almost any order, but this is unusual. The more complex a
project, the greater the need for analysis of dependencies.
Interactions are slightly different; they occur when tasks are linked but not dependent. This can
arise for a variety of reasons: a good example is a requirement to share the use of a scarce
resource. If there were two of us working on our vegetable plot but we only possessed one spade,
we could not use it simultaneously both to cultivate the plot itself and to dig the trench in which
we wish to place the kerbstones. We could choose to do either of these activities first, but we
could not do them both at the same time.
The output from the WBS process is a list of tasks, probably arranged hierarchically to reflect the
disaggregation of activities. This then becomes the input into the planning and control processes
described in the rest of this section.
2.2 PRINCE2 – product breakdown
Rather than using work breakdown structure, PRINCE2 uses a product-based approach to
planning. This has the advantage of directing management attention to what is to be achieved
rather than how to do it, thus providing an automatic focus on achieving the product goals. Also,
it can be helpful in complex projects, where the processes involved may be initially unclear. Under
Chapter 5: Project Management Tools and Techniques
Page | 148
this approach, work breakdown is preceded by product breakdown. PRINCE2 starts this analysis
by dividing the project products into three groups.
a) Technical products are the things the project has been set up to provide to the users. For an
IT system, for example, these would include the hardware, software, manuals and training.
b) Quality products define both the quality controls that are applied to the project and the
quality Standards the technical products must achieve.
c) Management products are the artefacts used to manage the project. They include the project
management organisation structure, planning documentation, reports and so on.
Each of these groups of products is then broken down into manageable components as part of
the planning process, using the traditional work breakdown structure approach if the complexity
of the project requires it. Project and stage plans may make use of the normal planning tools
such as CPA, Gantt charts and resource histograms.
2.3 Estimating timing and task duration
Project duration defines the length of time (in hours, days, weeks or months) to complete an
activity. Typically, in any projects, the deadline will be set, such as to launch in time for a Christmas
holiday or before the Olympics. Working back from the set deadlines is stressful for a project
manager, and often for all other members of the project team too.
Task and activity duration also needs to be determined for planning purposes. Estimating the
task duration for work packages is one of the most difficult things for a novice project manager.
There are several ways to try and determine this:
Consider similar activities for which you have information about the task duration. However,
this may not be possible for all tasks.
Historical data may identify how long tasks or activities have taken in the past. However,
some project tasks may be new tasks.
Expert advice – or knowledge – from senior managers can give indications of the likely – or
desired – outcomes.
Problems with establishing time periods include:
Lack of experience in planning time du ration for tasks, and in doing activities.
Chapter 5: Project Management Tools and Techniques
Page | 149
Clearly, novices will typically take longer than experienced workers to do the same tasks, and
may be unaware of the problems that take time. Clearly, lack of experience here can lead to
unrealistic timescales.
Complexity of the problems – often these involve creative tasks, for which focusing on time
may detract from quality.
Unexpected events or delays due to illness etc. Also, mistakes or other problems can add to
the time needed. Contingencies may have to be built into the systems.
Novices tend to underestimate the amount of work involved in any tasks. Expert project
managers tend to use the longest predicted duration in scheduling, as this allows for possible
delays.
There is a dual issue here. It is very difficult to judge the time taken for new projects or new
activities or tasks. Some tasks involved in marketing activities – such as creative work – are
especially difficult to do ‘to a timescale’. This in turn will impact on the feasibility of the project
completion date.
2.4 Determining requirements – a resource checklist
Project resourcing clearly varies depending on the type and size of projects. The central issue in
identifying this is using the WBS and estimated timings to determine the resource requirements
to complete the project on time and budget:
a) The people to be involved in the project, the level of their commitment, and the required
level of skills.
b) The facilities for the project planning, and depending on the project, its implementation.
c) The equipment required, such as computers, cameras, or other audio-visual equipment.
d) The money – a budget needed to complete the task. There will often be an iterative process
to determine budgets, taking account of the costs, timescales etc.
e) The materials – what tangibles, consumables or other items will be required in the process.
The resources need to be determined at this stage, and this becomes a reference point for
monitoring resource use once the project starts. While the WBS tends to work top-down, many
argue that resources should be determined from the bottom-up. Contingencies may need to be
built in for some resources.
Chapter 5: Project Management Tools and Techniques
Page | 150
3 Sequencing work
The tasks so far have complexities, but the real difficulties in project planning come through
scheduling. Scheduling is essentially about the links between and among activities/tasks and or
people and organisations. Some work tasks will be completed in parallel, while others will be
dependent on the completion of other activities.
Scheduling examines the sequence of tasks, both independent and interrelated, that will be
undertaken. This is then organised into a series of sub schedules and charts, which can be
prepared from the master plan, detailing what will happen when, by whom, and detailing the
interfaces and the milestones for the tasks.
For example, a brochure cannot be printed until the content has been prepared. The content
cannot be prepared until a copywriter has been appointed and the R&D team has provided the
product information. However, a printer can be sourced while the copy is being written.
Once you know what needs to be done, you need to examine the work involved to determine:
Predecessor tasks: those required for another task to be completed.
Successor tasks: those that cannot start until another task has been completed.
The schedule can be prepared once this workflow is established. The schedule becomes a key
tool in managing progress.
Detailed scheduling turns the project plan into action plans, on the basis of the WBS. Each WBS
task is normally named and numbered, and the duration of tasks, any lead or lag times, and
resources and budget involved must be estimated in order for a detailed schedule to be
undertaken. Clearly, this reinforces the need for good time and resource estimates. Each WBS
task should become the responsibility of a named individual.
However, schedules will often feature ideal start dates and late finish dates. Ideal start dates are
the latest dates for an activity to start, if delays are to be avoided. Late finish dates are the latest
dates for an activity to finish without causing delays in the project.
Later in the project, revised schedules are prepared as issues emerge. Rescheduling does not
always result in delays in completion, as contingencies – for time or budget – may be built into
the project plan. However, if the delays exceed this, and there is no flexibility with the de livery
Chapter 5: Project Management Tools and Techniques
Page | 151
date or resources, terminating the project should be considered. Many tools are used to present
schedules.
3.1 Gantt charts
Gantt charts are a visual planning tool useful for projects but are limited in their use as they do
not recognise the interrelations between tasks.
A Gantt chart, named after the engineer Henry Gantt who pioneered the procedure in the early
1900s, is a horizontal bar chart used to plan the time scale for a project and to estimate the
resources required.
The Gantt chart displays the time relationships between tasks in a project. Two lines are usually
used to show the time allocated for each task, and the actual time taken.
A simple Gantt chart, illustrating some of the activities involved in a network server installation
project, follows.
The chart shows that at the end of the tenth week Activity 9 is running behind schedule. More
resources may have to be allocated to this activity if the staff accommodation is to be ready in
time for the changeover to the new system.
Chapter 5: Project Management Tools and Techniques
Page | 152
Activity 4 has not been completed on time, and this has resulted in some disruption to the
computer installation (Activity 6), which may mean further delays in the commencement of
Activities 7 and 8.
3.2 Network analysis
Network analysis, also known as Critical Path Analysis (CPA), is a useful technique to help with
planning and controlling large projects, such as construction projects, research and development
projects and the computerisation of systems.
Network analysis requires breaking down the project into tasks with estimated durations and
establishing a logical sequence. This enables the minimum possible duration of the project to be found.
CPA aims to ensure the progress of a project, so the project is completed in the minimum
amount of time.
It pinpoints the tasks which are on the critical path, ie those tasks which, if delayed beyond the
allotted time, would delay the completion of the project as a whole. The technique can also be
used to assist in allocating resources such as labour and equipment.
Critical path analysis is quite a simple technique. The events and activities making up the whole
project are represented in the form of a diagram. Drawing the diagram or chart involves the
following steps.
Step 1 Estimating the time needed to complete each individual activity or task that
makes up a part of the project.
Step 2 Sorting out what activities must be done one after another, and which can
be done at the same time, if required.
Step 3 Representing these in a network diagram.
Step 4 Estimating the critical path which is the longest sequence of consecutive
activities through the network.
Chapter 5: Project Management Tools and Techniques
Page | 153
3.3 The critical path
The duration of the whole project will be fixed by the time taken to complete the largest path
through the network. This path is called the critical path and activities on it are known as critical
activities.
Activities on the critical path must be started and completed on time; otherwise the total project
time will be extended.
Network analysis shows the sequence of tasks and how long they are going to take. The diagrams
are drawn from left to right. To construct a network diagram you need to know the activities
involved in a project, the expect time of each order (or precedences) of the activities.
3.3.1 Example
The table below shows the Activities, time scales and precedences of a particular project.
This information could be used to construct the network diagram shown below the table.
Activity Expected time Preceding activity
A 3 –
B 5 –
C 2 B
D 1 A
E 6 A
F 3 D
G 3 C,E
Points to note from the diagram:
a) Events (e.g. 1 and 2) are represented by circles. Tasks (e.g. A) connect events.
Chapter 5: Project Management Tools and Techniques
Page | 154
b) The critical path may be shown by drawing a small vertical line through the arrow or by
making arrows on the critical path thicker. The critical path is the longest (in terms of time)
path through the network – which is the minimum amount of time that the project will take.
c) It is the convention to note the earliest start date of any task in the top right hand corner of
the circle.
d) We can then work backwards identifying the latest dates when tasks could start. These we
insert in the bottom right quarter of the circle.
The critical path in the diagram above is AEG.
Note the float time of five days for Activity F. Activity F can begin any time between days 4 and
9, thus giving the project manager a degree of flexibility. The diagram above uses 'Activity on
line' notation – as Activities are shown on the lines or arrows that connect events.
3.4 Activity-on-node presentation
Network diagrams may also be drawn using Activity-on-node presentation which is similar in
style to that used by the Microsoft Project software package.
3.4.1 Example: Activity on Node
Suppose that a project includes three activities, C, D and E. Neither activity D nor E can start until
activity C is completed, but D and E could be done simultaneously if required.
This would be represented as follows
Note the following.
(a) An activity within a network is represented by a rectangular box. (Each box is a node.)
(b) The 'flow' of activities in the diagram should be from left to right.
(c) The diagram clearly shows that D and E must follow C.
Chapter 5: Project Management Tools and Techniques
Page | 155
A second possibility is that an activity cannot start until two or more activities have been
completed. If activity H cannot start until activities G and F are both complete, then we would
represent the situation like this.
3.4.2 Example showing start and end nodes
Draw a diagram for the following project. The project is finished when both D and E are complete.
Activity Preceding activity
A -
B –
C A
D B & C
E B
The first solution that follows excludes start and end nodes – the second solution includes them.
Solution
Microsoft Project style
With start and end nodes
Chapter 5: Project Management Tools and Techniques
Page | 156
Any network can be analysed into a number of different paths or routes. A path is simply a
sequence of activities which can take you from the start to the end of the network.
In the example above, there are just three possible routes or paths (based on the precedences
given earlier).
a) A C D.
b) B D.
c) B E.
3.5 Showing the duration of activities
The time needed to complete each individual activity in a project must be estimated. This duration
may be shown within the node as follows. The meaning of the other boxes is explained later.
Task A
ID 6 days
Note that there are a range of acceptable notation styles for network diagrams. You should learn
the principles of the technique so you are able to interpret diagrams presented in a variety of
formats (with an explanatory key).
3.5.1 Example: The critical path
Activity Immediately preceding activity Duration (weeks)
A - 5
B - 4
C A 2
Chapter 5: Project Management Tools and Techniques
Page | 157
D B 1
E B 5
F B 5
G C, D 4
H F 3
I F 2
a) What are the paths through the network?
b) What is the critical path and its duration?
Solution
The first step in the solution is to draw the network diagram, with the time for each activity shown.
We could list the paths through the network and their overall completion times as follows.
Path Duration (weeks)
AC G (5 + 2 + 4) 11
BD G (4 + 1 + 4) 9
B E (4 + 5)
B F H (4 + 5+ 3) 2
B F I (4 + 5 + 2 + 0) 1
The critical path is the longest, BFH, with a duration of 12 weeks. This is the minimum time needed
to complete the project.
The critical path may be indicated on the diagram by drawing thick (or double-line) arrows, or by
the addition of one or two small vertical lines through the arrows on the critic al path. In Microsoft
Project the arrows and the nodes are highlighted in red.
Chapter 5: Project Management Tools and Techniques
Page | 158
Listing paths through the network in this way should be easy enough for small networks, but it
becomes a long and tedious task for bigger and more complex networks. This is why software
packages are used in real life.
Conventionally it has been recognised as useful to calculate the earliest and latest times for
activities to start or finish, and show them on the network diagram. This can be done for networks
of any size and complexity. Project management software packages offer a much larger variety
of techniques than can easily be done by hand. Microsoft Project allows each activity to be
assigned to any one of a variety of types: 'start as late as possible', 'start as soon as possible',
'finish no earlier than a particular date', 'finish no later than a particular date', and so on.
In real life, too, activity times can be shortened by working weekends and overtime, or they may
be constrained by non-availability of essential personnel. In other words with any more than a
few activities the possibilities are mind-boggling, which is why software is used.
Nevertheless, a simple technique is illustrated in the following example.
3.5.2 Example: Earliest and latest start times
One way of showing earliest and latest start times for activities is to divide each event node into
sections. This is similar to the style used in Microsoft Project except that Project uses real dates,
which is far more useful, and the bottom two sections can mean a variety of things, depending
what constraints have been set.
These sections record the following things.
a) The name of the activity, for example Task A. This helps humans to understand the
diagram.
b) An ID number which is unique to that activity. This helps computer packages to understand
the diagram, because it is possible that two or more activities could have the same name.
For instance two bits of research are done at different project stages might both be called
'Research'.
c) The duration of the activity.
d) The earliest start time. Conventionally for the first node in the network, this is time 0.
e) The latest start time.
Chapter 5: Project Management Tools and Techniques
Page | 159
(Note: Don't confuse start times with the 'event' times that are calculated when using the
activity on-arrow method, even though the approach is the same.)
Task D
ID number: 4 Duration: 6 days
Earliest start: Day 4 Latest start: Day 11
3.5.3 Earliest start times
To find the earliest start times, always start with activities that have no predecessors and give
them an earliest starting time of 0. In the example we have been looking at, this is week 0.
Then work along each path from left to right through the diagram calculating the earliest time
that the next activity can start. For example, the earliest time for activity C is week 0 + 5 = 5. The
earliest time activities D, E and F can start is week 0 + 4 = 4.
To calculate an activity's earliest time, simply look at the box for the preceding activity and add
the bottom left figure to the top right figure. If two or more activities precede an activity take the
highest figure as the later activity's earliest start time: it cannot start before all the others are
finished!
3.5.4 Latest start times
The latest start times are the latest times at which each activity can start if the project as a whole
is to be completed in the earliest possible time, in other words in 12 weeks in our example.
Work backwards from right to left through the diagram calculating the latest time at which the
activity can start, if it is to be completed at the latest finishing time. For example the latest start
time for activity H is 12 – 3 = week 9 and for activity E is 12 – 5 = week 7.
Activity F might cause difficulties as two activities, H and I, lead back to it.
a) Activity H must be completed by week 12, and so must start at week 9.
b) Activity I must also be completed by week 12, and so must start at week 10.
c) Activity F takes 5 weeks so its latest start time F is the either 9 – 5 = week 4 or 10 – 5 = week
5. However, if it starts in week 5 it not be possible to start activity H on time and the whole
project will be delayed. We therefore take the lower figure.
Chapter 5: Project Management Tools and Techniques
Page | 160
The final diagram is now as follows.
Critical activities are those activities which must be started on time, otherwise the total project
time will be increased. It follows that each event on the critical path must have the same earliest
and latest start times. The critical path for the above network is therefore B F H.
3.5.5 Criticisms of critical path/network analysis
The following criticisms are often made in relation to network analysis.
a) It is not always possible to devise an effective WBS for a project.
b) It assumes a sequential relationship between activities. It assumes that once Activity B starts
after Activity A has finished. It is not very good at coping with the possibility that an activity
'later' in the sequence may be relevant to an earlier activity.
c) There are problems in estimation. Where the project is completely new, the planning
process may be conducted in conditions of relative ignorance.
d) Although network analysis plans the use of resources of labour and finance, it does not
appear to develop plans for contingencies, other than crashing time .
e) CPA assumes a trade-off between time and cost. This may not be the case where a
substantial portion of the cost is indirect overheads or where the direct labour proportion
of the total cost is limited.
3.5.6 Example: Network analysis and Gantt charts
This example is provided as an illustration of how Gantt charts may be used to manage resources
efficiently. A company is about to undertake a project about which the following data is available.
Activity Preceded by activity Duration Day Workers required
A - 3 6
Chapter 5: Project Management Tools and Techniques
Page | 161
B - 5 3
C B 2 4
D A 1 4
E A 6 5
F D 3 6
G C, E 3 3
There is a multi-skilled workforce of nine workers available, each capable of working on any of
the activities. Draw the network to establish the duration of the project and the critical path. Then
draw a Gantt chart, using the critical path as a basis, assuming that jobs start at the earliest
possible time.
Solution
Here are the diagrams.
It can be seen that if all activities start at their earliest times, as many as 15 workers will be required
on any one day (days 6-7) whereas on other days there would be idle capacity (days 8-12). The
problem can be reduced, or removed, by using up spare time on non-critical activities. Suppose
we deferred the start of activities D and F until the latest possible days. These would be days 8
and 9, leaving four days to complete the activities by the end of day 12.
The Gantt chart would be redrawn as follows.
Chapter 5: Project Management Tools and Techniques
Page | 162
3.6 Project evaluation review technique (PERT)
Project evaluation and review technique (PERT) is a technique for allowing for uncertainty in
Determining project duration. Each task is assigned a best, worst, and most probable completion
time estimate. These estimates are used to determine the average completion time. The average
times are used to establish the critical path and the standard deviation of completion times for
the entire project.
PERT is a modified form of network analysis designed to account for uncertainty. For each activity
in the project, optimistic, most likely and pessimistic estimates of times are made, on the basis of
past experience, or even guess-work. These estimates are converted into a mean time and also a
standard deviation.
Once the mean time and standard deviation of the time have been calculated for each activity, it
should be possible to do the following.
a) Estimate the critical path using expected (mean) activity times.
b) Estimate the standard deviation of the total project time.
3.7 Resource histogram
A useful planning tool that shows the amount and timing of the requirement for a resource (or a
range of resources) is the resource histogram.
A resource histogram shows a view of project data in which resource requirements, usage,
and availability are shown against a time scale.
Chapter 5: Project Management Tools and Techniques
Page | 163
A simple resource histogram showing programmer time required on a software development
program is shown below.
Some organisations add another bar (or a separate line) to the chart showing resource
availability.
The chart then shows any instances when the required resource hours exceed the available hours.
Plans should then be made to either obtain further resource for these peak times, or to re-
schedule the work plan. Alternately the chart may show times when the available resource is
excessive, and should be re-deployed elsewhere. An example follows.
Chapter 5: Project Management Tools and Techniques
Page | 164
The number of workers required on the seventh day is 13. Can we re-schedule the non- critical
activities to reduce the requirement to the available level of 10? We might be able to re-arrange
activities so that we can make use of the workers available from day 9 onwards.
3.8 Float times and costs
Float time is the time built in to allow for unforeseen circumstances.
a) Total float on a job is the time available (earliest start date to latest finish date) less time
needed for the job. If, for example, job A's earliest start time was day 7 and its latest end time
was day 17, and the job needed four days, total float would be: (17~ 7) ~ 4 = 6 days
b) Free float is the delay possible in an activity on the assumption that all preceding jobs start
as early as possible and all subsequent jobs also start at the earliest time.
c) Independent float is the delay possible if all preceding jobs have finished as late as possible,
and all succeeding jobs have started as early as possible.
Chapter 6: Project Control and Evaluation
Page | 165
Chapter 6: Project Control and Evaluation
Topics covered in the chapter:
The project monitoring,
Project monitoring system
Reporting progress of a project work
Project status reports
Budget report, traffic light report
Decision to terminate a project
Termination criteria
Implementation of project termination
The project report: success of the project, learning of project
The post-completion audit, project scorecard
Chapter 6: Project Control and Evaluation
Page | 166
1 Project monitoring
Managers are familiar with the concept of a planning and control cycle. Planning and control is
different within the project environment from the analysis, planning, implementation and control
cycle in marketing. Project managers focus on planning, monitoring and controlling. Planning
was addressed earlier, and so now the focus moves to the monitoring phase.
According to Meredith and Mantell (2003): ‘Monitoring is the collecting, recording and reporting
information concerning any and all aspects of project performance that the project manager or
others in the organisation wish to know.’
Tracking and monitoring progress helps to ensure an effective and efficient project, by reviewing
project implementation against the approved plan and budget. Monitoring focuses on tracking
data about activities and progress. It needs to be built on a good plan and substantial data. The
design of a realistic chain of results, outcomes, outputs and activities is particularly important.
Monitoring cannot make a project successful – it is a ‘neutral’ part of the project process.
However, timely monitoring (followed by effective control) can help identify – and avoid if
necessary – the three Cs that challenge projects:
Crises
Catastrophes
Change
Monitoring is usually the responsibility of the project co-ordinator and may be carried out
informally (through weekly briefs) or through routine review of the project documents. The
minimum forms of review for a project should be on the ‘triple constraints’ or:
Time (schedule)
Cost (budget)
Performance
Within this, the key parameters are:
Current project status
Progress to date
Chapter 6: Project Control and Evaluation
Page | 167
The project monitoring system
The key stages in designing a monitoring system are:
Identify the information requirements
Identifying the key factors to be monitored
Identifying the boundaries
Project monitoring normally relies on the parent organisation having a robust internal
information system for monitoring and control.
The project monitoring system needs to be specified at the project initiation. Typically, this will
look at the data collection process, the standards and the performance criteria. Unfortunately,
these may change over time, because of changes affecting scope, legal change s or other
budgetary or business priorities.
The monitoring system should also consider project mile stones of performance criteria (such as
the number of changes to plan or variations in resources usages).
The project action plan, WBS system and the further more detailed subplans are the reference for
this. These describe the project activities, tasks, schedules, resource levels and costs for all
elements. However, these factors may not identify all elements needed for project monitoring.
Indeed, focusing on monitoring activity, rather than the output, is a common error. A project may
have a considerable amount of activity, but the output may still be hidden. Focusing on the
activity may mask the problems in creating output.
2 Reporting progress
The above material has identified various ways of monitoring progress, but these analyses are
not only for the project manager. Commonly, monitoring is communicated to others through
reports and meetings. Reports can be prepared by the project team, or prepared by independent
auditors, depending on the organisation, type of project and the level of project risk. The reports
will al so form the record on which the project history will be based. However, the project manager
has the ultimate responsibility for defining how reports and meetings are managed.
2.1 Project status reports
Project status reports provide updates on the project status.
Routine reports are normally those that provide updates on the project status.
Chapter 6: Project Control and Evaluation
Page | 168
An executive status report, for the project sponsors or other key stakeholders who are
not directly involved in the project activities. These should be prepared on an agreed
schedule, often monthly or quarterly, and timed to fit with meetings with executive
stakeholders.
The focus of this report should be on the ‘top-level’ issues affecting progress and plans.
Project progress status reports will be prepared on a regular time schedule. Projects
with full-time team members or working within a tight schedule will commonly have
these prepared weekly. Part-time projects may have a less frequent reporting schedule,
as long as they do not have a short time duration.
Project status reports are normally prepared by those in key roles in the project team. These keep
the project manager and project team up-to-date with progress or problems, and enable all to
be aware of plans to reduce problems or recover from problems.
The frequency and contents of progress reports will vary depending on the length of, and the
progress being made on, a project.
The report is a control tool intended to show the discrepancies between where the project is,
and where the plan says it should be. Major considerations will be time and cost and reports will
highlight comparisons of planned and actual progress.
Any additional content will depend on the format adopted. Some organisations include only the
‘raw facts’ in the report, and use these as a basis for discussion regarding reasons for variances
and action to be taken, at a project review meeting.
Other organisations (particularly those involved in long, complex projects) produce more
comprehensive progress reports, with more explanation and comment.
Gray and Larson (2010) suggest the following basic format for a control report:
1. Progress since last report
2. Current project status
Time schedule
Cost Scope
3. Cumulative trends
4. Problems and issues since last report
Chapter 6: Project Control and Evaluation
Page | 169
5. Actions and resolution of earlier problems
6. New variances and problems identified
7. Corrective action planned
2.2 Budget reports – earned value
The progress report should include cost information: the earned value approach is widely used,
especially when projects are managed using the US Project Management Institute methodology.
The essence of monitoring using earned value is the computation of variances for cost and
schedule (schedule here means time progress). Three cost figures are required for the
computations.
a) Actual cost of work completed (AC). This is the amount spent to date on the project.
b) Planned value of the work scheduled to date (PV). The amount that was budgeted to be
spent to this point on scheduled activities.
c) Earned value (EV). This figure is calculated by pricing the work that has actually been done
– using the same basis as the scheduled work.
EV – AC = The cost variance for the project.
EV – PV = The schedule variance for the project.
It should be noted that the schedule variance, while a useful overall indicator, is not the best
indicator of time progress: the project network is far more accurate and informative.
2.3 Traffic light reports
Traffic light control can also provide a higher level visual summary of progress.
In the traffic light approach, project members estimate the likelihood of various aspects of a
project meeting its planned target date. Each aspect is then colour-coded.
Green Means ‘on target’: the work is on target and is expected to meet stakeholder
expectations.
Yellow Signifies the work is behind target, but the slippage is recoverable. Yellow
indicates that some problem areas have been identified, but corrective actions
can be taken to deal with them.
Red Signifies the work is behind target and will be difficult to recover. A ‘red’ traffic
light suggests there are major problems: for example, if a major component
Chapter 6: Project Control and Evaluation
Page | 170
of the project is behind target it could significantly affect the progress of the
project as a whole.
Traffic light control can also be applied to cost and quality aspects of a project as well as time.
Equally, traffic light control could be applied to the three elements of time, cost and quality
together. If a project is on course to substantially meet its objectives in all three elements, it will
be indicated by a green traffic light. If two out of the three are likely to be substantially met, the
traffic light will be yellow, but if less than two objectives are substantially met, the traffic light will
be red.
2.4 Control charts
Several different types of chart may be used to display project progress. The Gantt chart is
inherently suited to use as a control chart, displaying planned and actual usage of resources, as
is, to some extent, the resource histogram. A 'project schedule control chart' displays overall
progress against plan. An example is shown below.
This chart shows that after a good start, by the end of period 3, the project had fallen behind by
almost two days. Efforts were obviously made to recover the lost time, because the latest report,
at the end of period 8, shows the project only about half a day behind.
Chapter 6: Project Control and Evaluation
Page | 171
2.5 Milestones
Milestones should be definite, easily identifiable events that all stakeholders can understand.
Monitoring progress towards key milestones can be done on a control chart of the type described
above, or on a milestone slip chart such as that shown below. This chart compares planned and
actual progress towards project milestones. Planned progress is shown on the X- axis and actual
progress on the Y-axis. Where actual progress is slower than planned progress slippage has
occurred.
On the chart above milestones are indicated by a triangle on the diagonal planned progress line.
The vertical lines that meet milestones 1 and 2 are straight–showing that these milestones were
achieved on time.
At milestone 3 some slippage has occurred. The chart shows that no further slippage is expected
as the progress line for milestone 4 is the same distance to the right as occurred at milestone 3.
3 The project termination decision
Two key models or forms of project decision-making exist:
Models based on the extent to which the project has achieved – or failed to achieve – its
desired outcomes
Chapter 6: Project Control and Evaluation
Page | 172
Models that compare the project against generally accepted standards for success and
failure for a project
3.1 Assessing project termination
A project can be terminated at any stage in the project process. Whether projects should continue
is essentially a resource allocation decision. Generally, this follows a project review, or results from
other organisational decisions.
Meredith and Mantell (2003) state ‘that the primary criterion for project continuance or
termination is whether or not the organisation is willing to invest the estimate d time and cost
required to complete the project, given the project’s current status and expected outcome.’
They argue that this definition can be applied to all projects. In practice, some managers allow
tactical projects to continue, without substantial review, if there is no ‘bad news’ associated with
them. A departmental plan will have a range of subprojects, such as those designed to support a
new brand launch.
Each element will normally continue – unless risk, budget or other factors go right out of control.
While project managers should be committed to their projects, they should also recognise when
and how to stop unsuccessful projects. Often, project managers will protect their projects,
because of an emotional involvement or concern over their careers. Early project termination can
be emotional though, as reflected in the language used.
Projects that finish early are ‘culled’ or have ‘hatchets’ taken to them. In reality, continuing some
projects may have worse outcomes on the careers of the managers and of the sponsoring
organisation. Usually, project termination decisions are made by senior sponsors rather than
project managers.
3.2 Criteria for reviewing ongoing project termination
Relatively little attention has been given to criteria for ongoing project termination in formal
studies. Dean (1968) identified the following criteria for terminating a project early.
Table PTC: Project termination criteria
Termination evaluation criteria Possible tools for evaluation
Probability of technical/commercial success Marketing research, profit/loss analysis, value
analysis
Chapter 6: Project Control and Evaluation
Page | 173
Profitability/ROI/market potential Marketing research, profit/loss analysis, value
analysis
Cost growth Budgeting, variance analysis
Changing competitive factors/market needs Marketing intelligence, profit/loss analysis
Technical problems that cannot be resolved Project viability, marketing mix analysis
Competing projects having higher priority
within the organisation or department
Investment performance analysis, project
priority review
Low probability of technical/commercial success
Low profitability/ROI/market potential
Damaging cost growth
Change in competitive factors/market needs
Technical problems that cannot be resolved
Competing projects having higher priority within the organisation or department
Schedule delays
Despite the age of Dean’s work, these issues remain valid. Note that Dean includes changing
market situations, which is not explicitly mentioned in Meredith and Mantell’s definition. Studies
in 2008–2009 showed that over 50% of US marketing managers were considering culling projects
or project expenditure. It is not clear whether this was due to lower budgets, less cash to invest
in marketing or changes in potential rewards from projects.
Organisations rarely have formal criteria for evaluating the early termination of projects. Often, it
is easier – in terms of the level of investment and the external evidence of the project – to stop
projects than those with tangible evidence of work completed, for example construction projects.
It is also easier to stop projects that do not have a full-time team as there are no redundancies.
Notably, staff motivation and concerns are often not included in project termination decisions.
4 The project report
At the end of the project, two differing views of the project report exist:
1. Project report identifying the success of the project
2. Project history to encourage learning
Chapter 6: Project Control and Evaluation
Page | 174
A Project Success Report focuses on the outcomes of the project, and should identify:
a) Whether the project’s objectives have been met and identifying the success of the project
on the basis of this.
b) A comparison of the performance against the planned target time and cost.
c) Whether the original project plan needed changes.
d) Analysis of any changes to time, cost, outcomes, during the project.
e) Any other organisational requirements, e.g. staff performance, testing etc.
On project completion, the project manager will produce a completion report. The main purpose
of the completion report is to document (and gain client sign-off for) the end of the project.
The report should include a summary of the project outcome:
a) Project objectives and the outcomes achieved.
b) The final project budget report showing expected and actual expenditure (If an external
client is involved this information may be sensitive – the report may exclude or amend
the budget report).
c) A brief outline of time taken compared with the original schedule.
d) Responsibilities and procedures relating to any such issues should be laid down in the
report.
5 The outcome matrix
A matrix approach may be taken to the presentation of various aspects of the completion report.
The simplest kind of matrix will simply list project deliverables in the left-hand column of cells
and show an objective assessment of achievement in the right-hand column. The matrix can be
made more informative by incorporating further columns to summarise outcomes in terms of,
for example, time, cost and stakeholder satisfaction. An example is given below.
Table NPD: New product development project outcomes
Deliverable Schedule Cost Production
engineering
Sales Finance
Product
design
Three weeks
late
£10,900 under
budget
Complexity
considered
marginally
acceptable
Good market
performance
anticipated
Breakeven
unlikely below
14,600 units
per month
Chapter 6: Project Control and Evaluation
Page | 175
Packaging On time £2,700 over
budget
Satisfactory Satisfactory
Considered
expensive
Service
requirements
specification
Six weeks late £4,900 over
budget
Satisfactory
Over-complex Satisfactory
A more complex type of outcome matrix can be used to analyse performance against two
interacting criteria. This is the very common two-axis type of matrix that you are probably already
familiar with through ideas such as Ansoff’s product/market matrix. An example of an outcome
matrix would be one that analysed technical aspects of a project deliverable in terms of quality
of design and quality of execution.
6 The post-completion audit
Any project is an opportunity to learn how to manage future projects more effectively.
The post-completion audit is a formal review of the project that examines the lessons that may
be learned and used for the benefit of future projects.
The audit looks at all aspects of the project with regard to two questions:
a) Did the end result of the project meet the client's expectations?
i. The actual design and construction of the end product
ii. Was the project achieved on time?
iii. Was the project completed within budget?
b) Was the management of the project as successful as it might have been, or were there
bottlenecks or problems? This review covers:
i. Problems that might occur on future projects with similar characteristics.
ii. The performance of the team individually and as a group.
The post-completion audit should involve input from the project team. A simple questionnaire
could be developed for all team members to complete, and a reason ably informal meeting held
to obtain feedback, on what went well (and why), and what didn't (and why).
This information should be formalised in a report. The post-completion audit report should
contain the following:
Chapter 6: Project Control and Evaluation
Page | 176
a) A summary should be provided, emphasising any areas where the structures and tools used
to manage the project have been found to be unsatisfactory.
b) A review of the end result of the project should be provided, and compared with the results
expected. Reasons for any significant discrepancies between the two should be provided,
preferably with suggestions of how any future projects could prevent these problems
recurring.
c) A cost-benefit review should be included, comparing the forecast costs and benefits
identified at the time of the feasibility study with actual costs and benefits.
d) Recommendations should be made as to any steps which should be taken to improve the
project management procedures used.
Lessons learnt that relate to the way the project was managed should contribute to the smooth
running of future projects.
A starting point for any new project should be a review of the documentation of any similar
projects undertaken in the past.
7 Benefits realisation
It is obviously important that the benefits expected from the completion of a project are actually
enjoyed. Benefits realisation is concerned with the planning and management required to realise
expected benefits. It also covers any required organisational transition processes.
The UK Office of Government Commerce has identified a six-stage procedure for benefits
realisation. This is most relevant to projects aimed at process improvement and changing the
organisation's way of doing things.
Stage 1 Establishing benefits measurement
Measure the start state and record it in the benefits profile. The benefits profile
defines each anticipated benefit and is used to track progress towards its
realisation. Determine how benefit realisation will be measured. Benefits may be
complex and spread across departments: designing usable and realistic
measures may be difficult.
Stage 2 Refining the benefits profile
Chapter 6: Project Control and Evaluation
Page | 177
The benefits profile should be refined and controlled throughout the life of the
project. Project managers should conduct regular benefits profile reviews in
collaboration with key stakeholders.
Stage 3 Monitoring benefits
There should be regular monitoring of benefits realisation. It must be accepted
that some projects will only be beneficial in enabling other projects to be
successful.
Stage 4 Transition management
Projects are likely to bring change and this must be managed in a proper way.
Effective communications will be required as will the deployment of good people
skills
Stage 5 Support for benefit realisation
Benefits realisation will mainly accrue after the end of the project. Where a
project brings changes in methods and processes, there is likely to be a period
for settling-down before benefits are fully realised. During this period, costs may
rise and problems may occur. Careful management is required to overcome
these short-term effects. A philosophy of continuous improvement is required if
further benefits are to be achieved.
Stage 6 Measuring the benefits
Benefits achieved should be established by comparison with the pre-
improvement state recorded in the benefits profile.
The Project Success Report can be an important way of showing stakeholders that the project
has achieved its outcomes, or identifying the reasons for failure. This is critical for the project
manager’s future career.
The Project History focuses on ‘lessons learned’ for future projects, rather than on the merits of
the project. This report is sometimes called a project history. This history will examine the
following to determine what worked and what did not, and when and why problems occurred.
It will address:
Project performance – the outcomes, successes, failures and challenges.
Chapter 6: Project Control and Evaluation
Page | 178
Administrative performance – reports and reporting, communications and meetings, review
procedures, scoping and change procedures, financial management.
Project organisation – how this changed throughout the project, and how this helped or
hindered the project.
Project teams – how these performed, recommendations for future teams.
Project management – scoping, plans, methodologies, budgets, schedules, risk management
etc.
Table: Project review
Summary of project history
What went well What went badly Recommendations
Project performance
Admin performance
Project organisation
Project teams
Project management
Often, these reviews will be presented in a meeting or presentation. Simply, this basic finding can
be summarised in a presentation, and Table above will help identify these key issues.
More formal project audits are often undertaken for major projects, and especially those in the
public sector.
8 The project scorecard
Project scorecards extend the traffic light approach to provide progress summaries on key
performance metrics for a project. They are produced on a regular basis, for example weekly,
monthly or quarterly, depending on the project. This scorecard approach complements, rather
than replaces, other planning and monitoring systems.
Organisations must determine appropriate metrics to include in their project scorecards. These
can take one of the two forms. The first focuses on key project management dimensions,
including:
Cost, e.g. between the actual spend against planned spend
Quality, e.g. the percentage of work completed to standard
Chapter 6: Project Control and Evaluation
Page | 179
Time, e.g. the extent to which the project is meeting the project schedule
Corporate factors, e.g. the extent to which corporate goals or standards are being met
The second takes a ‘balanced scorecard’ approach, and assumes that assessing the following
dimensions will deliver the above benefits:
The financial perspective, e.g. EVA, ROI
The customer perspective, customer satisfaction, economic value added. (Notice the
difference between earned value analysis and economic value added. The commonality
of the acronyms can cause confusion.)
The training and innovation perspective, staff PM expertise, lessons learned
The project or other internal business perspective, e.g. satisfaction indices, fit with
corporate objectives
This information can be presented in different ways. Some organisations produce a simple one-
page sheet, which:
Highlights key developments
Shows the tracking of the key performance matrices
Identifies areas that need attention (i.e. are over budget, late, possible risks on the
horizon etc.)
The temporary nature of projects means that tracking and monitoring systems must be
accessible, easy to use and current. As a temporary initiative, some or all aspects of the project
tracking may not fit well within the existing information systems. Further, often only the larger
projects have staff with responsibilities, for example information systems or finance. Therefore,
the tracking data should be, wherever possible, gathered as part of the normal routine of the
project.
Another general rule is that the reporting should be kept brief. Therefore, an updated report
should be only a page or two for most projects.
Often, organisations do not require these reports despite their contribution to project
management knowledge and future projects. Often, other priorities overtake this, or the project
manager has moved to other projects or has a wish to move on. Further, on longer projects, there
is much documentation, but often the reasons for changes or problems are not noted.