Using a project leadership framework to avoid and mitigate information technology (IT) project risks
Timothy J. Kloppenborg, PhD, PMP
Williams College of Business,
Debbie Tesch, DBA
Williams College of Business,
Proceedings of the PMI Research Conference
11-14 July 2004 – London, UK
Software project risk management advocates allege that identifying and analyzing threats to success can lead to actions that reduce the chance of failure. Many of these advocates are proponents of the Project Management Institute's (PMI®) common body of knowledge. Project management professionals in a professional development seminar were asked to examine risks identified in the literature as IT project risks from three categories. Categorized as risks related to scope and requirements, operations risks, or risks related to roles and responsibilities, participants were asked to describe avoidance and mitigation strategies for each risk and to associate each risk with its appropriate stage in a project leadership model.
In the next section of the paper, we review prior work related to project risk in Information Systems (IS) research. Using this base, we then describe the establishment of a list of IT project risk factors and their subsequent examination by Project Management Professionals (PMP®s) in each of two professional seminars.
Results described include the establishment of avoidance and mitigation strategies for each risk and subsequent categorization of each risk to the appropriate stage in a leadership model framework. Tabulated results are discussed as to location and frequency of occurrence. We conclude with implications for IT project leaders and suggestions for how to use these findings.
Key functions in A Guide to the Project Management Body of Knowledge (PMBOK® Guide) related to the IS/IT discipline were extracted from the literature through a previous partnership between Xavier University and PMI. This research grant required generation of the body of all research abstracts dated between January 1, 1999 and December 31, 2001 specifically related to project management in the IS/IT area. Using a previously established research definition of project management and focusing on research specifically in the IS/IT area, 784 records formed the initial research base. Published as lessons learned in the Project Management Journal (Tesch, Kloppenborg, & Stemmer, 2003), significant findings included the requirement for IS projects to include generally qualified project management professionals as well as business and technically trained project leaders and the identification of the top three IS project risk factors. These factors are the lack of top management commitment, failure to obtain user commitment, and misunderstanding of commitment.
In order to increase the success rate of IS projects, managers must assess risks early and constantly throughout the life of the project. Yet, proper risk assessment requires an understanding of what the risks are and which of these risks is most critical. Using a rigorous, systematic approach, Schmidt, Lyytinen, Keil, and Cule,(2001) developed an “authoritative” list of 33 risk factors (including 23 factors derived from the literature and Boehm's “Top Ten”) using input from a multicultural set of 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 non-technical. From this comprehensive list of risk factors, a set of risk factor groups was developed. The groups created are consistent with five risk groups previously established in Barki, Rivard, and Talbot (Fall 1993). Risk groups created include corporate environment, sponsorship/ownership, relationship management, project management, scope, requirements, funding, scheduling, development of process, personnel, staffing, technology, external dependencies, and planning.
In a survey of IS executives, Oz and Sosik (Fall, 2000) collected quantitative and qualitative data about reasons why IS projects are abandoned in an extensive literature search. Thirty items were identified as reasons for IS project abandonment from trade and academic journals. 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 Willshire (2003), in a unique examination of the sinking of the Royal Swedish Navy ship Vasa, parallel the problems of the Vasa project that are common to large software projects and offer antidotes for software projects.
Project leaders must make stage-specific decisions on all projects. Systematically applying their experience and judgment in making these decisions is the essence of project leadership, according to Kloppenborg, Shriberg and Venkatraman (2003). These stage-specific decisions form the basis of the project leadership model used in this paper (see Exhibit 2). While this project leadership model is research-based with well over 100 written sources, we wanted to enrich our knowledge of how these decisions are made by capitalizing on the collective experience of senior project management professionals (PMP®s) who regularly deal with risk on IT projects.
Kerzner (1998, p. 9) states “in the future, project managers…will be given the authority to address potential problems by proactively managing their projects rather than reacting to ongoing risks.” Since Kerzner made that statement six years ago, we feel this described future should be now. To do our part in making that happen, we decided to stage a series of research events in which experienced PMPs could offer their opinions regarding how project leaders can more effectively avoid and mitigate common risks on IT projects.
First Professional Seminar
In October 2003, twenty-three PMPs with an average of 12.4 years experience in IT project management participated in a professional development day associated with the Southwest Ohio PMI chapter and self-selected a session entitled “Cutting Edge IS/IT PM Research: Risk Factors Associated with Project Failure/Success.” Participants were asked to examine 92 risk factors presented in 9 categories of risk: corporate environment risks, funding and scheduling, requirements, personnel and staffing, project management, scope, relationship management, sponsorship/ownership, and a miscellaneous group. All risk factors discovered in this most recently described literature were considered. The groups described in Schmidt et al., (Spring, 2001) were used to organize factors.
Participants were randomly assigned to examine risk categories. Working individually at first, participants were asked to rate each risk in their area as high, medium, or low. Once completed, PMPs formed small groups by risk area to rank the risks from highest to lowest. In both instances, participants were asked to consider both the probability of the risk event happening and the consequences to a project if it would happen. From this initial assessment, risks identified as of high or medium consequence were organized for further investigation.
Second Professional Seminar
In February 2004, 25 project managers (21 of whom were PMPs) with an average of 17.8 years experience participated in an exercise designed to assign avoidance and mitigation strategies to each of 70 risks (out of the original 92) established previously by a unique group of PMPs as high or medium-level risks. It is remarkable that there were no duplications in participation. No participant in the second seminar had previously participated. To facilitate discussion, we organized the previous nine groups of risks into three categories: roles and responsibilities, scope and requirements, and operations. Exhibit 1 presents risks proposed for consideration. Participants were invited to participate from a risk response development perspective by identifying for each risk avoidance and mitigation strategies from their personal experience.
For each risk category, participants were provided with an initial set of 12 Post-It Notes for each risk. Six muted color labels affixed with the risk item represented avoidance strategies necessary to ward off the occurrence of the risk. To represent mitigation strategies, six bold-colored labels were provided. We also printed 12 copies of each risk on labels and affixed half of the labels to muted-color Post-It Notes to represent six avoidance strategies, and the other six on bright-colored Post-It notes to represent mitigation strategies. Each group of participants had the opportunity to identify strategies for all 70 identified risks. Participants were also able to create additional risk labels where needed. Each participant was asked to develop more than one avoidance or mitigation strategy under the belief that the first strategy may be obvious and sometimes the second or third identified strategy may be more creative. The participants were then asked to determine which project participant should be assigned the strategy. Participants to consider were steering team, sponsor, project manager, functional manager, customer, and technical lead. More than one role could be assigned to a strategy.
Once created, participants were asked to post strategies by risk category in the most appropriate of seven project leadership task categories within each of the four life cycle stages (initiation, planning, execution, and closing) (see Exhibit 2). This process resulted in a first complete pass through each of the risks for each group.
After the first pass, participants exchanged groups, spent some time analyzing previously created risk avoidance/mitigation strategies, and proceeded to add additional strategies based on their experience. This exchange occurred twice in order that all participants had an opportunity to contribute to the process.
As a final phase in the process, participants were asked to sort strategies within categories where a large number of inputs had been provided. For example, monitor and control project work had many mitigation strategies. The participants then grouped the many strategies in that category into related groups of strategies. The relation was based upon how to implement the strategies – not what specific risk prompted the strategy. Once groups were determined, the participants developed names for the strategy groups. Persons responsible for sorting risks by group were then asked to explain briefly to the entire group what they thought of the strategies identified in their area. This led to general discussion.
Based on results in the literature and personal project management experience, we anticipated several outcomes. First, we anticipated that most avoidance strategies would occur during project initiation and planning. Second, we anticipated that most mitigation strategies would occur during project execution. Third, we anticipated that, for risks categorized as roles and responsibilities, strategies would be primarily in the project leadership categories that deal primarily with people: namely, human resources, human relations, promotion, and commitment. Fourth, we anticipated that, for risks categorized as scope and requirements, most strategies identified would fall into the three project leadership categories that are mostly concerned with process: namely, priorities, details, and integration. Finally, we anticipated that operations risk strategies would also be most closely associated with project leadership process tasks.
IT Risks were examined by risk category and leadership stage as presented in Exhibit 3. There were 745 risk avoidance/mitigation strategies generated. More strategies were generated for operational risks (37%) than for roles and responsibilities (34.6%) and scope and requirements (28.3%) risks. The initiating, planning, and executing stages account for approximately 97% of the total. The number of strategies for these first three stages was approximately equal: 229 (30.7%) for initiating, 241 (32.3%) for planning, and 251 (33.6%) for executing.
Exhibit 4 presents initial results of total strategies generated by task within each project life cycle stage. This more detailed exploration of the tasks associated with each of the life cycle stages reveals that avoidance/mitigation strategies described were most frequently associated with the project details tasks (30.7%). Of the strategies dealing with details, those in the execution stage of the project life cycle were most common (107 strategies).
While the previous two exhibits deal with all risk strategies, Exhibit 5 only deals with avoidance risk strategies. These are shown by task within project life cycle stage. The most frequently discussed project avoidance risk strategies were considered in the initiating stage (51.7%) of the project life cycle. The planning stage also had a large number of proposed strategies (41.1%). Of the initiating stage tasks, project details strategies (35) and human resources strategies (34) were the most frequent strategies. The project leadership category with the fewest proposed strategies is project promotion (23).
Mitigation risk strategies by task within each life cycle stage are presented in Exhibit 6.
The most frequently described mitigation strategies were found in the executing stage of the project life cycle (62.0%). Once again, project details (34.2%) was the leadership category most frequently considered in mitigating IT project risk. Project integration received only 18 mitigation risk strategies (4.9%).
Exhibit 7 presents risks by category (roles and responsibilities risks, scope and requirements risks, and operational risks) within each leadership task for the combined project life cycle stages. Thirty-seven percent (276) of the strategies described were associated with operational risks, 35% were roles and responsibilities strategies, and 28% of the risks were scope and requirements risk strategies. Again, more strategies (226) were ascribed to the project details leadership task (30%) than any other project leadership category.
Combined avoidance/mitigation strategies were examined by risk category for each leadership task within each life cycle stage in Exhibits 8 through 10. There were 276 of the 745 strategies (37%) described in the operational risk category, 258 (35%) strategies were described for roles and responsibilities risks, and 211 (28%) were scope and requirements risk strategies.
In the operational risks category (Exhibit 8), 102 (37%) of strategies assigned were project executing stage risks, followed by 83 (30.1%) in the initiating stage of the life cycle, 79 (28.6%) in the planning stage, and 12 (4.3%) in the closing stage. On an overall project basis, the project details stage risks accounted for 31.5% of strategies assigned.
An examination of scope and requirements risk strategies (Exhibit 9) reveals that the largest number of assigned strategies was in the planning stage (42.7%), followed by executing (33.6%), initiating (22.3%) and closing (1.4%). Once again, more strategies were assigned to the project details task category (42.7%) than any other project leadership category.
Roles and responsibilities risk strategies (Exhibit 10) were most frequently assigned to the initiating stage of the project life cycle (38.4%). The executing stage was assigned 30.2% of these strategies, followed by planning (27.9%) and closing (3.5%). An examination by task reveals that more strategies were associated with human resources tasks (22.1%), followed by project details (19.0%), project commitment (17.1%), project promotion (15.9%), human relations (12.4%), project priorities (8.1%), and project integration (5.4%).
In order to test for the presence of projected outcomes as described earlier, we used the Chi-square test of independence. In each case, the null hypothesis indicates that there is no relationship between assigned row and column variables described in a cross-tabulation. The following hypotheses related to the projected outcomes were tested:
H0: Avoidance and mitigation strategies are assigned independently of project life cycle stages.
H1: Role and responsibility, operations, and scope and requirements risks are assigned independently of project leadership task categories.
Using contingency table data as described in Exhibit 11 and the Statistical Package for the Social Sciences (SPSS) cross tabs analysis, the Pearson Chi-Square value is 310.98 and H0 is rejected at a highly significant level (.001) indicating that a relationship exists between assigned strategies and project life cycle stages. To test the independence of risk categories and project leadership tasks, project leadership task categories were combined to reflect tasks associated with process (priorities, details, and integration) and people (human resources, human relations, promotion, and commitment). Similarly, using data described in Exhibit 12, the Pearson Chi-Square value is 61.798 and H1 is again rejected (alpha = .001) indicating that a relationship exists between risk categories and project leadership tasks.
One of the first interesting findings is that, on an overall basis, a significant number of strategies were suggested in each stage except closing. The overall percentages of suggestions (as shown in Exhibit 3) were 34% in the executing stage, 32% in the planning stage, 31% in the initiating stage, but only 3% in the closing stage. Each of the first three stages offers many opportunities to avoid and/or mitigate risks on the current project. The few suggestions during closing, however, are primarily useful for avoiding risks on future projects. These strategies deal with terminating, auditing, and capturing lessons learned. We will focus the remainder of our interpretation on the 97% of the proposed strategies that deal with the first three project stages.
Another set of overall trends worth noting deals with the assignment of strategies by leadership tasks within project life cycle stage, as can be seen in Exhibit 4. The most strategies by far were proposed for the oversee project details area (229 suggestions or 31% of the total). This is not surprising since many times an overlooked detail is what leads to a problem. The PMPs proposed a significant number of suggestions for each of the seven categories of project leadership (note that the smallest category, project promotion, still received 56 suggestions).
The individual project leadership task that received by far the most suggested strategies was monitor progress and control changes within the project details category of the executing stage (107 suggestions). This is not surprising since effectively monitoring progress can lead to earlier identification of potential risks. The effects of many risks can be minimized if they are identified quickly. The individual project leadership tasks that came in a distant second was overseeing detailed plan development with 69 suggestions (again in the project details category). This is not surprising either since taking great care to plan a project in detail should uncover many risks or make them easier to deal with. All of the other individual project leadership tasks have significantly fewer suggestions.
Our first projected outcome is that more avoidance strategies would be proposed for the Initiating and Planning stages than the stages later in the project. A cross-tabs analysis confirmed the existence of a relationship. In fact, 52% of the strategies proposed were for the initiating stage (as can be seen in Exhibit 5) and another 41% were for the planning stage. Executing at 6% and closing at 1% have far less avoidance strategies. The single project leadership task with the most avoidance strategies was overseeing detailed plan development in the planning stage. Six of the initiating tasks and two other planning tasks had at least 24 strategies each.
Our second projected outcome is that project execution is the stage for which most of the mitigation strategies would be proposed. Again, a relationship is substantiated using Chi square. Exhibit 6 indicates that 62% (228) of the mitigation strategies proposed were for the executing stage. Planning with 23%, initiating with 9% and closing with 5% of the suggestions follow. Monitor progress and control changes in the executing stage with 92 strategies have far more suggestions than any other project leadership task. The next three tasks with the most suggestions are also part of the executing stage: supervise work performance (37), secure customer acceptance (34), and lead teams (29).
We strongly expected the results we received for the first two projected outcomes. Very large Chi-square values confirmed dependent relationships. We included them largely to confirm that we could trust associated projected relationships.
Our third projected outcome is that the strategies dealing with roles and responsibilities risks would be predominantly in the leadership categories of human resources, human relations, project promotion, and project commitment (the categories that deal primarily with people). When one looks at the list of roles and responsibilities risks (see Exhibit 1), one way of categorizing them is that some deal above the team level (corporate commitment and strength of sponsor), some at the team level (project manager and other team members), and some generally deal with behaviors (responsibilities, skills, and conflict).
When evaluating our third prediction (see Exhibit 10), we noted that 67% of the identified strategies dealt with the four “people” categories of project leadership. Select key project participants (23 strategies) and supervise work performance (20 strategies) were the two tasks most frequently cited. However, two other “people” tasks were not far behind with 17 suggestions each: commit to the project and secure key stakeholder approval. Additionally, one “process” task--monitor progress and control changes--also had 17 proposed strategies. It is interesting to note that 16 of the 28 project leadership tasks had at least 10 suggestions for dealing with role and responsibility risks. Twelve of those tasks (75%) receiving a large number of suggestions are among the “people” tasks.
Our fourth prediction is that we believed the scope and requirements strategies would occur predominantly in the leadership categories of project priorities, project details, and project integration (the categories that deal primarily with “process”). One way to categorize the scope and requirements risks (see Exhibit 9) is to group them largely into two areas: understanding and agreeing to initial requirements and the effects of change (creeping requirement and control methods).
In fact (see Exhibit 9), 68% of the scope and requirements risk strategies suggested deal with “process” task categories. The three project leadership tasks that received by far the most suggestions are all “process” tasks. Monitor progress and control changes is highest with 46 suggestions followed by oversee detailed plan development with 34 and understand and respond to the customer with 31. These tasks all occur during the planning or executing stage. No other tasks in any stage received more than 11 suggestions.
Our fifth and final projected outcome is that the strategies for avoiding and mitigating operational risks would mostly deal with the “process” task categories as well. The operational risks, as seen in Exhibit 8, mostly deal with the issues of project tradeoffs (cost, schedule, and scope), outside stakeholders (vendors and users), and project planning and control methods. The results of this projected outcome are not so clear. A smaller majority of the suggestions here (56%) are in the categories of project leadership that we anticipated. Monitor progress and control changes is the task that received by far the most suggestions (44). The next two highest suggestion tasks also deal with project details: oversee detailed plan development (23) and perform risk analysis (19). Tied for the fourth-most suggestions with 17 are justify and select the project, develop communication plan, and secure customer acceptance. In retrospect, the operational risks that deal with outside stakeholders really are “people” issues and it is not surprising that there were numerous suggestions for develop a communications plan and secure customer acceptance.
When we look at the three broad categories of risks and the timing of the suggestions (see Exhibits 8, 9, and 10), an interesting pattern emerges. There are more suggestions for roles and responsibilities during project initiation, more suggestions for scope and requirements during planning, and more suggestions for operational risks during executing. It seems that the most basic advice is to first get the right people, then get the right requirements, then execute the operation the right way.
Project management professionals in a local PMI professional development seminar were asked to define risk avoidance and mitigation strategies for each of 70 risks in three risk categories. Once defined, these risks were applied to one of seven task areas in each of the four project life cycle stages. A number of observations can be made about the 745 assigned strategies.
- The majority of risk avoidance strategies occur during project initiation and planning.
- Most mitigation strategies are based in the project execution stage.
- Risks categorized as roles and responsibilities risks are closely aligned with project leadership tasks associated with people: human resources, human relations, promotion, and commitment.
- Risks categorized as scope and requirements strategies occur predominantly in the leadership categories associated with process: project priorities, project details, and project integration.
- Operations risk strategies are concerned with process (56%) and people (44%) tasks.
Statistical analysis confirms that a relationship exists between risk strategies and project life cycle stages, and between risk categories and leadership stage categories. The categorization of risk avoidance/mitigation strategies into a project leadership model offers project management professionals a framework for considering implementation of avoidance strategies at the appropriate stage of project development, as well as the opportunity to anticipate when appropriate mitigation strategies might become necessary. Future analysis of these results will include detailed examination and definition of specific strategies, as well as an investigation of the roles associated with these strategies. This framework can then be used to confirm conclusions reached in a large- scale survey analysis.
We plan to perform at least two types of further analysis with this data. First, the PMPs who suggested each strategy also suggest what role or roles should be associated with each. The various roles identified are the executive steering team, sponsor, project manager, functional (resource) manager, senior customer representative, and technical lead. We think it will be interesting to understand what each of the people in these roles needs to do to avoid and/or mitigate various risks.
Second, in this paper, we have considered the overall trends in suggested strategies. The next thing we wish to do is look more closely at each of the 745 individual strategies. As we further understand the details, we anticipate constructing a survey with which to verify and clarify these findings.
This paper represents several stages of an ongoing research effort to combine the project risk and project leadership knowledge areas, using both literature and experienced practitioners. We feel that we now have some useful suggestions concerning what needs to be done, by whom, and when to avoid or mitigate the effects of some of the more common risks that are likely to occur on projects. We hope to continue this stream of research and to be able to offer additional advice to both practitioners and researchers.
Barki, H., Rivard S., and Talbot, J. 1993. Toward an Assessment of Software Development Risk. Journal of Management Information Systems 10:2,(Fall 1993): 203-225.
Fairley, R. E., and Willshire, M. J. 2003. Why the Vasa sank: 10 problems and some antidotes for software projects. IEEE Software (March/April): 18-25.
Kerzner, H., 1998. In Search of Excellence in Project Management. New York: Van Nostrand Reinhold.
Kloppenborg, Timothy J., Shriberg, Arthur, and Venkatraman, Jayashree. 2003. Project Leadership. Vienna, VA: Management Concepts Incorporated.
Oz, E., and Sosik, J., 2000. Why information systems projects are abandoned: a leadership and communication theory and exploratory study. Journal of Computer Information Systems (Fall): 66-78.
Schmidt, R., Lyytinen, K., Keil, M., and Cule, P. 2001. Identifying software project risks: an international delphi study, Journal of Management Information Systems (Spring): 5-36.
Tesch, D., Kloppenborg, T. and Stemmer, J. Investigation of IS/IT Research for Project Management Learning, Project Management Journal, 34:4, December 2003: 33-39.
Author Contact Information
Timothy J. Kloppenborg, PhD, PMP
Professor of Management and Entrepreneurship
3800 Victory Parkway
Cincinnati, OH 51207-5163
Telephone: (513) 745-4905
Fax: (513) 745-4383
Debbie Tesch, DBA
Assistant Professor of Information Systems
3800 Victory Parkway
Cincinnati, OH 51207-5161
Telephone: (513) 745-3377
Fax: (513) 745-4383