1

Systems Engineering
by Dirk Pons
Edition 3

Cover image: Curiosity Touching Down, Artist's Concept

‘This artist's concept depicts the moment that NASA's Curiosity rover touches down onto
the Martian surface. Curiosity is touching down onto the surface, suspended on a bridle
beneath the spacecraft's descent stage as that stage controls the rate of descent with its
eight throttle-controllable rocket engines. The rover is connected to the descent stage by
three nylon tethers and by an umbilical providing a power and communication connection.
When touchdown is detected, the bridle is cut at the rover end, and the descent stage flies
off to stay clear of the landing site. Entry, descent, and landing for the Mars Science
Laboratory mission includes a combination of technologies inherited from past NASA Mars
missions, as well as exciting new technologies. The sheer size of the Mars Science
Laboratory rover (over one ton, or 900 kilograms) would preclude it from taking advantage
of an airbag-assisted landing. Instead, the Mars Science Laboratory uses the sky crane
touchdown system, which is capable of delivering a much larger rover onto the surface.
The new entry, descent and landing architecture, with its use of guided entry, allows for
more precision. Where the Mars Exploration Rovers could have landed anywhere within
their respective 93-mile by 12-mile (150 by 20 kilometer) landing ellipses, Mars Science
Laboratory will land within a 12-mile (20-kilometer) ellipse! In the depicted scene, More
information about Curiosity is at http://www.nasa.gov/msl and
http://mars.jpl.nasa.gov/msl/.‘

Caption and Image credit: NASA/JPL-Caltech, public domain, caption has been modified to the past tense and simplified,
http://www.nasa.gov/mission_pages/msl/multimedia/gallery/pia14840.html
https://commons.wikimedia.org/wiki/File:593496main_pia14840_full_Curiosity_Touching_Down,_Artist%27s_Concept.jpg

Author biography
Dirk Pons, PhD, Master of [Business] Leadership, Master of Science (Medicine), BScEng (Mech), Chartered
Professional Engineer (CPEng: IPENZ), International Professional Engineer. University of Canterbury,
Christchurch, New Zealand. dirk.pons@canterbury.ac.nz

© Copyright D Pons 2018.

2
Summary
Complex projects do not respond well to piecemeal solutions, because of the
interaction of effects. These problems need to be treated holistically, and
solutions implemented in an integrated manner. It is about avoiding
unintended consequences that could have been anticipated.

This book describes the systems engineering method, and then the project
management method.

Extended abstract
SYSTEMS ENGINEERING ............................................................................................... 16
Systems engineering (SE) is the application of engineering management, design
methods, analysis tools, and testing protocols in a systematic and integrated
manner, for the solution of complex engineering problems. Key principles to SE are
‘requirements analysis’, and ‘validation/verification’. Key methodologies that it uses
are diagrammatic representation, and project management. .................................... 16
The key concepts and principles that underpin systems engineering are to
decompose (break) the technical system into modules (sub-systems). Use a flowchart
to represent the system diagram. ................................................................................ 17
Assess what functionality is necessary. Then aim to provide that, and only that. This is
termed design sufficiency. Any work spent providing more functionality than required
is wasted time. .............................................................................................................. 17
If the project is impossible (the scope is unrealistic relative to the resources) then
determine which functionality is more important, and which can be compromised.
There are almost always both hard (immovable) and soft (negotiable) constraints in
design............................................................................................................................ 17
In many cases there is a simple correspondence between the technical sub-systems
(modules) and the functionality of the system as a whole. In more complex cases one
module may make multiple contributions. .................................................................. 17
Get the people with the best expertise to develop each technical sub-system.
Preferably buy systems that are ready to go – these are invariably more reliable as
they have been used and hence tested by other people. Use custom solutions if really
necessary, but plan for these to have unanticipated problems that will decrease
functionality or delay the project. The sub-systems (modules) may be further
decomposed if necessary, which is termed hierarchical decomposition. .................... 17
The interfaces between the technical sub-systems are where the failures occur even
if the sub-systems themselves are perfect. These interfaces include mechanical
connections, electrical power/voltage, signal/communication compatibility, software
variables (real vs. integer), measurement units (ISO vs. imperial). ............................. 18

3
Verification refers to testing that the sub-system works as intended. This testing is
done at the level of the individual independent sub-systems, and then at the next
level up where multiple sub-systems are assembled together, all the way up to the
top level assembly. ....................................................................................................... 18
Systems engineering is about anticipating what analysis, testing, research and design
is required to get the product into the desired quality state....................................... 22
INCOSE definition: “Systems engineering integrates participating disciplines and
specialty groups into a team effort by coordinating contributions throughout the
system life cycle stages from concept to disposal. Systems engineering balances the
social, business, and technical needs of all stakeholders to achieve a quality product
that meets these needs.” ............................................................................................. 22
Wikipedia Definition: ‘Systems engineering is an interdisciplinary field of engineering
that focuses on how to design and manage complex engineering projects over their
life cycles. It overlaps technical and human-centered disciplines such as control
engineering, industrial engineering, organizational studies, and project management.
...................................................................................................................................... 24
Complex projects don’t respond well to piecemeal solutions, because of the
interaction of effects. These problems need to be treated holistically, and solutions
implemented in an integrated manner. ....................................................................... 25
Most engineering problems are multidisciplinary, and consequently engineers are
expected to have the skills to solve such problems. .................................................... 27
Complex engineering problems usually require cooperative effort to solve them. This
means being able to work collaborative with others from different disciplines. It is
helpful for any one engineer to understand the terminology and the issues faced by
the other other engineers and the non-engineering contributors (marketing, legal,
financial, construction, etc.). ........................................................................................ 29
Due to this complexity, it is not always possible to solve the parts of the problem
independently. Solutions in one area affect others. Consequently it is necessary to
find holistic solutions involving the integration of multiple sub-solutions each of
which is recursively adapted to fit the whole. Systems engineering provides this
integration methodology.............................................................................................. 30
Consulting engineers work for specific clients and provide professional service in the
form of design, analysis, feasibility studies, and project management. They provide
independent expertise to their Clients, i.e. they are not swayed by the specific needs
of other parties, and this objectivity and impartiality is an important part of the value
they offer to the Client. ................................................................................................ 38
The nature of the consulting engineer’s work, at least at the higher level of
abstraction, is systems engineering. These engineers tend not to design specific
products, but rather design larger systems in which other firms will provide
specialised hardware and services. .............................................................................. 39
The V-diagram is a conceptual model, represented graphically, of how the product or
system is developed. .................................................................................................... 42

4
In some countries, notably Germany and to a lesser extent the USA, the process has
been formalised into operating standards within project management
methodologies. In other situations the V diagram is seen more as an idealisation of
the process. .................................................................................................................. 42
The V diagram represents the phases to the project: establishing the client’s needs
(requirements analysis), design to increasing levels of detail, construction,
hierarchical testing & assembly, commissioning and handover to client. ................... 43
A key concept of the V diagram is that test criteria are defined before the design
commences (not after, as is commonly the case). ....................................................... 43
Reviews on the descending leg correspond to design reviews, project decision gates,
and manufacturing/constructability reviews. These types of reviews are directed at
ensuring the outputs of design and decision-making rest on well-founded
assumptions, sound methodology, rational extraction of implications for the life cycle
of the system, thorough consideration of future risks & consequences, and ethically
robust decisions. ........................................................................................................... 45
Reviews on the ascending leg correspond to verification and validation, among other
types. In this context verification refers to the process of confirming the truth, i.e.
that the system has indeed been designed to appropriate criteria and constructed
true to the design. In contrast validation is the later process of assuring that the
system does meet the needs of the client/stakeholders. This may be associated with
acceptance testing, commissioning, and hand-over of the asset to the client.
However there is variability in the use of these two terms. ........................................ 45
In the consulting practice fields the verification processes broadly correspond to peer
review, and this involves an independent person examining the system. .................. 46
A significant part of the commercial application of systems engineering is
determining the specification for the system. There are some commonalities with the
project management scope-setting process as evident in the PMBOK [7], but SE has a
wider field of view than merely the explicit activities and work-packages necessary to
get to the deliverables. ................................................................................................. 49
The requirements analysis process seeks to take the client needs, in all the
dimensions in which the client seeks value, and identify the implications for the
engineering design & development process. ............................................................... 53
Systems engineering is about applying big-picture planning and insight to complex
systems. Visualising the interconnections in complex systems is a difficult task, and
requires special tools for representing the system. This is usually done graphically,
with specialised flowcharts that have specific notation. ............................................. 61
Integration definition zero (IDEF0) flowcharts are a way of representing the
interactions between systems. They are particularly powerful in being able to
differentiate the various types of inputs to an activity. By comparison most flowchart
notations merely mix up all the inputs. The method is also strongly hierarchical,
which matches the SE methodology well. .................................................................... 62
These IDEF0 models readily lend themselves to the creation of sub-models, hence
they are hierarchical. This allows the bigger-picture (high-level) model to show the

5
main activities and their integration, with sub-models setting out the details. Note
that IDEF0 uses the boxes to represent ACTIONS or activities. This makes it easy to
convert into project plans and Gantt charts when more specific work-instructions are
required. This is another benefit to the method. ........................................................ 65
PROJECT INITIATION .................................................................................................... 67
A project charter may be used for projects internal to an organisation. It comprises
the objectives, resources, and delegated authority. .................................................... 70
A tendering process is typically used when spending public money on civil
engineering works, military, and aerospace. However the process may be used in
other situations too. The main activities are that the Client has a need (1), which
arises either because they have money of their own to spend on a certain objective,
or they have a contract from someone else and need help to complete it (sub-
contracting). With a contract type project, the client may ask for a Request for
information (RFI), which seeks to get information from the market about the
technologies and capabilities that may be available. Once the client has defined the
project, they call for bids. The outcome here is called a Request for proposal (RFP)
and goes from the client to the market. ...................................................................... 71
Public-private partnerships (PPP) are a type of project where government and private
companies partner together to develop infrastructure (roads, rail, ports, hospitals,
prisons, schools, etc). Usually the government provides only some of the capital or
underwrites the loan, but carries most of the risk. The private company builds the
asset and then is either paid by the government to operate it, or charges levies to
users. PPPs are popular with governments because they reduce the immediate
capital cost (thus making the government look good) but unpopular with the public
as they result in high costs deep into the future (the public have to pay for these
costs after income tax has already been deducted). Also, service quality from the
firms is often poor, e.g. prisons become violent, electricity networks are not
maintained. Related business structures are alliancing and build-own-operate-and-
transfer (BOOT) arrangements. .................................................................................... 78
Split scope is a negotiation tactic of first seeking to come to agreement on the
technical aspects of the project. Only once that is done does the discussion turn to
the financial details. The costs are then portrayed as natural consequences of the
technical scope. In practice this may be implemented with the ‘Two Envelope
System’. ........................................................................................................................ 79
PROJECT MANAGEMENT ............................................................................................. 82
Project management is a method for coordinating multiple work streams, usually but
not necessarily by different people, to achieve a specific outcome in a finite time
period............................................................................................................................ 82
Projects always have an end. This means that general management, which continues
indefinitely, is not a project. ......................................................................................... 82
Project management is a method that is used to set up these projects beforehand,
and manage them as they unfold. The method arose initially in the aerospace
industries, and was soon accepted in the civil engineering and construction

6
industries. Later project management became appreciated and used in non-
technology areas such as event-management, and within general management. ..... 82
A project is an endeavour (work) that (a) seeks a particular outcome (deliverable), (b)
is of finite duration (time), and (c) involves some customization of activities (either
the outcome is innovative, or the process is unusual, or the work is unfamiliar to the
particular people involved). In addition, most (but not all projects) involve: (d) a
team of people, and (e) constraints on cost (i.e. a budget). ........................................ 83
My definition: A project is a venture of co-ordinated effort to capture an opportunity
within constrained resources (particularly time and cost). ......................................... 83
The concept of FUNCTION – TIME – COST, and the need to optimize all three
variables, is important in project management. This is called the project management
triangle. ......................................................................................................................... 83
The two main stages of a project are ‘planning’ and ‘control’. The planning involves
estimating the likely cost, and determining the workload, project end date, etc. The
control stage arises once the project is running, and involves checking that the tasks
are done on time, monitoring costs, and checking quality of work. ............................ 84
Project planning is the most important engineering management skill after
communication (survey of NZ professional engineers)................................................ 84
Project planning involves anticipating the sub-tasks that will be necessary to get the
outcomes. Relative timing of tasks is usually an essential part of a project, as some
things will always depend on the completion of earlier tasks. .................................... 85
The best way to implement real-life project management is to use software that is
dedicated to the task. There are several software packages that are available.......... 88
The most common representation is the Gantt chart. This has a list of tasks called the
‘work breakdown structure’, and a time axis. The duration of each task is indicated by
the length of its bar. The relationship of ‘precedence’ between tasks is indicated by
‘link’ lines. An alternative representation is the ‘network diagram’............................ 88
With MS Project software, it is important to indent the subsidiary tasks using the
specialized button, not use the indent on the keyboard. Also, create links between
tasks, rather than drag them across the screen. .......................................................... 94
The Project Management Institute (PMI) has developed a ‘Body of Knowledge
(PMBOK)’ [19] that describes the activities that a professional project manager will in
general have to consider. This brings a structured approach to problem solving, as
opposed to ad-hoc solutions with incomplete deliverables, important accessories
omitted, work not budgeted for, unnecessary rework, unanticipated consequences.
.................................................................................................................................... 107
PLANNING .................................................................................................................. 111
The scope is the statement of the project deliverables, e.g. the products and their
features. It gives the criteria that will be used to determine whether the project is
successful. Often this has contractual and financial consequences. In engineering
design terms this corresponds to the functional specification, and in systems
engineering to the requirements analysis. ................................................................. 111

7
Creating an adequate work breakdown structure (WBS) is a key activity in project
management. The WBS is a hierarchical decomposition of the project scope into
pieces of work. While the project scope is focused on deliverables or outcomes of
the project, the WBS shows how the internal work is intended to be done to achieve
those outcomes. ......................................................................................................... 112
The architecture of a project, as expressed in the WBS, typically has an overall
structure of temporal phases (e.g. feasibility study, consultation, design, build, test &
assembly, commission). Within this are commonly found sub-projects for the
technical and hardware components (e.g. road, electrical equipment, foundations,
wind-turbne mechanicals, etc.) .................................................................................. 112
The WBS must be taken to a sufficient level of detail: clear, coordinated, and control.
.................................................................................................................................... 113
The WBS must include all the work needed for its completion. Anything missing is not
part of the project, and will delay the project or increase the cost when found. ..... 113
No unnecessary work should be included in the project. Unnecessary work adds cost
and duration to the project, without affecting the agreed deliverables. .................. 113
Ultimately each task will be allocated to a person, and they will also be given some
time in which to do the work. Thus it is necessary to estimate the duration (length of
time) for each task. ..................................................................................................... 121
In practice the durations are typically entered directly into project management
software, in units of days, weeks, or months............................................................. 121
The Gantt chart is used to define the sequence of tasks by creating ‘links’ between
the tasks. There are several types, these typically being named by the origin and
destination, thus finish-to-start, start-to-start, finish-to-finish, and these may also
have delays (lag and lead). ......................................................................................... 122
Each task needs resources. In this context resources refers to equipment, people,
specialist services, subcontractors, and consumables. These are categorised into
LABOUR cost (duration x hourly rate), FIXED costs which may be lump sum or capital,
and CONSUMABLES (materials that are consumed during the project). ................... 130
Crashing is the allocation of additional resources to activities so that they can be
completed sooner. Crashing may avoid penalties for late completion, and it also
decreases overheads. However crashing also adds cost, which needs to be
anticipated and provided for. The activities on the critical path benefit the most from
being crashed as they determine project duration. Once an activity is crashed, so
other activities will then become critical in turn........................................................ 142
CONTROL .................................................................................................................... 170
A benefit, perhaps even a unique feature, of the project management methodology
is its ability to both plan the project, and management its execution. The latter is
called monitoring and control. ................................................................................... 170
The usual approach to monitoring is to record the current status of the project
typically through progress meetings, on-line collaboration being supported by some
software. Then progress is assessed relative to the original plan, with earned value

8
analysis being a typical mechanism (how much should we have spent by this point in
time?). In parallel the variances in project cost and schedule (time) are determined.
Then the project execution is adjusted to close the gap, based on information about
the extent of the deviation from the plan, and the identity of the tasks concerned.
This information is then summarised and reported. ................................................. 174
The current date is shown as a vertical line in the Gantt chart. All tasks that are not
complete up to that line are behind schedule. When reviewing project progression it
is then possible to concentrate on those activities that are lagging, especially if they
are on the critical path. Project costs are presumed to occur in proportion to the
percent complete. ...................................................................................................... 176
Progress reports vary between organisations. Project managers can expect to have to
deliver verbal and written reports. ............................................................................ 177
Always communicate any matter that has implications for the recipient (client,
superior). .................................................................................................................... 178
Variance in project management refers to the difference between actual and
intended time or cost. It does not have the same meaning as in statistics (where it
refers to the dispersion of random variables about the mean). ................................ 181
Schedule variance is deviation from time plan. A tracking Gantt chart shows the
schedule variance (once a baseline has been saved against which to compare).
Variance is straightforward to determine using software, once the percentage
complete values have been entered. ......................................................................... 181
The baseline is the original project plan, e.g. as agreed by superiors or the client, or
formally approved revisions thereof. Baseline is a fixed project plan. It becomes a
reference against which the actual project performance may be assessed. A baseline
is useful if there is a contract, quotation, or other commitment to others on the
project deliverables. ................................................................................................... 181
The critical path is that set of tasks, which if any one is delayed, will delay the whole
project. It is shown on the Gantt chart in a different colour. .................................... 182
In principle the critical path is calculated (automatically) from the network diagram,
and requires the task durations to be known and the links established. The
calculation determines the amount of slack (or float) in each task. The critical path is
therefore the set of tasks with no slack (or float). ..................................................... 182
Critical path may be used in two complementary ways: to minimise time-threats and
maximise the time value of extra effort. The first is reasonably self-evident, but the
latter may need some explanation: Shortening any activity on the critical path will
decrease the whole project duration. Shortening the activities that are NOT on the
critical path will NOT shorten the project duration, and thus there is less benefit of
making such changes. ................................................................................................. 182
Once the project gets underway, then the costs have to be monitored and controlled,
and corrective action may be necessary. It means that organisations that implement
project management costing tend to need to also implement time-sheet accounting.
.................................................................................................................................... 185

9
Cost variance is the difference between planned (total) project cost and the latest
projected cost. The latter is based on any changes to durations of activities, labour
rates, capital expenses etc. ........................................................................................ 186
Earned value measures progress as the proportion of cost spending: the cost that
should have been spent up to the review date if everything was going exactly to plan.
.................................................................................................................................... 187
Closure is the decommissioning of the project office after a successful project, or
early termination of a bad project. This is often done badly. Many projects attach
‘closure’ as a few tasks at the end of an existing project. Furthermore, the tasks are
executed at a time when incentives and motivation are waning. ............................ 190
The project management method is good at managing time and resources. Its major
weakness is the inability to evaluate the degree of technical completion of the
project. This is a particular risk where the project involves some novelty or uncertain
technical route. Many project failures are due to the inability to fully anticipate all
the technical work (and the rework loops), and the inability to measure functional
completeness. Commissioning is often rushed and done poorly for lack of resources.
.................................................................................................................................... 190
The ‘sunk cost’ bias suggests that people’s decisions about ongoing investment in a
project are influenced by how much they have invested in it. The theory says that the
more money and time they have invested, the more they are likely to want to persist
with the project to completion, i.e. an escalation of commitment bias. However, the
research evidence for the sunk cost bias is ambiguous. ............................................ 197
Maturity models seek to represent the level of achievement (quality) of the
organisation’s processes. They are typically stepped models. Their intent is to
encourage ongoing improvement in the project management (or other) practices. It
provides a means to merge quality management, project management, and strategic
management. For organisations whose work is primarily a series of projects, this is
potentially very valuable. ........................................................................................... 208
RESEARCH TOPICS ...................................................................................................... 211
People are not dispassionate resources. Inability to perceive this is a great failing of
the project management methodology. He aha te mea nui o tea o? What is the most
important thing in the world? He tangata, he tangata, he tangata. It is people, it is
people, it is people. .................................................................................................... 211
The method fails to acknowledge the existence of intrinsic motivators for team
members, neither the motivation that prompts people to be willing to join a project
team, nor the motivation that provides the ongoing quality labour, nor the
motivational discontinuity as the project closes. More research is needed in this area.
.................................................................................................................................... 211

10
Contents
Systems Engineering ...................................................................... 2
Summary ........................................................................................... 3
Extended abstract ............................................................................. 3
Contents ......................................................................................... 11
1 Systems engineering: Integrated solutions ................................. 16
.1 What is it?................................................................................. 16
.2 Key concepts............................................................................. 16
System flowchart: decompose the system into sub-systems ...................................... 17
AIM FOR SUFFICIENCY .................................................................................................. 17
PRIORITISE THE MORE IMPORTANT FUNCTIONAL OUTCOMES .................................. 17
DETERMINE HOW THE TECHNICAL SUB-SYSTEMS RELATE TO THE FUNCTIONALITY .. 17
SELECT ROBUST MODULES ........................................................................................... 17
WATCH THE INTERFACES .............................................................................................. 18
VALIDATE HIERARCHICALLY .......................................................................................... 18

.3 Formal definition of systems engineering................................. 18

.4 Why is systems engineering important? ................................... 27
Required graduate attribute......................................................................................... 27
Why is it necessary? ..................................................................................................... 28
Where does the technology complexity arise? ............................................................ 28

.5 Complexity ................................................................................ 30
A definition of complex problem solving ..................................................................... 30
Strategies for dealing with complexity ......................................................................... 32
Where the wild things are ............................................................................................ 32
Solving complex problems ............................................................................................ 35
Types of engineering work ........................................................................................... 37

.6 Application: Consulting engineer .............................................. 38

2 System development process ............................................... 42
.1 V diagrams ................................................................................ 42

11
 .2 Decision making from the systems engineering perspective .... 44
.3 Requirements analysis .............................................................. 49
.4 Quality function deployment (QFD) .......................................... 57
.5 Life-cycle analysis ..................................................................... 61
.6 Diagrammatic Representation .................................................. 61
IDEF0 notation .............................................................................................................. 62

3 Project initiation .................................................................. 67

.1 Internal projects ....................................................................... 67
.2 External tendering .................................................................... 70
.3 Product design .......................................................................... 73
Hydra contracts with Yellow Hut .................................................................................. 75

.4 External client ........................................................................... 75

Public-private partnerships and alliancing projects .................................................... 78
Ethics............................................................................................................................. 78

.5 Negotiations strategies ............................................................. 78

Optimisation – win x lose ............................................................................................. 79
Transactional - trading sacrifices .................................................................................. 79
Split scope ..................................................................................................................... 79
Building consensus from the big picture then into the details (purpose … deliverables)
...................................................................................................................................... 80
Need stratification and satisficing ................................................................................ 80

4 Project management ............................................................ 82

.1 What is a project? ..................................................................... 82
Why are projects important? ....................................................................................... 82
Project definition .......................................................................................................... 83

.2 Project triangle ......................................................................... 83

.3 Two main stages: ‘planning’ and ‘control’ ............................... 84
.4 Simple project plans ................................................................. 85
Paper based .................................................................................................................. 86
Timelines....................................................................................................................... 87
Software........................................................................................................................ 87

12
 Examples ....................................................................................................................... 89

.5 MS Project tutorial ................................................................... 93

.6 The Project Management body of knowledge (PMBOK) ........ 107
5 Project planning process .................................................... 111
.1 Define the scope ..................................................................... 111
.2 Create the Work breakdown structure ................................... 112
.3 Estimate durations ................................................................. 121
.4 Define the sequence of work .................................................. 122
Determine task interaction......................................................................................... 122
Create links with software .......................................................................................... 125

.5 Allocate resources and costs .................................................. 130

Labour cost ................................................................................................................. 131
Material cost ............................................................................................................... 136
Capital or fixed cost .................................................................................................... 138
Crashing the project ................................................................................................... 142
Load levelling: Balancing workload ............................................................................ 142
Implementing costs in MS Project software .............................................................. 146
Example: Children's play gym ..................................................................................... 148

.6 More advanced scheduling ..................................................... 153

Estimate nominal task durations (1) .......................................................................... 153
Estimate task duration using group (3) ..................................................................... 155
Determine stochastic uncertainty in schedule (2)..................................................... 155
Determine alternative work breakdown structure and links (4) ............................... 155

.7 Apply stochastic methods to estimate duration ..................... 156

Estimate limits ............................................................................................................ 156
Summary diagram....................................................................................................... 157
Fit distribution (2) ....................................................................................................... 158
Apply PERT (3)............................................................................................................. 159
Apply possibilistic method (5) .................................................................................... 162
Apply probabilistic method (6) ................................................................................... 164
Summary: stochastic uncertainty in duration ............................................................ 167

6 Project control and monitoring ........................................... 170

13
 .1 Work streams for executing a project .................................... 170
.2 Overview of monitoring .......................................................... 174
.3 Reporting progress ................................................................. 176
Assess progress relative to plan ................................................................................. 176
Record current status ................................................................................................. 176
Assess progress relative to plan ................................................................................. 176
Report on progress ..................................................................................................... 177

.4 Time and Schedule ................................................................. 181

Baseline....................................................................................................................... 181
Tracking Gantt ............................................................................................................ 181
Critical path................................................................................................................. 182

.5 Monitoring Costs .................................................................... 185

Time-sheets ................................................................................................................ 185
Cost variance .............................................................................................................. 186
Earned value ............................................................................................................... 187

.6 Adjust project execution to close the gap .............................. 189

7 Project closure ................................................................... 190
Deliberately plan for closure ...................................................................................... 190

.1 Introduction ............................................................................ 190

Why is Closure difficult? ............................................................................................. 190
Contractual issues at closure ...................................................................................... 191
Administrative closure ................................................................................................ 191
Learn lessons .............................................................................................................. 192
Check against original criteria of success ................................................................... 193
The PMBOK perspective of closure ............................................................................ 193

.2 Making the decision to terminate early .................................. 194

Predictors of project success ...................................................................................... 194
Initiating hazard events .............................................................................................. 195
Who makes the termination decision? ...................................................................... 196
On what information is a termination decision made? ............................................. 196
What is the mechanisms for making the decision? And is there a Sunk cost bias? ... 197
Perceptions differ by role ........................................................................................... 198
Termination strategy .................................................................................................. 199

14
 .3 Closure process....................................................................... 199
Close project ............................................................................................................... 201
Decide whether to terminate project before completion ......................................... 203
Conditional decision-making in the future (1) ........................................................... 206
Predict likelihood of project outcomes (3) ................................................................. 206

8 Maturity models ................................................................ 208

Introduction ................................................................................................................ 208
Underlying principles .................................................................................................. 208
Implementation .......................................................................................................... 209
Discussion ................................................................................................................... 210

9 Psychology in project management .................................... 211

Strong outcome focus in project management.......................................................... 211
What motivates the project leader (sponsor/champion)? ........................................ 212
Motivation of team members .................................................................................... 212
Hypotheses for intrinsic motivation within project teams ........................................ 213

References ................................................................................. 216

15
1 Systems engineering: Integrated
solutions
SYSTEMS ENGINEERING

.1 What is it?
Systems engineering (SE) is the application of engineering management,
design methods, analysis tools, and testing protocols in a systematic and
integrated manner, for the solution of complex engineering problems. Key
principles to SE are ‘requirements analysis’, and ‘validation/verification’. Key
methodologies that it uses are diagrammatic representation, and project
management.

DOWN SHE GOES: The Curiosity Mars rover was landed by a rocket-powered
hovering skycrane. Getting all this hardware to this situation is a system
problem, not merely a project. Image public domain http://mars.jpl.nasa.gov/m2020/images/PIA14839-fi.jpg

.2 Key concepts

16
System flowchart: decompose the system into sub-systems
The key concepts and principles that underpin systems engineering are to
decompose (break) the technical system into modules (sub-systems). Use a
flowchart to represent the system diagram.

This will need to be updated as the project progresses and more information
becomes available. Look closely at the interfaces (see below).
Example: A robotic device for a Warman student competition might comprise
systems for CHASSIS, PROPULSION, MASTER CONTROLLER HARDWARE,
SOFTWARE, LIFT, BALL SORT, SENSORS.
AIM FOR SUFFICIENCY
Assess what functionality is necessary. Then aim to provide that, and only that.
This is termed design sufficiency. Any work spent providing more functionality
than required is wasted time.
PRIORITISE THE MORE IMPORTANT FUNCTIONAL OUTCOMES
If the project is impossible (the scope is unrealistic relative to the resources)
then determine which functionality is more important, and which can be
compromised. There are almost always both hard (immovable) and soft
(negotiable) constraints in design.
Example: A Warman robotics competition presents a problem that is impossible
for most students to achieve completely. Only a few students will find a
winning solution – most will not achieve the whole set of objectives. Yet
students may be forced to participate. In which case look at the scores for
achieving various objectives. Determine what outcomes to focus on to achieve
the highest possible score, i.e. optimise to get a sufficient pass for the course.
DETERMINE HOW THE TECHNICAL SUB-SYSTEMS RELATE TO THE
FUNCTIONALITY
In many cases there is a simple correspondence between the technical sub-
systems (modules) and the functionality of the system as a whole. In more
complex cases one module may make multiple contributions.
Consider using quality function deployment (QFD) to help yourself better
understand these contributions.
SELECT ROBUST MODULES
Get the people with the best expertise to develop each technical sub-system.
Preferably buy systems that are ready to go – these are invariably more
reliable as they have been used and hence tested by other people. Use custom
solutions if really necessary, but plan for these to have unanticipated problems
that will decrease functionality or delay the project. The sub-systems

17
(modules) may be further decomposed if necessary, which is termed
hierarchical decomposition.
However at the top level all that is needed is the geometry for the physical
outline of the sub-system, and a definition of its interfaces and outputs.
Example: For a Warman robot you will need an electric motor. Are you going
to:
○ Build one from first principles
○ Buy an unpackaged one from an electronics catalogue
○ Buy a packaged one complete with mounting provision cable, and RJ
connector
○ Buy an industrial IP rated motor
Which is sufficient for you?
WATCH THE INTERFACES
The interfaces between the technical sub-systems are where the failures occur
even if the sub-systems themselves are perfect. These interfaces include
mechanical connections, electrical power/voltage, signal/communication
compatibility, software variables (real vs. integer), measurement units (ISO vs.
imperial).
These are what cause projects to fail.
Example: An electrical motor on a Warman robot need to be supplied from a
battery. The electronic controller also needs power. Have you checked what
voltages these are? If they are different then the internal details of your battery
module are suddenly a lot more complex than if both sub-systems use the same
voltage. Consequently you might deliberately avoid this problem by selecting
motors and controller that can operate on the same voltage. Or you might
select the battery for the higher of the two voltages and then put an inefficient
voltage divider in place to lower the voltage for the other sub-system (as
opposed to putting the battery at the lower voltage and then inserting a
switched mode power supply to increase the voltage for the other sub-system.
VALIDATE HIERARCHICALLY
Verification refers to testing that the sub-system works as intended. This
testing is done at the level of the individual independent sub-systems, and
then at the next level up where multiple sub-systems are assembled together,
all the way up to the top level assembly.
See also V-diagrams (below).

.3 Formal definition of systems engineering

The process follows the systematic design methods, by emphasising:

18
 1. Establish the system objectives (this is called Requirements analysis and
Specification),
2. Determine the functional requirements (hence Functional
Analysis/Allocation),
3. Creation of physical artefacts or software code to meet those functional
needs (Synthesis),
4. Systematic processes of testing at the subcomponent and system level
(Evaluation, validation, verification).

An important principle in SE is the decomposition of higher level systems into

sub-systems (analysis). The sub-systems are then solved, and the piece-
solutions synthesised (put together) to create the end solution, with a
particular focus of attention on the interfaces between the systems. Generally
these interfaces are where the technology system fails.

Piecemeal approaches are notorious for resulting in sub-systems that do not

integrate well together, i.e. the individual components work well, but
nonetheless the customer does not get the functionality expected. There are
numerous examples of this, where millions of dollars are spent on (say)
software development projects that fail to satisfy. The SE method takes care to
minimise this risk by a strong emphasis on (a) integration of sub-systems, and
(b) testing and evaluation at every level in the product assembly tree.

Within that general SE framework there are many different approaches that
may be taken, and tools that can be used.

19
Here are more details about the rover deployment. More of the systems
become apparent at this level. For example you can see previous separation
and control activities. There is an even broader context, with the activities
preceding this mission back at Earth with the engineers and scientists
controlling the rover and doing the science. Image credit: http://cdn-
static.zdnet.com/i/r/story/70/00/001653/original/mars-esa-3-620x439.jpg?hash=LJIyBGyuZ2

20
LAUNCH IS TOUGH ON THE HARDWARE: ‘An Atlas V evolved expendable
launch vehicle carries NASA's Mars Science Laboratory from Cape Canaveral
Air Force Station ‘ Caption, Image Public domain, http://en.wikipedia.org/wiki/File:Atlas_V_541_into_the_flight.png

21
Systems engineering is about anticipating what analysis, testing, research and
design is required to get the product into the desired quality state.

It is particularly focussed on:

1. Taking the big-picture perspective: e.g. using Integration definition zero
(IDEF0) flowcharts
2. Making sure that all the design is consistent with the customer
requirements: e.g. using Quality Functional deployment (QFD)
3. Ensuring that the analysis is realistically representative of real issues the
product will have to face in its life, e.g. finite element analysis (FEA)
4. Effectively managing the design & product development process:
typically using project management (PM) methods, and Risk
management (RM)
5. Modelling and simulation. A model is a simplified representation of
processes in the real world, in the form of a mathematical expression,
concept, or physical prototype, that is used to anticipate the likely
behaviour of the real world.
6. Planning for appropriate testing regimes to validate the analyses and
product performance: Design of Experiments (DoE), and Reliability
engineering.
7. Integrating the manufacturing into the design considerations: e.g. Design
for manufacturing and assembly (DFMA) and concurrent engineering
8. Considering the full life of the project (from concept through to
commissioning of plant), and of the product in the customer’s hands
(supply chain, manufacture, distribution & sales, user instructions,
maintenance/support/repair, product disposal, recycling). Hence LIFE-
CYCLE analysis (LCA).

More formal definitions follow:

INCOSE definition: “Systems engineering integrates participating disciplines
and specialty groups into a team effort by coordinating contributions
throughout the system life cycle stages from concept to disposal. Systems
engineering balances the social, business, and technical needs of all
stakeholders to achieve a quality product that meets these needs.”
https://connect.incose.org/Shared%20Documents/INCOSEBrochure.pdf

22
ALL PACKED UP: Multiple systems are required in a space project, and they
all have to work flawlessly. ‘Exploded view of the five major stages of the
MSL spacecraft: 1 Cruise stage, 2 Backshell, 3 Descent stage, 4 Rover, 5
Heatshield, 6 Parachute. ‘ Caption, Image Public domain, http://en.wikipedia.org/wiki/File:MSL-spacecraft-
exploded-view.png

23
Wikipedia Definition: ‘Systems engineering is an interdisciplinary field of
engineering that focuses on how to design and manage complex engineering
projects over their life cycles. It overlaps technical and human-centered
disciplines such as control engineering, industrial engineering, organizational
studies, and project management.
‘Issues such as reliability, logistics, coordination of different teams
(requirement management), evaluation measurements, and other disciplines
become more difficult when dealing with large, complex projects. Systems
engineering deals with work-processes, optimization methods, and risk
management tools in such projects.
Systems Engineering ensures that all likely aspects of a project or system are
considered, and integrated into a whole.’
http://en.wikipedia.org/wiki/Systems_engineering

GOING THERE: ‘NASA's Curiosity rover landed in the Martian crater known as
Gale Crater, which is approximately the size of Connecticut and Rhode Island
combined. A green dot shows where the rover landed, well within its
targeted landing ellipse, outlined in blue.’ Caption, Image (Public domain)
http://en.wikipedia.org/wiki/File:Curiosity_Cradled_by_Gale_Crater.jpg

24
BITS AND PIECES: Sub-systems in the rover itself. Image Public domain,
http://en.wikipedia.org/wiki/File:MSL-spacecraft-exploded-view.png

Complex projects don’t respond well to piecemeal solutions, because of the

interaction of effects. These problems need to be treated holistically, and
solutions implemented in an integrated manner.

25
MANOEUVRE: ‘In the depicted scene, thrusters on the backshell of the
spacecraft's aeroshell are firing to adjust the orientation of the spacecraft
during the guided entry maneuvers. The rover (Curiosity) and the
spacecraft's descent stage are enclosed inside the aeroshell during this
passage through the upper atmosphere of Mars.’ Caption, Image (Public domain),
http://en.wikipedia.org/wiki/File:593419main_pia14834-full_full_Mars_Science_Laboratory_Guided_Entry_at_Mars.jpg

26
.4 Why is systems engineering important?
Required graduate attribute
Most engineering problems are multidisciplinary, and consequently engineers
are expected to have the skills to solve such problems.

These attributes are expressed in the international graduate attributes below.

9. Individual and Team work : Role Function effectively as an individual, and as a

in and diversity of team member or leader in diverse teams and in multi-
disciplinary settings.
10, Communication : Level of Communicate effectively on complex engineering
communication according to activities with the engineering community and
type of activities performed with society at large, such as being able to
comprehend and write effective reports and
design documentation, make effective
presentations, and give and receive clear
instructions.
Project Management and Demonstrate knowledge and understanding of
11. Finance: Level of management engineering and management principles and
required for differing types of apply these to one’s own work, as a member and
activity leader in a team, to manage projects and in
multidisciplinary environments.
Table 1: Selected graduate competencies required for Engineers at the end of a
4yr study programme, as per the Washington Accord [1], paraphrased.

27
Why is it necessary?
Systems engineering is a further development and maturation of two
methodologies: design methods and project management.

The issue is that the conventional design methods are best applied to well-
defined problems where a complete and unambiguous specification is
provided or can be developed at the outset. Alternatively, where creativity is
required in a focussed area. Such design methods are described in the
systematic method and models of Pugh [2], Hales [3], Pahl and Beitz [4],
among others.

These design methods were historically adequate for the development of

products within single-disciple areas, e.g. mechanical cameras, electronic audio
amplifiers, road bridges, and the like. However engineering systems have
become much more complex in the integration of diverse hardware systems
and need for interdisciplinary design activities, and simplistic design methods
are often insufficient.

Examples of complex projects are space probes, extensive civil engineering

infrastructure developments, and user-electronics (e.g. smart phones). Hence
there has been an expansion into the system engineering methodology. SE is
therefore a natural extension of the systematic design methods into more
complex situations. The original design methods are still valid for their narrow
areas, or at the level of simpler systems. They are included within SE.

Where does the technology complexity arise?

The complexity arises from many causes:
 Multiphysics, in the combinations of different mechanics, e.g. injection
molding problems involve mechanical stress, fluid flow, changing
geometry, and material phase change. Non-linear mechanics add further
complexities.
 Multidisciplinary effort, where experts from different specialised
disciplines need to collaborate on the solution, e.g. cell-phones are
required to look good (industrial design), have robust hardware
(electronic engineering), operate predictably (embedded system design,
software engineering, app design), be accepting of rough treatment
(mechanical engineering), be quick to produce (manufacturing
engineering), and sell well (market research and marketing).
28
  Multiple autonomous technology sub-systems need to be integrated to
work together effectively. For example space probes have different
hardware packages developed by different organisations, and these all
need to work smoothly together.
 Sociotechnical interactions, i.e. how users and operators interact with
the hardware. Also referred to as human systems integration and other
such terms. This part of systems engineering introduces the psychology
of cognition, i.e. what goes on in people’s minds when they interact with
the technology. This is an important consideration in most situations,
and especially where human error can cause catastrophic failure (e.g.
flight control systems for aircraft).
 Whole life cycle of the system, including its creation, operation, and
decommissioning. The life of the system may be very long in situations
of civil engineering infrastructure (e.g. potable water and waste pipes in
cities) and hence need careful consideration of effects far into the
future. In other cases the product life is short (e.g. consumer electronics
and cell phones) so environmental considerations at disposal must be
considered even at design time.

The other attributes of complexity as defined by the engineering profession [5]

are also relevant, see also [6]. There are multiple dimensions to these
problems such as technical, environmental, safety, societal, financial, and
other issues. The solution requirements in the different dimensions, or the
needs of the different stakeholders, are widely varying, and in conflict with
each other. A simple optimisation is not easy to find, and instead an element
of engineering judgement is necessary. Each of these dimensions has different
stakeholders with widely varying needs and perceptions of worth.
Consequently complex problems require resolution of critical problems
arising from coupled interactions between wide ranging technical,
engineering and other issues. Holistic solutions are necessary, that require
integration of multiple sub-solutions from different areas.

Complex engineering problems usually require cooperative effort to solve

them. This means being able to work collaborative with others from different
disciplines. It is helpful for any one engineer to understand the terminology
and the issues faced by the other other engineers and the non-engineering
contributors (marketing, legal, financial, construction, etc.).

29
Due to this complexity, it is not always possible to solve the parts of the
problem independently. Solutions in one area affect others. Consequently it is
necessary to find holistic solutions involving the integration of multiple sub-
solutions each of which is recursively adapted to fit the whole. Systems
engineering provides this integration methodology.

Where projects are well-defined, and the sub-components to the solution are
largely independent of each other, then project management methods can be
sufficient. However project management primarily focuses on scope
(deliverables), time and cost. It does not address the technical development as
well as systems engineering.

.5 Complexity
This section elaborates on the above description of engineering complexity.
A definition of complex problem solving
Students tend to think that complexity in engineering problems comes from
mathematical complexity. This is one form of complexity, but actually the form
least likely to be encountered in professional practice. The other more
common forms of complexity arise from the multiple contexts to the problem.
These other dimensions can include not only the technical complexity but also
the user/customer/client, and the need to accommodate financial, societal,
environmental, health & safety, and legal considerations. These are usually
conflicting (mutually exclusive), and hence further complexity arises.

The engineering profession has a DEFINITION OF COMPLEXITY. It is important

because (a) it determines, via the accreditation process, the course content for
the various engineering qualifications, and (b) it defines the level of skill
required for professional registration.

To paraphrase [5], complex engineering problems have some or all of the

following characteristics:
1. Involve multiple dimensions to the problem such as technical,
environmental, safety, societal, financial, and other issues.
2. The solution requirements in the different dimensions, or the needs of
the different stakeholders, are widely varying, and in conflict with each
other. A simple optimisation is not easy to find, and instead an element of
engineering judgement is necessary. Each of these dimensions has
different stakeholders with widely varying needs and perceptions of worth.

30
3. Require resolution of critical problems arising from interactions between
wide ranging technical, engineering and other issues. Holistic solutions are
necessary, that require integration of multiple sub-solutions from different
areas
4. Have significant consequences in multiple dimensions (range of contexts).
These include engineering system functionality, safety & injury,
environmental impacts, liability, financial, and others. These consequences
can be anticipated even if they cannot be predicted. Have an element of
risk, both opportunity and threat. Also an element of potential
catastrophe.
5. Involve infrequently encountered issues. These are outside the problems
encompassed by standards and codes of practice for professional
engineering. Have no obvious solution and require originality in analysis
and innovation in problem-solving. Involve the use of new materials,
techniques, or processes or the use of existing materials, techniques, or
processes in innovative ways.
6. Involve the use of diverse resources. Resources includes multiple people
(teams), money, equipment, materials and technologies.
7. Require sophisticated mathematical tools for analysis of problems and
design of solutions. However this is not a necessary attribute of
complexity.

Most of the complexity in professional engineering problems is not the

mathematics but the multiple CONTEXTS to the problem.

1 Preamble Engineering problems which cannot be resolved without

in-depth engineering knowledge, much of which is at, or
informed by, the forefront of the professional discipline,
and have some or all of the following characteristics:
2 Range of conflicting Involve wide-ranging or conflicting technical, engineering
requirements and other issues
3 Depth of analysis Have no obvious solution and require abstract thinking,
required originality in analysis to formulate suitable models
4 Depth of knowledge Requires research-based knowledge much of which is at,
required or informed by, the forefront of the professional discipline
and which allows a fundamentals-based, first principles
analytical approach
5 Familiarity of issues Involve infrequently encountered issues
6 Extent of applicable Are outside problems encompassed by standards and
codes codes of practice for professional engineering
7 Extent of stakeholder Involve diverse groups of stakeholders with widely varying
involvement and level needs
31
 of conflicting
requirements
8 Consequences Have significant consequences in a range of contexts
9 Interdependence Are high level problems including many component parts
or sub-problems
1 Preamble Complex activities means (engineering) activities or
projects that have some or all of the following
characteristics:
2 Range of resources Involve the use of diverse resources (and for this purpose
resources includes people, money, equipment, materials,
information and technologies)
3 Level of interactions Require resolution of significant problems arising from
interactions between wide-ranging or conflicting technical,
engineering or other issues,
4 Innovation Involve creative use of engineering principles and
research-based knowledge in novel ways.
5 Consequences to Have significant consequences in a range of contexts,
society and the characterized by difficulty of prediction and mitigation
environment
6 Familiarity Can extend beyond previous experiences by applying
principles-based approaches
Table: Definition of complex problems. Source IEM [5].
http://www.ieagreements.com/IEA-Grad-Attr-Prof-Competencies-v2.pdf

Strategies for dealing with complexity

Complex problems are complex precisely because they cannot be solved using
straight-forward methods. See sidebar Dishwasher Design. A variety of
intersecting qualitative requirements all impinge at once. How do you solve
those problems? Where is the Engineering Science method that will tell you
how to proceed? They do not exist. You have to find new methods to cope
and thrive. Perhaps only a few percent of your time each day will be in using
that engineering science learned at university, and the rest will be in solving
complex problems in other domains. So it is important to learn to recognise
the complexity, and have methods (skills) to deal with it.

Where the wild things are

In terms of a systems perspective, the various attributes of complexity
conspire to make difficult problems. The Engineer needs to IDENTIFY THE MULTIPLE
CONTEXTS (DIMENSIONS ) TO THE PROBLEM. In doing so it is important to understand
the different needs of the various stakeholders. The CONTEXT is the meaning
of the problem and the idealised solution as perceived by the people in that

32
situation. Each separate context is a different dimension to the problem, as
people understand the same problem differently and have different
expectations for the solution. Consequently there are multiple criteria of
success, and this adds complexity. It is also necessary to Identify the
consequences of the problem (2). Complex problems are those with significant
consequences in a range of contexts, characterized by difficulty of prediction
and mitigation. The Engineer must also IDENTIFY THE CONFLICTING REQUIREMENTS AND
DEPENDENCIES (3), since problems include many component parts or sub-
problems, in different contexts, that interact together in conflicting ways.
Depending on the level of complexity, and our discussion here is primarily
focussed on the professional engineering level, the PROBLEM IS NON-TRIVIAL (4) as
it is outside the standards and codes of practice and has no obvious solution.

The above is a paraphrase of the IEM definition of complexity, and contains

common textual elements. We can then reformulate this as a process diagram,
to represent the definition as a set of actions in the problem solving process.

33
IDENTIFYING COMPLEXITY: It is important to understand where the
complexity arises in the problems before you. Otherwise you may
34
underestimate the resources needed to solve it, or undersell yourself or your
organisation.

Solving complex problems

Engineers have a specific approach to solving complex problems. Some of this
is evident in the IEM definition of complex problem-solving, but it may be
easier to understand this when represented as a diagram of actions, [see SOLVE
COMPLEX PROBLEMS]. This is also a useful opportunity to clear up confusion about
the terms ANALYSE, MODEL, and DESIGN as these are key to the engineering
methodology.

The first solution tool for the engineer is to ANALYSE THE PROBLEM (1). This
requires abstract thinking, and a fundamentals-based, first principles analytical
approach. Development of these skills is a strong feature of most engineering
degrees. In many cases, though not all, the Engineer uses analysis to CREATE A
MODEL OF THE SYSTEM BEHAVIOUR (2). This can be used for optimising the design.
Complex problems are typically unusual in their nature, and this requires the
Engineer to APPLY INNOVATIVE THINKING (3). This involves creativity, intuition, and
lateral thinking, and some people are better than others at this, and select
careers accordingly. All these activities support the main task, which is to
DESIGN A SOLUTION (4). Skills of engineering design include SATISFICING (finding
sufficient as oppose to perfect solutions), and SYNTHESIS (combination of part
solutions into a new and integrated whole). There is also the execution of the
solution to consider, whereby the Engineer will APPLY A RANGE OF RESOURCES (5)
including people, money, equipment, materials, information and technologies.
This is where the own contextual knowledge, gained from work experience, is
useful. The final activity in the process is to IMPLEMENT A SOLUTION (6), and the
objective is to deliver a completed technical system that meets (preferably
exceeds) the requirements and criteria of success for all the contexts, in
whatever ways those people perceive ‘value’.

35
SOLVING COMPLEX PROBLEMS: Engineers apply systematic methods to solve

36
 complex problems.
Types of engineering work

ANALYSIS: breakdown of complex problem into smaller problems and an

investigation of these individually.

CREATIVITY: lateral associations between ideas, ‘creativity is measured by

originality’, creativity refers to cognitive conceptualisation processes, and
innovation to embodiment in an artefact or other tangible output. Creativity is
the cognitive process of creating novel ideas, solutions and schemas, by the
formation of complex cognitive associations (hence intelligence) between
otherwise nominally unrelated schemas (e.g. from other knowledge areas,
skills or experience), occurring through consciously linear and subconscious
massively-parallel cognitive mechanisms. Innovation is the application of
creativity to solve a problem in a new way. It results in a new product or
process.

CAUSALITY: relationships of cause and effect (objective vs. subjective). Most of

our engineering formulae, at least in the engineering sciences, are objective:
there are nice clear mathematical expressions. You input certain numbers and
a neat number (or set thereof) comes out the other end of the equations.
However most problems in real life do not present so neatly. Most of our
personal decision-making (choices about studies, career, locations, purchasing)
are unsuitable for mathematical modelling, because they are subjective. Some
of the intermediate complexity relationships we can represent with
correlation (e.g. scatter plots, association rules) and other statistical methods.

DESIGN: Development, by means of systematic and creative means, of a plan

(with more or less detail) representing the structure of a system that is
intended to provide a specific functionality. Skills of engineering design include
SATISFICING (finding sufficient as oppose to perfect solutions). Design involves
multiple sub-optimisations using quantitative and qualitative variables, being
processed by algorithms as well as heuristics, along solution paths that are only
partly evident at the outset.

DETERMINISM: level of uncertainty in a variable (quantitative vs. qualitative).

Actually the quantitative vs. qualitative differentiation is a bit simple. There is a
sliding scale from single numerical value (which we use for most of our
engineering calculations), through safety factors, ranges (optimistic and
37
pessimistic estimates, probability distributions, intervals & fuzzy theory), and
finally qualitative variables (e.g. ‘hot/cool/cold’).

DYNAMIC: changing with time (dynamic vs. static). Much of our engineering
analysis is static. We include some dynamic effects in fatigue design, but even
then we tend to reduce it to an equivalent static effect. We see dynamic
effects in simple harmonic motion, but that really is not very complex. The full
complexity of dynamic effects is instead seen in something like the two-bar
pendulum. We also have vibrations and dynamic loads on structures. Cashflow
projections in engineering management are another dynamic effect. Dynamic
systems are always harder to analyse.

LINEAR: relationships of cause and effect are proportional (linear vs. non-
linear). Example of linear is: double the force and the strain doubles too. In
mechanical engineering we see non-linearily mainly in plastic behaviour of
materials. We also see it when FEA geometry changes under loading, e.g. low
stiffness rubber parts.

MODEL: A simplified representation, usually mathematical, used to explain the

workings of a real world system or event. In engineering it is often based on
physical mechanics such as thermodynamics, fluid mechanics, structural
mechanics, dynamics & statics, but other principles are equally applicable.
These include probability (e.g. fault trees), queueing theory (e.g. production
plant flow), economics (e.g. business models for profitable route to market),
and statistical models that correlate variables (e.g. ANOVA, factors analysis,
path analysis).

SYNTHESIS: Combination of part solutions into a new and integrated whole.

Also synthesis of information to provide valid conclusions.

.6 Application: Consulting engineer

Consulting engineers work for specific clients and provide professional service
in the form of design, analysis, feasibility studies, and project management.
They provide independent expertise to their Clients, i.e. they are not swayed by
the specific needs of other parties, and this objectivity and impartiality is an
important part of the value they offer to the Client.

So much so that in some cases clients who already have a solution in mind, or
who are being pressed by other stakeholders into a particular solution, will
38
employ a consulting engineer for the purpose of making sure that all options
have been fairly considered. This is a debiasing or due-diligence type of role,
but there are many other ways that consulting engineers operate.

The nature of the consulting engineer’s work, at least at the higher level of
abstraction, is systems engineering. These engineers tend not to design specific
products, but rather design larger systems in which other firms will provide
specialised hardware and services.

For example an engineer designing a water treatment plant will be involved at

the level of the overall site plan and will specify the capabilities of the various
pumps, tanks, pipes, control systems etc. The pumps will be provided by a
separate pump manufacturer, with whom the consulting engineer will
communicate. The consulting engineer wants to ensure the right kind of pump
is specified, e.g. power rating, flow characteristics, whether the impeller can
handle grit and sewer waste, what upstream screening is required, etc. The
actual design of the impeller is done by the design engineers working for the
pump manufacturer, not the consulting engineer. Of course the consulting
engineer needs the background knowledge and appreciation of the
technology, so as to make a sound recommendation, and it is this that the
Client is paying for.

39
Sha Tin Water treatment plant in Hong Kong.
Photo credit Chong Fat, Wikimedia Commons en.wikipedia.org/wiki/File:HK_WSD_ShaTinWaterTreatmentWorks.JPG

Typical areas in which consulting engineers work are building services (HVAC,
water & waste plumbing, energy efficiency, thermal modelling), fire protection,
safety, system design of plant (industrial, water and waste treatment), building
layout (people usage and flow e.g. hospitals, airport terminals), transportation
(rail, road, harbour, airport), structural (e.g. building, bridges).

A big part of the work can be feasibility studies. These seek to answer the
question: which option gives the most value to the client? There is a
component of high-level design involved here, again at the systems level, but
also involving other considerations such as economic and environmental.
Maintenance life-cycle can be important here. Clients might go for cheaper
hardware, but this can result in longer term life-cycle issues. The consulting
engineer is interested in teasing out these effects, to give the Client sound
advice about the various options.

The consulting engineer is strongly focussed on the Client’s need. Having a

good relationship with the Client is an important part of successful projects.
40
Engineers present their work, which could be the results of an analysis or the
evaluation of several options, to the Client. Good presentation skills and a
client focussed approach are important. Consulting engineers are conscious of
the need to add value to the Client, through helping clarify the options and
support the client’s decision making on complex issues. [See the definition of
complex engineering problems in the chapter on PROFESSIONAL ATTRIBUTES.]
Most consulting engineers work on several projects at one, which makes it
interesting. They work at the interfaces with other professionals and
specialists, e.g. a pump system will need mechanical engineers for the
machinery and flow, electrical engineers for the power and controls, civil
engineers for the buildings, architects for building features, quantity surveyors
for costs, etc. The degree of involvement of the engineer varies as the projects
go through their different phases. Skills you learn as a consulting engineer are
design, analysis, and communication with other disciplines.
The projects are carried out by teams of people from different backgrounds,
with a professional engineer in charge as the team leader. Consulting roles give
the opportunity to develop personal PROFESSIONAL JUDGEMENT experience,
which is an important skill to learn in preparation for professional engineering
registration.

The consulting firms may be small, as little as a single person in private

practice, or large multinational organisations. From an ORGANISATIONL
perspective a defining attribute is that they are led and owned by engineers.
The engineers control the organisation – which is very different to most firms
that produce products where financial roles dominate the decision-making.
Also unusual is the consulting engineering firms use a partnership type of
structure, whereby people who work in the firm have ownership 9as opposed
to having external shareholders). These firms are owned and operated by
engineers to do engineering design & analysis, and therefore understand how
engineers work. They tend to have excellent professional development
programmes.

41
2 System development process
.1 V diagrams
The V-diagram is a conceptual model, represented graphically, of how the
product or system is developed.

The method originated in Germany in the defense and government project

areas. It is now widely used in many other areas, with software development
being an enthusiastic adopter. It provides a broad conceptual framework for
understanding the system development process.

In some countries, notably Germany and to a lesser extent the USA, the
process has been formalised into operating standards within project
management methodologies. In other situations the V diagram is seen more as
an idealisation of the process.

There are many different versions of the diagram. The following is an

interpretation for engineering design and system-development.

Simple V diagram

42
The V diagram represents the phases to the project: establishing the client’s
needs (requirements analysis), design to increasing levels of detail,
construction, hierarchical testing & assembly, commissioning and handover to
client.

A key concept of the V diagram is that test criteria are defined before the
design commences (not after, as is commonly the case).

Decomposition side (descending)

43
Test and integration side (ascending)

.2 Decision making from the systems engineering

perspective
Systems engineering is the application of engineering management, design
methods, analysis tools, and testing protocols in a systematic and integrated
manner, for the solution of complex engineering problems. Engineering
problems are complex to the extent that they involve interactions between
multiple dimensions (e.g. technical, environmental, safety, societal, financial,
etc.) and go beyond project management considerations of quality, cost, and
schedule). See the CA30 competency standard for more on complexity. The
systems engineering perspective emphasises a systematic approach to
establishing the system objectives (this is called Requirements analysis and
Specification), determining the functional requirements (Functional
Analysis/Allocation), creation of engineered products to meet those functional
needs, and review/testing throughout the process. A conceptual framework
for this is provided by the V diagram, which shows the progression whereby a
customer need is decomposed to detailed design activities, followed by
construction and a hierarchy of testing to ensure that the system meets the
client’s need.

44
Basic V diagram showing decomposition to detailed design, construction and a
hierarchy of testing to ensure that the system meets the client’s need. Review
occurs at key points throughout.

Review activities therefore occur at many stages in the life of the project, see
the decision points on the diagram.

Reviews on the descending leg correspond to design reviews, project decision

gates, and manufacturing/constructability reviews. These types of reviews are
directed at ensuring the outputs of design and decision-making rest on well-
founded assumptions, sound methodology, rational extraction of implications
for the life cycle of the system, thorough consideration of future risks &
consequences, and ethically robust decisions.

The IPENZ Code of Ethical Conduct is relevant here, as are the risk assessment
methods (ISO 31000), and the Health and Safety at Work Act (2015).

Reviews on the ascending leg correspond to verification and validation, among

other types. In this context verification refers to the process of confirming the
truth, i.e. that the system has indeed been designed to appropriate criteria and
constructed true to the design. In contrast validation is the later process of
assuring that the system does meet the needs of the client/stakeholders. This
may be associated with acceptance testing, commissioning, and hand-over of
45
the asset to the client. However there is variability in the use of these two
terms.

Reviews may also occur towards the end of the system development process,
especially if the system fails to perform as expected. Hence an expert witness
role is a type of post-hoc review in a conflict situation.

Review processes in engineering are often informed by an analysis of some

sorts, such as failure mode and effect analysis (FMEA), safety assessment, risk
assessment, assessment of environmental effects (also called environmental
impact assessment), among many others.

In the manufacturing practice fields the review processes typically occur as

activities internal to the organisation, in the form of review meetings.

In the consulting practice fields the verification processes broadly correspond

to peer review, and this involves an independent person examining the system.

Having an independent person involved is a valuable way to manage the large

technical, economic, safety, and contractual risks that often arise for
consulting projects. The peer review process is elaborated in the practice note.

46
Work-streams and decision-making

Iteration

47
Communication: internal and external

Timeline problems and solutions

48
Where analysis fits in

.3 Requirements analysis
A significant part of the commercial application of systems engineering is
determining the specification for the system. There are some commonalities
with the project management scope-setting process as evident in the PMBOK
[7], but SE has a wider field of view than merely the explicit activities and work-
packages necessary to get to the deliverables.

49
ENTRY TO MARS ATMOSPHERE: Entry involves the deployment of a number
of systems. The craft is too heavy to land solely with air-bags. Image Public domain,
http://en.wikipedia.org/wiki/File:20090428MSLEntry1.jpg

50
PARACHUTE BANDS: ‘The team developing the landing system for NASA's
Mars Science Laboratory tested the deployment of an early parachute design
in mid-October 2007 inside the world's largest wind tunnel, at NASA Ames
Research Center, Moffett Field, California. In this image, two engineers are
dwarfed by the parachute, which holds more air than a 280-square-meter
(3,000-square-foot) house and is designed to survive loads in excess of
36,000 kilograms (80,000 pounds). The parachute, built by Pioneer
Aerospace, South Windsor, Connecticut, has 80 suspension lines, measures
more than 50 meters (165 feet) in length, and opens to a diameter of nearly
17 meters (55 feet). It is the largest disk-gap-band parachute ever built and is
shown here inflated in the test section with only about 3.8 meters (12.5 feet)
of clearance to both the floor and ceiling. The wind tunnel, which is 24
meters (80 feet) tall and 37 meters (120 feet) wide and big enough to house
a Boeing 737, is part of the National Full-Scale Aerodynamics Complex,
operated by the U.S. Air Force, Arnold Engineering Development
Center.Entry involves the deployment of a number of systems. The craft is
too heavy to land solely with air-bags. Caption, Image (Public domain),
http://en.wikipedia.org/wiki/File:MSL_parachute.jpg

51
TOUGH CONDITIONS: Curiosity faces difficult conditions on Mars. Dust, soft-
sand, rocks, route-obstructions, and no real-time communication from Earth.
The requirements analysis is intended to determine these conditions
beforehand, and design the rover to suite. Image Public domain
http://www.nasa.gov/jpl/msl/pia18390/

52
As INCOSE, the professional society for SE explains:
‘Systems engineering is an interdisciplinary approach and means to enable the
realization of successful systems. It focuses on defining customer needs and
required capability early in the development cycle, documenting requirements,
then proceeding with design synthesis and system validation while considering
the complete problem: • Operations • Cost & Schedule • Performance • Risk &
Opportunity • Test • Training & Support • Manufacturing • Disposal.’
Source:
https://connect.incose.org/Shared%20Documents/INCOSEBrochure.pdf

The requirements analysis process seeks to take the client needs, in all the
dimensions in which the client seeks value, and identify the implications for
the engineering design & development process.

53
REQUIREMENTS ANALYSIS: Systems engineering identifies the customer’s
needs, and converts them into functional requirements. In turn these are
allocated to lower-level hardware and software sub-system elements. The
analysis also defines the interactions –physical and data communication-
between those sub-systems, this being essential for the solution as a whole
to have integrity. Image Public domain http://en.wikipedia.org/wiki/File:Systems_Engineering_Process.jpg

FINAL STAGES: A skycrane system is used for the final landing. This has to be
decommissioned and disposed of afterwards. Image (Public domain),
http://en.wikipedia.org/wiki/File:20090428MSLEntry2.jpg

54
NEARLY THERE: More sub-systems are required at the end too. Artists
impression. ‘Curiosity is touching down onto the surface, suspended on a
bridle beneath the spacecraft's descent stage as that stage controls the rate
of descent with four of its eight throttle-controllable rocket engines. The
rover is connected to the descent stage by three nylon tethers and by an
umbilical providing a power and communication connection. When
touchdown is detected, the bridle will be cut at the rover end, and the
descent stage flies off to stay clear of the landing site.’
Caption, Image (Public domain), http://commons.wikimedia.org/wiki/File:Curiosity_Touching_Down,_Artist%27s_Concept.jpg

55
IT’S BLEAK THERE: ‘This panorama is a mosaic of images taken by the Mast
Camera (Mastcam) on the NASA Mars rover Curiosity while the rover was
working at a site called "Rocknest" in October and November 2012. The
center of the scene, looking eastward from Rocknest, includes the Point Lake
area. After the component images for this scene were taken, Curiosity drove
83 feet (25.3 meters) on Nov. 18 from Rocknest to Point Lake.’ Caption, and Image
(Public domain), http://en.wikipedia.org/wiki/File:PIA16453-MarsCuriosityRover-RocknestPanorama-20121126.jpg

One of the other methods in common use, especially for product development
where it is a user or customer in mind (as opposed to a contracted client), is
Quality functional deployment (QFD).

MARTIAN GRAVEL: Wheel with Mars gravel. Dust and gravel and get
anywhere, and these problems have to be anticipated beforehand. Fault tree
analysis and failure mode effect analysis (FMEA) are typical tools for such
situations. The small and large holes in the wheel represent Morse code,
and spell out JPL. Image (Public domain),
http://en.wikipedia.org/wiki/NASA#mediaviewer/File:Martian_gravel_beneath_one_of_the_wheels_of_the_Curiosity_rover.jpg

56
.4 Quality function deployment (QFD)
In this example consider how a user (car driver) interacts with a car mirror. The
analysis is broken into discrete activities, strung together in the time
dimension. It is then a simple task of determining what additional functionality
the user might appreciate at each of these stages. These are shown in italics in
the figure. Taken together, these provide a set of functional requirements.

57
 Mirror to be easy
to adjust, smooth The reality is that
This activity is not operation people invariably
essential, but it is need to make some Mirror adjustment
Mirror adjustment
recommended for adjustments, to be predictable
to operate in hot
safety. especially on long and not distracting
or cold (frost), dry
journeys Mirror adjustment
or wet,
Adjusts seat must have no
noticeable
User adjusts backlash
controls before User settles in and Adjusts
starting (2) adjusts posture mirrors while
Adjusts
mirrors while driving(4) driving
before driving

Mirror
Mechanism for adjustment
adjusting mirror mechanism
(manual, level, to be easy to
electric) find and
operate Check for
Check mirrors
blind-spot
before moving
occupancy
Aesthetic
appearance
User (driver of mirror
of car)
User approaches User in
User drives off (3) Moving car
car (1) driver seat

Car
Mirror must not
Starting engine, shake or vibrate
Sees car, unarms
We are not locks, opens door, engaging gears,
concerned about gets into seat accelerator,
these details, as we handbrake, etc Mirror must not
are focussing on the fog or hold water
engagement with drops
the wing mirror

Sudden This is a high-risk

external area. Cognitive
Check mirrors events or loading is the
during internal problem, and
manoeuvre distractions contributes to
human error
Lane change, Mirror must give
turns, over- reliable coverage
Fold mirror under
taking, etc. of important
command or if
regions including
bumped
blind-zone

Manoeuvres
User performs Park and exit car User walks
completed
manoeuvres (5) (6) away from car
successfully
Mirror might
detect and warn of
objects in blind-
zone

Mirror might
detect and warn if
something is
coming and driver
has not looked at
mirror recently

Determine customer preferences regarding specific product

NPD-1-2-2
User experience flow analysis: Wing mirror case study

58
Example of how user needs may be determined by analysing the interactions of
the user with the product, in this case a car wing mirror.

Identifying the engineering attributes in a customer need is a special type of

transformation process, and there are particular mechanisms used to achieve
this, notably quality function deployment [8-10].

59

(2) Functional
requirements are
scored with an
importance.
Importance to user
(1) Functional
requirements that the
customer has of the
product, ex the
previous functional
analysis.
Aesthetic appearance of
mirror
Mirror adjustment mechanism
to be easy to find and operate
Mirror to be easy to adjust,
smooth operation
Mirror adjustment must have
no noticeable backlash
Mirror adjustment to be
predictable and not
distracting
Mirror adjustment to operate
in hot or cold (frost), dry or
wet,
Mirror must not shake or
vibrate
Mirror must not fog or hold
water drops
Mirror must give reliable
coverage of important regions
including blind-zone
Fold mirror under command
or if bumped
Mirror might detect and warn
of objects in blind-zone
Mirror might detect and warn
if something is coming and
driver has not looked at
mirror recently
Technology
importance
NPD-1-5-1
QFD applied to the car wing mirror case. User requirements are converted to
prioritised engineering features.
From the systems engineering perspective these activities are part of the
requirements analysis process, which seeks to take the client needs, in all the
(3) Engineering features or
attributes of the product. May
be physical sub-systems, as here,
or design requirements more
generally.
Structural rigidity of mirror
Mirror controls inside car
Shape of mirror including
Mirror drive mechanism
Shape details of shroud
Mirror mounting to car
Additional electronics
housed in mirror
Mirror shroud
Mirror pivot
near mirror
curvature
pod
3 5 1
5 5 (4) Matrix evaluation is the extent to
which the engineering feature is
important in providing the functional
needs. Requires appropriate
5 5
knowledge to anticipate.
3 4 4 4 4
3 4 4
5 5
5 5 5 5 5
5 3 4
5 5
3 2 5 4 2
(5) Weighted total identifies which
2 5
of the engineering features are the
more important, in this case the
mirror drive mechanism.
4 5
37 43 52 111 10 43 14 36 20
Identify engineering attributes:
Example application of Quality function deployment
60
dimensions in which the client seeks value, and identify the implications for
the engineering design & development process.

.5 Life-cycle analysis
‘Life cycle assessment (LCA) is a core concept in the development of
environmentally-conscious design and cleaner practices in industry and
involves the evaluation of environmental burdens associated with product,
process, service or practice’ [11]. It is a systems engineering approach that
involves evaluating everything that goes into and out of a product and its
production and usage system, throughout the life of the product. When
applied to environmental cases (ISO 14040), it is the environmental
consequences of the product system that are under consideration.

.6 Diagrammatic Representation
Systems engineering is about applying big-picture planning and insight to
complex systems. Visualising the interconnections in complex systems is a
difficult task, and requires special tools for representing the system. This is
usually done graphically, with specialised flowcharts that have specific
notation.

The typical graphical representation tools are:

 “Functional Flow Block Diagram (FFBD)
 VisSim
 Data Flow Diagram (DFD)
 N2 Chart
 IDEF0 Diagram
 Use case diagram
 Sequence diagram
 USL Function Maps and Type Maps.
 Enterprise Architecture frameworks, like TOGAF, MODAF, Zachman
Frameworks etc.”
http://en.wikipedia.org/wiki/Systems_engineering

It is valuable to develop ability to think and represent in this manner. In this

book I focus on Integration definition zero (IDEF0) flowcharts, because they are
the most general. Generally these diagrams are difficult for non-systems
engineers to interpret, because the notation is a special type of language that
needs to be known first.

61
IDEF0 notation
Integration definition zero (IDEF0) flowcharts are a way of representing the
interactions between systems. They are particularly powerful in being able to
differentiate the various types of inputs to an activity. By comparison most
flowchart notations merely mix up all the inputs. The method is also strongly
hierarchical, which matches the SE methodology well.

The IDEF0 modelling method uses a structured, deductive process to

decompose the process being analysed into multiple sub-activities (functions)
and for each deduce the initiating events, the controls that determine the
extent of the outputs, the inputs required, the process mechanisms that are
presumed to support the action, and the outputs. The end result is a graphical
model that describes the relationships between variables, thereby providing a
synthesis of what is known and surmised about the topic.

I sometime call it a subjective causality model. The model is expressed as a

hierarchical series of flowcharts using the integration definition zero (IDEF0)
notation [12, 13].

With IDEF0 the object types are inputs, controls, outputs, and mechanisms
(ICOM) and are distinguished by placement relative to the box, see Figure. An
activity may begin autonomously when its required inputs are available and its
constraints permit. (This is an important concept). Consequently, the notation
provides that multiple activity boxes can be simultaneously active, i.e.
concurrent or parallel. Sequenced activities (series) can still be readily
modelled where necessary.

62
 Legend

Initiators that Constraints Feedback,

start the that limit the controls on
Activity outputs the outputs

boon, unexpected
advantage

value (benefit),
intended or perceived

Inputs and Description of Activity

consumed (number:additional outputs
resources sheet)

ommissions (non-
outputs) latent or
patent

mechanisms
supporting the activity detriments
(side effects, unwanted
or unanticipated
outputs)

Figure: The IDEF0 object types are inputs, controls, outputs, and mechanisms
(ICOM), and are distinguished by placement relative to the box, with inputs
always entering on the left, controls above, outputs on the right, and
mechanisms below. The box itself describes a function (or activity), and the
arc (line arrow) describes an object. In most other flowchart notations
arrows represent sequence of activities. However, with the present notation
it is important to note that arrows should be interpreted as conveying
objects to activities (blocks) and not as sequence.

Examples of how IDEF0 has been applied, from some of my own research:
 We developed a model of the plant commissioning process, which is
otherwise a rather neglected area of research. Read our paper
Integrative Approach to the Plant Commissioning Process
http://dx.doi.org/10.1155/2013/572072 [14]

 The process of writing a thesis for postgraduate study [15]. This applies
also to academic writing, e.g. a journal paper.
 Kanban control systems for lean manufacturing [16].
 The project management process itself [17].

63
  Strategic risk management for manufacturing [18].
design document concurrent
(instructions for fabrication), engineering
(e.g. specified geometry, constraints from elsewhere,
materials, manufacturing (e.g. manufacturing,
process, tolerance) (see Nv- marketing), ergonomics,
2) styling Design
errors

candidate solution
and context of system project decision
(approval,
Determine remedial action)
manufacturability
manufacturing manufacturing
constraints (feedback
sequence process
to design)
(1: Prd-1-1)
Design the
Design of
production plant Plant
(2: Prd-1-2)

Research new Novel processes,

substantial
production
improvements on
processes existing
(6: Prd-6) processes Supply chain: networks of Design tools,
others (including (e.g. computer
partnerships) for aided design)
manufacture and delivery
Research and of the organisation's
development products/services

Analyse
technology risk New plant-design
with reduced
(equipment and risk of failure or
operators) harm
(9: MfR)

Control process- Occupational

production Risk management
health and safety
flow control methods
methods
(3: Prd-3) processes

Unintended plant
Construction behaviours: low productivity,
errors safety issues, staff usability
problems, product quality
defects
Test and
Build production commission system ready for
Built system
end user - e.g.
resources plant & system (plant, production production
(4) equipment) system capability
(5: Prd-1-5)
test
stimulii
economic viability,
Project test schedule, efficiency of
management, commissioning technology, hazards, Lifetime parts
construction approach legal requirements,
Project requirement
mechanisms maintenance needs
management also to storage
provides
Manage project
mechanisms to
(8: Pm) support many of
Decommission system
the other activities
recycled
on this page system for other
(7: Prd-7) use

Copyright Dirk Pons . File version: Prd-2. Sheet: 1Build. Printed: 27 June, 2012
Develop production capability (Prd-1)

64
IDEF0 model for the development of production capability. From [14]

These IDEF0 models readily lend themselves to the creation of sub-models,

hence they are hierarchical. This allows the bigger-picture (high-level) model to
show the main activities and their integration, with sub-models setting out the
details. Note that IDEF0 uses the boxes to represent ACTIONS or activities. This
makes it easy to convert into project plans and Gantt charts when more
specific work-instructions are required. This is another benefit to the method.

REPAIR IS NOT AN OPTION: During R&D the engineers can get up close to
the rovers. But once on Mars the opportunity for human hardware
intervention is nil. Consequently these systems have to be designed for
maximum reliability and fault tolerance, and tested thoroughly beforehand.

‘Two spacecraft engineers stand with a group of vehicles providing a comparison of three generations of Mars rovers developed at
NASA's Jet Propulsion Laboratory, Pasadena, Calif. The setting is JPL's Mars Yard testing area. Front and center is the flight spare for
the first Mars rover, Sojourner, which landed on Mars in 1997 as part of the Mars Pathfinder Project. On the left is a Mars Exploration
Rover Project test rover that is a working sibling to Spirit and Opportunity, which landed on Mars in 2004. On the right is a Mars
Science Laboratory test rover the size of that project's Mars rover, Curiosity, which landed on Mars in 2012. Sojourner and its flight
spare, named Marie Curie, are 2 feet (65 centimeters) long. The Mars Exploration Rover Project's rover, including the "Surface System
Test Bed" rover in this photo, are 5.2 feet (1.6 meters) long. The Mars Science Laboratory Project's Curiosity rover and "Vehicle System
Test Bed" rover, on the right, are 10 feet (3 meters) long. The engineers are JPL's Matt Robinson, left, and Wesley Kuykendall. The
California Institute of Technology, in Pasadena, operates JPL for NASA.’
Caption, Image (Public domain), http://en.wikipedia.org/wiki/File:PIA15279_3rovers-stand_D2011_1215_D521.jpg

65
GROUND SYSTEMS ARE NEEDED: The system for a mars probe also
comprises the ground sub-systems including the communication hardware.
‘Three 34m (110 ft.) diameter Beam Waveguide antennas located at the
Goldstone Deep Space Communications Complex, situated in the Mojave
Desert in California. This is one of three complexes which comprise NASA's
Deep Space Network (DSN). The DSN provides radio communications for all of
NASA's interplanetary spacecraft and is also utilized for radio astronomy and
radar observations of the solar system and the universe.’
Caption, Image (Public domain),
http://en.wikipedia.org/wiki/Goldstone_Deep_Space_Communications_Complex#mediaviewer/File:Goldstone_Deep_Space_Communic
ation_Complex_-_GPN-2000-000506.jpg

66
3 Project initiation
PROJECT INITIATION
In a commercial setting there is no project unless there is a paying client. While
some of the project planning will need to occur before the contract is signed,
the bulk of the project effort only starts once there is a negotiated acceptance
of the project on both sides. The negotiation of the project occurs early in the
project life. There is a temptation to perceive that negotiating a project is
simply a matter of writing up a contract. While a contract is indeed the final
outcome in many cases, it only the last and most tangible of a series of prior
activities.

The acceptance activity produces a contract in which will be included various

responsibilities, obligations, and provisions for failure events. The failure
events may comprise a large portion of the contract since they will specify the
remedies in the case of technical, temporal and financial failures. Since
projects are characterised by uniqueness, and sometimes even novelty, there
is a higher risk of failure than in general management.

.1 Internal projects
Variant 1 is the internal project. It involves setting up the project with the
internal Owner (1) and this also involves finding a common (internal)
understanding of the purpose (3). This type of project does not usually require
formal contracting.

WORK STREAMS
The locus of effort is shown in the diagram.

67
 project
opportunity opportunities
(asset, (threats) presented:
product, e.g. new product
process) features

project scope
Set up project
with internal
project plan
Owner
(1: Pm-2-1) project
contract

resources to
project

project supporter
(sponsor,
champion)

Subjective and strategic

understanding of purpose. The
Find a common overall big-picture purpose. The
understanding of customer’s need and the client’s
the client’s need (if different people). What
purpose (3: Nv- will this venture (project, work)
achieve? What is the outcome
2-2) that will constitute acceptance/
satisfaction?

Confirming
Production of Frequent early recent
early drafts communication with agreements
client

Negotiate acceptance of project (Pm-2) : Variant 1 - Internal p

INTERNAL OWNER
The case of an internal project is elaborated in Figure Pm-2-1. The internal
process starts off with the internal client identifying the project opportunity
(1). This may arise because of strategic challenges: business sustainability,
operational processes, staff capability (2).

Once the desired project objectives are known (asset, product, process), the
next activity is to define the project outcomes (3). This may involve some
preliminary project planning (4). The process involves the executives in the
organisation that is executing the project and carrying the risk, which is
assumed to be internal in this case, but perhaps another business unit. The
outcome is a project scope and proposed. A reconciliation loop runs back to
activity (1) to reconcile expectations between executives and the project
manager.

68
 realistic
ethical
expectations
responsibilities in
offering or seeking
work project scope

Define the project

budget,
project outcomes contract if
(3) necessary

Management
knowledge of oversight
Plan the project
organisational
(4: Pm-1) capability
involvement of
executives in the
organisation that
project plan
is executing the
opportunities project and
(threats) presented: carrying the risk
e.g new product
features

strategic challenges
Identify strategic (business
risks to the sustainability,
organisation operational
processes, staff
(2: Om-3-1-3)
capability)

opportunity
presents to
owner

desired intended
Client identifies project benefit from
project objectives projet
opportunity (asset,
product,
(1) project supporter
process)
(sponsor,
champion)
Owner frees
resources to
resources project
(5)

project decision
(approval,
Make decision decline, remedial explicit purpose for
(6: DTS-5) action, new organisation that
concept) adds value from
owner perspective
(see Om-1-1)
authorisation to
proceed

project plan

Execute the output: completed

project system (functional,
(7: Pm-3) on-time, on-budget)

Copyright Dirk Pons . File version: VisioDocument. Sheet: 21. Printed: 30 June, 2009

Set up project with Internal Owner

(Pm-2-1)

69
With this preliminary scoping complete, the next activity is to make a decision
(6). Of course it sometimes happens that executives are so keen on a project
that they start with (6) and then work out the details. The decision then frees
up resources (5) for the project. Importantly, it also provides a project
supporter (sponsor, champion) who supports the project at the executive level.
In the present context 'executive' refers to the level at which decisions are
made; this may or may not correspond to the top management team.

The acceptance of the project inevitably involves decision-making, and

therefore executive and governance functions. This is because all projects carry
an element of risk, and cost, and decisions as to the willingness of the
organisation to carry those are made at higher levels.

The senior decision-making processes have received some attention in the

literature, though no clear picture emerges. Turner approach the problem by
defining the people involved, and came up with roles of owner, sponsor,
broker, steward, and of course the project manager [51]. Distinguishing
between these different people requires careful semantics, and even then it is
possible to conceive of cases where the roles are confounded [52].

A project charter may be used for projects internal to an organisation. It

comprises the objectives, resources, and delegated authority.

.2 External tendering
Variant 2 is the external tendering process (2) where the Client awards the
contract to the successful bidder, after which the contract details are
negotiated (6).This variant may involve some of the other generic activities to
greater or lesser extent, see below.

70
 Client has an
objective

Engage with Client awards

Tendering contract to
process successful
bidder
(2: Pm-2-2)

ethical
responsibilities in
offering or seeking
approval

Negotiate
project
outcomes intent
(5: Pm-2-5)

Optimisation –
win x lose

Transactional -
trading sacrifices

split scope

Building
consensus from
the big picture
then into the
details (purpose
… deliverables)

Need
stratification and
satisficing

contract

project plan, Gantt

chart, baseline costs, Negotiate Description of
workloads contract details responsibilities,
(responsibilities), (6) deliverables, obligations
time schedule
consequences of failure
events and
non-performance on
either side

promised financial
outcomes (payment,
including timing thereof)

Negotiate acceptance of project (Pm-2) : Variant 2 – External tendering

Copyright Dirk Pons . File version: VisioDocument. Sheet: P2Neg. Printed: 29 January, 2010

A tendering process is typically used when spending public money on civil

engineering works, military, and aerospace. However the process may be used
in other situations too. The main activities are that the Client has a need (1),
which arises either because they have money of their own to spend on a
certain objective, or they have a contract from someone else and need help to
complete it (sub-contracting). With a contract type project, the client may ask
71
for a Request for information (RFI), which seeks to get information from the
market about the technologies and capabilities that may be available. Once the
client has defined the project, they call for bids. The outcome here is called a
Request for proposal (RFP) and goes from the client to the market.

Guidance on writing such documents is available [53].

The process is sketched out in Figure Pm-2-2.
Client has money of
their own to spend on
a certain objective

Client has a contract

from someone else
and needs help to
complete it

Request for
Client’s proposal
Client has a Client issues call
definition of (from the
need (1) project for bids (2) client to the
market)

Request for
information (from
the client to the
market)

Ethics standards
of the profession

Submit to Expected
Behaviour of
profession’s standards of
professional
ethics professional
member
behaviour
(5: Tw-5-2-6)
contract may
include
penalty
clauses to
minimise
client’s risk

Project manager Client awards

Bid: technical
Client evaluates contract to
puts together a scope and
successful
cost tenders (4)
bid (3) bidder

Copyright Dirk Pons . File version: VisioDocument. Sheet: 22. Printed: 20 August, 2009

Engage with Tendering process

(Pm-2-2)

Within one of those firms operating in the market, the project manager puts
together a bid (3) that might typically include the technical scope and cost.
There is usually a deadline on these bids. The Client then evaluates all the
received tenders (4) and decides who to award it to. The next activity is to
negotiate the contract details (Pm-2-6). The Client's decision could be the
72
lowest price bid received, but it might not be if there is some doubt about the
ability of the contractor to understand the scope of the work or deliver quality
work. The Client may also involve the successful bidder in further negotiations
about details of the contract or the approach taken. Several selection
processes are available on the client’s side: Selection by Referral, Brooks’ Law,
Two Envelope System, Cost Weighted Method, Budget Method (Target Price),
and Price Competition [54].

.3 Product design
Variant 3 is the case of new product development. Here the main activities for
a Design Manager are to clarify the Customer needs, determine the Client’s
purpose, and negotiate the outcomes that will define a successful product.

73
 Subjective and strategic
understanding of purpose. The
Find a common overall big-picture purpose. The ethical
understanding of customer’s need and the client’s responsibilities in
the client’s need (if different people). What offering or seeking
purpose (3: Nv- will this venture (project, work) approval
achieve? What is the outcome
2-2) that will constitute acceptance/
satisfaction?
Negotiate
project
Confirming outcomes intent
Production of Frequent early (5: Pm-2-5)
recent
early drafts communication with agreements project
client charter

customer's need for

product/service

Initiators: commercial,
market pressure,
identified need, strategic
Building
need, opportunities from
consensus from
the External environment
the big picture
then into the
customer
details (purpose
feedback
Users (operators) need … deliverables)
for production process

technical
Clarify customer objectives and
needs importances,
(4: Nv-1) product and
service features

contract

project plan, Gantt

chart, baseline costs, Negotiate Description of
workloads contract details responsibilities,
(responsibilities), (6) deliverables, obligations
time schedule

Negotiate acceptance of project (Pm-2) : Variant 3 – General product design

Copyright Dirk Pons . File version: VisioDocument. Sheet: P2Neg. Printed: 29 January, 2010

74
 Hydra contracts with Yellow Hut
You have been given the job of developing a design of outdoor chair
specifically for Yellow Hut, a large retail chain. It looks straight-forward
enough, though it’s only the beginning stages and there is no contract yet.
But there are a couple of questions milling around in your mind, and they
come to the fore at morning tea-break.
‘This situation with unique products is a bit strange’, you remarked to Derek
over coffee.
‘Sure is! But you can see the method in the madness.’
‘Hmm… I’m not sure that I can!’, you reply.
‘Well it’s all about marketing’, replied Derek. ‘The good folk at Yellow want
to be able to say that they have a unique product. That way they have
something that is rare, inimitable, and hopefully valuable to the customer.’
‘OK, I’m sure we can achieve that for them.’
‘By the way’, continued Derek, ‘what approach are using to develop a good
relationship with Yellow, and what do you suggest as our negotiation
approach?’
He laughed. ‘Sorry, that’s two questions!’
‘No problem! I’ll consider them A and B and answer them separately’, you
replied. ‘Though I guess they are inter-related’.

A: What makes a good relationship between Engineer and Client?

B: What negotiating strategies could be useful for getting a contract

between Hydra and Yellow Hut?

.4 External client
Variant 4 is the general process where a Project Manager interacts with a
nominally external client. The process involves clarifying the customer needs
(4). Note that the customer or user is not necessarily the same as the client
who is paying for the work to be done. The project manager will therefore in
general have to also find a common understanding of the client's purpose in
the project (3). In particular, 'What will this venture (project, work) achieve?'
And of special importance is the satisfaction criterion: 'What is the outcome
that will constitute acceptance/satisfaction from the client perspective?' This
activity depends on good communication.
75
Once the project objectives are understood, the next activity is to negotiate
the outcomes (5). This activity is about reconciling different expectations and
hopes for the project. Once the project intent is clear, then the final activity is
to negotiate the contract details (6), and this is where the final, usually written,
contract appears. This contract is the most tangible part of the process, and
perhaps the most intimidating because of its sense of legal threat. However, as
the diagram shows, the contract itself is only one small part of the process, and
is not even needed in certain cases.

The IPENZ practice note [55] is particularly relevant to Engineers who are
practising project management, and to those who are interacting with clients
generally. It discusses the relationship between Engineer and Client, and why
this relationship is valuable.
 IPENZ (2005). Practice Note 06: Developing and Maintaining Client
Relationships (No. ISSN 1176-0907). Wellington: IPENZ.

The guidelines [54] provide useful further background information to the

process.
 IPENZ (2004). Guidelines on the briefing and engagement for engineering
consultancy services (No. ISBN 0-9583605-6-1). Wellington: IPENZ.

76
 project
opportunity opportunities
(asset, (threats) presented:
product, e.g. new product Client has an
process) features objective

project scope
Set up project Engage with Client awards
with internal Tendering contract to
project plan
Owner process successful
bidder
(1: Pm-2-1) project (2: Pm-2-2)
contract

resources to
project

project supporter
(sponsor,
champion)

Subjective and strategic

understanding of purpose. The
Find a common overall big-picture purpose. The ethical
understanding of customer’s need and the client’s responsibilities in
the client’s need (if different people). What offering or seeking
purpose (3: Nv- will this venture (project, work) approval
achieve? What is the outcome
2-2) that will constitute acceptance/
satisfaction?
Negotiate
project
Confirming outcomes intent
Production of Frequent early (5: Pm-2-5)
recent
early drafts communication with agreements project
client charter

Optimisation –
win x lose
customer's need for
product/service
Transactional -
trading sacrifices
personal objectives -
Initiators: commercial,
needs - are constraints split scope
market pressure,
on (future) well-being that
identified need, strategic
the self desires to satisfy, Building
need, opportunities from
and each has an consensus from
the External environment
importance attached (see the big picture
Mo-3) then into the
customer
details (purpose
feedback
Users (operators) need … deliverables)
for production process
Need
technical
Clarify customer stratification and
objectives and
satisficing
needs importances,
(4: Nv-1) product and
service features

contract

project plan, Gantt

chart, baseline costs, Negotiate Description of
workloads contract details responsibilities,
(responsibilities), (6) deliverables, obligations
time schedule
consequences of failure
events and
non-performance on
either side

promised financial
outcomes (payment,
including timing thereof)

Copyright Dirk Pons . File version: VisioDocument. Sheet: P2Neg. Printed: 29 January, 2010
Negotiate acceptance of project (Pm-2)

If you are a Civil Engineer practising in New Zealand, then you need to
understand the concept of Producer statements PS1 to PS4. See
http://www.ipenz.org.nz/ipenz/practicesupport/endorsedinfo/.

77
Public-private partnerships and alliancing projects
Public-private partnerships (PPP) are a type of project where government and
private companies partner together to develop infrastructure (roads, rail,
ports, hospitals, prisons, schools, etc). Usually the government provides only
some of the capital or underwrites the loan, but carries most of the risk. The
private company builds the asset and then is either paid by the government to
operate it, or charges levies to users. PPPs are popular with governments
because they reduce the immediate capital cost (thus making the government
look good) but unpopular with the public as they result in high costs deep into
the future (the public have to pay for these costs after income tax has already
been deducted). Also, service quality from the firms is often poor, e.g. prisons
become violent, electricity networks are not maintained. Related business
structures are alliancing and build-own-operate-and-transfer (BOOT)
arrangements.

Alliancing uses an Alliance board for decision-making, and sharing of risks and
gains [56]. The latter may result in build-own-operate-and-transfer (BOOT)
arrangements. For an example of the latter, applied to a recycling facility in
Auckland (NZ), see [57].

Ethics
The engineering profession has ethical expectations specifically in this area of
tendering. For example, the Institute of Professional Engineer in New Zealand
(IPENZ) explicitly states that one of the minimum standards of acceptable
ethical behaviour is to ‘Not promise, give, or accept inducements’ (#7/10) [58].
Failure to comply is a cause for disciplinary action.

The issue of ethics is poorly represented in project management and would

likely benefit from further research. Existing approaches tend to have simplistic
constructs of ‘ethics’, identifying only part of the problem, such as inflating
cost estimates [38] (p299).

.5 Negotiations strategies
Negotiation refers to the process of converging to mutually agreeable
expectations. The emphasis is on the intent of the parties, not the exact
wording of the contract (which is left to activity 6). There are several different
mechanisms for negotiation, as shown in Figure Pm-2-5.

78
Optimisation – win x lose
Assuming two parties to the negotiation, and each can either win or lose, then
there are 2! outcomes, i.e. 4 combinations of win and lose. The optimisation
strategy seeks to create a win, at least for whichever party is stronger.

Strength in this context refers to power: the ability to make others behave in a
certain way or impose limitation on their choices. In the commercial project
area this situation may arise because one party has greater purchasing power,
cash-flow, reputation, market choice, or some other competitive advantage.
The more powerful party can then seek to optimise the negotiation to get the
outcomes that benefit them the most. This is the win-lose strategy. It is
perhaps the dominant approach in the competitive environment, and effective
at getting success, at least for one party.

However it has detriments: the exercise of power is perceived as political

behaviour, and the subjects will therefore seek to evade it in future and will
decrease their trust in the dominant party. When the tables are turned the
weaker party will exert its power in its own win-lose strategy.

There is also the possibility for win-win outcomes. Undoubtedly there are
situations where a certain project outcome can maximise value for both
parties.

Transactional - trading sacrifices

The transactional approach works by sharing the losses. Each party takes some
sacrifices, and these are arranged to be about the same. It is an equity-based
approach. It works where the parties are about equally matched in power,
aware that a perfect optimisation is not possible, but still need to work
together. There is a dependency between the parties.

Split scope
Split scope is a negotiation tactic of first seeking to come to agreement on the
technical aspects of the project. Only once that is done does the discussion
turn to the financial details. The costs are then portrayed as natural
consequences of the technical scope. In practice this may be implemented
with the ‘Two Envelope System’.

79
Therefore, if the client does not like the cost, then the solution is to go back
and delete some of the deliverables.

Finalise
technical
scope Commercial
scope

Proposed Technical Contract and

project scope project plan

Split scope involves first discussing the technical details, and only then the
commercial.

Building consensus from the big picture then into the details
(purpose … deliverables)
This is a partnering approach, where the two parties trust each other and are
genuinely willing to work to the best interests of the project as a whole. The
overall purpose of the project is identified, as are its benefits. Leadership is
applied to motivate the parties to all want to achieve these outcomes. Then
the locus of effort goes into working out the details of the deliverables and the
contribution of each party. It is a collaborative problem-solving approach.
Collaboration is a different mechanism to competition, and the incentives are
different. Thus this approach is unlikely to work in a competitive area.
Need stratification and satisficing
These are my terms. This strategy is based on finding different needs to satisfy
for the different parties. For example, the client may be able to get the low-
cost solution he wants. This becomes possible because his firm does all the
welding on the project, which is an easy thing for his firm. The strategy is based
on realising that different parties have different needs, where each need has
an importance assigned to it. So not only are the needs different across
parties, but their importances are too (think of a hierarchy of needs if you will).
Hence the needs are 'stratified'. If the client's and project manager's needs can
be determined (see Clarify customer needs (4) in Figure Pm-2), then it may be
possible to find a solution that adequately satisfies both parties needs, hence
'satisficing' [59]. Note that different needs are satisfied even though there is
only one project. Note also that no-one's needs are perfectly optimised, and
neither is there transactional sacrificing, but instead the objective is that
everyone gets out of the project something that is valuable to them. I am not

80
suggesting that every project is necessarily amenable to this approach, but I do
suggest that it is worth attempting as the first mechanism.

Those are various conjectured negotiation strategies. None is perfect, and all
have detriments and risks alongside their benefits. The approach selected will
depend on the situation, and may change if the selected strategy is ineffective.

81
4 Project management
PROJECT MANAGEMENT
Project management is a method for coordinating multiple work streams,
usually but not necessarily by different people, to achieve a specific outcome
in a finite time period.

A project is any large designed system that for its creation requires multiple
tasks to be completed. Alternatively, a project is set of activities in time, which
produce specific goals.

Projects always have an end. This means that general management, which
continues indefinitely, is not a project.

Usually multiple people will contribute to a project by doing selected specialist

tasks. They may not know or care about the overall project objective, but they
are still important in providing their skills. The project manager is the person
who coordinates all the people and makes sure that the project is completed.

.1 What is a project?
Project management is a method for planning and deploying projects. It is
widely used in mechanical engineering (e.g. development of new motor cars
and new products generally), civil engineering construction and asset
management, business projects and new ventures, social event management,
computer service upgrades, etc.
Why are projects important?
Much of the work done by companies is in the form of projects. Developing a
new cell-phone, or landscaping a commercial building, or resurfacing a road, or
launching a deep-space probe; these are all projects in the technology area.
They are all characterized by having a start and end date, which is to say they
are of finite duration.

Project management is a method that is used to set up these projects

beforehand, and manage them as they unfold. The method arose initially in
the aerospace industries, and was soon accepted in the civil engineering and
construction industries. Later project management became appreciated and

82
used in non-technology areas such as event-management, and within general
management.
Project definition
A project is an endeavour (work) that (a) seeks a particular outcome
(deliverable), (b) is of finite duration (time), and (c) involves some
customization of activities (either the outcome is innovative, or the process is
unusual, or the work is unfamiliar to the particular people involved). In
addition, most (but not all projects) involve: (d) a team of people, and (e)
constraints on cost (i.e. a budget).
My definition: A project is a venture of co-ordinated effort to capture an
opportunity within constrained resources (particularly time and cost).

.2 Project triangle
The concept of FUNCTION – TIME – COST, and the need to optimize all three
variables, is important in project management. This is called the project
management triangle.
Customers will usually want the maximum amount of FUNCTION in an
impossibly short TIME and at a ridiculously low COST. Why wouldn’t they want
to use their money to their best advantage? Part of the negotiation function of
senior project managers or sponsors is to get a balance that works for the firm
doing the project, as well as adding value for the customer.

83
PROJECT TRIANGLE: The key to negotiating with a CLIENT is to work on the
DIFFERENT WORTH that you and the client place on attributes of the
prospective SOLUTION. Find things that are valuable to the client but less so to
you (and the converse).

 If the customer wants the outcomes in shorter TIME then this will
increase COST, or alternatively result in less FUNCTION being provided
by the product. You can often offer to develop the additional features
LATER for a new contract.
 If the customer wants lower COST then time or quality tends to be
sacrificed. Usually best to offer decreased FUNCTION rather than quality
per se. These clients often have CASHFLOW constraints – so additional
features may wait until the product is earning.
 If the customer wants increased FUNCTION, e.g. additional features in
the software, then this will take more TIME and increase the COST.
Generally such clients will be willing to pay. Try to arrange your business
workflow such that it is easy and does not cost you a lot to offer (high-
priced) additional features.

.3 Two main stages: ‘planning’ and ‘control’

The two main stages of a project are ‘planning’ and ‘control’. The planning
involves estimating the likely cost, and determining the workload, project end
date, etc. The control stage arises once the project is running, and involves
checking that the tasks are done on time, monitoring costs, and checking
quality of work.

A software tool is invariably used.

Measure
Form project Perform the Handover Customer
PURPOSE progress
of project
team project work deliverables achieves the
(monitor) benefit
(1: Pm-3-1-1) (2: Pm-3-2) (1: Pm-4-1)
(3: Pm-3-3)

The two stages of ‘planning’ and ‘control’ can be further broken down. There is
no universal accepted list of stages, because they depend on the type of
project and the scope. However a general set of five stages is offered by the
PMBOK: initiating, planning, executing, monitoring & control, closing [7](p42).

Project planning is the most important engineering management skill after

communication (survey of NZ professional engineers).
84
Project planning is an important part of project management, being the front
end of the deployment process, as well as an activity that may re-arise during
execution itself.

future business
constraints: opportunities
constraints: unforseen
unforseen internal
external events (site
events (planning
conditions, weather, labour
unavailability, etc.)
mistakes, errors, slip) Obtain project
satisfied
benefits customer
Contract: initiator of (4: Pm-4)
project (see Pm-2)
financial profit for
project
organisation

sense of
personal
achievement for
project builders
input: resources output: completed
Execute project
(labour, materials, system (functional,
plant) (3: Pm-3) on-time, on-budget) skills (technical,
management) for
future work

Software tools

customer
requirements
and
expectations
(see Pm-2)

constraints: risk: pressure on

milestones, date planning to fulfil
constraints strategic objectives

input:
output: project plan,
customer
Gantt chart, baseline
technical Plan project
costs, workloads
requirements (1: Pm-1) (responsibilities),
and
time schedule
expectations

mechanism to
achieve this: Work
breakdown structure,
Gantt chart, etc.

.4 Simple project plans

Anticipate the sub-tasks that will be necessary to get the outcomes.
Copyright Dirk Pons . File version: VisioDocument. Sheet: P. Printed: 20 May, 2009

Project planning involves anticipating the sub-tasks that will be necessary to

Manage project (Pm)
get the outcomes. Relative timing of tasks is usually an essential part of a
project, as some things will always depend on the completion of earlier tasks.

85
A simple project plan can be created by listing the activities that need to be
done, and showing when they need to be done. The relative timing of tasks is
usually an essential part of a project, as some things will always depend on the
completion of earlier tasks.
Paper based
A simple project plan can be done on a piece of paper. Or you could use a word
processor or diagramming software to draw a neater plan. The essentials are:
∙ Describe the task
∙ Show when it starts
∙ Show how long it is planned to take (or the finish date)

The figure below shows how this would look for a simple project. This has been
done with a table. This is only an illustration and generally, we would not
attempt to manage a project to this level of detail.

Task 6:00 6.3 7:00 7:30 8:00 8:30 9:00 9:30

Wake up ◆
Shower
Get dressed
Make coffee
Eat cereal
Brush teeth
Collect books
Bike to class
Class starts ◆
Simple project plan

Simple Gantt charts may be created with software like MS Visio®. However
these charts are limited in their ability to show complex task interactions.

86
 Sep 2008
ID Task Name Start Finish Duration
8 9 10 11 12 13 14 15 16 17 18 19 20 21

1 Dig post holes 8/09/2008 8/09/2008 1d

2 Pour and cure concrete 9/09/2008 11/09/2008 2d 4h

3 Erect roof 11/09/2008 12/09/2008 1d

4 Build walls 12/09/2008 15/09/2008 1d

5 Lay gravel driveway 11/09/2008 12/09/2008 1d

6 Shed complete 15/09/2008 15/09/2008 0d

MS Visio can be used to create simple project plans.

Timelines
When all the activities are in a series sequence, which is approximately the
case with some possible exceptions (e.g. Get dressed and Make coffee), then a
simple time-line can be effective.

2006
1998 2005
2003 2004 Premises established Type certificate obtained
Initial sighting of
Investors create firm Plans Purchased at Hamilton 2007 Future growth
plane and early planning
prospects

1998 - 2003 2003 - 2005 2005 - 2007 2007 - 2012

Early planning Create firm Produce plane Future developments
1999 2000 2001 2002 2003 2004 2005 2006 2007 2008 2009 2010 2011 2012
1998 2012

Milestones for the development of a new aircraft, and the establishment of the
firm. Based on a case study.

Software
When the project gets to be large, then there is too much for a single person to
do, and it becomes necessary to share the tasks among multiple people. These
people each do different things. Coordinating all these tasks that are running
in parallel then becomes more complex, and simple timelines become
insufficient. At this point project management tools such as the Gantt chart
become useful, because they can show who is doing what and when.

87
The best way to implement real-life project management is to use software
that is dedicated to the task. There are several software packages that are
available.

This paper has standardised on MS Project ®.

Software is a great help because it automates some of the tasks. Project

managers can easily show which other tasks need to be done first, by using the
connectors (links). The software also provides other features, like keeping track
of people, progress and costs.

The most common representation is the Gantt chart. This has a list of tasks
called the ‘work breakdown structure’, and a time axis. The duration of each
task is indicated by the length of its bar. The relationship of ‘precedence’
between tasks is indicated by ‘link’ lines. An alternative representation is the
‘network diagram’.

An example from MS Project is shown.

Project management software – in this case MS Project – can be used for more
complex projects, including costs and resources.

88
Examples
CHAIR PROJECT
The figure below shows a typical project plan. The main items are a list of tasks
(activities) and a calendar.

Structure: Note that the list of tasks (activities) is indented under the project
title (‘Chair project’).
Gantt: This is called a Gantt chart. Point out the spelling of the name. As
opposed to the network diagram. See
http://en.wikipedia.org/wiki/Gantt_chart
Resources: Names of people are given. This is optional, but most projects
have to consider resources. People and equipment are all
resources.
Schedule: Links show the order in which the tasks are created.
Application: Refer to companion paper which shows how to create this same
example, step-by-step.
Simple: In reality the tasks (Design chair, Test chair, Manufacture chair)
would all be further elaborated.
CARPORT PROJECT
In practice most project plans have a greater level of (a) detail and (b) structure
than the simple previous example. A more realistic example would be the
following figure for a carport construction project.

89
Top task: List the project title at the top. This will permit costs to be
summed to this level.
Structure: The main tasks are design carport, get consent, and build carport.
Each of these is further subdivided.
Milestones: Zero duration activities. Good for showing decision events or
dates.
Schedule: Some other links in here: start to start.
###: Simply means the column width too small.
Cost: Show them the following, and point out that it’s simply a different
view of the same project. Explain that it includes cost of materials
and labour (but the precise mechanisms will have to wait for a
future paper).

SELL AND BUY HOUSE PROJECT

This is a project that many people can relate to because they have either done
it, or are hoping to do it someday. The list of tasks is quite simple, having only
one level of indent. However there are a number of tasks in parallel.

90
Top task: As always, it’s a good idea to list the project title at the top.
Parallel: Note the parallel tasks, i.e. tasks happening at the same time.
Things are parallel when a vertical line down from the calendar
cuts through multiple tasks. Explain that the term concurrent is
sometimes used, especially in engineering design.
Schedule: Parallel tasks can be created by linking from a common
predecessor.
Milestone: Show why a milestone at the end is a good idea: permits the
entire project to be rescheduled. But readers are unlikely to see
that benefit until they actually use the software.
GREEN RAT TRAP PROJECT
This one is totally fictitious. But the Green rat trap project is useful in showing
a more complex use of the Gantt chart.

91
Top task: As always, list the project title at the top.
Costs: Total cost is summed to top line.
Income: However this little project illustrates something different: the
ability to incorporate income. So this project makes a profit –
unfortunately MS Project handles profit as negative. At this point
it’s sufficient to know that MS Project assumes money is invariably
spent, but it can handle income if necessary.
RESURFACE MADRAS ST PROJECT
This one is hypothetical, but my previous civil engineering students helped me
write it as a class exercise one day, so it’s representative even if a bit simple.
Main thing here is the % complete.

% complete: The dark bars show how much is complete. When 100% then the
tick.
Split: Try and ignore that split and the reasons for it (the subsequent
piece was rescheduled after the first bit had been done on time).
Sufficient for now is the knowledge that tasks can be split if
needed.
92
Control: The idea that there is a planning stage beforehand, followed by a
deployment stage. Point out that project management principles
permit people to not only plan the project, but also to monitor
and control it once it is running. The Flower bud analogy: the bud
forms at end of winter, and in spring it receives the sap and starts
to unfold.
TEST
Check how well you can interpret a simple Gantt chart.
1. Why does ‘product design’ have a long black bar?
2. How much time is allocated to ‘design production process’?
3. Who will ‘make models’?
4. What exact date does the project start?
5. What other task must be complete before David can ‘design production
process’?
6. What tasks must be complete before the team finalises the concept?
7. Is the production of marketing brochures part of this project?
8. The company board of directors have approved the spending of a lot of
money for this project, and they are interested in being informed about
the progress at key points. Identify three places where this could
happen.
9. How confident are the team about getting the design right the first
time? On what did you base this assessment?

.5 MS Project tutorial
USER INTERFACE
The main functions are shown below. The interface has not changed much
since 1995.

93
With MS Project software, it is important to indent the subsidiary tasks using
the specialized button, not use the indent on the keyboard. Also, create links
between tasks, rather than drag them across the screen.

Link and unlink tasks: This creates the arrows or

links between tasks.

Add notes, set properties: Don’t usually have to use this,

except for advanced features.
Assign people: Also assigns other inanimate
resources.

Indent and outdent tasks: Please make sure that the

green indent and outdent
buttons are visible on the
third row. If necessary, drag
that toolbar into this place.

Show critical path: The time-critical tasks can be

identified in red.

94
CREATE A PROJECT IN MS PROJECT
In this tutorial you will create a simple project plan that uses several of the
features of the software. The output will be a Gantt chart.

1 Start a new project. See (1) in Figure above.

2 Enter the following tasks in column 'task name' (2).

Click with left mouse button in the top rim. Type the text
below. Press <Enter> between each task.
Design chair
Test chair
Manufacture chair

3 Insert a project heading. First Insert a new line: click in

first row and press <Insert> on keyboard. Should now have a
blank line at the top.

Enter text 'CHAIR PROJECT’

4 Make this the heading, by indenting all the tasks

underneath it. Select all the underneath tasks (numbers 2 to
4): Click and hold down the left Mouse button on 'Design
chair', drag downwards to 'Manufacture chair'. All tasks 2-4
should now be highlighted (see Figure 7).

95
Now indent these tasks: press the indent screen button (3).
The indent will make them subtasks of the task above. This
will also automatically make the above task ‘Chair project’
task into a summary. DO NOT USE THE TAB KEY ON THE
KEYBOARD.

At other times you may need to outdent tasks. This moves

the selected task to a higher level in the structure.

5 Set the duration for each task: type the number of

days into the column 'duration':
Design chair 10d
Test chair 10d
Manufacture chair 15d
Just enter '10' etc since MS Project will assume the units of
days.

6 The completion of one task causes the next one to

start. Link the tasks together. First select tasks 2 and 3. Then

96
Link them by pressing the 'link' button on the screen. DO
NOT DRAG THE TASKS TO ALIGN. (If you do, then double
click the tasks >properties/advanced/change constraint back
to as-soon-as-possible).

Likewise link tasks 3 and 4. Zoom out to see the whole

project.

7 Next we want to assign people to these tasks. Change to the resource

sheet: menu\view\resource sheet.

Enter names of people:

John

97
 Kim
Chun
Only enter names: the rest of the sheet is for other
information that will be covered later.

Return to the Gantt chart (menu\view\gantt chart).

Assign John to design the chair: Select the 'Design chair'. Press screen button.
In the new window select 'John' and then press screen button 'Assign'. Repeat
the process to Assign Chun to Test chair. Assign Kim to Manufacture chair.

You have now successfully created a simple project plan with

MS Project. Your plan should now look like this:
98
Try the exercises below on your own. Once you can create simple plans, you
will be ready to move on to projects with a more challenging work breakdown
structure.

EXERCISES
Exercise 1
The following simple Gantt chart shows a process for submitting a tender, e.g.
a civil engineering project. Reproduce this Gantt chart with the software.

Start date will be different to the one shown here, and that’s acceptable, since
MS Project usually starts any new projects on the current date. Of course this
can be changed.

Exercise 2
Simple parallel links may be created by linking from a common precursor.
Reproduce the following Gantt chart with the software. You may use a
different start date. (The ### simply indicates that there is too much text to
display.)

Note that the tasks are usually listed in the same time-order in which they are
done, but this is only for convenience. It is acceptable to link back upwards, as
in this example. In more complex projects there is so much happening at once
that simple lists break down.
Exercise 3
Create a simple project plan for landscaping a domestic garden. Identify the
tasks that will be needed, and set durations. Assign people.
99
Exercise 4
Create a project plan for organising a 21st birthday that will be held at your
home. Family and friends are available to help out with tasks, but they just
need to be told what to do and when to do it. Your Gantt chart is just what
they need, so make sure that it has their names on it.

Exercise 5
Reproduce this Gantt chart for a small product development project. It is
complicated by the various types of links used.

Exercise 6
A research and development project seeks to predict the residual life of diesel
engine timing chains, hence service implications, from vibration data.1 This is a
one-year project that involves building a measurement system, collecting data,
determining the critical parameters in the signal, and building a robust pre-
production prototype. Create the Gantt chart. The project has a one year
duration. Solution (one of potentially many) overleaf, but create your own
from scratch.

1This is the type of project that an engineering graduate might get while in a research and development role, or doing
postgraduate research.
100
Exercise 7: Desk project
The Hydra company wants to design a new office desk. Hydra currently make
only chairs. This project will require the creation of design capability (or its
outsourcing), and the creation of production capability. But running the
production line is not part of the project. Create a Gantt chart for this project.
Solution (one of potentially many) follows.

Exercise 8: Office conversion project

Hydra, the company that you work for, is growing and needs additional office
space. It has been decided to convert a store room in the existing building into
a set of offices for five staff members. Create a Gantt chart for the conversion
of the space. Assume that only minor structural changes (if any are required),
but that interior subdivision and fit-out would be necessary.

Exercise 9: Landscape project

The Hydra Office Company is situated on a flat property in a plain industrial
area. It is under new management now, and wants to improve its profile.
Consequently, it has been decided to landscape the surroundings. It is your job
to prepare the project plan for this. Assume that you are an external landscape
consultant. The project also moving the area where staff park their vehicles.

101
Exercise 10: Factory extension project
Business is booming at the Hydra Office Company, and they need an extension
to the factory. There is no problem with space, since they have plenty of room
to expand on their existing site. The new extension will be used for light
manufacture and assembly of a new range of office chairs. Assume that you
are a project manager for an external civil/architectural firm, and your scope is
to deliver a serviced building.

Exercise 11: Factory commissioning project

As a manufacturing Engineer with the Hydra Office Company you are busy with
plans for a major upgrade to the product line, in the form of a new office chair.
This involves an extension to the factory, and the commissioning of new
equipment (plastic injection molding and light presses), a new assembly area,
and a new stores/dispatch area. Create a project plan for this work. Note that
the building extension is not part of the scope of your project, at least not in
detail, though you would need to make assumptions about times and
availability of the new facilities. There is no problem with space, since they
have plenty of room to expand on their existing site. The new extension will be
used for light manufacture and assembly of a new range of office chairs.
Assume that you are a project manager for an external civil/architectural firm,
and your scope is to deliver a serviced building.

Exercise 12: Building services project

As a member of the property management team at the Hydra Office Company
you have the task of writing the project plan for some new office
developments. These is going to be a major upgrade to the factory, and some
new offices for production staff are being built as part of that upgrade. An
external contractor will be doing the building work, and your task will be to fit
the offices with furniture, computers, telephones, etc. Draw up the Gantt
chart.
SOLUTION FOR DESK PROJECT
At first this project might look intimidating, especially if you do not have
experience with construction. Here is a method that you can try, with an
example solution.

102
STEP 1: Make a list of physical outputs (stuff) Since the deliverables (outputs)
of this particular project are physical artefacts (things), an easy way to start is
to list all the things needed in the room. A list might look like this:
Lighting
103
Phones
Security
Electrical wiring
Data cables
Partitions
Paint
Carpets
False ceiling
Printer
Copier
Computers
Storage
Desks
Chairs
Filing cabinet
etc.
...............
...............
...............
Get the help of friends or colleagues when you make your list, because others
can anticipate things that you might miss. For example, the following could
also be added to the above list:
Door signs
First aid kit
Ventilation and air conditioning
New windows
Window blinds
Plumbing
Coffee machine
Pin boards for wall
Pot plants
Art work

STEP 2: Make a list of things to do (tasks). Now that you know what must go
into the room, the next job is to list the work need to get each of those things
in place. If you happen to have done previous projects that were similar, then
you could go directly to defining a complete list of tasks. However, in general
you will not have done a similar project, and will need to follow a different
strategy. This is to list the five or six big clusters of tasks.

104
This approach works well for many design projects because the main tasks
tend to be similar. The main tasks could be:
(1) Define scope
(2) Do detailed design
(3) Construct building (or Make machine, etc)
(4) Fit out building (or Test machine, etc)
(5) Hand-over

STEP 3: Decide on sub-tasks. Now take each of the listed things from STEP 1,
e.g. Lighting, and decide where it fits in the tasks of STEP 2. Generally it will fit
in more than one place. For example, there are several sub-tasks needed to get
lighting into the room. These are:
design lighting, which is done by a designer as part of Do
detailed design, and
install lighting, which is done by an electrician as part of
Construct building.

Your aim should be to break the task (lighting) down into sub-tasks according
to the person who will be doing the work. Then place that sub-task inside the
appropriate main task.

If you prefer working on paper, you can now create a mind-map diagram of
tasks, as shown above. Or you can go straight to enter the tasks into the
project management software.

STEP 4: Create Work Breakdown Structure. Now enter the project title into the
software, and then the (five) main tasks indented underneath it. (This permits
costs to be automatically summed at project level, as you will see later). You
can also add a 'start project' milestone. This makes it easy to move the project
if the start date is delayed. You should then use the 'indent' button to create a
work breakdown structure.

105
Solution for Landscape project

106
.6 The Project Management body of knowledge
(PMBOK)
The Project Management Institute (PMI) has developed a ‘Body of Knowledge
(PMBOK)’ [19] that describes the activities that a professional project manager
will in general have to consider. This brings a structured approach to problem
solving, as opposed to ad-hoc solutions with incomplete deliverables,
important accessories omitted, work not budgeted for, unnecessary rework,
unanticipated consequences.

THE NINE
The PMBOK identifies nine knowledge areas:
4 Project Integration Management
5 Scope Management
6 Time Management
7 Cost Management
8 Quality Management
9 Human Resource Management
10 Communications Management
11 Risk Management
12 Procurement Management

The numbering above reflects the PMBOK numbering and chapter designation.
The first four knowledge areas (project integration, scope, time and cost) are
core and unique to project management. The other knowledge areas (quality,
human resources, communications, risk and procurement) are from other
management and technology disciplines. The PMBOK suggests that you should
apply the nine knowledge areas throughout the stages of a project.
PROJECT INTEGRATION MANAGEMENT
Project Integration Management is simply the overall project management
task that keeps the whole project together. This activity occurs throughout the
project and includes planning, control and closure.
SCOPE MANAGEMENT
This is about defining the scope and creating the work breakdown structure
(WBS) down to the level of work packages. The PMI approach differentiates
between work packages (5) and activities (6). The work packages correspond
to the summary tasks in the WBS.

107
TIME MANAGEMENT
This covers the definition of detailed activities, estimating their duration, and
linking (sequencing) them together. It also includes allocation of resources and
a number of other matters .

The biggest problem with estimating time (and cost) is the intrusion of bias.
Bias refers to a person’s inability to see something impartially. Projects may be
affected by bias in various ways. At the activity level this might be someone
underestimating (or overestimating) the time required to complete the
activity. Many people are usually involved in providing the information that
goes into a project plan. Therefore the project manager has to be vigilant
about bias, not only self bias, but also that of others.

Different types of bias are:

 representativeness (stereotyping)
 availability (vividness of experience)
 over/under confidence
 motivational (comply with group expectations,
management requirements, personal ambitions)
 anchoring (can’t conceive the possible range)
COST MANAGEMENT
This covers the estimate of costs, production of a baseline, and then the cost
control activities that arise when the project is under way.
QUALITY MANAGEMENT
Quality is a broad discipline that originally developed in the manufacturing
engineering areas. Topics such as total quality management (TQM) have since
been developed to apply quality principles to the whole organisation. In the
process the focus of quality has moved away statistical techniques, though
those are still useful in production environments, to include customer
satisfaction (e.g. voice of the customer’) and continuous improvement (e.g.
the plan-do-check act cycle, six sigma), and much more. Design of experiments
is also included, but this is a mainly a statistical tool for research and
development or problem solving, and is thus of limited relevance to many
projects.

The PMBOK is provides an abbreviated coverage of the comprehensive topic

of TQM (see Figure 8-1 and 8-2 PMI, 2004). It includes topics like control
charts, run charts, scatter diagrams (among others) that are highly relevant to
continuous production processes. However these are not particularly relevant
108
to management of design projects, other than perhaps in commissioning of
plant.

The main quality activities from the project management perspective are to
determine the required quality of the deliverables, in such a way that
comparison of actual vs intended quality can be done. This is important
because the project manager will want to only authorise payment for services
where the quality is up to scratch. Thus the project manager may produce a
project plan (describing how quality will be ensured - a statement of intent),
checklists to be used during project deployment, and the metrics by which
adequate quality will be measured.
HUMAN RESOURCE MANAGEMENT
At the planning stages this covers the assembly of the staff (definition of
responsibilities, maybe an organisation chart, workloads required) and the
assignment of tasks to staff. Many of these outputs are available off the Gantt
chart and other reports produced by project management software. The
project manager will also need to manage the team, for example provide
training and motivation, sort out conflicts, appraise staff performance, and
help decision making work effectively.

The team is an association of people from diverse backgrounds. They may be

from the organisation or external consultants. They bring different skills, and
have to be managed.

The assignment of a person to your project team is usually temporary.

However it may be disruptive to normal business operations because of the
loss of staff, especially if no relief staff are provided (as is often the case). If
the assignment is partial, i.e. a person is expected to contribute both to the
normal job and the project, then this can be stressful for the person and there
may be a workload issue. Some projects may be long duration, in which case
people may find that they have no job to go back to at project closure, since
the normal business has compensated and made the position unnecessary.

The Project manager holds the team together. While individual team members
need only know their part in the project, the Project Manager needs be able to
create the project plans and keep the overall objectives in sight.

The Project Manager position is a difficult one. The uncertainty and possibility
of failure is very much more apparent in projects than in general management,
109
creating stress. Time and cost constraints are more intense than ongoing
management. There is also less job security. In addition team members are
more difficult to coordinate as they are from different professional
backgrounds and have no long term relationships to maintain with colleagues.
Also, the team may consist of people from both client and service provider
organisations, with different and conflicting strategic objectives. It can be
frustrating to have a task to do, but have to rely on other people to do their
part when those others are not task focussed and not answerable to the
project manager.

The position also has rewards, such as the opportunity to prove abilities. There
is also excitement, challenge and a sense of accomplishment.
COMMUNICATIONS MANAGEMENT
The project manager will need to communicate with clients, superior
managers, sub-contractors, and staff. These people have different reporting
needs. The PMBOK calls for a communications management plan (p227),
although many projects will not actually need this level of formal statement up
front. More important is the topic of performance reporting (p231), since
clients and managers will generally want to be informed about project status.
RISK MANAGEMENT
All projects have risks to some extent. Even routine projects have schedule
and cost risks. Novel projects have those risks plus technology and quality
risks. There is a large separate body of specialised knowledge on risk
management, and the PMBOK extracts some of this (see Figure 11-1 and 11-2
PMI, 2004). The topic is returned to in a subsequent chapter, but for the
moment we shall simply present the PMBOK perspective. The PMBOK calls for
risk management plan. Risks need to be identified and analysed (qualitatively
or quantitatively). Suggested methods to respond to risks are avoidance,
transfer to a third party, and mitigation (reduction in likelihood or
consequence). Monitoring and control of risks is also included.
PROCUREMENT MANAGEMENT
Procurement refers to purchase of goods and services. Many projects, for
example in civil engineering construction, involve subcontracting.
Consequently it is necessary to decide what work will be done in-house vs.
subcontracted. The external work packages may need contracts to ensure that
the deliverables are correct in quality, time and cost. These contracts have to
be managed and may need to be changed during the project to accommodate
changes in scope or environmental factors (e.g. the cost of goods may increase
during the project) (see Figure 12-1 and 12-2 PMI, 2004).
110
Contract administration is a large topic in its own right, and no attempt is
made here to fully explain it. The interested reader is recommended to study
further in the construction or legal domains where the topic receives full
coverage.

5 Project planning process

PLANNING

.1 Define the scope

The scope describes the project deliverables (objects and characteristics
thereof) and, identifies the criteria that will be the basis of determining
success.

The scope is the statement of the project deliverables, e.g. the products and
their features. It gives the criteria that will be used to determine whether the
project is successful. Often this has contractual and financial consequences. In
engineering design terms this corresponds to the functional specification, and
in systems engineering to the requirements analysis.

The PMBOK perspective is that the scope involves collecting the requirements,
defining the scope, creating the work breakdown structure, verifying the
scope, and controlling the scope [19]. If the client is familiar with the
technology, then he may be able to directly express his technical objectives
and their importances, e.g. product and service features. However in general
the client will not have this knowledge so explicitly, and it will be necessary
instead to converge towards a common understanding of the purpose of the
project (2). Either way, there comes a point where the purpose of the project
may be described (3), though it may take several iterations and some
negotiation to reach this point.

The purpose statement is descriptive and broadly sets out the reason for doing
the project and the overall intended benefits and outcomes. Next it is
necessary to create a more specific definition, i.e. to elaborate the objectives
of the project (4). These objectives could be the products that will be
delivered, and their features, assuming that the project is producing
something tangible. The key performance criteria (descriptive or quantitative)
will also be described. This activity answers the questions:
111
  What exactly will this project achieve?
 What outputs will be delivered? (Not the same as the work that will be
done).
 What is the outcome that will constitute acceptance/satisfaction?
 How will the adequacy of that outcome be determined (quality)?

With those answers it is possible to state the scope (6). The scope describes:
 the project deliverables (objects and characteristics thereof) and,
 identifies the criteria that will be the basis of determining success.

As noted above, these criteria will have contractual and financial implications
if the project is one that requires a formal contract. If the organisation does
not have the capability (5) to meet these objectives, then the project scope is
infeasible and needs to be renegotiated. This situation could arise at any time,
during the planning or during deployment. The ability to renegotiate will be
determined by the contract and the willingness of the client.

.2 Create the Work breakdown structure

Creating an adequate work breakdown structure (WBS) is a key activity in
project management. The WBS is a hierarchical decomposition of the project
scope into pieces of work. While the project scope is focused on deliverables
or outcomes of the project, the WBS shows how the internal work is intended
to be done to achieve those outcomes.

The architecture of a project, as expressed in the WBS, typically has an overall

structure of temporal phases (e.g. feasibility study, consultation, design, build,
test & assembly, commission). Within this are commonly found sub-projects
for the technical and hardware components (e.g. road, electrical equipment,
foundations, wind-turbne mechanicals, etc.)

The process to create a WBS is:

1 Take the deliverables from the scope.
2 Anticipate the blocks of work that will be needed to achieve those
deliverables.
3 Create a hierarchical structure (sub-headings). Different structures are
possible, e.g. by temporal phases or engineering subsystems, or
combinations thereof.
4 Refined to detailed tasks. Use verb noun at this stage.

112
The WBS must be taken to a sufficient level of detail: clear, coordinated, and
control.

Suffiency means:
 Clarity of task for workers. If team members have high autonomy or
specialist skills, then less detail can be expected in the WBS.
 Ability to release preliminary information to other work streams
 Allows reporting from team members. Provides the desired granularity
of control over finance.
In doing so, one has to assume a level of competency in the workers. For
example, in a factory fitout, the project plan does not need to tell the
electricial how to run the cables to the machines. As one gains experience, so
one becomes better able to anticipate the roles of others and what level of
instruction they need.

WHAT CAN GO WRONG WITH THE WBS?

Defining the tasks is not as easy as it seems, and often the definition is
inadequate [20]. Each activity must have a description, duration, cost, and
resources. That is usually relatively easy to do, but the more difficult problem
is making sure that all tasks are included in the first place [7].

The WBS must include all the work needed for its completion. Anything missing
is not part of the project, and will delay the project or increase the cost when
found.

No unnecessary work should be included in the project. Unnecessary work

adds cost and duration to the project, without affecting the agreed
deliverables.

Such work may also be corrupt – it may be where the project is padded out to
include backhanders and favours.

COMPARISON TO DESIGN THEORY

Several of the design theories, particularly from the European school of
thought [4, 21], express the idea that engineering product/machine design
proceeds from specification, to functional decomposition. This process is
directly comparable to the process that takes a project scope and creates a
work breakdown structure.

113
 sufficient
project scope
(deliverables/
function,
time, cost)

List the main

list of outputs
tangible of project
deliverables (1)

Risk: omit
integration tasks
Necessary
precursor
Break the project
into more List of blocks
tasks to
of work (in
achieve the manageable hierarchical
various blocks of work clusters)
outputs (see
Pm-1-4)
(2: Pm-1-2-2)
Benefit:
makes the
objectives
Anticipate the blocks mechanisms for more
of work that will be WBS: structured achievable
needed to achieve decomposition,
the deliverables. object based,
Each block of work template
advances closer to
the overall project
objective.

Skill and experience

of people who will
be doing the work
determines the level
of instruction
needed

Need for project

control over finance
Sequence,
schedule,
dependencies
between tasks
(see Pm-1-4)
Refined work work
breakdown breakdown
Define the
structure and structure
precursors detailed tasks (3) (WBS) and
(see Pm-1-4) tasks

specificity of goals is Team

Explicit statement of the work Define to the
strongly associated with formation
that will be done. Description level of detail
high motivation (goal- effects
is clear enough that there is a needed for
common understanding reporting setting theory, Locke,
between project manager from team 1968) (see Mo-5-3)
and team member as to what members, or
is required to be done. May for control
allocate a person or over finance
resources to tasks. These are Document the
sometimes called work WBS
packages.
WBS document
(4: Pm-6)

114
Determine work breakdown structure and tasks
Copyright Dirk Pons . File version: VisioDocument. Sheet: 12. Printed: 8 March, 2010

(Pm-1-2)
OPTIONS FOR STRUCTURE
A work breakdown structure is like a grocery shopping-list. For most people
grocery shopping is a sufficiently routine task that a simple list is adequate, see
column 1 below. However, if it was worth the effort, then the list could be
structured by shopping isle (column 2), or by meal type (3), or by day of the
week (not shown).
Simple grocery list without any Structured by shopping isle: Structured by meal type:
structure:
Potatoes 3 kg Vegetable isle Breakfasts
Broccoli 1 head Potatoes 3 kg Milk 4litre
Rice 5 kg Broccoli 1 head Weetbix
Honey x1 Jam (strawberry)
Mince 1 kg Tins and dry goods Yoghurt, Greek 1 litre
Chicken 2 kg Rice 5 kg
Frozen peas Weetbix Lunches
Eggs x12 Sugar, raw 1 kg Honey x1
Milk 4litre Sugar, white 2 kg Margarine, 500g
Oil 2.5 litre Oil 2.5 litre
Tin fruit, peaches x 5 Dinners
Weetbix Jams and desserts Potatoes 3 kg
Sugar, raw 1 kg Honey x1 Broccoli 1 head
Sugar, white 2 kg Tin fruit, peaches x 5 Rice 5 kg
Jam (strawberry) Jam (strawberry) Mince 1 kg
Toilet paper Chicken 2 kg
Detergent, Dishwash Refrigeration isle Frozen peas
Detergent, clothing Mince 1 kg Tin fruit, peaches x 5
Yoghurt, Greek 1 litre Chicken 2 kg
Margarine, 500g Frozen peas General cooking
Milk 4litre Eggs x12
Margarine, 500g Oil 2.5 litre
Yoghurt, Greek 1 litre Sugar, raw 1 kg
Sugar, white 2 kg
Kitchen isle
Toilet paper
Detergent, Dishwash Household
Detergent, clothing Toilet paper
Detergent, Dishwash
Bread and eggs isle Detergent, clothing
Eggs x12

Similarly, a WBS is a structured list of tasks. The way it is structured depends

on the project. Some common structures are:
Structured by time phase (work sequence).

115
This is one of the most common methods. Many projects have a natural
sequence of steps that are ordered by time. They may overlap to some degree,
but each occupies only a part of the overall timeline of the project. For
example, a house building project typically has phases of design, building
permit, contract administration, site preparation, foundations, walls, roof,
external cladding, plumbing, electrical wiring, internal cladding, finish
plumbing, painting, finish electrical, floor coverings, landscaping.

Structured by engineering sub-system.

In many product-development cases there are different engineering sub-
systems that need to come together in the final product. For example, an new
electric drill requires a motor, gearbox, housing, electronic control, charger,
packaging, and marketing material. These can each be their own high-level
item on the WBS. This approach is especially useful if there are specialist sub-
teams working on parts of the project, and their effort is required through
most of the project timeline (though not necessarily continuously so).

Other structures.
It can be appropriate to structure a WBS on other factors such as geographic
location [20], work group or company division, etc.

A WBS may use different structures in various places. For a simple project I
would structure it by time phase. For a more complex product-design project I
would structure it by the main deliverables, or by the physical sub-systems.
Then I would structure by time phase within each of those sub-systems. I
would also make sure to add an activity of ‘manage the project’ at the top, to
cover all the integration work that is necessary, like setting up the project in
the first place, running it, and closing it down at the end.

SOFTWARE IMPLEMENTATION
In most project management software the usual place to create the WBS is in
the Gantt chart view. Simply list the tasks in the column, and create the
hierarchical structure by using the appropriate indent command.

116
A simple WBS for building a carport. Note the hierarchical structure (indents)
which shows main tasks and then the sub-tasks underneath them.

TOP-DOWN APPROACH TO WBS

With this approach, the project manager starts with the big picture and works
towards the detailed tasks. This may be the best method where the project is
novel, i.e. the project manager does not have experience of the technology, or
the project is multi-disciplinary. The process is as follows:

Define the overall project objectives (e.g. extend the production capability of
the dishwasher assembly plant).

List the deliverables or physical sub-systems or phases (e.g. build an

extension to the factory, install new plastic injection molders in the extension,
reposition the staff car park, provide for handling of more inwards and
outwards goods, and re-landscape the grounds). Include an overall project
management function to provide support [20].

117
Identify every area of work required. It is essential that nothing is missed out.
This is the biggest risk area in the planning process, i.e. the stage where it is
possible to make the biggest mistakes. For example, a large teaching
organisation built a new multi-storey building on their campus. Once it was
complete and ready to be occupied, they made the unfortunate discovery that
there had been no planning for classroom or office furniture. This was a major
unbudgeted expense.

A simple way of ensuring that the WBS is complete is the “100% rule” [20]
which you apply by asking yourself: “Does the sum of the work represented
by the child elements equal 100 percent of the effort summarized in each
parent element? Is any work missing?” (p19)

Detail the project down to the work packages. The WBS can be progressively
detailed with additional levels, until eventually the packages of work are
apparent. A work package is a collection of tasks that can be assigned to an
individual or organisation [20]. It might be a large block of work that can be
subcontracted. Below the work packages are the actual tasks.
It is often convenient for the financial accounting and monitoring to be at the
level of the work package, rather than the tasks [20]. This is because actual
costs on individual tasks can be impractical to obtain, and are often somewhat
artificial. Thus the work package often has a financial account (cost centre) so
that it can be monitored.

In some industries it is common practice to have a WBS that has only three
levels. However, as PMI observe, ‘that number may not be appropriate for all
situations’ [7]. The number of levels (depth) in a WBS must be determined by
the complexity of the project, not some arbitrary external constraint.

Bottom-up approach to WBS

This method starts with the detailed work packages and simply lists them.
Then suitable headings can be included to group related tasks, if desired. This
method is suitable for project managers who are themselves experts in the
technology being used for the project. We typically find this method is popular
for vocational people who are moving into management of their trade area.
They know their trade so well that they can easily list the tasks required in a
WBS. For example, an expert carpenter often uses a bottom-up method if
he/she moves into a new position as construction manager for domestic
building.

118
It is a reliable method where the project manager has first-hand experience of
the technology (or a lot of experience with managing very similar projects).
However, the bottom-up method has serious limitations when the project is
outside the experience base of the project manager, or incorporates multiple
disciplines. In these more complex cases it is often necessary to use a top-
down approach.

Template approach to WBS

A third method for creating a WBS is simply to adapt a existing WBS that
someone else has developed. Pre-developed work breakdown structure
templates can be found in books such as the PMI practice standard for WBS
[7]. There are also templates that come with software such as MS Project®.

This is an excellent approach when the project manager does not have
personal experience, but the project itself is not novel. It permits a project to
benefit from the experience of others on similar projects. Many construction
and procurement projects are ideally suited to this approach.
INTEGRATION TASKS IN A WBS
All projects require ongoing management, and thus project management is a
work package that needs to be included in the WBS. This is one kind of
integration task [7], also called ‘cross cutting activity’ [20] that applies to the
whole project. Other similar tasks include assembly of a physical system,
analysis (research, design, development, reliability analysis), and testing.

These integration tasks apply across multiple activities (hence the name cross
cutting). They need to be shown in the WBS at the level at which their peer
tasks occur. They may be shown by an entry for ‘Project management’, and
this should always be at the level immediately below the main project
outcome. The risk is that the WBS omits these integration tasks, and they end
up having to be done anyway but without resources.

DEFINE THE DETAILED TASKS

The final activity is to extend the WBS into describing the detailed tasks. This is
typically necessary, though in some projects involving sub-contractors it may
be sufficient to stop one level higher at the work packages.

The WBS, up to and including the work packages, is often conveniently

structured according to the physical deliverable, and thus the items tend to be
nouns. At this final level where the tasks are defined, the wording tends to
119
change to reflect the actions. Thus it is common at this level to use verb-noun
descriptions, e.g. ‘excavate foundation’. The project manager will break the
work packages down into the individual tasks. This may require several levels,
because they need to be broken until there is sufficient detail that the worker
will understand what needs to be done. This will also give the project manager
adequate detail for subsequent reporting and control.

If the Project Manager breaks the tasks into too much detail, then he/she risks
micro-managing other people, and they will generally find this de-motivating
and leave responsibility for quality to the Project Manager. In practice this
means that the Project Manager needs to anticipate the level of skill in the
people who work in the project. If they are highly competent, then the WBS
need not go into detail. This is often the case with sub-contractors who provide
specialist skills and are proud of their work. However, less competent people
or new trainees will need to have their work more explicitly laid out.

A task may need to decomposed into smaller tasks if it meets one of these
criteria:
 More accurate cost or duration estimates are
needed.
 More than one person is responsible for the
work.
 The timing between internal tasks is important.
 Individual internal tasks are linked to other work
packages.
 Duration is longer than 80 hrs.
(Adapted from Haugan, 2002, p34).

A similar principle applies in the common practice of subcontracting, where

another organisation is given the whole responsibility for a deliverable. The
actual technical details of how they achieve this, which may be very complex,
are of no interest to the main project manager. As long as the contracted
deliverable is provided at the set date to the agreed price, then the project
manager is happy.

The assumption project management is that all resources who are assigned to
an effort-driven task will contribute equal efficiency: it is not possible to
specify that some people are experts and others only trainees.

120
PSYCHOLOGY
The way the work packages are made up and the level of detail in their
description should be customised to the individuals on the project. For
example, the work package could be described with sufficient detail for the
recipient to understand the task, and be motivated by it. More or less detail
could be de-motivating or confusing respectively. Tasks could be slightly more
rather than less challenging and with specific goals so that the criteria for
personal satisfaction are obvious [22]. From the goal setting perspective, high
goals direct the attention to relevant actions [23] and high self-efficacy
provides the duration and intensity of effort to complete the job despite
setbacks [24]. Furthermore, participative goal setting processes may also assist
satisfaction because they have social and esteem components that are typical
contributors to satisfaction.

.3 Estimate durations
Ultimately each task will be allocated to a person, and they will also be given
some time in which to do the work. Thus it is necessary to estimate the
duration (length of time) for each task.

Technically this is not part of the WBS, but in practice it is closely associated
with the WBS and may be done in parallel as the WBS is being built. This close
association arises because the level of detail in the WBS determines the
duration: a task defined at a high level will need more time than the same one
that is broken down into numerous smaller ones.

Estimating duration can be relatively simple, involving an estimate of the

nominal task duration. However it can also be a more complex process if the
uncertainty in that estimate is to be captured.

Durations are typically estimated based on the experience of the individual on

related past projects. If that experience is lacking, or the project highly novel,
then those estimates may be not much more than guesses or statements of
intent.

In practice the durations are typically entered directly into project

management software, in units of days, weeks, or months.

121
.4 Define the sequence of work
Once the precursor tasks are identified, the WBS present, and the durations
specified, then the inputs are available to complete the project plan by
defining the sequence of work.

This activity corresponds to ‘scheduling’ in the PMBOK, which may be found

under ‘time management’ [19].

In times past project managers would explicitly record the precursors, draw up
the sequence, and then create a network diagram. That in turn formed the
basis for the techniques of critical path method (CPM) and project evaluation
and review technique (PERT).

A simpler method, especially with the help of software, is to use the Gantt
chart.

The Gantt chart is used to define the sequence of tasks by creating ‘links’
between the tasks. There are several types, these typically being named by the
origin and destination, thus finish-to-start, start-to-start, finish-to-finish, and
these may also have delays (lag and lead).

The output of this activity is a work plan. It details the tasks that will be done,
the length of each, and the timing of each. This is typically expressed as a Gantt
chart. At this stage it only needs the allocation of resources to be a complete
project plan.

One the sequence of work is defined, then the schedule is complete and the
due dates for the tasks become apparent. Some of these tasks may deliver
outcomes that are required by a specific date, these typically being the tasks
on the critical path. These then become the deadlines for the team members.
However, it has been pointed out that people have different responses to
deadlines and this can result in frustration within the team [25]. Thus deadlines
are not necessarily a simple factoid, but may affect team performance by the
manner in which the project manager presents them to the team.

Determine task interaction

The task interaction is represented in the Gantt chart as a series links.

122
In simple projects the tasks simply follow each other sequentially, and are
represented in the Gantt chart as a series links. For example, in building a
house, the walls need to be in place before the electrical wiring is installed.

However projects are generally more complex than that. This arises because
the tasks interact with each other by requiring precursor information or
hardware to be in place before the task under consideration can start.
Furthermore, projects are typically done under time constraints, and thus
there can be pressure to overlap tasks simply to complete the system faster.

The sequence is determined by anticipating the precursor tasks, e.g. the

equipment and knowledge that needs to be in place before the task under
consideration can start. This permits certain tasks to be strung together in
series. There may be several such strings in the project. Project management
software represents this as links, and several types are available. The project
planner will be alert to the opportunity for sequencing tasks in parallel
(concurrent, or overlapping), since this is a major method for reducing total
project duration.

SERIES PROJECTS
In simple projects the activities, e.g. design and manufacturing, are done in
series. If tasks in a project follow one after each other (finish to start), then the
tasks are in series. This has the consequence that a delay in any one of them
will delay the whole project. In a Gantt chart this is evident in finish-to-start
links, which often give a staircase look to the chart. Only when the design has
been completed does the manufacturing starts.

Project tasks, all linked in series (finish to start). This is a good start, but is not
enough for a good project plan. Instead, the project manager needs to find
places where tasks can be done in parallel, and then change the links as
necessary.
123
In many cases, it is necessary to get a project completed in a shorter time
frame, usually because of competitive reasons. To do this requires one of
several adjustments to the basic series project plan: get individual tasks done
faster by working harder or sharing the work over more people, or do tasks in
parallel.

Generally, a single person working on a project has limited ability to do things

in parallel, and can only work harder to make a difference. However, most
significant large projects are undertaken by teams of people, and so it is
possible to have different people doing different tasks, and this is where the
power of project management becomes evident.

PARALLEL DEVELOPMENT OR CONCURRENT ENGINEERING

Parallel tasks are those that occur at the same time. For example, they might
start or finish at the same time, or partly overlap. In most projects there are
some tasks than can be done in parallel. These are tasks that are independent
of each other. In the more general case the project team may need to break
the tasks down to create opportunities for concurrency. The problem is that
large monolithic tasks do not lend themselves to concurrent (or parallel)
scheduling.

Project tasks, all linked in series (finish to start), but with some parallel streams
of tasks. These parallel streams have to be identified by the project manager
(they cannot automatically be created by the software) as they require
knowledge of the context. The parallel streams are created by controlling the
precursor tasks, and not automatically assuming that the task higher up in the
list has to be done first. Later it will be shown that parallelism can also be
created by changing the type of link (e.g. to start-to-start). Note that links may
have a lag (delay), e.g. link from 7 to 9, which is created by double clicking the
link. Note also that multiple precursor tasks can be specified (e.g. task ID 7), so
that the task only happens when ALL of the precursors have completed.

124
In practically all situations there is benefit in capturing the opportunity for
parallel (concurrent, overlapping) tasks, because this permits the
project/product to be brought to completion quicker. Doing so does burn
through resources faster (hence cash-flow implications), and might even cost a
little more, but it has several benefits. These are quicker time to market,
shorter delivery times to final customer, beating the competition to market,
taking advantage of external windows of opportunity (dry weather for
construction projects, Christmas shopping season for new products), or simply
more time to fix errors if the project is complex.

The solution is to redefine the task list, in particular breaking the tasks into
finer sub-tasks. There are several ways to achieve this: Create sub-tasks to
allow earlier release of results, Use lag (lead) to give time for one task to get
ahead, specifically create new tasks to find useful preliminary information
(information gathering, quick experimentation).

Overlapping tasks by releasing preliminary information, in this case #9. Note

that this task has a SS link with a lag, to give the team some time to get some
design done before David gets it together for release.

This approach may shorten the project time, reduce costs, and get a product
to market earlier. Usually it is necessary to find additional resources to
implement parallel tasks, i.e. many people have to work on different parts of
the project at the same time. If this is not done , then people are easily
overloaded, with consequent stress, dissatisfaction and demotivation. Once
people fail, a parallel project rapidly disintegrates into a series project, and the
sudden extra project duration can be difficult for a firm to cope with financially
and strategically.

Create links with software

Links show the sequence in which the tasks are done. The most common link is
‘finish to start’. This means that one activity must finish before the next can
start. Here is how you can set up the default finish to start links:
 Highlight all the tasks to be linked, and press the ‘link’ button (chain
image). You can highlight the tasks by holding down the ‘Ctrl’ key as you
125
 click them with the mouse. (NB: Release the ‘Ctrl’ key before you press
the ‘link’ button!)
 Alternatively, graphically drag one Gantt bar (not the text) on top of
another that you want to link to.
 Manually enter the number of the predecessor in the column.

Links are important because they permit the project plan to accommodate
adjustments dynamically. Also, they determine which activities are critical (see
critical path later). Don't try to manually reposition the tasks relative to each
other. This will introduce unnecessary constraints (to repair: double click the
tasks >properties/advanced/change constraint back to as-soon-as-possible).

CREATE PARALLEL LINKS

There are several ways to create parallel links in MS Project. The simplest
method is to have multiple tasks all linked F-S from a single precursor. This the
simplest and often the easiest to do. It also gives the most predictable results
with critical path (discussed later).

A single precursor, in this case a milestone (diamond), can be used to place

tasks in parallel.

Otherwise, change to a different type of link:

1. Start-to-start links (S-S) are a special type of link that makes two tasks
start at the same time, or at least as soon as possible. However, the
successor (second) task will not start before the predecessor. Usually the
two tasks will start at the same time, but you can add a lag if necessary.
Use this link where the starting of tasks can be coordinated to start at
the same time or after a set delay. With start-to-start links it is implied
that the finish dates for the two tasks are NOT co-ordinated.
2. Finish-to-finish links (F-F) are a special type of link that makes two tasks
end at the same time. However, the successor (second) task will not
finish before the predecessor (first). The two tasks will tend to finish at
the same time if they can, and to do this the shorter task will start later
(where possible). Therefore, the starting of these tasks will NOT be

126
 coordinated. Use this link where things have to come together at the
end.

Finish to finish (FF) link

In MS Project simply double click on a link to change it to another type. (Right-

click with some software).

Simple parallel links. This diagram shows several different ways of placing tasks
in parallel.

Some suggestions for a clean project:

 Consider inserting a milestone at the beginning (and end) of the project
so that everything moves together.
 Add other links as necessary: highlight the activities (use ‘Ctrl click’ to
select multiple tasks) and then link.
 Make sure every activity is linked into the project in some way both its
start and its end. The links may be either directly to the task or to its
summary task. This is necessary to show the critical path properly.
 Links may be made to and from summary tasks too.

LINKS WITH LAG AND LEAD

In all types of link a time lag or lead may be specified. A lead (ahead) is useful
when the second task can start half way through the first, for example the
electrical wiring can start to be installed before the panels are all finished. Use
a negative value for a lead.

127
A lag (behind) is used when the second activity must wait some time after the
first one completes. The lag is useful for showing time required for paint to dry
for example. Values may be specified in time units or percentage of the first
task. In MS Project, to access the lag (delay) or lead: double click an existing
link.

Examples of lead and lag for a simple project of two tasks.

128
SUMMARY DIAGRAM
work
breakdown Identify tasks Tasks with
structure
(WBS) and
that can be done no common
in parallel (2) precursors
tasks (see
Pm-1-2)
Necessary
Anticipate the precursor
list of outputs tasks to
of project
precursor tasks achieve the
(1) various
outputs

Ask: What predecessor

Subject-relevant tasks need to be done
experience helps before this one? What
information needs to be
known, or hardware in
place, before the current
task can start?

Need to capture
opportunity for parallel
(concurrent, overlapping)
tasks
Consider breaking tasks
to release preliminary
design information to
Aversion to downstream processes
ambiguity

Redefined
task list
Break tasks
down to create release early data
opportunities (3) (concurrent
engineering), dual
track development,

Define the Refined work

Create sub-tasks Use lag Set tasks to create breakdown
(lead) to give sequence of structure and
to allow earlier useful preliminary
release of results time for one information work (4) precursors
estimate of
task to get (information task duration
ahead gathering, quick (see Pm-1-3)
experimentation)

Represent links Sequence,

schedule,
between tasks dependencies
(5: Pm-6-1-2) between tasks

Determine
Software
critical path for Critical
mechanisms:
time path
Gantt chart,
network (6: Pm-6-1-3)
diagram
(see Pm-6)

Copyright Dirk Pons . File version: VisioDocument. Sheet: 14. Printed: 2 July, 2009

Determine task interaction

(Pm-1-4)

129
 Origins of Hydra’s Octopus chair
‘I’m just not sure’, replied Derek cautiously.
‘Why not?’, asked Neil, the General Manager.
‘Well, I think a group of university students might be able to do the research and development on the Octopus project.
But they might not.’
‘But it would be much cheaper for us to let them do so, no so?’
‘Yes, of course. But maybe not because they would take a lot longer perhaps, so we could be longer to market.’
‘Hmm, good point’, responded Neil. ‘Time to market is important for us.’
‘I tell you what’, replied Derek, his face brightening, ‘We can do a preliminary project plan to work out how much it
would cost us to do the job with full-time staff. Then we can compare and make a decision.’
‘Yes, that sounds like a good way to approach the decision.’
‘Fine, and I’ve got just the person who can do the project planning for us; one of our new staff who is showing some
real skills in this type of area.’
‘Great! So let’s have it by next week if possible, and review it then’, answered Neil.

It wasn’t a minute later that Derek was in your office, explaining what he wanted you to do.
‘Preliminary information’, he said, ‘Sufficient to be able to make a decision. This project needs to be fully costed, as if it
were being done by a commercial research and development company. I’m looking for a Gantt chart with costs and
resources.’

‘I’m right onto it’, you replied. Truthfully, as it turned out. The door shut and Derek was gone.

There was a look of respect on the face of Kevin, your office mate, and a fellow engineering graduate (albeit from
another university).
‘Can you really do all that?’, asked Kevin incredulously.
‘Of course!’, you laughed. ‘At least, I know where to start on the principles, and I know how to use the software. And
after that I guess I’ll just have to rely on my brain to work the rest out.’
Kevin looked thoughtful. ‘Hmm, do you mind showing me how to do that sometime when you have a moment free. I
really like to know myself.’

.5 Allocate resources and costs

Each task needs resources. In this context resources refers to equipment,
people, specialist services, subcontractors, and consumables. These are
categorised into LABOUR cost (duration x hourly rate), FIXED costs which may
be lump sum or capital, and CONSUMABLES (materials that are consumed
during the project).

Once the resources are allocated to tasks, then it is advisable to check that the
resulting workload is feasible for the people concerned. This is an issue
because the sequence of tasks, particularly parallel links between tasks can
cause individuals to be overloaded. Also, many projects are done within
organisations where there are other projects happening, so conflicting
resource requirements readily arise. If the overload is too high to
accommodate with overtime, then it will be necessary to adjust the project
plan elsewhere, reallocate resources or even define the WBS or links.
130
A similar exercise is to determine the quantities of materials required, though
of course the issue is not workload but feasibility of procurement. With the
allocation of resources complete, the information is ready to determine the
total project cost. Software is available to do much of the routine calculation.
Labour cost
This refers to the cost of employing people. As previous sections show, part of
project management is assigning people to specific tasks. Those people have a
cost. In project management the labour cost arises when a person is assigned
to a task. However it’s important to note that the only cost is that due to the
hours that the person spends directly on the project. When a person is not
allocated to any task, then no labour cost arises. Of course the labour rate of
the person needs to be known, and this is usually provided in ‘cost per hour’
terms.

Resources are things, e.g. people, who do the tasks in your project. Resources
primarily include people and equipment (work resources), that are not
consumed when they are used. These work resources can have an hourly rate
specified, using the resource sheet. The total cost of using that resource is then
determined automatically by the software, using the hourly rate and the
duration.

Labour Costs are applied to resources. Note that resources include people and
equipment. The resources may also include consumable costs where those
costs are proportional to time. The software permits labour costs to be defined
for:
 standard working rate
 overtime rate
 calendar for each person setting the working hours (may be unique)
 maximum workload as a percent of full hours, after which overtime
becomes payable
 call-out cost
 method of payment (up front, pro-rata with time, or on completion)
 people may be assigned more or less work than their maximum, this
assignment being done at each activity

RESOURCE TABLE
All these costs are available in the resource table:
 The Resource table is available from <menu>/View/Resource sheet
131
  Or from a button on the ‘View bar’ at far left.
 When you are done, revert to the Gantt chart by changing the view in a
similar manner.

The Resource table shows the maximum units, that is the threshold over which
overtime rate becomes payable. The actual allocated units is shown for the
activity, and may be more or less than the maximum.

Resource sheet

In the above figure ‘Joe the Builder’ has ‘Max units’ of 100%, and this is the
default. On the actual task we have the option to use him more or less.

A person may be allocated to more than one concurrent task, and this may
cause them to be overloaded, even if each individual task is below the
maximum. They will then be marked with red text.

OVERTIME
This is an advanced topic.
The resource sheet makes provision for an overtime rate, which is a higher
rate for work in excess of the maximum ‘max units’. It is easy to set the
overtime rates in this table. However, MS Project will not automatically apply
them: instead the project manager has to manually give permission for the
overtime rate to be applied. See the help file for more details.

CALENDARS
This is an advanced topic.
Each person (resource) can have a different calendar. For example, you could
have a person who only works mornings, or takes different holidays. To create
a new calendar, use menu Tools/Change working time. You can then either
edit the standard calendar, or you can create a new one. I suggest you create a
new one with a different name so that you can recover from any edits.

To change calendar for a particular person (resource), go to Resource sheet,

and select the Base calendar from the drop down list. If a suitable calendar has
132
not previously been created, then go to Resource sheet, select the person, and
then use menu Tools/Change working time to create an individual calendar.

A potentially tricky aspect concerns calendars and the definition of a ‘day’ in

MS Project. It assumes a day is a block of 8 hours. For example if you create a
task of 3 days duration, it will assume that the work is 3x8hr = 24 hr, and
initially show it over three days. If you then apply a 24 hr calendar, the
software will correctly show the task occurring over only one day, but it will
still list it as 3 days in any summary task. This is because the default duration
for summary tasks is set as days and a day is assumed to be the duration
divided by 8 hrs. You can change this: use menu Tools/Change working
time/Options../Hours per day.

To change the default calendar for a project, use menu Project/Project

Information../Calendar and select from the drop down list. You would be wise
to do this early in the development of your Gantt chart, before you have
entered too many activities.

WORK AND DURATION IN MS PROJECT

This is an advanced topic.
Some additional scheduling features are provided in the software for advanced
users: the task may be Fixed duration, Fixed units, or Fixed Work.

The software distinguishes between ‘duration’ and work’. Duration is the total
number of days taken to complete the activity. If many people work on the
activity then the duration is reduced. The total ‘work’ performed is the same,
but having more resources gets it done quicker. It is termed ‘effort based’
scheduling when adding resources decreases the duration (with no change to
work), and this is the default behaviour. However you can turn this off for the
project as a whole (Tools/Options) or for individual activities (double click task
description/Advanced).

Here are some examples:

Common tasks: Generally, the more people who do a job, the faster it goes.
Keep the default setting of fixed units (effort driven) but assign them one-by-
one (not all together). Otherwise, use fixed work.

Meetings: More people don’t get meetings done any faster, so change the
task properties to fixed units (not effort driven) or fixed duration (not effort
driven).
133
Curing concrete: This task requires a set amount of hours. These hours can
occur during the night and over weekends, and this can be challenging to
model with MS Project. The only way seems to be to make the task fixed units
(effort driven is not critical). Create a resource ‘Concrete cure’, give it the 24 hr
calendar, and assign it to the task. Adjust the duration x3. For example, if you
want 7days of curing @ 24 hr = 168 hr, then enter 21d duration. (Or call up the
‘work’ column and type in 168 hr). Messy, but that’s the best I’ve found!

Weekend work: Change the weekends to working days.

When you set up the Gantt chart you specify duration, typically in days [d]. The
amount of work that anyone does is zero, until you assign people (resources).
The first time you make the assignment, the work7 is automatically calculated
according to the ‘task type’ property setting, which can be fixed units, fixed
work, or fixed duration. Each task can have a different setting8. Initially, you
can assign one or more people to the task, and the work and duration will
adjust according to the setting.

A separate setting, called ‘effort based’ controls what happens when you
subsequently assign additional people to the task.

(1) Fixed work:

Initially: The amount of work equals the duration, on the basis that 1 d
duration = 8hr work. Whether you initially assign one or more people to the
task, the work stays the same. However, the duration will adjust, decreasing if
more people are initially assigned.

Subsequently: Fixed work is always effort based. When you assign subsequent
people, the behaviour is the same: the work stays constant and the duration
decreases. If there are multiple people assigned to a fixed work task then the
cost of that task does not change compared to the single person case (unless
the people are at different hourly rates).

7 Work can be viewed by creating an additional column in the Gantt

chart. To do this, right click on the table and insert column, search for ‘work’.
8 Double click the task to set the properties.
134
In other words, the more people who are assigned to the task, the quicker it
gets done. Use this setting for any activity where many hands make lighter
work.
(2) Fixed units9:
Initially: The duration is constant, so the more people are initially assigned, the
greater the total work. Each person does 8 hr work. Subsequently: The setting
for ‘effort based’ controls what happens when subsequent people are
assigned.
 For effort based the duration now decreases, with work constant. This is
the default for MS Project 2002.
 For not effort based the duration stays constant and the work increases.
This is good for modelling a meeting, where adding more participants
does not result in a shorter meeting. In fact the more people added, the
greater the total amount of work, e.g. a 1d meeting attended by two
people results in 16 hr work.

Many people find this a confusing setting as the system behaviour changes:
initially it behaves as constant duration, but subsequently as constant work.
This task type, unlike fixed duration, WILL accept another calendar. This makes
it useful for scheduling tasks over a weekend or other non-work time, e.g.
curing of concrete. To achieve this, assign a dummy resources (e.g. ‘Cure’) to
the task, and let that resource have the 24 hr calendar. You will have to adjust
the duration (or work) to match.

(3) Fixed duration

Initially: The duration is constant, so the more people are initially assigned, the
greater the total work. Each person does 8 hr work. This behaviour is exactly
like initial fixed units.

Subsequently: The setting for ‘effort based’ controls what happens when
subsequent people are assigned.
 For effort based the duration is constant, and total work is also
constant. The parameter that changes is utilisation: this decreases the
percentage that each person works, e.g. down to 50%.

9The Microsoft definition of fixed units (for what it’s worth) is: “A task in which the assigned units (or

resources) is a fixed value and any changes to the amount of work or the tasks duration dont impact the tasks
units. Units = Work Duration.” (MS Project Help file)

135
  For not effort based the duration is constant, and work increases, e.g. to
16 hr, with utilisation staying at 100%. This is useful to model meetings.

IT may be important to note that Fixed duration events always take the default
project calendar, i.e. you cannot make your resources work over a weekend at
all (MS Project 98), or without splitting the task (MS Project 2002). This
happens even if they have the 24 hr calendar.

Here is a summary of the main differences:

Initial effect on Subsequent assignment of Initial effect on

assigning one person one person (after one is assigning two people10
already assigned)
work duration work duration work duration
Fixed work Initially Initially constant at halved: constant at halved:
(always effort 0hr, 1d, 8hr decreases to 8hr changes
based) changes to remains 0.5 d to 0.5d
Fixed units 8 hr 1d doubles: constant
(effort based) changes to at 1d
Fixed units doubles: constant at 16 hr
(NOT effort increases to 1d
based) 16 hr
Fixed duration total
(effort driven) constant at
8 hr but
spreads:
50% A, 50%
B
Fixed duration doubles:
(NOT effort increases to
driven) 16 hr
(everyone
at 100%)

Material cost
Most projects consume materials. For example, a civil engineering project to
build a road will need materials of bitumen, crushed stone etc. Materials are
consumed in the project, which means they are used up and have negligible
salvage value. Once that road is built, there is no value in digging it up and
reselling the bitumen and stone. Labour is similar: once spent it cannot be
recovered. Generally materials are consumed progressively, and are available

10To see this effect you may have to delete the task, or at least unassign all the resources.

136
in small units. For example concrete (17.5 MPa) costs about NZ$170 per cubic
metre delivered (2007 prices), and a project could call for different units to be
delivered on various days. By comparison capital items are single large
expenses and the resulting asset can sometimes be reused for other projects.
FIXED MATERIAL USAGE
One option is 'fixed' material usage, which means that you will specify how
much of the material is to be used on a particular task.
For example, if 10 tons of concrete were required for a
task called 'pour concrete', then you would first set up
'concrete' as a type of material resource and then assign
10 units to the task. Here is how you do it: #1 open the
resource sheet, add a new entry called "Concrete",
change the 'type' from 'work' to material, add a material
label of 'ton', and enter $45 in the 'std. rate' column. #2
Then change to the Gantt view, select the task and open
the 'assign resources', select 'Concrete' and enter '10'
into the units. Your Gantt chart should now show
'Concrete[10 ton]' next to this task.
You only enter how much of the material you want assigned to this task. You
don't need to enter the units again as these were given in the resource sheet.
You can now assign the same material to other tasks, e.g. 7 ton to make car-
parks.

VARIABLE MATERIAL USAGE

Another option is 'variable' material usage, which means that the use of the
material depends on time.
For example, if timber was used at the rate of 20 metres
per week on a task called 'build structure', then set this
up in the resource sheet and then assign it to the task.
You would do it like this: #1 open the resource sheet, add
a new entry called 'Timber', change the 'type' from 'work'
to material, add a material label of 'metre', and enter $5
in the 'std. rate' column. #2 Then change to the Gantt
view, select the task and open the 'assign resources',
select 'Timber' and enter '20/week' into the units. Your
Gantt chart should now show 'Timber[20 metres/wk]'
next to this task.
You enter how much of the material you want assigned to this task, a slash '/'
and the time rate (day, week, month etc.). You don't need to enter the volume
units again as these were given in the resource sheet. You can now assign the
same material to other tasks, even using a different rate (e.g. 2 metre/day).

137
Capital or fixed cost
Many projects require large lump-sum purchases of plant, equipment or
software. For example a civil firm may need to purchase a barge to lay a
sewage ocean outfall. Likewise a factory automation project will need
transducers, motors, actuators, and programmable logic controllers. A design
project will need computer aided design (CAD) software. Generally a capital
cost has some salvage value: if the project fails then the equipment can be
sold.

Fixed costs are those costs that are fixed, regardless of the duration of the
task. They could include the materials cost for building a house, or the salaries
of support staff, or capital plant and equipment.

Fixed costs are set in <menu> View/Table/Cost. This provides a Gantt chart
with cost columns, one of which is for Fixed costs. Costs may be entered
directly into this column. Note that resource costs do not show in the table, as
they are calculated in the background from the task durations and the
resource rates. However they will show in the total cost.

To apply fixed costs, use View/Table/Cost and enter total monetary value into
the fixed cost column for the relevant task. This is generally the simplest way.
For capital costs, e.g. air conditioning plant for a building, this is really the best
way to enter the cost.

You can also enter the cost of other materials in here too, providing that you
can estimate the total cost of that consumable. For example, the total cost of
timber for a building can be entered as one fixed cost. Regardless of how long
or short the project takes, the timber cost is constant.

Fixed costs can be limiting though, as you cannot put multiple fixed costs onto
a task, except as a total, and there is no place to add any text describing how
that total was derived. Also, if the material usage depends on time, then fixed
cost will not automatically adjust if the duration changes. For more flexibility in
how costs are assigned, you can use 'material resources instead'.

TIP: To get the total project cost, make sure that you have a WBS with a
single item at the very top (i.e. the whole project may be shrunk to one
activity). The total cost will then show for that activity.

138
If a sub-contractor gives you a price for performing some task, e.g. one cost for
an Electrician plus materials for wiring a shed, how would you enter this in
your project?
 Resource hourly rate?
 Fixed cost?
 Resource cost per use?
Answer: there is no fixed solution. Some materials are bought by the project
manager in bulk and consumed progressively. In this case they can either be
accommodated as fixed costs or they can be treated as a material resource.
However, if the material cost is built into the price that an independent sub-
contractor quotes, then it is better to treat the total quotation as a fixed cost.

SUBCONTRACTOR COST
The construction industry makes extensive use of sub-contractors. For
example, the relatively simple project of building a house requires other
specialized people: architectural draughtsman, electrician, plumber, roofer,
carpet layer, etc. As the term suggests, subcontractors have a contract to do a
part of the project. Most commercial projects use subcontractors to some
extent, because it is an easy way to bring specialized skills to the project (recall
that projects generally have a degree of novelty). It is generally easier, more
reliable and quicker to subcontract the specialized work, than develop the in-
house capability for it. (The exception is where the firm intends to grow
capability in this specialized area). The cost of a subcontractor can often be
included as a fixed cost, similar to a capital cost.

Subcontractors can be cheaper than doing it in-house, especially if the

subcontractor uses staff with lower labour rates or has access to cheaper
materials than the project manager. Furthermore, subcontractors may have
more staff, more experience and thus better problem-solving skills. However,
subcontractors have their own overheads to cover, and they also carry much of
the risk of project failure, and this can increase their costs.

OVERHEAD COSTS
The overheads are the other costs to running the business, like the project
manager’s salary, the rental of office premises, director’s payments, etc. These
costs exist even if the organisation does no work. Generally a project plan is
used to determine the direct cost of only the project, including the resources it
needs. To cover overheads, the firm will they usually add an additional cost, a
mark-up, as a percentage of the project cost. This larger price will then be
139
quoted to the client. The PMBOK refers to cross-cutting or integration tasks,
and while include the project management function itself, they don’t generally
include overheads.

How do you assign the costs of a project office to the project? The problem is
that often there are costs, e.g. of the project manager, even if there are no
tasks running at a particular time. Assigning a project manager to every task on
the project is not a robust solution as it does not cover the gaps, and often
there are parallel tasks which would get counted twice in the costing.

Likewise, there might be other staff, e.g. design engineers, who are fully
assigned to the project, but do not have explicit tasks at all times on the Gantt
chart. Project management will tend to under-estimate these costs, because it
will only include cost when the person has a task.

One solution is to create a task that takes the full duration of the project, and
assign the costs to it. However, this is not an ideal solution as the duration
needs to be adjusted manually.

My suggestion is to create a resource called 'Project Office', give it an hourly

rate (e.g. based on a 40 hr week) which covers the administrative costs and the
salaries of any permanent staff. Then make sure that there is a top level
summary for the entire project (all tasks should nest inside this summary).
Finally, assign this resource to the summary task. This will put the project office
costs once onto the project, and the value will update if the project duration
changes. This is the best solution I have found. The only disadvantage is that
the cost is not explicitly and separately displayed in View/Table/Cost, though it
still used in calculating the total project cost.

If you are going to follow the above solution, then I also suggest that you
create a resource called ‘project manager’ with zero hourly rate (the rate is
already included in that for ‘project office’). In this way you can assign the
person to some specific tasks, and still keep the costing accurate (if you were
to assign ‘project office’ to the summary as well as specific tasks, then the
costs would be counted twice).

With a little effort (double-click in the white space of the Gantt chart) it is
possible to customize the summary bar so that it does show the resource name
(by default summary bars do not display resources, even if they have been
applied).
140
 estimate of
task duration
(see Pm-1-3)
Determine
Availability of
availability of resources
resources (2)
Resources:
people, plant,
materials

Timing
Equipment details for
needs, specialist resource
services, usage
subcontractors,
consumables Allocate tasks to Task
resources (3) allocation
Charter (project
work breakdown
authorisation)
structure and
tasks (see Pm-1-
2)

Obtain access to Authority

resources over Project
(1) resources management
software to
allocate
resources

workloads must
be reasonable, or
at least agreed

Rework
Holidays and
project plan if
other non-
necessary
work days
Conflicting (see Pm-1)
resource
requirements of
other projects
Check workload
Sequence, (4)
schedule,
dependencies Feasible
between tasks workload/
(see Pm-1-4) utilisation of
resources
manual and
computer
assisted
enterprise
methods

Determine
Bill of
quantities of materials
materials (5)

Determine cost resource

(6) sheet, costs

Copyright Dirk Pons . File version: VisioDocument. Sheet: 15. Printed: 18 May, 2009

Allocate resources (Pm-1-5)

141
Crashing the project
Crashing is the allocation of additional resources to activities so that they can
be completed sooner. Crashing may avoid penalties for late completion, and it
also decreases overheads. However crashing also adds cost, which needs to be
anticipated and provided for. The activities on the critical path benefit the
most from being crashed as they determine project duration. Once an activity
is crashed, so other activities will then become critical in turn.

To crash an activity, allocate more resources to it. In MS Project:

 Select the ‘assign resources’ button on the top tool bar.
 Assign additional resources. They may be part or full-time.
 If you are having unexpected results when assigning part time staff, it
may be necessary to un-assign and then reassign the staff for those
tasks.

The total work is still the same, but since more resources are doing it, the
duration decreases. Consequently other tasks may come onto the critical path.
Sometimes the addition of more resources also means that some tasks that
were in series (because they were done by the same person) can now be done
in parallel.

The software does not take into account the additional overhead of managing
the multiple resources, i.e. it assumes resources are deployed with perfect
efficiency. If this is not the case then you might need to add another task for
managing the resources.

Load levelling: Balancing workload

Project plans lack robustness if the workload is not checked. Workload refers
to the utilisation of resources. Workload is easily obtained for all resources. In
MS Project: Use the ‘Resource graph’ on the side tool bar. Or use <menu>
View/Resource graph. This shows a graph of the use, for each person/resource.

142
Resource graph shows when a person is overworked, but does not identify the
actual tasks that contribute. For this information the ‘resource usage’ view
would be more helpful.

All usage over 100% is a cause for concern. It may be achievable in the short
term, but it is not sustainable long term, and there can be serious
consequences on staff morale, and achievement of project objectives. When
staff are paid overtime, then over-allocation may be more palatable, but it
would be unwise to assume that everyone who is eligible for over-time wages
necessarily wants to work those hours.

In many projects there are staff on salary, who do not have overtime
provisions. Poorly configured projects can put a lot of stress on them, for little
reward. No-one wants to work for a project manager who imposes unrealistic
expectations on others or fails to compensate them in some way for demands
beyond the call of duty.

What is the solution? The solution is that the project manager has to level the
load (load levelling). There are several ways to level an overload:
 reschedule activities, which for overload invariably means delaying them
 lengthening tasks
 adding more resources to a task
These changes will add both COST and TIME to the project. While this might
seem undesirable, it needs to be noted that a project plan with excessive
workload is unrealistic and should not be used as the benchmark.

The Figure shows the resource graph for ‘Arthur’ after levelling. His workload
has not been entirely levelled, as the ‘Consult focus group’ and ‘Do detailed
design’ overlap. Perhaps an adequate solution might be to excuse him from

143
some of the ‘Do detailed design’ as the ‘Consult focus group’ task is of short
duration. This type of decision will have to be made on a case-by-case basis.

Resource usage graph, for ‘Arthur’ after levelling. His workload has not been
entirely levelled, as the ‘Consult focus group’ and ‘Do detailed design’ overlap.
Perhaps an adequate solution might be to excuse him from some of the ‘Do
detailed design’ as the ‘Consult focus group’ task is of short duration. This type
of decision will have to be made on a case-by-case basis.

The following Figures show the sequence of effects on the project plan.

Project plan showing critical path. The tasks in red are worth trying to
compress, as this will shorten overall project duration.

144
Project plan after accelerating some critical tasks. Arthur has been allocated to
assist with ‘Do detailed design’. Consequently this task has shortened, and the
whole project is also shortened. Other tasks have now come onto the critical
path. Unfortunately Arthur is now badly overworked, though that is not
apparent from the Gantt chart. There are also some other people, like Kim, who
are overworked.

Project plan after leveling. Everyone’s workload is now better, though perhaps
still slightly imperfect. The project has now lengthened again. Also, the critical
path has changed again.

Managers have a temptation to get irritated about all this, and blame the staff
for being unwilling to work the extra hours, or accuse the project manager of
145
paralysis-by-analysis. These are invalid charges, because what this really shows
is that this particular project was never going to be feasible to achieve within
the original constraints of time and available resources. It was doomed to fail
anyway. It’s just that we have been able to anticipate it beforehand, while
there is still time to consider treatment, rather than deep into the project
when the costs are already partially sunk. To make this project feasible it will
be necessary to relax some of the constraints: accept a lower quality product;
accept that it will take longer; or allocate greater budget to staffing. After all, if
there is a time-value to getting this project done fast, then some of that
financial benefit needs to go back into the budget for the project. It’s a cost of
doing business.

It’s like a jet engine: if you want more power from the turbine then you need
to compress the air. In which case you have to accept that the compressor is
going to require a substantial part of the turbine’s power.

Load levelling also increases the utilisation of a resource so that there is less
idle time. Project management software assumes that if a resource (person) is
not being used, then there is no cost to the project. This is not a problem
when contractors are paid by the hour or by the task completion. However
when there are staff who are dedicated to the project then their slack time is
not costed correctly. In such cases it may be better to put their salary bill as a
separate project overhead regardless of the actual utilisation (create a dummy
activity and apply the cost to it).
Implementing costs in MS Project software
There are two groups of costs that the software monitors: resource costs
(labour + material), and fixed costs. Total cost is calculated as:

Total Cost = Fixed Cost + Resource Cost

146
Total Cost = Fixed Cost + Resource Cost
Total cost is Fixed Cost: additional
computed by the costs for typically
software. The total equipment or bulk
cost for the whole materials. This amount is
project is only shown entered by you as
on the Gantt chart if project manager. Use the
you have a summary column under
task for the whole view/table/cost. The cost
project. is the same however
long the task takes. This
is the only cost you can
enter in this view.
The software calculates this
(see below) from the labour
rate and the duration.
Resource Cost is not explicitly
shown in standard views as it is
implied in ‘Total Cost’.
Where
Resource Cost =
(Labour rate x duration)
+ Once-off costs, e.g. delivery
+ call-out cost
+ (material rate x material
usage)

You set the material rate in the

Resource Sheet and the usage
in the Resource Usage table.

You set the Labour rate in the

Resource Sheet and the
duration in the Gantt Chart

TIP: A special view is available for entering and displaying costs (<view/Gantt
chart> <view/table/cost>). It’s also important to note that you can only enter
the fixed cost in this view. You should not attempt to overwrite the total cost,
but rather let the software do the calculation for you. The resource cost is
automatically included in the total cost. You have control over the resource
cost, by changing hourly rates and task duration, using other views.

147
Overall view of different types of cost, for MS Project.

Example: Children's play gym

This hypothetical project is to build a Children's play gym in a park for a
property developer. The project organisation has some experience in building
decks and other structures with wooden poles, and seeks to extend its
capabilities to this new type of project.
GANTT CHART

148
WBS for play gym project

Main features of the WBS are the provision of some basic interaction with the
client (this could be further detailed, especially the contract administration), a
design phase that includes early concept design, detailed design (e.g. solid
modeling) and drawings, permits and compliance process (simplified), and the
construction. Most of the scheduling is series (FS links), though there is
provision for some overlapping of the design tasks, among others.

RESOURCE SHEET
A simple set of resources has been identified.

Resource sheet

Some comments to help interpret the resource sheet:

149
  Most of the people have an hourly rate assigned, but a few have zero
cost (e.g. client, council). There is no cost to ‘Helen's Landscaping’
because she is instead offering a fixed sum, which appears in the
financial report.
 The ‘Designer’ is overworked, and this is because of overlapping tasks.
We would have to fix this, either by rescheduling tasks, changing
allocation, or employing more design staff, but this is not attempted
here.
 The ‘construction team’ have 5 people. The hourly rate given is for the
set of people.
 ‘Concrete’ has been given the type of material (using the drop-down
box), and I have entered the units of m^3. The entered rate of $170
assumes those same units. Similarly for ‘poles’.
FINANCES
Adding labour cost is straightforward and automatic: simply assign people to
tasks, and set the hourly rates. The software will do the rest.

Material costs are also easily accommodated (providing they have first been
set up as material in the resource sheet). In the Gantt chart, simply assign the
material, but enter the quantity required. Both labour and materials can be
assigned to the task (assigning materials does not shorten the task duration,
though more labour would).

150
The material of ‘concrete’ is being assigned to task ‘Concrete poles into
ground’, and 6 units (m^3) are required. The ‘Construction Team’ is also
required on this task.

Change to cost view (view/table/cost) and enter the fixed costs. Here the fixed
costs included the consent process, additional timber and hardware other than
poles, paint, protective mats, and a landscaping sub-contract. Note that
although there is also a structural engineer sub-contract (#12), it is an hourly
rate not a fixed price.

This shows is that labour and materials can be treated in various ways,
depending on convenience. It’s a good idea for the project manager to
document those assumptions in a notebook or on the project plan (there is a
comments field available for each task) as an aid to memory.

151
Total costs for project

Thanks to the work breakdown structure, the project now has cost summaries
at each level. The most important of these is the top level, at which it is shown
that the project cost is $49,350. Any changes to durations or hourly rates will
immediately and automatically adjust this total. To this the overheads could
now be added, and a quotation sent to the client. Once the client accepts the
quotation, then save a baseline for future comparison because projects never
track exactly according to plan and the baseline will show the difference
(tools/tracking/set baseline).

152
.6 More advanced scheduling
This is an advanced topic.

Estimate nominal task durations (1)

The primary activity is to estimate nominal task durations (1). Typical inputs
are estimates by team members and the project manager. The mechanism for
making the estimates is presumably experience of the individual on related
past projects. If experience is high then this can be simple, quick, and reliable,
but may be problematic when the project is novel and there is no experience
on which to base estimates.

Unfortunately, even experience does not necessarily ensure reliable estimates.

There are a number of biases that can intrude and compromise the accuracy of
the estimates. The is a well known familiarity bias, in which the most recent or
most memorable information dominates [26].

Other sources of error may be pressure to meet overall schedule requirements

or strategic objectives. Such pressures were largely to blame for the loss of
space shuttle Columbia, since the project plans had no slack and mission
managers were thus unwilling to admit contrary technical evidence (foam
strikes) for fear of compromising the imposed schedule [27].

In most projects a simple deterministic estimate of nominal task duration is all

that is applied. Such an estimate carries no indication of uncertainty, but that
seems sufficient for many projects. That adequacy may be because the project
is simple, or the schedule consequences minor, or that it is too hard to
estimate the uncertainties.

153
154
Estimate task duration using group (3)
Projects in which it is desired to have a better understanding of the risk in
duration can make use of multiple rather than single estimates. A group of
experts each give their own opinion of the duration of the task, and these are
combined to produce a more robust estimate of task duration. In principle this
appears to be a good idea. However, the difficulty is in finding a suitable
mechanism to combine the multiple different opinions.

The input opinion of each individual will generally be a subjective value

judgement [28-30], incorporating assumptions taken for granted [31]. Systems
based on voting, weighting, and consensus are potential candidates. However,
they all have significant detriments. Voting is simple, but vulnerable to
groupthink [32, p302]. The characteristic feature of engineering applications of
groupthink is intrusion of management objectives to the point of
overwhelming the dissenting alternative considerations. Weighting is a popular
mechanism, but has major difficulties in determining the weights without
resorting to subjectivity by a judge. Consensus is good, but may not be
achievable. The model of Bley et al addresses one aspect of this problem,
namely the collation of expert risk assessments [33]. Another related
development, for engineering decision making, is that of Ullman and
collaborators [34, 35].

Determine stochastic uncertainty in schedule (2)

An alternative approach is to determine the stochastic uncertainty in
durations, i.e. represent it with probability. This is a popular strategy for more
sophisticated projects, and there are several mechanisms for achieving these
outcomes. However, the methods do have detriments. This activity is further
analysed below.

Determine alternative work breakdown structure and links (4)

Conventional project management is highly singular about the work
breakdown structure and the links. Very seldom are alternative plans
constructed (4) to explore other ways the project might unfold. There is a
strong fixation by project managers on one project approach, and this
introduces risk of project failure. This activity is further analysed below.
155
.7 Apply stochastic methods to estimate duration
This is an advanced topic.
There are several methods of applying a stochastic2 approach to duration [36] ,
and these are shown in Figure Pm-1-3-2. These methods are mainly applied
during the initial planning stage, though they can also be used during
deployment to make new predictions for any residual work.

Estimate limits
The first activity is to estimate the upper and lower limits of duration (1), for
each task. The nominal duration would also be set if not done previously. The
output is then the worst, typical and best estimates for duration. Conventional
project management theory then proceeds to use these estimates, as shown
below. However, there are risks that are introduced at this estimating stage, so
serious that all the downstream methods are compromised. There are two
parts to the risk: the unreliability of the estimates, and the ambiguous
interpretation, and these are seldom explicitly identified in project
management practice.

2
Also called random variability, or probabilistic uncertainty, or aleatory uncertainty.

156
Summary diagram

UNRELIABLE ESTIMATES

157
Estimates are generally unreliable because data on which to base the
estimates are often unavailable. Consequently, the estimates are often nothing
more than guesses, and just as likely to be inspired by emotional state of mind,
personal objectives, personal attitudes to risk, and organisational politics as by
experience and rationality. Furthermore, the estimates are based on the
protagonist’s perceptions of probability, which is challenging to many
especially when trying to assess extreme events that have never been actually
experienced. Estimating extreme values is also vulnerable to several biasses:
anchoring/centering (fixate on the nominal value and unable to anticipate the
full range that could be possible), representativeness (fixation on a value that
is familiar, e.g. the time taken in the last project), and optimism/pessimism
[26].

Estimates are generally also ambiguous. What exactly is a minimum or

maximum value anyway? Is it the typically expected value, or the maximum
conceivable? The interpretation significantly affects the overall schedule
variability. Further trouble comes when multiple people, each with their own
interpretation, are involved with providing duration estimates. This type of
problem has been identified in the risk assessment literature [26, 37], where it
is generally accepted that minimum and maximum values are weak (though
appropriate in non-critical areas), but are highly problematic when external
scrutiny and public participation are involved because they are hard to defend.
Some have suggested that a better way is to assign a cumulative probability to
each estimate, e.g. 99% [38, p 394]. While this might be ideal, it is difficult if
not impossible to achieve with any reliability. People cannot estimate the
magnitude of such an extreme event, one seldom actually encountered, with
anything but a personal guess. Nor is it easy for people to distinguish fine
graduations of likelihood, e.g. 99% vs 99.5%, but unfortunately it is precisely at
the tails of a distribution that such accuracy is most important.

Fit distribution (2)

Having made the necessary estimates, with their inherent uncertainties, the
locus of effort proceeds to fit a distribution (2) to the (three) points. There are
several options here, depending mainly on which probabilistic tool will be used
downstream. For PERT, a beta distribution is fitted to the points, giving the
moments of the distribution (see below). For fuzzy theory, a simple triangular
membership function (analogous to a probability distribution) is used, or
perhaps a trapezoidal shape. For full probabilistic computation a normal or any
other distribution can be used.
158
Apply PERT (3)

159
The most common probabilistic method is the project evaluation and review
technique (PERT) (3). However, it is not a full probabilistic method since it
combines the three estimates of duration into a single time estimate, the
mean. PERT then determines the project completion date by summing all the
newly calculated mean durations for all tasks on the critical path. It relies on
the central limit theory (CLT), which assumes task independence, and permits
the means to be summed. The CLT also permits the standard deviation to be
determined for the total project duration, as the square root of the sum of the
individual variances.3 For this it is necessary to determine the standard
deviation of each task duration. PERT does this by fitting a beta distribution to
the three estimates. The worst and best case estimates correspond to the end
bounds of the beta, not the 99% cumulative probability as is sometimes
believed [38], and the nominal estimate corresponds to the mode. Selection of
the beta is simply for convenience, since it is bounded on both sides (unlike the
normal), and its standard deviation is easily determined from the end points
(again unlike the normal). However, the CLT would permit any approximately
normal shaped distribution to be used - it only needs the mean and standard
deviation, i.e. the moments of whatever distribution is used. PERT has become
something of an ingrained habit in project management, one that is used
without question, and the limitations of which tend to be overlooked. There
are more powerful methods for coping with stochastic uncertainty in duration,
discussed below.

Software, e.g. Microsoft Project®, may be used to perform PERT calculations,

as shown below. These show the three estimates, the resulting calculated
duration, and the Gantt chart. However, the PERT implementation in MS
Project® is lightweight, since it only uses the mean data, not the variances, and
therefore cannot show the spread in duration. To achieve this, it is necessary
to perform an external calculation of project standard deviation, e.g. with a
spreadsheet, the results of which are shown in below.

3
‘Variance’ in this case refers to the statistical term for dispersion of the distribution, i.e. the square
of the standard deviation, and not to the project management term which is difference between planned and
actual outcomes e.g. as used in MS Project.

160
PERT analysis. Three estimates are required for each task, excluding summary
tasks (bold): the optimistic (best case), expected (nominal), and pessimistic
(worst case). The software, in this case MS Project®, then calculates the most
likely mean ‘Duration’, using weighting factors provided by the user.

Gantt chart for PERT analysis. Calculated mean durations have been inserted by
the software in place of the nominal values first provided (see ‘expected dur.’ in
previous figure). The project duration has become longer than before, because
individual task durations have lengthened, in turn due to the effect of the
pessimistic estimates.

PERT has several limitations. One is that the critical path is fixed. PERT, at least
that used in common software like MS Project ®, is unable to accommodate
the fact that the critical path itself may change, i.e. other tasks may come onto
(off) the critical path as durations adjust. Furthermore, the PERT algorithm,
which uses the beta distribution, is only an approximate probabilistic
computation method.4 It gives some indication of the central tendency (mean)

4
Three estimates are used in PERT to determine a mean expected time using a beta distribution in
which the mean is typically t = (a+4b+c)/6 where a, b, c are the minimum, most likely, and maximum times

161
and dispersion (standard deviation), but uses moment methods which are
approximate. Nor is there any underlying theoretical justification for using the
beta rather than any other distribution, except convenience for the analyst. In
many ways this does not need to be a problem, given the large uncertainties
listed above. However, if the data support it, and a precision analysis is
required for duration, then the following methods are superior.

PERT analysis for project variance, calculated in a spreadsheet. The project

standard deviation (bottom right) may then be used to create a normal
distribution and determine likelihood of various scenarios.

Apply possibilistic method (5)

Fuzzy theory (5) may be applied to determine uncertainty in project duration.
This feature is unavailable in software such as MS Project®, and would have to
be done with other special tools. Fuzzy theory is based on possibility theory as
opposed to probability theory.

A fuzzy set represents membership across an interval: it ‘records the possibility

that a given value could be in the set, and consequently many range variables
may all have a possibility of unity. By comparison, a probability density instead
has unit area under the curve’ [39, p532]. Fuzzy sets are usually triangular or
trapezoidal, as uniform (rectangular) sets tend to misbehave.

Fuzzy theory has benefits but also some detriments. The benefits are that
indecision (‘imprecision’) about the precise value of a parameter (e.g.
duration) is arguably better represented by a fuzzy set of possibilities (hence
possibilistic) rather than a probability distribution. This is because probability
distributions are strictly only for representing frequency of random events, and

respectively. Values other than '4' and '6' are possible (Vose, 1996). The mean expected time is then used in
the network as a deterministic value. The variance for each activity is v = ((c-a)/6)^2 for the beta distribution.
The total project time has a normal distribution (as per the central limit theorem) with variance given by the
sum of the variances of the activities on the critical path (Taylor, 1999, p463).

162
indecision is not necessarily random. The detriment of fuzzy theory is that
there is no underlying theoretical reason why uncertain intervals should have
the shapes used, such as triangular or trapezoidal. These two are used for
convenience (the normal distribution is irrelevant in fuzzy theory). Nor is fuzzy
theory able to cope with all types of distributions, e.g. it misbehaves with
uniform and multimodal distributions. By comparison the probabilistic
approaches are not limited in the distributions they accept, and they have the
added advantage that there can in some situations be strong underlying
validity for the normal distribution.

Nonetheless fuzzy theory has been applied extensively in engineering and

decision making, where it is noted that ‘the Fuzzy cut set approach is possibly
the method of choice where the inputs are opinions rather than
sampled/estimated frequencies, rapid assessment is required, and the precise
shape of the uncertainty is not needed’ [39, p536]. There are many examples
of fuzzy theory being applied to project management [40]. Project
management software would do well to abandon its fixation with PERT, and
instead adopt fuzzy theory.

DSI-fuzzy used the above acyclic computation graph to determine the fuzzy
project duration.

For example, the project plan can be analysed with fuzzy cut set theory, as
follows. First, the critical path is identified as activities 4, 5, 10, 11, 13, 14. Next,
fuzzy sets are asserted for each of these variables. For ease of comparison,
beta distributions were used with the same parameters are in Figure 1, and
these distributions were then fuzzified, i.e. scaled so that the likelihood of the

163
 mode was unity. Then the total project duration was calculated as the sum of
the durations on the above critical path. The DSI-fuzzy engine was used [39].
The graph of the model and the results for project duration follow.

Uncertainty in Project duration fuzzy

1
Probability

0
0E+0 1E+1 2E+1 3E+1 4E+1 5E+1 6E+1 7E+1 8E+1
Project duration fuzzy

Fuzzy set for total project duration. The shape is superficially similar to that
obtained with a probabilistic method. Mean value is 33.6 days. Standard
deviation is not computable. The mode (position of the peak likelihood of one)
is 32 days, which is exactly the same as obtained with the deterministic
calculation – an appealing aspect of fuzzy theory.

Apply probabilistic method (6)

The most theoretically robust way to determine stochastic uncertainty,
assuming the variables are random, is one of the probabilistic methods. There
are actually three, described below, but one dominates.

The mathematically precise method is the algebra of random variables [41, 42].
This becomes impractically complex for all but the addition of normal
distributions. Within these limitations it could be applied to determine project
duration, though applications are generally financial [43].

The most popular practical method is Monte Carlo simulation. It involves

assigning a full probability distribution (not just the moments as in PERT) to
each uncertain variable, e.g. task duration. The simulation then takes a single
random sample from each distribution, and determines the total project
duration. If programmed accordingly, the algorithm can also determine the
new critical path. The process is repeated numerous times to build up a
histogram for the total project duration. There have been many research
applications [44]. The method is embodied in software, e.g. @Risk®,

164
Analytica®. The project plan shown in Figure 2 can be analysed with Monte
Carlo simulation. As before, the critical path is 4, 5, 10, 11, 13, 14, and beta
distributions were asserted as per Figure 1. Then the total project duration was
calculated as the sum of the durations on the above critical path. The @Risk®
software was used, and the spreadsheet model and results for project duration
follow.

Model for project duration as represented in a spreadsheet using @Risk®.

Monte Carlo simulation result for total project duration, using @Risk®. Note the
characteristic roughness to distributions produced with the Monte Carlo
method: this is an artefact of the random sampling process. Mean value is 36.5
days. Many other statistics are available, including the mode (35.3 d).

Importantly, Monte Carlo does not have to assume independence of the

variables. For example, if bad weather affects more than one task, then that
can be accommodated, whereas PERT does not. Also important is the ability to
dynamically determine the critical path. Hence its popularity and widespread
application [26, 45-47]. However, these advanced features require special
attention by the analyst, perhaps even software programming. Detriments of

165
 Monte Carlo simulation are that probability distributions are not necessarily a
valid way of expressing uncertainty in task duration (see fuzzy theory above).
Recall also the estimating errors above. So, though it presents impressively
accurate results, the relevance is not automatic.

The third probabilistic method is based on discrete combinatorial methods

[48]. It is a relatively obscure mechanism, but has been applied to engineering
design [39, 49] and has advantages over Monte Carlo in some features. The
project plan shown in Figure 2 can be analysed with this method, using the DSI
software [39]. As before, the critical path is 4, 5, 10, 11, 13, 14, and beta
distributions were asserted. Then the total project duration was calculated as
the sum of the durations on the above critical path. The DSI model and the
results for project duration follow.

Uncertainty in Project duration

0.05
0.045
0.04
0.035
Probability

0.03
0.025
0.02
0.015
0.01
0.005
0
2.5E+1 3E+1 3.5E+1 4E+1 4.5E+1
Project duration

Result for total project duration, using controlled interval simulation with DSI.
Note the characteristic smoothness of the distribution produced with this
method. Mean value is 36.0 days.

166
Acyclic computation graph used by DSI to determine project duration.

Summary: stochastic uncertainty in duration

Several methods have been shown for simulating the stochastic uncertainty in
project duration. Each has benefits and detriments. The results for each
method, for the sample project being analysed, were projected onto the same
axis to facilitate comparison. The results are shown below.

167
Comparison of multiple methods of estimating duration.

This shows project durations as determined from the critical path:

 The Deterministic estimate (32d) is the typical method used in project
management. It is simple and easy to use, but fails to show duration risk.
 The best-worst case project interval (16-73 d) is readily determined, e.g.
by MS Project. However, it is practically worthless as it fails to show any
likelihood.
 The fuzzy theory estimate (32 d mode) is effectively a shaped interval,
and is therefore much superior to a best-worse case interval. The fuzzy
result covers the full range of the best-worse case interval, but has
lighter tails. Nonetheless, fuzzy theory over represents the risk of
extreme outcomes (see the greater likelihood in the upper and lower
tails), at least compared to the probabilistic methods.
 PERT (36.17 d mean) produces a reasonable probabilistic estimate, but it
under represents the risk of extreme outcomes (lighter tails than full
probabilistic methods). This would seem a disadvantage.
 Monte Carlo (36.5 d mean) produces a probabilistic result, but this is
partly obscured by large random artefacts. This is problematic if the

168
 likelihood of extreme events is being investigated, since Monte Carlo will
not reliably detect these, unless the number of iterations is substantially
increased. The mean is also variable from run to run.
 DSI (36.0 d mean) also produces a probabilistic result. Benefits are a
smooth curve, and good representation from the upper and lower tails
for less computational effort than Monte Carlo.

169
6 Project control and monitoring
CONTROL
A benefit, perhaps even a unique feature, of the project management
methodology is its ability to both plan the project, and management its
execution. The latter is called monitoring and control.

.1 Work streams for executing a project

The main activities are shown in Figure Pm-3, as Manage the project team (1),
Perform the project work (2), Measure progress (monitor) (3), and Handover
deliverables (6). During the process it is usually also necessary to
Communicate with stakeholders (5). If things don't go according to plan then it
may be necessary to have redefine the project (4).

MANAGE THE PROJECT TEAM (1)

The management of teams is part of the psychology field, and models like
those of Tuckman [50] are typically applied. However, that literature applies to
teams in general, which are usually enduring, whereas project teams are
transient. Further work is needed to determine whether teams should be
managed differently in the project context. I discuss some of the possible
motivational factors in the paper on closure. This is an area of ongoing
research, and interested postgraduate students are welcome to discuss this
further.

PERFORM THE PROJECT WORK (2)

Every project is different, so the way the work is performed is variable. The
productivity of project workers is determined by several factors including
motivation. There is not much other project management theory or practice-
guidelines on this area.

MEASURE PROGRESS (MONITOR) (3)

The measurement of progress is a well-developed methodology in project
management.

170
SUMMARY DIAGRAM
risk: change to
project scope
from client

Major redefinition
Changed
of project project plan
(4: Pm-3-4)

key performance criteria or

specification (descriptive or Modified
quantitative), i.e. quality (see project
Pm-1-1) objectives or
Communicate scope
with
project plan, Gantt chart,
stakeholders (5:
baseline costs, workloads
(responsibilities), time Pm-3-5)
schedule Communication

constraints: unforseen
internal events (planning
mistakes, errors, slip)

contract
constraints: unforseen detriment:
external events (site common mode
conditions, weather, labour failure (rely on
unavailability, etc.) same common
element) Delivery
Financial
dates and
budget
milestones
initiator:
Descriptions
project
of work done
approval

Measure
input: resources Perform the input:
progress Measure of
(labour, project work costs to
progress
materials, plant) date (monitor)
(2: Pm-3-2)
(3: Pm-3-3)
output:
(partially)
completed
system
(functional)
Manage the
Project
project team team
(1: Pm-3-1)

Team
management
methods

satisfied
customer
Handover output: completed Obtain project
deliverables system (functional, benefits
(6: Pm-4-1) on-time, on-budget) (7: Pm-4)
financial profit for
project
organisation
Copyright Dirk Pons . File version: VisioDocument. Sheet: P3. Printed: 3 July, 2009

Execute project
(Pm-3)

171
MAJOR REDEFINITION OF THE PROJECT (4)
There is always a potential that the project does not go according to plan:
perhaps the technology solution is unproductive, or it takes too long or costs
too much, or key staff leave. Or there can be an unexpected break-through,
such as a complete sub-system being now available as a bought-out-item. The
Client’s needs may also change: perhaps the market pressures have changed,
or a simpler solution is now available elsewhere. For any of these reasons it
may be necessary to redefine the project.

HANDOVER DELIVERABLES (6)

This is a minor activity in the overall scheme of work, and of short duration. Yet
it is important since it (a) closes the contracted obligations, and thereby
initiates invoicing, and (b) provides a sense of emotional closure and
satisfaction for all those involved. Consequently, the activity is often done with
some small ceremonies and pleasantries, along with a celebration.

COMMUNICATE WITH STAKEHOLDERS (5)

Part of project management is communication with the people who have some
ownership of the project or its outcomes. A simple model for this is shown in
Figure Pm-3-5, from the perspective of the Project Manager. There are
multiple directions of communications: directors, clients, suppliers, the team
itself. Each of these have different needs for information, and so the Project
Manager needs to provide a various output communication media and
messages.

172
 Business
constraints:
Untruthful,
financial,
deceptive
time
message of
Direct project (3) reassurance

Senior Inform client of

managers developments
Project charter
(authorisation
from superiors,
and business
justification)

Defined
scope of
deliverables

customer Status
feedback reports
Change
requests

Clarify customer Manage project Work instructions

needs Customer’s communications (e.g. Gantt Chart)
(2: Nv-1) need (1: Pm-3-5-1) and corrective
Project
Customer, actions
manager
(client)
Procurement
schedule

technical Sub-
objectives and contracts
importances,
product and
service features

Progress
reports,

Supply materials
(5) Problems:
Materials technical,
Suppliers schedule,
personal
Perform the
project work Project
outcomes
Supply parts (6) (4: Pm-3-2) (deliverables)
Project
Sub- team
components
Contractors deliverables

Copyright Dirk Pons . File version: VisioDocument. Sheet: 35. Printed: 3 July, 2009

Communicate with stakeholders

(Pm-3-5)

173
.2 Overview of monitoring
The usual approach to monitoring is to record the current status of the project
typically through progress meetings, on-line collaboration being supported by
some software. Then progress is assessed relative to the original plan, with
earned value analysis being a typical mechanism (how much should we have
spent by this point in time?). In parallel the variances in project cost and
schedule (time) are determined. Then the project execution is adjusted to
close the gap, based on information about the extent of the deviation from the
plan, and the identity of the tasks concerned. This information is then
summarised and reported.

You should be able to do all these in MS Project:

 Baseline
 Progress % complete
 Tracking Gantt
 Schedule variance
 Find float (slack)
 Cost variance

174
 Feasibility in Redirection of project
technology, staff, (involving decision-
resource, cost making by directors
dimensions and client)
Latest customer
requirements and
expectations (may Redefined
have changed)
Major redefinition project scope
of project (deliverables/
Subjective and strategic (9: Pm-3-4) function,
understanding of purpose. The time, cost)
overall big-picture purpose. The Focus on overall Tweaks to project
customer’s need. What will this execution (involving
venture (project, work) achieve?
purpose internal decision-
What is the outcome that will (1: Pm-3-3-1) making)
constitute acceptance/satisfaction?
(see Pm-1-1) Priorities for what
Check that this really needs to be
venture (project) is achieved and what
still fulfilling the can be give light
purpose, i.e. that treatment
completion would still
satisfy a need

key performance criteria or

specification (descriptive or
quantitative), i.e. quality (see
input: Pm-1-1)
costs to
date

Record current Assess progress

Descriptions Current Measure of
of work done
status project status
relative to plan progress
(3: Pm-3-3-3) (4: Pm-3-3-4)
Milestones
reached,
outputs
Earned value
deliverables Feedback from team
analysis
members during
meeting or electronic
communication
contract

Delivery
Financial
dates and
budget
milestones

Schedule
(Time)
Quantify Variance
Modified project plan, Gantt
variance and Cost chart, workloads
Identify source Variance (responsibilities), time
Adjust project schedule, resources
(5) functional execution to
Variance close the gap
Known tasks (6: Pm-3-3-6) Specific achievable
causing
remedial actions
variance

Report on
Anticipate risks Anticipated Summary of
risks
progress above data
of next stage (7)
(8: Pm-3-3-8)

Copyright Dirk Pons . File version: VisioDocument. Sheet: 33. Printed: 3 July, 2009

Measure progress (monitor)

(Pm-3-3)

175
.3 Reporting progress
Assess progress relative to plan
Standard project management practice uses regular meetings to assess
progress. These have historically been done face-to-face, though on-line
reporting is feasible using software. Meetings typically seek to determine the
degree of completeness of tasks. The information is commonly inserted into
the Gantt chart.
Record current status
The current date is shown as a vertical line in the Gantt chart. All tasks that are
not complete up to that line are behind schedule. When reviewing project
progression it is then possible to concentrate on those activities that are
lagging, especially if they are on the critical path. Project costs are presumed to
occur in proportion to the percent complete.

Gantt chart showing degree of task completion. In this particular version of

software (MS Project®) the completion is shown by a dark bar. Comparison
with the current date (vertical line at 28 May) permits tasks to be quickly
identified where they are behind schedule. (In this case ‘Make models’ is
behind, but ‘Consult focus group’ has been achieved ahead of intended
schedule.)

Completeness is often difficult to estimate precisely. If it is really necessary to

measure the degree completeness accurately, then it may be necessary to
break the task down into subtasks.
Assess progress relative to plan
The important parameters to monitor are technical performance, cost, and
schedule. During project reviews:
 check whether or not forecast costs and financial returns are still
possible,
 assess whether or not the next stage in the project can be proceeded
with,
 consider deviations from technical scope, either from your side, or
raised by the client,
 check that project is still on planned schedule.

176
It is advisable to report risks and failures on schedule, cost, or performance
when the team becomes aware of them. If you hold back the information and
report them late, then you will be criticised for bad faith.
Report on progress
Progress reports vary between organisations. Project managers can expect to
have to deliver verbal and written reports.

CONTENT OF A PROGRESS REPORT

Generally reports include elements such as the following:
 Title: project name, date, names
 Overall project purpose
 Accomplishments: milestones reached
 Soft evidence: photographs of people, work in progress, preliminary CAD
models, etc.
 Current status: % complete, earned value (optional)
 Projections: cost, schedule. A projection is a prediction into the future,
usually to the end of the project. In other words: what is the expected
cost and hand-over date for completion?
 Issues: problems overcome in the last period, unsolved problems, future
risks or uncertainties
 Immediate next activities and priorities for project team
 Implications for managers: any decisions or funding required? Any
change to scope?
 Gantt chart (as attachment).
 Hard evidence (as appendices): investigation reports.
One way to structure a progress report is by the nine knowledge areas of the
PMBOK. An example of this, illustrated with representative data, is shown
below.

THINK OF THE AUDIENCE

For effective Communication:
 Identify the recipient.
o Who will read this?
 Recipient’s Specific Name, or designation.
 Secondary readers who might get hold of
this, e.g. the boss’ superior.
o Why do they want the communication? What is
their need?
 To Make a decision?

177
  To be reassured?
 To Forward it to others?
 To protect themselves?
 Identify your needs
o What do you want out of the communication?
What are your needs? What do you hope they
will do with the report?
 Sit back and bless you?
 Help you make a difficult decision?
 Give you more resources than at present?
 Identify how to meet those needs.
o Identify recipient’s bandwidth
 How much detailed/technical information
can the recipient cope with?
 How knowledgeable is the recipient?
 Engineering knowledge?
 Business knowledge?
 Project management skills?
 How much time does the recipient have
to look at this report?
o What information is needed to meet that need?
o What structure of presentation could best
present that information to the recipient?
 Place relevant information early in the
report.
 Use headings to draw visual attention to
the important information.
o State your needs (if any) clearly and politely. Be
specific.
o Provide hard data in appendices. It’s really
reassuring to see the information, even if the
recipient does not read it.

Always communicate any matter that has implications for the recipient (client,
superior).

Most managers are busy, and therefore they will read the ‘executive
summary’. They may not have time to read the whole report in detail. They will
however be attuned to detecting sign of impending project failure.

178
SAMPLE REPORT

Sample only
Hydra Office Furniture Ltd
PROJECT ‘Lift!’ office chair
Status report: 31 December
A report to the Board of Directors, prepared by Dirk Pons
(Project Manager)
Revision 1.3

Executive summary
 Purpose and scope: The scope of the Lift! project is to design a new office chair and
set up the necessary manufacturing plant.
 Summary of achievements and major milestones met: Factory construction is
complete ahead of schedule, and procurement of plant is also ahead.
 Progress on technical, time, and cost: Technical issues have delayed design, which
will delay the project by 2 wks. The financial variance at this point is $9,100 over
budget. There is opportunity to recover some of this later in the project.
 Current issues: Resolving technical issues with the gas lift spring, expected to be
solved soon.
 Immediate next actions and priorities: The design and market testing are on the
critical path, so the Team will be focusing effort on these areas.

0 Project integration management

The overall progress on this project is tracking to expectations. We have had some technical issues
with the gas lift spring, which have delayed us by 2 wks. However we expect to solve those issues
soon. The factory construction is complete ahead of schedule, and ‘Set up plant’ is also happening
ahead of schedule.

Cumulative list of accomplishments:

 Factory construction is complete

1 Scope
There are no current changes to scope to consider.
Marketing have suggested that the sales in the first year could be higher than originally estimated.
This increases the potential viability of the project but does not affect the execution of the project.
Furthermore, Marketing would like to see the ‘Develop derivative products’ activity occur a year
earlier. We are working on the implications of that request, but tentatively think it will be possible to
put some resource, though not the whole design team, onto starting that activity early. Distribution
and product placement has been raised as work that needs to be done, and this has been referred to
the Sales team as those activities are outside the scope of the present project.

2 Schedule and work plan (Time and WBS)

The following describes the current schedule and effect on major milestones.
The milestone for final sales has slipped slightly (two weeks) due to the design issues raised above.
The effect on the entire project is relatively minor, as shown in the high-level tracking Gantt chart
below. A full print-out is attached.

179
Marketing and Sales have been alerted to the possibility of this delay in First Sales.

3 Cost
Current expenses have been a slight over cost in the construction, but a saving in the equipment.
The financial variance at this point is $9,100 over budget (i.e. compared to baseline). There is
opportunity to recover some of this later in the project.

4 Progress towards technical objectives (Quality)

Any issues on technical specification or difficulties.
Recent accomplishments. These are …
Recent technical findings or reports (attached).

5 Human resources
Any issue on lack of resources or loss of key staff.
Joe Baker (Mechanical Design Engineer) has left the firm. We are currently recruiting a replacement,
and the job description is with Human Resources. The workload has temporarily been taken up by a
contract CAD operator, so there are no direct impacts on the project schedule or cost.

6 Communications
Any significant discussion or feedback from (potential) clients.
Marketing showed early concept drawings of Lift! to some of our existing large buyers and corporate
customers. The feedback is anecdotal but positive.

7 Risks
Any changes to the risk treatment plan, any new risks that have emerged.
Technical design problems was originally identified as a risk, and has indeed caused us some delay as
described above. Fortunately early indications are that it looks like the rest of the technology is not
going to give us any problems, though it will be another month before we will know for certainty.

The risk of Supply chain issues is not something we can finalise yet, but we are nonetheless alert to
the issues. Thus the Design team have been taking particular care to preferentially specify bought-
out components where the provenance is reliable and local.

8 Procurement
Any issues with large capital procurement matter, or issues with contracts, legal problems etc.
Finance have been working on the procurement of the plant and equipment. As some of this is
sourced from overseas, there are currency issues and delivery terms which they are attending to.
Approximately half the capital budget for plant has been committed.

180
.4 Time and Schedule
Variance in project management refers to the difference between actual and
intended time or cost. It does not have the same meaning as in statistics
(where it refers to the dispersion of random variables about the mean).

Schedule variance is deviation from time plan. A tracking Gantt chart shows
the schedule variance (once a baseline has been saved against which to
compare). Variance is straightforward to determine using software, once the
percentage complete values have been entered.
Baseline
The baseline is the original project plan, e.g. as agreed by superiors or the
client, or formally approved revisions thereof. Baseline is a fixed project plan.
It becomes a reference against which the actual project performance may be
assessed. A baseline is useful if there is a contract, quotation, or other
commitment to others on the project deliverables.
Tracking Gantt
Create a baseline when you are finished preparing the project plan. In MS
Project use menu/Tools/Tracking/Save Baseline. To see the changes, use the
format Gantt chart button on the top tool bar, or press Tracking Gantt on the
side bar.

Tracking Gantt chart shows the originally planned project (upper bars, grey),
and the current reality (lower bars, blue) with % complete too. This gives a
quick visual representation of the schedule. In this particular example the
‘Produce Prototype’ activity is now expected to require more time. The effect of

181
this is to prolong the whole project. There was also a delay in starting to
‘Research the market’ but there was enough flexibility (float, slack, see critical
path) in the schedule to accommodate this.

In MS Project it is possible to tabulate the schedule variance: Gantt Chart then

<menu> view/table/Work, or Tracking Gantt then <menu>View/Table/Work.

Critical path
The critical path is that set of tasks, which if any one is delayed, will delay the
whole project. It is shown on the Gantt chart in a different colour.

Critical path (red) identifies those activities that are determining the project
completion date. These tasks need to be managed carefully to ensure that they
do not slip. The people doing these tasks might need special support. Example
is with MS Project.

In principle the critical path is calculated (automatically) from the network

diagram, and requires the task durations to be known and the links
established. The calculation determines the amount of slack (or float) in each
task. The critical path is therefore the set of tasks with no slack (or float).

However in most cases the software does the calculation so the user hardly
even knows how it is being done. The important point is that the input
information must be accurate.

MS Project uses this format tool to show the critical path.

Critical path may be used in two complementary ways: to minimise time-

threats and maximise the time value of extra effort. The first is reasonably self-
evident, but the latter may need some explanation: Shortening any activity on

182
the critical path will decrease the whole project duration. Shortening the
activities that are NOT on the critical path will NOT shorten the project
duration, and thus there is less benefit of making such changes.

The critical path is not fixed. Its input dependencies are the durations and the
links.

Each has consequences:

1. Effect of duration on critical path
a. To shorten a project, you concentrate on the tasks on the critical
path. Put more resources onto the task.
b. If some durations are changed, then other tasks may come onto
(off) the critical path, i.e. the critical path will change.
c. The critical path shows worthless information if the durations are
unrealistic.
2. Effect of links on critical path
a. The critical path shows worthless information if the links are
inaccurate. The link structure is essential for the accuracy of the
critical path. The links will automatically bring other tasks onto the
critical path as necessary. Therefore it is important to create an
appropriate link structure in the first place.
b. If all the tasks in the project are in series, then everything is on the
critical path.
c. Whichever chain of linked tasks ends latest will be the critical one.
d. Even a single unlinked task at the end of the project will suppress
the rest of the critical path.
e. Even a single unlinked milestone at the end of the project will
suppress the rest of the critical path.
f. Constraints affect the critical path.
SOLVING ERRORS WITH CRITICAL PATH
Does the critical path on your project not show as you expect? Usually this is
because of link and constraint errors. Here are some tips for solving and
avoiding problems.

All tasks in the whole project must be linked for the critical path to show
correctly. The link may be either directly to the task, or to its summary. The link
can be downstream or upstream of the task, or both. Why? Otherwise only
part of the project will show as critical. Thus any milestone at start (or end) of
project must be linked to the other activities. Also, clusters of tasks must be
linked, e.g. by summaries.

183
All chains (clusters) of tasks must be linked somehow to the project. If not, then
only the last-ending chain will show as critical.

Inadvertent constraints are another common error. The constraints typically

arise because novices have dragged the time bars into place rather than
creating links!

Fixing the start dates of tasks causes problems with the display of critical path.
All the upstream tasks are never critical. Therefore, be precise about applying
constraints such as ‘must start on’, and do not manually position tasks (use
links instead).

Use of other links: The finish-to-start (FS) links behave as expected in the
critical path. However the other link types behave differently. Start-to-start

184
links (and finish-to-finish links) sometimes result in the second task not
affecting the critical path in the way expected. Why? This is a natural
behaviour of these links. Often it is possible to just ignore it since the
implications are usually minor. However, if you need to get rid of this
behaviour, then the simplest solution is to avoid this type of link: instead have
multiple tasks all linked F-S from a single precursor.

Links such as finish to finish can have unexpected consequences on the critical
path.

.5 Monitoring Costs
Once the project gets underway, then the costs have to be monitored and
controlled, and corrective action may be necessary. It means that
organisations that implement project management costing tend to need to
also implement time-sheet accounting.

Time-sheets
Project management is highly task-focused, and this extends to the way costs
are treated. This has some consequences and also detriments.
For example, on a particular day an employee might
work works 5 hours on the project and 3 hrs on a training
course. In which case the person needs to fill out a time-
sheet with this breakdown, and this is subsequently used
by the accountants to charge 5hrs to the project and
3hrs to a general overhead account. In general the
situation could be more complex, since the person might
have several projects on the go at once, and will need to
keep track of the various hours spent on each. Thus it will

185
 not surprise you to know that time-sheets are commonly
used in civil consulting firms, where there are multiple
simultaneous projects.

Time-sheets are good for allocating cost to specific projects. The project
manager can get reports of exactly how much effort has been exerted on the
project. Or rather, we should say how much cost has been attributed to the
project, because not all the cost is necessarily spent in pursuit of project
objectives. People vary in daily productivity, and in a time-sheet regime they
will have to cost their time to some project even if they had a bad day and did
not get anything done at all: the problem of Non-project time. Consequently,
time-sheets are not necessarily as precise as they might seem. However they
may for impressive looking accounting when it comes to reporting back to the
client.

Much more can be said about controlling project cost, e.g. about earned value,
but we won’t do that here. The important thing for the present is to
understand that accurate control requires thorough prior project planning.

Cost variance
Cost variance is the difference between planned (total) project cost and the
latest projected cost. The latter is based on any changes to durations of
activities, labour rates, capital expenses etc.

Cost variance is deviation from budget cost, and is usually of major concern. It
takes into account the monetary value of the extra time. The spreadsheet
component of PM software may be used to show the cost variance. For MS
Project, change to cost view with <menu>View/Table/Cost, then see the
column titled ‘Variance’ for the effect of the changes.

In this particular figure the variance is zero because the project is going exactly
to plan (or more likely it has not been undated!). Note that the ‘Actual’ cost is

186
starting to rise: this is the measure of spending proportional to task
completion.

Two small changes have been made to the project. The cost implications of
these are immediately shown in the Variance column. None of the durations
has been changed in this simple example, but if one was to be, then it too
would contribute to the variance. Variance may be positive or negative
(saving).

The one variance that is not captured is the technology variance: to what
extent have the technology features been completed? This is the purpose of a
progress report or project review.

Earned value
Earned value measures progress as the proportion of cost spending: the cost
that should have been spent up to the review date if everything was going
exactly to plan.

The completeness of a project may also be assessed by the proportion of cost

spending, which is termed earned value. For example, a project that has spent
half its budget is 50% complete. This provides a measure of completion that is
different to that of time, and in some ways better since some tasks may take a
lot of time despite having low importance to the project. However, in practice
it takes some effort to determine the proportion of cost spending, since each
task may be ahead or behind schedule, and the cost projections may have
changed relative to the original budget. This is an easy problem for software
though.

The financial performance of a project is evident in several metrics. The most

popular of these is earned value, which in MS Project is termed budgeted cost
of work performed (BCWP). However the term ‘earned value’ has variable

187
usage (Meredith & Mantel, 1995 p524) and it is thus necessary to clarify it
further. ‘Earned’ is an unfortunate term since it wrongly suggests ‘actual’
rather than budgeted, however the term persists in the project management
literature. Earned value (BCWP) is the cost that should have been spent up to
the review date if everything was going exactly to plan. Thus it does not take
into account whether the task has actually been completed or not.

An important indicator of progress is the amount of cost that should have been
spent by the review date but has not. This is the cost variance (CV), which is
thus the budgeted less actual cost of work performed, i.e. CV = BCWP - ACWP.
The way these metrics is determined is complicated by the fact that some tasks
are ahead of schedule and others behind.

Method by which MS Project ® software determines earned value.

188
.6 Adjust project execution to close the gap
To close gaps: rearrange the work, add new tasks, change resource allocations.
Project management allows for changes to the plan as things occur. Most
projects will have unforeseen circumstances, e.g. adverse weather on a
building project. Tasks may be delayed, new tasks added, and resources
changed in response to needs. If a baseline has been saved (see next section),
it is possible to immediately see how a change affects the final project date or
total cost.

REARRANGE PROJECT EXECUTION

The typical way to adjust project execution is to rearrange the work, add new
tasks, change resource allocations, etc. These changes are internal operational
details, and while they may be communicated to superiors, they are not
necessarily discussed with the client. Not unless they are so large that they
significantly affect the project deliverables (output quality, deadline, cost) or
have changed the risk. In those cases it will be necessary to redefine the
project.

IMPLICATIONS: SOFTWARE PRACTICE

Percentage complete shows how much of the task is complete. It also fixes a
task, so that it will split if it is subsequently rescheduled.

This project has some tasks complete (black bars). However the residual
incomplete work has to be re-scheduled into the future and thus the tasks are
split. This example uses MS Project software.

189
7 Project closure
Deliberately plan for closure
Closure is the decommissioning of the project office after a successful project,
or early termination of a bad project. This is often done badly. Many projects
attach ‘closure’ as a few tasks at the end of an existing project. Furthermore,
the tasks are executed at a time when incentives and motivation are waning.

Closure tends to be neglected and poorly planned [60].

Closure of a project is not just initiation in reverse, thus ‘quality practitioners

who do not understand the different responsibilities of project initiation and
project closure stages make severe errors’ [61]( p 63).

If there is an industry that specifically addresses project closure in a methodical

and successful manner, then it is the nuclear industry [62, 63]. The problem
they face is the challenging one of decommissioning radioactive plant. The
reason they are successful at this is because they treat the closure as a project
in its own right, and resource it accordingly, e.g. USD 7.5 billion for cleanup at
Rocky Flats [64]: not only so, but they also sometimes provide contract
incentives for success.

The project management method is good at managing time and resources. Its
major weakness is the inability to evaluate the degree of technical completion
of the project. This is a particular risk where the project involves some novelty
or uncertain technical route. Many project failures are due to the inability to
fully anticipate all the technical work (and the rework loops), and the inability
to measure functional completeness. Commissioning is often rushed and done
poorly for lack of resources.

.1 Introduction
Why is Closure difficult?
Much of project management effort and research literature is focussed on the
planning and execution stages. These are explicit activities with tangible

190
outcomes. Relatively less is known about the closure activities, which despite
generally being perceived as routine, can be highly complex.

Closure has a unique set of challenges and is one of the stages that is too often
done badly [65]. The preferred outcome is a project that provides the
deliverables and is shut down in a controlled and progressive manner [7, 19],
leaving everyone content [38]. In other words, the project should satisfy all the
stakeholders: the client, project organisation, sub-contractors, and the team
members. If that is not possible then it is generally held to be desirable that a
failing project be terminated cleanly. The problem is that a variety of partial
failure modes are possible. For example a project can grind on interminably
consuming a steady trickle of resources, or terminate abruptly by providing
only the basic deliverables and leaving loose ends.

Contractual issues at closure

The important tasks are verification of the project outcomes and settling the
contract, see also [7, 65]. This can also include early termination of the
contract if the project is unable to deliver the specified outcomes. Contract
closure is also mentioned in procurement (section 12).

The difficulty in contract closure is confirmed by research that has shown that
the major problems that project managers have to deal with at closure are:
* negotiating claims and final payment with clients [66]
* demonstrating performance, including statutory requirements and
performance guarantees [66]

Those issues arise even for projects that end as planned. The problems are
greater still if the project, or a sub-contract thereof, terminates unusually.
Disputes easily arise if a contractor abandons the work, or the project
manager terminates the services on the basis of non-performance [67].

Administrative closure
The administrative closure includes collation and archiving of documents. This
activity features prominently in the practitioner literature [7]. The obvious
output is documents archived in a project file. Other outputs are the freeing up
of assets to the client or the project organisation: provision of user manuals,
provision of spare parts, return of unused resources, and handing over
intellectual property [38]. Closure of the project office is another outcome.
These are relatively easy to finalise providing only that the project plan makes

191
provision for the work required. However, other important assets are
intangible and harder to anticipate, as elaborated below.

Learn lessons
Important intangible assets of a project include the skills and knowledge
gained by the team members, which need to be captured by the individuals
and used to enrich the organisation (‘learning organisation’). Capturing that
‘lessons learned’ knowledge can be done with a review [38].

A strong feature of much of the PM literature is the need to collect the

learning from the project, and use these to improve the next similar project
[65]. Thus, ‘various authors realise that project environments could also
benefit from the creation and re-use of knowledge, including from the lessons
learned that should be documented during project close-out’ [68](p41).

However, it has been observed that this is not always as effective as it might
be: ‘though project history is prepared in many companies, this somehow does
not reflect in learning from mistakes and modifying project management
procedures appropriately’ [66](p124).

It is broadly true that project management focuses on outcomes, not people: it

is achievement orientated, and personal issues of project-team members are
considered subservient to project progress. The myth within project
management is that a project is only a temporary endeavour, and therefore it
does not matter what personal costs the team members must carry.
Consequently project management theory is weak at comprehending personal
issues. The reality is that every member of a project-team is potentially a
member of another future project-team, and will therefore carry any stings
[69] into the future situation.

However it is probably better to do so in a non-condemnatory manner as the

purpose is to learn, not assign blame. Perhaps you might like to create an
atmosphere of trust and honesty by setting some rules about behaviour during
the review meeting. Let everyone have their say and don’t worry about trying
to forge consensus. Do the review as soon as possible to take advantage of
well-established reinforcement principles from behaviourism psychological
[32, 70]. If the team doesn’t take time to reflect on the outcomes, then the
learning is lessened.

192
Check against original criteria of success
Projects are initially expected to produce value of some kind, e.g. financial
return on investment (ROI) for the client. The PM method then creates a list of
activities (the work breakdown structure) for building the necessary system.
The risk is that the focus is on completing tasks or building a system, to the
detriment of the original expectations of value. Thus:
‘It’s all too possible for completed projects to appear to be successful
based on adherence to schedules and budgets, as well as delivery of
benefits, even if they didn’t meet the objectives that drove the original
ROI case’ [60](p37).
Hence the need to check against the original intended value. In this area the
systems engineering methodology is potentially superior, because it includes
the concept of validation: checking that the system as delivered still meets the
client’s needs.

Project managers can go further than this though, by seeking to increase value
through subsequent enhancements. We are not talking here about changes to
scope that occur during the project (scope creep), but about opportunities to
develop secondary projects that add further value to the customer. The
problem is that ‘people think of projects as temporary endeavors ...[and
therefore] disband the project team’ [60] (p38). By being too focused on only
the project itself, they miss the opportunity for derivative works. These other
works may be product enhancement, secondary functionality, or related
products. Ideas for these derivatives may come from brain-storming with the
client after the project is closed.

The PMBOK perspective of closure

The codified project management body of knowledge (PMBOK) includes
project closure as the last stage, termed ‘close project’, in project integration
management (section 4, third edition) [7]. It is described as having two
component procedures. The first being administrative closure, in which records
are collated and archived, and lessons learned. The second is contract closure,
involving verification of the project outcomes and settling the contract [see
also 65]. This can also include early termination of the contract if the project is
unable to deliver the specified outcomes. Contract closure is also repeated as
part of procurement (section 12).

The later fourth edition of the PMBOK [19] removed the demarcation between
administrative and contract closure, at least at the integration activities
(section 4), but preserved the concept of verifying that ‘all project

193
requirements are complete’ (p102), and the collation of project
documentation. It also emphasised the concept that closure involves transition
of the project deliverables to the client. The contract closure was de-
emphasised in section 4, and in section 12 was renamed ‘close procurements’.
The overall change from third to fourth edition was therefore relatively minor.

While the PMBOK standard notes the need for closure, the mechanisms for
achieving closure are ambiguous. The PMBOK [7] states that these methods
are the PM methodology itself (a circular reference), the PM information
system (vaguely defined as a manual or automated system for gathering and
disseminating project outputs, p369), and ‘expert judgement’ (p101) (though
that of course is of little help to the novice). The idea that ‘expert judgement’ is
required is continued into the fourth edition.

Consequently, it is fair to state that the PMBOK lacks specificity about how a
project manager would go about closure. Furthermore, there are several
aspects of closure, particularly the human aspects, which the PMBOK omits
entirely. Thus it is unsurprising that project managers are at risk of
underestimating what is involved for successful close-out, and failing to
prepare adequately [66].

.2 Making the decision to terminate early

Predictors of project success
There are two sides to decision-making regarding termination. One is to
predict whether the project is likely to be successful, and this activity happens
at the outset and at various decision-stags within the project life. The second
is to respond to initiating hazard events.

As regards the first, the practitioner and research literatures assert that certain
factors are critical [38, 66, 71], though the evidence base for these
assumptions is not always clear. For example a study [72] of research and
development projects identified various factors as being related to project
success:
* technical route: smoothness and probability of success
* project champion

Others are associated with failure:

* deviations in cost schedule
* chance events

194
However many other factors have ambiguous contributions. Other results, also
for R&D, are somewhat contradictory and suggest that technical feasibility and
economic analysis are not strong components of decision-making, thus: ‘basic
research projects are much less likely to be subjected to a formal economic
analysis and are generally thought of as being "strategic" investments’ [73,
p291].

Initiating hazard events

This model mainly examines those projects where continuation decision points
(e.g. stage gates) are NOT built in from the outset. For these projects it is some
hazard event that forces the organisation to a decision: whether to terminate
or continue a project. These hazard events are anticipated to include:
 impending failure of project scope (e.g. either schedule, cost, function,
or quality),
 lack of support from senior management (they have changed objectives,
disinterest, or the external environment has changed),
 loss of motivation of project staff (they are stressed, pathological team
relationships, despondent),
 loss of key capability (key technical skills lost, technology has been
usurped by another project, intended technology solution is non-
feasible, funding is drying up), or
 loss of political support for project, e.g. loss of sponsor, project
champion.
Adapted from: [38, 74]

If one or more of these factors is present then it may cause catastrophic

project failure unless actively managed. However we conclude that it is not
easy to predict beforehand whether a project is likely to succeed or fail,
neither at the outset nor part way through.

Lists of purported critical success (failure) factors, and some may be found in
the popular practitioner literature, may be useful as a guide to practical action.
They are plausible, but are of unknown reliability and should be used with
care. Finding empirical evidence for the importance of one or a few select
factors is not too difficult, especially if the factors are broadly defined. The
more important problem to identify which of a large set of factors are actually
important, and which are irrelevant. There has been some research to
determine just what these critical project factors might be. This type of
research typically takes a large list of candidate factors, offers them to people

195
to rate, and uses the statistical process of factor analysis to determine clusters
of factors that best accommodate the variability encountered in the survey.

For example, this has been done for critical factors in project failure, and the
results show that two of the most important factors (at least for public service
projects) are:
* Change in the political commitment (e.g. external/internal politics,
funding source, champion, regulation).
* Change in the need for (or importance of) the project, i.e. a departure
from the initial expectations.

Who makes the termination decision?

Making a decision to terminate a non-performing project is not easy. There are
sunk costs which will be lost if the project is abandoned, but which might just
be recovered if a little more is spent on the project. Termination is a
particularly difficult decision when the salvage value is low but the termination
costs are high.

The project manager is perhaps not always the best person to make that
decision, because most have the otherwise useful characteristic of being
biassed towards overcoming problems by persistence. The question to ask is
whether the organisation would still initiate the project if it were being
proposed today for the first time, with what is now known. There is some
research to suggest that someone not directly involved with the project often
makes the decision to terminate the project [75].

On what information is a termination decision made?

Much of the literature states that termination should be made on rational
economic criteria [73, 74, 76-79]. However the research is not entirely clear on
what the termination decision is actually made on. Economic criteria do not
feature in reality as much as might be expected. It seems that time, especially
calendar time, is important at least in some cases [80].

There is also evidence that different criteria exist for different types of
projects, for example research has found that ‘post-audits of Applied and
Development projects are based on economic measures, whereas Basic
research projects focus on physical or operational goals’ [73] (Cook & Rizzuto,
1989, p291), from which an approximate inference is that the same measures
would be used in termination decisions.

196
The issue of technical feasibility arises in some projects more than others.
Consequently one would expect technical feasibility problems to be the cause
of many termination decisions in research and development. However there is
research that shows this is not so: ‘most R&D projects are terminated because
R&D priorities have changed rather than because they are not technically
feasible’ (Cook & Rizzuto, 1989, p291). Other research suggests that technical
infeasibility is indeed an important influence on termination decisions [81].

What is the mechanisms for making the decision? And is there a

Sunk cost bias?
Given that meeting financial cost budgets is an important criterion of project
success, one would expect that projects would be terminated/continued on
the basis of the cost performance up to the date of review. Thus unprofitable
projects would be expected to be promptly terminated. However it does not
always happen like this [76].

The ‘sunk cost’ bias suggests that people’s decisions about ongoing investment
in a project are influenced by how much they have invested in it. The theory
says that the more money and time they have invested, the more they are
likely to want to persist with the project to completion, i.e. an escalation of
commitment bias. However, the research evidence for the sunk cost bias is
ambiguous.

The rationale [80] behind this theory is that people make decisions based on
the ‘expectancy' of success: the compounding of expected intrinsic value of an
outcome with the expected likelihood of success [82]. Avoidance of cognitive
dissonance may also be involved: to first support the project on its perceived
value, and then to later be confronted with evidence that the value will not be
obtained or the decision was wrong, is cognitively uncomfortable and the
source of that discomfort may be suppressed. Thus the evidence of possible
failure may be cognitively suppressed, hence a bias. A third effect that might
underpin the sunk cost bias is repercussions. Research shows that project
managers feel more personal career risk when cancelling projects than do
executives, and hence there is an escalation of commitment bias [80].

A fourth effect may be aversion to regret [79], i.e. being reluctant to make
decisions that finally confirm losses because that creates regret. People
postpone that pain by continuing the project, in the hope that while the future

197
is ambiguous it might still result in success. It is better to be a live dog than a
dead lion?

However, the research evidence for the sunk cost bias is ambiguous. Some
research has found no support for the effect [83], while other studies have
confirmed the existence of the bias [see [80] for public-service projects; [84].]
Other research suggests the opposite effect, namely de-escalation of
commitment as sunk cost increased [85].

In some ways sunk cost might not be the best term, because it suggests
financial cost, whereas there is evidence that it can be time that really matters.
Thus some research suggests it may be more accurate to say that decisions are
based on how close the project is to completion [83, 86, 87]. Project
completion can be more important in people=s decision-making than the
economic concerns of sunk cost:
‘projects are initially undertaken with the goal of economic profit in
mind. As a project nears completion, however, the initial goal of
economic profit is overtaken by the goal of project completion’
[87](p192).
This effect has been evident in other research [88]. In other words, people are
intrinsically motivated to complete a project, and towards the end the financial
profitability may become secondary.

However this is complex topic and it may be that the biases varies according to
the type of accountability required (e.g. decision outcome vs. decision process)
[89], or stage of project [90], or that cost and completion factors are
complementary [91]. It is also possible that in some circumstances the effect
may be in the opposite direction, i.e. a de-escalation [92].

To sum up, the matter of escalation bias is a complex one. It seems likely that
there is not just one universally applicable ‘sunk-cost bias’. Further research is
needed to determine the different types of bias, the influencing factors, and
the strength (and direction) of the resulting bias. From a practitioner’s
perspective, it is probably reasonable to assume that an escalation bias could
be operating in any given project, driven by cost invested to date and closeness
to completion.

Perceptions differ by role

Research shows that ‘project managers are more likely to terminate a project
that is running overtime than are executives’ [80] (p388). Thus project

198
managers are more sensitive to total time spent on a project: perhaps overly
so. Executives ‘may be more understanding of schedule slippages than project
managers give them credit for’ (p394). However that same research also found
that while executives were not as worried about labour hours as were the
project managers, they were more sensitive to calendar time.

The research also suggests that the bias is different for project managers
compared to executives [80], and for projects involving risky research and
development compared to deployment of existing technology, but further
research is required to elaborate these effects.

Based on the evidence so far, it seems that a sunk cost bias does exist,
especially if ‘cost’ refers to finance or time. However the effect is variable and
only partly understood, and it is still difficult to provide practising project
managers with reliable advice in this area.

Termination strategy
A termination strategy will then need to be selected based on the decision
made. The choices are natural closure due to achievement of objectives,
forced closure due to unsuccessful outcomes or client disinterest, transfer
(‘addition’) of all project resources (equipment and staff) to a new
organisation, piecemeal integration of project resources into a host
organisation, or stasis (‘starvation’) where the project budget is removed but it
continues to exist, at least nominally, to meet political objectives of senior
management [38, 93].

.3 Closure process
In this model the closure activities are placed within the overall activity of
‘obtain project benefits’, since that best describes the purpose of closure.

The whole purpose of the project is to deliver benefits to stakeholders. They

can only receive those benefits once the deliverables have been handed over
to them. At that time the project manager will generally also report on the
outcomes, so that everyone is clear about what has been achieved (or not) and
the contractual implications. Once those activities have been completed then
the project may be finally closed.

These activities are represented in the system model as shown in Figure Pm-4.
They include the hand-over of deliverables (1), reporting on outcomes (2), the

199
closure activities themselves (3), and the distribution of benefits to
stakeholders (4,5). The Reader is encouraged to study the diagram and see
how the above textual description maps into the model. Also, the model has
further detail about the nature of the deliverables (physical artifact,
documentation, etc.), and to whom the reporting occurs (superior, client,
project team). It also shows how the value created by the project flows into
the organisations involved thereby contributing to those organisations meeting
their own purposes. From this perspective a project is therefore part of a client
organisation's strategy for achieving its organisational purpose. Thus the model
integrates across into organisational management and governance, and
although the details of those other models are beyond the present scope. The
implications are that we should stop perceiving of a project as a set of
coordinated tasks, and rather see it as a strategic means of achieving
organisational purpose. To introduce a concept that will be further developed
later in this paper: early closure occurs when a project is no longer meeting
organisational purpose, regardless of the quality or otherwise of the project
management methods being used.

200
Close project
Having set the context in which closure is embedded in the broader project
theory, and the organisational setting, we now turn to closure itself. The model
for this is shown in Figure Pm-4-3a, this being a simplified version. The model
accommodates two main closure outcomes: normal and forced termination.

201
Normal termination applies for projects that are completed on-time, on-
budget, and functionally complete. Forced termination involves a decision on
whether to terminate the project early (1). Not shown here, but elsewhere the
wider model includes an activity of major redefinition of the project part-way
through during execution, that being a preferable outcome to forced
termination.

Termination results in closure of the contract (2), and of the project office (3),
these being the main activities recognised by the existing PM standard.
Learning lessons (4) and deliberate planning for closure (5) are included as
these are also present in the literature. This model also proposes two other
activities that are relatively rarely mentioned if at all: seeking to increase
future value (6), and soft closure (7). All these activities are elaborated below.

202
 Decide whether
to terminate Forced premature
project before termination of whole
completion project
(1: Pm-4-3-1) Normal termination:
completed system
(functional, on-time,
on-budget)

output: completed
Close contract Closed
system (functional,
(2) contract
on-time, on-budget)

Administrative Closure of project

closure (3) office

Archived
documents Seek to increase
future business
value opportunities
(6: Pm-4-3-6)

skills (technical,
Learn lessons
management) for
(4: Pm-4-3-4) future work

Soft closure
Motivate staff
Deliberate plan (7: Pm-4-3-7)
(possibly a
separate project)
Deliberately plan
for closure (5)
Awareness of
soft issues

Not shown in this view are

the more complex
relationships.

Copyright Dirk Pons . File version: VisioDocument. Sheet: 43. Printed: 7 January, 2010
Close project (Pm-4-3) (a: simplified view only)

203
Decide whether to terminate project before completion
Projects occasionally get into trouble, and a decision must be made whether to
terminate them prematurely or persist tenaciously to completion. This is
situationally specific, and the precise factors that bring about this situation
cannot readily be predicted beforehand. Nonetheless it is possible to model
the process of decision-making that occurs.

The decision-making process starts with those who have oversight over the
project, i.e. the governance function, see (7) in Figure Pm-4-3-1. Factors at this
level include loss of political support: if the project no longer has the potential
to advance organisational purpose or personal political objectives of
executives, then its continuation is not longer required. Thus the group
behaviour and politics of executives may affect the future of the project in
ways that seem irrational and confusing to the project team. Another potential
cause of project-irrelevance is that organisational strategy is constantly shifting
in response to events in the external environment (and internal events). The
project itself may have a longer duration than the strategic planning horizon
for the organisation. Thus the organisation's priorities may change and the
desirability of the project outcomes may be diminished (5).

204
 personal and
deterministic thinking: inability to collective risk
conceive that the project may be tolerances: ability to
only marginally feasible in one of carry consequences
its dimensions of failure
delibeately tolerance of
structured personally commitment and
ambiguity of project
approach to emotional well-being tied up in
outcomes: loosing
achieving the the project,
nerve
purpose of the
unwillingness to impose political
overall venture
implications for sponsors,
champions, clients, etc
Identify tolerable Tolerable
Conditional decision-making risk level of
(4: MfR-1-1-2) risk
decision-making points in the
in the future (1) timeline

Hazard Event:
technical, schedule,
cost, or resource
problems
stage-gate break project
scope statement
approach into phases
provides criteria for
evaluating project perceived
success (failure) likelihood of
project failure
Predict likelihood
progress report
Report on project (original objectives, of project
outcomes actual outcomes, outcomes (3)
perceived
(2: Pm-6-6-2) comparison to targets,
likelihood of
future work)
project success

Identify critical
desirability key
success factors
of project characteristics of
success for the venture success
(6: MfR-1-1-1)
Determine
ongoing
desirability of
project outcomes
dreaded
(5) consequences of
ongoing support for
project
project failure

project decision (selected solution,

Team makes approval to commit resources,
larger decision decline, remedial action, stimulus for
organisational (8: DM-3-4) new concept, new criteria,
objectives and procrastination, indecision)
strategic priorities
Management Forced premature
oversight termination of whole
project
Oversee the political support (or
project loss thereof) for
(7: Pm-5) project

group behaviour
and politics

termination strategy
Select (natural closure,
termination forced closure
approach (9) transfer, piecemeal
integration, or stasis)

Decide whether to terminate project before completion

Copyright Dirk Pons . File version: VisioDocument. Sheet: 431. Printed: 29 October, 2010

(Pm-4-3-1)

205
Conditional decision-making in the future (1)
Some projects, particularly in research and development, are designed from
the outset with milestones at which feasibility decisions are made. Further
continuation of the project is conditional on satisfactory achievement of
previous objectives. A phased approach is taken to the venture, with the
opportunity for disengagement built in as the decision points. This is
sometimes called a stage-gate approach.

However, for many projects the commitment is either fully there (or not) from
the outset, and these projects understandably do not anticipate that such a
decision will even arise. Therefore conditional decision-making is not provided
in the WBS from the outset, so it requires a conscious realisation that such a
decision is necessary when problems arise.

Belated decision-making is difficult because (a) it is a new task and therefore a

change to the project as originally conceived, (b) the decision-making is
potentially intrusive to the project team who may have a lot of personally
commitment and emotional well-being tied up in the project, and (c) there are
political implications for sponsors, champions, clients, etc.

Predict likelihood of project outcomes (3)

The progress reports (2) provide information on actual outcomes and the
amount of future work required. Comparing this against the original scope
statement provides the criteria for evaluating the degree to which the project
is currently successful (3).

It is proposed here that there could be two sides to this evaluation: failure and
success. The perceived likelihood of project failure initiates a risk management
activity of identifying the tolerable risk (4), which is primarily the personal and
collective ability to carry the consequences of failure
(4).

If the project is perceived to be likely to be successful (3), then that is still not
enough. Instead it is necessary to pass the additional test of whether the
project outcomes are still desirable (5). Many things could have happened to
change that desirability, even if it fully existed at the outset. If the project is to
be successful, then it must also meet several objectives, or critical success
factors (6), and these too may have changed since the outset.

206
Those who oversee the project (7) make control how these decisions are
made.

The penultimate activity of making a decision about the future of the project
may be a team one (8), but even if it is made by an individual it will tend to
nonetheless be influenced by other people in the organisation. The point is
that it is not simply the technical likelihood of success (3) that determines the
fate of the project. The project manager, who tends to be focussed on
faithfully delivering against the original objectives, really only reliably sees
activities 1-3.The other activities occur at higher levels within the organisation,
and are more strategic and political in origin. It is understandable that project
managers find the closure decision-making perplexing.

Towards the end of a project it may be important that the project manager
change his/her focus from what has probably been predominately a task-
orientation, to include an equally strong relationship-focus. Simple things
might help: compliment the team members on their contribution [65]. In
particular, be alert to the anxieties that team members have about their future
employment roles [94].

There are a set of tacit tasks at the bottom of the WBS, which are to ensure
that the project staff are (a) personally satisfied with their contribution to the
project, and (b) engaged with healthy motivation towards their next
employment position. Leadership in a project manager involves more than
simply handing the staff back to a central human resources department to
reassign or dismiss. Project management does not do this well.

207
8 Maturity models
Maturity models seek to represent the level of achievement (quality) of the
organisation’s processes. They are typically stepped models. Their intent is to
encourage ongoing improvement in the project management (or other)
practices. It provides a means to merge quality management, project
management, and strategic management. For organisations whose work is
primarily a series of projects, this is potentially very valuable.

Maturity models provide a mechanism to optimise organisational business

processes and projects to meet strategic objectives. The method is
characterised by the application of evidence-based measures of what really
counts for the organisation, the adoption of best practices, and continuous
improvement.

The term ‘maturity’ is used because there are increasingly higher levels of
achievement. The highest levels of maturity are considered to include
coherence between strategy and operation.

Introduction
Maturity models seek to advance the 'maturity' of the organisation in regard
to the way it goes about fulfilling its purpose. There are several maturity
models available (http://www.pmforum.org/standards/matmatrix.htm). The
Organisational Project Management Maturity Model (OPM3) is from the
Project Management Institute (PMI), and the following comments generally
apply to that model.

Underlying principles
The following principles tend to be involved:

(1) EVIDENCE-BASED
Maturity models share with the Baldrige criteria [98] a focus on an evidence-
based approach to measuring achievements against explicit statements of
intended organisational purpose. Relevance questions are 'how do you know
that you are achieving xxx?' Related to this is the need to identify, and then
measure, the business variables that really matter.

208
(2) GROWING MATURITY THROUGH CONTINUOUS IMPROVEMENT
Most of the maturity models have stages of maturity. At the lowest level the
organisation runs ad-hoc processes, is reactive to risk, measures things out of
habit, different work areas measure things in different ways, has vague
strategic objectives that are mismatched with the management information
systems, etc.

At the highest level there is continuous improvement, awareness and sharing

of best practice, consistent measurement, and a close alignment of
measurement and strategic purpose. For example, see here:
http://dti.delaware.gov/majorproj/pdf/newsletter/news_sep05.pdf
For a more academic treatment of the levels in OPM3 (which does not have
explicit levels) see here
http://www.pmforum.org/library/papers/2007/PDFs/Schlichter-6-07.pdf

(3) ALIGNMENT BETWEEN MANAGEMENT SYSTEMS AND STRATEGY

Internal strategic alignment is the primary intended benefit at the highest
maturity level. For example:
'Using the model, one can develop coherence between the organization’s
strategic goals and its project-based activities, by guiding organizations
in the development of the capabilities necessary to choose the right
projects to advance their strategies, and the capabilities necessary to
deliver those projects successfully, consistently, and predictably.'
http://en.wikipedia.org/wiki/Organisational_Project_Management_Mat
urity_Model

Implementation
Implementation of maturity models involves these steps:
1. Assess the existing state of maturity in the organisation.
a. With OPM3 this is done by a series of questions.
b. Assessment may be done by self-evaluation, or using a consultant.
2. Determine what constitutes best practice for this particular type of
industry.
a. With OPM3 there is a database of best practices provided.
b. Decide which metrics are effective. The maturity methods do not
explicitly say that input control should be totally abandoned, but
instead imply that organisations should select measures that are
closely aligned to strategic purpose and which are applied at
output level.

209
 3. Improve organisational practices. This is the biggest stage.
a. Identify what needs to be improved.
i. Create a plan-roadmap for achieving it. OPM3 provides a
tool to support this. The plan itself can be a project
management charter, which includes goals, scope,
deliverables, responsibilities etc. For an example see
http://dti.delaware.gov/majorproj/pdf/newsletter/news_s
ep05.pdf
ii. 'The ASSESSMENT element is an interactive database tool
accessible on the web site that lets organizations evaluate
their current situation and identify their areas in need of
improvement. If an organization decides to embark on the
path to higher maturity, the IMPROVEMENT element, also
accessible on the web site as a database, will help them
map out the steps needed to achieve their goals.'(
http://opm3online.pmi.org/Overview.aspx )
b. Implement a programme to develop the organisation’s capabilities
to the desired level of maturity (
http://opmexperts.com/OPM3ExecGuide.pdf )
The process may be repeated to advance to higher levels of ‘maturity’.

Discussion
The main benefit is usually given as greater strategic success for the
organisation. For example, maturity models provide a ‘mechanism to advance
your organization’s strategic interests through the efficient and successful
execution of projects’ ( http://opmexperts.com/OPM3ExecGuide.pdf ).

Whether or not maturity models are themselves more effective than any other
strategic tool is unclear. That kind of question simply does not feature strongly
in management research, so we do not know the answer yet. Like any
management innovation it may or may not be a fad, but nonetheless it has
some outcomes that are likely to be enduring: In some ways the OPM3
maturity model is about lifting project-based thinking from the operational to
the strategic level, and providing a structured way to achieve that. You could
also see it as a merger of quality management, project management, and
strategic management.

210
9 Psychology in project management
RESEARCH TOPICS

People are not dispassionate resources. Inability to perceive this is a great

failing of the project management methodology. He aha te mea nui o tea o?
What is the most important thing in the world? He tangata, he tangata, he
tangata. It is people, it is people, it is people.

The method fails to acknowledge the existence of intrinsic motivators for team
members, neither the motivation that prompts people to be willing to join a
project team, nor the motivation that provides the ongoing quality labour, nor
the motivational discontinuity as the project closes. More research is needed
in this area.

Most constructs of motivation in psychology implicitly assume a steady-state

employment, and most leadership constructs focus on vision and initial
motivation to accept a change effort. By comparison project management
includes several different phases where motivation can be expected to vary.

Strong outcome focus in project management

Project management is an outcome-driven method. It earnestly seeks
achievement of functional objectives, and all its tools and processes are
focused on the criteria of project success. Those criteria are primarily quality
(function), cost, and schedule. Furthermore, those criteria are usually client-
centric, i.e. seek to maximise value from the client perspective.

Consequently project management can sometime be perceived as too

instrumental, and too preoccupied with functional outputs, to the detriment of
the human dimension of the staff concerned. Certainly the PMBOK
acknowledges the importance of human resource management (section 9), but
even so it is mostly task-oriented. For examples the PMBOK lists the need to
document project roles and the reporting hierarchy, ‘obtaining the human
resources’, ‘improving the competencies’ of individuals, tracking performance,
resolving problems [95]( p 199) - the whole purpose being to ‘enhance project
performance’. To be fair, the PMBOK does mention team-building briefly. It
also mentions rewards, though it does so only from a behavioural psychology
perspective: ‘only desirable behaviour should be rewarded’ [7] (p214). There is

211
nothing wrong with behavioural psychology, but it is focused on output
behaviour and the control thereof, rather than addressing other dynamics of
motivation. Thus there is evidence for a strong task-orientation throughout the
PM method.
What motivates the project leader (sponsor/champion)?
Many projects don’t need much leadership. Such leadership that is required is
provided by the executives and human resource managers of the host
organisation, and by the project sponsor (a politically powerful person who
endorses the project and advocates for it at senior levels).

As regards the latter, who can also be called project champions, research has
shown that champions are motivated not by the technical merit of the project,
but by the political advantage [96](p444). Furthermore, as regards terminating
projects, the same research shows that champions protect their projects from
termination. Their behaviour is primarily political rather than functional, since
‘champions are successful at providing resources to projects that are no more
likely to succeed than other projects’ (p444). In other words, a champion’s
support for a project is not based on the technical merit of the project nor any
superior ability to discern successful candidate projects, but on the political
opportunity. Consequently, ‘managers can no longer assume that champions
are selfless, sagacious, visionary, and intrinsically motivated’ (p444).

There is a tendency in project management to perceive greater rationality in

executive decision-making than may actually exist. Thus there is a belief that
the initial approval decision (or termination decision) for a project at executive
level will be based on ‘true business priority’ [74], economics (e.g. nett present
value, NPV) [73, 76, 79], salvage [77], formal processes [78], or other objective
criteria. It is probably more realistic to say that these only influence the
decision, and that decision-making is seldom purely rational but rather
ultimately based on intuition, selfishness, politics, etc., [96, 97].

Motivation of team members

Champions and sponsors aside, it is particularly at closure that an element of
local leadership is valuable. Leadership is needed to at this stage to maintain
motivation of the team:
‘During this phase, it is very important to maintain team effort and
enthusiasm as personnel tend to get disturbed over uncertainties about
their future role and sometimes their continuation in the job.’ [94]

212
There can be anxiety even in a project that ends normally. If the project is
terminated prematurely then the opportunity for anxiety is much greater, and
can demoralise staff [75].

This psychology aspect to project teams might seem paradoxical to some

practitioners, given that the purpose of the project in the first instance was
financial, and it is likewise generally assumed that people work on projects for
the financial (extrinsic) reward. In offering an explanation for this, it may be
helpful to partition motivation into extrinsic and intrinsic. Personal economic
profit is an extrinsic motivation, especially if a performance bonus is paid to
team members. Intrinsic motivation refers to deeply held personal motives for
performing some action, and in this regard goal-setting theory perhaps
explains the situation: people are motivated to achieve a goal they deem
challenging but feasible, because they seek the satisfaction that accomplishing
it will give them. The type of people who self-select into project roles perhaps
have a high need-for-achievement. Terminating the programme prematurely
denies them the satisfaction and sense of self-efficacy (hence self-worth), and
could be resisted.

Thus we are saying that even though the project itself might originally have
been motivated by the economic value, the team who implement it are not
emotionless automatons but instead attribute their own personal values and
hopes to the project and thereby motivate themselves. In this regard a project
is NOT simply a temporary economic endeavour [60], but a partnership
whereby a client obtains a tangible output of economic value, the hosting
organisation obtains a financial profit, and the individuals of the team obtain
an income and enhanced self-efficacy. To deny the self-efficacy component is
to miss out on an important part of the motivational reason for people to
undertake work.

Hypotheses for intrinsic motivation within project teams

We speculate that anticipation of project success provides some prior intrinsic
motivation to team members, and increases their self worth. However we
anticipate that all that changes at the end of the project, so there is a life-cycle
of motivation:
* Thus we expect that initially team members will be motivated by a sense
of an achievable challenge (goal-setting theory) [23]. Specific goals also
help set the definition of what level of output will be cause for
satisfaction [23], and the anticipatory seeking of that satisfaction is the
basis of motivation [24] (p1180). The challenging attribute of the goal

213
 causes the protagonist to change beliefs about self efficacy (3), which
positively affects commitment to the goals (4) [24].

* The successful completion of a project gives the team members a sense

of accomplishment. If the project ends normally, then as the project
nears completion that source of motivation turns to satisfaction (or not
as the case may be), and is used up. Instead new needs arise, e.g. the
need for ongoing employment. Unfortunately the project environment
often make ongoing roles uncertain, so the need cannot be fully met and
this can lead to anxiety.

* If the project is terminated prematurely, then the individual is denied

the sense of accomplishment (hence motivation may immediately
decline), and self-efficacy may be decreased. The person may actively
resist these outcomes, e.g. by seeking to have the project continued.

* In this theory the motivation for the between-project phase is based on

anticipation of the next project accomplishment (failure). Thus the
positive motivation is presumably conditional on the evidence that there
is going to be a next project or a positive belief that the psychological
contract with the employer is strong enough that some project
employment will be provided in the end even if none is currently
apparent. (This suggests that personal outlook and positive employment
relationships may be important in sustaining motivation in the lulls
between projects). The opportunity for de-motivation also exists, if the
individual perceives that there is no following project, or that the next
project is likely to result in failure. The de-motivational effect would be
particularly strong if the previous project had also failed. This is
consistent with other reported research:
‘Repeated negative feedback appears to induce individuals to see
each successive failure as more and more diagnostic. As a result,
even a short series of failed attempts evokes beliefs that future
attempts will also fail. These emergent expectations of failure,
generated by causal attribution processes, associative learning,
and/or discounting of ambiguous information, appear very
compelling and induce people to forgo profitable marginal
investments.’ [92]( p365)

214
Further research would be required to validate this theory. In the absence of
other theories it may at least be useful for identifying the types of issues
practitioners may consider.

215
References
1. IEM, Graduate Attributes and Professional Competencies 2013, International
Engineering Alliance.
2. Pugh, S., Total Design, Integrated Methods for Successful Product Engineering. 1991:
Addison Wesley.
3. Hales, C., Managing Engineering Design. 1994: Longman Scientific & Technical.
4. Pahl, G. and Beitz, W., Engineering Design: A systematic approach, ed. K.e. Wallace.
1988: Springer-Verlag (Berlin) and The Design Council (London).
5. IEM, Graduate Attributes and Professional Competencies International Engineering
Alliance, 2013. http://www.washingtonaccord.org/GradProfiles.cfm(23 Nov 2013).
6. Pons, D.J., Solving Complexity: Engineering Professional Practice in New Zealand.
Elements. Vol. 1230000538251. 2015: Kobo.
7. PMI, A guide to the project management body of knowledge (PMBOK guide). 3 ed.
2004, Newtown Square, Pa: Project Management Institute.
8. Gustafsson, A., Customer focused product development by conjoint analysis and QFD.
Vol. Dissertation No. 418. 1996: Linköping Studies in Science and Technology,
Division of Quality Technology, Department of Mechanical Engineering, Linköping
University, S-581 83 Linköping Sweden.
9. Martin, M.V., Kmenta, S., and Ishii, K., QFD and the designer: lessons from 200+
houses of quality. World Innovation and Strategy Conference, Sydney, Australia,
1998.
10. Mill, H.F., Simplifying the implementation of QFD. IEE Colloquium (Digest), 1994.
086(May 6): p. 5/1-5/4.
11. Roosen, T. and Pons, D.J., Environmentally Lean Production: The Development and
Incorporation of an Environmental Impact Index into Value Stream Mapping. Journal
of Industrial Engineering, 2013. 2013(298103): p. 1-17.DOI:
http://dx.doi.org/10.1155/2013/298103.
12. FIPS. Integration Definition for Function Modeling (IDEF0). 1993 12 Aug 2003];
Available from: http://www.itl.nist.gov/fipspubs/idef02.doc.
13. KBSI. IDEF0 Overview. 2000 12 Aug 2003]; Available from:
http://www.idef.com/IDEF0.htm.
14. Lawry, K. and Pons, D.J., Integrative Approach to the Plant Commissioning Process.
Journal of Industrial Engineering, 2013. 2013(572072): p. 1-12.DOI:
http://dx.doi.org/10.1155/2013/572072.
15. Pons, D.J., Postgraduate research through the production lens. Journal of Adult
Learning in Aotearoa New Zealand, 2011. 39(1): p. 107-145.
16. Pons, D.J., System model of production inventory control. International Journal of
Manufacturing Technology and Management (IJMTM), 2010. 20(No.1-4): p. 120 -
155.DOI: http://dx.doi.org/10.1504/IJMTM.2010.032895.
17. Pons, D.J., Ventures of co-ordinated effort International Journal of Project
Organisation and Management, 2012. 4(3): p. 231-255.DOI:
10.1504/IJPOM.2012.048221.

216
18. Pons, D.J., Strategic risk management in manufacturing. The Open Industrial &
Manufacturing Engineering Journal, 2010. 3: p. 13-29.DOI:
http://dx.doi.org/10.2174/1874152501003010013.
19. PMI, A guide to the project management body of knowledge (PMBOK guide) 4ed.
2008, 14 Campus Blvd, Newtown Square, Pennsylvania, USA: Project Management
Institute.
20. Haugan, G.T., Effective work breakdown structures. 2002, Vienna, Virginia, USA:
Management Concepts.
21. Hubka, V. and Eder, W.E., Design Science. 1996, Berlin: Springer-Verlag.
22. Locke, E.A., Toward a theory of task motivation and incentives. Organizational
Behavior and Human Performance, 1968(May): p. 157-189.
23. Locke, E.A. and Latham, G.P., Work motivation and satisfaction: Light at the end of
the tunnel. Psychological Science, 1990. 1(4): p. 240-246.
24. Bandura, A., Human Agency in Social Cognitive Theory. American Psychologist, 1989.
44(9): p. 1175-1184.
25. Somani, S., On deadline, in PM Network. 2008, PMI. p. 25.
26. Vose, D., Quantitative risk analysis. 1996: Wiley.
27. CAIB, Columbia Accident Investigation Board: Report Volume II, in Columbia Accident
Investigation Board, October 2003, http://www.caib.us. 2003, Columbia Accident
Investigation Board, http://www.caib.us.
28. Horlick-Jones, T., Meaning and contextualisation in risk assessment. Reliability
Engineering & System Safety, 1998. 59(1): p. 79-89.
29. Pidgeon, N., Risk assessment, risk values and the social science programme: why we
do need risk perception research. Reliability Engineering & System Safety, 1998.
59(1): p. 5-15.
30. Slovic, P., The risk game. Reliability Engineering & System Safety, 1998. 59(1): p. 73-
77.
31. Jasanoff, S., The political science of risk perception. Reliability Engineering & System
Safety, 1998. 59(1): p. 91-99.
32. Robbins, S.P., Millett, B., Cacioppe, R., and Waters-Marsh, T., Organisational
behaviour: leading and managing in Australia and New Zealand. 3 ed. 2001, Frenchs
Forest NSW, AU: Prentice Hall.
33. Bley, D., Kaplan, S., and Johnson, D., Strengths and limitations of PSA: Where we
stand. Reliability Engineering & System Safety, 1992. 38: p. 3-26.
34. Ullman, D.G., Herling, D., and D'Ambrosio, D., What to do next: using problem status
to determine the course of action. Research in Engineering Design, 1997, 1997. (9): p.
214-227.
35. Ullman, D.G., Toward the Ideal Mechanical Engineering Design Support System.
Research in Engineering Design, 2002. 13(2, 2002): p. 55-64.
36. Herroelen, W. and Leus, R., Project scheduling under uncertainty: Survey and
research potentials. European Journal of Operational Research, 2005. 165(2): p. 289-
306.
37. Pate-Cornell, M.E., Uncertainties in risk analysis: Six levels of treatment. Reliability
Engineering & System Safety, 1996. 54: p. 95-111.
38. Meredith, J.R. and Mantel, S.J., Project management: a managerial approach. 5 ed.
1995, New York: Wiley.

217
39. Pons, D.J. and Raine, J., Relative effectiveness of mechanisms for simulating
uncertainty in quantitative systems. Journal of Engineering Manufacture, 2003. 217:
p. 531-540.
40. Zheng, D.X.M. and Ng, S.T., Stochastic Time–Cost Optimization Model Incorporating
Fuzzy Sets Theory and Nonreplaceable Front., in Journal of Construction Engineering
& Management. 2005, American Society of Civil Engineers. p. 176-186.
41. Springer, M.D., The algebra of random variables. 1979, New York: John Wiley & Sons.
42. Syski, R., Random Processes. Second ed. 1989, New York: Marcel Dekker Inc.
43. Sarper, H., Capital rationing under risk: a chance constrained approach using
uniformly distributed cash flows and available budgets. Engineering Economist 39 1
Fall 1994 IIE p 49-76 0013-791X, 1994.
44. Shih, N.-H., Estimating completion- time distribution in stochastic activity networks.
Journal of the Operational Research Society, 2005. 56(6): p. 744-749.
45. Basu, A., Practical risk analysis in scheduling. AACE International. Transactions of the
Annual Meeting Jun 28-Jul 1 1998 1998 AACE Inc. 4p, 1998.
46. Croll, G., Cost & schedule risk analysis in major engineering projects. IEE Colloquium
(Digest) 183 Oct 30 1995 IEE p 4/1-4/4 0963-3308, 1995.
47. Finley, E.D. and Fisher, D.J., Project scheduling risk assessment using Monte Carlo
methods. Cost Engineering (Morgantown, West Virginia) v 36 n 10 Oct 1994 AACE p
26-28, 1994.
48. Cooper, D.F. and Chapman, C.B., Risk analysis for large projects. 1987: John Wiley &
Sons.
49. Pons, D.J. and Raine, J., Design with uncertain qualitative variables under imperfect
knowledge. Journal of Engineering Manufacture, 2004. 218(8): p. 977-986.
50. Tuckman, B.W., Developmental sequence in small groups. Psychological Bulletin,
1965. 63(6): p. 384-399.DOI: 10.1037/h0022100.
51. Turner, J.R., Towards a theory of project management: The nature of the project
governance and project management. International Journal of Project Management,
2006. 24(2): p. 93-95.
52. Siegelaub, J.M. Looking for Your Sponsor? - The PRINCE2™ Project Board Approach to
Senior Management Engagement. 2008 24 Feb 2009]; Available from:
http://www.butrain.com/business-management-training-
courses/LookingForYourSponsor.asp.
53. Swift, D., Statement of Work (SOW) Writing Guide. 2009, RFP SOLUTIONS
http://www.rfpsolutions.ca/files/SOW_Writing_Guide2.pdf: Ottawa.
54. IPENZ, Guidelines on the briefing and engagement for engineering consultancy
services. 2004, IPENZ: Wellington.
55. IPENZ, Practice Note 06: Developing and Maintaining Client Relationships. 2005,
IPENZ: Wellington.
56. Walton, J., ALLIANCING CONTRACTS: Panacea to All That Ails?, in e.nz magazine.
2008, IPENZ: Wellington. p. 40-44.
57. Raea, S., Making molehills out of mountains, in e.nz magazine. 2008, IPENZ:
Wellington. p. 18-22.
58. IPENZ. IPENZ Code of Ethics. 2009 12 June 2009]; Available from:
http://www.ipenz.org.nz/ipenz/who_we_are/ethics_inc.cfm.
59. Simon, H.A., The sciences of the artificial. 2 ed. 1981, Massachusetts: The MIT Press,.
60. Brandel, M., Not So Fast! Computerworld, 2006. 40(3): p. 37-39.

218
61. Kloppenberg, T.J. and Petrick, J.A., Managing Project Quality. Quality Progress, 2004.
37(9): p. 63-72.
62. Aitken, S.B., High Level Waste Tank Closure Project: ALARA Applications at the Idaho
National Engineering and Environmental Laboratory. Health Physics, 2005. 88(5): p.
S91-S96.
63. GAO, Nuclear Cleanup: Preliminary Results of the Review of the Department of
Energy's Rocky Flats Closure Projects: GAO-05-1044. GAO Reports, 2005: p. 1.
64. GAO, Nuclear Cleanup: Progress Made at Rocky Flats, but Closure by 2006 Is Unlikely,
and Costs May Increase: GAO-01-284. GAO Reports, 2001: p. 1.
65. Ceran, T. and Dorman, A.A., The Complete Project Manager. Journal of Architectural
Engineering, 1995. 1(2): p. 67.
66. De, P.K., Project termination practices in Indian industry: a statistical review.
International Journal of Project Management, 2001. 19(2): p. 119.
67. Battelle, A.E., Small Claims Management: The Termination Case. Dispute Resolution
Journal, 2004. 59(1): p. 49-55.
68. Pretorius, C.J. and Steyn, H., Knowledge management in project environments. South
African Journal of Business Management, 2005. 36(3): p. 41-50.
69. Linstead, S., Resistance and Return: Power, Command and Change Management.
Studies in Cultures, Organizations & Societies, 1997. 3(1): p. 67-89.
70. Fontana, D., Personality in the workplace. 2000, London: Macmillan Press.
71. PMI, Pull the plug. PM Network, 2006. 20(6): p. 38-44.
72. Balachandra, R. and Brockhoff, K., Are R&D project termination factors universal?
Research Technology Management, 1995. 38(4): p. 31.
73. Cook, T. and Rizzuto, R., Capital Budgeting Practices for R&D: A Survey and Analysis
of Business Week's R&D Scoreboard. The Engineering Economist, 1989. 34(4): p. 291-
304.
74. Melymuka, K., Surviving THE Sponsor Exit. Computerworld, 2004. 38(7): p. 40.
75. Balachandra, R., Brockhoff, K.K., and Pearson, A.W., R&D Project Termination
Decisions: Processes, Communication, and Personnel Changes. Journal of Product
Innovation Management, 1996. 13(3): p. 245-256.
76. Dobson, J. and Dorsey, R., Reputation, Information and Project Termination in Capital
Budgeting. The Engineering Economist, 1993. 38(2): p. 143-152.
77. Messica, A. and Mehrez, A., Time-to-market, window of opportunity, and
salvageability of a new product development. Managerial and Decision Economics,
2002. 23(6): p. 371-378.
78. Rad, P.F. and Levin, G., A Formalized Model for Managing a Portfolio of Internal
Projects. AACE International Transactions, 2005: p. 04.1-04.5.
79. Statman, M. and Caldwell, D., Applying Behavioral Finance to Capital Budgeting:
Project Terminations. Financial Management (1972), 1987. 16(4): p. 7-15.
80. Dilts, D.M. and Pence, K.R., Impact of role in the decision to fail: An exploratory study
of terminated projects. Journal of Operations Management, 2006. 24(4): p. 378-396.
81. Guan, J., Liu, Q., and Peng, H., MAKING BETTER PROJECT TERMINATION DECISIONS.
Research Technology Management, 2002. 45(1): p. 13.
82. Vroom, V., Work and motivation. 1964, New York: John Wiley.
83. Boehne, D.M. and Paese, P.W., Deciding Whether to Complete or Terminate an
Unfinished Project: A Strong Test of the Project Completion Hypothesis.
Organizational Behavior & Human Decision Processes, 2000. 81(2): p. 178-194.

219
84. Garland, H., Throwing good money after bad: The effect of sunk costs on the decision
to esculate commitment to an ongoing project. Journal of Applied Psychology, 1990.
75(6): p. 728-731.
85. Garland, H., Sandefur, C.A., and Rogers, A.C., De-escalation of commitment in oil
exploration: When sunk costs and negative feedback coincide. Journal of Applied
Psychology, 1990. 75(6): p. 721-727.
86. Conlon, D.E. and Garland, H., THE ROLE OF PROJECT COMPLETION INFORMATION IN
RESOURCE ALLOCATION DECISIONS. Academy of Management Journal, 1993. 36(2):
p. 402.
87. Paese, P.W., Deciding Whether to Complete or Terminate an Unfinished Project: A
Strong Test of the Project Completion Hypothesis. Organizational Behavior and
Human Decision Processes, 2000. 81(2): p. 178-194.
88. Garland, H. and Conlon, D.E., Too Close to Quit: The Role of Project Completion in
Maintaining Commitment. Journal of Applied Social Psychology, 1998. 28(22): p.
2025-2048.
89. Girandola, F. and Gauthier, E., Organizational decision making: Effects of
accountability on escalation of commitment. European Review of Applied
Psychology, 2001. 51(1): p. 111-119.
90. He, X. and Mittal, V., The effect of decision risk and project stage on escalation of
commitment. Organizational Behavior & Human Decision Processes, 2007. 103(2): p.
225-237.
91. Moon, H., Looking forward and looking back: Integrating completion and sunk-cost
effects within an escalation-of-commitment progress decision. Journal of Applied
Psychology, 2001. 86(1): p. 104-113.
92. Zikmund Fisher, B.J., De-escalation after Repeated Negative Feedback: Emergent
Expectations of Failure. Journal of Behavioral Decision Making, 2004. 17(5): p. 365-
379.
93. Statman, M. and Sepe, J.F., Project Termination Announcements and the Market
Value of the Firm. FM: The Journal of the Financial Management Association, 1989.
18(4): p. 74-81.
94. Doshi, J.J., Project handing over mechanics. Chemical Business, 1999. 13(5): p. 185.
95. PMI, A guide to the project management body of knowledge (PMBOK guide). 2000,
Newtown Square, Pa: Project Management Institute.
96. Markham, S.K., Corporate Championing and Antagonism as Forms of Political
Behavior: An R&D Perspective. Organization Science, 2000. 11(4): p. 429.
97. Elton, J. and Roe, J., Bringing discipline to project management. Harvard Business
Review, 1998. 76(2): p. 153.
98. NIST. Criteria for performance excellence, Baldrige National Quality Progam. 2005;
Available from: http://www.quality.nist.gov/PDF_files/2005_Business_Criteria.pdf.

220