Open main menu
Home
Random
Recent changes
Special pages
Community portal
Preferences
About Wikipedia
Disclaimers
Incubator escapee wiki
Search
User menu
Talk
Dark mode
Contributions
Create account
Log in
Editing
Critical chain project management
(section)
Warning:
You are not logged in. Your IP address will be publicly visible if you make any edits. If you
log in
or
create an account
, your edits will be attributed to your username, along with other benefits.
Anti-spam check. Do
not
fill this in!
== Details == With traditional project management methods, 30% of lost time and resources are typically consumed by wasteful techniques such as bad multitasking (in particular [[Task switching (psychology)|task switching]]), [[student syndrome]], [[Parkinson's law]], in-box delays, and lack of prioritization.<ref>Harvey Maylor, Project Management</ref> In a [[project plan]], the '''critical chain''' is the sequence of both [[:wikt:precedence|precedence]]- and resource-dependent tasks that prevents a [[project]] from being completed in a shorter time, given finite resources. If resources are always available in unlimited quantities, then a project's critical chain is identical to its [[critical path method]]. Critical chain is an alternative to [[critical path analysis]]. Main features that distinguish critical chain from critical path are: # ''Use of (often implicit) resource [[Dependency (project management)|dependencies]]''. Implicit means that they are not included in the project network, but must be identified by looking at the resource requirements. # ''Lack of search for an optimum solution''—a "good enough" solution is enough because: ## As far as is known, there is no analytical method for finding an absolute optimum (i.e., having the overall shortest critical chain). ## The inherent uncertainty in [[Estimation (project management)|estimates]] is much greater than the difference between the optimum and near-optimum ("good enough" solutions). # ''Identification and insertion of buffers'': #* Project buffer #* Feeding buffers #* Resource buffers (companies are usually reluctant to give more resources) # Monitoring project progress and health by monitoring the consumption rate of the buffers rather than individual task performance to [[Schedule (project management)|schedule]]. CCPM planning aggregates the large amounts of safety time added to tasks within a project into the buffers—to protect the due-date performance and avoid wasting this safety time through [[Human multitasking|bad multitasking]], [[student syndrome]], [[Parkinson's Law]], and poorly synchronized integration. Critical chain project management uses buffer management instead of [[earned value management]] to assess the performance of a project. Some [[project manager]]s feel that the earned value management technique is misleading, because it does not distinguish progress on the project constraint (i.e., on the critical chain) from progress on non-constraints (''i.e., on other paths). [[Event chain methodology]] can determine the size of the project, feeding, and resource buffers.'' === Planning === A project plan or [[work breakdown structure]] (WBS) is created in much the same fashion as with critical path. The plan is worked backward from a completion date with each task starting as late as possible. A duration is assigned to each task. Some software implementations add a second duration: one a "best guess," or 50% probability duration, and a second "safe" duration, which should have higher probability of completion (perhaps 90% or 95%, depending on the amount of risk that the organization can accept). Other software implementations go through the duration estimate of every task and remove a fixed percentage to be aggregated into the buffers. Resources are assigned to each task, and the plan is [[resource leveling|resource leveled]], using the aggressive durations. The longest sequence of resource-leveled tasks that lead from beginning to end of the project is then identified as the critical chain. The justification for using the 50% estimates is that half of the tasks will finish early and half will finish late, so that the variance over the course of the project should be zero.<ref>https://www.melbourne.pmi.org.au/wp-content/files/MWP1020_Critical_Chain.pdf {{Bare URL PDF|date=August 2024}}</ref> Recognizing that tasks are more likely to take more time than less time due to [[Parkinson's law]], [[Student syndrome]], or other reasons, CCPM uses "buffers" to monitor project schedule and financial performance. The "extra" duration of each task on the critical chain—the difference between the "safe" durations and the 50% durations—is gathered in a buffer at the end of the project. In the same way, buffers are gathered at the end of each sequence of tasks that feed into the critical chain. The date at the end of the project buffer is given to external [[Project stakeholders|stakeholders]] as the delivery date. Finally, a baseline is established, which enables financial monitoring of the project. An alternate duration-estimation methodology uses probability-based quantification of duration using [[Monte Carlo simulation]]. In 1999, a researcher{{Who|date=April 2010}} applied simulation to assess the impact of risks associated with each component of project work breakdown structure on project duration, cost and performance. Using Monte Carlo simulation, the project manager can apply different probabilities for various risk factors that affect a project component. The probability of occurrence can vary from 0% to 100% chance of occurrence. The impact of risk is entered into the simulation model along with the probability of occurrence. The number of iterations of Monte Carlo simulation depend on the tolerance level of error and provide a density graph illustrating the overall probability of risk impact on project outcome. === Execution === When the plan is complete and the project is ready to start, the project network is fixed and the buffers' sizes are "locked" (i.e., their planned duration may not be altered during the project), because they are used to monitor project schedule and financial performance. With no slack in the duration of individual tasks, resources are encouraged to focus on the task at hand to complete it and hand it off to the next person or group. The objective here is to eliminate bad multitasking. This is done by providing priority information to all resources. The literature draws an analogy with a relay race. Each element on the project is encouraged to move as quickly as they can: when they are running their "leg" of the project, they should be focused on completing the assigned task as quickly as possible, with minimization of distractions and multitasking. In some case studies, actual batons are reportedly hung by the desks of people when they are working on critical chain tasks so that others know not to interrupt. The goal, here, is to overcome the tendency to delay work or to do extra work when there seems to be time. The CCPM literature contrasts this with "traditional" project management that monitors task start and completion dates. CCPM encourages people to move as quickly as possible, regardless of dates. Because task duration has been planned at the 50% probability duration, there is pressure on resources to complete critical chain tasks as quickly as possible, overcoming student's syndrome and Parkinson's Law. === Monitoring === According to proponents, monitoring is, in some ways, the greatest advantage of the Critical Chain method. Because individual tasks vary in duration from the 50% estimate, there is no point in trying to force every task to complete "on time;" estimates can never be perfect. Instead, we monitor the buffers created during the planning stage. A fever chart or similar graph can be created and posted to show the consumption of buffer as a function of project completion. If the rate of buffer consumption is low, the project is on target. If the rate of consumption is such that there is likely to be little or no buffer at the end of the project, then corrective actions or recovery plans must be developed to recover the loss. When the buffer consumption rate exceeds some critical value (roughly: the rate where all of the buffer may be expected to be consumed ''before'' the end of the project, resulting in late completion), then those alternative plans need to be implemented.
Edit summary
(Briefly describe your changes)
By publishing changes, you agree to the
Terms of Use
, and you irrevocably agree to release your contribution under the
CC BY-SA 4.0 License
and the
GFDL
. You agree that a hyperlink or URL is sufficient attribution under the Creative Commons license.
Cancel
Editing help
(opens in new window)