Study

MGT8022
Project -based management

Faculty of Business and Law
Study book
Published by
University of Southern Queensland
Toowoomba Queensland 4350
Australia
http://www.usq.edu.au
© University of Southern Queensland, 2012.1.
Copyrighted materials reproduced herein are used under the provisions of the Copyright Act 1968 as amended, or
as a result of application to the copyright owner.
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 prior permission.
Produced by Learning Resources Development and Support using the ICE Publishing System.
Table of contents
Page
Module 1 – The nature of projects 1

Objectives 1
Learning resources 1
Text 1
1.1 Introduction 1
1.2 A framework for managing projects 2
1.3 Providing a focus to your studies 6
1.4 What is a project? 6
1.5 How does project management differ from general management? 8
1.6 What is project management? 10
1.7 The project management processes 10
1.8 The organisational context of projects 12
1.9 The strategic role of projects 14
1.10 Project-based management as change management 15
1.11 Environmental context of project management 15
1.12 Project management outcomes and success? 16
1.13 Project stakeholders 17
1.14 The international context of project management 19
Conclusion 19
Reference list 19
Module 2 – Systems and strategy 21

Objectives 21
Text 21
Selected readings 21
2.1 Introduction 22
2.2 Systems theory 22
2.3 A systems view of projects 23
2.4 A systems model as project life cycle 25
2.5 The project life cycle 26
2.6 Global project management bodies of knowledge 28
2.7 Project management methodologies 29
2.8 Project management tools and software 30
2.9 Project management sustainability 31
2.10 The systems view of project strategy 31
Conclusion 34
Reference list 34
Module 3 – Initiating the project 37

Objectives 37
Text 37
3.1 Introduction 38
3.2 The project management processes 38
3.3 The project charter 41
3.4 The business case 42
3.5 Project portfolios 44
Conclusion 45
List of references 45
Module 4 – Planning the project 47

Objectives 47
Text 47
4.1 Introduction 48
4.2 Planning inputs 48
4.3 Planning processes 52
4.4 Planning outcomes 53
4.4.1 The project management plan (PMP) 53
4.4.2 Contents of a PMP 54
4.4.3 Structure of a PMP 56
4.5 Implementation of the project plan 57
4.6 Project screening and selection 57
4.6.1 Motives and criteria for project screening and selection 58
4.6.2 Traditional cash flow analysis 59
4.6.3 Discounted cash flow analysis 60
Conclusion 61
Reference list 61
Module 5 – The hard skills of project management 63

Objectives 63
Text 63
5.1 Introduction 64
5.2 Hard skills and soft skills of project management 64
5.3 Scope management 65
5.3.1 The importance of planning 65
5.4 Breakdown structures 66
5.4.1 Organisation breakdown structure 68
5.5 Scope management 69
5.6 Time management 70
5.6.1 Introduction 70
5.6.2 The importance of the time factor in project management 70
5.6.3 Time-cost-resources are interrelated 71
5.6.4 Some causes of ‘poor’ time estimates 72
5.6.5 Probability factors in completion date estimates 73
5.7 Time management tools and techniques 73
5.7.1 Milestone charts 74
5.8 Network development 76
5.8.1 Forward and backward pass 78
5.8.2 Float and critical path 79
5.9 Scheduling of activities 79
5.9.1 What is scheduling? 79
5.10 Resources in project management 81
5.10.1 Resource data needs of management 82
5.10.2 Time/cost trade-off-cost schedule optimisation 82
5.11 Cost management 83
5.11.2 The nature of cost and its importance 84
5.11.3 Cost estimating methodology 85
5.11.4 Cost estimating techniques 85
5.11.5 Accuracy of cost estimates 86
5.11.6 Allowance for uncertainty 87
5.11.7 Through-life or life-cycle costs 87
5.12 Project cost monitoring and control 89
5.12.1 Earned value and data analysis 90
Conclusion 91
Reference list 91
Module 6 – Project quality and risk management 93

Objectives 93
Text 93
6.1 Introduction 94
6.2 Project quality management 95
6.2.1 This thing called quality 95
6.2.2 Quality management 96
6.2.3 Quality standards – the starting point 97
6.2.4 Project quality management system 97
6.2.5 Project management quality control 97
6.3 Project risk management 100
6.3.1 Introduction to risk management 100
6.3.2 What are project success and failure? 100
6.3.3 Risk management in projects 101
6.3.4 Risk management planning 102
6.3.5 Management options for handling risk 104
6.3.6 Risk treatment documentation 106
6.3.7 Risk management in the implementation and termination phases 108
6.4 Project procurement management 109
6.4.2 The procurement process 109
6.4.3 Procurement planning 110
6.5 Pre-contract procedures 112
6.5.1 Procurement process 112
6.5.2 Contract execution 112
Conclusion 113
Reference list 114
Module 7 – The soft skills of project management 115

Objectives 115
Text 115
7.1 Introduction 116
7.2 The management of people in projects 117
7.2.1 Project stakeholders and organisational structures 117
7.2.2 Stakeholder management 118
7.3 Project organisation types 119
7.3.1 The organisation continuum 119
7.3.2 Functional organisation – advantages and disadvantages 121
7.3.3 The matrix organisation – the hybrid system 122
7.4 The project team 124
7.4.1 The project manager 125
7.5 Resolving conflict in the project organisation 128
7.6 Project communication 129
7.7 The project management information system (PMIS) 131
7.7.1 The function of project management software 132
7.8 Project integration 134
7.8.1 What is project integration? 134
7.8.2 Project integration management processes 134
Reference list 136
Module 8 – Monitoring and controlling the project 139

Objectives 139
Text 139
8.2 Project integration management processes 140
8.3 Monitoring and controlling processes 141
8.4 Change control 143
8.4.1 Monitoring and controlling scope 143
8.4.2 Monitoring and controlling cost 143
8.4.3 Monitoring and controlling time 144
8.4.4 Monitoring and controlling quality 144
8.4.5 Monitoring and controlling risk 144
8.4.6 Monitoring and controlling procurement 144
8.4.7 Monitoring and controlling human resources 145
8.4.8 Monitoring and controlling communications 145
8.5 Project recovery 145
Conclusion 146
Reference list 146
Module 9 – Closing the project 147

Objectives 147
Text 147
9.2 Project closure 148
9.2.1 Why terminate a project? 148
9.2.2 How to decide to terminate 149
9.2.3 Termination strategies 150
9.2.4 Why don’t they terminate? 152
9.3 The termination process 154
9.4 How to learn for the future – the project review 157
9.4.1 Why have them? 157
9.5 The conduct of project reviews 160
Conclusion 163
Reference list 163
Module 10 – Ethics and governance 165

Objectives 165
Text 165
10.2 Ethics and project management 166
10.3 Strategy and governance 168
10.4 Project governance 169
Conclusion 170
Reference list 171
MGT8022 – Project management framework 1
Module 1 – The nature of projects
Objectives
On successful completion of this module, you should be able to:
● differentiate between day-to-day operational activities and project-based activities

● define and apply basic project management processes and methodologies
● identify organisational activities that may be effectively managed using the recognised
principles of project management
● define the strategic role of individual projects within the organisational context
● identify an appropriate framework for the management of small to medium projects
● define the criteria by which the success of a chosen project can be measured and verified
● identify significant stakeholders involved in a defined project
● differentiate between project management processes appropriate for different
international domains.
Learning resources
Text
Turner, RJ 2009, The handbook of project-based management: Leading strategic change in
organisations, 3rd edn, McGraw Hill, New York – chapters 1, 2, 3, 4 and 19.
1.1 Introduction
Audio
Introduction to module 1
Listen to audio
Welcome to MGT8022 Project-based management. MGT8022 is one of four courses that

represent the core of the Master of Project Management program and provides an
introduction to the application of project management principles to a business environment.
These principles have been acknowledged as sufficiently important that MGT8022 also
forms part of the core of the Master of Business Administration program.
© University of Southern Queensland

2 MGT8022 – Project-based management
Module 1 provides a broad introduction to project management and examines the nature of
projects and their role in organisations in achieving strategic objectives. In this module, we
define what constitutes a project from a business perspective, and how project management
differs from general management. It looks at the environment in which projects are carried
out and the organisational structures that must be created to improve the likelihood of
success. It also considers the life cycle of projects and the various phases through which
project management techniques must be applied.
1.2 A framework for managing projects

Project management may be seen as a collection of many business disciplines within a
framework that provides an holistic and integrative model for identifying and achieving
organisational objectives, whether at a low ‘project’ level or at a higher ‘portfolio’ level.
Studies at USQ in project management use a framework of nine knowledge areas and five
management process groups illustrated in table 1.1 and detailed in a publication by the
Project Management Institute based in the USA: A guide to the project management body of
knowledge (commonly referred to as the PMBOK® Guide) (PMI 2008).

Table 1.1: Project Management Process Groups and knowledge areas mapping
Project Management Process Groups
Knowledge areas Initiating Planning Process Executing Process Monitoring and Closing Process
Process Group Group Group Controlling Group
Process Group
4. Project integration 4.1 Develop project 4.2 Develop project 4.3 Direct and manage 4.4 Monitor and 4.6 Close project or
management charter management plan project execution control project work phase
4.5 Perform integrated
change control
5. Project scope 5.1 Collect requirements 5.4 Verify scope
management
5.2 Define scope 5.5 Control scope
5.3 Create WBS
6. Project time 6.1 Define activities 6.6 Control schedule
management
6.2 Sequence activities
6.3 Estimate activity
resources
6.4 Estimate activity
durations
6.5 Develop schedule
7. Project cost 7.1 Estimate costs 7.3 Control costs
management
7.2 Determine budget
8. Project quality 8.1 Plan quality 8.2 Perform quality 8.3 Perform quality
management assurance control
9. Project human 9.1 Develop human 9.2 Acquire project
resource management resource plan team
9.3 Develop project
team
9.4 Manage project
team
10. Project 10.1 Identify 10.2 Plan 10.3 Distribute 10.5 Report
communications stakeholders communications information performance
management
10.4 Manage
stakeholder
expectations
11. Project risk 11.1 Plan risk 11.6 Monitor and
management management control risks
11.2 Identify risks
11.3 Perform qualitative
risk analysis
11.4 Perform quantitative
risk analysis
11.5 Plan risk responses
12. Project 12.1 Plan procurements 12.2 Conduct 12.3 Administer 12.4 Close
procurement procurements procurements procurements
management
(Source: PMI 2008, Table 3-1, p. 43

The structure of the four core courses in project management based on the nine knowledge
areas defined in the PMBOK® Guide is not ideal from a conceptual point of view, but it has
been chosen to allow students to commence their studies at any point in the academic year.
Ideally, study of project management would follow the life cycle or natural progression of a
project from its inception through to its logical conclusion, but that would make it difficult to
commence study at some point other than the course that discusses the beginning of the
project life cycle. MGT8022 provides such a cyclical overview although the other three
courses in the project management specialisation are structured around the knowledge areas.
The four core courses of project management consider the topics listed in table 1.1, and each
course should be studied to gain a comprehensive understanding of the skills and knowledge
required to adequately manage a small to medium project. Table 1.2 illustrates the
relationship between the respective courses and the project management knowledge areas
covered. MGT8022 covers all nine knowledge areas of project defined by the PMBOK®
Guide within a life cycle framework and is ideal as a stand-alone course of study. The other
three courses consider the nine knowledge areas in greater detail. Other specialist courses in
project management provide studies in those areas where research indicates most projects
fail:
● ENG8111 Project requirements management: considers how the scope of the project can
be defined in a way that gains the consensus of all major stakeholders so that only what
is needed is delivered.
● MGT8028 Project tendering and contracting: looks at the options for procurement
strategies that determine the nature of the relationships between key stakeholders, and
which play a major role in how the project unfolds and how conflicts are dealt with.
● MGT8021 Project sustainability management: looks at what is required to sustain the
needs of a project throughout its entire life cycle from the time of delivery up to that
point in time when it is no longer needed and is retired or abandoned.
● LAW8074 Project legal studies: examines those aspects of law that impact on the likely
success of a major project, and how legal relationships can be structured to reduce
conflict and avoid costly delays.
Table 1.2: Relationship between the project management courses
MGT8022 MGT8025 MGT8024 MGT8027
The nature of
projects
Systems and
strategies
Initiating the project
Planning the project
The hard skills of Scope management
project management Time management
Cost management
Managing quality and Quality management
risk Risk management
Procurement
management
The soft skills of HR & organisational

project management management

Communications
management
Integration
management
Monitoring and
controlling the
project
Closing the project
Ethics and
governance
MGT8022 Project-based management is an introductory course and covers all knowledge

areas of project management as defined by the PMBOK® Guide (PMI 2008). It provides
students with a brief overview and can be studied if no other project management courses are
considered. It provides a framework within which study of the other three courses can be
carried out in a meaningful way.
MGT8025 Project scope, time and cost management looks at three of the early knowledge
areas defined in the PMBOK® Guide, and takes a ‘project-centric’ view of what are often
regarded as the hard skills of project management. These are fundamental attributes of each
project, and if managed well, will provide a reasonable chance of achieving project success.
MGT8024 Project quality, risk & procurement management considers more qualitative
aspects of project management. Quality is a dimension of project deliverables as well as of
management processes and project managers must remain vigilant or quality can suffer. All
projects are carried out in a volatile environment of risk, and it must be managed throughout
the entire project life cycle. Procurement is a strategy by which projects are delivered to
sponsors, and is regarded widely as a means of risk mitigation by involving external
stakeholders who are best situated to handle certain risks.
MGT8027 Project HR, communications & integration management considers the

‘softer’ management skills, and looks at the people who are given the responsibility of
delivering the completed project and the organisational structure within which they operate,
while integration management remains the ‘matrix’ by which the complex systems are
managed and the diverse stakeholders are brought together in a cohesive manner.
The focus of these project management courses takes a ‘management’ perspective and
encourages you to develop a strategic perspective on ‘management by projects’, rather than
‘management of projects’. These courses use established theory to provide a framework in
which you can analyse your own projects and develop appropriate management skills.
Students wishing to gain more project management skills at the team member level may
enjoy reading the following practical text:
Burke, Rory 2003, Project management: planning and control techniques, 4th edn,
John Wiley & Sons, Chichester, UK.

1.3 Providing a focus to your studies

Project management is a very wide field with many sub-fields that you can explore when you
have a good understanding of the basic principles. Disciplines such as information systems
often refer to ‘agile’ or ‘six-sigma’ project management. Defence often refers to its project as
‘complex’ and there are now studies in complex project management. There are proprietary
project management methodologies such as Prince2 (developed by the Office of Government
Commerce in the United Kingdom), as well as others developed by government bodies in
Australia and overseas (such as the Queensland Department of Main Roads and the
Tasmanian Government). They are all variations on a common theme, and the project
management courses at USQ focus on the generic principles which will allow you to evaluate
proprietary methodologies to determine if they are appropriate for the needs of your project
and your organisation. For this course, focus on the requirements of the assessment items and
that will help you to place a boundary around your studies and readings so that you can
complete your studies in a reasonable time frame. Focus specifically on your selected project
and the context of that project.
1.4 What is a project?

For convenience much of the study materials of the project management program is based on
the Guide to the project management body of knowledge(PMBOK® Guide) that is produced
by the Project Management Institute (PMI) in the USA, and which defines a project quite
simply as:
A project is a temporary endeavour undertaken to create a unique product, service, or

result. The temporary nature of projects indicates a definite beginning and end. The end
is reached when the project’s objectives have been achieved or when the project is
terminated because its objectives will not or cannot be met, or when the need for the
project no longer exists.
(Source: PMI 2008, p. 5)
Stretton (1983) describes a project as having the following characteristics:
Unique: A project is usually a one-off, one time, specific undertaking with a single set of
clearly defined objectives; it is rarely, if ever, repeated.
Finite: It has a definable start point, a finite duration and a definite end point at which it
can be said to be completed and its objective accomplished.
Multi-disciplinary: It requires the involvement of many different disciplines and for the
most part is also multi-organisational. Different mixes of disciplines, functions,
resources, trades and other specialisations must be brought together to focus on the
achievement of the objective of the project.
Complex: The targets set by the project are often complex and for the most part very
technical, often seeking to achieve levels of technical performance not yet met elsewhere.
Dynamic: In a project the unexpected is always happening; new problem situations must
be addressed when they arise, rather than in some periodic manner.

High risk: Project performance goals usually involve high technology development and
computer programming that require extensive testing and proving. Overall the time
schedule and cost over-run probabilities are high.
(Source: Stretton 1983)
You will also come across the term ‘program management’ and ‘portfolio management’. A
program is defined by the PMI (2008) as a group of related projects managed in a
coordinated way and usually include an element of ongoing activity. Think of a program as
having a longer term, strategic direction. It may also not be finished. These strategic
objectives are achieved by completing a portfolio of individual projects. Don’t get caught up
in the definitions of such terms as there is little agreement within the project management
discipline.
A classification of projects using technological uncertainty and program/project management

scope is illustrated in figure 1.1 below. Figure 1.2 illustrates the relationship between
uncertainty and complexity in a range of typical projects.
Figure 1.1: Project classification
(Source: Wideman & Shenhar 2001, colour enhanced by USQ.)

Figure 1.2: Complexity-uncertainty relationships in projects
(Source: Hamilton 1997, p. 68, colour enhanced by USQ.)
1.5 How does project management differ from general

management?
Figure 1.3 highlights the differences in the management environment that you will find in the
projects and operation processes.
Figure 1.3: Differences in environment between general management and project management

In the course of development, project management has developed into a complex multi-
disciplinary profession; it has drawn considerably on the body of knowledge built up by
other disciplines and professional areas of management. The way in which the relevant
bodies of knowledge have been drawn on in the practice of project management is shown in
figure 1.4.
Figure 1.4: Areas of expertise needed by the project team
(Source: PMI 2004, figure 1-2, p. 13, colour enhanced by USQ.)

1.6 What is project management?

Significant projects have occurred throughout human history, especially related to the
development of agriculture, transport and society. Kwak (2003) suggests that:
Project management has been practiced for thousands of years since the Egyptian era,
however, it has been about half a century ago that organizations start applying
systematic project management tools and techniques to complex projects. In the 1950s,
Navy employed modern project management methodologies in their Polaris project.
During the 1960s and 1970s, Department of Defense, NASA, and large engineering and
construction companies utilized project management principles and tools to manage
large budget, schedule-driven projects. In the 1980s, manufacturing and software
development sectors started to adopt and implement sophisticated project management
practices. By the 1990s, the project management theories, tools, and techniques were
widely received by different industries and organizations
(Kwak 2003, n.p.).
In a broad universal sense, it is suggested that project management is a set of coordinated

processes which utilise a multi-disciplined team to manage available resources to procure a
project from its inception to completion aimed at best meeting the client group’s interrelated
requirements such as scope, risk, time, cost, quality and safety.
Although project management was once predominantly the domain of the Defence and
construction industries which often involve high technology, multiplicity of specialised
providers and complex cybernetic systems, its use is no longer confined to those industries.
Indeed, many industries utilise project management concepts where disparate disciplines,
technologies and skills are combined in one project. Project Management is now often
referred to as the ‘accidental profession’ since most practitioners have had formal training in
many other professions but not necessarily in project management. Most managers therefore
rely on experience and unstructured incidental learning and are often reluctant to adopt
formal techniques as a basis for action where they cannot fully understand what they mean or
how valid they are.
1.7 The project management processes

The management of the project life cycle process should be structured in logical stages,
aligned to the various phases of the project, and separated by major decision points called
milestones or ‘gates’. The process begins with the identification of broadly stated project
mission. Uncertainties and their risk evaluation, system performance, production cost
estimates, life-cycle costs, cost-performance-schedule trade-offs, procurement strategy,
constraints, and risk management should be major considerations at each milestone decision
point, including the decision to continue with the project. Under the PMBOK® Guide (PMI
2008, p. 39), the main project management processes are:
● initiating processes
● planning processes
● executing processes

● monitoring and controlling processes

● closing processes.
The relationship between these processes is illustrated in figure 1.5, and their iterative nature
at each phase throughout the project is illustrated in figure 1.6.
Figure 1.5: Relationship between project management processes
(Source: Hamilton 1997, p. 80, colour enhanced by USQ.)

Figure 1.6: Iterative nature of project management processes
(Source: Adapted from Hamilton 1997, p. 81, colour enhanced by USQ.)
Animation
View animation for figure 1.6.
At the initiation of the project, the appropriate milestones should be proposed by the project
manager and approved by the client group together with the level of decision-making and the
required documentation for each milestone. This proposal should consider such parameters
as the size, complexity, and risk of the project. All these determinations should be re-
evaluated at each milestone in light of then-current project outcomes and conditions.
1.8 The organisational context of projects

Turner (2009) puts project management into the context of the organisation from which the
project is derived. Unless there is some correlation between the finished project outcomes,
and the organisational objectives, then the project success is difficult to establish. The
Sydney Opera House in Australia is an iconic project, but it didn’t meet the objectives of the
original sponsor and end-user, and it is still not regarded by some as an ideal venue for opera.
Nevertheless, it is regarded today as a success, on the basis of its aesthetics, its contribution
to the urban environment, and the financial benefits that occur through tourism.

Figure 1.7: Sydney Opera House
The dimensions of a project should parallel those of the organisation when looking at issues
such as mission, objectives, strategy and goals. In figure 1.8, Gray and Larson (2000, p. 15)
provide us with a diagrammatic model of what they call the ‘Integrated management of
projects’ showing the project gestation from ‘customer’ need through to implementation.
This theme of a project flowing from a simplistic initial concept through a series of stages to
its final implementation and operational state will be referred to frequently in the study and
reference materials in project management. At each stage, human and resources energy will
have to be put into the process to create the changes necessary, and it is the control of these
change processes that defines successful project management.
Figure 1.8: Integrated management of projects

(Source: Gray & Larson 2000, p. 15, colour enhanced by USQ.)
Reading activity
Read the set text Turner, chapter 1, for a review of this introduction to project
management and the organisational context of projects.
1.9 The strategic role of projects

An organisational strategic plan defines the fundamental goals and objectives of projects in
specific terms and provides a basic long-range framework into which all the other forms of
planning should mesh. The strategy-making process should be capturing what the manager
learns from all sources (both the soft insights from his or her personal experiences and the
experiences of others throughout the organization and the hard data from market research
and the like) and then synthesizing that learning into a vision of the direction that the
business should pursue. From that vision flows a series of lower-level processes by which
organisational resources can be used in a way that is consistent with organisational
objectives, and this hierarchy is illustrated in figure 1.9.
Figure 1.9: Strategic project management

(Source: Adapted from Cleland & King 1988, p. 171, colour enhanced by USQ.)
1.10 Project-based management as change management

In keeping with one of the major themes of the USQ Master of Business Administration
(MBA) program, change management is today seen as the major focus of project
management. Organisations need to evolve and respond to their environment and their
objectives, and that requires constant change – sometimes incremental, sometimes
paradigmatic. Project-based management provides a mechanism to focus organisational
resources on a coherent, consistent and effective strategy. Borrowing from recognised
management philosophies such as strategic management, quality management, risk
management and cost management , project-based management provides the integrative
matrix to allow the change to be brought about efficiently and effectively.
Project management as a professional discipline has expanded from a tools-based

management technique for delivering tangible outcomes such as atomic bombs, bridges,
tunnels, spacecraft, etc. to an holistic management philosophy encompassing the
conceptualisation of organisational needs through to the delivery of outcomes and the
through-life support of those deliverables for decades. As Turner (2009, p. 5) indicates, ‘we
do not produce an asset for its own sake: we make it so we can operate it to satisfy some
purpose or produce some benefit’.
A recent spin-off from project-based management is the growth of the change management
discipline which sees itself as providing an expanded role in delivering change as well as
capturing the intended benefits of the change project. Regardless of who is actually the
change agent, adoption of project-based management provides a valuable dimension to
organisations who seek to bring about change in a coordinated way rather than through
chaotic and fragmented activities of disparate elements in the organisation.
1.11 Environmental context of project management

Considering project management as merely delivering a project in terms of cost, time and
performance is far too narrow a view. The external environment is playing a far more
significant role in the success or failure of projects, and the higher the profile or the more
advanced the technology, the more significant the process of managing this external
environment.
Predictions for the rise and fall of economic cycles, changes in fiscal policy, interest rates,
end user preferences etc. are difficult to forecast over long periods of time and once a project
has commenced it is either impractical or difficult to change its scope without incurring cost
and other penalties. Environmental analysis often takes place within a PESTLE structure as
indicated in figure 1.10 and using criteria such as political, economic, socio-cultural,
technological, legal and environmental/ecological.

Figure 1.10: An environmental scan
(Source: Archibald 1992, p. 40, colour enhanced by USQ.)
Reading activity
Read the set text Turner, chapter 2, for a review of the strategic role of projects
and project management as change management.
1.12 Project management outcomes and success?

Rarely is a project an outright failure – in most cases it comes down to the determination
(often subjective) of whether the marginal difference in outcome between that specified and
that achieved in practice is a significant draw-back in the achievement of organisational
goals. Early writers tended to view the overall success or failure of a project as consisting of
the joint achievement, or not, of all of the three factors: performance, time and cost. This
meant that, as most projects experienced time and cost over-runs, there was a perception of
project failures. This tended to suggest that meeting these three criteria was a poor measure
of success, leading to research being conducted to find more appropriate alternatives. The
problem that confronts us is finding out what the user actually wants and producing it, in an
environment where the user is likely to change their mind. The solutions to these problems
lie in effective scope and communication management, but you need to understand that they

can have a direct impact on the achievement of project success. In an ideal world, a project’s
scope would be agreed at the start and there would be no changes. In the real world,
however, this is not the case and changes seem almost inevitable. A change management
mechanism is an essential component of a project plan. The mechanism must be such that
scope creep cannot occur and the project cannot get out of control. On the other hand, it must
allow the user to change their mind, or user dissatisfaction is likely and, based on the
definition above, project success put at risk. Another definition of project success is
proposed as follows:
Projects succeed – or fail – in direct proportion to how well they meet – or fail to meet –
the evolving expectations of significant project stakeholders, in the areas of cost,
schedule, technical performance and politics.
(Source: Baker 1997, p. 26)
Reading activity
Read the set text Turner, chapter 3, for a review of strategies for project success.
1.13 Project stakeholders

As part of the environmental analysis, the project manager must consider the relevant
stakeholders and their likely level of influence over the project outcome. Many stakeholders
will be supportive of the project and will represent opportunities to be ‘exploited’ by the
manager. However, the interests of many stakeholders won’t necessarily align with those of
the project, and may well be diametrically opposed to them.
There is not always consistency in the use of the terms to categorise stakeholders and they
will vary from organisation to organisation, and from project to project. What is important is
to recognise that there are many individuals and organisations with vested interests in the
project, and those interests are not always in line with those of the project manager.
Cleland (1999, p. 167) gives a comprehensive listing of stakeholders in at typical project as

set out in figure 1.11, putting them into concentric groups to represent the diminishing level
of significance or responsibility.

Figure 1.11: The project stakeholders
(Source: Cleland, 1999, p. 167, colour enhanced by USQ.)
Stakeholders are often able to use their positions of power to influence the progress and
outcome of the project. Project managers must recognise that project objectives and
organisational objectives of the respective stakeholders don’t always coincide. Stakeholders
can often be on different sides of the fence, and the objectives of one group of stakeholders
may be to ensure that the project does not proceed, or does not succeed. This is where the
project manager’s role becomes challenging. Does the project manager implement a project
that is knowingly detrimental to the interests of some stakeholders? Think of the Ok-Tedi
mine and current concerns about the long-term implications of coal-seam gas operations. Just
because a stakeholder lacks power or authority does not diminish their rights and interests.
Reading activity
Read the set text Turner, chapter 4, for a review of the significance of project
stakeholders.

1.14 The international context of project management

Considering project management in a global context, it may be necessary to consider the
particular professions and the legal framework of the respective countries, including the
following:
● Those countries practising under US methodologies which include Canada, much of the
Middle East and Gulf regions, South America and parts of Africa. In these situations
project management is readily accepted in principle and clearly understood. Many major
defence projects are USA influenced in methodologies.
● Commonwealth and former British colonies practising under UK methods, including
Australia, New Zealand, parts of Africa, where generally, whilst there is a demand for
project management, there is also a reluctance by established professions to accept it as a
legitimate form of management in its own right.
● European countries where project management concepts and roles of the participants are
modified to mesh with the national and professional backgrounds and cultures of the
individual countries. For example, the Swedish Byggledare system operates where
independent professional firms work for a fee and provide design, budgeting and
management expertise. Some of these organisations also offer management contracting to
provide an implementation capacity.
● Developing and third world countries, in particular in the development of infrastructure,
where project management has been adopted as a solution due to such projects generally
being implemented by international corporations and due to the basic lack of indigenous
management expertise.
Reading activity
Read the set text Turner, chapter 19, for a review of the international context of
project management.
Conclusion
We have now looked at projects in their broader context as a means to bringing about
organisational change, from conceptualisation to completion. The issues that we have looked
at provide a framework within which we can better understand the inter-relationships
between the respective project phases and management processes.
Reference list
Archibald, R 1992, Managing high technology programs and projects, 2nd edn, John Wiley,
New York, USA.

Baker, B 1997, ‘Great expectations: turning failure into success – and vice versa’,
PMNetwork, vol. 11, no. 5, pp. 25–8.
Burke, R 2003, Project management: planning and control techniques, 4th edn, John Wiley
& Sons, Chichester, UK.
Cleland, D 1999, Strategic design and implementation, 3rd edn, McGraw Hill, New York.
Cleland, D & King, W 1988, Project management handbook, 2nd edn, Van Nostrand
Reinhold, New York, USA.
Gray, C & Larson, E 2000, Project management: the managerial process, Irwin/McGraw-
Hill, Boston, USA.
Hamilton, A 1997, Management by projects: achieving success in a changing world, Thomas

Telford, London, UK.
Kwak, Y 2003, 'Brief history of project management', in Carayannis, Kwak & Anbari (eds),
The Story of Managing Projects, Quorum Books,
<http://home.gwu.edu/~kwak/PM_History.pdf>.
PMI 2008, A guide to the project management body of knowledge (PMBOK® Guide), 4th
edn, Project Management Institute, Newtown Square, Pennsylvania.
Stretton, A 1983, ‘Distinctive features of project management: a comparison with

conventional management’, Transactions of the Institution of Engineers, Australia, vol. GE7,
no. 1, pp. 15–21.

organisations, 3rd edn, McGraw Hill, New York.
Wideman, RM & Shenhar, AJ 2001, ‘Professional and personal development management: a

practical approach to education and training’, in J Knutson (ed.), Project management for
business professionals: a comprehensive guide, John Wiley & Sons, NY.

Module 2 – Systems and strategy
Objectives
● relate small to medium projects to systems theory, both as self contained systems, and as
part of a larger organisational system and a social system,
● establish the level of complexity and uncertainty related to a chosen project,
● develop an appropriate life cycle model based on systems theory for a chosen project,
clearly identifying the various stages or phases of the life cycle,
● apply various project management bodies of knowledge to your selection of an
appropriate project management methodology for managing a chosen project,
● identify appropriate tools and software to assist in the management of a chosen project,
● identify sustainability issues relating to a chosen project, and incorporate consideration
of those issues in the management of the project, and
● relate the project to organisational strategies in order to achieve corporate aims and
objectives.
Learning resources
Text
organisations, 3rd edn, McGraw Hill, New York – chapter 1 (pp. 9-17).
Selected readings
Selected reading 2.1: Nicholas, JM 2004, Project management for business and
engineering: principles and practice, pp. 51-9.
Selected reading 2.2: Crawford, L 2011, 'Comparing apples with apples: Aligning project
management capability with corporate strategy’.
Note: References will also be made to sections of the Guide to the Project Management
Body of Knowledge (PMBOK® Guide) (PMI 2008) which is available online through the
USQ Library eBooks. Reading these sections of the PMBOK® Guide will assist your
understanding of the topics.

2.1 Introduction
Audio
Listen to audio
Project management text books have rarely considered the broader systems view of project
management until recently. It is now common for project managers to be encouraged to step
backwards and understand the internal and external environment in which the project is
being managed. There are many issues that could adversely affect the project outcomes, and
many of those are not visible when the project is being commenced. Situations will
undoubtedly arise that will affect the inputs to the project management processes and in turn,
affect the outputs or outcomes in some way. If the project manager has a broader, more
flexible perspective on the project, such changes in the project environment are unlikely to
threaten the success of the project.
The set text by Turner (2009) does not cover the systems view of project management very
well for our purposes. Selected reading 2.1: Nicholas 2004 is from a different project
management textbook and provides a view on systems theory and how it applies to the
management of projects.
We also examine in more detail how projects fit into their organisational context. From a
strategic point of view, we again look at how project objectives must align with the
objectives of other parts of the same organisational system, and how good principles of
governance require project managers to act responsibly in the interests of the major
stakeholders.
2.2 Systems theory

As Nicholas (2004, p. 52) indicates that a system can be quite simple or extremely complex
and defines a system as ‘an organised or complex whole; an assemblage of things or parts
interacting in a coordinated way’. It can be visible, like a motor vehicle, or nebulous, like an
organisation. A system is generally defined by its inputs, process and outputs as illustrated in
the simple diagram in figure 2.1.
Figure 2.1: Input-process-output system model
(Source: Nicholas 2004, p. 56)

In a motor vehicle, the inputs, the processes and the outputs are easy to identify and observe,
and can be quantified. On the other hand, identifying the inputs, processes and outputs of a
large organisation can be quite difficult. If we accept that a project can be regarded as a
system, then the level of complexity of that system will reflect the complexity of the project
environment and objectives. Figure 2.2 provides a typology of projects, considering the level
of uncertainty in time, cost and performance, relative to the level of complexity expressed in
cost-time (labour hours). We have seen this structure previously in a diagram in module 1,
but we can now visualise the projects in terms of the complexity of inputs, processes and
outputs required to achieve the objectives. The inputs and processes required to complete an
assignment for this course is far simpler than the inputs and processes required to put a
manned space vehicle on Mars and safely return all astronauts to Earth.
Figure 2.2: Typology of projects
2.3 A systems view of projects

A simple system for any specific project can be represented as a static model of its
components as in a hierarchical structure such as a Work Breakdown Structure (which we
will discuss in more detail in a later module on scope management), or as a dynamic model
of the components and the inter-relationships such as in a project network (which we will
discuss later when we look at time management), as illustrated in figure 2.3.

Figure 2.3: Project system models
If we place a technical project into its internal and external environment, the static systems
model includes consideration of the technical matters, the organisational or institutional
setting, and the broader environmental issues as suggested in figure 2.4.
Figure 2.4: Systems view of a technical project
Reading activity 2.1

Read selected reading 2.1: Nicholas 2004, for a more detailed view on the
application of systems theory to project management.

Nicholas (2004, p. 65) suggests we consider a systems approach as a framework for problem
solving:
The systems approach is a framework for conceptualising problems as systems and

doing things – such as solving problems and designing systems. The framework utilises
systems concepts such as elements, subsystems, relationships and environment. The
systems approach formally acknowledges that the behaviour of any one element may
affect other elements and no single element can perform effectively without help from the
others. This recognition of interdependency and cause-effect among elements is what
most distinguishes the systems approach.
In project management, it is important that we see the bigger picture – the holistic view of
our project – rather than just focus on the deconstructed components. We must always
remember that our project is part of a bigger system, the organisation, which in turn is part of
a larger system, society, and so on. At the same time, we must be able to identify manageable
components of our system. This is part of the dilemma of project management.
2.4 A systems model as project life cycle

If we now consider the view from figure 2.4 as a more dynamic model incorporating typical
project management processes such as conception, definition, execution and operation, we
have created what is called a life cycle model of a project as shown in figure 2.5.
Figure 2.5: Systems development cycle
There are many different life cycle models for projects which reflect the different project
types, the environment in which they are managed, and the organisational methodology
chosen, so each one of these can be represented by a different systems model. Some of these
models have been formalised by a specific project management methodology such as those

suggested in the PMBOK® Guide (PMI 2008) and as detailed in PRINCE 2 (which stands
for Projects in Controlled Environments).
For this course, it is not essential for you to have a strong understanding of such
methodologies, but it is important for you to know that there are many different models, and
that, as the project manager, you are able to see how a methodology might be suitable or not
for your project.
A complex methodology like PRINCE 2 is resource intensive, and is used by many Defence
organisations for complex projects, but for small or simple projects, it might be
inappropriate.
2.5 The project life cycle

Although projects can come from different industries, be of varying lengths and have a wide
range of costs, they all have life-cycles that proceed from some form of conceptual
consideration to a project termination, via a definition and execution process. You will find
that some industries talk about four phases or stages, others have five or more. The text by
Turner (2009, p. 10) refers to a basic five stage model whereas there are numerous models to
reflect the circumstances and environment of each project.
Because it is useful to understand how a project arises and develops over its life span, and to
orient the management activities across recognisable steps, four separate project stages have
been suggested in the discussion below. However, remember that the life cycle of each
project is determined by the nature of the project and the circumstances under which it is to
be managed. If organisational policies mandate approval prior to the commencement of each
stage, then a fast-track life cycle with overlapping stages will not reflect the project’s
circumstances. Projects are not able to be forced into a preferred model of a life cycle – the
project dictates the life cycle model that is relevant, regardless of personal preference. There
may be a life cycle model proposed by the theory that fits the circumstances of your project,
or there may not, and there is nothing to say that your project can’t have many more stages
than what is suggested below.
Conception: In this phase the identification and broad statement of the requirement are
produced. The stage can begin at any time but usually starts with the formal acknowledgment
in the organisation that a new operational need has arisen. The conceptual phase includes the
justification of the need for the project and its ranking in priority with other needs of the
organisation. The end of the conceptual stage is signified by the acceptance of the project
into a program of action. This may well be the most important stage as it is common for
organisations to deliver a project on time and within budget, but to deliver the wrong project.
The adverse impacts on the organisation may not be realised for some time after completion,
at which time the major stakeholders have moved on, leaving the sponsor with a project
deliverable of little if any value.
Definition: This encompasses the detailed definition of the requirement. It begins with the
inclusion of the project in the program and may conclude with the letting of contracts (where
this is relevant). It is called the definition stage because it consists primarily of defining the
new requirements in operational and technical terms, tendering and assessment, and the
development of contractual agreements. This is where the project manager defines what is

delivered, and what is not delivered (just as important), and stakeholder consensus on this
point is critical for project success.
Realisation: This is the broad (and perhaps longest) stage where the new requirement is
achieved, delivered into operation, and the change benefits realised. This is where the ‘proof
of the pudding is in the eating’.
Completion: This is the transitional stage whereby the project user or sponsor accepts
responsibility for the completed project and the project manager’s role often finishes. Other
stakeholders generally take over the project deliverable and provide support and sustainment
throughout its useful life.
Some points that should be noted about the project life-cycle:
● The phases or stages are not discrete; unless an organisation has a project management
methodology that has formal approval steps, there need not be an obvious point where
one can say ‘the concept phase is complete, we are now starting the definition phase’.
Projects can and do go backwards - for example problems with detailed definition can
force a rethink of the concept.
● The ability to make changes to the project and the cost of making those changes vary as
the project proceeds. The ability reduces considerably as the project moves through the
respective life cycle stages, and the cost of making those changes increases considerably,
as illustrated in figure 2.6.
● This is clearly illustrated in the case of software development where the concept phase is
followed by the definition, construction and evaluation phases – best illustrated by a
spiral. The initial concept, including conceptual design, proof of concept and risk
analysis, is succeeded by a loop containing logical design, build and evaluation steps, a
loop containing physical design, build and evaluation steps and a final design, build and
test loop.
● Note that what is being described here is the life-cycle project of the actual project; quite
often the project manager is not appointed until a considerable amount of concept and
perhaps even definition work has been done.
● To avoid confusion in other courses, you need to understand the difference between a
project life-cycle and a product or system life-cycle. A project life-cycle commences with
a concept phase and ends when the system is commissioned; a product or system life-
cycle commences with a concept but does not end until the system is retired from
operational service.

Figure 2.6: Potential to add value and cost to change
(Source: Adapted from Burke 2003, p. 34, colour enhanced by USQ.)
Reading activity
Read the set text by Turner, chapter 1, pages 9-17, for an overview of project
life cycles and organisations.
Reading activity
Access the PMBOK® Guide from the USQ library (PMI 2008) and read chapter
2, for more views on the relevance of project life cycles to the management of
projects within organisations.
2.6 Global project management bodies of knowledge

You will come across numerous project management bodies of knowledge (or BOK). The
most well known BOK in Australia is the Guide to the Project Management Body of

Knowledge (or PMBOK® Guide) produced by the Project Management Institute (PMI) in the
1980s and revised a number of times. The PMBOK® Guide provides comprehensive
guidelines for processes by which projects can be effectively managed, and knowledge areas
which provide a comprehensive understanding of the dimensions of project management
(e.g. time management, scope management, etc). The current version is the fourth edition
published in 2008 and further revisions will take place on a regular basis. The PMBOK®
Guide was used by the Australian Institute of Project Management (AIPM) (or Project
Management Forum as it was known then) to produce the Australian National Competency
Standards for Project Management (NCSPM) in the 1990s. They have been revised
periodically and are now managed as Australian Standards. In the United Kingdom, the
Association for Project Management (APM) has developed its own BOK, as has the Project
Management Association of Japan (PMAJ) with its A Guidebook of Project & Program
Management for Enterprise Innovation.
There is no single BOK which represents all of the knowledge in the project management
domain, and there is no single authority which represents project management. The total
body of knowledge is spread across the world among all of its practitioners and is added to
constantly through research by practitioners and academics.
2.7 Project management methodologies

A methodology is different to a body of knowledge (BOK) as discussed above. A
methodology illustrates a system by which inputs, processes and outputs are articulated, and
may be defined as:
‘a system of recognized project management processes and practices, targeting to

enhance project effectiveness and increase chances of project success, applied in a
coherent and coordinated way to obtain benefits not available from employing them
individually. Project management methodologies may include logics, structures, tools,
techniques and methods outside the discrete processes in the methodology’
(Vaskimo 2011, p. 5)
An example of a methodology is Prince2 (Projects in Controlled Environments – Version 2)

which was developed in the United Kingdom and is now distributed by the Office of
Government Commerce (OGC) on a commercial basis. For organisations that do not want to
spend time and resources to develop their own methodology, Prince2 provides an off the
shelf solution. The Tasmanian Government has developed a comprehensive methodology for
managing projects and makes resources available (mostly at no cost) for individuals and
organisations interested in managing their projects in a more effective manner.
A project management methodology provides a strategy for managing projects within a

particular environment. It will reflect the internal and external environments within which
the project is managed. Internal environmental issues will include governance structures,
project management maturity of the organisations and the individuals in the project team,
importance of the project to the organisation (does it have the potential to adversely affect
the corporation’s survival), availability and timing of funding, etc. External environmental
issues will include the political climate, dependence on external stakeholders to provide key
components, availability of technology, availability of external resources, financial climate,
etc.

Each organisation will choose an off-the-shelf methodology (e.g. Prince2) or develop its own
in-house methodology, or a combination of the two. There is no correct, nor incorrect,
methodology. Selection of an appropriate methodology will allow the project to proceed
more smoothly in a less risky environment, and contribute to the likelihood of a successful
outcome. The framework of a typical project management methodology can be represented
as a matrix looking at the project life cycle stages mapped to the major dimensions of a
project such as cost management, risk management, quality management, etc as illustrated in
figure 2.7.
Figure 2.7: Construction project management methodology
(Source: Morris 1994, p. 178, colour enhanced by USQ.)
2.8 Project management tools and software

The basis of any methodology is to provide tools and templates so that project team members
within an organisation can undertake the management of projects on a consistent and
previously agreed basis. This avoids confusion and allows governance committees to
compare and oversee projects in an efficient manner. Prince2 provides a lot of tools to guide

project managers, but they can be unnecessarily complex for simple projects. Many
organisations develop their own tools and templates to suit the organisational environment
and the nature of projects that they manage. Templates will be available for the development
of a project charter, a business case, and a project management plan (PMP). Tools will be
available for a range of activities which might include scheduling, budgeting, risk
identification, procurement strategy selection, etc.
2.9 Project management sustainability

Contemporary project management places a high value on sustainability. Consideration of
issues that relate to sustainability may include the following:
● Whether to undertake a project or not given it will consume organisational resources of

various types,
● The selection of one project solution over other options given the demand on internal
resources (human or financial),
● The selection of one project solution over other options given its need to consume
external physical resources (e.g. various forms of transport or communication),
● The nature of the solution (e.g. unmanned space flight versus manned space flight),
● The nature of resources required and the consumption of energy resources (e.g. curtain
wall glazing to a high-rise building versus solid heat-resistant materials),
● In-house versus outsourcing to commercial providers (delivery and distribution systems,
private versus public medical facilities),
● The need for ongoing consumption of resources (e.g. solar energy versus air-
conditioning).
The list is endless but project management has a long history of evaluation of alternative
solutions to achieve project outcomes. Selection criteria include multiple dimensions, many
of which are weighted heavily towards sustainable solutions from both an organisational and
a societal perspective. A later module considers the ethical and moral dimensions of project
management which add to the challenges that confront project managers of today.
2.10 The systems view of project strategy

We can define project management in technical terms – achieving project objectives on time
and within budget etc., but that takes an extremely narrow view of project management.
As we have discussed above, project management is really a much broader responsibility

than implementing some processes and undertaking some activities that have been defined by
others. To achieve its greatest potential to ‘value add’ to an organisation, project
management is about strategic management. Senior executives and boards of directors are
required to take a broader systems perspective on the ‘management’ of a company, and are
advised to avoid the ‘nuts and bolts’ of the day-to-day management in favour of the ‘bigger
picture’. They are required to have an holistic view of the organisation, of the stakeholders,
and of the community – professional or social – in which they operate. From this perspective
they will develop the strategies necessary for effective and responsible management of the

organisation, and to integrate that strategy into a systems view of the governance of the
organisation as indicated in figure 2.8.
Figure 2.8: Strategic portfolio management and the enterprise program management framework
(Source: Williams & Parr 2004, p. 20)
From those organisational strategies, senior management will identify a range of

undertakings that are aligned with, and central to, achievement of those objectives. From that
‘portfolio’ of activities, they will identify specific opportunities that can be quantified and
defined – in other words, programs – from which even more specific activities – projects –
can be identified and carried out, as illustrated in figure 2.9.

Figure 2.9: Hierarchy of objectives, strategies and projects
(Source: Archibald 2003, p. 9, colour enhanced by USQ.)
Research by Crawford (2011, p. 10) clearly indicates ‘a relationship between the importance
of strategy to an organization and the breadth of project management practices they
implement’. She concludes that:
This supports the proposition that project and program management are vehicles for the
delivery of strategy in organizations. Overall, the more critically important all or some
of the three strategies, Operational Excellence, Customer Intimacy and Product
Leadership are to an organization, the wider the range of project management practices
they are likely to implement’
(Crawford, 2011, p. 10).
To put it simply, project management is closely aligned to, and forms an essential part of,
strategic management, if given sufficient scope to contribute to the identification and
definition of organisational opportunities. When this role is considered, it is easy to see how
a project office (a dedicated section of the organisation with expertise in the management of
projects) can make a significant contribution to the organisation that it serves.

Reading activity
Read selected reading 2.2, Crawford 2011 for details of research into the
alignment between project management practices and delivery of strategy within
organisations.
Conclusion
This module has provided an introductory examination of systems theory, and how it applies
to project management. It identifies the need to examine the project inputs, the processes to
be established to deal with those inputs, and the system outputs which should represent the
desired objectives of the major stakeholders.
This module has also emphasised the need for an organisation to maintain an enterprise-wide
perspective for identifying and achieving organisational objectives, and to see project
management as one component of portfolio management, if all objectives are to be realised
in an effective manner.
In the same manner that senior figures in a large organisation are required to demonstrate
good governance of that organisation at all times, project managers are under constant
scrutiny that they have provided good governance of their projects. It is no longer a defence
by the project manager that he/she was acting under instructions. If project managers wish to
represent themselves as ‘professionals’ in a competitive world, then it is essential that
professional skills and expertise are brought to bear on all aspects of the project, and not just
on the ‘hard’ skills relating to time and money.
Reference list
Archibald, R 2003, Managing high technology programs and projects, 3rd edn, John Wiley
& Sons, New Jersey, USA.
Crawford, L 2011, 'Comparing apples with apples: Aligning project management capability
with corporate strategy', paper presented to IPMA 25th World Congress – Brisbane,
Queensland, 2011, Brisbane, Australia, 9-12 October.
Nicholas, JM 2004, Project management for business and engineering: principles and
practice, 2nd edn, Elsevier Butterworth-Heinemann, Burlington, USA.
PMI 2008, A guide to the project management body of knowledge (PMBOK® Guide),
4th edn, Project Management Institute, Newtown Square, Pennsylvania.
Vaskimo, J 2011, 'Project management methodologies: an invitation for research', paper

presented to 25th IPMA Global Congress, Brisbane, Australia, 9-12 October.

Williams, D & Parr, T 2004, Enterprise project management, Palgrave, Macmillan,

Bassingstoke, UK.


Module 3 – Initiating the project
Objectives
● define the steps and processes necessary to move the project forward from a conceptual
idea to a meaningful change management project
● develop an initial project charter for sponsor decision-making so that more detailed
investigations can be undertaken
● develop business cases necessary to ensure the project is consistent with the sponsor’s
objectives and goals
● define the scope and nature of the proposed project to allow more detailed planning to
take place for sponsor commitment.
Learning resources
Text
organisations, 3rd edn, McGraw Hill, New York – chapter 11, pp. 235-41.
Selected readings
Selected reading 3.1: McKeever, C 2006, 'The project charter – blueprint for success',
Crosstalk - The Journal of Defense Software Engineering, January, pp. 6-9.
Selected reading 3.2: Gambles, I 2009, Making the business case: proposals that succeed
for projects that work, Gower Publishing Limited, Farnham, UK, chapter 1, pp. 1-20.
Selected reading 3.3: Williams, D & Parr, D 2004, 'Strategic portfolio management', in
Enterprise project management: delivering value, Palgrave Macmillan, Basingstoke, UK, pp.
18-30.

3.1 Introduction
Audio
Listen to audio
In module 2, we looked at project management as a systems approach to managing change in

organisations. We examined well-known aspects of project management such as life cycles
and methodologies and how they fitted in to the systems approach.
In this module, we examine the early stages of the project life cycle and how initial
conceptual projects for organisational change can be developed and nurtured so that the end
project and the final outcomes are consistent with what the sponsor originally anticipated.
We look at the well-known processes defined in the Guide to the Project Management Body
of Knowledge (PMBOK® Guide) (PMI 2008), and those early outcomes that happen to be
defined by different names in different sectors or countries. The preliminary project brief
from the sponsor is articulated as a project charter to ensure agreement in broad terms, and
this charter progressively develops through various iterations of business cases, feasibility
studies, viability studies, project management plans, etc.
The terminology will change from organisation to organisation as will the processes and
steps, but that is not important. The constant affirmation that the intended project outcomes
are consistent with the sponsor’s expectations is critical, and this approach will continue
through the detailed planning stages discussed in the next module, and during the
implementation stages as well.
3.2 The project management processes

Figure 3.1 is from the PMBOK® Guide (PMI 2008) and shows the relationship between
project management processes and stakeholders, and the various outputs that are generated as
a result of those processes. This module focuses on the early stages of getting a project from
a conceptual idea into some quantitative form and figure 3.1 provides one view of how
projects can be initiated and developed, but it is unlikely to suit all project sponsors. Some
sponsors and project managers will develop variations of this approach and document them
as their own internal project management methodologies, or even adopt proprietary
methodologies such as Prince2. We can see how the project sponsor puts forward some form
of business case or statement of work which is considered as part of the initiating process
group which creates a project charter for further consideration and/or revision.

Figure 3.1: Project management process interactions
Figure 3.2 shows a variation on the project life cycle in the form of a flow chart adopted by
the Victorian Government in Australia for their Health Services department, showing how
government policy frameworks, policy objectives and priorities are represented initially in
strategic business cases which are subject to strategic assessment as part of their ‘gateway’
processes. Formal approval by ‘higher authorities’ is required for a project to move from one
stage to the next. The sponsor (DHS) does not use the terminology of ‘project charter’ but
prefers to see the outcomes from each stage as a series of ‘business cases’, moving from a
strategic (or high level) business case to a preliminary business case and eventually to a final

business case. This does remove some of the confusion over the use of terms such as project
charter, project plan, etc. It also focuses the attention of stakeholders in these early stages on
‘business’ criteria rather than on technical or procedure issues. Each project is a business
venture and must satisfy the business requirements.
Figure 3.2: DHS project life cycle
(Source: Capital Projects and Service Planning 2007,

http://www.capital.dhs.vic.gov.au/CapitalProjectLifecycle/)
From the earliest stage, preliminary business cases are developed and expanded as
information becomes available. From these planning and evaluation stages, a final business
case is developed for final decision-making by the sponsor prior to commitment to the
project. The final business case is further developed into a plan that is suitable for

implementation by the project team. In this instance, no mention is made of a project

management plan (PMP), a project implementation plan (PIP) or a project execution plan
(PEP), so we see how different organisations can develop their own ‘lexicon’ or language for
dealing with the management of projects. However this may take place, the principles and
processes generally remain similar.
3.3 The project charter

PMI (2008, p.45) suggests that the project charter is a document that ‘formally authorises a
project or a phase of a project’, and documents ‘initial requirements that satisfy the
stakeholder’s needs and expectations’. There are no hard and fast rules on what constitutes a
project charter and this will vary from organisation to organisation, from country to country,
etc. What is called a charter in one instance may be called a project brief in another. What is
important is that all key stakeholders agree on the need for processes and outputs, consistent
terminology, allocation of responsibilities, levels of authority, steps by which projects can
move from one phase to another, etc. This will be evident in some form of formal or informal
project management methodology which is consistently used throughout the organisation for
convenience, and for risk reduction.
Kloppenborg and Petrick (2004, p.65) suggest that ‘the culmination of the initiation stage is
when a project charter is signed’ and that a project charter is ‘a signed agreement between
the sponsor, who represents senior management and any other senior stakeholders, and the
core team, which publicly commits to completing the necessary work’. I would suggest that it
is a commitment to proceed to the next stage rather than a commitment to complete the
project. Subsequent stages will elaborate on the project to provide sufficient information for
key stakeholders to make the final commitment. They also suggest (p. 65) that elements of a
charter would include:
● The three Ws – why, what and when

● The three Hs – how much, hazards and how
● The four Cs – critical success factors, communication plan, collection of knowledge and
commitment.
Reading activity
Read selected reading 3.1: McKeever, for insights into the value of a project
charter in the early stages of a project.
Suggested reading activity

For the PMI’s view on development of the project charter, you might like to
read chapter 4 of the PMBOK® Guide, pp. 73-8.

Learning activity 3.1

Find a project charter used for a project that you have been involved with and
review how it came about, who was involved, was it signed off or simply used
for information. Can you find one? If so, was it a valued document and referred
to afterwards, or simply forgotten?
3.4 The business case

The Association for Project Management (APM) suggests that the project business case
provides ‘justification for undertaking a project, in terms of evaluating the benefit, cost and
risk of alternative options and the rationale for the preferred solution. Its purpose is to obtain
management commitment and approval for investment in the project. The business case is
owned by the (project) sponsor’ (Association for Project Management 2006, p. 129).
DHS indicates that a Strategic Business Case is the first component of the Business Cases
developed for their projects. They suggest that it ‘should provide sufficient detail to make an
initial determination on the initiative’s strategic fit and suitability for further development’
and that it should provide ‘a preliminary justification for the program or project based on a
strategic assessment of business needs and a high level assessment of the program or
project’s likely costs and potential for success’ and that it should explain:
1. What the project is

2. Why it should be done
3. What options have been considered?
4. How much will it cost?
5. How will it be done?
6. What are the risks?
(Source:http://www.capital.dhs.vic.gov.au/capdev/ProjectProposals/StrategicBusCase/Str
ategicBus/).
This is very similar to the ‘project charter’ that was discussed in the previous section of this
module. Don’t get too caught up in the terminology of what is a business case and what is a
project charter. Focus on the organisational needs and processes to ensure that logical and
valid steps are taken to move the project forward through to a point where key sponsors can
make informed decisions as to whether to commit organisational resources in the form of
finances and staff to proceed with the project.
The business case will form the baseline from which the project planning can proceed. It
defines the parameters and boundaries within which the project will achieve the intended
objectives. There are numerous reports on ‘failed’ projects and information systems projects
are high on the list of these ‘failed’ projects – rightly or wrongly. I suspect that the project
managers are not really to blame and little analysis is provided on whether the failed projects
were defined sufficiently through an appropriate business case by key sponsors prior to
commitment.

The more formal business case contains more quantitative information for decision making
purposes. It may contain what is commonly called a preliminary feasibility study, or what
should be more correctly called a financial viability study. This study will be based on
limited information due to the early stages of the project, but later viability studies will
reflect more detailed information, and these are examined in module 4 as part of the
decision-making related to planning.
Gambles (2009) provides some clear guidelines on the purpose of a business case and how to
go about it.
Reading activity
Read selected reading 3.2: Gambles 2009 ch. 1, for insights into the purpose of
a business case and how to go about developing one. In particular, look at table
1 which provides a good overview of business cases and where they tend to fall
down.
Upon completion, the Business Case should demonstrate that the following objectives have
been addressed:
‘Confirm that the business case is robust – that is, in principle it meets business need, is
affordable, achievable, with appropriate options explored and likely to achieve value for
money.
Establish that the feasibility study has been completed satisfactorily and that there is a
preferred way forward.
Ensure that there is internal and external authority, if required, and support for the
project.
Ensure that the major risks have been identified and outline risk management plans have
been developed.
Establish that the project is likely to deliver its business goals and that it supports wider
business change, where applicable.
Confirm that the scope and requirements specifications are realistic, clear and
unambiguous.
Ensure that the full scale, intended outcomes, timescales and impact of relevant external
issues have been considered.
Ensure that there are plans for the next stage.
Confirm planning assumptions and that the project team can deliver the next stage.
Confirm that overarching and internal business and technical strategies have been taken
into account.
Establish that quality plans for the project and its products are in place.’

(Source:http://www.capital.dhs.vic.gov.au/capdev/PlanningEvaluation/FinalBusinessCase/)

Find a project business case used for one of your projects, preferably one for the
project you have chosen to analyse in assignment 2. Were you able to find one?
If so, does it conform to the guidelines that are suggested above? Who prepared
it? For whom? In what way was it used? Was it a valuable use of organisational
resources?
3.5 Project portfolios

We should also keep in mind that organisations are rarely focused on one project at a time. In
most instances, part of the objective for carrying out a business case is to assist in the
decision making of which project or projects will proceed. Each project competes for
organisational resources, whether finances or staffing, and must demonstrate that it is the
better option to take, or that it is the best fit with other projects to which the organisation has
previously committed as part of a larger strategic framework.
In practice, project managers are often not part of this practice. It is more the realm of project
directors or program managers but it is important to understand the context in which the
project is considered within the organisational framework.
Reading activity
Read selected reading 3.3: Williams and Parr 2004, for insights into the
purpose of a business case and how to go about developing one.
In conclusion, it is of value to read the text by Turner on the project processes leading up to
and forming part of the project stage where the project charter and business case are
developed, and which then lead into the more formal planning stage. In this reading, Turner
looks at the project life cycle, the feasibility study (which we consider more fully in the next
module) and design (which is also considered in the next module).
Reading activity
Read the set text by Turner, chapter 11, pp. 235-41, for an oversight of the
topics discussed above. Turner takes a different perspective and uses different
terminology but this is not a concern. We are interested in the principles of
taking a logical and sequential approach to developing a valid framework for
our project prior to commitment.

Conclusion
This module has looked at the transition of idea or concept through to the point where a
meaningful project or suite of projects has been defined in such a way that the sponsor is
comfortable that the guidelines exist for project management staff to take it forward to the
next stage of planning where a final commitment can be made.
The project charter and the business case, however they may be described or sequenced, will
provide the platform for development of the project management plan, which is also one of
the most important documents that a project manager is required to develop. Strangely, many
projects do not have one. Many organisations tend to adopt a philosophy of ‘get on with it’,
and minimise the stages of planning that are recommended in project management theory. It
can be a frustrating time for all concerned to have a wonderful idea set down in a business
case that appears to be capable of immediate implementation. As history has told us on
numerous occasions, there are no shortcuts to planning and the project charter and business
case are essential tools to allow us to undertake the planning quickly and efficiently.
List of references
Albadvi, A, Farahani, M & Sheykh, MJ 2011, The comparison study of project success
models for extending the excellence in projects, International Project Management
Association, Brisbane, Australia, 9-12 October.
Association for Project Management 2006, Body of Knowledge, 5th edn, APM, UK.
Capital Projects and Service Planning 2007, Capital Project Lifecycle, Capital Projects and
Service Planning, viewed 18 January,
<http://www.capital.dhs.vic.gov.au/CapitalProjectLifecycle/>.
Gambles, I 2009, Making the business case: proposals that succeed for projects that work,
Gower Publishing Limited, Farnham, UK.
Kloppenborg, TJ & Petrick, JA 2004, 'Managing project quality', Quality Progress, vol. 37,
no. 9, pp. 63-8, viewed 20 January 2012
McKeever, C 2006, 'The project charter – blueprint for success', Crosstalk - The Journal of
Defense Software Engineering, January, pp. 6-9.
Project Management Institute 2008, A Guide to the Project Management Body of Knowledge,
(PMBOK® Guide) 4th edn, Project Management Institute, Newtown Square, USA.

Basingstoke, UK.


Module 4 – Planning the project
Objectives
● define an appropriate approach to the planning of a selected project

● identify the required inputs into the planning process
● define the planning processes to be undertaken
● articulate the planning outputs of a selected project
● develop an appropriate project management plan (PMP) for a selected project
● implement the PMP
● develop a simple financial viability study for a selected project.
Learning resources
Text
organisations, 3rd edn, McGraw Hill, New York – chapter 11.
Selected readings
Selected reading 4.1:Burke, Rory 2011, Advanced project management: Fusion method
XYZ – a project methodology systems approach for the project sponsor to implement
corporate strategy, chapter 4.
Selected reading 4.2: Dugdale, D 1991, ‘Is there a “correct” method of investment
appraisal?

4.1 Introduction
Audio
Listen to audio
To date, we have examined the bigger picture of the projects that we are likely to be required
to manage, and placed them into the organisational context to ensure their organisational
‘fit’. We have articulated the expectations of the key sponsors in terms of an initial project
brief or charter, developed guidelines and constraints as to what is to be delivered (and what
isn’t), and put together a project business case as a set of parameters for the following stages
in the project life cycle.
Key sponsors now have firm expectations in terms of what the outcomes will be, when it will
be delivered, how it will be delivered, who will deliver it, what resources will be consumed,
and what benefits will be delivered. In this next stage of project planning, we implement the
business case to provide the essential artefacts to deliver the project. We will define the
organisational unit that has project responsibility, what finances the organisation can afford
to consume, what processes will take place to ensure that the project happens with the least
fuss and the least exposure to risk, and how the end benefits will be measured to demonstrate
project success (or failure as the case may be).
In this module, we will look at what inputs are required to create a comprehensive project
management plan (PMP), what processes must be undertaken, and what the outcomes
provide for further decision-making and implementation purposes.
4.2 Planning inputs

The planning phase sits between a good idea and a giant leap of faith when the project
sponsor places her/his trust in the project manager to commit valuable resources to the
project. The project manager’s reputation and career is on the line. A conceptual idea has
been expanded to a business case based on assumed information and the sponsor now
requires the project manager to develop a plan for implementation. This is a time consuming
stage which requires financial resources to be expended. Depending on the size of the
project, this could represent a considerable sum.
Figure 4.1 indicates how we have moved from the project charter (or business case) through
to the project plan.

Figure 4.1: Project integration steps – a scalable methodology guide
(Source: Adapted from Chapman 1997, colour enhanced by USQ)
The nature and scope of the project is now clear. It has a life cycle form which is determined
by the project itself as well as the internal project management methodology by which it will
be managed and delivered. Approval points (or phase gates as they are often called) define
which activities can proceed based on what level of approvals from higher authorities, and
these are incorporated into our project management methodology which forms part of our
governance process which is discussed in a later module.
Project planning is a challenging phase of the project. The project manager is under pressure
from key sponsors to move the project forward once approval of the project charter and
business case is given. However, these documents were mainly based on assumed
information in the absence of actual data, and the planning stage is time-consuming in that it
requires a vast amount of factual data to be collected, processed, analysed and documented in

such a way that it allows the sponsors to commit to the project with the confidence that the
outcomes will be consistent with their expectations.
The means by which project managers achieve this objective is to develop a comprehensive
document containing relevant information on all aspects of the project that represent some
risk to the project outcomes. The inputs to this process are indicated in figure 4.2 from the
PMBOK® Guide (PMI 2008). Because of the holistic nature of these planning activities,
drawing information from multiple sources and making value judgements on what is the best
balance to achieve project outcomes, this forms part of what is described as project
integration management.

Figure 4.2: Develop project management plan data flow diagram

4.3 Planning processes

Project planning in itself may be seen as part of risk management. Without a plan, the project
team could easily launch into implementation and do whatever they think necessary to
deliver the project. I suspect that many projects are actually managed in that fashion because
of lack of time, lack of expertise or simply lack of knowledge on how to do it any other way.
Each project represents a risk in one way or another to the sponsor.
It could be cost implications that are not anticipated and represent a threat to the
organisation’s survival. This has happened recently when the global financial crisis caused
many property markets to collapse with property projects mid-stream. The projects had to be
either completed at more cost with an uncertain future for their sale, or halted temporarily
until the market improved, adding considerably to holding costs.
It could be performance implications in that the project deliverable does not do what it was
intended to do, or not well enough. Information systems projects often fail with regard to
some functionality. Aviation projects often are not able to do what was expected.
Organisational restructures may be no more efficient than before and revert to previous
models.
The nature of the project and the sponsor expectations will influence the processes by which
the PMP is developed, with the emphasis on the important aspects of the project. The various
elements of the PMP (based around the knowledge areas of the PMBOK® Guide (PMI 2008)
in some way or another), will be developed as indicated in figure 4.2 to create a
comprehensive plan that is suitable for the key sponsors for decision-making on whether to
commit or not. That is the decision that has serious implications for the organisation and is
often referred to as the ‘go/no go’ decision.
Gray and Larson (2000) provide some guidelines for the PMP development process as
follows:
Important planning decisions are made when answering the following project-related
questions:
How will the project plan be developed?
Who will develop the project plan, and how involved will the customer be?
What project management software package will be used, if needed?
Who on the project team will be responsible for entering the planning information?
Who will have input on the plan?
What specifically are the roles and responsibilities of each team member?
How will team members be informed of decisions?
Understanding that cost, time, and quality (performance) are all important, what are the
priorities?
What are the deliverables of the project planning process?

What format is appropriate for each of these deliverables (e.g., milestone charts)
Who will approve and certify at the completion of each deliverable?
Who receives each deliverable?
(Gray & Larson 2000, p. 301)
Reading activity
Read the set text by Turner, chapter 11, pp. 235-245, on the project life cycle
and the design phase.
Turner, chapter 11, pp. 246-263, are optional reading and relate to a discussion
on specific project types.
4.4 Planning outcomes

The main outcome from the planning process is the project management plan (PMP) which is
comprised of many sub-plans relating to the key aspects of the project which influence
project deliverables and performance.
4.4.1 The project management plan (PMP)

However, like many aspects of project management, there is no universal agreement on what
constitutes a PMP. The term may be used in many ways to mean many different things,
country by country, industry by industry. The PMP might be called by many names such as:
● The project plan (PP)

● The project management plan (PMP)
● The project master plan (PMP)
● The project action plan (PAP)
● The project execution plan (PEP)
● The project implementation plan (PIP)
The important issue is that some form of document is produced and agreed to by the project
sponsor and major stakeholders prior to commitment to the major implementation phase of
the project. The PMBOK® Guide (PMI 2008) defines a PMP as a document that defines how
a project is executed, monitored and controlled, and closed (PMI 2008, p. 78). It provides
information on:
● how the project will be managed, as well as

● how the product or service itself will be produced.
The PMP is a consistent and coherent document that is used to

● Guide project execution

● Document project planning assumptions
● Document project planning decisions
● Facilitate communications among stakeholders
● Define key management reviews as to content, extent, & timing
● Provide a baseline for progress measurement & project control.
The PMP development process includes all of the actions necessary to define, integrate, and
coordinate all subsidiary plans into a single document – the PMP – although, in many
instances where the project is of significant size, the PMP may be made up of multiple
documents or of appendices to a parent document.
4.4.2 Contents of a PMP

The contents of a PMP will vary depending upon the application area and complexity of the
project. It is a guide for the definition and control of the work so Barkley (2006) suggests
that it should include:
● control points, for instance, stage-gateway reviews, to ensure that management authorizes
movement from one phase or stage to another
● reporting and monitoring strategies, including the use of earned value to integrate cost,
schedule, and quality performance, which should be made explicit.
It should also include:
The project management processes selected by the project management team
The level of implementation of each selected process
The descriptions of the tools and techniques to be used for accomplishing those
processes
How the selected processes will be used to manage the specific project, including the
dependencies and interactions among those processes, and the essential inputs and
outputs
How work will be executed to accomplish the project objectives
How changes will be monitored and controlled
How configuration management will be performed
How integrity of the performance measurement baselines will be maintained and used
The need and techniques for communication among stakeholders
The selected project life cycle and, for multi-phase projects, the associated project
phases

Key management reviews for content, extent, and timing to facilitate addressing open
issues and pending decisions.
(Source:Barkley 2006)
The PMP has many purposes and is intended for multiple audiences.
For instance the PMP is used as a decision-making document for higher authorities in
governance roles. They will require comprehensive information but only the information
needed for their decision-making processes. This would be presented in a way that is suitable
for that audience and would not contain a lot of technical background information used to
arrive at key recommendations for the sponsor.
A PMP intended for implementation by the project team might not include sensitive financial
data at an organisational level such as financial viability studies.
A version of the PMP might be used to gain financial support for a project from an external
funding source, and is unlikely to contain sensitive (and unnecessary) data relating to the
organisation and the project.
Another version of the PMP might be used to brief project consultants and again,
components relevant to such audiences will be carefully selected.
For ease of reference and to allow the document to be tailored in ways that are appropriate
for the respective audiences, the PMP may contain a higher-order summary (like an
executive summary) with a collation of subsidiary plans which reflect the knowledge areas of
the PMBOK® Guide (PMI 2008) and might include:
● Project scope management plan

● Schedule management plan
● Cost management plan
● Quality management plan
● Process improvement plan
● Staffing management plan
● Communication management plan
● Risk management plan
● Procurement management plan.
Within these sub-plans, there might be more detailed documents including components such
as:
● Milestone list to provide key dates by which events are anticipated or by which progress
must take place to meet other criteria
● Resource calendar to identify and confirm availability of key resources, both physical
and personnel, to achieve deadlines
● Schedule baseline to provide guidance on likely completion dates, or to confirm ability to
meet key deadlines and milestones which may affect things such as approvals, funding,
weather events, opening dates (e.g. Olympics)

● Cost baseline to confirm the extent and timing of financial resources which is critical for
other stakeholders such as project funding authorities
● Quality baseline to establish what is expected and/or required for adequate performance
of the project deliverable
● Risk register to confirm that major risk events have been considered and evaluated.
Development of the respective components of the PMP might be carried out by external
stakeholders with the relevant expertise and knowledge. Much of the technical data will
come from stakeholders who are not part of the internal project team. Discussion about the
specific knowledge areas to be covered by the PMP is covered in subsequent modules in
these study materials.
4.4.3 Structure of a PMP

The actual PMP structure will be determined by the organisational culture and the
methodology that has been adopted. The most important thing is that the PMP is meaningful
for each of its intended audiences. There are no hard and fast rules but an indicative structure
might look like the following:
● Overview or executive summary – a brief description of the project and its deliverables,
and a list of major milestones
● Objectives – a detailed description of the project’s deliverables and outcomes, (Mission
Statement)
● General approach – where technical and managerial approaches are defined
● Contractual - where the procurement process is described, and the specific legal aspects
defined
● Schedule – an outline of all schedules and milestones, using an action plan based on a
WBS
● Resources – estimates of capital and operating expenses.
● Personnel – describing the project work force, and requirements for special skills,
expertise etc.
● Evaluation methods – describing evaluation methods and standards for the completed
project.
● Potential problems – identifying any likely risk events that could adversely affect the
project.
Reading activity
Read selected reading 4.1: Burke 2011, chapter 4, pp. 48-57, for some
additional views on how to develop a PMP and what should go into it.

4.5 Implementation of the project plan

The completed PMP is a blueprint for the following stages of the project. It is comprehensive
and once approved, allows members of the project team to proceed with their respective
responsibilities. Once again, it is normal for a stage gate review to take place with the key
sponsors and stakeholders giving authorisation to proceed as per the PMP, in terms of what
is to be delivered, as well as how it is to be delivered and by whom.
When the relevant higher authority has granted approval, project team members are able to
proceed immediately with the execution of the PMP as set out in the conditions of approval.
This stage of execution, monitoring and control is discussed in a later module of these study
materials.

Find a PMP from your workplace (or from the internet) suitable for analysis. It
should be of an adequate size (but not too large) to allow you to compare the
actual PMP with what theory suggests should be developed to increase the
likelihood of successful project outcomes.
4.6 Project screening and selection

If it has not already happened in the project initiation stage, it is likely that various project
options will be considered as part of the planning stage to arrive at a PMP for the project to
be recommended for approval. Project appraisal is another important aspect of project
management but it is not covered well in project management texts. Unless the project
manager has a reasonable understanding of the criteria by which a project adds value to the
stakeholders, then the emphasis might incorrectly be placed on how to manage, rather than
what needs to be managed. Managing the wrong project well is not necessarily in the
sponsor’s best interests. The project sponsor will expect some form of financial business
case to be included in the PMP to confirm that the project is worth doing.
Detailed examination of financial appraisal of projects is provided in MGT8025 Project

Scope, Time & Cost Management, so the following information in this section is provided as
an introduction only. If you are interested in this side of project management, you should
consider studying some economics courses where financial appraisal is examined in more
detail.
Each proposal must undergo an ever increasingly rigorous process of analysis before gaining
approval to proceed. In the first instance the feasibility of the proposal is examined – is it
possible? If, on the basis of current knowledge, experience and technology, the proposal is
theoretically possible then we must ask the simple question – is it economically viable?

4.6.1 Motives and criteria for project screening and selection

If we consider that there are three major types of project proponent organisations, namely the
government, private and not-for-profit sectors, then different motives and screening and
selection criteria emerge.
● The government sector must seek to meet major political, cultural, social, economic and
educational objectives on behalf of the electorate.
● The private sector must seek to meet major organisational objectives on behalf of the
shareholders, most of which will be value or profitability related.
● The not-for-profit sector consists of charities, social organisations, trade associations
and unions and political organisations. These organisations are usually driven solely by
the needs of their constituents.
Meredith and Mantel (2003, p. 43) indicate that selection and screening models can be
divided into two main categories:
1. non-numeric or qualitative models

2. numeric or quantitative models.
Non-numeric models include (p. 46):
● the ‘sacred cow’ (the CEO’s personal area of interest)

● the operating necessity (compliance with changed regulations and laws)
● competitive necessity (to continue to be competitive in the business sector)
● the product line extension.
Numeric models include (p. 49):
● payback period
● accounting rate of return (ARR)
● net present value (NPV)
● internal rate of return (IRR).
Incremental cash flows
In evaluating a project we are interested only in those actual cash flows that change if the
project is undertaken and these are called the incremental cash flows. The most common
cash outlays considered in the capital budgeting decision are:
● the initial cost of the investment

● incremental operating costs needed for the investment
● maintenance and repairs associated with the investment
● any increase in working capital required to support the investment.
Typical cash inflows associated with the investment decision are:
● incremental revenues from the investment

● resulting cost reductions

● revenues gained from the disposal of the asset or, alternatively, any residual value at the
end of the asset’s useful life if there is no disposal of the asset
● any decrease in working capital that may occur during or at the end of the asset’s life.
Opportunity costs have been defined as ‘benefits foregone by using limited resources for a
particular purpose’ (Horngren & Foster 1987, p. 958). For example a new project could
utilise spare factory capacity and achieve a net cash flow of $2 million per annum. Had the
project not been undertaken such capacity could have yielded a cash flow of $500,000 in the
form of rental revenue. In evaluating the project such benefit foregone should be included.
There are differing and conflicting views on whether interest payments should be included as
part of the cash flows. In a non-discounted analysis, they can be considered as they do not
conflict with the discounting calculations. In a discounted cash flow analysis, it is important
not to include the effect of interest payments twice and understanding the selection of the
discount rate is critical. The calculation of net present value and internal rate of return
automatically considers payment of interest as well as repayment of capital. If interest
payments are included we are double counting.
Cash flow analysis may be carried out pre-tax or post-tax, or both, as the evaluation may
yield different results. Calculation of taxation benefits and liabilities is quite complex, and
should be left to those with expertise in this field.
4.6.2 Traditional cash flow analysis

We have available to us a range of financial assessment tools, ranging from the ‘quick and
dirty’ to the more sophisticated. In this section, we will only discuss briefly four types of
financial appraisal. These are divided into the following categories:
Traditional methods
● Accounting rate of return (ARR)

● Payback method.
Discounted cash flow analysis
● Nett present value (NPV)

● Internal rate of return (IRR).
Accounting Rate of Return (ARR) is sometimes called ‘return on investment’ (ROI). The
method of calculation varies widely, which is in itself a deficiency. Many of these terms are
hardly precise, and this contributes to the shortcomings of the ARR as a precise method of
project appraisal.
Accounting Rate of Return = Profit/Capital Investment × 100%
The Payback Method refers to how quickly the ‘original investment outlay’ is recovered.
Usually annual, after-taxation, net cash flows are divided into the capital outlay and
expressed as ‘years to payback’.

4.6.3 Discounted cash flow analysis

The cost of purchasing a component of our project in the future will most likely be higher
than it is today. If we want to be as accurate as possible in our cash flows, we must estimate
the likely increased future cost (or escalated value) of items and services to reflect this
diminished purchasing power.
If we commit funds today to a project, we are foregoing some alternative opportunity to

utilise those funds, such as a bank deposit, which would earn us interest. We have to ensure
that our chosen project investment increases sufficiently in value to offset that loss of
earnings (called the opportunity cost).
Alternatively, if we borrow funds for our project, we have to repay our borrowings plus some
interest, which is the cost of borrowing capital. Again, we have to ensure that our project
earns us enough ‘profit’ to offset the interest that must be paid when we repay our
borrowings. Future earnings from a project come at a cost, one way or another, and to
compensate for that cost, we reduce (or discount) future earnings to tell us if we made a
‘real’ profit or not, after we have allowed for our costs of investment.
The net present value (NPV) is defined as the present value (PV) of future benefits minus
the present value (PV) of the costs of those benefits. Calculation of the net present value of
an investment (or any form of cash flow) requires knowledge of the following:
● amount and timing of any future cash inflows

● amount and timing of any future cash outflows
● a discount rate (generally expressed as a percentage rate).
Any decisions we make based on net present values must be seen only in the context of the
chosen discount rate, which can be manipulated to influence the outcome (e.g. high discount
rates will substantially reduce the benefit of earnings if they are well into the future – it
distorts the evaluation). If the net present value (NPV) is zero, the project is providing a
return on investment (ROI) equal to the selected discount rate. If the net present value (NPV)
is positive the project will be returning more than the required rate of return.
There are many ways of selecting a discount rate that could be used to discount project cash
flows and determine their net present value. Three common rates are:
● the risk free cost of capital, i.e. the Government Bond Rate
● the marginal cost of capital, i.e. the cost of borrowing the next dollar of capital necessary
to finance the project, or in the case of major projects the cost of finance raised
specifically for the project
● the weighted average cost of capital (WACC), i.e. a weighted average of the capital
structure determined by the organisation’s corporate financial circumstances and
objectives. This takes into account the pro rata cost of borrowings and equity
(shareholders expect a return on investment for equity left in the company as retained
profits as it rightfully belongs to them).
● Organisations sometimes nominate a ‘hurdle’ discount rate that must be exceeded by
the returns of any investment proposal to achieve approval. This may include the interest
rate on borrowed capital, a risk factor, an inflation factor, etc. The key is to be able to
interpret the result of such calculations to ensure that ‘apples are compared with apples’.

The Internal Rate of Return (IRR) is an alternative technique used for making capital
investment decisions that also takes into account the time value of money. The internal rate
of return represents a unique discount rate at which:
the NPV of all the inflows equals the NPV of all the outflows
The main difference between NPV and IRR is that they are measuring different things. NPV
measures ‘profit’ in monetary terms. IRR measures a specific discount rate at which the
NPV is zero, and is expressed as a percentage rate. The use of both NPV and IRR gives us a
better idea than either one alone.
Reading activity
Read selected reading 4.2: Dugdale 1991, ‘Is there a “correct” method of
project appraisal?’ for an overview of investment appraisal. This course does
not focus on financial analysis of projects in any detail, but it is good to gain a
basic grasp of what your project has to achieve to be seen as successful from a
financial or economic perspective.

Find a financial analysis of a project from your workplace or from the internet.
Identify what criteria were set to determine if the project is successful or not.
Are they financial criteria, or are they more qualitative criteria in terms of
performance? How important are financial criteria?
Conclusion
In this module, we have looked at the more detailed planning that is required to verify that
the project is worth doing. The outcome of the detailed examination of all aspects of the
project is a PMP that can be used for decision-making by the key sponsors with confidence
that the outcomes will be similar to those projections within the PMP. It also provides a
blueprint for the project team to implement and execute the project once approval is given.
The following modules look at the various knowledge areas in the PMBOK® Guide (PMI
2008) divided into what we have called the hard skills and the soft skills of project
management as well as an examination of issues related to quality, risk and procurement.
Reference list
Barkley, B.T. 2006, Integrated Project Management, McGraw-Hill, New York.
Burke, Rory 2011, Advanced project management: Fusion method XYZ – a project
methodology systems approach for the project sponsor to implement corporate strategy.

Chapman, J 1997, Project management scaleable methodology guide, home of principle

based project management training site, viewed 23 January 2012,
http://www.hyperthot.com/pm_meth1.htm.
Gray, C.F. and Larson, E.W. 2000, Project management: the management process, McGraw-
Hill/Irwin.
Horngren, CT & Foster, G 1987, Cost accounting, 6th edn, Prentice Hall, New York.
Meredith, J & Mantel, S 2003, Project management: a managerial approach, 5th edn, John
Wiley & Sons Inc, New York.

Module 5 – The hard skills of project management
Objectives
● utilise the relationship between project dimensions of scope, time and cost to establish
the optimal project profile to meet the requirements and expectations of the key
stakeholders,
● define the scope of work that comprises the project, and to clearly define the scope of
work that is outside the project so there is no misunderstanding about what is to be
delivered,
● define the criteria by which successful project outcomes can be measured and confirmed,
● create a simple breakdown structure to aid in defining the project scope,
● relate the responsibility for project activities to appropriate organisational resources,
● identify the strategic aspects of the project time frame which impact on starting times,
milestones and project completion,
● define the implications on the duration of the project resulting from changes to scope and
cost
● create a simple bar chart and network to define the likely project schedule for approval
by higher authorities,
● identify key issues impacting on the likely cost of the project,
● select an appropriate methodology and technique for estimating project costs,
● give appropriate consideration to the through-life costs of the project, and
● estimate the value of the project achieved at any specific point in time during delivery.
Learning resources
Text
organisations, 3rd edn, McGraw Hill, New York – chapters 5, 8 and 9.
Selected readings

5.1 Introduction
Audio
Listen to audio
This is a large module as it considers three highly-visible aspects of a project – scope, time
and cost – so allow sufficient time to read through the module and the chapters of the text.
The topics that will be considered under the concept of the ‘hard skills of project
management’ are quite well covered in your text book by Turner (2009) and you will be
directed towards different topics as we progress through the module. Selected readings have
also been included and add depth to the coverage in the study module and provide different
emphases to that in the text book.
5.2 Hard skills and soft skills of project management

This module examines aspects of managing projects which fit within a common description
of ‘hard skills’ in contrast to other skills which are more difficult to measure, but which
research shows to be more likely to lead to project failure. We will examine these ‘soft
skills’ in module 7.
The hard skills may be seen as process-related and the use of tools, or they may also be seen
as those knowledge areas defined in the Guide to the Project Management Body of
Knowledge (PMI 2008) comprising scope, time and cost management which are more
quantitative or measurable. Scope management looks at what is delivered and what is not.
Each major stakeholder has different expectations about what will be delivered and some are
bound to be disappointed. Time management considers the resource of time – what is the
likely duration of this project, when could it possibly start, and what time constraints exist
(think Olympic Games Opening Ceremony)? Cost management is on the top of most
stakeholders’ list of concerns. What is the estimate of financial resources that are required,
how likely are we to exceed that estimate, and how do we manage the costs to meet
stakeholder expectations? In a simplistic diagram, we can show a relationship between these
three elements of a project. It is difficult to vary one of these three dimensions of a project
without impacting on one or both of the other two dimensions. A bigger project (increased
scope) is difficult to achieve without taking longer (increased time) and requiring more
financial resources (increased cost). Other dimensions could also be considered here such as
quality, performance, risk, etcetera, but for the moment, we will restrict our considerations to
these three. These considerations are the beginning of what we call integration management
– an holistic view of all dimensions of a project – which we will consider in module 7.

Figure 5.1: Scope, time and cost relationship
A disciplined and ruthless project manager can probably manage these dimensions of a
project to meet the constraints, but the final outcome might not meet the sponsor’s needs, and
the project manager will need mastery of the soft skills to interpret those needs and to
manage the scope, time and cost in an appropriate way to achieve the optimal outcome – the
project manager’s dilemma. This module now looks at those three dimensions of:
● Scope management
● Time management
● Cost management.
5.3 Scope management
5.3.1 The importance of planning

The Australian Institute of Project Management (AIPM) (Australian Institute of Project
Management 2010, p. 3) defines project scope and scope management as follows:
The scope of a project comprises a combination of the business planning process and its
outcomes, the end products of the project and the work required to deliver the project
deliverables required using systems thinking to ensure the definition and delivery of the
required project outcomes. Scope management involves the initial justification of the
project through the strategic planning process, the development of the business case,
management of the initial project start-up activity followed up by the ongoing definition
of the deliverables within project objectives and constraints. Project scope forms the
foundation of the project plan, the basis from which all other project specific plans are
developed and is the focus for an overall systems approach to project management.

To satisfy these criteria, a project manager has to first establish the project’s objectives and
deliverables and decide what measurable benefits and outcomes can be used to evaluate
project performance. At the same time, the project manager must decide how scope changes
that are proposed during project implementation are to be managed. Once these aspects have
been decided, the project manager has to get approval from the project’s sponsor or client .
By approving the plan, the sponsor is accepting that the plan’s scope will lead to the
achievement of the objectives and is agreeing to make appropriate resources available to the
project.
Planning is a cornerstone of project management and planning activities can vary

considerably, depending on the type of project and the management environment in which
the project originates and develops.
It needs both the people with the right skills and the availability of the right tools.
Getting started is perhaps the hardest part of planning, or at least it seems to be the major
problem. It begins with gathering all the information that is available about the project,
starting with the operational objectives and the major technical objectives and combining
this with the organisational procedural steps which need to be achieved in order to bring the
project to a successful completion.
Turner (2009) argues that, of the five project objectives he focuses on, scope management is
the principal one as it is through scope management that the client’s requirement is met. That
is to say, without careful scope management, there can be no confidence that the project’s
outcome will satisfy the client’s needs.
At this early planning stage, constraints that will limit the scope of the project and its
subsequent execution must be identified. For example, an obvious constraint on an Olympic
Stadium project is that it must be completed before the opening ceremony (and perhaps some
time before!). A constraint needs to be noted in such a way that it will guide all future
decisions on the project.
Success criteria are defined by statements which can be used at project completion to
identify what has been achieved and to confirm that we have delivered what we promised to.
Obviously they should match the objectives, reflect the scope and fit within the constraints.
The traditional criteria include schedule, budget and performance (or more precisely,
specification). These are at least measurable. Turner (2009) proposes a successful project is
one that achieves its business purpose; provides satisfactory benefit to the owner; satisfies
the owner, user and stakeholder needs; meets its pre-stated objectives; meets the traditional
criteria above; and provides satisfaction to the project team and their supporters.
5.4 Breakdown structures

In your text you will come across the term ‘work breakdown structure’. As you can see
below, this is one of a number of ‘breakdown structures’ that can be used in project
management.
Scope definition may be expressed by designated, clearly defined boundaries, such as:

● product breakdown structure (a cascade of products, sub-products, assemblies and

components)
● organisation breakdown structure (a cascade of resource types, skill types or activities
● work breakdown structure (a cascade of the products and work activities),and/or
● some other form which comprehensively defines products and activities
(Australian Institute of Project Management 2010, p. 6)
The work breakdown structure (WBS) is an established tool for structuring a large project so
that all the individual component elements are identified according to some established
functional, physical or organisational hierarchical basis.
It consists of various layers, like an organisation chart, each increasing the detailed content,
until at the lowest level a single task or ‘work package’ can be evident.
WBSs are used because they:
● provide a framework for the organisation and management of the project

● provide a framework for planning and control of cost, schedule, scope of work and risk
● break the project down into manageable components (work packages)
● provide a means of ensuring that all work is covered and well defined, or alternatively,
that some work is not left out
● are a very convenient means of allocating and tracing costs
● are useful as a quantitative basis for pricing
are useful for allocating responsibility for the achievement of the various elements of the
total project.
Coding systems can be used to define the work in the WBS so that computerised systems can
be used to select and summate data.
Figure 5.2 illustrates a good technique for developing a WBS, to show the main elements in
the contract as layers in the structure – major deliverables, groups and activities and finally
work packages. Figure 5.3 illustrates the WBS for a small computer project which is used as
a case study in a later module.

Figure 5.2: WBS using contract deliverables breakdown
Figure 5.3: WBS for computer exercise
5.4.1 Organisation breakdown structure

An organisational breakdown service (OBS) is an hierarchical structure of the human
resources involved in a project. An important use of the OBS is to combine it as shown in
figure 5.4 with the WBS to produce a responsibility matrix.

Figure 5.4: Matrix of WBS to develop cost centre responsibility
5.5 Scope management

The fundamental objective of the process for managing scope is to ensure that whatever was
specified as the project outcome is what is produced. The process must therefore be able to
cater for the almost inevitable changes that will be proposed, assessing their validity and
either accepting or rejecting them. If they are accepted, the process must be such that they
are then incorporated into the requirement properly, becoming an equally understood and
important part of the overall project. At the same time, the process must be able to ensure
that changes are not allowed to slip into the requirement unnoticed – so called ‘scope creep’.
These could come about because project stakeholders deliberately or unknowingly request
additional deliverables, functions or performance characteristics. However, many of these are
legitimate changes to the scope of the project and if they are correctly authorised, then this
does not present a problem. A project management methodology that does not provide for
adjustment to contractual conditions could in fact lead to frustration of the contract through
inability to comply with inflexible contract conditions.
Reading activity
To review your understanding of scope management, read the set text by turner
chapter 5.

Reading activity
To review your understanding of scope management, read the recommended
reading by the Project Management Institute (2008), chapter 5 – Scope
management.

Think about the project you are going to use for your assignments. Develop a
simple work breakdown structure that you can use as the basis for project
planning and scheduling.
5.6 Time management
5.6.1 Introduction
Modern project management theory and practice revolve around the need to complete
projects within an appropriate time period, as well as within cost and resource constraints.
The concepts of project planning are extended to include the identification of time
constraints, identification and scheduling of activities, and developing the concept from an
activity network to a practical schedule, for which managers can take responsibility. Finally
the project schedule has to be approved and communicated, so as to become the baseline for
subsequent tracking.
The management of time during project implementation includes four performance criteria.
First, the tracking of actual time; second, the identification of variances and the analysis of
their impact; third, schedule changes are made to cater for changes; and finally new
schedules are developed.
5.6.2 The importance of the time factor in project management

Project management systems were originally designed to gain some control over the time
factor in large complex engineering projects. For example, PERT (Program Evaluation and
Review Technique) was developed for the Polaris Submarine project in the early 1960s. The
project was completed substantially ahead of the usual time for projects of this magnitude
and complexity, the credit going to this new networking technique of project planning and
control.
In the construction of large buildings and engineering/manufacturing projects, very detailed

activity network based project management techniques are used. The aim is to ensure the
financial viability of the project by minimising time over-runs, thereby avoiding the large
financial losses which can result from finance charges and loss of revenue for the periods
beyond the planned target completion dates.

Over the 30 years that PERT has become more widely used, critics have pointed to the many
cases when the use of the technique has not prevented project completion ‘blow out’. Much
of the criticism arises from the unrealistic time estimates calculated for many of the
activities, leading to unrealistic project target dates. Most problems result from activity time
duration being under-estimated and this leads inevitably to the project completion dates
being grossly under-estimated.
5.6.3 Time-cost-resources are interrelated

We have seen earlier the relationship between scope, time and cost. When managing the time
dimension of a project, the relationship between time, cost and resource represents an
additional focus. It is impossible to consider a change to one of these elements without
considering the impact on the others. Figure 5.5 shows the connection between time, cost and
resource characteristics of an activity and figure 5.6 shows their inter-dependence.
Figure 5.5: The three primary factors or project management
When an activity is estimated to take a certain time to complete, it is assumed that the
required resource will be applied to achieve this duration. The resource has cost
characteristics which are applied to determine what the cost will be for the activity. Changes
in the time estimate will usually change the resource requirements – similarly, changing the
availability and number of units of resources to be applied to the task will affect the time it
will take to complete the task.
Figure 5.6: Inter-relationship between time, cost and resource factors

5.6.4 Some causes of ‘poor’ time estimates

External factors are those which are the cause of events, situations or actions of people or
organisations over which the project manager has no control or influence. An important
external factor which can affect time estimates is the imposition of date constraints. The
‘must be finished by’ or the ‘must be started by’ conditions which may be linked to special
arrangements place pressure on planners to adopt optimistic time estimates for those
activities. Date constraints need to be very carefully evaluated by the planner. While many of
the ‘must start by’ and ‘must finish by’ conditions may be essential elements of the project,
others can be simply preferences or desires of senior managers, politicians or even workers
themselves.
Internal factors are those over which the project manager or staff could reasonably be
expected to have some control or influence. They can include:
● initial estimates not being changed to reflect other changes to the project such as
increased scope
● events in the work place causing delays in many activities which can accumulate into a
large over-run.
An important point of caution should be registered by those using project management
software (e.g. Microsoft Project) for preparation of project schedules. Users often assume
that the computer calculations for earliest start/earliest finish dates are certain to be achieved
given that a reasonable degree of management is applied. As with many other computer-
based systems, the amount of detail and the format of the data can give a false feeling of
confidence which has no factual basis. Some tips include:

● Don’t be too optimistic, and recognise when enthusiasm or pride is causing others to
commit themselves to more than they can deliver.
● Break the activities down to a lower level to obtain better visibility of any problems.
● Select those areas which are known from past experience to be likely trouble spots and
plan carefully those activities.
● Provide some reasonable ‘contingency fund’ of time.
● Be ‘fair and reasonable’ when negotiating a time with people who have to perform the
task.
● Find out what priority the project has in the organisation compared with others with
which it will compete for resources.
5.6.5 Probability factors in completion date estimates

The original PERT concept was designed around its use on projects where new technology
was being employed and new manufacturing techniques were being continually improved.
The time estimates had elements of risk and uncertainty. To cope with this situation the
creators of the PERT methodology called for three time estimates to be used to calculate the
‘expected’ time estimate. The three time estimates were determined as follows:
Optimistic estimate – how long would it take to do the activity if everything went extremely
well. Relating to a 1 in a 100 chance.
Most likely estimate – how long would it take to complete the task if things went in a fairly
normal fashion. Relating to an average performance.
Pessimistic estimate – how long would it take to complete the task if everything went wrong.
Relating also to about a 1 in 100 chance.
Most PC based project management software leaves out the full three-time estimate feature
although MS Project now allows you to choose a PERT mode to insert multiple assessments
of the likely duration. Note that when the project management software only provides for a
single time estimate it is assumed that you will insert what you determine to be the ‘most
likely’ time estimate for that activity.
5.7 Time management tools and techniques

In the initial planning process, project managers need techniques, methodologies and tools to
determine how long a project will take. This involves considering how tasks are related, how
they are to be scheduled and which are critical to the project’s timely completion. They also
need systems which can communicate this information succinctly and effectively to the
upper levels of the organisation’s management and to other project stakeholders. The three
that have the most general and widespread use are:
Milestone chart – chart to represent significant events (those with zero duration)
Gantt chart – bar chart to show visual relationships between multiple tasks or resources

Network – logic network (CPM and PERT) charts and reports.
5.7.1 Milestone charts

The simplest of the project management tools is the Milestone chart. It is useful for:
● presentation to senior management levels who may only wish to be concerned with the
detail of major elements of the project, to see whether these are going according to plan,
and
● planning at a very broad level where operational target dates might need to be compared
with likely phase dates for the project.
Figure 5.7 is a representative Milestone Chart for a typical project, showing only the major
milestones. In communications terms the milestone chart is more efficient than a descriptive
report, and the project manager need only report in detail on the milestones that are slipping.
Figure 5.7: Major milestone chart showing the type of information needed by higher level managers
(Source: Meredith & Mantel 2003, colour enhanced by USQ.)

Gantt or Bar charts

The Gantt chart (named after Henry Gantt) is a very commonly used means of showing the
duration of tasks or activities. This graphical presentation is very useful for showing
activities which will be going on at any particular time. Relationships and dependencies are
not normally shown, however more recent project management packages can show linking
arrangements.
The X axis baseline can be either absolute time or a calendar scale or both combined.
The Y axis usually shows a chronological list of activities but variables in the project such as
resources can be displayed.
Figure 5.8 shows a simple bar chart illustrating a small project. In a similar manner to
Milestone charts, the bars are placed along the horizontal grids, forming the lines between
the start date and the completion date of the activity represented by the bar. The thickness of
the bar has no significance. Bar charts are very popular at all levels of project management
because they are:
● clear and simple

● easily understood
● can show progress
● can also be used to show manpower/and other resources.
They also have the following disadvantages, however. They:
● may not show inter-relationships easily

● therefore cannot be used to coordinate work
● have physical size limitations for convenient handling of large projects
● if done manually, cannot cope easily with frequent changes.

Figure 5.8: Bar chart showing a video production project
(Source: Meredith & Mantel 2003, p. 403)
5.8 Network development

Two well known network systems were developed in the 1950s. The Critical Path Method
(CPM) was developed by Kelly and Walker under a du Pont, Remington and Univac joint
effort and was intended for optimising time-cost problems – situations where known activity
times could be shortened but at a cost. The Program Evaluation and Review Technique
(PERT) was developed from the efforts of Lockheed, US Navy Special Projects Office and
Booz, Allen & Hamilton for use in situations where activity duration was not known with
any degree of certainty. It added network analysis and probability theory to program
scheduling with multiple options for estimates of activity duration (from worst case scenario
to best case scenario).
The two techniques have tended to become synonymous. In fact, many modern project
management software packages refer to PERT diagrams (e.g. Microsoft Project) but only
accept a single time estimate for each activity.
While simple Milestone charts and Gantt charts are useful for presentation purposes they are
limited in the amount of material they can show without becoming crowded and causing
confusion. Also they do not enable complex inter-relationships between activities to be
represented. The PERT and CPM (critical path method) activity networks are the basic
planning and management tools for the project manager. An example of a PERT report is
provided in figure 5.9. All project management software packages produce something
similar, however the level of information contained in each box may vary.
The advantages of using activity network diagrams to produce project data and reports
include:

● They take into account the inter-dependence among tasks where bar charts do not handle
this easily
● Thinking through the dependencies (the logic) identifies most items needed to complete
or start a task and the preferred, possible, risky and impossible sequences
● They clearly identify critical activities which if delayed, will result in a delay to the
overall project
● They communicate the overall plan in a very effective way, although they can be
confusing to people who are not familiar with them, which makes their use for
communicating with senior management more difficult.
Figure 5.9: Sample network for video production project
(Source: Meredith & Mantel 2003, p. 403)
Other advantages to be gained from using the network system of planning include:
● Reduction in project time schedule. By formalising project planning, the ability to

schedule activities is more accurate and complex operations can be more effectively
coordinated to give significant reductions in project times.
● Closer control of complex projects. The ability of the computer to deal quickly and
accurately with the mass of data that is involved in the planning and progressing of
complex projects and to produce meaningful management reports leads to closer control
of the projects.
● More efficient use of resources. Resource allocation distinguishes between those
activities which will have a critical effect on the schedule, and those other activities that
are on a path having excess time (float) available. By re-arranging resources of

manpower and facilities, the critical path can not only be shortened but resources can be
fully utilised.
● More detailed planning and scheduling. The analytical approach and the discipline
imposed in the construction of networks for a project automatically excludes unrealistic
thinking and leads to more detailed planning and scheduling.
● Forecast of potential bottlenecks. The detailed planning and scheduling of a project
will reveal both real and potential bottlenecks. During the progress of the project, the
network analysis allows a continual detailed watch to be kept upon the effect of any
delay. In many cases the delay of one activity need cause no change in schedule, but if
the activity is on the critical path then urgent management action must be taken if delay
in the overall project is to be avoided.
● Ability to test alternative solutions. Planning simulations can be evaluated to test the
effects of a variety of changes in the sequencing of events or allocation of resources. This
could enable an optimum project plan to be produced.
● Highlights critical activities requiring closer management attention. Management
action becomes more effective when directed towards likely trouble areas. Progress of
whole projects can turn upon a short list of critical items.
● Emphasis on inter-relationships between activities. The concept of network
construction highlights the inter-dependence and inter-relationships between activities.
Personnel responsible for control of individual activities can see their position in relation
to the rest of the project, and are better able to understand the timing and relationship of
their responsibilities to those of other participants in the project.
5.8.1 Forward and backward pass

The simple basis of a network is that relationships between activities are identified in a
logical sequence moving from the start to the finish. There are many pathways from the
beginning to the end if we go through all of the different groups of activities. If we find the
longest pathway, we have identified the shortest possible time to complete the project based
on that set of relationships. From there, we can modify relationships or durations in order to
adjust the project duration to fit with other project constraints (such as fixed dates for the
commencement, fixed dates for activities along the way, or inflexible completion dates).
The initial step is to identify all of the activities and the relationships between them. This
establishes the logic of the project – how each activity is linked to others. Each activity is
then represented by a ‘box’ with the logic relationship represented by arrows from one
activity to subsequent activities. Information about each activity is then displayed in the box
to provide us with a comprehensive view of all issues related to project duration.
The manual calculation begins with the Forward Pass through the network. Its purpose is to
establish the earliest start and earliest finish times for each activity in the network. In most
cases, the earliest start date of an activity is determined by the completion date of preceding
activities. By identifying the earliest start date of the final activity and adding the duration of
that activity, the earliest completion date of the project can be calculated. This is the earliest
date by which the project can be completed, and it can only be changed by making
adjustments to activities, their durations, or the relationships between activities.
The Backward Pass is now calculated. Starting from the estimated completion date of the
final activity (the completion date of the project), the Backward Pass calculates the latest

finish times and therefore latest start times for every activity in the network. These are
calculated by subtracting the duration of that activity from its latest completion date. This
gives us the latest dates that activities can either start or finish and still meet the overall
project target completion time. Latest start and completion times are calculated in the
opposite direction to earliest times. The start point for the Backward Pass is at the end point
in the network and the times of the activities are subtracted from the previous times.
The manual calculation which has just been completed has a serious deficiency. It has been
calculated in terms of working days, and while this may be useful in some situations, the vast
majority of activity networks must consider ‘calendar’ date information and take into
account that the usual working week has only 5 days. The number of working days calculated
will then equate to a greater number of calendar days.
5.8.2 Float and critical path

Two important concepts in activity networking are Critical Path and Float. The Critical Path
is simply the longest time path through the network from its start to its finish. This dictates
the earliest possible date by which the project completion can be achieved. Any variation in
the duration of the activities on this critical path will vary the project completion point.
There are various specific types of float used in project management activity networking,
although the most common one is Total Float. Total Float is defined as the amount of time
that an activity may be delayed from its early start without delaying the project finish date or,
in other words, before the critical path is affected. Put another way, it is the difference in
time between the earliest finish date for the preceding activity and the latest start time for the
succeeding activity, minus the actual activity duration. Free Float, on the other hand, is
defined as the amount of time that an activity may be delayed without affecting the earliest
start of the activity immediately following (PMI 2008). Activities on the critical path have
zero float.
5.9 Scheduling of activities
5.9.1 What is scheduling?

Scheduling is part of the management decision making process which provides the transition
of a draft project plan into a firm and practical course of action. It involves management
considering the data provided in the preliminary activity network and resolving any time or
resource conflicts which may be present in that data, so that the resulting start and finish
dates are considered to be feasible and achievable. These could form the basis of some
contractual agreement so it is critical to understand these dates clearly. At this point, the
schedule is a strategic tool and not an operational tool. It must be interpreted and adjusted to
fit with strategic issues before becoming an operational tool for implementation of the
project.
Remember that a specific start date is not necessary at this point. We are simply defining the
overall duration of the project based on assumptions at that time. When a start date or finish
date can be agreed and incorporated, then start and finish dates for each activity will

automatically follow. External issues might impact on the relationships or durations (such as
public holidays) so definition of the available actual working days is important.
When the plan for the project has been developed into the form of a draft activity network
which contains the tasks needed to complete the project objectives, and the best estimate of
the time necessary to complete each task has been incorporated, it is then time to review the
activity network for scheduling purposes. This will require that the project start date be
inserted into the initial input data. The output report will provide earliest and latest start and
finish dates for each activity in the network and the earliest finish date for the project. Bar
charts will show diagrammatically the nature of the calendar spread of the activities. A large
capital project may span many years, from the time it is originally conceived until all the
major systems in the project are in operational service. This examination of the initial project
plan for feasible and/or desirable timing of major phases and events can be an important
element in the development of an acceptable overall project management plan.
It is only when the complete activity network has been calculated that it is possible to assess
the full implications of how long the project is likely to take and the extent of the
coordination needed for successful completion. Management will be able to see clearly if the
major milestones fit comfortably within expectations. The most important element of the
plan, as designed, is the identification of activities which make up the project critical path –
the longest time path through the activity network. This becomes the default schedule for all
activities along this path as there is no alternative, assuming that the logic of the project
activities has been structured correctly and the time estimates for the individual activities are
reasonable.
In practice it is not unusual for the initial project plans to need considerable changes in
structure and reassessment of time estimates. Some of the more common reasons for this
scheduling type work are:
● The original layout of activities and the time estimates associated with them would result
in an unacceptably long project duration. The project finish date provided by the project
management software may not meet the requirements of key stakeholders.
● Some activities may either have definite times when they either must start or must finish,
they must happen on a given day, or within a narrow band of time which might be
dictated by budget cycles or corporate committee hearings. Special provision in
scheduling is needed to enter this data into the activity network.
● While the dates might be acceptable, the resources needed to complete the activities
within the time estimates show some conflicts which were not anticipated. These
resources may be people, specific facilities and/or equipment or approved/available
finance.
● The cash flows related to the schedule may not be acceptable to key stakeholders. By
prudent scheduling it may be possible to move the pattern of payments either forward or
back depending on the available float situation.
If the project finish date is still outside the operational date required by key stakeholders, the
action then is to examine the activity network critical path (the longest path through the
network) to see if this can be reduced in any way. This may be achieved by:
● reducing the time duration on some activities, or

● altering the activity network by doing some tasks in ‘parallel’, if this is feasible.

Minor scheduling decisions: Scheduling decisions which are not of major impact to the
overall project are made for convenience, to match-in with resource availability, to provide a
better cash flow situation, to accommodate requests from external organisations, or even to
take advantage of a politically motivated opportunity. All these minor schedule movements
will involve management taking the initiative to advance or delay the start of some activities
within the bounds of the float that is available. As long as these scheduling changes stay
within float allowance, the major target dates will still be achieved.
Scheduling activities inevitably use up the float available on the minor paths in the activity
network, such that as the project progresses it is not uncommon to find that activities which
are not in the ‘main stream’ of the project suddenly become the critical activities affecting
the final target date.
5.10 Resources in project management

Resources are the ‘people and things’ that are required to complete the tasks or activities of a
project. Consideration of the likely resource requirements needs to be included as early as
the conceptual phase of a project. The most common resources used in a project, from the
customer project management viewpoint, are people, equipment, facilities, money, materials,
and management and administrative funds. From the supplier viewpoint the resources needed
to complete the design, testing, manufacture, acceptance and delivery of the system or
equipment are equally extensive.
As resources are defined broadly as anything which is needed to complete the activity or
task, there is a need to look closely at the structure and characteristics of resources in order
to understand how they are treated in the project management context.
Human resources – can be a specific person, a specific skill, a group of more than one
person acting as a resource pool, or an authoritative position in an organisation. The human
resources can be full time on the project, employed only on an activity or task, or can be
allocated to the task for a specific proportion of their time – they can work overtime, or a
specific work week. Specific days when they are not available can be defined. They can be
given a lump sum payment or be paid by the hour, day, week, month, etc.
Equipment or items – these can be any item of hardware which needs to be available for
use on the activity/task, although common practice is to include only special items which are
not generally available in the workplaces of the project and which have to be especially
obtained.
Organisational resources – these can be used to define an involvement by another

organisation which might be needed to complete project activities, without specifying
precisely the person or group.
Financial resources – cash funds needed. The categorisation of funds can usually be
developed based on uses or sources so that specific records or control can be kept. Funds can
be paid on a time period basis e.g. per elapsed day, per day worked, per hour, week, month
etc. as a lump sum spread over a number of time periods, at the start, end or middle of the
activity. It is often possible to define fixed costs, variable costs and overhead costs to
projects or activities.

5.10.1 Resource data needs of management

Formal project planning, that is the construction and processing of an activity network,
forces management to address all the aspects of the project in a qualitative and quantitative
way. Adding the resource dimension, and making it work, is a significant step in project
awareness which many project managers may not be willing to take or may not think is
necessary.
While management needs for project data may vary widely according to the type of project
or degree of responsibility of management, the use of resource based material is increasing
because managers have increased awareness of the ability of currently available project
management software to provide easy-to-use resource histograms to supplement the text
output reports.
For many users of project management software, resource data is the most important aspect
of the project plan. It is the basis of the time calculation, it controls the task scheduling and is
the basis of the cost/payment schedules. This type of user will also rely heavily on the
resource levelling feature to achieve a degree of resource allocation which could not be done
manually. The resource capability should be used to schedule, control or report on resource
usage. These resource based reports might include:
● Resource bar charts. A Gantt chart format showing bars on a time scale where the
resource will be scheduled for work.
● Resource histograms showing loading (and overloading) for a particular resource on a
particular schedule.
● Resource costing calculations.
● Summaries of resources by department or organisation.
● Progress and output reports by resource.
● Resource levelling. Using the resource capacity information as a basis for comparison,
the program automatically considers options for scheduling so that peaks in resource
requirements which exceed the maximum available levels are reduced to a best fit of
available resources.
5.10.2 Time/cost trade-off-cost schedule optimisation

A use of the CPM/PERT methodology was the investigation of the effect of reducing the
overall project time by reducing the time of tasks on the critical path. This was generally
done by adding more direct resources, thereby increasing the cost of the activity. This
increase in costs of earlier activity completion is offset by reductions in indirect costs
associated with the increased time that the project takes to complete. The resulting total cost
curve shows that there is an optimum time for the completion of the project – that which
corresponds to the lowest point on the total cost curve.
Reading activity
Review your study of time management by reading the text by Turner, chapter
8.

Reading activity
reading by the Project Management Institute (2008), chapter 6 – Time
management.

Is time of a critical nature for your project? Would it be the first or last thing
that you would sacrifice? What level of priority would time be given to duration
in the following projects:
● Olympic Games stadium

● major heart-lung transplant surgery
● development of a new IT business system.
Are there going to be any critical resource constraints in the project in your
assignments? Consider how you are going to cater for them?
5.11 Cost management
5.11.1 Introduction
A responsible project manager should try to become involved in all aspects of cost and
funding as this is a key concern for all key stakeholders. It is highly visible (like time
management) and significant variance can threaten the very existence of the sponsoring
organisation.
This module considers the management of project cost in two separate phases; the first phase
is strategic and focuses on the management of cost up to the time a decision is made to
proceed with the implementation of a project, and the second phase is operational and relates
to the management of cost after such a decision is made. The first phase examines the
estimating of project costs during project initiation and planning, and the second with the
monitoring and control of cost during implementation using project management tools.
The project manager is required to cost each task within the project, based on the resources
required over the duration of each of them. These task costs are then rolled up into a
consolidated project budget. Finally, they are broken down again into a cost management
plan for the project. This can be a time based expenditure pattern or a functional breakdown,
for example, labour, professional services, material, equipment hire and so on.
The second phase requires the project manager to show that costs are being managed as per
the plan. Costs have to be tracked against the cost management plan, and when variances

occur, options to overcome them have to be analysed. This process should lead to a
recommendation being made which, if accepted, should be developed into a new project cost
baseline.
The intention in this course is not to make you cost estimators, or even cost accountants, but
to familiarise you with the components and factors which influence project cost and with
some of the common analytical methods which are used to estimate and/or predict costs in
both customer and supplier areas.
5.11.2 The nature of cost and its importance

Cost over-runs are unpopular because they usually create serious payment scheduling
problems, changing the expenditure requirements in one or a number of budget periods. As
the budget is usually fully committed, adjustment actions will ripple through into later fiscal
periods. This can delay the start of new projects which may be almost ready for approval and
may force other current projects to revise delivery and payment schedules. The National
Audit Office in the United Kingdom found a number of reasons for changes in project cost as
illustrated in figure 5.10. Once again, technical factors figured prominently.
Figure 5.10: Analysis of total cost variation by factor
(Source: National Audit office 2004, p. 13)

The project manager’s involvement with cost matters should ideally begin in the earliest
stages of the project, at the time a new asset or system has been officially recognised by the
organisation and it has been included in the forward budgets for future years. The nature of
the project manager’s task is divided into two distinct areas in the progress of the project’s
life cycle:
Prior to commitment: The period where the conceptual and definition phases lead the
project from ideas, schemes and glossy brochures to a clear and unambiguous description of
what is needed. The project manager is involved with estimates and evaluation of alternative
solutions to the sponsor’s needs.
Post-commitment: The period where the project is brought into reality – deliverables are
delivered and benefits are realised. The focus of the project manager’s role changes to that of
a cost monitor and expenditure authorising delegate.
At a very early stage in any project life cycle, management will require a cost estimate or
several cost estimates, which it can use for consideration and evaluation purposes. There are
several methods which can provide a very useful cost estimate for the particular purpose for
which it is required.
5.11.3 Cost estimating methodology

Logically, a project cost estimate is achieved by adding together all the relevant separate
estimates that are produced for the various components of the project. The problem is
identifying what those components are, ensuring none is missed, and accurately estimating
the cost of those components at a time when little information exists. These components can
be costed using either a ‘top down’ or a ‘bottom up’ estimating approach.
‘Top down’ or analysis approach – a project component is sub-divided only to a level which
can be specified with sufficient detail such that a cost estimating technique can be used to
produce a cost estimate. One would expect the elements at this level to be relatively large
and few in number. For a building project, that may comprise the land, the works below the
surface, the infrastructure above the surface and the services to make it all work.
‘Bottom up’ or synthesis approach – breaks down the task into its constituent smaller tasks,
each of which is separately estimated on the best assessment possible at the time, having due
regard to past recorded performance, preferably in terms of the effort, material, and facilities
required. The total estimate is arrived at by adding these separate estimates together, if
necessary with allowances for still unforeseen eventualities. In its extreme form, this method
requires a fully detailed design and knowledge of the processes/materials involved, so that a
complete analysis of the successive work stages can be made and an estimate constructed
using conventional estimating techniques. For our building project, we need to identify and
estimate the civil works, the footings, the steel reinforcement, the concrete, etc. This involves
a lot of time and cost to be accurate.
5.11.4 Cost estimating techniques

Within each of these two methodologies, cost estimating techniques are used to produce
individual estimates:

Subjective technique. In the subjective technique reliance is placed on personal experience,

recollection and judgement of the magnitude and nature of the task with limited reference to
recorded and analysed data from previous projects. As the descriptor indicates, it is
‘subjective’ and will vary from expert to expert. Cost is low and accuracy is low.
Parametric estimating technique. The Parametric technique relates some form of

parameter (size, speed, area, etc) of the project under consideration to the known costs of
that parameter in previous projects, e.g. a cost estimate of a particular type of ship based on a
typical cost per unit of displacement, or an estimate of the cost of a power generator based on
a typical industry cost of manufacture per KW. The cost is slightly higher but so is the level
of accuracy. The cost of a building may be estimated using a cost per square metre rate
without any consideration of the specific circumstances.
Comparative technique. This is similar to the parametric technique, but detailed records
from previous projects are used to make direct comparisons between the actual costs of
similar activities or products and the current project. Such comparisons may be made at
different levels of detail. For example, broad comparisons may be made by taking actual
costs of installation of a similar system and applying a factor to allow for size, complexity,
wage rates, overheads etc. Such methods require access to relatively well established cost
recording data so costs are higher but so is the level of accuracy.
The selection of the most appropriate of the above techniques will depend on the state of
progress of the project and its size and complexity. In the very early stages where perhaps
only generic equipment or systems are being considered, the subjective and parametric
techniques could be used. As the project definition becomes clearer, the comparative method
utilising detailed comparisons of smaller work packages may provide a better solution.
5.11.5 Accuracy of cost estimates

The level of accuracy of cost estimates increases as the level of information increases, and as
more time is invested in the calculations. Three levels of accuracy can be considered as
follows:
Order-of-magnitude estimates are normally within an accuracy range of –30 to +50 per
cent. This type of estimate is usually made without any detailed technical data. The
estimate is often developed using cost-capacity curves, scale-up or scale down factors,
or ratio estimating techniques. These estimates are used during the formative stages of a
capital expenditure program when there is a lack of firm of verifiable information for the
initial evaluation of the project. The accuracy of a preliminary estimate is usually very
low.
Preliminary estimates are normally within an accuracy range of –15 to +30 per cent.
This type of estimate refers to the owner's budget, not to the budget as a project control
document. Where applicable, information such as flow sheets, layouts, and equipment
details are necessary to perform this type of estimate. These estimates are used for the
development of the PMP. These cost estimates are used for many purposes, including bid
proposals, establishment of budgets, fair-price estimates for bid evaluations, contract
change orders, extra work orders, etc.
Detailed estimates are normally within an accuracy range of –5 to +15 per cent. This
type of estimate is developed from very defined technical data through specifications and

drawings, etc. The accuracy of an estimate depends on the quality and quantity of
available project information.
A guide for judging estimate accuracy and the type of estimate to be used, based on
available information, is shown in the Figure 5.11.
Figure 5.11: Accuracy range of cost estimates
5.11.6 Allowance for uncertainty

A contingency provision is made to cover the uncertainty involved in bringing a project to
fruition. It is normally a subjective judgement and reflects the degree of confidence in the
cost estimates. Contingency provisions are usually expressed as percentages of the relevant
individual element of the project.
A project in its infancy will contain far higher risks and uncertainties in the accuracy of the
estimated costs than one which has sought and evaluated tenders, or one which is half way
through production. These risks are often managed through the selection of the type of
contract to be entered into with the main contractor or supplier. A firm or fixed price contract
would have very small contingencies, while cost plus contracts generally attract quite high
contingency allowances.
5.11.7 Through-life or life-cycle costs

A more comprehensive way to evaluate the cost of a project is to consider the life cycle costs
– these are the total costs of ownership of the project deliverable for the expected length of
time that the equipment or systems will be in service. The Harvard University Office of
Sustainability suggests that:
Life cycle costing is a method of economic analysis for all costs related to building,
operating, and maintaining a project over a defined period of time. Assumed escalation

rates are used to account for increases in utility costs over time. Future costs are
expressed in present day dollars by applying a discount rate. All costs and savings can
then be directly compared and fully-informed decisions can be made .
(Harvard Office for Sustainability 2010)
The costs encompass the initial capital cost, including costs of development and project
management, the cost of operating the equipment throughout its life and the costs incurred
then finally disposing of it. The life cycle costs of a technically advanced capital system can
be in the order of four or five times the original acquisition cost so careful consideration
should be given to what level of initial investment in the project should be undertaken to
minimise through-life costs where the sponsor may also be the end user for many years.
Figure 5.12 illustrates the comparison between the initial capital acquisition cost large
project and the overall costs to the organisation over the full operating life.
Figure 5.12: Through-life costing
(Blanchard 2004, p. 25)
Figure 5.13 Illustrates this relationship for an office building showing those elements where
future maintenance costs require careful consideration in the planning and definition stages
of the project.

Figure 5.13: Through-life costs for an office building
(Harvard Office for Sustainability 2010)
5.12 Project cost monitoring and control

The responsibilities of the project manager in cost management during the delivery phases of
the project will be influenced by the type of contracts and sub-contracts in the capital
procurement. Fixed price contracts require a focus on both parties meeting their well-defined
obligations which are set out in comprehensive documentation. Variable price contracts
require a greater degree of monitoring of what is actually delivered and confirming a revised
cost to reflect changes to the scope of the project over the period of the contract. Cost
reimbursement contracts require considerable measurement and confirmation of what has
been carried out so the contractor can be reimbursed for expenses incurred in delivery of the
project.

5.12.1 Earned value and data analysis
Earned value
Earned Value is a simple measurement of the performance of a project. Comparing the
Actual Cost (AC) to the Budget or Planned Value (PV) fails to reflect whether or not the
project is behind or ahead of schedule. By measuring the value of what has been achieved to
date (or the Earned Value (EV)), the project manager is able to determine what has actually
been achieved compared to what was planned to be achieved. The addition of the Earned
Value information allows the calculation of both cost and schedule variances. Figure 5.14
provides a graphical view to illustrate the basic concept of using Earned Value to determine
cost and schedule variances. Earned value is covered in greater detail in MGT8025.
Figure 5.14: Application of earned value
(Source: Standards Australia 2003, p. 14, colour enhanced by USQ.)
Reading activity
Review your study of cost management by reading the text by Turner, chapter 9.

Reading activity
reading by the Project Management Institute (2008), chapter 7 – Cost
management.

Is project cost a critical aspect of your project? Would it be the first or last thing
that you would sacrifice? What level of priority would time be given to final
costs in the following projects:
● Olympic Games stadium

● major heart-lung transplant surgery
● development of a new IT business system
● Commencement of a new franchise business project?
Are there going to be any critical cost issues in the project in your assignments?
Consider how you are going to cater for them?
Conclusion
We have considered some important aspects of managing projects – scope, time and cost –
and the relationship between them. They have been grouped because they are similar in some
regards. They are highly visible (as compared to procurement management for example) and
are quantitative in nature more so than other aspects such quality management,
organisational management and risk management. In a later module, we look at some more
aspects of managing projects under the heading of ‘soft skills’ and that may help to clarify
the distinction between the various knowledge areas defined by the Guide to the Body of
Project Management (PMI 2008). In the next module, we look at the following aspects of
managing your projects – quality management, risk management and procurement
management. Again, there are valid reasons for grouping these three aspects together for our
studies.
Reference list
Australian Institute of Project Management 2010, AIPM Professional Competency Standards
for Project Management, Unit 1 – Plan, Manage and Review Scope, Australian Institute of
Project Management, Canberra.
Blanchard, B 2004, Logistics engineering and management, 6th edn, Prentice Hall
International, Upper Saddle River, New Jersey, USA.

Harvard Office for Sustainability 2010, Green Building Resource, Harvard University,
viewed 11 November, <http://www.green.harvard.edu/theresource/new-construction/life-
cycle-costing/>.
Meredith, JR & Mantel, SJ 2003, Project management: a managerial approach, John Wiley
& Sons, New York, USA.
National Audit Office 2004, Ministry of Defence: major projects report 2003, HC195,
January, UK.
Standards Australia 2003, Australian Standard AS4817–2006, Project performance

measurement using Earned Value, Sydney, Australia.

Module 6 – Project quality and risk management
Objectives
● define the quality standards to be achieved for project deliverables

● define and implement quality processes for the delivery of project outcomes
● define a risk management strategy for the project
● develop a risk management plan for the project
● implement the risk management plan and manage risks throughout the project
● plan the procurement strategy for a project
● define the procurement requirements of a small project
● carry out pre-contractual procurement activities for a project
● put in place procurement contracts for a project
● manage and administer the procurement contracts for a small project.
Learning resources
Text
organisations, 3rd edn, McGraw Hill, New York – chapters 6, 7 and 10.
Selected readings
USQ Library eBooks. Reading these sections of the will assist your understanding of the
topics.
Note: References will also be made to sections of the AS/NZS ISO 31000:2009: Risk
management – Principles and guidelines which is available online through the USQ Library
eJournals. Reading these sections of the Standard will assist your understanding of the
topics.

6.1 Introduction
Audio
Introduction to module 6.
Listen to audio.
This module provides an explanation of the application of quality and risk management
principles to the project environment, and the role played by procurement practices in
helping to manage quality and risk.
Quality exponents such as Deming and Juran gained world-wide attention with their concepts
of quality management, and the benefits to be achieved in an increasingly competitive
international environment. Numerous quality philosophies such as QC (quality control), QA
(quality assurance), SQC (statistical quality control), TQM (total quality management), etc.
have competed for acceptance, with management, government and the public responding
with mixed feelings and a level of scepticism. Quality management is a fundamental aspect
of project management, in that it applies to every deliverable, and to every process used to
deliver those outcomes. It involves a constant process of identification, definition,
application, monitoring and control. In this module the important area of quality management
will be considered. Many people still equate quality management with quality control and the
person who inspects and approves the product at the end of the production line. This
coverage takes the modern view of quality management as a philosophy which must
permeate the whole organisation to ensure that quality is designed and manufactured into a
product, and that management arrangements and procedures are in place to see that this
happens. The project manager’s responsibility is to specify items effectively and to nominate
the appropriate quality requirements for the project. guidelines exist to assist project
managers in the form of an Australian Standard which is available online through the USQ
Library eJournals - AS ISO 10006 – 2003: Quality management systems— Guidelines for
quality management in projects. However, this standard goes into issues related to quality
management in some depth so it is not essential reading. If you are interested in quality
management, you will find it rewarding.
Risk management was one of the most recent project management knowledge areas to be
included in the PMBOK® Guide. Since that time a considerable body of literature covering
the topic has been produced. There is considerable consistency in the literature but you will
find that there are differences in terminology that can cause some confusion. Accepting the
terminology in AS/NZS ISO 31000:2009 Risk management – Principles and guidelines ,
however, should overcome most of this. In this study of risk management, we focus on
qualitative risk analysis. Although there are tools and techniques available for use in
quantitative risk management, you only need to be aware of their existence as you will not be
required to use any of them during this course.

6.2 Project quality management
6.2.1 This thing called quality

The importance of quality in the project setting was generally recognised in the early 1980s,
when the importance of a relationship between cost, time and quality (or performance) was
accepted (Stretton 1994). It could be seen that there was a trade-off between the three; for
example, if in a project, cost and time were to be achieved no matter what, then quality
would have to be reduced if the project looked like going over time or budget. Over a similar
time frame, we have seen in the general business environment the development of quality
principles and standards and the enthusiasm for total quality management (TQM), with a
move away from the reliance on traditional quality control measures.
Turner (2009, p. 141) provides four criteria by which a good project quality outcome can be
confirmed. A good project deliverable:
● Meets the specification

● Is fit for purpose
● Meets the customer’s requirements
● Satisfies the customer.
Turner stresses conformance to customer’s requirements and the way this can be specified.
You may come across three types of specification (and these are explored later under
procurement management):
1. One is a method specification where the physical attributes are dictated, with the
customer accepting responsibility if the product looks as it should – but does not work.
2. Another is the performance specification, where the customer specifies performance
targets and the project team decides what physical structure is required to meet them.
Performance specifications are very difficult to write because the customer has to decide
exactly what targets are required, and how to measure them. For example, how do you
measure ‘durability’ in a sensible time frame. Also the customer has to accept the ‘shape’
that is presented. If the customer does not like this and starts specifying physical
attributes, the concept of using a performance specification to transfer risk will be
jeopardised.
3. The third type of specification is ‘fit for intended purpose’ (FIP). Using an FIP
specification for a total project outcome would be unacceptably risky for the project
because it is very difficult to specify the total ‘intended purpose’. Having said this,
project components can be expected to be FIP, for example, roofs should not leak, etc.
You will often read that ‘the cost of quality’ is free. This is based on the concept that the
savings generated by removing the costs associated with dealing with the consequences of
poor project quality will far outweigh the additional costs involved in developing and
delivering a quality project outcome, especially if the through-life costs of a project are
considered. If the quality system is successful, this should be true, but you cannot ignore that
there will be a sizeable investment required up front and the pay back period could be quite
long. Therefore you can expect some resistance to the idea.

6.2.2 Quality management

As mentioned above, there are two aspects to project quality management:
1. the management of the quality of the project product

2. the management of the quality of the project management process itself.
The guidance for quality management of projects in the Australian Standard (AS ISO 10006
– 2003, p. 5) is based on eight quality management principles:
1. customer focus
2. leadership
3. involvement of people
4. process approach
5. system approach to management
6. continual improvement
7. factual approach to decision making
8. mutually beneficial supplier relationships.
Part of the challenge for the project manager is the terminology that is used to describe the
respective stages of quality management throughout the project. This is mostly because
project managers have imported terminology from other disciplines and this is not always
consistent with how the project management processes are defined in publications such as
the PMBOK® Guide (PMI 2008). Terms such as quality assurance, quality control, total
quality control etc add to this confusion.
Figure 6.1: Quality management structure
Figure 6.1 is trying to represent the overall structure for quality management in a project. As
you can see, a quality management plan is produced during project definition. Outputs from
this flow down in to the quality assurance process as implementation commences. During
implementation this process passes information to and receives it from the quality control
process. Somewhere in all of this, the quality profession also talks about ‘total quality

control’ which is difficult to define. Don’t get too caught up in the terminology. The
important thing is to understand what the key stakeholders will see as a quality outcome,
incorporate those objectives into the project planning process, and ensure that they are
delivered in the final outcome.
6.2.3 Quality standards – the starting point

In general, standards describe what is required to meet the required level of quality
assurance, but do not state how these standards are to be achieved. Each organisation must
use the standards in formulating, documenting and implementing a quality assurance system
that meets its particular business conditions. The organisation decides what level it wishes to
achieve, installs the system and seeks accreditation from a potential customer like the
Department of Defence or an authorised ‘third party’ accreditation agent such as Lloyds
Register, Bureau Veritas or Det Norska Veritas. The outcome of the process of establishing
the quality of the finished project outcome and the processes by which it will be achieved
will be captured in a quality management plan, which forms part of a larger Project
Management Plan (PMP). The PMP is used to gain approval from key stakeholders as to
what is to be delivered and how it is to be delivered so quality management is an integral part
of the project manager’s brief.
6.2.4 Project quality management system

The PMBOK® Guide (PMI 2008, p. 200) suggests that ‘the quality management plan
describes how the project management team will implement the performing organisation’s
quality policy’. PMI (2008, p. 200) also says that ‘the quality management plan may be
formal, informal, highly detailed, or broadly framed. The style and detail is determined by
the requirements of the project’. As in most aspects of project management, you develop the
plans in detail sufficient to give you the control you need to achieve a successful outcome.
The important idea to take on board is that the plan must make it clear what standards apply,
how and when they will be tested and who will do it.
6.2.5 Project management quality control

So far we have discussed the way quality management requirements can be included in a
project plan. We have also looked at project quality management systems. Although, by
covering the above, we have put ‘quality assurance’ (QA) in place, there is still a need for
sufficient quality control that we can be confident that the QA system is working. The
complete four-stage quality management cycle suggested by Turner (2009) is illustrated in
figure 6.2.

Figure 6.2: Four-stage control cycle
(Source: Turner 2009, p. 146)
To achieve the necessary cycle of data collection, measurement, analysis, and corrective
action, we have available a range of techniques which include:
● Data table – a simple matrix within which data are recorded and analysed visually or
statistically, revealing any patterns in the distribution of the data.
● Pareto analysis – outcomes of analysis represented as a bar chart indicating the
characteristics being monitored in order from the largest frequency to the smallest
frequency. The intention is to identify the most significant characteristics leading to a
reduction in quality, thus allowing remedial efforts to be directed to where they are
needed most.
● Cause and effect analysis – commonly referred to as a fishbone’ diagram, this is an
analysis by which the respective categories of causes are represented as branches of the
fishbone diagram, and how the respective categories ‘flow’ into the aggregated effect.
● Trend analysis – identification of any trend or pattern in the results of the monitoring
process.
● Scatter diagram – a visual representation of data analysis to reveal any pattern when the
results obtained from the monitoring process are plotted.
More detailed discussion on quality control is covered in MGT8024 Project quality, risk and
procurement management.
Total Quality Management (TQM) has been defined as:
…a people-focused management system that aims at continual increase in customer

satisfaction at continually lower real cost. It is a total system approach (not a separate
area or program), and is an integral part of high level strategy. It works horizontally
across functions and departments, involving all employees, top to bottom, and extends
backwards and forwards to include the supply chain and customer chain…
(Source: Bounds et al. 1994)

Stebbing (1994, p. 554) highlighted the importance to the quality management process of
people and says:
To achieve a positive reduction in quality related costs there must be …. a complete

awareness throughout the entire organisation of the need to manage quality. Each
individual must understand this and the role they play.
Reading activity
Complete your studies of quality management by reading the following:
Read the set text by Turner, chapter 7.
Reading activity
You can expand your understanding of project quality management by reading
the PMBOK® Guide (PMI 2008), chapter 8.
Reading activity
To further expand your understanding of quality management in a project
environment, you can access the following Australian Standards online through
the USQ Library homepage at no cost. Select ‘all electronic databases’, select
Australian Standards Online, and type in ‘quality management’ in the search
criteria. Among many publications on quality management, you will find:
● AS/NZS ISO 10005:2006: Quality management systems - Guidelines for

quality plans
● AS ISO 10006-2003: Quality management systems - Guidelines for quality
management in projects
● AS/NZS ISO 9000:2006: Quality management systems - Fundamentals and
vocabulary


Analyse the project you are considering using for your assignments. Was there a
quality management system in place? Was quality management defined in the
project plan? What quality control tools were used, if any? Was there any
attempt made towards continuous quality improvement, either for the product or
the process?
Were there any quality problems? What would you do next time to reduce or
avoid them?
6.3 Project risk management
6.3.1 Introduction to risk management

A recent standard has been published on risk management that fits well with the project
environment - AS/NZS ISO 31000:2009 : Risk management - Principles and guidelines. The
standard makes it clear that it covers risk management in a generic sense, not just in projects
and indicates that risk management is the term applied to a logical and systematic method of
identifying, analysing, assessing, treating, monitoring and communicating risks associated
with any activity, function or process, hence its applicability to managing the risks in a
project. The standard goes on to make another point that should not be forgotten: Risk
management is as much about identifying opportunities as avoiding or mitigating losses.
We carry out risk management in a project in an attempt to ensure that the project is a
success, but what do we mean by project success or failure
6.3.2 What are project success and failure?

When considering project success and failure, one should first define what constitutes
project success. It was generally accepted for many years that, as meeting cost, time and
performance targets were the objectives of any project, achieving all of them in a project
would automatically mean that the project was a success. More recently, however, project
managers have found that, having done as required – they have produced exactly what the
user demanded, on time and within budget – the user is not happy with the results.
To address this scenario, Baker (1997, p. 28) has previously suggested that ‘project failure,
then, is not always a clear proposition. Projects succeed – or fail – to the extent that they
meet the expectations of the project’s stakeholders. Those expectations are not fixed—they
evolve as the project evolves’. This view is still relevant today, and reflects the importance
of gaining and maintaining the support of key stakeholders throughout the project.
When trying to establish if project outcomes meet requirements or not, a good starting point
is the original operational requirement – the document which stated the user’s needs and
what it was to be able to do in operational terms. It is often an extremely expensive and
lengthy process to test new capital equipment or complex systems to the limit of the
operational performance specifications so a practical definition of project requirements and

how they will be confirmed is essential. Good practice demands that criteria for project
success should be measurable, and immediate objectives can usually be measured as soon as
the project work is complete. On the other hand, it is likely that before business benefits can
be measured, some time will have to be allowed while the new system settles down. If this is
the case, when is the project finished – when the deliverable is complete or when the benefits
can be measured?
Before we look at categories of risks that can be found in projects (those risks that can cause
failure and therefore must be managed), you should be aware of what are called project
success factors. These are factors that, if managed successfully, can contribute to the
increased likelihood of project success. Pinto and Slevin (1997) looked at this issue some
time ago and identified the following key factors which if addressed, will reduce the risk of
project failure:
● Clarity of project mission – make sure that all key stakeholder agree on what is to be
achieved.
● Support of senior management sponsoring the project – ensure that there is consensus
among the key stakeholders that the project is essential and should proceed.
● Adequacy of project planning – ensure that the project charter and subsequently the
project management plan have considered the key issues and risks, and that planning is in
place to address those risks.
● Support of the end users – ensure that the end users of the project deliverables are ‘on
board’ and support the project.
● Appropriate project personnel – ensure you have the appropriate members on the project
team and that the essential skill sets are covered.
6.3.3 Risk management in projects

By their very definition projects are unique and difficult undertakings. They often involve
using unfamiliar technology and processes in an attempt to achieve combinations of
performance and capability which have not been provided before. Projects are fraught with
various risks, for example in trying to meet goals and objectives of extended operational
performance, technological achievement, time targets, or budget limits.
The NCSPM (AIPM 2010, p. 20) suggests the risk management process consists of ‘seven
steps: communicate and consult; establish the context; identify risk; analyse risk; evaluate
risk; treat risk and monitor and review risk in order to maximise opportunity and minimise
the consequences of adverse events. The risk management process is completed through the
review of the plan and recording of lessons learned’.
Part of the project manager’s responsibility, at the end of the definition stage of a project, is
to minimise the risk to an acceptable level before recommending an acquisition strategy to
the corporate management of the organisation. As we will see in the next section,
procurement management is an inherent part of risk management in a project environment.
Procurement strategies identify various risks and allocate them to the contractual parties,
either knowingly or unknowingly. Unsuspecting parties to a contract can realise that they
have accepted risks for which they are not equipped to manage, leading to disastrous
consequences. Simply passing on risk to another party does not make the risk disappear. It
may well make it invisible until it is too late. Risks should always be clearly identified and
allocated to the party that is best equipped to handle it.

Risk is a term applied to related events that can have an adverse impact on the meeting of
project objectives. Risk management is a method of managing that risk which concentrates
on identifying and controlling the areas or events that have a potential for causing undesired
circumstances. A short list of possible risk factors is provided here as a starting point for our
consideration of risk management in the project context.
● Technical risk: the possibility that the technical requirements on which the original
estimate was based may be not be achieved within the cost and schedule estimates.
● Financial risk: the possibility that the cost may rise because of factors not allowed for,
or not adequately allowed for, in the original estimate.
● Management risk: the possibility that planning or management arrangements may cause
additional costs not predictable at the time the cost estimate was compiled.
● Contractual risk: the possibility that inadequacies in the contract agreement will result
in additional costs being manipulated by the contractor, or accepted as part of the
contract.
● Schedule risk: the possibility that the completion schedule will not conform to the
contractual or management plan.
● Operational performance risk: the possibility that the equipment or system will not
meet all the operational needs of the user.
6.3.4 Risk management planning

The standard AS/NZS ISO 31000:2009 has a five step process including a preliminary step
called ‘Establish the context’. Under this heading, the standard suggests that the strategic,
organisational and risk management contexts should be considered. The strategic context can
include financial, operational, competitive, political and social aspects, to name but a few. It
also includes the identification of stakeholders. The organisational context includes the
organisation’s goals, objectives and capabilities and hence indicates how the project, and the
project’s risk, will be treated by the organisation. The other steps in the standard are
identification, analysis, evaluation and treatment as indicated in figure 6.?. Risk is
systematically and constantly identified and managed throughout the project life cycle.
A detailed risk management plan should be developed, as part of the project plan. This too
should be approved by the project sponsor. Risk management does not stop at this stage but
must continue throughout the project. As the project is executed, the point where a particular
risk could occur will be reached and, assuming nothing has happened, it can be crossed off
the list. On the other hand, risks can arise that were not planned for, caused by for example
changes in the economic or political environment. Figure 6.3illustrates the iterative nature of
the risk management process. The diagram has been taken from the Australian Standard on
risk management and represents the views of representatives from most, if not all, industries
that could expect to confront serious risks such as health, banking and finance, customs,
quarantine, defence, transport, and so on.

Figure 6.3: Risk management overview
(Source: Standards Australia 2010, p. 14)
The identification and analysis of project risk should commence in the concept phase.
Although there will be little project detail available, a risk management process should be
carried out, based on what is known. This concept phase risk management plan should be
part of the concept proposal or project charter submitted for project approval, so the
approving authority can see what risks they may be taking. At this stage it may be possible to
prevent a lot of wasted effort if any unacceptable and unavoidable risks are identified,
forcing project cancellation – it is better to cancel now, before a lot of work is done on
project development.
As you can see, the first step in the process is to ‘Establish the context’. First we define the
strategic context, the relationship between the organization and its environment. You should
be considering what the organization is good at, what its weaknesses are and what
opportunities and threats may exist. This examination should give you an understanding of
possible risks to the project and the organisation’s ability to handle them. You should
identify stakeholders. Stakeholders to a project can be supportive, neutral or hostile and you
need to establish who they are and their possible attitude early in project planning. Obviously
hostile stakeholders are a potential source of risk, but supportive stakeholders may be able to
reduce risks and you may want to work this into your risk management plan. Next we
establish the organizational context. It is important to understand the organization and
what its objectives are. This should define the importance of the project to the organization –
is it just one of a number of projects that are assisting with the achievement of the objectives,
or is it the only one (with the future of the organization resting upon it)? In the former case, it
may attract only limited extra support if it gets into trouble; in the latter case, the project

manager could expect considerable assistance should problems arise. Another important
implication from this, however, is that in the latter case the damage to the organization could
be very high and therefore risk taking should probably be minimised.
We establish the risk management context. This activity could be considered as laying the
ground rules for the risk management process that is to be used on the project. It involves
first defining the project – its goals, objectives, strategies, scope and parameters (such as
time and location). These aspects should all be covered in the project plan. This activity
should decide whether all risks are to be considered, or only specific ones. It should also
decide who will be involved – roles and responsibilities; and how this project will relate to
other projects in the organization. Finally it will need to decide whether existing controls
only can be used or new ones developed.
Now we develop risk evaluation criteria. Here we decide what levels of risk are acceptable
and which will have to be reduced. As the text spells out, these decisions can be based on,
amongst others, operational, technical, financial, legal, social and humanitarian criteria. For
example, higher financial risks may be accepted (if the potential return is high) whereas even
moderate safety risks may be socially unacceptable.
Finally, the last sub-step requires you to decide the structure on which the risk management
process will be based. The standard suggests that the project should be decomposed into a
number of elements, and these should form the basis for the identification and analysis of
risks. The obvious basis to use is the Work Breakdown Structure (which we discussed under
scope management), where the risks for each task (bottom level activities) should be
considered. As you consider each of these, do not just find one risk and then move on – some
tasks will have several risks, others will have none. Another point to note is that you also
need to address the project as a whole – there can be risks that will not be revealed in a
detailed consideration but could have an impact on the overall project, for example economic
problems or changes to senior management.
The next step in the overall process is to ‘Identify risks’. Note that risk identification answers
the questions ‘What can happen?’ and ‘How can it happen?’. Risk analysis follows. Here we
look at the likelihood of a particular risk events occurring AND the likely consequence, to
establish the level of risk. There are many ways of establishing this, ranging from totally
qualitative analysis through to very complex quantitative methods. No matter how rigorous
or complicated the method, and regardless of how impressive the outcome may be, you must
not lose sight of the fact that the initial input was most likely subjective.
We now have to ‘evaluate risks’. This involves us comparing the level of risk we calculated
during risk analysis with the criteria we decided upon while establishing the project context.
In simple terms, this comparison will allow us to accept the risk or force us to do something
about it – ‘Treat risks’.
6.3.5 Management options for handling risk

Faced with a project which has elements of risk, the project manager can use the following
approaches:
● Acceptance or assumption: The risk is acknowledged and the decision is made to

accept the effect of the undesired consequences if they occur. What you are deciding is
that, if it happens, you can manage it on the day.

● Reduce the risk. You have calculated what you believe is an unacceptable level of risk
through an assessment of probability and consequence. You look for ways of reducing
either or both so the overall level of risk falls to an acceptable level.
● Avoid the risk: Some risks can be avoided by the selection of system options which are
of lower risk. Choosing this safer situation, however, may mean that more innovative
technology or more forward looking designs are not achievable. Also, in the ultimate,
avoidance may mean recommending the whole project be cancelled.
● Transfer of risk: The situation is created where part of the risk is accepted by the other
participants in the project. This is usually done through the development of contracts of
the fixed price, incentive or warranty type.
A sensible risk treatment process is shown in figure 6.4 which comes from an earlier version
of the standard on risk management, and provides a good flow chart on the processes to be
considered. As you can see, during risk assessment a risk is classified as either acceptable or
not. If it is not, it is processed through a number of questions until a decision is reached as to
its final method of treatment.

Figure 6.4: Risk treatment overview
(Source: Standards Australia 1999, p. 17)
6.3.6 Risk treatment documentation

The risk management process should be fully documented so there is a record of the
identification, analysis and treatment strategy, before project implementation commences. It
is only through communication and consultation that problems that may arise from different
perceptions of a particular risk can be addressed and this documentation will provide the
basis for a risk communication process. There is no mandated format for what is usually
referred to as the risk register but a table format containing all of the essential detail is
appropriate. Each risk identified is listed, with the event and how it can occur described. You
need to think through this process, as you need to get to a level of detail in the risk scenario
that you can analyse and treat. For example, a risk of ‘project slippage’ does not give any

guidance as to likelihood (close to 100% in many projects), nor does it suggest a treatment.
On the other hand, risk of ‘project slippage because of delayed delivery of equipment from
overseas’ does.
In the format suggested here, the identification is supported by a description of the

consequence and likelihood. This is followed by an assessment of the adequacy of any
relevant control mechanisms – tools, procedures, techniques, etc., that are already in place
and that could reduce the consequences, the likelihood or both. The effect it could have is
taken into account when each risk is then analysed. The consequence, should a risk occur, is
estimated, often using the scale of 1 (insignificant) to 5 (catastrophic) described in the
standard. The likelihood, using another five point scale, A to E is also estimated, where A is
almost certain and E is rare.
These two estimates can then be used in a matrix to produce the level of risk – low,
moderate, high or extreme. Finally the risks are placed in a priority order for treatment. This
prioritisation should obviously note the level of risk, but low risks likely to occur in the very
near future should sensible take precedence over extreme risks not likely to occur for some
time – assuming that the treatment process does not require a long lead time.
Figure 6.5: Risk register example 1
(Source: Standards Australia 2004a, p. 99, colour enhanced by USQ.)
Once the risk register is complete, with a list of risks to be treated in priority order, you need
to plan the treatment process for each risk. This process can be documented using a table that
allows you to list possible treatment options for each risk and then to select one. A column
should be provided for the retained or residual risk, the risk remaining after the treatment
process has been put in place. The table should also allow the inclusion of another important

aspect of risk treatment – making it quite clear who is responsible for carrying out the
treatment process. There is little point in working through the risk management process if, in
the end, nobody actually implements whatever treatment option is chosen. Not only is it
important to delegate responsibility for the process, it is also important to schedule the
implementation which should also be listed.
6.3.7 Risk management in the implementation and termination phases

The importance of continuous risk monitoring throughout the implementation phase of a
project cannot be over-emphasised. To aim for best practice project risk management, you
should review the risk register on a regular basis, for example in regular project meetings
where risk management should be a standing agenda item, to check that the context has not
changed, there are no new risks and that risk treatment processes are in place as planned
originally. The methods whereby you achieve the objectives of this part of the risk
management process can be many and varied but they need to include a regular review
process where risks are crossed of the list if their time has passed, risk problems are solved
and new risks are identified, assessed and treated.
As part of project termination a project review should be carried out. At the very least this
should involve the project team reviewing the management of each of the nine project
management functions – what were the issues and what were the lessons learned. These
lessons should be formulated into recommendations that senior management can react to. It
is only through this sort of continuous improvement process that an organization’s project
management methodologies, knowledge and skills will be developed. As with the other
functions, the risk management process used in the project should be reviewed. Any
instances where there were risk related problems should be analysed and any lessons learned
should be documented. Two things can be done with these. As a way of encouraging the use
of experience as a risk management tool, Kerzner (2009) recommends the use of some form
of ‘lessons learned’ database. He then illustrates what it could contain by listing and
describing a number of risks. Note that these are all from a technical environment so will not
have general applicability. Having said that, the concept of a lessons learned database does.
The other use that can be made of the lessons learned is that they can be the basis of
recommendations made to higher authority. Hopefully the recommendations will be accepted
and any necessary improvements made – to the benefit of future projects.
Reading activity
Now read the set text by Turner, chapter 10, for a review of risk identification,
assessment, monitoring and control.
Reading activity
For a greater understanding of risk management in a project context, read the
Guide to the Project Management Body of Knowledge (PMI, 2008), chapter 11.

Reading activity
For a greater understanding of the processes and methods for effective risk
management, you might like to read the Australian Standard AS/NZS ISO
31000:2009: Risk management – Principles and guidelines. This is not a
mandatory reading and is only suggested for those who have an interest in
effective risk management.

You should develop or review a risk management plan of the project selected
for assignment 3. You should identify any project related risks and any risks
related to individual tasks. You should analyse each of these risks and then
decide on appropriate risk treatment strategies. I suggest you use the Australian
Standard format for the analysis and that you produce a risk register that can be
used during project implementation.
6.4 Project procurement management
6.4.1 Introduction
Most projects involve procurement of some form. It can involve the simple acquisition of
goods or services or hiring of people. As you would expect, the overall objective of project
procurement is to provide whatever is required, to meet a schedule, at a predetermined
standard of quality and at a cost that equates to value for money. Any procurement for a
project should be planned and managed just like any other aspect of the project.
Procurement management, like most other aspects of project management, have a strategic
dimension and an operational dimension. Procurement strategies will determine the tone of a
project. An aggressive fixed price strategy with all possible risk transferred to an external
contractor will provide just what would be expected – an adversarial process driven by
conflict and competing interests. It could well end up in court with third parties deciding who
gets paid what. On the other hand, an alliance contract where appropriate parties sit down at
the beginning and jointly investigate the most effective way of delivering the required
objective will create a different environment – one of joint decision-making and compromise
rather than ‘class warfare’.
6.4.2 The procurement process

Project procurement management may be regarded as consisting of six processes, leading
from the planning of a procurement process to the final contract close-out. Based on the
national competency standards, the structure can be summarised as follows:

Determine procurement requirements:
● establish what has to be acquired and when it will be needed

● decide the procurement strategy to be used.
Establish agreed procurement processes:
● ensure that the goods or services required are available

● establish the selection processes and criteria, and communicate them to ensure fair
competition
● get approval from the appropriate authority to commence formal procurement activities.
Conduct contracting and procurement activities:
● call for tenders

● evaluate those tenders submitted
● negotiate final terms and conditions with the selected supplier.
Implement the contract and/or procurement:
● after the contract is signed, ensure that the supplier understands your detailed
requirements
● during the execution of the procurement, review progress regularly to ensure that your
requirements will be met
● identify problems and, where necessary, seek approval for changes to so as to ensure a
satisfactory outcome.
Manage contract and procurement finalisation procedures:
● once the good or service has been delivered satisfactorily, formally close the contract
● review the effectiveness of the procurement process
● from any lessons learned, make appropriate recommendations for application to
subsequent procurements.
6.4.3 Procurement planning

The procurement requirement will come from other parts of the project plan. It will arise out
of the processes discussed under resource management, and during the scoping of the
project, the need for goods and services will be established. The scheduling process will
establish when each of these is actually required by the project. It is generally agreed that the
development of the procurement requirement should include input from key stakeholders and
higher project authorities to ensure consensus. Once the individual requirements have been
established, it is necessary to decide how each will be acquired. Hamilton (1997, p. 106)
points out that the procurement plan could suggest a range of options that include internal
and external procurement using a range of mechanisms. The variables that could influence
this decision include:
● the level of technology required

● the cost of the procurement

● the availability of the good or service

● whether the purchaser is a government or private organisation.
To explain the last point, private organisations can generally procure what they want from
whomever they like – they are not constrained by government regulations. Having said that, a
well managed private organisation will seek value for money in its procurements, but it can
be influenced by commercial realities. For example, the organisation may be prepared to pay
a premium for a good or service for a particular project, in return for a cost reduction
elsewhere. On the other hand, government organisations are constrained by both the need to
achieve value for money and the requirement for probity – they must be seen to give all
potential suppliers the same opportunities. This means that government organisations nearly
always have to seek multiple quotes, go to open tender, or buy from pre-approved suppliers.
Another aspect that can be addressed during procurement planning is whether a contract
should be used and, if so, what type it should be. The PMBOK ® Guide (PMI 2008)
summarises the major categories of contracts as follows:
● fixed price or lump-sum

● cost reimbursable
● time and material.
However, there are numerous contract types and there are no clear distinctions any more.
Contract management and contract law are subjects in their own right and can only be
mentioned briefly here. Contracts are often referred to as a risk transfer mechanism, and the
level of risk is one factor that could influence the decision as to the type of contract to use.
Other factors include the level of control you want, your level of expertise with the system
being procured, whether you are prepared to pay for quality or whether you will select the
system based on price and the type of specification you are going to use. Having said all that,
in many if not most large organisations, there is a procurement management policy or
methodology that will spell out the strategy to use.
Two categories of contractual relationships are generally easy to recognise, which are
described in this course as ‘traditional’ and ‘not-traditional’. ‘Traditional’ tendering is taken
to comprise the following:
● appointment by the client of a supervising consultant (or agent) such as a project

manager;
● preparation of a project design and documentation by other specialist consultants in
accordance with the client’s brief;
● invitation to potential suppliers or contractors to submit tenders (quotations, prices, bids
etc.) for the production and delivery of the project, generally based on a fixed price for a
known scope of works;
● submission of competitive offers (tenders) by the invited suppliers;
● acceptance by the client of a tender (as an offer);
● creation of a contract between the client and the contractor; and
● administration of the project contract by one of the consultants appointed by the client.
Non-traditional tendering (or contracting) in these studies is taken to include a wide range of
alternative processes by which clients, consultants and suppliers agree on a method for the
design, documentation, production, and delivery of the finished project. They may include:

● design and construct (or design/build)

● reimbursement or cost plus
● project management (in a context where the project manager takes over the contracting
role with respective suppliers on behalf of the client) or management contracting.
The terminology varies substantially from industry to industry, and the examples listed above
are predominantly from the construction and development industry. In each of the categories
listed above, there may be variations on determining contract price e.g. fixed price,
guaranteed maximum price (GMP), target price. As you can see, it is a specialist area with
many pitfalls for the unwary. More details on the range of options and how they work are
provided in MGT8028 Project tendering and contracting.
6.5 Pre-contract procedures
6.5.1 Procurement process

Once the requirement and the procurement strategy have been established, it is necessary to
check the feasibility of the chosen approach. Can the requirements actually be met? Who are
the suppliers that may be able to meet them?
Once potential sources have been established, it is necessary to decide how the final
selection will be made. You have to decide what process will be followed to solicit bids from
potential suppliers. Also, you have to decide what the basis for selection will be – the
selection criteria. Harking back to the comments above about fairness, the selection criteria
have to be published such that all potential suppliers know how their bids will be assessed.
This stems from governance and probity issues that we will discuss in a later module on the
soft skills of project management.
The next step leading to final selection is to communicate the final proposal to those sources
you have decided can meet your requirements. This can be done through open tendering,
restricted tendering or negotiation (though the latter is not usually acceptable for government
procurement). Once tender bids are received, you have to go through a process where you
rank the bids based on the published selection criteria. This should lead to your making a
recommendation to higher authority for approval to enter into final negotiation and then a
contract with the selected supplier.
Once the supplier has been chosen, it is usual for further negotiations to take place to sort out
and agree the final terms and conditions of the contract. In this process, a final price should
be agreed (it is not uncommon for a buyer to ask for a prices for options, nor is it uncommon
for a tenderer to submit non-compliant suggestions). Once these negotiations are complete,
the contract can then be signed.
6.5.2 Contract execution

Once the contract has been signed, an initial planning meeting should take place between the
buyer and the supplier. At this meeting it should be ensured that both parties are in complete
agreement about the details of the procurement – scope, schedule, payment arrangements,

quality assurance, and so on. This contact should be maintained throughout the execution of
the contract, so changes can be agreed and managed, any conflicts can be ironed out and final
objectives can be achieved. Any problems that arise should be escalated if necessary so
solutions can be found and implemented with a minimum of delay.
Once the seller has produced whatever the contract required and the buyer has accepted it,
the contract should be closed formally. Activities at this stage of the procurement will
probably include final quality checks and performance tests, rectification of any faults, entry
of the items on a register of assets (if appropriate), processing of final payments and the
production of a completion certificate.
The final activity in the procurement process should be the conduct of a post procurement
review, addressing any issues that arose, deriving lessons learned and making
recommendations for improvements for the future. This could be conducted as part of an
overall post-project review, but it is important that it is done, as it is through this process that
continuous improvement is achieved.
Reading activity
Read the text by Turner, chapter 6, for a review of the procurement processes
for a project. Relate these to the procurement strategies and processes in your
own professional environment – this will change from industry to industry and
from country to country.
Reading activity
For a wider understanding of procurement management, read the Guide to the
Project Management Body of Knowledge (PMI, 2008), chapter 12.

Think about the project you have selected for analysis in your assignments.
What aspects of that project will be delivered through a procurement process?
All of it? None of it? If procurement is involved, how would you describe it
using the terminology above? Was it effective, or were there problems? What
changes would you suggest?
Conclusion
Module 6 has looked at the important issues of quality and risk associated with the delivery
of a project, and how these dimensions can be managed. One of the mechanisms used to

manage quality and risk is procurement. It allows outcomes to be defined, and delivery
processes to be predetermined, to ensure that all parties are working towards a consistent
view of the deliverables and how they will perform in terms of their intended use. The inter-
relationship between these aspects of managing projects is achieved through integration
management which is discussed in module 7. Quality, risk and procurement management are
examined in more detail in MGT8024 Project Quality, Risk and Procurement Management.
Reference list
Baker, B 1997, 'Great expectations : turning failure into success - and vice versa', PM
Network, vol. 11, no. 5, pp. 25-28.
Bounds, G, Yorks, L, Adams, M & Ranney, G 1994, ‘Keeping the lid on project costs’, in D
Cleland (ed.), Beyond total quality management towards the emerging paradigm, Van
Nostrand Reinhold, New York, USA.
Hamilton, A 1997, Management by projects: achieving success in a changing world, Thomas

Telford, London, UK.
Kerzner, H 2009, Project management – a systems approach to planning, scheduling and

controlling, 10th edn, John Wiley & Sons, New York.
Standards Australia 2009, AS/NZS ISO 31000:2009: Risk management – Principles and
guidelines, Standards Australia, Strathfield.
Standards Australia 2003, AS ISO 10006 – 2003: Quality management systems— Guidelines
for quality management in projects.
Stebbing, L 1994, ‘Project quality management’, in D Lock (ed.), Gower handbook of

project management, Gower, Aldershot, UK, pp. 550–89.
Stretton, A 1994, ‘A short history of modern project management part one: the 1950s and
60s’, The Australian Project Manager, vol. 14, no. 1, Mar., pp. 36–7.

Module 7 – The soft skills of project management
Objectives
● identify and classify the stakeholders of a project

● prepare a project stakeholder management strategy for a project
● select and define appropriate project management organisational structures for
management of a small to medium project
● identify the appropriate ‘human’ aspects required for team work in a selected project
● identify the characteristics of a successful project manager
● put in place the processes for effective management of conflict in a project organisation
● establish effective communication management processes for a project
● establish an effective project management information system
● establish effective processes for project integration management
● carry out project management integration management of a small to medium project.
Learning resources
Text
organisations, 3rd edn, McGraw Hill, New York – chapters 4, 6, 15 and 17.
Selected readings
Selected reading 7.1: Belzer, K 2001, Project Management: Still More Art than Science,
PMForum, viewed 15 December 2011,
http://www.pmforum.org/library/papers/BusinessSuccess.htm
Selected reading 7.2: Bourne, L & Walker, DHT 2005, 'Visualising and mapping
stakeholder influence', Management Decision, vol. 43, no. 5, pp. 649-60, viewed 16
December 2011, http://mosaicprojects.com.au/PDF_Papers/P044_Visualising_mapping.pdf
Selected reading 7.3: Ford, RC & Randolph, WA 1992, 'Cross-functional structures: A

review and integration of matrix organization and project management', Journal of
Management, vol. 18, no. 2, pp. 267-95, viewed 11 January 2012.

Selected reading 7.4: Crawford, L 2011, 'Extending the project management skill set to
encompass change implementation', paper presented to 25th IPMA Global Congress,
Brisbane, Australia 9-12 October.
Selected reading 7.5: Camilleri, E 2011, Project success: critical factors and behaviours,
Gower Publishing Limited, Farnham, UK, chapter 7, pp. 89-112.
7.1 Introduction
Audio
Listen to audio.
Allow adequate time for this module as it is quite large, covering some key areas of
managing projects through the management of important internal stakeholders,
communication between all stakeholders and integration of key project processes and
activities.
In module 5, we considered the ‘hard’ skills of managing projects which we suggested were
related to scope, cost and time. In these study materials, they are described as ‘hard’ because
the respective dimensions of the project are quantitative in nature and easily measured, and
rigorous management techniques work reasonably well in defining and controlling the
outcomes. In this module, we talk about ‘soft’ skills. There is no real consensus within the
profession on the nature of the relevant skill sets, nor which ones should be included. For the
sake of convenience in this course, we will consider the soft skills as those that relate to the
management of people, communication and integration. As Belzer (2001, p. 1) indicates:
Understanding processes, tools, and techniques (the hard skills, the science of project
management)—and knowing when and how to apply them—is only part of the answer. A
greater piece of the puzzle for successful project delivery is soft skills (the art of project
management)--the timeless principles of working within an organization. Soft skills help
to define the business value, clarify the vision, determine requirements, provide
direction, build teams, resolve issues, and mitigate risk. Without the appropriate soft
skills, the likelihood of project success diminishes.
The subjects of people management and organisational structures are well covered in
management texts and this module examines those aspects relevant to project-oriented
organisational structures. Organisational structures are simply a tool to assist in the efficient
utilisation of human resources – in the end, it comes down to managing the people who can
influence the likelihood of a successful project outcome.

Based on wide-ranging research undertaken within the discipline of project management, we

now know what needs to be done, at least in a generic sense, to manage a project through its
life-cycle to a successful conclusion. We continue to prove, however, that no matter how
much detailed planning nor how appropriate the use of clever tools and techniques, if the
people involved in executing the project do not care about the outcome the project is unlikely
to achieve its objectives. Hence the importance of developing the soft skills that allow a
project manager to identify the key factors that will influence the likelihood of project
success, and managing those factors successfully in a quiet and unobtrusive way. Project
management refers frequently to the concept of stakeholders, but there is little consensus on
who or what represents a project stakeholder, and how they can be managed. Few
stakeholders, especially those who see themselves as being at a senior level, like to feel that
they are being ‘managed’. Learning how to manage stakeholders discreetly is extremely
important for the effective project manager.
This module will also examine communication in the project environment and the
importance of an effective project stakeholder management strategy. The module briefly
considers the use of project management software packages but we are more interested in the
objectives of stakeholder management and communication than any specific tools. Their use
as a decision support tool is explained, as is their value as the core of a project management
information system (PMIS).
This management juggling act of coordinating people, organisations and resources comes
under the concept of project integration. Every decision will impact on some other aspect of
the project, and the project manager has a responsibility to balance the competing interests in
order to deliver the optimal outcomes that satisfy the expectations and needs of major
stakeholders. To fulfil those responsibilities the project manager must develop the soft skills
at a sufficiently high level to manage downwards, sidewards and upwards.
Reading activity
To set the scene for the need for soft skills in project management, read selected
reading 7.1 by Belzer, 2001.
7.2 The management of people in projects
7.2.1 Project stakeholders and organisational structures

The management of people in projects relates to the management of individuals and the
utilisation of organisational structures.
Individuals come in all sorts of categories and may be part of the project team or may be
someone who is an ‘outsider’. They may be supportive of the project or they may be
violently opposed to the project. They may be acting alone or may be part of a larger
organised group or organisation. One way or another they will be a project ‘stakeholder’.

To effectively manage the ‘human’ resources related to the project, the project manager will
have to allocate roles and responsibilities within the organisational structure. These in turn
will relate to specific aspects of the project so there is a clear linkage between the respective
elements of the project and individual team members. Reporting structures and levels of
authority will be required for efficiency and some form of organisational structure will either
be imposed on the project team members, or will evolve of its own accord. Communications
between individuals and organisations become critical and management of the information
flows is an important challenge.
The exact extent to which organisational factors influence project management performance
has not been established in project management literature, but it is sensible to assume that
there will be advantages in developing an organisational structure for a project which is
optimised to the nature of the project, the type of staff which operate in it and the authority
and rules under which they are expected to conform and work effectively.
We have reason to believe that a ‘good’ organisation structure (ostensibly one where roles
are well defined and relationships between positions are also clear) will run smoothly and
effectively, and that staff will invariably make a ‘bad’ organisation work anyway through
informal arrangements, albeit at a lower level of efficiency. Part of an organisation’s
performance is due to the structure and part is due to the calibre of the people.
7.2.2 Stakeholder management

There are numerous definitions of ‘stakeholders’ and it is not critical which one you use. It is
important that you are consistent, and that others understand the meaning that you give to the
term. Turner (2009, p. 77) sees stakeholders as anyone who has an interest in the project. In
earlier research, Dinsmore (1995) defines stakeholders as those who are positively or
negatively affected by the activities or final results of a project. He classifies them under the
following headings: project champions (including investors, project sponsors, upper
management, clients and politicians); project participants (including the project manager,
team members, suppliers, contractors, specialists, and regulatory agencies): and external
stakeholders (including environmentalists, community leaders, social groups, the media, and
project team family members). Other classifications include primary versus secondary by
Cleland (1999) as illustrated in module 1, and internal versus external.
It is important that you understand where each stakeholder sits in relation to the project
which is why a stakeholder analysis will identify where risks can arise from a stakeholder
perspective, and how you can best use your project resources to reduce those risks, and
increase the likelihood of project success. Carrying out a simple matrix analysis to identify
which stakeholders have a high or low level of interest and a high or low level of power to
influence project outcomes will reveal which stakeholders sit in that high interest/high power
quadrant. More detailed discussion on how to manage stakeholders is provided in MGT8027
Project HR, communications & integration management.
Other more sophisticated methods of analysing stakeholders have been developed and
selected reading 7.2 provides an insight into the identification and analysis of project
stakeholders.

Reading activity
To set the scene for the need for soft skills in project management, read selected
reading 7.2 by Bourne & Walker, 2005.
Reading activity
To explore the influence of stakeholders in project management, read the set
text by Turner, chapter 4, pp. 71-83.
7.3 Project organisation types
7.3.1 The organisation continuum

It has long been suggested that there are three major organisational forms used in the
management of projects – functional, matrix and project – and these may be presented as a
continuum ranging from functional at one end to project at the other (Salapatas 1981). The
continuum is based on the percentage of people who work in their own functional department
versus those who are full time members of a project team. The dividing line between
functional and matrix is the point at which an individual is appointed with part-time
responsibility for coordination across functional department lines. Figure 7.1 illustrates the
continuum principle.

Figure 7.1: Organisational continuum in project management
(Source: Salapatas 1981, p. 63, colour enhanced by USQ.)
Matrix organisations are often described as strong or weak. Strong and weak are not used in
the sense of good and bad, rather they refer to the relative size and power of the integrative
function in the matrix.
The bottom line of the continuum diagram shows a weak matrix has a part-time coordinator.
Power remains with the functional manager. The matrix gets stronger as you move from full-
time coordinator to full-time project manager and finally to a project office that includes
such people as systems engineers, cost analysts and accountants, and planners/schedulers.
The difference between coordinator and manager is the difference between mere integration
and actual decision making.
Table 7.1 defines in further detail the different styles of project management structures that
can exist along the continuum.

Table 7.1: Project management structures
(Source: Larson & Gobeli 1987, p. 129)
7.3.2 Functional organisation – advantages and disadvantages

In a project-related environment, the most common form of organisational structure is the
functional organisation, sometimes called a bureaucracy. The organisational structure is
broken down into different functional areas such as engineering, finance, production,
marketing, logistics, personnel and so forth. Each functional area has a senior manager who
has a line responsibility. In the functional line resides the particular specialisation and its
hierarchy of experts and vested interests. The prominence of this centre of expertise in the
functional organisation is closely guarded and any attempts to usurp this position will be
strongly opposed. Take for example the engineering department – it has all the design, test
and development engineers and is managed by a hierarchy of engineers under the chief
engineer. It is both the written and unwritten law that all engineering matters must be
‘cleared’ by the engineering department. Although there may be senior professional
engineers in the Manufacturing Department, or the Quality Assurance Department, these are
not seen as having the same degree of authority as those in the specific functional division of
the organisation.
While the disadvantages of functional organisations may seem to be its rigid and specialised
structure, its strengths lie in its specialised departments and its on-going stability. Figure 7.2
shows the structure of a typical functional organisation with its respective advantages and
disadvantages.

Figure 7.2: Firm organised by functional departments
The functional organisation is the traditional structure for a manufacturing company which
has general management requirements associated with on-going operations of a similar type.
Table 7.2 highlights the advantages and disadvantages of the conventional functional
structure in a project context.
Table 7.2: Advantages and disadvantages of functional structures
Advantages Disadvantages
Maximises functional interest Difficulty in achieving coordination
within departmental units between functional areas
Simple communication and Fosters a parochial emphasis on
decision network functional objectives
Results in efficient use of Cost of coordination between
resources departments can be high
Facilitates measurement Employee identification with
of functional outputs and specialist groups makes change
results difficult
Gives status to major functional Limits development of broadly
areas trained managers
Preserves strategic control at Encourages inter-departmental
top management level rivalry and conflict
Client satisfaction can be low
7.3.3 The matrix organisation – the hybrid system

The matrix style of organisation has evolved as a means of providing a project structure
which will maximise the strengths and minimise the weaknesses of functional structures.
In effect, a large organisation sets up a smaller, temporary, special-purpose structure with a

specific objective or set of objectives. It is interesting to note that the internal structure of the
project organisation is very often functional in nature.

The advantage of the project based organisation comes from the single-mindedness of
purpose and the unity of command. Close links are formed and a team spirit is usually
engendered through a clear understanding of well defined objectives. Informal
communications are usually very effective in the close-knit team.
Setting up a new highly visible temporary structure, however, upsets the regular
organisation. Facilities are provided in the new project office which may not be available
elsewhere in the organisation. There is the question of job security for those who go to the
new team – personnel will often lose their position in the functional structure while they are
off working on a project.
The functional, hierarchical organisation is organised around technical inputs, such as

engineering, marketing, accounting etc. The project organisation is a single pDisadvantages
The solution lies in developing a proper balance between long term objectives of the
functional departments in building and maintaining technical expertise and the short-term
objectives of the project. Figure 7.3 shows an example of the Matrix organisation concept.
Figure 7.3: Matrix organisation
The following list in table 7.3 highlights the advantages and disadvantages of the matrix
organisation.
Table 7.3: Advantages and disadvantages of a matrix organisation

Advantages Disadvantages
● Efficient use of resources – individual ● Power struggles – Conflict occurs since
specialists as well as equipment can be boundaries of authority and
shared across projects. responsibility deliberately overlap.
● Project integration – There is a clear ● Heightened conflict – Competition over
and workable mechanism for scarce resources occurs especially when
coordinating work across functional personnel are being shared across
lines. projects.
● Improved information flow – ● Slow reaction time – Heavy emphasis on

Communication is enhanced both consultation and shared decision making

laterally and vertically. retards decision making.
● Flexibility – Frequent contact between ● Difficulty in monitoring and controlling
members from different departments – Multidiscipline involvement heightens
expedite decision making and adaptive information demands and makes it
responses. difficult to evaluate responsibility.
● Discipline retention – Functional experts ● Excessive overhead – Double
and specialists are kept together even management by creating project
though projects come and go. managers.
● Improved motivation and commitment – ● Experienced stress – Dual reporting
Involvement of members in decision relations contribute to ambiguity and
making enhances commitment and role conflict
motivation.
(Source: Larson & Gobeli 1987, p. 130)
Reading activity
Read your text by Turner, chapter 6 for further information on managing
organisational structures in a project context.
Reading activity
Read your text by Turner, chapter 17 for further information on developing
organisational capability and individual competence.
7.4 The project team

Larger projects tend to need a dedicated team of specialists to provide full time attention to
critical operational and technical aspects. These project teams or project offices usually take
the form of small functionally oriented structures reflecting a similarity with the parent
organisation structure.
Figure 7.4 shows the main features of the make-up of a typical project team or project office
for a capital equipment procurement project. The main feature of the structure is the
emphasis placed on the core staff and the partial involvement of some participants; these
often provide services such as computer programming, legal counselling, and contract
development. The figure also shows the fluctuating levels of involvement which occur as the
project progresses.

Figure 7.4: Management team structure for project requiring full project office
The importance of the project to the customer or supplier organisation will often be the
critical factor in determining the level of core staff in the project office. Strengths and
weaknesses of the project team leader can become more apparent when the project team has
a low level of staffing.
One problem that you should be aware of is that the project team within a matrix
organisation can become ‘functional’ in behaviour and integration across the project team
can once again become difficult.
7.4.1 The project manager
Role and responsibilities

Once the project organisation has been designed, it is necessary to allocate staff to it. The
essential aspect of this is that it is done in such a way that each staff member understands
quite clearly what their tasks and responsibilities are. Equally important is to ensure that
somebody is responsible for each and every task in the project – or tasks will be missed.
What sort of person is needed? The following extract from Kerzner (2004) proposes that if
the responsibilities of a project manager were applied to the total organisation, they would
describe the qualities of the general manager.
Project management cannot succeed unless a good project manager is at the controls. The
selection process is an upper-level management responsibility … The major responsibilities
of the project manager include:

● To produce the end item with the available resources and within the constraints of time,
cost, and performance/technology
● To meet contractual profit objectives
● To make all required decisions whether they be for alternatives or termination
● To act as the customer (external) and upper-level and functional (internal)
communications focal point
● To ‘negotiate’ with all functional disciplines for accomplishment of the necessary work
packages within time, cost and performance/technology
● To resolve all conflicts.
(Source: Kerzner 2004, p. 143)
Project managers are often thought to possess power by virtue of their position. In practice
the power of the project manager to dictate the course of the project is flimsy at best. Most
project managers find that the success of the project can be determined by factors far from
the centre of the activity, in areas where the project manager has little or no measure of
control. These areas can include sub-sub contractors (sometimes in foreign countries), other
government departments/regulatory bodies, trade unions, transportation systems and the like.
Situations can arise, arbitrarily and without warning, which can disrupt schedules and
increase costs. Project issues are often decided by steering groups or control boards with
little or no reference to the project manager who has a high degree of responsibility but little
authority.
Part of the project manager’s responsibility is to bring about change, but the recognised
competencies for project managers currently do not include those required for change
management. The skill sets required to do that have been examined by Crawford (2011, p. 1)
who suggests that ‘there is a need for a better understanding of the activities and
competencies required for the effective implementation of change’.
Additionally, a recurring theme in integration management is the need for control of changes
to the project. The project manager must be able to receive inputs from many sources and
effect adjustments as necessary, to keep the project on track. There are many processes by
which change control is managed, such as the establishment of steering groups, or project
control boards. Each of these approaches is another example of an attempt to put in place
effective integration management, and to be effective, the project manager must extend the
scope of his/her vision as indicated in figure 7.5.

Figure 7.5: The project leader’s direction finder
(Source: Adapted from Briner et al. 1996, p. 17, colour enhanced by USQ.)
Reading activity
Read your text by Turner, chapter 6 for further information on managing
organisational structures in a project context.
Reading activity
Read selected reading 7.3 by Ford and Randolph for more information on
project organisational matrix structures.
Reading activity
Read selected reading 7.4 by Crawford, 2011, for an understanding of the
competencies required by a project manager to effectively manage change.

7.5 Resolving conflict in the project organisation

One of the most important roles of the project manager is making decisions and providing
working arrangements which are conducive to reducing conflict within the project and with
outside organisations.
Table 7.4 shows the results of a research project whereby about one hundred experienced
project managers ranked the areas of conflict in project management with the various phases
of the project life. They were asked to rank in order the item which they would expect from
their experience would be the most intense source of conflict. Although the research is dated,
the findings are still indicative of the situations in projects today. However, even though the
schedule may be the ‘source’ of the conflict, it is most likely that this stems from people
issues rather than technical issues.
Table 7.4: Survey rankings of seven sources of conflict

Project formation Build-up Main program Program end
Schedules 3 2 1 1
Priorities 1 1 4 4
Labour 4 5 3 3
Technical opinions 6 4 2 6
Procedures 2 3 5 7
Personality 7 6 7 2
Cost 5 7 6 5
(Source: Adapted from Thamhain & Wilemon, 1975)
Reading activity
Read the set text by Turner, chapter 4, pp. 85-95 for further information on the
creation and management of project teams.
Reading activity
For more information on project organisational structures, teams and conflict,
read selected reading 7.5, Camilleri, chapter 7.

This is a suggested reading for those who have the time, but it is not a Selected
Reading as part of the materials. For additional information on project
organisational structures, you might like to read the PMBOK® Guide, PMI
2008, chapter 9.


Think about the project you are using for assignment 2, develop a simple
organisational chart for the project.
7.6 Project communication

The management of project communications is particularly important to the success of the
project. As Belzer suggests (2001, p. 2):
Few projects fail because the Gantt chart/PERT/CPM are wrong, the
roles/responsibilities are not mapped out in a matrix, or the cost charts were off. More
often they fail because of a project manager’s inability to communicate effectively, work
within the organization’s culture, motivate the project team, manage stakeholder
expectations, understand the business objectives, solve problems effectively, and make
clear and knowledgeable decisions. These are the skills that take time to acquire through
experience, coaching, and mentoring.
You should focus on the aspects of ‘essential information’, ‘timeliness’, ‘accuracy’ and
‘relevance’. The introduction of the computer as a tool for project management brought with
it the capability to drown people in information. When this happens, the value of the
communication is wasted because people do not bother, or are too busy, to fossick through a
pile of paper looking for the one piece of information that may be relevant to them. On the
other hand, the computer has the ability to manipulate data and produce a report very rapidly.
Having a single database and one source of information reduces the potential for
transcription errors, increasing the likely accuracy. ‘Relevance’ is tied to ‘essential
information’. With the computer and well planned project communications, reports can be
tailored so recipients get only the information they need, when they need it. We will look at
the concept of the PMIS later in this module, and you will see how it can produce tailored
information on demand – so long as the input is accurate and up to date, and sufficient effort
has been devoted to the communications plan.
The Tasmanian Government suggests that ‘the types of communication to be considered can
be categorised as verbal, electronic, written or visual based on the purpose of the tool. Mode
(formal or informal), timeliness (slow, moderate or fast) and reach (limited, moderate or
broad) of each type must also be considered’ (Tasmanian Government 2011, p. 81) and Table
7.5 provides examples of the types of communication.
Table 7.5: Types of communications

Verbal Electronic Written Visual
Presentations Personal email to Mailouts of important Display – workplace,
/briefing sessions identified documentation (letter, conference
(one-to-one, one-to- stakeholders (one to memorandum,
many) one, one to many) factsheet, FAQs) Transport advertising
Telephone (one-to- Broadcast email (one Newsletter ‘Roadshow’

one)/Teleconferences to many) Advertising – ‘Parody’ presentation

(one-to-many) newspaper, magazine, – play, puppet show
Internet/intranet web
Forums including online 3D presentation
forums, fact sheets, Pamphlets and
Networking newsletter, brochures (consider
facilitation Sharepoint – web shelf life issues)
sharing of ongoing
Staff meetings project planning with Information in agency
internal and/or newsletters etc
Seminars/workshops external stakeholders
Media release
Community meetings SMS messaging
Ministerial
Launches Weblog
Request for Tender
Specific events Facebook, MySpace, (RFT)
YouTube
Social gatherings Contract
Twitter
Visitation programs Project planning
RSS Feed documentation
Radio/television
CD-ROM/DVDs
Fax stream, faxback
(Source: Tasmanian Government 2011, p. 81)
Burton and Michael (1992) suggest that the communication plan should address the
following:
● ‘Who will be working on the project?

● Who will be affected by the project?
● When do we need to communicate?
● How shall we communicate (by report, letter, memorandum, newsletter, questionnaire,
video presentation, meetings, overhead transparencies, suggestion box)?
● Who is responsible for passing on what areas of information?
● What channels do we need for feedback and who is responsible for giving, receiving and
acting on it’?
(Source: Burton & Michael 1992, p. 98)
One simple way of producing a communication plan is to draw up a matrix, with recipients
down the side and communication formats across the top. Each of the junction points can
contain such detail as the medium to be used and the frequency of transmission.
We now move on to look at stakeholder management. You will find that the selection,
classification and management of the stakeholders in your project impacts directly on your

communication planning. It is vital to success that many of these stakeholders receive

particular tailored information as part of your stakeholder management strategy.
Reading activity
Read the text by Turner, chapter 4, pp. 83-85 on project communication.
Reading activity
Read the text by Turner, chapter 15, on project governance and communication
between key stakeholders.

This is not a selected reading as part of the study materials. Should you like to
read more about project communications, read PMI 2008, PMBOK® Guide
chapter 10, for a review of project communications management and
stakeholder management strategies.

Think about the project you are using for assignment 2. Develop a project
stakeholder communication management strategy for the project.
7.7 The project management information system (PMIS)

An important aspect of communications management in a project environment is the
identification of what information needs to be collected, analysed, stored and disseminated.
Information flows start on day 1 of a project and continue throughout the project and at times
for many years beyond the handover of the project deliverable to cater for warranty periods,
user testing, etc. Communications cover a wide range of media and include telephone calls,
memos, reports, text messages, email, project management plans, etc. Effective management
of the communications could become critical if a dispute arises, and especially so if litigation
takes place. Those parties who have good records tend to be more successful than those who
don’t. However, communications management can be a time-consuming and expensive
function. The formal project management information system (PMIS) has emerged from
computer based critical path systems for project scheduling and the use of database
structures to store and manipulate project data.
In broad terms a PMIS could be defined as any system of information which is used by
project managers and participants in the planning and execution of projects. This may be in
printed or electronic format but increasingly, information is captured and manipulated
electronically in digital format by enterprise-wide computer systems that are linked globally
within organisations as well as externally to other stakeholders.

A project management information system should capture and manage data related to:
● people
● activities
● procedures
● technology.
The PMIS can be utilised for:
● collection of the relevant data from multiple sources, often automatically,

● storage until it is required
● processing of data to provide answers to specific questions for better decision-making
● communication of resulting information to those who need to act on it.

This is not a selected reading as part of the study materials. Should you wish to
learn more about PMISs and their relation to project success, you can look up
the following journal article: Raymond, L & Bergeron, F 2008, 'Project
management information systems: An empirical study of their impact on project
managers and project success', International Journal of Project Management,
vol. 26, no. 2, pp. 213-20, viewed 11 January 2012.
7.7.1 The function of project management software

Project management computer software packages are a means of providing a level of detail
in the planning of large and complex projects which would be impractical or impossible by
manual means. PERT (Program Evaluation & Review Technique) and CPM (Critical Path
Method) activity networks can now be generated easily to illustrate the activities that
comprise the project, and the relationships between them.
Many organisations purchase project management software believing that in doing so their
project management problems are overcome. What happens is that a whole new set of
problems begin. Project management software is not easy to use and it often needs a
completely new level of understanding of what the project is about and how things need to
happen. What must always be remembered is that the software is simply an elaborate and
complex data-base system; it will only do a fixed assortment of algorithms, depending on
which process is requested from the menu selections. It needs practice, training and
dedication from the users to learn how to use the software effectively and commitment by
senior management to ensure that this learning process takes place.
When used properly the software provides assistance to project planners and managers in the
development and understanding of their projects. It requires project managers to consider
many aspects of their projects well before actual problems arise. It allows simulations to be
run, and ‘what if...’ questions to be considered and simulated. Your practical work in this
unit will give you an insight into how project management software works and how it can be
integrated together with other common software packages to give a very useful management
system which provides graphic and text reports. If this is the first project management

software system you have used, you will find that it can be used as a base-line for
comparison when judging other project management software specifications in the future.
Basic level
Users applying the software at this level are satisfied with the basic time schedules, bar
charts and reports. Even at this level the information can be extremely useful for overall
project timing and for checking the feasibility of meeting operational target dates which may
be some two to five years away. The software is used to do the hard work of drawing
diagrams and calculating where milestones are likely to occur.
At this level some ‘housekeeping’ data is needed to specify any new project, such as the
calendars, the display options etc. Then all that is needed is to ‘create’ the tasks within the
project, provide an estimate of the time required to complete each task, link these together
using the linking mechanisms provided in the system and, finally, specify either a start or
finish date.
General level
The project which needs to be planned at the general level may not be very complicated but
will have quite a few people and organisations that will be involved in the work.
Accordingly, there is a need to show them all clearly when they will be needed so that the
project to ensure there are no resource conflicts.
Advanced or detailed level

The project at this level is probably a complex development where most of the activities may
be timed in man-hours of work and there are different shifts for the different resources being
used on the tasks. There are different teams of people and these must be coordinated with
other projects in the same organisation. The total project will probably have to be broken
down into minor projects and the work breakdown structure taken to a very detailed work
package level in order to ensure very fine control over costs and expenditure.
Most important aspect

Computer-based project management information systems are driven by algorithms that may
vary from package to package. They are not fool-proof and are subject to the ‘garbage in,
garbage out’ syndrome. The level of precision of calculations and reports can provide a false
sense of security and accuracy in the outputs. Common sense should always be used to
interpret reports generated from a PMIS. Don’t attempt to generate too much detail too early.
Use the PMIS iteratively to gradually improve the level of accuracy as more detailed
information comes to hand.
This section of the module has taken a detailed look at the stakeholder and organisational
context for management of projects and the human resources needed to manage them
effectively. We have considered how to identify and analyse the stakeholders for a project so
we understand their respective requirements, and how we can manage the complex
communications that are necessary to ensure that all stakeholders are kept appropriately
informed and involved. We have looked at the wide range on interpersonal skills that a
project manager needs, especially those to deal with the inevitable conflicts that will arise.
We have considered the allocation of responsibilities for the respective components of
projects because of the need for delegation in a complex project environment.

7.8 Project integration
7.8.1 What is project integration?

In the generic sense, integration is the bringing together of other elements to create an
holistic outcome. In project management, we need to understand the nature of the specific
project we are managing, and bring together the respective elements in an appropriate way. If
we are developing a large and complicated defence-oriented project, integration of weapon
systems, propulsion systems, aviation systems etc is critical for the deliverable to perform as
expected. In such a project, procurement may be a critical aspect of the project. If we are
managing an organisational restructure, procurement may not be a significant aspect of the
project at all. The project manager must take control of the respective ‘strings’ of the project
and manage each aspect without adversely impacting on the other aspects. In a previous
module, we discussed how various ‘triangles’ are frequently discussed in the project
management literature, revealing the interconnectedness of such aspects as scope, time and
cost, or scope, cost and performance. Each of these ‘triangles’ is a simplistic example of
project integration management. Pull one string in a particular way, and other strings are
affected. Each project will require a slightly different touch on each of the nine aspects of
managing projects, as set out in the Guide to the PM Body of Knowledge (or PMBOK®
Guide) (PMI 2008).
Project integration management has been defined by the Project Management Institute in the
Guide to the Project Management Body of Knowledge (PMBOK® Guide) as ‘the processes
and activities needed to identify, define, combine, unify, and coordinate the various
processes and project management activities within the project management process groups’
(PMI 2008, p. 71). It includes ‘characteristics of unification, consolidation, articulation, and
integrative actions that are crucial to project success’ (p. 71). Key activities that form part of
project integration include the following:
1. Develop project charter

2. Develop project management plan
3. Direct and manage project execution
4. Monitor and control project work
5. Perform integrated change control, and
6. Close project or phase
(PMI 2008, p. 71)
7.8.2 Project integration management processes

As we discussed above, integration is the orchestration role played by the project manager or
project director. The project manager must frequently stand back from the details of the
project and study the bigger picture. It is often necessary to revisit the project objectives in
the context of the organisational requirements, and to ‘fine tune’ the processes so that the
outcomes are consistent with the requirements of the major stakeholders. The PMBOK®
Guide (PMI 2008) suggests the following major steps:
● Develop project charter

● Develop project management plan

● Direct and manage project execution
● Monitor and control project work
● Integrated change control
● Close project.
There are many models that attempt to represent the holistic and inclusive nature of project
integration management, and one view of is provided by Turner (1999) in an earlier model of
the integrative processes as illustrated in figure 7.6.
Figure 7.6: An integrated model of project management
(Source: Turner 1999, p. 23, colour enhanced by USQ.)
In module 4, we discussed the business case and the project management plan (PMP). Both
of these are important tools for integration management. The business case creates the initial
framework, bringing together all of the criteria necessary for a project to be regarded as
successful by key stakeholders. The PMP is also a critical document as it brings together all
of the relevant information in one place, at a key point in time when the project sponsor must
make the ‘go/no go’ decision. The PMP often has multiple purposes including gaining
sponsor sign-off and will provide other key stakeholders such as financiers, champions,
steering committee members and project team members with the essential information
needed to fully understand the scope of the project, the risks, the schedule, the budget, etc.
and how it will be achieved. If you get the PM plan correct, you are well on the way to
effective integration management and a successful project. If you get it wrong, you will be on
the back foot right from the start.

The need for, and the importance of, project integration management will increase with the
size and complexity of the project, or the project portfolio if there are more than one project.
A more detailed look at project integration management is provided in MGT8027 Project
human resources, communications and integration management.

Consider the practical integration management steps you would take for the
project you analysed in assignment 2.
Reference list
Belzer, K 2001, Project management : still more art than science, PMForum, viewed 15
December 2011, http://www.pmforum.org/library/papers/2001/ArtthanScience.pdf.
Bourne, L & Walker, DHT 2005, 'Visualising and mapping stakeholder influence',
Management Decision, vol. 43, no. 5, pp. 649-60, viewed 16 December 2011,
http://mosaicprojects.com.au/PDF_Papers/P044_Visualising_mapping.pdf
Briner, W, Hastings, C & Geddes, M 1996, Project leadership, 2nd edn, Gower, Aldershot,
UK.
Burton, C & Michael, N 1992, A practical guide to project management, Kogan Page,
London.
Camilleri, E 2011, Project success: critical factors and behaviours, Gower Publishing
Limited Farnham, UK.
Cleland, D 1999, Strategic design and implementation, 3rd edn, McGraw Hill, New York.
Crawford, L 2011, 'Extending the project management skillset to encompass change

implementation', paper presented to 25th IPMA Global Congress, Brisbane, Australia 9-12
October.
Ford, RC & Randolph, WA 1992, 'Cross-functional structures: a review and integration of

matrix organization and project management', Journal of Management, vol. 18, no. 2, pp.
267-95, viewed 11 January 2012.
Dinsmore, PC 1995, ‘Will the real stakeholders please stand up?’, PMNetwork, Dec.

PMI 2008, A guide to the project management body of knowledge (PMBOK® Guide®
Guide), 4th edn, Project Management Institute, Newtown Square, Pennsylvania.
Raymond, L & Bergeron, F 2008, 'Project management information systems: An empirical

study of their impact on project managers and project success', International Journal of
Project Management, vol. 26, no. 2, pp. 213-20.

Salapatas, JW 1981, ‘Organising for project management’, in LC Struckenbruck (ed.), The

implementation of project management, Addison-Wesley, Reading, Mass, pp. 51–68.
Tasmanian Government 2011, Project Management Guidelines: Version 7, Tasmanian

Government, Hobart.
Thamhain, HJ & Wilemon, DL 1975, ‘Conflict management in project life cycles’, Sloan
Management Review, Summer, pp. 31–50.
Turner, JR 1999, The handbook of project-based management, 2nd edn, McGraw-Hill,

London.
Turner, JR 2009, The handbook of project-based management, 3rd edn, McGraw-Hill,

London.


Module 8 – Monitoring and controlling the project
Objectives
● incorporate appropriate project processes to allow the project to be varied in ways that
increase its ability to meet the needs and expectations of key sponsors
● select and activate appropriate monitoring processes to identify any variance to the
intended project outcomes
● activate appropriate controlling processes to bring any variances back to within
acceptable variance limits.
Learning resources
Text
Turner, RJ 2009, The handbook of project-based management: leading strategic change in
organisations, 3rd edn, McGraw Hill, New York – chapter 13.
Selected readings
Selected reading 8.1: Snyder, JR 2004, 'How to monitor and evaluate projects', in D Cleland
(ed.), Field guide to project management, John Wiley & Sons Inc., Hoboken, USA, pp. 407-
25.
8.1 Introduction
Audio
Listen to audio
In earlier modules, we placed great emphasis on gaining consensus from key stakeholders as
to what was to be delivered to the organisation by virtue of our project, and what benefits it
would bring to the organisation. To increase the likelihood of achieving those objectives, it is
essential that we have:

● the ability to respond to changing circumstances in the project environment by

introducing planned variations to the project in appropriate ways
● the ability to detect unplanned and unwanted changes and to rectify those changes.
Modules 5 to 7 have looked at the nine knowledge areas of project management as suggested
in the Guide to the Project Management Body of Knowledge (PMBOK® Guide) (PMI 2008),
and examined the project management processes for each of those knowledge areas from the
earliest stages of planning to the final stages of project completion.
In this module, we will revisit those processes that relate to the execution stage of the
project, in particular those that relate to monitoring project progress, detection of variances
and applying control processes to bring the project back on track.
Because of the holistic nature of these processes (as opposed to a focus on individual
knowledge areas such as scope, time, cost, etc), these processes belong under the heading of
project integration which we have also discussed under the heading of ‘soft skills’.
8.2 Project integration management processes

As we discussed in module 7, integration is the orchestration role played by the project
manager or project director. It is often necessary to revisit the project objectives in the
context of the organisational requirements, and to ‘fine tune’ the processes so that the
outcomes are consistent with the requirements of the major stakeholders. The PMBOK®
Guide (PMI 2008) suggests the following major steps:
● Develop project charter

● Develop project management plan
● Direct and manage project execution
● Monitor and control project work
● Integrated change control
● Close project.
The PMBOK® Guide (PMI 2008) suggests that there are five major processes which the
project manager must control to manage the project successfully, and these are indicated in
figure 8.1. As the diagram indicates, these processes are not sequential in nature. To some
extent, they all commence on day 1 of the project and they all finish towards the end of the
project. However, they each have their most intensive stage at different points in the project,
and they will follow the sequence of initiation, planning, execution, monitoring/controlling
and closing for most projects, as indicated in figure 8.1. In this module, we are most
interested in the monitoring/controlling processes, the tools available to project managers to
assist in this regard, and the objectives for application of those

Figure 8.1: Process groups interact in a phase or project
For the execution processes, the project manager is most interested in completing the project
in the optimal time frame. That is not necessarily the shortest time frame as there are
substantial costs associated with undertaking a project in the shortest time possible. These
might include the costs associated with working 24 hours each day, even if that was
allowable depending on the nature of the project. This is often the case for projects in remote
locations or for the construction of tunnels where there is little chance of disturbing innocent
stakeholders. The costs might arise from congestion where the project site is physically
constrained. It might be a matter of availability of finance, or of meeting specific deadlines,
or where the project is not required until a date that is some time in the future (e.g. Olympics
Games venues).
A more detailed look at project integration management is provided in MGT8027 Project

human resources, communications and integration management.
8.3 Monitoring and controlling processes

Kloppenborg (2012, p. 389) suggests that ‘monitoring and controlling project work includes
the processes required to track, review, and regulate the progress to meet the performance
objectives of the project plan’. The monitoring process is designed to ‘collect project
performance data with respect to the project plan, to produce performance measures and to
report and disseminate performance information’ (p. 389. The control processes relate to the
comparison of ‘actual performance with planned performance, analysing variances, assessing
trends to effect process process improvements, evaluation possible alternatives, and
recommending appropriate corrective action’ (p. 389).
The monitoring and controlling processes provide the ‘accelerator and brake’ to assist in
maintaining the appropriate level of progress, by responding to the project environment.
Where circumstances are consistent with what was expected, execution activities will

proceed as planned. Where circumstances need to change due to a change in the project
objectives, monitoring and controlling processes will provide the mechanism to bring about
those changes. Where circumstances change unexpectedly and impact on the project
progress, the monitoring and controlling processes will detect those variances and provide
the mechanism for bring about corresponding changes to the execution activities. As we
mentioned above, monitoring and controlling processes must be capable of being both
proactive and reactive towards changes in the respective knowledge areas as indicated in
figure 8.2.
Figure 8.2:
As we can see in figure 8.2, the integrative processes of monitoring and controlling must
continually monitor each major aspect of the project (as denoted by the various knowledge
areas) and respond in the appropriate manner.
In module 5 we discussed the use of Earned Value Analysis to monitor project progress in
terms of both time and costs. We utilise scheduling software for planning purposes but also
use it for monitoring and controlling by comparing intended progress with actual progress.
We utilise accounting processes to establish project budgets and we use monitoring and
controlling processes to ensure that expenditure is consistent with what was expected. We

use quality management to define required quality standards, and monitoring and controlling
processes to ensure that quality outcomes are consistent with those requirements.
Those monitoring and controlling processes will be reflected in the project management
methodology that has been established for managing each project. This will vary from
country to country, organisation to organisation, and project to project, based on common
practice, culture or personal preference.
Proprietary project management methodologies such as Prince2 will provide ready-made

processes and templates for monitoring and controlling. Individual methodologies will
incorporate some form of monitoring and controlling processes from the simple to the
sophisticated. It is important that the processes that are put in place are appropriate for the
environment in which the project is being managed.
8.4 Change control

Projects are often initiated and authorised based on unsubstantiated data and information. It
is impossible to anticipate the future and risk management processes are incorporated to
identify possible changes at the earliest opportunity.
Integrated change control is the process of ‘reviewing all change requests, approving changes
and managing changes to deliverables, organisational process assets, project documents and
project management plan’ (Kloppenborg 2012, p. 390). Change control procedures will be
part of the governance plan defined by key stakeholders to ensure that changes are managed
in accordance with the project objectives. Monitoring and control of the project will relate to
all aspects of the project including scope, cost, time, quality, risk, procurement, human
resources and communication, similar to what we have seen in figure 8.2.
8.4.1 Monitoring and controlling scope

In module 5, we have considered the issues related to scope management. Scope change can
come about for many reasons, both intended and unintended (or scope creep as it is
sometimes called). Few project plans can anticipate every detail of what will be required.
Contingencies are common in project contracts to provide the project manager some
opportunity to revise, increase or reduce scope to ensure the project deliverable is the closest
fit to what is actually required. Contracts with no provision for any variation whatsoever
would be extremely difficult to administer as any measurable change could lead to a breach
of contract. Flexibility is important for practical reasons.
Scope is defined through tools such as work breakdown structures (WBS) and may be
represented in the form of drawings, specifications, photos, samples, etc. By using cost codes
that relate to elements of the WBS, variances in cost or time could be indicators of changes
to actual scope, requiring further investigation and controlling processes to be implemented.
8.4.2 Monitoring and controlling cost

Project budgets are the planning tool to define the financial resources required to complete a
project, and the timing of the availability of those funds. Again, appropriate cost centres

related to the WBS will provide early indicators of any variances to the cost allocations,
allowing remedial action to be taken through the defined contractual mechanisms. Additional
funds may be necessary requiring additional control mechanisms to gain approval from the
approving bodies. Project management information systems (PMIS) will provide a means of
relating costs to schedule and scope, providing an early warning system of potential
variances.
As discussed in module 5, Earned Value Analysis (EVA) will provide a multi-dimensional

view of the costs incurred, time elapsed and value earned for the project based on progress to
date.
8.4.3 Monitoring and controlling time

Gantt charts and networks have been discussed in module 5. They have a valuable role in
planning the project schedule from a strategic and operational perspective. They also provide
an excellent monitoring and controlling tool by allowing actual progress to be tracked against
the planned progress, giving clear evidence of variances and possible problems. Variances
may be caused by unintended changes to the schedule (and these can be ahead of or behind
the original schedule), or by conscious decisions to accelerate or slow down progress for
valid reasons.
8.4.4 Monitoring and controlling quality

Quality can be a subjective dimension and can be difficult to ascertain and evaluate.
Structural elements can be tested (e.g. concrete tests during construction). Other components
can be compared to samples or prototypes to ensure consistency and compliance.
Performance may be more difficult to determine as it may not be possible to test until
completion, at which time it may be too late. Interim tests may be possible (e.g. wind tunnel
tests to confirm performance of aviation components). Individual components may be
capable of being tested, such as components of a software project where various modules can
be tested prior to integration into larger modules. The tools used to monitor and control
quality have been discussed in module 6.
8.4.5 Monitoring and controlling risk

Again, risk is quite subjective. Most project management plans will include an initial risk
register that identifies potential risks to the project outcomes, and may includes means of
monitoring and controlling any such risks that are detected (e.g. discovery of rock while
excavating footings for a construction project). most PM methodologies will include
provision to re-examine potential risks at a regular interval and to review their status and
their treatment. Steps can be taken to accept, transfer, avoid or mitigate in some other way.
8.4.6 Monitoring and controlling procurement

Procurement strategies can be incorporated into the PMP, and these will be reviewed at the
time that procurement activities are undertaken. Strategies may have to be modified due to
changes in the project environment (e.g. lack of suppliers and contractors following a major

event such as floods or other natural disaster). Practices may have to be modified to take
advantage of more competition in the marketplace (e.g. during a recession in the sector of the
industry). The ethics of those involved in procurement activities should be monitored to
discourage any temptation to seek personal advantage by those involved in letting large
contracts. Procurement activities and processes have been discussed in module 6.
8.4.7 Monitoring and controlling human resources

Projects can unfold over lengthy periods of time, and project teams (and other stakeholders)
do not remain static over that time. Sponsor organisations can change. Governance
committees can change. Project team members will inevitably change, leading to a change in
capabilities and experience, which can impact on the skill sets available to manage the
project. The sponsoring organisation may change, leading to different reporting and
authorisation procedures.
8.4.8 Monitoring and controlling communications

A communications plan will be put in place as part of the PMP to ensure that internal and
external communication channels, media and artefacts are appropriately managed. As
stakeholders change, communication requirements will change. As the project progresses,
communication requirements will change.
8.5 Project recovery

Should the monitoring and controlling activities reveal significant variances to the project
that threaten its ability to deliver the intended outcomes and benefits, then a project review
would be carried out to determine the most appropriate course of action. It may be a full
audit of the project to date to determine what went wrong to ensure similar problems are
unlikely to occur. It may be a review to determine the best way forward. More detailed
discussion on project reviews and audits is provided in module 9.
Reading activity
Read selected reading 8.1, Snyder 2004, for an overview of how to monitor and
control projects.
Reading activity
Read the set text by Turner, 2009, chapter 13 on project execution and control.

If you would like to read some more about the monitoring and controlling
processes of project management, you can read the PMBOK® Guide (PMI
2008), Section 3.6, pp. 59-64.


Consider the project you have selected for your assignments. What mechanisms
exist to permit sponsor-initiated change requests to be put in place? What
mechanisms exist to identify unanticipated variances to the respective
dimensions of the project? What mechanisms exist to respond to undesirable
variances?
Conclusion
This module has built on the discussion in modules 5 to 7 relating to the management of the
respective knowledge areas defined in the PMBOK® Guide (PMI 2008). We have looked
specifically at those processes that are required during the execution phase to monitor
progress and achievement at various intervals to identify variances, and to take action that is
essential to bring problems under control. If these processes are managed effectively, the
project should proceed according to plan towards completion, which is examined in more
detail in module 9.
Reference list
Kloppenborg, TJ 2012, Contemporary project management: organize/plan/perform,
Southwestern Cengage Learning, Mason, USA.

Module 9 – Closing the project
Objectives
● carry out appropriate project reviews during the course of the project
● establish whether a project should be terminated prematurely or allowed to complete
naturally
● bring a project to a final completion
● carry out a post-project review after termination or completion.
Learning resources
Text
organisations, 3rd edn, McGraw Hill, New York – chapters 14 and 18.
Selected readings
Selected reading 9.1: Busby, J 1999, ‘An assessment of post-project reviews’, Project
Management Journal, vol. 30, no. 3, pp.23-9.
9.1 Introduction
Audio
Listen to audio
We have now looked at the project as it has progressed from a concept to a stage where it is
being implemented. It is important that we now look forward to how it will all end. If the
project is on track, then it would eventually be brought to a logical conclusion with all of the
appropriate celebrations and congratulations to the team involved. If it has gone astray, then
it may have to be terminated early rather than waste further organisational resources on a
project that is no longer financially viable.

It is always of value to consider some form of project review at critical stages to ensure that
it is really on track, rather than take the word of the project team members who may be
unwilling to be the bearer of bad news until it is too late. If there are concerns, it may be
appropriate to undertake a project audit, which has a more quantitative nature than a review,
which is more general.
When the project has been completed, successfully or otherwise, there is value in
undertaking a post-project review to capture the ‘lessons learned’ while team members are
still accessible. This information can then be stored in an organisational database for the
assistance of team members of future projects.
9.2 Project closure

Project termination and closure attracts a lot of attention because too often projects are not
brought to a close in a timely and efficient manner, resulting in a less than optimal outcome
for the project. The upshot of this is explained by Meredith and Mantel (2003, p. 643):
The skill with which a termination, or a condition called “near termination”, is managed
has a great deal to do with the quality of life after the project. The termination stage of
the project rarely has much impact on technical success or failure, but it has a great
deal to do with residual attitudes towards the project – the“taste left in the mouth”of the
client, senior management, and the project team.
Cooke-Davies (2001, p. 201) points out the difficulty of finding reference to the subject of
project termination in the project management literature. Hopefully these study notes will
provide some useful information on the subject. In the module we will examine the
requirements of project termination. In particular, we will look at why a decision can be
made to terminate a project and the factors that can influence that decision. We will consider
both broad and detailed termination strategies. We will then look at a related aspect – the
reasons behind the failure to terminate a project when there are strong indicators that this
should be done. We will consider the issues that need to be addressed and suggest a planning
process that should cater for them. Finally we will devote some time to the very important
activity of project reviews.
9.2.1 Why terminate a project?

Projects are terminated (or should be) when the work that was planned has been completed.
However, Cleland (1999) suggests that projects can be terminated for a number of reasons:
1. The project results (a product or service) have been delivered to the customer. If
appropriate, service and maintenance contracts can be negotiated and
consummated.
2. The project has overrun its cost and schedule objectives and/or is failing to make
satisfactory progress toward attaining its technical performance objectives.
3. The project owner’s strategy has changed such that the project no longer has a
strategic fit in the owner organization’s future.

4. The project’s champion has been lost, thereby putting the continued application of
resources on the project in doubt.
5. Environmental changes have emerged which adversely influence the project’s future.
6. Advances in the state of the art hoped for in the project (such as in research and
development) have not been realized, and therefore further funding is not
forthcoming.
7. The project’s priority is not high enough to survive in competition with higher-
priority projects.
(Source: Cleland 1999, pp. 347–8)
Kerzner (2003, p. 414) adds some other reasons to this list:
● the idea that the initial planning and market assessment was wrong and there is unlikely
to be a demand for the project product
● a potentially better outcome or product has been proposed
● key people, not only the project champion but perhaps staff with vital skills leave the
organisation
● management has a change of mind for no apparent reason or
● it is found that the project is too complex for the organisation’s skill capability.
From a more practical perspective, where projects reach a natural conclusion, they need to be
terminated (Hamburger & Spirer 1989, pp. 588–9) or completed so that:
● Final payments can be made, avoiding unnecessary expenditure.

● Staff can be redeployed, avoiding paying staff that have little to do.
● Final documentation can be passed to the client so they can use whatever the project’s
product is without risk of under-performance or damage.
● Final documentation may be required to allow compliance with Government regulations.
● Qualified staff are available to other organisation projects and potential morale problems
are avoided.
● Supplier – organisation relationships are not damaged through procurement processes
dragging on.
● Lessons learned from the project, particularly the accuracy of estimating methodologies,
are available to assist future projects.
● All unused material can be returned to the rightful owners, rather than risk it being lost.
● A date for the commencement of any warranty period can be set quite clearly and
management of the warranty process can commence.
9.2.2 How to decide to terminate

Cleland (1999) suggests that the answers to the following questions should guide the
decision as to whether a project should be terminated or not:
Does the project continue to fit the strategic plans of the organization?

Does the project continue to complement a strength of the organization?
Correspondingly, does the project avoid a dependence on a weakness in the

organization?
Is the project still consistent with the strategy of the sponsoring organization?
Will the project continue to help that organization achieve its objectives?
Will the completion of the project help that organisation to accomplish its goals?
If the project’s results are put into an operating mode, will these results provide a
competitive advantage to the sponsoring organization?
Can the project owner continue to assume the financial and other risks associated with
the project?
Does the project continue to represent a specific step along the way to the
accomplishment of the project owner’s objectives and mission?
Does the project continue to be directly related to established strategies?
Does the project team believe that the project continues to have a strategic fit in the
design and execution of organizational strategies? If not, why not?
(Source: Cleland 1999, pp. 350–2)
One would hope that many of these questions were answered before the project was
approved to proceed from concept to definition and then re-assessed before the decision to
implement the project was made. With most projects, particularly longer ones, however, the
environment will change and the questions will need asking again. These questions should be
considered during a regular review process which, as Cleland (1999, p. 352) points out,
should not be allowed to focus only on time, cost and technical factors but must also
consider the continuing need for the project in light of any changes to the organisation’s
strategic situation. The conduct of these reviews will be addressed later in these study notes.
9.2.3 Termination strategies

There are a number of strategies that can be used to terminate a project. Some of these will
be fixed by the nature of the project whereas others may be selected by the sponsor
organisation. Meredith and Mantel (2000, pp. 541–5) discuss four different varieties.
The first they call Termination by extinction. In this situation the project is stopped, either
because it has achieved the objective and the new system (a machine, a program, a strategy
or a policy, for example) has been commissioned and is operating successfully, or because it
has been decided to terminate for any number of the reasons 2 to 7 listed above by Cleland
(1999). Meredith and Mantel (2000) note that with this strategy productive work on the
project ceases but there is a considerable amount of organisational work that must be
completed (this will be discussed later).
Their second strategy they call Termination by addition, so named because the project’s
outcome is ‘added’ to the organisation. They cite as an example where a range of IT courses

at a University become a fully fledged department. For this strategy to be used, normally the
project would be in-house and have to be at least a partial success (so there is something to
add). Unlike the earlier strategy of extinction, with addition the resources tend to stay with
the project as it transitions to become a separate component of the overall organisation or
system.
The third strategy is Termination by integration. With this approach, the project’s outcome
becomes an integral part of the parent organisation or system, as do many of the project’s
resources. This strategy brings with it the problem fitting the facilities, equipment, personnel
and their functions into the owning organisation. The complexity of this strategy will
increase with the spread of the integration, for example, it could involve placing people in all
divisions of the organisation and training the original staff so they can all use whatever the
new system is that the project has developed. Meredith and Mantel (2000, p. 544) highlight
particular areas that may need attention: personnel, including the fate of the project team and
the continuing operation of the new development; manufacturing, including training and the
effect of the new system on the old; finance, including the closure of the project and ensuring
that the operation of the new system is included in relevant annual budgets; engineering,
including as-built drawings, operating instructions and maintenance programmes;
information systems, including testing, documentation and training; and marketing and
logistics when appropriate.
Their fourth strategy is Termination by starvation, which is not really a termination but a
strategy whereby the project continues as an entity but is starved of money and resources so
it cannot achieve its objectives. This situation can occur when management are not prepared
to admit that the project is obsolete or unnecessary in case this is seen as their failure.
Hamburger and Spirer (1989) differentiate between termination by extinction and

termination by addition or integration with the terms ‘natural completion’ and ‘unnatural
completion’. Natural completion refers to the termination of a project after the objective has
been met and all major deliverables have been completed. Unnatural completion, on the
other hand, refers to those projects that are stopped, regardless of what may have been
achieved, for any of the reasons listed above. Hamburger and Spirer (1989, p. 590) make the
point that the termination process in either case would be similar but that the atmosphere
could be quite different. If you are caught in a situation like this with a project, you should
consider the following factors:
● The suddenness of termination increases the complexity of the process.

● The project team are likely to be demoralised and not keen to continue.
● It is unlikely that you will have a project finalisation plan.
● Senior management will have lost interest, making it difficult for you to get the support
you need.
● Similarly, the project’s priority will have been reduced.
● The client will be more difficult to deal with.
● The technical effort will not require completion.
● You will have to decide the fate of completed items.
● You may need to assess the possibility/feasibility of a re-start in the future.
Considering a termination strategy at a more detailed level, Cleland (1999, p. 356) lists a
number of activities. The activities will vary from project to project, and will to an extent

depend on whether the client is internal or external. Cleland suggests that in some
organisations the first step in the termination process would be to replace the project
manager with somebody skilled at closing projects. Hamburger and Spirer (1989, p. 591)
support this idea, at least in theory. They explain that a project manager who has the broad
vision, the energy and the drive to get a project up and running may not also be good at the
mundane but important detailed work that is required at the end of a project.
If a new project manager is appointed, they need to review the project – the status of each
work package and its associated budget, schedule and technical performance. Once this is
done, the following must also be carried out:
Ensure that all project deliverable end products have been provided to the project owner
and that all project functional work is finished, along with any closeout records.
Review the status of all contracts to ensure that requirements have been met or
provisions made if such requirements have not been duly satisfied.
Work with the project team in developing and distributing a closeout plan that provides
guidance for an orderly termination of all elements of the project.
Maintain an ongoing surveillance of the closeout activities, including the closeout of all
records and the disposition of materials.
Notify relevant stakeholders of the termination.
Ensure that all financial matters on the project have been satisfactorily terminated.
Assist members of the project team to find other work in the organisation.
Prepare the project history, particularly a ‘lessons learned’ report, so that future teams
in the organisation can benefit from the experiences of the project.
Conduct a post-completion audit of the project to identify strengths and weaknesses in

the management of the project, what impact mistakes have had, how such mistakes can
be avoided in future projects, and how that organisation was affected, positively or
negatively, by the project.
(Source: Cleland 1999, p. 356)
9.2.4 Why don’t they terminate?

Many projects get into difficulties at some stage during their life cycle. When this happens
an assessment has to be made as to the extent of the problems and then management must
decide whether to continue with the project or to close it down. This assessment is usually
done through some sort of project review process – this will be addressed later in these notes.
If it is decided to continue, it is then necessary to plan the way ahead, to work out the process
required to develop the project from the current situation to a point where the original
objectives are attained. Having said this, there will be occasions when, as part of the ‘rescue
package’, original objectives may be varied, perhaps to be more achievable. The process of
assessing the project, deciding to continue or terminate and then re-planning if required
appears quite logical but you must not forget that there are people involved in this process so
cold, hard logic may not necessarily be applied. Staw and Ross (1991) conducted research

into why projects may not be terminated when logic and common sense would suggest that
they should be (termination by starvation is probably an example of this). In their research
paper they discussed some of the psychological reasons that, firstly, can lead to project
managers refusing to accept that there is a problem and secondly, if and when they do,
deciding to tough it out, rather than allowing common sense to prevail.
They argue that there are groups of factors that can lead to this irrational behaviour. The
factors can be pertinent to the actual project, to the manager, to normal social pressures and
to the organisation owning the project. In the first instance, the seriousness of a problem
besetting a project may be ignored, the problem being treated as just one of those problems
you expect in a project. Also projects with limited salvage value and high exit costs will
probably be allowed to continue even though there may be clear signs that the objective will
not be achieved.
Their second group of factors relate to the project manager. They point out that
reinforcement theory has shown that people that have been rewarded regularly for some form
of behaviour will continue that behaviour even if the rewards become smaller and
intermittent. This encourages project managers to tough things out, to keep going when the
signs are bad because they are sure they will eventually be rewarded. Another factor in this
group relates to the tendency for humans to see what they want to see. In the project setting
this means that the project manager will tend to put the best possible interpretation on
information and, if it is impossible to do this, may discredit the source. Their third factor in
the group is the need for self justification that most of us have. A project manager is likely to
invest further resources in a project that is unsuccessful, to avoid thinking that they may have
failed.
The third group relate to the social pressures that influence most of us. Firstly people do not
want to be seen as a failure by their peers so, if they are closely identified with a project, they
will strive to make it a success long after any hope of this has disappeared. They will be
found defending the project, regardless of the real situation. Secondly, we are all aware that
society admires strong leaders, particularly those who build a reputation for turning a failing
situation around. This encourages project managers to keep driving their projects, even past
the point of failure, because of the potential effect on their reputations.
The final group of factors pertain to the organisation itself. Organisations, particularly very
large ones, can have policies and procedures that encourage the status quo, rather than
flexibility. This means that projects continue because of ‘administrative inertia’– it is seen as
just too difficult to carry out all the activities needed to close a project, redeploying
personnel, releasing facilities, closing books of accounts and trying to find a use for whatever
the project has produced to date; it is much simpler to just let the project continue. Another
relevant factor can be political – senior managers have too much of their own credibility,
reputation and future tied up in the project to terminate it. No matter the likely reduced
benefits that the project will probably deliver, ways of keeping it going will be found.
Staw and Ross (1991) suggest some solutions to the factors outlined above. They group these
in to two categories – those that can be used by the project manager and those that need the
organisation to do something. Project managers can avoid a number of problems if they
recognise their own over commitment to a project. The authors suggest they should ask
themselves the following on a regular basis:
Do I have trouble defining what would constitute failure for this project or decision? Is
my definition of failure ambiguous, or does it shift as the project evolves?

Would failure on this project radically change the way I think of myself as a manager or
as a person? Have I bet the ranch on this venture for my career or for my own
satisfaction?
Do I have trouble hearing other people’s concerns about the project, and do I sometimes
evaluate others’ competence on the basis of their support for the project?
Do I generally evaluate how various events and actions will affect the project before I
think about how they will affect other areas of the organization or the company as a
whole?
Do I sometimes think that if this project ends, there will be no tomorrow?
(Source: Staw & Ross 1991, p. 61)
They suggest that some organisational action that could reduce the risk of projects not being
terminated when they should be is to change project managers. They admit this would be
disruptive and costly, but argue that replacing those people who are committed to what has
become a failing course of action should lead to more rational decisions about the way ahead
being made. A variation on this theme, they suggest, would be to introduce a separate
decision maker to handle difficult, contentious decisions that relate to the project’s
continuation. A third suggestion is for organisations to reduce the price of failure. They make
the point that a project manager whose career progression is directly linked to a project’s
success or failure will quickly realise they have nothing to gain and everything to lose by
stopping a project – they will press on regardless of the signs, hoping for a miracle.
Organisations can overcome this by rewarding project management process rather than
outcome – a project manager who manages a project competently should not be punished if it
fails. Finally they suggest that projects should be supported by an information management
system that is honest because:
Several laboratory experiments have shown that people will withdraw from escalating
situations when they see the high costs of persisting.
(Source: Staw & Ross 1991, p. 62)
9.3 The termination process

This brings us to the stage where a decision has been taken to terminate a project or,
hopefully the project has reached its logical and natural completion. We must now increase
management effort, as shown in the graph in figure 9.1. This follows a trough where
construction/production/ manufacturing/development dominated the mainstream of a project
activity. Projects tend to ‘linger on’ longer than is generally necessary if this surge in energy
is not provided. The effect of this, for the supplier, is cost leakage or continued charging to
the project of labour costs and administrative costs while final issues are prolonged; for the
customer, any project staff cannot be re-assigned and must be locked into the project through
its extended final stage.

Figure 9.1: Diagram showing the increase in management activity near the wind-up period
There are a number of factors and considerations that must be catered for when planning the
termination of a project. Hamburger and Spirer (1988, p. 235) divide the potential problems
or issues and, in effect, some of the tasks, into two groups – emotional (or affective) and
intellectual (or cognitive) as indicated in figure 9.2. The terms can be a little confusing, but
the problem groups are quite clear; one group covers the people issues and the other the
practical project termination issues. You should note that they include the perspectives and
problems of both project staff and client in these groups.

Figure 9.2:Termination issue breakdown structure
(Source: Hamburger & Spirer 1988, p. 235, colour enhanced by USQ.)
Hamburger and Spirer (1988, pp. 239–40) suggest a number of activities that can at least
reduce any emotional problems that project staff may suffer. The project manager should:
● Plan closure as a project with its own identity and a clearly defined objective.
● Do whatever possible to get the team to identify with the closure project.
● Hold frequent informal team gatherings (formal team meetings will also be required, but
they are part of normal project management). Staff can be working on a number of
independent tasks so their team allegiance can suffer.
● The project manager should have frequent contact with project staff, no matter how
isolated they may be.
● Plan staff reassignments carefully – choose people with appropriate skills for closure, be
open about reassignments, and get involved in staff placements whenever possible.
Hamburger and Spirer’s paper was written from the perspective of a contract project
manager, doing work for an external client. That is why they discuss the emotional issues
that can arise with client staff and that the project manager may have to handle. In-house
projects may not have these issues but there are similarities between internal and external
clients. Hamburger and Spirer (1988) suggest that the project manager is more likely to gain
cooperation from client staff if they emphasise the benefits that the client staff can get from a

well organised termination – credit for the closure, assurance of ongoing support for the
project’s product, clear warranty obligations and sensible close-out negotiations.
Intellectual issues can be managed by using tools that clearly define what has to be done.
Hamburger and Spirer (1989, pp. 590–1) suggest that the closure should be planned as a
project so the nine functional areas should be addressed as they apply to the closeout:
● Whatever plans may have been made for project termination, in all but short projects
these are probably obsolete and they should be discarded.
● The closeout project needs a closure objective.
● A closure work breakdown structure will need to be constructed.
● Responsibility allocation is very important as there tend to be a large number of small
tasks to be completed during termination and it is easy for some to be overlooked.
● A schedule is necessary but many of the tasks will be independent; a critical path will be
less important.
● As much parallel work as possible should be done as it is important to terminate a project
as quickly as possible.
● Labour expenses will be a major component, as most material will have been consumed
in the project. Unnecessary staff needs to be redeployed as soon as they are no longer
needed.
● At this stage in the project most deliverables should have been transferred to the client
and the project manager’s senior management’s interest will be waning. This means the
project manager’s power at the negotiating table will also be reduced.
Reading activity
Read the set text by Turner, 2009, chapter 14, for further information on the
issues related to bringing a project to a close, either through completion as
intended, or prematurely due to changed circumstances.

Can you think of any project that has continued longer than it should? What
were the reasons for continuing the project? How could the problems have been
addressed at an earlier time?
9.4 How to learn for the future – the project review
9.4.1 Why have them?

Competency standards for project management require a project manager to review a project
once it is complete: to consider the issues that arose, reflect on the way they were addressed

and to develop any pertinent lessons; and then to formulate these into a series of
recommendations that should be passed to the higher project authority. Whenever it is
appropriate, these recommendations should then be incorporated into the organisation’s
project management policies, procedures and methodologies. The importance of the post-
project review is emphasised by Pritchard (1998, p. 382) when he points out that part of
‘maximising positive closeout is the development of and implementation of lessons learned’.
He bemoans the fact that many organisations lose a lot of corporate knowledge with the
disbandment of project teams. He also bemoans the fact that even when an attempt is made
to collect lessons, the effort is often wasted because the way the lessons are analysed and
documented is too shallow.
Pritchard argues that for the lessons learned to provide information of any value, they must
be timely, detailed, relevant and in context. The need for timeliness is obvious – the longer
their collection is delayed after project completion, the more hazy memories become. Also
people become more sanguine with time, so the unpleasantness of some lessons tends to
fade. In particular, with time detail is forgotten, and often the valid lessons are only found at
the detailed level. Relevance is important to the continuous improvement process – if a
particular issue would not arise in any other project, there is little point in considering it.
Context is similar – an issue may be important in one context but not in another.
Busby (1999, p. 23) notes that organisations conduct post-project reasons for very good
reasons. People do not necessarily learn from their own experiences unless they actually
reflect upon the experience. Not everybody in a project has the same experiences. Not
everybody in a project team is equipped to analyse all outcomes. As people can be given
different tasks from time to time, lessons learned previously by others will help avoid the
same mistakes being repeated.
Cooke-Davies (2001, p. 205) takes the concept of post-project reviews a stage further. He
notes that project success is very much in the eye of the beholder; also that time has an
influence on this. Projects that are completed on time and budget look impressive to the
project team and their senior management, at the time, but the client may have a different
attitude sometime later when it is found that the project’s product does not achieve what was
sought. Shenhar, Levy and Dvir (1997) support this contention – their research showed that
there are actually four stages after project completion where project success can be defined
differently. Cooke-Davies argues that because of this any review should be based on agreed
success criteria and that the project should be reviewed twice: one review immediately after
project termination when the detail is still remembered, to derive the lessons learned; and
one some time later to review the benefits. Cooke-Davies (2001) calls this latter review a
post-implementation review (PIR). Various organisations use different names for the review
carried out after a project has been completed. These can include the PIR mentioned, post-
project review, post-project report and project close-out report, as examples. (These
organisations can also require a different range of information, but lessons learned and
recommendations should be included.)
Cook-Davies (2001 p. 205) lists the people who should be involved in the PIR – the project
manager, project sponsor, the project team and at least representatives from all other groups
who participated in the project. He also highlights the need for the review to be honest,
because lessons that have been ‘filtered’ to avoid embarrassment are unlikely to produce
worthwhile lessons. He points out that this is easier said than done:
The skills of creating an atmosphere of trust within a group are subtle and complex, but
some pointers for the conduct of the review meeting can be helpful.

(Source: Cooke-Davies 2001, pp. 205–6)
Busby (1999) studied a number of post-project review meetings to assess whether they were
a worthwhile activity. Like Cooke-Davies, he saw honesty to be a problem. He also noted
that they can be very time and effort consuming, so project managers sometime try to avoid
them – ‘after all, they do not benefit my current project, do they’. He also encountered
people who did not believe that others’ experiences could be passed on – to learn from them,
they had to be experienced first hand. He found that attendees were sceptical about the long
term effect of the reviews – would their organisation actually make any changes? He found
that some of the scepticism was also caused because much of the analysis was superficial.
On a positive note, he also found:
They gave people a chance to demonstrate their concern with the organization’s
objectives.
They helped people correct misconceptions they had learned in the course of normal
project activity.
They gave people the chance to explain and justify their actions in a way that was not
always open to them during the project.
They suggested available practices that had not been realized by those who might have
used them.
They promoted collective remedies and engendered feelings of commitment to them.

Remedies were sometimes dismissed for their superficiality…, but at least they were
voiced collectively.
The reviews had an important disseminating function, although this requires sharing the
review results with outsiders.
(Source: Busby 1999, p. 28)
With the weight of evidence supporting the conduct of post-project reviews, why are they
often carried out so poorly, if they are carried out at all? Cooke-Davies (2001, p. 209)
explains that what can happen is:
● Final payments drive closure. The project team just hope other unresolved issues will
disappear.
● Termination can become acrimonious, with the project team doing the minimum to gain
client acceptance.
● Project teams are moved on to the next urgent project and time cannot be found to meet
to review the previous project.
● Termination documentation (including the review report) is seen as very low priority so
it doesn’t get done.
● Lessons may be collected and stored, but they are not learned.

9.5 The conduct of project reviews

Having established the importance of the post-project review, we should consider how they
should be conducted. Turner (2009) suggests a range of options, ranging in decreasing levels
of formality from a detailed review by an external body, through a properly organised
debriefing session and an informal review limited to the project team to a get together at the
local pub. (I am not convinced that the last form of review would produce much of value, but
it would probably be much more fun.)
The external review could create a range of difficulties but may be necessary if a project has
been terminated early and there is no agreement as to what went wrong. An external review
may also be conducted before termination, to assess whether the project is salvageable. The
person or persons appointed to do the review must be competent in the technical fields
involved in the project. They must also be completely independent and objective and have
not been associated with the project or its decisions. Common grounds for instigating a
review are that the operational performance or technical functioning of the items or system is
expected to be significantly less than expected or that either the costs or time factors are
expected to be significantly overrun, causing considerable embarrassment to higher
management levels in the organisation or even political debate which may damage the
project.
Project reviews under these circumstances are usually conducted by a small multi-
disciplinary team of specialists who have considerable experience in the analysis of
management and technical processes, financial accounting and business legal practices.
Often if the technology of the project is very advanced or the system aspects are extremely
complex it might not be possible for the internal resources of the organisation to provide a
suitable set of independent experts for the review – it may be necessary to engage a special
consultant or group of consultants to advise the review about special technical decisions and
situations.
Higher management will usually provide a brief for the review team which provides the
terms of reference. The terms of reference will include the scope of the investigation, the
authority to seek and obtain materials and information as required, the issues which need to
be addressed, and the specific questions needing to be answered. In most cases where a
project has come under severe and adverse criticism the review is seen to be the most
appropriate way to answer these criticisms and to determine the project prognosis.
Because the very nature of the review process implies criticism and the levelling of blame,
the review team will inevitably strike resistance, animosity and lack of cooperation from
some members of the project staff who will feel threatened by the likely outcome of the
review. This is a fact of life for auditors and this can be minimised by briefing the project
members and being completely open with them about the objectives of the review and the
constructive rather than destructive nature of the purpose of the review.
The above refers to project reviews conducted during the project, and, as is stated, these
reviews are usually only demanded when a project appears to be in trouble. The process
outlined above may also be appropriate for projects that have been reasonably successful, but
in this case there may be no requirement for the same level of formality and the review can
be conducted by actual project participants. Because projects can differ in so many ways, it
is not feasible to dictate a formal review process, however the general conduct of a project
review can be divided into the following stages:

Planning: The review objectives are defined from the instructions which have been provided
as part of the review team brief. From this the various review team experts determine the
performance criteria against which the project results/assessment will be compared. A
suitable means of measurement of performance and performance criteria may not readily be
available and a suitable and appropriate measurement methodology might have to be
developed. The review team must be able to isolate specific attributes which may exist in the
nature of either the project or its environment, so that a structured and analytical framework
can be provided to comprehend the true nature of complex problems in the project and how
the project expected to solve these problems. A work schedule plan is developed which
includes the various stages of the review and the activities needed to complete each phase.
The survey: It is necessary for the review team to become familiar with the project and this
includes understanding its history, its authority and approvals and the operational objectives
for which the project was approved. Close examination of documentary records and detailed
interviews of project staff and other project participants could be time consuming and require
visits to sites where project activity took place, or where persons who can provide visits to
sites where project activity took place, or where persons who can provide required
information may be located. The objective of the survey is to identify issues and situations
which will focus on areas for detailed examination. Project Review specialists, like their
financial audit counterparts, are practised in the art of knowing what to look for as precursors
to project problems. The survey will usually eliminate the areas which do not require a
detailed examination.
Detailed examination: The survey will reveal the critical issues and specific areas of
detailed examination to be undertaken by the review team. Commonly the review will need
to pursue the area of concern/suspicion that was the reason for the review being arranged but
this is not always the case. In many cases this is only the manifestation of several
management or technical problems which have proceeded for some time either undetected or
unactioned.
The current situation: The vital factors in the project structure are examined in detail to
ascertain whether the current situation indicates that the progress made to date is
likely/unlikely to lead to the original project objectives being achieved. This can be a very
difficult task, requiring detailed quantitative assessments and the consultation with experts
who are not associated with the project.
Deciding whether the situation is satisfactory or unsatisfactory: The whole purpose of

the review is to decide whether the current situation is satisfactory or unsatisfactory and the
review team cannot sit on the fence. This is never an easy point in the review process even
though there may be reasons for determining that the situation is ‘grey’ rather than ‘black or
white’.
Determining what went wrong or what is going wrong: This involves following the
various activity paths through the project to determine at what stage or during which
activities the unsatisfactory situations began and how subsequent managerial action may
have not been able to detect the problems. Alternatively, where problems were detected, why
management were not able to bring corrective action to bear. For the review team this is
usually not a difficult task in principle, but may involve complex situational detail which
tends to cloud the basic issues of management competence. The review should rely on
objective data measurement and on a comparison between the data elements found in the
project investigations and the performance standards.

Meredith and Mantel (2003, pp. 661–2) emphasise that the structure of the report is not
important, so long as it addresses the range of subjects necessary. They argue that these
should include:
● Project performance – a comparison between the plan and the outcome, with reasons for
major variations. The PM can include judgements as to why certain outcomes occurred.
● Administrative performance – administrative procedures and processes should be
reviewed, and comments mad about those that worked well and those that did not.
● Organisational structure – the effectiveness of the structure used should be analysed.
● Project and administrative teams – the review report could make confidential comments
about the suitability of particular people to the project environment. It could also
recommend that specific team members or team subgroups be reassigned to other
projects.
● Techniques of project management – the management of the nine functional areas should
be reviewed and any lessons learned – good or bad – should be documented.
Meredith and Mantel (2003, p. 662) highlight that the review should lead to
recommendations for change where considered necessary. They also make the point that
these recommendations should not ignore positive outcomes – if a particular tool, technique,
procedure, organisation, etc. was used and it proved to be effective, it use in the future
should be recommended. Of course, all recommendations have to be justified. You should
note that there comments are very much in line with the NCSPM. As was pointed out at the
beginning of this module, nearly twenty percent of performance criteria support the need for
the nine functional areas of a project to be reviewed, for issues to be addressed, for lessons
learned to be documented and for recommendations for future use or avoidance to be made.
Reading activity
Read selected reading 9.1, Busby, to gain some insights into the carrying out of
project reviews.
Reading activity
Read the set text by Turner, 2009, chapter 18, to complete this consideration of
the issues relating to ongoing evaluation of projects to ensure that they continue
to meet the requirements and expectations of the key sponsors.

Think about the project you have selected for analysis in your assignments. Was
there any project review carried out during the course of the project to ensure
that it was on track? If not, why not? Do you think that some benefit would have
been achieved by doing so?

Conclusion
This module has looked at the issues associated with bringing a project to completion. It
sounds like the easy part of the project. We expect it to simply happen, but the transition
from execution to completion is not a simple pathway. It does not happen on a particular day.
It begins to happen as components of the project are finished and handed over, while other
components may continue on for some time. Responsibility for the deliverables might
continue for months or years so the final completion may extend over a long time frame.
Who remains responsible for those aspects?
We naively believe that our project will take place with few if any problems. We resist the
evidence that suggests our project is not really on track, and think that things will get better.
We realise one day that what we are delivering may not really achieve what our sponsor is
expecting it to do. How do we verify that the project is really on track? Project reviews and
audits are not high on the list when the project scope is defined, but they are critical
dimensions of project success and need to be planned for and included in our list of things to
do.
The final module looks at a range of issues under the title of ‘governance’. What is
governance? How do we as project managers ensure that what we do is ‘right’ under the
circumstances and that what others do is also appropriate? There is a lot of scope for things
to go wrong, either unintentionally on our part, or intentionally on the part of others. It is
important that processes and safeguards are put into place to ensure that our project meets
the level of governance expected by key stakeholders.
Reference list
Busby, JS 1999, ‘An assessment of post-project reviews’, Project Management Journal, vol.
30, no. 3, pp. 23–9.
Cleland, DI 1999, Project management: strategic design and implementation, 3rd edn,
McGraw-Hill, New York, USA.
Cooke-Davies, T 2001, ‘Project closeout management: more than simply saying good-bye
and moving on’, in J Knutson (ed.), Project management for business professionals – a
comprehensive guide, John Wiley & Sons, New York, USA.
Hamburger, DA & Spirer, HF 1988, ‘Phasing out the project’, in D Cleland & W King (eds),
Project management handbook, 2nd edn, Van Nostrand Reinhold, New York, USA.
Hamburger, DA & Spirer, HF 1989, ‘Project completion’, in RL Kimmons & JH Loweree

(eds), Project management – a reference for professionals, Dekker, New York, USA.

Meredith, J & Mantel, S 2000, Project management: a managerial approach, 4th edn, John
Wiley & Sons, New York, USA.

Meredith, JR & Mantel, SJ 2003, Project management: a managerial approach, 5th edn,
John Wiley & Sons, New York.
Pritchard, CL 1998, ‘Project termination: the good, the bad, the ugly’, in DI Cleland (ed.),
Field guide to project management, Van Nostrand Reinhold, New York, USA.
Shenhar, A, Levy, O & Dvir, D 1997, ‘Mapping the dimensions of project success’, Project
Management Journal, vol. 28, no. 2, pp. 5–13.
Staw, BM & Ross, J 1991, Project management, Harvard Business School Press, Boston,
USA, pp. 57–63.

organisations, 3rd edn, McGraw Hill, New York

Module 10 – Ethics and governance
Objectives
● articulate an appropriate ethical framework for your project based on the corporate
ethical values
● define an appropriate governance structure for your project based on the strategic
objectives of the sponsoring organisation
● establish appropriate governance bodies to oversee the project.
Learning resources
Text
organisations, 3rd edn, McGraw Hill, New York – chapter 18, pp. 367-75.
Selected readings
Selected reading 10.1: Pinto, JK, Thoms, P, Trailer, J, Palmer, T & Govekar, M 1998,
Project leadership: from theory to practice, Project Management Institute, Newtown Square,
USA, chapter 7, pp. 87-103.
Selected reading 10.2: Daw, C 2001, 'Ethics management: are you really protected?', in J
Knutson (ed.), Project management for business professionals: a comprehensive guide, John
Wiley & Sons, New York, USA, chapter 21, pp. 384-399.
Selected reading 10.3: Müller, R 2009, Project governance, Gower Publishing Limited,
Farnham, UK, chapter 5, pp. 63-83.
Selected reading 10.4: Burke, Rory 2011, Advanced project management: Fusion method
XYZ – a project methodology systems approach for the project sponsor to implement
corporate strategy, pp. 125-135.

10.1 Introduction
Audio
Listen to audio
In the final chapter of this course, we look at some topics that don’t feature highly in most
texts on project management – ethics and governance. For example, neither word appears in
the index in the PMBOK® Guide (PMI 2008). That may be because the PMBOK® Guide is a
set of standards, or it may be because such topics are highly subjective and difficult to
prescribe. The set text by Turner discusses governance briefly, but does not address issues
related to ethics. These issues are important in a world of litigation and increasingly
legislative responsibility on senior management of organisations, both public and private. It
also concerns the raison d’etre of project management – the optimisation of organisational
and community resources.
Project management practitioners not only see themselves as ‘professionals’ (however that
may be defined) but also want to be recognised by the wider community (and other
professionals) as true professionals. It is not a tag that sits lightly. Doctors take a Hippocratic
oath to publicly acknowledge their primary responsibility towards their patients. Permission
for solicitors to practise in most Australian states is granted by the courts so registration is
not given lightly. These practices and standards have evolved over hundreds of years but
project managers seek professional status based on a few decades of practice with little or
minimal recognised theory. Historical successes of projects are questionable and each
country has its own Body of Knowledge with little or no agreement nor consensus on
practices, standards, methodologies, etc.
We also examine how good principles of governance require project managers to act
responsibly in the interests of the major stakeholders. Governance arises from underlying
questions of ethics. What is the purpose of the project? Which stakeholders are affected and
in which ways? In what way will the project be managed? Who has responsibility?
10.2 Ethics and project management

To understand how good governance can be achieved on a project, it must first be
understood in terms of what ethical behaviour means in a project context. Pinto et al. (1998)
talk about the conflicting roles that a project manager must play in coordinating a project.
She or he is required to manage upwards as well as downwards, so expectations and
dilemmas arise from many directions. Ethics is concerned with ‘determining the rightness or
wrongness of a given decision’ (Pinto et al. 1998, p. 96). Ethics is not directly related to what
is lawful and what is not, however the two may be connected in the sense that many laws
arise from what the community believes is right and wrong. Laws change as community
standards and expectations of relationships and ethical behaviour change.
The project manager is involved in multiple relationships, of which some are sensitive and
which involve conflicting expectations. What is ethical behaviour for the project manager?

How does the project manager define a set of behavioural standards by which project
decisions can be made? If the project manager can resolve this dilemma, this provides a
framework for establishing appropriate governance for the project to meet the requirements
of key stakeholders.
Reading activity
Read selected reading 10.1, Pinto et al. 1998, for a quick overview of ethics in
a project management context.
Daw (2001) points out that projects and project managers are agents of change. As part of
this change management process, organisational values may be affected by the changes
which are inherent in the project itself. She points to:
● Administrative values including efficiency, effectiveness and accountability

● Professional values including respect for others, administrative fairness and values
expected by other parties such as professional bodies, and
● Ethical values including honesty, integrity, objectivity and openness.
In a project context, these impact on:
● Organisational structures and roles

● Project quality outcomes
● Communication policies and practices
● Management of contracts with other parties
● Management and acceptance of risk
● Resolution of conflicts between scope, time, cost performance, etc.
To assist the project manager, she provides a ten-step ethical decision-making model, which
is contained in selected reading 10.2.
Reading activity
Read selected reading 10.2, Daw (2001), which provides an excellent overview
of ethics management in a project management context, including a decision-
making model to assist project managers in resolving ethical dilemmas.

Consider the project you have selected for analysis in your assignments, and the
sponsoring organisation. Write down some key ethical values of the
organisation that you believe should be reflected in the ethical values associated
with the project.

10.3 Strategy and governance

As indicated earlier, this module covers aspects of project management that are not well
covered in most project management texts, nor in Guide to the Project Management Body of
Knowledge (PMBOK® Guide) (PMI 2008).As part of our examination of the importance of
project governance, it is of value to consider the philosophy of ‘management by projects’, so
we can understand why senior management and executives of organisations choose to
undertake activities that are inherently risky to the organisation and why these risks need to
be managed through appropriate governance structures. The outcomes of projects can never
be guaranteed, and history tells us that many projects fail to achieve their objectives on many
counts – time, cost, performance, quality, etc. So why would an organisation undertake such
a venture?
As we have discussed in the early modules, organisations inherently exist to bring about
change of some sort – to create wealth (e.g. mining), to achieve specific objectives (e.g.
develop a new drug to fight disease), or to explore new frontiers (e.g. exploration of Mars).
There are numerous ways of bringing about change, and most of them involve a project of
one type or another in order to achieve that change. So, if we put project management into
that context, we can see that project managers and their teams are really ‘agents of change’
working on behalf of others, subjugating their personal objectives in most instances in order
to achieve the change desired by others, as illustrated in figure 10.1.
Figure 10.1: External and internal forces
(Source: Williams & Parr 2004, p. 8)
To bring about that change, it is essential to have some form of strategy, from which tactics
or intermediate goals can be identified and monitored to determine if the correct strategy has
been chosen. With so many stakeholders involved, how do we select an appropriate strategy?
Whose objectives are really predominant – the project sponsor’s, the project champion’s, the
project end-users’, or the project manager’s? How many ‘bad’ projects have been delivered
on time, on budget, and in conformance with the specification, but to no avail?
Governance is a difficult concept to define. It implies that actions will be undertaken with the
interests of others in mind – but which others?

● Does a surgeon owe an obligation to the hospital administration to reduce costs wherever
possible, or does he owe a duty of care to the patient, regardless of the cost? How much
is a life worth?
● Does a project manager owe an obligation to the immediate supervisor who is determined
to complete the project within the schedule, regardless of what that does to the quality of
the project or to the cost?
● Or does the project manager owe a duty of care to the ‘higher authority’ in the
organisation who has defined the project in terms of objectives?
● Or does the project manager owe a duty of care to the stakeholders, or an even higher
duty of care to the community?
These are complex issues in a world where legal and moral issues are difficult to define, and
upon which they are difficult to find agreement.
10.4 Project governance

Governance provides ‘a framework for ethical decision-making and managerial action within
an organisation that is based on transparency, accountability and defined roles’ Müller 2009,
p. 2). That organisation could be the parent or international entity, it could be a local section,
or it could be a project team. Corporate governance ‘provides the structure through which the
objectives of the company are set, and the means of attaining those objectives and
monitoring performance’ (OECD 2004, cited in Müller 2009, p. 3). He provides a model for
governance of project management as indicated in figure 10.2.
Figure 10.2: Model for governance of project management
(Source: Müller 2009, p. 40)
This model illustrates the need for consideration of many aspects of managing a project.
Governance is not a one-dimension issue – it involves the selection of an appropriate
methodology, creation of a steering committee, ensuring appropriate training and
qualification of key personnel, benchmarking of organisational practices, etc.

Müller (2009) also stresses the importance of the steering group in establishing appropriate
governance for a project, and this is discussed in detail in selected reading 10.3.
Reading activity
Read selected reading10.3: Müller 2009, which provides a model for
governance of projects.
The senior executives and board of directors of an organisation have a responsibility, both
legal and moral, to provide good governance for that organisation. Increasingly we see
evidence where good governance has not been provided and government bodies are
authorised to take severe steps to bring such individuals before the courts for punishment.
In a similar manner, project managers are also expected to provide good governance of their
projects, and this places them in a difficult position where conflicts inevitably arise regarding
the management of the project processes and outcomes.
A broad overview of the dimensions of good governance in a project context is provided in

selected reading 10.4 by Burke (2011). He provides additional perspectives on the
dimensions of corporate governance, corporate ethics, sustainable development (and the
ethical dimensions of achieving that aim), and achieving a balance across the ‘triple bottom
line’ of profit, people and planet, and climate change.
Reading activity
Read selected reading 10.4: Burke 2011, pp, 125-35 for a good coverage of the
topics discussed above.
Reading activity
Read the set text by Turner, 2009, pp. 367-75, for his views on the principles of
good governance associated with project management. This section also looks at
how project audits come under the umbrella of project governance.

Consider the project you have selected for analysis in your assignments, and the
sponsoring organisation. Identify an appropriate governance structure for your
project and what groups might be established as part of governance, to increase
the likelihood that project outcomes are consistent with the expectations of key
stakeholders.
Conclusion
This module has emphasised the need for an organisation to maintain an enterprise-wide
perspective for identifying and achieving organisational objectives, and to see project

management as one component of portfolio management, if all objectives are to be realised

in an effective manner. Good corporate strategy incorporates dimensions of ethical behaviour
and governance, and there must be alignment between those values held at corporate level
with those at lower levels including within the project team.
In the same manner that senior figures in a large organisation are required to demonstrate
good governance of that organisation at all times, project managers are under constant
scrutiny that they have provided good governance of their projects. It is no longer a defence
by the project manager that he/she was acting under instructions. If project managers wish to
represent themselves as ‘professionals’ in a competitive world, then it is essential that
professional skills and expertise are brought to bear on all aspects of the project, and not just
on the ‘hard’ skills relating to time and money.
We have now covered all modules in this course. We have followed our project through its
life cycle from inception to termination and handover to the end user stakeholder. We have
successfully delivered the change requested by the project sponsor, confident that the
benefits will be realised over the operational life span of the delivered project. The project
will require ongoing management throughout its operational life span which could include
major upgrades, alterations, additions, or even its eventual abandonment and termination, but
that is generally seen as a different project. These aspects are covered in MGT8021 Project
sustainability management.
I hope you have gained valuable insights into your own projects, and discovered ways of
managing those projects that fit within your organisation’s methodology. Good luck with the
management of your projects.
Reference list
Burke, Rory 2011, Advanced project management: Fusion method XYZ – a project
methodology systems approach for the project sponsor to implement corporate strategy.
Daw, C 2001, 'Ethics management: are you really protected?', in J Knutson (ed.), Project
management for business professionals: a comprehensive guide, John Wiley & Sons, New
York, USA.
Müller, R 2009, Project governance, Gower Publishing Limited, Farnham, UK.
Pinto, JK, Thoms, P, Trailer, J, Palmer, T & Govekar, M 1998, Project leadership: from
theory to practice, Project Management Institute, Newtown Square, USA.

Bassingstoke, UK.


Study

Uploaded by

Document Information

Original Description:

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

Study

Uploaded by

Copyright:

Available Formats

MGT8022

Project -based management

© University of Southern Queensland, 2012.1.

Module 1 – The nature of projects 1

Module 2 – Systems and strategy 21

Module 3 – Initiating the project 37

Module 4 – Planning the project 47

Module 5 – The hard skills of project management 63

Module 6 – Project quality and risk management 93

Module 7 – The soft skills of project management 115

Module 8 – Monitoring and controlling the project 139

Module 9 – Closing the project 147

Module 10 – Ethics and governance 165

Module 1 – The nature of projects

● differentiate between day-to-day operational activities and project-based activities

Welcome to MGT8022 Project-based management. MGT8022 is one of four courses that

© University of Southern Queensland

1.2 A framework for managing projects

© University of Southern Queensland

(Source: PMI 2008, Table 3-1, p. 43

© University of Southern Queensland

project management management

MGT8022 Project-based management is an introductory course and covers all knowledge

MGT8027 Project HR, communications & integration management considers the

© University of Southern Queensland

1.3 Providing a focus to your studies

1.4 What is a project?

A project is a temporary endeavour undertaken to create a unique product, service, or

(Source: PMI 2008, p. 5)

Stretton (1983) describes a project as having the following characteristics:

© University of Southern Queensland

(Source: Stretton 1983)

A classification of projects using technological uncertainty and program/project management

Figure 1.1: Project classification

(Source: Wideman & Shenhar 2001, colour enhanced by USQ.)

© University of Southern Queensland

Figure 1.2: Complexity-uncertainty relationships in projects

(Source: Hamilton 1997, p. 68, colour enhanced by USQ.)

1.5 How does project management differ from general

© University of Southern Queensland

Figure 1.4: Areas of expertise needed by the project team

(Source: PMI 2004, figure 1-2, p. 13, colour enhanced by USQ.)

© University of Southern Queensland

1.6 What is project management?

(Kwak 2003, n.p.).

In a broad universal sense, it is suggested that project management is a set of coordinated

1.7 The project management processes

© University of Southern Queensland

● monitoring and controlling processes

Figure 1.5: Relationship between project management processes

(Source: Hamilton 1997, p. 80, colour enhanced by USQ.)

© University of Southern Queensland

Figure 1.6: Iterative nature of project management processes

(Source: Adapted from Hamilton 1997, p. 81, colour enhanced by USQ.)

1.8 The organisational context of projects

© University of Southern Queensland

Figure 1.7: Sydney Opera House

Figure 1.8: Integrated management of projects

© University of Southern Queensland

(Source: Gray & Larson 2000, p. 15, colour enhanced by USQ.)

1.9 The strategic role of projects

Figure 1.9: Strategic project management

© University of Southern Queensland