1. File:CCPGS05 CC present Page: 1 ETXPGS 2000-09-14

2. File:CCPGS05 CC present Page: 2 ETXPGS 2000-09-14 22 3612 6 4 1. To know when the project can be finished we estimate the individual task times and add them up in a project schedule. -> We follow the additive rule 2. We follow the progress of the activities and take action when problems occur. -> How do we estimate the duration of an activity? How do we manage uncertainty in projects?

3. File:CCPGS05 CC present Page: 3 ETXPGS 2000-09-14 Probability A realistic estimate (ca 90%) median time with 100% concentration 100% concentration “I also do other things” How do we estimate the duration of an activity ?

4. File:CCPGS05 CC present Page: 4 ETXPGS 2000-09-14 22 3612 6 4 But why are so many activities still late? That should indicate that our estimates do not have safety, it indicates they are overoptimistic - Right? Let´s look at the effect of high probability estimates. We build in safety that protect each activity

5. File:CCPGS05 CC present Page: 5 ETXPGS 2000-09-14 5% 50% 90% (High risk)(Medium risk)(Low risk) Probabili ty One effect is: Finishing early but not reporting until the scheduled completion. - What’s the rush?...The next resource isn’t ready anyway! - The “3 Minute Egg Rule”...It’s not quality if it’s finished before the time is up. - Parkinson’s Law...Work expands to fill its time. Activity A 10 days Activity B 10 days 1. Unreported Early Finishes Finishing early but not reporting until the scheduled completion - for several reasons, e.g: Parkinson’s Law and The 3 Minute Egg Rule - Two effects from the same root:...the lack of good criteria defining when a task is complete. Effects of high probability time estimates...

6. File:CCPGS05 CC present Page: 6 ETXPGS 2000-09-14 1. We have a margin until we reach the estimated completion time for the activity. 2. We have other urgent issues to deal with. Planned start Planned completion Activity intensity 2. The student syndrome Murphy

7. File:CCPGS05 CC present Page: 7 ETXPGS 2000-09-14 Current mode of operation: Single tasking: Current mode of operation: (Multi Tasking) More Complexity More Complexity Unclear Priorities Many things to do at the same time It’s not always possible to complete one task until it is required to shift to another task (especially true for limited key resources). With more Complexity - Priorities become Unclear...

8. File:CCPGS05 CC present Page: 8 ETXPGS 2000-09-14 The additive rule does not work in projects We add safety in our time estimates to protect for uncertainty and the effects of variability and dependencies We consume safety time Not taking advantage of positive variation (error reporting) Student Syndrome Multi-tasking Summary:

9. File:CCPGS05 CC present Page: 9 ETXPGS 2000-09-14 DD = Due Date DD DDD D 422 12 366 What is the constraint of a project? The longest chain of all dependent events... Critical Chain - the Critical Chain! 1. IDENTIFY the System’s Constraint(s). 2. Decide How to EXPLOIT the System’s Constraint(s). 3. SUBORDINATE Everything Else to the Above Decision. 4. ELEVATE the System’s Constraint(s). CC Four Step Systems Improvement Process Developing the Critical Chain Single Project Solution...

10. File:CCPGS05 CC present Page: 10 ETXPGS 2000-09-14 Put all the safety in the Critical Chain tasks in an aggregated Project Buffer! DD DDD D 422 12 366 Critical Chain D 422 6183 PB (33 days) 6 Critical Chain Project Buffer - Protecting the Project Completion CC Four Step Systems Improvement Process 2. Decide How to EXPLOIT the System’s Constraint(s). 3. SUBORDINATE Everything Else to the Above Decision. 4. ELEVATE the System’s Constraint(s). 1. IDENTIFY the System’s Constraint(s).

11. File:CCPGS05 CC present Page: 11 ETXPGS 2000-09-14 D 422 6183 PB (33 days) 6 Critical Chain Put all the safety in the non-critical feeding paths tasks in an aggregated Feeding Buffer! FB (13) 211 Feeding Buffers - Protecting the Critical Chain 1. IDENTIFY the System’s Constraint(s). 2. Decide How to EXPLOIT the System’s Constraint(s). 3. SUBORDINATE Everything Else to the Above Decision. 4. ELEVATE the System’s Constraint(s). CC Four Step Systems Improvement Process

12. File:CCPGS05 CC present Page: 12 ETXPGS 2000-09-14 1. IDENTIFY the System’s Constraint(s). 2. Decide How to EXPLOIT the System’s Constraint(s). 3. SUBORDINATE Everything Else to the Above Decision. 4. ELEVATE the System’s Constraint(s). We also need to make it possible for people to act in an appropriate way that supports task times with (much) less safety in them - Relay Runner! DD 6183 PB (33 days) 6 Critical Chain FB (13) 211 Relay Runner

13. File:CCPGS05 CC present Page: 13 ETXPGS 2000-09-14 1. IDENTIFY the System’s Constraint(s). 2. Decide How to EXPLOIT the System’s Constraint(s). 3. SUBORDINATE Everything Else to the Above Decision. 4. ELEVATE the System’s Constraint(s). From statistics we know: “The overall project estimate has much less variability than each of the individual task estimates that have been added together to create it”. DD 6183 PB (33 days) 6 Critical Chain FB (13) 211 DD PB (17 days) FB112 Reduced Buffer Size...

14. File:CCPGS05 CC present Page: 14 ETXPGS 2000-09-14 Minimise the wasting of safety times: Accept that task times have a natural variation Use short but not impossible duration times (­50/50) Protect the critical chain with feeding buffers, do not start activities earlier than that in order to avoid multi-tasking. Do not use fixed intermediate milestones for controlling the project. The only fixed point is the Project due date. Resources finish the activity they are working on unless our control mechanism tells us otherwise, i.e no bad multi-tasking. Subordinate everything else...

15. File:CCPGS05 CC present Page: 15 ETXPGS 2000-09-14 + ++= += Project Buffer Feeding Buffer Region I Act Region II Watch & Plan Region III OK 1.Report estimates of remaining duration periodically (daily, bi-weekly, weekly) + when any task is started/completed. 2.Update penetration into buffers. 3.Base task priority decisions and correct- ive actions on buffer penetration data. 4.Do not re-plan, unless there is a major change in scope, dead-line etc We no longer track progress against Milestones - But we still need to know how we are doing! The Control Mechanism - Buffer Management

16. File:CCPGS05 CC present Page: 16 ETXPGS 2000-09-14 “Life Before Critical Chain” Tight time plan Insufficient resources From start Delays in other projects Late input Input with unknown and varying quality Unclear when we are ready Much re-work ”We are ready when we are ready!”

17. File:CCPGS05 CC present Page: 17 ETXPGS 2000-09-14 “Life After Critical Chain” Resources available when needed Avoid Multitasking Use buffer penetration as indication for action All input in place Less stress Less re-planning Less rework Define Exit Criteria More clear priority between projects More easy to follow progress ”We are ready when exit criteria met”

18. File:CCPGS05 CC present Page: 18 ETXPGS 2000-09-14 And remember: All risks are not eliminated! You should be more immune to “common cause variation” You still have to manage “special cause variation” Stick to the plan, keep the momentum up It’s easy to fall back in traditional behaviour Question all intermediate milestones, and avoid committing to dates for them