Five behaviors that can reduce schedule risk
Craig D. Peterson, PMP, Sr Project Management Consultant, EDS
Critical Chain Project Management (CCPM) methodology, by Eli Goldratt is one of today's hottest and most controversial methodologies to come out in a long time. Depending on to whom you talk, it is either the most exciting breakthrough in project management in a long time, or its just the most recent project management theory du'jour, which will like other methodologies, will fall by the wayside in time without any deep lasting impact. No Project Manager ever plans to deliver a project late, over budget or without all of the requirements, but somewhere along the way something unexpected and unplanned occurs. And despite the careful planning and sophisticated risk management techniques employed by seasoned professionals, projects are all too often still unable to recover from these unexpected events or the unknown unknowns. Why?
Traditionally, project management theorists have tackled this problem through a wide variety of quantitative techniques that have focused on everything from complicated mathematical models for estimating, to expert opinions, to scanning databases on past projects. CCPM takes a different approach to this problem. It claims our traditional project management methods incentivize people into negative behavior without realizing it. It is these behaviors that introduce risk to projects and are the cause of the majority of under achievements. By addressing these behaviors head-on and correcting them, the risk of project failure (over budget, late or reduced scope, etc.) is reduced and the probability of project success greatly increased.
While most project managers will agree that the behaviors exist, at least to some extent, the controversy surrounding CCPM centers mostly on the supposed dramatic schedule reductions that users of this approach claim to be able to achieve. However, if the people really do consistently behave as CCPM claims, then addressing these behaviors should reduce project risk whether or not the CCPM methodology is fully embraced and implemented. In fact, correcting these behaviors should work with, not against, any methodology. Additionally, combining it with solid risk management practices, as prescribed by the PMBOK® Guide should only enhance the probability of a project's success.
What are these negative behaviors that project managers are accused of inadvertently encouraging? The behaviors that CCPM purports to correct are:
• Protection of the Estimate
• Management to Due Dates verses Estimated Duration.
• Starting Tasks Earlier than Necessary
• Management of Key Resources (Constraint Management)
• Resource Multitasking.
Protection of Estimates
Protection of estimates is when people add a safety margin to their estimate (consciously or otherwise) to ensure that they can complete the work on time. In other words, people add this factor of time or money to their estimates as a contingency to protect them from risk or the unknown unknowns. Margin is increased until they are confident they can make the estimate.
CCPM assumes that duration estimates are based on roughly a 90+% probability or confidence level, since people do not like to miss their commitments. Instead of a 90% confidence level, CCPM argues that estimates should be based on the true “most-likely” or 50% probability. Then according to the law of averages, some tasks would finish early, some on time, and rest would be late. This “extra time” is then captured in a separate task or “buffer.” If additional time is needed to complete the task, then some of the buffer time is consumed. Likewise, if a task finishes earlier then expected, then positive gains are added back into the buffer. The majority of the buffers within CCPM exist to protect the project end date and tasks that feed into the critical chain.
The CCPM process typically cited for doing this is to take the task's estimated duration, cut it half and then add approximately 25% of the original estimate to the project buffer. This method for addressing protectionism is one of the most contentious CCPM issues to traditional project management practitioners. Many project managers are neither comfortable with doing this, nor do they believe that the amount of safety in their estimates is 40–50%. It must also be kept in mind that the point of this technique is to reduce the confidence level of the estimate to the true 50–50 percentage point, which may or may not be half of the original estimate. It would be inappropriate to half some point estimates, since some tasks will take a guar anteed amount of time (i.e., paint drying, concrete curing, etc.).
Is this behavior real on projects? In the environment described in Goldratt's Critical Chain, it certainly is conceivable. Team members provide estimates they can live with and the project deadline is established. What is not discussed is to what extent do market forces influence the project deadline, causing the overall schedule estimates to be adjusted to fit this externally imposed deadline. Team members will still push their estimate as far as possible, but can they still achieve 90%-plus levels, which are then divided in half under CCPM.
Whether or not you agree with the purely mathematical approach for reducing estimates, there is still benefit obtained by identifying the amount of safety added to individual tasks in a traditional (non-CCPM) project environment. Identifying the amount of contingency in an estimate allows the project manager to understand the perceived magnitude of risk associated with the estimate and opens the opportunity to take appropriate risk control actions. The basic four components of a risk management process listed in the PMBOK® Guide can be used to identify and quantify the magnitude of risk for each task. With this knowledge, the project manager can consider the use of a project buffer or other time contingency considerations within the (non-CCPM) project.
Starting with identification, the first risk management process, the goal is to identify the risks driving the size of the contingency. Inputs worth reviewing are the product or project description, other planning documents, and historical information. The tools or techniques, which can be used to draw out the risks, could be checklists, flow charts and interviewing techniques. Discussing with the estimator the size and nature of the contingency assigned may reveal additional unidentified risks and the perceived magnitude of the problem. After all, the individual's comfort level with the current duration effort is largely driven by the perceived risks inherent within the tasks. The results of this “contingency” risk identification process should then be incorporated into the project's risk management system.
The next step is to quantify the risks behind the extra time. As in the case of the other risks, the objective is to quantify how likely a risk is to occur and the potential size of its impact. In traditional project management methodologies, this quantified information may be used to determine and size the management reserves. In the CCPM methodology, taking the time to specifically identify the driving forces behind the risk would provide an objective means to more accurately size the project buffers versus having them simply driven by a non-varying mathematical process.
Once the risks creating the contingency has been identified and quantified, a risk response plan can be developed. As with other risks on the project, it must be decided whether a risk is accepted or whether developing a response is more appropriate. The responses could consider approaches that prevent, transfer or mitigate the risk impact. Naturally, any risks identified during this process should be monitored as they are for others in the project.
Controlling and monitoring project risk in both the traditional or CCPM environment will provide additional insight for evaluating the state of the contingency or project buffer. If the majority of tasks are finishing later than the estimated time and the management reserve or project buffer is being consumed rapidly then this is an indication that either unforeseen risks are occurring, or individual task risks were greater than anticipated. Based upon an updated risk assessment, the buffers can be reevaluated.
This process of delving into the risks that affect the safety margin or project buffer should give the stakeholders additional confidence in either a CCPM or traditional (non-CCPM) project environment. In summary, application of this technique, removing the protective time from the duration estimate, reduces risk in non-CCPM projects for three reasons:
1. The amount of unknown-unknowns has been reduced through the further investigation of the risks. This reduces the size of the management reserve or project buffer to appropriate levels.
2. The risk driving the contingency or project buffer is being dealt with in an open manner, presenting an opportunity to decide in advance how to handle the risk.
3. It helps assure the stakeholders that the sizes of the risk budget, management reserve or project buffer is appropriately sized for the risks involved.
Due Dates vs. Estimates
Project plans generally include both the estimated work of a task and the expected start and finish dates. CCPM argues that people focus on the due dates of tasks, not the amount of effort it will take to complete the task. And, with the task's due date far in the future, the project participants do not become 100% focused until the work is much nearer. CCPM refers to this as the “student syndrome.”
The student syndrome affects projects in the area of the time lost due to late finishes. The contingency or safety that the estimator added to the task is often consumed (lost) during the slow (less focused) start. If and when unexpected events occur, the task finishes late. Conversely, CCPM argues that if a task finishes early, then it is rare that the timesavings are captured to help offset the late finishes. This failure to capture an early start opportunity can result from two different events: (1) there is a conscious decision to not start ahead of the scheduled task start date, and/or (2) the task lead is not informed that the preceding task has finished early.
To avoid student syndrome, CCPM advocates giving people only the task's work effort estimates. By eliminating the due dates, along with reducing the task estimate to a 50% confidence level, the project team has no choice. They must start on the task right away and are one hundred-percent focused on completing the objective. Should schedule variations occur under these conditions, it is not due to team focus, but to other (risk) events. In these situations, the project manager ensures that the project will still finish on time by drawing upon the project buffer. Likewise, when tasks finish early, gains are captured here. The objective of this technique (focusing upon duration estimates) is to force people to be completely focused on the task that they are working upon, and nothing else. The project manager alone will concerned with the projected finish date, and closely tracking the progress of the different tasks in relation to the due dates for key deliverables and project completion.
The importance of focusing the team on their tasks cannot be understated in the CCPM environment. If the task estimates are reduced to fifty-percent, and the team members are not focused, then tasks will finish late, consuming the project buffer at an abnormal rate. Additionally, without the benefits of positive gains from finishing tasks early to offset the time lost to tasks finishing late, then the project will finish significantly past the targeted completion date.
Applying this behavior on traditional and non-CCPM projects works equally as efficient. If the team members can be successfully encouraged to focus their efforts immediately when starting off a task, and remain 100% committed to it, then the probability of achieving the most likely duration estimate becomes plausible. Additionally, the expected plus and minus variations around the average estimate should then also be observed.
This technique is all about changing the way people work, not a particular methodology or technique for managing projects. Working to effort estimates instead of due date requires change and support from both the project's management and team. There are several behaviors project managers and team members need to embrace to support this change. First, project managers should concentrate on how much effort is needed to complete a task, not how much effort has been expended. By focusing on how much effort remains, the project manager will understand if the task can be completed within the estimated time or additional time from the contingency or buffer will be required.
The second behavior change is for project managers to change their reaction to missed estimates. If estimates are based on the CCPM recommended 50% probability, then management needs to be prepared to accept that some tasks will be late (i.e., as many as half of them). Traditionally, there have been penalties for finishing over an estimate to dissuade people from being late. If a project manager continues to punish people when they do not make estimates that have a true 50% of failure, then the resources will quickly become demoralized and lose their initiative. A project manager in this situation could quickly find themselves in a much worse position than if they had not implemented any change. Lastly, the team members need to be willing to change their work habits by giving their best effort to meet the estimated effort and be willing to pass on the early completions when they occur.
The risk analysis and management processes outlined in the PMBOK® Guide is unaffected by the adoption of this behavior, and may actually be enhanced. Focusing resources on the task identifies issues and missing information early. This provides the greatest opportunity for proactive actions to deal with the unexpected.
Starting as Soon as Possible
Traditionally, project management plans have been built on the assumption that all tasks should start as soon as possible. This convention is so strong that virtually all project management software programs default to the start as soon as possible mode. CCPM criticizes this practice as one of the causes for lost resource time.
CCPM advocates starting tasks as late as possible to prevent rework, which occurs when work is started without all of the necessary knowledge and must be redone once all the necessary information is finally attained. Another source of rework results from scope changes that take place during the course of executing the project. By starting the task late, both of these scope impacts can be easily incorporated into the work not yet started. CCPM does not take the view that scope changes are negative and should be avoided, but rather it recognizes that changes will occur and provides a proactive means to deal with it that minimizes impact.
There is another benefit from starting tasks late. Consider the previously discussed behaviors (protecting the estimate and managing to due dates versus effort estimates). Tasks allowed to start early can expand to fill the time available. Starting as late as possible provides a mechanism to control and support these previously discussed behaviors.
The CCPM methodology does include buffer time with the task estimate to determine the last possible start date, that is, it adds a buffer at the end of a sequence of tasks that feed into the critical chain. Therefore, the latest possible start date is actually as late a project planning software program will schedule it, corrected then for a feeding buffer. Risk management affects this technique in two ways. First, as previously discuss the size of the buffer should be based on the risk of the project and the tasks that the buffer is supporting. If the buffer is too small to mitigate the task's estimate over run, then the end date may be jeopardized. Secondly, controlling and monitoring risk throughout the project will provide an indication of whether or not the late start dates need to be revised.
This is certainly not a behavior currently practiced in traditional project management environments. However, non-CCPM projects can also reap similar benefits by moving tasks to the latest possible start date. By delaying tasks, the latest knowledge and information can be considered. Risk management plays a crucial role in determining how late a task can start, since buffers are not normally used in a non-CCPM environment. Risks need to be evaluated and considered at both the project and task levels for the probability and impact of risks. The results of the risk analysis is then considered when determining the task's late start date.
The traditional environment should not hesitate to employ this technique despite the lack of buffers for several reasons. First, even starting just a few tasks later than their early start dates can produce significant project savings. For example, equipment that is ordered early and then sits idle for several months waiting to be used ties up the company's capital. Second, this action prevents work from expanding to fill the estimated (available) time. Finally, starting tasks later allows more flexibility when competing for scarce corporate resources.
The benefits of employing this behavior can be tremendous for project stakeholders both within and outside the immediate project team. Starting tasks at their latest possible start date is similar to managing inventory on a just-in-time basis. By keeping resources free until they are truly required allows them to be utilized on other projects. This saves money, and in some cases, it helps to relieve the over scheduling of scarce resources. And as previously stated, it supports the other behaviors already discussed, such as safeguarding against expanding work to fill the time.
Management of Key Resources
The management of key resources within CCPM addresses how the scarcest resources are handled. These resources are typically the biggest constraint to progress since the project will not be able to move any faster than the availability and pace of these assets. The constraining resources could be anything from a special piece of machinery to an individual person or limited group of people with a unique skill set. However, in today's fast-paced technology driven economy, it is more often the case that companies suffer from a shortage of a skilled-labor type.
CCPM tackles the management of key resources on several fronts. Once a critical resource is identified, the next step is to evaluate the resource's tasks, timing and workload. Under the CCPM methodology, critical resources should only perform those tasks for which they alone can uniquely fulfill. In other words, it is important that the critical resources not be assigned to tasks that other team members could perform.
The second thing that CCPM focuses upon is the timing associated with the resources. This is addressed from two vantages: will the resource be ready to start the work when required, and will the work be ready for the resource to start? To accomplish this, two different buffers are employed. Feeding buffers ensure work arrives to the constrained resource early to on time, preventing lost time by the constraint. In a multiproject environment, resource buffers are used to ensure the availability of the constraint in time for the project's needs.
Equally important in CCPM is the key resource's workload. This is because even with maximum efficiencies conditions applied, these assets can only process work at a prescribed rate. Therefore, there is no benefit in having other resources building up an inventory of work that cannot be processed in a timely manner. This is another supporting argument for commencing tasks later than the early start date.
The traditional project management environment can utilize all of these actions for managing key resources with only minor adjustments. Of the three actions proposed by CCPM for managing the constraint, ensuring that the key project resources are focused solely on the tasks that only they can perform is relatively easy to determine and implement. The way to determine this is to ask whether that resource is the only one that can perform the task or whether it has been assigned to that resource simple because they have always performed this type of effort in the past. This is what Goldratt calls “corporate inertia,” and critically examining your reasoning process helps to break this cycle. If the later is the reason a resource has been assigned the task, then reassign it to another resource is wise and benefits the project and the corporation.
In the traditional project management environment, schedules are typically planned around a system lifecycle, industry norms and/or customer input. This is particularly true with regards to the required due date. The key resource(s) is rarely, if ever, considered. Traditional software relies strictly on the logical dependencies of the different tasks. While not as convenient, the schedule can still be manually analyzed (filtered) for those tasks requiring the limited (constrained) asset. Knowing where the constraints are used provides the project manager the opportunity to proactively intervene, and to manage them relative to risk events.
The buffers that CCPM implements to ensure that the project is ready for the key resources on time can be emulated in the traditional environment by using float time. Managing the float time between the predecessor tasks of the key resource tasks will act in a similar fashion as would be gained through the use of CCPM feeding buffers.
Applying this approach early in a project can significantly lower schedule risk. Frequently, the risk of key resources is simply ignored on projects. The constraint defines the project's pace; therefore, their time lost here can never be recouped, which can only result in project deadlines being missed. Identifying and managing these resources early will produce less schedule variation. One of this paper's authors has applied constraint management techniques to several different projects that were inherited in a “distressed” condition mid-schedule. The results were dramatic improvements in the team's productivity, which greatly improved upon the forecasted performance. Based upon what was seen on these projects, if this approach were applied earlier in a project, the expected benefits are significant.
Multitasking is defined as assigning one person to working on two or more task simultaneously. This occurs most frequently when resources or specific skill sets are scarce, and in consulting organizations where the utilization of resources is directly related to revenue. Multitasking is considered by CCPM to be one of the most disruptive behaviors to projects, since the time lost by the resource's constant refocusing can be considerable.
CCPM recommends that multitasking be eliminated. For example, instead of having a resource spread 50% between two tasks for two weeks, focus 100% on only one task for the first week and then on the other task for the second. Another alternative to resolve this dilemma would be to add a second part-time resource for one of the tasks. Again, other previously discussed behaviors (i.e., avoiding student syndrome) work in support of correcting this behavior.
Multitasking is clearly present in most traditional project environments, and its reduction is beneficial for them. As in the CCPM environment, the ideal way is to eliminate multitasking from a project is to simply not schedule any from the start. (When identifying resources that are multitasking, it is prudent to look for resources not only on the immediate project, but also on other corporate initiatives.) If its elimination is not practical, the first question is to determine if the multitasking involves the constraint. If not the constraint, then this resource might have sufficient capacity to deal with the inherent inefficiency that comes with multitasking. If the constraint is involved, risk management can be used to help assess and respond to the impact it will have on a project. Then, an appropriate response can be developed and plan put into place should inefficiencies exceed levels that the project cannot accommodate.
Remember, multitasking can come from both within and outside the project. Corporate initiated efforts and their impact on projects from sharing/multitasking resources is not specifically managed in non-CCPM environments. The project manager's ability to eliminate them is often very limited. Risk planning can be used as the primary medium to communicate this impact to upper management, as well as any resource needs to mitigate its impact.
There are several benefits that come with removing project multitasking, which also reduces the overall project risk level. First, the elimination of multitasking supports keeping people focused on the their immediate tasks, which lessens the probability of schedule risks taking place. This behavior change also works in concert with working toward task estimates and not due dates. Second, it eliminates conflicts between priorities, keeping team member focused on those items that critical for project success. Lastly, removing the conflict and confusion created by multitasking allows progress to more clearly be measured. All of these benefits support reducing project risk and reaching the end goal of finishing the project on time, within budget and without scope reduction.
Critical Chain Project Management takes a new approach to the challenge of delivering projects on time, within budget and with complete scope. Instead of devising a new mathematical model or a complex estimating system, it seeks to approach it from a different direction … to change the behavior of the project manager and team members. CCPM assumes good project management practices, such as well-defined project plans and solid estimates, are already in place. It is atop this that the behavior components sit.
Do the behaviors that CCPM address really exist and are they the problem they claim to be? Will using them help the project to be completed when it was originally planned? Yes, from our experiences, they are real and tend to create the problems as described. However, these problems do not necessary require the introduction of different techniques, such as CCPM, to get them under control. These behaviors can be easily introduced in the traditional project management environment. They do not necessarily require all the process of critical chain to yield benefits. Additionally, while mutually supporting one another, some can be implemented independent of one another.
Changing these behaviors do remove risk from the project, particularly in the schedule. Constraint management and multitasking help improve the productivity by which the project team converts the plan into results. The implementation of these two behaviors adds little in the way of new, collateral risks.
Removing hidden safety time (estimate protection), managing to effort, and starting tasks as late as possible come with both benefits and a note of warning. These behaviors work together to focus team members only upon the task at hand, it increases the likelihood of capturing positive schedule variations, provide a means to incorporate the inevitable scope creep, and provide a built in reserve to protect the project end date. With minimal effort, they can be incorporated into the non-Critical Chain environment; however, they do introduce some risks that must be proactively managed. For the tasks to be shortened in a reasonable and responsible manner, and then started as late as possible, they must be fully understood. Communications is key to dynamically adjusting and preparing the successor task team members to start when the predecessor work is ready. A solid risk management program must be in place to support these behavioral changes. Identifying and quantifying the risks, and then defining and controlling the appropriate risk responses, allows these benefits to be maximized. It is our opinion that the risks introduced are predictable and controllable, and support the judicious use of these changes. For those less daring, multitasking and recognizing/maximizing the constraint's productivity comes with very few penalties in the non-CCPM managed project.
Many projects have performance issues. By incorporating even some of these changes, a tangible and measurable improvement should be observed. Given the poor project performance in some industries (the Information Technology industry results in this area are already well documented), even improvements as little as 2% or 3% are valuable, particularly in this case where the investment cost is zero. Once project managers and stakeholders can see tangible and positive changes, stakeholders will become more motivated to support fresh and more intensive approaches, and to bearing the cost which come with them.
PMI Standards Committee. (1996). A guide to the project management body of knowledge (PMBOK® guide). Upper Darby, PA: Project Management Institute.
Goldratt, Eliyahu M., (1997). Critical Chain.
Goldratt, Eliyahu M. (1984). The Goal, A Process of Ongoing Improvement.
Kerzner, Harold. (1998). Project Management, A Systems Approach to Planning, Scheduling, and Controlling.
Leach, Larry. (1997). The Critical Chain Project Managers' Fieldbook.
Newbold, Robert C. (1998). Project Management in the Fast Lane.
Proceedings of the Project Management Institute Annual Seminars & Symposium
September 7–16, 2000 • Houston, Texas, USA