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 [email protected]

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

Page 2 of 11

Chrispus Kimingichi Wanjala

software projects are cancelled outright and the remaining projects suffer from schedule slippage, cost overruns, or failure to meet their project goal (Boehm, 1991) Things like scope management is so difficult to manage since most of the software requirements cannot be captured at the initial stage. 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. Because of this, software development engineers have high turnover rates among software development firms. Software managers in india perceived personnel turnover as their biggest source of risk ( Boehm and Demarco, 1997) Many software project and programs involve multiple entities such as companies, divisions etc. that may have certain interest. There is often a feeling of disconnection between software developers and their management, each believing that the others are out of touch with reality resulting in misunderstanding and lack of trust, research shows that 45% of all the causes of delayed software deliverance are related to organizational issues (Van Genuchten, 1991).

The PMBOK Guide 3rd edition [1], defines Project Risk Management as "the processes concerned with conducting risk management planning, identification, analysis, responses, and monitoring and control on a project". Project Risk Management then involves the systematic process of identifying, analyzing, and responding to project risk. Project risk involves understanding the potential for problems as they might impede project success. In a study of project management maturity by industry group (including infonnation systems) and knowledge area, project management risk ranked among the eight core and facilitating functions examined. Of the four industries included, risk in the IS area ranked lowest in level of maturity (2.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. As described in the PMBOK [1], project risk management processes include: Risk management planning the process of deciding how to approach, plan, 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

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, and Risk monitoring and control responding to changes in risk over the course of the project through identification, tracking and monitoring of risks, execution of risk response plans, 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. This indicates that time and other resources must be allocated to manage risk when developing any information technology software project. However, most software developers and project management perceive risk management processes and activities as extra work and expense. Risk management processes are the first thing to be removed from the project activities when the project schedule slips. 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. Jones (2001) mentioned it is peculiarity of IT that very complex systems can be built with a very low level of control by clever, driven people. Many software development practitioners understand risk management and control as inhibiting creativity. The risk can be managed well when is identifies at the early stages. This can be done using a vigorous, systematic approach, Schmidt, et al [15] developed an "authoritative" list of 33 risk factors using input from 41 practicing project managers. Comparison of the list of risk factors with those generated in previous studies suggests that this list is fairly comprehensive and nontechnical. The list of risk factors was organized into 14 groups based on the source of the risk and subsequently ranked in order of priority. From this comprehensive list of risk factors, a set of risk factor groups was developed. Groups created are consistent with five risk groups previously established by Barki et al. [2]. Risk groups created include corporate environment, sponsorship/ ownership, relationship management, project management, scope, requirements, funding, scheduling, development of process, personnel, staffing, technology, extemal dependencies, and planning. In a survey of IS executives, Oz and Sosik [13] collected quantitative and qualitative data concerning reasons why IS projects are abandoned. They identified 30 reasons for IS project abandonment.

Page 4 of 11

Chrispus Kimingichi Wanjala

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

(TSM

TM

) for the team

(PSP

TM

) for individual during software project

development (SEI 2001). Keshlaf and Hashim (2000) have developed models for tools to aid the software

Page 5 of 11

Chrispus Kimingichi Wanjala

Project Risk Management has developed into an accepted discipline, with its own language, techniques, procedures and tools. 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. There are a number of areas where risk management needs to develop in order to build on the foundation that currently exists. One of the most important of these is the ability to measure effectiveness in managing risk. This measurement is often undertaken by project managers, many of whom are professionally certified. The following are some of areas the risk can come from and measures that can be taken to prevent them from occurring.

Sponsorship/Ownership Risks
Sponsorship/ownership risks include such factors as corporate management's loss of interest in the project; the project has a weak/lacking champion, lack of corporate leadership, an unstable corporate environment, failure of corporate management to make decisions at critical junctions, lack of client buyin to the project, conflict between user departments, and unethical behavior. The top risk in this group is the project may have inadequate top management commitment. A strategy for dealing with inadequate top management commitment is an important factor to reduce risk of project failure. The best way out is the avoidance strategies that is trying to head the problems off before it become severe. Most of these strategies involve the role of the project's sponsor. Carr, et. al., [3] assert that the sponsor should set the project team's goals and vision, encourage and support the project team, and remove roadblocks. 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, going over the sponsor's head, replacing the sponsor, forcing the sponsor or the steering team to either back or cancel the project, and several specific suggestions for developing and maintaining communications. There were also a few mitigation strategies suggested. These included continuing to secure commitments or refusing to continue work and continuing to use the communications that were established as avoidance strategies.

Funding and Scheduling Risks

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, under funding of development, use of artificial deadlines, under funding of maintenance, deviation from budget, and having a user lead the project. The top ranked risk is that the entire project must be budgeted at the outset of the project and schedule risks, and getting the customer to commit to further funding or limit the project.

Personnel and Staffing Risks

Personnel and staffing risks included the projects lack of enough people with the right skills, lack of required knowledge/ skills in the project personnel, lack of available skilled personnel, incompetent IS professionals on the team, infrequent meetings of the project team, and excessive use of outside consultants. The highest rated of these was the first the project lacks enough people or those with the right skills. Strategies to ensure enough people with the right skills include determining the resource requirements, assessing the skills of those already assigned, recruiting to fill gaps, using a roles and responsibilities matrix to identify problem areas, and ultimately not committing to perform the project if you do not have the right skills available. If the project is underway and resource problems surface, mitigation strategies include reducing the scope if you cannot add sufficient staff, obtain temporary resources, replace or reassign people, and work with your existing team to determine how to overcome the shortage. The above mentioned risk is just part of the risk that can make information project failure. 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. 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, 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). Additional factors include objectives are unclear or misunderstood, scope tends to creep, requirements tend to creep, and changing needs are introduced when the project is already underway. Chasing technology instead of satisfying legitimate requirements can be avoided by using strategies such as conducting feasibility studies to determine expected benefit, validating the business case for the project with your sponsor,

Page 7 of 11

Chrispus Kimingichi Wanjala

rejecting unworthy projects at the outset, piloting new technology before rolling it out, and defining alternative approaches to satisfying the legitimate business needs of the organization. If problems arise when a project team ignores a requirement, top management should re-evaluate the project, stop the project if a strong business case cannot be developed, direct that an alternative approach be used, and kill the project if necessary. If the project team has started to develop a technology that does not support the business case but appears to be promising, top management may elect to roll this technology into a new project aimed at a market for which a business case can be justified.

Requirements Risks
Requirements risk factors include no agreement on goals, lack of understanding users' needs, not freezing the requirements, not identifying risks and contingency plans, not exerting proper control, having unclear lines of communication, and handling project changes poorly. The practitioner experts rated the final risk_ handling project changes poorly as the top risk in this category. 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, assigning an experienced project manager is the next suggestion. Following this should be several typical project management practices of agreeing to a good charter before proceeding, establishing a change control process, determining in advance when you need to obtain approval from your sponsor and steering team, and agreeing to track progress and the need for changes. Once the project is underway, follow the rules you established regarding changes and their approval, meet regularly with your sponsor and customers to discuss potential changes and secure their approval, evaluate the impact of potential changes, and redo any task that was not completed properly.

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, lack of cooperation from users, failure to identify all stakeholders, lack of appropriate experience from user representatives, and higher user expectations due to their growing sophistication. Ultimately, these all lead to the top rated risk which is failure to meet user expectations. 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, set clear expectations in the project charter, hold requirements sessions with the user, hold design reviews with the user, and generally work imaginatively to ensure all key stakeholders have been identified and that you obtain their input

Page 8 of 11

Chrispus Kimingichi Wanjala

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

Page 9 of 11

Chrispus Kimingichi Wanjala

process performance, but these terms also refer to time and budget (process performance), as well as requirements (product performance). Further, non-traditional project success definitions partially include features of traditional project success, e.g. McGrew and Bilotta (2000), who investigate the influence of risk management on project planning. Han and Huang (2007) use the concepts of product and process performance (see e.g. Wallace et al., 2004a), but add the impact of risks on team performance as described by Jiang et al. (2000), thereby broadening the definition of project success. 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; they avoid them, ignore them, or delay their actions until the circumstances have improved. These are the characteristics of behavior that is not in line with the view presented by the risk management approach that actors behave rationally. Flyvbjerg et al. (2003) have shown that at the start of a project, people deliberately both overestimate the benefits of the project and underestimate its risks and uncertainties. As a result, the stakeholders become biased; right from the start of the project, their expectations are too high. Project success will, therefore, become much harder to achieve in terms of time and budget requirements. Besner and Hobbs (2006) as well as others, e.g. Bannerman (2008), Raz et al. (2002) and Voetsch et al. (2004) have investigated the various activities carried out within the risk management process of several types of projects. They have come to the conclusion that the sequence of identification, analysis, responses, and monitoring is often not followed. Risk identification is often included in the process; Voetsch et al. (2004) state that it is done in almost all of the projects. Risk analysis, however, is rarely done. Besner and Hobbs (2006) have observed that project managers do not regard risk analysis as potentially valuable, especially quantitative risk analysis. Therefore, the performance of quantitative risk analyses within IT projects is not expected to increase in the near future. Bannerman (2008) in his research finds that none of the 17 IT projects he investigated used quantitative risk analysis. 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), but epistemic, which means that there is not enough information available to take a decision. In project situations, this often leads to the postponement of the decision (Kutsch and Hall, 2005), or to a request for more information.

Conclusion
The failure of IT systems development projects has been well documented. While there are many reasons for these failures, they can typically be categorized as cost, time, and performance (quality) issues. As a

Page 10 of 11

Chrispus Kimingichi Wanjala

way to help overcome these project failures, the literature was examined to identify those risk factors that plague the systems development process. Although software risk management is a daunting task, organizations that implement effective processes proved to be successful, while those that fail in this effort will be unsuccessful. The nature of software projects makes risk management to be managed diligently to avoid the common drawback of many projects. The perceptions and attitudes towards risk management activities compound difficult challenges for implementing a risk management strategy. Many risk management processes have been created to aid organizations, but integrating the processes into organizations was not successful. The theoretical aspects of the process must be reconciled with the practical challenges of the organization to implement risk management successfully. 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.

References
i. ii. iii. iv. v. vi. vii. viii. ix. A Guide to the Project Management Body of Knowledge (PMBOK" Guide), Project Management Institute, Upper Darby, PA, 2004 Barki, H., Rivard, S., and Talbot, J. "Toward an assessment of software development risk," Journal of Management Information Systems, (10:2), Fall 1993, 203-225. Carr, G., Englehardt, G. and Tuman, J. "Energizing Project Teams," Field Guide to Project Management 2nd ed., Cleland, D.I. (ed.), Hoboken, NJ: John Wiley & Sons, Inc, 2004. Cleland, D. I., & Ireland, L. R. Project Management Strategic Design and Implementation (4th Ed.). McGraw-Hill, New York, NY, 2004. 13. Fairiey, R. E., & Willshire, M. J. "Why the Vasa sank: 10 problems and some antidotes for software projects," IEEE Software, March/April 2003, 18-25. Fretty, Peter. "Why do Projects Really Fail," PMNetwork, 14. (20:3), March 2006, 44-48. Hayes, F "Chaos Is Back," Computerworld, (38:45), 2004, 15. 70. Hoffman, William. "Balancing Act" PMNetwork, (20:5), May 2006, 28-34. Jedd, Marcia. "Risking Less" PMNetwork, (19:9), Septem- 16. ber 2005, 76-80. need," Information Systems Management, Spring 2004, 31- 37

x.

Karlsen, J.T. & Gottschalk, P. "An Empirical Investigation of Knowledge Transfer Mechanisms for IT Projects," Journal of Computer Information Systems, (44:1), Fall 2003, 17. 112-119.

Page 11 of 11

Chrispus Kimingichi Wanjala

xi. xii. Leung, H. "Organizational factors for successful management of software development," Journal of Com- 18. computer Information Systems, (xx:x). Winter 2001-2002, 26-37. Oz, E. & Sosik, J. "Why information systems projects are abandoned: a leadership and communication theory and exploratory study," Journal of Computer Information Systems, (41:1), Fall 2000, 66-78. xiii. xiv. Royer, Paul S. Project Risk Management: A Proactive Approach. Vienna, VA: Management Concepts, 2002. Schmidt, R., Lyytinen, K., Keil, M., & Cule, P. "Identifying software project risks: an intemational Delphi study,". Journal of Management Information Systems, (17:4), Spring 2001,536. xv. xvi. xvii. Tesch, D.B., Kloppenborg, T.J., & Stemmer, J.K. "Investigation of ISAT Research for Project Management Leaming," Project Management Journal, (34:4), December 2003, 33-39. Vemor, J.M. & Evanco, WM. "In-House Software Development: What Project Management Practices Lead to Success?" IEEE Software, (22:1), January 2005, 86-92. Wallace, L., Keil, M., and Rai, A. "How Software Project Risk Affects Project Performance: An Investigation of the Dimensions of Risk and an Exploratory Model," Decision Sciences, (35:2), Spring 2004, 289-321.

BIOGRAPHY
Mr. Chrispus Kimingichi Wanjala is a system administrator at African Institute of Research and Development studies. He holds a BSc. degree in Computer Science from Masinde Muliro University of Science and Technology. He is also a Cisco Certified Network Associate. Currently he is pursuing a Master of Science in Information Technology program at Masinde Muliro University of Science and Technology. He has a strong research interest in mobile technology and computer networks.