WrapUp

1
Topics
1
Introductions Scenario Introduction Overview
Step 1 Decide to Change Step 2 Get
Sponsorship Step 3 Where Are We? Step 4 Plan
the Change Step 5 Implement the
Change 5a Implement the ChangeTraining 5b
Implement the ChangeQA Step 6 Measure the
Change Training Wrap-Up
Topic 1 Topic 2 Topic 3 Topic 4 Topic
5 Topic 6 Topic 7 Topic 8 Topic 9 Topic
10 Topic 11
2
3
4
5
6
7
8
9
10
11
2
Topic Objectives

• What is business process reengineering?
• Is a radical redesign of business right for your
  State?
• Theory of constraints (TOC)
• Where are business processes breaking down?
• Using use cases to describe the process
• Using focus groups to describe the process

3
Process Improvement Model
1. Decide toChange
4
Business Process Reengineering?

• Need to find where you need to improve
• Where is the current process most inefficient?
• Where is the most pain?

5
Radical Redesign

• Radical redesign will break the organization
• Find the most pain, fix it first
• Evolve to the to be
• Will take multiple revolutions around the Process
  Improvement circle

6
Theory of Constraints

• TOC
• Optimize the flow through the constraint, even if
  it means suboptimizing other processes
• Examples
• An individual that must approve all actions,
  and this individual keeps their inbox full
• Using an incorrect measure of success
• In The Goal he refers to measuring pounds as the
  primary measure of a steel plant. But it may not
  be the correct measure for thin steel.

Source Goldratt M. Eliyahu, and Cox, Jeff. The
Goal. Great Barrington, MA The North River Press
Publishing Corporation, 2004.
7
TOC In 100 Words or Less

• Thinking process, to gain cause-effect insight
  about a system
• Designed to identify constraints within the
  system
• Constraints are critical leverage points that
  determine the potential output of a system
• Limiting it from moving toward or achieving its
  goal
• Constraints are resilient
• Reinforced by system feedback

8
TOC In 100 Words or Less (cont.)

• The practical results of Eli Goldratt's work on
  decision making in systems with constraints
• Resources
• Capacities
• Demand
• First described in The Goal A Process of Ongoing
  Improvement
• Published in 1984
• Now well-established in many organizations
• Continuous improvement
• Quality management

Source Goldratt, Eli. The Goal A Process of
Ongoing Improvement. Great Barrington, MA The
North River Press Publishing Corporation, 2004.
9
TOC Application

• Production management
• Solve problems of bottlenecks, scheduling, and
  inventory reduction
• Throughput analysis
• Shift from local, cost-based decision making to
  decisions based on global system impact
• TOC logical processes
• Identify organizations limiting factors
• Develop a solution and solution implementation

10
Use Cases

• A collection of possible sequences of
  interactions between a system and its external
  actors in relationship to a particular goal or
  outcome
• Capture user requirements for a system by
  describing how a system will be used and for what
  purpose in a way that the end user can understand
• Usually written in simple language, without
  technical jargon so that they can be easily
  understood by all participants in the process

11
Use Case Goals and Roles

• A complete set of use cases specifies all the
  different ways to use the system and defines all
  behavior required of the system
• Goals
• Design system from users perspective
• Communicate system behavior in terms recognized
  by the user
• List all externally visible behaviors
• Uses
• Communication with stakeholder
• Analysis
• Estimation

12
Use Case Basic Components

• Actors Roles who perform the use case, not
  people or things the same person can be
  different actors
• Actions Complete steps involved in the task
  (e.g., use case), usually initiated by an actor
• Examples Read, create, destroy, modify, or store
  
• Preconditions (e.g., conditions like approvals
  and required information that need to exist
  before use case execution)
• Postconditions (e.g., results/conditions that
  exist after use case execution)

13
Use Case Presentation Methods
Schedule a Meeting Use Case Diagram Visual
Relationships

• Use Case Diagram
• Text
• Numbered Steps
• Table Form
• Message Flow Diagram

Text Example "Schedule a meeting To schedule
a meeting, the secretary calls all of
the administrators who manage a room to find a
room that is open for the meeting..."
Numbered Steps Example Schedule a meeting 1.
Secretary chooses a meeting time. 2. Secretary
calls room admins. to find an available room. 3.
After finding a room, secretary calls each
attendee. 4. ...
14
Benefits of Use Cases

• Help define user requirements
• Identify and document current methods, systems,
  and stakeholders
• Drive detailed application analysis and design
• Develop scripts for testing
• Suggest prototyping activity
• Clarify architecture requirements
• Highlight risks and needs for risk management

15
Potential Use Case Drawbacks

• Might be incomplete
• Each case may not describe enough detail of use
• Not enough uses cases may miss entire areas of
  functionality
• Might be inaccurate
• Might not have been reviewed
• Might not have been updated when requirements
  changed
• Might be ambiguous/unclear
• Will not find many bugs

16
Use Case Considerations

• Each use case is a complete course of events in
  the system from a users perspective
• Each use case is independent of the others
• Use cases are usually targeted for fairly major
  tasks they do not need to be written for every
  action
• Design information is included in the use case in
  order to make it easier to discuss with the user,
  but this information is not a part of the
  requirements
• The goal is to extract the real underlying
  requirements
• Review use cases for completeness and correctness
• Conduct training in use case creation

17
When to Use Use Cases

• Model user requirements
• Model test scenarios
• User acceptance test (UAT)
• Positive business as usual functional testing
• Manual black-box
• Automated testing
• Regression testing
• Adhoc testing
• Define the to be model

18
Focus Groups

• A focus group is a group discussion
• Similar backgrounds or experiences
• Specific topic of interest
• Moderator (or group facilitator)
• Introduces topics for discussion
• Helps the group to participate
• Record keeper
• Knowledgeable about the subject
• Critical to capture and record the results
  accurately

19
Focus Group Benefits

• Information produced quickly
• Easily managed by people not trained as
  researchers
• Assumes topic is relatively simple
• May discover attitudes and opinions that might
  not be revealed in a survey questionnaire
• Usually well-accepted because it is form of
  communication found naturally
• Focus groups are fun!

20
Focus Group Limitations

• Results cannot be used to make statements about
  the wider community
• Participants often agree with responses from
  fellow group members
• Lack of a trained moderator can influence
  results
• Limited value in exploring complex issues

21
Focus Groups Lessons Learned

• You never can do too much planning for a focus
  group
• Advanced planning always pays off
• Good focus group moderators bring objectivity and
  expertise in the process to a project
• Specific product knowledge should not be an
  important criteria in selecting a moderator
• An effective moderator must be able to
• Draw people out
• Listen well
• Interpret the results of the sessions
• Communicate those results effectively

22
Focus Groups Lessons Learned (cont.)

• The moderator and the sponsor should coordinate
  their efforts
• Obtain sponsor input prior to holding the focus
  groups
• Have regular communication between the moderator
  and the sponsors at all stages of the process
• Moderator must provide a fast report turnaround
• Full report within 3 to 5 days
• Allows people who attended the sessions to
• Gain the benefit of the moderators perspective
• Identify what they do and do not agree with
• The sponsors can determine the common areas of
  agreement and disagreement

23
Focus Groups Lessons Learned (cont.)

• Sponsors should be thoroughly briefed about the
  research objectives before the sessions start
• Ensure that all the sponsors are in sync with the
  objectives and the desired output
• The most valuable service a moderator can provide
  is objective conclusions
• Without regard for what the sponsor wants to hear
• It is a mistake to try to sugarcoat conclusions

24
Summary

• Not just a big jump to improve processes
• Need to find the evolutionary path
• Document the path in a way that all the
  stakeholders can understand
• Fix the constraints in order of importance and
  availability
• Most pain
• Low-hanging fruit
• TOC can help
• How have you documented the as is model?