Software Project Management

Dr. Bharat Singh

1
Organization of this
Lecture
Responsibilities and activities of a
software project manager
Project planning activity
Estimation techniques

2
Software Project Management

The main goal of software project

management is to enable a group of
developers to work effectively
towards the successful completion
of a project.

3
SPM COMPLEXITIES

Invisibility: Invisibility of software makes it

difficult to assess the progress of a project and is
a major cause for the complexity of managing a
software project.
Changeability: Frequent changes to the
requirements and the invisibility of software are
possibly the two major factors making software
project management a complex task.

4
SPM COMPLEXITIES

Complexity: Even a moderate sized software has

millions of parts (functions) that interact with each other in many
ways—data coupling, serial and concurrent runs, state transitions,
control dependency, file sharing, etc

Uniqueness: Every software project is usually

associated with many unique features or situations.

Exactness of the solution

Team-oriented and intellect-
intensive work
5
RESPONSIBILITIES OF A SPM

Responsibilities of a project
manager
Project Planning
Project Monitoring

6
RESPONSIBILITIES OF A SPM

Skills necessary to accomplish

those.
Three skills that are most critical to
successful project management are the
following:
Knowledge of project management
techniques.
Decision taking capabilities.
Previous experience in managing similar
projects.
7
Project Planning

Once a project has been found to be feasible,

software project managers undertake project
planning.
Initial project planning is undertaken and
completed before any development activity
starts.
Precedence ordering among planning activities.

8
Project Planning

During project planning, the project manager performs

the following activities.
Estimation: The following project attributes are
estimated.
„ ost: How much is it going to cost to develop the software
C
product?
„ Duration: How long is it going to take to develop the
product?
„ Effort: How much effort would be necessary to develop the
product?

9
Project Planning
The effectiveness of all later planning activities such as
scheduling and staffing are dependent on the accuracy with
which these three estimations have been made.
Scheduling: After all the necessary project parameters have
been estimated, the schedules for manpower and other resources
are developed.
Staffing: Staff organisation and staffing plans are made.
Risk management: This includes risk identification, analysis,
and abatement planning.
Miscellaneous plans: This includes making several other plans
such as quality assurance plan, and configuration management
plan, etc.

10
Sliding Window Planning
Very difficult to make accurate plans for large
projects .
During the span of the project, the project
parameters, scope of the project, project staff,
etc., often change drastically resulting in the
initial plans going haywire.
Planning a project over a number of stages
protects managers from making big
commitments at the start of the project.
This technique of staggered planning is known
as sliding window planning.
11
Sliding Window Planning

The complexities of different project activities

become clear, some of the anticipated risks get
resolved, and new risks appear.
The project parameters are re-estimated
periodically as understanding grows and also
aperiodically as project parameters change.
By taking these developments into account, the
project manager can plan the subsequent
activities more accurately and with increasing
levels of confidence.
12
Metrics for Project Size Estimation

Project size It is not MB or BYTE

-

Two metrics are popularly being used

to measure size—
lines of code (LOC)
function point (FP).

13
Metrics for Project Size Estimation

Lines of code (LOC)

The project manager divides the
problem into modules, and each
module into sub-modules and so on,
until the LOC of the leaf-level modules
are small enough to be predicted.

14
Metrics for Project Size Estimation
LOC metric has several shortcomings when
used to measure problem size.
LOC is a measure of coding activity alone.
LOC count depends on the choice of specific instructions
LOC measure correlates poorly with the quality and efficiency of the
code
LOC metric penalises use of higher-level programming languages
and code reuse
LOC metric measures the lexical complexity of a program and does
not address the more important issues of logical and structural
complexities:
It is very difficult to accurately estimate LOC of the final program
from problem specification:

15
Metrics for Project Size Estimation

Function Point (FP)

Function point metric was proposed by
Albrecht and Gaffney in 1983.
It can easily be computed from the
problem specification itself.

16
Metrics for Project Size Estimation

Function Point (FP)

The conceptual idea behind the function
point metric is-
The size of a software product is directly
dependent on the number of different high-
level functions or features it supports.
This assumption is reasonable, since each
feature would take additional effort to
implement.
17
Metrics for Project Size Estimation

Function Point (FP)

System function as a mapping of input data to output data
in addition to the number of basic functions that a software
performs, its size also depends on the number of files and the
number of interfaces associated with it.

18
Metrics for Project Size Estimation

Function Point (FP) metric computation

System function as a mapping of input data to output
data
In addition to the number of basic functions that a
software performs, its size also depends on the number
of files and the number of interfaces associated with it.

19
Metrics for Project Size Estimation

Function Point (FP) metric computation

The size of a software product (in units of function points or FPs)
is computed using different characteristics of the product
identified in its requirements specification. It is computed using
the following three steps:
Compute the using a heuristic expression. unadjusted function
point (UFP)
Refine UFP to reflect the actual complexities of the different
parameters used in UFP computation.
Compute FP by further refining UFP to account for the specific
characteristics of the project that can influence the entire
development effort.

20
Metrics for Project Size Estimation

Function Point (FP) metric computation

UFP = (Number of inputs)*4 + (Number
of outputs)*5 + (Number of inquiries)*4
+ (Number of files)*10 + (Number of
interfaces)*10

21
Metrics for Project Size Estimation

Function point
Function point and feature point metrics
claim that these two metrics are
language-independent and can be easily
computed from the SRS document during
project planning stage itself

22
PROJECT ESTIMATION
TECHNIQUES

These can broadly be classified into three

main categories:
Empirical estimation techniques
Heuristic techniques
Analytical estimation techniques

23
PROJECT ESTIMATION
TECHNIQUES

These can broadly be classified into three

main categories:
Empirical estimation techniques
essentially based on making an guess of the
project parameters.
While using this technique, prior experience with
development of similar products is helpful.
based on common sense and subjective
decisions, over the years.
Expert judgement and the Delphi techniques 24
PROJECT ESTIMATION
TECHNIQUES

These can broadly be classified into three

main categories:
Heuristic techniques
Heuristic techniques assume that the relationships that exist
among the different project parameters can be satisfactorily
modelled using suitable mathematical expressions.
COCOMO model

25
PROJECT ESTIMATION
TECHNIQUES

These can broadly be classified into three

main categories:
Analytical estimation techniques
Analytical techniques do have certain scientific
basis.
Halstead’s software science
Halstead’s software science is especially useful
for estimating software maintenance efforts

26
software maintenance efforts

27
COCOMO— COnstructive COst
estimation MOdel

Proposed by Boehm [1981]

COCOMO prescribes a three stage process
for project estimation.
In the first stage, an initial estimate is
arrived at.
Over the next two stages, the initial
estimate is refined to arrive at a more
accurate estimate.
28
COCOMO— COnstructive COst
estimation MOdel

The three stages of COCOMO estimation

technique are—
Basic COCOMO,
Intermediate COCOMO,
Complete/Detailed COCOMO.

29
COCOMO— COnstructive COst
estimation MOdel

Basic classes of software development

projects

Organic
Semidetached
Embedded

30
COCOMO— COnstructive COst
estimation MOdel

Basic classes of software development

projects

Organic
if the project deals with developing a well-
understood application program, the size of the
development team is reasonably small, and the
team members are experienced in developing
similar types of projects
31
COCOMO— COnstructive COst
estimation MOdel

Basic classes of software development

projects
Semidetached
if the development team consists of a mixture of
experienced and inexperienced staff. Team
members may have limited experience on
related systems but may be unfamiliar with
some aspects of the system being developed.

32
COCOMO— COnstructive COst
estimation MOdel

Basic classes of software development

projects
Embedded
if the software being developed is strongly coupled
to hardware, or if stringent regulations on the
operational procedures exist.
Team members may have limited experience on
related systems but may be unfamiliar with some
aspects of the system being developed.
33
Basic COCOMO—

The basic model is used for quick and rough cost calculations
for the software. It calculates the effort, time, and number of
people required to use a project's kLOC (kilo lines of code).
The formulae to calculate these entities are:

34
Basic COCOMO—

The constants a, b, c, and d vary for each

model type.
The following are the constant values for
the basic model:

35
Basic COCOMO Example

Suppose a project was estimated to be made in 400

kLOC. Lets calculate its effort, time, and the number
of people required while considering the project is of
organic type.

36
Basic COCOMO Example

Assume that the size of an organic type software product has been
estimated to be 32,000 lines of source code. Assume that the average
salary of a software developer is `15,000 per month. Determine the effort
required to develop the software product, the nominal development time,
and the cost to develop the product.

37
Basic COCOMO

Person-Month Curve
Person-month (PM) is considered to be an appropriate unit for
measuring effort, because developers are typically assigned to
a project for a certain number of months

38
Basic COCOMO

Effort Vs Size plot

The effort required to develop a product

increases rapidly with project size. 39
Basic COCOMO

Development Time Vs Size plot

The development time is a sublinear function of the size of the
product.

40
Basic COCOMO

Cost Estimation
Project cost can be obtained by multiplying the
estimated effort (in man-month) by the manpower
cost per month.
A project would incur several other types of
costs which we shall refer to as the
overhead costs.
The overhead costs would include the costs due to
hardware and software required for the project and the
company overheads for administration, office space,
electricity, etc. 41
Basic COCOMO

Effort and Duration estimation

if you try to complete the project in a time
shorter than the estimated duration, then
the cost will increase drastically.

But, if you complete the project over a

longer period of time than that estimated,
then there is almost no decrease in the
estimated cost value.
42
Basic COCOMO

Staff Size estimation

E/T
It would clear that the simple division
approach to obtain the staff size would be
highly improper.

43
Intermediate COCOMO

The basic COCOMO model assumes that effort and

development time are functions of the product size
alone.
Other project parameters besides the product size affect
the effort as well as the time required to develop the
product. For example, the effort to develop a product
would vary depending upon the sophistication of the
development environment.

The intermediate COCOMO model

recognises this fact and refines the
initial estimates. 44
Intermediate COCOMO

The effort factor includes the effort

adjustment factor (EAF) that is calculated
with the cost drivers.

The EAF is calculated by multiplying the

parameter values of different cost driver
attributes. Ideally, the value is 1.
45
Intermediate COCOMO

The intermediate COCOMO model uses a set of

15 cost drivers (multipliers) that are determined
based on various attributes of software
development.
Cost driver can be classified as following attributes
Product attributes
Computer attributes
Personnel attributes
Development Environment attributes

46
Intermediate COCOMO
Cost drivers
The cost drivers and their attributes are as follows:
Product attributes
The product attributes are as follows:
Required software reliability extent
Size of the application database
The complexity of the product

47
Intermediate COCOMO
Cost drivers
Computer/Hardware attributes
The hardware attributes are as follows:
Run time performance constraints
Memory constraints
The volatility of the virtual machine environment
Required turnabout time

48
Intermediate COCOMO
Cost drivers
Personal attributes
The personal attributes are as follows:
Analyst capabilities
Software engineering capabilities
Applications experience
Virtual machine experience
Programming language experience

49
Intermediate COCOMO
Cost drivers
Development environment/Project attributes
The project attributes are as follows:
Use of software tools
Application of software engineering methods
Required development schedule

50
Intermediate COCOMO
Example
Suppose a project was estimated to be made in 400 kLOC. let's
calculate its effort, time, and the number of people required while
considering the project is of organic type and has a nominal
complexity. The developer has a high virtual machine experience.

Nominal complexity of a project is 1.00

High virtual experience of the developer is 0.90

51
Detailed or Complete
COCOMO model

A major shortcoming of both the basic and the

intermediate COCOMO models is that they consider a
software product as a single homogeneous entity.

Most large systems are made up of

several smaller sub-systems.
These sub-systems often have widely
different characteristics.

52
Detailed or Complete
COCOMO model
The detailed model is a combination of both the basic model and
the intermediate model.
The model is decomposed into multiple modules, and the COCOMO
model is applied to them individually.
This model uses various effort multipliers for each cost driver
attribute, and the cost is calculated at each stage separately.
The six stages of the detailed model are as follows:
Planning and requirements
System design
Detailed design
Module code and test
Integration and test
Cost constructive model

53
Detailed or Complete
COCOMO model

Example
A distributed management information system (MIS)
product for an organisation having offices at several
places across the country can have the following sub-
component.
Database part- semi detached
Graphical user interface (GUI)part-Organic
Communication part-- embedded

54
COCOMO II

Product-oriented development projects that were being

undertaken a few years ago, service-oriented projects
have now become popular.
The present day software products are highly interactive
and support elaborate graphical user interface.
Effort spent on developing the GUI part is often as much
as the effort spent on developing the actual functionality
of the software.

55
COCOMO II
COCOMO 2 provides three models to arrive at increasingly accurate
cost estimations.
These can be used to estimate project costs at different phases of
the software product.
As the project progresses, these models can be applied at the
different stages of the same project.
Application composition model: This model as the name suggests, can be
used to estimate the cost for prototype development.
Early design model: This supports estimation of cost at the architectural
design stage.
Post-architecture model: This provides cost estimation during detailed
design and coding stages.

56
COCOMO II

Accuracy of different COCOMO II estimations.

57
HALSTEAD’S SOFTWARE
SCIENCE

To measure size, development effort, and

development cost of software products.
Halstead used a few primitive program
parameters to develop the expressions for
overall program length
potential minimum volume
actual volume
language level
effort, and
development time.
58
HALSTEAD’S SOFTWARE
SCIENCE

For a given program, let:

η1 be the number of unique operators used in the
program,
η2 be the number of unique operands used in the
program,
N1 be the total number of operators used in the
program,
N2 be the total number of operands used in the
program.

59
HALSTEAD’S SOFTWARE
SCIENCE
Length and Vocabulary
length N = N1 + N2
program vocabulary η = η1 + η2.
Program Volume
V = N log2 η
Potential Minimum Volume
The potential minimum volume V* is defined as the volume of
the most succinct program.
V* = (2 + η2) log2(2 + η2)
The program level L is given by L = V*/V
The higher the level of a language, the less effort it
takes to develop a program using that language.
60
HALSTEAD’S SOFTWARE
SCIENCE

Effort and Time

effort E = V/L, E is the number of mental discriminations required
to implement the program
The effort required to develop a program can be obtained by
dividing the program volume with the level of the programming
language used to develop the code.

Length Estimation
Halstead suggests a way to determine the length of a
program using the number of unique operators and
operands used in the program.

61
HALSTEAD’S SOFTWARE
SCIENCE example

Consider the expression a = &b;

a, b are the operands and =, & are the operators.

62
HALSTEAD’S SOFTWARE
SCIENCE example

The function name in a function definition is not counted

as an operator.
int func ( int a, int b )
{...}
The operators are: {}, ( ) We do not consider func, a,
and b as operands.

63
HALSTEAD’S SOFTWARE
SCIENCE example

Consider the function call statement: func (a, b);.

func ‘,’ and ; are considered as operators and variables
a, b are treated as operands.

64
HALSTEAD’S SOFTWARE
SCIENCE example

Let us consider the following C program:

65
STAFFING LEVEL ESTIMATION

The staffing requirement for the

project can be determined
Norden’s Work
Putnam’s Work
Jansen’s Model

66
STAFFING LEVEL ESTIMATION
Norden’s Work
Norden concluded that the staffing pattern for any R&D project
starting from a low level, increases until it reaches a peak value. It
then starts to diminish. This pattern can be approximated by the
Rayleigh distribution curve.

Norden represent the Rayleigh curve as

67
STAFFING LEVEL ESTIMATION

Norden’s Work
Norden represent the Rayleigh curve as

where,
E is the effort required at time t.
E is an indication of the number of developers
K is the area under the curve, and
td is the time at which the curve attains its maximum
value.
It must be remembered that the results of Norden are applicable to
general R&D projects 68
STAFFING LEVEL ESTIMATION

Putnam’s Work
software development projects has characteristics very
similar to any other R&D projects.
Only a small number of developers are needed at the
beginning of a project to carry out the planning and
specification tasks. As the project progresses and more
detailed work is performed, the number of developers
increases and reaches a peak during product testing.
After implementation and unit testing, the number of
project staff falls

69
STAFFING LEVEL ESTIMATION

Putnam’s Work

where
K is the total effort expended (in PM) in the product development
and
L is the product size in KLOC
td corresponds to the time of system and integration and testing.
Therefore, td can be approximately considered as the time required
to develop the software.
Ck is the state of technology constant and reflects constraints that
impede the progress of the programmer.

70
STAFFING LEVEL ESTIMATION
Putnam’s Work

Typical values of
Ck = 2 for poor development environment (no
methodology, poor documentation, and review, etc.),
Ck = 8 for good software development environment
(software engineering principles are adhered to),
Ck = 11 for an excellent environment (in addition to
following software engineering principles, automated
tools and techniques are used).
71
STAFFING LEVEL ESTIMATION

Jansen’s Model
Jensen model is very similar to Putnam model
It attempts to soften the effect of schedule compression
on effort to make it applicable to smaller and medium
sized projects.

where,
Cte is the effective technology constant,
td is the time to develop the software, and
K is the effort needed to develop the software.
72
SCHEDULING

Scheduling the project tasks is an important project planning activity.

In order to schedule the project activities, a software project manager needs to
do the following:
1.Identify all the major activities that need to be carried out to complete the
project.
2. Break down each activity into tasks.
3. Determine the dependency among different tasks.
4. Establish the estimates for the time durations necessary to complete the
tasks.
5. Represent the information in the form of an activity network.
6. Determine task starting and ending dates from the information represented in
the activity network.
7. Determine the critical path. A critical path is a chain of tasks that determines
the duration of the project.
8. Allocate resources to tasks.
73
SCHEDULING
Work Breakdown Structure
Work breakdown structure (WBS) is used to
recursively decompose a given set of activities into
smaller activities.
Tasks are the lowest level work activities in a WBS
hierarchy. They also form the basic units of work
that are allocated to the developer and scheduled.
The end of each important activity is called a
milestone.
The root of the tree is labelled by the project name.
Each node of the tree is broken down into smaller
activities that are made the children of the node. 74
SCHEDULING
Work Breakdown Structure

How long to decompose?

A leaf-level sub-activity (a task) requires approximately two weeks to develop.
Hidden complexities are exposed, so that the job to be done is understood and can be
assigned as a unit of work to one of the developers.
Opportunities for reuse of existing software components is identified.

75
SCHEDULING
Activity Networks
An activity network shows the different activities making up
a project, their estimated durations, and their
interdependencies.
Two equivalent representations for activity networks are
possible and are in use:
Activity on Node (AoN): In this representation, each activity is represented by
a rectangular (some use circular) node and the duration of the activity is shown
alongside each task in the node. The inter-task dependencies are shown using
directional edges
Activity on Edge (AoE): In this representation tasks are associated with the
edges. The edges are also annotated with the task duration. The nodes in the
graph represent project milestones

76
SCHEDULING

Activity network Project parameter computed from

representation of the MIS activity Network
problem.

77
SCHEDULING

Critical Path Method (CPM)

CPM and PERT are operation research
techniques that were developed in the
late 1950s.
Many project management tools support
them as CPM/PERT

78
SCHEDULING

Critical Path Method (CPM)

A critical task is one with a zero slack time.
A path from the start node to the Finish
node containing only critical tasks is called
a critical path.

79
SCHEDULING

Critical Path Method (CPM)

A path in the activity network graph is any set of
consecutive nodes and edges in this graph from the
starting node to the last node.
A critical path consists of a set of dependent tasks that
need to be performed in a sequence and which together
take the longest time to complete.
CPM is an algorithmic approach to determine the
critical paths and slack times.

80
SCHEDULING
Critical Path Method (CPM)
Minimum time (MT): It is the minimum time required to complete the project.
It is computed by determining the maximum of all paths from start to finish.
Earliest start (ES): It is the time of a task is the maximum of all paths from the
start to this task. The ES for a task is the ES of the previous task plus the
duration of the preceding task.
Latest start time (LST): It is the difference between MT and the maximum of
all paths from this task to the finish. The LST can be computed by subtracting the
duration of the subsequent task from the LST of the subsequent task.
Earliest finish time (EF): The EF for a task is the sum of the earliest start time
of the task and the duration of the task.
Latest finish (LF): LF indicates the latest time by which a task can finish
without affecting the final completion time of the project. A task completing
beyond its LF would cause project delay. LF of a task can be obtained by
subtracting maximum of all paths from this task to finish from MT.
Slack time (ST): The slack time (or float time) is the total time that a task may
be delayed before it will affect the end time of the project. The slack time
indicates the ”flexibility” in starting and completion of tasks. ST for a task is LS-
ES and can equivalently be written as LF-EF.
81
SCHEDULING

Critical Path Method (CPM)

AoN for MIS problem with (ES, EF)

82
SCHEDULING

Critical Path Method (CPM)

CPM can be used to determine the
minimum estimated duration of a project
and the slack times associated with
various non-critical tasks.

83
SCHEDULING

Project Estimation review Technique

(PERT)
The actual durations might vary from the estimated
durations, the utility of the activity network
diagrams are limited.
The CPM can be used to determine the duration of a
project, but does not provide any indication of the
probability of meeting that schedule.

84
SCHEDULING
Project Estimation Review Technique
(PERT)
Project managers know that there is considerable uncertainty
about how much time a task would exactly take to complete.
The duration assigned to tasks by the project manager are
after all only estimates.
PERT charts can be used to determine the probabilistic times
for reaching various project mile stones, including the final
mile stone.
PERT charts like activity networks consist of a network of
boxes and arrows. The boxes represent activities and the
arrows represent task dependencies.

85
SCHEDULING
Project Estimation Review Technique
(PERT)
Each task is annotated with three
estimates:
Optimistic (O): The best possible case task completion time.
Most likely estimate (M): Most likely task completion time.
Worst case (W): The worst possible case task completion time.

The mean estimated time is calculated as

ET = (O + 4M + W )/6
Variance of an activity σ2=((W-O)/6)2
86
SCHEDULING

GANTT CHARTS
Gantt chart has been named after its developer Henry Gantt.
A Gantt chart is a form of bar chart.
The vertical axis lists all the tasks to be performed. The bars
are drawn along the y-axis, one for each task.

A Gantt chart is a special type of bar chart where each bar

represents an activity. The bars are drawn along a time line.
The length of each bar is proportional to the duration of time
planned for the corresponding activity.

87
SCHEDULING
GANTT CHARTS
The shaded part of the bar shows the length of time each
task is estimated to take.
The unshaded part shows the slack time or lax time.

88
Risk Management

A risk is any anticipated unfavourable event or circumstance

that can occur while a project is underway
Risk management aims at reducing the chances of a risk
becoming real as well as reducing the impact of a risks that
becomes real.
Risk management approaches can broadly be classified into
reactive and proactive approaches.
Risk management consists of three essential activities—
risk identification
risk assessment
risk mitigation

89
Risk Management

Reactive approaches
Reactive approaches take no action until an unfavourable event occurs.
Once an unfavourable event occurs, these approaches try to contain the
adverse effects associated with the risk and take steps to prevent future
occurrence of the same risk events.
Proactive approaches
The proactive approaches try to anticipate the possible risks that the
project is susceptible to.
After identifying the possible risks, actions are taken to eliminate the risks.
If a risk cannot be avoided, these approaches suggest making plans to
contain the effect of the risk.

90
 Risk Management
❖ Risk identification
❖ The project manager needs to anticipate the risks in a project as early as
possible. As soon as a risk is identified, effective risk management plans
are made, so that the possible impact of the risks is minimised.
❖ There are three main categories of risks which can affect a software
project: project risks, technical risks, and business risks.
❖ Project risks: Project risks concern various forms of budgetary, schedule,
personnel, resource, and customer-related problems.
❖ Technical risks: Technical risks concern potential design, implementation,
interfacing, testing, and maintenance problems. Technical risks also include
ambiguous specification,incomplete specification, changing specification,
technical uncertainty, and technical obsolescence. Most technical risks occur
due the development team’s insufficient knowledge about the product.
❖ Business risks: This type of risks includes the risk of building an excellent
product that no one wants, losing budgetary commitments, etc.

91
Risk Management
Risk Assessment

The objective of risk assessment is to rank the risks in terms of their

damage causing potential.
For risk assessment, first each risk should be rated in two ways:
„ The likelihood of a risk becoming real (r).
„ The consequence of the problems associated with that risk (s).

Based on these two factors, the priority of each risk can be computed as
follows: p=r×s
where, p is the priority with which the risk must be handled.

92
Risk Management

Risk Mitigation

Different types of risks require different containment procedures.

There are three main strategies for risk containment:
Avoid the risk
Transfer the risk
Risk reduction

93
Risk Management
Risk Mitigation
Avoid the risk: Risks can be avoided in several ways. Risks
often arise due to project constraints and can be avoided by
suitably modifying the constraints.
The different categories of constraints that usually give rise to
risks are:
Process-related risk: These risks arise due to aggressive work
schedule, budget, and resource utilisation.
Product-related risks: These risks arise due to commitment to
challenging product features (e.g. response time of one second, etc.),
quality, reliability, etc.
Technology-related risks: These risks arise due to commitment to use
certain technology (e.g., satellite communication).

94
Risk Management

Risk Mitigation
Transfer the risk: This strategy involves getting the risky
components developed by a third party, buying insurance cover,
etc.
Risk reduction: This involves planning ways to contain the
damage due to a risk. There can be several strategies to cope up
with a risk. To choose the most appropriate strategy for handling
a risk, the project manager must consider the cost of handling
the risk and the corresponding reduction of risk.

95
Thank you!!!

96