Problem Statements

1
Problem Statements

• Lecture 3
• Spring 2004

2
Leonardo Da Vinci

• Nature is extremely efficient, frugal. She has
  no effect without cause . . .
• no invention without necessity.

3
Executive Summary

• Everybody has a solution
• Nobody knows the problem

4
Managers

• The job of the manager is to fire himself /
  herself

• Managers create order out of chaos
• When successful, they will fire themselves
• You will never be promoted, unless you have
  trained your replacement
• Crave chaos, seek it, solve it, move on . . .
• Programmers become project managers
• Project managers become change managers
• Change managers become . . . ETC.

5
The Project Team Process
ORDER
CHAOS
6
The Software Crisis

• The Project will be challenged by
• The complexity of the inputs (environmental-,
  group-, and individual-level factors)
• The team dynamics (patterns of interaction,
  activity, and sentiment, including informal
  cliques, norms, unofficial practices Norming,
  Storming, Forming)
• Unexpected Changes!!
• Miscommunication at the Hand-offs

7
Systems Development Life Cycle
Hand Offs
8
(No Transcript)
9
(No Transcript)
10
(No Transcript)
11
(No Transcript)
12
(No Transcript)
13
(No Transcript)
14
Moral of the Story

• Everybody has a solution.
• Nobody knows what the problem is.

15
How to Avoid The Software Crisis

• Better Communication at the Hand offs
• OO Paradigm
• Focus on the PROBLEM not the SOLUTION
• Example the 2cm X 2cm paper request
• Business Analysis Planning Phase
• Systems Analysis Analysis Phase

16
OO Paradigm

• Closes the communication gap between our view
  of the system and its implementation to minimize
  analysis and design errors
• Makes reuse possible so that system components
  can evolve toward a defect-free state
• Fosters a prototyping life-cycle which increases
  the interaction between users and analyzers,
  designers, and implementers and decreases risk

17
Communication Gaps

• The object-oriented approach provides a closer
  match between our shared perceptions of reality
  and the languages and tools of analysis, design,
  and implementation.

STRUCTURED Process-oriented
Analysis/Logical Design
Physical Design / Implementation
Planning
OBJECT-ORIENTED
Planning
Analysis/Logical Design
Physical Design / Implementation
18
Business Analysis

• The Funnel
• Even though the reader is your client, a good
  Business Profile shows that you understand the
  client, his/her business, and ALL his/her
  critical business problems
• Clearly separating fact from opinion, clearly
  separating problem statement from solution, aids
  communication and inspires trust.
• Thus the importance of the Business Case at the
  bottom of the funnel.

19
Good Problem Statements

• Statement of the what is affecting the business,
  not an opinion on how to solve it.
• Diagnosis, YES
• Prescription, NO
• Good problem statements
• Our main problem here at X is that since Walmart
  moved in our sales are down and could continue to
  slide.
• Our biggest problem here at Y is that we have
  too few repeat customers.

20
Bad Problem Statements

• Since Walmart moved in our sales have been down
  and could continue to slide. The problem here at
  X is we dont know how to do marketing.
• We have too few repeat customers. The problem
  here at Y is we have no way of knowing if
  customers are dissatisfied. The problem is we
  never survey them.

21
Separating Good from Bad

• Bad -- OPINION
• . . . The problem here at X is we dont know
  how to do marketing.
• . . . The problem here at Y is we have no way
  of knowing if customers are dissatisfied the
  problem is we never survey them.

• Good -- FACT
• Our main problem here at X is that since Walmart
  moved in our sales are down and could continue to
  slide.
• Our biggest problem here at Y is that we have
  too few repeat customers.

22
Toyota Processing System (TPS)

• TPS is an integrated collection of business
  best practices.
• JIT, Zero-Inventory, and several others
• The Five WHYs is one of these other best
  practices.
• The reason The Five Whys is so successful, is
  that it neatly separates
• fact from opinion,
• diagnosis from prescription,
• problem statement from solution.

23
WHY?
HOW?
Cause
Effect
Root Cause
24
A Word of Caution

• It is easy to forget WHY we do Systems Analysis
• Systems Analysis is the most important task in
  the SDLC only because Business Analysis isnt
  typically part of the SDLC
• Business Analysis is more important than Systems
  Analysis
• Industry Analysis is more important than Business
  Analysis
• Societal Analysis is more important than Industry
  Analysis
• It is very easy to jump the gun and begin on the
  HOW too early Why Techies Crash

25
Business Analysis
WHY?
HOW?
SDLC
New Business Process
Business Problem
26
System Analysis
Just a small part of the puzzle
WHY?
HOW?
Use Cases
Class Model
Business Vision
Process-oriented verbs
Object-oriented nouns
27
The Bottom Line

• WHY before HOW
• Dont do anything unless you know WHY you are
  doing it.
• When delegating the HOW part, include the WHY in
  your communications!!
• Write good problem statements
• The solutions are dealt with after the hand-off

28
(No Transcript)
29
(No Transcript)
30
(No Transcript)
31
Executive Summary

• Everybody has a solution
• Nobody knows the problem

32
An Important Announcement

• Phase Deliverables

33
PHASE Deliverables

• The PHASE Deliverables for this course are three
• Phase I Planning
• Phase II Analysis
• Phase III Design (includes Code)

34
REGULAR Deliverables

• The REGULAR Deliverables for this course are
  nine, see the Class Schedule
• Deliverable I The Team
• Deliverable II Business Analysis
• Deliverable III Analysis Plan
• Deliverable IV Requirements
• Deliverable V Models
• Deliverable VI User Interface
• Deliverable VII System Architecture
• Deliverable VIII Project Assessment
• Deliverable IX System Proposal

35
PHASE vs. REGULAR

• The Regular Deliverables make up the Phase
  Deliverables
• Phase I Planning
• Deliverable I The Team
• Deliverable II Business Analysis
• Phase II Analysis
• Deliverable III Analysis Plan
• Deliverable IV Requirements
• Deliverable V Models
• Phase III Design (and Code)
• Deliverable VI User Interface
• Deliverable VII System Architecture
• Deliverable VIII Project Assessment
• Deliverable IX System Proposal (includes The
  Code)

36
PHASE vs. REGULAR

• The PHASE Deliverables go to the client and/or
  the champion for payment
• The REGULAR Deliverables go to the instructor for
  feedback

37
Money
Project Team
Regular Deliverables
Phase Deliverables
Wisdom
Instructor
Client/Champion
38
PHASE vs. REGULAR

• After the instructor gives you feedback on the
  Regular Deliverables, you will use them to write
  the Phase Deliverables
• In your workplan, make sure you schedule adequate
  Phase Deliverable deadlines

39
Add-ons

• You will bill the client with each Phase
  Deliverable.
• You will survey the champion with each Phase
  Deliverable.

40
Leonardo Da Vinci

• Nature is extremely efficient, frugal. She has
  no effect without cause . . .
• no invention without necessity.