Presentation is loading. Please wait.

Presentation is loading. Please wait.

Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 5, Part 1, Page 1 8/8/2004 Day 5, Part 1 Basic Principles and Techniques of Productivity,

Similar presentations


Presentation on theme: "Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 5, Part 1, Page 1 8/8/2004 Day 5, Part 1 Basic Principles and Techniques of Productivity,"— Presentation transcript:

1 Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 5, Part 1, Page 1 8/8/2004 Day 5, Part 1 Basic Principles and Techniques of Productivity, Quality and Cycle Time Management Software Project Planning and Management Dr. Dennis J. Frailey Principal Fellow Raytheon Company

2 Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 5, Part 1, Page 2 8/8/2004 The Overall Planning Cycle Analyze Job Manage Risks Execute Generate Detailed Plans Generate Initial Plans Measure, Manage Productivity and Quality

3 Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 5, Part 1, Page 3 8/8/2004 Outline The basic principles of productivity Customer value and value-added analysis Principles of cycle time improvement

4 Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 5, Part 1, Page 4 8/8/2004 Basic Principles of Productivity

5 Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 5, Part 1, Page 5 8/8/2004 Productivity is... The quality or state of being productive Webster’s 9th New Collegiate Dictionary Productive: Having the power of producing; Yielding or furnishing results, benefits, or profits Webster’s 9th New Collegiate Dictionary

6 Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 5, Part 1, Page 6 8/8/2004 Productivity is NOT being... Busy Industrious Virtuous Productivity has to do with results (what and how much you produce), not with the means or methods of production or the characteristics of the producer Wealthy Hardworking etc.

7 Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 5, Part 1, Page 7 8/8/2004 Measuring Productivity Productivity is usually measured in terms of how much you produce in relation to how much you invest Productivity = Output Input or Investment

8 Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 5, Part 1, Page 8 8/8/2004 Productivity Measures Products produced per labor hour Return on investment Bushels of grain per acre of land Modules tested per week Requirements validated per day A farmer who invents a new method of growing that doubles the output per acre would be more productive than a farmer who works longer hours and doubles output per acre.

9 Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 5, Part 1, Page 9 8/8/2004 Efficiency Productivity is a measure of how efficient your process is Thus the way you improve productivity is to make the process more efficient Many principles of quality engineering and cycle time improvement are directly related to productivity improvement

10 Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 5, Part 1, Page 10 8/8/2004 Work in Process (WIP) WIP or “work in process” is work in the midst of being done –code being tested –specifications being written –objects being designed Excess WIP is work waiting to be done that is not being done -- waiting in queues instead –something is holding up the process

11 Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 5, Part 1, Page 11 8/8/2004 Excess “Work in Process” is a Key Symptom Excess WIP is a symptom of low productivity, long cycle time, and process inefficiency Another key symptom is non-value-added work. This will be addressed later.

12 Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 5, Part 1, Page 12 8/8/2004 Excess WIP Usually Implies a Constraint or Bottleneck When work is waiting to be done, it means that there is something holding it up Usually this is some kind of limitation on resources or other form of process constraint

13 Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 5, Part 1, Page 13 8/8/2004 Constraint Management

14 Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 5, Part 1, Page 14 8/8/2004 What Is a Constraint? A constraint (bottleneck) is any resource with capacity less than the demand placed upon it – This could be a person, a computer, a network, a machine, etc. The constraint regulates the output rate of the entire process

15 Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 5, Part 1, Page 15 8/8/2004 Improving a constraint provides capacity increase, often without capital investment Management provides flexibility to respond to changes in customer demand Reduces product cost as a result of increased output and improved efficiency Why Is Constraint Management Important? Hiking Boys Story

16 Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 5, Part 1, Page 16 8/8/2004 If 100 people each worked to increase capacity by 1% on 100 different parts of the software development process, the 1 person working on the constraint would save the company thousands more than all the other 99 people combined! Where Are Your Resources Focused?

17 Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 5, Part 1, Page 17 8/8/2004 Effective Utilization Before deciding to take actions to improve the constraint, we must first understand the concept of effective utilization

18 Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 5, Part 1, Page 18 8/8/2004 Effective Utilization Defined 24 HOURS AVAILABLE (A)UNAVAILABLE REQUIRED (R) Focus on decreasing ”R" and increasing “A” I.e., decrease effective utilization! Focus on decreasing ”R" and increasing “A” I.e., decrease effective utilization! = EFFECTIVE UTILIZATION = TIME REQUIRED TIME AVAILABLE R A

19 Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 5, Part 1, Page 19 8/8/2004 Effective Utilization -vs- Productivity Webster’s definitions: – Utilize: To make use of – Busy: Constantly active or in motion – Productive: Yielding or furnishing results, benefits or profits We tend to measure utilization by how busy we are, BUT utilization tells us little about how productive we are.

20 Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 5, Part 1, Page 20 8/8/2004 Why Reduce Effective Utilization? EFFECTIVE UTILIZATION WIP or CYCLE TIME 100% Running assets at a high effective utilization requires a costly cycle time trade off per Erlang, 1917 (see Gross and Harris, pp 10-11, 101-102)

21 Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 5, Part 1, Page 21 8/8/2004 Examples Network performance vs load Traffic flow vs load on freeway Computer response vs load Telephone dial tone delay vs load etc.

22 Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 5, Part 1, Page 22 8/8/2004 Utilization vs Productivity High effective utilization will cause delays (cycle time) to increase greatly (increase investment) while output is increased only marginally, thus lowering productivity of the system Lower utilization means the resource is available when needed most, thus reducing delays and raising productivity of the overall system

23 Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 5, Part 1, Page 23 8/8/2004 Example - Firemen Why are firemen usually sitting around the fire station, essentially idle? Because they are needed ASAP when there is a fire.

24 Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 5, Part 1, Page 24 8/8/2004 Effective Utilization And the Constraint Reducing effective utilization is especially critical at the constraint, because it determines the performance of the system as a whole To minimize effective utilization, we must make our assets more productive –This does not necessarily mean that they are busier!

25 Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 5, Part 1, Page 25 8/8/2004 Ways to Improve Efficiency at the Constraint Repair analysis improves our ability to repair and maintain the constraint, so we can improve its availability (increase “A”) Repairman Story

26 Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 5, Part 1, Page 26 8/8/2004 More Ways to Improve Efficiency at the Constraint Flow balancing allows us to effectively increase tool availability (increase “A”) –Flow variability to the constraint increases the probability of the constraint running dry –Flow management helps control variability Statistical process control techniques can decrease required processing time as well as increase tool availability (decrease “R”, increase “A”)

27 Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 5, Part 1, Page 27 8/8/2004 Customer Value

28 Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 5, Part 1, Page 28 8/8/2004 What Constitutes Customer Value? Customer value is the real target of any competitive business The exact definition depends on the customer and the market –Sizzle vs steak –Features vs ease of use –Cost of operation vs comfort and safety

29 Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 5, Part 1, Page 29 8/8/2004 Defining Value Correctly defining value is the first step of customer satisfaction Cut out the tasks or features that do not directly or indirectly contribute to value –They add cost but do not provide appropriate benefit

30 Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 5, Part 1, Page 30 8/8/2004 Dimensions of Customer Value Low Costs / High Productivity –Product development/manufacturing efficiency –Attractive price High Quality –Customer satisfaction –Reliability & few defects Short Cycle Time –Rapid product development –Response to orders

31 Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 5, Part 1, Page 31 8/8/2004 The Goal Improve all components of the customer value triangle Customer Value Quality Productivity Cycle Time

32 Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 5, Part 1, Page 32 8/8/2004 Without Process Change... You can improve any one at the expense of the others High Quality and Low Cost, but Slow High Quality, but Slow and Costly Fast, Cheap, but Shoddy

33 Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 5, Part 1, Page 33 8/8/2004 Even Better Value Better Value Good Value Satisfactory Value By Changing Process & Culture... … you can improve all together

34 Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 5, Part 1, Page 34 8/8/2004 Weinberg’s Definition of Quality “Quality is value to someone” In Weinberg’s sense, value is quality And the cost to produce value is the cost of quality But the term “cost of quality” is usually used in a different context, to describe tasks we execute that improve quality Keep this in mind as we continue in this course

35 Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 5, Part 1, Page 35 8/8/2004 Value-Added Analysis

36 Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 5, Part 1, Page 36 8/8/2004 Who Produces Value? Value is the result of the best software engineers doing their best work. So software engineers produce value - and quality!

37 Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 5, Part 1, Page 37 8/8/2004 WHAT ARE THE COSTS OF SOFTWARE DEVELOPMENT? Total Costs EssentialNon Essential Value-Added Non-Value-Added

38 Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 5, Part 1, Page 38 8/8/2004 Value-Added Costs Costs for tasks performed... –Materials (e.g.., paper, software) –Labor hours (salaries) –Capital equipment (workstations, facilities) … that produce value –Products –Customer satisfaction –Future labor that will not be expended e.g.., reduced maintenance and repair

39 Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 5, Part 1, Page 39 8/8/2004 The Strict Definition of “Value-Added” Any activity that is part of the process is considered a value-added activity if it meets three criteria: 1) Must change the product in some way 2) Must make the product more desirable to the customer (i.e., the customer wants the change) 3) Must be done right the first time

40 Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 5, Part 1, Page 40 8/8/2004 The Strict Definition This very strict definition helps us open our minds So we identify the proper targets for process improvement. Anything that is not value-added is a suitable target for removal or improvement.

41 Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 5, Part 1, Page 41 8/8/2004 Things Not Part of Value-Added Features the engineer thinks are nice but the customer doesn’t care about Moving a product around Translating between incompatible tools Repairing mistakes Tests and inspections Most management activities Activities unrelated to the process Many other things we tend to think of as “necessary” or “desirable” –And some of them are necessary!

42 Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 5, Part 1, Page 42 8/8/2004 Some Non-Value-Added Activities Management Quality Assurance Testing... The term “value-added” is used to help us improve our processes. It is not meant to imply that the above tasks are not valuable or that the people who do them are dispensable.

43 Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 5, Part 1, Page 43 8/8/2004 Non-Value-Added Essential Costs for tasks performed because the process is not perfectly efficient –Peer reviews –Evaluations, inspections, verification and validation –Metrics collection, storage and analysis –Extra reviews and verifications required by customer or company policy (usually because of past problems) –Certain overhead costs (benefits, support activities)

44 Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 5, Part 1, Page 44 8/8/2004 Why are they Essential? They would not be necessary in a perfect world But they are necessary with our current methods of product development and our current level of product development knowledge Every process has some essential, non-value-added elements

45 Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 5, Part 1, Page 45 8/8/2004 Another Perspective Non-value-added but essential tasks are things we might wish we did not have to do But if we did not do them, things would be worse. However, we still can study them to find out how to minimize them, optimize them, and improve them

46 Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 5, Part 1, Page 46 8/8/2004 Non-Value-Added, Not Essential Tasks that are not value-added and that are not essential Typically, these are tasks that we perform because we have not really optimized our processes –For example, things we have always done but no longer need to do –Or methods that once made sense but don’t any more due to newer technologies or changes in the organization or environment

47 Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 5, Part 1, Page 47 8/8/2004 Examples of Non-Value-Added, Not Essential Tasks –Excessive paperwork or approvals –Waits for test equipment or “signoff” –Debugging due to sloppy design or coding –Costs resulting from bugs in our software development tools –Costs for activities unrelated to the process These tasks should be eliminated or streamlined first, as they add cost for no useful purpose

48 Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 5, Part 1, Page 48 8/8/2004 Some Costs are Especially Painful High costs incurred later because of tasks not performed during software development (or not performed at the right time or in the right way) –Debugging –Correcting defects –Maintenance and repair These can subtract value: –Loss of customer good will –Future labor that must be expended

49 Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 5, Part 1, Page 49 8/8/2004 Typical Value-Added Categories Non-EssentialEssential Value-AddedNon-Value-Added (costs $, no value to customer) 1) Customer Wants 2) Changes Product 3) Done Right the First Time Design Development Fabrication Documentation Assembly Process Creation Upgrade Shipping Set-Up Training Planning Customer- required test Moving Data Between Steps Many Quality Improvement activities Rework Service Modification Expediting Recall Correction Retest Error Analysis Extra paperwork Waits Delays Bottlenecks Counting Installing Software Tools Extra Un- wanted Features

50 Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 5, Part 1, Page 50 8/8/2004 Analyzing Value-Added by Task or Category This is the first step of value-added analysis List all of the tasks or task categories in your process Then place each task into one or more of the three value-added classes Value-Added Essential Non-Essential Non-Value-Added If a task fits more than one class, you may want to break it up into parts

51 Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 5, Part 1, Page 51 8/8/2004 Example Result of Analysis by Task / Category Non-EssentialEssential Value-AddedNon-Value-Added (costs $, no value to customer) 1) Customer Wants 2) Changes Product 3) Done Right the First Time Requirements analysis Design Coding Documentation Integration Manufacturing Packaging Shipping Estimating Training Planning Customer- required acceptance test Configuration Control Inspections Debugging Service calls Warranty costs Fedex costs for patches Loss of customer goodwill etc. Approval by 7 people! Delays for test systems Data conversion between design tool and coding tool Wait for subcontracted hardware

52 Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 5, Part 1, Page 52 8/8/2004 Analyzing Value-Added Costs This is the second step of value-added analysis Each task can be assessed with respect to how much of its cost adds value Often, a task will contribute some value but have some non-value-added elements as well

53 Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 5, Part 1, Page 53 8/8/2004 Example of Cost Analysis

54 Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 5, Part 1, Page 54 8/8/2004 What Are the Units? The unit we measure for “cost”can be anything that is available … –Dollars –Labor hours –Percent of time spent For initial analysis, the data do not have to be very accurate –Estimated percent of time spent –Estimated hours spent

55 Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 5, Part 1, Page 55 8/8/2004 Suggested Approach to Apply These Concepts in Practice Take a typical process from your work environment and do a value-added analysis by task or category For tasks that have some value-added and some non-value-added, estimate percentages of each Estimate what percent of the overall process is non-value-added Discuss how you might measure the costs (what units to use) using available information or information readily obtained

56 Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 5, Part 1, Page 56 8/8/2004 Typical Result Value-added -- 35% of total cost NVA Essential -- 20% of total cost NVA Non-essential -- 45% of total cost –Top three items: Rework due to design and coding errors -- 14% Extra customer support -- 12% Labor for individuals waiting for test equipment that is not available -- 11%

57 Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 5, Part 1, Page 57 8/8/2004 A Dilemma in Analyzing Non-Value-Added Costs Sometimes we must introduce non- value-added tasks to reduce the costs and impact of other non-value-added tasks This is a fundamental dilemma and a fundamental reason why we need to do more than analyze value-added We discussed this a little when we talked about cost of quality analysis

58 Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 5, Part 1, Page 58 8/8/2004 Note that Efficiency Improves Three Perspectives Quality (Fewer Defects; Customer satisfaction) Low Cost or High Productivity Customer Value Short Cycle Time or Schedule

59 Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 5, Part 1, Page 59 8/8/2004 Summary Understanding value is the starting point for effective and efficient processes Value-added analysis can help identify the best places to focus improvement efforts Just because something is “non-value- added” does not mean it is not worthwhile or necessary or good

60 Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 5, Part 1, Page 60 8/8/2004 References Knox, 1993, Raytheon studies reported by Houston and Keats, Software Quality Matters, vol 5, no 1 (Spring, 1997), U. of Texas SW Quality Institute Musa, John D, 1992, “The Operational Profile,” in Software Reliability Engineering: An overview. Weinberg, Gerald M., 1992, Quality Software Management, Volume 1, Systems Thinking, Dorset House, New York, ISBN 0- 932633-22-6.

61 Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 5, Part 1, Page 61 8/8/2004 This Page Intentionally Blank

62 Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 5, Part 1, Page 62 8/8/2004 Principles of Cycle Time Improvement

63 Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 5, Part 1, Page 63 8/8/2004 Outline Why Cycle Time is Important Symptoms and Causes of Cycle Time Problems

64 Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 5, Part 1, Page 64 8/8/2004 Cycle Time Reduction Time costs money Cutting cycle time saves money and can increase quality The issue: how to do it effectively Quality (Fewer Defects; Customer satisfaction) Low Cost or High Productivity Customer Value Short Cycle Time or Schedule

65 Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 5, Part 1, Page 65 8/8/2004 Why Cycle Time is Important Yes, Sir! Right Away, Sir. I Need that Software no later than next week! Why is it taking so long? But we’re already working overtime! We’ll work overtime to get it out, sir.

66 Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 5, Part 1, Page 66 8/8/2004 Importance of Low Development Cost for New Product Development 05101520253035 % LOSS OF TOTAL PROFIT ON TIME, CORRECT PRODUCT COST, BUT WITH 50% DEVELOPMENT COST OVERRUN Mckinsey & Co. Analysis of new product introduction profit and loss

67 Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 5, Part 1, Page 67 8/8/2004 Importance of Product Cost for New Product Development 05101520253035 % LOSS OF TOTAL PROFIT ON TIME AND BUDGET, BUT PRODUCT COST 9% TOO HIGH ON TIME, CORRECT PRODUCT COST, BUT WITH 50% DEVELOPMENT COST OVERRUN

68 Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 5, Part 1, Page 68 8/8/2004 Importance of Cycle Time for New Product Development 05101520253035 % LOSS OF TOTAL PROFIT ON TIME AND BUDGET, BUT PRODUCT COST 9% TOO HIGH ON BUDGET, BUT PRODUCT IS SHIPPED 6 MONTHS LATE ON TIME, CORRECT PRODUCT COST, BUT WITH 50% DEVELOPMENT COST OVERRUN

69 Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 5, Part 1, Page 69 8/8/2004 Why Improve Software Development Cycle Time? This does not necessarily mean that you will always need to develop products quickly –Not all situations require short cycle time –But for those that do, you are more competitive To improve the organization’s capability to develop software products quickly.

70 Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 5, Part 1, Page 70 8/8/2004 What If You Don’t Need Short Cycle Time? You can use this capability to: –Achieve competitive costs –Start software development later in the program cycle –Allow less time to change requirements –Get software development off of the critical path

71 Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 5, Part 1, Page 71 8/8/2004 A Common Cycle Time Issue It took so long to develop the software that the customer’s needs changed. This resulted in excessive rework, higher costs, and further delays The key is to develop the software quickly so today’s needs can be met We’ve changed this requirement.

72 Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 5, Part 1, Page 72 8/8/2004 How Can Cycle Time Be Improved? The following video illustrates how to improve cycle time in an area that many of us are familiar with - building a house As you watch, think of ideas that might be applicable to software development

73 Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 5, Part 1, Page 73 8/8/2004 Some Lessons from the Cycle Time Video What did they do? Is there a software counterpart? Things they did: +_%$#@& ~~~~~~~~~~ ~~~~~~~~~~~

74 Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 5, Part 1, Page 74 8/8/2004 How Is Cycle Time Improved? Doing every process step faster? Working longer hours? Piling up work? Faster!!!

75 Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 5, Part 1, Page 75 8/8/2004 How Is Cycle Time Improved? Doing every process step faster? Working longer hours? Piling up work? Faster!!!

76 Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 5, Part 1, Page 76 8/8/2004 Cycle Time Improvement Is... Improving the Process

77 Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 5, Part 1, Page 77 8/8/2004 Cycle Time Improvement Is... Improving the Process Reducing the Critical Path

78 Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 5, Part 1, Page 78 8/8/2004 Cycle Time Improvement Is... Improving the Process Reducing the Critical Path Eliminating Waits, Queues, Bottlenecks

79 Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 5, Part 1, Page 79 8/8/2004 Cycle Time Improvement Is... Improving the Process Reducing the Critical Path Eliminating Waits, Queues, Bottlenecks Helping People work Smarter

80 Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 5, Part 1, Page 80 8/8/2004 Cycle Time Improvement Is... Improving the Process Reducing the Critical Path Eliminating Waits, Queues, Bottlenecks Helping People work Smarter Increased Cycles of Learning

81 Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 5, Part 1, Page 81 8/8/2004 Cycle Time Improvement Is... Improving the Process Reducing the Critical Path Eliminating Waits, Queues, Bottlenecks Helping People work Smarter Increased Cycles of Learning Reengineering the Process

82 Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 5, Part 1, Page 82 8/8/2004 Symptoms and Causes of Cycle Time Problems

83 Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 5, Part 1, Page 83 8/8/2004 Symptoms of Cycle Time Problems –Long waits and queues –Lots of “work in process” –High inventory levels –Excessive overtime Tickets --> How long is this line?

84 Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 5, Part 1, Page 84 8/8/2004 Major Contributors to Slow Cycle Time Bottlenecks and constraints Barriers Inefficient processes Inadequate training Variability

85 Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 5, Part 1, Page 85 8/8/2004 Bottlenecks and Constraints Symptom: excess WIP or “work in process” –work waiting to be done that is not being done -- waiting in queues instead –something is holding up the process Causes: limited capacity, poor processes, poor execution, or various barriers imposed by the organization Places in the process that inhibit efficient flow of work

86 Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 5, Part 1, Page 86 8/8/2004 Example Process Pizza Oven Toppings Crust Box Slicer Deliver Take Order Take Order Where could the bottlenecks be?

87 Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 5, Part 1, Page 87 8/8/2004 Barriers Things that prevent you from going faster, such as budgetary limits, head count limits, lack of people or equipment, process problems, missing data, regulations, etc.

88 Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 5, Part 1, Page 88 8/8/2004 Sample Barriers Approval processes Excessive paperwork Limited space Limited budgets Wasteful processes Defective information or material …..

89 Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 5, Part 1, Page 89 8/8/2004 Dealing with Barriers Question why barriers are there –Often they are the remnants of past problems and no longer need to be there Obsolete approval procedures Redundant checks and balances –Sometimes the barriers have benefits but the organization does not understand their consequences The “cure” may be more expensive than the problem

90 Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 5, Part 1, Page 90 8/8/2004 Organizations Often Resist Removal of Barriers There are many reasons, such as … –Political factors –Power issues –How performance and success are defined –Fear of change Exercise What barriers does your organization resist removing and why?

91 Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 5, Part 1, Page 91 8/8/2004 Lack of Training Contributes to Slow Cycle Time Inadequate Training - people do not know what to do, or how to do it most effectively –So it takes them longer to do the work Investment in training usually pays off well -- But it requires foresight and faith

92 Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 5, Part 1, Page 92 8/8/2004 Process Contributes to Slow Cycle Time Inefficient Processes - processes containing steps that do NOT ADD VALUE –All processes have inefficiencies –Most processes can be improved in efficiency Variability - in processes, materials, skills, etc. –Variability is natural –But it can be controlled

93 Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 5, Part 1, Page 93 8/8/2004 Special Notice For the next exercise, each student should bring a pair of dice –Actually, one die per student will do And five coins or other tokens And have some desk space free

94 Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 5, Part 1, Page 94 8/8/2004 References Deming, W. Edwards, Out of the Crisis, MIT Press, 1982. Goldratt, Eliyahu M. & Jeff Cox, The Goal, (North River Press, 1984.) Also, Theory of Constraints, It’s Not Luck, and Critical Chain Management. Swartz, James B., The Hunters and the Hunted, (Portland, Oregon, Productivity Press, 1994) ISBN 1- 56327-043-9.

95 Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 5, Part 1, Page 95 8/8/2004 Outline Variability Experiment Definitions, Terms and Concepts Solutions to Cycle Time Problems –Reducing Variability –Reducing Work in Process Observations and Caveats

96 Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 5, Part 1, Page 96 8/8/2004 Variability Experiment

97 Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 5, Part 1, Page 97 8/8/2004 Variability Experiment Line up 5 tokens, like a train Each turn, move tokens right –See rules on a later slide How many turns does it take to move the leftmost token 15 positions? Rules: –Round 1 will have low variability –Round 2 will have high variability –Round 3 will have high variability but higher capacity

98 Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 5, Part 1, Page 98 8/8/2004 Token Setup for Experiment o o o o...Round 1 o o o o … Round 2 o o o o … Round 3 ^ ^ ^ Left Token Right Token Positions to Move to You may execute the rounds sequentially or in parallel.

99 Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 5, Part 1, Page 99 8/8/2004 Round 1 Rules Each turn, move each token 3 places, starting with the one on the right (3 places right, per turn) Result of first turn: o o o o o o … Result of second turn: o o o o o o... How many turns does it take for the leftmost token to move 15 places to the right?

100 Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 5, Part 1, Page 100 8/8/2004 Round 2 Rules Each turn, move each token n places, starting with the one on the right, where n is a number from 1 to 5 determined randomly by rolling a die - 6’s don’t count. –Roll the die separately for each token –A token cannot move past another Note that the average move is 3 places Possible result from first turn o o o o o o …

101 Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 5, Part 1, Page 101 8/8/2004 Round 3 Rules Each turn, move each token n places, starting with the one on the right, where n is a number from 1 to 6 determined randomly by rolling a die - 6’s do count. –Roll the die separately for each token –A token cannot move past another Note that the average move is 3 1/2 Possible result from first turn o o o o o o …

102 Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 5, Part 1, Page 102 8/8/2004 Why Variability Results in Longer Cycle Time Slower tokens block faster ones If you have a low roll on the die you cannot take advantage of opportunities to “catch up” Even with higher average capacity (round 3), variability results in slower cycle time

103 Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 5, Part 1, Page 103 8/8/2004 Definitions, Terms and Concepts The next few slides address some basic cycle time terminology

104 Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 5, Part 1, Page 104 8/8/2004 Cycle Time is... This could be: –First operation to ship –A single operation –A group of operations –Customer order to product delivery Cycle time includes actual processing time …… and all waiting time –Consider a “10 minute” oil change The time required to execute all activities in a process

105 Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 5, Part 1, Page 105 8/8/2004 Lead Time is... What is: –Your customer’s lead time? –Your potential customer’s lead time? The maximum time the customer will wait between order placement and product delivery. How long will it take? How long will it take? Here’s my order!

106 Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 5, Part 1, Page 106 8/8/2004 Cycle Time vs Lead Time To be competitive, you must make: Otherwise, you lose business Or else orders have to be started on speculation, which means higher risk of rework or failing to satisfy the customer Cycle Time < Lead Time

107 Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 5, Part 1, Page 107 8/8/2004 Throughput is... This could be: –Modules tested per day –Components produced per week –Defects corrected per month –etc. Throughput is a measure of the output of a process The number of products produced per unit of time

108 Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 5, Part 1, Page 108 8/8/2004 How to Measure Cycle Time? Static Cycle Time The average of the actual cycle times (CT) experienced by some number (n) of products CT 1 + CT 2 + CT 3 + CT 4 +...+ CT n n Cycle Time =

109 Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 5, Part 1, Page 109 8/8/2004 Using This Measure This can be used to measure cycle time for many situations –For example, measure the cycle times of the tokens in the variability experiment –Or measure the cycle times for cars being serviced in a “10 minute oil change” station But this is not always easy to measure when many of the products are only partway through the process –So we need a dynamic measure

110 Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 5, Part 1, Page 110 8/8/2004 A Measure to Use when Static Cycle Time is Not Convenient Dynamic Cycle Time The total work in process (WIP) divided by the throughput of the process Cycle Time = WIP (products being developed) THROUGHPUT This equation can be shown from queueing theory. See Gross and Harris, in reference list, p83.

111 Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 5, Part 1, Page 111 8/8/2004 Revised Variability Experiment Take 5 turns for each round Measure the total number of tokens that reach the 15th position After 5 turns, measure WIP Also measure throughput, cycle time, etc (see next slide) Think of this as a 15 step process, with the tokens being work going through the process

112 Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 5, Part 1, Page 112 8/8/2004 Solution Record for Variability Experiment

113 Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 5, Part 1, Page 113 8/8/2004 This Page Intentionally Blank

114 Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 5, Part 1, Page 114 8/8/2004 Solutions to Cycle Time Problems

115 Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 5, Part 1, Page 115 8/8/2004 What Makes Cycle Time High? Inventory or work in process (WIP) Higher overhead, longer delays Process flow variability Excessive waiting and long queues Complexity of processes Redundant and unnecessary steps These are all related to each other

116 Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 5, Part 1, Page 116 8/8/2004 3 Steps to Cycle Time Improvement Reduce variability Simplify the process Reduce WIP This order is recommended Due to time limitations, we will only address the first and third of these in this module. Process simplification will be addressed in the next module

117 Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 5, Part 1, Page 117 8/8/2004 Reducing Variability

118 Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 5, Part 1, Page 118 8/8/2004 Variability Increases Cycle Time USLLSL USL LSLUSLLSL 2134 If price and delivery were equal, which supplier would you buy a product from? OUTPUT FROM FOUR DIFFERENT PROGRAMMING SHOPS

119 Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 5, Part 1, Page 119 8/8/2004 Sources of Variability Movement of programs or documents between workstations or systems Machines or software not being available Hot lots / priority tasks that disrupt normal activity Software defects that require rework and debugging Special cases that require holds and delays Inconsistent processes and procedures Excessive approval requirements Hundreds more...

120 Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 5, Part 1, Page 120 8/8/2004 Expediting via Priority Tasks The tendency is to establish many levels of priorities – Hot – Super hot – Immediate – Per the boss Pressure exists to raise the number of priority tasks The list always grows

121 Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 5, Part 1, Page 121 8/8/2004 Other Problems Resulting from Priority Tasks Managing priorities consumes many resources And it delays other jobs

122 Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 5, Part 1, Page 122 8/8/2004 Expediting vs Cycle Time 0510152025303540455055606570 Percent expedited Cycle Time Multiplier for Non-Expedited Jobs When we expedite a product, other products are delayed In some cases, each product waits until it is expedited before it moves at all

123 Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 5, Part 1, Page 123 8/8/2004 Variability Management Must Minimize Expediting 7142128 BAU NUMBER OF SHIPMENTS CYCLE TIME (DAYS) 7142128 CYCLE TIME (DAYS) NUMBER OF SHIPMENTS EXPEDITED LOTS DELINQUENT LOTS With managed priorities, you improve the normal case and reduce the need for “priority jobs”

124 Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 5, Part 1, Page 124 8/8/2004 A Strategy for Managing Priorities Allow only two priorities –Hot –Not hot Control the maximum percentage of “hot” (less than 8% to 10%) –If you add a hot job, you must subtract another –This requires discipline (and faith that it works!)

125 Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 5, Part 1, Page 125 8/8/2004 Further Management of Priorities Monitor distribution throughout the process –Do not plug up one operation or individual with priority tasks Monitor frequently Remove tasks from the priority list when they don’t really need priority

126 Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 5, Part 1, Page 126 8/8/2004 EFFECTIVE UTILIZATION Cycle Time, Utilization and Variability WIP or CYCLE TIME 100%

127 Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 5, Part 1, Page 127 8/8/2004 Higher Utilization Increases Cycle Time EFFECTIVE UTILIZATION WIP or CYCLE TIME 100% SOME VARIABILITY

128 Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 5, Part 1, Page 128 8/8/2004 EFFECTIVE UTILIZATION Variability Affects the Extent of the Added Delay WIP or CYCLE TIME 100% NO VARIABILITY SOME VARIABILITY

129 Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 5, Part 1, Page 129 8/8/2004 EFFECTIVE UTILIZATION OR THROUGHPUT High Low Variability Output Opportunity Cycle Time Opportunity Variability Reduction Opportunities WIP or CYCLE TIME

130 Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 5, Part 1, Page 130 8/8/2004 Reducing Work in Process (WIP)

131 Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 5, Part 1, Page 131 8/8/2004 High WIP = High Cycle Time Any intermediate work in the system is WIP. Anything that is not being actively processed is excessive WIP. For related background, see Gross and Harris, in reference list, p83. Dynamic Cycle Time = WIP THROUGHPUT

132 Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 5, Part 1, Page 132 8/8/2004 Examples of Excessive WIP for Software Code waiting to be tested Designs waiting to be coded Specifications waiting to be inspected Change requests waiting for approval Hundreds more...

133 Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 5, Part 1, Page 133 8/8/2004 Smooth Flow - Ideal Process The ideal process flows smoothly, like a train running on tracks. Note: tracks are empty most of the time

134 Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 5, Part 1, Page 134 8/8/2004 Uneven Flow - Typical Process Lots of exits and entrances Vehicles of varying sizes and speeds Note: streets are usually crowded - with WIP! The typical process runs unevenly, like vehicles on a city street »Some drivers uncertain of what they want to do »Lots of stoplights to “control” the flow (mainly to prevent collisions)

135 Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 5, Part 1, Page 135 8/8/2004 Techniques for Obtaining Smoother Flow Identify bottlenecks and constraints -- and manage/optimize them Utilize pull systems instead of push systems “Conduct the orchestra” (keep everyone going at the same speed) Flow management systems.....

136 Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 5, Part 1, Page 136 8/8/2004 Observations and Caveats

137 Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 5, Part 1, Page 137 8/8/2004 Too Much Measurement! The tendency is to measure too much and in too much detail –Rough estimates usually identify the biggest problems and opportunities

138 Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 5, Part 1, Page 138 8/8/2004 Some of The Problems & Solutions are Technical 30% of the improvement comes from technical changes –Process changes –Tool changes –Changing rules and operations

139 Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 5, Part 1, Page 139 8/8/2004 Most of The Problems & Solutions are Not Technical 70% of the improvement comes from organizational and people changes, such as –Education –Communication –Management –Teamwork

140 Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 5, Part 1, Page 140 8/8/2004 Practitioners generally focus on their work and on what they THINK is happening rather than on what IS happening –They tend not to see all of the waits, queues, etc. that they cause themselves –Their perception of how they spend their time is generally incorrect –They are too busy getting the job done to see how they might improve it Independent Observers See Problems and Opportunities the Best

141 Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 5, Part 1, Page 141 8/8/2004 Just as athletes rely on coaches, software engineers need to learn to trust in others to observe and help them do better The Athletic Coach Analogy

142 Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 5, Part 1, Page 142 8/8/2004 Software Developers are Accustomed to Improving Cycle Time Think of your software development process as a large computer program that runs too slow. –How would you make it run faster? –Imagine how you would speed up a computer program........ –Then draw analogies to the software development process

143 Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 5, Part 1, Page 143 8/8/2004 Improve the Process the way you would Speed Up a Program Code Speed-up Faster hardware Better algorithm Optimizing compiler Remove code from inner loops Optimize code ….. Process Speed-up Faster hardware Better process Eliminate waste Remove redundant steps Eliminate wasteful meetings and approvals …..

144 Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 5, Part 1, Page 144 8/8/2004 You don’t pay for the steps you don’t do –Fewer steps means fewer opportunities to introduce defects –Shorter cycles means less time to change requirements –Shorter cycles means more time to iterate designs or benefit from cycles of learning Cycle Time Bonus It generally turns out that improved cycle time produces lower costs and higher quality as well!

145 Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 5, Part 1, Page 145 8/8/2004 Examples of Software Cycle Time Techniques “Just-in-time” training Plan testing and test equipment well in advance Rethink the detailed design process –Do you need to maintain detailed design documentation? –Do you need to do detailed design at all? Use on-line requirements and design models instead of paper documents and specifications

146 Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 5, Part 1, Page 146 8/8/2004 Examples of Commonly Found Software Cycle Time Barriers Poor communication/cooperation between software development and the rest of the organization Poor management of unstable requirements, algorithms and interfaces Contention for test assets -- need better planning, assets allocated to software test Poorly qualified software subcontractors

147 Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 5, Part 1, Page 147 8/8/2004 More Commonly Found Software Cycle Time Barriers Excessive paperwork, signatures, and reporting –Negotiate reductions with management and customer Reuse of software not designed for reuse Attempts to use the latest tools and methods -- without adequate support and integration

148 Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 5, Part 1, Page 148 8/8/2004 Summary Measure cycle time Measure rework Use these to show the value of process improvements And to convince others that your techniques are worthwhile –Because many cycle time improvement techniques are “counterintuitive” Focussing on cycle time can make the whole process more efficient, and effective

149 Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 5, Part 1, Page 149 8/8/2004 References Deming, W. Edwards, Out of the Crisis, MIT Press, 1982. Goldratt, Eliyahu M. & Jeff Cox, The Goal, (North River Press, 1984.) Also, Theory of Constraints, It’s Not Luck, and Critical Chain Management. Gross and Harris, Fundamentals of Queueing Theory (Wiley). Swartz, James B., The Hunters and the Hunted, (Portland, Oregon, Productivity Press, 1994) ISBN 1- 56327-043-9.


Download ppt "Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 5, Part 1, Page 1 8/8/2004 Day 5, Part 1 Basic Principles and Techniques of Productivity,"

Similar presentations


Ads by Google