Project tracking and controlling

Control Systems

The important part is the feedback loop from the output to the input. This provides the ability
to control and correct. For project control, this usually means data collection, validation,
analysis, summarization, and reporting in a
timely manner.
Timely is important here. It has been said that running a project by reading the monthly or
quarterly reports is like trying to drive your car down the road by following the yellow stripe
in your rear-view mirror. You want data that
allows you to anticipate what is ahead and react accordingly. Advanced thermostats for homes
have an anticipation feature, which gradually adjusts the temperature to a new setting well in
advance of its programmed time. In your incoming data about project parameters, look for
indicators of outcomes that are reasonable predictors of what will occur before you have
complete data. An example indicator to look for in a software development project is inspection
metrics, the statistics about how much time was spent and how many defects were found in
formal inspection data-logging meetings.

Project Monitoring & Control Process

• Evaluation and comparison of actual measured results against those planned is the
fundamental principle of project monitoring process.
• Whenever there is a variance, corrective action is required to keep the project on schedule
and to budget.
• The inputs are the project plan and progress reports that contain data collected from the
project team.
• Where progress deviates significantly, and this usually means outside of a predetermined
tolerance limit, it is important to identify the underlying causes and take corrective action.
Following diagram shows the project monitoring cycle to be followed at regular period of
intervals of the project duration.
Monitoring Process (on a regular basis)
• Collect.
• Get the data about the current status of your project.
• Measure and Compare.
• Compare with baseline plan, highlight any deviation, make a projection based on
current data.
• Assess and Re-plan.
• Decide whether corrective actions are necessary.
• If so, plan, document, and take the corrective actions.

2.1 Monitoring and controlling activities

• Involves tracking, reviewing, and regulating project progress
• Includes status reporting, progress measurement, and forecasting
• Reports on scope, schedule, cost, resources, quality, and risks
• Controls project and project document changes
• Includes control of scope, schedule, costs, and risks
• Formalizes acceptance of deliverables
• Records quality control results
• Implements risk treatment plans and actions
• Administers suppliers

2.2 Key Results from monitoring process

• Progress and status reports
• Plan updates
• Risks registers
• Change requests
• Work products/deliverables

3. Techniques to evaluate project performance

3.1 Earned Value Analysis
Objective:
• To measure the progress of an activity, deliverable and/or project by comparing the actual
value to planned value, thereby indicating the probability of meeting the scope, time &
cost budget of the activity, deliverable and/or project, and need for any corrective actions.
• To analyze the project performance, calculate the variance for schedule and cost and
indicates where the project stands in comparison to the estimates calculated earlier for this
point in time.
Many a times one could easily be on time, however may overspend, or may be on time & within
budget however scope may be incomplete. In simple terms, EV analysis is better than
comparing actual to planned results or by simply guessing the project status.

Definitions

Planned Value (PV) or Budgeted Cost of Originally planned cost of the work that should
Work Scheduled (BCWS) have been done by this time

Actual Cost (AC) or Actual Cost of Work Actual cost expenses on this project up to this
Performed (ACWP) time

Earned Value (EV) or Budgeted cost of

Work Performed (BCWP) Estimated cost of budgeted work completed

Budget at Completion (BAC) Total budget for the project

Estimate At Completion (EAC) Estimated final cost of the project
Estimate To Completion (ETC) Estimated cost of the remaining work of the
project
 Description EVA Formulas Result
Cost Variance (CV) CV = EV – AC Positive value is good.
Negative value
unfavourable.
Schedule Variance (SV) SV = EV – PV Value below 1.0 = below par
performance. Value above
1.0 = above par performance
The further away the ratio is
from 1.0 the more urgent
need to investigate
Cost Performance Indicator CPI = EV / AC, compares >1 means project efficient,
(CPI) performed to actual cost <1 means project inefficient
Schedule Performance SPI = EV / PV, compares >1 means project ahead of
Indicator (SPI) work performed to work schedule, <1 means project
planned behind schedule
Estimate At Completion EAC = BAC/CPI
(EAC)
Estimate To Complete (ETC) ETC = (BAC – EV) / CPI

Example
Assume a project that has exactly one task. The task was baselined at 100 hours, but 110 hours
have been spent and the estimate to complete is 10 additional hours. The task was to have been
completed already. Assume an hourly rate of $100 per hour.

Description Formulae Result

PV Hourly Rate * Total Hours Planned 100*100 = 10,000
or Scheduled
AC Hourly Rate * Total Hours Spent 100*110 = 11,000
% Complete AC divided by estimated cost at 11000/(11000+1000) = 91.667%
completion which is 11,000 plus
cost of 10 additional hours
EV Baselined Cost * % Complete 9166.667 (baseline of 10,000 *
Actual 91.667% complete)
BAC Baselined Effort in hours * Hourly 10000 (100 hours * 100) indicates
Rate initially budget signed off for the
project
EAC AC + ETC 12000 (11000 + 1000) notice this is
over budget
VAC BAC – EAC -2000 (10000 – 12000) indicates
additional funds required to
complete work
% Completed PV / BAC 100% (10000/10000)
Planned
% Completed AC / EAC 91.7% (11000/12000) lesser than
Actual planned completion
SV Earned Value (EV) – Planned -833.33 (9166.667 –
Value (PV) 10000) negative schedule variance
or behind schedule
 SPI SPI = EV / PV 0.9167 (9166.667 /
10000) indicating poor schedule
performance
CV Earned Value (EV) – Actual Cost -1.833.33 (9166.67 –
(AC) 11000) indicating a cost overrun
CPI Earned Value (EV) /Actual Cost 0.833 (9166.667 / 11000) indicating
(AC) over budget

3.2 The Critical Ratio

• The critical ratio (CR) is the product of CPI and SPI. It can also be called the cost-schedule
index (CSI).
• It is used as an indicator of the overall project health
CR = CPI x SPI.
For the above project, CR = 0.833*0.9167 = 0.764.
• A CR of 1.00 indicates that the overall project performance is on target.
• This may result from both CPI and SPI being close to target, or, if one of these indices
suggests poor performance, the other must be indicating good performance.
• This allows some trade-offs to reach the desired project goals.
A graph of the critical ratio over time provides a quick indicator of trends in the overall project
performance, and of the impact of any corrective actions. These graphs may be very effective
in project reviews
3.3 Line of Balance
The Line of Balance (LOB) Scheduling Technique was originated by the Goodyear Company
in the early 1940’s for the programming and control of both repetitive and non‐repetitive
projects.
The Line‐of‐Balance also known as the Repetitive Scheduling Method (RSM), Location Based
Scheduling, Vertical Production Method or Vertical Scheduling Method.

• Line of Balance (LOB) is a method of showing the repetitive work that may exist in a
project as a single line on a graph.
• A LOB Chart shows the rate at which the work that makes up all of the activities has to be
undertaken to stay on schedule.
• The relationship of one trade or process to the subsequent trade or process is defined by
the space between the lines.
A simple diagram in which line shows location and time at which a certain crew will be
working on a given operation is known as LOB. It is used on repetitive work such as
constructing multiple dwelling units, when used on linear work such as roads and railways the
technique is more accurately called Time/Location Charts
The purpose of the LOB method is to ensure that the many activities of a repetitive production
process stay “in balance” that is, they are producing at a pace which allows an even flow of the
items produced through a process and at a speed compatible with the goals set forth in a plan.
Advantages of LOB schedule
• Clearly shows the amount of work taking place in a certain area at a specific time of the
project.
• Has the ability to show and optimize the resources used for large number of repeated
activities, executed in several zones or locations.
• Easier cost and time optimization analysis because of all the information available for each
activity in the project.
• Ease of setup and its superior presentation and visualization.
• Easier to modify, update and change the schedule.
• Better managing of all the various sub-contractors in the project.
• Allows for simpler and clearer resource management and resource optimization functions.
• Visualization of productivity and location of crews.
• It allows project managers to see, in the middle of a project, whether they can meet the
schedule if they continue working as they have been.
3.4 Graphical Evaluation and Review Technique (GERT)
Graphical Evaluation and Review Technique, commonly known as GERT, is a network
analysis technique used in project management that allows probabilistic treatment of both
network logic and estimation of activity duration. The technique was first described in 1966 by
Dr. Alan B. Pritsker of Purdue University and W.W. Happ.
Advantages:
• GERT approach addresses the majority of the limitations associated with PERT/CPM
technique. GERT allows loops between tasks.
• Allows for conditional and probabilistic treatment of logical relationships
• GERT considers both deterministic and probabilistic branching unlike PERT. It
incorporates both in the network analysis.
• GERT allows additional branching features not provided by CPM or PERT.
Disadvantages:
• GERT technique is the complex programme (Monte Carlo simulation) required to model
the GERT system.

Scope Management

If a project is allowed to change freely, the rate of change will exceed the rate of progress.
Every project needs change control; otherwise, things will get out of control
rather quickly. One of the worst things that can happen to a project is "scope creep," where the
requirements seem to balloon out of control, usually slowly, until the balloon bursts and they
exceed the capacity of the team and the time available to satisfy them. So, you need a scope
control system to keep things under control. A scope control system is just a change control
system focused
on scope management. The basic elements of a change control system are:
• a means of identification and nomenclature figuring out a plan for naming things, to
avoid confusion;
• a process for managing baselines and processing changes, to keep versions straight and
owners identified;
• a way to report the current status of any or all items, for handling inquiries about items
or summaries; and
• a periodic audit or review process, to ensure integrity of the data you have.

Relationship of Configuration Management to a Project Control System

The change control process's central idea is that all changes start as "requests" that must go
through a predefined control point, usually a change control
board (CCB) of some kind. This can be a single part-time person for a small project or a large
department for a major defense contract. However it is handled, there is always some kind of
official repository for the official versions of anything important to the project. For software
products, the CM system is the project's work product library. Changes to anything in there are
not permitted until the change request can be evaluated for impact on other areas of the project,
such as scope, schedule, cost, and quality. This is the function of
the CCB.

Successful project control is good change control. Some guidelines to follow are listed here:
• All project contracts or agreements must include a description of how changes to it will
be handled.
• All change orders must be approved by the appropriate signature authority.
• All project artifacts must be amended with the impact of approved changes.
• Any change to a project artifact requires a captured change control request or change
order.

For each change order:

- Review all changes for product and process impact.
- Identify all activities and work-package impacts.
- Translate impacts to performance, cost, and schedule.
- Evaluate benefits and costs of changes.
- Identify alternatives that may do the same thing.
- Accept or reject on merit.
- Communicate changes to all parties.
- Summarize all changes in next reporting period.

Flexibility Matrix
It is also useful for change management control to prepare a decision-making matrix
beforehand so that decisions can be made regarding trade-offs when they occur. This is often
called a flexibility matrix, and it helps the team choose more effectively. It is best to discuss
which of the three main items in the triple constraint are most flexible and least flexible with
regard to the conditions on this particular project.
A Sample Flexibility Matrix
matrix in the figure, the least flexible parameter is the schedule. The team must hold to the
schedule. However, the team can hold to it by increasing resources, if necessary, and possibly
by reducing scope. Deciding how to decide for the project at the beginning of the project can
make for fewer arguments later.

Crashing and Fast Tracking

Four Steps to Crash a Project

Although collapsing a schedule appears to be a complex task, these are the
four basic steps in crashing the project:
• Build a precedence network.
• Find all activities on the critical path (check to see if it changes).
• Find the activity or activities with the most favorable cost-time trade-offs.
• Crash the activity by 1 unit of time until the project cannot be crashed anymore.

Crashing Example Setup

Let's consider an example problem. Here's the setup:
As requested, Heather sent an email to her boss, Jack, Director of Projects, saying that her team
had estimated that the eX project would require 13 months for completion. Heather realized
that the customer wanted the job completed in less time. To meet market windows, the contract
has a $50,000 bonus for every month earlier, down to six months of total project time, and
Jack would like to invest more resources into the project, for maximum return. Heather and her
team collected the information shown in Table.What is the minimum number of months that
Heather and Jack should predict to the
customer, and at what net benefit to their company?

Set Up the Problem Workspace

To solve this problem, do Step 1 to initially draw the network diagram and find the critical
path. This is done for you and is shown in Figure
Project Crashing and Time-Cost Trade-Off
Project duration can often be reduced by assigning more labor to project activities, in the form
of overtime, and by assigning more resources (material, equipment, and so on). However,
additional labor and resources increase the project cost. Thus, the decision to reduce the project
duration must be based on an analysis of the trade-off between time and cost.
Project crashing
• It is a method for shortening the project duration by reducing the time of one (or more) of
the critical project activities to less than its normal activity time.
• This reduction in the normal activity time is referred to as crashing.
• Crashing is achieved by devoting more resources to the activities to be crashed.
“Crashing an activity” (“Crashing the network”):
• Reducing the time required to complete an activity (in hopes that this will reduce the
completion time of the entire project) by assigning additional resources to that activity.
• But reducing the duration time of the activities on the critical path may change the critical
path.
Some of the terms generally used in this process are
• Normal Time (NT): the expected time to complete an activity
• Normal Cost (NC): the cost to complete the activity in its normal time
• Crash Time (CT): the shortest possible time in which the activity can be completed
• Crash Cost (CC): the cost to complete the activity in the shortest possible time (ie., the
cost to complete the activity in its crash time)
• Crash Cost per time period(Cost Slope) = (CC – NC) / (NT – CT)

• As projects continue over time, they consume indirect costs, including the cost of
facilities, equipment, and machinery, interest on investment, utilities, labor, personnel
 costs, and the loss of skills and labor from members of the project team who are not
working at their regular jobs.
• Financial penalties for not completing a project on time were also incurred. For example,
many construction contracts and government contracts have penalty clauses for exceeding
the project completion date.
• Project crashing costs and indirect costs have an inverse relationship; crashing costs are
highest when the project is shortened, whereas indirect costs increase as the project
duration increases. This time-cost relationship is illustrated in the above figure. The best,
or optimal, project time is at the minimum point on the total cost curve.
Project crashing Example:
Critical path for the house building network in following figure is activities 1-2-3-4-6-7 and
the project duration was 9 months, or 36 weeks. Suppose the home builder needed the house
in 30 weeks and wanted to know how much extra cost would be incurred to complete the house
by this time.

Following table represents the time and costs before and after project crashing

The total cost of crashing the project to 30 weeks is 2,500. The contractor could inform the
customer that an additional cost of only 2,500 would be incurred to finish the house in 30
weeks.

Activity Normal Crash Time Normal Crash Total allowable Crash

Time (Weeks) Cost Cost Crash Time Cost
9Weeks) (Weeks) per
Week
1-2 12 7 3000 5000 5 400
2-3 8 5 2000 3500 3 500
2-4 4 3 4000 7000 1 3000
3-4 0 0 0 0 0 0
4-5 4 1 500 1100 3 200
4-6 12 9 50000 71000 3 7000
5-6 4 1 500 1100 3 200
6-7 4 3 15000 22000 1 7000
Total 75000 110700
 RISK MANAGEMENT AND CHANGE MANAGEMENT

Risk

The word risk originates from the Italian term risicare. Risicare means to dare. It is a science
based on theory of probability. The risk is understood as the possibility of loss. Risk is
identified, its possibility of occurrence is expressed in probability, and consequence of the
risk is measured in loss.
The monetary impact of the loss is a quantitative measure of risk impact. The risk is
perceived as high or low in terms of its exposure, defined as the product of the probability of
its occurrence multiplied by the potential loss.
Risk is handled by different people in different ways based on their preferences and attitude
towards risk. People differ in their tolerance to risk. The difference occurs due to the different
utility functions on which exposure is measured.
A person’s utility function reveals whether he or she is risk adverse, risk seeking, or risk
neutral. Risk is managed through strategies. The strategies are of two types, one ‘reactive’
and the other ‘proactive’. Reactive strategies are the ones that are applied when risk occurs,
whereas proactive strategies are the ones that are applied in anticipation of risk. Like any
other business function risk also needs to be managed properly through a process called risk
management.

Risk Management(CRM)

RM is a process made up of the following steps: risk identification, risk analysis, risk
assessment, risk planning, risk monitoring and risk mitigation. RM resolves the risk scenario
through these steps.

Risk Identifies and enumerates the risks

Identification
Risk Analysis
Enables an understanding of the occurrence, its impact and the timing of
occurrence.
Risk
Assessment Quantified in terms of the probability of occurrence, loss on occurrence, and
the risk exposure.
Risk Planning
for resolution Provides approach in terms or effective steps in dealing with risk in terms
of strategies and execution.
Risk
Monitoring Helps to identify and measure the occurrence, impact and implications of
risk till it is resolved satisfactorily.
Risk
Mitigation Helps to meet the challenges of risk occurrence in effective implementation
of specific plan of RM.
RM converts a threating risk scenario into an acceptable risk scenario, controlling risk through
the stages of its likely occurrence to its satisfactory resolution. Risk scenario is perceived with
reference to goals and objectives to be achieved. Hence, a clear definition of the goal is essential
in RM. The risk is seen in the process of goal achievement when it is riddled with uncertainty,
lack of knowledge about the future, and loss that might occur if risk is not resolved properly.

RM is a scientific process based on the application of game theory, decision theory, probability
theory and utility theory. Risk scenarios may emerge out of management challenges and
technical challenges in achieving specific goals and objectives.

RM must be performed regularly throughout the achievement life cycle. Risks are dynamic, as
they change over time. RM should not be regarded as an activity integral to the main process
of achieving specific goals and objectives. Risk and its management should not be treated as
an activity outside the main process of achievement. Risk is managed best when RM is
implemented as a mainstream function in the software development and goal achievement
process.
Introduction to Software Risk(SR)

Software risk is a measure of the probability of its occurrence and the loss due to its exposure.
The SR affects the process of development, project development, and software product itself.
The SR is possible in software process, project and product management.

Software risk arises due to uncertainties in management and the ineffectiveness of technical
procedures.
Types of Risks

Software process Risks include managerial and technical procedures required to be

undertaken for software development. Managerial processes include activities like planning,
staffing, monitoring, quality assurance and control. In technical procedures, software
engineering activities such as requirement analysis, design, code and test are included.
Process risk occurs due to uncertainties involved in assessing, estimating various inputs to the
software process. There are uncertainties in resource availability, confirmed quality
specifications from the customer and so on. In technical procedures, uncertainty may be on
account of the customer not being able to confirm in precise terms the software requirement
specifications, or uncertainty about platform, its capability and configuration and so on. Such
uncertainties affect quality, efforts, cost and schedule enhancing the business risk.

Software Project Risk arises on account of operational, organizational and contractual

software development factors. This risk occurs due to conditions and constraints about
resources, relationship with vendors and contractors unreliable vendors and lack of
organizational support. Funding is the significant project risk the management has to face. It
occurs due to initial budgeting constraints and unreliable customer payments.

Software Project Risk mainly concerns the quality characteristics of the software product.
This originates from the conditions such as unstable requirement specifications, not being
able to meet the design specifications affecting software performance and uncertain test
specifications. In view of the software product risk, there is a risk of losing the business and
facing strained customer relations.

Though these risks are identified and put into three classes, they have a close relationship
with each other. For example, if there is an uncertainty in requirement specification, it gives
rise to software product risk of not meeting the customer acceptance standards. Further, it
affects the resource estimation, as requirements are not known completely in clear terms
giving rise to project management risk. Once there is uncertainty about requirement, there is
also uncertainty about the process of development affecting the schedule. The risk of not able
to deliver the product on time sets in.

The nature of risk and its class are, however, fixed, and they are stated below:

Technology Risks
(Unpredictable) These risks fall in the domain of hardware, software and network
communication technology, which are subject to continuous
improvement and may lead to obsolescence.
People Risks
(Known) These risks are associated with persons in the teams and risk
concerns availability, capability, skills, maturity and so on.
Organizational Risks
(Predictable) These are in the area of development organization and customer
organization. The environment in both the organizations is a matter
of concern.
Requirement Risks
(Known) This is about clarity, completeness and confirmation of the
requirement by the end users and customer. It is about the volatility
of the requirement.
Estimation Risks
(Known) Not being able to judge in precise terms the component of the
software, reusability and system characteristics affecting the size,
effort and schedule.

Predictable risks are the ones that can be identified based on past experience in development.
The examples are people, organizational and technology risks.

The unpredictable risks are the ones that appear suddenly and out of the blue. They are
technology, obsolescence, business and management change.

The objective of viewing the risk by nature, type or category is to identify all of them and deal
with them effectively. Experience reveals that risk incidence is spread over the entire life cycle
of software development. Due to the complex nature of software risks operating throughout the
life cycle of development, Software Risk Management (SRM) becomes an essential and
integral component of the software development.
Software Risk Management(SRM)

SRM is a process built in five steps. The steps are:

plan, risk
Identify the risk analyze resolution
startegy

track montor mitigate the

Risks risks

Analyze and Assess Risk

Risk Analysis b (RA) is a process that defines activities and methods to estimate and evaluate
risk. In estimation, the probability of occurrence is estimated and its consequence. In
evaluation, the risk options against certain criteria are discussed.

The risk analysis process begin with list of risks obtained from the earlier process of risk
identification. Each risk from this list is taken for estimation and evaluation. To act on this
step, the organization needs an evaluation criteria and the risk database. First, the probability
and consequence is estimated and then the risk Exposure (RE) determined.

The risk analysis process begins with list of risks obtained from the earlier process of risk
identification. Each risk from this list is taken for estimation and evaluation. To act on this
step, the organization needs an evaluation criteria and the risk database. First, the probability
and consequence is estimated and then the Risk Exposure (RE) determined.

Risk Exposure = Probability X Loss

For example, the customer environment suggests that the stability of requirement
specification is very low.

This is also the experience of the project team with this particular customer. Hence, identified
risk, a critical requirement may be missing or may change radically .Based on the risk
database and customer experience, probability is 0.50. The loss due to this risk occurrence is
a waste of three man-month effort, amounting to a loss of Rs. 1.5 lakhs. Hence, risk exposure
is

RE = 0.50 X 1.5 = 0.75 lakhs

Based on this criterion of risk exposure, it is determined whether it is low, Moderate or high
and considered against the time frame as short, medium and long term. Both these attributes
are evaluated on common criteria known as risk severity. The following table shows the
index of risk severity.
timeframe Risk exposure
LOW Moderate High
short 5 2 1
Medium 7 4 3
long 9 8 6

Based on the risk severity criteria, the risks are prioritized for action Index “1” for a short-term
time frame and high risk exposure is considered the highest risk severity. Index ‘9’ is termed
as the lowest because of the low exposure and long-term time frame. When you evaluate all
risks by these criteria, they come under a common platform, irrespective of whether the risk is
of project, product or process.
At the end of risk analysis, you get a prioritized risk list with probability, risk exposure, and
risk severity. This forms the basis for constructing a risk action plan for resolution.

Plan Risk Resolution Strategy

The risk plan proposes various actions to deal with the risks identified and analyzed in the
earlier processes. The output of the process is the Risk Action Plan (RAP).

RAP takes as input the Prioritized Risk List based on risk severity, and determines resolution
strategies for each one on the list. The risk resolution strategies suggested by Ellan H. Hall a
researcher and author of the book on Risk management are:

• Risk Acceptance
• Risk Protection
• Risk Reduction
• Risk Transfer
• Risk Reserves
• Risk Avoidance
• Risk Research

Risk Acceptance: this strategy is chosen when you have no choice but to live with risk and
face the consequences.

Risk Protection: This strategy is chosen when there is a possibility to reduce the probability
of occurrence and the consequential loss. For example, you may hire a temporary consultant
to provide domain knowledge support or the skills required to reduce process delay and
product risk.
Risk Reduction: This strategy is chosen over and above risk protection. Based on a cost
benefit analysis, the organization may take such actions that risk incidence is reduced, giving
rise to major reduction in the consequential loss.

Risk Transfer: This strategy is chosen when it is possible to transfer the risk to somebody
else. You may choose outstanding, subcontracting, buying a resource or tool, taking
insurance as a risk transfer strategy.

Risk Avoidance: This strategy is chosen to eliminate risk altogether or by pass it altogether.
This strategy is chosen when you are in lose lose situation. You will deal with the sources of
risk to avoid or eliminate them by management actions.

Risk Research: This strategy is chosen to reduce the risk by seeking more information about
it for better evaluation, and also to deal with it effectively. The firm may, for example,
conduct a proof of concept exercise or experiment to reduce the volatility of the requirement
specifications. Another example is that the organization may seek more information from
genuine resources on new products or the introduction of new technology. Based on this
information, the index of severity will be reduced, and the action plan changed accordingly.

The process has an input on risk status from the project team and from various MIS reports
on software development addressing the issues of schedule, cost, delivery and quality. Thee
output of the tracking process is evaluation of exposure, severity and triggers to act where
necessary.

For example, risk of delay in delivery is a high severity risk. Assume that over 100 activities
are involved which affects the delivery. So threshold for these activities is a delay of 15% in
completion. If delay exceeds 15% it should be reported through MIS for action.

It is important to note that risk occurrence is a possibility at any time. The original estimates
and forecasts on occurrence, exposure, timing may change during the life cycle, and tracking
risk becomes an essential activity in risk management system, and has to be made integrated
activity in software development plan.

Risk Mitigation through RMMM plan

SRM handles each risk based on its severity and suggests resolution strategy. Organization
needs a SRM plan for all identified to track, measure, monitor and trigger action to contain the
risk impact. This is known as Risk Mitigation, Monitoring and Management (RMMM) plan.
Risk Mitigation Planning
Risk mitigation or reducing the impact of risk is done through an RMMM plan. An RMMM
plan deals with mitigation, monitoring and management of risks in a systematic manner. The
steps in an RMMM plan are as under.

• Prepare a prioritized risk list based on risk exposure and its severity index
• Determine risk resolution strategy for each risk
• Design an action plan based on resolution strategy to deal with risk
• Institute a monitoring plan through systematic review , and MIS reports on risks integrated
into software development MIS reports
• Take corrective measures to control the impact.