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
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
© McGraw-Hill/Irwin 2004
Information Systems Project Management—David Olson
User Requirement
Elicitation
•
•
•
•
Meetings
Interviews
Brainstorming
Structured methods
– Nominal Group Technique
– Delphi
© McGraw-Hill/Irwin 2004
5-4
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
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
5-9
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
© McGraw-Hill/Irwin 2004
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
© McGraw-Hill/Irwin 2004
5-11
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
© McGraw-Hill/Irwin 2004
5-12
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
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
5-16
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
• yet of 300,000 large & mid-sized computer system
installations, <3% had disaster recovery plans
© 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
– Anglo-French SST; BART in San Francisco
© 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
influence diagrams
to explore relationships
© 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 quantity; test quality
© McGraw-Hill/Irwin 2004
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
© 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