Research
Publications
Managing Risks in IT Initiatives
By Dayasindhu Nagarajan, Sriram Padmanabhan and Jamuna RaviThis article appears in the SETLabs Briefings on ‘Managing Risks in IT Initiatives: A CXO Guide’ (Oct - Dec, 2007).
Read the complete issue
Unforeseen risks can turn out to be a significant impediment to realizing the business value of IT
John Calvin, the CIO of one of the world's biggest investment banks, was unable to concentrate on his golf and this had nothing to do with the New England autumn. His golfing partner and colleague, Thomas Hobbes, VP Customer Service (North America), was rambling on about how the new billing system was a white elephant that his department did not want to use it. John was intrigued. The new million dollar billing system used state-of-the-art technology, was three times quicker than the old system and had been developed with inputs from users in customer service division. In fact, this was the most successful IT project that the bank had executed in terms of cost, quality and on time completion. The IT services vendor was the best the bank had ever worked with and had been given the mandate for rolling out the new billing system in its European operations.
The game was over sooner than usual. Even as John found himself trying to relax, the billing system still played in his head. Each passing moment seemed to bring the same questions: What had gone wrong with the "perfect" billing system project?.
CURRENT APROACH TO RISK MANAGEMENT
The quandary that John Calvin finds himself in is not isolated. According to a Standish Group report, in 1995 only 16.2 per cent of software projects on an average were completed in time and on budget [1]. A later study by the Standish Group in 2006 shows that the situation is getting better and that on an average 35 per cent of the software projects were completed in time and on budget [2].
The question is whether the 35 per cent average is good enough for critical projects and whether we can improve this average. In our experience, a large number of these failures are a result of inadequately managing risks that are external to the IT project but have an impact on the project and outcome.
Risks can be thought of as negative outcomes during or on completion of an IT project. The size of risk is the loss that is incurred if that negative outcome occurs. Therefore, risk management can be conceptualized as both a strategy and a process to mitigate risks in the lifecycle of an IT project.
IT project risks have been identified for about three decades now and most enterprises have been practicing risk management techniques to mitigate them successfully. The responsibility of managing risk is with the project manager, who usually follows a structured approach, involving the identification of the risks that impede project implementation, assessing the impact of each risk and developing corresponding risk mitigation plans. A list of the important risks in this category would include resources shortfall, unrealistic schedules and budgets, continuing stream of requirement changes, shortfalls in externally furnished components, real-time performance shortfalls and straining computer science capabilities [3].
Many of the mitigation plans for project risks are usually short-term in nature. A typical example of an IT project risk is that of new developers not producing software in concordance with standards. Risk management involves enforcing a standardized variable definition that is maintained in a central repository. This makes it easier for testing, debugging and for a new programmer to get a quick grasp of the system.
Enterprises tend to treat risk management as a mechanism to set on course IT projects that have gone awry resulting in many IT projects falling short of promised quality, cost and schedules. Large program initiatives typically include, in addition to the project, a set of resource suppliers and a set of business benefit recipients after deployment. The success of such programs is measured in terms of those business benefits that have accrued to the enterprise that are attributable to this project. An understanding of such external program risks is crucial to understanding risk management. Risk management as on date seldom addresses such external program risks. Our hypothesis is that external program risks should be addressed in a risk management framework to enhance the success rate of critical projects.
We believe that the proposed rethink on managing risks especially program risks will considerably help in improving the success and acceptance of IT projects.
AN INTEGRATED APPROACH TO RISK MANAGEMENT
A new paradigm on risk management is required to overcome the limitation of a risk management approach that focuses only on project implementation risks. The limitations have been exposed by "unforeseen" risks derailing IT projects. Project managers usually do not have the visibility or control over these external program risks. A Delphi exercise based on existing research in this domain with five project managers with seven or more years of experience in managing IT initiatives revealed some important program risks as seen in Figure 1 [4].
Isolated risk management techniques that work at the project level have been in existence for a few decades and they are well understood and practiced, especially by the IT services vendors engaging in outsourcing and operating at high process maturity levels.
The challenge today lies in successfully managing programs that involve a high number of external dependencies. These typically involve strategic initiatives for achieving key business objectives and require a large number of interfaces and stakeholders. It is in such programs that isolated risk management techniques fail. The relationship between risk management and the external dependencies are depicted in Figure 2.
Making the set of program risks visible at project management level implies that the CXOs need to take an active role in ensuring that the project manager is empowered to be a part of discussions on aligning IT projects with the business strategy at the program level. This is likely to drive both effectiveness and efficiency of the project manager to deliver an IT solution that is acceptable to all stakeholders. A risk management strategy that follows from the business needs would ensure a smoother transition of the new IT system to users. As part of the risk mitigation strategy, interface points between different IT systems and appropriate governance models need to be identified.
The subsequent sections in the paper show how the proposed risk management strategy and process have worked in real life situations and the lessons learned from these experiences.
CASE STUDIES THAT VALIDATE THE NEW APPROACH
Case 1: Financial Risks
The investment banking arm of a large Wall Street bank embarked on an ambitious program to convert its entire suite of legacy applications to a new Web-based architecture. After a lengthy vendor selection process, the company undertook a detailed requirement analysis exercise and followed it up with a design and prototyping stage. Midway through this stage, after investing close to US $ 500,000 the company put a sudden end to the program as budgets had dried out, and the new economic climate did not allow for the increased budgets. In this case, the Project Manager had not taken into account a key financial risk, leading to wasteful expenditure for the bank.
Case 2: Internal Silo And Political Risks
A leading bank with a worldwide presence discovered that its software inventory included three applications that performed the same business function (trade settlement), each with some degree of localization to cater respectively to the American, European and Asia Pacific stock markets. Each location had its own IT establishment, linked closely with the corresponding business unit. The firm launched a major code convergence program, but recognized at an early stage the urgent necessity of aligning the IT teams as a pre-requisite program success.
Accordingly, the company brought the maintenance and support of all settlement applications worldwide under the ownership of a single vendor, who then assisted them in drawing up and implementing a road map to convergence.
The key risk in this program was that of disparate groups with individual political agendas ultimately leading to confusion and failure. Identifying this early and tackling it resulted in the success of the program.
Case 3: Stakeholder Risks
A Fortune 500 company outsourced the design and development of a Web portal that was to service both internal and external users. The company identified the stakeholders: business users from the operations division, report recipients from the marketing department, owners of various applications that were required to feed data into the portal, software analysts, product vendors, software development consultants, database administrators and the quality assurance department.
After the detailed requirements elicitation process, the consultants submitted a design that involved the intranet and extranet applications residing on the same physical machines. All identified stakeholders found the design elegant and approved it. A few weeks before the actual deployment of the application, the network security administrators were shown the deployment view and they raised a valid concern from the point of view of the company's data security policies. This concern scuttled the proposed architecture, forcing a major re-design exercise that caused the project to miss schedules and greatly overshoot budgets.
By not undertaking a risk evaluation exercise at the commencement of the project,the Project Manager had failed to identify a key stakeholder, resulting in losses, in spite of having sought and secured buy-in from the rest of the stake-holders.
Case 4: User Acceptance Risks
A large financial conglomerate with multiple product lines had unsuccessfully attempted a customer integration hub project twice in the past. When the company decided to take it up for the third time, the project manager assigned decided to begin the project by studying the key reasons for the previous failures, and thereby enumerating the risks for the current attempt. The primary risk that emerged from this exercise, surprisingly, was that of user acceptance: however rich in functionality the application was, business users preferred to revert to the legacy applications that they had grown familiar with. Armed with this insight, the project manager invested energy and money on hiring user interface modelers and planned the prototyping phase in great detail, insisting on involving certain influential users in the approval process for the user interface design. At one stroke he had converted his biggest prospective critics into the most vociferous champions for the application. Six months later, the customer integration hub went live on budget and schedule. The users gave rave reviews to the customer integration hub project.
Once again, an integrated risk evaluation exercise was instrumental in uncovering a hidden risk that might have led to the failure of the program. Instead of focusing merely on technical project risks, the project manger took an integrated approach linking the user perspective challenges, which made the difference between success and failure.
Case 5: Global And Local Risks
In the same program as discussed in Case 4, one risk that was recognised extremely early was that of the high degree of external dependency. The program manager was an American, while the application was to be rolled out on a worldwide scale. It was a logistical nightmare to be able to engage business users from other regions to define functional requirements that were tailored to local situations, and IT department who could detail out the interfacing requirements with their respective local applications.
When the product manager found that he was unable to bring all stakeholders onto a common risk management agenda, he quickly scaled down the scope of work to US operations as a pilot exercise. Once the application was rolled out successfully in the US region to appreciation from the business user community, it became much simpler for the Project Manager to propagate global cognizance of the necessity to manage the program in an integrated manner.
The risk evaluation exercise allowed the project manger to discover that due to various reasons, he was unable to assess and mitigate risks on a worldwide scale, mainly on account of reasons of organizational structure that were beyond his control. Consequently, the only recourse available to him was to reduce the scope of the program to a manageable level, which would enable maximizing chances of success of the project despite the isolated risk mitigation strategy
CXOs should empower project managers to work like entrepreneurs and take a holistic perspective of risk and its management at each phase of the program, from conceptualization to execution.
Case 6: System Risks
Continuing with the same program discussed in Cases 4 and 5, the customer hub application needed to interface with twenty different upstream applications. One of the pre-requisites to the System Test phase in the development lifecycle was the need for sample feeds in the correct format, from each of the interfacing applications. Non-availability of these test feeds on time was recognized as a risk to completing the project on schedule. When the project manager convinced the IT teams that owned the interfacing applications to integrate their project schedules and risks, he discovered that two of the applications could not meet the deadlines imposed by his schedule, for valid reasons. He therefore revisited his own schedule and reprioritized the testing of these two feeds, thus ensuring that the overall schedule was still met.
When the project manager took an integrated view of the program risks, what he and initially identified as a project risk became known to be a certainty instead of a risk. He then had to merely plan for it.
The three cases 4, 5 and 6 pertaining to this program illustrate the value of integrating one's risk management strategy across a variety of parameters viz..,
- Across business/IT stakeholders
- Across geographies/business divisions
- Across application development teams.
A telecommunications and entertainment major was unhappy with the amount it was spending on the maintenance and support of its vast inventory of applications, many of which had been outsourced to a large local vendor. The company took the decision to change vendors and choose an offshore vendor, to reduce costs while maintaining quality. Their first attempt to do this involved transferring control of a few applications, in a piece-meal manner. The offshore vendor ran into problems straightaway, thanks to the non-cooperativeness of the existing vendor in providing knowledge, data and documentation essential towards understanding the applications. The venture proved a failure because each engagement had been conceived as an individual project. The risks in each of these projects were related, and they had to be tackled at a relationship level, taking the entire outsourcing deal as a strategic program.
The CIO recognized this, and shortly afterwards, launched a Strategic Outsourcing Program, driving it from the top this time, in an integrated manner, identifying goals and targets for each track of the program that could be rolled up to the program level, in consonance with the chosen offshore vendor.
INFERENCES FROM CASE STUDIES
In cases 1 and 3, isolated risk management is the main reason for project failure. The other case studies illustrate how integrated risk management contributed effectively to the success of the project. Cases 2, 4, 5 and 6 illustrate how the project manager has effectively employed an integrated risk management strategy across different stakeholders, geographies/business divisions and application development teams.
These case studies lead us to conclude that an effective risk management process would be one where risks are evaluated at a program level, rather than the project level. Also, external risks need to be analyzed with inputs from the CXO and an integrated risk management strategy needs to be put in place that mitigates external and internal project risks and plans for certainties.
It is imperative that CXOs empower the project managers to work like entrepreneurs and take a holistic perspective of risk and its management at each phase of the program, from conceptualization to execution. This ensures that the project managers are able to take appropriate risk mitigation steps that result in successful IT initiatives.
Our experience leads us to believe that investing in project mangers with the entrepreneurial spirit is a true challenge for CXOs. We also believe that this is not easily achieved by training interventions. Successful CXOs have created this entrepreneurial mindset by employing other means, such as mentorship programs, job rotations across divisions, and most importantly, by shaping organizational culture. These enterprises align rewards and recognition to demonstration of entrepreneurial traits, as well as provide an environment that is conducive for project mangers to demonstrate them.
CONCLUSION
Risk management is one of the most challenging areas of IT project management. This is mainly because of the emerging new operating models and changing business environment that have a significant impact on risk management strategies. CXOs should share their knowledge of program risks with the project mangers. This ensures that the project mangers leverage the Integrated Risk Management process better and take appropriate risk mitigation steps that result in successful IT initiatives.
REFERENCES
- Chaos, The Standish Group Report, 1995. Also Available at
http://www4.in.tum. de/lehre/vorlesungen/vseWS2004/1995_ Standish_Chaos.pdf - Standish Group Report: There's Less Development Chaos Today, March 1, 2007. Also available at
http://www.sdtimes.com/article/story-20070301- 01.html
- Managing Risk: Methods for Software Development, E.M. Hall, Addison-Wesley (SEI Series), 1997
- Strategies for Heading Off Project Failure, P. Cule, R. Schmidt, K. Lyytinen and M. Keil, Information Systems Management , Spring 2 0 0 0 , pp. 65-73.
Media Mentions
Fortune ranks Infosys 10 among Top Companies for Leaders 2007 More
Press releases
Infosys reorganizes to leverage growing business opportunities in a Flat World More
In the News
Sourcing at your fingertips:
Global Sourcing Essentials
Everything you wanted to know about global sourcing, in five easy parts.
Download your copy
