Project management inherently involves
high levels of risk, because projects by definition are being done
for the first time. There are a number of classical project domain
types, each with their own characteristics. For instance,
construction projects focus on inanimate objects, such as materials
that are transformed into some purposeful object. There are people
involved, although as time passes, more and more work is done by
machinery, with diminishing human control. Thus construction
projects are among the more predictable project domains. Government
projects often involve construction, but extend beyond that to
processes, such as the generation of nuclear material, or more
recently, the processing of nuclear wastes. Government projects
involve high levels of bureaucracy, and the only aspect increasing
predictability is that overlapping bureaucratic involvement of many
agencies almost ensures long time frames with high levels of
change. There is a very wide spectrum of governmental projects.
They also should include civil works, which drive most construction
projects. A third project domain is information system project
management, focusing on the development of software tools to do
whatever humans want. This field, like construction and
governmental projects, has been widely studied. It is found to
involve higher levels of uncertainty than construction projects,
because software programming is a precise activity, and getting a
computer code to work without bugs is a precise activity.
Seyedhoseini et al. 1 reviewed
risk management processes within projects, using the contexts of
general project management, civil engineering, software
engineering, and public application. Those authors looked at
sixteen risk management processes published over the period
1990–2005, spread fairly evenly over their four context areas,
identifying methodologies. These contexts all involve basic project
management, but we argue that each context is quite different.
Project management in civil engineering is usually easier to
manage, as the uncertain elements involve natural science (geology,
weather). However, there are many different types of risk involved
in any project, to include political aspects 2 and
financial aspects. 3 While these sources provide more
than enough uncertainty for project managers, there is a much more
difficult task facing software engineering project managers.
4
We argue that this is because people are more fundamental to the
software engineering production process, in the form of developing
systems, programming them, and testing them, each activity
involving high degrees of uncertainty. 5 Public
application projects are also unique unto themselves, with high
levels of bureaucratic process that take very long periods of time
as the wheels of bureaucracy grind slowly and thoroughly. Slowly
enough that political support often shifts before a project is
completed, and thoroughly enough that opposition of the
“not-in-my-backyard” is almost inevitably uncovered prior to
project completion.
Project Management Risk
The Project Management Institute views
risk as general to projects, and through the Project Management
Body of Knowledge (PMBOK) 6 , which develops standards,
policies and guidelines for project management. It focuses on tools
and techniques related to project management skills and
capabilities. Project management responsibilities include achieving
cost, schedule performance objectives. Risk management is a major
element of PMBOK, with major categories of:
-
planning,
-
risk identification,
-
quantitative risk analysis,
-
quantitative risk analysis,
-
risk response planning, and
-
risk monitoring and control.
The Project Risk Analysis and
Management (PRAM) Guide in the United Kingdom is very similar in
approach, 7 and fits the description of a
typical risk management program from other sources. Each of these
categories applies to all projects to some degree, although the
level of uncertainty can make variants of tools applied
appropriate. A number of recent papers have proposed risk
assessment methodologies in construction, based on an iterative
process of risk identification, risk analysis and evaluation, risk
response development, and administration. 8 The key is
to keep systematic records over time to record risk experiences,
with systematic updating. 9
Risk Management Planning
As with any process, inputs need to be
gathered to organize development of a cohesive plan. Things such as
the project purpose and stakeholders need to be identified,
followed by identification of tasks to be accomplished. This
applies to every kind of project. These tasks are cohesive
activities, usually accomplished by a specific individual or group,
and for each task estimation of duration and resources required, as
well as immediate predecessor activities is needed. This is the
input needed for critical path analysis, to be demonstrated in this
chapter. That quantitative approach deals with risk in the form of
probability distributions for durations (demonstrated in this
chapter through simulation).
But there are other risk aspects that
need to be considered. It is important to consider the
organization’s attitude toward risk, and qualitatively identify
things that can go wrong. Risk attitude depends upon stakeholders.
Identification of what might go wrong and stakeholder preference
for dealing with them can affect project management team roles and
responsibilities.
Risk management planning concludes
with a risk management plan. This plan should define methodologies
for dealing with project risks. Such methodologies can include
training internal staff, outsourcing activities that other
organizations are better equipped to deal with, or insurance in
various forms. Ultimately, every organization has to decide which
risks they are competent to manage internally (core competencies),
and which risks they should offload (at some expected cost).
Risk Identification
Once the risk management plan is
developed, it can naturally lead to the next step, risk
identification. The process of risk identification identifies major
potential sources of risk for the specific project. The risk
management plan identifies tasks with their risks, as well as
project team roles and responsibilities. Historical experience
should provide guides (usually implemented in the form of
checklists) to things that can go wrong, as well as the
organization’s ability to cope with them.
Specific types of risk can be viewed
as arising in various ways. A classical view is the triumvirate of
quality, time, and budget. Software projects are often said to
allow any two of the three—you can get code functioning as intended
on time, but it usually involves more cost than expected; you can
get functional code within budget as long as you are patient; you
can get code on time and within budget as long as you don’t expect
it to work as designed. This software engineering project view
often generalizes to other projects, but with some different
tendencies. In construction, there is less duration variance,
although unexpected delays from geology or the weather commonly
create challenges for project managers. If weather delays are
encountered, the tradeoff is usually whether to wait for better
weather, or to pay more overtime or extra resources. If geological
elements are creating difficulties, more time and money is usually
required. The functionality of the project is usually not degraded.
Governmental projects may involve emergency response, where time is
not something that can be sacrificed. The tradeoff is between
quality of response and cost. Usually emergency response teams do
the best they can within available resources, and public outcry
almost always criticizes the insufficiency of the effort.
There are a number of techniques that
can be used to identify risks. Some qualitative approaches include
interviews of experts or stakeholders, supplemented by techniques
such as brainstorming, the nominal group technique, the Delphi
method, or SWOT analysis (strengths, weaknesses, opportunities, and
threats). Each of these methods are relatively easy to implement,
and the quality of output depends on the participation of a diverse
group of stakeholders. Historical data can also be used if the
organization has experience with past projects similar to the
current activity. This works well if past experiences are
well-documented and retrieved efficiently.
The outputs from risk identification
is a more complete list of risks expected in the project, as well
as possible responses along with their expected costs. This results
in a set of responses that can be reviewed as events develop,
allowing project managers to more intelligently select appropriate
responses. While success can never be guaranteed, it is expected
that organizational project performance will improve.
Qualitative Risk Analysis
After a more precise estimation of
project element risk is identified, the relative probabilities and
risk consequences can be addressed. Initial estimations usually
require reliance on subjective expert opinion. Historical records
enable more precision, but one project element of importance is
that projects by definition almost always involve new situations
and activities. Experts have to judge the applicability of
historical records to current challenges.
A qualitative risk analysis can be
used to rank overall risks to the organization. A priority system
can be used to identify those risks that are most critical, and
thus require the greatest degree of managerial attention. In
critical path analysis terms, critical path activities would seem
to call for the greatest managerial attention. Behaviorally, humans
tend to work hardest when the boss is watching. However, the
fallacy of this approach is that other activities that are not
watched may become critical too if they delay too far beyond their
expected duration.
Qualitative risk analysis can provide
a valuable screening to cancel projects that are just too risky for
an organization. It also can affect project organization, with more
skilled personnel assigned to tasks that call for more careful
management. It also can be a guide to look for means to offload
risk, either through subcontracting, outsourcing, or
insurance.
Quantitative Risk Analysis
We will present more formal
quantitative tools in the following sections. Quantitative analysis
requires data. The critical path method calls for a specific
duration estimate, which we will demonstrate. Simulation is less
restrictive, calling for probability distributions. But this is
often more difficult for humans to estimate, and usually only works
when there is some sort of historical data available with which to
estimate probability distributions.
Quantitative risk analysis, as will be
demonstrated, can be used to estimate probabilities of project
completion times, as well as other items of interest that can be
included in what is essentially a spreadsheet model. These examples
focus on time. It is also possible to include cost
probabilities.
Risk Response Planning
Once risk analysis (qualitative,
quantitative, or both) is conducted, project managers are hopefully
in a more educated position to make plans and decisions to respond
to events. Risk response planning is this process of developing
options and reducing threats if possible. The severity of risks as
well as cost, time, and impact on project output (quality) should
be considered.
A broad categorization of risk
treatment strategies include:
-
Risk avoidance (adopting alternatives that do not include the risk at issue)
-
Risk probability reduction (act to reduce the probability of adverse event occurance)
-
Risk impact reduction (act to reduce the severity of the risk)
-
Risk transfer (outsourcing)
-
Risk transfer (insurance)
-
Add buffers to the project schedule
The process of project risk management
is for project decision makers to tradeoff the costs of each risk
avoidance strategy in light of organizational goals. The key to
success is for organizations to adopt those risks internally where
they have competency in dealing with the risk at issue, and to pay
some price to offload those risks outside of their core
competencies.
The output of risk response planning
can be a prioritized list of risks with potential responses. It
also can include assignment of specific individual responsibilities
for monitoring events and triggering planned responses.
Risk Monitoring and Control
This category of activity is
implementation of all prior categories. Accounting is the first
line of measurement of cost activity. Operational project
management personnel also need to keep on top of time and quality
performance as the project proceeds. When adverse events are
identified, corrective action (either adoption of contingency
plans, or development of alternative actions) need to be applied.
In the long run, it is important to document projects, both in
terms of specific time and cost experiences, as well a qualitative
case data to enable the organization to do better on future
projects.
Project Management Tools
A variety of risk management
implementation tools have been applied. We referred to PMBOK
earlier, which is intended to provide a process model to generic
risk management projects. There are other process models, to
include the Software Engineering Institute’s capability maturity
model (CMM). The five levels of the CMMI are shown in Table
12.1.
Table
12.1
Capability maturity model for software
engineering processes
|
Level
|
Features
|
Key processes
|
|---|---|---|
|
1 Initial
|
Chaos
|
Survival
|
|
2 Repeatable
|
Individual control
|
Software configuration management
Software quality assurance
Software subcontract management
Software project tracking &
oversight
Software project planning
Requirements management
|
|
3 Defined
|
Institutionalized process
|
Peer reviews
Intergroup coordination
Software product engineering
Integrated software management
Training program
Organization process definition
Organization process focus
|
|
4 Managed
|
Process measured
|
Quality management
Process measurement and analysis
|
|
5 Optimizing
|
Feedback for improvement
|
Process change management
Technology innovation
Defect prevention
|
The CMM level 1 covers software
engineering organizations that do nothing. The other four levels
involve distinctly different process areas, leading to better
control over software development. It should be noted that
attaining each level involves an organizational cost in added
bureaucracy, which requires a business decision on the part of each
organization. However, there is a great deal of research that
indicates that in the long run, software quality is improved
dramatically by moving from any level to the next higher level, and
that overall development cost and development time are improved.
This is a clear example of risk management—paying the price of more
formality to yield reduced risk in terms of product output. Other
process risk management models in software engineering include
Boehm’s spiral model, 10 which provides iterative risk
analysis throughout the phases of the software development.
Bannerman 11 categorized
software project risk management into the three areas of process
models (reviewed above), analystical frameworks (based on some
dimension such as risk source, the project life cycle, or model
elements), and checklists. Checklists are often found as the means
to implement risk management, with evidence of positive value.
12
Checklists can be (and have been) applied in any type of project.
To work well, the project must repeat a domain, as each type of
project faces its own list of specific risks. The value of a
checklist of course improves with the depth of experience upon
which it is based.
Simulation Models of Project Management Risk
We will focus on demonstrating
quantitative tools to project risk management. We will demonstrate
how simulation can be used to evaluate the time aspect of project
management risk. The models are based on critical path, which can
be modeled in Excel, enabling the use of distributions through
Crystal Ball simulation. We begin with a basic software engineering
project using a traditional waterfall model. Figure 12.1 gives a schematic of
the activities and their precedence relationships.
Fig.
12.1
Network for software installation
example
Table 12.2 gives the input
information, along with distributions assumed for each activity.
These distributions should be based on historical data if possible,
subjective expert judgment if historical data is not available.
Table
12.2
Software installation input data
|
Activity
|
Duration
|
Distribution
|
Predecessors
|
|---|---|---|---|
|
A Requirements analysis
|
3 weeks
|
Normal (3,0.3)
|
None
|
|
B Programming
|
7 weeks
|
Lognormal (7,1)
|
A
|
|
C Hardware acquisition
|
3 weeks
|
Normal (3,0.5)
|
A
|
|
D User training
|
12 weeks
|
Constant
|
A
|
|
E Implementation
|
5 weeks
|
Exponential (5)
|
B,C
|
|
F Testing
|
1 week
|
Exponential (1)
|
E
|
Figure 12.2 gives the Microsoft
Project output for this model.
Fig.
12.2
Microsoft Project model output
The Excel model based on critical path
analysis is given in Table 12.3.
Table
12.3
Crystal Ball model of software installation
project. ©Oracle. Used with permission
Some modeling adjustments were needed.
For all distributions, durations in weeks were rounded up in the
Duration column of Table 12.1. For normal distributions, a minimum of 0
was imposed. Note that the lognormal distribution in Crystal Ball
requires a shape parameter (constrained to be less than the mean).
Here the shape parameter is 5, the mean 7, and standard deviation
1. Also note that the exponential distribution’s mean is inverted,
so for E Implementation, 5 weeks becomes 0.2. Figure 12.3 gives the simulation
results (based on 1000 replications).
Fig.
12.3
Simulated software installation completion
time. ©Oracle. Used with permission
The average for this data was 18.62
weeks, compared to the critical path analysis 16 weeks (which was
based on assumed duration certainty). There was a minimum of 15
weeks (0.236 probability) and a maximum of 58 weeks. There was a
0.490 probability of exceeding 16 weeks.
There are other simulation systems
used for project management. Process simulation allows contingent
sequences of activities, as used in the Project Assessment by
Simulation Technique (PAST). 13
Governmental Project
We assume a very long term project to
dispose of nuclear waste, with activities, durations and
predecessor relationships given in Table 12.4.
Table
12.4
Nuclear waste disposal project
|
Activity
|
Duration
|
Distribution
|
Predecessors
|
|---|---|---|---|
|
A Decision staffed
|
60 weeks
|
None
|
|
|
B EIS
|
70 weeks
|
A
|
|
|
C Licensing study
|
60 weeks
|
A
|
|
|
D NRC
|
30 weeks
|
A
|
|
|
E Conceptual design
|
36 weeks
|
A
|
|
|
F Regulation compliance
|
70 weeks
|
E
|
|
|
G Site selection
|
40 weeks
|
A
|
|
|
H Construction permit
|
0
|
constant
|
D,F,G
|
|
I Construction
|
100 weeks
|
H
|
|
|
J Procurement
|
70 weeks
|
F SS, I SS + 5weeks
|
|
|
K Install equipment
|
72 weeks
|
I
|
|
|
L Operating permit
|
0
|
K
|
|
|
M Cold start test
|
16 weeks
|
K
|
|
|
N Readiness test
|
36 weeks
|
M
|
|
|
O Hot test
|
16 weeks
|
N
|
|
|
P Begin conversion
|
0
|
L,O
|
Table 12.5 gives the Excel
(Crystal Ball) model for this scheduling project. Normal
distributions were used for project manager controllable
activities, and lognormal distributions used for activities beyond
project manager control Figs. 12.4, 12.5, and 12.6.
Table
12.5
Model for governmental project
|
A
|
B
|
C
|
D
|
E
|
|
|---|---|---|---|---|---|
|
1
|
Activity
|
Duration
|
Start
|
End
|
|
|
2
|
A Decision staffed
|
=INT(CB.Normal(60,5))
|
None
|
0
|
=D2 + B2
|
|
3
|
B EIS
|
=INT(CB.Lognormal(70,10))
|
A
|
=E2
|
=D3 + B3
|
|
4
|
C Licensing study
|
=INT(CB.Lognormal(60,10))
|
A
|
=E2
|
=D4 + B4
|
|
5
|
D NRC
|
=INT(CB.Lognormal(30,5))
|
A
|
=E2
|
=D5 + B5
|
|
6
|
E Conceptual design
|
=INT(CB.Normal(36,6))
|
A
|
=E2
|
=D6 + B6
|
|
7
|
F Regulation compliance
|
=INT(CB.Normal(70,10))
|
E
|
=E6
|
=D7 + B7
|
|
8
|
G Site selection
|
=INT(CB.Normal(40,5))
|
A
|
=E2
|
=D8 + B8
|
|
9
|
H Construction permit
|
=0
|
D,F,G
|
=MAX(D5,D7,D8)
|
=D9 + B9
|
|
10
|
I Construction
|
=INT(CB.Lognormal(100,10))
|
H
|
=D9
|
=D10 + B10
|
|
11
|
J Procurement
|
=INT(CB.Normal(70,5))
|
F SS, I SS + 5weeks
|
=MAX(D7,D10 + 5)
|
=D11 + B11
|
|
12
|
K Install equipment
|
=INT(CB.Normal(72,5))
|
I
|
=E10
|
=D12 + B12
|
|
13
|
L Operating permit
|
=0
|
K
|
=E12
|
=D13 + B13
|
|
14
|
M Cold start test
|
=INT(CB.Lognormal(16,6))
|
K
|
=E12
|
=D14 + B14
|
|
15
|
N Readiness test
|
=INT(CB.Lognormal(36,6))
|
M
|
=E14
|
=D15 + B15
|
|
16
|
O Hot test
|
=INT(CB.Lognormal(16,6))
|
N
|
=E15
|
=D16 + B16
|
Fig.
12.4
Network for governmental project
Fig.
12.5
Gantt chart for governmental project
Fig.
12.6
Histogram of governmental project
completion time in months. ©Oracle. Used with permission
Minimum completion time based on 1000
replications was 280 months, and maximum 391 months. The mean was
332 months, with a standard deviation of 16 months. The
distribution of completion times appears close to normal. Table
12.6 gives the
probabilities of completion in 10-month intervals:
Table
12.6
Probability of Completion
|
Months
|
Probability
|
|---|---|
|
310
|
0.912
|
|
320
|
0.759
|
|
330
|
0.550
|
|
340
|
0.329
|
|
350
|
0.153
|
|
360
|
0.057
|
|
370
|
0.011
|
|
380
|
0.005
|
Conclusions
We have argued that there are a number
of distinct project types, to include more predictable projects
such as those encountered in civil engineering, highly
unpredictable projects such as encountered in software engineering,
and projects involving massive undertakings or emergency response
typically faced by government bureaucracies. There are many other
types of projects, of course. For instance, we did not discuss
military procurement projects, which are extremely important unto
themselves. This type of project is a specific kind of governmental
project, but here we focused more on emergency management (which
military operations is closer to).
We also presented a framework for
project risk analysis, based on PMBOK. This included a number of
qualitative elements which can be extremely valuable in project
management. But they are less concrete, and therefore we found it
easier to focus on quantitative tools. We want to point out that
qualitative tools are also very important.
The qualitative tools presented start
with the deterministic critical path method, which assumes no risk
in duration nor in resource availability. We present simulation as
a very useful means to quantify project duration risk. Simulation
allows any kind of assumption, and could also incorporate some
aspects of resource availability risk through spreadsheet
models.
While the ability to assess the
relative probability of risk is valuable, the element of
subjectivity should always be kept in mind. A simulation model can
assign a probability of any degree of precision imaginable, but
such probabilities are only as accurate as the model inputs. These
probabilities should be viewed as subject to a great deal of error.
However, they provide project managers with initial tools for
identification of the degree of risk associated with various
project tasks.
Notes
- 1.
Seyedhoseini, S.M., Noori S. and AliHatefi, M. 2008, Chapter 6: Two Polar Concept of Project Risk Management, in D. L. Olson and D. Wu, eds., New Frontiers in Enterprise Risk Management. Berlin: Springer, 77–106.
- 2.
Skorupka, D. (2008). Identification and initial risk assessment of construction projects in Poland, Journal of Management in Engineering 24:3, 120–127.
- 3.
Kong, D., Tiong, R.L.K., Cheah, C.Y.J., Permana, A. and Ehrlich, M. (2008). Assessment of credit risk in project finance, Journal of Construction Engineering and Management 134:11, 876–884.
- 4.
Chua, A.Y.K. (2009). Exhuming IT projects from their graves: An analysis of eight failure cases and their risk factors, Journal of Computer Information Systems 49:3, 31–39.
- 5.
Olson, D.L. (2004), Introduction to Information Systems Project Management, 2nd ed. NY: McGraw-Hill/Irwin.
- 6.
Project Management Institute (2013), A Guide to the Project Management Body of Knowledge, 5th ed.Newtown Square, PA: Project Management Institute.
- 7.
Chapman, C. (2006). International Journal of Project Management 24(4), 303–313.
- 8.
Schatteman, D., Herroelen, W., Van de Vonder, S. and Boone, A. (2008). Methodology for integrated risk management and proactive scheduling of construction projects, Journal of Construction Engineering and Management 134:11, 885–893.
- 9.
Choi, H.-H. and Mahadevan, S. (2008). Construction project risk assessment using existing database and project-specific information, Journal of Construction Engineering and Management 134:11, 894–903.
- 10.
Boehm, B. (1988). Software Risk Management. Washington, DC: IEEE Computer Society Press.
- 11.
Bannerman, P.L. (2008). Risk and risk management in software projects: A reassessment, The Journal of Systems and Software 81:12, 2118–2133.
- 12.
Keil, M., Li, L., Mathiassen, L. and Zheng, G. (2008). The influence of checklists and roles on software practitioner risk perception and decision-making, The Journal of Systems and Software 81:6, 908–919.
- 13.
Cates, G.R. and Mollaghasemi, M. (2007). The Project Assessment by Simulation Technique, Engineering Management Journal 19:4, 3–10.