© McGraw-Hill/Irwin 2004

Information Systems Project Management—David Olson5-1

© McGraw-Hill/Irwin 2004

Information Systems Project Management—David Olson5-2

Chapter 5: Requirements Analysis

Elicitation from users

Project risk

Outsourcing

© McGraw-Hill/Irwin 2004

Information Systems Project Management—David Olson5-3

definition

• 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

© McGraw-Hill/Irwin 2004

Information Systems Project Management—David Olson5-4

User Requirement Elicitation

• Meetings

• Interviews

• Brainstorming

• Structured methods– Nominal Group Technique– Delphi

© McGraw-Hill/Irwin 2004

Information Systems Project Management—David Olson5-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

© McGraw-Hill/Irwin 2004

Information Systems Project Management—David Olson5-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

© McGraw-Hill/Irwin 2004

Information Systems Project Management—David Olson5-7

Group Support Systems

• Facilitate groups facing unstructured decisions

• Easy to use

• Record points

• discourage conflict, miscommunication, groupthink

• aid negotiation, compromise

© McGraw-Hill/Irwin 2004

Information Systems Project Management—David Olson5-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 TeamFocus took 35 days (15

electronic meetings) - normally 1 year

© McGraw-Hill/Irwin 2004

Information Systems Project Management—David Olson5-9

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

© McGraw-Hill/Irwin 2004

Information Systems Project Management—David Olson5-10

Nemawashi Approach

• Japanese• Coordinator visits group participants

1. Privately identifies their needs individually2. Generates solution acceptable to all3. Selects plan most likely to be accepted4. Negotiates and persuades5. Document circulated

• Once agreement reached, hold meeting

© McGraw-Hill/Irwin 2004

Information Systems Project Management—David Olson5-11

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

© McGraw-Hill/Irwin 2004

Information Systems Project Management—David Olson5-12

Risk Identification Methods

• Brainstorming

• Nominal Group Technique– structured: initial ideas recorded, discuss,

evaluate

• Delphi– anonymous input, shared evaluation, cycle

© McGraw-Hill/Irwin 2004

Information Systems Project Management—David Olson5-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)

© McGraw-Hill/Irwin 2004

Information Systems Project Management—David Olson5-14

IRS

• Computer systems developed in 1960s• 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

© McGraw-Hill/Irwin 2004

Information Systems Project Management—David Olson5-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

© McGraw-Hill/Irwin 2004

Information Systems Project Management—David Olson5-16

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

© McGraw-Hill/Irwin 2004

Information Systems Project Management—David Olson5-17

the Systems Failure Method

Learning from Failure: The Systems Approach

Joyce Fortune & Geoff Peters, Wiley, 1995

© McGraw-Hill/Irwin 2004

Information Systems Project Management—David Olson5-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 system installations, <3% had disaster recovery plans

© McGraw-Hill/Irwin 2004

Information Systems Project Management—David Olson5-19

Failures in Planning

• negative disasters: decision culminating in physical result, later substantially modified, reversed or abandoned after heavy resource commitment– Edsel; FoxMeyer 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

© McGraw-Hill/Irwin 2004

Information Systems Project Management—David Olson5-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)

© McGraw-Hill/Irwin 2004

Information Systems Project Management—David Olson5-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

© McGraw-Hill/Irwin 2004

Information Systems Project Management—David Olson5-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

© McGraw-Hill/Irwin 2004

Information Systems Project Management—David Olson5-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 & environmentinfluence diagrams to explore relationships

© McGraw-Hill/Irwin 2004

Information Systems Project Management—David Olson5-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

© McGraw-Hill/Irwin 2004

Information Systems Project Management—David Olson5-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

© McGraw-Hill/Irwin 2004

Information Systems Project Management—David Olson5-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

© McGraw-Hill/Irwin 2004

Information Systems Project Management—David Olson5-27

Communication

• failure often due to link missing, inadequate, or not used

• vicious circle– information overload– restriction of communication– distortion & omission– more messages

© McGraw-Hill/Irwin 2004

Information Systems Project Management—David Olson5-28

Human Aspects

• who is responsible for what• what is appropriate conduct• what information is communicable• what is considered fixed & unchangeable• how problems are to be solved

© McGraw-Hill/Irwin 2004

Information Systems Project Management—David Olson5-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