1. Copyright © 1995-2003, Dennis J. Frailey, All Rights Reserved Day 5, Part 2, Page 1 5/1/2003 Day 5, Part 2 Applying the 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-2003, Dennis J. Frailey, All Rights Reserved Day 5, Part 2, Page 2 5/1/2003 The Overall Planning Cycle Analyze Job Manage Risks Execute Generate Detailed Plans Generate Initial Plans Measure, Manage Productivity and Quality

3. Copyright © 1995-2003, Dennis J. Frailey, All Rights Reserved Day 5, Part 2, Page 3 5/1/2003 Summary of This Module Simplifying the process –Reduce rework –Make processes more consistent –Analyze value-added (see part 1) –Analyze and optimize process flow –Periodically re-engineer the process –but not so often as to be disruptive –Manage the white space Exercise to apply and demonstrate the power of these techniques

4. Copyright © 1995-2003, Dennis J. Frailey, All Rights Reserved Day 5, Part 2, Page 4 5/1/2003 Process Simplification

5. Copyright © 1995-2003, Dennis J. Frailey, All Rights Reserved Day 5, Part 2, Page 5 5/1/2003 Many Processes are Too Complex How to Change a Lightbulb Volume 1 Volume 2 Volume 3Volume 4Volume 5

6. Copyright © 1995-2003, Dennis J. Frailey, All Rights Reserved Day 5, Part 2, Page 6 5/1/2003 Process Complexity Means Low Productivity and Long Cycle Time Typical software development processes are much more complex than they need to be This often results from trying to be too comprehensive or too rigid –Processes are important –But they must be designed for efficiency We need to focus on eliminating steps that do not add value to the product

7. Copyright © 1995-2003, Dennis J. Frailey, All Rights Reserved Day 5, Part 2, Page 7 5/1/2003 Ways of Analyzing Processes to Simplify Them Reducing rework Making processes more consistent Value-added analysis Flow analysis Re-engineering the process Managing the white space

8. Copyright © 1995-2003, Dennis J. Frailey, All Rights Reserved Day 5, Part 2, Page 8 5/1/2003 Reducing Rework

9. Copyright © 1995-2003, Dennis J. Frailey, All Rights Reserved Day 5, Part 2, Page 9 5/1/2003 Reducing Rework - The Impact of Defects on Cycle Time Process Step Undetected Defect Several Steps Process Step Defect Detected

10. Copyright © 1995-2003, Dennis J. Frailey, All Rights Reserved Day 5, Part 2, Page 10 5/1/2003 Doing It Over Again Process Step Undetected Defect Several Steps Process Step Defect Detected Rework costs money and time

11. Copyright © 1995-2003, Dennis J. Frailey, All Rights Reserved Day 5, Part 2, Page 11 5/1/2003 The Longer It Takes To Detect, The Higher The Cost COSTCOST PHASE WHERE DETECTED

12. Copyright © 1995-2003, Dennis J. Frailey, All Rights Reserved Day 5, Part 2, Page 12 5/1/2003 Look for Rework Rework is anything you do because you didn’t do it right the first time. –debugging –correcting documentation –correcting designs –correcting requirements –re-testing –responding to customer complaints Some rework is hard to avoid but most can be reduced significantly

13. Copyright © 1995-2003, Dennis J. Frailey, All Rights Reserved Day 5, Part 2, Page 13 5/1/2003 Rework = Inefficiency Total rework is a measure of process efficiency You probably have a lot more rework than you think

14. Copyright © 1995-2003, Dennis J. Frailey, All Rights Reserved Day 5, Part 2, Page 14 5/1/2003 Making Processes More Consistent

15. Copyright © 1995-2003, Dennis J. Frailey, All Rights Reserved Day 5, Part 2, Page 15 5/1/2003 Impact of Inconsistent Processes and Procedures Tools do not share data Individuals do not understand each others’ work Excessive time and effort spent on interfaces between different individuals and organizations System Engineer Story

16. Copyright © 1995-2003, Dennis J. Frailey, All Rights Reserved Day 5, Part 2, Page 16 5/1/2003 Example of Inconsistent Processes and Procedures On one project, we found that roughly 50% of the cycle time was spent in the following activities: –Converting documents and software from one tool/format to another –Correcting problems due to different programming styles –Handling interfaces between programs written in different languages

17. Copyright © 1995-2003, Dennis J. Frailey, All Rights Reserved Day 5, Part 2, Page 17 5/1/2003 Making Processes More Consistent Use standards, especially for interfaces and data formats Use compatible tools and procedures (even if they are not optimal for individual tasks!) Develop a culture that resists “ownership” of processes and methods Email Story

18. Copyright © 1995-2003, Dennis J. Frailey, All Rights Reserved Day 5, Part 2, Page 18 5/1/2003 Flow Analysis

19. Copyright © 1995-2003, Dennis J. Frailey, All Rights Reserved Day 5, Part 2, Page 19 5/1/2003 Flow Analysis Identifies Process Bottlenecks Determine what people actually do throughout the entire software development cycle –what is their actual, day-to-day process? Diagram the actual process flow –(not what you think it does - what it really does!) Draw a flow chart or other diagram

20. Copyright © 1995-2003, Dennis J. Frailey, All Rights Reserved Day 5, Part 2, Page 20 5/1/2003 Sample Process Flow Diagram START CHECK STATUS CORRECT ERROR COUNT? GO TO DEBUG STEP DEBUG ERRORS LOGOUT INSPECT MODULE OK? LOGOUT IS ERROR CORRECTION CORRECT? APPROVE LOGOUT FINISH DETERMINE WHY? REPEAT INSPECTION CORRECT ERROR CNT CORRECT THE ERROR NO YES NO YES FIND SW MODULE

21. Copyright © 1995-2003, Dennis J. Frailey, All Rights Reserved Day 5, Part 2, Page 21 5/1/2003 Show Everything Include all inputs, outputs, inspections, rework, temporary storage, set ups, etc. –everything that happens Determine which components do not add value Identify opportunities to eliminate waste and flow problems Focus on non-essentials

22. Copyright © 1995-2003, Dennis J. Frailey, All Rights Reserved Day 5, Part 2, Page 22 5/1/2003 Areas to Focus On Procedures and methods –Are they working effectively? –Are they interfacing well with each other? People –Are they using their time efficiently? –Are they spending too much time waiting between tasks? Coordination - or lack of it … continued

23. Copyright © 1995-2003, Dennis J. Frailey, All Rights Reserved Day 5, Part 2, Page 23 5/1/2003 More Areas to Focus On Computers and Software –Are they available and effective? –Is too much time spent getting them to work? Requirements/specifications/other inputs –Are they available when needed? Queues and waits –Where is the excess WIP?

24. Copyright © 1995-2003, Dennis J. Frailey, All Rights Reserved Day 5, Part 2, Page 24 5/1/2003 Identifying Queues and Waits þThink of yourself as the software product being developed. þTake yourself through the process. þAt what points are you just waiting, with no useful work being performed? þThese are bottlenecks, waits or queues that should be removed

25. Copyright © 1995-2003, Dennis J. Frailey, All Rights Reserved Day 5, Part 2, Page 25 5/1/2003 Example - Eliminating Queues and Waits Problem: you take a long time to complete unit test because everyone needs the test system at the same time Analysis: the test system is a constraint Solution: optimize the constraint! I must have the test system today! But I must have it too!!

26. Copyright © 1995-2003, Dennis J. Frailey, All Rights Reserved Day 5, Part 2, Page 26 5/1/2003 Some Options for Solution Stagger development schedules to even out use of test system –costs more up-front planning –requires people to be flexible in their schedules Obtain more test systems –costs more money –but may be worth it

27. Copyright © 1995-2003, Dennis J. Frailey, All Rights Reserved Day 5, Part 2, Page 27 5/1/2003 Exercise - The Passing Game Input: Six coins piled on the end of a long table, with six people lined up on one side of the table Output: Six coins piled on the other end of the table Goal: Shortest time / highest productivity Finish Start

28. Copyright © 1995-2003, Dennis J. Frailey, All Rights Reserved Day 5, Part 2, Page 28 5/1/2003 Rules for The Passing Game Each coin must be picked up before it is moved. Each person must hold each coin for a minimum of 1 second -- if they do not, you get a penalty - the coin moves back to the starting point See how fast you can move the coins by coordinating and synchronizing your handoffs

29. Copyright © 1995-2003, Dennis J. Frailey, All Rights Reserved Day 5, Part 2, Page 29 5/1/2003 Typical Results First time - 22 seconds After coordination of handoffs - 13 seconds

30. Copyright © 1995-2003, Dennis J. Frailey, All Rights Reserved Day 5, Part 2, Page 30 5/1/2003 Re-engineering the Process

31. Copyright © 1995-2003, Dennis J. Frailey, All Rights Reserved Day 5, Part 2, Page 31 5/1/2003 Organizations usually begin by designing themselves to fit the needs of the customer, the business environment and the available technology Organizations Optimize to Fit the Customer Organization Customer, Environment, Technology

32. Copyright © 1995-2003, Dennis J. Frailey, All Rights Reserved Day 5, Part 2, Page 32 5/1/2003 After time, the organization no longer fits the customer and/or the available technology But Things Change Organization Customer, Environment, Technology

33. Copyright © 1995-2003, Dennis J. Frailey, All Rights Reserved Day 5, Part 2, Page 33 5/1/2003 Process Re-engineering Basic Idea: from time to time, it is necessary to reinvent the process Motivation can come from: –intense competition –new technologies –new customers –new laws –other changes in the environment –realization that competition does it better –realization that you have not rethought the issues in a long time and may be stagnating

34. Copyright © 1995-2003, Dennis J. Frailey, All Rights Reserved Day 5, Part 2, Page 34 5/1/2003 Changes Make Organizations and Processes Obsolete You define your organization to mirror or support a given environment. But environments change and changes can make organizations less effective.

35. Copyright © 1995-2003, Dennis J. Frailey, All Rights Reserved Day 5, Part 2, Page 35 5/1/2003 Organizations Need Periodic Redesign or Re-engineering “We’ve always done it this way and it works just fine” Assess the environment Rethink the processes Reinstate the direct connections to –customers –suppliers –employees –etc.

36. Copyright © 1995-2003, Dennis J. Frailey, All Rights Reserved Day 5, Part 2, Page 36 5/1/2003 Example 1 Credit Approval Process Before: Credit approval must go through six departments Each department takes 2-3 business days So credit approval typically takes 3 weeks Meanwhile, the competition is approving credit in 1 week! And we are losing sales because of this.

37. Copyright © 1995-2003, Dennis J. Frailey, All Rights Reserved Day 5, Part 2, Page 37 5/1/2003 Solution Credit Approval Process Each department must increase productivity and reduce cycle time to 1 day per approval step Each department does this through incentives (bonuses, rewards, etc.) Will this work? >If so, why? >If not, why not?

38. Copyright © 1995-2003, Dennis J. Frailey, All Rights Reserved Day 5, Part 2, Page 38 5/1/2003 Wrong Solution! Credit Approval Process It is accomplished by –Rejecting faulty input (even slightly faulty) –Producing output that is often defective Result: Average credit approval takes 6 weeks! Greatly increased rework!

39. Copyright © 1995-2003, Dennis J. Frailey, All Rights Reserved Day 5, Part 2, Page 39 5/1/2003 One individual handles all six steps of each transaction The six former departments become consultants, available to handle special cases but not involved in routine cases Re-engineered Solution Credit Approval Process Credit approvals reduced to 1 week!

40. Copyright © 1995-2003, Dennis J. Frailey, All Rights Reserved Day 5, Part 2, Page 40 5/1/2003 Analysis Changed the process Changed the organization structure –Responsibilities –Authority Changed the culture –What is important is serving the customer

41. Copyright © 1995-2003, Dennis J. Frailey, All Rights Reserved Day 5, Part 2, Page 41 5/1/2003 Example 2 Graphic Artist Group Original Process: Need Graphic Artist Design Group: Assignment Dept G1 G2 G3 G4 G5 Design Graphic Artist Printing Group: Assignment Dept P1 P2 P3 P4 P5 Inspection Good Products Defective Products Sample

42. Copyright © 1995-2003, Dennis J. Frailey, All Rights Reserved Day 5, Part 2, Page 42 5/1/2003 Example 2 Graphic Artist Group Original Process: Need Graphic Artist Design Group: Assignment Dept G1 G2 G3 G4 G5 Design Graphic Artist Printing Group: Assignment Dept P1 P2 P3 P4 P5 Inspection Good Products Defective Products Sample Motive for this approach: even workloads

43. Copyright © 1995-2003, Dennis J. Frailey, All Rights Reserved Day 5, Part 2, Page 43 5/1/2003 Example 2 Graphic Artist Group Original Process: Need Graphic Artist Design Group: Assignment Dept G1 G2 G3 G4 G5 Design Graphic Artist Printing Group: Assignment Dept P1 P2 P3 P4 P5 Inspection Good Products Defective Products Sample Bad samples are common on the first attempt due to the nature of the work.

44. Copyright © 1995-2003, Dennis J. Frailey, All Rights Reserved Day 5, Part 2, Page 44 5/1/2003 Example 2 Graphic Artist Group Original Process: Need Graphic Artist Design Group: Assignment Dept G1 G2 G3 G4 G5 Design Graphic Artist Printing Group: Assignment Dept P1 P2 P3 P4 P5 Inspection Good Products Defective Products More defects are generated on the second cycle! Sample

45. Copyright © 1995-2003, Dennis J. Frailey, All Rights Reserved Day 5, Part 2, Page 45 5/1/2003 Re-engineered Process for Graphic Artist Group Improved Process: Need Assignment Dept G1 G2 G3 G4 G5 Design P1 P2 P3 P4 P5 Inspection Good Products Defective Products Sample

46. Copyright © 1995-2003, Dennis J. Frailey, All Rights Reserved Day 5, Part 2, Page 46 5/1/2003 Re-engineered Process for Graphic Artist Group Improved Process: Need Assignment Dept G1 G2 G3 G4 G5 Design P1 P2 P3 P4 P5 Inspection Good Products Defective Products By tying a graphic designer to a printer for the whole job, defects were repaired quickly and good products had greatly reduced cycle time. Sample

47. Copyright © 1995-2003, Dennis J. Frailey, All Rights Reserved Day 5, Part 2, Page 47 5/1/2003 Problem: there are many delays during software test because of requirements errors and changes –Rework to fix code to match new requirements Analysis: we didn’t have time to examine and rework the requirements earlier Example 3 SW Process Takes Too Long

48. Copyright © 1995-2003, Dennis J. Frailey, All Rights Reserved Day 5, Part 2, Page 48 5/1/2003 Process changes: –ADD a requirements inspection –ADD time in the requirements phase to correct defective requirements –MODIFY the reward system to foster discovery of requirements defects during the requirements phase Improving the SW Process

49. Copyright © 1995-2003, Dennis J. Frailey, All Rights Reserved Day 5, Part 2, Page 49 5/1/2003 Reduced total development time –Modest increment to requirements analysis schedule –Large reduction in debugging time Reduced cost –The number of staff during requirements was smaller than the number during test –The amount of rework during the test phase was smaller so they saves money Results of Re-Engineering to Reduce Rework

50. Copyright © 1995-2003, Dennis J. Frailey, All Rights Reserved Day 5, Part 2, Page 50 5/1/2003 Rethinking The Passing Game Re-engineer the process You must follow the rules But examine the assumptions Hint: it can be done in under 2 seconds!

51. Copyright © 1995-2003, Dennis J. Frailey, All Rights Reserved Day 5, Part 2, Page 51 5/1/2003 What Assumptions were Invalid? Why did we make them?

52. Copyright © 1995-2003, Dennis J. Frailey, All Rights Reserved Day 5, Part 2, Page 52 5/1/2003 How Often do you Need to Re-engineer? Re-engineering is disruptive, so you should not do it too often Conditions that call for re-engineering: –Changed customer environment –Significant new technology –Significant new competitive circumstances –Need to make the process more efficient from the customer’s perspective –Significant new but different business opportunity

53. Copyright © 1995-2003, Dennis J. Frailey, All Rights Reserved Day 5, Part 2, Page 53 5/1/2003 Examples of Successful Re-engineering Federal express vs post office –Who would’ve thought that flying a package to Tennessee and back is faster than trucking it for 200 miles? 10 minute oil change vs car dealer –Someone realized that Service stations seldom provide this service anymore Car dealers are too slow to satisfy customers

54. Copyright © 1995-2003, Dennis J. Frailey, All Rights Reserved Day 5, Part 2, Page 54 5/1/2003 Managing the White Space

55. Copyright © 1995-2003, Dennis J. Frailey, All Rights Reserved Day 5, Part 2, Page 55 5/1/2003 White Space A Fundamental Problem of Of Hierarchical Organizations Too many handoffs between departments, where there is no responsibility at the point of need, only much higher in the organization

56. Copyright © 1995-2003, Dennis J. Frailey, All Rights Reserved Day 5, Part 2, Page 56 5/1/2003 Managing the White Space The “white space” represents all of the parts of your process that nobody is responsible for Or where the responsibility is too far from the day to day process –handoffs between organizations or activities –changes in responsibility –etc.

57. Copyright © 1995-2003, Dennis J. Frailey, All Rights Reserved Day 5, Part 2, Page 57 5/1/2003 The Classic “White Space” Situation 21 43 6 5 87 Organizational Hierarchy 8-step Process for Serving the Customer

58. Copyright © 1995-2003, Dennis J. Frailey, All Rights Reserved Day 5, Part 2, Page 58 5/1/2003 The Classic “White Space” Problem 21 43 6 5 87 Who is responsible for this handoff? Organizational Hierarchy

59. Copyright © 1995-2003, Dennis J. Frailey, All Rights Reserved Day 5, Part 2, Page 59 5/1/2003 The Classic “White Space” Problem 21 43 6 5 87 Organizational Hierarchy Who is responsible for this handoff?

60. Copyright © 1995-2003, Dennis J. Frailey, All Rights Reserved Day 5, Part 2, Page 60 5/1/2003 How Do You Reduce the White Space? Re-design the process to provide optimal flow to the customer –(minimize white space) Re-design the organization to align responsibility directly with the process –(minimize mismatches) Consider the credit approval and graphic artist examples.

61. Copyright © 1995-2003, Dennis J. Frailey, All Rights Reserved Day 5, Part 2, Page 61 5/1/2003 How Do You Manage the White Space? Assign responsibility for interfaces –With authority equal to or greater than that of product development steps –This concept requires rethinking how we assign responsibility and authority Assign overall responsibility for the entire process flow –At a level where day-to-day activity is visible

62. Copyright © 1995-2003, Dennis J. Frailey, All Rights Reserved Day 5, Part 2, Page 62 5/1/2003 White Space Management Software Development Example Microsoft “integrate every day” strategy Interfaces are defined early in the process and placed under change control Mock-ups of the complete system are defined at the start of the project Integration team has control over all interface changes An integration test is run every day

63. Copyright © 1995-2003, Dennis J. Frailey, All Rights Reserved Day 5, Part 2, Page 63 5/1/2003 Effect on Software Developer Your module or function is not complete until it integrates with the rest of the system without introducing any problems If your module fails this test, you must take it back and fix it

64. Copyright © 1995-2003, Dennis J. Frailey, All Rights Reserved Day 5, Part 2, Page 64 5/1/2003 Effect on Software Process Integration and test errors are minimized at the end of the process The product can be “shipped” at any time after the major features are successfully integrated –Additional time, if any, allows for less important features –Features that don’t get done in time wait for the next release

65. Copyright © 1995-2003, Dennis J. Frailey, All Rights Reserved Day 5, Part 2, Page 65 5/1/2003 Summary Simplify the process –Reduce rework –Make processes more consistent –Analyze value-added –Analyze and optimize process flow –Periodically re-engineer the process –but not so often as to be disruptive –Manage the white space

66. Copyright © 1995-2003, Dennis J. Frailey, All Rights Reserved Day 5, Part 2, Page 66 5/1/2003 References Goldratt, Eliyahu M. & Jeff Cox, The Goal, (North River Press, 1984.) Also, Theory of Constraints and It’s Not Luck. Gross and Harris, Fundamentals of Queueing Theory (Wiley). Hammer, Michael & James Champy, Reengineering the Corporation, - A Manifesto for Business Revolution (Harper Collins, 1993.) Swartz, James B., The Hunters and the Hunted, (Portland, Oregon, Productivity Press, 1994) ISBN 1- 56327-043-9.

67. Copyright © 1995-2003, Dennis J. Frailey, All Rights Reserved Day 5, Part 2, Page 67 5/1/2003 Additional References 1. Bartlett, Christopher A. and Sumantra Ghoshal, "Changing the Role of Top Management: Beyond Strategy to Purpose" Harvard Business Review, Nov-Dec 1994 (and Jan-Feb 95, May-Jun 95) 2. Beatty, Richard W. and David O. Ulrich, "Re-Energizing the Mature Organization" Organizational Dynamics, date unknown, sometime in 1991 or 1992 3. Belasco, James A., Teaching the Elephant to Dance - Empowering Change in Your Organization, Crown Publishers, 1990 4. Boynton, Andy and Bart Victor "Organizations and Change: A Consultant's View", from a presentation, date unknown, probably Oct 1992 5. Duck, Jeanie Daniel: “Managing Change: The Art of Balancing” Harvard Business Review, Nov-Dec 1993 6. Deming, W. Edwards, Out of the Crisis, MIT, 1982 7. Fiman, Byron: “Accelerating Change” by Implementation Management Associates, Inc, presented by Byron Fiman

68. Copyright © 1995-2003, Dennis J. Frailey, All Rights Reserved Day 5, Part 2, Page 68 5/1/2003 Additional References 8. Frey, Robert, "Empowerment or Else" Harvard Business Review, Sep-Oct 1993 9. Hall, Gene, Jim Rosenthal, and Judy Wade, “How to Make Reengineering Really Work” Harvard Business Review, Nov-Dec 1993 10. Kotter, John P., “Leading Change: Why Transformation Efforts Fail” Harvard Business Review, Mar-Apr 1995 (reprint # 95204) 11. Peters, Tom, “The Tom Peters Seminar - Crazy Times Call for Crazy Organizations” 1994 12. Stevenson, Wayne, President and CEO of Control Systems International, from a lecture in Jan 1995 13. Tichy, Noel M. and David O. Ulrich, "The Leadership Challenge - A Call for the Transformational Leader" Sloan Management Review, Massachusetts Institute of Technology, Fall 1984, Volume 26, Number 1