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 brianp@networkmagazineindia.com