OPERATIONS STRATEGY

KRUPANIDHI SCHOOL OF MANAGEMENT

PROJECT SCOPE MANAGEMENT

CHAPTER 4

Syllabus for Chapter 4

Project Risk Management : contingency planning ,scheduling resources ,
reducing project duration .
1. Why should a project manager understand risk?
Every project manager understands risks are inherent in projects. No
amount of planning can overcome risk, or the inability to control chance
events. In the context of projects, risk is an uncertain event or condition
that, if it occurs, has a positive or negative effect on project objectives. A
risk has a cause and, if it occurs, a consequence. For example, a cause
may be a flu virus or change in scope requirements. The event is that team
members get striken with the flu or the product has to be redesigned. If
either of these uncertain events occurs, it will impact the cost, schedule,
and quality of the project.
Some potential risk events can be identified before the project startssuch
as equipment malfunction or change in technical requirements. Risks can
be anticipated consequences, like schedule slippages or cost overruns.
Risks can be beyond imagination like the September 11, 2001, attack on
the Twin Towers in New York City.
2. What is risk management?
Risk management attempts to recognize and manage potential and
unforeseen trouble spots that may occur when the project is implemented.
Risk management identifies as many risk events as possible (what can go
wrong), minimizes their impact (what can be done about the event before
the project begins), manages responses to those events that do materialize
(contingency plans), and provides contingency funds to cover risk events
that actually materialize.
3. Explain in detail the risk management process.
The chances of a risk event occurring (e.g., an error in time estimates, cost
estimates, or design technology) are greatest in the concept, planning, and
start-up phases of the project. The cost impact of a risk event in the
project is less if the event occurs earlier rather than later. The early stages
of the project represent the period when the opportunity for minimizing the
impact or working around a potential risk exists. Conversely, as the project
passes the halfway implementation mark, the cost of a risk event occurring
increases rapidly. For example, the risk event of a design flaw occurring
after a prototype has been made has a greater cost or time impact than if
the event occurred in the start-up phase of the project. Clearly, identifying
project risk events and deciding a response before the project begins is a
more prudent approach than not attempting to manage risk.

PROF. KERENA ANAND

Page 1

OPERATIONS STRATEGY

KRUPANIDHI SCHOOL OF MANAGEMENT

1: Risk Identification
The risk management process begins by trying to generate a list of all the
possible risks that could affect the project. Typically the project manager
pulls together, during the planning phase, a risk management team
consisting of core team members and other relevant stakeholders. The
team uses brainstorming and other problem identifying techniques to
identify potential problems. Participants are encouraged to keep an open
mind and generate as many probable risks as possible. More than one
project has been bushwhacked by an event that members thought was
preposterous in the beginning. Later during the assessment phase, participants will have a chance to analyze and filter out unreasonable risks.
One common mistake that is made early in the risk identification process
is to focus on objectives and not on the events that could produce
consequences. For example, team members may identify failing to meet
schedule as a major risk. What they need to focus on are the events that
could cause this to happen (i.e., poor estimates, adverse weather, shipping
delays, etc.). Only by focusing on actual events can potential solutions be
found.
After the macro risks have been identified, specific areas can be checked.
An effective tool for identifying specific risks is the work breakdown
structure. Use of the WBS reduces the chance a risk event will be missed.
On large project multiple risk teams are organized around specific
PROF. KERENA ANAND

Page 2

OPERATIONS STRATEGY

KRUPANIDHI SCHOOL OF MANAGEMENT

deliverables and submit their risk management reports to the project

manager.
A risk profile is another useful tool. A risk profile is a list of questions that
address traditional areas of uncertainty on a project. These questions have
been developed and refined from previous, similar projects.
Good risk profiles, like RBSs, are tailored to the type of project in question.
For example, building an information system is different from building a
new car. They are organization specific. Risk profiles recognize the unique
strengths and weaknesses of the firm. Finally, risk profiles address both
technical and management risks.
Risk profiles are generated and maintained usually by personnel from the
project office. They are updated and refined during the post project audit).
These profiles, when kept up to date, can be a powerful resource in the
risk management process. The collective experience of the firms past
projects resides in their questions.
Historical records can complement or be used when formal risk profiles are
not available. Project teams can investigate what happened on similar
projects in the past to identify potential risks. For example, a project
manager can check the on-time performance of selected vendors to gauge
the threat of shipping delays. IT project managers can access best
practices papers detailing other companies experiences Converting
software systems. Inquiries should not be limited to recorded data. Savvy
project managers tap the wisdom of others by seeking the advice of veteran
project managers.
Step 2: Risk Assessment
Step 1 produces a list of potential risks. Not all of these risks deserve
attention. Some are trivial and can be ignored, while others pose serious
threats to the welfare of the project. Managers have to develop methods for
sifting through the list of risks, eliminating inconsequential or redundant
ones and stratifying worthy ones in terms of importance and need for
attention.
*
Scenario analysis is the easiest and most commonly used technique for
analyzing risks. Team members assess the significance of each risk event
in terms of:
Probability of the event.
Impact of the event.
Simply stated, risks need to be evaluated in terms of the likelihood the
event is going to occur and the impact or consequences of its occurrence.
The risk of a project manager being struck by lightning at a work site
would have major negative impact on the project, but the likelihood is so
low if is not worthy of consideration. Conversely, people do change jobs, so
an event like the loss of key project personnel would have not only an
adverse impact but also a high likelihood of occurring in some
organizations. If so, then it would be wise for that organization to be
proactive and mitigate this risk by developing incentive schemes for
retaining specialists and/or engaging in cross-training to reduce the
impact of turnover.
Step 3: Risk Response Development
When a risk event is identified and assessed, a decision must be made
concerning which response is appropriate for the specific event. Responses
to risk can be classified as mitigating, avoiding, transferring, sharing, or
retaining.
Mitigating Risk
PROF. KERENA ANAND

Page 3

OPERATIONS STRATEGY

KRUPANIDHI SCHOOL OF MANAGEMENT

Reducing risk is usually the first alternative considered. There are

basically two strategies for mitigating risk:
(1) reduce the likelihood that the event will occur and/or (2) reduce the
impact that the adverse event would have on the project. Most risk teams
focus first on reducing the likelihood of risk events since, if successful, this
may eliminate the need to consider the potentially costly second strategy.
Testing and prototyping are frequently used to prevent problems from
surfacing later in a project. An example of testing can be found in an
information systems project. The project team was responsible for
installing a new operating system in their parent company Before
implementing the project, the team tested the system on a smaller isolated
network. By doing so they discovered a variety of problems and were able
to come up with solutions prior to implementation. The team still
encountered problems with the installation but the number and severity
were greatly reduced.
Often identifying the root causes of an event is useful. For example, the
fear that a vendor will be unable to supply customized components on time
may be attributable to (1) poor vendor relationships, (2) design
miscommunication, and (3) lack of motivation. As a result of this analysis
the project manager may decide to take his counterpart to lunch to clear
the air, invite the vendor to attend design meetings, and restructure the
contract to include incentives for on-time delivery.

Mitigating Risk
Reducing risk is usually the first alternative considered. There are
basically two strategies for mitigating risk:
(1) reduce the likelihood that the event will occur and/or (2) reduce the
impact that the adverse event would have on the project. Most risk teams
focus first on reducing the likelihood of risk events since, if successful, this
may eliminate the need to consider the potentially costly second strategy.
Avoiding Risk
Risk avoidance is changing the project plan to eliminate the risk or
condition. Although it is impossible to eliminate all risk events, some
specific risks may be avoided before you launch the project. For example,
adopting proven technology instead of experimental technology can
eliminate technical failure. Choosing an Australian supplier as opposed to
an Indonesian supplier would virtually eliminate the chance that political
unrest would disrupt the supply of critical materials.
Step 4: Risk Response Control
'
The last step in the risk management process is risk controlexecuting
the risk response strategy, monitoring triggering events, initiating
contingency plans, and watching for new risks. Establishing a change
management system to deal with events that require formal changes in the
scope, budget, and/or schedule of the project is an essential element of
risk control.
Project managers need to monitor risks just like they track
project*progress. Risk assessment and updating needs to be part of every
status meeting and progress report system. The project team needs to be
on constant alert for new, unforeseen risks. Management needs to be
sensitive that others may not be forthright in acknowledging new risks and
problems. Admitting that there might be a bug in the design code or tha*
different components are not compatible reflects poorly on individual
performance. If the prevailing organizational culture is one where mistakes
are punished severely, then it is only human nature to protect oneself.
PROF. KERENA ANAND

Page 4

OPERATIONS STRATEGY

KRUPANIDHI SCHOOL OF MANAGEMENT

Similarly, if bad news is greeted harshly and there is a propensity to kill

the messenger, then participants will be reluctant to speak freely. The
tendency to suppress bad news is compounded when individual responsibility is vague and the project team is under extreme pressure from top
management to get the project done quickly.
Project managers need to establish an environment in which participants
feel comfortable raising concerns and admitting mistakes. The norm
should be that mistakes are acceptable, hiding mistakes is intolerable.
Problems should be embraced not denied. Participants should be
encouraged to identify problems and new risks. Here a positive attitude by
the project manager toward risks is a key.
On large, complex projects it may be prudent to repeat the risk
identification/assessment exercise with fresh information. Risk profiles
should be reviewed to test to see if the original responses held true.
Relevant stakeholders should be brought into the discussion. While this
may not be practical on an ongoing basis, project managers should touch
base with them on a regular basis or hold special stakeholder meetings to
review the status of risks on the project.
A second key for controlling the cost of risks is documenting responsibility.
This can be problematic in projects involving multiple organizations and
contractors. Responsibility for risk is frequently passed on to others with
the statement, That is not my worry. This mentality is dangerous. Each
identified risk should be assigned (or shared) by mutual agreement of the
owner, project manager, and the contractor or person having line
responsibility for the work package or segment of the project. It is best to
have the line person responsible approve the use of budget reserve funds
and monitor their rate of usage. If management reserve funds are required,
the line person should play an active role in estimating additional costs
and funds needed to complete the project. Having line personnel
participate in the process focuses attention on the management reserve,
control of its rate of usage, and early warning of potential risk events. If
risk management is not formalized, responsibility and responses to risk
will be ignoredit is not my area.
The bottom line is that project managers and team members need to be
vigilant in monitoring potential risks and identify new land mines that
could derail a project. Risk assessment has to be part of the working
agenda of status meetings and when new risks emerge they need to be
analyzed and incorporated into the risk management process.
4. What is the importance of scheduling resources?
There are always more project proposals than there are available
resources. The priority system needs to select projects that best contribute
to the organizations objectives, within the constraints of the resources
available. If all projects and their respective resources are computer
scheduled, the feasibility and impact of adding a new project to those in
process can be quickly assessed. With this information the project priority
team will add a new project only if resources are available to be formally
committed to that specific project. This chapter examines methods of
scheduling resources so the team can make realistic judgments of resource
availability and project durations. The project manager uses the same
schedule for implementing the project. If changes occur during project
implementation, the computer schedule is easily updated and the effects
easily assessed.
If resources are adequate but the demand varies widely over the life of the
project, it may be desirable to even out resource demand by delaying
noncritical activities (using slack) to lower peak demand and, thus,
increase resource utilization. This process is called resource leveling or
smoothing.
On the other hand, if resources are not adequate to meet peak demands,
the late start of some activities must be delayed, and the duration of the
PROF. KERENA ANAND

Page 5

OPERATIONS STRATEGY

KRUPANIDHI SCHOOL OF MANAGEMENT

project may be increased. This process is called resource- constrained

scheduling. One research study by your author of more than 50 projects
found that planned project network durations were increased 38 percent
when resources were scheduled.
5. What are the types of resource constraints?
Types of Resource Constraints
Resources are people, equipment, and material that can be drawn on to
accomplish something. In projects the availability or unavailability of
resources will often influence the way projects are managed.
People This is the most obvious and important project resource. Human
resources are usually classified by the skills they bring to the projectfor
example, programmer, mechanical engineer, welder, inspector, marketing
director, supervisor. In rare cases some skills are interchangeable, but
usually with a loss of productivity. The many differing skills of human
resources add to the complexity of scheduling projects.'
Materials Project materials cover a large spectrum: for example, chemicals
for a scientific project, concrete for a road project, survey data for a
marketing project.
Material availability and shortages have been blamed for the delay of many
projects. When it is known that a lack of availability of materials is
important and probable, materials should be included in the project'
network plan and schedule.
Equipment Equipment is usually presented by type, size, and quantity. In
some cases equipment can be interchanged to improve schedules, but this
is not typical. Equipment is often overlooked as a constraint. The most
common oversight is to assume the resource pool is more than adequate
for the project. For example, if a project needs one earth-moving tractor six
months from now and the organization owns four, it is common to assume
the resource will not delay the pending project. However, when the earthmoving tractor is due on-site in six months, all four machines in the pool
might be occupied on other projects.
6. What is the difference between time constrained project and a
resource constrained project?
Most of the scheduling methods available today require the project
manager to classify the project as either time constrained or resource
constrained. One simple test to determine if the project is time or resource
constrained is to ask, If the critical path is delayed, will resources be
added to get back on schedule? If the answer is yes, assume the project is
time constrained; if no, assume the project is resource constrained.
A time-constrained project is one that must be completed by an imposed
date. If required, resources can be ad4ed to ensure the project is completed
by a specific date. Although time is the critical factor, resource usage
should be no more than is necessary and sufficient.
A resource-constrained project is one that assumes the level of resources
available cannot be exceeded. If the resources are inadequate, it will be
acceptable to delay the project, but as little as possible.
In scheduling terms, time constrained.means time (project duration) is
fixed and resources are flexible, while resource constrained means
resources are fixed and time is flexible. Methods for scheduling these
projects are presented in the next section.
7. What is meant by splitting activities?
PROF. KERENA ANAND

Page 6

OPERATIONS STRATEGY

KRUPANIDHI SCHOOL OF MANAGEMENT

Splitting tasks is a scheduling technique used to get a better project

schedule and/or to increase resource utilization. A planner splits the
continuous work included in an activity by interrupting the work and
sending the resource to another activity for a period of time and then
having the resource resume work on the original activity. Splitting can be a
useful tool if the work involved does not include large start-up or shutdown
costsfor example, moving equipment from one activity location to
another. The most common error is to interrupt people work, where there
are high conceptual start-up and shutdown costs. For example, having a
bridge designer take time off to work on the design problem of another
project may cause this individual to lose four days shifting conceptual
gears in and out of two activities. The cost may be hidden, but it is real.
8. Write a note on Multiproject Resource Schedules
For clarity we have discussed key resource allocation issues within the
context of a single project. In reality resource allocation generally occurs in
multiproject environment where the demands of one project have to be
reconciled with the needs of other projects. Organizations must develop
and manage systems for efficiently allocating and scheduling resources
across several projects with different priorities, resource requirements, sets
of activities, and risks. The system must be dynamic and capable of
accommodating new projects as well as reallocating resources once project
work is completed. While the same resource issues and principles that
apply to a single project also apply to this multiproject environment,
application and solutions are more complex, given the interdependency
among projects.
The following lists three of the more common problems encountered in
managing multiproject resource schedules. Note that these are macro
manifestations of single-project problems that are now magnified in a
multiproject environment:
Overall schedule slippage. Because projects often share resources, delays
in one project can have a ripple effect and delay other projects. For
example, work on one software development project can grind to a halt
because the coders scheduled for the next critical task are late in
completing their work on another development project.
Inefficient resource utilization. Because projects have different
schedules and requirements, there are peaks and valleys in overall
resource demands. For example, a firm may have a staff of 10 electricians
to meet peak demands when, under normal conditions, only 5 electricians
are required.
Resource bottlenecks. Delays and schedules are extended as a result of
shortages of critical resources that are required by multiple projects.
9. What are the Options for Accelerating Project Completion?
Options When Resources Are Not Constrained
Adding Resources
The most common method for shortening project time is to assign
additional staff and equipment to activities. There are limits, however, as to
how much speed can be gained by adding staff. Doubling the size of the
workforce will not necessarily reduce completion time by half. The
relationship would be correct only when tasks can be partitioned so
minimal communication is needed between workers, as in harvesting a crop
by hand or repaving a highway. Most projects are not set up that way;
additional workers increase the communication requirements to coordinate
their efforts. For example, doubling a team by adding two workers requires
six times as much pairwise intercommunication than is required in the
PROF. KERENA ANAND

Page 7

OPERATIONS STRATEGY

KRUPANIDHI SCHOOL OF MANAGEMENT

original two-person team. Not only is more time needed to coordinate and
manage a larger team; there is the additional delay of training the new
people and getting them up to speed on the project. The end result is
captured in Brooks law: Adding manpower to a late software project makes
it later.
Outsourcing Project Work
A common method for shortening the project time is to subcontract an
activity. The subcontractor may have access to superior technology or
expertise that will accelerate the completion of the activity. For example,
contracting for a backhoe can accomplish in two hours what it can take a
team of laborers two days to do. Likewise, by hiring a consulting firm that
specializes in ADSI programming, a firm may be able to cut in half the time
it would take for less experienced, internal programmers to do the work.
Subcontracting also frees up resources that can be assigned to a critical
activity and will ideally result in a shorter project duration.
Scheduling Overtime
The easiest way to add more labor to a project is not to add more people,
but to schedule overtime. If a team works 50 hours a week instead of 40, it
might accomplish 25 percent more. By scheduling overtime you avoid the
additional costs of coordination and communication encountered when new
people are added. If people involved are salaried workers, there may be no
real additional cost for the extra work. Another advantage is that there are
fewer distractions when people work outside normal hours.
Overtime has disadvantages. First, hourly workers are typically paid time
and a half for overtime and double time for weekends and holidays.
Sustained overtime work by salaried employees may incur intangible costs
such as divorce, burnout, and turnover. The latter is a key organizational
concern when there is a shortage of workers. Furthermore, it is an
oversimplification to assume that, over an extended period of time, a person
is as productive during his or her eleventh hour at work as during his or
her third hour of work. There are natural limits to what is humanly
possible, and extended overtime may actually lead to an overall decline in
productivity when fatigue sets in.
Overtime and working longer hours is the preferred choice for accelerating
project completion, especially when the project team is salaried. The key is
to use overtime judiciously. Remember a project is a marathon not a sprint!
You do not want to run out of energy before the finish line.
Establish a Core Project Team
One of the advantages of creating a dedicated core team to complete a
project is speed. Assigning professionals full time to a project avoids the
hidden cost of multitasking in which people are forced to juggle the
demands of multiple projects. Professionals are allowed to devotejheir
undivided attention to a specific_project. This singular focus creates a
shared goal that can bind a diverse set of profes- sionals to a highly
cohesive team capable of accelerating project completion. Do It TwiceFast
and Correctly
If you are in a hurry, try building a quick and dirty short-term solution,
then go back and do it the right way. For example, the Rose Garden
stadium in Portland, Oregon, was supposed to be completely finished in
time for the start of the 1995-1996 National Basketball Association (NBA)
season. Delays made this impossible, so the construction crew set up
temporary bleachers to accommodate the opening-night crowd. The
additional costs of doing it twice are often more than compensated for by
the benefits of satisfying the deadline.
PROF. KERENA ANAND

Page 8

OPERATIONS STRATEGY

KRUPANIDHI SCHOOL OF MANAGEMENT

Options When Resources Are Constrained

A project manager has fewer options for accelerating project completion
when additional resources are either not available or the budget is severely
constrained. This is especially true once the schedule has been established.
Below are some of these options.
Fast-Tracking
Sometimes it is possible to rearrange the logic of the project network so that
critical activities are done in parallel (concurrently) rather than
sequentially. This alternative is a good one if the project situation is right.
When this alternative is given serious attention, it is amazing to observe
how creative project team members can be in finding ways to restructure
sequential activities in parallel. One of the most common methods for
restructuring activities is to change a finish-to-start relationship to a startto-start relationship. For example, instead of waiting for the final design to
be approved, manufacturing engineers can begin building the production
line as soon as key specifications have been established. Changing activities
from sequential to parallel usually requires closer coordination among those
responsible for the activities affected but can produce tremendous time
savings.
Critical-Chain
Critical-chain project management (CCPM) is designed to accelerate project
completion. At the same time, it would be difficult to apply CCPM
midstream in a project. CCPM requires considerable training and a shift in
habits and perspectives that take time to adopt. Although there have been
reports of immediate gains, especially in terms of completion times, a longterm management commitment is probably necessary to reap full benefits.
Reducing Project Scope
Probably the most common response for meeting unattainable deadlines is
to reduce or scale back the scope of the project. This invariably leads to a
reduction in the functionality of the project. For example, the new car will
average only have 25 mpg instead of 30, or the software product will have
fewer features than originally planned. While scaling back the scope of the
project can lead to big savings in both time and money, it may come at a
cost of reducing the value of the project. If the car gets lower gas mileage,
will it stand up to competitive models? Will customers still want the
software minus the features?
The key to reducing a project scope without reducing value is to reassess
the true specifications of the project. Often requirements are added under
best-case, blue-sky scenarios and represent desirables, but not essentials.
Here it is important to talk to the customer and/or project sponsors and
explain the situationyou can get it your way but not until February. This
may force them to accept extension or to add money to expedite the project.
If not, then a healthy discussion of what the essential requirements are and
what items can be compromised in order to meet the deadline needs to take
place. More intense re-examination of requirements may actually improve
the value of the project by getting it done more quickly and for a lower cost:
Calculating the savings of reduced project scope begins with the work
breakdown structure. Reducing functionality means certain tasks,
deliverables, or requirements can be reduced or even eliminated. These
tasks need to be found and the schedule adjusted. Focus should be on
changes in activities on the critical path.
Compromise Quality
Reducing quality is always an option, but it is rarely acceptable or used. If
quality is sacrificed, it may be possible to reduce-the time of an activity on
PROF. KERENA ANAND

Page 9

OPERATIONS STRATEGY

KRUPANIDHI SCHOOL OF MANAGEMENT

the critical path.

In practice the methods most commonly used to crash projects are
scheduling overtime, outsourcing, and adding resources, Each of these
maintains the essence of the original plan. Options that depart from the
original project plan include do it twice and fast-tracking. Rethinking of
project scope, customer needs, and timing become major considerations for
these techniques.

PROF. KERENA ANAND

Page 10