4.planning Projects

04.
Planning Projects:
===========================================================================
4.1 Crashing project time,

4.2 Resource loading and leveling,
4.3 Goldratt's critical chain,
4.4 Project Stakeholders and Communication plan Risk Management in projects:
4.4.1 Risk management planning,
4.4.2 Risk identification and risk register,
4.4.3 Qualitative and quantitative risk assessment,
4.4.4 Probability and impact matrix.
4.4.5 Risk response strategies for positive and negative risks.
===========================================================================
4.1 Crashing project time: -
The Meaning Of Crashing

The process of shortening the time to complete a project is called crashing and is usually
achieved by putting into service additional labour or machines to one activity or more activities.
Crashing involves more costs. A project manager would like to speed up a project by spending as
minimum extra cost as possible. Project crashing seeks to minimize the extra cost for completion
of a project before the stipulated time.
Steps In Project Crashing
Assumption: It is assumed that there is a linear relationship between time and cost.
Let us consider project crashing by the critical path method. The following four-step procedure is
adopted.
Step 1
Find the critical path with the normal times and normal costs for the activities and identify the
critical activities.
Step 2
Find out the crash cost per unit time for each activity in the network.
This is calculated by means of the following formula.
𝐶𝑟𝑎𝑠ℎ cos𝑡 𝐶𝑟𝑎𝑠ℎ cos𝑡 − 𝑁𝑜𝑟𝑚𝑎𝑙 cos𝑡

=
𝑇𝑖𝑚𝑒 𝑝𝑒𝑟𝑖𝑜𝑑 𝑁𝑜𝑟𝑚𝑎𝑙 𝑡𝑖𝑚𝑒 − 𝐶𝑟𝑎𝑠ℎ 𝑡𝑖𝑚𝑒
Step 3
Select an activity for crashing. The criteria for the selection are as follows:
Select the activity on the critical path with the smallest crash cost per unit time. Crash this
activity to the maximum units of time as may be permissible by the given data.
Crashing an activity requires extra amount to be spent. However, even if the company is
prepared to spend extra money, the activity time cannot be reduced beyond a certain limit in
view of several other factors.
In step 1, we have to note that reducing the time of on activity along the critical path alone will
reduce the completion time of a project. Because of this reason, we select an activity along the
critical path for crashing.
1
Project Management Module-4
In step 3, we have to consider the following question:

If we want to reduce the project completion time by one unit, which critical activity will involve
the least additional cost?
On the basis of the least additional cost, a critical activity is chosen for crashing. If there is a tie
between two critical activities, the tie can be resolved arbitrarily.
Fig. 4.1
Step 4
After crashing an activity, find out which is the critical path with the changed conditions?
Sometimes, a reduction in the time of an activity in the critical path may cause a non-critical path
to become critical. If the critical path with which we started is still the longest path, then go to
Step 3. Otherwise, determine the new critical path and then go to Step 3.
Problem 1
A project has activities with the following normal and crash times and cost:
Activity Predecessor Normal Crash Time Normal Cost Crash Cost

Activity Time (Weeks) (Rs.) (Rs.)
(Weeks)
A - 4 3 8,000 9,000
B A 5 3 16,000 20,000
C A 4 3 12,000 13,000
D B 6 5 34,000 35,000
E C 6 4 42,000 44,000
2
F D 5 4 16,000 16,500
G E 7 4 66,000 72,000
H G 4 3 2,000 5,000
Determine a crashing scheme for the above project so that the total project time is reduced by 3
weeks.
Solution
We have the following network diagram for the given project with normal costs:
Fig. 4.2 Network Diagram of problem 1

Beginning from the Start Node and terminating with the End Node, there are two paths for the
network as detailed below:
Path I
A B D F
1 2 5 4 6 6 5 8
4
The time for the path = 4 + 5 + 6 + 5 = 20 weeks.

Path II
A C E G H
1 2 3 5 7 8
4 4 6 7 4
The time for the path = 4 + 4 + 6 + 7 + 4 = 25 weeks.
Maximum of {20, 25} = 25.
Therefore, Path II is the critical path and the critical activities are A, C, E, G and H. The non-
critical activities are B, D and F.
Given that the normal time of activity A is 4 weeks while its crash time is 3 weeks. Hence the
time of this activity can be reduced by one week if the management is prepared to spend an
additional amount. However, the time cannot be reduced by more than one week even if the
management may be prepared to spend more money. The normal cost of this activity is Rs. 8,000
whereas the crash cost is Rs. 9,000. From this, we see that crashing of activity A by one week
will cost the management an extra amount of Rs. 1,000. In a similar fashion, we can work out the
crash cost per unit time for the other activities also. The results are provided in the following
table.
3
Activity Normal Crash Normal Crash Crash Normal Crash

Time Time Cost Cost cost - Time - Cost
(Weeks) (Weeks) (Rs.) (Rs.) Normal Crash per
Cost Time unit
time
A 4 3 8,000 9,000 1,000 1 1,000
B 5 3 16,000 20,000 4,000 2 2,000
C 4 3 12,000 13,000 1,000 1 1,000
D 6 5 34,000 35,000 1,000 1 1,000
E 6 4 42,000 44,000 2,000 2 1,000
F 5 4 16,000 16,000 500 1 500
G 7 4 66,000 72,000 6,000 3 2,000
H 4 3 2,000 5,000 3,000 1 3,000
A non-critical activity can be delayed without delaying the execution of the whole project. But, if
a critical activity is delayed, it will delay the whole project. Because of this reason, we have to
select a critical activity for crashing. Here we have to choose one of the activities A, C, E, G and
H . The crash cost per unit time works out as follows:
Rs. 1,000 for A; Rs. 1,000 for C; Rs. 1,000 for E; Rs. 6,000 for G; Rs. 3,000 for H.
The maximum among them is Rs. 1,000. So we have to choose an activity with Rs.1,000 as the
crash cost per unit time. However, there is a tie among A, C and E. The tie can be resolved
arbitrarily. Let us select A for crashing. We reduce the time of A by one week by spending an
extra amount of Rs. 1,000. After this step, we have the following network with the revised times
for the activities:
Fig. 4.2 Modified Network Diagram of problem 1 after crashing activity A
The revised time for Path I = 3 + 5 + 6 + 5 = 19 weeks.

The time for Path II = 3 + 4 + 6 + 7 + 4 = 24 weeks.
Maximum of {19, 24} = 24.
Therefore Path II is the critical path and the critical activities are A, C, E, G and H. However, the
time for A cannot be reduced further. Therefore, we have to consider C, E, G and H for crashing.
Among them, C and E have the least crash cost per unit time. The tie between C and E can be
resolved arbitrarily. Suppose we reduce the time of C by one week with an extra cost of Rs.
1,000.
After this step, we have the following network with the revised times for the activities:
4
Fig. 4.2 Modified Network Diagram of problem 1 after crashing activity C
The time for Path I = 3 + 5 + 6 + 5 = 19 weeks.

The time for Path II = 3 + 3 + 6 + 7 + 4 = 23 weeks.
Maximum of {19, 23} = 23.
Therefore Path II is the critical path and the critical activities are A, C, E, G and H. Now the time
for A or C cannot be reduced further.
Therefore, we have to consider E, G and H for crashing. Among them, E has the least crash cost
per unit time. Hence we reduce the time of E by one week with an extra cost of Rs. 1,000.
By the given condition, we have to reduce the project time by 3 weeks. Since this has been
accomplished, we stop with this step.
Result: We have arrived at the following crashing scheme for the given project:
Reduce the time of A, C and E by one week each.
Project time after crashing is 22 weeks.
Extra amount required = 1,000 + 1,000 + 1,000 = Rs. 3,000.
Network Diagram For the Constrained Resources

A network diagram is the graphical representation of a detailed project plan; it illustrates the job
logic and basic activity sequencing. In general, a network diagram shows the ‘big picture,’ what
is going to happen and in what order. In this way, it is an accurate, efficient, and reliable review
method to prevent any bad logic from getting “lost” in the scheduling software. Thus, it is very
important that interested parties understand how to read and evaluate these diagrams. The most
popular, powerful, flexible, and effective diagramming method used in the construction industry
is the Precedence Diagramming Method (PDM)—used by nearly every scheduling software—
due to its ease of creation and use, and due to its incorporation of the four major activity
relationships. A single node represents an activity and is logically connected to other activities
by a line or arrow, as represented in Figure 4.3. Like other methods, PDM has rules and
standards. Figure 4.4 shows the standard nomenclature for activities in a precedence network.
Fig. 4.3: Precedence

Fig. 4.4 : Standard Precedence Diagramming Nomenclature
Diagramming
5
The activities for successful project completion have been identified, their durations determined,
and their sequence defined; all that remains is knowing exactly when they will occur, the specific
time associated with their sequence. Essentially, the PDM puts the pieces of the plan together,
preparing them for the scheduling process. Figure 4 shows an example precedence diagram
where the basic job logic is applied in order to sequence the activities. The figure shows a very
simple sub-network with very few activities, very straightforward logic, and no smart
relationships. Nonetheless, a well-modeled network diagram for even the most complicated
project is absolutely necessary. The scheduling of the model is only as effective as the model
represents reality. Accordingly, in order that scheduling has any relevance, planning must define
inputs that closely model the actual construction of the project.
Fig. 4.5: Example Precedence Network

The Process
Once the project network is diagrammed and durations have been assigned to activities, the
schedule is ready for calculation. CPM uses a forward and backward pass to calculate the
following important scheduling information for each activity: early start (ES), early finish (EF),
late start (LS), late finish (LF), and the float. (These topics will be thoroughly discussed in the
Outputs section) The starts and finishes determined are in ordinal days—time not bound to a
calendar or time period, but a unit of time. Thus, the sequential ordinal days are then converted
to calendar days, from which a complete construction schedule is developed. Scheduling is not
an easy process, but with the aid of computer-based software, the tedious and repetitive parts of
scheduling are performed instantly. Modern calculations are performed by intelligent computer-
based scheduling software. Inside the “black box,” the software performs all the tedious
calculations and iterations instantaneously. However, schedules produced by software are only as
relevant as the inputs are reflective of the actual construction plan. And, the produced schedule is
only as accurate as the software correctly applies the rules of CPM and resource leveling.
4.1 Forward Pass
The forward pass is the process of navigating through a network from start to finish and
calculating the early dates for each activity and the completion date of the project [Mubarak
2005]. Specifically, the forward pass through an activity network yields the early start and early
finish of each activity and the minimum total project duration. The process assumes that all
6
activities in the network will start as soon as possible; each activity will start just as soon as the
last of its predecessors finishes. Furthermore, the activities will finish as soon as possible;
thereafter, succeeding activities will start immediately. The process starts with the first activity
and time zero. The early finish (EF) is found by simply adding the duration of the activity to its
earliest start. The early start (ES) for an activity is the earliest an activity can start; therefore, the
early start is the same as the early finish of a preceding activity. However, if more than one
activity precedes an activity, the early start comes from the latest finish of all preceding
activities. Figure 5 illustrates the ease of the forward pass on a network without smart
relationships.
Fig. 4.6: Basic Forward Pass Example

Adding SS, FF, SF relationships and leads and lags significantly complicates the process. But,
the definitions of early start and finish remain the same. When performing the forward pass with
smart relationships and leads and lags, collect all the possible ES for each activity and choose the
latest ES from the list. For FF and SF relationships, find the ES by first finding the EF and
subtract the activity’s duration. Figure 6 demonstrates how the forward pass becomes more
complex when relationships and time are added to more realistically model a construction
project.
Fig. 4.76: Forward Pass with Smart Relationships
7
If multiple calendars are employed, forward pass calculations follow this rule: if the ES or EF of
the successor calculated directly from the predecessor is a non-working day, the early time
should be postponed to the next available working date in order to satisfy the minimum time
interval. Clearly, multiple calendars add another layer of complexity, making even the simple
forward pass time consuming and very complicated.
4.2 Backward Pass

The backward pass is the process of navigating through a network from finish to start and
calculating the late dates for all activities [Mubarak 2005]. Specifically, the backward pass
yields the late start and late finish of each activity and further helps identify the critical path and
float times. The backward pass assumes that all activities in the network will start and finish as
late as possible; each activity will finish as the earliest of its successors starts. Moreover, the
process assumes that all preceding activities will also finish as late as possible. Working
backward, from finish to start, the process starts with the final activity and assumes the zero-float
convention, which uses the exact number of days calculated by the forward pass as its starting
point. The late start (LS) is found by simply subtracting the duration from the LF if there is a
single succeeding activity. In the event of multiple successors, the late finish is the earliest late
start of all succeeding activities. Figure 7 illustrates the ease of the backward pass on a network
without smart relationships.
Adding SS relationships and leads and lags significant complicates the process. But, the
definitions of late start and finish remain the same. When performing the backward pass with
smart relationships and leads and lags, collect all the possible LF for each activity and choose the
earliest from the list. For SS relationships, find the LF by first finding the LS and adding the
activity’s duration. Figure 8 demonstrates how the backward pass becomes increasingly more
complicated.
Fig. 4.8: Backward Pass Example

Again, if multiple calendars are involved, backward pass calculations follow this rule: if the LS
or LF of the predecessor calculated directly from the successor is a non-working day, the late
time should be advanced to the previous available working date in order to satisfy the minimum
time interval. To reemphasize, multiple calendars add another layer of complexity to even the
simplest of CPM calculations, making them very difficult and tedious.
8
Fig. 4.9 : Backward Pass with Smart Relationships
4.2 Resource loading and leveling: -
Resource Loading
Resource loading describes the amounts of individual resources an existing schedule requires
during specific time periods. Therefore, it is irrelevant whether we are considering a single work
unit or several projects; the loads (requirements) of each resource type are simply listed as a
function of time period. Resource loading gives a general understanding of the demands a project
or set of projects will make on a firm’s resources. It is an excellent guide for early, rough project
planning. Obviously, it is also a first step in attempting to reduce excessive demands on certain
resources, regardless of the specific technique used to reduce the demands. Again, we caution the
PM to recognize that the use of resources on a project is often nonlinear. Much of the project
management software does not recognize this fact. If resources of a project are increased by X
percent, the output of the project usually does not increase by X percent, and the time required
for the project does not decrease by X percent. The output and time may not change at all, or may
change by an amount seemingly not related to X. An increase of 20 percent in the number of
notes played does not necessarily improve the quality of the music. Any time the resource base
of a project is altered from standard practice, the risk that the project may not be successful is
changed, often increased. Given a WBS, deriving a resource-loading document is not difficult.
The part of the WBS lists the personnel resources needed for each activity. Utilizing data in the
WBS, MSP generated the resource usage profile or calendar. Each of the human resources used
in the project is listed, followed by the name of the activities in which the resource is used. The
total hours of work for each resource called for by the WBS are shown together with the amount
planned for each activity. The schedule for resource loading is derived and the loading is then
shown for each resource for each week (or day or month) of the project. It should be clear that if
the information in this calendar were entered into an Excel® spreadsheet along with estimates of
the variability of resource times, Crystal Ball® could be used to simulate the resource loading for
any or all of these resources. Because the project WBS is the source of information on activity
9
precedence, durations, and resources requirements, it is the primary input for both the project
schedule and its budget. The WBS links the schedule directly to specific demands for resources.
Thus, the AOA network technique can be modified to generate time-phased resource
requirements. A Gantt chart could be adapted, but the AOA diagram, particularly if modified to
slacks, will be helpful in the analysis used for resource leveling.
Let us illustrate with the AOA network is illustrated in Figure 4.10, and resource usage is
illustrated for two hypothetical resources, A and B, on the arcs. The expected activity time is
shown above the arc, and resource usage is shown in brackets just below the arc, with the use of
A shown first and B second—for example, [5,3] would mean that five units of A and three units
of B would be used on the activity represented by the arc. Figure 4.11 shows the “calendarized”
AOA diagram, similar to the familiar Gantt chart.
Resource demands can now be summed by time period across all activities. The loading diagram
for resource A is illustrated in Figure 4.12 and that for resource B in Figure 4.13. The loads are
erratic and vary substantially over the duration of the project.
Fig. 4.10. AOA Network for illustration of Resource loading
Fig. 4.11. Modified AOA diagram showing activity slack and resource usage (from Figure
4.10)
Resource A, used in tasks a, b, and c, has a high initial demand that drops through the middle of
the project and then climbs again. Resource B, on the other hand, has low initial use but
increases as the project develops. The PM must be aware of the ebbs and flows of usage for each
input resource throughout the life of the project. It is the PM’s responsibility to ensure that the
required resources, in the required amounts, are available when and where they are needed. In
the next three sections, we will discuss how to meet this responsibility.
10
Fig. 4.12 Load diagram for resource A
Fig. 4.13 Load diagram for resource B
Resource Leveling
Resource leveling, or smoothing, is a method for developing a schedule that attempts to
minimize the fluctuations in requirements for resources. This method levels the resources so that
they are applied as uniformly as possible without extending the project schedule beyond its
required completion time. It is a trial-and-error method in which the start of noncritical activities
(those with positive slack values) are delayed beyond their earliest start times (but not beyond
their latest start times) to maintain a uniform level of required resources. Activities can be
delayed only to the point where all their positive slack is used up, as any further delays would
cause the project to extend beyond the project required completion time. Resource-leveling
attempts to establish a schedule in which resource utilization is made as level as possible without
extending the project beyond its required completion time. To reiterate, construction project
success depends heavily on efficiently utilizing limited and costly resources—labor, materials,
and equipment. A resource-loaded schedule demonstrates the interdependencies between
activities and resources. Once resources are applied to an activity, the project resources should be
leveled (or smoothed) to improve work efficiency and minimize costs. Formally, resource
leveling minimizes the fluctuation in daily resource usage throughout the life of the project by
shifting non-critical activities within their available float. To smooth resources realistically, the
scheduler must employ resource constraints, because no contractor has unlimited resources. The
constraints placed on resources should reflect the most likely amount of labor, equipment, and
materials available to the contractor under normal conditions. The constraints supersede the
original project duration; meaning, the project duration is extended if the constraints cannot be
11
met by using the available total float. Hence, these resource limitations may drive the schedule,
changing the critical path. Figures 4.14 and 4.15 illustrate how leveling resources may or may
not extend the project duration.
Fig. 4.14: Resource leveling without constraints (within original project duration)
Fig. 4.15: Resource leveling with constraints (project duration extended 2 days)
12
Problem 2
Consider the following problem of project scheduling. Obtain a schedule which will minimize
the peak manpower requirement and smooth out period to period variation of manpower
requirement.
Activity Duration in Weeks Manpower requirements

1-2 6 8
1-3 10 4
1-4 6 9
2-3 10 7
2-4 4 6
3-5 6 17
4-5 6 6
Fig. 4.16 Manpower Requirement for problem 2
The corresponding manpower requirement histogram is shown below.
Fig. 4.17 Improvement in Manpower Requirement for problem 2
13
From this figure, it is observed that the peak manpower requirement is 21 and it occurs from 0 to
6 weeks. The activities which are scheduled during the period are: (1-2), (1-3) and (1-4). The
activity 1-2 is critical activity. So it should not be disturbed. Between activities (1-3) and (1-4),
the activity (1-3) has high slack value of 6 weeks (whereas its only 4 weeks for (1-4)). Hence, it
can be started at the end of 6 weeks. The corresponding modification is shown by the following
histogram.
Fig. 4.18 Leveling of Manpower Requirement for problem 2
The manpower requirement is now smooth throughout the project duration.
Problem 3
Cables By Us is bringing a new product on line to be manufactured in their current facility in
existing space. The owners have identified 11 activities and their precedence relationships.
Develop an AON for the project, Plot on Gantt chart and calculate the slack.
Activity Description Immediate Optim Most Pessim

Predecessor istic Likely istic
(to) (tm) (tp)
A Develop product specifications None 2 4 6
B Design manufacturing process A 3 7 10
C Source & purchase materials A 2 3 5
D Source & purchase tooling & equipment B 4 7 9
E Receive & install tooling & equipment C 12 16 20
F Receive materials D 2 5 8
G Pilot production run E&F 2 2 2
H Evaluate product design G 2 3 4
I Evaluate process performance G 2 3 5
J Write documentation report H&I 2 4 6
K Transition to manufacturing J 2 2 2
Solution
Step-1 Calculate Estimated Time ( te)
Activity Optimistic (to) Most Likely (tm) Pessimistic (tp) Estimated Time (te)
A 2 4 6 4
B 3 7 10 6.83
14
C 2 3 5 3.17
D 4 7 9 6.83
E 12 16 20 16
F 2 5 8 5
G 2 2 2 2
H 2 3 4 3
I 2 3 5 3.17
J 2 4 6 4
K 2 2 2 2
Draw network diagram
Fig. 4.19 Network diagram of problem 3

Step-2 Find Connected Paths and Calculate the Project Completion Times
1. A,B,D,E,G,H,J,G=44.66
2. A,B,D,E,G,I,J,G=44.83
3. A,C,F,G,H,J,K=23.17
4. A,C,F,G,I,J,K=23.34
ABDEGIJK is the expected critical path & the project has an expected duration of 44.83 weeks
Now, We know that
• All activities on the critical path have zero slack
• Slack defines how long non-critical activities can be delayed without delaying the
project
• Slack = the activity’s late finish minus its early finish (or its late start minus its early
start)
• Earliest Start (ES) = the earliest finish of the immediately preceding activity
• Earliest Finish (EF) = is the ES plus the activity time
• Latest Start (LS) and Latest Finish (LF) = the latest an activity can start (LS) or finish
(LF) without delaying the project completion
Step-3 Draw ES, EF Network
Fig. 4.20 Network diagram of problem 3 with ES & EF
15
Gantt Chart Showing Each Activity Finished at the Earliest Possible Start Date
Fig. 4.21 Gantt Chart of problem 3
Step-4 Draw LS, LF Network
Fig. 4.22 Network diagram of problem 3 with ES, EF, LS & LF
Gantt Chart Showing the Latest Possible Start Times if the Project Is to Be Completed in 44.83
Weeks
Fig. 4.23 Modified Gantt Chart of problem 3
16
Step-5 Calculating Slack

ACTIVITY LATE FINISH EARLY FINISH SLACK ( WEEKS)
A 4 4 0
B 10.83 10.83 0
C 28.66 7.17 31.51
D 17.66 17.66 0
E 33.66 33.66 0
F 33.66 12.17 21.49
G 35.66 35.66 0
H 38.83 38.66 0.23
I 38.83 38.83 0
J 42.83 42.83 0
K 44.83 44.83 0
4.3 Goldratt's critical chain: -

In the previous section, we showed that the problem of constrained resource scheduling of
multiple projects could be reduced to the problem of scheduling activities using scarce resources
in the case of a single project. However, the best-known attack on the resource constrained
scheduling problem is Goldratt’s Critical Chain (1997). The celebrated author applies his Theory
of Constraints to the constrained resource scheduling problem. The original focus of the Theory
of Constraints to project management was the single project case, but it, too, is just as applicable
to multiple projects. If we consider all the comments we have heard about the problems PMs
have to deal with on a daily basis, many are brought up over and over again. Further, it is
interesting to note that these statements are made by PMs working in construction,
manufacturing, software development, R&D, marketing, communications, maintenance, and so
on and the list of industries could easily be extended. For example, the following issues are
raised with high frequency, and this short list is only indicative, not nearly exhaustive.
• Senior management changes the project’s scope without consultation, without warning, and
without changing the budget or schedule.
• Project due dates are unrealistic and set with little regard given to availability of resources.
• There is no possible way of accomplishing a project without exceeding the given budget.
• Project workloads and due dates are set by the sales group, not by the nature of the projects and
the level of resources needed.
• Project due dates are set unrealistically short as an “incentive” for people to work harder and
faster.
It appears that these, and many other, problems are generic. They are independent of the area of
application. Note that all of these issues concern trading off time, cost, and scope. To deal with
the strong optimistic bias in many project schedules, let us consider just a few of the things that
tend to create it.
1. Thoughtless optimism Some PMs, apparently with a strong need to deny that lateness could
be their fault, deal with every problem faced by their projects as strict exceptions, acts of chance
that cannot be forecast and hence need not be the subject of planning. These individuals simply
ignore risk management.
2. Capacity should be set to equal demand Some senior managers refuse to recognize that
projects are not assembly lines and are not subject to standard operations management line
17
balancing methods. “Resource Loading/Leveling and Uncertainty,” for proof of the need for
capacity to exceed demand for projects.
3. The “Student Syndrome” This phrase is Goldratt’s term for his view that students often
delay starting school projects until the last possible moment. The same tendency is observed in
projects where project team members delay the start of their work. The problem with delaying
the start of a task is that obstacles are frequently not discovered until the work has been
underway for some time. Delaying the start of a task diminishes the opportunity to cope with
these unexpected obstacles and increases the risk of completing the work late.
4. Multitasking to reduce idle time Consider a situation where there are two projects, A and B,
each with three sequential activities and with you as the only resource required by both projects.
Each activity requires 10 days. In Figure 9.13 see two Gantt charts for sequencing the activities
in the two projects. In the first, switch from project A (dark) to project B (light) for each of the
three activities, that is, carry out Activity 1 for project A, then Activity 1 for project B, then
Activity 2 for A, and so forth. In the second sequence, complete project A before starting project
B. In both cases, the total time required will be 60 days. In the second, note that project A is
completed after 30 days and B after 60 days. In the first chart, however, Project A will be
finished after 50 days and B after 60 days. While the total time required is the same, project A
has been delayed for 20 days by the multitasking. Further, this ignores the startup time and loss
in efficiency that often accompanies switching back and forth between tasks.
5. Complexity of networks makes no difference Consider two different projects as seen in
Figure 9.14. Assume that each activity requires 10 days and is known with certainty. Clearly,
both projects are completed in 40 days though one is considerably more complex than the other.
But let’s get a bit more real. Assume that each activity is stochastic, with normally distributed
times. The mean time is 10 days, and the standard deviation is 3 days. If we simulate the projects
500 times, we get the mean project completion time of about 40 days and for the simulation of
the complex network, its mean completion time is about 46 days. Complexity, uncertainty and
merging paths all join to make trouble.
6. People need a reason to work hard Senior managers of our acquaintance have been known
to argue that project workers—and they include PMs in that category—“always” have enough
slack time in their activity duration estimates to make sure that they can complete the activities
on time and “without too much sweat.” Therefore, it makes some managerial sense to cut back
on the time allowances until they can serve as an incentive to the project team. It has, however,
long been known that for people with a high need for achievement, the maximum level of
motivation is associated with only moderate, not high, levels of risk of failure.
Fig.4. 24 Effect of multitasking on project completion.
18
Fig. 4.25 Two levels of 40 days network complexity
7. Game playing This is possibly the most common cause of late projects. It is certainly a major
cause of frustration for anyone involved in a project. Senior managers, firm in the belief that
project workers add extra time and resources to activity time and budget estimates in order to
insure a safe and peaceful life on their portion of a project, routinely cut schedules and budgets.
Project workers, suspecting that senior management will cut schedules and budgets without
regard to any logic or reason, increase their schedules and budgets as much as they guess will be
allowed. Each assumes that the other is not to be trusted. The outcome is simple. Rather than
practice careful risk management, each blames the other for any lateness or budget overage. As
we noted in the “Aside” in Chapter 8, unbiased honesty in estimates on the part of both worker
and manager is mandatory for any reasonable chance of on-schedule performance of projects.
Do Early Finishes and Late Finishes Cancel Out? So What?
One of the tacit assumptions of probabilistic networks is that early and late activity completions
cancel out. This assumption might be sensible were it not for the matters listed in the previous
subsection. Assume two activities, A and B. A is a predecessor of B. If activity A is late, then
activity B will start late by whatever amount of lateness is bequeathed to it by A. Similarly, if in
spite of all the forces tending to thwart such things, activity A finishes early, B will start early.
The assumption, which is also a tacit assumption of both the analytical and simulation methods
of finding a path’s duration, is generally true for the first case, when A is late. But for the case
when A is early, the assumption is rarely true. Unfortunately, a finish by A in less than its
expected duration almost never translates to a start by B before its expected start time. With a
few exceptions, the fact that early finishes do not become early starts is ignored by most people
involved with projects. Goldratt writes about the phenomenon (1997, Chapter 13 and elsewhere),
and a few others have also briefly discussed the matter. There is a mild debate as to the reason
for this deplorable condition. Goldratt feels that project workers will avoid admitting that an
activity has been completed early out of fear that future time estimates will be cut. Others point
out that when the activity schedule is set; it is presumed that the activity will start immediately
after the most likely finish date of its (latest) predecessor. The reason is simple—its resources
will not be available until that date. There is also a logical explanation of why the start of a
successor is usually delayed until its predetermined expected start time. Some say that project
workers will not report finishes before the most likely duration. The logic of this position
depends on an inherent distrust between project workers and senior management. If an early
finish is reported, workers assume that the shorter-than normal activity duration will be the
expectation for similar activities in the future. Senior managers, the argument proceeds, do not
really understand the uncertainty faced by project workers. Senior management will assume that
19
if an activity can be finished early once, it can be finished early again, or that they were correct
in their assumption that workers “pad” their time and resource estimates. The chance event of an
early finish is, thus, used to substantiate a shortened duration estimate in the future.
There is also a logical explanation of why a successor activity does not receive resources until its
predetermined expected start, which is, by definition, equal to the expected finish of the latest
predecessor activity. A stochastic network has little in common with an assembly line;
nonetheless, we find some managers attempting to delay the deployment of resources to a project
as long as possible. If we agree to start a project as soon as its predecessors are completed, we
must contemplate having the resources available and waiting well before the activity’s expected
start. Idle resources, however, are not acceptable to managers trained in a just-in-time view of the
world. Assembly lines are reasonably predictable; projects are not.
A Common Chain of Events
According to Goldratt, the behaviors and practices discussed above lead to the following chain of
events:
1. Assuming that activity times are known and that the paths are independent leads to
underestimating the actual amount of time needed to complete the project.
2. Because the time needed to complete the project is underestimated, project team members tend
to inflate their time estimates by some “safety” time.
3. Inflated time estimates lead to work filling available time, workers not reporting that a task has
been completed early, and the ever-present student syndrome.
4. An important caveat is that the safety time is only visible to the project workers and is often
misused.
5. Misused safety time results in missed deadlines and milestones.
6. Hidden safety time further complicates the PM’s task of prioritizing project activities.
7. The lack of clear priorities likely results in poor multitasking.
8. Task durations increase as a result of poor multitasking.
9. Uneven demand on resources—some overloaded and others underloaded—may also occur as
a result of poor multitasking.
10. In an effort to utilize all resources fully, more projects will be undertaken to make sure that
no resources are underutilized.
11. Adding more projects further increases poor multitasking.
According to Goldratt, this chain of events leads to a vicious cycle. Specifically, as work
continues to pile up, team members are pressured to do more poor multitasking. Increasing the
amount of poor multitasking, leads to longer activity times. Longer activity times lead to longer
project completion times, which ultimately lead to more projects in the waiting line. It might
have occurred to you that one way to reverse this cycle would be to add more resources.
According to Goldratt, however, the appropriate response is to reduce the number of projects
assigned to each person in an effort to reduce the amount of bad multitasking.
Incidentally, a simple way to measure the amount of bad multitasking is to calculate the
difference between the time required to do the work for a task and the elapsed time actually
required to complete the task.
Determining when to release projects into the system is the primary mechanism for ensuring that
the right amount of work is assigned to each person. If projects are started too early, they simply
add to the chaos and contribute to poor multitasking. On the other hand, if projects are started too
20
late, key resources may go underutilized and projects will be inevitably delayed. Consistent with
his Theory of Constraints, Goldratt suggests that the key to resolving this trade-off is to schedule
the start of new projects based on the availability of bottleneck (scarce) resources.
While properly scheduling the start of new projects does much to address the problems
associated with poor multitasking, it does little to address the problem of setting unrealistic
project deadlines and the accompanying response of inflated time estimates. Relying on
elementary statistics, it can be easily shown that the amount of safety time needed to protect a
particular path is less than the sum of the safety times required to protect the individual activities
making up the path. The same approach is commonly used in inventory management where it
can be shown that less safety stock is needed at a central warehouse to provide a certain service
level than the amount of safety stock that would be required to provide this same service level if
carried at multiple distributed locations.
Based on this insight, Goldratt suggests reducing the amount of safety time workers add to
individual tasks and then adding some fraction of the safety time reduced back into the system as
safety buffer for the entire project, called the project buffer. The amount of time each task is
reduced depends on how much of a reduction is needed to get project team members to change
their behavior. For example, the allotted time for tasks should be reduced to the point that the
student syndrome is eliminated. Indeed, Goldratt suggests using activity durations where in fact
there is a high probability that the task will not be finished on time.
The Critical Chain
Another limitation associated with traditional approaches to project management is that the
dependency between resources and tasks is often ignored. More specifically, Goldratt argues that
two activities scheduled to be carried out in parallel and using the same scarce resource are not
independent as the traditional theory would assume.1 If the supply of the scarce resource is not
sufficient to allow both activities to be carried out simultaneously, then whichever of the two is
given priority immediately lengthens the other activity’s path but not its actual duration.
Assume that two parallel paths compose a project. One path consists of activities A1 and B and
the other path consists of activities A2 and C. Activities A1 and A2 require the same scarce
resource. Activities B and C use different resources. A1 requires 7 days, A2 requires 5 days, B
needs 10 days, and C needs 6 days and thus, the path A1-B is 17 days and the path A2-C is 11
days. If there is not enough of the scarce resource to fund both A activities, they must be done
sequentially. If A1 is done first, A2 cannot start until A1 is complete, thereby adding 7 days to
the A2-C path, making it 18 days long and increasing the project finish date by 1 day. If A2 is
done first, 5 days will be added to the A1-B path, making it 22 days, a 5-day increase over its
original 17-day duration. If this problem seems familiar, it is. This is precisely the issue we dealt
with when we examined the process of resource leveling in Section 9.4. Using Goldratt’s
meaning of the word “dependent,” the activities of a project can be ordered into paths based on
their resource dependencies as well as on their technological precedence requirements. The
longest of these paths of sequentially time-dependent activities is known as the “critical chain.”
A project, therefore, is composed of its critical chain and of noncritical chains that feed into it—
see Figure 9.15. There are two sources of delay for the project. One comes from a delay of one or
more activities in the critical chain. The second results from a delay in one or more of the
activities on a noncritical or “feeder” chain because such delays could delay activities on the
21
critical chain. A project buffer protects the critical chain, and feeding buffers protect the feeder
paths.
Resources used by activities on the critical chain are given priority so that they are available
when required.
In the next chapter, we move to the ongoing implementation of the project and consider the
project information systems used for monitoring progress, costs, scope, and so on. The chapter
also describes some available computer packages for this function.
Fig. 4.26 Critical Chain, Project Buffer and Feeder Buffer
4.4 Project Stakeholders and Communication plan
A stakeholder is an individual, group, or organization that may affect, be affected by, or

perceive itself to be affected by a decision, activity, or outcome of a project. Project
stakeholders may be internal or external to the project, they may be actively involved,
passively involved, or unaware of the project. Project stakeholders may have a positive or
negative impact on the project, or be positively or negatively impacted by the project.
Examples of stakeholders include but are not limited to:
Internal stakeholders: Sponsor, Resource manager, Project management office (PMO), Portfolio
steering committee, Program manager, Project managers of other projects, and Team members.
External stakeholders: Customers, End users, Suppliers, Shareholders Regulatory bodies,
and Competitors.
Communication is the exchange of information, intended or involuntary. The information
exchanged can be in the form of ideas, instructions, or emotions. The mechanisms by which
information is exchanged can be in:
Written form- Either physical or electronic.
Spoken- Either face-to-face or remote.
Formal or informal (as in formal papers or social media).
Through gestures- Tone of voice and facial expressions.
Through media- Pictures, actions, or even just the choice of words.
Choice of words- There is often more than one word to express an idea; there can be subtle
differences in the meaning of each of these words and phrases.
Communications describe the possible means by which the information can be sent or received,
either through communication activities, such as meetings and presentations, or artifacts, such as
22
emails, social media, project reports, or project documentation. Project managers spend most of
their time communicating with team members and other project stakeholders, both internal (at all
organizational levels) and external to the organization.
Communication activities have many dimensions, including but not limited to:
Internal- Focus on stakeholders within the project and within the organization.
External- Focus on external stakeholders such as customers, vendors, other projects,
organizations, government, the public, and environmental advocates.
Formal- Reports, formal meetings (both regular and ad hoc), meeting agendas and minutes,
stakeholder briefings, and presentations.
Informal- General communications activities using emails, social media, websites, and informal
ad hoc discussions.
Hierarchical focus- The position of the stakeholder or group with respect to the project team will
affect the format and content of the message, in the following ways:
Upward- Senior management stakeholders.
Downward.-The team and others who will contribute to the work of the project.
Horizontal- Peers of the project manager or team.
Official- Annual reports; reports to regulators or government bodies.
Unofficial- Communications that focus on establishing and maintaining the profile and
recognition of the project and building strong relationships between the project team and its
stakeholders using flexible and often informal means.
Written and oral- Verbal (words and voice inflections) and nonverbal (body language and
actions), social media and websites, media releases.
Communication develops the relationships necessary for successful project and program
outcomes.
Stakeholder management refers to managing communications to satisfy the needs of, and resolve
issues with, project stakeholders. Actively managing stakeholders increases the likelihood that
the project will not veer off track due to unresolved stakeholder issues, enhances the ability of
persons to operate synergistically, and limits disruptions during the project. The project manager
is usually responsible for stakeholder management.
Fig. 4.27 Manage Stakeholders: Inputs, Tools & Techniques, and Outputs
23
Manage Stakeholders: Inputs

1. Communications Management Plan
Stakeholder requirements and expectations provide an understanding of stakeholder goals,
objectives, and level of communication during the project. The needs and expectations are
identified, analyzed, and documented in the communications management plan, which is a
subsidiary of the project management plan.
2. Organizational Process Assets
As project issues arise; the project manager should address and resolve them with the appropriate
project stakeholders.
Manage Stakeholders: Tools and Techniques
1. Communications Methods
The methods of communications identified for each stakeholder in the communications
management plan are utilized during stakeholder management. Face-to-face meetings are the
most effective means for communicating and resolving issues with stakeholders. When face-to-
face meetings are not warranted or practical (such as on international projects), telephone calls,
electronic mail, and other electronic tools are useful for exchanging information and dialoguing.
2. Issue Logs
An issue log or action-item log is a tool that can be used to document and monitor the resolution
of issues. Issues do not usually rise to the importance of becoming a project or activity, but are
usually addressed in order to maintain good, constructive working relationships among various
stakeholders, including team members. An issue is clarified and stated in a way that it can be
resolved. An owner is assigned and a target date is usually established for closure. Unresolved
issues can be a major source of conflict and project delays.
Manage Stakeholders: Outputs
1. Resolved Issues
As stakeholder requirements are identified and resolved, the issues log will document concerns
that have been addressed and closed. Examples include:
-Customers agree to a follow-on contract, which ends protracted discussion of whether requested
changes to project scope are within or outside the scope of the current project
-More staff is added to the project, thus closing the issue that the project is short on required
skills
-Negotiations with functional managers in the organization competing for scarce human
resources end in a mutually satisfactory solution before causing project delays
- Issues raised by board members about the financial viability of the project have been answered,
allowing the project to move forward as planned.
2. Approved Change Requests
Approved change requests include stakeholder issue status changes in the staffing management
plan, which are necessary to reflect changes to how communications with stakeholders will
occur.
3. Approved Corrective Actions
24
Approved corrective actions include changes that bring the expected future performance of the
project in line with the project management plan.
4. Organizational Process Assets (Updates)
Lessons learned documentation includes the causes of issues, the reasoning behind the corrective
action chosen, and other types of lessons learned about stakeholder management. Lessons
learned are documented so that they become part of the historical database for both this project
and the performing organization.
5. Project Management Plan (Updates)
The project management plan is updated to reflect the changes made to the communications
plan.
4.5 Risk Management in projects: -
Project Risk Management includes the processes of conducting risk management planning,
identification, analysis, response planning, response implementation, and monitoring risk on a
project. The objectives of project risk management are to increase the probability and/or impact
of positive risks and to decrease the probability and/or impact of negative risks, in order to
optimize the chances of project success.
The Project Risk Management processes are:
1. Plan Risk Management-The process of defining how to conduct risk management activities for
a project.
2. Identify Risks-The process of identifying individual project risks as well as sources of overall
project risk, and documenting their characteristics.
3. Perform Qualitative Risk Analysis-The process of prioritizing individual project risks for
further analysis or action by assessing their probability of occurrence and impact as well as other
characteristics.
4. Perform Quantitative Risk Analysis-The process of numerically analyzing the combined effect
of identified individual project risks and other sources of uncertainty on overall project
objectives.
5. Plan Risk Responses-The process of developing options, selecting strategies, and agreeing on
actions to address overall project risk exposure, as well as to treat individual project risks.
6. Implement Risk Responses-The process of implementing agreed-upon risk response plans.
7. Monitor Risks-The process of monitoring the implementation of agreed-upon risk response
plans, tracking identified risks, identifying and analyzing new risks, and evaluating risk process
effectiveness throughout the project.
KEY CONCEPTS FOR PROJECT RISK MANAGEMENT
All projects are risky since they are unique undertakings with varying degrees of complexity that
aim to deliver benefits. They do this in a context of constraints and assumptions, while
responding to stakeholder expectations that may be conflicting and changing. Organizations
25
should choose to take project risk in a controlled and intentional manner in order to create value
while balancing risk and reward.
Project Risk Management aims to identify and manage risks that are not addressed by the other
project management processes. When unmanaged, these risks have the potential to cause the
project to deviate from the plan and fail to achieve the defined project objectives. Consequently,
the effectiveness of Project Risk Management is directly related to project success.
Risk exists at two levels within every project. Each project contains individual risks that can
affect the achievement of project objectives. It is also important to consider the riskiness of the
overall project, which arises from the combination of individual project risks and other sources
of uncertainty. Project Risk Management processes address both levels of risk in projects, and
these are defined as follows:
-Individual project risk is an uncertain event or condition that, if it occurs, has a positive or
negative effect on one or more project objectives.
-Overall project risk is the effect of uncertainty on the project as a whole, arising from all sources
of uncertainty including individual risks, representing the exposure of stakeholders to the
implications of variations in project outcome, both positive and negative.
Individual project risks can have a positive or negative effect on project objectives if they
occur. Project Risk Management aims to exploit or enhance positive risks (opportunities) while
avoiding or mitigating negative risks (threats). Unmanaged threats may result in issues or
problems such as delay, cost overruns, performance shortfall, or loss of reputation. Opportunities
that are captured can lead to benefits such as reduced time and cost, improved performance, or
reputation.
Overall project risk can also be positive or negative. Management of overall project risk aims
to keep project risk exposure within an acceptable range by reducing drivers of negative
variation, promoting drivers of positive variation, and maximizing the probability of achieving
overall project objectives.
Risks will continue to emerge during the lifetime of the project, so Project Risk Management
processes should be conducted iteratively. Risk is initially addressed during project planning by
shaping the project strategy. Risk should also be monitored and managed as the project
progresses to ensure that the project stays on track and emergent risks are addressed.
In order to manage risk effectively on a particular project, the project team needs to know what
level of risk exposure is acceptable in pursuit of the project objectives. This is defined by
measurable risk thresholds that reflect the risk appetite of the organization and project
stakeholders. Risk thresholds express the degree of acceptable variation around a project
objective. They are explicitly stated and communicated to the project team and reflected in the
definitions of risk impact levels for the project.
TRENDS AND EMERGING PRACTICES IN PROJECT RISK MANAGEMENT
The focus of project risk management is broadening to ensure that all types of risk are
considered, and that project risks are understood in a wider context. Trends and emerging
practices for Project Risk Management include but are not limited to:
26
Non-event risks-Most projects focus only on risks that are uncertain future events that may or
may not occur. Examples of event-based risks include: a key seller may go out of business
during the project; the customer may change the requirement after design is complete, or a
subcontractor may propose enhancements to the standard operating processes. There is an
increasing recognition that non-event risks need to be identified and managed. There are two
main types of non-event risks:
Variability risk-Uncertainty exists about some key characteristics of a planned event or activity
or decision. Examples of variability risks include: productivity may be above or below target, the
number of errors found during testing may be higher or lower than expected, or unseasonal
weather conditions may occur during the construction phase.
Ambiguity risk-Uncertainty exists about what might happen in the future. Areas of the project
where imperfect knowledge might affect the project's ability to achieve its objectives include:
elements of the requirement or technical solution, future developments in regulatory frameworks,
or inherent systemic complexity in the project.
Variability risks can be addressed using Monte Carlo analysis, with the range of variation
reflected in probability distributions, followed by actions to reduce the spread of possible
outcomes. Ambiguity risks are managed by defining those areas where there is a deficit of
knowledge or understanding, then filling the gap by obtaining expert external input or
benchmarking against best practices. Ambiguity is also addressed through incremental
development, prototyping, or simulation.
Project resilience- The existence of emergent risk is becoming clear, with a growing awareness
of so-called unknowable-unknowns. These are risks that can only be recognized after they have
occurred. Emergent risks can be tackled through developing project resilience. This requires each
project to have:
-Right level of budget and schedule contingency for emergent risks, in addition to a specific risk
budget for known risks;
-Flexible project processes that can cope with emergent risk while maintaining overall direction
toward project goals, including strong change management;
-Empowered project team that has clear objectives and that is trusted to get the job done within
agreed-upon limits;
-Frequent review of early warning signs to identify emergent risks as early as possible; and
-Clear input from stakeholders to clarify areas where the project scope or strategy can be
adjusted in response to emergent risks.
Integrated risk management- Projects exist in an organizational context, and they may form
part of a program or portfolio. Risk exists at each of these levels, and risks should be owned and
managed at the appropriate level. Some risks identified at higher levels will be delegated to the
project team for management, and some project risks may be escalated to higher levels if they
are best managed outside the project. A coordinated approach to enterprise wide risk
management ensures alignment and coherence in the way risk is managed across all levels. This
27
builds risk efficiency into the structure of programs and portfolios, providing the greatest overall
value for a given level of risk exposure.
TAILORING CONSIDERATIONS
Because each project is unique, it is necessary to tailor the way Project Risk Management
processes are applied. Considerations for tailoring include but are not limited to:
1. Project size- Does the project's size in terms of budget, duration, scope, or team size require a
more detailed approach to risk management? Or is it small enough to justify a simplified risk
process?
2. Project complexity-Is a robust risk approach demanded by high levels of innovation, new
technology, commercial arrangements, interfaces, or external dependencies that increase project
complexity? Or is the project simple enough that a reduced risk process will suffice?
3. Project importance-How strategically important is the project? Is the level of risk increased for
this project because it aims to produce breakthrough opportunities, addresses significant blocks
to organizational performance, or involves major product innovation?
4. Development approach-Is this a waterfall project, where risk processes can be followed
sequentially and iteratively, or does the project follow an agile approach where risk is addressed
at the start of each iteration as well as during its execution?
Tailoring of the Project Risk Management processes to meet these considerations is part of the
Plan Risk Management process, and the outcomes of tailoring decisions are recorded in the risk
management plan.
CONSIDERATIONS FOR AGILE/ADAPTIVE ENVIRONMENTS
High-variability environments, by definition, incur more uncertainty and risk. To address this,
projects managed using adaptive approaches make use of frequent reviews of incremental work
products and cross-functional project teams to accelerate knowledge sharing and ensure that risk
is understood and managed. Risk is considered when selecting the content of each iteration, and
risks will also be identified, analyzed, and managed during each iteration. Additionally, the
requirements are kept as a living document that is updated regularly, and work may be
reprioritized as the project progresses, based on an improved understanding of current risk
exposure.
4.4.1 Risk management planning: -

Careful and explicit planning enhances the possibility of success of the five other risk
management processes. Risk Management Planning is the process of deciding how to approach
and conduct the risk management activities for a project. Planning of risk management processes
is important to ensure that the level, type, and visibility of risk management are commensurate
with both the risk and importance of the project to the organization, to provide sufficient
resources and time for risk management activities, and to establish an agreed-upon basis for
evaluating risks. The Risk Management Planning process should be completed early during
project planning, since it is crucial to successfully performing the other processes described
here.
28
Fig. 4.28 Risk Management Planning: Inputs, Tools & Techniques, and Outputs
Risk Management Planning: Inputs
1. Enterprise Environmental Factors- The attitudes toward risk and the risk tolerance of
organizations and people involved in the project will influence the project management plan.
Risk attitudes and tolerances may be expressed in policy statements or revealed in actions.
2. Organizational Process Assets- Organizations may have predefined approaches to risk
management such as risk categories, common definition of concepts and terms, standard
templates, roles and responsibilities, and authority levels for decision-making.
3. Project Scope Statement- The project scope statement describes, in detail, the project’s
deliverables and the work required to create those deliverables. The project scope statement also
provides a common understanding of the project scope among all project stakeholders and
describes the project’s major objectives. It also enables the project team to perform more detailed
planning, guides the project team’s work during execution, and provides the baseline for
evaluating whether requests for changes or additional work are contained within or outside the
project’s boundaries. The degree and level of detail to which the project scope statement defines
what work will be performed and what work is excluded can determine how well the project
management team can control the overall project scope. Managing the project scope, in turn, can
determine how well the project management team can plan, manage, and control the execution of
the project.
4. Project Management Plan-The Develop Project Management Plan process includes the
actions necessary to define, integrate, and coordinate all subsidiary plans into a project
management plan. The project management plan content will vary depending upon the
application area and complexity of the project. This process results in a project management plan
that is updated and revised through the Integrated Change Control process. The project
management plan defines how the project is executed, monitored and controlled, and closed. The
project management plan documents the collection of outputs of the planning processes of the
Planning Process Group.
29
Risk Management Planning: Tools and Techniques

1 Planning Meetings and Analysis- Project teams hold planning meetings to develop the risk
management plan. Attendees at these meetings may include the project manager, selected project
team members and stakeholders, anyone in the organization with responsibility to manage the
risk planning and execution activities, and others, as needed. Basic plans for conducting the risk
management activities are defined in these meetings. Risk cost elements and schedule activities
will be developed for inclusion in the project budget and schedule, respectively. Risk
responsibilities will be assigned. General organizational templates for risk categories and
definitions of terms such as levels of risk, probability by type of risk, impact by type of
objectives, and the probability and impact matrix will be tailored to the specific project. The
outputs of these activities will be summarized in the risk management plan.
Risk Management Planning: Outputs
1 Risk Management Plan-The risk management plan describes how risk management will be
structured and performed on the project. It becomes a subset of the project management plan.
The risk management plan includes the following:
Methodology- Defines the approaches, tools, and data sources that may be used to perform risk
management on the project.
Roles and responsibilities- Defines the lead, support, and risk management team membership
for each type of activity in the risk management plan, assigns people to these roles, and clarifies
their responsibilities.
Budgeting- Assigns resources and estimates costs needed for risk management for inclusion in
the project cost baseline.
Timing- Defines when and how often the risk management process will be performed
throughout the project life cycle, and establishes risk management activities to be included in the
project schedule.
Risk categories- Provides a structure that ensures a comprehensive process of systematically
identifying risk to a consistent level of detail and contributes to the effectiveness and quality of
Risk Identification. An organization can use a previously prepared categorization of typical risks.
A risk breakdown structure (RBS) is one approach to providing such a structure, but it can also
be addressed by simply listing the various aspects of the project. The risk categories may be
revisited during the Risk Identification process. A good practice is to review the risk categories
during the Risk Management Planning process prior to their use in the Risk Identification
process. Risk categories based on prior projects may need to be tailored, adjusted, or extended to
new situations before those categories can be used on the current project.
Definitions of risk probability and impact- The quality and credibility of the Qualitative Risk
Analysis process requires that different levels of the risks’ probabilities and impacts be defined.
General definitions of probability levels and impact levels are tailored to the individual project
during the Risk Management Planning process for use in the Qualitative Risk Analysis process.
Probability and impact matrix- Risks are prioritized according to their potential implications
for meeting the project’s objectives. The typical approach to prioritizing risks is to use a look-up
30
table or a Probability and Impact Matrix. The specific combinations of probability and impact
that lead to a risk being rated as “high,” “moderate,” or “low” importance—with the
corresponding importance for planning responses to the risk -are usually set by the organization.
They are reviewed and can be tailored to the specific project during the Risk Management
Planning process.
RBS for Generic Project Sample RBS of a project
Revised stakeholders’ tolerances-Stakeholders’ tolerances may be revised in the Risk

Management Planning process, as they apply to the specific project.-
Reporting formats-Describes the content and format of the risk register as well as any other risk
reports required. Defines how the outcomes of the risk management processes will be
documented, analyzed, and communicated.
Tracking- Documents how all facets of risk activities will be recorded for the benefit of the
current project, future needs, and lessons learned. Documents whether and how risk management
processes will be audited.
4.4.2 Risk identification and risk register: -
Risk Identification determines which risks might affect the project and documents their
characteristics. Participants in risk identification activities can include the following, where
appropriate: project manager, project team members, risk management team (if assigned),
subject matter experts from outside the project team, customers, end users, other project
managers, stakeholders, and risk management experts. While these personnel are often key
participants for risk identification, all project personnel should be encouraged to identify risks.
Risk Identification is an iterative process because new risks may become known as the project
progresses through its life cycle. The frequency of iteration and who participates in each cycle
will vary from case to case. The project team should be involved in the process so that they can
develop and maintain a sense of ownership of, and responsibility for, the risks and associated
31
risk response actions. Stakeholders outside the project team may provide additional objective
information. The Risk Identification process usually leads to the Qualitative Risk Analysis
process. Alternatively, it can lead directly to the Quantitative Risk Analysis process when
conducted by an experienced risk manager. On some occasions, simply the identification of a
risk may suggest its response, and these should be recorded for further analysis and
implementation in the Risk Response Planning process.
Fig. 4.29 Risk Identification: Inputs, Tools & Techniques, and Outputs
Risk Identification: Inputs

1. Enterprise Environmental Factors
Published information, including commercial databases, academic studies, benchmarking, or
other industry studies, may also be useful in identifying risks.
Information on prior projects may be available from previous project files, including actual data
and lessons learned.
3. Project Scope Statement
Project assumptions are found in the project scope statement. Uncertainty in project assumptions
should be evaluated as potential causes of project risk.
4. Risk Management Plan
Key inputs from the risk management plan to the Risk Identification process are the assignments
of roles and responsibilities, provision for risk management activities in the budget and schedule,
and categories of risk , which are sometimes expressed in an RBS .
5. Project Management Plan
The Risk Identification process also requires an understanding of the schedule, cost, and quality
management plans found in the project management plan. Outputs of other Knowledge Area
processes should be reviewed to identify possible risks across the entire project.
Risk Identification: Tools and Techniques
1. Documentation Reviews
A structured review may be performed of project documentation, including plans, assumptions,
prior project files, and other information. The quality of the plans, as well as consistency
32
between those plans and with the project requirements and assumptions, can be indicators of risk
in the project.
2. Information Gathering Techniques
Examples of information gathering techniques used in identifying risk can include:
Brainstorming- The goal of brainstorming is to obtain a comprehensive list of project risks. The
project team usually performs brainstorming, often with a multidisciplinary set of experts not on
the team. Ideas about project risk are generated under the leadership of a facilitator. Categories
of risk, such as a risk breakdown structure, can be used as a framework. Risks are then identified
and categorized by type of risk and their definitions are sharpened.
Delphi technique- The Delphi technique is a way to reach a consensus of experts. Project risk
experts participate in this technique anonymously. A facilitator uses a questionnaire to solicit
ideas about the important project risks. The responses are summarized and are then recirculated
to the experts for further comment. Consensus may be reached in a few rounds of this process.
The Delphi technique helps reduce bias in the data and keeps any one person from having undue
influence on the outcome.
Interviewing- Interviewing experienced project participants, stakeholders, and subject matter
experts can identify risks. Interviews are one of the main sources of risk identification data
gathering.
Root cause identification- This is an inquiry into the essential causes of a project’s risks. It
sharpens the definition of the risk and allows grouping risks by causes. Effective risk responses
can be developed if the root cause of the risk is addressed.
Strengths, weaknesses, opportunities, and threats (SWOT) analysis- This technique ensures
examination of the project from each of the SWOT perspectives, to increase the breadth of
considered risks.
3. Checklist Analysis
Risk identification checklists can be developed based on historical information and knowledge
that has been accumulated from previous similar projects and from other sources of information.
The lowest level of the RBS can also be used as a risk checklist. While a checklist can be quick
and simple, it is impossible to build an exhaustive one. Care should be taken to explore items
that do not appear on the checklist. The checklist should be reviewed during project closure to
improve it for use on future projects.
4. Assumptions Analysis
Every project is conceived and developed based on a set of hypotheses, scenarios, or
assumptions. Assumptions analysis is a tool that explores the validity of assumptions as they
apply to the project. It identifies risks to the project from inaccuracy, inconsistency, or
incompleteness of assumptions.
5. Diagramming Techniques
Risk diagramming techniques may include:
Cause-and-effect diagrams- These are also known as Ishikawa or fishbone diagrams, and are
useful for identifying causes of risks.
33
System or process flow charts- These show how various elements of a system interrelate, and
the mechanism of causation.
Influence diagrams- These are graphical representations of situations showing causal
influences, time ordering of events, and other relationships among variables and outcomes.
Risk Identification: Outputs

The outputs from Risk Identification are typically contained in a document that can be called a
risk register.
1. Risk Register
The primary outputs from Risk Identification are the initial entries into the risk register, which
becomes a component of the project management plan . The risk register ultimately contains the
outcomes of the other risk management processes as they are conducted. The preparation of the
risk register begins in the Risk Identification process with the following information, and then
becomes available to other project management and Project Risk Management processes.
List of identified risks- The identified risks, including their root causes and uncertain project
assumptions, are described. Risks can cover nearly any topic, but a few examples include the
following: A few large items with long lead times are on critical path. There could be a risk that
industrial relations disputes at the ports will delay the delivery and, subsequently, delay
completion of the construction phase. Another example is a project management plan that
assumes a staff size of ten, but there are only six resources available. The lack of resources could
impact the time required to complete the work and the activities would be late.
List of potential responses- Potential responses to a risk may be identified during the Risk
Identification process. These responses, if identified, may be useful as inputs to the Risk
Response Planning process.
Root causes of risk- These are the fundamental conditions or events that may give rise to the
identified risk.
Updated risk categories- The process of identifying risks can lead to new risk categories being
added to the list of risk categories. The RBS developed in the Risk Management Planning
process may have to be enhanced or amended, based on the outcomes of the Risk Identification
process.
4.4.3 Qualitative and quantitative risk assessment: -
Qualitative Risk Analysis
Qualitative Risk Analysis includes methods for prioritizing the identified risks for further action,
such as Quantitative Risk Analysis or Risk Response Planning. Organizations can improve the
project’s performance effectively by focusing on high-priority risks. Qualitative Risk Analysis
assesses the priority of identified risks using their probability of occurring, the corresponding
impact on project objectives if the risks do occur, as well as other
factors such as the time frame and risk tolerance of the project constraints of cost, schedule,
scope, and quality.
34
Definitions of the levels of probability and impact, and expert interviewing, can help to correct
biases that are often present in the data used in this process. The time criticality of risk-related
actions may magnify the importance of a risk. An evaluation of the quality of the available
information on project risks also helps understand the assessment of the risk’s importance to the
project.
Qualitative Risk Analysis is usually a rapid and cost-effective means of establishing priorities for
Risk Response Planning, and lays the foundation for Quantitative Risk Analysis, if this is
required. Qualitative Risk Analysis should be revisited during the project’s life cycle to stay
current with changes in the project risks. Qualitative Risk Analysis requires outputs of the Risk
Management Planning and Risk Identification processes. This process can lead into Quantitative
Risk Analysis or directly into Risk Response Planning.
Fig. 4.30 Qualitative Risk Analysis: Inputs, Tools & Techniques, and Outputs
Qualitative Risk Analysis: Inputs

Data about risks on past projects and the lessons learned knowledge base can be used in the
Qualitative Risk Analysis process.
Projects of a common or recurrent type tend to have more well-understood risks. Projects using
state-of-the-art or first-of-its-kind technology, and highly complex projects, tend to have more
uncertainty. This can be evaluated by examining the project scope statement.
Key elements of the risk management plan for Qualitative Risk Analysis include roles and
responsibilities for conducting risk management, budgets, and schedule activities for risk
management, risk categories, definition of probability and impact, the probability and impact
matrix, and revised stakeholders’ risk tolerances. These inputs are usually tailored to the project
during the Risk Management Planning process. If they are not available, they can be developed
during the Qualitative Risk Analysis process.
4. Risk Register
A key item from the risk register for Qualitative Risk Analysis is the list of identified risks.
Qualitative Risk Analysis: Tools and Techniques
35
1. Risk Probability and Impact Assessment

Risk probability assessment investigates the likelihood that each specific risk will occur. Risk
impact assessment investigates the potential effect on a project objective such as time, cost,
scope, or quality, including both negative effects for threats and positive effects for
opportunities.
Probability and impact are assessed for each identified risk. Risks can be assessed in interviews
or meetings with participants selected for their familiarity with the risk categories on the agenda.
Project team members and, perhaps, knowledgeable persons from outside the project, are
included. Expert judgment is required, since there may be little information on risks from the
organization’s database of past projects. An experienced facilitator may lead the discussion,
since the participants may have little experience with risk assessment. The level of probability
for each risk and its impact on each objective is evaluated during the interview or meeting.
Explanatory detail, including assumptions justifying the levels assigned, is also recorded. Risk
probabilities and impacts are rated according to the definitions given in the risk management
plan. Sometimes, risks with obviously low ratings of probability and impact will not be rated, but
will be included on a watchlist for future monitoring.
2. Probability and Impact Matrix
Risks can be prioritized for further quantitative analysis and response, based on their risk rating.
Ratings are assigned to risks based on their assessed probability and impact. Evaluation of each
risk’s importance and, hence, priority for attention is typically conducted using a look-up table or
a probability and impact matrix (Figure 4.31). Such a matrix specifies combinations of
probability and impact that lead to rating the risks as low, moderate, or high priority. Descriptive
terms or numeric values can be used, depending on organizational preference. The organization
should determine which combinations of probability and impact result in a classification of high
risk, moderate risk, and low risk. In a black-and-white matrix, these conditions can be denoted
by different shades of gray. Specifically, in Figure 4.31, the dark gray area (with the largest
numbers) represents high risk; the medium gray area (with the smallest numbers) represents low
risk; and the light gray area (with in-between numbers) represents moderate risk. Usually, these
risk rating rules are specified by the organization in advance of the project, and included in
organizational process assets. Risk rating rules can be tailored in the Risk Management Planning
process to the specific project. A probability and impact matrix, such as the one shown in Figure
4.31, is often used.
36
Fig. 4.31 Probability and Impact Matrix
As illustrated in Figure 4.31, an organization can rate a risk separately for each objective (e.g.,
cost, time, and scope). In addition, it can develop ways to determine one overall rating for each
risk. Finally, opportunities and threats can be handled in the same matrix using definitions of the
different levels of impact that are appropriate for each. The risk score helps guide risk responses.
For example, risks that have a negative impact on objectives if they occur (threats), and that are
in the high-risk (dark gray) zone of the matrix, may require priority action and aggressive
response strategies. Threats in the low-risk (medium gray) zone may not require proactive
management action beyond being placed on a watchlist or adding a contingency reserve.
Similarly for opportunities, those in the high-risk (dark gray) zone that can be obtained most
easily and offer the greatest benefit should, therefore, be targeted first. Opportunities in the low-
risk (medium gray) zone should be monitored.
3. Risk Data Quality Assessment
A qualitative risk analysis requires accurate and unbiased data if it is to be credible. Analysis of
the quality of risk data is a technique to evaluate the degree to which the data about risks is
useful for risk management. It involves examining the degree to which the risk is understood and
the accuracy, quality, reliability, and integrity of the data about the risk. The use of low-quality
risk data may lead to a qualitative risk analysis of little use to the project. If data quality is
unacceptable, it may be necessary to gather better data. Often, collection of information about
risks is difficult, and consumes time and resources beyond that originally planned.
4. Risk Categorization
37
Risks to the project can be categorized by sources of risk (e.g., using the RBS), the area of the
project affected (e.g., using the WBS), or other useful category (e.g., project phase) to determine
areas of the project most exposed to the effects of uncertainty. Grouping risks by common root
causes can lead to developing effective risk responses.
5. Risk Urgency Assessment
Risks requiring near-term responses may be considered more urgent to address. Indicators of
priority can include time to affect a risk response, symptoms and warning signs, and the risk
rating.
Qualitative Risk Analysis: Outputs

1. Risk Register (Updates)
The risk register is initiated during the Risk Identification process. The risk register is updated
with information from Qualitative Risk Analysis and the updated risk register is included in the
project management plan. The risk register updates from Qualitative Risk Analysis include:
Relative ranking or priority list of project risks- The probability and impact matrix can be
used to classify risks according to their individual significance. The project manager can then use
the prioritized list to focus attention on those items of high significance to the project, where
responses can lead to better project outcomes. Risks may be listed by priority separately for cost,
time, scope, and quality, since organizations may value one objective over another. A description
of the basis for the assessed probability and impact should be included for risks assessed as
important to the project.
Risks grouped by categories- Risk categorization can reveal common root causes of risk or
project areas requiring particular attention. Discovering concentrations of risk may improve the
effectiveness of risk responses.
List of risks requiring response in the near-term- Those risks that require an urgent response
and those that can be handled at a later date may be put into different groups.
List of risks for additional analysis and response- Some risks might warrant more analysis,
including Quantitative Risk Analysis, as well as response action.
Watchlists of low priority risks- Risks that are not assessed as important in the Qualitative Risk
Analysis process can be placed on a watchlist for continued monitoring.
Trends in qualitative risk analysis results- As the analysis is repeated, a trend for particular
risks may become apparent, and can make risk response or further analysis more or less
urgent/important.
4. Quantitative Risk Analysis

Quantitative Risk Analysis is performed on risks that have been prioritized by the Qualitative
Risk Analysis process as potentially and substantially impacting the project’s competing
demands. The Quantitative Risk Analysis process analyzes the effect of those risk events and
assigns a numerical rating to those risks. It also presents a quantitative approach to making
decisions in the presence of uncertainty. This process uses techniques such as Monte Carlo
simulation and decision tree analysis to:
38
-Quantify the possible outcomes for the project and their probabilities
-Assess the probability of achieving specific project objectives
-Identify risks requiring the most attention by quantifying their relative contribution to overall
project risk
- Identify realistic and achievable cost, schedule, or scope targets; given the project risks
- Determine the best project management decision when some conditions or outcomes are
uncertain.
Quantitative Risk Analysis generally follows the Qualitative Risk Analysis process, although
experienced risk managers sometimes perform it directly after Risk Identification. In some cases,
Quantitative Risk Analysis may not be required to develop effective risk responses. Availability
of time and budget, and the need for qualitative or quantitative statements about risk and
impacts, will determine which method(s) to use on any particular project. Quantitative Risk
Analysis should be repeated after Risk Response Planning, as well as part of Risk Monitoring
and Control, to determine if the overall project risk has been satisfactorily decreased. Trends can
indicate the need for more or less risk management action. It is an input to the Risk Response
Planning process.
Fig. 4.32 Quantitative Risk Analysis: Inputs, Tools & Techniques, and Outputs
Quantitative Risk Analysis: Inputs

Information on prior, similar completed projects, studies of similar projects by risk specialists,
and risk databases that may be available from industry or proprietary sources.
Projects of a common or recurrent type tend to have more well-understood risks. Projects using
state-of-the-art or first-of-its-kind technology, and highly complex projects, tend to have more
uncertainty. This can be evaluated by examining the project scope statement.
Key elements of the risk management plan for Quantitative Risk Analysis include roles and
responsibilities for conducting risk management, budgets, and schedule activities for risk
39
management, risk categories, the RBS, and revised stakeholders’ risk tolerances.
4. Risk Register
Key items from the risk register for Quantitative Risk Analysis include the list of identified risks,
the relative ranking or priority list of project risks, and the risks grouped by categories.
5. Project Management Plan
The project management plan includes:
Project schedule management plan- The project schedule management plan sets the format and
establishes criteria for developing and controlling the project schedule.
Project cost management plan- The project cost management plan sets the format and
establishes criteria for planning, structuring, estimating, budgeting, and controlling project costs.
Quantitative Risk Analysis: Tools and Techniques

1. Data Gathering and Representation Techniques
Interviewing- Interviewing techniques are used to quantify the probability and impact of risks
on project objectives. The information needed depends upon the type of probability distributions
that will be used. For instance, information would be gathered on the optimistic (low),
pessimistic (high), and most likely scenarios for some commonly used distributions, and the
mean and standard deviation for others. Examples of three-point estimates for a cost estimate are
shown in Figure 4.33. Documenting the rationale of the risk ranges is an important component of
the risk interview, because it can provide information on reliability and credibility of the
analysis.
Fig. 4.33 Range of Project Cost Estimates Collected During the Risk Interview
Probability distributions- Continuous probability distributions represent the uncertainty in

values, such as durations of schedule activities and costs of project components. Discrete
distributions can be used to represent uncertain events, such as the outcome of a test or a possible
scenario in a decision tree. Two examples of widely used continuous distributions are shown in
40
Figure 4.34. These asymmetrical distributions depict shapes that are compatible with the data
typically developed during the project risk analysis. Uniform distributions can be used if there is
no obvious value that is more likely than any other between specified high and low bounds, such
as in the early concept stage of design.
Fig. 4.34 Examples of Commonly Used Probability Distributions

Expert judgment- Subject matter experts internal or external to the organization, such as
engineering or statistical experts, validate data and techniques.
2. Quantitative Risk Analysis and Modeling Techniques
Commonly used techniques in Quantitative Risk Analysis include:
Sensitivity analysis- Sensitivity analysis helps to determine which risks have the most potential
impact on the project. It examines the extent to which the uncertainty of each project element
affects the objective being examined when all other uncertain elements are held at their baseline
values. One typical display of sensitivity analysis is the tornado diagram, which is useful for
comparing relative importance of variables that have a high degree of uncertainty to those that
are more stable.
Expected monetary value analysis- Expected monetary value (EMV) analysis is a statistical
concept that calculates the average outcome when the future includes scenarios that may or may
not happen (i.e., analysis under uncertainty). The EMV of opportunities will generally be
expressed as positive values, while those of risks will be negative. EMV is calculated by
multiplying the value of each possible outcome by its probability of occurrence, and adding them
together. A common use of this type of analysis is in decision tree analysis. Modeling and
simulation are recommended for use in cost and schedule risk analysis, because they are more
powerful and less subject to misuse than EMV analysis.
Decision tree analysis- Decision tree analysis is usually structured using a decision tree diagram
(Figure 4.34) that describes a situation under consideration, and the implications of each of the
available choices and possible scenarios. It incorporates the cost of each available choice, the
probabilities of each possible scenario, and the rewards of each alternative logical path. Solving
41
the decision tree provides the EMV (or other measure of interest to the organization) for each
alternative, when all the rewards and subsequent decisions are quantified.
Modeling and simulation- A project simulation uses a model that translates the uncertainties
specified at a detailed level of the project into their potential impact on project objectives.
Simulations are typically performed using the Monte Carlo technique. In a simulation, the
project model is computed many times (iterated), with the input values randomized from a
probability distribution function (e.g., cost of project elements or duration of schedule activities)
chosen for each iteration from the probability distributions of each variable. A probability
distribution (e.g., total cost or completion date) is calculated. For a cost risk analysis, a
simulation can use the traditional project WBS or a cost breakdown structure as its model. For a
schedule risk analysis, the precedence diagramming method (PDM) schedule is used. A cost risk
simulation is shown in Figure 4.35.
Fig. 4.35 Cost Risk Simulation Results
Quantitative Risk Analysis: Outputs

1. Risk Register (Updates)
The risk register is initiated in the Risk Identification process and updated in Qualitative Risk
Analysis. It is further updated in Quantitative Risk Analysis. The risk register is a component of
the project management plan. Updates include the following main components:
Probabilistic analysis of the project- Estimates are made of potential project schedule and cost
outcomes, listing the possible completion dates and costs with their associated confidence levels.
42
This output, typically expressed as a cumulative distribution, is used with stakeholder risk
tolerances to permit quantification of the cost and time contingency reserves. Such contingency
reserves are needed to bring the risk of overrunning stated project objectives to a level acceptable
to the organization. For instance, in Figure 4.35, the cost contingency to the 75th percentile is $9
million, or about 22% versus the $41 million sum of the most likely estimates.
Probability of achieving cost and time objectives- With the risks facing the project, the
probability of achieving project objectives under the current plan can be estimated using
quantitative risk analysis results. For instance, in Figure 4.35, the likelihood of achieving the cost
estimate of $41 million (from Figure 4.32) is about 12%.
Prioritized list of quantified risks- This list of risks includes those that pose the greatest threat
or present the greatest opportunity to the project. These include the risks that require the greatest
cost contingency and those that are most likely to influence the critical path.
Trends in quantitative risk analysis results- As the analysis is repeated, a trend may become
apparent that leads to conclusions affecting risk responses
Quantitative Risk Assessment Methodologies

Commonly used techniques in Quantitative Risk Analysis include:
Sensitivity analysis- Sensitivity analysis helps to determine which risks have the most potential
impact on the project. It examines the extent to which the uncertainty of each project element
affects the objective being examined when all other uncertain elements are held at their baseline
values. One typical display of sensitivity analysis is the tornado diagram, which is useful for
comparing relative importance of variables that have a high degree of uncertainty to those that
are more stable.
Expected monetary value analysis- Expected monetary value (EMV) analysis is a statistical
concept that calculates the average outcome when the future includes scenarios that may or may
not happen (i.e., analysis under uncertainty). The EMV of opportunities will generally be
expressed as positive values, while those of risks will be negative. EMV is calculated by
multiplying the value of each possible outcome by its probability of occurrence, and adding them
together. A common use of this type of analysis is in decision tree analysis (Figure 4.34).
Modeling and simulation are recommended for use in cost and schedule risk analysis, because
they are more powerful and less subject to misuse than EMV analysis.
Decision tree analysis- Decision tree analysis is usually structured using a decision tree diagram
that describes a situation under consideration, and the implications of each of the available
choices and possible scenarios. It incorporates the cost of each available choice, the
probabilities of each possible scenario, and the rewards of each alternative logical path. Solving
the decision tree provides the EMV (or other measure of interest to the organization) for each
alternative, when all the rewards and subsequent decisions are quantified.
Modeling and simulation- A project simulation uses a model that translates the uncertainties
specified at a detailed level of the project into their potential impact on project objectives.
Simulations are typically performed using the Monte Carlo technique. In a simulation, the
43
project model is computed many times (iterated), with the input values randomized from a
probability distribution function (e.g., cost of project elements or duration of schedule activities)
chosen for each iteration from the probability distributions of each variable. A probability
distribution (e.g., total cost or completion date) is calculated. For a cost risk analysis, a
simulation can use the traditional project WBS or a cost breakdown structure as its model. For a
schedule risk analysis, the precedence diagramming method (PDM) schedule is used. A cost risk
simulation is shown in Figure 4.35.
Failure Mode and Effect Analysis (FMEA)
FMEA is the application of a scoring model such as those used for project . It is straightforward
and extensively used, particularly in engineering, and is easily applied to risk by using six steps.
1. List the possible ways a project might fail.
2. Evaluate the severity (S) of the impact of each type of failure on a 10-point scale where “1” is
“no effect” and “10” is “very severe.”
3. For each cause of failure, estimate the likelihood (L) of its occurrence on a 10-point scale
where “1” is “remote” and 10 is “almost certain.”
4. Estimate the inability to detect (D) a failure associated with each cause. Using a 10-point
scale, “1” means delectability is almost certain using normal monitoring/ control systems and
“10” means it is practically certain that failure will not be detected in time to avoid or mitigate it.
5. Find the Risk Priority Number (RPN) where RPN S L D.
6. Consider ways to reduce the S, L, and D for each cause of failure with a significantly high
RPN. (We discuss this in Step 5: Risk Response Planning.)
Table 4.1 FMEA Example table
Threat Severity ,S Likelihood , L Ability to Detect , D RPN
1. Tight schedule 6 7.5 2 90
2. Can’t acquire tech knowledge 8.5 5 4 170
3. Client changes scope 4 8 5 160
4. Costs escalate 3 2 6 36
5. Recession 4 2.5 7
Table 4.1 illustrates the use of FMEA for the same five threats we considered in Step 4
previously, but here we use more precise data. As we see from the RPN numbers, the biggest
threats are: Can’t acquire tech knowledge (2), and Client changes scope (3). Threat 2 has a great
severity, should it occur, and threat 3 is quite likely, though the severity is much less damaging.
The cost threat (4) and the recession threat (5) can probably be ignored for now since their
likelihoods are so low. The tight schedule (1) will have some repercussions and is also quite
likely, but we will see it coming early and can probably take steps to avoid or mitigate it. Some
extensions of FMEA use additional scoring categories such as Ability to Mitigate (even if the
threat cannot be detected).
4.4.4 Probability and impact matrix: -
Definitions of risk probability and impact- The quality and credibility of the Qualitative Risk
Analysis process requires that different levels of the risks’ probabilities and impacts be defined.
44
General definitions of probability levels and impact levels are tailored to the individual project
during the Risk Management Planning process for use in the Qualitative Risk Analysis
process. A relative scale representing probability values from “very unlikely” to “almost
certainty” could be used. Alternatively, assigned numerical probabilities on a general scale (e.g.,
0.1, 0.3, 0.5, 0.7, 0.9) can be used. Another approach to calibrating probability involves
developing descriptions of the state of the project that relate to the risk under consideration (e.g.,
the degree of maturity of the project design).
The impact scale reflects the significance of impact, either negative for threats or positive for
opportunities, on each project objective if a risk occurs. Impact scales are specific to the
objective potentially impacted, the type and size of the project, the organization’s strategies and
financial state, and the organization’s sensitivity to particular impacts. Relative scales for impact
are simply rank-ordered descriptors such as “very low,” “low,” “moderate,” “high,” and “very
high,” reflecting increasingly extreme impacts as defined by the organization. Alternatively,
numeric scales assign values to these impacts. These values may be linear (e.g., 0.1, 0.3, 0.5, 0.7,
0.9) or nonlinear (e.g., 0.05, 0.1, 0.2, 0.4, 0.8). Nonlinear scales may represent the organization’s
desire to avoid high-impact threats or exploit high-impact opportunities, even if they have
relatively low probability. In using nonlinear scales, it is important to understand what is meant
by the numbers and their relationship to each other, how they were derived, and the effect they
may have on the different objectives of the project. Figure 4.36 is an example of negative
impacts of definitions that might be used in evaluating risk impacts related to four project
objectives. That figure illustrates both relative and numeric (in this case, nonlinear) approaches.
The figure is not intended to imply that the relative and numeric terms are equivalent, but to
show the two alternatives in one figure rather than two.
Fig. 4.36 Definition of Impact Scale for four project objectives

Risk probability assessment investigates the likelihood that each specific risk will occur. Risk
impact assessment investigates the potential effect on a project objective such as time, cost,
scope, or quality, including both negative effects for threats and positive effects for
opportunities.
45
Probability and impact are assessed for each identified risk. Risks can be assessed in interviews
or meetings with participants selected for their familiarity with the risk categories on the agenda.
Project team members and, perhaps, knowledgeable persons from outside the project, are
included. Expert judgment is required, since there may be little information on risks from the
organization’s database of past projects. An experienced facilitator may lead the discussion,
since the participants may have little experience with risk assessment. The level of probability
for each risk and its impact on each objective is evaluated during the interview or meeting.
Explanatory detail, including assumptions justifying the levels assigned, is also recorded. Risk
probabilities and impacts are rated according to the definitions given in the risk management
plan. Sometimes, risks with obviously low ratings of probability and impact will not be rated, but
will be included on a watch list for future monitoring.
Risks can be prioritized for further quantitative analysis and response, based on their risk rating.
Ratings are assigned to risks based on their assessed probability and impact. Evaluation of each
risk’s importance and, hence, priority for attention is typically conducted using a look-up table or
a probability and impact matrix (Figure 4.37). Such a matrix specifies combinations of
probability and impact that lead to rating the risks as low, moderate, or high priority. Descriptive
terms or numeric values can be used, depending on organizational preference. The organization
should determine which combinations of probability and impact result in a classification of high
risk (“red condition”), moderate risk (“yellow condition”), and low risk (“green condition”). In a
black-and-white matrix, these conditions can be denoted by different shades of gray.
Specifically, in Figure 4.37, the dark gray area (with the largest numbers) represents high risk;
the medium gray area (with the smallest numbers) represents low risk; and the light gray area
(with in-between numbers) represents moderate risk. Usually, these risk rating rules are specified
by the organization in advance of the project, and included in organizational process assets. Risk
rating rules can be tailored in the Risk Management Planning process to the specific project. A
probability and impact matrix, such as the one shown in Figure 4.37, is often used.
Fig. 4.37 Probability and Impact Matrix
46
An organization can rate a risk separately for each objective (e.g., cost, time, and scope). In
addition, it can develop ways to determine one overall rating for each risk. Finally, opportunities
and threats can be handled in the same matrix using definitions of the different levels of impact
that are appropriate for each. The risk score helps guide risk responses. For example, risks that
have a negative impact on objectives if they occur (threats), and that are in the high-risk (dark
gray) zone of the matrix, may require priority action and aggressive response strategies. Threats
in the low-risk (medium gray) zone may not require proactive management action beyond being
placed on a watch list or adding a contingency reserve. Similarly for opportunities, those in the
high-risk (dark gray) zone that can be obtained most easily and offer the greatest benefit should,
therefore, be targeted first. Opportunities in the low-risk (medium gray) zone should be
monitored. Risks are prioritized according to their potential implications for meeting the
project’s objectives. The typical approach to prioritizing risks is to use a look-up table or a
Probability and Impact Matrix. The specific combinations of probability and impact that lead to a
risk being rated as “high,” “moderate,” or “low” importance—with the corresponding
importance for planning responses to the risk are usually set by the organization. They are
reviewed and can be tailored to the specific project during the Risk Management Planning
process.
4.4.5 Risk response strategies for positive and negative risks: -
Several risk response strategies are available. The strategy or mix of strategies most likely to be
effective should be selected for each risk. Risk analysis tools, such as decision tree analysis, can
be used to choose the most appropriate responses. Then, specific actions are developed to
implement that strategy. Primary and backup strategies may be selected. A fallback plan can be
developed for implementation if the selected strategy turns out not to be fully effective, or if an
accepted risk occurs. Often, a contingency reserve is allocated for time or cost. Finally,
contingency plans can be developed, along with identification of the conditions that trigger their
execution.
1. Strategies for Negative Risks or Threats

Three strategies typically deal with threats or risks that may have negative impacts on project
objectives if they occur. These strategies are to avoid, transfer, or mitigate:
Avoid- Risk avoidance involves changing the project management plan to eliminate the threat
posed by an adverse risk, to isolate the project objectives from the risk’s impact, or to relax the
objective that is in jeopardy, such as extending the schedule or reducing scope. Some risks that
arise early in the project can be avoided by clarifying requirements, obtaining information,
improving communication, or acquiring expertise.
Transfer- Risk transference requires shifting the negative impact of a threat, along with
ownership of the response, to a third party. Transferring the risk simply gives another party
responsibility for its management; it does not eliminate it. Transferring liability for risk is most
effective in dealing with financial risk exposure. Risk transference nearly always involves
47
payment of a risk premium to the party taking on the risk. Transference tools can be quite diverse
and include, but are not limited to, the use of insurance, performance bonds, warranties,
guarantees, etc. Contracts may be used to transfer liability for specified risks to another party. In
many cases, use of a cost-type contract may transfer the cost risk to the buyer, while a fixed-
price contract may transfer risk to the seller, if the project’s design is stable.
Mitigate- Risk mitigation implies a reduction in the probability and/or impact of an adverse risk
event to an acceptable threshold. Taking early action to reduce the probability and/or impact of a
risk occurring on the project is often more effective than trying to repair the damage after the risk
has occurred. Adopting less complex processes, conducting more tests, or choosing a more
stable supplier are examples of mitigation actions. Mitigation may require prototype
development to reduce the risk of scaling up from a bench-scale model of a process or product.
Where it is not possible to reduce probability, a mitigation response might address the risk
impact by targeting linkages that determine the severity. For example, designing redundancy into
a subsystem may reduce the impact from a failure of the original component.
2. Strategies for Positive Risks or Opportunities
Three responses are suggested to deal with risks with potentially positive impacts on project
objectives. These strategies are to exploit, share, or enhance.
Exploit. This strategy may be selected for risks with positive impacts where the organization
wishes to ensure that the opportunity is realized. This strategy seeks to eliminate the uncertainty
associated with a particular upside risk by making the opportunity definitely happen. Directly
exploiting responses includes assigning more talented resources to the project to reduce the time
to completion, or to provide better quality than originally planned.
Share. Sharing a positive risk involves allocating ownership to a third party who is best able to
capture the opportunity for the benefit of the project. Examples of sharing actions include
forming risk-sharing partnerships, teams, special-purpose companies, or joint ventures, which
can be established with the express purpose of managing opportunities.
Enhance. This strategy modifies the “size” of an opportunity by increasing probability and/or
positive impacts, and by identifying and maximizing key drivers of these positive-impact risks.
Seeking to facilitate or strengthen the cause of the opportunity, and proactively targeting and
reinforcing its trigger conditions, might increase probability. Impact drivers can also be targeted,
seeking to increase the project’s susceptibility to the opportunity.
Module-4 Planning Projects (Question Bank)
1. What is a project launch meeting? who are the invitees of this meeting? What are the outcomes
of this meeting?
2. What is crashing of the project? Explain with a small example the process of crashing
3. What is resource loading? How does it differ from resource leveling?
4. What is Goldratt’s critical chain method? What is meant by a project buffer?
48

4.planning Projects

Uploaded by

Copyright:

Available Formats

4.planning Projects

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

4.planning Projects

Uploaded by

Copyright:

Available Formats

04.

4.1 Crashing project time,

4.1 Crashing project time: -

The Meaning Of Crashing

𝐶𝑟𝑎𝑠ℎ cos𝑡 𝐶𝑟𝑎𝑠ℎ cos𝑡 − 𝑁𝑜𝑟𝑚𝑎𝑙 cos𝑡

In step 3, we have to consider the following question:

Activity Predecessor Normal Crash Time Normal Cost Crash Cost

Fig. 4.2 Network Diagram of problem 1

The time for the path = 4 + 5 + 6 + 5 = 20 weeks.

The time for the path = 4 + 4 + 6 + 7 + 4 = 25 weeks.

Maximum of {20, 25} = 25.

Activity Normal Crash Normal Crash Crash Normal Crash

Fig. 4.2 Modified Network Diagram of problem 1 after crashing activity A

The revised time for Path I = 3 + 5 + 6 + 5 = 19 weeks.

Fig. 4.2 Modified Network Diagram of problem 1 after crashing activity C

The time for Path I = 3 + 5 + 6 + 5 = 19 weeks.

Network Diagram For the Constrained Resources

Fig. 4.3: Precedence

Fig. 4.5: Example Precedence Network

Fig. 4.6: Basic Forward Pass Example

Fig. 4.76: Forward Pass with Smart Relationships

4.2 Backward Pass

Fig. 4.8: Backward Pass Example

Fig. 4.9 : Backward Pass with Smart Relationships

4.2 Resource loading and leveling: -

Fig. 4.10. AOA Network for illustration of Resource loading

Fig. 4.12 Load diagram for resource A

Fig. 4.13 Load diagram for resource B

Activity Duration in Weeks Manpower requirements

Fig. 4.16 Manpower Requirement for problem 2

The corresponding manpower requirement histogram is shown below.

Fig. 4.17 Improvement in Manpower Requirement for problem 2

Fig. 4.18 Leveling of Manpower Requirement for problem 2

The manpower requirement is now smooth throughout the project duration.

Activity Description Immediate Optim Most Pessim

Draw network diagram

Fig. 4.19 Network diagram of problem 3

Fig. 4.20 Network diagram of problem 3 with ES & EF

Fig. 4.21 Gantt Chart of problem 3

Step-4 Draw LS, LF Network

Fig. 4.22 Network diagram of problem 3 with ES, EF, LS & LF

Fig. 4.23 Modified Gantt Chart of problem 3

Step-5 Calculating Slack

4.3 Goldratt's critical chain: -

Fig.4. 24 Effect of multitasking on project completion.

Fig. 4.25 Two levels of 40 days network complexity

Do Early Finishes and Late Finishes Cancel Out? So What?

A Common Chain of Events

The Critical Chain

Fig. 4.26 Critical Chain, Project Buffer and Feeder Buffer

4.4 Project Stakeholders and Communication plan

A stakeholder is an individual, group, or organization that may affect, be affected by, or

Manage Stakeholders: Inputs

4.5 Risk Management in projects: -

4.4.1 Risk management planning: -

Risk Management Planning: Inputs

Risk Management Planning: Tools and Techniques

RBS for Generic Project Sample RBS of a project

Revised stakeholders’ tolerances-Stakeholders’ tolerances may be revised in the Risk