No matter how good a project schedule is or how well resources perform in the execution of tasks in that schedule, if critical dependencies associated with the project are not included in the description of the effort, they represent considerable risk to delivering project value.

The Dependency Network

The primary aspect of planning in a Critical Chain environment is a process known as Network Building. It is a multi-pass approach designed to assure that no key dependencies for the project are missed. Like all effective project management planning processes, it starts, as Stephen Covey might say, with the end in mind. It requires careful consideration of what the project is about, emphasizing identification of the true value-generating aspects of the project. The TOC origins of Critical Chain provide a basis for this clarification, in terms of providing a focal point in the relationship of the project to the project owners constraint and the contribution of the project to an enhanced ability to achieve (more of) the organizations goal. From this analysis comes necessary clarity of objectives, deliverables, and success criteria, assuring that everyone is on the same page regarding success of the project.

Once the end is understood, Network Building quickly shifts to a focus on task dependencies required to get there. The clear definition of deliverables serves as a high level WBS, but rather than continue developing the individual hierarchical branches of a WBS, Network Building shifts to dependency identification. To the extent that projects are highly interdependent efforts, this emphasis on what is needed to develop a handoff is a more straightforward way of building a holistic set of dependencies than trying to search across the lower levels of branches of a traditional WBS. This also assures an emphasis on deliverables and handoffs through their identification as necessary inputs, with clarity further enhanced by a strong preference for verbose task descriptions (Jacob, 1998).

Once the first pass of major dependencies, from end to beginning have been developed, it is addressed for identification of the minimum resource capability needed for task completions. Very often, this emphasis on minimum capability helps identify additional supporting task dependencies, as assumptions about the use of masters versus journeymen and apprentices are uncovered. Once resource identification is complete, if they havent already been involved, the next pass in Network Building is a review of the task structure by representatives of those resources, highly useful for further catching missed dependencies and for assuring clarity of expected task outcomes.

Network Building and Risk Identification

The emphasis of Network Building in a Critical Chain environment is on clarity of task inputs necessary to support that tasks deliverables. The resulting discussion of input requirements are directly related to risks associated with the ability of that task to do what needs to be done for its required output. The backward building of the network assures that outputs are understood before defining inputs. This focus on dependencies is, in effect a focus on risk, since missed dependencies in plans and schedules are a serious source of risk. The repeated questioning of what do you need? followed by is there anything else that is needed? serves to trigger thought of things that could go wrong, i.e., identification of potential risks in delivering task outputs.

The iterative process (initial identification of task outputs and inputs, through resource identification and review, to estimation of durations and iterations) provides a series of safety nets enhancing the chances of catching more missed dependencies and risks.

Network Building and Risk Avoidance/Mitigation

Any effective planning process is about the identification and inclusion of necessary handoffs. These handoffs are the linkages of the chain of tasks -- they serve as inputs to some tasks and are developed as outputs of others. The plan -- the dependency network -- is simply the sum of handoffs that need to occur to overcome obstacles on the way to the projects objective and to minimize the effect of potential pitfalls along the way. To the extent that careful consideration is given to the completeness of necessary inputs, identified risks can be avoided or mitigated by adding additional tasks to the network.

In Network Building, the emphasis on input identification rather than on a flow of tasks or on isolated legs of a WBS helps to assure that risks of missed dependencies are avoided. It is far easier, once ones required outputs are identified, to come up with the full complement of necessary inputs, rather than try to guess what ones successor needs, especially when that successor is in some separate leg of a WBS.

Too often, plans include assumptions regarding the existence of necessary inputs. The incessant (some might say obsessive) focus on whether all identifiable inputs are sufficiently provided for in the network goes a long way to avoiding and mitigating risks that might have otherwise been buried in those assumptions.

Durations and Iterations

The final step in Network Building is the development of range estimates for both task durations and iterations. Critical Chain Scheduling utilizes a 2-point estimate, for both durations and iterations. Avoiding the idea of the oxymoronic accurate estimate, the Critical Chain approach explicitly accepts and takes into consideration the reality of variation and uncertainty associated with every project endeavor. With knowledgeable representatives of the appropriate resources involved, it is critical to understand what might happen in the event that Murphys Law strikes, and what could happen if the task in question gets lucky. This is applicable to both durations of particular tasks, as well as to the number of iterations associated with dealing with things that are unknown up front.

To this end, resources are first queried for a safe estimate -- one in which they have a high level of confidence, and are willing to consider a commitment. This defines the upper end of the possible requirements of the project components in terms of time. Once this upper limit is initially established, a second aggressive but achievable estimate is solicited -- one that reflects a near best case situation that is in the realm of possibility if things go well in the performance of the task in question.

Two-Point Estimates and Risk Assessment/Avoidance/Mitigation

Schedule and cost risk assessment are inherent in Critical Chains 2-point duration and iteration estimates. Once basic dependencies are identified in the Network Building process, the uncertainty and potential variation associated with individual tasks and groups of tasks are the next link related to the risk of keeping project promises and delivering desired value. Even if identified, mitigated, or avoided through additional tasks in the network, task delivery is still subject to technical or performance risk.

In addition to serving as the basis for turning the dependency network into a Critical Chain schedule, the 2-point estimation process is an excellent vehicle for further understanding risks and ways of addressing them. The first, commitment-level estimate should reflect the inherent task or iteration risk associated with the piece of the project in question. The difference between the larger and smaller estimates is directly related to the assessment of necessary safety associated with task estimates. The amount of safety necessary, relative to the aggressive but achievable estimate will highlight the level of risk associated with the task. The reasons for that safety, which should be a piece of the estimation discussion, will provide opportunities for identifying additional inputs and tasks that can serve to rationally reduce either or both of the estimates, or to help assure that they wont be exceeded in execution.

This article is an expanded version of one originally presented at the national Project Management Institute Symposium (Nashville, November, 2001). It is presented here in linked sections for ease of reading on the web. This version has been accepted for the 2002 World Project Management Week conference (Hong Kong, March, 2002). For off-line reading and sharing, the full article can be downloaded in Adobe Acrobat (pdf) format at ccrisk.pdf or in Microsoft Word format at ccrisk.doc.

Program Management -- Turning Many Projects into Few Priorities with TOC -- This link will lead to a paper on the key attributes of a TOC Multi-Project Management environment. (Most projects are performed by resources shared with other projects. It can be deadly to ignore the resulting interactions, no matter how well you manage single projects.) This paper was originally presented at PMI's Global Symposium in Philadelphia in October of 1999 and is included in the proceedings of that conference. Audio tapes of the presentation are also available from PMI.

Project Portfolio Management - The First Cut is the Kindest Cut - One of the common problems faced by project-oriented organizations is having too many projects relative to their capacity. Therefore, one of the first things that needs to be done is to determine what can be done is to determine what should be done . . . and what should not be done . . .