System_Project_Risk - Identifying and Mitigating...

Info iconThis preview shows page 1. Sign up to view the full content.

View Full Document Right Arrow Icon
This is the end of the preview. Sign up to access the rest of the document.

Unformatted text preview: Identifying and Mitigating Identifying Information System Project Risk Information D. Harrison McKnight Michigan State University 1 Important 2 Know* Be able to explain why system implementation sometimes fails. 2 Rationale • If risks are so rampant in system projects • And if the risk exposures can be so large • We need to really We – – – – Delve into the specific risks Become familiar with them Understand risk types Figure out how to deal with the key risks • An IT-lens view of these risks will help 3 Leading SA&D Textbook Treatment of Project Risk • Ch. 2 System Analysts (1 paragraph) – Risk mgmt is a skill needed by system analysts • Ch. 3 Project Mgmt (2 very short paragraphs) – Identifying and assessing risk is one of 10 activities in Identifying the Project Planning phase of the SDLC the – “Goal is to ID sources of project risk” + consequences • Ch. 6 Initiating/Planning Sys Projects (2.5 pages) – – – List of Project Risk Assessment Factors Table—combinations of different types of risk Mainly address “technical risks” within feasibility task Hoffer, George and Valacich, 2002 4 List of Risk Factors Risk Factor Examples Project Size -# of project team members -Project duration time -# of org’l departments involved -Size of program (hours, function points) Project Project Structure Structure -New system or renovation of existing system -User willingness to participate -Org’l, procedural changes resulting from system Development Development Group Group -Familiarity with target hardware, s’ware, tools, OS -Familiarity with application area -Familiarity with building similar size systems User Group -Familiarity with systems development process -Familiarity with application area, similar systems 5 Table of Risk Interactions Low Structure High Structure High High Familiarity with Tech or Applic. Area Applic. Large Large Project Project Low Risk Low Risk Small Small Project Project Very Low Risk Very Low Risk Low Low Familiarity with Tech or Applic. Area Applic. Large Large Project Project Very High Risk Medium Risk Small Small Project Project High Risk Hoffer, George and Valacich, 2002 Low-Medium Low-Medium Risk Risk 6 Project Risk Delphi Study • Study methodology – 41 project managers, avg. 16 years experience • • • USA Finland Hong Kong – Three Delphi project phases • • • Brainstorming—to produce list of risk factors (53) Selecting key factors—a manageable number (20) Ranking the 11 factors common to all 3 panels Ranking 11 Keil, Cule, Lyytinen and Schmidt, 1998 7 Most Important Risk Factors 1. 2. 3. 4. 5. 6. 7. 8. 8. 9. 10. 11. (in order of importance ) Lack of top mgmt commitment to the project Failure to gain user commitment I2K* Misunderstanding the requirements Lack of adequate user involvement Failure to manage end user expectations Changing scope/objections Lack of required skills Lack Lack of frozen requirements Introduction of new technology Insufficient / inappropriate staffing Conflict between user departments8 Lo + Hi: Some Insights • Only one of the 11 involves technology! Only – Factor #9: Introduction of new technology • Top mgmt commitment topped the list (#1) – “if…not present, then all other risks…may be if…not impossible to address…” impossible • User commitment (#2) user system ownership User – May even help overcome lack of mgt commtmt. • Misunderstanding the requirements (#3) – “Requirements drive the entire project.” – Without it, may produce system no one wants to use • Lack of adequate User Involvement (#4) 9 Risk Categorization Framework • Interesting: Panelists often ranked as most risky things over which they had little control Hence, a framework was built to reflect this 10 Project Risk Categorization Framework High Perceived Perceived Relative Imptce of Risk Risk 1 Customer Customer Mandate Mandate 2 Scope and Scope Requiremts Requiremts Moderate 4 Environment Environment 3 Execution Low High Perceived Level of Control 11 Most Important Risk Factors: Quadrants Q 1….. 1. 1….. 2. 2….. 3. 1….. 4. 2….. 5. 2/4... 6. 3….. 7. 2….. 8. 8. 3….. 9. 3….. 10. 4….. 11. Lack of top mgmt commtmt to project Failure to gain user commitment Misunderstanding the requirements Lack of adequate user involvement Failure to manage end user expectatns Changing scope/objections Lack of required skills Lack Lack of frozen requirements Introduction of new technology Insufficient / inappropriate staffing 12 Conflict between user departments Project Risk Categorization Framework High High Perceived Perceived Relative Imptce of Risk Risk 1 Customer Customer Mandate Mandate 2 Scope and Scope Requiremts Requiremts Moderate 4 Environment Environment 3 Execution Low High Perceived Level of Control 13 Managing Quadrant 1 Risks • Keil et al. suggest: – Build long-term relationships with users and Build Sr. Mgt. – Build trust by meeting commitments – Use your political skills • Align project with other important goals of the Align various project stakeholders various • Continue to gauge commitment Continue – All the above address Factors 1, 2, 4 14 Project Risk Categorization Framework High High Perceived Perceived Relative Imptce of Risk Risk 1 Customer Customer Mandate Mandate 2 Scope and Scope Requiremts Requiremts Moderate 4 Environment Environment 3 Execution Low High Perceived Level of Control 15 Managing Quadrant 2 Risks • Use evolutionary system development Use approaches like the spiral model approaches • Specify what is not in the scope Specify not • Educate users on impacts of scope creep • Help users feel ownership of the specs • Manage end user expectations 16 Project Risk Categorization Framework High High Perceived Perceived Relative Imptce of Risk Risk 1 Customer Customer Mandate Mandate 2 Scope and Scope Requiremts Requiremts Moderate 4 Environment Environment 3 Execution Low High Perceived Level of Control 17 Managing Quadrant 3 Risks • Have frequent internal/external project Have evaluations • Devote time and effort to: – Define roles and responsibilities – Develop contingency plans to cope with Develop staffing shortfalls – Make sure you follow detail methodology 18 Project Risk Categorization Framework High High Perceived Perceived Relative Imptce of Risk Risk 1 Customer Customer Mandate Mandate 2 Scope and Scope Requiremts Requiremts Moderate 4 Environment Environment 3 Execution Low High Perceived Level of Control 19 Managing Quadrant 4 Risks • Little can be done to anticipate them • Do a little contingency planning for the Do most likely possible external events most • Tighten up your disaster planning 20 More Insights • • Use the 11 Risk Factors as a checklist for risk Use assessments assessments Compare to Boehm and Ross’s list (1989) 21 The Boehm + Ross Top 10 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. Employee Shortfalls Unrealistic schedules and budgets Developing the wrong software functions Developing the wrong user interface Gold plating of requirements Continuing stream of requ’s changes Externally-furnished component shortfalls Shortfalls in externally-performed tasks Real-time performance shortfalls Straining computer science capabilities 22 The Boehm + Ross Top 10 (with corresponding Keil item#/quad in red) 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. Employee Shortfalls (#7, #10-Q3) Unrealistic schedules and budgets (Q3) Unrealistic (Q3) Developing the wrong software functions (#3-Q2) Developing (#3-Q2) Developing the wrong user interface (#3-Q2) Developing (#3-Q2) Gold plating of requirements (Q2) Gold (Q2) Continuing stream of requ’s changes (#6, 8-Q2, Q4) Continuing (#6, Externally-furnished component shortfalls (Q4) Externally-furnished (Q4) Shortfalls in externally-performed tasks (Q4) Shortfalls (Q4) Real-time performance shortfalls (Q3) Real-time (Q3) Straining computer science capabilities (~#9-Q3) Straining (~#9-Q3) 23 Project Risk Survey Study • Until the Survey Study, the 4 Quad framework Until was untested, leaving open the questions: was – – • Do the risks in these quadrants matter? (i.e., do Do they affect project outcomes (e.g., product, process outcomes like schedule completion)? outcomes Do the risks in one quadrant interact with or offset Do risks in any other quadrant? risks The Survey Study Methodology – – – 507 software project mgrs—members of Project 507 Management Institute (PMI) Management Mapped the 53 factors against the 4 Quadrants Asked mgr to state the extent to which each was a Asked factor in a specific project factor Wallace and Keil, 2004 24 Project Risk Survey Study: Findings Predicting On Time, In Budget Completion • Q2 (scope/requs. risk) completed on time, in bgt Q2 • Q3 (execution risk) completed on time, in bgt Q3 • Q3 is twice as strong a factor as Q2 • Q1, Q4 did not predict this outcome Q1, • No Q2/Q3 interaction Hence: • Projects with unstable scope/requs exceed bgt • Projects with little IT control (Q1-customer mandate Projects risks, Q4-environmental risks) may not matter as much to budgeted/scheduled completion much 25 Project Risk Survey Study: Findings Predicting Product Outcome Success • • • • • Q1 (Cust. mandate risk) Product Success Q1 Q2 (scope/requs. risk) Product Success Q2 Q3 (execution risk) Product Success Q3 Q4 did not predict Q4 Q1/Q3 and Q2/Q3 interactions 26 Project Risk Survey Study: Findings Predicting Product Success: Interactions • Q1/Q2/Q3 interactions: – – – – – – When execution risk (Q3) is low, high levels of customer When mandate (Q1) or scope-requ’s (Q2) risk barely affect product success product When Q3 is high, effects of Q1 +/or Q2 are higher That is, with high Q3 risk must try to lower risks of Q1 +/or That Q2; but w/low Q3 risk, Q1/2 no worry Q2; Hence, focus on minimizing Q3 risk Makes sense, because Q3 involves risks of team experience, Makes project complexity, proj plng/control; hence focusing on them can neutralize risks of scope creep, volatile requ’s, and customer mandate customer Also: low Q2 minimal effect of Q3 on product outcome; minimal high Q2 up to 3.5 the effect of Q3 than when Q2 is low high 27 Project Risk Survey Study: Findings Study Conclusions • Good news: Process outcomes depend on Q2/Q3, both of Good which are controllable which Not as good news: Must manage Q1/Q2/Q3 to influence Not Product outcomes Product For both outcomes, Q3 (Execution) is the most important For factor factor Good project execution can compensate for customer Good mandate and scope risks mandate Good scope can make execution problems less important Project execution matters most of all. Hence, seek to: • • • • • – – – Find experienced team members who work well together Manage project complexity Use good project planning and control methods 28 Execution (Q3) Factors: A Selection • • • • • • • • • • • • • • • Inadequately trained development team members Team member lack of commitment to the project Conflicts among development team members Frequent turnover within the project team Project involves the use of new technology Highly complex task being automated Project affects large number of user departments/units One of the largest projects attempted by the organization Immature technology Lack of an effective project mgmt methodology Inadequate estimation of project schedule Project progress not monitored closely enough Project milestones not clearly defined Ineffective project manager Ineffective communication 29 ...
View Full Document

This note was uploaded on 11/17/2011 for the course ITM 311 taught by Professor Harrisonmcknight during the Fall '10 term at Michigan State University.

Ask a homework question - tutors are online