Скачать презентацию Information Systems Project Management David Olson 5 -1 Скачать презентацию Information Systems Project Management David Olson 5 -1

46bda792d1aa37925f9f2ed8cd31eda6.ppt

  • Количество слайдов: 29

Information Systems Project Management—David Olson 5 -1 © Mc. Graw-Hill/Irwin 2004 Information Systems Project Management—David Olson 5 -1 © Mc. Graw-Hill/Irwin 2004

Information Systems Project Management—David Olson 5 -2 Chapter 5: Requirements Analysis Elicitation from users Information Systems Project Management—David Olson 5 -2 Chapter 5: Requirements Analysis Elicitation from users Project risk Outsourcing © Mc. Graw-Hill/Irwin 2004

Information Systems Project Management—David Olson definition 5 -3 • Determine resources needed to build Information Systems Project Management—David Olson definition 5 -3 • Determine resources needed to build project – specific identification of what system is to do – expand upon proposal specifications • Business requirements – conceptual design – logical design – validation – formal specification © Mc. Graw-Hill/Irwin 2004

Information Systems Project Management—David Olson User Requirement Elicitation • • Meetings Interviews Brainstorming Structured Information Systems Project Management—David Olson User Requirement Elicitation • • Meetings Interviews Brainstorming Structured methods – Nominal Group Technique – Delphi © Mc. Graw-Hill/Irwin 2004 5 -4

Information Systems Project Management—David Olson 5 -5 Caterpillar: Extranet • Important to get product Information Systems Project Management—David Olson 5 -5 Caterpillar: Extranet • Important to get product modifications to customers quickly • EXTRANET: linked 18 outside organizations – semi-private access – customers can track part delivery status – shortened delivery cycle (place order quicker) • was 50 days, became 5 © Mc. Graw-Hill/Irwin 2004

Information Systems Project Management—David Olson 5 -6 Objectives Meeting • • • All relevant Information Systems Project Management—David Olson 5 -6 Objectives Meeting • • • All relevant document read beforehand Each team member produces keyword list List of agreed keywords produced Agreed keywords combined - deliverables NEED: whiteboard to focus attention NEED: sufficient time © Mc. Graw-Hill/Irwin 2004

Information Systems Project Management—David Olson Group Support Systems • Facilitate groups facing unstructured decisions Information Systems Project Management—David Olson Group Support Systems • Facilitate groups facing unstructured decisions • Easy to use • Record points • discourage conflict, miscommunication, groupthink • aid negotiation, compromise © Mc. Graw-Hill/Irwin 2004 5 -7

Information Systems Project Management—David Olson 5 -8 Group Support Systems FORTUNE magazine 23 March Information Systems Project Management—David Olson 5 -8 Group Support Systems FORTUNE magazine 23 March 1992 • Managers spend 30% to 70% of their time in meetings • GSSs provide a way for PCs to pay off • BOEING - cut team project times an average of 91% • Using Team. Focus took 35 days (15 electronic meetings) - normally 1 year © Mc. Graw-Hill/Irwin 2004

Information Systems Project Management—David Olson Group Support System Products PC Magazine 14 June 1994 Information Systems Project Management—David Olson Group Support System Products PC Magazine 14 June 1994 • • • E-Mail Electronic Bulletin Board Products Conferencing Software Whiteboard Software Desktop Videoconferencing Structured Group Discussion Meeting Room Software © Mc. Graw-Hill/Irwin 2004 5 -9

Information Systems Project Management—David Olson 5 -10 Nemawashi Approach • • Japanese Coordinator visits Information Systems Project Management—David Olson 5 -10 Nemawashi Approach • • Japanese Coordinator visits group participants 1. 2. 3. 4. 5. • Privately identifies their needs individually Generates solution acceptable to all Selects plan most likely to be accepted Negotiates and persuades Document circulated Once agreement reached, hold meeting © Mc. Graw-Hill/Irwin 2004

Information Systems Project Management—David Olson Risk Analysis • Risk identification - identify, rank • Information Systems Project Management—David Olson Risk Analysis • Risk identification - identify, rank • Risk analysis – convert data into understanding • Risk control - measure, implement control • Risk reporting NOT step-by-step: continuous process © Mc. Graw-Hill/Irwin 2004 5 -11

Information Systems Project Management—David Olson Risk Identification Methods • Brainstorming • Nominal Group Technique Information Systems Project Management—David Olson Risk Identification Methods • Brainstorming • Nominal Group Technique – structured: initial ideas recorded, discuss, evaluate • Delphi – anonymous input, shared evaluation, cycle © Mc. Graw-Hill/Irwin 2004 5 -12

Information Systems Project Management—David Olson 5 -13 State of Washington • 1992 - To Information Systems Project Management—David Olson 5 -13 State of Washington • 1992 - To unify driver’s license, vehicle registration databases - $16 million • residents fill out only one change-of-address form – initial estimate of required scope too low – new laws • spent $40 million before cancelled (would have taken an additional $27. 5 million) © Mc. Graw-Hill/Irwin 2004

Information Systems Project Management—David Olson 5 -14 IRS • Computer systems developed in 1960 Information Systems Project Management—David Olson 5 -14 IRS • Computer systems developed in 1960 s • spend $hundreds of millions annually – upgrade efforts, about 50 projects – current modernization program $8 billion – lose up to $50 billion/year in lost revenue • 2000 staff on upgrade, 10 outside contractors for every staff • outsourced © Mc. Graw-Hill/Irwin 2004

Information Systems Project Management—David Olson 5 -15 Star*Doc Oz (1994) • joint venture, 2 Information Systems Project Management—David Olson 5 -15 Star*Doc Oz (1994) • joint venture, 2 international air freight firms – US, Japan • reduce data redundency, better tracking • 18 month project, $3. 3 million – specifications for packaging only – users not informed until system installed – management passive • massive failure © Mc. Graw-Hill/Irwin 2004

Information Systems Project Management—David Olson Features Found in Successful Projects Ingram (1994) • • Information Systems Project Management—David Olson Features Found in Successful Projects Ingram (1994) • • No loss to third parties Objectives agreed upon early Needed skills available Objectives clear throughout project No loss to platform issues Technical approach sound Software issues top priority © Mc. Graw-Hill/Irwin 2004 5 -16

Information Systems Project Management—David Olson 5 -17 the Systems Failure Method Learning from Failure: Information Systems Project Management—David Olson 5 -17 the Systems Failure Method Learning from Failure: The Systems Approach Joyce Fortune & Geoff Peters, Wiley, 1995 © Mc. Graw-Hill/Irwin 2004

Information Systems Project Management—David Olson 5 -18 Systems Failure Method • systematic method for Information Systems Project Management—David Olson 5 -18 Systems Failure Method • systematic method for analysis of failure • successfully applied - wide variety of situations • by reviewing past failures, avoid future failure • as organizations rely more on computers, there is a corresponding increase in significant business interruptions • yet of 300, 000 large & mid-sized computer © Mc. Graw-Hill/Irwin 2004 system installations, <3% had disaster

Information Systems Project Management—David Olson 5 -19 Failures in Planning • negative disasters: decision Information Systems Project Management—David Olson 5 -19 Failures in Planning • negative disasters: decision culminating in physical result, later substantially modified, reversed or abandoned after heavy resource commitment – Edsel; Fox. Meyer ERP • positive disasters: decision culminating in physical results implemented despite heavy criticism, subsequently felt by many informed people to have been a mistake – Anglo-French SST; BART in San Francisco © Mc. Graw-Hill/Irwin 2004

Information Systems Project Management—David Olson 5 -20 Failures of Projects • information technology • Information Systems Project Management—David Olson 5 -20 Failures of Projects • information technology • 1992 - London Ambulance Service – 1. 5 million pound system on line 26 Oct 1992 – immediately lost ambulances – <20% of dispatched ambulances reached destinations within 15 minutes of summons – (before system, 65% met 15 minute standard) © Mc. Graw-Hill/Irwin 2004

Information Systems Project Management—David Olson 5 -21 Failures of Projects • • Some never Information Systems Project Management—David Olson 5 -21 Failures of Projects • • Some never work others over budget, very late, or both others perform less than design others meet design specifications, but maintenance & enhancement nightmares © Mc. Graw-Hill/Irwin 2004

Information Systems Project Management—David Olson 5 -22 Systems Failure Method • model • manipulate Information Systems Project Management—David Olson 5 -22 Systems Failure Method • model • manipulate model to better understand system • compare planned system with – robust system capable of working without failure – past failed systems • GOAL: systematic interpretation of failure leading to corrective action © Mc. Graw-Hill/Irwin 2004

Information Systems Project Management—David Olson 5 -23 Modeling Systems name & define system; describe Information Systems Project Management—David Olson 5 -23 Modeling Systems name & define system; describe components; describe relationships; identify wider system; describe inputs & outputs; identify system variables; establish structural relationships that describe system behavior tools: systems diagrams (input-output) systems maps snapshot of system & environment influence diagrams to explore relationships © Mc. Graw-Hill/Irwin 2004

Information Systems Project Management—David Olson 5 -24 Comparison • formal system model – compare Information Systems Project Management—David Olson 5 -24 Comparison • formal system model – compare what you think happened with model of system • formal system – – decision-making subsystem performance-monitoring subsystem task performing subsystems continuous purpose, connectivity of components, environment & boundaries, resources © Mc. Graw-Hill/Irwin 2004

Information Systems Project Management—David Olson 5 -25 common results failure commonly a result of Information Systems Project Management—David Olson 5 -25 common results failure commonly a result of • organizational structure deficiencies – lack of performance-measuring, control • no clear statements of purpose • subsystem deficiencies • lack of effective communication between subsystems • inadequate design • insufficient consideration of environment; insufficient resources • imbalance of resources production quantity; test quality © Mc. Graw-Hill/Irwin 2004

Information Systems Project Management—David Olson 5 -26 Control • action to reach or maintain Information Systems Project Management—David Olson 5 -26 Control • action to reach or maintain desired state • classical feedback control - if output doesn’t match target, adjust • modern feedback control - if output bad, model output & effects of changes • feedforward control - predict outcome before production • common problem - misreading output © Mc. Graw-Hill/Irwin 2004

Information Systems Project Management—David Olson 5 -27 Communication • failure often due to link Information Systems Project Management—David Olson 5 -27 Communication • failure often due to link missing, inadequate, or not used • vicious circle – information overload – restriction of communication – distortion & omission – more messages © Mc. Graw-Hill/Irwin 2004

Information Systems Project Management—David Olson 5 -28 Human Aspects • • who is responsible Information Systems Project Management—David Olson 5 -28 Human Aspects • • who is responsible for what is appropriate conduct what information is communicable what is considered fixed & unchangeable • how problems are to be solved © Mc. Graw-Hill/Irwin 2004

Information Systems Project Management—David Olson 5 -29 Summary • Requirements analysis needed to identify Information Systems Project Management—David Olson 5 -29 Summary • Requirements analysis needed to identify what system is to do – Functionality best obtained from sponsor – Technical requirements best from IT • Group systems can aid reaching consensus – Nemawashi approach one alternative – Brainstorming another – Delphi yet another • Systems failure approach a systematic way to deal with project complexity and risk © Mc. Graw-Hill/Irwin 2004