1. CSE 7315 - SW Project Management / Module 22 - Software Scheduling, Part 2 Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved CSE7315M22 Slide 1 September 12, 2004 SMU CSE 7315 / NTU SE 584-N Planning and Managing a Software Project Module 22 Software Scheduling, Part 2

2. CSE7315M22 Slide # 2 September 12, 2004 CSE 7315 - SW Project Management / Module 22 - Software Scheduling, Part 2 Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved 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. CSE7315M22 Slide # 3 September 12, 2004 CSE 7315 - SW Project Management / Module 22 - Software Scheduling, Part 2 Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved 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. CSE7315M22 Slide # 4 September 12, 2004 CSE 7315 - SW Project Management / Module 22 - Software Scheduling, Part 2 Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved 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. CSE7315M22 Slide # 5 September 12, 2004 CSE 7315 - SW Project Management / Module 22 - Software Scheduling, Part 2 Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved 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. CSE7315M22 Slide # 6 September 12, 2004 CSE 7315 - SW Project Management / Module 22 - Software Scheduling, Part 2 Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved 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. CSE7315M22 Slide # 7 September 12, 2004 CSE 7315 - SW Project Management / Module 22 - Software Scheduling, Part 2 Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved 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. CSE7315M22 Slide # 8 September 12, 2004 CSE 7315 - SW Project Management / Module 22 - Software Scheduling, Part 2 Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved 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. CSE7315M22 Slide # 9 September 12, 2004 CSE 7315 - SW Project Management / Module 22 - Software Scheduling, Part 2 Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved If the schedule is small, “eyeball” and determine which path is the longest. Otherwise a tool can be used Critical Path => min possible schedule Critical Path Tasks Non-Critical Path Tasks Developing a PERT Chart Step 3 - Determining the Critical Path 6 weeks 3 weeks 5 weeks

10. CSE7315M22 Slide # 10 September 12, 2004 CSE 7315 - SW Project Management / Module 22 - Software Scheduling, Part 2 Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved 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. CSE7315M22 Slide # 11 September 12, 2004 CSE 7315 - SW Project Management / Module 22 - Software Scheduling, Part 2 Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved 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. CSE7315M22 Slide # 12 September 12, 2004 CSE 7315 - SW Project Management / Module 22 - Software Scheduling, Part 2 Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved 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. CSE7315M22 Slide # 13 September 12, 2004 CSE 7315 - SW Project Management / Module 22 - Software Scheduling, Part 2 Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved 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. CSE7315M22 Slide # 14 September 12, 2004 CSE 7315 - SW Project Management / Module 22 - Software Scheduling, Part 2 Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Scheduling Tools Can … (continued) … assist in “what if” analysis of possible alternatives … revise schedules with minimal effort Sample tools: Microsoft Project®, Primavera®

15. CSE7315M22 Slide # 15 September 12, 2004 CSE 7315 - SW Project Management / Module 22 - Software Scheduling, Part 2 Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved “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. CSE7315M22 September 12, 2004 CSE 7315 - SW Project Management / Module 22 - Software Scheduling, Part 2 Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Shopload Shows Resource Needs and Allocation by Time Period

17. CSE7315M22 Slide # 17 September 12, 2004 CSE 7315 - SW Project Management / Module 22 - Software Scheduling, Part 2 Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved 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. CSE7315M22 Slide # 18 September 12, 2004 CSE 7315 - SW Project Management / Module 22 - Software Scheduling, Part 2 Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Schedule for Project P (sample) JFMAMJJASOND

19. CSE7315M22 Slide # 19 September 12, 2004 CSE 7315 - SW Project Management / Module 22 - Software Scheduling, Part 2 Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved 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. CSE7315M22 Slide # 20 September 12, 2004 CSE 7315 - SW Project Management / Module 22 - Software Scheduling, Part 2 Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Gantt Charts

21. CSE7315M22 Slide # 21 September 12, 2004 CSE 7315 - SW Project Management / Module 22 - Software Scheduling, Part 2 Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved 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. CSE7315M22 Slide # 22 September 12, 2004 CSE 7315 - SW Project Management / Module 22 - Software Scheduling, Part 2 Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Sample Gantt Chart Vertical line represents current date Task 2 Task 3 Task 6 Task 5 Task 1 Task 7 Task 4

23. CSE7315M22 Slide # 23 September 12, 2004 CSE 7315 - SW Project Management / Module 22 - Software Scheduling, Part 2 Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved A More Advanced Form of Gantt Chart Height of box indicates number of people working on the activity Width of box indicates length of activity Task 2 Task 1 Task 3

24. CSE7315M22 Slide # 24 September 12, 2004 CSE 7315 - SW Project Management / Module 22 - Software Scheduling, Part 2 Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved 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

25. CSE7315M22 Slide # 25 September 12, 2004 CSE 7315 - SW Project Management / Module 22 - Software Scheduling, Part 2 Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Network Charts

26. CSE7315M22 Slide # 26 September 12, 2004 CSE 7315 - SW Project Management / Module 22 - Software Scheduling, Part 2 Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved 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

27. CSE7315M22 Slide # 27 September 12, 2004 CSE 7315 - SW Project Management / Module 22 - Software Scheduling, Part 2 Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved 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

28. CSE7315M22 Slide # 28 September 12, 2004 CSE 7315 - SW Project Management / Module 22 - Software Scheduling, Part 2 Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved 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

29. CSE7315M22 Slide # 29 September 12, 2004 CSE 7315 - SW Project Management / Module 22 - Software Scheduling, Part 2 Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved 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

30. CSE7315M22 Slide # 30 September 12, 2004 CSE 7315 - SW Project Management / Module 22 - Software Scheduling, Part 2 Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved 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

31. CSE7315M22 Slide # 31 September 12, 2004 CSE 7315 - SW Project Management / Module 22 - Software Scheduling, Part 2 Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved 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

32. CSE7315M22 Slide # 32 September 12, 2004 CSE 7315 - SW Project Management / Module 22 - Software Scheduling, Part 2 Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved 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

33. CSE7315M22 Slide # 33 September 12, 2004 CSE 7315 - SW Project Management / Module 22 - Software Scheduling, Part 2 Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved 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

34. CSE7315M22 Slide # 34 September 12, 2004 CSE 7315 - SW Project Management / Module 22 - Software Scheduling, Part 2 Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved 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

35. CSE7315M22 Slide # 35 September 12, 2004 CSE 7315 - SW Project Management / Module 22 - Software Scheduling, Part 2 Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved 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

36. CSE7315M22 Slide # 36 September 12, 2004 CSE 7315 - SW Project Management / Module 22 - Software Scheduling, Part 2 Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Critical Chain Analysis & Slack Management

37. CSE7315M22 Slide # 37 September 12, 2004 CSE 7315 - SW Project Management / Module 22 - Software Scheduling, Part 2 Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved 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

38. CSE7315M22 Slide # 38 September 12, 2004 CSE 7315 - SW Project Management / Module 22 - Software Scheduling, Part 2 Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved 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%

39. CSE7315M22 Slide # 39 September 12, 2004 CSE 7315 - SW Project Management / Module 22 - Software Scheduling, Part 2 Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved 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

40. CSE7315M22 Slide # 40 September 12, 2004 CSE 7315 - SW Project Management / Module 22 - Software Scheduling, Part 2 Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved 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)

41. CSE7315M22 Slide # 41 September 12, 2004 CSE 7315 - SW Project Management / Module 22 - Software Scheduling, Part 2 Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Critical Chain Analysis Start with Latest Start Date schedule Mark critical path tasks as “on the critical chain” & identify resources needed for these tasks

42. CSE7315M22 Slide # 42 September 12, 2004 CSE 7315 - SW Project Management / Module 22 - Software Scheduling, Part 2 Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Critical Chain Analysis (continued) 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!

43. CSE7315M22 Slide # 43 September 12, 2004 CSE 7315 - SW Project Management / Module 22 - Software Scheduling, Part 2 Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved 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

44. CSE7315M22 Slide # 44 September 12, 2004 CSE 7315 - SW Project Management / Module 22 - Software Scheduling, Part 2 Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved 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.

45. CSE7315M22 Slide # 45 September 12, 2004 CSE 7315 - SW Project Management / Module 22 - Software Scheduling, Part 2 Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved 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

46. CSE7315M22 Slide # 46 September 12, 2004 CSE 7315 - SW Project Management / Module 22 - Software Scheduling, Part 2 Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved 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

47. CSE7315M22 Slide # 47 September 12, 2004 CSE 7315 - SW Project Management / Module 22 - Software Scheduling, Part 2 Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved 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

48. CSE7315M22 Slide # 48 September 12, 2004 CSE 7315 - SW Project Management / Module 22 - Software Scheduling, Part 2 Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved 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

49. CSE7315M22 Slide # 49 September 12, 2004 CSE 7315 - SW Project Management / Module 22 - Software Scheduling, Part 2 Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved 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

50. CSE7315M22 Slide # 50 September 12, 2004 CSE 7315 - SW Project Management / Module 22 - Software Scheduling, Part 2 Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved 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

51. CSE7315M22 Slide # 51 September 12, 2004 CSE 7315 - SW Project Management / Module 22 - Software Scheduling, Part 2 Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved 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

52. CSE7315M22 Slide # 52 September 12, 2004 CSE 7315 - SW Project Management / Module 22 - Software Scheduling, Part 2 Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved 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

53. CSE7315M22 Slide # 53 September 12, 2004 CSE 7315 - SW Project Management / Module 22 - Software Scheduling, Part 2 Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved END OF MODULE 22

54. CSE7315M22 September 12, 2004 CSE 7315 - SW Project Management / Module 22 - Software Scheduling, Part 2 Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved 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/studentaccounts/rn ew/perthome.html

55. CSE7315M22 Slide # 55 September 12, 2004 CSE 7315 - SW Project Management / Module 22 - Software Scheduling, Part 2 Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Addendum How to Develop a More Detailed PERT

56. CSE7315M22 Slide # 56 September 12, 2004 CSE 7315 - SW Project Management / Module 22 - Software Scheduling, Part 2 Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved 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

57. CSE7315M22 Slide # 57 September 12, 2004 CSE 7315 - SW Project Management / Module 22 - Software Scheduling, Part 2 Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved 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

58. CSE7315M22 Slide # 58 September 12, 2004 CSE 7315 - SW Project Management / Module 22 - Software Scheduling, Part 2 Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved At Lower Levels There Are Two Options 1) Limit dependencies at each level to those within that level...

59. CSE7315M22 Slide # 59 September 12, 2004 CSE 7315 - SW Project Management / Module 22 - Software Scheduling, Part 2 Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved 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......

60. CSE7315M22 Slide # 60 September 12, 2004 CSE 7315 - SW Project Management / Module 22 - Software Scheduling, Part 2 Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved 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.....

61. CSE7315M22 Slide # 61 September 12, 2004 CSE 7315 - SW Project Management / Module 22 - Software Scheduling, Part 2 Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Developing a PERT from the Bottom Up (continued) Do the same for other activities (or the people in charge of them should do this).....

62. CSE7315M22 Slide # 62 September 12, 2004 CSE 7315 - SW Project Management / Module 22 - Software Scheduling, Part 2 Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Developing a PERT from the Bottom Up (continued) Then move up a level and coalesce dependencies from lower level tasks.....

63. CSE7315M22 Slide # 63 September 12, 2004 CSE 7315 - SW Project Management / Module 22 - Software Scheduling, Part 2 Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved 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

64. CSE7315M22 Slide # 64 September 12, 2004 CSE 7315 - SW Project Management / Module 22 - Software Scheduling, Part 2 Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved 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

65. CSE7315M22 Slide # 65 September 12, 2004 CSE 7315 - SW Project Management / Module 22 - Software Scheduling, Part 2 Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved 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

66. CSE7315M22 Slide # 66 September 12, 2004 CSE 7315 - SW Project Management / Module 22 - Software Scheduling, Part 2 Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Note on Alternative Bottom-up Approach This approach may produce surprising results - combining things that did not seem appropriate to combine -- it is sometimes a good way to define teams on the project as well

67. CSE7315M22 Slide # 67 September 12, 2004 CSE 7315 - SW Project Management / Module 22 - Software Scheduling, Part 2 Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Sample Result

68. CSE7315M22 Slide # 68 September 12, 2004 CSE 7315 - SW Project Management / Module 22 - Software Scheduling, Part 2 Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved 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