Archives ||About Us || Advertise || Feedback || Subscribe-
Issue of August 2003 
 Home > Cover Story
 Print Friendly Page ||  Email this story

Cover Story: Enterprise-wide IT Projects

Risky Business

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

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.

Consultants will 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 immediately.

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 Pendse.

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.

Risk Management

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."

Jason Gonsalves, 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).

Yusuf Lanewala, 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."

Lanewala feels 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 the project.

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 up.

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 drafting contracts.

Brian Pereira can be reached at

What could go wrong?

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 past projects.

Hard Risks
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.
  • Obsolescence. 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.

Soft Risks
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 risks.

  • 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 delays.
  • 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.
- <Back to Top>-  

© Copyright 2001: Indian Express Newspapers (Bombay) Limited (Mumbai, India). All rights reserved throughout the world.
This entire site is compiled in Mumbai by the Business Publications Division (BPD) of the Indian Express Newspapers (Bombay) Limited. Site managed by BPD.