Information Systems Project Management—David Olson

5-1

© McGraw-Hill/Irwin 2004
Information Systems Project Management—David Olson
5-2

Chapter 5: Requirements
Analysis
Elicitation from users
Project risk
Outsourcing

© McGraw-Hill/Irwin 2004
Information Systems Project Management—David Olson
5-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 Olson
5-4

User Requirement
Elicitation
• Meetings
• Interviews
• Brainstorming
• Structured methods
– Nominal Group Technique
– Delphi

© McGraw-Hill/Irwin 2004
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

© McGraw-Hill/Irwin 2004
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

© McGraw-Hill/Irwin 2004
Information Systems Project Management—David Olson
5-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 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 TeamFocus took 35 days (15
electronic meetings) - normally 1 year

© McGraw-Hill/Irwin 2004
Information Systems Project Management—David Olson
5-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 Olson
5-10

Nemawashi Approach

• Japanese
• Coordinator visits group participants
1. Privately identifies their needs individually
2. Generates solution acceptable to all
3. Selects plan most likely to be accepted
4. Negotiates and persuades
5. Document circulated
• Once agreement reached, hold meeting

© McGraw-Hill/Irwin 2004
Information Systems Project Management—David Olson
5-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 Olson
5-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 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)

© McGraw-Hill/Irwin 2004
Information Systems Project Management—David Olson
5-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 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

© McGraw-Hill/Irwin 2004
Information Systems Project Management—David Olson
5-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 Olson
5-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 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
McGraw-Hill/Irwin 2004
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; FoxMeyer ERP
• positive disasters: decision
culminating in physical results
implemented despite heavy criticism,
subsequently felt by many informed
people to have been a mistake
© McGraw-Hill/Irwin 2004
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)

© McGraw-Hill/Irwin 2004
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

© McGraw-Hill/Irwin 2004
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
© McGraw-Hill/Irwin 2004
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 © McGraw-Hill/Irwin 2004
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

© McGraw-Hill/Irwin 2004
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
McGraw-Hill/Irwin 2004 quantity; test
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
© McGraw-Hill/Irwin 2004
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

© McGraw-Hill/Irwin 2004
Information Systems Project Management—David Olson
5-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 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
© McGraw-Hill/Irwin 2004