Goldratts Thinking Process and Systems Thinking James R

Goldratt’s Thinking Process and Systems Thinking James R. Burns Fall 2010 1

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) b Dettmer, H. William, Goldratt’s Theory of Constraints, ASQ, 1997. 5/28/2002 3

THE ISSUES ARE: b What to change? • {What is the core problem? } b What to change to? • {Where to look for the breakthrough idea? } b How to effect the change? • {How to bridge from a breakthrough idea to a full solution? } 5/28/2002

Goldratt’s TP (Thinking Process) b An excellent methodology to facilitate sessions during the initiation phase (definition and conceptualization stage) of a project 5/28/2002 5

Strategy for change b Create the tree b Critique the tree 5/28/2002

Why trees? ? b To get a complete picture of what is going on b To model all of the causation involved b To see what is related to what b To identify the core problem b To validate a proposed injection 5/28/2002

What to change? b Team constructs a current reality tree (CRT) b Team starts by listing all undesirable effects (UDE’s) b Team inter-relates these by use of a tree, called a CRT b In the current reality tree, the team traces UDE’s back to a core problem (CP) 5/28/2002

EXAMPLES OF UDE’s b Due dates are often missed b It is difficult to respond to urgent demands b There is too much expediting b Inventory levels are too high b There are frequent material shortages b Safety stocks are inadequate 5/28/2002

Symptoms, Root Causes & a Core Problem b Rather than reacting to symptoms, we should be finding root causes b We consider undesirable effects to be symptoms b 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 b Only 28% of software projects are successful—on-time, within budget and with full functionality b 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 5/28/2002 Software Development Projects cost too much A Software Development Projects have quality problems 12

Software Development Projects take too long Fixing changes takes time There are many latebreaking changes to requirements Users discover new features they want included in the software 5/28/2002 Users don’t know what they want Software Development Projects cost too much Fixing changes costs money Users change their minds Users are untrained and not sophisticated 13

Late in the lifecycle Users discover new Users are untrained and not sophisticated features they want included in the software A 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 14 in Software projects

We conclude…. b That the core problem is with poorly trained software project managers 5/28/2002 15

The next construct is the Evaporating Cloud {EC} b 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 b Evaporating clouds (ECs) will surface assumptions b Breaking an assumption leads to a breakthrough called an injection b At this point the team is unconcerned with the practicality of the injection 5/28/2002

What is an injection? b a solution to the core problem b a strategy that will mitigate all of the UDE’s b Injections that appear impossible to achieve are called flying pigs 5/28/2002

Example Evaporating Cloud Training takes much time/money, requires trainers Project training is long and arduous Project Manager expertise is required now Instant Project Manager expertise required Many well-trained Project Managers Are available now 5/28/2002 19

What have we learned from the EC above? b Many expert project managers are needed now b Creating well-trained project managers takes time b Instant project management expertise is required now b SOLUTION: Expert system for project management 5/28/2002 20

INJECTION b 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? b From the CRT and ECs, a Future Reality Tree (FRT) is constructed b One purpose of the Future Reality Tree is to validate that the injection will achieve the desired effects (DE’s) 5/28/2002

Examples of DE’s b b b 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 b b b 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 b Start by turning the UDE’s around and writing them with a positive tone as DE’s b Place DE’s at the top of the limbs in the FRT b At the bottom of the FRT place the injection b 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, Cont’d? b The idea here is to get a picture of how an injection (a breakthrough) might affect the overall performance of the system. b The Future Reality Tree is the validation that a collection of injections will turn all of the UDE’s into DE’s 5/28/2002

Future Reality Tree for our example Managing Software Development Projects Is usually successful Software Development Projects take reasonable lengths of time 5/28/2002 Software Development Projects aren’t too costly A Software Development Projects create quality products 26

Software Development Projects take reasonable Projects take too long Lengths of time Fixing changes takes time Thereare aremany few latebreaking changes to requirements Usersdiscovernonew features they want included in the software 5/28/2002 Users don’t know what they want Software Development Projects aren’t too Projects cost too much costly Fixing changes costs money Userschange rarely change their minds Users are untrained more trained andand not sophisticated 27

Late in the lifecycle Users rarely discover Users are trained and sophisticated features they want included in the software A 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? b The prerequisite tree b The transition tree b These help to get buy-in b 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 b Place INJECTIONS at the top b List the obstacles that are expected b For each obstacle that is overcome, an intermediate objective is achieved • Each obstacle gives rise to an intermediate objective b The intermediate objectives need to be sequenced b The prerequisite tree does the sequencing 5/28/2002

OBSTACLE b b INTERM. OBJECTIVE No well-defined ES Architecture There are many commerciallyavailable ES Shells 5/28/2002 b Pick an appropriate ES Architecture b Select an appropriate ES Shell 32

The Prerequisite Tree, Cont’d b Takes an impediment or obstacle approach b 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 Objective Test Project Management Expert System A 5/28/2002 34

A Construct Project Management Expert System No well-defined PM Body of Knowledge Codify PM Body of Knowledge into Expert System Shell No well-defined ES Architecture Decide upon Obtain PM Body of Knowledge 5/28/2002 Select Expert System Shell Expert System Architecture 35

The Transition Tree b We know where we stand b We identified the core problem b We found an injection (one or more) that produces the desired effects b We found the milestones of the journey-the intermediate objectives (IO’s) b The question now is What specific actions must we take? 5/28/2002

The Transition Tree, Cont’d b We must focus, not on what we plan to do but on what we plan to accomplish b For each IO, a specific action or set of actions are determined and initiated b Causing a specific change in reality is the imperative b 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 Condition of 5/28/2002 reality Unfulfilled Unfilled need 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

That’s it for Goldratt’s Critical Thinking b To get the full version, you have to go to New Hampshire (Goldratt Institute) , spend two weeks and $10, 000 b To learn more, please refer to… b www. eligoldratt. com 5/28/2002 42