Information Technology Project Management

1. Information Technology Project Management Managing IT Project Risk

2. Outline • Defining IT Failure • Defining Risk and Risk Management • Risk Management Cycle • Risk Identification • Risk Analysis • Risk Handling • Risk Monitoring

3. What do we mean by failure? • Lyytinen (1988) distinguishes between “development failure” and “use failure” • A more detailed categorization of IT failure would include: • system grossly exceeds original budget • system grossly exceeds original schedule • system never functions technically • system functions, but quality is so poor that, for all practical purposes, system is not usable • system functions but is not used--users reject the system because it is cumbersome to use or because they have no incentive to use it • system functions, but completely lacks originally promised functionality or fails to fit the task it was designed to support “Runaway Systems”

4. Total Failure Total Success Stakeholder A Stakeholder B Some Observations about Success/Failure • Success/Failure is often viewed as a binary classification • Success/Failure should be viewed along a continuum • Success is in the eyes of the beholder

5. Why IT Projects Fail:The Traditional Wisdom • Systems are specified and initiated by IS without sufficient input from the user(s) • Inadequate estimates of development cost and time • Lines of responsibility not clearly specified • User acceptance test delayed until the project is completed • Inadequate system testing • Implementation difficulties

6. Warning Signs(Keider, 1984) • Inadequate status reporting • Isolation • Lack of schedule changes • Overemphasis on how a system will be built • Premature programming • Staff reassignments

7. Defining Risk and Risk Management • A project risk is a potential problem that would be detrimental to a project’s success should it materialize • Risk management is the identification and response to potential problems with sufficient lead time to avoid a crisis

8. Risk Management Cycle Risk Monitoring Risk Identification Risk Analysis Risk Handling

9. Risk Identification • Business risk • Market risk • Shifts in business strategy or senior management • Technical risk • Design and development problems • Testing and maintenance problems • Technical uncertainty • Project risk • Budget • Schedule • Personnel • Requirements problems

10. Tools for Identifying Risks • Checklists (e.g., Boehm’s top ten risk list) • Frameworks (e.g., McFarlan’s framework) • Questionnaires (e.g., Barki, Rivard, and Talbot survey)

11. Risk Factors: What the Literature Says . . . • Technological newness • Application size • Application complexity • Task complexity • Project team expertise • Organizational environment • Magnitude of potential loss Barki, Rivard, and Talbot, 1993

12. What Project Managers Say

13. Risk Analysis • For each identified risk, evaluate the probability of occurrence • For each identified risk evaluate the impact if the risk should occur • Prioritize your risk handling effort based on both probability and impact

14. Assigning Probabilities • Here we ask: “What is the likelihood that something will go wrong?” • Establish a scale that reflects the perceived likelihood of a risk • Probability scales are commonly used • Can be qualitative or quantitative • e.g. highly improbable, improbably, moderate, likely, highly likely • e.g. 0-100% probability

15. Example Scale for Evaluation of Probability

16. Assessing Impact • Here we ask: “What is the damage or impact if something does go wrong?” • Three factors can be used to assess impact • Nature of the risk (i.e. the problems that are likely if it occurs) • Scope of the risk (i.e. how serious is the risk and how much of the project will be affected?) • Timing of the risk (i.e. when and for how long will the impact be felt)

17. Example Scale for Evaluation of Impact

18. Risk Matrix Example

19. Risk Handling • Risk prevention • Develop options to reduce the potential of the problem occurring • Risk avoidance • Accepting a lower risk (another solution) to avoid a high risk • Risk remedy • Monitoring risk status and developing solutions to reduce effect when risk becomes a problem • Risk assumption • Decision to accept the risk should it occur • Risk reduction • Obtaining additional information that will reduce risk (e.g., prototyping, incremental development)

20. Risk Monitoring • Should be done periodically • (e.g., when certain milestones are reached, at the end of project phases, at steering committee meetings, etc.) • Useful to regularly assess and update project risk exposure • Senior management should be involved in monitoring and should be aware of exposures • Listen to the project group

21. Region in which project termination will occur Projected Schedule Overrun Referent level for cost/schedule overruns Projected Cost Overrun Establishing Risk Referent Levels • Risk referent levels can be set to define regions of acceptable and unacceptable risks • Three typical risk referent levels • Cost overrun • Schedule slippage • Performance criteria • Example