MGMT631 Slides Six.ppt - - /


Published on

Published in: Technology, Business
1 Like
  • Be the first to comment

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

MGMT631 Slides Six.ppt - - /

  1. 1. MGMT631 Project Management Slides Six
  2. 2. Session Objectives <ul><li>Planning & scheduling </li></ul><ul><ul><li>Work Breakdown Structure </li></ul></ul><ul><ul><li>Realistic Estimating </li></ul></ul><ul><ul><li>Critical Path </li></ul></ul><ul><ul><li>Time Boxes & Critical Chain </li></ul></ul>
  3. 4. Project Time Management Processes <ul><li>Project time management involves processes required to ensure timely completion of a project </li></ul><ul><li>Processes include: </li></ul><ul><ul><li>Activity definition </li></ul></ul><ul><ul><li>Activity sequencing </li></ul></ul><ul><ul><li>Activity duration estimating </li></ul></ul><ul><ul><li>Schedule development </li></ul></ul><ul><ul><li>Schedule control </li></ul></ul>
  4. 5. Work Breakdown Structure (WBS) <ul><li>WBS breaks down the work of the project into manageable chunks </li></ul><ul><li>WBS can be graphical or outline </li></ul><ul><li>Start at top, progressively break work down (tree structure) into work packages </li></ul><ul><li>Packages provide clear work assignments </li></ul>Project best understood by breaking it down into its parts
  5. 6. Estimating: Work Breakdown Structure <ul><li>“ Project best understood by breaking it down into its parts” </li></ul><ul><li>Work Breakdown Structure (WBS) </li></ul><ul><ul><li>powerful tool for doing this (not just a task list) </li></ul></ul><ul><ul><li>defines the total scope of the project </li></ul></ul><ul><ul><li>fundamental to much of project planning & tracking </li></ul></ul><ul><li>Start at top, progressively break work down (tree structure) into work packages </li></ul><ul><li>Roll up the packages for bottom up estimating </li></ul><ul><li>Packages give clear work assignments </li></ul>
  6. 7. Sample Intranet WBS Organized by Phase
  7. 8. Intranet WBS in Tabular Form 1.0 Concept 1.1 Evaluate current systems 1.2 Define Requirements 1.2.1 Define user requirements 1.2.2 Define content requirements 1.2.3 Define system requirements 1.2.4 Define server owner requirements 1.3 Define specific functionality 1.4 Define risks and risk management approach 1.5 Develop project plan 1.6 Brief web development team 2.0 Web Site Design 3.0 Web Site Development 4.0 Roll Out 5.0 Support
  8. 9. Intranet WBS and Gantt Chart Project 98 file
  9. 10. Intranet WBS & Gantt Chart Organized by PM Groups
  10. 11. Realistic Estimating (Frame) <ul><li>Lots of reasons for poor estimates </li></ul><ul><ul><li>inexperience, technical problems, changes optimists, low-balling, politics </li></ul></ul><ul><li>Bottom-up cost estimating </li></ul><ul><ul><li>rollup the WBS packages </li></ul></ul><ul><li>Top-down or Parametric estimating </li></ul><ul><ul><li>from experience to complex models </li></ul></ul>
  11. 12. Realistic Estimating (cont.) <ul><li>Which technique is better? </li></ul><ul><ul><li>ideally use both </li></ul></ul><ul><ul><li>early on don’t have WBS so must use top-down </li></ul></ul><ul><ul><li>accuracy of top-down depends on availability/quality of historical data </li></ul></ul><ul><ul><li>building complete WBS can be expensive, but guesses can be even more costly </li></ul></ul>
  12. 13. Deliverables and Milestones <ul><li>Deliverables </li></ul><ul><ul><li>Tangible, verifiable work products </li></ul></ul><ul><ul><li>Reports, presentations, prototypes, etc. </li></ul></ul><ul><li>Milestones </li></ul><ul><ul><li>Significant events or achievements </li></ul></ul><ul><ul><li>Acceptance of deliverables or phase completion </li></ul></ul><ul><ul><li>Cruxes (proof of concepts) </li></ul></ul><ul><ul><li>Quality control </li></ul></ul><ul><ul><li>Keeps team focused </li></ul></ul>
  13. 14. The seeds of major software disasters are usually sown in the first three months of commencing the software project. Hasty scheduling, irrational commitments, unprofessional estimating techniques & carelessness of the project management function are the factors that tend to introduce terminal problems. Once a project blindly lurches forward toward an impossible delivery date, the rest of the disaster will occur almost inevitably. T. Capers Jones
  14. 15. Software Engineering Metrics <ul><li>Lines of Code (LOC) </li></ul><ul><li>Function Points </li></ul>
  15. 16. Lines of Code (LOC) <ul><li>Most traditionally used metric for project sizing </li></ul><ul><li>Most controversial </li></ul><ul><ul><li>Count comments? </li></ul></ul><ul><ul><li>Declaring variables? </li></ul></ul><ul><ul><li>Efficient code vs. code bloat </li></ul></ul><ul><ul><li>Language differences </li></ul></ul><ul><ul><li>Easier to count afterwards than to estimate </li></ul></ul>
  16. 17. Function Points <ul><li>Analysis based on evaluation of data and transactional types: </li></ul><ul><ul><li>Internal Logical File (ILF) </li></ul></ul><ul><ul><li>External Interface File (EIF) </li></ul></ul><ul><ul><li>External Input (EI) </li></ul></ul><ul><ul><li>External Output (EO) </li></ul></ul><ul><ul><li>External Inquiry (EQ) </li></ul></ul>
  17. 18. Function Points <ul><ul><li>Value Adjustment Factor based on </li></ul></ul><ul><ul><ul><li>Degrees of Influence (DI) aka Processing Complexity Adjustment (PCA) </li></ul></ul></ul><ul><ul><ul><li>General Systems Characteristics (GSC) </li></ul></ul></ul><ul><ul><li>Total Adjusted Function Points (TAFP) </li></ul></ul><ul><ul><ul><li>transformed into development estimates </li></ul></ul></ul><ul><ul><ul><li>converted in equivalent LOC </li></ul></ul></ul><ul><ul><li>Backfiring </li></ul></ul>
  18. 19. The Application Boundary for Function Point Analysis
  19. 20. The Mythical Man-Month – Frederick Brooks <ul><li>0ur techniques of estimation are poorly developed. More seriously, they reflect an unvoiced assumption which is quite untrue i.e., that all will go well. </li></ul><ul><li>Our estimating techniques fallaciously confuse effort with progress , hiding the assumption that men and months are interchangeable. </li></ul>
  20. 21. The Mythical Man-Month – Frederick Brooks <ul><li>3. Because we are uncertain of our estimates, software managers often lack the courteous stubbornness of Antoines chef </li></ul><ul><li>4. Schedule progress is poorly monitored. Techniques proven & routine in other engineering disciplines are considered radical innovations in software engineering </li></ul>
  21. 22. The Mythical Man-Month – Frederick Brooks <ul><li>5. When schedule slippage is recognized, the natural tendency (& traditional) response it to add more manpower. Like dousing a fire with gasoline, this makes matters worse, much worse. More fire requires more gasoline & thus begins a regenerative cycle which ends in disaster. </li></ul>
  22. 23. Brooks Law: “ Adding manpower to a late software project makes it later.”
  23. 24. Scheduling Tools & Methods <ul><li>Gantt Charts </li></ul><ul><li>Critical Path Method (CPM) </li></ul><ul><li>Program Evaluation and Review Technique (PERT) </li></ul><ul><li>Time Boxes </li></ul><ul><li>Critical Chain </li></ul><ul><ul><li>(Theory of Constraints) </li></ul></ul>
  24. 25. Developing a Project Schedule <ul><li>Base documents </li></ul><ul><ul><li>Project charter </li></ul></ul><ul><ul><li> – start/end dates (tentative) , budget </li></ul></ul><ul><ul><li>Scope statement </li></ul></ul><ul><ul><li> – what will be done (& not done) </li></ul></ul><ul><li>Activity definitions </li></ul><ul><ul><li>develop detailed WBS </li></ul></ul><ul><ul><li>plus supporting explanations to understand all work to be done </li></ul></ul>
  25. 26. Activity Sequencing <ul><li>Review activities & determine dependencies </li></ul><ul><ul><li>Mandatory dependencies: inherent in the nature of the work; hard logic </li></ul></ul><ul><ul><li>Discretionary: defined by the project team; soft logic </li></ul></ul><ul><ul><li>External: involve relationships between project and external activities </li></ul></ul><ul><li>Must determine dependencies to use critical path analysis </li></ul>
  26. 27. Gantt Charts <ul><li>Created 1800 </li></ul><ul><li>Standard format for displaying project schedules </li></ul><ul><ul><li>activities, durations, start/end finish dates displayed in calendar format </li></ul></ul><ul><li>Advantages </li></ul><ul><ul><li>enforces planning </li></ul></ul><ul><ul><li>easy to create & understand </li></ul></ul><ul><ul><li>preferred for summary/exec-level information </li></ul></ul>
  27. 28. Gantt Charts (cont.) <ul><li>Symbols include: </li></ul><ul><ul><li>black diamond: milestones </li></ul></ul><ul><ul><li>Thick black bars: summary tasks </li></ul></ul><ul><ul><li>Lighter horizontal bars: tasks </li></ul></ul><ul><ul><li>Arrows: dependencies between tasks </li></ul></ul><ul><li>Bar Charts </li></ul><ul><ul><li>Simplified version </li></ul></ul><ul><ul><li>Serve similar function </li></ul></ul>
  28. 29. Sample Project Gantt Chart
  29. 30. Sample Tracking Gantt Chart white diamond: slipped milestone two bars: planned and actual times
  30. 31. Critical Path Method (CPM) <ul><li>Developed 1957 </li></ul><ul><li>CPM diagram shows activities, durations, start/end dates & sequence in which they must be completed </li></ul><ul><li>Critical path for project is the series of activities that determines the earliest time by which project can be completed </li></ul><ul><li>Critical path is longest path through network diagram, has least (zero) slack or float </li></ul>
  31. 32. CPM (cont.) <ul><li>Critical path helps you make schedule trade-offs </li></ul><ul><li>Slack or float amount of time activity can be delayed without delaying early start of dependent activities </li></ul>
  32. 33. Simple Example of Determining Critical Path <ul><ul><li>consider following network diagram </li></ul></ul><ul><ul><li>assume all times in days </li></ul></ul>a. How many paths are on this network diagram? b. How long is each path? c. Which is the critical path? d. What is the shortest amount of time needed to complete this project? Activity-on-Arrow (AOA) Network Diagram
  33. 34. Precedence Diagramming Method (PDM) <ul><li>Activities are represented by boxes </li></ul><ul><li>Arrows show relationships between activities </li></ul><ul><li>More popular than ADM method as used by PM software </li></ul><ul><li>Better at showing different types of dependencies </li></ul>
  34. 35. Task Dependency Types
  35. 36. Activity Analysis for AON H,I 1 Write report to management J G 5 Train users I F,G 2 Write announcement of intranet for corp. newsletter H D,E 3 Move web pages to production environment G C,D 4 Test Web pages and links F B 1 Estimate Web traffic E B 3 Set-up Server D B 4 Design Web page layouts C A 5 Define user requirements B None 2 Evaluate current technology platform A Predecessor Estimated Duration (Days) Description Activity
  36. 37. Activity on the Node (AON) Network Diagram Develop our own Network (CPM) diagram
  37. 38. Possible Activity Paths 17 A+B+E+G+I+J Path 5 2+5+1+3+5+1 2+5+3+3+5+1 19* A+B+D+G+I+J Path 4 2+5+3+3+2+1 16 A+B+D+G+H+J Path 3 2+5+3+4+2+1 17 A+B+D+F+H+J Path 2 2+5+4+4+2+1 18 A+B+C+F+H+J Path 1 Total Path Possible Paths
  38. 39. Critical Path <ul><li>Longest path </li></ul><ul><li>Shortest time project can be completed </li></ul><ul><ul><li>Zero slack (or float) </li></ul></ul><ul><ul><ul><li>The amount of time an activity can be delayed before it delays the project </li></ul></ul></ul><ul><li>Must be monitored and managed! </li></ul><ul><ul><li>PM can expedite or crash </li></ul></ul><ul><ul><li>Can fast track </li></ul></ul><ul><ul><li>The CP can change </li></ul></ul><ul><ul><li>Can have multiple CPs </li></ul></ul>
  39. 40. Techniques for Shortening a Project Schedule <ul><li>Shortening durations of critical tasks: </li></ul><ul><ul><li>add more resources </li></ul></ul><ul><ul><li>change their scope </li></ul></ul><ul><li>Crashing tasks by obtaining the greatest amount of schedule compression for the least incremental cost </li></ul><ul><li>Fast tracking tasks by doing them in parallel or overlapping them </li></ul>
  40. 41. PERT <ul><li>Developed 1959 for Polaris project </li></ul><ul><li>Similar to CPM but addresses uncertainties in task durations </li></ul><ul><li>Uses probabilistic time estimates – optimistic, most likely, pessimistic estimates of activity durations </li></ul>
  41. 42. PERT Formula and Example <ul><li>PERT weighted average formula : </li></ul><ul><li>optimistic time + 4X most likely time + pessimistic time </li></ul><ul><li>6 </li></ul><ul><li>Example: </li></ul><ul><li>PERT weighted average = </li></ul><ul><li>8 workdays + 4 X 10 workdays + 24 workdays = 12 days </li></ul><ul><li>6 </li></ul><ul><li>where 8 = optimistic time, 10 = most likely time, and 24 = pessimistic time </li></ul>
  42. 43. Normal Distribution
  43. 44. PERT Distribution
  44. 45. Activity Analysis for PERT 30 days 31.6 days 1.3 3 1 .5 H,I J 5.5 9 5 4 G I 2.3 5 2 1 F,G H 3.0 4 3 2 D,E G 4.0 6 4 2 C,D F 1.0 1 1 1 B E 3.3 6 3 2 B D 3.8 5 4 2 B C 5.2 8 5 3 A B 2.2 4 2 1 None A Expected Duration (a+4b+c) 6 Pessimistic Estimates (Days) Most Likely Estimates (Days) Optimistic Estimates (Days) Predecessor Activity
  45. 46. Selecting Scheduling Approach <ul><li>Consider project size, risk and complexity </li></ul><ul><li>Gantt </li></ul><ul><ul><li>senior management </li></ul></ul><ul><ul><li>smaller, less complex projects </li></ul></ul><ul><li>CPM </li></ul><ul><ul><li>medium size/complexity/risk </li></ul></ul><ul><li>PERT </li></ul><ul><ul><li>high risk projects </li></ul></ul><ul><ul><li>medium to high complexity </li></ul></ul>
  46. 47. Time Box Scheduling <ul><li>Deals with delivering in short time frames </li></ul><ul><li>Focuses on prioritization </li></ul><ul><li>Facilitator brings stakeholders together to agree on priorities </li></ul><ul><li>It’s customer–developer partnering </li></ul><ul><ul><li>win-win </li></ul></ul><ul><li>Compromise on scope to achieve early delivery </li></ul>
  47. 48. Critical Chain Scheduling <ul><li>Addresses challenge of meeting or beating project finish dates </li></ul><ul><li>Application of the Theory of Constraints (TOC) </li></ul><ul><li>Developed by Eliyahu Goldratt in his books The Goal and Critical Chain </li></ul><ul><li>Method of scheduling that takes limited resources into account when creating project schedule & includes buffers to protect completion date </li></ul><ul><li>Assumes resources do not multitask as it often delays task completions & increases total durations </li></ul>
  48. 49. Multitasking Example
  49. 50. Buffers and Critical Chain <ul><li>A buffer is additional time to complete a task </li></ul><ul><li>Critical chain schedule removes buffers from individual tasks & instead creates </li></ul><ul><ul><li>A project buffer, which is additional time added before the project’s due date </li></ul></ul><ul><ul><li>Feeding buffers, which are addition time added before tasks on the critical path </li></ul></ul>
  50. 51. Critical Chain Scheduling Example
  51. 52. Critical Chain (cont.) <ul><li>Simple view: </li></ul><ul><ul><li>in critical situation, don’t try to strengthen all of the links in the chain </li></ul></ul><ul><ul><li>focus on the weakest link </li></ul></ul><ul><li>Some organizations view as best thing since sliced bread </li></ul><ul><li>But does it sound like common sense? </li></ul>
  52. 53. The End