LEAN CONSTRUCTION PROCEDURES (LCP®)
LEAN and Critical Chains
Critical Chain programs
Introduction Here's a high level view of some of the major concepts involved in Critical Chain approach to project management and why they do what they do.... The focus should alway be on the end date - this is the promise that we set out to achieve. Most project do not finish on time - count the ones you have been on - statistics quoted are that 70% do not achieve the planned completion date! Critical Chain (CC) Programming is about changing focus from individual task completion to undertaking an analysis of making sure we complete by the promised date.
Given that 70% of projects don't manage to do this - this seems like quite a goal. As a matter of fact, the scheduling mechanisms provided by CC scheduling allow/require the elimination of task due dates from project plans. Its benefit is that it allows those who use it to partially avoid "Parkinson's Law;" i.e., work expanding to fill the time allowed. Take away the idea of time allowed, and you've got half the battle won.
But how to do that is the question that requires us to look at some current common project practices. Project tasks are subject to considerable uncertainty, from both the unknowns of the invention process (in development projects especially) and from the universal effects of "Murphy's Law." As a result, task estimates that make up project schedules can contain considerable "safety" in them to try to allow for these unknowns when planning the project. Given this all task have uncertainty - Do you have a choice in deciding what task duration you will use?
Most choose "Accurate Estimate" This is an oxymoron - a contradiction in terms. This lies at the root of programming error.
We believe that the estimates used for task durations are accurate! How can they be - often an estimate is chosen a year in advance of the task - " the equipment will be delivered on a wednesday in February in eight month time", we are then somewhat surprised when it isn't. Why are durations round numbers? Ten days, Five days, etc Why not 3.4 or 6.7 days? Why do they start on Monday and finish on Friday? Why not Tuesday etc The truth is, we know they are only vaguely right - but forget that this was the case when these are added in line by logic and presented on a 1000 line programme.
How can this be improved?
The Theory Of Constraints approach addresses this expansion of project plans with two mechanisms. In addition, many project organisations are multi-project enterprises, with resources frequently working across projects on more than one significant task in any particular period of time. This practice of multi-tasking, unfortunately common in many project organisations in many industries, also leads to expanded project lead times because when a resource alternates between tasks/projects, the task times for an individual project are expanded by the time that is spent on the other projects' tasks. Project resources are aware that they're in this multitasking environment and so their task estimates are further expanded (even unconsciously multiplied by factors of as much as two or three) to account for this practice in project task commitments. The combination of the effect of the multi-tasking environment and the need to cover uncertainty lead to "realistic" project task estimates that contain considerable "safety" above and beyond the actual work time required for a task, and subsequent project plans and commitments that include these expanded times.
The Theory Of Constraints approach addresses this expansion of project plans with two mechanisms. First, we remove the safety from the tasks, and aggregate it as "buffers" of time that are sized and placed in the schedule to protect the final due date of the project from variability in critical tasks and that protect critical tasks from variability in non-critical tasks that feed them. These buffers now allow us to shorten task time estimates to aggressive target durations, shortening the time within which resources strive to to achieve their tasks. These short target durations (approximately 50% confidence estimates, whose expected overruns are isolated from the actual project commitments by the buffers), also support the second mechanism.
They are so short that the resources are uncomfortable succumbing to multi-tasking or other distractions. The LEAN Buffer Progress Chart Provide the project manager and/or team with a clear indication of the health of the project at any point in time. Quick Links This behaviour supports the additional requirement posed by the CC methodology for management to enable resources to focus on tasks and to eliminate the multiplying effect of multitasking on project lead times. This is intuitive to many of us -- we often-isolate project teams from multitasking in special task forces or "skunk works" when projects are of special importance.
What the TOC approach allows us to do is apply this common sense solution to the overall project environment. OK, so we've reduced task estimates, but we still have these buffers that include the protection that was previously spread around and hidden in the tasks. Note that I mentioned using 50% confidence estimates for the task durations. That means that, if allowed to focus on the tasks, half of the time tasks will be done in less than the target plan and half the time they will take longer. Due to the statistical nature of this uncertainty of tasks, this leads those using the TOC approach to be able to use buffers that are significantly shorter than the sum of the safety that was spread around in the previous scheduling paradigm. After all, those that come in ahead of time will replenish the buffer that was consumed by those that took longer than expected, assuring the protection of the only date that counts -- the final project due date.
So with the combination of reduced task estimates due to the aggregation of safety and the reduction of buffer size, overall project plans can be typically 20-30% shorter than traditional plans with similar initial risk. There is also another benefit of the use of the buffers, beyond protection of due date performance. They aren't just passive chunks of time in the schedule, but rather also provide the project manager and/or team with a clear indication of the health of the project at any point in time.
The tracking of the consumption of these buffers provides warnings and indications of potential problems far before the project promise is in real trouble, allowing development of recovery plans in an atmosphere other than one of crisis. Once a project plan is implemented and underway, TOC's "Buffer Management" provides built-in risk management and therefore enhanced reliability of meeting the project due date, even with the shortened overall project lead time. RAG Lights for Watch, Plan and Act Shorter project lead times, improved reliability of project due dates, and increased capacity of the organisation As a summary for individual projects, the TOC approach, by viewing the project as a whole system instead of simply as a chain of independent tasks, allows for both shorter project lead times and enhanced reliability.
But as I said before many project organisations are multi-project environments. How can TOC provide guidance for enhancing the ability of a multi-project organisation to be more productive in the quantity of projects or new products undertaken and delivered? Project and task times, due to focus and buffering, are shortened. Therefore, first we expect that the capacity hidden in and consumed by practices such as multi-tasking and task-based safety can be unleashed to simply do more work in the same timeframe. But even beyond that, the core of the TOC view of multi-project environments lies in recognising that within a project organisation, there is some resource that can be considered a bottleneck or constraint limiting the ability of the organisation to do more projects. When we manage the individual projects using the TOC approach, the lack of multi-tasking and embedded safety makes it easier to ascertain the true capacity of project resources, and hence identify the constraint resource.
Once the organisation as a whole is managed with the constraint in mind, management attention becomes far more focused and decisions to further enhance project capacity are easier to justify and implement. Shorter project lead times, improved reliability of project due dates, and increased capacity of the organisation to take on more projects are not only predictable but have been observed in a number of organisations that have used this approach to projects in a variety of industries.