Goldratts Thinking Process and Systems Thinking

James R. Burns Fall 2010

THEORY OF CONSTRAINTS: GOLDRATT

1. Identify the system constraints 2. Decide how to exploit the system constraints 3. Subordinate everything else to that decision 4. Elevate the system constraints 5. When this creates new constraints, go back to step 1
5/28/2002

Reference(s)
Dettmer, H. William, Goldratts Theory of

Constraints, ASQ, 1997.

5/28/2002

THE ISSUES ARE:

What to change?

{What is the core problem?}

What to change to?

{Where to look for the breakthrough idea?}

How to effect the change?

{How to bridge from a breakthrough idea to a full solution?}

5/28/2002

Goldratts TP (Thinking Process)

An excellent methodology to facilitate

sessions during the initiation phase (definition and conceptualization stage) of a project

5/28/2002

Strategy for change

Create the tree Critique the tree

5/28/2002

Why trees??
To get a complete picture of what is going

on To model all of the causation involved To see what is related to what To identify the core problem To validate a proposed injection
5/28/2002

What to change?
Team constructs a current reality tree

(CRT) Team starts by listing all undesirable effects (UDEs) Team inter-relates these by use of a tree, called a CRT In the current reality tree, the team traces UDEs back to a core problem (CP)
5/28/2002

EXAMPLES OF UDEs
Due dates are often missed It is difficult to respond to urgent demands There is too much expediting Inventory levels are too high

There are frequent material shortages

Safety stocks are inadequate

5/28/2002

Symptoms, Root Causes & a Core Problem

Rather than reacting to symptoms, we

should be finding root causes We consider undesirable effects to be symptoms We look for a common cause that is the source for most of the undesirable effects

5/28/2002

10

A CRT for software development

Only 28% of software projects are

successfulon-time, within budget and with full functionality Software projects are always the slowest projects to be completed
TI merged two divisions of the firm.
It took 6 months to do all logistics It took 18 months to reconcile all of the software differences
5/28/2002 11

Example Current Reality Tree

Managing Software Development Projects Is rarely successful

Software Development Projects take too long

Software Development Projects cost too much

5/28/2002

Software Development Projects have quality problems

12

Software Development Projects take too long

Software Development Projects cost too much

Fixing changes takes time

There are many latebreaking changes to requirements

Fixing changes costs money

Users discover new

features they want included in the software

Users dont know what they want

Users change their minds

13

5/28/2002

Users are untrained and not sophisticated

Late in the lifecycle Users discover new

features they want included in the software

Users are untrained and not sophisticated

Project Managers do not utilize early discovery techniques with users

Project Managers Do not train and teach Users about software development

Software is of poor quality and takes Much time/money to debug

Software Project Managers do not encourage use of walkthroughs through testing

5/28/2002

Software Project Managers Are poorly trained And unaware of pitfalls in 14 Software projects

We conclude.
That the core problem is with poorly

trained software project managers

5/28/2002

15

The next construct is the Evaporating Cloud {EC}

The Evaporating Cloud is used to address

the question

What to Change to.

5/28/2002

16

Core problems are studied further by use of an evaporating cloud

Evaporating clouds

(ECs) will surface

assumptions Breaking an assumption leads to a breakthrough called an injection At this point the team is unconcerned with the practicality of the injection
5/28/2002

What is an injection?
a solution to the core problem a strategy that will mitigate all of the UDEs Injections that appear impossible to

achieve are called flying pigs

5/28/2002

Example Evaporating Cloud

Training takes much time/money, requires trainers Many well-trained Project Managers Are available now
Project Manager expertise is required now
5/28/2002

Project training is long and arduous

Instant Project Manager expertise required

19

What have we learned from the EC above?

Many expert project managers are needed

now Creating well-trained project managers takes time Instant project management expertise is required now SOLUTION: Expert system for project management
5/28/2002

20

INJECTION
Create a PM expert system

An advisory system that novice Project Managers can seek and obtain advice from.

5/28/2002

21

What to change to?

From the CRT and ECs, a Future Reality Tree

(FRT) is constructed One purpose of the Future Reality Tree is to validate that the injection will achieve the desired effects (DEs)

5/28/2002

Examples of DEs

Due dates are rarely missed Demands are met 99% of the time There is little expediting Inventory levels are low There are no material shortages Production lead times are short or satisfactory
5/28/2002

Due date perf. is high Customers rely on quick responses There is little expediting Inventory levels are reduced significantly Material is available when needed Customers rely on quick responses

Building the Future Reality Tree

Start by turning the UDEs around and

writing them with a positive tone as DEs Place DEs at the top of the limbs in the FRT At the bottom of the FRT place the injection Building the FRT is a two-phase process
Build considering only positive, ideal links, and assuming win/win strategies Add negative loops later
5/28/2002

What to change to, Contd?

The idea here is to get a picture of how an

injection (a breakthrough) might affect the overall performance of the system. The Future Reality Tree is the validation that a collection of injections will turn all of the UDEs into DEs

5/28/2002

Future Reality Tree

for our example
Managing Software Development Projects Is usually successful

Software Development Projects take reasonable lengths of time

Software Development Projects arent too costly

5/28/2002

Software Development Projects create quality products

26

Software Development Software Development Projects take reasonable Projects take too long Lengths of time

Software Development Software Development Projects arent too Projects cost too much costly

Fixing changes takes time

There Thereare aremany few latelatebreaking changes to requirements

Fixing changes costs money

Users Users discover discover no new new

features they want included in the software

Users dont know what they want

Users Userschange rarely change their their minds

27

5/28/2002

Users Users are are untrained more trained andand not sophisticated sophisticated

Late in the lifecycle Users rarely discover

features they want included in the software

Users are trained and sophisticated

Project Managers utilize early discovery techniques with users

Project Managers Do train and teach Users about software development

Software is of good quality and dubbing is inexpensive and quick

Software Project Managers encourage use of walkthroughs through testing

5/28/2002

Software Project Managers use an expert system To avoid pitfalls in 28 Software projects

Last Question.

How to cause the change?

We will use two more trees
5/28/2002 29

How to cause the change?

The prerequisite tree The transition tree These help to get buy-in These help us to develop a strategy for

achieving a flying pig (an injection that appears impossible to achieve or implement)

5/28/2002

The Prerequisite Tree

Place INJECTIONS at the top List the obstacles that are expected For each obstacle that is overcome, an intermediate objective is achieved

Each obstacle gives rise to an intermediate objective

The intermediate objectives need to be sequenced The prerequisite tree does the sequencing

5/28/2002

OBSTACLE

INTERM. OBJECTIVE

No well-defined ES Architecture There are many commerciallyavailable ES Shells

Pick an appropriate ES Architecture Select an appropriate ES Shell

5/28/2002

32

The Prerequisite Tree, Contd

Takes an impediment or obstacle approach This approach enables dissection of the

implementation task into an array of interrelated, well-defined, intermediate objectives

5/28/2002

The Prerequisite Tree

Our Example

Create Project Management Expert System

Test Project Management Expert System

Objective

A
5/28/2002 34

A Construct Project Management Expert System Codify PM Body of Knowledge into Expert System Shell No well-defined ES Architecture

No well-defined PM Body of Knowledge

Decide upon
Obtain PM Body of Knowledge
5/28/2002

Select Expert System Shell

Expert System Architecture

35

The Transition Tree

We know where we stand We identified the core problem We found an injection (one or more) that

produces the desired effects We found the milestones of the journey-the intermediate objectives (IOs) The question now is What specific actions must we take?
5/28/2002

The Transition Tree, Contd

We must focus, not on what we plan to do

but on what we plan to accomplish For each IO, a specific action or set of actions are determined and initiated Causing a specific change in reality is the imperative The transition tree provides a ROAD MAP for getting from here to there!
5/28/2002

The Four-Element Transition Tree

Expected effect

Condition of reality
5/28/2002

Unfulfilled need

Specific action
38

Expected effect

Condition of reality

Unfulfilled Unfilled need

Specific action

Condition of 5/28/2002 reality

Unfulfilled need

Specific action

39

The Transition Tree

Our Example

Create Project Management Expert System

Test Project Management Expert System

A
5/28/2002 40

5/28/2002

41

Thats it for Goldratts Critical Thinking

To get the full version, you have to go to

New Hampshire (Goldratt Institute) , spend two weeks and $10,000 To learn more, please refer to www.eligoldratt.com

5/28/2002

42