Page 1 of 11

Chrispus Kimingichi Wanjala

Information Technology Project Success with Effective Risk Management
Chrispus Kimingichi Wanjala Masinde Muliro University of Science and Technology chrispus2011@gmail.com

Abstract
The question whether risk management contributes to IT project success is considered relevant by people from both academic and practitioners’ communities already for a long time. Over the last 10 years, much has become known about what causes IT projects to fail. However, there is still very little empirical evidence that this knowledge is actually used in projects for managing risks in IT projects. Project risk management is one of the hardest tasks that information technology project managers face. It is very difficult to integrate risk management processes into software development in the organization. However, the outcome of effective risk management is of great benefit to the organization and the developers . This paper address the benefits that an organization will get if it implements effective information technology project risk management in its process of developing an information technology project. It also explores the various ways information technology software developers and managers will identify and deal with risk that may arise during development process. Key words: IT projects, risk management, software development, organization

Introduction
Project failures are as a result of poor project management in terms of Integration management, Scope Management. Time management; Cost management; Quality Management. Human resource Management; Communication management; risk management and Procurement management cycle. However, project risk management is one of the biggest causes of failures in project management. Most organization will invest less of time and resource to manage risk because they do not expect any to occur during the project management life. Developing an information technology project involves creating something that has never been done. It is not like constructing a house which has common processes in every project. Risk can come from any source, I.e if scope, budget, time, quality etc are not well managed, they lead to a risk of the project failing. Jiang and Klein (1999) find different types of risks will affect budget, user satisfaction, and system performance. Other studies indicate that 15 to 35% of all

defines Project Risk Management as "the processes concerned with conducting risk management planning. identification. or failure to meet their project goal (Boehm. and monitoring and control on a project". cost overruns. Software managers in india perceived personnel turnover as their biggest source of risk ( Boehm and Demarco. Project Risk Management then involves the systematic process of identifying. In addition if the requirements are captured. they will continue to change as the system is being developed leading to a risk of project failure. In a study of project management maturity by industry group (including infonnation systems) and knowledge area. software development engineers have high turnover rates among software development firms. 1997) Many software project and programs involve multiple entities such as companies. analysis. 1991) Things like scope management is so difficult to manage since most of the software requirements cannot be captured at the initial stage. and responding to project risk. project risk management processes include: • • • Risk management planning — the process of deciding how to approach. research shows that 45% of all the causes of delayed software deliverance are related to organizational issues (Van Genuchten. 1991). plan. responses.75 on a 5 point scale) The objectives of project risk management are to minimize the probability and impact of potential risks while maximizing the probability and impact of potential opportunities.Page 2 of 11 Chrispus Kimingichi Wanjala software projects are cancelled outright and the remaining projects suffer from schedule slippage. divisions etc. There is often a feeling of disconnection between software developers and their management. Because of this. project management risk ranked among the eight core and facilitating functions examined. analyzing. risk in the IS area ranked lowest in level of maturity (2. Project risk involves understanding the potential for problems as they might impede project success. each believing that the others are out of touch with reality resulting in misunderstanding and lack of trust. that may have certain interest. As described in the PMBOK® [1]. and execute risk management activities for a project Risk identification — determining which risks are likely to affect the project and documenting their characteristics Qualitative risk analysis — the prioritization of risks for further analysis and detailing their probability of occurrence and impact . The PMBOK Guide — 3rd edition [1]. Of the four industries included.

The free spirited culture in many software development firms is in conflict with the amount of control often required to develop complex software systems in a discipline way. Many software development practitioners understand risk management and control as inhibiting creativity. and • Risk monitoring and control — responding to changes in risk over the course of the project through identification. In a survey of IS executives.Page 3 of 11 Chrispus Kimingichi Wanjala • • Quantification risk analysis — numerical analysis of the effect of identified risks on project objectives Risk response planning — development of options and actions to enhance opportunities and reduce threats (normally in the form of either strategies to avoid risk or to mitigate the impact if it occurs) to project objectives. tracking and monitoring of risks. driven people”. Risk groups created include corporate environment. However. Groups created are consistent with five risk groups previously established by Barki et al. scope. Schmidt. most software developers and project management perceive risk management processes and activities as extra work and expense. a set of risk factor groups was developed. staffing. relationship management. development of process. . This indicates that time and other resources must be allocated to manage risk when developing any information technology software project. This can be done using a vigorous. sponsorship/ ownership. requirements. Risk management processes are the first thing to be removed from the project activities when the project schedule slips. scheduling. et al [15] developed an "authoritative" list of 33 risk factors using input from 41 practicing project managers. execution of risk response plans. They identified 30 reasons for IS project abandonment. funding. and evaluation of their effectiveness From the above process as described by PMBOK® it indicates that risk management is a basic need in any software development and it involves various stages. Oz and Sosik [13] collected quantitative and qualitative data concerning reasons why IS projects are abandoned. technology. The risk can be managed well when is identifies at the early stages. Jones (2001) mentioned “it is peculiarity of IT that very complex systems can be built with a very low level of control by clever. systematic approach. From this comprehensive list of risk factors. [2]. project management. The list of risk factors was organized into 14 groups based on the source of the risk and subsequently ranked in order of priority. extemal dependencies. and planning. personnel. Comparison of the list of risk factors with those generated in previous studies suggests that this list is fairly comprehensive and nontechnical.

A large number of processes have been generated in recent years to address the need for more effective risk management. Using a sample of practitioners from financial. Keshlaf and Hashim (2000) have developed models for tools to aid the software . Since risk management is widely used and understood. thus. parallel the problems of the Vasa project to the problems common to large software projects and offer antidotes. 1991). Fairley and Wilshire [5] in a unique examination of the sinking of the Royal Swedish Navy ship Vasa. estimating the impact if the risk event occurs. Effective risk management is the most important management tool a project manager can employ to increase the likelihood of project success. estimating the probability of the risk event. risk management appears to be the least-practiced project management discipline. 2001) is a good overview of the typical processes. and the Personal Software Process risk management process. yet it is often too generic to meet the specific needs of software projects.Page 4 of 11 Chrispus Kimingichi Wanjala Five factors emerged from a factor analysis of surveys: lack of corporate leadership. TM TM (TSM TM ) for the team (PSP TM ) for individual during software project development (SEI 2001). Vemer and Evanco [17] found that most developers and project managers perceive risk management processes and activities as creating extra work and expense. poor project management. An investigation of inhouse software development practices describes active risk management as one of many necessary essentials in promoting project success. Through the use of logistic regression analysis. and deviation from timetable/budget. they should then be managed in a keen way for the project to be successful. and analyzing when the risk can be expected. Despite the inherent risk associated with software development projects. they found that risks managed throughout the project were among the best predictors of project success. this could be a significant competitive advantage to those that implement the risk management process in their project. The software engineering Institute (SEI) has developed the Team Software Process as a whole. inadequate skills and means. and insurance companies. Research of failed software projects showed that “their problem could have been avoided or strongly reduced if there had been an explicitly early concern with identifying and resolving their high risk elements” (Boehm. Royer [14] operationalizes the quantitative and qualitative risk analysis by instructing project managers to examine each risk by placing it into a category. pharmaceutical. Once the risks have been identified. The risk management process provided in PMBOK® (PMI. Table 1 summarized these software project risks. poorly communicated goals/deliverables. there are strong indicators that these risk can be managed successfully.

Carr. The best way out is the “avoidance strategies” — that is trying to head the problems off before it become severe.. lack of client buyin to the project. al. There are a number of areas where risk management needs to develop in order to build on the foundation that currently exists. This measurement is often undertaken by project managers. There were also a few mitigation strategies suggested. and several specific suggestions for developing and maintaining communications. These strategies include trying to create the role of the sponsor. work around a weak or missing champion by having other roles such as the customer or project manager fill part of the traditional sponsor role. with its own language.Page 5 of 11 Chrispus Kimingichi Wanjala Project Risk Management has developed into an accepted discipline. The following are some of areas the risk can come from and measures that can be taken to prevent them from occurring. lack of corporate leadership. One of the most important of these is the ability to measure effectiveness in managing risk. Funding and Scheduling Risks . Sponsorship/Ownership Risks Sponsorship/ownership risks include such factors as corporate management's loss of interest in the project. forcing the sponsor or the steering team to either back or cancel the project. techniques. an unstable corporate environment. The top risk in this group is the project may have inadequate top management commitment. [3] assert that the sponsor should set the project team's goals and vision. the project has a weak/lacking champion. replacing the sponsor. Most of these strategies involve the role of the project's sponsor. encourage and support the project team. The value of a proactive formal structured approach to managing risks and uncertainty is widely recognized. Many organizations are seeking to introduce risk management into their organizational and project processes in order to capitalize on the potential benefits. and remove roadblocks. These included continuing to secure commitments or refusing to continue work and continuing to use the communications that were established as avoidance strategies. et. failure of corporate management to make decisions at critical junctions. many of whom are professionally certified. conflict between user departments. A strategy for dealing with inadequate top management commitment is an important factor to reduce risk of project failure. going over the sponsor's head. procedures and tools. and unethical behavior.

Additional factors include objectives are unclear or misunderstood. Some of the risks that may arise are so technical such that they require a trained team to deal with them. Scope Risk Factors In the scope category. under funding of maintenance. and excessive use of outside consultants. use of artificial deadlines. assessing the skills of those already assigned. The highest rated of these was the first — the project lacks enough people or those with the right skills. . incompetent IS professionals on the team. scope tends to creep. Chasing technology instead of satisfying legitimate requirements can be avoided by using strategies such as conducting feasibility studies to determine expected benefit. and getting the customer to commit to further funding or limit the project. mitigation strategies include reducing the scope if you cannot add sufficient staff. This means that there should be a term in the project development that must be assigned to manage risks and be given all the required resources to deal with. and having a user lead the project. recruiting to fill gaps. and work with your existing team to determine how to overcome the shortage. under funding of development. If the project is underway and resource problems surface. using a roles and responsibilities matrix to identify problem areas. lack of required knowledge/ skills in the project personnel. obtain temporary resources. infrequent meetings of the project team. The above mentioned risk is just part of the risk that can make information project failure. the top rated risk factor is the project may not be based on a sound business case (and the impact is business requirements are ignored for sake of interesting technology). Strategies to ensure enough people with the right skills include determining the resource requirements. and changing needs are introduced when the project is already underway. The top ranked risk is that the entire project must be budgeted at the outset of the project and schedule risks. replace or reassign people. requirements tend to creep. and ultimately not committing to perform the project if you do not have the right skills available. deviation from budget.Page 6 of 11 Chrispus Kimingichi Wanjala The funding and scheduling category contains risks such as: requires budgeting the entire project at the outset leading to underfunding in later years. validating the business case for the project with your sponsor. Personnel and Staffing Risks Personnel and staffing risks included the projects lack of enough people with the right skills. lack of available skilled personnel.

assigning an experienced project manager is the next suggestion. set clear expectations in the project charter. not freezing the requirements. these all lead to the top rated risk which is failure to meet user expectations.Page 7 of 11 Chrispus Kimingichi Wanjala rejecting unworthy projects at the outset. failure to identify all stakeholders. establishing a change control process. meet regularly with your sponsor and customers to discuss potential changes and secure their approval. Ultimately. and agreeing to track progress and the need for changes. If the project team has started to develop a technology that does not support the business case but appears to be promising. and higher user expectations due to their growing sophistication. Strategies for avoiding the poor change handling that plagues some projects start with assessing your organization's readiness to execute a major project. Providing your organization is capable. having unclear lines of communication. Relationship Management Risks Risks that have been identified with managing project stakeholder relationships come from Schmidt et al [ 15] and include expectations are mismatched with deliverables. hold requirements sessions with the user. direct that an alternative approach be used. evaluate the impact of potential changes. hold design reviews with the user. and defining alternative approaches to satisfying the legitimate business needs of the organization. Once the project is underway. and generally work imaginatively to ensure all key stakeholders have been identified and that you obtain their input . top management should re-evaluate the project. If problems arise when a project team ignores a requirement. top management may elect to roll this technology into a new project aimed at a market for which a business case can be justified. piloting new technology before rolling it out. The practitioner experts rated the final risk_ handling project changes poorly as the top risk in this category. and redo any task that was not completed properly. Following this should be several typical project management practices of agreeing to a good charter before proceeding. Requirements Risks Requirements risk factors include no agreement on goals. lack of understanding users' needs. and handling project changes poorly. not exerting proper control. and kill the project if necessary. stop the project if a strong business case cannot be developed. lack of appropriate experience from user representatives. determining in advance when you need to obtain approval from your sponsor and steering team. follow the rules you established regarding changes and their approval. lack of cooperation from users. Methods to prevent a failure to meet user expectations include asking the user to be part of the steering team in order to obtain feedback quickly. not identifying risks and contingency plans.

Also Kutsch and Hall (2005) and Dey et al. and improve project communications. In the 26 publications on the relation between risk management and project success that were investigated. project success.b) use product performance and . as early as possible seek input from key stakeholders. as illustrated by Conrow and Shishido (1997) in the introduction to their paper: ‘‘rising costs. Two other publications that remain implicit about what is meant by project success are Akkermans and van Helden (2002) and Gemmer (1997). This is in contrast with the 1997 findings of Ropponen and Lyytinen (1997). however. The above elaborations indicate that. was discussed from a contingency perspective (Barki et al. Because the contingency approach does not consider risk management as a separate process. project success is neither mentioned nor defined. these three publications were not further investigated. who both use the term ‘‘performance” without further defining it. cost limits and meeting requirements . it is embedded in the various processes and procedures of the project. Better fits between project and environment as well as between risk exposure and the project management profile (Barki et al. Jiang and Klein. In the remainder of their study. (2004a. put agreements in writing. Royal Academy of Engineering. and a discussion about risk and risk management. A clear definition of project success. . often remains rather implicit. Further study of the publications presented between 1997 and 2009 revealed a relatively small third group of publications in which risk management. About two third of the publications dealt with in this paper refer to project success in terms of compliance with time limits. 1999.. Wallace and Keil (2004) and Wallace et al..Page 8 of 11 Chrispus Kimingichi Wanjala early and often. 2004) is still very common. 2007). in that they focus on the overall factors or causes of risk. 1999. and their relationship. They claim that most papers that were published until 1997 approach risk management from the evaluation perspective. If you still fail to meet user expectations. costs and requirements in their introductions. the traditional manner of defining and determining project success (The Standish Group International. 2001. Sauer et al.. followed by a reference to a 1994 Standish report on the success and failure of IT projects. falling performance and slipping schedules are common problems . project risk management can be dealt with in different ways and the end product is a success in project. 2001) increase project performance. The contingency approach considers project success to be dependent on how well the project as a whole is able to deal with uncertainties in the project environment. .”. meet with customers face to face. Risk management is not considered to be a separate management process in these publications. enlist the help of your sponsor. (2007) merely refer to time. The set of publications presented between 1997 and 2009 that consider risk management from an evaluation perspective (12 publications) almost equals the one that views it from a management perspective (14 publications).

A reason why quantitative risk analysis is not considered useful may be that many of the risks in IT projects are not aleatoric in nature (they are not based on probability). the stakeholders become biased. which means that there is not enough information available to take a decision. Risk identification is often included in the process. In project situations. (2002) and Voetsch et al. who investigate the influence of risk management on project planning. as well as requirements (product performance). Voetsch et al. but epistemic. this often leads to the postponement of the decision (Kutsch and Hall. These are the characteristics of behavior that is not in line with the view presented by the risk management approach that actors behave rationally.g. Besner and Hobbs (2006) as well as others. non-traditional project success definitions partially include features of traditional project success. McGrew and Bilotta (2000). Kutsch and Hall (2005) show that project managers in IT projects show a tendency to deny the possibility or actual presence of risk and uncertainty. Therefore.g. Risk analysis.g. They have come to the conclusion that the sequence of identification. or delay their actions until the circumstances have improved. (2004) state that it is done in almost all of the projects. but these terms also refer to time and budget (process performance). or to a request for more information. While there are many reasons for these failures. Raz et al. (2000). their expectations are too high. however. and performance (quality) issues.. Bannerman (2008). e. Wallace et al. right from the start of the project. thereby broadening the definition of project success. 2005). e. Further. Project success will. Flyvbjerg et al. (2004) have investigated the various activities carried out within the risk management process of several types of projects. they can typically be categorized as cost. but add the impact of risks on team performance as described by Jiang et al. become much harder to achieve in terms of time and budget requirements. time. (2003) have shown that at the start of a project. Han and Huang (2007) use the concepts of product and process performance (see e. analysis. As a . ignore them. Bannerman (2008) in his research finds that none of the 17 IT projects he investigated used quantitative risk analysis. Besner and Hobbs (2006) have observed that project managers do not regard risk analysis as potentially valuable. and monitoring is often not followed. they avoid them.Page 9 of 11 Chrispus Kimingichi Wanjala process performance. As a result. Conclusion The failure of IT systems development projects has been well documented. therefore. responses. especially quantitative risk analysis. the performance of quantitative risk analyses within IT projects is not expected to increase in the near future. people deliberately both overestimate the benefits of the project and underestimate its risks and uncertainties. 2004a). is rarely done.

Fall 2003." Journal of Management Information Systems. Fretty. May 2006. Hoffman. S. P.Page 10 of 11 Chrispus Kimingichi Wanjala way to help overcome these project failures. (20:5). William. NY." Field Guide to Project Management 2nd ed. New York." IEEE Software. 203-225. Effective risk management process will succeed by changing the organizational culture to motivate the individual. Cultural changes require time and repetition before they are firmly embedded into the organization. Hayes. Spring 2004. Septem. G. D.T. organizations that implement effective processes proved to be successful. vi. 2004. v. 13. 76-80. and Talbot. Cleland. Fall 1993. "An Empirical Investigation of Knowledge Transfer Mechanisms for IT Projects. J. Carr. F "Chaos Is Back. Karlsen. ii." PMNetwork. A Guide to the Project Management Body of Knowledge (PMBOK" Guide).. Project Management Institute. 14. & Gottschalk.37 x. iii. McGraw-Hill. (ed. 70. Peter. . 2004. the literature was examined to identify those risk factors that plague the systems development process. H. and Tuman. Upper Darby. while those that fail in this effort will be unsuccessful. Cleland. 2004. J. M. 44-48. E. iv. 31. L. PA. 2004 Barki. Inc. Many risk management processes have been created to aid organizations.. 17. The nature of software projects makes risk management to be managed diligently to avoid the common drawback of many projects. Marcia.16. 28-34. J. Rivard." Computerworld." Information Systems Management. "Why the Vasa sank: 10 problems and some antidotes for software projects. 15. "Energizing Project Teams. & Willshire. March/April 2003. I. The theoretical aspects of the process must be reconciled with the practical challenges of the organization to implement risk management successfully. J. Hoboken. Jedd. (38:45). G. R.. 112-119. "Risking Less" PMNetwork. D. R. "Why do Projects Really Fail. NJ: John Wiley & Sons. Fairiey.).. (20:3). (19:9). but integrating the processes into organizations was not successful. "Toward an assessment of software development risk. & Ireland. viii. March 2006. ber 2005. Although software risk management is a daunting task. need. References i.. (44:1). (10:2).)." Journal of Computer Information Systems. vii..I. The perceptions and attitudes towards risk management activities compound difficult challenges for implementing a risk management strategy. 18-25. ix. "Balancing Act" PMNetwork. Project Management Strategic Design and Implementation (4th Ed. Englehardt.

xvi. 2002. BIOGRAPHY Mr. 86-92. J. (35:2). Vienna. "In-House Software Development: What Project Management Practices Lead to Success?" IEEE Software. He holds a BSc." Journal of Com.M. "How Software Project Risk Affects Project Performance: An Investigation of the Dimensions of Risk and an Exploratory Model. VA: Management Concepts. Fall 2000. Winter 2001-2002. Spring 2001. M.J. Lyytinen.". Project Risk Management: A Proactive Approach. xiv.K..536. & Sosik. xv. (41:1). Vemor. December 2003. Tesch. and Rai. E. WM. Paul S. & Cule." Project Management Journal. 66-78. M. A." Decision Sciences.18. degree in Computer Science from Masinde Muliro University of Science and Technology.. "Identifying software project risks: an intemational Delphi study. "Organizational factors for successful management of software development.. (34:4). J. "Why information systems projects are abandoned: a leadership and communication theory and exploratory study. Chrispus Kimingichi Wanjala is a system administrator at African Institute of Research and Development studies.. Kloppenborg." Journal of Computer Information Systems. Oz.Page 11 of 11 Chrispus Kimingichi Wanjala xi. J. T. Keil. 289-321. (xx:x). & Stemmer. (17:4). computer Information Systems. H. P. L. Leung. Wallace. Currently he is pursuing a Master of Science in Information Technology program at Masinde Muliro University of Science and Technology. Keil. January 2005. Spring 2004. xvii. Royer... xii. K. . Journal of Management Information Systems. xiii.B. Schmidt. & Evanco. 26-37. (22:1). 33-39. He is also a Cisco Certified Network Associate. R. He has a strong research interest in mobile technology and computer networks. D.. "Investigation of ISAT Research for Project Management Leaming.