A new IT project is a risky proposition.
There are hard risks, soft risks and risks that you
cannot foresee. But how do you identify and plan for
such risks? by Brian Pereira
Undertaking major enterprise-wide
projects presents a plethora of risks. And when that
project is so critical to your business, you want to
tackle as much of those risks upfront—before implementation
begins. You want to make sure that implementation and
roll-out are executed with minimal hiccups—like a well
planned family wedding. In this story we'll talk about
the various risks you might encounter (some unforeseeable),
and the methods for doing risk analysis—so that you
might identify and mitigate those risks well in advance.
|"I recommend a concept called
Risk Sharing. A vendor shouldn't just talk about
delivering value—he should also be ready to share
some of the pain" —Yusuf Lanewala, IT consultant
Risk analysis helps
you identify all the possible glitches you might encounter
during the implementation phases. Basically there are
two ways of doing risk analysis: One is to use commonsense
reasoning and the other is to do Statistical Risk Analysis.
Most Indian enterprises opt for the former method (and
employ mechanisms like SLAs and contracts to mitigate
risks). Few CIOs have adopted statistical analysis tools
to analyze and mitigate risk for software project management.
tell you that statistical risk analysis is essential
for project portfolio management. It's a more accurate
method for reducing the probability of project failure
and improves the decision-making process for projects.
Statistical risk analysis quantifies the risk, so you
can separate the critical ones from those that do
not have such a major impact on business—and address
the critical ones first.
Three decades back
you needed a gargantuan mainframe to do statistical
risk analysis. Today you can do the same with a notebook
computer, spreadsheet software and risk analysis simulation
software (like Monte Carlo.) Then there are other methods
like Decision Tree Analysis.
Kuoni Travel employs
a method called Potential Deviation Analysis. The steering
committee (with senior executives from top management)
does a brain storming session to come up with all possible
risks. "Typically in two hours they arrive at 150 risks,"
informs Satish Pendse, Head-Information Technology,
Kuoni Travel (India). "There are two ways of dealing
with each risk. One is the Probability of that risk
occurring, and second is the Seriousness of that risk
(the impact it will have on the project."
Pendse and his
team apply weightage levels (1 - 5) for each of the
two parameters. Then they take a cross parameter product
to identify critical risks. So risks that have high
weightage for Probability as well as Seriousness will
be on top of the list— and these need to be dealt with
We sometimes arrive
at as many as 25 critical risks that are highly probable
and highly impacting. So we build a preventive plan
and do contingency planning for these 25 risks," says
And all this is
done upfront in the planning stage. Pendse advises that
one should spend a lot of time doing risk planning.
"So that nothing hits you by surprise later," he says.
Once you've identified
all those risks that could potentially disrupt your
project (and hit your business), you can use various
methods to mitigate those risks.
There are all kinds
of risks that could come up in risk analysis (See box:
What could go wrong?) The key to dealing with those
risks is to be clear about your business objectives
and how the IT solution will be used to attain those
objectives. The success of the project depends on how
you manage those risks.
"If you want to
mitigate all those risks you need to be clear about
your requirements, and about the business concept,"
says S.B. Patankar, Director-Information Systems, The
Stock Exchange. "If you are not clear about this the
project could be a failure. Domain knowledge expertise
of the business concept is extremely important."
CIOs worry a lot
about vendor/implementer risks. To mitigate this one
should do a proper due diligence on the vendor/implementer
or service provider. Do a background check on the vendor,
visit reference sites and talk to his existing customers.
For example, if you are going in for a core banking
solution, visit other sites that use the same solution
and ask those users what issues they face and check
how good is their relationship with the vendor/implementer.
Once you've selected
the vendor/implementer you want to ensure that you get
the promised service levels—that's where contracts and
SLAs come in. It could take months to arrive at the
final version of the contract as advocates from both
sides keep revising and adding legal clauses. But an
SLA can be provided sooner and just before project implementation.
The SLA could include
clauses that talk about 'penalties' and 'bonuses.' But
some CIOs feel this isn't the right way to ensure service
levels. An SLA just postpones the problem for later.
The amount the vendor loses through penalties is minuscule
compared to the loss of business due to project delay.
And there are some vendors who deceitfully agree to
SLA terms as they are desperate for the contract.
"It's not right
to have a penalty to ensure service levels. If a vendor
has to give better service it should be because he wants
to retain you as a customer," says Satish Naralkar,
CEO, NSE.IT. "Instead of imposing financial penalties
we ask in kind. For instance we ask the vendor to extend
the service by three months if he doesn't deliver."
General Manager-IT & Costing, Goodlass Nerolac Paints
feels a contract or SLA should be fair to both parties.
"It should not try to penalize somebody beyond a point.
At the same time, it should not expose one to risks
(due to deficiencies). So during the evaluation process
we try to ensure that a fair amount of transparency
is built into the system. We spend time understanding
how the contract will be executed by the vendor."
To minimize vendor
risks one should spend more time drafting the contract.
You need to understand vendor policies. For instance
some MNCs do not recognize certain processes (like the
Indian purchase order).
an independent IT consultant recommends a concept called
Risk Sharing. "A vendor shouldn't just talk about delivering
value—he should also be ready to share some of the pain."
measures like vendor deposits, bank guarantee, phased
payments are some ways of ensuring that a vendor takes
complete ownership for the project. With vendor deposits
a part of the vendor's margin is with the bank and will
be returned only if the project is satisfactorily completed.
You could also get a bank to assure the credibility
of the vendor, through a bank guarantee. And with phased
payments you pay the vendor in installments after successful
completion of each phase. The final amount is paid on
completion of the project.
These are some
common ways of managing risks, but you could also define
your own methods. To sum it up, you need to have clear
deadlines, clear commitments and clear guarantees if
you want to mitigate risks. You need to be transparent
and also ensure that there is all-round ownership for
A final word of
advice. All risks (and the manner in which they are
managed) should be recorded in a knowledge base for
future projects. You may also add in the best practices
that improve efficiencies. The knowledge base mitigates
risks for future projects by a significant margin. It
also ensures knowledge retention—if skilled personnel
are not available in future, the project won't be held
The business contract
is an important instrument for mitigating risks. So
for our next story we consulted a reputed technology
law firm to find out what needs to be incorporated while
Brian Pereira can be
reached at email@example.com
There are several
things that could go wrong. The biggest uncertainty
is project viability. There's doubt whether the
project will take off or not; this is especially
true for IT driven projects. The technology may
be ahead of its time and is yet unproven in Indian
environments-or there isn't adequate support infrastructure
for it yet. In such instances it will be wise
to defer the project by a few months.
The various kinds
of risks can be broadly classified as 'Hard' risks
and 'Soft' risks. The former are easier to identify
and manage, as you can anticipate them in advance.
Soft risks arise from unexpected events that catch
you by surprise. Let's take a look at some of
the hard risks and soft risks that came up in
These are the obvious ones that you can anticipate
and tackle in advance. Here are a few examples
of hard risks.
- Vendors or service
providers fail on commitments. You may not be
getting the promised levels of service. For
instance, you may be getting less bandwidth
and the service provider could pass the buck.
- Technical problems.
There are bound to be 'teething' problems with
hardware and software. Hardware components may
be faulty; the existing system can't recognize
the new devices. Then there could be problems
with application integration.
A certain technology or software might be obsolete
by the time the project is completed.
- Futuristic. A
certain technology might be ahead of its time
and users are not ready for it yet.
These risks can be really serious as they are
sudden and can sometimes delay the project by
several months. Here are three examples of soft
- Imagine a scenario
where core team members leave mid-way through
a project. These personnel cannot be immediately
replaced and the knowledge and skill exit with
them. Finding people who are as experienced
and then briefing them could take awhile, thereby
delaying the project. This is a problem typically
seen with the vendor's implementation team.
- Bandhs, strikes
and 'rainy day' holidays are common in our country.
This could upset project schedules and cause
- Business activities
could also pose soft risks. Suppose you are
planning a roll-out in April, and need to train
people on the new system in February. But the
company has planned an all India sales meet
in that month. What if you were unaware about
that? If you knew about the upcoming sales meet
a few months earlier, you might have got the
marketing head to prepone or postpone the event.
So it pays to involve all the function heads
in your plans.