ABE Level 6 Project Management Study Manual

i
PROJECT MANAGEMENT
QCF Level 6 Unit
Contents
Chapter Title Page
Introduction to the Study Manual iii

Unit Specification (Syllabus) v
Coverage of the Syllabus by the Manual ix
1 Project Initiation 1
Introduction 2
From Business Objectives to Project Description 3
Project Feasibility and Risk Analysis 7
Project Planning – towards a Life Cycle Model 11
The Project Manager Role 18
2 Project Analysis 27
Introduction 28
Hierarchical Division of Work 28
Risk Assessment and Management 35
Cost Planning and Estimation 42
Dealing with Bids, Tenders and Contracts 48
Effects of Location on Project Management 52
3 The Project Plan 57

Introduction 58
Project Overview 58
Project Management Structures 60
Project Activities and Schedules 69
Dealing with Change in Project Schedules 74
Project Communications 78
4 Monitoring and Controlling Project Progress 83

Introduction 84
Progress Monitoring 84
An Approach to Project Control 91
Regaining Project Control 97
5 Dealing with Team Structures and Leadership 103

Introduction 104
Organising Suitable Team Structures 104
Strategic Approach to Effective Leadership 116
© ABE
ii
Chapter Title Page
6 Managing Quality and Change 131

Introduction 132
Understanding Project Quality 132
Dealing with Change 143
Configuration Control 151
7 Project Closure and Review 155

Introduction 156
Project Termination 156
Closing Down a Project 161
Documenting Project Completion 163
© ABE
iii
Introduction to the Study Manual
Welcome to this study manual for Project Management .

The manual has been specially written to assist you in your studies for this QCF Level 6 Unit
and is designed to meet the learning outcomes listed in the unit specification. As such, it
provides thorough coverage of each subject area and guides you through the various topics
which you will need to understand. However, it is not intended to "stand alone" as the only
source of information in studying the unit, and we set out below some guidance on additional
resources which you should use to help in preparing for the examination.
The syllabus from the unit specification is set out on the following pages. This has been
approved at level 4 within the UK's Qualifications and Credit Framework. You should read
this syllabus carefully so that you are aware of the key elements of the unit – the learning
outcomes and the assessment criteria. The indicative content provides more detail to define
the scope of the unit.
Following the unit specification is a breakdown of how the manual covers each of the
learning outcomes and assessment criteria.
The main study material then follows in the form of a number of chapters as shown in the
contents. Each of these chapters is concerned with one topic area and takes you through all
the key elements of that area, step by step. You should work carefully through each chapter
in turn, tackling any questions or activities as they occur, and ensuring that you fully
understand everything that has been covered before moving on to the next chapter. You will
also find it very helpful to use the additional resources (see below) to develop your
understanding of each topic area when you have completed the chapter.
Additional resources
 ABE website – www.abeuk.com. You should ensure that you refer to the Members
Area of the website from time to time for advice and guidance on studying and on
preparing for the examination. We shall be publishing articles which provide general
guidance to all students and, where appropriate, also give specific information about
particular units, including recommended reading and updates to the chapters
themselves.
 Additional reading – It is important you do not rely solely on this manual to gain the
information needed for the examination in this unit. You should, therefore, study some
other books to help develop your understanding of the topics under consideration. The
main books recommended to support this manual are listed on the ABE website and
details of other additional reading may also be published there from time to time.
 Newspapers – You should get into the habit of reading the business section of a good
quality newspaper on a regular basis to ensure that you keep up to date with any
developments which may be relevant to the subjects in this unit.
 Your college tutor – If you are studying through a college, you should use your tutors to
help with any areas of the syllabus with which you are having difficulty. That is what
they are there for! Do not be afraid to approach your tutor for this unit to seek
clarification on any issue as they will want you to succeed!
 Your own personal experience – The ABE examinations are not just about learning lots
of facts, concepts and ideas from the study manual and other books. They are also
about how these are applied in the real world and you should always think how the
topics under consideration relate to your own work and to the situation at your own
workplace and others with which you are familiar. Using your own experience in this
way should help to develop your understanding by appreciating the practical
application and significance of what you read, and make your studies relevant to your
© ABE
iv
personal development at work. It should also provide you with examples which can be
used in your examination answers.
And finally …
We hope you enjoy your studies and find them useful not just for preparing for the
examination, but also in understanding the modern world of business and in developing in
your own job. We wish you every success in your studies and in the examination for this
unit.
Published by:
The Association of Business Executives
5th Floor, CI Tower
St Georges Square
New Malden
Surrey KT3 4TE
United Kingdom
All our rights reserved. No part of this publication may be reproduced, stored in a retrieval
system or transmitted, in any form or by any means, electronic, mechanical, photocopying,
recording or otherwise without the prior permission of the Association of Business Executives
(ABE).
ABE would like to thank Magnum Opus Knowledge Transfer Ltd and acknowledge their role
in the development of this study manual.
© The Association of Business Executives (ABE) 2011
© ABE
v
Unit Specification (Syllabus)

The following syllabus – learning objectives, assessment criteria and indicative content – for
this Level 6 unit has been approved by the Qualifications and Credit Framework.
Unit Title: Project Management

Guided Learning Hours: 210
Level: Level 6
Number of Credits: 25
Learning Outcome 1
The learner will: Be able to initiate the preliminary stages of a project.
Assessment Criteria Indicative Content
The learner can:
1.1 Identify an appropriate project 1.1.1 Recognise the need for a specific undertaking (a
from an appraisal of business ‘project’) in order to achieve business goals.
objectives. 1.1.2 Explain how pursuing the objectives of an
organisation can lead to a project definition and a
specification of requirements.
1.2 Assess the feasibility of a 1.2.1 Emphasise the importance of conducting a
proposed project, taking risk and feasibility study into a proposed project.
uncertainty into account. 1.2.2 Identify the various dimensions of feasibility such
as financial, technical, social, ethical, ecological and
managerial.
1.2.3 Assess the levels of risk and uncertainty in a
project and identify critical success factors.
1.3 Devise an outline life cycle 1.3.1 Describe the basic project life cycle model
plan suitable for the project’s comprising definition, planning, organising, execution
environment. and closure stages.
1.3.2 Appraise the suitability of alternative life cycle
models involving phased development and prototyping.
1.4 Define the responsibilities and 1.4.1 Explain the diverse activities of a project manager
activities of the project manager. in delivering a successful outcome, such as estimating,
planning, administrating, reporting and leading.
1.4.2 Point out the importance of ensuring good
communication with all stakeholders, including the
project sponsor and the client.
© ABE
vi
Learning Outcome 2
The learner will: Be able to analyse the project work content and associated risks, in order
to obtain estimates and tenders.
The learner can:
2.1 Explain how a project can be 2.1.1 Describe how a project can be sub-divided
sub-divided into work packages hierarchically into a work breakdown structure (WBS).
and cost estimates. 2.1.2 Explain how the WBS can be expanded into work
packages and tasks with an accompanying cost
breakdown structure.
2.2 Identify, analyse and manage 2.2.1 Identify and assess risks in terms of their possible
the risks in a project. impact on the project outcome.
2.2.2 Manage project risk by appropriate means such as
avoidance, reduction, transfer, acceptance and
contingency planning.
2.3 Appraise relevant data in order 2.3.1 Gather information in order to obtain balanced
to calculate overall estimates for estimates of time and cost.
the project. 2.3.2 Consider the likelihood of cost escalation and any
ensuing need for contingency allowances in preparing
final estimates.
2.4 Evaluate tenders in order to 2.4.1 Describe a process by which suppliers’ tenders
reach a formal contract. can be evaluated in order to select one contractor.
2.4.2 Outline the contents and legal basis of a typical
contract to supply
2.5 Explain the effect of 2.5.1 Explain how project management practice may be
globalisation, including cultural influenced by geographical and cultural factors
issues, on project management.
Learning Outcome 3
The learner will: Be able to create a detailed project plan.
The learner can:
3.1 Devise a structure for the 3.1.1 Justify the need for a formal project management
management and administration of structure.
the project. 3.1.2 Propose an appropriate structure for the control
and administration of a project and indicate the
responsibilities of key personnel.
3.2 Identify and schedule the 3.2.1 Identify the activities in a project and establish
activities in a project by employing their dependencies.
appropriate techniques. 3.2.2 Employ recognised techniques, such as the Gantt
Chart and network analysis, in order to devise a project
schedule.
3.2.3 Outline the typical functions of project
management software packages which can assist the
scheduling task.
© ABE
vii
3.3 Adjust schedules as necessary 3.3.1 Explain the need to adjust project schedules when
in order to optimise the use of the available resources are subject to constraints.
resources. 3.3.2 Reorganise a project schedule in order to smooth
resource requirements.
3.4 Construct and justify a detailed 3.4.1 Recognise the need to communicate the project
project plan. plan to various interested parties.
3.4.2 Describe the contents of a detailed project plan.
Learning Outcome 4
The learner will: Understand how the progress of a project can be monitored and controlled.
The learner can:
4.1 Identify factors which 4.1.1 List typical problems which affect the progress of a
frequently disturb the progress of a project.
project. 4.1.2 Account for such problems and propose remedial
actions.
4.2 Suggest techniques by which 4.2.1 Identify those sources of information which might
the project manager can appraise indicate deviations from the desired progress of a
the status of a project. project.
4.2.2 Explain the importance of corroborating and
evaluating status information before taking action.
4.3 Explain methods by which the 4.3.1 Explain how cost variances and slippage can be
project manager could resolve the calculated.
problems detected, with examples. 4.3.2 Describe the courses of action open to the project
manager in managing deviations from a planned
schedule.
Learning Outcome 5
The learner will: Know how to organise a suitable team structure for the project personnel
and devise strategies for leading them effectively.
The learner can:
5.1 Compare the commonly 5.1.1 Emphasise the importance of effective team
employed project team structures. organisation and management.
5.1.2 Compare and contrast teams organised on
functional, project, matrix and contract structures.
5.2 Identify the interpersonal skills 5.2.1 List and discuss key leadership skills which are
required for effective teamworking considered desirable in a project manager.
and project management. 5.2.2 Discuss the actions and decisions by which a
project manager can influence the motivation of team
members.
© ABE
viii
Learning Outcome 6
The learner will: Understand the management of quality and change within a project.
The learner can:
6.1 Explain how quality may be 6.1.1 Explain the term ‘quality’ viewed from perspectives
assessed and managed in a such as the product, the consumer, the manufacturing
project. specification and value.
6.1.2 Describe standard techniques for assessing and
maintaining quality requirements.
6.1.3 Explain how the quality of software products may
be assessed and managed.
6.2 Suggest reasons for proposing 6.2.1 Using examples, distinguish between internal and
changes to a project from within. external changes.
6.2.2 Recognise the importance of implementing a
formal change control procedure and describe its
constituent elements.
6.3 Devise an administrative 6.3.1 Explain the steps in a typical configuration control
procedure by which change procedure.
proposals may be justified and
processed.
Learning Outcome 7
The learner will: Know about the recommended activities and required reports in the closure
and review of a project.
The learner can:
7.1 Summarise the difficulties that 7.1.1 Distinguish between the human and technical
may be encountered in the closing problems related to project termination.
stages of a project. 7.1.2 Consider factors related to the project staff, the
client, project handover, maintenance and
documentation, contract completion and acceptance,
financial matters and closure checklists.
7.2 Describe the administrative 7.2.1 Construct a list of actions appropriate for a project
actions often required of the manager preparatory to closing down a project.
project manager as a project is
terminated.
7.3 Identify the reports which 7.3.1 Distinguish between the purposes of the project
should be prepared and describe manager’s final report and the post-implementation
their likely contents. report.
7.3.2 Summarise the contents of the project manager’s
final report and the post-implementation report.
© ABE
ix
Coverage of the Syllabus by the Manual
Learning Outcomes Assessment Criteria Manual

The learner will: The learner can: Chapter
1. Be able to initiate the 1.1 Identify an appropriate project from an Chap 1

preliminary stages of a appraisal of business objectives
project 1.2 Assess the feasibility of a proposed Chap 1
project, taking risk and uncertainty into
account
1.3 Devise an outline life cycle plan suitable Chap 1
for the project’s environment
1.4 Define the responsibilities and activities Chap 1
of the project manager
2. Be able to analyse the 2.1 Explain how a project can be sub- Chap 2
project work content and divided into work packages and cost
associated risks, in order estimates
to obtain estimates and 2.2 Identify, analyse and manage the risks Chap 2
tenders in a project
2.3 Appraise relevant data in order to Chap 2
calculate overall estimates for the
project
2.4 Evaluate tenders in order to reach a Chap 2
formal contract
2.5 Explain the effect of globalisation, Chap 2
including cultural issues, on project
management
3. Be able to create a 3.1 Devise a structure for the management Chap 3

detailed project plan and administration of the project
3.2 Identify and schedule the activities in a Chap 3
project by employing appropriate
techniques
3.3 Adjust schedules as necessary in order Chap 3
to optimise the use of resources
3.4 Construct and justify a detailed project Chap 3
plan
4. Understand how the 4.1 Identify factors which frequently disturb Chap 4
progress of a project can the progress of a project
be monitored and 4.2 Suggest techniques by which the Chap 4
controlled project manager can appraise the status
of a project
4.2 Explain methods by which the project Chap 4
manager could resolve the problems
detected, with examples
© ABE
x
5. Know how to organise a 5.1 Compare the commonly employed Chap 5

suitable team structure for project team structures
the project personnel and 5.2 Identify the interpersonal skills required Chap 5
devise strategies for for effective teamworking and project
leading them effectively management
6. Understand the 6.1 Explain how quality may be assessed Chap 6

management of quality and managed in a project
and change within a 6.2 Suggest reasons for proposing changes Chap 6
project to a project from within
6.3 Devise an administrative procedure by Chap 6
which change proposals may be
justified and processed
7. Know about the 7.1 Summarise the difficulties that may be Chap 7
recommended activities encountered in the closing stages of a
and required reports in the project
closure and review of a 7.2 Describe the administrative actions Chap 7
project often required of the project manager as
a project is terminated
7.3 Identify the reports which should be Chap 7
prepared and describe their likely
contents
© ABE
1
Chapter 1
Project Initiation
Contents Page
Introduction 2
A. From Business Objectives to Project Description 3

The Need for a Specific Undertaking (Project) to Achieve Business Goals 3
How Pursuing Organisation Objectives can Lead to a Project Definition 5
B. Project Feasibility and Risk Analysis 7

The Importance of Conducting a Feasibility Study 8
The Various Dimensions of Feasibility 9
The Levels of Risk and Uncertainty and Success Factors 11
C. Project Planning – towards a Life Cycle Model 11

The Basic Project Life Cycle Model 12
The Suitability of Alternative Life Cycle Models 15
D. The Project Manager Role 18

The Diverse Activities of a Project Manager 20
The Importance of Ensuring Good Communication 23
Summary 25
Answers to Review Questions 26
© ABE
2 Project Initiation
INTRODUCTION
Like every course on project management, this one begins by setting the scene for the main
concepts. In this chapter the project management concept itself is explained in detail, and we
then take an overview of the core components of a project.
Each project has a purpose that makes it useful to its sponsors and the people (or
organisations) that need the project to succeed (and who are therefore willing to invest time,
effort and money for that purpose). A project is created in order to provide a solution to a
problem that can be clearly defined. The solution to the problem follows the analysis of the
needs triggered by the existence of the problem. Projects must be realistic: resources are not
endless, and the impact of the solution developed must justify the overall cost of the
resources used.
Each project is implemented within a certain context and the main consideration is the
available time and space for the development of its activities. The complexity of each project
depends on the problem that must be solved and the planning decisions made. Since
problems can be demanding, it is often the case for projects to be complex and to require a
collective effort to support their activities. For this reason project teams are created, and it is
highly likely for work to be delegated, subcontracted and outsourced, which leads to even
more complex project structures.
Projects must be unique, creative and innovative because they are solving specific problems
of particular scenarios that exist in organisations. The uniqueness of a project and the
developed solution does not mean that project managers do not resort to the adaptation of
existing solutions and the partial use of existing available methods and approaches. The
assessment of a project takes place in a variety of forms, ranging from individual
performance criteria and progress indicators for project phases, to overall project evaluation
and monitoring of specific actions. For all these reasons projects are usually described in
terms of phases that are interrelated and can be identified in terms of tasks, deliverables and
resources needed.
Objectives
After studying this chapter, you should be able to:
 justify the need for a specific undertaking (a "project") in order to achieve business
goals
 explain how pursuing the objectives of an organisation can lead to a project definition
and a specification of requirements
 justify the importance of conducting a feasibility study into a proposed project
 identify the various dimensions of feasibility such as financial, technical, social, ethical,
ecological and managerial
 assess the levels of risk and uncertainty in a project and identify critical success factors
 describe the basic project life cycle model comprising definition, planning, organising,
execution and closure stages
 appraise the suitability of alternative life cycle models involving phased development
and prototyping
 explain the diverse activities of a project manager in delivering a successful outcome,
such as estimating, planning, administrating, reporting and leading
 justify the importance of ensuring good communication with all stakeholders, including
the project sponsor and the client.
© ABE
Project Initiation 3
A. FROM BUSINESS OBJECTIVES TO PROJECT

DESCRIPTION
This chapter discusses the core principles of project management and provides the
foundation for further discussion of more specific topics later. A working definition of project
management regards the principles, methods, approaches and techniques used to support
and lead project teams towards meeting certain requirements by following a schedule,
dealing with calculated risks and handling available resources.
The Need for a Specific Undertaking (Project) to Achieve Business Goals

There are so many definitions of what constitutes a project. The main concern is that
projects cannot be adequately defined because they are unique in nature. Potentially,
each organisation or individual embarking on a project has unique needs that must be
addressed, a unique set of available resources, a set of unique environmental factors and
constraints and a unique way to employ existing principles, practices and techniques.
The complexity and interconnectivity of activities means that each project ends up being a
maze of tasks that are somehow related to producing the deliverables that correspond to
certain needs. These tasks can eventually be used not only to satisfy those needs, but also
to work towards jointly solving the organisation's problem.
Usually each project originates from a single goal, perhaps even a single key objective that
must be met. The complexity of each project depends on the criticality of the project aim and
the planning decisions made. The project life cycle is also affected by a number of factors.
The available time and the project environment may allow certain decisions to be made while
other options may not be available.
Finally a project can be defined in terms of its budget and scheduling, since these two
concepts affect the resources available as well as the way that the project specification is
tailored to meet the original requirements. We can therefore identify a number of project
parameters that can be used to provide a concise method for describing projects. These are:
 Scope – scope means what needs to be done and which problem will be solved with
the successful implementation of the project activities.
 Quality – if certain success criteria are met they provide performance indicators and
standards of acceptable project deliverables as well as project operations. It is
necessary to realise that quality may be defined according to what is expected of the
project products or the criteria for assessing the project processes.
 Cost – budgeting requirements and constraints are very important for the project
definition.
 Time – deadlines, constraints and availability of resources seriously affect the project
progress and overall performance.
 Resources – apart from monetary resources, projects require technology, workforce,
skills, experience, etc.
Think Point 1
For an organisation of your choice consider a set of needs leading to the creation of a
project. Identify the main parameters of your project plan and explain how these parameters
are in line with the organisation's mission.
© ABE
Each organisation defines in its mission the main aims and how they must be achieved. You
should focus on the scope for the project, the necessary criteria for assessing the quality of
the project's deliverables, the costs associated with the project activities, the available time
and any resource needs.
We could safely argue that projects can be classified according to some of the characteristics
just mentioned. Some straightforward criteria to be used when classifying projects may
include:
 cost
 risk
 duration
 value
 complexity
 technology.
We have discussed the way projects are defined. The next step is to explain what project
management is. The project management concept is quite often defined in terms of the steps
or phases that it includes. Initially it is project management practice to establish a set of
definitions. These definitions may include the definition of the problem to be solved, the
project aims, the organisation's goal, the objectives of the project team, the success criteria
to be used and even the assumptions that can be safely made with respect to cost,
resources, time, etc.
Project management is also about planning, a phase that is discussed in detail next. There
are clear benefits for a planning phase as it ensures that adequate understanding of the
project tasks is shared by project stakeholders. Proper planning helps to deal with project
complexity and improve efficiency as resources are used more wisely.
The planning phase is followed by an execution phase that also forms part of project
management responsibilities. The execution of a plan assumes that certain resources are
made available for each project task. The execution phase also includes the allocation of
tasks and the scheduling and budgeting for these tasks.
While the project tasks are being developed and deliverables are being prepared, the
emphasis of project management is on controlling the overall process. A detailed project
control action involves an assessment of how project objectives are met and the level of
completion for each task. The allocation of responsibilities between team members, the
identification of suitable deliverables and the performance measurement for each team
member are also included in the controlling phase.
The last phase of project management relates to project closure. This assesses whether
the deliverables meet the requirements identified originally, if the project manager is
persuaded that the deliverables are in a state to be handed over to the project sponsor, and
which aspects of the project plan have been successfully completed. The handover of a
project is usually a good opportunity to share lessons learned, as these can prove useful for
consequent projects.
A summary of project management phases includes:
 Scoping the project – involves defining the problem, establishing the overall goal,
identifying the objectives.
 Developing the project plan – involves identifying activities, scheduling activities,
establishing resource requirements, preparing proposal.
 Launching the plan – involves team selection and recruitment, balancing resources,
establishing operations, documenting.
© ABE
 Monitoring the project – involves reporting, controlling change, monitoring progress,

assessing performances, revising plans.
 Closing the project – involves obtaining acceptance of project sponsor, producing
documentation, auditing and publishing reports.
How Pursuing Organisation Objectives can Lead to a Project Definition

So far we have discussed the definitions of a project and have explained the meaning of
project management. Project management is very important for today's organisations as it
offers the connecting link between the understanding of an organisation's vision and mission
and its operations and outputs. Projects are defined according to the goals identified at
organisational level. The understanding of how the common vision can be implemented in
the form of a product or a service is essential in order to establish which projects must be
implemented.
Within organisations, project management offers a great opportunity to reduce the time
required to develop solutions by providing more effective ways of utilising resources and
producing deliverables. Project management allows an efficient way of operation leading to
new markets, new customers, the internationalisation of provision and entering global
markets. Project management allows us to deal with project complexity by accessing the vast
amount of information and volumes of knowledge in diverse fields. The project management
scope includes dealing with increasing costs of operations, downsizing, diversification and
resource dispersion of modern organisations while maintaining an intense client focus.
A project management team must understand that a project operates within a broad
environment. The project management context embraces many aspects such as the project
life cycle, stakeholders and organisational influences as well as a required skill set. Since the
1950s systemic approaches have emerged in order to solve organisational problems in a
more analytical way. The core of such approaches consisted of:
 a systems philosophy that views everything as a system of interacting components
aiming to solve a specific problem
 a systems analysis attempting to support problem solving
 a systems management approach addressing organisational, technological and
business issues.
Dealing with stakeholders
Putting project management in context should include discussion of the stakeholder concept.
It is important to understand why stakeholders are so important for project management.
Predominantly stakeholders can be identified as:
 primary – who are in a direct relationship with the project
 secondary – who are indirectly affected
 tertiary – who have a level of influence to the project.
It is very important to understand the role of stakeholders, as they can affect project
management either by being project sponsors who commission the project or end-users who
provide the project requirements. They can also be "externals" who may affect the
environment in which the project operates.
Managing the relationship between the project manager, the project team and the
stakeholders is critical for smooth project operation as well as the provision of necessary
information and support. Additionally, the communication protocol followed is likely to affect
how the project deliverables are prepared and the extent to which initial requirements are
met.
© ABE
Think Point 2
Describe a typical strategy for identifying a project's stakeholders and explain how the
identified stakeholders may affect the project's life cycle.
Typically, stakeholders may be classified as internal to the organisation or external. Based on

this classification, the stakeholders are likely to affect project decisions in different ways.
Internal stakeholders are usually readily available to identify their requirements, whereas
external stakeholders are treated as clients and may communicate their requirements in
more formal procedures.
It is necessary to identify some typical stakeholders in projects:
 clients – people who may be using certain project services and a number of its
deliverables
 end-users – similar to clients in cases where a product is the main project deliverable
 sponsor – the source of the financial support and the person or organisation that
provides the scope of the project
 manager – may affect the project as he or she assesses the project's value for money
and return on investment (ROI)
 project manager – the person who controls and manages the project activities
 project team – the workforce allocated to the project's activities
 project management office – those supporting the project management team, including
those working for the sponsor
 operations manager – the person in the organisation responsible for integrating the
project after its closure
 top management – the executives who may affect the project by altering the
organisation's direction and goals
 resource managers – those who decide whether resources become available
 contractors – sometimes work may be outsourced or subcontracted, adding to the
complexity, cost and time overheads
 suppliers – in certain cases projects may require external supplies which may affect the
project timeline if delayed.
Organisational Influences
There are many examples of projects failing to meet their targets and it is quite common to
see similar projects being executed in quite different ways. It is essential to understand the
factors that affect the way a project is implemented within an organisation.
An important concept that you need to become familiar with is the one of "organisational
culture". It implies that an organisation is an entity that possesses certain characteristics that
can be described as a culture, affecting how the organisation's behaviour affects its internal
structures and operations as well as its stakeholders and affiliated entities (e.g. clients, other
companies).
It is important to identify those aspects of the organisation culture that affect projects. These
are features that set the organisation's environment. Since our focus is on project
management, we can classify the organisational influences according to the impact they
have on a project. We can identify at least four categories of environmental influences:
© ABE
 values and norms

 policies and procedure
 authority and responsibility
 work ethics and patterns.
It is highly unlikely for a successful organisation to operate without a clear mission statement
that outlines the organisation's vision, its values and norms as well as beliefs and
expectations. The organisation aims to create an environment that is based on clear goals
that are common between its members and is shared amongst its workforce. Such values
and beliefs may affect initiatives that a project manager wishes to introduce and may lead to
conflicts between a project's objectives and what is perceived as acceptable in the
organisation.
An important aspect of project management is the establishment of clear plans regulating
procedures, the way of doing things and eventually the methods employed for solving
certain problems or even taking decisions. Typically, organisations introduce polices to
ensure that their operations are regulated and that stakeholders are aware of their rights and
responsibilities as well as what is expected from them.
The authority and responsibility aspects of roles within an organisation are set
predominantly either in a formal way through appraisals, performance monitoring and
contract clauses, or informally in terms of expectations at the workplace. It is quite important
to understand how authority is exercised within an organisation in order to estimate its
possible impact upon any project.
Finally the patterns of work and work ethics regulate the way an organisation reaches its
targets and produces its outputs. It is necessary to identify any constraints or special features
of work and performance as a workforce is unlikely to shift into new ways of doing things in a
short period of time.
Review Questions 1
(a) What are the five main project management phases?
(b) There are twelve types of typical project stakeholder. Try and name at least nine of
them.
Now check your answers with those given at the end of the chapter.
B. PROJECT FEASIBILITY AND RISK ANALYSIS

It is very important for the success of a project to be absolutely certain about what is to be
delivered. The feasibility study provides an overview that allows a reality check to those
involved with the project. Furthermore, it can lead to a more detailed analysis of the project
requirements and any associated constraints and special aspects that may affect the
success of the project and the provision of the final deliverables. The feasibility study of
projects may take various forms, depending on project management styles followed and
perhaps the existence of internal procedures and policies that may exist in the organisation.
This section discusses how a feasibility study may affect a project's outcome and
emphasises the role of risk analysis in the eventual success of the project's objectives.
© ABE
The Importance of Conducting a Feasibility Study

The feasibility study could be incorporated into the initial stages of a project's design as it
may lead to significantly altering the project's estimated resources, reshaping its aims and
overall scope and perhaps adjusting any identified objectives.
There are several suggested procedures and step-by-step approaches that support the way
a feasibility study can be conducted. It is quite frequent for a feasibility study to take the form
of a requirements analysis exercise.
We could identify the following stages on such an exercise:
 identifying project stakeholders
 capturing stakeholder needs
 performing a needs assessment
 performing a reality check
 establishing an agreement.
Think Point 3
Explain why the role of the feasibility study is important for analysing the project's
requirements.
A feasibility study assesses whether the project objectives can be achieved in the available
time and resources. If the feasibility study identifies certain issues that must be addressed,
the project plan may have to be changed.
The five steps we have identified provide good guidance on how to group together certain
activities that will help you to identify whether your project is feasible or not. The scope of this
analysis of the project's requirements is to establish what needs to be done for the project to
succeed in its current form, or alternatively how to reshape what was initially perceived as the
project's aim and objectives.
We will discuss the requirements analysis stages in some detail next.
 Identifying project stakeholders
The project stakeholders are the key people who may have an impact on the project
with their decisions or may be in a position or role that may be affected by the project's
outcomes. Key people may be classified as internal or external to the organisation that
is in charge of the project.
 Capturing stakeholder needs
Obviously key people and roles are important for the project's success and therefore
we need to establish a good understanding of how these stakeholders are related to
the project. This can be achieved by capturing their needs and establishing that we
have sufficient information to prepare a requirements map for the project.
There are several ways of identifying stakeholder needs. It is quite common for
stakeholders to be interviewed, participate in focus groups or even take part in surveys.
All three techniques provide opportunities for stakeholders to communicate their views
and for project managers to understand what the stakeholder needs are. The different
techniques provide alternative routes for collecting information, depending on whether
it is important for two-way communication to be established as well as the detail of
information required.
© ABE
Additional techniques can be employed if the project involves the use of technology. In
such cases users may participate in cooperative evaluations of existing systems or the
design of prototype systems to explain how the project outcome will affect their roles.
More options include the development of user scenarios and even the observation of
stakeholders in the workplace performing their activities.
 Performing a needs assessment
Once requirements are captured it is essential to use a classification scheme. This will
allow us to group together needs of similar nature while establishing a prioritisation for
the project's objectives. The requirements identified may be functional or operational,
meaning that they may affect the way the project's functions are performed or they may
be operations that must be present to support the project's output.
Requirements may also be classified as technical if they relate to technological
aspects of the project, or transitional when they relate to the changeover from the
existing situation to the one following the project's completion. Requirements can be
classified according to their severity and it is not uncommon for some of them to be
referred to as desirable, being implemented only when certain criteria are met (e.g.
time availability, budget).
 Performing a reality check
The reality check stage is critical for all parties involved as it helps towards a common
understanding of the needs identified so far. It is important not only for project
managers to understand the stakeholder requirements, but also for each stakeholder to
realise how their role and perceived needs may affect the project. The definition of
each requirement is a key matter for this stage as the clarification and level of detail
must be such to ensure that a project deliverable can be associated with it.
The various requirements can be prioritised in terms of their importance and each
project may use a different weighing system to establish how these range from critical
to non-essential. It is expected that clashes between requirements originating from
different stakeholders will exist and it is necessary to establish how such conflicts are
resolved. Finally the impact of each requirement being met, as well as the awareness
of change and the appreciation of the new environment created, are three issues that
must be addressed.
 Establishing an agreement
The final stage finds the involved parties in agreement as to the stakeholder
requirements and how the project will work towards satisfying them to an extent which
is predefined.
The Various Dimensions of Feasibility

We have discussed the importance of project stakeholders and explained how capturing their
requirements may affect our project. It is important to realise that prior to the project initiation,
a feasibility study is essential. The feasibility study can be defined as an assessment of
whether the project should go ahead or not. For some people the feasibility study is part
of the project life cycle, while others believe that a feasibility study should be in the form of an
assessment of the situation prior to the project imitation. In either case, the feasibility study
provides useful information and allows an appreciation of the current climate for business as
well as an awareness of how the environment may affect the project.
There are several reasons why the feasibility study is so important. A typical reason for
requiring a feasibility study is the launching of new initiatives, especially in uncharted waters,
in order to avoid spectacular failures. Such a study would allow an assessment of the
likelihood of success and review examples of similar endeavours. Another reason for a
feasibility study would be the creation of new products and services when we are not sure
© ABE
whether these would work antagonistically to what is already on offer by the organisation. In
addition, the study would allow defining the specification and establishing requirements in
line with similar products or services that may be available by competitors. Sometimes when
change is required in established operations the impact on the rest of the organisation is
unknown until a feasibility study provides estimates of what is required to manage such a
change. Projects leading to collaborations and new structures may also need a feasibility
study to identify the actual cost of the new structure in the long term.
So what is offered by a feasibility study? The main elements can be identified as:
 assessing demand – allowing an understanding of what the actual demand is for the
new service or product and therefore justifying the cost and investment
 assessing resources – estimating whether the project is likely to succeed with
existing resources and identifying whether additional resources may become available
and at what cost
 assessing impact – identifying the changes introduced with the deployment of the
project
 assessing timeline – calculating the duration of the project and how this may affect
the success of the project deliverables once deployed.
A feasibility study should be based on the following four steps:
 An examination of the current situation with the aid of scenarios, to establish an
understanding of the background and the environment, and how the project will be
affected by any external factors.
 Assess the project requirements and perform a reality check to establish that these
requirements are realistic and that the plan provides a reasonable way to address
them.
 Then the method followed to implement the project is put to the test to establish
whether it is proven and stable and with a significant chance to succeed against pre-
defined quality criteria.
 Provide possible contingency plans and alternative routes for a number of scenarios
relevant to identified risks.
A number of feasibility study dimensions can help to understand whether the project should
go ahead or not. These are:
 Competitive landscape – the existence of similar products and services that are well
established and quite competitive offerings may lead to a project that delivers
something that has no chance against the competition.
 Operating needs – the needs of the project deliverable to ensure that it is sustainable
after the project completion.
 Scope clarity – the project may be based on unclear scope and conflicting aims or a
vision that is no longer supported by the organisation.
 Financial aspects – the project may be unrealistically budgeted for or may result in
deliverables pricey to obtain or operate.
 Technical aspects – the technology use may be near its end, resulting in obsolete
deliverables.
 Social aspects – the project aims at a market that is incapable of appreciating the
quality of the project deliverables.
 Economic study – the project benefits may not outweigh the costs.
© ABE
 Fundraising study – the project may be unlikely to attract the support required to
complete it.
The Levels of Risk and Uncertainty and Success Factors

So we can see that a feasibility study allows a project to be assessed in terms of its
likelihood of success. An important consideration associated with feasibility study is risk
management and that is discussed further in later chapters. However you should note that it
is quite important to assess the levels of risk associated with the project soon after the
feasibility study provides its findings.
There are some guidelines in terms of how to assess the risk level in our projects and they
can prove quite useful when making decisions. First of all risk management should be part of
the project throughout its life cycle. It is necessary to establish a risk assessment policy that
covers each project activity and links to a specific contingency plan. Another important
guideline is to establish a risk assessment procedure that kick starts once the project is
initiated. This means that any risks may be identified very early in the process. The next
guideline is that the risks should be communicated among stakeholders, as this practice is
likely to result in solutions and proactive steps. Another view is to regard risks not only as
threats but also as possible opportunities to further benefit from the project's deliverables.
Risks should also be classified and prioritised to allow a swift response. Risk analysis should
be a part of the risk management process as it breaks down the risk at different levels and
identifies whose responsibility it is to address particular threats. Also this practice allows the
identification of tasks which are likely to be affected (and when during their timeline). A risk
response plan should be in place to support the step-by-step reaction that is likely to succeed
and also be monitored so producing an accurate reflection of the actual impact when risks
are realised. Establishing a risk log and any responses provides an invaluable tool for future
projects. Finally, risk tracking should take place in parallel with task planning, and project
monitoring should report on project tasks as well as any associated risks.
Review Question 2
Name the five main requirements of the analysis stage.
Now check your answer with that given at the end of the chapter.
C. PROJECT PLANNING – TOWARDS A LIFE CYCLE

MODEL
Quite often project management is discussed in terms of a number of stages that are
required for the completion of a specific project. This is frequently helpful but is often
confused with the project planning activity. It is critical to understand that although project
planning is perhaps the most important stage (since requirements are identified, explained,
defined and agreed), it is still one of the steps that one has to follow in order to complete a
project.
Project stages can be identified as follows:
 definition
 planning
 organising
© ABE
 execution
 closure.
In principle, the project overall aim and specific objectives are defined prior to the stage
involving a detailed plan. The resources and other operational aspects affecting the project
operations and deliverables are then organised prior to the execution and delivery of the
project.
The Basic Project Life Cycle Model

According to Harvey Maylor, the project life cycle is viewed as four interrelated phases
(Project Management, fourth edition). These phases are identified as:
 Defining the project – concerned with the overall organisation goal and the definition of
the project aims.
 Designing the project processes – concerned with the planning activities that may
range from risk analysis and cost estimation to conflict resolution and justification of
decisions.
 Delivering the project – concerned with the control of the project activities,
management of resources, leadership and initiative as well as decision-making and
problem solving.
 Developing the process – concerned with the evaluation of the process by establishing
what must change and a reflection on the project's deliverables.
The project management life cycle suggested by Maylor is illustrated in Figure 1.1. It is
commonly referred to as the 4-D structure.
Figure 1.1: The 4-D project life cycle structure suggested by Harvey Maylor
Define it
Error!
Develop it Design it
Do it
Figure 1.1 shows the transition between the four phases. This could be described as
producing a brief during the "define it" stage that is used for the "design it" stage in order to
produce a detailed proposal. The proposal is then used during the "do it" stage that
concludes with the project outcomes in the form of specific deliverables. Finally the "develop
it" stage summarises the process and product knowledge for evaluation and further
development.
Maylor also discusses the 7-S framework that was promoted by management consultants
McKinsey and Company. This framework can be used to establish a certain level of detail
and quality of work irrespective of the project management stage we are in. This project
management framework is based on seven elements identified as follows:
 Strategy
Strategy provides a high level perception of the requirements identified for the project
and an assessment of how the project aims are going to be achieved. The strategy for
the project may be in line with an overall strategy for a specific organisation or may be
affected by constraints and special characteristics of the project.
 Structure
© ABE
Structure creates a mapping of all those elements required for the successful
completion of the project. The various project requirements are used to identify what
structures must be in place to meet the project's objectives.
 Systems
The use of technology may not be required for the introduction of systems as this
element is concerned with the methods used to achieve project tasks as well as
monitoring and controlling the process.
 Staff
Establishing an accurate record of the staff members involved in the project is critical
for scheduling as well as resource planning. Staffing involves recruitment and selection
and may include training or additional activities to support the skill set needed for the
project. The performance profile of existing staff, as well as the transferable skills that
must be possessed by role holders, are used to align role responsibilities and job
descriptions to individual profiles.
 Skills
The required skills for project management may range from managerial and
transferable skills to technical skills needed to use project management tools.
 Style/culture
The style followed in project management is affected by the organisational culture as
discussed earlier in the chapter, and provides a set of guidelines of what is acceptable
and expected behaviour during the project.
 Stakeholders
Finally the identification of the project stakeholders is an essential part of the
framework as it helps to understand the needs of individuals or groups affiliated with
the project.
The planning phase
At this point we could focus further on the planning phase and how the elements identified so
far may affect the project management decisions. A step-by-step approach to project
planning may include the following:
 defining goals
 identifying deliverables
 scheduling
 planning infrastructure.
Think Point 4
For a project of your choice identify the main steps you should follow during the planning
phase and explain their importance for the project's overall success.
Traditionally, the planning team needs to consider the project's goals, deliverables, schedule
and required infrastructure. Failure to address any of these issues could lead to projects
aiming towards unrealistic goals, project outputs that are not aligned to stakeholder needs as
well as delays and budget overspent.
© ABE
Goal definition step requires a clear and solid understanding of the project. This starts from
a reflection on how the project is described by the initiator (it could be a client or the same
organisation that is managing the project). A stakeholder analysis must follow as explained
previously. Related activities will include the identification of the project sponsor, who is either
the source of funds or where other types of resources are drawn from. The recipient of any
deliverables as well as others involved in various capacities with the project tasks is also very
important. Obviously the analysis of their needs helps to establish the project goals. Such
goals are clearly stated in the project plan and are likely to be used in the future as
performance indicators and the success criteria for the project's progress. The project's goal
is usually described in the form of SMART objectives. This technique is based on the
identification of objectives that are:
 Specific
 Measurable
 Achievable
 Relevant
 Timely.
Project deliverables are sometimes difficult to identify during the planning stage. It is not
always possible to know clearly what must be produced by the end of the project. Sometimes
the requirements of the project may also change, leading to radically varying outputs. This is
why it is a very good practice to provide a working list of project deliverables that is revised at
preset time-stamps that coincide with important developments in the project's life cycle. The
deliverables may consist of documentation, artefacts, systems, procedures, policies and
every conceivable possible result of project activities.
Project scheduling is usually the core of the project plan as it associates the project
objectives with specific deliverables and the resources used. The project schedule depends
on the duration of the project, and the choice of time units used for scheduling needs to be
appropriate for the project duration. For example, for a project that is likely to last for a month
it may not be wise to use weeks as the time units as this will not allow sufficient detail in the
project plan. The scheduling effort must be based on two factors, namely the effort required
and the resource employed. This means that the project activities and tasks are outlined
(usually in a tabular format) and then grouped together according to the project phase with
specific reference to the required resources.
There are various methods used for the presentation of project schedules but the most
common one takes the form of Gantt charts. In these charts each task is represented by a
bar of a certain length, signifying its effort in terms of duration (e.g. number of days) in
comparison to the project's timeline. (Gantt charts are discussed in Chapter 4.)
Project schedules are used to make decisions critical to the project's success. If the project
goes smoothly, then the timeline is followed till the final deadline. If the plan is not in line with
the schedule produced and progress differs significantly then it is likely to require:
 more resources
 more time
 less deliverables.
The first two decisions (more resources and more time) lead to additional resources being
drafted while the third means that the project sponsor must remain satisfied although certain
aspects of the project will not be implemented.
Infrastructure planning is concerned with the provision of sufficient detail to allow the
project manager to control aspects such as workforce, risks and communication. The human
resource plan of a project provides a detailed overview of who will be responsible for carrying
© ABE
out any activities. Human resources can be classified according to department or even
individual roles. On certain occasions it may be the case that a portion of the project is
outsourced. The communication plan of the project provides a protocol that is followed to
establish that adequate communication takes place for a number of important functions such
as making decisions, solving problems, dealing with extensions and delays, assessing
performance, checking progress, monitoring deliverables, etc. The risk management plan
(further discussed in Chapter 2) is a repository of identified risks, usually followed by some
form of likelihood-of-occurrence factor. Typical examples of project risks may relate to budget
cuts, lack of skills, discontinued lines, frequent change of requirements and significant
alteration of project scope.
Quite often project phases are described in terms of different types of model according to the
needs of the project managers. The next section provides an overview of some techniques
that are used when developing project life cycles.
The Suitability of Alternative Life Cycle Models

There is a plethora of life cycle models in project management. The main reason for this is
the need to provide a customised management approach to projects that sometimes seem
quite unique for a certain scenario or a specific organisation. In early project management
days it was quite common for such models to be created in order to fulfil the needs of specific
projects. These days there are so many approaches to project management life cycle models
and it is possible to adapt them to fit the needs of each new project. This section discusses
some alternative solutions for project management life cycle models.
Phased development project management views the entire management activity as a series
of key phases and sub-phases. A project management approach based on phased
development can identify a number of key phases that may be broken down into simple
steps.
Figure 1.2: Phased development project management
Project
Planning Management Monitoring
 Creation  Development  Evaluation

 Proposal  Adjustment  Performance
 Resource  Assessment  Progress
generation
 Reporting
© ABE
Figure 1.2 illustrates a phased development project management approach that is based on
three key phases: planning, management and monitoring. The principle is that the entire
project can be controlled through these key phases. Although the illustration does not provide
any links to show possible iterations and interrelations between the three key phases,
different projects may follow a number of adaptations of the core principle. The underlying
idea is that each project initially enters a planning phase that provides the foundation for the
project (as discussed in the previous section). A number of sub-phases can be identified and
in this particular instance project planning could be perceived as an opportunity to create the
project, provide a project proposal and initiate resource generation from funding to staff
selection.
The project management phase is mainly concerned with the development of the project
deliverables and the necessary activities that make up the project. Assessment of
deliverables and work pattern is also part of the project management phase and it may
include any adjustments made to the original plan. It should be noted that project
management in this instance is viewed as the management of the project activities towards
the generation of the deliverables. Project development is a term that quite often is used to
describe this phase.
The monitoring phase is predominantly concerned with the overall project progress, the
performance of staff and the completeness of project tasks. It is sometimes referred to as
evaluation or testing, although the term "evaluation" only refers to those activities that assess
whether the initial requirements are met, and "testing" essentially addresses the evaluation
needs for more technical projects, especially when the technology is being assessed against
the support provided through tools and techniques developed to meet stakeholder
requirements. Monitoring is not really concerned with any evaluation findings. Reporting is an
activity that enriches the outputs of the monitoring phase.
Life cycle models may be more specific in their description of project management as they
can focus on specific tasks and how the project manager can lead the project team through
these. Obviously the project management tasks identified in these life cycle models are
related and can be broken down further. There are various forms of such models depending
on how information, deliverables and workflow transitions between the tasks. Some of the
more frequent models are:
 Sequential – these models are in the form of a sequence of tasks leading to the
project completion.
 Iterative – these are based on a number of iterations or the availability of cyclic
implementation of certain tasks until a desirable outcome is achieved. There is no
predetermined number of iterations required as certain steps may be repeated several
times before the initial requirements are met.
 Spiral – these are similar to iterative models but also have certain aspects associated
with their spiral nature, meaning that certain project aspects (e.g. risk) may decrease
as we move from the initial parts of the spiral (early phases of a project) towards its
centre (project completion stage).
© ABE
Figure 1.3 illustrates a sequential model that demonstrates how a project shifts from one task
to the next.
Figure 1.3: Task specific project management
Organisation aim
Project objectives
Environment
Resource gathering
Project activities
Deliverables
Evaluation
As shown in Figure 1.3, the initial task is to identify the organisation's overall aim for the
particular project as it sets the background for the project and the foundation for further
decisions. The next task is to proceed with specific project objectives that may involve the
identification of stakeholders. Next, the project enters the environmental constraints phase
which requires the assessment of the organisation's mission and any other filters for the
initial project proposal.
The resource gathering stage may include selection of key staff, adding new members to the
project, budget decisions and any other activities that are reflected in the project's schedule.
The next task includes all activities relating to the project development and the
implementation of its deliverables. The testing and deployment of the deliverables are
followed by the evaluation task. As we can see from the figure, there is an iterative option in
the way the model can be viewed as each step may return to any of the previous ones in
case adjustments have to be made. The number of iterations, the possible paths to previous
tasks and the criteria used to make a decision for an iteration depend on the project and the
organisation's needs.
At this point it should be noted that project managers often include tasks that deal with all
issues following the deployment of all the deliverables and the official closure of the project.
Such tasks depend on how the project is sustained in the organisation. Projects that are
viewed as a one-off delivery of certain services and products usually end with the evaluation
task. However some projects that require continuous support may involve tasks such as
follow-up activities, support, maintenance, etc.
A different approach to project management, especially when products or specific services
are delivered to stakeholders, is through the development of prototypes. Prototyping refers to
© ABE
the development of a "bite" out of the project deliverables, taken in order to assess whether
the deliverables are likely to meet stakeholder requirements. Prototyping is a great way to
give a prompt experience of the project outcomes to the end-users or customers and is quite
often the source of revisions and adjustments following a reality check and reflection
exercise.
The main benefit of prototyping is the opportunity it provides to evaluate the project against
the initial requirements. The process is not particularly lengthy and allows opportunities for
communication and evaluation early in the process. The main drawback is that it may trigger
a second round of requirements capture and may result in additional costs.
Figure 1.4: Phased development project management
Prepare Prepare
prototype prototype
Evaluate Evaluate
prototype prototype
Evolve Throw away Develop main

prototype prototype project
Figure 1.4 provides an illustration of two prototyping techniques, based on evolutionary and
throw-away approaches. The evolutionary approach is very iterative and is used when it is
quite expensive to discard a prototype that has been already developed. The way this
approach operates is by preparing a prototype that is evaluated. After feedback is received
by the stakeholders involved in the evaluation, then work commences on the next version of
the prototype. Once the final evaluation iteration is entered the prototype is then transformed
into the final set of project deliverables.
An alternative to the evolutionary prototyping approach is the throw away version that begins
with a sequential series of steps quite similar to the first iteration of the evolutionary
approach. Once the evaluation results are received, the prototype is discarded and the
information collected is used to start the project development stage. This approach seems
the obvious one when time is an issue and the requirements of capture are likely to remain
unaltered throughout the project.
D. THE PROJECT MANAGER ROLE

So far we have discussed core project management concepts, and this has led us, in the
previous section, to life cycle models. In this introductory chapter it is essential to discuss the
role of the project manager. The project manager is the key person in each project: he or she
is responsible for the successful completion of the project and the achievement of the targets
set.
Before discussing the activities a project manager has to go through, we need to explain that
a project manager must be capable of coming up with the right questions as well as making
sure that answers are given to all project questions. These questions can be grouped
together according to the different tasks that have been identified in the project life cycles as
discussed in the previous section.
© ABE
The following lists summarise the activities the project manager has to undertake.
Project scope and requirements analysis:
 place the project in the organisation context
 identify the stakeholder requirements
 understand the changes the project will bring to the organisation
 prepare for the change management phase
 define the project outcome
 explain the reasons for the project
 describe the stakeholder aspects satisfied by the project deliverables.
Project setting:
 map out the project activities
 select a project management approach
 establish a project proposal
 perform a feasibility study.
Project structure:
 define the project method
 define the project deliverables
 schedule the project.
Project implementation:
 establish an understanding of the project logistics
 address project practical issues.
Project resources:
 decide the budget
 identify sources of project costs
 categorise the resources according to different project phases.
Project partners:
 identify needs for outsourcing
 establish agreements with partners and collaborators
 select tasks for outsourcing
 coordinate resources
 attract additional resources and support.
Project communication:
 establish a protocol for project communications
 provide means for communication and collaboration
 associate workflow with communication opportunities
 arrange etiquette for communication with external stakeholders and collaborators.
© ABE
Project evaluation:
 prepare an evaluation plan
 evaluate against the requirements
 select the project aspects suitable for evaluation
 justify evaluation plans and choices
 provide a sustainability plan.
We will now discuss how such activities are an integral part of the project management role.
At this point you should be able to prepare questions in order to obtain the information
necessary for these activities.
The Diverse Activities of a Project Manager

The diverse activities of the project manager role can be best explained by using what are
known as the "project management process groups". Since 1987 the Project Management
Institute (PMI) has produced the Project Management Body of Knowledge (PMBOK), a guide
that identifies project management processes classified under five process groups and nine
knowledge areas.
The project management process groups are:
 initiating
 planning
 executing
 monitoring and controlling
 closing.
The knowledge areas are:
 integration management
 scope management
 time management
 cost management
 quality management
 human resource management
 communications management
 risk management
 procurement management
The process groups provide yet another approach to the project life cycle, based on specific
inputs and outputs. The input of the initiating phase is the project proposal or work contract,
while the main output is the project scope statement. The next phase which is planning
produces the project management plan. This plan is used as input for the project executing
group that produces the project deliverables and performance reports. The deliverables are
evaluated and approved during the monitoring and controlling phase. The closing stage is
completed once the project final approval and handover are agreed between the project
sponsor and the project manager.
© ABE
Think Point 5
Consider the various roles a project manager must undertake during the lifespan of a project
and discuss how the various aspects of this role may affect the project's outcome.
The project manager should act as a coordinator of project activities, a controller of project
progress and a facilitator of team communications and collaboration.
There are numerous specific activities and tasks that fall under the project manager role in a
typical project. The following examples give an impression of the variety of the
responsibilities the role entails.
Project manager role tasks:
 break down the project into phases and identify tasks under each phase
 allocate tasks to different team members and ensure the necessary skills are present in
the project team
 ensure the necessary infrastructure is available throughout the project
 keep track of the project tasks and avoid any slippage
 deal with personnel management issues as well as appraisals and performance
measurement
 deal with the project budget and any financial issues
 engage in problem solving, conflict resolution and decision-making relevant to any
project activities and associated deliverables
 report on project progress and individual performances
 perform risk assessment and control sources of risk as well as ensuring quality targets
are met.
Quite often, leadership is mentioned as a key virtue that should be possessed by successful
project managers. Adair has identified three main areas of concern when team leadership
skills are defined. In an adaptation of his leadership model, a project manager should be able
to cater for:
 task needs
 team needs
 individual needs.
We can classify some project manager responsibilities under each of the categories
identified by Adair.
Attending task needs
The first action a project manager must take is to plan the work ahead and allocate
resources. It is necessary to identify and define all the necessary tasks as this will allow
estimating the resources required and scheduling the project. The allocation of tasks to team
members means that responsibilities are assigned and quality assurance can start through
regular monitoring of task progress and performance indicators. Inspecting the project
progress followed by an ability to reflect are two skills that are advantageous for the role. The
continuous assessment of performance is closely related to the tasks.
© ABE
Attending team needs

The delegation of work is a responsibility associated with the task at hand but also helps to
foster a team that can deal with crisis. Adopting a hierarchical structure and ensuring that
there is a second in command or a coordinating sub-team can prove an important team
"hygiene" factor. Ensuring that motivation and commitment levels remain high as well as
regulating the team operations are critical activities for the maintenance of an effective team.
Teams require training in order to work together, deal with project tasks and overcome
coordination, communication and collaboration difficulties. Communication skills as well as
people skills help to improve the team spirit and resolve or remove any conflicts.
Attending individual needs
In the end project teams are as good as their members and a successful project manager
must be able to consider the development and learning needs of team members. Although
this is typically perceived to be a career boosting activity, a well-designed continuous
professional development (CPD) programme ensures that the team members acquire the
necessary skills for the task. Sometimes project managers must strike a balance between the
needs of the individuals, the teams and the task. Being able to set the right priorities and
keep the project on track is imperative. Performance measurement, awareness of individual
contributions and reward management are important concepts associated with the well-being
of individuals involved with the project. It is not rare for project managers to undertake a
coaching role, being involved with consultancy, advice and self-improvement initiatives for
project team members.
So far we have discussed the responsibilities of a project manager and the way this role
evolves depending on the different stages of the project as well as a number of varying
perspectives.
We have identified a number of important project manager tasks, but it is also important to
mention some key skills a project manager should possess. The following list is indicative
and by no means complete and final:
 defining project scope
 planning project activities
 designing the project life cycle
 producing a project plan
 planning resources
 justifying resources needed
 scheduling project activities
 providing time and cost estimations
 dealing with budgeting issues
 managing risks
 ensuring quality targets are met
 producing performance reports
 developing timeline charts
 performing risk analysis
 finalising or draft documentation
 leading the team
 dealing with personnel issues
© ABE
 influencing strategic planning

 informing stakeholders
 liasing with project sponsors
 producing analytical reports (e.g. scalability)
 organising outsourcing activities
 being aware of legal aspects
 grasping external factors (e.g. social, political, economic)
 evaluating progress
 preparing/deploying contingency plans
 negotiating project alternatives
 maintaining systems and processes
 managing people and processes
 reflecting on goal setting.
The Importance of Ensuring Good Communication

In the previous section, the possession of communication skills was mentioned on several
occasions since it often proves to be an essential skill for project managers. In Chapter 3 we
will discuss how communication skills affect the success of projects as well as the liaison
between various project stakeholders.
However, it is imperative to understand how good communication throughout a project
depends not only on interpersonal skills of individuals but also on the development of
techniques and processes that nurture communication and enable efficient exchange of
information.
Think Point 6
Explain why establishing good communication between the project team and stakeholders is
critical for the success of the project.
Good communication with stakeholders will help to identify requirements, better understand
aspects of the project that are not clear to end-users, sort out any issues, and deal with
problems in the early stages.
Project management process mapping is a technique for establishing a common
understanding of a project as well as a reference point in communication among
stakeholders. The project process map is a graphical representation of the project's tasks
and their relationships. Such an illustration of the project's structure, main decision paths and
possibly the issues relating to each process, provide a solid foundation for the project's
success.
Process mapping can easily provide an understanding of the project's standing. It can be
used as a snapshot that allows a reality check at any point with respect to how the project
progresses in meeting its requirements. Process mapping provides not only a clear and
concise method of identifying which tasks are under way but also of answering questions
relating to the "actors" of each process and other features including the location,
responsibility and method followed. Scheduling is also a viewpoint on project performance
information that shows tasks on targets and possibly delays. The criticality of different tasks
© ABE
can also be shown in relation to any problems or issues arising and obviously a
representation of the allocated resources, a reflection on their suitability and an estimation of
any additional ones that may be needed.
The process mapping is based on a number of clear steps, including:
 identifying processes
 assigning responsibilities
 defining quality standards
 reviewing processes
 drawing the map.
There are various techniques that can support the process mapping. A very popular
approach providing support to business process mapping is the Business Process
Management (BPM) approach that is discussed in more detail next. According to the
Association of Business Process Management Professionals (ABPMP):
"Business Process Management (BPM) is a disciplined approach to identify, design,
execute, document, monitor, control, and measure both automated and non-automated
business processes to achieve consistent, targeted results consistent with an
organisation's strategic goals. BPM involves the deliberate, collaborative and
increasingly technology-aided definition, improvement, innovation, and management of
end-to-end business processes that drive business results, create value, and enable an
organisation to meet its business objectives with more agility."
A BPM framework takes under consideration a number of factors, including:
 organisation
 process definition
 process responsibility
 process sponsorship
 process measures
 process awareness
 process alignment
 information technology
 methodology.
The BPM framework can be viewed as a series of phases, including:
 process planning and strategy
 analysis of business processes
 design and modelling of business processes
 process implementation
 process monitoring and controlling
 process refinement.
© ABE
Another established project management approach is PRINCE2 (PRojects IN Controlled

Environments), a process-based method for effective project management. The approach is
based on a number of key processes that can be identified as:
 directing a project (DP) – dealing with initiation, staging boundaries, ad hoc direction
and project closure
 starting up a project (SU) – dealing with information gathering, setting up the team and
creating a plan
 initiating a project (IP) – considering project scope justification, establishing a
management base, assessing the business case, establishing the project foundation,
obtaining resources, dealing with project ownership issues, establishing decision-
making practice, maintaining scheduling and resourcing management control
 managing stage boundaries (MSB) – assuring project phase completion and
assessment of progress, passing knowledge from previous stages to the next to
maintain acceptable progress
 controlling a stage (CS) – including the authority to delegate work, gathering
information, managing change, reviewing and reporting on progress, as well as
intervening when required
 managing product delivery (MP) – agreeing allocated work, forecasting and ensuring
work is done and quality criteria are met
 closing a project (CP) – focusing on assessing whether requirements are met, ensuring
deliverables are accepted, recommending follow-up actions and preparing end-of-
project report documentation
 planning (PL) – being very important for other stages such as the initiation stage,
planning a project, planning a stage and producing an exception plan.
Review Questions 3
(a) There are nine main tasks that fall within the project manager's role. Try to identify six
of them.
(b) List the five main steps of a project process.
SUMMARY
This chapter has introduced the idea of the project and project management concepts. The
first section of the chapter discussed the transition from business objectives to project
description and emphasised the role of stakeholders and organisational influences. The next
section discussed the importance of feasibility studies, requirements analysis and risk
management. The third section of the chapter provided an overview of project planning and a
detailed description of project life cycle approaches. Finally, it concluded with a detailed
review of the project manager role and project management processes.
© ABE
ANSWERS TO REVIEW QUESTIONS

Review Questions 1
(a) The five main project management phases are: scoping the project; developing the
project plan; launching the plan; monitoring the project; closing the project.
(b) The 12 types are: clients; end-users; sponsor; manager; project manager; project
management office; project team; operations manager; top management; resource
managers; contractors; suppliers.
Review Question 2
The five main requirements are:
– identifying project stakeholders;
– capturing stakeholder needs;
– performing a needs assessment;
– performing a reality check;
– establishing an agreement.
Review Questions 3
(a) The nine main project manager tasks are:
– break down the project into phases and identify tasks under each phase;
– allocate tasks to different team members and ensure the necessary skills are
present in the project team;
– ensure the necessary infrastructure is available throughout the project;
– keep track of the project tasks and avoid any slippage;
– deal with personnel management issues as well as appraisals and performance
measurement;
– deal with the project budget and any financial issues;
– engage in problem solving, conflict resolution and decision-making relevant to any
project activities and associated deliverables;
– report on project progress and individual performances;
– perform risk assessment and control sources of risk as well as ensure quality
targets are met.
(b) The five main steps are: identifying processes; assigning responsibilities; defining
quality standards; reviewing processes; drawing the map.
© ABE
27
Chapter 2
Project Analysis
Contents Page
Introduction 28
A. Hierarchical Division of Work 28

Describing Project Scope with Work Breakdown Structures 30
Dealing with Work Packages and Associated Cost Structures 33
B. Risk Assessment and Management 35

Assessing Risks and their Impacts on Projects 35
Planning Ahead and Responding to Risks 38
C. Cost Planning and Estimation 42

Budgeting for Cost and Time 43
Dealing with Cost Escalation and Contingency Planning 46
D. Dealing with Bids, Tenders and Contracts 48

Evaluating Bids and Selecting Contractors 49
Understanding the Content of Contracts to Supply 50
E. Effects of Location on Project Management 51

Managing Differences 53
Summary 55
© ABE
28 Project Analysis
INTRODUCTION
This chapter provides a detailed view of how the analysis stage of a project takes place. The
aim of the chapter is to explain how this work can be divided into manageable units that can
be organised according to our perspective of the project and the aim of the project
management stakeholders. The analysis of a project should not be based solely on the
identification of the work structures needed but also on the assessment of any associated
risks. This ensures that a project proposal is based on accurate structures and follows a
detailed approach in identifying different aspects affecting the negotiated resources and
budget.
Objectives
 justify the need for a specific undertaking (a "project") in order to achieve business
goals
 explain how pursuing the objectives of an organisation can lead to a project definition
and a specification of requirements
 justify the importance of conducting a feasibility study into a proposed project
 identify the various dimensions of feasibility such as financial, technical, social, ethical,
ecological and managerial
 assess the levels of risk and uncertainty in a project and identify critical success factors
 describe the basic project life cycle model comprising definition, planning, organising,
execution and closure stages
 appraise the suitability of alternative life cycle models involving phased development
and prototyping
 explain the diverse activities of a project manager in delivering a successful outcome,
such as estimating, planning, administrating, reporting and leading
 explain the importance of ensuring good communication with all stakeholders, including
the project sponsor and the client.
A. HIERARCHICAL DIVISION OF WORK

Before explaining how the work in a project can be divided hierarchically, we need to become
familiar with the concept of new product development (NPD). Quite a few projects involve
an element of product development and it is often the case that new products are created as
the main outcome of such efforts. The process followed from the initial conceptual stages of
NPD, leading all the way to the development of the deliverables which may range from goods
and artefacts to services and structural elements, is described next.
Designing the process that must be followed by the project always starts from soon after its
inception. We can therefore identify concept development as the starting point for any
project. Obviously this differs according to the way the projects are kick-started. For example,
some inceptions are generated during stages of existing projects, while others are based on
unique ideas of individual stakeholders. Harvey Maylor, in the fourth edition of his book
Project Management, provides a hierarchical approach to planning outline that is illustrated in
Figure 2.1. This approach involves four key elements that initiate from the inception of a
project. Concept development is perceived as the source of the direction a project is
intended to follow.
© ABE
Project Analysis 29
The next element is scope development. This includes the steps necessary to proceed from
an initial idea to a more detailed plan of how this idea must be implemented and assessment
of whether it can be aligned to the intention of the project stakeholders. The scope
development stage can be viewed as an effort to specify what must be created in order to
satisfy the vision of the creators of the initial concept.
The next step is to separate the two main pathways following from the detailed description of
the project scope. This means that our efforts are now split between providing the product
overview and the process overview. The product overview element offers an opportunity to
obtain a holistic view of the deliverables that will be created and describes the project's
output. The objective is to understand how the product satisfies the requirements of the initial
concept and whether the implementation of the product is in line with the conceptual model
developed in the earlier stages of the overall process. It is this process that lends itself to the
final element of the outline planning since it considers the process overview. More
specifically, the process followed from the development of the conceptual model and the
identification and definition of the project scope to the more detailed steps of process design
must be explained. The product and process overview elements help us to put together a
plan of what steps must be followed in order to bring the project safely through a pathway
leading to the achievement of its objectives.
Figure 2.1: Project outline planning as suggested by Harvey Maylor
Concept
development
Scope
development
Product Process
overview overview
The illustration of the four elements in Figure 2.1 shows how the bidirectional arrows
between the different elements give us the opportunity to reflect and backtrack so we can
make adjustments to earlier steps in the process. A good example is the way the scope of the
project may be adjusted after finding out that the product overview has identified problems
with the original ideas. The original outline planning as suggested by Harvey Maylor
illustrates a hierarchical view of the four elements with concept development being on top of
a three-layer structure, followed by the scope development element and eventually leading to
the overview elements. The underlying idea is that the project manager may proceed from
one layer to the next, eventually ending up using the overview elements to define a more
detailed process design.
This suggestion can be adapted to suit those projects where due to lack of time, resources or
even an entirely hierarchical structure, some direct exchange of thoughts is possible between
the concept development stage and product or process overview. In small and medium
enterprises the idea creators are often involved in the management of the project as well as
© ABE
30 Project Analysis
some of the implementation steps and more detailed process. In such cases changes in the
original concepts or adjustments in the scope of the project are more immediate in the way
they manifest in changes to the product and process overview.
Describing Project Scope with Work Breakdown Structures

The scope of the project is formulated through a series of events that involves the maturity of
an initial idea and the development of the concept that triggered the project. It is important to
understand that a number of factors affect the way a concept is developed. The initial idea is
rarely the creation of a single mind, but rather an evolving process that offers the synthesis of
several perspectives.
Therefore concept development must take under consideration a number of contributions
from different sources such as:
 Staff – directors and managers may be the sources of ideas, but the workforce may
help formulating ideas. This may be done either through detailed processes in cases of
marketing and creative departments or with reflective exercises where the
organisation's capacity and resource capabilities are matched to the concept's
attributes.
 Competitors – usually it is the competition that drives progress, by introducing products
or services that an organisation must either match or exceed with even more innovative
and cost-effective solutions.
 Customers – a pull-driven model means that it is the customer who actually drives
change and progress by requesting specific services and products, currently
unavailable. The concept creation is driven by the need to satisfy the customer
requests.
 Suppliers – the suppliers of the organisation who are setting the constraints within the
concept must be developed. Usually the diversification of existing products may lead to
new ideas and successful product development.
 Research and development departments – organisations must invest in R & D
departments regardless of their size. R & D departments are capable of generating new
ideas, introducing new concepts and engaging in the development of new products.
All these sources of new ideas and input for concept development practice offer the
opportunity for an organisation to exploit the new concept and generate new revenue
streams. Some examples could include:
 introducing a licensing system where the developed product or service can be used by
other organisations for a licence fee
 franchising models that allow the use of a specific model of operations based on a
geographically dispersed business model where local partners can represent the
organisation for a commission fee
 selling the idea to a larger firm that may develop it to an extent the concept-developing
organisation is incapable of achieving
 developing a new product or service
 introducing a spin-off company, offering new business opportunities.
© ABE
Project Analysis 31
Scope Planning
So far we have discussed how a hierarchical structure may help to achieve a work
breakdown that will help us to implement ideas into new products. It is necessary to
introduce a method for helping with the identification of what the project scope is as well as
assisting with the planning and management of the scope.
In order to manage the scope of the project we must be in control of the following:
 Project initiation – by being aware of how the project was created and identifying
what triggered the initial idea, we will be able to understand the main aim and the more
specific objectives we are trying to achieve. Unless we maintain a constant strong link
to the fundamental driver for the project we may be in danger of side tracking, and
follow a direction that does not serve our initial concept.
 Change of scope – the initial concept may be based on a great idea, but during the
development process this idea may lead us to certain obstacles that are impossible to
overcome. It is not uncommon for organisations to shift their goals accordingly in order
to better achieve them. This does not necessarily mean failure. Often an organisation
will realise that the objectives set can be achieved more efficiently if the original scope
is changed to fit new requirements.
 Scope plan – planning for the project scope starts with the identification of the scope
itself. Usually we see organisations and their units adopting a common vision. This is a
shared goal that everyone involved with the project should always keep in mind. The
vision is likely to affect the creation of their concepts as well as the pathways followed
when these concepts are further developed. A mission statement may also be present,
providing a set of values, beliefs and perhaps guidance for practice while preparing
project deliverables and being involved with project operations.
Think Point 1
Assuming you are in charge of a web development project, describe how you would control
the project scope. You should discuss each stage – project initiation, change of scope and
scope plan – with specific examples relating to the web development tasks.
Scope planning efforts should be further analysed according to the three main dimensions
just described.
Starting from the project initiation, there are a number of issues we need to consider. First,
the identification of a number of constraints is likely to help us setting a realistic project
scope, which can be achieved within the available project resources. Second, certain
assumptions must be made for a number of issues relating to the project. Such
assumptions could include the way the project deliverables are likely to be used, the real
customer requirements, the operations that may be included in the project, or even the
stakeholders involved and the form the project deliverables will have. The third issue to be
addressed is the selection process that involves decision-making for a number of areas
including workforce deployed, resources needed, structure of operations, management style,
etc. Finally the initiation activities should be concluded with the design of a strategic plan
that offers a mapping of available resources to the identified objectives in an effort to work
towards the required project deliverables.
Having completed all necessary steps for the project initiation we are now ready to move on
with the project operations and assess whether the project is running smoothly or is likely to
attract unexpected difficulties. There are two main factors that project managers should be
concerned with at this stage. First, change management is essential to ensure that the
© ABE
32 Project Analysis
project may alter its course of action and so be capable of adaptation to new settings and a
changing environment. Being able to control the way the project operations change or how
project stakeholders are affected by new requirements or different customer needs is a key
factor for successful project management. Second, performance management provides the
means for monitoring how the project performs against a number of indicators. Performance
management is commonly used by human resources departments but is also used in
operations. On one hand performance monitoring may help us to identify issues such as
employees who cannot perform as required, lack of available resources, the need for
specialised skills and perhaps additional training and continuous professional development.
On the other hand, performance recording could identify certain operations that are
inefficient, support the understanding of why certain tasks do not meet the standards set or
even help with the restructuring of work to increase the effectiveness of the deployed
resources.
Scope planning consists of a number of steps, building on the initiation of the project. The
preparation of a scope statement is in line with the provision of mission statements. The main
difference is that the scope statement provides a detailed description of what is to be
achieved with the project deliverables. Furthermore, the scope must be defined in terms of a
checklist that can be used to assess whether the project scope is achieved. We will have a
more detailed discussion on scope definition and work breakdown structures (WBS) next. It
is necessary for a successful project to have its scope accepted by its stakeholders, as it is
necessary for everyone involved to believe in the project deliverables.
Scope Definition
The scope definition process can be described as a number of steps that can form a
checklist for project managers. In their book, Project Management: The Managerial Process
(2010), Gray and Larson provide such a checklist. The project scope is defined as the
expectations of project managers for the project deliverables. In other words, the project
scope is what the project manager expects to offer to the project's stakeholders when the
project is completed successfully.
The scope definition may have several forms depending on the approach we are using. The
following checklist is indicative, but in general a checklist may include additional items
depending on the project's structure and the need that triggered the initial concept. The
project scope checklist includes:
 Objectives – these should offer a full understanding of what is expected and how the
project satisfies the needs of stakeholders. The objectives may be described in terms
of achieving certain tasks or meeting identified needs. Project objectives may also
include aims for the project duration, cost and resources used.
 Deliverables – these describe the form of the project outcomes. Deliverables can have
different forms ranging from software applications and reports to artefacts and
integrated solutions.
 Milestones – these help with scheduling the project as they identify significant events
in the project life cycle, events that are expected to occur at specific points in time.
Usually milestones are used to reflect on project progress or to initiate a project phase
or key step.
 Technical requirements – these offer a detailed view of how certain goods and
services are expected to adhere to existing standards. Examples of technical
requirements might be acceptable ranges of voltage and frequency, or indications of
what an acceptable performance for services is.
 Limitations and exclusions – the constraints for the project can be viewed as limits
and exclusions. The project limitations may be associated with the resources available
or even acceptable costs and budget items. The project also has a defined set of
potential deliverables and aspects that are not part of the project deliverables, and
© ABE
Project Analysis 33
these form the project exclusions. These are features that, while attractive to
customers, may not be feasible to achieve, and so they are not included in the project
outcomes.
 Reviews – these offer a reflection on how the project achieves its interim objectives
and quite often involve various stakeholders, including customers. The aim is to have a
reality check before the project enters further stages.
Dealing with Work Packages and Associated Cost Structures

A project manager must be able to view a project from several viewpoints. Each project must
be defined in terms of three key features:
 scope
 cost
 time.
Scope has already been defined in detail and describes the project performance towards its
objectives. The cost and time are two concepts associated with the project budget and
schedule. These three issues usually require project managers to juggle and prioritise
according to the project's overall performance. Depending on the nature of the project it
could be argued that cost and time sacrifices may be perceived as easier to accept as
opposed to significant changes of the project's scope. Usually a significant change in the
project's scope would imply major concerns and problems associated with the initial concept,
as well as the problems of acceptance of the project's deliverables by customers and
stakeholders.
Being able to deal with the work included in a project, and more specifically units of work that
are usually referred to as work packages, is one of the responsibilities of the project
manager. One of the key project management concerns is getting the prioritisation of the
project issues right. This is closely related to quality issues for each project. For example, a
project that has its scope changed a few times may end up addressing needs that are not
exactly what the customers require. This leads to a project of poor quality. Similarly, high
quality may not be achieved when cost and time sacrifices affect the project's performance.
Project managers have three options in their prioritisation of the project scope, cost and time.
First, these three criteria can be viewed as constraints, meaning that the original decision for
each of the criteria must not be changed throughout the project. This means that we have to
comply with strict deadlines, rigid budgets and a scope that accepts no changes. Second, the
criteria may be open for enhancement, meaning that if opportunity arises each of the three
criteria might be adjusted to add value to the project. This could be translated in the
reduction of costs, the addition of more resources to certain project tasks or even the revision
of the project objectives and deliverables. The third option is acceptance of the three criteria,
meaning that the originally identified scope, cost and time parameters can be viewed as
rather loose with the possibility of revising them to fit the project's life cycle.
Project managers can use these concepts in their efforts to control the project's performance,
budget and schedule. A typical technique is to prioritise the key project criteria of success by
using a project priority matrix. Such a matrix would take the form of a three by three table
that can be used to check which criteria can be prioritised as a constraint, an enhancement
or an acceptance.
So far we have discussed the project scope and the way the project's deliverables fit in the
overall scope. We need to explain further how the project scope and deliverables are
associated with the project's operation by explaining the concept of work packages.
Creating a WBS
© ABE
34 Project Analysis
As mentioned earlier, a project manager may use a work breakdown structure (WBS) to
assess the project's performance at various stages. Creating a WBS involves a number of
concepts:
 Project – this is the complete project that starts with the initial concept and ends with
the deployment of the project deliverables and the customers' sign off.
 Deliverable – this means a major deliverable that may have several forms depending
on the project's scope.
 Sub-deliverable – this is a supporting deliverable that together with a number of
similar sub-deliverables is required for a major project output.
 Lowest sub-deliverable – this is the lowest unit of responsibility in the project and can
be used for splitting project operations as well as mapping out the responsibilities of
each employee involved with the project operations.
 Cost account – this is a tool used for performance management, when work packages
are grouped together to assign responsibility and measure performance indicators.
 Work package – this is an identified unit of work such as a set of tasks that defines
what is required and how it can be achieved with the available resources.
For example, suppose we are dealing with a project that will deliver an online shopping
website to the customer. We can identify the WBS concepts as follows:
 The project is the entire website, including all required functions and usability aspects.
 Project deliverables may include the interface used by the customers, a database
including the product catalogue and a maintenance manual to be used by the website
administrator.
 Sub-deliverables could be identified for each of the main functions, such as creating a
shopping cart, a registration page and a secure banking function for the online
shopping functionality offered to the visitors of the website.
 Lowest sub-deliverables could be identified as specific interface items, code for the
shopping transactions and the secure mechanism to accept electronic payments.
 Cost account can be used to assess the progress achieved for the user interface, by
identifying the efforts and results on interface design, ease of use and clarity of
navigation.
 Work packages can be identified as a number of tasks to be achieved, such as
shopping cart, registration form, product catalogue, confirmation page, etc.
The work package can be further defined by the following:
 Defining the work required for a specific task. This may include a series of actions,
performance of an operation and on certain occasions the development of a sub-
deliverable.
 Identifying the time needed for each work package and any deadlines for the outputs
generated.
 Identifying the cost associated with the tasks included in the work package. Such costs
may include resources, salaries, equipment, etc.
 Identifying the resources required for each work package and justifying their role for the
successful completion of the work package.
 Identifying of the responsibility of holders for work units, leading to a map of roles for
each work package and associated tasks. An example would be the role holder with
any supporting roles that may help with specific tasks.
© ABE
Project Analysis 35
 Identifying performance criteria and progress monitoring measures for each work
package that may be used at certain interim stages or even as an overall set of
performance criteria when the work package is delivered.
Think Point 2
For a project that is concerned with the development of a sales department in a new location,
identify three work packages and define them in terms of the associated tasks, cost, time,
resources, etc.
Review Questions 1
(a) List the five usual sources for ideas leading to the concept initiation for a project as well
as the project scope.
(b) Name the six main elements included in a project scope checklist.
(c) Identify the six key concepts involved in the creation of a work breakdown structure.
B. RISK ASSESSMENT AND MANAGEMENT

It is essential for project managers to be aware of the main risks associated with the entire
project. It is also very useful for a project manager to be able to associate certain risks with
specific work packages and tasks. Assessing a project's risk means that the project manager
may adjust certain decisions and ensure that the project quality criteria are prioritised
accordingly. The management of risks implies that project managers are capable of dealing
with change and how its effects alter the way a project is controlled.
We can appreciate the role of risk in a project's life cycle by using risk event graphs or similar
risk illustration methods. Such a graph would show the fluctuation of costs associated with
specific risks throughout the project's duration. It is expected that the chances of risks
presenting themselves for any project are quite high at early stages of the project. This
happens because early stages of each project are usually associated with several unknown
factors and unquantifiable sources of risk. Gradually the chance of such risks is reduced
proportionally as time passes, and eventually it becomes quite low. It should be noted that
the chance of a risk occurring is never eliminated as a project manager cannot guarantee
that all risks are catered for. The second variable that may be illustrated in a risk event graph
is the way costs for fixing risk occurrences change over time. Initially the cost for fixing a risk
presence for a project is quite low. This is understandable, as in the early stage of the project
if something goes wrong we do not need to change much. However as we progress along
the project's lifeline, risks and their effects may generate more damage and become more
expensive to rectify.
Assessing Risks and their Impacts on Projects

A risk associated with a project can be defined as the possibility of something happening that
will lead to a loss or damage for the project. The notion of risk is associated with the practice
of risk taking. This is a common practice that project managers see as a necessity for each
© ABE
36 Project Analysis
project. There is the need for a trade-off between the increases of the project's risk in order
to improve the indicators of some quality criteria discussed previously in this chapter. This
means that reducing costs and using fewer resources is likely to increase the risk of the work
schedule not being met.
Project Risk Management
The project risk management process can be described as a series of steps that the project
manager must go through iteratively. This means that at certain points the project manager
may revisit each one of these steps and assess whether the risks initially identified are still
causes for concern. Each time a step is revisited more risks are likely to be identified. The
steps involved are:
 Risk identification – this step involves the analysis of the entire project and a
refinement of each work package in such a way that a detailed list of known risks
associated with each project stage is generated.
 Risk assessment – this step is using the list of known risks from the previous step and
assessing the chance of each happening. There are a number of variables that must
be taken into consideration during this assessment. First, the likelihood of the risk
happening must be estimated for each identified source of risk. This means that we
have to prioritise each risk in terms of its likelihood of occurrence. An example of this is
injury or death of key personnel, a factor that is directly affected by the nature of work.
At this stage it is important to identify any factors that may be affecting the likelihood for
each risk. Second, the severity of impact for each risk must be identified and each
effect must be explained in detail. How difficult it will be for the project to survive the
risk presence must be clear and it should be described in terms of possible pathways
and corrective actions. For example, the loss of key personnel who may have decided
to leave the project for a better job at another employer is quite critical towards the end
phases of the project. Third, the controllability of the risk and its effects is often
associated with the existence of a contingency plan. Project managers should be able
to cope with the occurrence of identified risks. For example, a significant change in
user requirements could be dealt with by a prompt revision of required resources and
skills for a number of project work packages. A risk assessment report with a detailed
analysis of the three risk assessment factors is produced when this step is completed.
It is possible for further risks to be identified while the analysis takes place.
 Risk response development – this step is concerned with two possible approaches.
One approach is that the project manager must think proactively and establish a
preventative risk response methodology. In other words, the project manager must
have a clear strategy to reduce the damage of any risk occurrences. The second
approach, a rather corrective one in risk response development, finds the project
manager dealing with the development of contingency plans and establishing ways for
dealing with crisis. Such practices are further discussed in the following section on risk
management planning. This step produces a detailed risk management plan and
possibly helps in the identification of further risks.
 Risk response control – the final step includes the implementation of a risk strategy
that supports the way a project manager and project officers deal with occurrences of
specific risk events. The risk strategy is structured in such a way that it forms an
organised method for selecting which actions are more suitable for different risks and
for how decisions should be made in the event of a risk event taking place. The
monitoring of the project's performance is a continuous process that is an essential part
of the risk response control step. Once a risk event is observed the risk management
strategy is implemented and the project plan is adjusted accordingly. The project
manager's perspective on change management is an integral part of risk response
control. This is because it dictates how much change will be allowed in the project,
even in cases where a risk provides a significant cause for concern and alters the
© ABE
Project Analysis 37
project environment dramatically. Even at this late step in the overall process, it is
possible to identify further risks for the project.
Risk Management Planning
The risk management plan prepared by the project manager is quite often customised as
each project has its own unique characteristics and environment. A risk management plan
could be based on the development of realistic scenarios and their analysis. But it could be
argued that the establishment of realistic scenarios may prove a hit-and-miss technique, as it
is difficult to identify all possible scenarios. There are two main difficulties with this technique.
On one hand we are not sure whether the scenarios we have identified and described in
detail may prove sufficient to identify and anticipate risks. On the other hand it is unlikely that
the project resources will enable us to identify every single scenario for our project.
The project scope definition and the project's description in the form of WBS offer sufficient
detail for the creation of a main project description in terms of its deliverables. The way these
deliverables are used provides what is needed for the development of several scenarios.
The next step is to analyse each scenario in terms of project risks. Each scenario is broken
down into a series of steps. Each step is then reviewed in terms of possible risks and a list of
those risks posing a threat for the specific step is identified. Each risk is then assessed in
terms of:
 a detailed description of the risk, its cause and the way it presents itself in an occurring
event
 a list of effects caused by the risk event to the project and a specific reference to the
task, operation, process, deliverable or output being affected
 an estimation of the risk event impact and a possible measurement of the severity to
the project in general as well as to specific aspects of the project
 an estimation of the likelihood for the risk event happening and a report on those
factors affecting this likelihood
 an assumption of the timing for a risk event and an analysis of the project's timeline to
identify possible time-stamps for risk occurrences
 an association of risks with resources used elsewhere and an identification of events
that may be caused as a knock-on effect of risk occurring in other projects.
Think Point 3
Assess several risks associated with a project that deals with the expansion of a restaurant
chain to a new city with three new restaurants being added to the existing fifteen venues.
The risk assessment of the project should include a description of the risks, impact,
likelihood, assumptions and links to other projects.
Risk Identification
There are no set ways for identifying project risks, and it is difficult if not impossible to
provide specific guidelines of how to identify causes of concern. It is quite often the case that
project managers follow ad hoc procedures that have worked in the past, adjusting certain
aspects based on the special features of the project at hand. A very helpful technique is to
attempt a risk profile by tracking a project one work package at a time. We can then identify
aspects of risk profiling and describe each risk in a detailed way. Risk profiling is not based
on specific sources of risk as these are not consistent for all identified risks. It is more likely
to attempt a risk profile by identifying the possible sources of risk.
© ABE
38 Project Analysis
One of the main areas of project risks relates to costs and budgeting. For example, cost
estimation may not be accurate or economic changes or social instability may affect the way
the project budget is structured.
Scheduling of the project is almost always an area of concern as the timing, deadline and
workloads may be inaccurate. The estimation of work required for each work package may
be false and additional requirements or task difficulties may lead to extensive revisions of the
project schedule.
Quality standards and performance management may lead the project to an adjusted scope
and even a revised plan. The risks associated with quality are very important as a failure to
meet standards late in the project may lead to complete failure of the project.
There are certain risks associated with the processes followed in the project's life cycle. For
example, training and induction tasks may prove inadequate and skill-building professional
development tasks may require more time and resources. The analysis, design and
development of deliverables may run into problems that require more time and costs. Testing,
evaluation and deployment are always sources of nasty surprises for project managers.
Additional risk causes may include staffing and other resources which may differ from the
original estimations. External changes to the project environment may affect the way the
project operations are controlled. Customer requirements may change either due to the
presence of a competitor, lack of understanding, timing of products and services or even
external factors such as industry trends and the economic situation of the local market.
Planning Ahead and Responding to Risks

A successful project manager is one who is capable of following a detailed risk management
plan. As mentioned earlier, such a risk management plan is based on the identification of the
project risks. Initially the project manager must be aware of all external and internal sources
of project risks. The next step is to become familiar with risk indicators and any symptoms
that would help the early recognition of a risk event. Another approach is making
assumptions for time and cost estimations associated with project operations and work
packages. Furthermore, an analysis of the total cost of quality (TCQ) (the total of costs
arising from poor quality or product failure) provides useful information for further sources of
risks that may appear after quality trade-offs (and obviously the likelihood of those risks).
Responding to risks implies that a response control strategy is in place. This requires the
project manager to identify opportunities and threats for the project. Opportunities should
offer themselves for increasing the project's success and reducing the requirements on
resources, time and costs. These opportunities are balanced with threats, either due to
internal or external factors, to the project outcome. Opportunities and threats analysis as well
as identifying the strengths and weakness of the project are likely to help project managers
to identify ways to respond when an opportunity or threat appears. Corrective actions are
expected when a project reaches a risk event. Such actions are likely to be part of a
contingency plan which is often based on the use of back-up resources.
Finally the quantification of risks and their likelihood is very useful for risk management and
control. Estimating the likelihood of a risk could be based on either a qualitative or a
quantitative risk analysis. Whichever method is followed, the estimation of the risk effects and
the effort required to deal with them requires the attention of the project manager.
Qualitative Risk Analysis
A typical approach for risk analysis is to gather information from various project stakeholders.
This leads to a qualitative analysis, in order to understand risks and establish a risk
management plan.
As mentioned earlier, risks are assessed in terms of their likelihood and impact on the
project. A qualitative approach could be based on identifying from project stakeholders a list
© ABE
Project Analysis 39
of risks. These are then assigned certain values to their probability of occurrence and their
severity for the project's operations. An example of such a technique would be to create a
matrix that would help to identify risks and classify them according to their likelihood and
impact as shown in Figure 2.2. This illustrates how risks can be classified accordingly and
helps identify clusters of risks with similar impact and probability values.
Figure 2.2: Probability-impact graph
Probability
High
 Redeployment
Medium  Retirement
 Death
 Government change
Low
Severity
Low Medium High
Think Point 4
For a project dealing with the change of name and packaging of an energising drink, use the
probability-impact graph to identify certain risks. The identified risks should be classified
according to the probability and severity as estimated.
A more advanced technique is to provide a failure mode effect analysis (FMEA). This
approach takes into consideration the likelihood and severity values of certain risks in a
similar way to that just described. However a third notion – "hideability" – is introduced: this
describes the possibility for a certain risk that may be present at a project operation, work
package, stakeholder group or stage and remain hidden from the project manager. The
possibility that a risk might be hidden is a very important factor to take into consideration, as
the impact of any risk becomes significantly higher when a project manager cannot prepare
for it.
The FMEA method is based on calculating the risk priority number (RPN) for each risk by
multiplying the values of the three concepts expressed as integer numbers. Therefore the
RPN for each risk is a number that helps us prioritise each risk, calculated as follows:
RPN = severity  hideability  likelihood
By expressing each concept as a number between 1 and 10, we may have a minimum RPN
of 1 and maximum RPN of 1000. It is obvious that the qualitative nature of this method
© ABE
40 Project Analysis
relates to the fact that the values given to the three concepts are based on data gathering
taking place between stakeholders, and include a certain level of estimation (based on
certain assumptions) from the project manager.
Quantitative Risk Analysis
Quantitative methods in risk analysis are quite useful when we need to provide a
mathematical approach in identifying and assessing risks. Some quantitative methods
include:
 Expected value – an expected value can be assigned to any event, including risk
events, providing an estimation of the impact that the event will have on the project in
terms of monetary values. It can be calculated by multiplying a percentage representing
the probability of an event occurring with the value of this event. For example, the
expected value of a project takeover that would cost an additional £50,000 and has a
50 per cent chance of happening is £25,000. This expected value would be the same
as the replacement of the managing director which would cost £2,500,000 but has a
one per cent chance of happening.
 Sensitivity analysis – this technique is based on calculating three values for each
entry in the project's budget, in order to take into account possible opportunities and
threats. Therefore when calculating the cost of workforce, overheads and raw materials
for a project we provide three entries for the budget. The main entry is the expected
value for each budget item. This is used as an expected cost as indicated by the
project manager. The other two values for each item represent an estimation for worse
and best case scenarios. In other words, these two values offer a range for the
minimum and maximum values a budget item may fluctuate within before creating a
crisis to the project. The two values are calculated based on the expected value with an
adjustment of n per cent. The value of n depends on the range of values we aim for. It
is quite common for project managers to calculate these values based on (plus or
minus) five per cent to (plus or minus) ten per cent.
 Monte Carlo simulation – this is a mathematical technique that uses computer
processing to calculate risk in decision-making and risk analysis. The simulation is
used in order to provide a range of possible outcomes for the project with the
probability for each outcome to occur based on certain actions. Monte Carlo simulation
is based on the probability distribution concept that represents a range of values for
a known risk. By recalculating each possible combination of the value range
(representing the cost/income) for several identified risks we may create several
scenarios of how our actions may affect the project's outcome.
 Programme evaluation and review technique (PERT) – this provides a useful tool to
help in understanding any alterations to a project's original schedule. The technique
offers a method for calculating the time required for project activities and is based on
providing three time estimates for each activity concerned. Therefore each activity is
described in terms of (i) an optimistic time showing how long it would take for an
activity if everything runs smoothly, (ii) a most probable time showing the time the
activity takes under a normal scenario and (iii) the pessimistic time showing the time
required for the activity if a number of risk events occur. The three values help the
project manager to identify expected times for each one of the project activities.
Risk Response Planning
As part of the risk response plan, the project manager must be able to identify what is
expected by the project and identify the project outcome in terms of certain measurable
features. The next step is to identify best and worst case scenarios in order to establish a
series of actions that must form the contingency plan if risk events take place.
A risk response plan involves two very important concepts, those of risk transfer and risk
acceptance. Risk transfer is the approach followed by a project manager when the risk
© ABE
Project Analysis 41
management strategy is outsourced to another organisation capable of dealing with the

project risks and their impact. However it is possible that an organisation might prefer being
in control and avoid transferring the control along with the risks of the project to an external
party. In such cases, risk acceptance means that the project manager is prepared for certain
risk events to take place, prioritises their impact and likelihood and has in place a series of
contingency plan. In addition, there are two approaches that provide a more defensive
approach: risk avoidance and mitigation. With risk avoidance a project manager is
prepared to drop a task or an entire work package and associated deliverables in order to
avoid even the presence of the source of a specific risk. On the other hand, a less drastic
approach (i.e. mitigation) resorts to minimising the probability of a certain risk event taking
place.
Risk Monitoring and Control
The two main approaches in risk monitoring and control are establishing a risk register and
a risk log. A risk monitoring approach means that the project manager makes sure that the
possible risks are monitored continuously even if certain aspects of the project meant that
specific risks may be avoided.
A risk register uses the methods previously discussed to identify each risk and describe it in
detail in terms of its likelihood, source, effects, impact, symptoms, etc. The risk register can
be used to trigger a response plan that may be in place. On the other hand, the risk log offers
a diary for project managers to record possible risk events and their occurrence. Following a
risk log entry, the project manager can record the response event and how any corrective
actions that followed have performed.
There are several monitoring and control tools, including:
 Work breakdown structures – as mentioned earlier a WBS offers a hierarchical view of
tasks and helps identify problems with specific work packages.
 Estimated and actual project budgets – helps identify risks associated with incorrect
budgeting and lack of sufficient resources.
 Project schedules – offers a reflection on the project progress and is likely to identify
symptoms such as delays, overlapping, under-resourcing and over-resourcing.
 Earned value of project activities – provides a detailed overview of the way each
project activity adds up to the total project value. Further analysis may offer insights of
what happens when corrective actions are not taken immediately, reducing the earned
value for certain work packages.
 Project resource list – provides a detailed list of all resource items made available to
the project.
 Project plan – helps establish whether the project scope is maintained at various points
of the project timeline.
 Change control log – a tool for logging any changes and alterations that have taken
place, usually due to the occurrence of a risk event.
A risk control process is likely to benefit the project in a number of ways. It offers awareness
of the project's progress and status to the project manager as it provides a progress
snapshot at given times. It supports the documentation and monitoring of any corrective
actions taken. It helps with the establishment of a risk management plan that deals with risks
as they appear.
A risk control process makes sure that any actions are recorded in such a way that their
impact on project costs reflects on an updated budget. Similarly, the risk control process
ensures that project schedules are updated accordingly once a risk event affects a portion of
the project operations and activities. The documentation of the risk log helps to disseminate
© ABE
42 Project Analysis
the impact of any risk, the effects to the project and a reflection on how the response
provided ensured project continuity.
Review Questions 2
(a) Identify the four main project risk management steps.
(b) Name the four main quantitative risk analysis methods.
(c) Identify the seven most common monitoring and control tools that can be used in risk
assessment.
C. COST PLANNING AND ESTIMATION

A very important aspect of project management is providing cost estimates and planning for
the costs of the project activities. Previously in this chapter we briefly discussed a number of
techniques used for cost estimation and activity planning. It is important to remember that
most times the project plan cannot be based on completely accurate estimates as a number
of factors may affect the time and cost of each activity.
It is necessary for project managers to be able to break down projects into tasks and
estimate the workload associated with each one of these identified tasks. Each project
activity may vary in terms of its duration. There are certain factors affecting activity duration
and depending on how these factors are addressed in a project, the original estimations may
prove accurate or show a dramatic increase or decrease on required time.
We can identify some causes for varying activity duration as follows:
 Skills – the lack of a consistent set of skills in the project's workforce means that the
same task may be achieved at different times when different people are in charge of it.
The skill variation can be dealt with through continuous training, but individuals will still
show different capabilities and adaptation to newly acquired skills.
 Events – the risks identified in previous sections may present themselves in a variety
of events, affecting the way activities are undertaken and perhaps providing additional
time overheads.
 Efficiency – the efficiency of an activity can also be measured in terms of the time and
cost associated with the way an employee undertakes his or her role. Interruptions,
obstacles and external factors affecting one's attention, focus and performance may be
part of the reasons for a less than optimal work pattern.
 Errors – mistakes that can be caused by individuals, teams or errors on decision-
making and problem solving might also cause activities to fall back. Project managers
may also cause some delays if they make wrong decisions when dealing with the
project work packages as well as managing the overall process.
 Random variations – project activities are calculated in terms of cost and time based
on assumptions and individual estimations. The mathematical models and techniques
that attempt to quantify each activity will never be capable of an exact match. One of
the reasons is the lack of a harmonic and homogeneous approach on establishing the
exact duration of each project activity. Eventually even minor variations will exist when
we attempt to calculate the duration of a project task.
© ABE
Project Analysis 43
Think Point 5
Explain why two teams that deal with similar projects in construction show significant
variation in the duration of key activities. You should identify a number of activities and
explain how and why their duration may vary significantly. Your discussion should focus on
skills, efficiency, errors, etc.
Budgeting for Cost and Time

When budgeting for cost and time, project managers may be affected by a number of factors
depending on the setting and environment of the project. One of the most important aspects
we need to take under consideration is the planning horizon as it definitely affects the
accuracy of estimates. It is quite different to assess the cost of an activity that is expected to
take place in a week, compared to one that is six months ahead. The duration of the project
is also important as sometimes even the technology used may change before the project is
completed. This is a factor we need to consider when dealing with long-term projects. The
human element is an essential feature of cost and time estimation, as we are not always
sure whether we will allocate roles correctly and if the team put together is capable of
providing an optimum solution. A team that falls apart, or dealing with conflict and
interpersonal relationships are examples of why cost estimations may be revised after the
project initiation. The structure of the project may lead to several teams working together
and a rather complex set of interrelated activities. The domino effect created in such projects
may lead to spiralling costs if the estimation for a particular work package is wrong. The
estimate padding phenomenon describes the practice of adjusting estimates to fit the
project requirements and perhaps the context of a project activity. In other words a project
manager may provide either an average estimate or a more optimistic or pessimistic value
according to what impression must be made. The corporate culture notion is discussed
later in this chapter, but it is an important aspect of project management as it dictates how
the cost estimation is based on average values or allows a range to be used.
Project Procurement Management
As mentioned in Chapter 1, the Project Management Institute (PMI) has produced the Project
Management Body of Knowledge (PMBOK), a collection of processes and knowledge areas
accepted widely in the field. It has for years been recognised as a standard and describes
five basic process groups and nine knowledge areas in the project management field.
The five project management processes are:
1. initiating
2. planning
3. executing
4. monitoring and controlling
5. closing.
The nine knowledge areas are:
1. project integration management
2. project scope management
3. project time management
4. project cost management
5. project quality management
© ABE
44 Project Analysis
6. project human resource management

7. project communications management
8. project risk management
9. project procurement management.
Each of the project management processes are described in terms of: (i) inputs that may
include documents and designs; (ii) tools and techniques that are used to process the inputs;
and (iii) outputs that can be in the form of documents and deliverables. Each one of the nine
knowledge areas includes several project management processes.
The project procurement management knowledge area includes the following topics that are
further discussed next:
 procurement planning
 solicitation planning
 solicitation
 source selection
 contract administration
 contract closeout.
The project procurement management process assists managers in obtaining resources from
external suppliers. The process includes tasks such as ordering, receiving, reviewing and
approving items from suppliers. The process is used to identify and obtain items required as
well as establishing an effective relationship with suppliers. Some of the benefits of the
procurement process can be identified as:
 identifying goods and services to procure
 creating and issuing orders to suppliers
 confirming delivery methods and timings
 receiving ordered goods and services
 reviewing and accepting items ordered
 approving payments and settlements with suppliers
 constructing supplier contracts
 assessing supplier performance and impact
 resolving any issues with suppliers
 monitoring project procurement status.
In summary, we could define the project procurement management process as a series of
steps dealing with: (i) the identification and ordering of resources required by the project; (ii)
the creation of supplier contracts and the management of contractual obligations and
expectations; (iii) the administration of any contract issues; and (iv) the maintenance of the
relationship with suppliers.
Procurement management is also covered by the body of knowledge published by the
Association for Project Management (APM).
Plan Purchases and Acquisitions
The process of planning purchases and acquisitions deals with planning the resources that
are required for the project and determining how to obtain them. There are specific inputs
required for the plan purchases and acquisitions process. These inputs can be identified as
follows:
© ABE
Project Analysis 45
 Enterprise environmental factors – meaning that the state of the local market is likely
to affect the availability and the cost of the required resources
 Organisational process assets – meaning the policies and procedures in place that
may be constraining the way procurement decisions are made
 Project scope statement – meaning that the project scope, boundaries and
assumptions may affect the timeframes and budget specified for resources required
 Work breakdown structure – meaning the relationship between project tasks and the
association between resources used in related tasks
 WBS dictionary – meaning the specification of the work required as part of each
deliverable and the identification of each deliverable
 Project management plan – meaning that the overall project management plan is
likely to include details such as a contract management plan and a procurement
management plan.
The details included in project management plans help assessing the procurement needs of
the project. Planning outputs that may affect the identification of resources to be procured
may include: (i) risk register; (ii) risk-related contractual agreements; (iii) activity resource
requirements; (iv) project schedule; (v) activity cost estimates; (vi) project schedule; (vii)
activity resource requirements; and (viii) cost baseline.
There are a number of tools that may be used in plan purchases and acquisitions. These
tools include the following:
 The make-or-buy analysis technique allows project managers to make informed
decisions about resources required and more specifically whether the project should
invest in producing the needed items or seek them externally. A buy decision is likely to
trigger a call for proposals, include a selection stage and the definition of contract to
supply details.
 The expert judgment technique seeks advice from experts when confirming the
specification of required resources as well as sourcing the goods and service needed
from external source.
 Contract types are the tools used for establishing supplier contracts and may lead
either to: (i) fixed price contracts that are based on establishing a fixed price for a well-
defined product; or (ii) cost reimbursable contracts that deal with the payment of the
actual supplier costs with an added profit. The cost reimbursable contracts may be in
the form of: (i) cost-plus-fee (CPF), (ii) cost-plus-percentage of cost (CPPC), (iii) cost-
plus-fixed-fee (CPFF) and (iv) cost-plus-incentive fee (CPIF).
The output of the entire process is in the form of the following:

 The procurement management plan which may include the type of contract to be
used, the cost estimation for goods and services, the creation of procurement
documentation, selection process, negotiation of contracts, etc.
 The contract statement of work in the form of a statement of work (SOW) that
describes what must be supplied, including any constrains, rules, timeframes, etc.
 Make-or-buy decisions in the form of documentation that includes any identified risks
and an estimation of the actual costs of both type of decisions available. The
documentation is needed to justify the final decision made.
 Requested changes are a set of changes made to the project plan following an
estimation of the cost and time required for the supplied goods.
© ABE
46 Project Analysis
Think Point 6
Explain how a contract statement for work on the installation of a lift in a new building
development may trigger negotiation between the project manager and suppliers. The
discussion should be focused on how the suppliers and the project manager are likely to
negotiate the specification of goods, support services and other features of the required
resources.
Dealing with Cost Escalation and Contingency Planning

The project manager must be capable of making well-informed decisions on how the project
phases are associated with costs and time requirements. The process of creating cost, time
and resource estimations is critical for the project as any mistakes made are likely to cause
escalation of costs. The project manager must also have a contingency plan in place, ready
for deployment if the initial estimation proves false.
A typical approach in providing such estimates is arrived at by reviewing the project work
packages with a number of criteria in mind. The estimation of work packages should take
under consideration the following:
 Assuming responsibility – work package estimations should be made either by the
project manager or after consultation with project stakeholders who are knowledgeable
in the field and capable of understanding what the work package entails in terms of
work and resources required.
 Obtaining several perspectives – any estimations should be reached after the work
packages are reviewed by several stakeholders having different roles in order to obtain
a 360-degree feedback on what is needed for the specific work packages.
 Estimating for normal conditions – the estimations provided should be for normal
conditions as far as the project setting, its environment and resource availability are
concerned.
 Defining time units – from the early stages, the project should be structured based on
agreed time units that best reflect how the work packages and tasks associated with
deliverables can be structured. When using a suitable time unit, the project schedule
can be easily structured and revised.
 Maintaining project independence – since the project may be associated with other
projects and receive input from external sources it is necessary to attempt maintaining
a relevant independence of the estimations. By achieving this it may be possible to
avoid any future changes due to uncertainties caused by links to external sources.
 Preparing contingency plans – the estimation of any costs should take into
consideration the effects of change, the possibility of the situation being far from the
assumed norm and other project surprises. The cost of any contingency plans should
also be considered.
 Including risk assessment – the cost of identified risks that may be estimated
following the techniques we discussed earlier in the chapter should be included when
the overall project cost estimation is prepared.
Determining the Project Budget
The project budget is the estimation of the total costs associated with all the project activities.
This estimation of monetary resources is important for project managers – they need to
establish whether the project operates within the acceptable financial limitations established
by the stakeholders.
© ABE
Project Analysis 47
The determination of the project budget requires the project manager to consolidate all
separate estimations into a single document. The aim is to establish a holistic understanding
of all identified costs that may be incurred throughout the project. This is achieved by
following a number of steps which encompass the following:
 WBS decomposition – this will help identify every single task of the project and
therefore evaluate all costs associated with the entire project
 historical data – this step reviews previous budgets from similar projects and uses the
findings as a foundation for establishing the final budget
 lessons learned – this is based on key findings from previous experiences and such
lessons may be learned by the project manager, the project team, other stakeholders
or the organisation at large
 resource profiling – this means collecting information for various resource items as well
as any procurement details that contribute towards the overall project costs
 project policies – this step offers the framework within which the budget calculation
may be drawn, including any constraints the project may have.
The determination of the project budget uses the following as input:
 activity cost estimates that calculate the cost of every single work package
 basis of estimates that clarifies how decisions are made for the inclusion or exclusion
of costs
 scope baseline that splits the project in specific work packages and associated cost
units
 project schedule including deadlines, time plan and timeframes for activities
 procurement contracts that identify the costs associated with the provision of goods
and services from suppliers
 resource calendars that specify the timeframe for resource provision as well as the
allocation of tasks within each work package.
This budgeting effort provides three main outputs:
 a cost performance baseline that offers a budget that can be used to assess the
project performance at specific intervals
 project funding requirements including the overall funding required as well as all
identified costs
 project document updates such as schedules and risk registers that may be affected
by the finalised budget.
Review Questions 3
(a) List the nine project management knowledge areas described in PMBOK.
(b) Identify the two contract types which can be used for plan purchases and acquisitions.
© ABE
48 Project Analysis
D. DEALING WITH BIDS, TENDERS AND CONTRACTS

Project managers must create a product breakdown structure (PBS) similar to the WBS
produced during project planning. The aim for producing the PBS is to identify the
requirements for materials, goods and services needed throughout the project. The project
manager must be capable of dealing with a number of tasks, such as:
 traditional purchasing
 materials management
 supply chain management.
Certain project phases require a traditional, old-fashioned purchasing order for materials
based on what resources the project tasks need. This is relatively straightforward and
requires the invitation to tender and the acceptance of bids, followed by selection and
preparation of contracts. The way materials are managed implies that the project manager is
in control of the timeframe used for the supply of goods in such a manner that the project
schedule is not affected and there are no resources remaining idle. It also implies that delays
occur due to the inability of suppliers to produce what is needed.
When the resources required are composite a more advanced way of organising suppliers
takes place through a supply chain. An example of this could be when computer systems are
delivered, where suppliers may include hardware and software developing firms. It is likely
that another firm will also be involved, to integrate the hardware and software components
into a fully working system. So in this example there are three tiers prior to the organisation
receiving the computer systems, with the hardware supplier, software supplier and integration
contractor being lined up before the finished goods are dispatched. Similarly the output of a
project may reach intermediaries such as distributors or sales departments before reaching
the end-users. Being able to manage this supply chain requires a critical set of skills that
every project manager should possess.
We can identify a number of steps that can be followed for a typical purchasing process.
These steps may vary between projects but are required to establish a solid process that can
be used for the main orders of goods and services for each project. These include:
 approving purchasing stakeholders – it is necessary to be in control of who may order
goods and services, and such permissions may be granted to several members of staff
involved with specific project phases and work packages
 requesting goods and services – the specific goods and services are requested from
the purchasing department
 assessing purchasing orders – the purchasing orders are confirmed by assessing
possible inventories and internal sources for the required goods
 searching for suppliers – a list of potential suppliers is drafted and invitations to tender
may be sent out
 placing orders – the order is placed to the selected supplier following a negotiation of
contracts, unless supplier policy is followed
 receiving goods – the goods are provided and received by the organisation
 assessing purchased goods and services – the goods are assessed against the order
made and the original requirements from the project work packages
 paying for the goods – the payment for the services and goods is made.
© ABE
Project Analysis 49
Evaluating Bids and Selecting Contractors

Which suppliers are likely to offer the most in terms of value and quality of service? A number
of processes are involved in choosing the most suitable supplier, and working towards a draft
contract we can identify the following steps:
 determining the requirements for goods and services
 issuing an invitation to tender (ITT) based on the legislation that covers the economic
area the organisation operates within
 accepting tenders or bids by the set deadline (these may be sealed or open depending
on the process followed)
 assessing the suitability of each proposal received
 considering how the bids affect the project budget and existing estimations and
assumptions
 establishing a contractual arrangement with the selected suppliers.
Plan Contracting
When project managers plan for contracting they must provide a detailed documentation of
the resources required and any identified suppliers. The plan must include details of how the
procurement process should take place and also aspects of the contractual agreement.
The plan-contracting process is based on a number of inputs including:
 a procurement management plan
 a contract statement of work
 make-or-buy decisions
 the project management plan.
The project management plan is likely to provide information included in the:
 risk register
 risk-related contractual agreement
 resource requirements
 project schedule
 activity cost estimates
 cost baseline.
Once the goods required are identified, the project manager must generate a number of
documents depending on the process that is to be followed. A request for proposal (RFP)
requests the generation of a specific plan explaining how the work will be carried out and
how the goods will be produced by the supplier. The invitation for bid (IFB) or request for bid
(RFB) is issued when the project manager has a clearer idea of what must be produced. A
request for quotation (RFQ) is used when a quotation is needed per item, hour of work or unit
of service provided. These documents are likely to produced using standard forms that have
been designed for use in similar projects.
Expert judgment should also be applied in the form of structured reports offering further detail
and justification to support any purchasing decisions.
The output of the plan-contracting process takes the form of procurement documents
including detailed orders with some justifications for the main purchasing decisions. A
contract statement of work (SOW) is yet another output, together with any documentation
clarifying evaluation criteria and selection processes.
© ABE
50 Project Analysis
Request Seller Responses

The process of requesting seller responses should be based on offering suppliers the chance
to submit quotations, bids, and any associated information with their supplier services and
detailed proposals.
The seller responses required by the project manager will have been identified as part of the
plan-contracting process. The main distinction between the different types of request is
whether or not the project manager is capable of specifying the goods to be ordered in detail.
A request for proposal is likely to be sent out when the goods required do not have to adhere
to a very detailed specification. A request for bids is more suitable when the project manager
requires a very specific input and the selection is likely to be based on the ability of suppliers
to match the requirements of the invitation to tender.
Think Point 7
For a project that requires the development of several new classrooms in a further education
college, explain how you would request supplier responses for a number of required
resources. Focus your consideration on furniture and computer equipment, as well as
construction services and decorating tasks.
Select Sellers
The process of selecting a seller for a resource item involves reviewing the available
proposals and the selection of the most suitable seller. Part of the process is the negotiation
of the contract details.
A tender evaluation process can be either in the form of a bid examination and
determination of responsiveness or a detailed bid evaluation. The eligibility of bidders
must be assessed and this can be done by taking into consideration such factors as:
 prior experience of the sellers
 economic standing and stability of finances
 skills, experience, knowledge of seller
 equipment capability and infrastructure available
 arbitration history.
In order to make the selection a project manager must assess the experience of a bidder. A
typical test should focus on whether the supplier can operate in the environment provided
and on its relationship with its customers. The ability to meet the needs of the customers and
deal with legislation, administration and other factors that may affect the supplier's work is an
additional criterion. Quality management, service support, management policies, staffing
procedures and similar internal operations are certainly helpful to assess the well-being of
the organisation.
Understanding the Content of Contracts to Supply

There are two key processes involved with the preparation of the content of supply contracts
– contract administration and contract closure. It is essential to understand the importance
and the key aspects of each.
Contract Administration
© ABE
Project Analysis 51
The administration of the contract involves any corrective actions that may be required due to
the effects of external events. This quite often requires the project manager to maintain and
control the relationship with suppliers.
The administration of contracts includes the negotiation of the contract elements and is likely
to be based on an initial process going through several drafts of the contract. Renegotiation
and revision of the initial contracts may also be part of the process in more complex project
structures and supply chains.
Contract Closure
The closure process requires the project manager to hand over a specific portion of the
project and its deliverables. This means that each contract should be settled and any issues
should be resolved. The contract closure means that the specific part of the project should be
regarded as complete.
Once the project is complete the project manager must:
 release any resources so they can be used in other projects
 settle any financial issues
 complete project documentation and update any record keeping and associated
archives
 hold an end-of-project session and establish the lessons learned by the project
stakeholders through brainstorming.
An evaluation report for the project could include:
 sign off documents
 staffing and skills used
 organisational structures
 schedule management
 cost management
 quality management
 configuration management
 customer expectation management.
Review Question 4
List the eight main steps involved with the purchasing process in a project.
E. EFFECTS OF LOCATION ON PROJECT MANAGEMENT

The ways in which a project may be managed vary considerably, depending on where we
conduct our business and whether a project is tied to a specific location. There are several
factors that must be taken into account when setting up a project and location is one of the
most important ones. The location of a project can be determined in a number of ways. For
example, the country which is host to the organisation in charge of the project might be one.
Alternatively the project's location may be determined by where suppliers, customers or other
© ABE
52 Project Analysis
stakeholders reside. A different perspective could depend on where key operations take
place or how the organisation's presence is defined in terms of buildings and services. Since
a significant portion of today's organisations have a multinational presence, it is necessary to
understand how location affects the way projects are planned, designed and run. It is also
critical to become aware of aspects relating to location issues that may be affecting decision-
making and problem solving. Such aspects may relate to geography, political and economic
issues, culture, government policies, values and beliefs; many different location issues are of
concern for the modern project manager.
Before considering an analysis of such aspects and their role in project management, it is
necessary to discuss the concept of organisational culture as it provides an interesting
prism of how location affects projects. As mentioned, depending on location a project may be
tackled in different ways. However, it is not uncommon for some organisations to maintain a
relative harmony in the way their projects are managed, in an attempt to phase out the
effects of location. This is possible when a strong organisational culture exists that may
override other cultural effects. Such an organisational culture is evident when employees and
managers provide statements such as "this is the way things are done in this company" and
"all employees of this organisation are able to". This means that the organisation has
become the predominant source of behavioural etiquette and all its members are expected to
operate under certain patterns. A simple example could be the way deadlines are viewed by
the employees in comparison to the population of the country. It is quite interesting to
research what different cultures perceive of a deadline stating that "the report must be ready
first thing in the morning". For some first thing might be 9 a.m. while others may take this as
an acceptable window of three hours leading to lunch time. There will also be those who will
make sure everything is ready before even the working day begins (say between 6 a.m. and
8 a.m.). Therefore the notion of time could be one example of how location may affect project
management. We will discuss such examples further.
In their book Project Management, Gray and Larson (2003) identified ten characteristics that
can be used to describe the concept of organisational culture. These are:
 Member identity – this describes how members of an organisation may seek their
identity in their specific role, their job or as an integral part of a wider entity that is the
organisation.
 Team emphasis – this shows how strong a team spirit culture is within the
organisation or whether members show a high degree of individualism.
 Management focus – this refers to the organisation's awareness of how management
practices may be affecting the well-being and the role of the organisation's employees.
 Unit integration – this dimension identifies the extent of integration of the different
organisational units as opposed to those working in isolation.
 Control – this is a measurement of how strong policies, procedures and practices are
in dictating how operations take place.
 Risk tolerance – this shows whether the organisation is prepared to deal with risks
associated with certain decisions and operations.
 Reward criteria – this classifies organisations according to the reward mechanisms
used to increase employee motivation and reward the achievement of targets.
 Conflict tolerance – this distinguishes organisations according to their tolerance to
conflicts being openly discussed and resolved against to those that prefer complete
avoidance of conflicts.
 Means versus end orientation – this dictates where the focus of management is on
achieving its aims rather than the processes followed.
© ABE
Project Analysis 53
 Open systems focus – this explains how organisations choose to interact with their
environment.
Managing Differences
Different organisations depend on different structures and their unique characteristics usually
affect the way their projects are managed. One of the main aspects of project management
affected by such organisational differences is the way work is structured. As mentioned in
earlier sections of this chapter, a hierarchical approach in work structures facilitates the
management of projects. The three approaches to WBS are identified as:
 noun type approach
 verb type approach
 organisational approach.
A noun type approach is recommended by the Project Management Institute (PMI) and is
based on the various deliverables of the project. The approach defines deliverables in terms
of either the physical or functional components that are created during the project's
operations.
A verb type approach was recommended by the PMI before the introduction of the Project
Management Body of Knowledge (PMBOK), and is based on the design-build-test-implement
series of actions that are required for the creation of a deliverable. This approach is focused
on specific actions and the way these are related.
Finally an organisational approach defines deliverables in terms of organisational units that
are involved in the process. In this approach we must consider each deliverable in terms of
the business processes as well as any departmental units involved. An important aspect is
also the geographic location of an organisation's resources.
Geographical Issues
Quite a few organisations are based on complex structures, with their units of operation or
the resources they require geographically dispersed. As we have mentioned, the
organisational approach provides a number of different views of how projects may be
structured. The main drawback with these approaches is that they are based on the
organisation's structures rather than on project management disciplines. The obvious
problem with such an approach is that it becomes difficult to apply to projects outside the
organisation. Furthermore, as the approach is strongly affected by the way the organisation
units are integrated, it also depends on how efficient these units are. Therefore a project may
be managed according to a geographically oriented, departmental or business process
oriented perspective.
By breaking down business processes the organisation is able to provide a series of steps
that can be used in a variety of projects, allowing the achievement of aims and the production
of deliverables.
A project may be structured according to the departmental units involved. This approach
allows a more straightforward allocation of resources as the different deliverables are the
responsibility of well-defined departments. However, any inherent problems that may exist in
various departments may become a continuous source of concern for the project tasks
assigned to the specific unit.
Issues relating to geographic dispersion may be classified in a range of factors that may
affect the outcome of a project as well as its smooth operation. Geographic issues could
include the following:
 Political – where the stability of a nation is indirectly affecting the way projects perform.
Organisations may choose to avoid uncertainty and avoid specific territories where
corruption and lack of integrity may cause delays or additional costs.
© ABE
54 Project Analysis
 Legal – the laws of each country must be respected, meaning that certain functions or
actions may be constrained in some locations.
 Government – the government influence in the way private organisations perform their
operations in a country may be a factor affecting which projects may go ahead and
which may not.
 Security – establishing a secure environment for the project is critical and it depends
on how secure is the environment offered in each country and region.
 Social – the social norms of what is acceptable and what not is also a factor affecting
the suitability of a social environment for an organisation that operates within certain
industries.
 Location – the location itself may offer opportunities and threats for a project, including
mobility issues, experience in the sector, special skills and prior knowledge.
 Economic – the local economy may affect the range of operations that are performed
in each country and the extent a project is dependent on local resources.
 Infrastructure – the technology that is required for a project as well as the
infrastructure available in each location must be aligned to ensure that the project's
operations are not affected by inadequate technological infrastructure.
It is evident that a major impact of geographic dispersion is the way resources are allocated.
Some projects are dispersed in such a way that physical coexistence of resources is
impossible. This means that face-to-face communication is not feasible and on some
occasions even synchronous, technology-enabled discussions cannot take place. As a
matter of fact the number of projects that include teams residing in different countries with
different time zones is quite significant.
There is also the need to understand that geography plays a role even in smaller scale
projects. Typically, moving people from the same office to different floors or buildings could
provide a dramatic decrease in their efficiency and add unexpected overheads in their
communication. The time it takes to coordinate project offices and establish communication
between collaborating units is increased dramatically.
Cultural Issues
The concept of cultural differences in a project can be a complicated one to explain. The
notion of culture can be described differently, depending on the perception the project team
has of the way a project is affected by such differences.
Typically by culture we mean the national culture. This is portrayed in an individual's
conduct as a set of norms, values and behaviour patterns that have been formed through
experiences in the immediate environment such as family, school and local society.
In several countries a stronger regional culture has developed as a result of past population
movements. Such regional cultures may demonstrate differences in language, religion and
habits.
As mentioned earlier in the chapter, a corporate culture develops in (often multinational)
organisations that are established well enough to introduce their own norms, acceptable
behaviour and principles for their employees. It is perceived that corporate culture is
sometimes so strong that, when at work, employees tend to suppress any characteristics that
reflect their national or regional culture.
A professional culture has been observed in certain professions that require integrity, ethics
and a strong view on how discipline is applied through the profession. Professional culture
can be so strong that it offers a communication medium for those who share it. Professional
culture is expressed in terms of certain expectations and assumptions for professional
behaviour.
© ABE
Project Analysis 55
Individuals who share the same roles in different organisations may belong to the same
functional culture that is associated with the role responsibilities and duties. A functional
culture is what separates staff members and may be the reason why they have different
views on the organisation's operations and decisions.
Finally a team culture is quite often present in teams with members who are strongly
related, experienced in working together, share same goals and have a common ethos. The
team culture is so strong that may cause difficulties to new members who wish to join an
existing team.
Review Questions 5
(a) Name the ten main characteristics identified by Gray and Larson that can be used to
describe organisational culture.
(b) Identify the eight main geographic issues affecting a project's performance.
SUMMARY
This chapter introduced the hierarchical division of work and work breakdown structures. The
chapter also discussed in detail risk management and assessment as well as the processes
of cost planning and estimation. The later parts of the chapter emphasised the importance of
dealing with bids, tenders and contracts. The effects of location and culture in project
management concluded this chapter.
© ABE
56 Project Analysis

Review Questions 1
(a) The five usual sources are staff, competitors, customers, suppliers and R & D.
(b) The six main elements included in a project scope checklist are objectives,
deliverables, milestones, technical requirements, limitations and exclusions and
reviews.
(c) The six key concepts or steps involved in the creation of a work breakdown structure
involve project, deliverable, sub-deliverable, lowest sub-deliverable, cost account, work
package.
Review Questions 2
(a) The four main project risk management steps are risk identification, risk assessment,
risk response development and risk response control.
(b) The four main quantitative risk analysis methods are expected value, sensitivity
analysis, Monte Carlo simulation and the programme evaluation and review technique
(PERT).
(c) The seven most common monitoring and control tools that can be used in risk
assessment are work breakdown structures, estimated and actual project budgets,
project schedules, earned value of project activities, project resource list, project plan
and change control log.
Review Questions 3
(a) The nine project management knowledge areas described in PMBOK are project
integration management, project scope management, project time management,
project cost management, project quality management, project human resource
management, project communications management, project risk management and
project procurement management.
(b) The two contract types which can be used for plan purchases and acquisitions are
fixed price contracts and cost reimbursable contracts.
Review Question 4
The eight main steps involved with the purchasing process in a project are approving
purchasing stakeholders, requesting goods and services, assessing purchasing orders,
searching for suppliers, placing orders, receiving goods, assessing purchased goods and
services, and paying for the goods
Review Questions 5
(a) The ten main characteristics identified by Gray and Larson are team emphasis,
management focus, unit integration, control, risk tolerance, reward criteria, conflict
tolerance, means versus end orientation and open systems focus.
(b) The eight main geographic issues affecting a project's performance are political, legal,
government, security, social, location, economic and infrastructure.
© ABE
57
Chapter 3
The Project Plan
Contents Page
Introduction 58
A. Project Overview 58
B. Project Management Structures 60

Justifying the Need for Formal Project Management Structures 60
Assigning Responsibility to Personnel 66
C. Project Activities and Schedules 69

Identifying Project Activities and Dependencies 69
Devising Project Schedules 70
Using Scheduling Tools 73
D. Dealing with Change in Project Schedules 74

Adjusting Project Schedules according to Constraints 74
Reorganising Project Schedules to fit available Resources 76
E. Project Communications 78
Communicating Project Details to Stakeholders 78
Describing Project Plans 80
Summary 81
© ABE
58 The Project Plan
INTRODUCTION
Following on from the discussion of project initiation in Chapter 2 we will now look at how
project planning works. The project planning process involves a number of steps, and these
are needed in order to provide a project overview that can be followed and used as a
reference point for the duration of the project. The underlying intention is that following these
steps will result in a comprehensive plan which will enable the project to be described in the
necessary detail.
Objectives
 justify the need for a formal project management structure.
 propose an appropriate structure for the control and administration of a project and
indicate the responsibilities of key personnel
 identify the activities in a project and establish their dependencies
 employ recognised techniques, such as the Gantt chart and network analysis, in order
to devise a project schedule
 outline the typical functions of project management software packages which can
assist the scheduling task
 explain the need to adjust project schedules when the available resources are subject
to constraints
 reorganise a project schedule in order to smooth resource requirements
 recognise the need to communicate the project plan to various interested parties
 describe the contents of a detailed project plan.
A. PROJECT OVERVIEW
An important element of the project plan is to clearly define the scope of the project. After all,
the plan should be based on a good understanding of what the project requires. Initially we
need a project overview statement (POS) that provides sufficient detail for five
components:
 problem/opportunity
 project goal
 project objectives
 success criteria
 assumptions, risks and obstacles.
Identifying a problem in need of a solution or an opportunity for a new product or service is
quite often the beginning for a project. The identification of such problems or opportunities is
important as it sets the scene for the project requirements. A project may also be triggered by
specific customer requests or requirements from stakeholders. It could also be the case that
the organisation is introducing an initiative, entering a new market or taking further actions
that make the project a necessity. The influences behind a project may depend on external
factors, such as changes in the local market, dated technology, obsolete products, etc.
The project goal can usually be defined in a single statement that outlines the project scope,
and it can be quite descriptive. The project goal can be defined clearly by making sure a
© ABE
The Project Plan 59
number of characteristics are present when describing its primary aim. These features can
easily be remembered by using the SMART acronym:
 Specific – the goal statement must aim for specific targets
 Measurable – the project progress can be measured against certain criteria
 Assignable – there is a clear responsibility assigned to the role of those undertaking
specific parts of the project
 Realistic – the project deliverables are feasible with the available project resources
 Timely – there is a reasonable time frame identified for the completion of the project
and its deliverables.
The project objectives should follow the SMART characteristics and offer a detailed view of
how the project deliverables should meet the identified requirements. A statement that
describes a project objective in sufficient detail should include information about:
 the outcome of this objective in terms of whether it is a specific deliverable or another
form of accomplishment
 the duration of the tasks associated with this objective
 a way to measure the performance of the project towards this objective
 a series of actions required for this objective to be achieved.
The success criteria that can be used to assess a project will vary, depending on the type of
project considered, the organisation, the industry sector and various other factors. A typical
criterion is whether the project improves the revenue stream for the organisation. A project
may increase profits or reduce costs, offering value for the organisation. A project is likely to
produce additional goods and services in line with the existing provision of the organisation.
Several other concerns may affect the project overview and these may include certain
assumptions made, identified risks and even obstacles that may cause the project to
deviate from its original plan. Typically the immediate project environment and the setting for
its activities are causes for concern, especially when these are volatile and subjected to
numerous external pressures. The technology used and any infrastructure constraints may
also be reasons why a project statement may not be implemented precisely. Further
concerns may relate to resources, staffing issues, conflicts, personal relationships, etc.
Review Question 1
What do we mean when we require a project manager to set SMART objectives for a
project?
© ABE
60 The Project Plan
B. PROJECT MANAGEMENT STRUCTURES

Each project has a unique set of activities associated with its aims and (identified)
deliverables. The project scope can be defined in such a way that a specific project planning
process can be followed. Such a process can be identified in terms of the following four
steps:
 identifying the essential activities required for achieving the project's aims and
objectives
 determining how these activities are linked and whether they can be organised in a
sequence
 specifying the requirements of each activity in terms of costs, resources and time
needed
 mapping the activities and resources in such a way that a project schedule can be
created and shared between project stakeholders.
Harvey Maylor (Project Planning, fourth edition) has suggested the acronym ICOM – for the
project inputs, controls, outputs and mechanisms – for describing the project planning
process.
Typical inputs for a project take the form of project descriptions, specifications and any other
form of requirements. The project is controlled mainly through a set of standards that must be
adhered to and procedures that are followed by an organisation. The project controls may
include external factors for the project – various aspects of the macro-environment for the
project that may include political, social and cultural constraints. The planning process main
output takes the form of a project plan that may be used as a proposal for a bidding process.
The mechanisms employed in a project can be classified either as the human resources
(including the workforce involved along with the project manager and any external
stakeholders), or a set of tools and techniques that may be used to coordinate the project
activities.
Think Point
Provide an example of a project plan based on the ICOM (inputs, controls, outputs and
mechanisms) technique.
Justifying the Need for Formal Project Management Structures

Project management structures are required for both small and large projects. The need for
such structures is imperative: they help us to remain aware of the project scope and define it
in a clear way, deal with various project work activities and assign roles to members of the
workforce allocated to the project. For every project there are three main roles:
 project manager
 project team
 project champion.
As mentioned earlier the role of the project manager is to coordinate the entire project and
steer the project team in such a way that it works successfully towards the completion of the
project deliverables. The project champion role is usually introduced in larger projects. It is
the project champion's role to advocate the importance of the project and increase interest
and support both within the organisation and also externally. Sometimes this role may be part
© ABE
The Project Plan 61
of the project manager's responsibility and a member of the project team could be assigned
as the champion, or the task could be undertaken by another stakeholder.
The initial stage in producing a project management structure is to clearly assign roles and
establish the human resource structure. We could identify a number of steps for setting up
the structure of the project management human resources as follows:
 choose a project manager – this is the individual who will be in charge of the entire
project
 select project team members – these are the staff or even external contractors who
possess the required skills and who will undertake the project activities
 assemble a project steering group – this is the team of individuals who will be involved
in the decision-making and problem-solving tasks throughout the project
 identify a project champion – this is the individual who is likely to chair the steering
group and who will be able to provide an accurate description of the project's status
 prepare a project management plan – this is based on a flow of specific processes and
a set of well-defined activities.
We mentioned in Chapter 2 that an important aspect of project management is the
preparation of a work breakdown structure (WBS) that will allow us to monitor the project
during each of its phases. We must consider that the project plan should take into
consideration two important areas of concern, namely processes and products. The aim
should be to identify and map those processes required for the production of the project
products. The main structures associated with these two processes are:
 work breakdown structure – this is an analytical view of the work activities associated
with the project processes
 functional breakdown structure – this is an outline of the functions that are
supported or provided by the project deliverables
 physical breakdown structure – this is a representation of the physical representation
of the project objectives
 product breakdown structure – this provides the structure of the products associated
with the project deliverables.
These structures lead into the creation of the project deliverables in the form of specific work
packages that are defined in detail. Each work package is specified in terms of the duration it
requires for its completion as well as the sequence followed for its production. The sequence
is necessary, as some work packages may be dependent on others.
Think Point
With the aid of an example, distinguish between any two of the following types of breakdown
structure: work (activities), functional (functionality supported) or product (project outputs).
Creating a WBS
The work breakdown structure concept has been discussed at several points so far, and is
illustrated in Figure 3.1. The aim is to provide a graphical representation of a series of
activities and emphasise how these activities are related. The activities belong to the project
and form a list of requirements and responsibilities that must be fulfilled. The structure allows
us to view the activities in different levels (as some of them belong to the same complexity
level), before they are broken down to more refined tasks.
© ABE
62 The Project Plan
Figure 3.1: Work breakdown structure
1
Activity Name
1.1 1.2 1.3

Activity Name Activity Name Activity Name
1.2.1 1.2.2
Activity Name Activity Name
The numbering of the activities allows the project manager to group activities that belong to
the same role or to identify which sub-activities are at the same level. The same diagram can
be used to demonstrate the different types of breakdown structure discussed before. Figure
3.1 could therefore include the following activities, according to what type of breakdown
structure it demonstrates:
 work breakdown structure:
1 – develop a new website
1.1 – identify the user requirements
1.2 – design the web pages:
1.2.1 – design the interface of each page
1.2.2 – design the back-end and databases
1.3 – test the page with users
 functional breakdown structure:
1.1 – deal with implementation issues and skills required
1.2 – assess the website success criteria:
1.2.1 – conduct surveys with users/customers
1.2.2 – monitor competition and evaluate other similar sites
1.3 – acquire the technology required for the site interface
 physical breakdown structure:
1.1 – organise the user interface team
1.2 – organise the web development team:
1.2.1 – initiate the database design team tasks
1.2.2 – initiate the server design team tasks
1.3 – organise the testing team.
© ABE
The Project Plan 63
Think Point
Provide an example of a work breakdown structure for a project of your choice.
A number of approaches could be followed when putting together a WBS. Typically project
teams often choose a top-down approach, identifying the main project tasks and then
attempting to break them down into to simpler activities until very simple tasks are identified.
A bottom-up approach on the other hand would involve starting with the identification of
simple tasks that must be performed. Either way, it is necessary for all possible tasks to be
identified. Once this step is complete the team must group together these tasks in a
meaningful way, creating a level of more complex activities. This process is iterative, and
continues until the entire project can be viewed as a tree structure that starts from its most
analysed branches and finishes with its root.
The creation of a WBS following the top-down approach may have a number of variations.
For example, a team approach means that the entire project team is involved in the
breakdown of each task till the WBS is completed. Each time a new task must be analysed
further, the team is led by a member who is more experienced and knowledgeable of the
particular area. On the other hand a sub-team approach means that after the first level of
tasks has been created, the team is split according to the number of tasks identified at that
level. Each sub-team is then responsible for completing a specific portion of the WBS.
The WBS creation process is based on a number of inputs, including:
 any organisational process assets
 a project scope statement
 a project scope management plan
 any approved change requests.
The WBS creation process can be based on templates, and although templates cannot be
generic enough to cover all possible projects they can offer a useful set of guidelines. One
such is the Project Management Institute Practice Standard for WBS, which helps with the
creation, generation, development and application of WBS: the output takes the form of the
WBS itself. However there are other breakdown structures that may prove useful for project
managers, although it should be noted that such structures are not produced during the WBS
creation process. Such structures include organisation breakdown structure, risk
breakdown structure and resource breakdown structure.
It is important to understand that the WBS creation is based on the breakdown of activities
that define the project. The project breakdown is based on specific guidelines for the entire
process and involves:
 identifying the project deliverables and any work associated with each deliverable
 structuring the WBS
 breaking down each WBS level to a more analytical lower level
 assigning a code to each detailed component of the WBS
 verifying that no further breakdown is necessary.
Scope Verification
As mentioned before, an important part of the project planning process is the definition of the
project's scope, usually in the form of a clear scope statement. The input for the scope
definition process can be identified as:
© ABE
64 The Project Plan
 organisational process assets in the form of plans, policies and procedures influencing
the project success
 a project charter offering a term of reference for the project
 a preliminary project scope statement
 the project scope management plan
 any approved change request.
This input is quite similar to the input for the WBS. The scope definition may be terminated by
employing several techniques including product analysis, identification of alternatives, expert
judgment and stakeholder analysis. The scope definition output may include:
 project objectives
 scope description
 project requirements
 project boundaries
 project deliverables
 project acceptance criteria
 project constraints
 project assumptions
 initial project organisation
 initial defined risks
 schedule milestones
 fund limitation
 cost estimate
 project configuration management requirements
 project specifications
 approval requirements.
Based on the scope definition described before, the process of scope verification follows. It
can be defined as the process involving the acceptance of the project deliverables by the
project stakeholders. At this stage we must distinguish between the project verification and
the quality control process. The former is based on the acceptance of the deliverables while
the later focuses on whether the deliverables meet certain standards.
The project verification input includes the:
 project scope statement
 WBS dictionary
 project scope management plan
 deliverables.
Following the inspection of the project deliverables the outputs are:
 accepted deliverables
 requested changes
 recommended corrective actions.
Scope Control
© ABE
The Project Plan 65
Scope control is a process that is strongly associated with scope verification since it focuses
on ensuring that changes in the control process are invoked in order for recommended
changes and corrective actions to take place when required. The inputs of the scope control
process include:
 the project scope statement
 the work breakdown structure
 the WBS dictionary
 the project scope management plan
 any performance reports
 approved change requests
 work performance information.
It is obvious that the scope control process is primarily concerned with the way changes take
place and how they are approved as well as the effects of the requested changes on the
project's performance.
The scope control process is based on a number of techniques, including:
 Change control system – focusing on how the project's scope may change to
accommodate any change requests
 Variance analysis – focusing on analysing the magnitude of requested changes and
the effects on the project's scope
 Replanning – focusing on the changes required on the WBS following the requested
changes
 Configuration management system – focusing on the project deliverables and their
progress as well as the documentation of the changes in the WBS following the
requested changes.
Think Point
Focusing on how the WBS is adjusted following requested changes, explain the role of
replanning in the scope control process.
The scope control outputs include the following:

 updated project scope statement
 updated WBS
 updated WBS dictionary
 updated scope baseline
 requested changes
 recommended corrective action
 updated organisational process assets
 updated project management plan.
© ABE
66 The Project Plan
Assigning Responsibility to Personnel

So far we have discussed the way a project deals with change requests. It is necessary to
understand that the initial WBS may be affected by the introduced changes. We now need to
understand how the project schedule is created and more specifically to become aware of
how the project activities are taken into consideration when planning the schedule.
There are four key steps during the planning stages of the project. These steps can be
identified as:
 activity definition
 activity sequencing
 duration estimation
 schedule development.
There is also another step that is performed throughout the project and it is discussed later:
 schedule control.
Activity Definition
The activity definition process identifies all the activities required for the project deliverables
to be produced. Certain inputs are required for the activity definition process including:
 WBS
 project scope statement
 historical information
 constraints and assumptions.
The historical data is information that may be useful in providing an awareness of how similar
projects performed in the past. The constraints are the limitations of the choices available to
the project team, while assumptions allow the project team to take for granted that certain
factors are real.
The techniques and tools that are used in activity definition are breakdown and the use of
templates. As mentioned in our discussion of the WBS, the breaking down of activities is
necessary to define each activity and associated sub-activities. Any activities that have been
performed in previous projects may be used as templates for the activities of subsequent
projects.
The outputs of the activity definition process include:
 activity list
 supporting details
 WBS updates.
The list of all identified activities can be used as additional information to what is included in
the WBS, to ensure that all tasks involved in the project have been identified. The supporting
detail for each activity may include known constraints or any assumptions that can be made.
Obviously any changes to the initial WBS must be documented as they are necessary for the
definition of the project's activities.
Activity Sequencing
The activity sequencing process indicates how project activities are related. The aim is to
show that certain activities are dependent and that the project performance is affected by
these dependencies.
© ABE
The Project Plan 67
Inputs to the activity sequencing include:

 Activity list – The activity list is important as it identifies all the activities that must be
ordered in a sequence.
 Product description – The product description is likely to affect not only the activities
involved but also certain ways that the activity sequence can be formulated.
 Dependencies – There are several kinds of dependencies, including mandatory,
discretionary and external.
Mandatory dependencies are the ones that cannot be negotiated and are dependent
on the way the project deliverables must be prepared. Indeed sometimes it is
impossible to move to a particular step of the process unless another one is complete.
Discretionary dependencies can be decided by the project team and sometimes they
are preferred although there may exist another possible sequence of activities. These
might cause some conflicts if not properly documented as they are supposed to follow
good practice or even deal with unusual events. The external dependencies
demonstrate how activities that do not belong to the project may affect project
activities.
 Milestones – These are important events that, once reached, allow certain activities to
commence.
 Constraints – which have been discussed earlier in this chapter.
 Assumptions – which have also been discussed earlier in this chapter.
There are several sequencing methods that are used to provide an accurate representation
of any activity dependencies and how the sequence of activities leads to the end of the
project. Some of these methods and techniques are:
 Precedence Diagramming Method (PDM)
There are four types of precedence relationships in Figures 3.2 and 3.3, namely: (i)
finish-to-start, meaning that the successor activity cannot start till the predecessor
activity finishes; (ii) finish-to-finish, meaning that the successor activity cannot finish
before the predecessor activity finishes; (iii) start-to-finish, meaning the successor
activity cannot finish unless the predecessor activity has started; and (iv) start-to-start,
meaning that the successor activity cannot start until the predecessor activity has
started. The precedence diagramming method, also called the activity on node (AON)
method, is illustrated in Figure 3.2.
Figure 3.2: Activity Network Diagram (Precedence Diagramming Method)
A C D
Start
E
I End
B G
 Arrow Diagramming Method (ADM)
© ABE
68 The Project Plan
This method shows activities as arrows that are connected in nodes representing
dependencies. This is known as the activity on arrow (AOA) technique and is based on
finish-to-start dependencies only with an addition of dummy activities to allow a full
logical representation of the activity sequence. Figure 3.3 illustrates this technique.
Figure 3.3: Activity Network Diagram (Arrow Diagramming Method)
C G
2 5 8
A J
D H K L
1 3 6 9 10 End
B E I
4 7
F
 Conditional Diagramming Methods

The PDM and ADM techniques do not offer if-then-else branches. Such conditional
branching can be supported in conditional diagramming methods including the
graphical evaluation and review technique (GERT) and system dynamics models.
Activity sequencing has two main outputs, namely network diagrams and the activity list. The
former type of output is in the form of diagrams like the ones illustrated in Figures 3.2 and
3.3. The latter is in the form of an updated WBS which includes the revised list of activities.
Think Point
Draw an activity network diagram for a project example of your choice. Either PDM or ADM
diagram types can be used and the example should include no more than 10–12 activities.
Review Questions 2
(a) Identify the five main steps involved in structuring project management human
resources.
(b) Identify the five main stages involved in project breakdown.
(c) Identify 14 of the 16 main outputs from the scope definition process.
(d) List the six main inputs for the activity sequencing process.
(e) What are the two types of activity network diagrams and how do they differ?
© ABE
The Project Plan 69
C. PROJECT ACTIVITIES AND SCHEDULES

In order to understand the activities associated with a project and the way these take place in
its various phases we must be able to define the project goals. The project activities are
important for a number of people. First are the project sponsors, those stakeholders who
have a real interest in the project and have invested in its success. The second group of
people who are dependent on the project are the customers who will reap the benefits of the
project deliverables. Similarly, the end-users who will be using the project outputs also have
a strong interest in the project. Finally there are those involved with the project activities and
schedules, the project manager and team.
Identifying Project Activities and Dependencies

So far we have discussed a number of methods that can be used to identify those activities
necessary for the success of a project. It is essential to understand that the identification of
these activities alone is not sufficient. At this stage, the most important role of project
management is to be in control of how these activities are dependent on each other and also
ensure that such dependencies can be monitored and adjusted throughout the project's life
cycle.
Activity Resource Estimating
The scheduling responsibilities of the project manager and the team will deal with a number
of estimations for the project activities. The activity resource estimating process is concerned
with the identification of any resources required by each activity. The project activities are
defined in terms of the tasks that must be performed as well as a list of resources that must
be available to ensure their successful completion. The resources can be classified
according to their nature. For example, it could be funds or allowances, or perhaps specific
equipment or even software that may be required. A major part of the resource plan deals
with the human resource requirements, since each activity must be undertaken by individuals
who possess suitable skills, knowledge and experience.
Activity Duration Estimating
Once we have established what resources are needed for an activity we should attempt to
estimate how long the activity will last. Since, by providing the necessary resources we can
now guarantee that the activity will be completed within the required quality standards, the
next step is to assess its duration in a process called activity duration estimating.
The inputs to this process include:
 an activity list with all activities to be assessed
 any constraints that may affect the progress of each activity at a later stage
 any assumptions made in terms of the activity environment and the way that each
activity will be carried out
 any resource requirements (it should be noted that estimation of resources is
sometimes integrated with the activity duration estimation as the provision of resources
and any supplies may affect the progress of an activity and introduce delays)
 resource capabilities mapping out the range of support offered from the resources and
a realistic report on what can feasibly be achieved with the acquired resources
 any historical data that may allow a better understanding of each activity time frame.
The historical information can be based on prior knowledge of the team members from
similar projects. However a more formalised method would be based on the organisation's
record keeping of previous project management endeavours and sometimes on commercial
© ABE
70 The Project Plan
services offered by specialised firms in the field of estimating the duration of specific, well-
defined activities.
The activity duration estimation can be primarily based on the following tools:
 Expert judgment – This is a technique based on the views of experts in such cases
where the estimation of the activity duration is difficult to achieve. These judgments are
obviously based on years of experience and historical information.
 Analogous estimating – This is a technique which uses a top-down approach of
analysing prior activities of similar nature in an attempt to forecast their duration.
 Simulation – This is a method based on several techniques, an example of which
(Monte Carlo) was mentioned in Chapter 2. The objective is to attempt estimating the
duration of each activity based on a number of scenarios, and then measure the
duration based on different assumptions each time.
The process outputs of activity duration estimating include:
 activity duration estimates
 basis of estimates
 activity list updates.
The main output of the process is the provision of estimates in the form of an activity list and
the associated duration for each activity in preset units. These units could be days, weeks or
even hours, depending on the nature of the project. The duration estimate should include
some form of allowable range in case the project teams manage to complete them before the
expected deadline or certain constraints force the activity to overrun. The assumptions made
in order to reach the duration estimate should be reported as they provide the justification
supporting the estimation. Finally, the project WBS may be revised and a list of revised,
updated activities should be produced.
Devising Project Schedules

Once each activity is defined in detail, it is time to establish a detailed schedule. The project
schedule is yet another process available for project managers to control the way a project
progresses and monitor how the activities are performed according to plan. The main
concern at this point is not just to develop the project schedule, but also control it throughout
the project. Project managers are expected to intervene when a project schedule is difficult to
follow, making any necessary adjustments so the project activities can be achieved within the
time frame and the resources allowed.
Schedule Development
Developing the project schedule is an iterative process, and offers project managers the
chance to refine estimations for the duration, cost and resources needed for each activity.
The number of iterations required prior to the development of the final project schedule
depends on the project nature and involved activities.
The inputs for the schedule development process include the following:
 Activity duration estimates – these are provided for each activity (as discussed
previously) and are combined to estimate the duration of the entire project
 Project network diagrams – the methods described previously are used to offer an
illustrative view of the activity duration and dependencies
 Resource requirements – the summary of the resources needed for each activity
should be provided
© ABE
The Project Plan 71
 Resource availability – each resource item should have its availability monitored to
ensure that there are no delays to specific activities and to ensure the project overall
does not reach a deadlock
 Calendars – these offer a useful way to visualise work shifts and disseminate
information as to when work and idle periods are expected; calendars are also used for
resource availability
 Constraints – the list of all constraints and limitations to the project with a reference to
possible impacts on duration
 Assumptions – the list of all assumptions indicating which are expected for the project
schedule to be met, as well as any possible deviations that may be caused if the
assumptions are false
 Lead and lag times – these times help to fully understand the time frame for activities
and resource requests (an example would be the time it takes for suppliers to provide
the necessary resources after the order is made)
 Risk management plan – the identified risks should be taken into account, since the
duration of certain activities is most likely to be affected once the risks are realised
 Activity attributes – the special characteristics of each activity, as well as any factors
that may affect the way it is carried out, are needed to estimate whether the activity is
likely to meet the original estimation.
The main tools used for schedule development are:
 Project Management Software
Software applications are used to provide a semi-automated way of setting project time
frames and make necessary adjustments to schedules.
 Mathematical Analysis
The use of mathematical analysis allows the calculation of start and end times for each
activity. Examples of mathematical analysis techniques used are critical path method
(CPM) to identify the least flexible activities, graphical evaluation and review technique
(GERT) dealing with the logic behind activity dependencies and duration, and program
evaluation and review technique (PERT) that can calculate the project duration based
on weighted average duration estimate.
 Simulation
The use of simulations is based on various scenarios that use different estimates to
assess possible options for the final schedule.
 Resource Levelling
The resource levelling technique is based on the use of heuristics to create a schedule
that views resource allocation and other similar issues more realistically. Therefore the
schedule is based on allowing time for critical and more time demanding and less
flexible tasks to be achieved in time.
 Coding Structure
Coding structure is used to label activities in such a way that their attributes may be
used to logically group them together.
 Duration Compressions
The duration compression approach is based on a special form of mathematical
analysis that aims at reducing the project duration. Compression techniques include:
– crashing, which is based on reducing activity duration as much as possible
© ABE
72 The Project Plan
– fast tracking, allowing for activities to take place simultaneously.

Typical outputs for the schedule development process include:
 Project Schedule
This is a planned chart which includes all activities organised according to important
milestones. The schedule may be in the form of bar charts (known as Gantt charts),
network diagrams and many others.
 Supporting Details
Supporting details include all information required for the justification of the plan,
including assumptions and constraints.
 Schedule Management Plan
This plan dictates the project management style followed and the means that will be
employed to ensure the project schedule will be followed.
 Resource Requirements Updates
Since the schedule may end up including additional resource requests, any updates
must be recorded.
Schedule Control
Once a schedule is in place, it is quite likely for the project to commence based on the kick-
starting activities identified. Once the project is initiated, then the project manager needs to
control the schedule by ensuring that the project activities take place when they are
supposed to and last as long as the plan indicates.
The main purpose of the schedule control process is to deal with any changes that may be
imposed for various reasons. The project manager must ensure that prior to an activity a
certain set of pre-conditions must be met. These include the acquisition of resources, the
availability of human resources, ensuring the environment is set up and ensuring that all
permissions are granted. The project manager must also ensure that the progress of each
activity is in line with the original estimations. Further concerns should include resource
availability, any milestones, conflicting activities and possible antagonistic actions towards
the project resources from other projects.
The schedule control process requires a number of inputs including:
 project schedule
 schedule management plan
 performance reports
 change requests.
The schedule management plan is based on the initial planning offering the project baseline
and is used to establish whether the project progresses well. The performance reports
provide a detailed analysis of the schedule performance indicators. Any change requests that
are made formally or informally (and in a variety of forms) are likely to be dealt with during
the activity life cycle and a schedule management plan should indicate how the manager is
dealing with changes.
Some of the tools at the project manager's disposal for controlling the project include:
 Schedule Change Control System
These are the procedures that are followed when dealing with schedule changes.
© ABE
The Project Plan 73
 Performance Measurement
Performance measurement means the criteria used and factors taken under
consideration when the project performance is measured.
 Project Management Software
The software applications used to help with project management responsibilities.
 Variance Analysis
These are factors affecting the project schedule and the impact of these factors.
Identifying project variances from the original plan is important to ensure that all
activities are following a realistic plan.
 Planning
The planning process used as an iterative procedure, taking into consideration how
activities are grouped together and how they are logically grouped.
The schedule control process produces:
 Schedule Updates
The schedule updates deal with any modifications to the initial schedule. The main
concern is not only to identify the updates needed but also how these may relate to
further changes in other aspects of the project that are not directly identifiable.
 Corrective Actions
Corrective actions include all steps that must be followed in order to ensure that the
updated schedule is feasible and will not jeopardise the chances for successful
completion of the project.
 Lessons Learned
A detailed documentation of the lessons learned during different stages of the project is
important. These could include the reasons for updates, the changes made and the
justification behind them.
Using Scheduling Tools

Scheduling tools form a category of project management software that aims to facilitate the
project manager's control processes. Software applications can be used for resource
allocation, communication, collaboration tasks, etc. Scheduling tools help in those cases
where a project's schedule is so complicated that it is almost impossible to control its
schedule by following manual processes.
Semi-automation of scheduling tools allows us to visualise and group together events that
affect activities and also illustrate the impact of these events in terms of the project schedule
and activity duration. The analysis of the activity dependencies is produced in a way that may
allow the assessment of whether the current dependencies are logical. Reminders and
scheduled tasks could help to allocate resources, deploy certain resources and teams,
attend to critical events and deal with problematic activities. Scheduling tools help to provide
estimates, identify recurring events and various patterns as well as dealing with uncertainty.
Scheduling tools are also very helpful in providing task lists for members of the project team,
activity lists grouped according to importance or deadlines and a number of filters to sort out
project tasks and responsibilities. The duration overview for the project activities and a more
detailed analysis of task time frames are also provided. These tools can help project
managers to adopt a proactive stance by offering advance warnings in terms of workloads,
lagging tasks, etc. Retrospectively, scheduling tools can be used as a useful guide based on
historical data of similar projects, tasks from previous phases, patterns of work for individuals
© ABE
74 The Project Plan
and teams. They can also serve as a reporting mechanism which allows the project manager
to optimise the use of the available resources and maximise the project performance.
Making Better Use of Microsoft Project
There are several commercial applications that can be used as scheduling tools, and these
days basic scheduling tools are even provided with many email applications. One widely
available project management software tool is Microsoft Project, which is suitable for
everyday projects with a rather limited number of activities as well as more demanding
projects based on more complex structures. Microsoft Project was originally developed to
help with the management of projects running within Microsoft applications. Its main
characteristic is the development of a Gantt chart for the main project activities. Some quite
interesting features include progress tracking, resource assignment, managing budgets, etc.
Review Questions 3
(a) Name the six main tools used for schedule development.
(b) Identify the five main tools used in the schedule control of a project.
Now check your answers with that given at the end of the chapter.
D. DEALING WITH CHANGE IN PROJECT SCHEDULES

A major factor for successful projects is their adaptability to ever changing requirements,
external factors, environmental influences and schedule estimates. It is necessary for project
managers to allow sufficient margins in their planning to accommodate the need for change.
Furthermore it is necessary for contingency plans to be in place so any changes will have
only moderate effects on the project's progress.
Adjusting Project Schedules according to Constraints

Some typical strategies for ensuring that project schedules can be adjusted according to
constraints are based on allowing enough room for change, following a rather proactive
approach. Some of the methods used include the following:
 Allowing for Reserves
The project manager of any project should foresee that certain phases may lead to
overheads that one could not account for. The establishment of available reserves of
different resources should allow their use when needed. Obviously these resources
should not be underutilised and towards the end of the project they could be
redeployed or even support enhancing existing activities, provide further value-adding
outcomes and improve the overall project performance.
 Introducing Substitution
Usually activities that are delayed may lead to idle resources and the workforce
performing below its optimum productivity level. The substitution of activities with
alternative ones that are not bound to any lagging task helps to ensure that the project
performs according to an acceptable standard.
 Preparing for the Occurrence of Risk Events
The preparation of a contingency plan following a risk analysis for the project is a safe
way to ensure that there will be minimum impact on project activities following most risk
© ABE
The Project Plan 75
events. Planning for such scenarios may be part of the project planning process
already discussed in Chapter 2.
 Improving Working Practices
If change is introduced into a project phase, a project manager could choose to adjust
the working practices accordingly. Although this is not a practice that should be used in
the long run, by doing this it is possible to achieve an immediate effect and help the
project performance to stay at an acceptable standard. Usually a significant alteration
in work patterns should be followed by sufficient reward mechanisms, to ensure that
staff motivation and commitment remains high. Ideally the reasons for such changes
should be explained and be supported with sufficient and fair justification.
 Investing in the Workforce
Another common approach when change strikes a project's routine is to employ further
human resources or redeploy existing staff. The long-term effects should be
considered, as any permanent changes such as job offers, position openings and role
allocations might be difficult to maintain after the end of the project. There are also
short-term implications such as the cost associated with the use of additional human
resources. Furthermore, the time required for retraining, induction and harmonisation of
existing team members with new recruits may affect the project time overheads as well
as create a more complex communication structure.
 Overtime
The provision of mechanisms such as paid overtime, productivity bonuses and
additional shift work may also offer the means to overcome obstacles due to project
changes.
Controlling a Project
So far we have discussed the main issues relating to the project-controlling process. We
need to review such steps under a different perspective when considering how project
activities can be controlled and how decisions are made in reaction to change.
The process inputs include:
 the schedule baseline that provides the project plan elements that help setting up the
project main activities and can be used to revise these activities under the light of the
introduced changes
 performance reports should assess the project progress against certain criteria and
the impact of any changes should be reflected in such performance measurements
 a schedule management plan that offers a representation of the project schedule and
could be used to revise the schedule and reflect any changes needed
 approved change requests that document the justification for any changes.
The project-controlling process is based primarily on the following techniques:
 Progress Reporting
Progress reporting offers a detailed discussion on how the project performs and
identifies any issues affecting its performance.
 Variance Analysis
This is an analytical view of how the project direction has been altered from the original
baseline. It also includes the causes of these changes and any forecasts for the
project's feature.
© ABE
76 The Project Plan
 Performance Measurement
Performance measurement means the analysis of any performance assessment results
based on the identified criteria. The tools used in this method may include:
 schedule comparison bar charts that offer the opportunity to compare between the
original Gantt chart and possible project timeline representations
 project management software that may provide an analytical view of any changes
happening in the project performance
 schedule change control systems that allow the project manager to adjust the project
schedule accordingly
 schedule variance and schedule performance indexes that offer a very detailed
repository of any changes, their causes, the impact to the project and the effect to the
project resources.
From a project control perspective, each project can be viewed as an effort that has drifted
from its original target. A snapshot of the changes that have taken place is used to assess
how these have been realised. The project control outputs include:
 performance measurements according to a set of predefined criteria
 requested changes with supporting evidence and justification
 recommended corrective action with any associated changes to project resources
including workforce requirements
 schedule baseline updates changing the project activities and phases from the original
plan
 schedule model data updates representing the new project schedule
 activity list updates leading to the same, original deliverables
 activity attribute updates, discussing activity aspects that have been affected by
change
 organisational process assets monitoring the effects of change to what is perceived to
be an asset for the organisation
 a revised project management plan.
Reorganising Project Schedules to fit available Resources

Since we have now discussed the project planning process, the requirements for project
scheduling and how to deal with risks and change, we should be able to summarise the
features of team performance that differentiate successful projects from failing ones. The key
is the ability to adjust project schedules to fit change and, more specifically, available
resources. This can be achieved if the project stakeholders are able to work together towards
the same goal. It is expected that a project with high-performing teams should be able to
adjust to change in a better way. But what makes teams perform better? This is a question
that depends on a number of factors.
Keys to Better Project Team Performance
The factors affecting team performance range from those that depend on how the entire
team is structured to the ones that relate to the characteristics of individuals. The
effectiveness of some team performance factors is also dependent on the strategy followed
at organisation level, while others are affected by the project management style.
Some factors affecting team performance are:
© ABE
The Project Plan 77
 Cohesiveness
The cohesiveness of any group depends not only on the time team members have
spent together but also on the nature of their jobs, the organisational culture and the
way collaboration and interpersonal communications take place during a project. A
team with high cohesiveness is likely to demonstrate effective team work, supporting
members, common goals, efficient procedures and team spirit. However the group
cohesiveness is strongly affected by cultural differences, the nature of the team roles
and hierarchy.
 Communication
The communication mechanisms supported in a team are likely to affect both the way
individuals perform in their roles as well as the style followed when reporting to the
project manager. The communication style of individuals may affect any team
communication protocols and etiquette that may be in place.
 Group Thinking
When decision-making and problem solving is based on group thinking and
brainstorming there are two positive outcomes. First, the team operates as a single unit
with aligned goals and objectives. Second, the commitment and motivation of its
members is dramatically increased. However the main drawback is the time it takes for
such group thinking to take place.
 Homogeneity
Some organisations advocate the need for homogeneity in their project teams. In
theory a group with members who are similar to each other should face fewer conflicts
that are likely to reduce its performance. However, in today's global economy quite a
few organisations choose to celebrate diversity and opt for heterogeneous teams. The
main reason for this trend is that the diverse skills and perspectives of the team
members may help the team to achieve a wider range of objectives.
 Role Identity
An important performance factor is the degree of role identity that team members have.
This means that members with a high level of role identity can associate themselves
with role responsibility and feel that their role represents them and their contribution to
the team. Such members are likely to have significant motivation and commitment
levels.
 Stability
The stability of the team is also an important factor as frequent changes may affect a
team that is always trying to adjust change. Team stability is likely to offer an
environment where conflict is rare and the focus is on project activities and
deliverables.
 Team Size
Finally, the team size plays an important role. For years there have been suggestions
for optimum team size, depending on the role of the team and the project requirements.
It is impossible to come up with an ideal number of members for a project team.
However an increase in team size is likely to introduce communication overheads,
increased probability for conflicts and problems, arising as well as a more complex
structure.
© ABE
78 The Project Plan
Think Point
Provide two examples of how changes in the team size of a project may affect its
performance. You need to consider increases or decreases in team size, the introduction of
new team members, the removal of key staff members and the resolution of personal
conflicts.
Review Question 4
List seven factors affecting project team performance.
E. PROJECT COMMUNICATIONS
All project decisions from project planning to schedule control and from risk management to
activity sequencing are based on effective communication. The ability to generate, record,
disseminate and exchange information is critical for the progress of a project.
Communicating information throughout a project involves a number of key processes,
including:
 communications planning
 information distribution
 performance reporting
 administrative closure.
Communicating Project Details to Stakeholders

Communication planning is based on establishing the information needs of the project's
stakeholders. The underlying principle is that by establishing what kind of information each
stakeholder requires, the necessary communications that must take place during the project
are easier to plan and control.
Furthermore, the information distribution process should ensure that the project information
is directed towards the stakeholders who require it. The process is concerned with the
method that must be followed to ensure that this happens.
The performance reporting process deals with specific types of data and more expressly the
information required to assess the project's performance. Such information is constructed in
the form of reports that provide an overview of how the project performs in certain areas,
reflecting on the project's progress in term of specific criteria.
The project closure is yet another phase that requires a wealth of communicated information
for administrative reasons. The closing reports provide detailed reviews of the project's
various aspects and a summary of the project life cycle.
Managing Project Communications
The way a project manager deals with the different project communication processes
described in this section sets the communication management strategy for the specific
project.
© ABE
The Project Plan 79
The communications planning process is based on:

 identifying communication requirements
 establishing a framework for supporting communication technologies
 establishing an understanding of any communication constraints
 making certain assumptions for the communication exchanges of the project.
A stakeholder analysis can be used to establish how the communication exchange will take
place according to the information needs of each stakeholder. The communications
management plan is the main output of the process.
The information distribution process is based on:
 identifying a work plan that sets the time frame for any required information for each
project activity
 using the communications management plan to coordinate the information exchange
 assessing the project plan in terms of information requirements for each activity.
The information distribution process is dependent on:
 existing communication skills
 the support of information retrieval systems
 the use of information distribution systems.
The project records are produced as a direct outcome of the information distribution process.
The performance reporting process is based on:
 a detailed project plan
 work results
 available project records.
Performance reporting provides information that is sourced from:
 performance reviews
 variance analysis
 trend analysis
 earned value analysis
 information distribution tools and techniques.
The main outputs of the process are in the form of performance reports and change
requests.
Finally, the administrative closure of the project is based on:
 performance measurement documentation
 project and deliverables documentation
 project records.
The process output is in the form of:
 project archives
 formal acceptance of the project
 lessons learned.
© ABE
80 The Project Plan
Describing Project Plans

So far in this chapter we have discussed how a project schedule offers a clear understanding
of how the project activities are linked. The project schedule is an essential part of the
project plan as it offers the means to assess whether the project is in line with the suggested
plan. Any deviation from the original plan is likely to trigger certain corrective actions from the
project manager. Before we provide a more in-depth analysis of the project plan elements
required for successful projects, we must understand the importance of a number of
supporting plans that help the project manager to use the information available from different
viewpoints during the planning process.
A plan of the human resources required for the project is essential. Such a plan offers a
detailed overview of the project needs in terms of the workforce. Different projects show
varying needs for a human resource plan and view workforce requirements from different
perspectives. For example, more hands-on projects are usually dependent on the number of
staff members who are involved in the project as well as on their work capacity. However
there are some projects that are not dependent on numbers alone, but also need a quality
assessment of what each individual brings to the project in terms of skills, knowledge,
experience and capabilities.
Another very useful plan is the communications plan. This offers a detailed overview of the
way communications take place in the project as well as the support required for such
communications. The plan should identify all types of communication required for the project
activities as well as a detailed description of how different communications should be
supported. Periodical reports are used to summarise the communication taking place during
certain project phases.
Furthermore, following from the discussion on risk assessment in Chapter 2, a risk
management plan is necessary for each project. The risk management report should
provide a detailed outline of each risk area identified and a prioritisation of these risks. It
should also provide a clear plan on how the project activities will be carried out in such a
fashion that the risks will not affect the project progress.
Essential Elements for Any Successful Project
In the previous sections of this chapter the project planning process has been discussed in
detail. The success of a project is reliant on a carefully created plan, but it is also dependent
on a number of factors, such as:
 project aims – these must be specific, feasible and suitable for the magnitude and
importance of the project
 project outputs – these must be well defined and tailored to the needs of the
stakeholders
 quality criteria – such criteria should ensure that the project schedule, plan and
deliverables adhere to certain quality standards
 project resources – these should be estimated according to the needs of the project
activities
 management structure – a structure should be put together based on a plan that may
follow the structure of deliverables, activities, processes, team structures,
organisational units, etc.
 milestones – the identification of milestones depends on how the project phases and
activities are broken up
 tolerances – controlling the project resources so they remain within an expected or at
least acceptable range means that the project activities will run smoothly
© ABE
The Project Plan 81
 dependencies – the dependency between project activities should allow the smooth
operation of the project and avoid idle periods for the project resources
 risks – the identification of risks following a detailed risk analysis is likely to ensure the
reduction of delays and spiralling costs
 schedule – schedule management is always one of the primary causes of concern for
project managers.
SUMMARY
This chapter has emphasised the importance of project planning and the effects of change in
project schedules. It has introduced project management structures and discussed in detail
activities in terms of the responsibilities assigned to personnel. We continued with a detailed
review of project schedules and how these are affected by changes over time. The chapter
concluded with a detailed overview on project communications.
© ABE
82 The Project Plan

Review Question 1
The project objectives (and hence the project goal) must comply with the SMART acronym
meaning that the objectives must be specific, measurable, assignable, realistic and timely.
Review Questions 2
(a) The five main steps are: choosing a project manager, selecting project team members,
assembling a project steering group, identifying a project champion and preparing a
project management plan.
(b) The five main stages are: identifying the project deliverables etc., structuring the WBS,
breaking down each WBS level to a more analytical lower level, assigning a code to
each detailed component of the WBS and verifying that no further breakdown is
necessary.
(c) The 16 main outputs are: project objectives, scope description, project requirements,
project boundaries, project deliverables, project acceptance criteria, project constraints,
project assumptions, initial project organisation, initial defined risks, schedule
milestones, fund limitation, cost estimate, project configuration management
requirements, project specifications, approval requirements.
(d) The six main inputs are activity list, product description, dependencies (mandatory,
discretionary and external), milestones, constraints and assumptions.
(e) The two types are the precedence diagramming method (PDM) and the arrow
diagramming method (ADM). The ADM can demonstrate four types of precedence
relationships/dependency, i.e. finish-to-start, finish-to-finish, start-to-finish, start-to-start
whereas the PDM can only deal with finish-to-start.
Review Questions 3
(a) The six main tools are project management software, mathematical analysis,
simulation, resource levelling, coding structure, duration compressions.
(b) The five main tools are the schedule change control system, performance
measurement, project management software, variance analysis and the iterative use of
planning.
Review Question 4
The seven factors are cohesiveness, communication, group thinking, homogeneity, role
identity, stability and team size.
© ABE
83
Chapter 4
Monitoring and Controlling Project Progress
Contents Page
Introduction 84
A. Progress Monitoring 84
Typical Problems Affecting Project Progress 85
Remedial Actions for Project Problems 88
B. An Approach to Project Control 91

Identifying Information Sources Indicating Deviations from the Desired Progress 91
Evaluating Status Information before Taking Action 95
C. Regaining Project Control 97

Calculating Variances and Slippage 97
Managing Deviations from a Planned Schedule 99
Summary 101
© ABE
84 Monitoring and Controlling Project Progress
INTRODUCTION
In previous chapters we discussed how projects are initiated, how their strategy is defined
and how more detailed plans are formed. This chapter focuses on the project manager's
efforts to monitor and control project progress. Each project requires continuous monitoring
in order to assess whether the progress achieved matches the initial specification and the
plan that was put together before project activities commenced. By monitoring a project we
attempt to detect any issues arising while their impact is still relatively manageable.
Furthermore, a successful project monitoring procedure should allow the project manager to
identify the factors affecting the progress of the project as well as the effort needed to deal
with the effects of these factors. We could view the monitoring of a project as a proactive
approach that enables the detection and sometimes the prevention of events that may cause
the project not to meet its requirements or follow its schedule.
On the other hand, controlling a project is a rather reactive approach to project management.
The objective of controlling a project is to deal with any issues that require the attention of
the project manager and typically some form of action. The reactive nature of the procedure
means that a certain level of decision-making and problem solving is involved. It is necessary
to fully appreciate that projects are rarely in line with original plans for various reasons.
Therefore the role of the project manager is not limited to the development of a project plan
and its documentation, but spans a number of areas that can be grouped together under
project control. Such areas of concern could include measuring performance, assessing
whether project requirements are met, dealing with problems, identifying risks, etc.
Objectives
 list typical problems which affect the progress of a project
 account for such problems and propose remedial actions
 identify those sources of information which might indicate deviations from the desired
progress of a project
 explain the importance of corroborating and evaluating status information before taking
action
 explain how cost variances and slippage can be calculated
 describe the courses of action open to the project manager in managing deviations
from a planned schedule.
A. PROGRESS MONITORING
It could be argued that progress monitoring depends on the project's success and
performance against certain criteria. One could say that the more successful a project plan,
then the less monitoring is required. However this is not an attitude that can be realistically
adopted, as there are several causes of problems arising in the project life cycle.
It becomes obvious that progress monitoring is necessary as it offers the means to identify
project shortcomings. Issues affecting project performance are usually related to uncertainty
in terms of what conditions the project stakeholders will meet once the project begins and
during the production of its deliverables. We should try to identify some reasons for project
problems and assess their effects on the project progress.
© ABE
Monitoring and Controlling Project Progress 85
Typical Problems Affecting Project Progress

It is not uncommon for people to have a genuine dislike of change, and we often find
ourselves worrying about the unknowns that the future might bring. Projects and their
managers are not strangers to such feelings, and it is quite common for projects to struggle
to keep up with change or even deal with slight deviations from original plans. Even large
projects may be affected, since smaller changes that accumulate over different stages may
lead to a significant alteration of the project setting. Changes in the project environment may
lead to catastrophic effects if the necessary adjustments are not made.
Configuration management is a field that deals with the specification of project
requirements, the definition of project activities and the establishment of a project setting that
offers the necessary foundation for the project deliverables to be achieved. However even
the most thorough configuration management technique and visionary approach in project
management may fail to foresee possible changes! Additionally, project managers may resort
to altering management techniques to deal with change. Such a strategy requires the
identification of factors that may affect the current situation. Furthermore, a number of
different possible states may be identified following a potential change that may affect the
project. The aim is to be prepared and put together a plan with well-defined and carefully
designed actions that should help the project manager to deal with the changes identified in
the scenarios.
Unfortunately there is no guarantee that the project manager can cope with significant
changes or whether contingency plans will be implemented as intended. The project
environment, stakeholders, resources and work plan are some of the reasons why change
may prove too much to handle and may even lead to complete failure and the termination of
a project.
Think Point 1
Provide an example of how external influences may introduce change to a project and
discuss how you should prepare for its effects. You should be able to identify events from the
immediate environment that may affect the project and illustrate how a clear strategy with
well-defined actions should be in place.
Another reason for a project failing is the credibility of the project outcomes. This relates to
people behaviour and may be influenced by external factors. More specifically, the project
stakeholders may stop sharing the common vision and goals. This could manifest itself in
failure to effectively use systems employed or delivered by the project. It may lead to users
not following the exact procedures or project stakeholders showing less motivation and
commitment. Such a scenario is quite frequent when pressure increases, leaving
stakeholders in need of reassurance and morale boosting. Failing to keep high motivation
levels is likely to affect the effectiveness of the workforce, so leading to disappointing
performance. By monitoring certain indicators it is possible to identify which areas of the
project are failing and identify the real causes. This should allow the project manager to react
to low performance and ensure that project stakeholders remain advocates of the project
scope and aligned to the mission of the project. However, we should reflect whether the
mission statement that describes the original project scope was significantly affected by
change.
Projects commonly suffer from prolonged periods of increased pressure on stakeholders and
project workers and personnel usually find themselves operating under pressure for
significant periods of time. During these periods it is expected that prioritisation of activities,
goals and deliverables is the key to the project's performance, at least in the short run. In
© ABE
other words, it is possible for project personnel to focus too much on tasks that have an
immediate impact on the project performance at the expense of performance in the longer
term. This is often the cause of project slippage (not meeting project deadlines) and may
lead to significant deviations from original plans. Monitoring the project plan should be based
on both short-term and long-term plans. By identifying early signs of the project missing long-
term targets, it is possible to control the processes affected (for example by offering more
training or increasing resources) and reflect on how short-terms tasks affect long term
deliverables. This is an activity that needs the participation of both the project manager and
the project members involved.
Projects should be subject to frequent periods of review and reflection, usually triggered by
carefully planned milestones. This allows the identification of reasons for failure and possibly
the cause for any deficiencies. An obvious choice would be to plan such reflective sessions
and reviews after key deliverables are implemented, but this does not guarantee prompt
identification of any problems or immediate corrective action. The project manager should
decide the best way for introducing review tasks in the overall plan. Reviews should be
performed in such a way that all parties involved participate.
Finally the size of the project may itself be the cause of problems as larger projects are more
prone to changes. A sizeable project is likely to be broken up in various work units, involve
several work packages, produce numerous deliverables and have a significant number of
stakeholders. This means that the effects of change are likely to be great and the monitoring
of the project rather difficult. The challenge is for the project manager to balance the size of
the project to the available resources in such a way that change can be handled in
manageable areas. While maintaining control of the overall project, it is possible to segment
monitoring and the way any issues are dealt with.
What Happens in Reality
The progress of the project is likely to differ from what was assumed to be its expected life
cycle. One of the most used techniques in establishing an estimation of the project's duration
and timeline is based on identifying a critical path of activities. This offers an understanding
of how many activities are required for the production of the project deliverables as well as
the way activities are interrelated. Regardless of which technique is used to provide an
estimation of the project's duration, there are various reasons for a project not meeting its
original plan. It is necessary to understand causes for project shortcomings and their effects.
A typical effect observed with project monitoring is that project activities fail to meet original
targets in terms of duration and use of resources. This means that project activities may run
late, thereby delaying the overall project completion and changing the way resources are
scheduled for specific tasks and deliverables. This does not necessarily mean that mistakes
were made in making original estimations, since quite often delays occur due to unseen
events and unknown circumstances.
It is necessary to monitor a project in order to ensure that all activities are completed within
the time frame allowed by the project manager and serious consideration should focus on
how these time frames are estimated. Usually, contingency plans are in place to help the
project manager deal with uncertainties and unforeseen events. It is likely that when activities
are planned, a safety margin is provided to allow enough slack time in case an activity
requires more resources and time from that originally allowed. Unfortunately the safety
margins are often insufficient, leading to further delays. The main concern is that project
managers are highly unlikely to be prepared for such delays, since the provision of a
significant safety margin should eliminate the possibility of delays in the first place.
© ABE
Think Point 2
The main issue relating to the monitoring and control of project activities relates to the
feasibility of a contingency plan that is based on establishing safety margins.
Explain why contingency plans are necessary to deal with changes that may affect the
duration of project activities.
In chapter three we have discussed WBS as well as a couple of activity network diagram
techniques that are used to create work plans and describe the way activities relate to each
other. Typically, such techniques allow for some slack time for each activity. When activities
begin at the latest times allowed due to resources being used elsewhere, the project enters a
phase where certain activities become critical. The fact that some resources remain idle
while other resources are being used elsewhere (forcing an activity to start at the latest
allowed time), means that it is likely for certain project activities to fail meeting deadlines.
A similar effect is observed when parallel activities are taking place, producing outputs that
may be required for subsequent activities. In such cases, the most delayed activity will affect
subsequent activities. The problem is that if several paths are leading to the same
synchronising activity, the project may not proceed unless all activities are completed.
Projects must be monitored in such a way that any findings are informed within a time frame
that makes immediate action feasible. Quite often monitoring provides findings at a point
where any remedies are possible soon after the effects of any errors are visible. Sometimes
monitoring results may show that the majority of activities are making good progress and only
a small number of them are facing delay. It is important to avoid ignoring any early signs of
any activities facing problems.
Another cause for delays is time wasted at planning stages or even the lack of efficient use of
extra time given. Starting a project activity in time is crucial to the success of the overall
project. Project workers should aim to start each activity at the earliest allowed time instead
of using slack time to remain idle. If resources are available, there should be no reason for
using the slack time at the early part of an activity rather than saving towards the end so it
can be used as a potential safety margin.
Sometimes it is considered a virtue to be able to multitask any project activities that take
place in parallel, and the ability to engage in a number of activities simultaneously is a
desired skill among project personnel. It means that the project may operate in more ways
and follow different pathways rather than those implied by a strict sequential approach.
However there is a danger relating to multitasking: resources may sometimes spread too
thinly, making it impossible to complete tasks in the specified time. Failure to design
multitasking in a way that allocates the necessary effort to each activity means that there is a
chance for the project to be delayed even more than would be the case otherwise (compared
to the traditional sequential model where each activity follows its preceding one). One of the
main reasons that multitasking fails is that several activities are associated with steep
learning curves. This requires the people who undertake specific roles to invest time and
effort becoming familiar with the new task while performing another task. Losing focus means
that tasks that have been interrupted for a brief period may require additional time for
personnel to re-familiarise with them, leading to wasted time.
Finally, project problems are frequently caused by incorrect estimates. It is quite common for
project managers to request a rather vague estimate for the duration of a task. The reason
this estimate is requested is for the project manager to get a rough idea of the project
requirements and adjust any resources that must be safeguarded for certain activities.
However, the initial estimation that has been given as an indication of an average period
required for similar tasks may then become a formal deadline. In such cases the work plan is
© ABE
not based on justified deadlines and estimates that have been carefully calculated, but on
speculations. In Chapter 3 we discussed the use of historical data by project managers for
making decisions. Resorting solely on historical data and previous experiences from similar
projects are not always good methods for estimating how long an activity will take.
Remedial Actions for Project Problems

It is certain that projects will face problems, some of which will be more challenging to
address. There is almost no guarantee that a thorough risk management approach will
ensure that problems and their causes are eliminated. Focusing on problems relating to
project tasks, it is relatively safe to assume that a major remedy could take the form of
following a more detailed approach in producing estimations with respect to the time and
resources required.
So how should a project manager justify the time estimate that has been assigned for a
specific activity?
The time required for the activity should be broken down into a number of elements that can
be justified according to the work involved in them or the effects they have on the activity
duration. These elements can be identified as follows:
 Activity time
This is the time required for a specific activity to take place. It may take into
consideration the number of tasks involved, any time required for preparation,
supporting activities and prerequisites including resources made available.
 Other activities
This is the time invested for other activities leading to the activity under consideration. It
may be the case that certain outputs and interim deliverables are required that may
affect when the activity can begin. This might be in the form of resources remaining
idle, waiting for specific resources to become available or even for certain outputs to be
produced.
 Interruptions
This is the aggregation of all the occurrences leading to additional delays and leading
to activity interruptions. There may be internal or external reasons for such delays and
the extent to which the delay may affect a specific activity depends on when it takes
place, which resource is being affected and whether an intervention is needed to
resolve a deadlock or similar situation.
 Safety margin
This is the time project managers should allow for each activity in order to have a
feasible contingency plan prepared. The safety margin for each activity should not be
viewed as an opportunity to remain idle, taking advantage of slack time. It is a period of
time that should be used only when project activities are delayed for genuine reasons
and for the purpose of ensuring that reasonable delays affecting particular activities do
not cause the failure of the entire project.
One could argue that if projects are delayed even after activity duration is calculated with the
foregoing elements in mind, then the project manager should reconsider the estimations they
provided. All project managers know that activities are going to be delayed no matter what
happens! However, there is no easy way to provide a schedule that includes overinflated
time estimates. Such a schedule is likely to result in a rather lengthy project timeline and put
project stakeholders off.
Even in those cases where a project activity is completed on time or early, the project may
not gain any actual benefits. After all subsequent activities must take place, and these are
usually affected by the safety margin accounted for. It is rather disappointing, but even when
© ABE
certain activities are completed earlier than the original estimation, the project is likely to
continue according to the original schedule. The only time the project would gain from early
completion of activities would be when these activities are rather late in the project life cycle
and possibly when they are producing the final deliverables.
A very interesting observation is that the predominant method for measuring activity
performance takes the form of the percentage of the activity that has been completed (the
"completion percentage"). In other words, a project manager is not aware of how long the
activity takes until it finishes, but only knows the percentage of completed tasks. This statistic
may seem useful at first but can be very misleading. For example, a project that has 90 per
cent of its key activity complete could lead to the assumption that only 10 per cent of specific
tasks are left. However, there is no indication whether the remaining tasks will last
proportionately longer than the ones already completed, e.g. 10 per cent of the tasks might
take 25 per cent of the overall activity time allocation.
Measuring Against a Baseline
One way of addressing problems such as the ones discussed in earlier sections is to identify
possible solutions that deal with the provision of more accurate or realistic estimations. The
theory of constraints offers a possible solution that takes under consideration the various
factors affecting projects in manufacturing environments. A typical scenario is bottleneck
situations, where the project resources or work plan proves insufficient to process the
required tasks. The bottleneck effect means that tasks remain unattended while resources
are scarce. The theory of constraints approach involves the following:
 identifying the constraint
 exploiting the system constraint
 subordinating everything to the constraint
 elevating the constraint
 identifying further constraints.
These five stages of the theory of constraints approach can be applied to project
management, regardless of the domain in which the project operates.
 The identification of the constraint is important as it controls the way the project
operates. A constraint can be determined by the critical path of the project, meaning the
series of activities vital for the project success that must be completed as planned.
However a constraint may take the form of resources that must become available
during the project's critical path. It could be the case that the project constraint takes
the form of unavailable resources, or ones that other projects are competing for.
Furthermore, project constraints may take the form of important milestones and key
dates that may impose deadlines that cannot be negotiated.
 Although project managers should seek suitable dates for project milestones so that
some flexibility is allowed, scheduling a project may need to adhere to given timelines
and be affected by external influences. In addition, resources contention is a problem
that may be caused when limited resources are distributed across projects that take
place in parallel. When something goes wrong to one project then it is likely for the
others to be affected.
 The exploitation of the constraint means that the project manager emphasises the
importance of ensuring the smooth operation of this part of the project. More
specifically, the aim is to support the project area affected by the constraint as it is
identified as the weak point. It is necessary to support any related activities to perform
to their maximum capability. This can be achieved by eliminating any factors that may
cause inefficiencies. For example, additional resources may be brought in to help the
© ABE
existing workforce, or equipment may be put on standby to avoid wasting time while
machinery is being fixed or is needed for another project.
 The subordination of everything else to the constraint means that the project manager's
full attention is geared to ensure that the constraint area operates at its maximum. This
means that the project manager and any stakeholders may even change the way they
do things in order to avoid the constraint affecting the whole project. For example, if a
member of staff is key to all projects (e.g. involved in final reporting or evaluation tasks)
it is important to ensure that all necessary resources are available and that this
individual's involvement remains uninterrupted. Furthermore, if an activity is critical for
the success of the project, leading to a specific deliverable, no competing activities
should be scheduled at the same time.
 By elevating the constraint the project manager may succeed in removing it from the
project identified constraints altogether. In order to achieve this, the project manager
must be able to identify how the constraint may benefit from an increased flow. For
example a team that deals with the assessment of project deliverables may be
allocated more members or receive additional training. The more the invested
resources and the higher the received support, the easier it is to remove a project
constrain.
Think Point 3
Using an example, explain how each step of the theory of constraints approach can be used
in sequence to allow constraints to be identified and addressed, and how this facilitates
measuring a project's performance against its baseline.
Review Questions 1
(a) How does the size of the project affect the way both internal and external changes are
handled?
(b) How should project managers monitor activities that take place simultaneously leading
to project milestones which require their outputs?
(c) What is the benefit of including a safety margin when calculating the duration of a
project activity?
© ABE
B. AN APPROACH TO PROJECT CONTROL

So far, this chapter has emphasised the importance of monitoring projects and identifying
what might go wrong with them. By identifying the project problems and their causes, it is
likely that the project manager can deal with them and support the project towards its
completion.
A successful implementation of a project monitoring plan is likely to lead to an effective
project control approach. The aim should be to ensure that each activity is controlled in such
a way that the project requirements are met and the transition from the activity's input
towards its output is smooth. The most primitive form of a control mechanism should view
each activity as a process that requires certain input and produces the corresponding output.
In order to control this process we need to produce sufficient feedback that is then used for
any subsequent activities or for further iterations that may be required for the particular
activity. Such feedback may be in various forms as far as it provides adequate information of
what has gone wrong with the activity, and it may possibly offer suggestions for remedial
actions.
So it is necessary to introduce control systems that allow project managers to assess how
the project performs against certain criteria. The path followed by the project is determined
during the initial planning stages, while control systems are used during the implementation
of the original plan. Corrective actions may be possible following the feedback received by
the monitoring systems.
We can identify a number of important requirements for controls systems, including:
 identifying key characteristics
 determining an acceptable range for such characteristics
 measuring control characteristics
 supporting progress visibility
 providing performance related feedback
 supporting corrective actions.
Identifying Information Sources Indicating Deviations from the Desired

Progress
Assuming that a project has a control system in place that is in line with the project plan and
closely monitored by the project manager, we should be able to identify the different
requirements of such a system. The key characteristics of a control system may change
slightly due to the nature of the project, but in most cases they fall under three main
categories:
 cost
 time
 quality.
Some projects may require additional characteristics to be included in the core of their
control processes, but it is unlikely that these will not somehow be related to the ones
already identified.
Being able to control the project cost means that the project manager is in control of the
budget, and any identified resources and supplies are obtained according to the proposed
budget entry. This is imperative as spiralling costs and erroneous estimations of project-
related costs may lead to the project cancellation or eventual trade-offs. It is important to
ensure that all activities remain within budget, and any justified extra expenditure is either
© ABE
compensated with additional output or rectified through the optimisation of other aspects of
the project. There is always the danger of external forces affecting the project, as various
industries may be affected by petrol prices, food prices, manufacturing costs, etc.
The project time depends on what the project priorities are. The attitude towards any missed
deadlines reflects not only the abilities of the project manager, but also the project
environment, its nature and the performance and behaviour of its stakeholders. Time is an
important factor for projects, as project managers try to control the time spent on each project
activity, as well as the way time is estimated during planning stages. The time required for
project activities is likely to affect their costs and the availability of any associated resources.
As mentioned before, it is common for projects to undergo certain trade-offs following
miscalculation of either time or cost aspects of the project requirements. Unfortunately the
easy option quite often takes the form of reducing the quality of any deliverables, and a
detailed discussion of the quality concept follows in Chapter 6. For now note that quality can
be determined in terms of a number of different aspects of the project including its
deliverables, the way activities are performed, support towards the work of stakeholders, etc.
A rather harmonised approach in controlling project quality is by using widely accepted
standards, dictating the expectations for various project aspects. Using a known standard
ensures that the project manager can measure the performance of the team and the
progress of the project by using existing benchmarks to assess the quality of project outputs
and deliverables.
The project characteristics described so far (cost, time, quality) offer a way to control the
project, but sometimes the trade-offs required are difficult to determine. The project
characteristics may vary depending on what is feasible, but there should be certain
limitations to the extent to these variations. These limitations provide a range of acceptable
margins for issues such as time and cost. For example, the maximum allowed underspend in
a project phase, or the time elapsed after a deadline before the project is cancelled.
An important aspect associated with the definition of limitations to the variation of project
characteristics is the measurement of such characteristics. There needs to be a method of
measuring project characteristics for the purposes of both monitoring and controlling the
project. The measurement is likely to take place in the form of input, processes and output.
Each measurement may require input that may be provided by project activities or
observation of project performance. The input is likely to be in the form of raw data that can
be used to assess whether performance deviates from the expected criteria. There is also
the possibility for certain processes to be required in order to check whether work patterns
and activities are performed as planned. Finally, the output should be in such a format that
would allow the project manager to determine which performance indicators are outside an
acceptable range and whether immediate corrective action is required.
To maintain the motivation and commitment of the project team, controlling processes must
be transparent. By establishing a visible process of measurement and control we enable
stakeholders to become aware of what is going on as part of the project control mechanisms.
This also means that project workers can understand why the project needs the corrective
actions taken. Project workers who are unable to comprehend what is going on and perceive
the project manager's actions as ones based on unjustified decisions are unlikely to show
high levels of commitment. The role of feedback is very important here, as it offers the means
for a project manager to narrow down any problematic areas and provide information to
those involved with specific activities of what is required to rectify problems.
© ABE
Think Point 4
Explain why the transparency of project control procedures is so important for maintaining
high levels of motivation and commitment. How does transparency affect stakeholders and
project workers? What implications does it have for stakeholders?
The corrective actions taken by a project manager are typically dictated by the performance
indicators and monitoring results. It is not uncommon for (project management) flow charts to
offer suggestions for the most suitable actions to be taken once monitored activities have
slipped from optimum performance. However the experience of a project manager is an
aspect that we should always take under consideration when corrective actions are decided.
More experienced managers are likely to have seen similar problems in the past, and so
even at early monitoring stages when measurements are not available they are able to make
corrective decisions based on knowledge and intuition.
Using Documentation Wisely
In order for project documentation to be useful, it has to include some key characteristics.
Project documentation should allow a prompt identification of important events and project
performance patterns to support an accurate and speedy monitoring process. Furthermore,
the level of detail in project documentation is essential as there is a need for adequate
information in order to identify the actual causes of any deviations from project plans. This is
crucial for a successful controlling procedure.
Therefore we may identify the main features of a project-reporting mechanism as follows:
 Information should be timely and reported within a reasonable period following the
implementation of each project activity.
 Information should be accurate and detailed in terms of what has actually happened
and how it relates to the planned activity outputs and project deliverables.
 Information should be complete in terms of the project phase involved as project
managers must be able to make decisions without being misled due to partial
information that does not show all related aspects.
 The process followed should not be time consuming and add unreasonable time and
cost overheads to the existing project workload.
 Resulting documentation should be in a form that may be easily used by project
managers and other project stakeholders in order to make decisions and take
corrective actions.
 Resulting documentation should be trusted and acceptable by anyone who is likely to
use it. This requires ensuring that the procedure followed is such that the recipients of
any reports regard them as accurate and from a trustworthy source.
 Resulting documentation should be conclusive and relevant in terms of determining
any problems and their causes as well as the time frame for their creation, as they
must help towards fast recovery of any project activities.
 Resulting documentation should have sufficient clarity in order for the intended users
to use it effectively. There should be no unnecessary complicated structures and
extensive documentation usually created by bureaucratic procedures and excessive
analysis.
There are several types of project report that are created during a project life cycle. It is
likely for project managers to identify the nature of information included in each report as well
© ABE
as its description, structure and title when they identify work packages and project
deliverables. The main types of reports may include:
 current reports
 cumulative reports
 exception reports
 stoplight reports
 variance reports.
Current reports may be used as snapshots of project performance as they offer an accurate
representation of the current project situation. The aim is to provide project managers with
information relevant to project activities at given times. The main aim of such reports is to
gain awareness of project status with some assessment of performance indicators. It is likely
for such reports to include some suggestions regarding the areas of the project that are not
performing according to the plan. A current report should also identify possible causes for the
identified issues and problems and provide suggestions for any corrective actions that may
be required in order to get the project back on track.
Cumulative reports are required because they offer a historical view of the project. Such a
report uses archived information and historical data to provide a view of how the project has
performed over a significantly long period. The report may be focused on specific activities,
project phases, or any other project aspects that may be tracked back to the beginning. The
underlying principle is to offer a historical perspective and demonstrate any changes that
may have taken place over different periods. This kind of report is used frequently as a
reflective mechanism for project managers in those projects that extend over longer periods
and may be affected by external events or perhaps key decisions.
Exceptional reports are different in their scope as they do not focus on a thorough analysis
of a vast array of project features. The aim is to summarise issues relating to project
exceptions such as deviations from original plans. The reason for such reports is for project
stakeholders to become aware of any issues. It is quite common for such reports to be used
by managers to consider critical situations and make decisions that could affect the future of
the project.
Stoplight reports are usually associated with specific stages in the project schedule and are
used to offer a summary view of the project performance. There are numerous variations of
such reports where each activity, resource, deliverable, phase or any other project structural
unit is assessed in terms of performance and progress. The intention is that the report does
not offer a detailed overview of what is wrong, but can be used to acquire an accurate and
summarised view of any project aspects of concern.
Finally, variance reports are used to compare the performance indicators for a number of
identified criteria. These criteria may be selected by the project manager or be part of pre-
selected ones that are used for all projects within the organisation. Such reports are usually
the means of comparison between different projects or even used for assessing performance
of project managers and the projects they are responsible for. The report is constructed
around the list of performance indicators and three entries that represent the
 planned performance
 actual performance
 difference
between the two performance measurements. The formatting of this report may be textual or
visual depending, on the use of the report. A summarised table of variances is more useful
for a detailed calculation of time slippage, any additional resource requirements and costs
© ABE
associated with the identified variances. A visual representation of the report is more useful
when an illustration of the project performance is needed.
Evaluating Status Information before Taking Action

There are several reasons why project managers must be capable of evaluating the status of
the project before taking any further action. When evaluating a project, it is necessary to
identify a number of aspects that should be reviewed including quality, cost and time.
Once certain quality criteria are determined for the deliverables of a project as well as the
way these deliverables are achieved, it is necessary for the project procedures to conform to
the quality requirements. It is evident that quality requirements must be met in order for the
project to be in line with its prerequisites. An additional viewpoint on quality is the fact that
once a project fails to meet certain quality criteria, it is open to criticism. Its deliverables may
not be acceptable and the processes followed for the project outcomes may be characterised
by negligence and lack of conformity to standards.
An interesting perception of project evaluation is that certain expectations are created
following the project's initial planning phase. It is critical for projects to deliver on promises
and expectations made, as such performance measures may be perceived as a measure or
indication of quality.
Controlling project costs is another aspect of project evaluation. It is quite often the core of
project management scope, as spiralling costs are usually the reason for failing projects. The
project manager may control costs by:
 classifying costs according to the identified budget needs and any financial functions
relating to project activities
 analysing financial data to identify any problem areas or surplus of funds
 allocating financial responsibilities to role holders and stakeholders who are involved
with specific project activities
 allocating costs and resources to different project phases and activities
 evaluating whether project costs are spiralling without proper justification
 authorising payments and controlling budget and expense claims
 competing for budgets and resources with other projects.
Think Point 5
By reference to some of the techniques for controlling project costs explain how controlling
project costs may affect the key activities of a project, for example by the introduction of
further resources, rescheduling, etc.
Project Monitoring and Control: Bodies of Knowledge

Project management bodies of knowledge with respect to project monitoring and control
include the Association for Project Management (APM) and the Project Management Institute
(PMI).
APM body of knowledge areas:
 Change control (section 34) – recognising that projects are subject to change and the
need for stakeholders to be involved in dealing with change. The existence of a
documented change system means that any possible changes are identified as well as
the impact of changes to the project progress.
© ABE
 Earned value management (section 35) – requiring the measurement of the value
against cost of various project activities and stages.
 Configuration management (section 46) – offering an assurance function for each
project deliverable.
PMI body of knowledge areas
 Integrated change control (section 4.3) – dealing with the control of changes, the
evaluation of their impact and the assessment of the project performance following
radical changes.
 Scope change control (section 5.5) – determining the impact to the project of any
changes to the original project scope.
 Schedule control (section 6.5) – offering the means to cater for changes while
maintaining the original project scope following revised project schedule of any
activities.
 Cost control (section 7.4) – introducing systems that control and track costs associated
with project activities.
 Quality control (section 8.3) – ensuring that quality control takes place in project
procedures and processes.
 Performance reporting (section 10.3) – reporting on project performance based on the
collection of performance data and the evaluation of project performance indicators
against initial plans.
 Risk monitoring and control (section 11.6) – identifying, quantifying and mitigating risks
in various stages of the project life cycle.
Being Objective about Threats
The estimation of threats varies significantly, depending on how a project is managed. The
way threats are perceived may depend on the organisation's perception of risks. There are
organisations that cannot afford any tolerance towards failure and risks. Such organisations
are likely to introduce high control strategies that do not allow slippage and delays. This
means that project activities may include significant overheads in the form of reporting
mechanisms and progress-monitoring techniques. In addition, possible deviations may
trigger corrective mechanisms that may affect the way personnel perceive the activity and
introduce stress at the workplace. The main danger would be for staff members to focus on
deadlines and performance indicators rather than project goals and quality criteria.
On the other hand, organisations that may have delegated project control entirely to the
project manager are likely to have in place a low control policy that avoids regular monitoring
and detailed reporting. In such cases there are likely to be certain cut-off dates that are used
once the project is delayed beyond a reasonable period or spiralling costs exceed an
affordable budget.
The individual style of a project manager may also affect the way a project is controlled.
There is always a dilemma that project managers must find an answer for, since risk is
directly linked to the level of control. Managers must decide whether they prefer to operate in
a project environment where limited control allows more flexible work patterns. However,
such practices are likely to lead to higher risks and possible failures and deviations from the
original plan. A key factor affecting such a decision is the associated costs as there is an
additional price tag for each controlling procedure that is implemented. Obviously there is an
associated cost for rectifying any failures and dealing with risks. It is therefore important for
project managers to assess whether it is more realistic and less costly to manage a project in
a more controlling manner, or allow for higher level of risks in anticipation of dealing with any
problems rising as they appear.
© ABE
Review Questions 2
(a) What are the main aspects of a project control system?
(b) What are the five different types of project reporting that may be used for monitoring?
(c) What are the main concerns for projects that have low levels of control with respect to
associated risks?
C. REGAINING PROJECT CONTROL

The previous section emphasised the importance of documentation in project monitoring and
control. The preparation of such project reports is necessary to provide the information
required for control activities. These activities are needed when project managers become
aware of project characteristics that are not in line with what was expected.
Project reports are regarded as the necessary form of documentation to be used as the
reference for any actions undertaken as part of the project phases. Furthermore, project
reports can be used to provide information regarding the project implementation stages and
to associate the deliverables implemented with those in the initial plans. Project reporting
may be used primarily for:
 tracking project progress
 detecting variations from plans
 taking corrective actions.
A project report should be structured around project phases and any associated activities
and tasks. The aim should be to offer an accurate view of how the project performs and
whether the project performs according to certain performance indicators. A project report
should also be a trusted source of information, one which can be used to estimate how the
current project performance relates to the optimum performance indicated in the planning
stages. This should allow an appreciation of how difficult it will prove to make necessary
adjustments and bring the project back to the required performance track. Finally, a project
report should provide sufficient indication of any sources of inefficiencies, delays, spiralling
costs and similar aspects of poor performance. In order to use project reporting in an
effective way, it is necessary to follow certain techniques available for the calculation of
deviations.
Calculating Variances and Slippage

The main types of variances measured in projects relate to cost and time slippage. There is
also the measurement of effort variations that indirectly relate to the additional costs
associated with extra effort required, as well as the duration slippage associated with lack
of effort in the form of idle resources.
In order to calculate such variances we need to establish a strategy that is in line with the
project scope. The project scope is likely to be described as a number of objectives and
clearly determined goals. These objectives must be achieved through the optimisation of the
resources available for project activities. There are several reasons why the measurement of
variances from such optimum performance is critical for the project's success:
© ABE
 Identifying deviations at early stages – the sooner we identify the deviations from
the planned and expected project costs and duration, the easier it becomes to put
together a plan of how to ensure the project returns to the required state.
 Reducing fluctuation – it should be expected for changes to occur in projects and for
certain fluctuations to take place in a number of performance indicators. Project
managers should be able to control such fluctuations and ensure that any contingency
plans and allowed margins are used to ensure the project operates as required. It is
necessary to be aware that fluctuations from planned measurements will exist. As far
as these fluctuations are reduced to acceptable levels, the project will continue its life
cycle without any critical obstacles and the need for major adjustments.
 Nurturing early corrective actions – there are no reasons for delaying any corrective
actions, allowing the accumulation of deviations. By failing to address any identified
issues as early as possible, project managers may not be able to deal with the
detected problems at later stages. There is always a critical point which, once reached,
means it is unlikely that existing resources will be able to cope with the extent of
deviation (from the required costs and duration).
 Determining schedule variances – it is necessary to establish a regular evaluation of
the schedule measurements and assess how each activity and project stage
progresses in relation to the initial project plan.
 Determining effort variances – it is also necessary to monitor activities in terms of
workforce effort and resources used. This should provide not only an indication of
progress, but it also supports the determination of any additional costs associated with
resources required by project activities.
It is necessary to build on these objectives for measuring variances and establish a plan of
how to determine problems and introduce their solutions promptly.
Optimising Project Excellence
In working towards project excellence by optimising performance, project managers always
attempt to improve the output of projects by improving planning and procedures. Of course,
once the project begins and changes start to occur, the only action possible is to monitor and
control the project performance. This means addressing project issues as they begin to
appear.
Project managers may focus on following an iterative approach in evaluating the project
output and updating the information stored for project progress. There are several areas
where regular updates should enhance control, and the following list is indicative:
 Timing any project updates – it is necessary to follow a consistent pattern when
updating project information as this allows project stakeholders to work on the same
set of data and be aware of the actual progress of the project.
 Reporting on tasks completed – the ability to monitor a project is dependent on
regular updates of how the work of the project progresses throughout its stages. It is
important to monitor every project activity and provide information on their completion.
 Recording historical information – based on previous projects of similar nature it is
possible to use historical data to make decisions and establish an understanding of
certain patterns shown with respect to project activities and overall performance.
 Estimating remaining work – the evaluation of each project activity that is not
completed should be done in such a way that its rescheduling and the estimation of the
remaining resources required are possible.
 Reporting on start and finish milestones – a progress report should always be
based on the start and end dates for each project stage and all associated activities.
© ABE
 Reflecting on duration and progress – the project progress should be measured in

terms of activity performance, meaning that each activity is measured for its duration so
far and the estimated time required for its completion.
 Reviewing effort and resources – offering the means to measure the effort invested
so far on project activities is critical for the assessment of the project requirements and
progress. This should be followed by an estimation of the resources necessary for the
project's completion.
 Providing completion rates – the overall project completion measurement should be
based on reports for the project's duration, resources and costs.
Managing Deviations from a Planned Schedule

In earlier sections and chapters we discussed project plans and how important they are for
the project's success. We explained a number of methods used for the estimation of work
required towards work packages and project activities.
So far we have expressed concerns about variances to the project plan. The reason is that
most deviations are viewed from a negative perspective. This means that projects are
delayed, incur more costs and require more resources. These negative variances mean that
the project manager must act fast, based on any provisions made when putting together the
project plan.
However, there is also a chance for positive deviations to take place following the efficient
use of resources and leading to activities being completed in time or before their deadline,
with less than planned costs and fewer resources. This seems an idyllic scenario, as the
project will benefit from the extra resources and funds that become available to the remaining
project activities. There is a downside of positive deviations relating to the project schedule:
project activities completed quite early may lead to idle resources.
Recognising Multiple Success Metrics
There are several methods for assessing project progress and ensuring that the project
manager is aware of any issues affecting performance. Typically, some of these methods are
computer supported and are based on the use of software tools. The existence of graphical
reporting tools helps project managers to obtain a visual representation of the project's
standing and an indication for any required corrective action or sources of concern.
The use of Gantt charts is very important as they can represent the project life cycle in a
series of tasks that are described based on the overall schedule with their start and end
dates being clear. The resources needed and the responsible stakeholders are identified in
Gantt charts for each project task.
The use of Gantt charts may help to identify:
 missed milestones
 failing tasks
 slippages
 successive slippages
 significant changes
 shifting schedules.
These are some of the issues that may affect a project drifting out of control, it being affected
by external factors or influenced by lack of resources. The project manager should try to
evaluate the Gantt chart findings and decide the most suitable actions.
A Gantt chart may have several forms depending on the detail required in the specific project,
the style adopted by the project manager and any existing software tools used by the
© ABE
organisation. In its simplest form, a Gantt chart will include a list of activities in a hierarchy
based on the chronological order of the start dates for each activity. Each activity is
associated with a bar that spans across a number of time units, indicating the duration of the
activity. Figure 4.1 shows a very simple example.
Figure 4.1: A Gantt Chart
Weeks
Activities
1 2 3 4 5 6 7
Activity 1
Activity 1.1
Activity 2
Activity 2.1
Activity 2.2
Activity 3
Another method of assessing project progress is cost schedule control, which utilises the
project financial data. This method allows mapping the planned activities to the actual work
undertaken. As the initial plan includes the budgeted funds for each activity, the cost
schedule control provides an understanding of how much the project costs at each given time
and relates it to the planned costs for the exact same period.
The work breakdown structure may also be used as a method for reporting on project
progress. As the WBS offers a breakdown of work packages and deliverables, it offers the
means to assign a completion tag for each element of the structure, helping the project
manager to evaluate the project performance in general.
Review Question 3
List eight ways of evaluating the output of specific project activities.
© ABE
SUMMARY
This chapter has discussed the main principles associated with project monitoring and
control. We started by focusing on typical problems affecting a project and a reality check of
project performance. The first section of the chapter concluded with an overview of remedial
actions supporting the project to return to its optimum performance. The next section
described how a project baseline may be used to reflect on the impact of change and any
problems rising and emphasised on the importance of project control. A detailed review of
information sources for data indicating progress deviation explained how project managers
may stay in control of project activities. We discussed how documentation and project
reporting support the project control efforts. Associating the project evaluation findings with
corrective actions leads to considering threats and risks. The last section concluded with the
calculation of variances and slippage and the ways to manage their impact to the project
activities.
© ABE

Review Questions 1
(a) Larger projects are more susceptible to changes. There are likely to be several work
packages, many deliverables and a significant number of stakeholders. So the effects
of change are likely to be great and monitoring difficult. The project manager needs to
balance the size of the project against the available resources in such a way that
change can be handled in manageable areas, by segmenting the monitoring process
and the way any issues are handled.
(b) Simultaneous activities need to be monitored in such a way as to ensure that any
findings are informed within a time frame where immediate action is feasible.
(c) To ensure that reasonable delays affecting particular activities do not cause the failure
of the entire project.
Review Questions 2
(a) A project control system must be able to: identify key characteristics; determine an
acceptable range for such characteristics; measure control characteristics; support
progress visibility; provide performance related feedback; support corrective actions.
(b) The main types of reports may include: current reports, cumulative reports, exception
reports, stoplight reports and variance reports.
(c) Compliance with cut-off dates and ensuring that costs remain within budget.
Review Question 3
By: timing any project updates; reporting on tasks completed; recording historical information;
estimating remaining work; reporting on start and finish milestones; reflecting on duration and
progress; reviewing effort and resources; providing completion rates.
© ABE
103
Chapter 5
Dealing with Team Structures and Leadership
Contents Page
Introduction 104
A. Organising Suitable Team Structures 104

Criteria Affecting the Team Role 105
Effective Team Organisation and Management 106
Comparing and Contrasting Teams Organised on Functional, Project, Matrix and
Contract Structures 112
B. Strategic Approach to Effective Leadership 116

Key Leadership Skills Desirable in a Project Manager 118
Influencing the Motivation of Team Members 124
Summary 128
© ABE
104 Dealing with Team Structures and Leadership
INTRODUCTION
When dealing with the management of an organisation's resources, it is essential to establish
a strategy for supporting the project structures (discussed in detail during the earlier
chapters) with appropriate team structures and leadership style. A necessary consideration is
to identify how human resources may affect the progress of the project and whether a
specific plan must be in place.
There are three very important aspects of project management that relate to the way the
human resources are structured and organised in a project, and we will discuss them in this
chapter. It is critical to be in control of the way a project addresses issues relating to:
 team formation
 role allocation
 leadership.
Before introducing methods and techniques that may be used when putting project teams
together, we must be aware of the fact that each project may have certain constraints that will
affect the way teams are structured. For example, a project team may be inherited from a
previous project, or certain roles may belong to individuals who possess specific skills,
knowledge and experience. There may be other influences on the team structure, depending
on the nature of the project, the available budget for personnel costs, scheduling, availability
of skills and other limitations imposed at organisational or even at project level.
Objectives
 explain the importance of effective team organisation and management
 compare and contrast teams organised on functional, project, matrix and contract
structures
 list and discuss key leadership skills which are considered desirable in a project
manager
 discuss the actions and decisions by which a project manager can influence the
motivation of team members.
A. ORGANISING SUITABLE TEAM STRUCTURES

When putting together a project team, we must be absolutely clear of the role that this team
must fulfil. We need to determine the strategic decisions that must be made for the teams
to be structured in such a way that ensures:
 achieving the project objectives
 working efficiently towards the project deliverables
 dealing with any project tasks and team-related problems
 communicating effectively
 performing according to the project plan
 engaging in decision-making and problem solving
 supporting the project stages and allocated activities.
These are only some of the benefits to a project that may be achieved by putting together the
right team. However this is not a simple task, and making sure that the requirements for team
structure are identified is a necessary first step.
© ABE
Dealing with Team Structures and Leadership 105
Criteria Affecting the Team Role

The process of creating a project team should begin by identifying the role of the team. For
certain project types, the team role can be defined by determining the scope of the project
deliverables for which the team will be responsible. This means that the project team must be
created in order to fulfil a functional need. A number of functional specialisations can be
defined in order to classify the type of team structure. Some examples of team
specialisation may include:
 research and development
 sales
 marketing
 engineering
 human resources.
These are functional areas where most team members should be able to operate, possess
relating skills, qualifications and prior experience.
Apart from the function performed by teams, there are several additional criteria that may
affect the method chosen for structuring the team. Some of these criteria may include:
 Products
An organisation's scope may be to create and deliver specific products, and teams may
be structured in such a way that their focus is on specific product ranges. Examples
could include manufacturing companies producing cars or computers. The production
teams must be specialised in certain product ranges in order to demonstrate optimum
performance, and be experienced enough to troubleshoot any defective components
and deal with rapid shifts in requirements and other product related issues. The focus is
on product development specialisation and specific skills.
 Customers
An organisation may include a customer-centred department where after-sales support
or pre-sales services are provided. Teams may be structured to deal with customer
needs of different natures and sometimes such needs may span across different levels
of specialisation. The customer demands and the level of attention required may also
affect who becomes part of the team. Such teams may include teams dealing with
specific customer problems (e.g. product-related queries, customer account enquiries),
and may differ according to the customer prioritisation. Customers may be classified
depending on their importance for the organisation, the severity of their case or
additional factors that may depend on the business model. An example might be health
services projects and how different customers (i.e. patients) have different
requirements and are supported by teams with different focuses (e.g. accident and
emergencies teams, planned admissions teams). The focus is on determining
customer groupings and classifying teams and their members accordingly.
 Services
An organisation may provide services to customers, other organisations or as part of its
internal operations. In such cases, team structures correspond to the way services are
organised. An example is an organisation offering mobile telephony services. A range
of sub-services are included in the overall service that is perceived as the provision of a
mobile phone service. Such services may support the customer in: (i) creating an
account; (ii) selecting the most suitable service; (iii) ordering related products and
additional services; (iv) dealing with any problems; (v) troubleshooting services and
products; (vi) operating the phone network; (vii) billing; (viii) updating records, etc.
© ABE
Focus is on the kind of support different services require and how different teams may
handle queries relating to each service.
 Location
Organisations are quite often constrained by their physical structures. So if an
organisation operates in different countries, and/or is dispersed over a number of
remote locations (e.g. different cities) and includes complex building structures, the
teams that are created may follow the same model. It is not uncommon for
organisations to have remote structures where individuals or entire teams work from
home, travel between locations and may involve various time zones and different
cultures. There are several examples of such models in today's workplace, where
multinational organisations utilise various work styles imposed by location. Here the
focus is on how the location constraints will not be allowed to affect the performance of
a team by introducing availability conflicts and bringing together team members that
satisfy the location criteria but fail to meet requirements relating to their abilities.
 Function
Larger organisations include several departments that have a predominant
specialisation. These organisations require the support of cohesive functional teams.
Examples of such teams may include finance and sales departments, and marketing
and creative divisions as well as IT and warehouse teams. These structures are
primarily organised with respect to the function (quite often mapped to specific
operations) they perform for the organisation. Focus is on the functional skills that team
members bring to the team and how they relate to the organisation's operations they
support.
Think Point 1
Choose a number of criteria that may affect your decisions when structuring a team and
propose a strategy for putting together a project team.
You should focus on three or four criteria such as product ranges or services and consider
how these criteria would change the way your team is structured as well as the way it
performs. You should also assess how your team would change if further criteria were to be
added at later stages.
Effective Team Organisation and Management

So far we have discussed a number of criteria that may be taken into consideration when
structuring a team. Organisations are usually based on hierarchical structures when they
group together their personnel. It is easier to deal with the organisation and management of
an organisation's workforce by establishing a method that reflects the nature of work.
For example, a hierarchical structure may be used to demonstrate how the organisation roles
begin from lower levels that may include individual employees and team managers, lead to
middle and line managers, before reaching the higher level of head of departments and
directors. Such a hierarchy is based on the job title and the classification of roles in the
organisation.
However, other examples of workforce hierarchy may be based on additional criteria. Such
criteria may include responsibility, management overheads, corporate culture, line
management, etc. The organisation's workforce may be organised according to the
responsibility associated with specific roles. In such a hierarchy the structure takes under
consideration the authority associated with the role rather than the job title used to describe
© ABE
the role. The line management approach establishes a clear link between roles, and uses
reporting responsibility as the criterion to allocate individuals to specific groupings.
Management overheads may also be used to assign members to teams and create
structures that correspond to the organisation's available resources. Obviously the underlying
corporate culture is essential in determining how the proposed hierarchies are implemented
at operational level.
It is essential to understand the importance of team structures in organisations. Putting
together a team should be based on an identified need to group together individuals, their
skills, knowledge, experience and even personalities. There are several characteristics
associated with the nature of teamwork that manifest themselves once the transition from
being an individual member of the organisation's workforce to a team member takes place.
Some of these characteristics are:
 the benefit of creating a pool of skills and expertise by grouping together team
members
 the ability to engage all team members in decision-making and problem solving
 the involvement of team members in operations by sharing their different perspectives
and capabilities
 the alignment of skills and capabilities of team members to meet the needs of project
tasks
 the harmonisation of team operations and activities
 the improvement of team effectiveness and exploitation of team member capabilities
 the reaction to identified risks and performance obstacles
 the development of an environment-fostering commitment and motivation among team
members.
There are several models that can be used to describe how these characteristics change
with time. Teams evolve from their original structure and they can be viewed as organisation
units that have a life cycle consisting of several stages. The team performance and the
behaviour of its members differ, depending on the life cycle stage.
In 1965, Bruce Tuckman introduced a four-stage model that describes the way a team's
performance evolves over time. The four stages are:
 Forming
At this stage, the team is unable to operate without a clear leadership style. The team
leader must maintain control as it is difficult for the team to agree the aims and
objectives for key operations as well as the way team members should work towards
their responsibilities. The forming stage is concerned primarily with the formation of the
unit from its members rather than focusing on the project tasks.
 Storming
At this stage, the team has become an entity that shares common goals and decides
on how these goals can be achieved. However, during this stage the need for
brainstorming and decision-making provides challenging experiences for team
members with different viewpoints, personalities and agendas. The storming stage is
concerned mainly with the coaching of team members in order to maintain smooth
working relationships and acceptable performance.
 Norming
© ABE
At this stage the team becomes a more cohesive structure where members are
engaged, and team roles and responsibilities are clear and widely accepted. Each
team member demonstrates evidence of wider participation, sharing and an ability to
deal with delegated tasks. Decision-making and problem solving are more effective,
while leadership becomes a shared responsibility with respect to certain tasks. The
norming stage is focused mainly on establishing a leadership style that is based mainly
on facilitation of team member initiatives.
 Performing
At this stage the team is capable of dealing with its project tasks without any major
assistance through clear and specific procedures. Any decision-making and problem
solving requires no more than simple facilitation support. There are no major conflicts
to resolve and team members operate as a unit. There is companionship and evidence
of joint responsibility of project tasks. The stage is focused on achieving performance
targets with minimum intervention.
In 1975, the Tuckman model was revisited and revised to include a fifth stage:
 Adjourning
This stage focuses on how the break-up of a team must take place. The aim is to
ensure that the team should end its operations in a way that does not detrimentally
affect team members. This is necessary when a team has been together for a long time
and team members have shared common work patterns.
Think Point 2
Consider Tuckman's model by using it in a hypothetical scenario of a project team that must
operate on a project of your choice.
Depending on the scenario you choose you should identify each of the five stages for the
project team and identify the main issues relating to the way its members will operate. Your
focus should be on distinguishing how the team increases its effectiveness while shifting from
one stage to the next.
Similar models provide a detailed representation of a project team's life cycle. Depending on
the organisation's scope for putting together project teams, team life cycle stages are
identified accordingly. For example typical team life cycle stages may include:
 Team formation
At early stages the objective is to bring team members together and establish a plan of
which skills and capabilities are required for the project tasks to be achieved. The team
formation should take under consideration existing team member profiles and the
avoidance of personality conflicts.
 Role allocation
The next stage is to allocate roles to each team member based on individual skills and
the project needs. The role allocation should take under consideration the role
attributes and the characteristics of the individual member.
 Harmonisation
Once roles are assigned and project tasks and their responsibilities are allocated, it is
necessary to perform housekeeping tasks such as resolving conflicts, prioritising tasks,
dealing with deliverables, supporting decision-making and problem solving.
© ABE
 Cooperation/collaboration
There are clear cooperation and collaboration tasks associated with each project task.
The scope for putting together a team is for its members to establish synergies that
should increase the performance capabilities for the project. The principle is that the
performance of the whole (the team) is greater than the sum of its components
(individual team members).
 Phasing out
While certain teams may be more permanent structures that will remain in place for
specific organisation project tasks, it is not uncommon for teams to cease to exist once
the project is finished. A successful organisation plan should take under consideration
the deployment of the human resources after the project ends.
 Termination
Once the project is over, the team may need support in order to shift to new projects, or
deal with any major changes. This stage becomes critical when a project ends before
its expected completion date and prompt changes are required.
Rewarding Excellent Team Performance
Teams may be put together either for dealing with a specific project or to undertake certain
responsibilities that recur at regular intervals during an organisation's operations. Team
behaviour and performance is likely to vary significantly for a number of reasons. Different
teams may deal with similar projects so differently that it is important to assess their team
structure as well as their performance throughout their life cycle. However even the same
team may demonstrate varying performance during a project life cycle. This may depend on
tasks, external factors, unexpected events and several other factors. In either case, it is
necessary to follow a clear plan that ensures effective team performance.
There are some useful practices that, by improving the effectiveness of team work, may
encourage optimum performance and fewer team problems. For example:
 Define a clear goal that team members can associate with. This goal must be well
defined and should be shared between team members, offering a specific mission for
the entire team.
 Establish a result-driven strategy for organising the team structure. The aim of this
strategy is to ensure that each task has the necessary resources allocated for
achieving its deliverables.
 Involve team members with a suitable profile in undertaking the project roles and
responsibilities.
 Ensure that team members share their common objectives and support each other
when required.
 Nurture collaboration and communication between team members as required by
project deliverables.
 Define specific performance indicators and criteria for both the team and individual
team members.
 Establish performance rewards for the team and its members in order to increase
motivation and commitment.
 Attract external support and the necessary organisational infrastructure.
Think Point 3
© ABE
Consider possible reward mechanisms that you could introduce for a team that is not
performing up to the required standard. Think about the different measures which would be
appropriate if the lack of required performance relates to the entire team, certain roles or
individual team members.
Also, consider how you could define certain standards as a benchmark against which you
could structure a hierarchy of rewards.
The introduction of reward mechanisms should support the engagement of team members
and lead to increased team performance. These rewards may take various forms, depending
on the organisation's human resources policy. Rewards may include additional benefits,
increased salaries and bonuses, promotions, etc.
Recruiting the Project Team
Clearly the success of a project team depends on the team members as they affect a number
of project tasks performed during the project phases. The performance of a team depends on
how the team will deal with a number of tasks including:
 holding successful and productive project meetings
 establishing a team culture that is shared between members
 identifying a common goal and shared mission
 introducing reward mechanisms and performance rewards
 supporting decision-making and problem solving
 dealing with differences and conflicts
 motivating team members.
The membership of the project team is critical for the success of these tasks. Any project
team recruitment decisions must take under consideration a number of factors, including:
 abilities
 availability
 expertise
 credibility
 personality
 social standing.
This list is not exhaustive and sometimes a project manager will need to take other factors
into consideration. Often the main consideration will be whether the individual possesses the
skills, knowledge and capabilities to perform a specific vacant role. Such capabilities may
include transferable skills that may be used in a different setting, such as making decisions,
operating under pressure, dealing with change, managing unknown and vague scenarios,
etc. The availability of team members is critical, especially when a project is operating in a
very short time frame. This means that team recruitment may be based on the availability of
an individual, providing certain standards are satisfied in terms of the person's skills and
knowledge. The experience of team members in similar settings and with previous projects
of the same nature is an additional factor that guarantees team members being able to
address the project requirements. Certain individuals enjoy organisation-wide respect and
acknowledgement because of their efforts and prior success.
The credibility of team members may affect the way their opinions are perceived during
decision-making. Such members may undertake responsibilities including facilitation of
© ABE
meetings, mentoring and coaching. The team member's personality is an additional factor
that should be taken under consideration when deciding team membership. Team members
must be compatible and there must be no major conflicts created due to a personality clash
or differences in working habits. Team members with increased motivation, commitment,
integrity, ambition, personal drive and ambition are likely to become drivers for improved
team performance. Finally team members may offer additional benefits to the team by
personal links and connections, either within the organisation or externally.
Managing People
The management of teams includes a very important task: to manage the people involved in
the project tasks as team members. Sometimes the team performance may be affected by
personality and task issues associated with individual team members.
People management will involve various tasks that may include daily tasks or focus on the
introduction of policies that regulate how personnel are organised. A very important aspect of
people management is managing project meetings. A project meeting is perhaps the main
method for communicating ideas, dealing with any collaboration issues, making decisions
and resolving conflicts. The management of meetings includes a number of issues, such as:
 deciding on who should participate in the meeting
 determining the agenda of the meeting, including the main topics for discussion
 preparing for the meeting, especially if any actions are required or whether project
documentation must be presented
 following up with any actions resulting from the meeting decisions.
The management of project teams should be based on the adoption of certain practices that
may already exist in the organisation, may be common practice in the field or introduced for
the specific setting. The project manager should be able to set certain ground rules for what
is considered as acceptable behaviour and performance for team members. The planning
and scheduling of project meetings following the guidelines described previously should offer
an opportunity for team members to exchange ideas. The project manager must have a clear
strategy of how decisions should be planned ahead and for the procedure that should be
followed for making such decisions. The aim is to foster engagement from team members,
while smoothing any major differences and allowing brainstorming and debate.
The key success factor is for decisions to be well informed and based on sufficient
justification. The manager must be in control of the project decisions, meaning that each
decision must be supported by the entire team and be in line with the overall project mission.
Each decision should be traceable back to those members who are responsible for the
information and outputs used for its justification. The project manager should ensure that
team member relationships are such that they do not pose a concern for the project
performance. The manager must also support team members during times when change
takes place.
The management of human resources is also affected by the geographic dispersion of the
locations that are part of the project infrastructure. There are so many considerations for
project managers associated with the remote nature of geographically dispersed project
resources. If people reside in different locations then communication must have additional
support to compensate for the absence of face-to-face contact. The use of technology may
influence the effectiveness of project communications, as it may not communicate the
richness of mannerisms and human behaviour. When technology must be used for
communication, there may be cost or time overheads involved as team members must be
familiar with the tools used and the necessary equipment must be in place.
The existence of geographically dispersed resources may lead to the involvement of team
members that reside in different time zones. This means that careful scheduling is needed
to ensure that meetings are held at convenient times. The fact that meetings may be held
© ABE
between people in different location means that participants must make an effort to reduce
misunderstandings and noise from external influences. A worse-case scenario might be
different time zones preventing team members communicating at the same time on every
occasion (asynchronous communication).
In addition, there are cultural issues that may affect the management of dispersed
resources. An understanding of national culture is essential for establishing project
management practices that are suitable for the specific human resources involved, i.e. there
needs to be an awareness of how culture affects the behaviour of team members. Cultural
norms may also constrain the way a team performs and its team members communicate and
collaborate.
Think Point 4
For a project team that is in the middle of a project (you may choose a fictitious one) identify
the steps you should take for organising a series of project meetings.
After determining the scenario you wish to explore, you should identify the reasons for each
meeting and provide a set-by-step approach from putting together the meeting membership
to disseminating its minutes.
Comparing and Contrasting Teams Organised on Functional, Project, Matrix

and Contract Structures
There are several approaches in organising projects but organisations usually follow generic
ways that have proven useful in the past. There are three main methods that organisations
may follow in organising project structures and resources:
 divisional or projectised
 functional
 matrix.
The divisional or projectised approach means that each project becomes a separate entity
within the organisation with its own dedicated resources and structures. The nature of this
type of organisation is such that projects are self-contained. Each project has its own budget
and work plan and should not affect the organisation's other projects.
The functional method is based on the classification of human resources in a manner that is
derived from a specific function. There are several possible functions or divisions that may be
used for such a classification. For example, individuals may be grouped together based on
their skills or their role in the organisation. An alternative method could use the products or
services of the organisation to group together individuals who are undertaking tasks for
specific product ranges or services. Furthermore, the location of the workforce may be one of
the criteria used to provide the functional groupings of the organisation.
Finally, the matrix approach attempts to combine the main features of the previous two
methods. The matrix organisation uses the functional groupings that have been put together
based on the skills and capabilities of individuals. These functional groupings are the pools of
individuals that the project manager may use to select team members. Once a project is
defined, the project manager may draft certain members from each functional grouping and
establish a project team that has sufficient skills, experience, background, etc.
Project Manager or Functional Manager?
© ABE
It is rather difficult to decide the best approach when putting together project teams. The way
a project is managed depends on how the organisation perceives the project management
methods presented here. While it is not possible to identify which is the best method, there
are clear advantages for each.
A divisional or projectised approach is the most simple to use as it is based on organising
everything around the project. The project becomes the core of the organisation and the
project manager does not have to consider additional factors apart from the project budget,
requirements, resources and team.
However there is a significant drawback with this approach: it is rather rigid, since it is based
on individual projects. The resources dedicated to the project are not flexible in terms of
being capable of allocation to additional projects and external tasks. The project scope is
usually so central to the focus of team members that it may blur the organisation's mission.
Furthermore this approach may prove a rather expensive method, as it does not support the
reuse of resources and mobility between projects. Eventually, when the project terminates,
team members may find it more difficult to cope with their next tasks.
The functional approach is the best one for keeping individuals together according their
background and expertise. This practice allows them to maintain a high level of cohesiveness
and alignment with any corporate goals. The method is quite cost-effective as it allows the
use of skills as they are needed and projects can borrow human resources from each
division according to their work plan.
But there are several drawbacks with the functional approach, as the process is focused on
workforce rather than project needs. By not having dedicated resources, each project may
become a logistical nightmare. The project delivery is a very difficult task to achieve as
project managers do not have the same control on the allocated resources. The main
problem is that team members do not show any evidence of a team culture, but seem to
belong mainly to their functional cast. This means that their performance is almost impossible
to appraise, as their individual goals are aligned to their functional role within the organisation
instead of matching the needs of their project tasks.
Think Point 5
Compare and contrast the divisional and functional approaches.
You should focus on the advantages and disadvantages of following these two different
approaches. Your answer should be based on a clear understanding of the way project
members are selected for each of the two approaches.
Many feel that the matrix approach is perhaps the most effective way of managing project
teams. By using resources from various functional groupings there is always an availability of
skills for each project. By allocating resources to specific projects, team members become
focused and have a clear identity for their role and the tasks they undertake. The method
offers maximum flexibility, allows for frequent changes, supports project termination and
creation of additional project tasks and helps project managers to multitask different projects
with dedicated resources and budgets.
The main drawback of the matrix approach is that it requires a lot of communication to
succeed. The project manager must be in control of the resources dedicated to each project
while negotiating objectives, tasks and individual agendas. The prioritisation of different
projects and the determination of how resources are allocated must be agreed between
several stakeholders.
Project and Team Contracts
© ABE
Following our discussion of the different organisational approaches we will now consider how
negotiations take place in order to make project resources available. There are several
contractual agreements involved with each project. Depending on the organisation, the
management approach, the project scope and several other factors, the project manager
may have to consider numerous contractual arrangements.
Some of these arrangements may include contracts with:
 organisation employees
 project managers
 external employees
 suppliers
 other organisations and service providers.
One of the key factors affecting the contractual agreements of a project is the nature of the
work undertaken and any associated structures. In the case of the matrix organisation we
have seen there is a more ad hoc approach in bringing together project resources. The aim
of the project manager is to produce the project deliverables in the most effective way.
Therefore the agreements that must be in place should cover:
 project requirements
 project deliverables
 project resources.
In the matrix organisation human resources are drawn from existing organisational divisions,
meaning that agreements are in place to govern:
 individual roles
 job specification
 project participation.
It is evident that the arrangements made by an organisation will depend on the management
approach followed when putting together the management team. Being able to determine the
project team structure is likely to affect the establishment of clear contracts and agreements
that are easy to follow, leading to less conflicts and misunderstandings.
Project Team Structure
The project team structure depends on how human resources are organised, as we
discussed earlier in this section. There are several steps that must be followed before the
creation of the team. Such steps may include:
 Assigning a project manager – this step is concerned with the identification of the
individual who will be in control of the project and carry the main responsibility for the
project's success or failure.
 Defining roles – this step focuses on defining each role within the project team and
describing the tasks that are associated with project roles as well as ideal profiles for
candidates.
 Identifying responsibilities – this step provides a detailed specification of those
responsibilities associated with every project task. Ideally the role responsibility should
provide sufficient detail for the determination of the skills, knowledge and experience
required for the successful fulfilment of the role.
 Setting up a staffing process – this step provides a detailed process for staffing the
organisation (if no individuals with the required skills already exist within the workforce),
becoming a member of the team and being assigned a project task.
© ABE
 Setting up a performance management process – this step offers alternatives (from

letters of commendation and bonuses to additional benefits and incentives) for a
reward management system as well as the mechanisms used for monitoring
performance and raising awareness of project progress.
 Establishing a communication plan – this step describes the means and methods used
for enabling or supporting project communication. Communication may relate to project
tasks or be associated to project roles. Project communication may also be formal or
informal, periodical or sporadic, detailed or brief.
 Obtaining support – this step identifies those stakeholders who should provide their
support to the project. Sometimes support may be required by external entities such as
government, agencies, intermediaries, suppliers, etc.
Modern organisations are increasingly using the matrix organisation approach as it offers a
cost-effective way of allocating resources to projects. However, there are some variations to
the way the matrix method is implemented. The different models of the matrix approach are:
 lightweight
 balanced
 heavyweight.
In the lightweight model, the project manager acts as the coordinator of project resources
and the line managers of individual project team members are mainly responsible for their
performance and disciplinary actions. The lightweight model is used when a project does not
have a dedicated budget or a more permanent nature.
The balanced model provides a balance between line management and project
management. The project manager must identify those project tasks that require resources
that must be spared by the line manager from the corresponding division. The balance is
between the management of project resources and availability of resources at an
organisational level.
The heavyweight model is based on creating secondment opportunities for individuals in
the organisation's divisions. Once the project is completed, the individual returns to their
division. The project benefits in this model with skilled members that are required for specific
periods and cannot be afforded after certain project phases are completed.
Quite often project managers may choose their project membership from various
organisational functions as mentioned in the functional model. The scope for such an
approach is to establish:
 The provision of the required output at an acceptable cost.
 The production of project deliverables of an acceptable quality.
 The presentation of deliverables in the acceptable time frame.
It is quite common for a mixed approach to be the preferred choice as modern projects are
usually so specialised that many may require specific skills and for very short periods. The
project manager must be able to coordinate resources that may become available through
the following channels:
 organisation divisions (divisional approach)
 organisation functional groupings (functional approach)
 external contractors
 partner organisations.
© ABE
The project manager must be able to coordinate the various resources in such a way that
their working patterns and management style are harmonised and aligned with the
organisation's mission and policies.
Review Questions 1
(a) What are the seven main considerations for structuring a project team?
(b) List five examples of functional specialisms that can be used to classify team structure.
(c) What are the eight main characteristics associated with the nature of teamwork?
(d) What are the main stages of a project team's life cycle?
(e) What are the seven tasks that a high performing team must succeed at?
(f) What are the main advantages from each of the three project formation approaches?
B. STRATEGIC APPROACH TO EFFECTIVE LEADERSHIP

One of the key factors for an organisation's success is leadership and the way it is achieved,
both at a strategic level and on daily operations. The concepts of leadership and
management are closely related. It is argued that although project managers must possess
management skills for the fulfilment of their role, leadership skills are difficult to acquire.
We could define the management concept as the application of authority over team
members, according to a structure imposed by the organisation. In some cases this structure
may be a specific project or a more permanent structure, such as a department or division.
We could also define leadership as the ability to drive others towards the leader's vision.
This could be in the form of persuading team members to perform certain tasks, succeeding
to align individual goals with the leader's scope, establishing a certain attitude towards work,
motivating members, increasing commitment, etc.
One could argue that it is difficult to put together a recipe of known ingredients for a
successful manager and an inspirational leader. This section concentrates on identifying
several aspects affecting both management and leadership in a project. Some of these
aspects are:
 Background
An individual's background may reflect on the way he/she was brought up, including
influences from family, school, national culture, etc. The opportunities for education and
training are likely to affect one's abilities, knowledge and attitude.
 Roles and tasks
Managing and leadership skills are likely to manifest themselves in different ways
depending on the role of the individual. The attempts to motivate and inspire team
members should be proportionate to the specific task.
 Skills and abilities
A mosaic of a person's experiences, knowledge, skills, personality and behaviour
affects the way both management and leadership skills are put into practice.
 Project specific
© ABE
The project management role is dependent on the way the organisation perceives the
project's scope and the importance of the role. The underlying corporate culture is quite
likely to affect the perceived value of leadership skills.
 Style
The management style adopted is a combination of an individual's view of project
management and the organisation's framework for what is perceived as acceptable and
possibly required management behaviour.
 Effectiveness
Management skills are assessed in terms of how successful the manager is with
respect to specific indicators.
 Influence
Leadership skills are tested against the intended outcomes for the project.
Leadership is demonstrated in several ways during a project but also in everyday life. It is
almost impossible to provide a leadership model covering all possible perceptions of
leadership. On the other hand there are certain types of managerial leadership that are more
common in projects. Some examples may include:
 Leadership as a trait
There is always the view that leaders are born and not made. Possessing leadership
qualities is therefore a differentiating characteristic of certain individuals who should be
awarded certain roles in the organisation.
 Leadership as a responsibility
Some organisations perceive leadership as a responsibility that comes with the role, so
if someone holds a certain job title they should be able to lead. Sometimes this notion
of leadership may lead to group leadership models and the introduction of leadership
training programmes.
 Leadership as a behaviour
There is an approach to leadership that views how individuals alter their behaviour
once they are allocated a position of responsibility. Leadership becomes part of the
individual's behaviour and is likely to affect decisions and the way a project or a team is
managed.
 Leadership as a style
The personality of an individual also affects the way leadership is exercised, and more
specifically how leading roles affect communication and coordination of peer and
subordinates.
 Leadership as a condition
There are certain project phases that may require initiative and key actions. The
demonstration of leadership skills may be triggered by an event or a project crisis. This
approach considers leadership as a behaviour that varies with time and adapts to
different conditions.
 Leadership as a transformation tool
One of the effects of leadership should be to enable the transformation of an
organisation and its structures, the human capital and individual members, in order to
achieve set targets and work towards the common mission.
 Leadership as inspiration
© ABE
Eventually leadership is perceived as a virtue that once possessed can help the
management of individuals and teams. Regardless of the leadership style, a good
leader should be able to inspire others.
Think Point 6
Reflect on your leadership skills and, based on previous experience, identify your current
leadership style.
You should consider examples of leadership roles you might have had in the past and justify,
with evidence, why you believe yours is the specific leadership style you claim.
Key Leadership Skills Desirable in a Project Manager

There are several skills required for a successful project manager. Quite often these skills
are identified as the traits a leader must possess. The skills of a project manager may relate
to:
 the project task
 the project manager role
 character
 relationships
 personality.
These groupings may be used to describe the various skills a project manager must have in
order to deal with project difficulties.
A good leader should be in control of the project tasks and ensure that they are fulfilled as
required. The project manager must be able to allocate project resources and deal with any
issues rising from missing resources including finances, skills, etc. The manager should be
able to help out team members and be proactive in dealing with situations where existing
infrastructure and resources cannot cope with the workload. The cooperation with others and
the coordination of the team are essential for a high-performing project. The project manager
should be able to acquire knowledge, and disseminate information necessary for problem
solving and decision-making.
With respect to the project manager role, leadership skills are frequently associated with
respect from subordinates and peers as well as recognition for skills and knowledge. The
visibility of the role holder and his or her advancement and progress in the organisation's
hierarchy are also indicators of the project manager's status. This is likely to result in a
number of strong working relationships that are very useful throughout the project life cycle.
The character of the project manager is such that their vision is likely to lead to ambitious
plans and a drive towards achieving the organisation's mission. The project manager is likely
to have a drive towards excellence and performance. Integrity and an ethical view of the
project's scope are also part of a visionary approach to project management.
The project manager who is able to demonstrate leadership skills is likely to have a very
good relationship with the project team members. The project manager role does not
require a continuous coordination effort that focuses only on deliverables and performance
indicators. A leader is expected to understand other people's needs and become aware of
any personal problems. The successful project manager can shift from being a coordinator to
a more nurturing role, offering coaching skills to the team. The manager should be able to
accept the weaknesses and appreciate the strengths of individual team members. The ability
© ABE
to provide personal support when needed seems to be a key factor in establishing high
motivation and commitment within the group.
Finally, the personality of a leader should be such that any challenges are regarded as
opportunities. A project manager should thrive during difficult situations and be proactive in
dealing with problems. When such scenarios arrive a leader is more likely to be involved and
participate in finding a solution.
Leadership and Management Style
Both management and leadership styles depend on a number of factors that affect the way
decisions are justified and interpreted by the project stakeholders. The factors affecting the
preferred style of leadership will differ according to the organisation involved, the project
environment, the individual managing a project, the cultural background, etc. The different
approaches describing how the leadership style may be classified take into consideration the
following criteria:
 Addressing project requirements – the project requirements may range from more
basic ones that relate to the completion of deliverables, or may include more complex
ones associated with quality assurance.
 Considering stakeholder needs – those people who are actively involved with a
project may be viewed as workers who undertake certain roles, or as individuals with
their own needs that must be satisfied in order for the project to succeed.
 Assessing individual roles – each team member that undertakes a role may be
constrained in terms of the specified work packages and deliverables, or may be a
more autonomous unit that is allowed to make decisions and provide a more personal
touch to the way the work in undertaken.
 Determining management approach – the way a project is managed may follow a
more controlling approach that allows no flexibility to team members, or be based on
the manager having a more relaxed role that usually concentrates on the facilitation of
certain processes and monitoring the performance of the project tasks.
 Deciding on a work pattern – the project tasks may be implemented following well-
defined instructions and adhere to rules and organisation policies, or may allow a more
challenging approach based on risk taking and the exploration of ambitious
alternatives.
 Allocating responsibility – the responsibility of individual tasks and the overall project
may lay with the project manager, or alternatively it may be shared between all
participating team members.
So it is possible to follow several paths in the way a project is managed, and this is a
decision that is usually made by the project manager. While an organisation may dictate a
preferred management style for its projects, it is quite unlikely that it will attempt to impose
certain leadership styles. Although an organisation may attempt to draw the values of the
individual who should become an aspirational leader, it is usually a gamble whether the
project manager is able to lead in a style that is in line with the organisation's idealised
leadership profile. One of the conflict areas between the theoretical background offered by
leadership models and the practical aspects of personal leadership styles is the way chosen
to motivate team members.
Team Motivators
In smaller teams, after a significant period a project manager will be able to understand the
behaviour of each team member, and so can lead the team with a style that is tailored to the
individuals involved. In contrast, in modern organisations with more complex staffing
procedures, several simultaneous projects and tight time frames are likely to be based on
different theoretical models in order to maintain a highly motivated project team.
© ABE
There are several models that describe how team motivation may be supported and most of
these models are identifying factors affecting motivations as well as motivation levels that
can be achieved once certain factors are satisfied.
The work of Frederick Taylor is presented as a set of scientific management principles that
are concerned with the motivation of individuals who are involved in repetitive work. These
principles are identified with the following actions:
 Investigate how the project is structured in order to divide each project activity into
manageable tasks and introduce a quantitative way for estimating the actual work
needed for the task and how it should be performed.
 Follow a scientific approach in order to assign roles and allocate individuals to project
tasks. Therefore a matching process is needed to ensure that team members are
responsible for suitable tasks.
 Depending on the task's requirements, sufficient support should be provided to the
individual undertaking the responsibility for the task, including training and any other
means that are necessary for its successful completion.
 Introduce reward mechanisms that would act as both the motivation towards the task
completion and evidence for the organisation's appreciation for the team member's
performance.
There are several motivational strategies that can be implemented at an organisational level.
The principle is that job performance is perceived as a function of ability and motivation. In
other words, a project's success depends directly on the performance of the workforce
assigned to it. Indirectly the project performance is dependent on both the skills and
motivation of each team member. Some strategies that can be adopted to increase
motivation may include:
 Reinforcement – by following a positive attitude the project manager could convey to
team members that his/her high expectations are analogous to their capabilities and
potential.
 Discipline – poor performance may be addressed with effective penalties that make it
clear that while current performance in unacceptable, it is still possible to establish a
smooth working relationship.
 Fairness – both rewards and punishments must be proportionate to performance and
follow a policy that ensures all team members are valued and treated equally.
 Goal setting – by setting clear goals it is possible to align the organisation's mission to
the vision of individuals, the scope of each role, project goals and departmental
objectives.
 Addressing needs – the needs of each individual must be assessed and an effort
should be made to ensure that team members feel valued and that their needs are
taken under consideration.
 Dynamic roles – each role should be dynamic to such an extent that it reduces
repetitive and mundane tasks, allowing team members some variety in their work
pattern.
 Align performance and reward mechanisms – each reward should be proportionate
to the performance as well as the difficulty of the specific role and associated project
tasks.
The theory of motivation proposed by Abraham Maslow is a long-standing model that has
been used since 1943. This theory views individual needs in a hierarchical fashion and
argues that unless more basic needs are satisfied, the higher level ones are difficult to
address. The theory (see Figure 5.1) introduces the following levels of individual needs:
© ABE
 Physiological needs – these needs are essential to sustain life, such as air, water,
food and sleep.
 Safety needs – these relate to the safety and security of the individual in order to avoid
threats to such things as job security, living environment, financial and medical stability.
 Social needs – these are higher needs that are associated with the social nature of
people, including friendship, love, belonging to a group/team/society.
 Esteem needs – these are needs that are associated with the importance of oneself
and can be identified as: (i) internal motivators including accomplishment and self-
respect, or (ii) external motivators including recognition, attention and social status.
 Self-actualisation needs – these needs, once satisfied, ensure that the individual's
potential has been reached and include motivators such as truth, justice, wisdom and
meaning.
Figure 5.1: Maslow's hierarchy of needs
Self-actualisation Ultimate
satisfaction
Esteem needs
Social needs
Safety and security needs
Physiological needs Basic need
© ABE
Think Point 7
Consider Maslow's theory and provide examples of how you would address the needs of
your team members, at all five levels.
You should structure your answer in such a way that each level is dealt with before the next
one. You should explain not only how you would meet the needs of the team members, but
also how you would assess whether certain needs are not satisfied.
Several methods were created by adapting Maslow's theory and restructuring its five-level
hierarchical model. Alderfer has proposed the ERG theory that is based on three levels of
need identified as:
 existence, including physiological and safety needs
 relatedness, including social and external esteem needs
 growth, including internal esteem and self-actualisation needs.
This approach groups together Maslow's levels while splitting the esteem needs into internal
and external ones. The principle is that the basic level of needs that relates to existence if
neglected will lead to failure, while there are needs that relate to the project and the scope of
a team member's role. Finally the needs associated with growth are the ones that, if
addressed fully, will dramatically increase performance.
Yet another approach is offered by McClelland, who has identified three needs as the core
of his theory. These needs are identified as:
 The need for achievement – this set of needs is focused on the challenging nature of
tasks that involves an element of reward by being allocated an interesting role.
 The need for power – this set of needs is geared towards the individual's tendency to
lead others and be assigned roles with additional responsibilities.
 The need for affiliation – this is perhaps the only set of needs that takes under
consideration the social belonging of an individual at the workplace, in the form of
friendships, relationships and cooperation.
Another approach is provided by Vroom, Porter and Lawler, and is called expectancy
theory or VIE theory. The three variables affecting individual motivation are identified as:
 Valence – this relates to the individual's belief that an expected outcome (personal
benefit) will result by achieving a task.
 Instrumentality – this is associated with the individual's needs to believe that the task
was achieved due to personal abilities and skills.
 Expectancy – this is focused on confidence that individual performance is up to the
allocated task.
An alternative approach is provided by Adam's equity theory on job motivation, where a
scale is used as the metaphor to balance the inputs and outputs as perceived by an
individual who is assigned to a specific job. The input represents:
time effort ability loyalty tolerance flexibility integrity commitment reliability sacrifices, etc.
The output represents:
salary bonuses benefits security recognition interest development reputation praise
responsibility enjoyment, etc.
© ABE
Hygiene Factors
We have discussed several theories that focus on identifying issues relating to the motivation
of individuals, thereby introducing strategies for increasing motivation and subsequently
performance. Frederick Herzberg introduced the concept of motivators and hygiene
factors in order to assess whether people are happy in their job.
This theory can be used by project managers and leaders in order to maximise the
motivation of their team members. It is based on the identification of the following factors:
 factors for satisfaction
 achievement
 recognition
 the work itself
 responsibility
 advancement
 growth
 factors for dissatisfaction
 company policies
 supervision
 relationship with supervisor and peers
 work conditions
 salary
 status
 security.
A very interesting argument made by Herzberg in his motivation-hygiene theory is that
satisfaction and dissatisfaction are not precisely opposite concepts. More specifically, he
realised that although dissatisfaction is the opposite of satisfaction, the opposite of
dissatisfaction is no dissatisfaction. In other words, if an individual is not dissatisfied it does
not necessarily mean that he or she is satisfied. So if our team members are not dissatisfied,
they are not necessary as high performing as they may be lacking motivation and
demonstrate indifference.
Following this approach two steps are identified as necessary to remove the "hygiene
factors". These are the factors that are causing dissatisfaction. This two-step approach may
be outlined as follows:
 Step one – get rid of hygiene factors and therefore any causes for job dissatisfaction:
 Fix poor and obstructive company policies.
 Provide effective, supportive and non-intrusive supervision.
 Create and support a culture of respect and dignity for all team members.
 Ensure that wages are competitive.
 Build job status by providing meaningful work for all positions.
 Provide job security.
© ABE
 Step two – create conditions for job satisfaction:

 Provide opportunities for achievement.
 Recognise workers' contributions.
 Create work that is rewarding and that matches the skills and abilities of the
worker.
 Give as much responsibility to each team member as possible.
 Provide opportunities to advance in the company through internal promotions.
 Offer training and development opportunities, so that people can pursue the
positions they want within the company.
Think Point 8
Identify the ways in which the working environment may affect project teams.
Hopefully in looking at the ways in which the working environment might affect teams, you
will have identified issues such as the effects on team morale, whether the team meets its
objectives, how team members collaborate and communicate, individual performance and
commitment, and relationships between members.
Influencing the Motivation of Team Members

In the previous section we discussed a number of methods and theories that focus on how to
increase the motivation of individuals within an organisation. A project manager must be
capable of assessing the motivation of each team member, and ensure that their
performance is not affected by failing to address their individual needs.
Team member motivation depends on understanding the factors that influence the well-being
of each individual at the workplace and their team membership. In order to influence team
member motivation and enhance the performance of the team as a whole, managers must
adopt one of the proposed theories to ensure that they are aware of any problems in their
teams.
The project leader should also be in control of a number of additional factors that may affect
the performance of the team and motivation of its members. The way communication takes
place in the team and between its members must eliminate frustration, reduce
misunderstanding and ensure that members are capable of performing their roles without any
obstacles. The team should also have clear rules and procedures regulating its operations
and be organised in an effective way.
Managing Team Communication
We have mentioned before that holding successful meetings is part of a strategy for
managing a project effectively. A meeting is an important event that may be used to address
specific issues or to bring everyone together in an effort to disseminate important decisions
or project information. The project manager should be in control of several issues relating to
project meetings, including:
 the frequency of team meetings
 meeting membership
 the preparation of the meeting agenda
 the coordination and facilitation of the meeting
© ABE
 the note keeping, preparation and distribution of minutes as well as the enforcement of
any actions.
Although meetings offer opportunities for communication, a project team engages in far more
communication exchanges during each work package. As part of their project tasks, team
members may be in continuous communication with others and some of this communication
may not even be formal.
The project manager must be aware of the communication needs within the team, and one of
the key aspects of communication is its timing. The primary reason for team communication
is to share information that is usually needed for project tasks, either as input or output. The
timing of such communication is critical: information must not be delayed in order to avoid
delaying any tasks. Sometimes when information is provided too early it may become dated
and irrelevant by the time it is needed.
The way communication takes place is also important as the project may impose certain
constraints. Typically a face-to-face communication should be preferred as the optimum
method to exchange information and ideas, clarify any pending issues and reach a common
agreement. The problem is that meeting at the same place and same time may not be
feasible due to the location, other work commitments and even time zone differences
between the team members. Video conferencing, phone calls and other synchronous tools
can be used to overcome the distance obstacle. However, the mannerisms and closeness of
a face-to-face meeting are lost during a phone call and video calls may introduce additional
overheads, complexity and lose focus. The exchange of emails, reports and workflow
messages, and the use of collaborative technologies for share editing of documents are
some methods that allow the asynchronous communication between team members. These
are ideal alternatives when time is an issue, but they have additional problems such as
versioning, maintaining control, obtaining sufficient detail and reaching an agreement in
reasonable time.
Communication may also be informal and sometimes such communication is invaluable for
the success of the project. However the main concern here is that such communication is not
documented and it is difficult to use for auditing, once a decision must be justified, and as the
basis for further actions. The lack of an etiquette means that informal communication may
lead to misunderstandings and possible conflicts.
Of course communication is not constrained to within the team. Project communication is
also taking place with other stakeholders such as project sponsors, and with other teams and
members of the organisation. Establishing a clear communication protocol means that the
project manager is aware of how communication is taking place, controls the information
being exchanged and understands any communication expectations with respect to the
project.
Team Operating Rules
Apart from the communication protocol and etiquette, there are several other project areas
that need rules and procedures to ensure a smooth operation. These areas are:
 Problem solving
Usually problems arise when the project plan fails to foresee an event or the initial
estimation is not followed with respect to work. The problems may be identified by the
project manager or be informed by team members. The problem-solving process
should not be the sole responsibility of the project manager but should involve team
members also.
© ABE
 Decision-making
The decisions that must be made for the project involve the project manager when they
are at a critical stage for the project success or when they affect specific team
members and their role. However, decision-making should be delegated when possible
to individuals, if such decisions do not require the involvement of other members.
 Cooperation
The cooperation and collaboration of the team members who are allocated roles that
are interrelated should be governed by clear communication protocols and procedures.
These must dictate how the exchange of information and control of the project tasks
should take place.
 Performance
Monitoring performance indicators and recording how the project performs against
certain standards should be the responsibilities of the project manager. However, it is
necessary for this information to be disseminated among team members who should
also be aware of the overall project performance as well as the progress of their
individual project responsibilities.
 Ethics
Everyone involved in the project should share the same ethical views, especially when
certain dilemmas may affect any compromises that must be made (e.g. quality) in order
to achieve project targets (e.g. deadlines).
 Trust
The lack of trust between project stakeholders cannot be tolerated as it seriously
damages the project's stability and the potential to reach its goals.
 Prioritisation
It is necessary to jointly reach any decisions affecting the prioritisation of project
requirements and individual needs. This process affects not only the project
performance but also hygiene factors we have previously identified.
Organising the Project Team
The project manager must demonstrate his or her leadership skills when organising the
project team. It is necessary to demonstrate certain qualities that support the effective
management of the project resources. Such leadership skills are necessary for the project's
success and the well-being of the project team.
Some examples of the qualities a project manager must demonstrate include the ability to
do the following:
 Maintain stability – this means the project manager's ability to control any crisis,
maintain certain performance standards and deal with problems.
 Be creative and innovative – this is relevant to certain projects that require a forward-
thinking approach in problem solving and using the available resources.
 Get involved – this means the project manager's involvement with more basic tasks
and daily responsibilities (without losing power distance with any subordinates).
 Lead the way – this relates to the fact that a project manager should be able to
foresee the direction of the project and look ahead to the sector for any directions set
by the industry. Sharing these ideas with the team is likely to strengthen the respect
and trust of team members for the project manager's decision-making abilities.
© ABE
 Encourage team members – this is relevant to the measures taken to ensure that
team members remain motivated and committed to their tasks. The project manager
may follow a different strategy depending on priorities, individuals and project phase.
 Support the team – this emphasises the value of the team and includes any steps
required to ensure that all team members collaborate and communicate effectively,
while remaining focused on the common goal.
 Solve problems – this means the ability to solve problems, avoid critical situations and
ensure that a fair and ethical approach is used to deal with any project problems.
 Show flexibility – this allows the project manager to be firm on decisions while
considering alternative approaches and allowing team members to take initiatives and
work individually on delegated tasks.
 Deal with loyalty – this relates to both the ability to appreciate the loyalty of team
members but also to share the team identity and be supportive of the team and its
members when decisions are made at an organisational level.
The project manager should also possess certain skills and values, including:
 holistic approach – viewing the project as a whole
 integrity – managing others in the same way they manage themselves
 proactive behaviour – dealing with any issues before they lead to a crisis
 stress tolerant – coping with stress and deal with crisis
 business oriented – understanding the organisation's perspective on issues
 communication skills – being able to communicate with clarity and firmness
 time management – controlling time in both personal life and project role
 political acumen – balancing different personalities, goals, agendas and priorities
 optimism – showing a positive attitude and sharing it with others.
Review Questions 2
(a) How would you define the concepts of management and leadership?
(b) List five key leadership aspects or groupings to which the skills of a project leader may
relate.
(c) What are the main theories associated with motivational factors?
(d) What are the two steps proposed by Herzberg's motivational approach?
(e) What are the drawbacks of informal communication in a project?
© ABE
SUMMARY
This chapter consisted of two main parts, focusing on management and then leadership of a
project team. In the first part of the chapter we discussed team structures and criteria for
assigning team roles. The team formation and role allocation discussion focused on team
organisation and management responsibilities. The section also described reward
mechanisms and procedure followed when staffing and recruitment decisions are made. We
continued with more discussion on managing people and different management styles. The
sections dedicated to leadership discussed the necessary skills of a successful leader and
various leadership styles, and emphasised motivational and hygiene factors. Following the
introduction of several motivational theories, we described communication and operational
techniques as well as organisational issues relating to the qualities necessary for a leader.
© ABE

Review Questions 1
(a) Teams must be structured in a way that ensures: achieving the project objectives;
working efficiently towards the project deliverables; dealing with any project tasks and
team-related problems; communicating effectively; performing according to the project
plan; engaging in decision-making and problem solving; supporting the project stages
and allocated activities.
(b) Five examples of functional specialisms are: research and development, sales,
marketing, engineering, human resources.
(c) The main characteristics are: the benefit of creating a pool of skills and expertise by
grouping together team members; the ability to engage all team members in decision-
making and problem solving; the involvement of team members in operations by
sharing their different perspectives and capabilities; the alignment of skills and
capabilities of team members to meet the needs of project tasks; the harmonisation of
team operations and activities; the improvement of team effectiveness and exploitation
of team member capabilities; the reaction to identified risks and performance obstacles;
the development of an environment-fostering commitment and motivation among team
members.
(d) You could have cited either the Tuckman model (forming, storming, norming,
performing and adjourning) or the "typical" model (formation, allocation, harmonisation,
cooperation/collaboration, phasing out, termination). There is of course much overlap
between them.
(e) The team must succeed at: holding successful and productive project meetings;
establishing a team culture that is shared between members; identifying a common
goal and shared mission; introducing reward mechanisms and performance rewards;
supporting decision-making and problem solving; dealing with differences and conflicts;
motivating team members.
(f) Divisional/projectised: self-contained and the most simple method to use; good team
identity.
Functional: good for keeping together personnel according to their expertise; cost-
effective; team cohesive and good alignment with corporate goals.
Matrix: maximum flexibility; good skill availability; team members focused and have a
clear role identity; copes well with change and supports multitasking by project
managers.
Review Questions 2
(a) The answer given in the text is:
Management is the application of authority over team members, according to a
structure imposed by the organisation.
Leadership is the ability to drive others towards the leader's vision. This could be in the
form of persuading team members to perform certain tasks, succeeding to align
individual goals with the leader's scope, establishing a certain attitude towards work,
motivating members, increasing commitment, etc.
You may think of other responses to this question.
(b) The five aspects are: the project task, the project manager role, character,
relationships, personality.
© ABE
(c) Those of Frederick Taylor and Abraham Maslow.

(d) Step one – get rid of hygiene factors and any causes for job dissatisfaction.
Step two – create conditions for job satisfaction.
(e) Such communication is not documented and it is difficult to use for auditing, once a
decision must be justified, and as the basis for further actions. The lack of an etiquette
means that informal communication may lead to misunderstandings and possible
conflicts.
© ABE
131
Chapter 6
Managing Quality and Change
Contents Page
Introduction 132
A. Understanding Project Quality 132

Defining Quality – Product, Consumer, Manufacturing Specification and Value 133
Techniques for Assessing and Maintaining Quality Requirements 138
Assessing and Managing Quality – Software Products 139
B. Dealing with Change 143

Distinguishing between Internal and External Changes 143
Implementing a Formal Change Control Procedure 146
C. Configuration Control 151

Configuration Control Procedures 151
Summary 153
© ABE
132 Managing Quality and Change
INTRODUCTION
Once a project is structured according to a well-documented work plan and the project
resources are allocated, it is necessary for the project manager to control the production of
the deliverables. The project is expected to follow a life cycle that includes a number of
stages, and during this life cycle the project manager must cope with two main
considerations. Initially, the project manager must monitor and maintain an acceptable level
of quality. In this chapter we will define the concept of quality and discuss in detail how
quality can be assessed and maintained. The second concern is how the project manager
copes with changes introduced at various stages of the project life cycle.
Objectives
 explain the term "quality" viewed from perspectives such as the product, the consumer,
the manufacturing specification and value
 describe standard techniques for assessing and maintaining quality requirements
 explain how the quality of software products may be assessed and managed
 using examples, distinguish between internal and external changes
 discuss the importance of implementing a formal change control procedure and
describe its constituent elements
 explain the steps in a typical configuration control procedure.
A. UNDERSTANDING PROJECT QUALITY

In order to understand the concept of quality we must understand that discussing quality
depends on the perspective of how it is defined, measured and managed. For example, the
quality considerations when designing a computer system are different from the quality
issues relating to the construction of a building. It is therefore impossible to discuss quality in
such a manner that will cover all types of potential project.
There are also several perspectives for determining how quality can be managed. Project
management quality can be viewed from a number of viewpoints:
 Mathematical
The mathematical approach is focused on assessing whether the project deliverables
adhere to a given specification. This approach is more suitable for projects that include
deliverables that are in the form of products and processes as they can be described
based on mathematical and statistical formulas.
 Structural
This approach is focused on the project conforming to procedures. This perspective is
used for the establishment of quality assurance through a quality management
standard provided by the ISO (International Organization for Standardization). A project
of high quality conforms to the hierarchical production of certain procedural
documents.
 Organisational
The organisational approach describes the way most organisations view quality as it
emphasises the importance of meeting customer and stakeholder requirements. This
perspective requires constant communication with project stakeholders as they provide
the necessary input used for assessing project quality.
© ABE
Managing Quality and Change 133
 Economic
This approach takes under consideration the cost of achieving the required quality. The
focus is on assessing the perceived value of the achieved quality as well as the
awareness of any costs associated with project failure.
 Strategic
The strategic approach is followed by organisations that aim for niche markets (e.g.
luxurious products, high-end technological products) or the ones with quality being an
integral part of their mission. In such cases cost and procedures are irrelevant as the
aim of the organisation is to be perceived as one that guarantees projects with quality
in their core.
Defining Quality – Product, Consumer, Manufacturing Specification and Value

It could be argued that quality may have different meanings to organisations, stakeholders
and project managers according to their respective mission, goals and objectives. For
example, a manufacturing organisation is bound to focus on product specification, while a
project that supports a service is more likely to consider the level of support as a more
suitable quality measure. A consumer-centred approach is likely to consider value for money
as an indication for quality.
There are quite a few proposed models that attempt to determine quality by using a number
of dimensions. These efforts aim at facilitating the management of quality and the
assessment of project deliverables in terms of such quality measures.
A customer-centred definition of quality management could be based on the following eight
dimensions:
 performance – assessing whether the project produces a product or a service that
performs according to certain specifications
 features – assessing whether the deliverables that may be in the form of specific
products include the required features
 reliability – assessing the project deliverables with respect to consistently meeting the
requirements and not demonstrating a higher than acceptable failure rate
 conformance – assessing whether the project deliverable conforms to the given
specification
 durability – assessing the duration the project deliverables will last performing
according to the specification following their deployment
 serviceability – assessing whether the project deliverables are easy to maintain
 aesthetics – assessing aspects of the project deliverables relating to the way they look
to their end-users
 perception – assessing how the project deliverables are perceived by the project
stakeholders.
Think Point 1
Using a project of your choice (real or hypothetical), consider how these different dimensions
of customer-centred quality management can be applied in assessing the quality of its
project management.
© ABE
The different dimensions provide a useful means to estimate a project's management quality.
Depending on the project's scope, different dimensions can be used to establish an
understanding of the main strengths and weakness of the project management approach
followed.
Such approaches to defining quality can be used by project managers to measure quality
when the project deliverables are produced. However it is necessary to have a clear
understanding of quality during the project life cycle and before the deployment of the
project's deliverables. Quality is a very important concept as it offers a reality check for
project managers and team members.
Project managers should always reflect on how their quality objectives are realised at
different project stages. There are several reasons for this. Quality is important for the
success of most projects as it determines whether the project deliverables will meet the
requirements of end-users. Quality is also an indicator of an organisation's strategy to be
associated with high-quality services. Quality may also be used as an indicator for the
project's success, and the performance of individual team members.
Quality can be assessed from a couple of perspectives:
 quality of design – focusing on the stakeholders whose requirements are used for the
specification of the project deliverables
 quality of conformance – focusing on the project management and whether the
project deliverables are developed according to the design.
Quality should also be considered in terms of any associated costs. Such costs may be
summarised as:
 costs associated with quality control, including any measures that must be taken in
order to achieve the quality standards identified for the project deliverables and any
associated processes
 costs associated with the failure of the project when quality is not controlled, which
may include the costs associated with the delivery of products or services that do not
meet quality standards.
Defining Quality
So far we have visited a number of perspectives concerning how quality can be managed.
But how is quality defined? Quality is a concept that can be associated with the satisfaction
of certain needs. For example, a high-quality system must satisfy certain requirements. The
main issue is how to determine which requirements dictate whether the project has produced
deliverables of high or low quality.
We could identify three primary perspectives that provide requirements that can be used as
quality criteria. These perspectives are:
 internal organisation stakeholders
 external stakeholders
 quality assurance associations.
By focusing on internal and external stakeholders we can prioritise requirements that are
concerned with either internal quality issues or external aspects of the project. Quality
assurance associations offer another perspective that can be used to identify requirements
from a more objective point of view.
The internal organisation stakeholders include those who are involved with the
management and running of the project. The aim is to identify issues relating to these
stakeholders as their perception of the project deliverables is important in terms of assessing
the quality of the project. Some examples may include internal procedures that must be
© ABE
followed in order to produce deliverables, perform project activities and deal with project
actions. Another example of internal quality mechanisms may include monitoring how the
project may improve an operation's effectiveness and whether any errors are introduced to
specific operations as part of the project deployment.
Quality may also be viewed with respect to whether the project deliverables are 'fit for
purpose', meaning that they may address requirements that are different from the ones that
are identified by the stakeholders. Sometimes the project deliverables may involve
procedures that are too complex or have associated costs that are unreasonable for what
was expected. Alternatively the project outcomes may not have the technical quality required
or level of detail needed.
The external stakeholders may belong to other organisational divisions, as in the case of
affiliated projects or supervising departments. Their managers may monitor the project
outputs and assess them in a way that depends on their expectations. Being able to cope
with the expectations of external stakeholders is a major concern for project managers as
their perceived quality of the project may depend on false expectations. The perceived
quality of the project deliverables may also be affected by the views of external stakeholders
on the costs incurred.
It becomes obvious that there is the need for an impartial third party that operates
independently in order to establish whether the project's activities and outputs satisfy certain
quality criteria. Such third parties are usually in the form of associations (that may be
international or local) that focus on establishing certain standards against which the quality of
projects can be evaluated. These standards are quite often specific to industry sectors and
may only be used for project of certain types.
The involvement of an independent quality assurance party means that the project
elements are assessed against objective criteria. The principle is that certain standards are
used to examine the project deliverables as well as any processes, operations and activities
that have taken place while these deliverables were produced. Sometimes projects, by
achieving such quality standards, are able to influence the subjective views of stakeholders.
It should be clear that the satisfaction of the project stakeholders is perhaps the most
important aim of the project. The satisfaction of any stakeholder could be viewed as the
difference between any expectations for its performance and the perceived value of the
project. A project is considered to be successful if it manages to maintain relatively high
levels of satisfaction among its stakeholders. This is a more subjective aspect of quality
management. Furthermore, an increase in the stakeholder satisfaction means that the
project manager has succeeded in achieving an increase between their project value
perception and their expectations. This can be achieved in a number of ways, the following
included:
 Ensure that the stakeholder needs are accurately identified and described.
 Check whether the identified requirements have been satisfied.
 Assess whether the manager's perception of the requirements is different in
comparison to the actual requirements.
 Ensure that the formal project specification accurately reflects the project manager's
perceived requirements.
 Align the produced deliverables to the actual requirements they are supposed to
address.
 Avoid misleading project stakeholders to expectations that are unlikely to be satisfied.
 Reduce the differences between the quality of the project outputs and their perceived
value that stakeholders may have been led to expect.
© ABE
Performance Criteria
Following the definition of the quality concept, it is necessary to consider how quality relates
to project performance. There are two concepts we should take under consideration,
including quality performance and quality conformance. The main difference is in the way
these concepts affect the project life cycle. More specifically:
 The project's quality conformance indicates whether certain quality criteria are
addressed in order to produce project outputs of successful quality.
 The project's quality performance indicates whether the effort required to achieve
certain quality criteria affects certain performance indicators.
The project manager must ensure that the project processes are planned in such a way that
certain project quality objectives are achieved. The issues that should be taken under
consideration include:
 Organisational strategy
The organisation's mission is likely to affect how the project quality aims are achieved.
The strategic planning of the organisation's structure and resources affects the
perceived quality standards for its projects. For example, the quality of the project
could be dependent on the availability of resources and the procedures followed
throughout the project life cycle.
 Stakeholder requirements
The needs of those who are actively involved in the project should be taken under
consideration as they are likely to affect the way they participate in the project
activities. In addition end-users and customers have certain requirements that must be
met by the project outcomes.
 Project outputs
The project deliverables have a perceived quality relating to the expectations and
perceptions of the end-users. In those cases where the project deliverables are in the
form of products, certain characteristics are used to measure the quality of the
delivered product. Similarly services are evaluated against certain features that are
associated with high levels of quality.
 Conformance criteria
There are several criteria demonstrating that the project conforms to certain quality
measures that are imposed by the organisation or external stakeholders and
independent parties.
 Performance criteria
There are also certain criteria used to assess whether the project's performance
adheres to specific acceptable standards.
Measuring Progress
Establishing an understanding of how to measure the progress of a project with respect to
quality is very important. The project manager must be able to determine certain standards
against which the project's progress can be evaluated. These standards should be widely
accepted and therefore formed in a way that they are:
 Realistic – the identified quality standards should be realistic to achieve without
exceeding the project's resources.
 Reliable – any quality standards should be consistent in providing an accurate
reflection of progress for different projects and their stages.
© ABE
 Valid – in order for the quality standards to be acceptable they must be justified by
scientific or similar means.
 Clear – the quality standards must be easy to understand by everyone who is involved
in the production of the project deliverables or their use.
 Measurable – similar to the project's objectives, acceptable standards must be
quantifiable to facilitate the project manager when assessing the project's progress.
The development of quality standards is based on a step-by-step iterative process. These
steps include:
 defining the quality standards
 agreeing the quality standards with the project stakeholders
 identifying stakeholders who should be involved with the determination of these
standards
 collecting information required to define the standards
 testing the standards
 communicating the standards.
Following this process, a number of steps can be identified to assist project managers in
quality design. Such steps may include:
 identifying the project deliverable that must be designed
 defining the objectives for the project deliverable
 determining those stakeholders who are affected by the project deliverable
 gathering the project requirements and stakeholder needs
 prioritising the identified requirements
 associating project activities to the project requirements
 linking project deliverable features to each project activity
 introducing the new process in the project
 testing the process against identified standards
 deploying and monitoring the new process.
Think Point 2
How can project managers plan and design for project quality?
When the focus is on establishing a project plan of high quality, project managers must
ensure that a series of steps is followed to address the quality requirements identified. The
design of a project management approach should focus on both supporting the project plan
and schedule as well as ensuring that project support is in line with the identified
requirements.
These steps ensure that the project quality control is such that any new process is
thoroughly checked against quality criteria and is sufficiently planned to reduce the possibility
of failure.
© ABE
Techniques for Assessing and Maintaining Quality Requirements

There are specific areas of the APM and the PMI body of knowledge relating to the
management of quality. More specifically, the relevant areas are as follows.
 Section 24 of the Association for Project Management (APM) body of knowledge,
("Quality management") outlines the basics of quality planning and control.
 Section 8.1 of the Project Management Institute (PMI) Project Management Body of
Knowledge (PMBOK) ("Project quality management – quality planning") discusses
several issues including the role of the organisational quality policy, conformance to
requirements, the role of prevention versus inspection, etc.
 Section 8.2 of the PMI Project Management Body of Knowledge ("Project quality
management – quality assurance") focuses on quality planning and audit.
Quality Requirements Defined
Depending on the nature of the project, several quality factors and criteria can be identified.
These may be used as guidelines for defining qualities and assessing the project's quality
performance. The following list is indicative:
 Accessibility – this relates to the accessibility of information to project stakeholders. It
may include (i) penetration to user groups and communities, and (ii) transparency of
the project outputs without the need for the intended users to possess special skills
and capabilities.
 Correctness – determines whether the project specification is in line with the project
requirements. It may include (i) completeness in terms of deploying all required
functions, (ii) consistency of project output between all deliverables and (iii) accuracy of
project outputs according to precise requirements.
 Effectiveness – means using resources in an optimum way.
 Efficiency – meeting the requirements with an optimum use of available resources.
 Expandability – means supporting the scalability of the project to deal with an
additional volume of information, activities and tasks. It may include (i) augmentation of
project functions and information, (ii) modularity of project components and (iii)
simplicity of project deliverables.
 Feasibility – means offering the expected outcomes within the estimated financial
budget.
 Integrity – granting access to project resources and tasks only to authorised
stakeholders. It may include (i) security mechanisms for accessing project resources
and (ii) auditability of actions including modifications.
 Interoperability – exchanging information and resources with other projects. It may
include (i) commonality of tasks and outputs between projects and (ii) independence of
the project deliverables from the environment.
 Maintainability – allowing the maintenance of the project systems and outputs after
their deployment. It may include (i) conciseness of project functions, (ii) consistency of
project deliverables, (iii) modularity of project outputs and (iv) simplicity of project
functions.
 Portability – supporting the deployment of project deliverables to other environments.
It may include (i) independence of the project deliverables from the environment, (ii)
modularity of project outputs and (iii) standardisation of project processes.
 Potential – extending the organisation's scope and provision.
 Presentation – meeting the aesthetic requirements of stakeholders and end-users.
© ABE
 Profitability – increasing the productivity and performance of the organisation with the
use of the project deliverables. It may include (i) productivity of stakeholders, (ii)
affordability of project operations and (iii) the cost-benefit balance/ratio.
 Reliability – coping with a variety of situations and conditions during the project life
cycle. It may include (i) recovery from irregularities and (ii) accuracy of project output.
 Reusability – sharing project tasks, outputs, processes, procedures and deliverables.
 Timeliness – adhering to the estimated time frame.
 Usability – offering usable and understandable project outputs to end-users and
stakeholders.
Assessing Quality
Apart from the perceived value of deliverables, the quality of a project may be assessed in
terms of the evaluation of its performance. Project stakeholders may consider several
aspects that can be used as a measurement for quality. For example, the project may be
assessed in terms of its progress and costs with respect to its original plan. The fact that
some projects may exceed the original budget and time frame may be perceived as a sign of
not meeting quality standards.
A control process may be introduced in order to assess the quality of a project. This
process may involve the following steps:
 Creating a baseline plan – this is used to establish the original targets of the project
and monitor whether the project progress fails to meet any of them. If any deviation
from the initial plan is monitored, the effects of these changes on the project quality
must be estimated.
 Measuring the progress and performance of the project – meaning that the project
life cycle is monitored to ensure that the project progress is recorded and any
performance issues are identified and addressed.
 Comparing planned and actual progress – the project actual progress should be
used to assess whether the stakeholder expectations are likely to be satisfied or the
project will be perceived as a possible failure.
 Deciding corrective action – this step involves a reaction from the project manager to
ensure that the project can be realigned to meet the expectations of its stakeholders.
Assessing and Managing Quality – Software Products

The management of quality takes another turn when a project involves the use of computer
technology. In such cases the project manager must be capable of controlling quality issues
relating to the use of the technology as well as any software products that may be delivered
during the project life cycle. The effective use of the technology is critical for the success of
projects that are dependent on it for the facilitation or even the completion of specific tasks.
Technology may be part of the communication and information exchange taking place during
the project or be integrated in the development activities of certain project roles. Any failures
in the first scenario are likely to affect the effectiveness of collaboration between team
members and may lead, indirectly, to a performance decrease. In projects where technology
is integrated in project roles and tasks, the effects of any technological problems may lead to
the cancellation of project activities, significant delays and even failure.
Quality concerns are therefore associated with the way technology is used and whether
there are any mechanisms in place ensuring that technology is a driver for project
performance rather than an obstacle to progress. Quality assurance mechanisms may
include organisation policies for the proper use of technology, and procedures and guidelines
© ABE
that aim for the education and training of individuals as well as rules that should be applied in
project settings, by team members and in management practices.
There is a more intense use of technology in those projects that include the development of
software as part of their objectives. Here the entire project deliverables may take the form of
software applications. There is a dedicated specialism focusing on software quality and the
criteria used for measuring the success of organisations in developing high-quality software.
Software Quality Explained
Software quality can be evaluated in a number of ways including more formal approaches
using measurable criteria. These criteria can be used to assess the quality levels of software
products, and may be based on more objective data collection methods that monitor
performance indicators of the software applications.
As software quality relates to the experience of its intended end-users, it may also be
evaluated in a more subjective way by using surveys and observation techniques in order to
gather subjective data relating to the users' perspectives in terms of their experiences and
expectations.
Some of the criteria relating to the evaluation of software quality can be identified as:
 Requirements conformance – associated with the user and stakeholder
requirements with respect to the purpose of the software.
 Specification conformance – relates to the software functionality which must be in
line with the specification created from the requirements gathered and dictates the
functions that are necessary for the project to achieve its intended scope.
 Reliability – addresses any issues relevant to any problems arising when using the
software, and the performance of the software in different environments and scenarios.
 Scalability – indicates whether the software application can be extended to more
users, computers, locations and other departments. The concept relates to the ability
of the software to serve additional users and withstand further exploitation of its offered
functionality.
 Completeness – this reflects on the extent of functionality supported by the software
by assessing its initial scope as dictated by the identified requirements.
 Stability – provides an estimation of the software limitations and a benchmark to use
for establishing the borderline between failing and performing software.
 Fault tolerance – indicates software that allows a degree of failure by partially
reducing functionality rather than collapsing completely.
 Documentation – provides an overview of any supporting documentation that can be
intended either for end-users (e.g. how to use the software) or developers (e.g. how to
enhance or fix the software).
 Extensibility – allows any future expansion and the development of additional
software features.
 Maintainability – relates to the ability to maintain the software and ensure that
troubleshooting is feasible without any unrealistic associated costs.
 Usability – assesses the end-users' perception of the software in terms of ease of
use, look, feel and other similar non-functional requirements.
Why Systems Fail
There are several statistics that claim significant failure rates among software systems, and
there are estimates that as much as 50 per cent of software systems fail for a variety of
reasons. We must put these estimations in perspective though, as a system failure may not
© ABE
necessarily be catastrophic. Obviously a safety-critical system should be robust, as its failure

may lead to unthinkable situations as in hospital, airline and railway systems. However
software failure may also be associated with the ability to support only certain limited
functionalities, the delivery of a portion of software that does not meet all requirements, or
overruns in the estimated time and budgeted costs.
It is important to identify the real causes of system failure in order to attempt to shift the
scope of project management and introduce practices that are more suitable for the
development of software deliverables. A possible cause of failure is not necessarily
associated with a specific type of failure.
Some possible reasons for the failure of software projects, and subsequently the developed
software products, can be identified as:
 Development practice
It is not unusual for software to be developed in unstructured or ad hoc ways that are
likely to be prone to errors. Lacking a proper quality assurance procedure that spans
across several stages of the project life cycle is likely to lead to project failure. By not
ensuring the project deliverables and working practices are subject to quality
evaluation, a project manager fails to address any problems associated with the way
software is developed by the project team.
 Incorrect assumptions
Typically, user requirements and software specification information are gathered during
early stages of the project life cycle. When the project manager fails to revisit these
requirements regularly, it is quite possible for the final software to be deployed in a
changed setting. Quite often, project managers make certain assumptions when
interpreting user requirements. This practice is likely to lead the project in a different
path and result in software that is based on inaccurate requirements.
 User experience
The quality of software applications is subject to user evaluation that is not always
focused on the functionality provided. It may be the case that software fails to engage
its users by introducing an interface that is difficult to use and frustrating to the end-
user. User experience in a number of function and usability scenarios should be
monitored, as it may trigger a subjective perception of the software. This may lead to
disappointment, failure to persuade users to use the system and therefore the eventual
failure of the project.
 Hardware
Sometimes software is deployed in systems that are not capable of offering a
supporting environment for its smooth operation. The lack of suitable hardware or any
possible faults with the hardware infrastructure may be some of the reasons for
software failure.
 Software
Software does not exist in isolation: it resides on operating systems and in system
tools and usually interacts with other software applications. Software failure may be
caused by errors in the integration of several software deliverables, or even due to the
failure of entirely different software applications.
 User support
The quality of software is also related to the support received by users, including any
documentation, training for the use of the software functions and guidelines for
avoiding user errors.
© ABE
 Deployment
The deployment and the installation of software is also another aspect associated with
quality, especially since systems must fit with the organisation's need for software
applications.
Think Point 3
What are the main causes for software project failure likely to be?
Software projects fail for several reasons but the primary causes relate to the lack of
available resources and errors in estimating the project requirements, as well as issues
relating to effectiveness of processes and efficient use of resources.
The possible causes of system failure we have identified should be considered as the main
reasons for classifying a system or software application as a low-quality one. These are
failures that are caused either by poor project management, user-related issues and
infrastructure aspects. It is therefore necessary to manage software projects in such a way
that different causes of failure are taken under consideration. Project managers should
ensure that the likelihood of these causes of failure being present is minimised.
Managing Software Projects
The management of software projects needs to focus on classifying the failure causes and
address related issues accordingly. The project manager should be able to deal with the
software development life cycle and ensure that each stage is supported according to its
needs.
Software development is a process that has clear stages based on different activities.
Initially, a software project is based on a feasibility study that aims at identifying whether
there are any project aspects that may affect its chances of being implemented. Early stages
of the software development process include the requirements capture that involves the
potential end-users of the software as well as various other stakeholders. The project then
moves on to two stages that are closely related and focus on the analysis of the main
software components in line with the identified requirements and a more specific design of
the required software functions. Based on the design of the software system the team then
moves to the development or implementation of the actual software. The implemented
system is then tested to ensure that the required functions perform as expected. The
evaluation of the deployed software based on the initial requirements follows, in order to
assess whether the end product corresponds to its user needs.
Some of the main causes of failure can be identified as reasons for triggering project
management actions. We could identify possible project management areas of concern in
software-related projects and classify them according to:
 poor development practices
 end-user problems
 development errors.
With respect to poor processes and practices, a project manager must be aware that team
members involved with the development of software may be the main reason for failure. For
example, the testing of software may be inadequate, especially when key functions are not
tested against the requirements of the end-users. The development of software may also fail
by lack of supporting documentation as the project team may focus primarily on the
development of the software functions and neglect the provision of supporting manuals.
© ABE
As far as the end-users are concerned, the project manager should take under consideration
the fact that their perception of the software under development may be misinterpreted and
the entire process may be based on wrong assumptions. It is necessary for both end-users
and the software developing team to have a common understanding of the system
requirements and the main design aspects. Eventually users may not accept and support the
use of the new system, leading to a complete failure. The deployment of software should be
supported by training activities and detailed guidelines.
Finally, the actual development process may cause problems that may relate to the software
being developed, any applications that may be needed, the operating system and other
system tools that should be integrated, and any hardware infrastructure.
So far we have discussed the concept of quality and examined why systems may fail and the
effect of a low-quality project. Sometimes the lack of quality may relate to the fact that the
project fails to deal with changing needs and the evolution of its environment.
Review Questions 1
(a) List the five main perspectives for determining project management quality.
(b) Which criteria would you use to define project management quality?
(c) What is the role of an independent quality assurance party in establishing the quality of
a project?
(d) What are the six steps involved in the development of quality standards?
(e) Suggest three general instances of non-catastrophic software system failure.
B. DEALING WITH CHANGE

Most projects face continuous changes throughout their development stages. It is quite likely,
even with shorter projects, for the requirements to change: their stakeholders come up with
additional needs and the immediate environment may be altered. Common changes may
also include organisational changes, staffing, project scope and the availability of resources.
Distinguishing between Internal and External Changes

The project manager must be capable of identifying the main aspects of project change and
manage the changes taking place. Changes may be internal to the project, or be part of a
wider change taking place at the project's environment.
The project manager's concerns could focus on a number of issues, such as:
 the tools and skills required for managing change
 the processes followed when change takes place
 the underlying principles for change at an organisational level
 the human aspects relating to project changes
 the effects of change on project initiatives and scope.
The main interest of the project manager should be to identify whether any changes are
within the project's scope or are external to the core of the project, and therefore to be
© ABE
ignored or dealt with as issues of lower priority. In order to deal with change, the project
manager must ensure that appropriate project aspects are organised in such a way that they
can cope with the new situation. For example, the project will be based on clearly divided
tasks and a well-defined allocation of roles and responsibilities. Any relationships between
existing procedures, techniques and approaches and any proposed changes should be
clearly stated and described in detail. Furthermore any required skills, resources and support
should be identified and determined in association with project tasks.
The management of change relates to the overall management of the project. It should take
place by means of a parallel set of steps including:
 the recognition that change is needed
 the design of a possible solution
 the implementation of the proposed design
 the realisation of the benefits from the implemented solution
 the reflection of how change affects the project's output.
The need for change can be identified by listening to input from the project's stakeholders.
Change may also be triggered by external events, such as new entrants in a market,
competitors introducing new products, financial aspects of the organisation, the need to
react to certain performance indicators, a strategic plan for shifting focus, etc.
The design of a solution should be based on the introduction of new project structures, a
revised view of how technology is used, introduction of new services and products, redesign
of existing processes, etc.
The implementation of a solution for change should be based on the introduction of pilot
studies that focus on investigating how change affects certain aspects of the project, the
introduction of new processes, restructure of the organisation and the project resources,
deployment of new systems, etc.
Scope for Change
It is very important to have a clear scope for change in any project. The scope for change
can be viewed as an exercise to assess the readiness of the project manager to cope with
any changes introduced during the project life cycle.
The changes introduced in a project can be classified according to what is changed or who
is involved.
 "What" changes:
– What is the scope for change, meaning the reasons why this change is important
for the organisation in general or the project in particular?
– What is the extent of the change, meaning the effort and additional resources
required for implementing the change (and this is largely determined by the
underlying reason for it)?
– What is the complexity of change, meaning any additional skills and expertise
required for its implementation?
 "Who" changes:
– Who are the people involved, meaning the number of people, their roles in the
project and their agenda for change?
– Who are the people resisting changes, meaning the different obstacles for change
both at individual and organisation levels?
© ABE
Think Point 4
In what ways is the "what" and "who" classification of project change useful to project
managers?
Such a classification aims at providing a clear understanding of what needs to be changed

(i.e. the requirements) and at identifying those stakeholders who are involved with these
changes (i.e. responsibilities).
The project manager must be able to merge these "what" and "who" changes in order to
establish a balance between the scope for change and the way it can be implemented. At
this stage it is essential to identify the real drivers behind any changes. Some of the key
drivers for change might be:
 Changing organisational needs – the organisation's mission and strategy are changing
and therefore they may lead the project in a different direction.
 Changing organisational structure – the organisation may change following a merger,
an acquisition or other events at an organisational level, leading to restructuring of
project resources and management.
 Changing technology – the evolution of technology may offer more choices for
supporting tools and processes that could be introduced at later stages of the project.
 Changing priorities – the priorities of the organisation, stakeholders, project manager,
team members and users may change, therefore requiring a revised project scope.
 Changing relationships – new partners, competitors, suppliers, customers and
intermediaries may affect the way the project is managed.
 Changing politics – the project may be subject to new legislation, governmental
influence, political and social changes.
 Changing environment – the global nature of a project may change the locations
involved, resource availability and operations.
 Changing projects – the project objectives and associated initiatives are changed.
 Changing to address failure – user errors, project problems and mistakes from the
team members and the project manager make it necessary to change the project's
current structure, resources, plan and development.
Managing Change
The change management process consists of two main steps, namely:
 a project change request
 a project impact statement.
The project change request provides the formal documentation of any changes requested
for the project. Such documentation can be used while auditing changes and the effects to
the project performance and outcome. The project impact statement, on the other hand,
identifies possible alternative routes for the project and the associated impact of each option.
The project manager may choose to proceed with one of the identified options after
consulting the possible outcomes of this decision.
When the project manager is persuaded that a change is preferred from the current pathway
of the project, a project change request must be initiated. There are a number of
considerations relating to a project change request. These may include whether:
© ABE
 the change may be implemented within the current time frame

 the change is feasible with the existing project resources
 the change will affect the project schedule
 the change will require additional resources
 the change will need the prioritisation of the project deliverables and their deployment
schedule
 the change will lead to significant shift of project scope
 the change effects will span outside the project's boundaries.
The process followed for project changes is structured in a number of steps including:
 A change request is submitted following the identification of additional needs or the
occurrence of a specific event.
 The change request is reviewed and depending on its feasibility the project manager
may be (i) allowed to proceed, (ii) prompted to further review the change request or (iii)
denied any changes.
 The change request may be reviewed and resubmitted depending on the comments
received by the project manager.
 An impact study should take place in order to assess the effects of any implemented
changes to the immediate environment of the project, the project stakeholders and the
organisation as a whole.
 The impact study offers a second opportunity for iteration as it also allows the project
manager to rework and resubmit the study depending on the views of the
stakeholders.
 Once the change is approved, the implementation plan is deployed and the change
begins from the planning stage to its realisation.
These steps are quite formal in the sense that the project manager must submit proper
documentation with full justification for the requested changes. Such documentation is likely
to include information relating to the project, the specific activities and tasks that may be
affected by the proposed change, and any resources that are also involved. The owner of
the change request is specified as well as the date of the request. The justification for the
requested change should include evidence of support relating to the impact of the change to
the project performance as well as the benefits for the entire organisation and any positive
impact on stakeholders. Finally the project manager must identify any immediate actions that
are associated with the change, and a possible plan for the implementation of such actions
following a possible approval for this change.
Implementing a Formal Change Control Procedure

In order to introduce a change control management process, the project manager must be
capable of identifying the real drivers for project change, which we have already mentioned.
There are typically three main reasons for change, namely:
 the introduction of major changes due to a number of reasons that require a significant
alteration to the project
 the development of a contingency plan that may be used as a fallback when schedule
and budget can no longer support the project
 the changes leading to improvement of the initial project plan.
© ABE
A change control system should have a number of clear goals that include:
 identification of proposed changes and their drivers
 determination of any effects the proposed changes are likely to introduce
 evaluation of any proposed changes and their formal approval
 resolution of any conflicts associated with the introduced changes
 communication of changes to all stakeholders involved
 allocation of responsibilities associated with the implementation of change
 tracking ad monitoring of any changes.
A change control system may provide a number of benefits to the project as it allows the
project manager to be in control of the change implementation. The objective is for changes
to take place smoothly and reduce any negative impact on the project's performance. Some
of the main benefits of change to a project can be identified as:
 controlling the sequence of changes in such a way that the project remains on track
 maintaining a control of how changes affect the financial aspects of the project
 ensuring that the project performance remains unaffected
 maintaining the integrity of the project's WBS
 allocating the resources required for the implementation of change
 allocating responsibilities for change
 disseminating the effects of any project changes
 monitoring the implementation of change.
Controlling Major Constraints (Quality, Time and Cost)
The major constraints for change are the available time frame, the associated costs and the
effects on project quality. Sometimes project managers may consider avoiding change due
to the impact of those changes to the project.
In order to control how these constraints may affect the introduction of change, a project
manager must follow a number of steps to ensure the successful introduction of change.
These steps are:
 Requesting changes
The project manager must investigate the need for change and establish a good
understanding of changes relating to different stakeholder needs. Once the required
changes are identified a request is made to obtain support for these changes.
 Assessing the impact of changes
The proposed changes should be considered with respect to the impact they may have
on the project and the organisation at large. The aim is to establish that the benefits of
the introduced changes are significant and that there are no major drawbacks.
 Planning changes
A clear plan must be put together in order to schedule any actions leading to the
proposed changes, allocating responsibilities and establishing the availability of the
necessary resources.
© ABE
 Testing the change plan

The plan for change must be agreed with all involved stakeholders and a test is
necessary to ensure its feasibility. Any activities associated with the project changes
must be carefully scheduled.
 Implementing changes
Any proposed changes should be implemented taking under consideration the revised
schedule and resources allocated to support the implementation of change.
 Accepting changes
Once the changes are implemented the stakeholders must agree that they are
acceptable and that they correspond to the scope for change.
Scope verification is a process associated with the management of change and more
specifically with the efforts to address project constraints affecting change implementation.
Scope verification focuses on whether the scope for change has been achieved by the
implemented changes. There are three main elements in scope verification:
 assessment of requested changes
 recommendations for corrective actions
 acceptance of deliverables.
The requested changes are assessed in terms of several aspects including their feasibility,
the magnitude of change on the initial project scope, the impact on resources, etc. In
principle, once a change is identified as a preferred approach for the future of a project it
must be filtered carefully to establish whether it will benefit the project. Sometimes poor
project performance may trigger change requests that have not been carefully prepared.
Once a change request is submitted the project manager must identify all those actions that
may be required for the change to be implemented. Such actions may be part of the change,
or could be triggered from certain aspects of the change, or be supportive ones that are
indirectly related to the change.
Any accepted changes are likely to affect the initial form of the planned project deliverables.
Additional deliverables may be produced and existing ones may be transformed. It is
important to review, evaluate and reflect on how these deliverables are associated with the
project's scope before accepting them.
Change Control Procedures
So far we have discussed the need for change in most projects and the various
considerations of project managers that result from requested changes. It is necessary for
project managers to remain in control of the implemented changes, and this requires the
introduction of well-planned change control procedures.
There are several views on how a change control process can be managed. In previous
chapters we have discussed various aspects of project management methods and
approaches. Similarly, the way change is introduced and controlled in a project is subject to
a number of viewpoints. The project manager should balance the need for change and
prompt reaction to performance indicators and external events with the importance of staying
in control of the project and its activities.
A number of steps that can be followed while managing the change control process are:
 Using authorisation
By controlling who is allowed to introduce changes and how performed changes are
delegated to certain team members, the project manager is likely to avoid losing
© ABE
control of extensive changes that may otherwise lead to overlapping, repetition,

conflicts and misalignment.
 Demanding justification
Each change should be fully justified and supporting documentation should offer the
much-needed clarification of why change is important for the project. By identifying
relevant actions for each change it is possible to increase awareness of the actual
impact of the change and reflect whether it was required, as well as whether its nature
is imminent.
 Assessing risk
Any change to the project plan, schedule, resources and structure is likely to have an
impact. It is unrealistic to expect that changes will be implemented without affecting the
initial project plans. It is therefore necessary to identify how change will be experienced
by the project stakeholders and provide an accurate representation of how the project
tasks and deliverables will be affected. This will help to assess any risks associated
with the overall change plan and more specifically the risk imposed by each single
element of change that is accepted.
 Preparing for audit
Record keeping is a very important activity that allows project managers to gather
information with respect to any accepted changes. Such information may include the
nature of the change, the way it was implemented and deployed, the effects on the
project, any members involved in related actions, stakeholders who are affected by the
change, etc. The preparation of such detailed records will help to improve the chances
of reversing certain actions and return to previous stages if change leads to failure,
and identify reasons for such failure.
 Testing impact
It could be argued that change is good when it is introduced for addressing existing
problems and project failures. However there could be certain aspects of a project that
may not easily accommodate change. For example, the staffing of a project team, the
workload of individuals, the scheduling of project tasks and the allocation of
responsibility may be just some of the project aspects that may struggle to keep up
with a changed project scope. It is therefore essential to test the impact change would
have on the project and reflect on whether the benefits of the introduced change justify
the extra strain on resources and structures.
 Planning change
The proposed change is quite often in the form of new requirements, associated
resource needs, supporting actions and an overall scope that puts all these change
components in perspective. In simpler words, a requested change may be a project of
its own. The same reasoning we used in early chapters when dealing with project
planning applies to change. Change must be planned and such a plan should be
integrated with the existing current project plan.
 Implementing change
The planning of project change must be followed by a well-structured implementation
phase which focuses on addressing the identified requirements and follows the design
of the change plan. A thorough testing phase is necessary to ensure that the impact of
change is in line with the initial expectations and in agreement with the scope for
change, and that the change benefits have been achieved.
© ABE
 Preparing contingency plans

It is not uncommon for the implementation of change to fail meeting its targets. This
could lead to the existing problems remaining while the project deliverables are shifted
from the original plans. A contingency plan should either allow the project manager to
introduce further changes and react to the continuing problems, or return to a previous
state and follow a different change plan.
 Maintaining awareness
While change is implemented it is essential for the project manager to be in control of
the entire process but also disseminate any important outcomes to the project
stakeholders. The scope for change, the change management plan and certain
evidence for the impact of change should be known by others involved in the project
and the change activities. Such a practice puts individual actions in perspective,
improves communication within the project team and also with others, and is likely to
have a positive effect on morale and commitment.
 Reflecting on change
At the end of the change process it is necessary to perform a number of tasks. Initially
the implemented changes should be tested against the scope for change in order to
ensure that the change has been implemented properly. The introduced changes
should be evaluated by stakeholders in order to assess whether its actual impact is in
line with the initial estimation and assumptions. Finally, the project manager should
reflect on feedback received from both end-users (of changed deliverables) and the
team members to assess whether the change was worthwhile.
Organisations may introduce customised documentation to support and formally coordinate
the introduction of changes in a project. A typical example involves a change submission
form that describes in detail the proposed change, its justification, the potential impact and
any additional requirements relating to project resources. Additional forms can be used to
provide the risk assessment for the proposed changes, the request for additional resources
and preliminary plans for necessary actions and deviations from original project schedules.
The customisation of change forms is necessary to fit the special requirements of different
projects.
Review Questions 2
(a) What is the main criterion affecting a project manager's decision to request specific
project changes?
(b) What are the seven key considerations for assessing whether a project request should
be made?
(c) What are the three main activities associated with scope verification?
(d) Give an example of the documentation used to support the request for changes in a
project and the implementation of these changes once approved.
© ABE
C. CONFIGURATION CONTROL
The previous section discussed in detail the scope for change in a project and the ways such
changes are implemented and introduced. When introducing changes in a project the
configuration of its structure, plan and schedule is altered. The project manager is
responsible for control any configuration changes taking place. The main benefit of
configuration control is that it offers a justification for project change and a mechanism to
monitor changes and observe their impact.
Configuration control allows project managers to impose certain quality criteria on the way
change is implemented. Some examples are:
 justifying change requests with knowledge and awareness of the change impact
 prioritising any changes with respect to their impact, benefit and related actions
 filtering change requests according to specific criteria (e.g. benefits)
 evaluating the actual cost of change according to a number of factors such as cost,
resources and trade-offs
 obtaining support from stakeholders and management
 communicating change procedures, actions and outcomes
 controlling change processes and the way implemented changes are introduced
 maintaining the project's existing configuration baseline
 documenting any changes taking place in the project
 supporting the project after the introduction of the implemented changes.
Configuration control is an essential process for project managers for controlling the project
life cycle. It allows managers to perform changes in a fashion that takes under consideration
the project scope, any associated actions and relating costs. The configuration control of a
project allows the project manager to follow a more flexible approach in the way changes are
implemented. With configuration control the project manager is always aware of how
changes affect the project and whether any significant deviations from the project's scope
have taken place. The information provided from configuration control processes allows
project managers to adjust any project operations and actions to ensure the optimum use of
project resources. The fact that the configuration control process is the responsibility of the
project manager ensures that any changes are authorised and are in line with the project
plan.
Configuration Control Procedures

There are several ways for the configuration control of a project to take place. A number of
configuration control procedure steps include changes that may take place in the project and
the associated documentation. Such changes may be in the form of additional functionality
that alters the project specification, alters different project processes, and varies
characteristics and features of project deliverables, etc.
Reasons for introducing changes may include:
 providing additional functionality as requested by stakeholders
 enhancing product support
 making use of new technology
 improving project deliverables
 addressing project problems
© ABE
 dealing with safety and security concerns

 improving effective use of resources
 increasing project efficiency
 controlling project schedule slippage.
Change may be introduced in the project once the project manager's request for change is
reviewed and approved. Change review boards and configuration control boards are
organisational structures that are involved in this process. In principle such entities are
responsible for reviewing the change requests and make a justified decision to approve or
reject any changes. It is possible for changes to receive conditional approval where specific
constraints are imposed (e.g. change is approved subject to a limited budget).
Review Question 3
What is the aim of configuration control in projects?
© ABE
SUMMARY
This chapter has discussed the concepts of quality, change and configuration control. The
initial section focused on the understanding of quality and its effects on project management.
We looked at a number of different perspectives on quality and attempted to define quality in
relation to products, services, stakeholders and value. Emphasis was given to the
assessment of quality and maintenance of acceptable quality standards. The section
concluded with a more detailed description of quality issues associated with software
projects and the development of systems. The next section covered aspects associated with
change and its effects on projects. The different types of change were classified and a
detailed description of change control procedures was provided. The section also discussed
how change is implemented and managed. The chapter concluded with an overview of
configuration control and supporting procedures.
© ABE

Review Questions 1
(a) The five perspectives are mathematical, structural, organisational, economic and
strategic.
(b) The eight dimensions of: performance, features, reliability, conformance, durability,
serviceability, aesthetics, perception.
(c) The role of an independent quality assurance party is to offer a set of objective
standards against which project deliverables, processes, operations and activities can
be measured.
(d) The steps are: defining the quality standards; agreeing the quality standards with the
project stakeholders; identifying stakeholders who should be involved with the
determination of these standards; collecting information required to define the
standards; testing the standards; communicating the standards.
(e) Software failure may be associated with the ability to support only certain limited
functionalities, the delivery of a portion of software that does not meet all requirements,
or overruns in the estimated time and budgeted costs. You may have thought of others.
Review Questions 2
(a) To identify whether any changes are within the project's scope or are external to the
core of the project (and therefore to be ignored or dealt with as issues of lower
priority).
(b) The key considerations are: whether the change may be implemented within the
current time frame; whether the change is feasible with the existing project resources;
whether the change will affect the project schedule; whether the change will require
additional resources; whether the change will need the prioritisation of the project
deliverables and their deployment schedule; whether the change will lead to significant
shift of project scope; whether the change effects will span outside the project's
boundaries.
(c) The main activities are: assessment of requested changes; recommendations for
corrective actions; acceptance of deliverables.
(d) The example given in the text is a change submission form that describes in detail the
proposed change, its justification, the potential impact and any additional requirements
relating to project resources. Additional forms can be used to provide the risk
assessment for the proposed changes, the request for additional resources and
preliminary plans for necessary actions and deviations from original project schedules.
You might have thought of other examples.
Review Question 3
The main benefit of configuration control is that it offers a justification for project change and
a mechanism to monitor changes and observe their impact. It allows project managers to
impose certain quality criteria on the way change is implemented.
© ABE
155
Chapter 7
Project Closure and Review
Contents Page
Introduction 156
A. Project Termination 156

Human and Technical Problems Leading to Project Termination 157
Factors Affecting Project Completion 158
B. Closing Down a Project 161

Preparing for Project Closure 161
C. Documenting Project Completion 163

Final Report v. Post-implementation Report 164
Project Reporting 168
Summary 169
© ABE
156 Project Closure and Review
INTRODUCTION
A well-known anecdote refers to the fact that most projects spend 90 per cent of their
duration being 90 per cent complete. This can be interpreted in a number of ways as it is
likely that both the evaluation and testing stages may require more time. However, quite often
projects take time to be finalised while their resources are being freed for other projects, and
the project closure process depends on the project performance at earlier life cycle stages. A
project should enter its closure stage once it is confirmed that it is likely to fail its objectives or
when it is complete and has achieved the stakeholder needs and is ready to deploy its
deliverables.
Objectives
 distinguish between the human and technical problems related to project termination
 identify project termination factors related to the project staff, the client, project
handover, maintenance and documentation, contract completion and acceptance,
financial matters and closure checklists
 construct a list of actions appropriate for a project manager preparatory to closing down
a project
 distinguish between the purposes of the project manager's final report and the post-
implementation report
 summarise the contents of the project manager's final report and the post-
implementation report.
A. PROJECT TERMINATION
The way a project is terminated depends not only on its success but also the parent
organisation. You must appreciate that a failing project is likely to be terminated more
abruptly than a successful one. A failing project is unlikely to have a graceful closure, and
any resources will be expected to be dispersed amongst other projects with pending needs.
A failing project is unlikely to require a lengthy reporting stage as there is a chance that no
usable deliverables are produced. In some cases changes in an organisation's scope or
environmental influences may lead to the abandonment of a project. Again, a project that falls
under this category is not expected to have a lengthy termination procedure and lengthy
documentation.
On the other hand the termination of a successfully completed project requires the
production of detailed documentation that will support the sustainability of the project output.
The project enters its final stage by wrapping up any activities that are not yet finalised, and
ensuring a post-implementation audit provides the necessary information for its stakeholders
as well as any information that may be useful for similar projects in the future.
The way a project is terminated is also affected by the organisation's policies and
procedures. The way a project audit is performed and the phasing out of its final activities
and dedicated resources are both dependent on the organisation's strategy.
© ABE
Project Closure and Review 157
Human and Technical Problems Leading to Project Termination

Project termination involves the completion of certain tasks and handing over control and
responsibility of the project output to those stakeholders responsible for the post-
implementation phase. There are certain criteria that affect the way the project termination
takes place.
 Achieving goals
Initially the project manager must ensure that the common goal is for the project to be
completed successfully and for the project resources to be deployed elsewhere with
minimum disruption and delay. Sometimes personal agendas of team members and
certain stakeholders may require the continuation of the project and the extension of its
activities along with the associated financial rewards. The project should have clear
targets and sometimes additional benefits may act as drivers for early completion.
 Preparing documentation
The project completion must involve the preparation of any documentation that can be
used to support end-users and also offer an opportunity to understand how the project
was managed throughout its life cycle. The prepared documentation may be used for a
project review or to reflect on how the project deliverables were created.
 Terminating tasks
Project termination also involves tasks associated with the closing down of any
systems being used specifically for the project's scope. Such systems may include
accounting systems or IT support and any additional technology that project tasks were
dependent on. Sometimes project communication is supported by tools and procedures
that are no longer required in the organisation.
 Reviewing output
The project termination should also allow for a post-implementation review of certain
activities, tasks and project outputs. The opportunity to reflect could offer a prompt
response to possible omissions and could also act as an audit for the project's
performance.
 Redeploying resources
The project's human resources should also be deployed elsewhere within the
organisation following its completion. It is necessary for staff members to be
reassessed with respect to their performance, the achievement of certain objectives
and the acquisition of additional skills, knowledge and experience. It is essential to
review the individual profiles of team members in order to make informed decisions for
their next project or roles.
 Monitoring stakeholder satisfaction
The final step required for project termination relates to the stakeholders and their
satisfaction levels. A project evaluation is not complete unless it takes under
consideration the stakeholder perception of certain key performance indicators.
Think Point 1
Project termination may be unexpected and follow poor performance or failure. Alternatively
the project could be terminated according to its initial plan. Detaching human resources from
a project and its tasks, and/or the reassignment of staff members to specific tasks, depends
on the reasons for the project termination.
© ABE
What factors would you need to consider in developing a strategy for the redeployment of
human resources following the termination of a project?
Project Completion and Handover

The project completion and handover includes a number of tasks which ensure there are no
issues that have not been addressed. Quite often these tasks require the preparation of
dedicated documentation.
One of the key tasks before the formal handover of the project is to ensure that certain
quality criteria are met. The reason is that quality aspects are always part of the performance
indicators used for assessing project output. By establishing a commonly acceptable quality
assessment, it is possible to reach a shared understanding about the project's actual
performance. Failing to reach such an agreement, the project manager faces the danger of
entering a lengthy negotiation process before the project deliverables are accepted.
The project handover also requires the project manager and any team members involved in
the operation of certain project systems and deliverables to produce guidelines for their use.
One of the key concerns in projects includes their sustainability and their operation following
the project's completion. Any project outputs should be usable with minimum support that is
offered by the project documentation.
The project handover should also include guidelines and suggestions for further work on the
project's output. Perhaps additional projects advancing the original deliverables may be in
the pipeline, requiring specific recommendations.
Factors Affecting Project Completion

Project completion is a process that must deal with several loose ends and it requires the
project manager to make certain decisions. It is affected by several factors that quite often
are not dependent on the project's immediate environment.
One of the key factors affecting the time frame for the project's completion is staffing. Quite
often organisations must redeploy their staff members according to project needs. This is
likely to trigger reallocation of team members, rethinking of the project deliverables and
working practices within a project team. The lack of certain skills or availability of some team
members are also some of the issues affecting the completion of the project.
The project stakeholders, end-users and clients are quite often responsible for the way
the project is completed. Sometimes their needs change, leading to additional project
activities and output. Alternatively clients may rethink their priorities leading to project
changes.
Furthermore, the financial aspects of a project are likely to cut the project activities short
and reduce the project output. A reduction in the project's budget and perhaps a restructuring
of the available resources may affect the way a project is completed. It is possible that the
support offered to the project may be reduced by lack of time and involvement. In such cases
the project may suffer, as there is not enough input from clients to ensure that their
requirements are accurately understood and fully met.
Think Point 2
Identify issues relating to the financial aspects of a project and how they may affect its
termination.
© ABE
The financial issues relating to project performance may be associated with resources and
staffing used by the project, any performance expectations and the assessment of whether
the project is viable to continue.
Audit and Review
The post-implementation audit of a project is a process that is followed quite often by project
managers who wish to offer additional information to the project stakeholders. It is also a step
that may prove useful if further work is needed following up the project handover.
The audit process is required for a number of reasons, including:
 Reflecting on activities
The project manager is well placed to reflect on each project activity and identify any
problems. If the post-implementation audit takes place soon after the project's
completion, it is likely that any immediate issues will be easy to identify and will relate
to specific causes. The aim of this audit is to assess whether certain activities were
problematic, and possibly to identify the reasons for any problems and the reduced
efficiency of these activities.
 Assessing task performance
A project audit is likely to review the project in phases and activities and eventually
assess each individual task. This practice allows an assessment of whether task
holders had problems meeting specific performance targets. The evaluation of team
members' performance helps to identify whether additional support is needed by team
members and the capability of individuals to perform particular tasks.
 Triggering further actions
The audit of certain project phases may focus on specific deliverables and project
outputs. It is quite possible for corrective actions to be triggered by the audit results.
Although an audit takes place after the implementation of the project deliverables, it
may not be too late to make any necessary adjustments to ensure that the project
deliverables are fit for purpose.
 Reviewing project management
A project audit may also return some findings that relate to the way the project was
managed. This is likely to help project managers in their future responsibilities, as they
can reflect on how their management style and decisions affected the project's
performance and outcome. Similar projects may also be affected by having a baseline
to compare with in future scenarios.
 Changing strategy
The audit may also provide significant results that could eventually change organisation
policies or even the entire strategy if certain directions seem to lead to failure. The
initial requirements identified from the organisation's mission may be such that they
cannot be satisfied by similar projects, and in such cases the organisation should
reconsider its strategy.
 Adjusting procedures
The project audit also offers an opportunity for the classification of project techniques,
tools and procedures. In principle any means used by the project manager and the
team are evaluated, and the findings can be used to review whether they have proven
effective.
© ABE
Think Point 3
Explain why an audit would be required before or after the completion of a project.
There are several reasons why an audit may be required for a project. The focus may either
be on assessing the viability of the project, or reflecting on the project performance following
its termination.
There are clear benefits for an organisation that decides to perform a project audit and
review. Some of these benefits can be identified as:
 Increasing performance
The project manager is capable of identifying the most successful aspects of the
project as well as any issues that were difficult to resolve. By prioritising those project
activities and tasks in terms of their performance, the project manager is able to
organise future project work plans accordingly. The organisation is also able to
evaluate its workforce with respect to a number of performance criteria.
 Supporting development
The appraisal of individuals can be based on the results obtained from the project
audit. The findings may specify areas for further development and opportunities for
training and additional learning. By specifying skills, knowledge and experience needed
by team members, the audit report provides a detailed overview of training needs in the
project team.
 Ensuring sustainability
A project audit allows the organisation to develop a plan of how future projects of a
similar nature should be managed. Furthermore, the project output can be supported
with audit documentation. Finally, the organisation may use the audit findings to
increase the effectiveness of team formation and role allocation within project teams.
Review Questions 1
(a) How do the organisation mission and any associated policies affect the way that the
project is terminated?
(b) What are the six main steps associated with the project termination and how are these
documented in a project termination report?
(c) Name three main benefits for a project to follow an audit process.
© ABE
B. CLOSING DOWN A PROJECT

When a project is closed down after the successful implementation of its deliverables a
detailed procedure takes place. The way the closure of the project happens depends on how
the project customer (client, end-user) wishes the handover of project deliverables to occur.
Quite often project deliverables are accepted in a rather informal way.
The informal acceptance of project deliverables follows a procedure which depends on the
nature of the deliverables. Some examples are:
 Focusing on deadlines
The project deliverables are handed over on a specified deadline without any delay,
despite the fact that part of the deliverables may not be complete. It is more important
to meet the deadline rather than focus on the state of the deliverables.
 Focusing on deliverable state
The project deliverables are not accepted unless they meet certain quality criteria. The
focus is on addressing certain issues and meeting specific needs even if this results in
delays.
 Focusing on delivery
The project deliverables must be produced without any major evaluation. Usually
deliverables of such a nature are outputs of interim tasks that serve as inputs of
subsequent project activities. The objective is to achieve the implementation of the
deliverables and to avoid project delays.
A more formal approach may be necessary depending on the organisation that has
commissioned the project. In such cases, the organisation may require certain steps to be
followed in order to formally sign off deliverables. These steps may include testing and
evaluation tasks that assess the project deliverables against certain quality criteria. At this
stage the project deliverables may be assessed against a baseline or a benchmark scenario.
Usually the stakeholders will follow a checklist including certain items that are grouped
together depending on particular deliverable aspects being assessed and prioritised
according to specific criteria. It is possible for the project deliverables to be partially
accepted, leading to further work and continuation of a portion of the project activities. The
possibility for total project rejection is rather unlikely at such a late stage, but not impossible.
Preparing for Project Closure

The project manager must prepare for the closure of the project by following a carefully
planned process. It is the project manager's responsibility to ensure that the project closure
finds the organisation ready for the deployment of any deliverables, while post-
implementation activities are already planned.
An initial concern relates to the fact that the project output may need to be installed,
deployed and perhaps used by a variety of stakeholders. It is not uncommon for project
closure to require training and support activities. A number of responsibilities associated with
project closure are:
 preparing the infrastructure necessary for any installation tasks required
 introducing the project deliverables to the affected organisational units
 disseminating the deployment plan to stakeholders involved
 producing the documentation required for the installation and use of deliverables
 training users for the use of project deliverables
 troubleshooting the installation process and preliminary operation of deliverables
© ABE
 addressing any issues rising from low acceptance of project outcomes from end-users
 supporting end-users at early stages of operation
 providing a sustainability plan to reduce future involvement in the operation of the
deliverables
 introducing a maintenance strategy for any deliverables that may require support in the
future
 safeguarding any resources that may be needed for future support of the project
output.
Think Point 4
Project termination can be based on a number of steps depending on the circumstances. The
preparation for project termination depends on how the different stakeholders are likely to be
affected by it.
For a project example of your choice, identify the steps involved with the project closure and
explain the need for each.
Reviews and Learning

A very important aspect of a project's closure relates to the fact that the project manager and
the associated project team acquire new knowledge and learning from the project
experience. Such knowledge and learning may be very useful for any subsequent projects as
they can improve the way the project tasks are implemented and managed.
We can classify the project learning into two different types depending on how it is achieved.
Learning can be acquired by:
 The provision of learning opportunities before the commencement of the project.
 The assimilation of learning experiences following the completion of the project.
The first type of learning is associated with knowledge that can be obtained from the various
sources of information that may be used for project tasks. On the other hand, the learning
obtained following the project completion can be associated with findings from the project
audit and review phases.
The former type of learning is usually achieved from external sources, including training,
education, consultations and similar learning opportunities. The objective is to ensure that
the project team members have the skills that are needed to perform the project aims. The
learning provided should be linked to specific project tasks. Different types of learning could
support a number of tasks. Specific tasks that are based on certain skills could be supported
by customised training of those team members who are responsible for them. The
involvement of external consultants is necessary for the achievement of certain project
objectives. Sometimes the learning associated with the project activities may have taken
place in the past as an education programme fulfilled by the project members.
The latter type of learning is dependent on the project audit findings that may be associated
with the need for such learning, the resources required and the need for information. This
kind of learning is a more immediate response to project findings resulting from the project's
audit and review.
The main difference between the two types of learning is that when learning follows a project
task, it is rarely useful for the same project and should be directed to future projects with
© ABE
similar tasks. On the other hand when learning is provided in advance of the project tasks, its
outcomes are likely to affect the performance of the project.
Review Questions 2
(a) Identify three key perspectives that might be followed when putting together a
procedure for accepting project deliverables.
(b) What are the key differences between "learning from doing" and "learning before
doing"?
C. DOCUMENTING PROJECT COMPLETION

The completion of a project is itself a very important project stage. Project success depends
not only on how its deliverables are produced, but also on the way they are deployed and
handed over to the intended users.
Project completion is affected not only by the documentation of the process, but also by any
documentation that is associated with the final deliverables as well as any activities that may
follow the project completion.
The project documentation is a critical aspect of the project management process for a
number of reasons such as:
 Project documentation provides a consistent point of reference for any future work that
may be undertaken on the project deliverables. The documentation clarifying the
scope, design and implementation of each deliverable allows future work to be more
informed and reduces the time required for familiarisation with the project deliverables.
 Project documentation can be used as an archive of diary entries that may help in
understanding the main issues relating to the development of the project deliverables.
Such an archive increases the awareness of what was involved in their development.
 Project documentation offers a detailed project record that describes project activities
and tasks that are associated with the development of the project deliverables. The
project deliverables can be described with respect to the required resources, their
duration, any associated costs, the necessary skills and structures.
 Project documentation provides a supporting mechanism for project managers who are
likely to undertake similar responsibilities in the future. The existence of such
documentation ensures that project managers may reflect on previous experiences
prior to any decisions.
 Project documentation is also used as a training tool for end-users during the
deployment of project deliverables and during the introduction of the project output to
new stakeholders.
 Project documentation may also offer the mechanism used for the continuous
development of the project team and reference points for reflecting on previous
responsibilities and evaluating the way project members fulfilled their roles and
performed their responsibilities.
 Project documentation is sometimes used for monitoring the project progress and team
performance. It may offer an opportunity to increase awareness of pending issues, as
© ABE
well as reaching consensus with respect to the actual project performance and the way
it should be rated against the project plan.
Final Report v. Post-implementation Report

The documentation associated with a project depends on how thorough the documentation
process is for the organisation concerned. The structure and detail of the produced
documentation also relates to the project scope, its activities, the supporting structures and
the implemented deliverables.
A range of associated documents may be required at the project completion stage. These
include:
 overview statement – provides a project overview in a concise way, focusing on the
project's scope
 proposal – discusses in detail the project scope and overall aims as well as more
detailed objectives
 schedule – describes the schedule of any project activities including any revisions
made following project changes
 meeting minutes – offers a detailed archive with an outline of issues discussed during
each meeting, any decisions made on the day and possible actions that were
delegated to members and were followed up after the meeting; may also include the
outcomes of any actions resulting from previous meetings
 status report – a thorough analysis of the project progress, the team performance and
the status of each project activity and associated tasks
 design – a variety of forms can be used in documenting project designs as these may
include a detailed list of actions, a more formal specification or even illustrations
 change requests – the detailed justification of each change request offers a rationale
for any project revisions
 change notification – the description of the implemented changes may be used to
understand any deviations from initial project plans and the way changes are
implemented
 communication – a diary of communications that are likely to be in written format are
stored for future references, auditing and tracing decisions and actions to their source
 outstanding issues (to-do lists) – a report on issues that are still in need of attention
provides an estimation of work requirements and any pending actions
 deliverables – a detailed document that describes each deliverable in terms of its
objectives, the way it was designed and implemented, the requirements it satisfies and
any aspects necessary for its deployment and use
 acceptance document – a detailed form that is used to confirm the formal acceptance
of the project deliverables by the client
 final report – the final report on the project's life cycle, reflecting on its achievements,
the completion results and any produced deliverable
 post-implementation audit report – a report that provides an evaluation of the project
outcomes against its requirements.
© ABE
Improvement Activities
Following the completion of a project we must be able to identify not only those project
elements that contributed to its success but also any issues that affected its optimum
performance. Certain improvement activities may include the identification of key issues that
may relate to future projects, reflection on lessons learned and decisions made and reporting
on how the project evolved and progressed through its life cycle. The creation of a post-
implementation audit is necessary for contributing to the development of a management
strategy for similar projects.
The post-implementation audit is a process that is extremely useful for everyone involved
in the project. The project manager should be able to reflect on the project's performance
throughout its life cycle. Certain lessons are learnt during certain project phases and it is
necessary to provide such information to stakeholders, any project members that are likely to
be involved with similar projects in the future and the organisation, in order to identify and
assess similar issues in other projects.
The post-implementation audit has a single scope: to examine how the project progressed
and whether its performance was in line with the initial plan. Issues such as goals, specific
objectives, budget, resources, specification of output, deliverables, deadlines and even
human resource concerns should be taken into account. The post-implementation report
should not be viewed as the manager's diary reflecting on an individual's experience of the
project. Documenting this audit should be based on a clear structure providing sufficient
detail about any major observations. Although the perspective of those involved in the audit is
likely to be subjective when certain areas are covered, the aim should be to produce a
discussion that is as objective as possible.
The post-implementation audit should be based on a detailed log of project activities and
tasks. The main reason for this is that the audit needs to be based on facts and any actions
or events that have affected the project and those responsible for it. Although the project
deliverables provide an indication of quality and performance indicators they are likely to only
provide a snapshot of the final stages leading to their deployment after they are finalised. A
more dynamic review of the project life cycle should therefore be based on what did actually
take place while the project deliverables were being prepared.
Project managers who have kept a project log of major events, reasons for decisions, key
actions, changes that may have been introduced and outcomes from meetings are likely to
be more prepared for such an audit. Six necessary steps can be identified as a baseline for
organising the project's post-implementation audit and these are identified next.
 The first step should focus on assessing whether the project goals have been
achieved. The aim is to examine whether the project delivered what was required. This
step may consider examining both the project team's perspective as well as the client
or end-user perspective. For example, the project scope may be perceived from a
different viewpoint even at the final stages of the project. This step should first examine
whether the promises made by the project team were kept. In other words, whether the
project team produced deliverables that achieve what they claimed when producing the
original plan and supporting designs. Furthermore this step should investigate whether
the requirements for each deliverable and project outcomes have been satisfied.
 The second step should emphasise the way the project deliverables were produced.
This step could assess whether the project met certain quality criteria associated with
the budget, deadlines and specification. As discussed in the sections relating to quality,
the project's success depends on how the original budget and time frame were treated
and is affected by any delays and excessive costs. This step should also concentrate
on whether the project deliverables are in line with the project specification.
 The third step should focus on the stakeholders involved in the project and more
specifically with their perception of the project deliverables. In other words the end-
© ABE
users should be consulted to ensure that their original requirements were met. This
step should also consider how project changes may have affected the way the original
needs were altered. The aim should be to identify whether the final deliverables are in
line with the end-user needs.
 The fourth step should provide a more generic and bigger picture for the project by
assessing whether the project outcomes offered real value to the organisation. The
project's scope should exceed the production of specific deliverables and focus on how
the projection completion is likely to affect the organisation as a whole. The value of the
project to the entire organisation should be assessed in terms of how it further supports
the organisation in achieving its mission.
 The fifth step should be geared towards reflection on project management
techniques and the procedures followed. The project audit is necessary to consider
the way the project was managed and whether certain actions should be identified as
helpful in solving known problems or as being ineffective.
 The sixth step should provide a classification of the project experiences in the form
of guidelines for future similar actions. The scope of this step would be to identify
those aspects of the project that worked but also cases of failure and the reasons for
different types of failure.
Justifying Project Decisions
By reading through the documentation supporting a post-implementation audit we can
assess how the project was managed and whether certain actions were triggered by certain
events, external influences or project management decisions.
The justification of a project management approach, the methodology and techniques used
to produce the project outputs, the methodology for implementing the plan project activities
as well as the involvement of stakeholders must be documented in detail. The preparation of
a final project report addresses such issues while providing a detailed description of how
the project progressed from its initiation stage to its completion.
The final report could be structured in a number of sections addressing certain themes.
Organisations usually follow set guidelines when drafting project reports, and it is quite
common for prearranged templates and section headings to be used. In this section, a few
suggestions are provided for the required final report structure.
The project performance should be discussed clearly in the core of a final report. A reflective
approach is recommended providing a detailed analysis of how certain performance
indicators were used to assess whether the project met its objectives. The success of a
project could be measured in a variety of ways, as far as it provides an accurate
representation of how the project outcome is perceived by all associated parties.
The organisation of the project should be clearly described as it would put the progress
performance within the required context. The structure of the project resources and their
association with specific project requirements and objectives is necessary. The identification
of any planning deviations and the grouping of project activities and tasks are necessary in
order to provide a hierarchical view of any actions and events that have taken place.
The project report should also include a detailed discussion on the methodology imposed by
the organisation and the style of the project manager in charge, as well as any specific
techniques and tools used in order to achieve its targets.
Typically a project macro-analysis and a micro-analysis are likely to be included in a final
report. The scope of such analysis is to place the project outputs within the project
environment and explain how the project deliverables are likely to affect the organisation's
success in the future. Such analysis is likely to take place before the commencement of the
project and a review could be performed prior to the deployment of any deliverables. The
macro-analysis should focus on external and environmental factors affecting the project
© ABE
output including political, social, economic and other factors that are present in the relevant
field. A more focused analysis should concentrate on the specific project and provide an
overview of the project's main strengths and weaknesses.
A project's final report provides an excellent opportunity to collect useful information relating
to a number of issues relating to the project team and the way its members have undertaken
their roles. For example, the report may state how roles are allocated, the steps taken to form
the team and the way the project communication has taken place.
Think Point 5
Compare and contrast post-implementation reporting and final reporting.
The focus of post-implementation reporting and final reporting is based on the project
manager's objective. Post-implementation reporting considers the auditing of the project's
performance while the final project reporting offers a reflection on project actions.
Evaluation of Quality Costs
Project closure depends on a final decision that must take under consideration a number of
factors. This decision should assess whether the project performance is such that it requires
an early ending, or whether the project performance justifies the completion of its expected
life cycle.
Project performance can be assessed in a number of ways, each contributing to the final
decision on the project's completion. Some of these performance-related considerations
include:
 planning – relating to the way the project phases are planned in line with the project
objectives and whether the original plan is followed
 scheduling – relating to the problems the project faces with respect to the original time
frame and any deadlines associated with project deliverables
 organising – relating to the way the project manager organises the project and
ensures that the project heads in the right direction
 staffing – relating to human resource issues that may affect the viability of certain
tasks and the project as a whole
 controlling – relating to the way specific tasks are coordinated, the monitoring of team
performance and the collaboration between team members.
The performance evaluation of the project is likely to provide an overview of key quality
issues and associated costs. It is important to reflect on the fact that unless the quality
requirements are met within an acceptable range of resources and costs, there is no reason
for the continuation of the project.
© ABE
Project Reporting
The project completion is followed by the project documentation that is produced during the
closure stages of the project. The creation of any project reports should take under
consideration a number of views that are important for reflecting on the project's success.
Initially the project report should aim at addressing any project issues relating to stakeholder
needs and their interests. The project report should also focus on how the project is
perceived according to:
 the organisation's perspective
 the project team's perspective.
An organisation perspective of the project's success should focus on the way the
organisation's resources have been used for the purposes of the project deliverables. The
project report should provide an overview of how the organisation has supported the project
tasks by assigning resources, allocating the most suitable team members and dealing with
risks and costs.
The team perspective should be reported with respect to the way tasks have been allocated
and implemented. The perspective of team members might also focus on how the project
plan was followed, how certain skills have been exploited and the way team members
collaborated and coordinated throughout the project life cycle.
Project Completion Documentation
The documentation that is produced following the project's completion should be structured
in a way that provides the necessary information for reflecting on the project's success, but
also supporting the deployment of the project deliverables.
The project documentation should be initiated with an overview that classifies the project with
respect to its size, complexity, objectives, staffing, resources, support, scheduling and
planning.
The project documentation should also include an analysis of how the project progresses
towards the achievement of its objectives and overall aim. The project report should also
consider how resources have been used and how staffing was allocated.
Additionally the project completion report should include sections on the project decisions,
justification and any lessons learned as discussed earlier in this chapter.
Review Question 3
Name as many of the 14 main types of documentation that are required at the project
completion stage as you can.
© ABE
SUMMARY
This chapter concluded our study of project management by providing an overview of project
closure and review. We discussed the main considerations relating to project termination, the
process of closing down a project and the documentation of the project completion.
Project termination was discussed in terms of both human and technical factors affecting the
termination decisions. The first section was also concerned with the audit and review
processes as well as any associated documentation.
The second section described in detail the process involved in the closure of a project.
The chapter concluded with a discussion of the differences between the final report and the
post-implementation report. More specific issues relate to improvement activities, the
justification of project decisions, the evaluation of quality costs and any project completion
documentation.
© ABE

Review Questions 1
(a) A change in an organisation's policies or mission may lead to a project being
abandoned, e.g. if the project is no longer relevant to the organisation's purpose or
simply a lot less important than it was previously. The way a project audit is performed
and the phasing out of its final activities and dedicated resources are both dependent
on the organisation's strategy.
(b) The main steps are:
 The project manager must ensure that the common goal is for the project to be
completed successfully and for the project resources to be deployed elsewhere
with minimum disruption and delay.
 The project completion must involve the preparation of any documentation that
can be used to support end-users and also offer an opportunity to understand
how the project was managed throughout its life cycle.
 Project termination also involves tasks associated with the closing down of any
systems being used specifically for the project's scope.
 Project termination should also allow for a post-implementation review of certain
activities, tasks and project outputs.
 The project's human resources should also be deployed elsewhere within the
organisation following its completion.
 A project evaluation is not complete unless it takes under consideration the
stakeholder perception of certain key performance indicators (satisfaction levels).
(c) The text suggests increasing performance in the future, supporting development of
team members and project teams, and ensuring sustainability for future projects. You
might have thought of other benefits.
Review Questions 2
(a) The text identifies three alternative project acceptance procedures focusing on:
deadlines, deliverable state and delivery with evaluation.
(b) The main difference between the two types of learning is that when learning follows a
project task, it is rarely useful for the same project and should be directed for future
projects with similar tasks. On the other hand when learning is provided in advance of
the project tasks, its outcomes are likely to affect the performance of the project.
Review Question 3
Those given in the text are: overview statement; proposal; schedule; meeting minutes; status
report; design; change requests; change notification; communication; outstanding issues;
deliverables; acceptance document; final report; post-implementation audit report.
© ABE

ABE Level 6 Project Management Study Manual

Uploaded by

Copyright:

Available Formats

ABE Level 6 Project Management Study Manual

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

ABE Level 6 Project Management Study Manual

Uploaded by

Copyright:

Available Formats

What are the main steps involved in project termination?

What are the main steps involved in project termination?

What are the three alternative project acceptance procedures discussed in the text?

What are the three alternative project acceptance procedures discussed in the text?

i

Chapter Title Page

Introduction to the Study Manual iii

3 The Project Plan 57

4 Monitoring and Controlling Project Progress 83

5 Dealing with Team Structures and Leadership 103

Chapter Title Page

6 Managing Quality and Change 131

7 Project Closure and Review 155

Introduction to the Study Manual

Welcome to this study manual for Project Management .

Unit Specification (Syllabus)

Unit Title: Project Management

Coverage of the Syllabus by the Manual

Learning Outcomes Assessment Criteria Manual

1. Be able to initiate the 1.1 Identify an appropriate project from an Chap 1

3. Be able to create a 3.1 Devise a structure for the management Chap 3

5. Know how to organise a 5.1 Compare the commonly employed Chap 5

6. Understand the 6.1 Explain how quality may be assessed Chap 6

A. From Business Objectives to Project Description 3

B. Project Feasibility and Risk Analysis 7

C. Project Planning – towards a Life Cycle Model 11

D. The Project Manager Role 18

Answers to Review Questions 26

A. FROM BUSINESS OBJECTIVES TO PROJECT

The Need for a Specific Undertaking (Project) to Achieve Business Goals

 Monitoring the project – involves reporting, controlling change, monitoring progress,

How Pursuing Organisation Objectives can Lead to a Project Definition

Typically, stakeholders may be classified as internal to the organisation or external. Based on

 values and norms

B. PROJECT FEASIBILITY AND RISK ANALYSIS

The Importance of Conducting a Feasibility Study

The Various Dimensions of Feasibility

The Levels of Risk and Uncertainty and Success Factors

C. PROJECT PLANNING – TOWARDS A LIFE CYCLE

The Basic Project Life Cycle Model

The Suitability of Alternative Life Cycle Models

Planning Management Monitoring

 Creation  Development  Evaluation

Evolve Throw away Develop main

D. THE PROJECT MANAGER ROLE

The Diverse Activities of a Project Manager

Attending team needs

 influencing strategic planning

The Importance of Ensuring Good Communication

Another established project management approach is PRINCE2 (PRojects IN Controlled

ANSWERS TO REVIEW QUESTIONS

A. Hierarchical Division of Work 28

B. Risk Assessment and Management 35

C. Cost Planning and Estimation 42

D. Dealing with Bids, Tenders and Contracts 48

E. Effects of Location on Project Management 51

Answers to Review Questions 56

A. HIERARCHICAL DIVISION OF WORK

Figure 2.1: Project outline planning as suggested by Harvey Maylor

Describing Project Scope with Work Breakdown Structures