Professional Documents
Culture Documents
Systems Engineering
by Dirk Pons
Edition 3
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
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
.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
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
12
Examples ....................................................................................................................... 89
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
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
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).
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).
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.
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
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.
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.
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.
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.
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.
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.
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
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.
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.
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.
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.
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.
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).
43
Test and integration side (ascending)
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.
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 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.
46
Work-streams and decision-making
Iteration
47
Communication: internal and external
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
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
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.
59
(3) Engineering features or
attributes of the product. May
(2) Functional be physical sub-systems, as here,
requirements are or design requirements more
scored with an generally.
importance.
Additional electronics
housed in mirror
Importance to user
Mirror shroud
Mirror pivot
near mirror
(1) Functional
curvature
requirements that the
pod
customer has of the
product, ex the
previous functional
analysis.
Aesthetic appearance of
mirror 3 5 1
Mirror adjustment to be
predictable and not 3 4 4
distracting
Mirror might detect and warn (5) Weighted total identifies which
of objects in blind-zone 2 5
of the engineering features are the
Mirror might detect and warn more important, in this case the
if something is coming and mirror drive mechanism.
driver has not looked at 4 5
mirror recently
Technology
importance
37 43 52 111 10 43 14 36 20
From the systems engineering perspective these activities are part of the
requirements analysis process, which seeks to take the client needs, in all the
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.
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.
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
boon, unexpected
advantage
value (benefit),
intended or perceived
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)
Analyse
technology risk New plant-design
with reduced
(equipment and risk of failure or
operators) harm
(9: MfR)
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]
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.
.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)
Confirming
Production of Frequent early recent
early drafts communication with agreements
client
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
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
Copyright Dirk Pons . File version: VisioDocument. Sheet: 21. Printed: 30 June, 2009
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.
.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
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
promised financial
outcomes (payment,
including timing thereof)
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
Copyright Dirk Pons . File version: VisioDocument. Sheet: 22. Printed: 20 August, 2009
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
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
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’.
.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.
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)
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
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.
.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.
There is also the possibility for win-win outcomes. Undoubtedly there are
situations where a certain project outcome can maximise value for both
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
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.
.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.
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.
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).
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)
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.
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.
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
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
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.
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’.
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).
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.
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.
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.
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).
97
Kim
Chun
Only enter names: the rest of the sheet is for other
information that will be covered later.
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.
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.
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.
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.
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 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.
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.
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.
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.
Such work may also be corrupt – it may be where the project is padded out to
include backhanders and favours.
113
sufficient
project scope
(deliverables/
function,
time, cost)
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.
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
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.
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.
Define the overall project objectives (e.g. extend the production capability of
the dishwasher assembly plant).
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.
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.
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.
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).
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.
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.
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.
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.
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.
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).
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.
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).
126
coordinated. Use this link where things have to come together at the
end.
Simple parallel links. This diagram shows several different ways of placing tasks
in parallel.
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.
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
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,
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
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.’
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.
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).
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!
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.
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).
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.
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.
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.
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.
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.
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)
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)
Copyright Dirk Pons . File version: VisioDocument. Sheet: 15. Printed: 18 May, 2009
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.
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.
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:
146
Total Cost = Fixed Cost + Resource Cost
Total cost is Fixed Cost: additional The software calculates this
computed by the costs for typically (see below) from the labour
software. The total equipment or bulk rate and the duration.
cost for the whole materials. This amount is Resource Cost is not explicitly
project is only shown entered by you as shown in standard views as it is
on the Gantt chart if project manager. Use the implied in ‘Total Cost’.
you have a summary column under
task for the whole view/table/cost. The cost Where
project. is the same however Resource Cost =
long the task takes. This (Labour rate x duration)
is the only cost you can + Once-off costs, e.g. delivery
enter in this view. + call-out cost
+ (material rate x material
usage)
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.
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
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.
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.
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].
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.
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.
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.
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.
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.
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].
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.
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).
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.
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.
167
Comparison of multiple methods of estimating duration.
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.
170
SUMMARY DIAGRAM
risk: change to
project scope
from client
Major redefinition
Changed
of project project plan
(4: Pm-3-4)
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.
172
Business
constraints:
Untruthful,
financial,
deceptive
time
message of
Direct project (3) reassurance
Defined
scope of
deliverables
customer Status
feedback reports
Change
requests
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
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.
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
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
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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].
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).
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 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].
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
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].
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.
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].
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].
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.
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.
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)
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
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
group behaviour
and politics
termination strategy
Select (natural closure,
termination forced closure
approach (9) transfer, piecemeal
integration, or stasis)
(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.
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.
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.
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
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
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).
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].
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.
213
causes the protagonist to change beliefs about self efficacy (3), which
positively affects commitment to the goals (4) [24].
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