Presentation is loading. Please wait.

Presentation is loading. Please wait.

Copyright 1995-2009, Dennis J. Frailey CSE7315 – Software Project Management CSE7315 M23 - Version 9.01 SMU CSE 7315 Planning and Managing a Software Project.

Similar presentations


Presentation on theme: "Copyright 1995-2009, Dennis J. Frailey CSE7315 – Software Project Management CSE7315 M23 - Version 9.01 SMU CSE 7315 Planning and Managing a Software Project."— Presentation transcript:

1 Copyright 1995-2009, Dennis J. Frailey CSE7315 – Software Project Management CSE7315 M23 - Version 9.01 SMU CSE 7315 Planning and Managing a Software Project Module 23 Cycle Time Management and Negotiation

2 Copyright 1995-2009, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M23 - Version 9.01 2 Objectives of This Module  To introduce basic concepts of cycle time management  To discuss negotiation of estimates

3 Copyright 1995-2009, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M23 - Version 9.01 3 Introduction to Cycle Time Management Cycle time is addressed in more detail in the course CSE8314. Here we present some simple tips for cycle time management. Cycle time is addressed in more detail in the course CSE8314. Here we present some simple tips for cycle time management.

4 Copyright 1995-2009, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M23 - Version 9.01 4 Detailed Planning Process Estimate Size Estimate Effort and Cost Estimate Schedule Evaluate Source Information Statement of Work Requirements Constraints Standards Processes History etc. WBSSize Effort & Cost Schedule OK Complete Detailed Planning Revise & Negotiate Not OK

5 Copyright 1995-2009, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M23 - Version 9.01 5 What Is Cycle Time?  The amount of time it takes from the beginning of your project to the end  You must count everything, including delays, waits, etc. Looking at cycle time helps you see causes for schedule slips that you might miss using other methods

6 Copyright 1995-2009, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M23 - Version 9.01 6 What Makes Cycle Time High?  Excessive inventory or work in process (WIP) –Work waiting around but not being done –Higher overhead, longer delays  Process flow variability –Excessive waiting and long queues  Complexity and inefficiency of processes –Redundant and unnecessary steps

7 Copyright 1995-2009, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M23 - Version 9.01 7 3 Steps to Cycle Time Reduction 1. Reduce variability 2. Simplify the process 3. Reduce WIP N A V Y

8 Copyright 1995-2009, Dennis J. Frailey CSE7315 – Software Project Management CSE7315 M23 - Version 9.01 Reducing Variability Too often, we create variability -- mistakenly thinking we are improving performance For example, expediting some parts of the work due to “priorities” Too often, we create variability -- mistakenly thinking we are improving performance For example, expediting some parts of the work due to “priorities”

9 Copyright 1995-2009, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M23 - Version 9.01 9 0510152025303540455055606570 0 10 20 30 PERCENT EXPEDITED When we expedite a task, other tasks are delayed In some cases, each task waits until it is expedited before it moves at all When we expedite a task, other tasks are delayed In some cases, each task waits until it is expedited before it moves at all Cycle Time Multiplier for Unexpedited Tasks Expediting is Bad for Cycle Time

10 Copyright 1995-2009, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M23 - Version 9.01 10 BAU 7142128 CYCLE TIME (DAYS) Number Of Tasks Expedited Tasks Delinquent Tasks 7142128 Number Of Tasks CYCLE TIME (DAYS) With managed priorities, you improve the normal case and reduce the need for “priority tasks” Managed Expediting

11 Copyright 1995-2009, Dennis J. Frailey CSE7315 – Software Project Management CSE7315 M23 - Version 9.01 Inefficient Processes Often our processes are inefficient because of factors that we have not paid attention to

12 Copyright 1995-2009, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M23 - Version 9.01 12 Examples of Inefficient 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

13 Copyright 1995-2009, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M23 - Version 9.01 13 Waste Due to Inefficient Processes and Procedures Cycle time is wasted on such activities as: Real Work Conversion Correcting Languages  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

14 Copyright 1995-2009, Dennis J. Frailey CSE7315 – Software Project Management CSE7315 M23 - Version 9.01 Reducing Work In Process (WIP) The Key is Smooth Flow

15 Copyright 1995-2009, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M23 - Version 9.01 15 Smooth Flow  The ideal process flows smoothly, like a train running on tracks.  Note: tracks are empty most of the time

16 Copyright 1995-2009, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M23 - Version 9.01 16 Uneven Flow  The typical process runs unevenly, like vehicles on a city street  Lots of entrances and exits  Vehicles of different sizes and speeds  Some drivers are uncertain of what they want to do  Lots of stoplights to “control” the flow (mainly to prevent collisions)  Streets are usually crowded (with WIP!)

17 Copyright 1995-2009, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M23 - Version 9.01 17 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 We should work to increase productivity This may require decreasing utilization! Utilization vs Productivity

18 Copyright 1995-2009, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M23 - Version 9.01 18 EFFECTIVE UTILIZATION CYCLE TIME Running assets at a high effective utilization requires a costly cycle time trade off For details of theory, see Gross and Harris in reference list. 100% Why Reduce Utilization of Critical Resources?

19 Copyright 1995-2009, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M23 - Version 9.01 19 Other Cycle Time Hints

20 Copyright 1995-2009, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M23 - Version 9.01 20  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 Practitioners May Not See Problems and Opportunities

21 Copyright 1995-2009, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M23 - Version 9.01 21 Just as athletes rely on coaches, software engineers need to learn to trust in others to observe and help them do better Egoless Programming Independent Observers See Problems and Opportunities  They are not so busy getting the job done to see how they might improve it

22 Copyright 1995-2009, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M23 - Version 9.01 22 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 -- and improve the process the way you would improve a program

23 Copyright 1995-2009, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M23 - Version 9.01 23 Examples of Software Cycle Time Techniques  “Just-in-time” training  Plan testing / test equipment 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

24 Copyright 1995-2009, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M23 - Version 9.01 24 Examples of Commonly Found Cycle Time Obstacles  Poor communication /cooperation between software development and the rest of the organization  Poor management of unstable requirements, algorithms & interfaces  Contention for test assets -- need better planning, assets allocated to software test  Poorly qualified subcontractors

25 Copyright 1995-2009, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M23 - Version 9.01 25 More Cycle Time Obstacles  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 or effective integration of the new tools with other tools

26 Copyright 1995-2009, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M23 - Version 9.01 26 Negotiating

27 Copyright 1995-2009, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M23 - Version 9.01 27 Detailed Planning Process Estimate Size Estimate Effort and Cost Estimate Schedule Evaluate Source Information Statement of Work Requirements Constraints Standards Processes History etc. WBSSize Effort & Cost Schedule OK Complete Detailed Planning Revise & Negotiate Not OK

28 Copyright 1995-2009, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M23 - Version 9.01 28 If the Plan is Not Feasible  DO examine assumptions and data –initial cost estimates are often very conservative  DO examine risk/cost tradeoffs to see if you can accept a higher risk  DO make a list of barriers that must be removed in order to make the estimate fit the constraints

29 Copyright 1995-2009, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M23 - Version 9.01 29 “The quickest way to make a project uneconomical is by doubling the resources needed and using the cover story that you need to prevent failures.” Adams, The Dilbert Principle “The quickest way to make a project uneconomical is by doubling the resources needed and using the cover story that you need to prevent failures.” Adams, The Dilbert Principle If the Plan is Not Feasible  DO NOT “cave in” & lower everything to meet a target cost or schedule

30 Copyright 1995-2009, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M23 - Version 9.01 30 The Negotiation Process We MUST have the lowest bid!!! We will, boss!!! Management will try to trim the budget by sending an army of low-ranking, clueless budget analysts to interview you and ask “insightful” questions. Adams, The Dilbert Principle

31 Copyright 1995-2009, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M23 - Version 9.01 31 Re-think key factors Spreadsheet for estimating This will never satisfy the cost goal!???!

32 Copyright 1995-2009, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M23 - Version 9.01 32 Identify Opportunities and Barriers Barriers Opportunities to Cut

33 Copyright 1995-2009, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M23 - Version 9.01 33 Negotiate If they will cut back on the reviews and... Well, I’ll think about it

34 Copyright 1995-2009, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M23 - Version 9.01 34 Beware... Estimates are Never Perfect

35 Copyright 1995-2009, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M23 - Version 9.01 35 Estimating Accuracy vs. Phase 0 0.5 1 1.5 2 2.5 3 3.5 4 4.5 FeasibilityPlansDesignDetailed Design Code and Test Release Upper Limit Actual Lower Limit Typical Estimates

36 Copyright 1995-2009, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M23 - Version 9.01 36 Some Opportunities to Offer  Plan to re-estimate after important milestones  Prioritize requirements and promise to deliver the top ones by the deadline –Incremental deliveries

37 Copyright 1995-2009, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M23 - Version 9.01 37 Some Opportunities to Offer (continued)  Put a high cost on requirements changes  Look at each “adjustment factor” in Cocomo as an opportunity  Get training for everyone

38 Copyright 1995-2009, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M23 - Version 9.01 38 Some Typical Barriers to Faster Schedule or Lower Cost  Lack of adequate resources –Software, tools, people, etc.  Slow approval cycles for required resources  Poor coordination with other disciplines, other companies, etc.  Customers, peers in other disciplines, and managers who don’t understand software development very well

39 Copyright 1995-2009, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M23 - Version 9.01 39 Some Difficult Barriers to Faster Schedule or Lower Cost  Irascible and irrational customers & managers  Intentional barriers –Competitors, etc –Political constraints

40 Copyright 1995-2009, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M23 - Version 9.01 40 Negotiating Tip...  The more facts you have, the better off you are during negotiation  Get them to review your estimate –Sometimes they don’t bother  Be well prepared to explain it

41 Copyright 1995-2009, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M23 - Version 9.01 41 Several Iterations are Likely  Identify the factors that affect the cost and schedule –Experience levels, stability levels, etc.  Examine sensitivity of the results to various factors  Examine historical data to make a better picture of probable events  Don’t put too much faith in the accuracy of models That’s why you should use a spreadsheet or other estimating tool!

42 Copyright 1995-2009, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M23 - Version 9.01 42 Module Summary - I  Cycle time problems are usually traced to three factors: –Variability in processes –Inefficient processes –Excessive work in process (WIP)  Many cycle time improvements require looking at the whole process instead of just individual steps of the process

43 Copyright 1995-2009, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M23 - Version 9.01 43 Module Summary - II  When the plans show that there is not enough time or money to do the job, NEGOTIATE - don’t CAPITULATE  Having the facts will help you in the negotiation process  Expect several iterations

44 Copyright 1995-2009, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M23 - Version 9.01 44 END OF MODULE 23

45 Copyright 1995-2009, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M23 - Version 9.01 45 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, pp 10-11, 101-102  Swartz, James B., The Hunters and the Hunted, (Portland, Oregon, Productivity Press, 1994) ISBN 1-56327-043-9


Download ppt "Copyright 1995-2009, Dennis J. Frailey CSE7315 – Software Project Management CSE7315 M23 - Version 9.01 SMU CSE 7315 Planning and Managing a Software Project."

Similar presentations


Ads by Google