Presentation is loading. Please wait.

Presentation is loading. Please wait.

Copyright 1995-2009, Dennis J. Frailey CSE7315 – Software Project Management CSE7315 M22 - 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 M22 - 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 M22 - Version 9.01 SMU CSE 7315 Planning and Managing a Software Project Module 22 Software Scheduling, Part 2

2 Copyright 1995-2009, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M22 - Version 9.01 2 Objectives of This Module  To complete the discussion of how to develop a detailed schedule –Critical Path Analysis –GANTT Charts –Network Charts  To discuss methods of optimizing and managing a schedule –Critical Chain Analysis –Slack Management techniques

3 Copyright 1995-2009, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M22 - Version 9.01 3 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

4 Copyright 1995-2009, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M22 - Version 9.01 4 Developing a PERT Chart Step 2 - Task Duration  Lay out a time line at the bottom of the board  For each task, estimate its duration and write that information on the post-it note. –Can be minimum feasible duration or expected duration based on availability of resources  Place each task in its appropriate position relative to the time line

5 Copyright 1995-2009, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M22 - Version 9.01 5 Developing a PERT Chart Step 2 - Task Duration (continued)  Proper placement shows earliest start and end date for each task 20 weeks 8 weeks Minimum total time for whole activity is 26 weeks JFMAMJJASOND 6 wks 8 weeks 12 weeks 26 weeks

6 Copyright 1995-2009, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M22 - Version 9.01 6 What to Learn After Durations are Added  The first task to focus on is the very last task –Will it complete by the project deadline?  If not, how can you make the whole schedule shorter?  The answer starts with determining the Critical Path

7 Copyright 1995-2009, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M22 - Version 9.01 7 The Critical Path is... … the longest calendar path through the schedule from the first to the last activity The Critical Path in the above example is A,C,D Task A (5 weeks) Task C (3 weeks) Task B (3 weeks) Task D (4 weeks) Task E (2 weeks)

8 Copyright 1995-2009, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M22 - Version 9.01 8 The Critical Path is... … the path that must be shortened in order to shorten the whole schedule … the path that drives schedule slips –If a critical path task slips, the whole schedule slips … the riskiest part of the schedule Be especially wary when the critical path involves dependency on external tasks that you do not control!

9 Copyright 1995-2009, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M22 - Version 9.01 9  If the schedule is small, “eyeball” and determine which path is the longest.  Otherwise a tool can be used  Critical Path => min possible schedule  See references for more info Critical Path Tasks Non-Critical Path Tasks Developing a PERT Chart Step 3 - Determining the Critical Path 6 weeks 3 weeks 5 weeks

10 Copyright 1995-2009, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M22 - Version 9.01 10 What if the Minimum Schedule is Too Long?  You must find a way to cut the schedule  Begin with tasks on the critical path –Try to divide them into smaller tasks that can be done simultaneously –Assign more resources so you can do them faster  Note that when you do this you might create a different critical path

11 Copyright 1995-2009, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M22 - Version 9.01 11 Developing a PERT Chart Step 4 - Resource Requirements  Determine the resource requirements of each task: –Equipment, Facilities, etc. –Key personnel –Total labor effort (staff days, etc) –May also show minimum and maximum reasonable allocations, i.e., 8 staff weeks:  minimum 2 weeks (4 people)  maximum 8 weeks (1 person)

12 Copyright 1995-2009, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M22 - Version 9.01 12 Resources  Write this information on the index card or post-it note  Vary labor totals or types of personnel assigned to different tasks in order to meet schedule needs 8 staff weeks: 2 weeks, 4 people 8 staff weeks: 4 weeks, 2 people 8 staff weeks: 2 weeks, 3 senior people These options may reduce the critical path or even remove this task from the critical path These options may reduce the critical path or even remove this task from the critical path

13 Copyright 1995-2009, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M22 - Version 9.01 13 Scheduling Tools can... … find critical path/shortest schedule … find minimum and total effort levels … do simulation of schedule to determine likely outcomes when exact duration are indefinite

14 Copyright 1995-2009, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M22 - Version 9.01 14 Scheduling Tools Can … (continued) … assist in “what if” analysis of possible alternatives … revise schedules with minimal effort Sample tools: Microsoft Project®, Primavera®

15 Copyright 1995-2009, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M22 - Version 9.01 15 “Schedule from the Back” concept Minimal execution times for each task Assuming adequate staff, task E must be started at least 7 weeks before final integration, whereas task A must be started at least 11 weeks before! Using PERT Charts to Decide on Development Sequence Final Integration 4 weeks C 1 week D 3 weeks F 4 weeks E 2 weeks B 6 weeks A 2 weeks

16 Copyright 1995-2009, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M22 - Version 9.01 16 Shopload Shows Resource Needs and Allocation by Time Period

17 Copyright 1995-2009, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M22 - Version 9.01 17 Suggested Notation for Post-it Notes Yellow –Normal Tasks Pink or Red –External Tasks that You Depend On Blue –External Tasks that Depend on You

18 Copyright 1995-2009, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M22 - Version 9.01 18 Schedule for Project P (sample) JFMAMJJASOND

19 Copyright 1995-2009, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M22 - Version 9.01 19  Gizmo hardware must arrive by June 1 –We must watch their schedule  Joe and Mary must be available 100% for this project  Integration must wait until Sept 15  Programmers must be available on March 1  At least three test sets must be available during the month of August Critical Dependencies, Issues, Assumptions, and Lessons Learned (sample)

20 Copyright 1995-2009, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M22 - Version 9.01 20 Gantt Charts

21 Copyright 1995-2009, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M22 - Version 9.01 21 GANTT Charts  These are devised from some of the same data used in a PERT chart, but show the relative time phasing of the tasks instead of the dependencies  Each “activity” box is sized to be proportional to the length of time it takes  The boxes are lined up, usually in the order of execution, to show what is happening at what time

22 Copyright 1995-2009, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M22 - Version 9.01 22 Sample Gantt Chart Vertical line represents current date Task 2 Task 3 Task 6 Task 5 Task 1 Task 7 Task 4

23 Copyright 1995-2009, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M22 - Version 9.01 23 Task 6 Task 5 Task 7 Does Task 6 depend on Task 5? Can Task 5 finish on time? Gantt Chart does NOT tell you... … task dependencies … significance or impact of schedule slips … whether it is realistic to expect you to meet the schedule … critical path

24 Copyright 1995-2009, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M22 - Version 9.01 24 Network Charts

25 Copyright 1995-2009, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M22 - Version 9.01 25 JanFebMarAprMayJunJulAug Network Chart -- Combining the Pert and Gantt  Horizontal width indicates schedule length  Arcs indicate dependencies  Horizontal position indicates scheduled time and task parallelism Task A Task C Task B Task D Task E

26 Copyright 1995-2009, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M22 - Version 9.01 26 Network Chart Summary  Tells you the duration of tasks and their interdependencies.  Shows Critical Path  Can be color coded to show different parts of the project –Software in blue, mechanical in red, etc.  But it still cannot tell you if the schedule is realistic

27 Copyright 1995-2009, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M22 - Version 9.01 27 Possible Exam Questions  Explain the Advantages and Drawbacks of PERT charts and GANTT charts  Discuss how a Network Chart combines the advantages of PERT and GANTT charts

28 Copyright 1995-2009, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M22 - Version 9.01 28 Possible Exam Questions (continued)  Discuss what information is NOT shown by a PERT chart  Discuss what information is NOT shown by a GANTT chart  Discuss what information is NOT shown by a Network chart

29 Copyright 1995-2009, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M22 - Version 9.01 29 Project Management and Scheduling Tools  Most such tools can show a PERT or GANTT chart  More capable tools will show a network chart, which is hard to do by hand But tools take a lot of work to enter data and the data changes a lot in the early steps of detailed scheduling

30 Copyright 1995-2009, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M22 - Version 9.01 30 Recommendations Regarding Management/Scheduling Tools  Do a PERT chart by hand and work through the fundamental relationships  Then use a tool after things have settled down  Select a tool carefully –Some cannot handle the complexity of a very large project –But the most capable tools are harder to use

31 Copyright 1995-2009, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M22 - Version 9.01 31 Using Network or Pert Charts to Establish a Schedule Earliest Completion Date –Tells you how soon you can complete –Tells you the earliest you can start each task Latest Start Date –Tells you how late you can start and still meet the deadline –Tells you the latest you can start each task

32 Copyright 1995-2009, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M22 - Version 9.01 32 Using Network or Pert Charts to Establish a Schedule (continued) Critical Chain Analysis –Adds analysis of critical resource needs –Can help you manage to meet short cycle time

33 Copyright 1995-2009, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M22 - Version 9.01 33 Earliest Completion Date A, C, E, F can slip without hurting schedule E 4 weeks Final Integration 4 weeks G 3 weeks D 6 weeks A 3 weeks B 4 weeks C 2 weeks F 2 wks 17 weeks min. Earliest Start Date Later Start Date

34 Copyright 1995-2009, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M22 - Version 9.01 34 Latest Start Date A, C, E, F can start late without hurting schedule B, D, G, Final must start as shown, since on critical path Final Integration 4 weeks G 3 weeks D 6 weeks A 2 weeks B 4 weeks C 2 weeks F 2 wk E 4 weeks 17 weeks min. Earlier Start Date Latest Start Date

35 Copyright 1995-2009, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M22 - Version 9.01 35 Critical Chain Analysis & Slack Management

36 Copyright 1995-2009, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M22 - Version 9.01 36  A critical resource is a resource required on each of two or more tasks –A piece of equipment –An individual with unique skills  A critical resource can sometimes be used by only one task at a time  If shared, each task gets only part time use ? You are essential to my project My project will fail without you Critical Resources

37 Copyright 1995-2009, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M22 - Version 9.01 37  If two tasks need a resource, one must give it up or both must run slower  But it is tempting to fantasize that you can share resources without such high waste Sharing a Resource Means Less Efficiency Percent UseAvailabilityWaste 100%85%15% 50%+50%40%+40%20% 33%+33%+33%25%+25%+25%25% 25%+....17.5%+....30%

38 Copyright 1995-2009, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M22 - Version 9.01 38 Using Critical Resources  If the resource is critical, it is also known as a constraint  The fundamental rule of constraint management is that you should maximize the efficiency of the constraint  Which means you should avoid overusing constraints and wasting time on inefficient sharing

39 Copyright 1995-2009, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M22 - Version 9.01 39 If Task B needs a resource that is also needed by Task A then Task B is on the Critical Chain The Critical Chain  The critical chain consists of all tasks using resources that are needed on the critical path Task A (5 weeks) Task C (3 weeks) Task B (3 weeks) Task D (4 weeks) Task E (2 weeks)

40 Copyright 1995-2009, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M22 - Version 9.01 40 Critical Chain Analysis  Start with Latest Start Date schedule  Mark critical path tasks as “on the critical chain” & identify resources needed for these tasks  If also needed elsewhere in parallel tasks, mark those tasks as “critical chain” tasks  Reschedule those tasks earlier, so there is no conflict of resources  This may change the critical path!

41 Copyright 1995-2009, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M22 - Version 9.01 41 Conventions for Critical Chain Analysis Conflict Earlier Start Date Latest possible Start Date Normal Tasks Critical Path and Critical Chain but Not Critical Path Critical Path Tasks

42 Copyright 1995-2009, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M22 - Version 9.01 42 Example of Critical Chain Analysis G and F need the same critical resource So F and its predecessors (E, C) must be started sooner A 3 weeks Final Integration 4 weeks G 3 weeks D 6 weeks B 4 weeks E 4 weeks C 2 weeks F 2 wk 17 weeks min.

43 Copyright 1995-2009, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M22 - Version 9.01 43 A Further Example A and C cannot proceed in parallel This changes the critical path and lengthens the schedule! H 4 wks G 3 wks A 3 wks E 4 wks C 2 wks F 2 wks B 4 wks D 6 wks 18 weeks minimum Suppose A and C need the Same Critical Resource

44 Copyright 1995-2009, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M22 - Version 9.01 44 Other Schedule Management Techniques  Do more careful monitoring of critical path and critical chain tasks  Start critical chain tasks as soon as you can - to provide maximum risk control  DO NOT allow people to include slack time in their task schedules. All slack should be held in reserve by a higher level manager

45 Copyright 1995-2009, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M22 - Version 9.01 45 Example of Slack Management Problem Final Integration 4 weeks G 3 weeks E 4 weeks C 2 weeks Final Integration 4 weeks G 3 weeks E 4 weeks C 2 weeks Plan: C and E allow slack to reduce risk Actual: C and E wait until last possible minute to start

46 Copyright 1995-2009, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M22 - Version 9.01 46 What Might Really Happen Final Integration 4 weeks G 5 weeks E 4 weeks C 2.5 weeks Reality: C and G slip a little bit … C’s slip is absorbed by E’s slack But G’s slip causes the whole project to slip 2 weeks

47 Copyright 1995-2009, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M22 - Version 9.01 47 Slack Management Final Integration 4 weeks G 5 weeks E 4 weeks C 2.5 weeks Actual - Slack can be applied to any task that slips, so the project stays on schedule Plan: C and E have no slack Final Integration 4 weeks G 3 weeks E 4 weeks C 2 weeks Slack - 4 wks

48 Copyright 1995-2009, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M22 - Version 9.01 48 Module Summary - I  Adding task duration to a basic PERT shows critical path and shortest possible schedule length - but not relative timing  Critical path analysis identifies what tasks must be shortened to shorten the overall schedule  Adding resource requirements enables you to decide on sequencing and when to schedule tasks and resources

49 Copyright 1995-2009, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M22 - Version 9.01 49 Module Summary - II  GANTT shows relative timing but not dependencies, flow  Network chart shows both, but requires a more capable tool  Critical Chain shows resource conflicts between critical path tasks and other tasks

50 Copyright 1995-2009, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M22 - Version 9.01 50 Module Summary - III  Critical Resources must be managed to avoid impact on critical path  Critical Chain Analysis shows which tasks must be started earlier in order to avoid resource conflicts  Slack Management gives maximum risk control and shortest cycle time

51 Copyright 1995-2009, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M22 - Version 9.01 51 END OF MODULE 22

52 Copyright 1995-2009, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M22 - Version 9.01 52 References 1) Brassard, Michael, The Memory Jogger Plus+, Goal/QPC, Methuen MA, 1989. 2) Goldratt, Eliyahu M. & Jeff Cox, The Goal, (North River Press, 1984.) Also Theory of Constraints and It’s Not Luck. 3) Thayer, Richard H., ed., Software Engineering Project Management, IEEE Computer Society Press, 1994. 4) U. of West Florida, PERT Home page, http://www.uwf.edu/~coehelp/studenta ccounts/rnew/perthome.html

53 Copyright 1995-2009, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M22 - Version 9.01 53 Critical Path References  http://pmbook.ce.cmu.edu/10_Fundament al_Scheduling_Procedures.html http://pmbook.ce.cmu.edu/10_Fundament al_Scheduling_Procedures.html  Kaufman, A, Critical Path Method, Routledge (1969), ISBN 978-0677018805

54 Copyright 1995-2009, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M22 - Version 9.01 54 Addendum How to Develop a More Detailed PERT

55 Copyright 1995-2009, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M22 - Version 9.01 55 Developing a Detailed PERT Top Down Approaches  Start with top level process for each major activity -- draw PERT based on known dependencies An activity with more complex dependencies PrototypeFinal DesignBuildDesign Customer Assessment Marketing Review A simple activity with linear dependencies PrototypeFinal DesignBuildDesign Keyboard

56 Copyright 1995-2009, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M22 - Version 9.01 56 Developing a PERT From The Top Down (continued)  Then, for each process step, decompose into sub-activities PrototypeFinal DesignBuildDesign Keyboard..... Select Components Design Interfaces.....  At each level, determine dependencies between the sub-activities at that level

57 Copyright 1995-2009, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M22 - Version 9.01 57 At Lower Levels There Are Two Options 1) Limit dependencies at each level to those within that level...

58 Copyright 1995-2009, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M22 - Version 9.01 58 A More Powerful Option 2) Flow dependencies down from higher level and determine dependencies between tasks at each lower level from different higher level activities. I.e., determine all dependencies with other tasks, regardless of whether they are part of your activity or someone else’s......

59 Copyright 1995-2009, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M22 - Version 9.01 59 Developing a PERT from the Bottom Up  At the bottom level, determine all dependencies with other tasks, regardless of whether they are part of your activity or someone else’s Note that you are only determining dependencies related to your specific activity.....

60 Copyright 1995-2009, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M22 - Version 9.01 60 Developing a PERT from the Bottom Up (continued)  Do the same for other activities (or the people in charge of them should do this).....

61 Copyright 1995-2009, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M22 - Version 9.01 61 Developing a PERT from the Bottom Up (continued)  Then move up a level and coalesce dependencies from lower level tasks.....

62 Copyright 1995-2009, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M22 - Version 9.01 62 Developing a PERT from the Bottom Up (continued)  Continue this until you get to the top  Then you will have a complete list of task dependencies

63 Copyright 1995-2009, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M22 - Version 9.01 63 Developing a PERT from the Bottom Up (continued) NOTE: Many PERT tools do not support dependencies at the lower levels except within a given higher level activity (i.e., like option 1 on prior slides). –For these cases you must determine the higher level dependencies between activities by hand –and could miss some of them as a result

64 Copyright 1995-2009, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M22 - Version 9.01 64 Alternative Bottom-up Approach  Start with bottom level tasks  Determine all dependencies  Decide which ones to group together based on logical dependency flows, strong dependencies  Move up a level and repeat  Continue until you get a comfortable “top level” map

65 Copyright 1995-2009, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M22 - Version 9.01 65 Note on Alternative Bottom-up Approach This approach may produce surprising results - combining things that did not initially seem appropriate to combine -- it is sometimes a good way to define teams on the project as well

66 Copyright 1995-2009, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M22 - Version 9.01 66 Sample Result

67 Copyright 1995-2009, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M22 - Version 9.01 67 Iterate the Process  Whether you go bottom up or top down, your initial results may identify problems, inconsistencies, impossibilities, and unknowns that need to be resolved  Resolution will result in redoing the PERT  For that reason, a good tool is recommended to automate the process NOTE: normally you will not iterate the basic PERT, but will iterate a more complete PERT after developing the more advanced forms of PERT


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

Similar presentations


Ads by Google