Critical Chain. November 14 th Revision Draft

Transcription

1 Critical Chain November 14 th Revision Draft This document, as well as the software described in it, is furnished under license and may only be used or copied in accordance with the terms of such license. The information in this document is furnished for informational use only, is subject to change without notice, and should not be construed as a commitment by Sciforma. Sciforma assumes no responsibility or liability for any errors or inaccuracies that may appear in this document. No part of it may be reproduced or transmitted, in any form or by any means without the prior written permission of Sciforma. Copyright US Headquarters : 985 University Avenue Suite 5 Los Gatos, CA Tel: (1) info@sciforma.com

2 2

3 3 Contents A - INTRODUCTION IMPLEMENTING THE THEORY OF CONSTRAINTS Time estimating Task execution Student syndrome Parkinson's law Multitasking Disincentives for early finishes Shared safety Scheduling as late as possible/scheduling backward CRITICAL CHAIN SCHEDULING TECHNIQUES Starting a Critical Chain project Switching to Critical Chain Planning Mode Planning Critical Chain projects Defining tasks in Critical Chain Planning Mode Defining and assigning resources for a Critical Chain project Resolving Critical Chain resource contention Identifying the Critical Chain Adding explicit resource links on the Critical Chain Inserting Critical Chain buffers Dissolving Critical Chain buffers TRACKING CRITICAL CHAIN PROJECTS Starting a Critical Chain project on time Finishing tasks early Updating the schedule Adjusting Pin Dates Managing buffers MAKING RESOURCE ALLOCATION DECISIONS MANAGING MULTIPLE CRITICAL CHAIN PROJECTS BUDGETING CRITICAL CHAIN PROJECTS IMPORTING CRITICAL CHAIN PROJECTS FROM PS SUMMARY...30

4 4 A - Introduction Critical Chain project management is an approach to planning and managing projects that emphasizes the needs of the resources required to complete project tasks. Critical Chain project scheduling is different from Critical Path and PERT methods, because all work in a Critical Chain project is scheduled as late as possible in the schedule. Buffers of time are consolidated from safety margins that are removed from individual tasks and made available to an entire chain of tasks to use as necessary. These buffers protect the due dates from task overruns that occur unpredictably during project implementation. A buffer automatically absorbs the effects of late-finishing tasks, so the key to successful Critical Chain project management is correctly sizing and then managing these buffers. Critical Chain methodology recognizes that people, not computer programs, execute projects. When a project management discipline is applied to people, human nature takes over and often results in the opposite of what the project schedule intended. Work expands to fit the allotted time, distractions appear, and unexpected conditions delay the ability to start a task on time. The knowledge that a person has ample time to complete a task generally results in the person waiting well past the safe starting time to actually work on the task.

5 Individuals will often pad their schedules with extra time to compensate for unfamiliarity with a task, unplanned interruptions, and to protect themselves from the organization's response to workers who do not complete their tasks on time. After workers pad their tasks estimates, each level of management often adds additional safety margins because they know that on previous projects, their workers have missed their deadlines, resulting in overruns that reflect badly on the manager's ability to effectively manage projects. Furthermore, some organizations apply disincentives to workers who finish their tasks early; for example, reducing the amount of time available on future assignments. Critical Chain project management requires a different approach to managing projects and evaluating worker performance. Critical Chain projects are managed according to a relay race analogy, as opposed to the traditional schedules employed in the Critical Path method. After work on a task chain is started, the management focus is simply to make sure the work is done as fast as possible. Like a relay race, the following runner must be prepared to take off as soon as the preceding runner hands off the baton, and not attempt to finish the race according to a published schedule. This solves the problem in traditional Critical Path projects where any time gained in one part of the schedule is lost due to waiting for the scheduled time to arrive before starting the next task. Project performance is determined simply by monitoring the utilization of the buffers. Resource contentions are resolved by analyzing the impact of allocation alternatives on buffer utilization. The complete theory, description, and practice of Critical Chain project management can be found in the book, Critical Chain by Dr. Eliyahu Goldratt. The remainder of this document describes how Critical Chain project management is implemented in Sciforma. 5

6 6 1 - Implementing the Theory of Constraints Implementing Theory of Constraints (TOC) for project scheduling means changing the way we think about the way schedules work. Sciforma supports the full TOC model of project management according to the principles described by Dr. Eliyahu Goldratt in his book, Critical Chain. Scheduling using Critical Chain methodology requires rethinking the way projects are both scheduled and managed in ways that at first may seem counter-intuitive: Time estimates must not be padded they should reflect a 50% probability of achievement. Tasks must be scheduled to start as late as possible and scheduled backward from the target finish date. The padding removed from each task must be consolidated into shared safety buffers. Projects must be scheduled as late as possible and scheduled backward Time estimating Besides defining the set of steps that comprise a project, the first step in actually putting together a project schedule is determining how long each task will take to complete. To do this, the typical project manager asks each department to look at the schedule and give an estimate for their part. Each department then takes this schedule and breaks down the tasks by worker, asking each worker to give an estimate for his or her part. Each worker looks at his or her task and decides, based on past experience and perhaps discussing the matter with others who do the same type of work, how long the task will take. No one wants to hold up the project because they don't complete their work on time, so workers generally pad the estimates a bit to account for the unforeseen or the unusual. If a task will actually take 5 days to complete, the estimate the worker gives to the department head might be more like 10 days, "just to be safe." The extra 5 days is the worker's private contingency factor. The department head does not discourage this padding (if she is aware of it), because the department does not want to be in the position of holding up the project. In fact, holding up the project becomes such an important thing to avoid, the department head will typically pad time estimate again, after rolling up all the tasks that the department must estimate. The time estimates are passed back to the project manager who, although vaguely aware that the estimates have been padded, probably adds some additional padding to ensure that there is plenty of contingency time to handle the unforeseen. Depending on the character and politics of the company, it might not be unusual for a one week task to be scheduled as a one month task. Of course, all of the safety present in the task is hidden, and the task is represented on the schedule as a one-month task, not a one week task. You would think that this amount of padding would ensure that no project ever finishes late. But projects almost never finish early.

7 Task execution Why do projects not typically finish early? There are a number of reasons, each of which is addressed by the Critical Chain methodology: Student syndrome Parkinson's law Multitasking Disincentives for early finishes Student syndrome Student syndrome is simply waiting to start tasks because team members think they have plenty of time to finish them. When this thinking is applied to project schedules that have hidden contingency time built in, workers know that they can wait to start their tasks because they have more than enough time to comfortably complete them. Most workers have a number of tasks they could do, all with varying degrees of urgency. Human nature leads us all into putting off all tasks except the urgent ones. This means that we won't start a task until it becomes urgent. We won't start our one-week task (that has a two-week estimate) until the week of padding is mostly used up. Having two weeks to complete a one-week task leads everyone to believe that starting late will be fine, because the task really will take only one week. Then, on the following Thursday, the unexpected happens. Maybe a computer crashes and work is lost. Maybe an illness prevents work from progressing as anticipated. Maybe other, more urgent tasks are handed down that must start when plans have been made to work on that task that has been put off. Now the safety factors that are built into the original schedule are almost gone and team members realize they will overrun their estimates no matter how hard they work. This scenario is not unusual. It happens over and over again in the completion of a project. We are all human, and when we establish a task schedule with a hidden safety margin, most of us naturally fall into the student syndrome Parkinson's law Parkinson's law states that work expands to fill the allotted time. If a task is estimated to take 10 days, it usually will not be completed in less time. Effort on a task is adjusted to fill the allotted time in an number of ways. On software projects, developers will often add features that were not called for in the original specification. In other types of projects, workers may similarly try to add more to the task than required or may simply adjust their level of effort and commitment to the task so that it takes the allotted amount of time.

8 Multitasking At first glance, working on more than one project or task at a time seems like an excellent way to keep everyone happy. An organization might have four key customers all wanting their particular project finished as soon as possible. Each project requires four weeks to complete and each require the same resources. The initial reaction is to try to keep all four customers happy by telling them that work will proceed on their project right away, so each of the four projects is scheduled to interleave so that everyone is at least applying some effort on each project each month. This sounds like a great idea, doesn't it? Project A Name Jan Feb Mar Apr Ma Project B Project C Project D As each task takes four weeks, and the four weeks are spread out among four projects, it will take at least 16 weeks to complete each project. But what if a counter-intuitive methodology were applied and each project was scheduled without multitasking? What would be the benefit? For one thing, each worker could concentrate on one project at a time, giving it full attention and not losing productivity due to constantly changing tasks. This reason alone should be enough to merit consideration. But there is a larger reason that is not apparent to most people until they see a number of projects scheduled without multitasking. Project A Name Jan Feb Mar Apr Ma Project B Project C Project D

9 With a non-multitasking schedule, the first project is completed nine weeks earlier than if workers were multitasking. The second project is completed five weeks earlier, and the third project is completed three weeks earlier. The worst case, the fourth project, is completed at the same time as if the projects were competed using multitasking. The first project therefore is completed 225% faster, and the last project's completion date does not suffer. There is no down side, except that some customers will feel neglected if they do not understand this methodology. Not shown in these assumptions is that added productivity and efficiency that would be gained by allowing workers to focus on one task at a time Disincentives for early finishes Most seasoned project managers know that tasks either finish on time or late, but almost never finish early. Beyond student syndrome, Parkinson's law, and multitasking, there is another factor that contributes to this situation: the system of rewards and punishments and how they are applied. People will perform according to the system by which they are measured. Organizations that want a successful Critical Chain implementation must make absolutely sure that they do not punish people for finishing early or measure throughput in the wrong way. When a worker finishes a task early, what happens? Does that worker get rewarded? It is more likely that the worker is punished; maybe not officially, but punished nonetheless. For example, a worker that finishes a two-week task in one week might be accused of padding his estimates and may be pressured into reducing future estimates in response to the implication that he is lazy something that no one wants to deal with. Finishing a task on time, rather than early, is much safer in this environment. The next problem an early finisher encounters is that the resource to whom the task is handed off is not yet ready to work on the task. The original project schedule gave a clear starting date for this next task and the resources were allocated elsewhere until the schedule indicated the need. So finishing a task early may do nothing for the overall project schedule. Yet another problem is that other workers may resent a team member finishing early because it makes their time estimates for similar tasks look bad. The early-finisher in effect is taking away others' safety by showing management that the task can be done faster than consensus shows it can be done. Another unintentional disincentive is measuring the wrong type of throughput. If workers are rewarded for the number of pounds of items produced, organizations will find their warehouses filled with the heaviest items that can be made, not necessarily the ones that their customers need or want. Goldratt's book, Critical Chain, contains an example of a steel mill that rates workers based on the number of tons of product they produce. The mill has a warehouse full of thick steel plates because tonnage can be produced faster this way than when producing the thin steel plates that customers really need. 9

10 10 When student syndrome, Parkinson's law, multitasking, and a rewards system that punishes early finishers are combined, most organizations find that traditional project management methods can only propagate late finishes. In other words, the best traditional project planning methods can do is finish on time, and the likelihood of that happening is small Shared safety A key element of Critical Chain project management is that the workers must give unpadded time estimates for each task. The time they would have used for padding the estimates gets consolidated into various buffers that are placed in key points throughout the project schedule. If anyone needs extra time to finish a task, the extra time comes out of one of these buffers. Obtaining the cooperation needed to schedule a project in this way requires a change in both individual and organizational behavior. Everyone must be involved in understanding that their hidden safety is not being removed and discarded. Instead, that hidden safety is being exposed and pooled as a project resource as opposed to a hidden task-level resource. Both management and the project team must be convinced to embrace uncertainty rather than believe that they can defeat it with better estimating techniques. When safety is removed from a task, stakeholders must accept the fact that the task has a good probability of exceeding the time estimate. This is not a bad thing it is normal. Task actuals can no longer be compared to baseline estimates for the purpose of discovering discrepancies and treating them as problems. If this happens, team members will adjust their behavior to the measurements and put generous amounts of hidden safety back into their next estimates, defeating the Critical Chain method entirely. A work environment must be fostered that does not consider missing a time estimate as a failure. Innovation is messy an environment that tries too hard to contain and suppress the inherent messiness is unknowingly suppressing innovation. The goal is to obtain task estimates that have a 50% chance of being met. This means that there is also a 50% chance that the task will take more time than estimated. And it means that there is also some chance that the task will take less time than the estimate. Instead of asking team members for an estimate that has a 50% chance of being correct, they should be asked to provide estimates based on the following assumptions: All material and information needed for the task is on hand. They will be able to focus on the task without any interruptions. There won't be any surprises that cause additional work. Of course, these assumptions will seldom all be true throughout a project. But they will result in workers arriving at an estimate that has close to a 50% probability without the need to introduce workers to statistical mathematics.

11 Sciforma's Critical Chain methodology enables two durations to be entered and tracked. The Duration field contains the duration that has a 50% probability of being met. Then Sciforma uses parameters specified by the project manager to calculate a Safe Duration, which has about a 90% probability of being met. The Safe Duration is the value that is published to the outside world, while the Duration is the value used internally to manage the project Scheduling as late as possible/scheduling backward An important characteristic of Critical Chain projects is that their tasks are scheduled to start as late as possible in the schedule. Scheduling this way places the work as close as possible to the end of the schedule just the opposite of the way Critical Path scheduling works. There are many benefits to delaying project work as late as possible, and one drawback. 11 Using a production analogy, scheduling as late as possible minimizes the work-inprogress (WIP) and avoids incurring costs earlier than necessary. From the project manager's viewpoint, there is better focus at the critical start of the project because there simply aren't as many tasks scheduled to start. Also, in projects involving complex knowledge work, knowledge increases as workers progress into the project, as discoveries are made. By scheduling tasks as late as possible, teams capitalize on this increasing knowledge and therefore minimize the need for rework. The single drawback of ALAP scheduling is that, in traditional Critical Path terminology, all tasks are critical once the project is switched into tracking mode. Increasing the duration of any task pushes out the project end date by a corresponding amount. The Critical Chain solution to this problem is to insert time buffers at key points in the project plan. These buffers act as shock absorbers to protect the project end date against task duration increases. The buffers need to be sized to provide adequate protection against the uncertainty in any project. Because scheduling takes place backward from a desired finish date, Sciforma enables Critical Chain projects to be scheduled backward from the end. This does not mean that the last task must be entered first and the entire schedule worked backward. Rather, it means that as tasks are entered and linked and durations specified, the task starting date is computed while keeping the finish date fixed. Tasks can continue to be entered in any order as needed.

12 Critical Chain scheduling techniques Critical Chain scheduling occurs in two phases planning and tracking. Sciforma makes a distinction between these two phases by using two corresponding modes. This prevents many types of changes when in tracking mode that can be freely made when in planning mode. Furthermore, the way in which a project's tasks are displayed differs somewhat between the two modes. This section provides the following details about scheduling using Critical Chain methodology: Starting a Critical Chain project Switching to Planning mode Planning a Critical Chain project Tracking Critical Chain projects Making resource allocation decisions Managing multiple Critical Chain projects Note: Like any project management philosophy, a useful Critical Chain implementation requires clear, constant, and consistent communication. For example, it is critical for the project manager to continually monitor buffer capacities and buffer incursion, and it is critical for each team member to always know what task they should be working on at a give moment, and which task they should start immediately after finishing their current task. Fortunately, Sciforma can automate all of this communication through many different features: layouts, custom reports, automated s, and system/user preferences that display key fields and highlight key information with colors, icons, and graphical data. Consider all of these options to define configurations that suit the needs of the Critical Chain users Starting a Critical Chain project Starting a new Critical Chain project is a simple matter of setting three Project fields: Schedule Method must be set to Critical Chain. Schedule Direction should be set to Reverse, to facilitate the recommended Critical Chain scheduling methodology: projects being scheduled backward from the desired finish date. Single Critical Path should be set to Yes, to tie all tasks in a project to a common finish task. This enables Sciforma to calculate the true Critical Path of the project.

13 To make Critical Chain scheduling the preferred method, or enforce Critical Chain scheduling in an organization, project types can be created. Additionally Project forms can be set up with these fields visible as required. To switch a Critical Path project to Critical Chain, the values in these fields can be changed in the Project spreadsheet; however, users should be made aware that switching an established project schedule from one scheduling method to the other will require more work than simply changing the value of these fields Switching to Critical Chain Planning Mode As previously mentioned, Sciforma uses two distinct modes to manage Critical Chain projects: Planning mode and Tracking mode. To start scheduling a project, Planner must be switched to Planning mode. Switching to Planning mode does the following: Sets the Project.Schedule Direction field to Reverse. Unlocks all buffers (as can be seen in the Task.Buffer Lock field), enabling them to be adjusted as needed. Removes the Task.Pin Date on any pinned tasks so that the tasks can be freely moved during the planning phase. Sets the Task.Schedule Type field for all tasks to ALAP (as late as possible). Note that users can freely switch back and forth between Planning mode and Tracking mode as needed. Unless specific changes are made to the schedule, merely switching from one mode to the other does not affect the schedule. To switch to Planning mode, use the Switch To Planning Mode command in the Tools > Critical Chain menu or an equivalent toolbar button. If this command is unavailable, Sciforma is already in Planning mode Planning Critical Chain projects The Planning phase consists of the following steps: 13 Defining tasks Defining and assigning resources Resolving resource contention Indentifying the Critical Chain Adding explict resource links Inserting buffers and resolving resource contention again Dissolving (removing) buffers when necessary

14 Defining tasks in Critical Chain Planning Mode In Critical Chain Planning mode, a project manager develops a schedule by defining tasks and letting Sciforma schedule the project backward from the target finish date. When a task is added to the project, Sciforma places it so that it will complete by the target finish date; in other words, as late as possible in the schedule. Then, when another task is added and appropriately linked to the first task (assuming a link between the tasks is necessary), Sciforma moves the new task backward in time to make room to complete both the first and second task by the target end date. This process continues until all tasks have been added and linked. When task durations are entered, they should be realistic, unpadded estimates that have about a 50% chance of being accurate. Tasks can be added in any order and placed into any desired sequence. Just because Sciforma schedules projects backward from the end date does not mean that project managers have to think the plan in reverse order. The order in which tasks are scheduled is determined by the links between and among them, not the order in which they are entered Defining and assigning resources for a Critical Chain project Assigning resources to a Critical Chain project requires a somewhat different approach than assigning them to a Critical Path project. Resources should only be assigned full-time to tasks in a Critical Chain project. Therefore, individual resources (such as "Mary") should only have assignment rates of 1 (or 8 hours/day). Generic resources (such as "Programmer") should only have full time rates (such as 1, 2, or 3, or 8 hours/day, 16 hours/day, or 24 hours/day). Sciforma's ability to vary assignments over time should not be used in a Critical Chain project. Resources should only be assigned by using Uniform resource assignments. Important When resources are defined for a Critical Chain project, each resource should have full-time availability to the project (8 h/d). Generic resources that might apply to groups of individuals (for example, "Programmers") should have full time rates (1, 2, or 3, or 8h/d, 16 h/d, or 24 h/d) When resources are assigned to a Critical Chain project, they should be assigned full-time and should only be assigned uniformly (Labor Assignment.Allow Non-uniform field = No) Resolving Critical Chain resource contention When resources are assigned to tasks, it is likely that the same resource will be needed on two or more tasks during the same or overlapping time periods. This condition creates contention, or conflict, among the tasks competing for the resource. Sciforma automatically resolves resource contention by moving one or more tasks so that the same resource can accomplish them during different time periods. As with Critical Chain task scheduling, Sciforma resolves resource contentions backwards in time from the project's target finish date.

15 Resource contention is resolved while in Planning mode by using the Resolve Resource Contention command, available either in the Tools > Critical Chain menu or an equivalent toolbar button The resulting Resolve Resource Contention dialog box provides controls to configure the desired method for resolving contention, including: 15 Time scale: Specifies a time scale for resolving contention. The value determines the time spans Sciforma uses when moving tasks to resolve contention. For example, if Bob has five parallel one-day tasks scheduled on Monday, choosing a time scale of Day will cause Sciforma to move the tasks so that Bob receives one assignment on each of the five weekdays. On the other hand, choosing Week causes Sciforma to move nothing, because looking at Bob's resource assignment for a one-week period does not produce any contention. However, if Bob had one more assignment on Monday, for a total of six, choosing Week would cause Sciforma to move one task to the following Monday (next working day) because Bob has been overloaded by one day for the week. The benefit of using a larger Time scale value is that Sciforma always resolves contention faster (due to fewer iterations) and potentially makes fewer schedule changes (depending on the schedule's circumstances). However, a time scale value that is meaningful to the duration of the project must be specified to obtain useful results. Resources: Specifies whether to resolve contention among all resources, active resources, assigned resources, the current resource, the resource that matches the current resource request, or resources that match the selected organization, job classification, or skill. Save Baseline 10 before level: Saves the current state of the project before resolving resource contention, so that the changes can be revisited or reversed if needed. Use scaled availabilities: Specifies a percentage of each resource's availability when resolving contention. This can be either more or less than 100% as needed based on the level of safety needed in the schedule and whether it is desirable to use more than the official availability of resources. Honor Calendar Gaps: Controls whether to include periods of non-work caused by assignment calendars in deciding where to move an overallocated task. When this feature is enabled, gaps in the effective calendars are used when resource usage is low and resource availability is high to determine where to move a task to eliminate resource contention. This enables resource to work on tasks within the Non-work periods of other calendars, resulting in shorter schedules. When using the Honor Calendar Gaps feature, the Time Scale value controls how big the gaps must be before being applied to task that has resource contentions, in addition to the Time Scale value's normal function of specifying minimum time increments to use when resolving contentions.

16 16 Note To take advantage of the Honor Calendar Gaps feature, other assignments for the same resource must have an effective calendar with different Work and Non-work periods. (If the effective calendars for other assignments were the same, then the assignment would have no compatible gaps in which effort could be applied to the task being leveled.) Using different effective assignment calendars is one way to implement gaps that are compatible with this feature Identifying the Critical Chain The Critical Chain of a project is the longest chain of tasks, taking into account both task dependencies and resource dependencies. This is different from the definition of the Critical Path, which is based on task dependencies only. This is a subtle but extremely important difference. In the same way as Sciforma identifies the critical tasks in a Critical Path project, it can identify the tasks that are part of the Critical Chain in Critical Chain projects. But unlike tasks in a Critical Path project (which continuously re-computes critical tasks), Critical Chain tasks are computed only when requested by the project manager. Once identified, they remain Critical Chain tasks until the command is reissued or the tasks are manually changed. Sciforma provides an option to manually specify which tasks are on the Critical Chain because it is not always possible for an automated algorithm to identify these tasks. For instance, when possible Sciforma considers task and resource dependencies when calculating the Critical Chain, but if this is not possible, it will still choose a Critical Chain. In addition, Sciforma insets gaps or overlaps in the schedule, as explained below, if it cannot find a Critical Chain without them. The Critical Chain is identified while in Planning mode by using the Identify Critical Chain command, available either in the Tools > Critical Chain menu or an equivalent toolbar button. Depending on the complexity of the project, this process may be nearly instantaneous or take some time since the server is evaluating all possible Critical Chains and choosing the best. In any case, if there are any tasks in the project at all, Sciforma will choose a Critical Chain, even if there are no task and no resource dependencies at all. Sciforma does not display a dialog box or progress indicator (other than the hourglass), but simply changes the colors of the task bars in the Gantt chart. Sciforma sets the On Critical Chain task field to Yes for tasks that have been determined to be on the Critical Chain. (Note that parent, buffer, and hammock tasks are always excluded from the Critical Chain.) Since this process is choosing among alternatives, it is worthwhile to explain the criteria Sciforma uses in making its choice. The first applicable choice in the following list determines the Critical Chain outcome: 1. A Critical Chain consisting entirely of task and resource dependencies from end to end is always chosen over any chain with partial or no dependencies. 2. The chain with the minimum total gap between tasks is chosen over those with a longer gap. (No gap is the ideal case.)

17 3. The chain with the minimum total overlap between tasks is chosen over those with more overlap. Note that choices 2 and 3 combine to give priority to those chains that just touch from task to task. 4. The chain with the smallest number of resource dependencies is chosen over those with more. 5. The chain with the smallest number of tasks is chosen over those with more. Note that choices 4 and 5 combine to give priority to those chains which are richer in task dependencies. It is also possible to manually change which tasks are on the Critical Chain by adding the On Critical Chain column to the Task spreadsheet and setting to Yes for tasks that are to be on the Critical Chain and No for tasks that are not to be on the Critical Chain Adding explicit resource links on the Critical Chain The Critical Chain consists of both explicit links between tasks and implicit links that are due to resource dependencies. An explicit link is created when task A is physically linked to task B to denote a dependency. The explicit link is visible in the Network Diagram, Gantt Chart, and the Predecessor/Successor tabs of the Task Template. An implicit link is defined when task A and task B use the same resource and are scheduled in such a manner that an increase in the duration of task A will cause the start of task B to be pushed later due to the unavailability of the resource. Task B is said to have a resource dependency with task A. Note that for task A and task B to have this resource dependency, an overallocation of the resource must occur if task A and task B were to be scheduled concurrently. When a change is made to the duration of a Critical Chain task, the explicit task links will usually cause a scheduling change to successor tasks just as in Critical Path scheduling. However, when a change is made to the duration of a Critical Chain task that has an implicit resource link to another Critical Chain task, the change will not cause a direct rescheduling of the trailing Critical Chain task. To effect a schedule change due to implicit resource links, the schedule must be adjusted based upon resource loading, either through manual task adjustments or by using automatic resource leveling. Optionally, explicit links can be added to the Critical Chain by using the Add Critical Chain Resource Links command in the Tools > Critical Chain menu or an equivalent toolbar button. This command adds explicit links to Critical Chain tasks at the points where a resource dependency exists. These links are identified by the Task Link.Critical Chain Resource Link field. Explicit links added in this way can be removed by using the Remove Resource Links command, also available either in the Tools > Critical Chain menu or an equivalent toolbar button. This optional command should be used after the Critical Chain has been identified and before buffers have been inserted. 17

18 18 It is important to note that the addition of explicit links is an optional approach in Critical Chain planning. There are two benefits to this approach and one drawback: The first benefit is that the Critical Chain will be explicitly linked and behave similarly to a Critical Path. Any change in the duration of a Critical Chain task will directly affect the scheduling of the successor Critical Chain tasks. The second benefit is that the order of the Critical Chain tasks will be maintained when resources are leveled. Resource leveling adjusts the scheduling of tasks with the goal of obtaining the shortest schedule subject to resource availability. (There is a possibility that the order of certain Critical Chain tasks that have implicit resource links could change during this leveling as task updates change the durations of tasks.) The single drawback is that the addition of explicit links effectively creates a task dependency where there was only a resource dependency. If the resource situation changes during project tracking, the link may no longer be valid and could delay the successor task unnecessarily. When explicit links are used, the project manager has the added responsibility of reviewing the validity of specific links based upon any changes in resource assumptions during tracking. If a specific link is no longer valid, it should be deleted Inserting Critical Chain buffers At this stage of Critical Chain project scheduling, there is no margin of safety in the schedule. Resources have been asked to provide realistic, unpadded time estimates that have a 50% probability of being met. Furthermore, the project manager has not padded the schedule. Until a margin of safety has been introduced into the project, the odds of completing the project on time are very small. Safety in Critical Chain projects is added by inserting time buffers at key points in the schedule. A buffer represents a pool of extra time that is available to and shared by all the tasks that precede it. The inserted buffers absorb task overruns without affecting the target finish date. Critical Chain projects typically use the following buffers: Project buffer Protects against overruns in Critical Chain tasks. Placed after the last Critical Chain task in the schedule. Feeding buffer Protects against overruns in the feeding chains. Placed at each point a feeding chain intersects the Critical Chain.

19 Buffers can be inserted automatically while in Planning mode by using the Insert Buffers command, available either in the Tools > Critical Chain menu or an equivalent toolbar button. The resulting Insert Buffers dialog box provides controls to configure how the buffers are to be computed: 19 Calculation Method: Specifies how to calculate the size of the buffers to insert: Sum of Squares Percent of Safety Removed Calculate the square root of the summed variances between each task's Safe Duration and Duration fields. Use a percentage of the difference between the Safe Duration and Duration that was specified for each task. Specify the desired percentage in the box. Percent of Duration Use a percentage of the Duration that was specified for each task. Specify the desired percentage in the box. Dangling Chains: Configures how to provide safety for tasks that do not have successors and therefore do not intersect the Critical Chain: Connect to Project Buffer Insert Additional Project Buffer Connect the dangling chains to the Project buffer. Feeding buffers are then inserted on the (previously) dangling chains to add the appropriate safety factor before the chains intersect with the Project buffer. Use a separate Project buffer to hold the safety for dangling chains. Additive Constant: Specifies an additional amount of time to add to each buffer. This enables the project manager to ensure that the project has at least a minimal amount of safety even if the calculations do not produce a satisfactory safety margin. Round To: Specifies the time increment (Minute, Hour, Day, Week, Month, or Year) to which to round the buffers. If Sciforma calculates that the Project buffer should be 3 weeks and Month is specified in this list, Sciforma will create a Project buffer that has a duration of one month. Remove Existing Buffers: Enables Sciforma to calculate buffers for the entire project without regard to existing buffers. To maintain the existing buffers and just let Sciforma add to them if necessary, clear this check box. Resolve Resource Contention: Inserting buffers causes tasks to move and therefore may introduce new resource contention problems. Select this check box to automatically check for and resolve resource contention as soon as buffers are inserted. Clear this check box if resource contention should be handled manually.

20 20 After specifying these options, Sciforma calculates the buffers and inserts them as tasks into the Task spreadsheet with the names Project Buffer and Feeding Buffer. The duration of these tasks is the amount of time Sciforma computed using the information specified. Note: Project and Feeding buffers can be identified by examining the Task.Schedule Type field. Furthermore, an ordinary task can be manually changed to a buffer task (and vice-versa) by setting the appropriate value in this field Dissolving Critical Chain buffers At times, it may be necessary to remove all of the feeding and project buffers in a Critical Chain project. Perhaps a project must be reorganized and new buffers calculated; perhaps a Critical Chain project needs to be changed to a Critical Path planning model. The problem becomes: how to delete the buffers (tasks) and make the correct connections between their predecessors and successors. The tasks that are configured as buffers simply need to be snipped out everything connected as though those buffer tasks were never inserted. The Dissolve Buffers command automatically performs this operation. It is available on the Tools > Critical Chain menu or an equivalent toolbar button.

21 Tracking Critical Chain projects Sciforma uses two distinct modes to manage Critical Chain projects: Planning mode and Tracking mode. To track progress on a project, Planner must be in Tracking mode. Switching to Tracking mode does the following: Sets the project's Project.Schedule Direction field to Forward. Locks all buffers (as can be seen in the Task.Buffer Lock field), making them available for use as needed by task schedule overruns. Sets the Task.Pin Date on tasks that would move when changing from ALAP to ASAP mode. Setting a Pin Date prevents a task from moving in the schedule due to differences between scheduling it as late as possible or as soon as possible. Sets the Task.Schedule Type field for all tasks to ASAP (as soon as possible). Note that users can freely switch back and forth between Tracking mode and Planning mode as needed. Unless specific changes are made to the schedule, merely switching from one mode to the other does not affect the schedule. To switch to Tracking mode, use the Switch To Tracking Mode command in the Tools > Critical Chain menu or an equivalent toolbar button. If this command is unavailable, Sciforma is already in Tracking mode. Tracking a Critical Chain project consists of: Starting the project on time, not early or late Encouraging resources to finish early as though they are participating in a relay race Updating your schedule with actuals Adjusting Pin Dates when predecessor tasks finish early Managing the buffers

22 Starting a Critical Chain project on time Traditional Critical Path project management encourages team members to start and complete every task according to the dates published in the schedule. As slippages in the schedule occur, team members are updated with new starting dates. Focusing on each task's scheduled dates does not promote fast time-to-market. In fact, it ensures that any early finishes are lost because only late finishes accumulate in the schedule. Dealing with Critical Chain projects requires project managers to change their thinking somewhat. It is important to start each chain of a Critical Chain project on time, but no earlier than scheduled. Once a chain has been started, the project manager should focus on three things: Making sure the team has everything they need to get the task done. Finishing the task as fast as possible. Making sure the appropriate resources are ready to receive the hand off of the finished task. Unlike Critical Path projects, each task's scheduled start and finish dates should be deemphasized and the project manager should instead concentrate on preparing the team for the next task in the chain. Above all, this means communicating to team members at appropriate points to let them know exactly when to expect a task to be handed off Finishing tasks early Once progress is underway on a chain in a Critical Chain project, team members must be encouraged to think of themselves as participants in a relay race. Each team member should try to complete his or her task, or "leg" of the relay race, as quickly as possible, without regard to what the schedule says. The goal is to hand off the completed part to the next team member without delaying until the schedule says it is time. In a relay race, the competitive excitement of the race encourages the runners to do their best and beat their best times. Because runners capitalize on an early finish of the preceding runner, a fast leg can offset a slow leg to the benefit of the entire team. The relay race analogy provides the best visual image of how Critical Chain projects should be managed. Project managers should focus on making sure each member gets off to a running start when the "baton" is handed off from the previous member. A Critical Chain implementation can be designed to take advantage of reports, Forms, and automated notifications, enabling the project's tasks to make smooth and automatic transitions from one team member to another.

23 Updating the schedule In the same manner as a Critical Path project, the Critical Chain schedule should be examined updated regularly and frequently. The completed duration of each task should be recorded and the remaining duration updated with an estimate of the amount of work needed to finish the task as soon as that information is available. Unlike Critical Path projects, however, the project manager should not worry when a particular task overruns its estimate. Instead, project managers should take a big-picture approach and simply watch how the project and feeding buffers are affected by all tasks together. When the schedule is updated with new remaining duration estimates, the scheduling of resources as well as tasks changes. Such updates are likely to create resource overloads. These overloads need to be reviewed and consideration should be given to whether the schedule should be adjusted to remove them. One of the ground rules of Critical Chain project management is to avoid unnecessary rescheduling of a project once it is underway. Applying this ground rule to resource leveling means that the schedule should only be leveled when it is reasonably certain that a conflict will actually occur. If the resource conflict is close at hand and reasonably certain to occur, tasks will need to be rescheduled to avoid the conflict. If the resource conflict is far enough in the future, the conflict may resolve itself as ongoing task updates are made, and so should not yet be resolved until/if it becomes a more likely issue. The Resource Utilization view can be used alongside the Gantt Chart to identify resource overloads that are reasonably certain to occur. This side-by-side view can be configured by using Planner's View controls and then saved in a named Layout for future use. Overloads can be resolved by moving conflicted tasks with the mouse, by using resource leveling on selected tasks, or by using resource leveling within a date range. These approaches limit the schedule adjustment to meet the criteria of reasonably certain. They avoid resource leveling the entire project. It is important to note that the Critical Chain is defined as the longest chain of tasks based upon both task dependencies and resource dependencies. When an update is performed, the updated Critical Chain tasks that have task dependencies will directly affect the scheduling of their linked successor Critical Chain tasks. However, updates to Critical Chain tasks that have resource dependencies will not directly cause a rescheduling of the following resourcedependent Critical Chain tasks. The adjustment of task schedules to reflect resource dependencies must be accomplished by resolving resource conflicts using the techniques previously mentioned.

24 24 If the Add Critical Chain Resource Links command has been used to explicitly link Critical Chain tasks with resource dependencies, then updates made to the Critical Chain tasks will directly affect the scheduling of successor Critical Chain tasks without having to resolve resource conflicts. However, this does not remove the need to resolve resource conflict during task updating. Any changes in task durations can cause conflict and that conflict will need to be resolved if it is reasonably certain to occur using the techniques mentioned earlier. Additionally, if resource allocations have changed during tracking, the added resource links should be reviewed to ensure that they are still valid. These links can be identified by the Critical Chain Resource Link field in the Predecessor and Successor tabs of the Task Template. An important difference between Critical Path and Critical Chain scheduling is that Critical Chain uses a concept called Pin Dates. Because in Planning mode a project is scheduled to occur as late as possible, a Pin Date is applied to each task that would otherwise move when the schedule is switched to Tracking mode (and tasks are switched to ASAP mode). For example, in a feeding chain of five tasks, a Pin Date is set on the first task in the chain. To help users identify tasks with Pin Dates, a special symbol can be applied to a Pin Date filter in the Gantt Options preferences Adjusting Pin Dates Because a Pin Date defines the earliest date a task can start when in Tracking mode, the Pin Date field must be adjusted before a task can be scheduled to start earlier. This will need to be done if tasks start finishing sooner than planned and the starting dates on subsequent tasks need to be moved earlier. Pin Dates can be adjusted in three ways: In Tracking mode in Gantt Chart view, by moving the task earlier in time by dragging the Task bar. Sciforma updates the Pin Date when the mouse button is released. (Note that this approach can only move a task until it hits a predecessor.) By changing the value in the Pin Date field in any task spreadsheet. By switching to Planning mode, which removes Pin Dates, then restores them as necessary when Planner is returned to Tracking mode Managing buffers Managing buffers is the key component of tracking a Critical Chain project. But because task estimates are uncertain, project managers should not apply exact measurement techniques such as variance analysis and earned value to tasks. Instead, the Project and Feeding buffers should be monitored regularly, and the project manager should act according to how much of the buffer has been penetrated by task slippage.