Critical-Chain-Project-Management, CCPM, is the most successful and widely known application of TOC. The most striking feature of CCPM is the handling of uncertainty, and the second most striking feature is the understanding of the impact of performance measurements on the human behavior and how it affects the performance.
I’ve put handling of uncertainty first, because adding a visual project buffer time at the end of the project is a bold statement that we do not really know the exact date when the project would finish. It is a clearer buffer than the DBR buffer, which seems like a regular lead-time attached to a chain of operations. This concept of the project-buffer is a significant contribution to handling of “common and expected uncertainty”.
The famous Goldratt saying “Tell me how you measure me and I’ll tell you how I’ll behave” was coined a decade before CCPM. The realistic negative impact of performance measurements on the behavior of humans is clearly seen in the shop floor and it is even more relevant for projects, where people are the key resources. The devastating use of multi-tasking is also derived from performance measurements that judge every project manager in isolation from all other open projects and by that force him to fight for “his project.”
While CCPM is a breakthrough of huge value, one should always ask:
What are the boundaries of the given methodology?
In other words, when the use of CCPM is beneficial and when certain changes have to be introduced?
It all comes to checking the assumptions behind the methodology and when they are not valid.
Just to illustrate the point let’s think about a program to find a cure for cancer. At the beginning of such a research is it possible to give it a due-date? Is it possible to build the network of tasks for the whole project? Do we have any idea how long it would take? Is there any role for a project buffer when you do not have a due-date to start with?
Here is my list of basic assumptions behind CCPM, which might be sometimes invalid in certain situations:
- We have a good enough idea how to perform the project from start to finish.
- In particular, we have a good idea, from the start of the project, what features have to be developed.
- We do not have conditional points in the project that could dramatically change the downstream operations or go backwards to an earlier task.
- Completing the project before or at the due-date is of utmost importance.
- Finishing on-time is nicely correlated to meeting the specifications and budget.
- The control on the progress and its timing issues are at our hands.
- We plan to work continuously on the critical chain. Without that the definition of the critical chain as what determines the duration of the project is meaningless.
What happens when one or more of the basic assumptions are not valid?
Let’s view two examples:
Suppose the client has to confirm certain stages in the project, and the client takes his own time to confirm. Two assumptions are not valid: the fourth and the firth. The fourth is invalid because we do not have the means to force the client to adhere to our timetable. The fifth is invalid as the whole project is in hold during the client’s check. One might include the client’s task in the planning and assume a certain 50% time for that task. The point is – when the client delays the signal to go ahead how can the project people keep the due-date?
My recommendation for such a case is to cut the overall project into subprojects. The project team controls the progress until the client gets the output for confirmation and that is the completion of project one. Once the client confirms to go ahead, even with new requirements, the second project starts.
Another problematic project is one where the due-date is mandatory, so no delay is possible. In such a case the content of the “complete project” might be much less than the original plan, or the costs might go up sharply, which means the third assumption is invalid. The time buffer does not protect all the truly relevant variables. The planning of such a project has to make clear distinction between “must-have” and “nice-to-have” features. I can see a direction of solution with a buffer-of-nice-to-have-features on top of the project-buffer protecting the mandatory due-date.
A general comment: I find CCPM as the least holistic methodology in TOC. It is target to solve a problem that is quite common, but not necessarily the key problem of the organization. I’m troubled by solving an undesired-effect (UDE) without seeing the overall picture. You can improve the management of projects and the organization would not reach more of the goal.
As a concluding anecdote: I met a high executive is a huge international conglomerate. When I mentioned the nice CCPM implementation done in Israel, the executive commented: “They finished early the WRONG project!”
Shouldn’t TOC be involved not just in the planning and execution of the projects, but also making sure they are the RIGHT projects with the right choice of content and specifications?
Can we do it without being involved with the Strategy of the organization?
Eli Schragenheim 
Hi, Eli.
Great analysis you have done. Probably it’s time of new “Standing on the Giant’s shoulders”.
If I would answer on your question about our ability to perform project excellence, I’ll say NO. My answer have following reasons:
1. Consultants should have enough reasons about maximizing clients competitive advantage. Sometimes clients don’t talk about strategy because they don’t have this perspective of working and stack on old paradigms.
2. Client’s didn’t pay on results they have’t ordered;)
Thank you for this work.
LikeLike
Eli –
I have to say, I find this post perplexing. I disagree with each of your basic assumptions, to greater and lesser degrees. I believe there will almost always be value in planning and in managing uncertainty, whether these assumptions are valid or not.
I’d be happy to elaborate if that seems useful, but for now I would say my biggest issue is item 2: completing before the due date is of utmost importance. Take the case of new product development. Very often, some projects are worth a lot (could be $1M or more for each day delivered earlier) and some projects are worth little. CCPM works well in such situations, but it will typically still make sense to focus on the high-value projects, even if they are tracking on-time and low-value projects aren’t.
It might be helpful if you were to provide your view of what CCPM is. I suspect your definition is quite different from mine, and maybe from that of others as well.
Best regards,
Rob Newbold
LikeLike
Rob, this disagreement is quite surprising to me, but we have not talked to each other for many years.
What does it mean you disagree with my assumptions? The regular interpretation is that even when the assumption is invalid the methodology is still operational as is. However, your example for the second assumption is trying to argue that early completion is ALWAY beneficial. This is not a challenge to the assumption.
What is CCPM? It is a detailed methodology, and I don’t intend to discuss details that certain known disagreements exist, like the use of feeding buffers or the use of virtual drum. We do have a methodology called CCPM and it is different than Scrum. I have also clearly stated that when one of the basic assumptions is not valid then certain changes have to be implemented, thus I’m NOT claiming CCPM is totally useless in these cases.
I fully agree that we ALWAYS have to manage uncertainty and it has to impact both the planning and the execution, but there are many ways to that, including using different buffers than time.
Just some examples where early completion is damaging:
1. In the construction business of building apartments the timing of the completion, assuming most of the apartments are not already sold, should be inline with the economy of the real-estate. I have seen cases where contractors have put construction on hold for a year or two and I think they were right. Completing a building and letting it stay empty is very damaging. Even in the case of new product development, marketing consideration might suggest to delay a launch, and completing the product too early has the same negative branches of any “early start” decisions.
2. Suppose you run a project for a client, who manages a much larger project. If your client uses CCPM for his big project, then your project would be a task in a chain with a buffer, and the state of the buffer gives you a hint when it is critical to complete. What happens when the client does NOT use CCPM, and he is facing long delays from other suppliers? Is it critical to finish your project as soon as possible?
Time buffers are one mechanism to handle uncertainty. There are others, and based on the validity of the assumptions we should use them in addition, or even replacing, the time buffers. When this happens the resulting methodology would be quite different than CCPM.
LikeLike
I am surprised by the comment you make that CCPM is the least holistic methodology in TOC. If the application of CCPM is to run a single project then I could understand the statement, however when considering a system which exists to deliver projects then I would disagree.
In attempting to maximise throughput of such a system (i.e. a project delivery or engineering organisation/department) then I actually find CCPM quite holistic as the critical chain relates to the resources that constrains the delivery of the most projects.
What I have tended to see is the use of the planning approach of CCPM with a limited discipline in managing the scheduling and execution of the projects to the constrained resources because there is insufficient stability in the system based upon varying types of projects, fluidity in the resource pool or a lack of good design and implementation process providing adequate consistency to manage to. Most projects end up following critical path scheduling mentality once the original plan is done.
Determining which projects should be performed in my view has nothing to do with CCPM, but with appropriate prioritisation based upon improving the profitability of the broader organisation, i.e. elevating the constraint in the core production system of the business.
LikeLike
Michael, first my comment is that CCPM is the least holistic, which means the others, like DBR, replenishment and the TP are more holistic.
Even when CCPM is implemented in multi-projects then the 5FS, throughput accounting are, usually not part of the implementation.
Goldratt has defines three critical areas for multi-project environments:
1. How to decide which project is worthy?
2. How to manage the content (what features to include)?
3. How to manage the project through the timeline?
He said that CCPM answers only the third question. In order to have a truly holistic methodology we need the other two.
LikeLike
I understand what you mean now, the application of DBR without other aspects of TOC would suffer the same limitations you state of CCPM. The issue as I see it is not with CCPM itself but with the application of TOC to a project delivery system.
I would suggest this is mostly due to a limited understanding of what, or how many, systems make up a company, and how they interact with each other.
LikeLike
Eli –
My understanding regarding your basic assumptions was that you were saying “without all of these assumptions being valid, CCPM is not applicable.” Your examples seemed to indicate cases where the situation was changed to conform to your basic assumptions. If all you mean is that “if any of these assumptions are invalid, certain changes have to be implemented,” I’m less uncomfortable – except that “changes to what” is the obvious and wide-open question.
My point on due dates was that their utmost importance is not a necessary condition for the applicability of CCPM. There is no question but that sometimes due dates are all that matters, although in my view they often matter much less than people believe.
I agree regarding the importance of understanding the boundaries of the methodology. I also agree that many of the possible details (e.g. feeding buffers) don’t seem relevant for this topic. And, of course, there are many other methodologies, such as Scrum, that can be applied to projects.
As you well know, many practitioners have modified CCPM in order to fit their perceptions of the needs of different markets. So all this begs the question: which CCPM are we talking about? I don’t accept your basic assumptions as defining boundaries of CCPM. Maybe that means we have different understandings of what CCPM is. If that’s the case, I’ll continue to have trouble understanding your reasoning. And others probably will as well.
Rob
LikeLike
Rob,
In my original post I wrote:
“What are the boundaries of the given methodology?
In other words, when the use of CCPM is beneficial and when certain changes have to be introduced?”
I heard your presentation on the feeding buffers. What CCPM (feeding buffers are relevant only to CCPM) did you refer to?
You also wrote the first practical book on applying CCPM (Project Management in the Fast Lane). Can’t we take this reference as a broad definition for CCPM? Yes, some changes occurred, but there is still good enough knowledge what is considered to be CCPM. If some people introduced very substantial changes, including dealing with some of the assumptions I have mentioned, then those changes were not circulated within the TOC community. So they are “their CCPM”, which I have no idea what it is.
Regarding the importance of due-dates. “My CCPM” is a methodology to achieve better due-date performance of projects, maybe also shorten the duration of projects. Goldratt has defined that objective and many presentations I have seen addressed the common UDE of “too often our projects are significantly late”. The purpose of the project buffer is aimed at that target. If the due-date is not critical I don’t know what is the use of the project buffer.
When the due-date is a secondary concern, then something else is considered more critical, and when this is the case I doubt whether what I know as CCPM is equipped to handle it. Still, could be that with some additional ideas the use of main body of CCPM is still useful, but we cannot know until the detailed analysis is done.
I think that the boundaries of any methodology are defined by the underlining assumptions. If you don’t accept mine, either show me missing assumptions or show which assumption is not required – meaning even when it is not valid the methodology can be used as is and achieve the value. I cannot deal with a broad statement “I don’t accept your basic assumptions as defining boundaries of CCPM.”
LikeLike
In new product development projects, it is common that getting the project content right (the product) matters more than when the project finishes. Or the budget. Or the resources. And a CC PM focused solely on logistics provides little advantage for such projects. So why not continue the growth of CC PM to include what those projects need?
LikeLike
Even on projects where the due-date is a secondary concern, time buffers and buffer management are still very useful for project tracking. And if we apply the concept of buffers and buffer management to what is the primary concern, such as customer value (for new product development projects), then aren’t we simply using the general case of CC PM? Why should CC PM be limited to those cases where project performance in the time domain is the top priority?
LikeLike
Eli –
Knotty problems indeed. Nowadays I think of CCPM more as a set of principles that cut across different methodologies; with various tools like critical chain scheduling or agile sprints that can be applied as appropriate. That is obviously a big shift from Eli G.’s original book and from mine. Given certain underlying assumptions, principles should be generally applicable if your goal is to maximize the throughput and predictability of your project organization. In my last couple of books, I’ve been moving in this direction.
For me, the primary use of the project buffer should be to protect us from ourselves. Traditional schedules have plenty of safety time; the problem is that we have a tendency to use it all up. By aggregating safety time and managing it, we make that less likely. Note that too little buffer, besides reducing predictability, makes the schedule less credible; and therefore makes it less likely that people will use it.
Dates create a kind of homeostasis. If we have enough safety, we relax; if we don’t have enough (but still view a date as possible), we work harder. Over-emphasis on due dates – even project due dates – tends to encourage safety time to be used.
For example, I have seen people use CCPM primarily to hit due dates. If one project seems to be on time, they focus on another; multitasking is at best minimized only for critical chain tasks. People expect buffers to be used up, and as a result they are. Increases in speed are minimal; although, if you can talk people into cutting task times and then believing the resulting schedules, you can get a one-time jump.
If you want to get ongoing improvements to both speed and predictability from CCPM, you also need significant changes to execution – relay race behaviors. This typically requires finding ways of focusing on priorities, de-emphasizing deadlines, and re-thinking how projects are started. See my Project Manifesto.
I reacted negatively to your post because of the implication – whether intended or not – that if all these basic assumptions aren’t present, one shouldn’t attempt CCPM. A few specifics to think about regarding your list:
1. We have a good enough idea how to perform the project from start to finish.
(A rolling-wave approach is often useful, in which schedule detail is added nearer to the time work will be done. That allows us to have a broad picture, without wasting time planning details that will change. )
2. Completing the project before or at the due-date is of utmost importance.
(For new product development, it’s normally much more important to get things done as quickly as possible, which means minimizing buffer consumption, especially for the most important products.)
3. Finishing on-time is nicely correlated to meeting the specifications and budget.
(If there is little correlation, AND scope and budget are very important, then there are tradeoffs that must be considered in the schedule; and potentially budget buffers as well. It doesn’t mean CCPM is invalid, but you may need more than basic scheduling.)
4. The control on the progress and its timing issues are at our hands.
(Very often there are outside vendors whose tasks are work is important to our completion timing. That might imply, for example, setting up contracts appropriately.)
5. We plan to work continuously on the critical chain. Without that the definition of the critical chain as what determines the duration of the project is meaningless.
(I wasn’t actually sure what this meant, as distinct from #4. When wouldn’t this be valid?)
I see two reasonable ways to go with your original idea. You can take a basic, well-defined tool (e.g. “CC scheduling, as defined in Rob’s 1998 book”) and create a list of basic assumptions that means, “if these items aren’t valid, this tool must be modified.” Or you can create a small set of basic principles, and discuss the basic assumptions behind those principles. But a methodology implies a specific set of principles and tools, which will be hard to nail down.
Rob
LikeLike
When Bill Dettmer and I realized that what we came with as an effective planning and execution methodology for Production deviates from DBR we decided to call it another name (Simplified-DBR). If people believe that using Agile methods is more effective than CCPM this is OK, but then they do not use CCPM. They might come with a way to combine CCPM with sprints, and then I do believe that calling it another name is appropriate.
I also think that making changes to an existing methodology should be widely shared AND DISCUSSED through the community. Public discussions through TOCICO or other platforms are truly required, especially after Goldratt death.
In my original post I said that when an assumption does not apply certain changes are required. I don’t know a-priori whether the changes are big or small.
I think that most of the proposed changes to CCPM do not invalidate the assumptions I have come with, but the challenge parts of the CCPM methodology for not being effective enough, especially not reducing enough the impact of Parkinson Law and Multi-tasking. These challenges do not expand the boundaries of CCPM, they challenge CCPM itself.
I see your response to each of the assumption and, to my mind, you only make it clear the assumptions are right in place, meaning when they are not valid a certain change is required.
Regarding assumption no. 5: take a production order. Due-date is important. However, there is no intention to produce it continuously. So, the whole concept of CC is useless. We should NOT use CCPM for Production!
I have another example. In the beginning of the VV there was a try to put the VV projects on CCPM. It did not work, because there is no need for CCPM to handle such a project. The point is that there are quite lot of time where nobody works on the VV project. Tasks that are intended to deliver 2-day education are put on the plan for 2-weeks duration. So, it is 10 working days for just 2-days. In such an environment – what is the benefit of using CCPM?
LikeLike
Eli –
I believe most divergences from CCPM (or other TOC disciplines) have come gradually, as people tried to apply it and discovered problems or better ways. At what point does it cease to become CCPM? Who knows? If the underlying tool is critical chain scheduling, re-branding is primarily a business decision.
I think it would be great to have discussions in the community about changes to the methodologies. It’s the norm with (for example) PMI. For TOC people try to do it. I’ve tried to do it myself. But I’ve seen two serious obstacles.
First, there is no practical definition of the boundaries of TOC – what’s TOC and what’s not. If you do something holistically while considering constraints, is it de facto part of TOC?
And second, I’ve seen no process for defining and revising a body of knowledge. There is a TOCICO dictionary; is that the entire body of knowledge? Is it the exams? Doubtful. I don’t have a great answer, because a BOK requires fundamental and hard choices: not just enumerating and defining terms, which people don’t necessarily agree on; but deciding to what extent we only talk about tools versus talking about how they’re implemented.
As a thought experiment, consider my talk on feeding buffers from 2½ years ago. I did plenty of thinking, testing, and asking of experts. I have encountered no objections with real substance. Practically speaking, the changes work well, and as far as I know are accepted by every practitioner who has tried them. To my mind, they represent a substantial improvement to traditional CC scheduling. How would I get such a change accepted by the TOC community? And realistically, how hard should I try?
About your assumptions, I completely agree: each of them points to areas having ramifications regarding how one implements CC. There are other assumptions I could list as well. Very rarely, in my experience, is your list entirely valid. So the bottom line, for me, is that one must analyze each case on its merits and determine how best, or whether, to implement CCPM.
Rob
LikeLike
Rob, TOCICO tried to come up with a process to assess new knowledge and include it in the BOK of TOC. For the time being the implementation of the idea is very slow. You touch here upon a critical issue for TOC to continue to exist.
I also agree that how to implement is an additional and important issue. Eventually we need tools for that as well. It cannot be too loose. However, we are not there yet. The TOC tools themselves are still far from being templates. Thus, I think it is important to define the boundaries of every tool to point to what it does not, at the moment, cover. And this is a different issue than discussing the effectiveness of the features within the tool itself.
LikeLike
Dear Bob,
I think re-branding is not only a business decision, it provides clarity. many of the changes proposed above in your discussion remains unknown to future users if they think CCPM is same as it is broadly known. For example, integration of other types of buffer is a major change to CCPM , if not introduced with a new name how do users and academics should know there is such a thing? and if no boundaries are defined any failed attempt can undermine the whole methodology.
LikeLike
Eli – I agree that the body of knowledge is a critical issue. I like defining the boundaries of applicability for tools, because at the very least that forces us to acknowledge (and potentially overcome) limitations. Before that comes defining the tools themselves, which gets back to the body of knowledge. The TOCICO dictionary is a useful starting point, and it probably fulfills one requirement: no one is fully satisfied. But much remains, including processes and boundaries for adding knowledge. The few times I’ve talked about BOK issues with TOCICO board members I didn’t hear much interest.
By the way, without getting into a discussion of strategy vs. tactics, I’d like to differentiate between a tool and a methodology, with methodology including tools, understanding, and processes to achieve overall objectives. I think tools would be realistic to include in a TOC BOK.
Maryam – You make a fair point. There is a moral component that should trump business decisions: calling something what it is not is dishonest. As far as what is “broadly known” for CCPM, that’s a tougher question. For example, our “standard” approach to CC scheduling, without feeding buffers, is not in conflict with the TOCICO dictionary. To what extent would it be considered “true” critical chain scheduling by an academic? I don’t know. We have certainly made a business decision not to re-brand it.
Rob
LikeLike
I fully agree with your core point, Eli, and believe that, notwithstanding the tricky issues associated with a BOK and ensuring a clear definition of CCPM and its boundaries, CCPM can serve as a strong foundation for something more holistic.
You cite the example of poor project selection, and I agree that this must be addressed for any project-centric organization to achieve a global optimum. In my 2015 book, I added a section on Project Selection and applied some “P-Q” logic there (for operational capacity), in addition to some capacity considerations driven by project execution (which must be informed by staggering), as well as considerations for when the operational constraint is the same resource as the project portfolio throughput constraint. In more recent blog posts, I have emphasized the importance of using ROI or “Goal Impact” as a more universal and holistic metric, under the logic that all projects are investments, and all investments must provide reasonable expectations for a risk-adjusted return. CCPM’s ability to help improve the reliable throughput of project completions will usually have a huge impact on ROI, but it doesn’t specifically target ROI maximization as its goal.
On the use of buffers, I presented at TOCICO 2015 on “Buffer Type Flexibility” for projects, arguing that project-level buffering against uncertainty can take the form of schedule, budget, or scope buffers (or a mix of the three), depending on specific project circumstances, customer desires, or where flexibility in the triple constraint may be most abundant–effectively, aligning buffer strategy in a way that maximizes ROI. As you state, CCPM assumes that this will be due-date performance (schedule), but this may not always be the case. (Agile projects default to scope buffers, which may not always be optimal either, of course!) What’s interesting to me is that CCPM’s project-level schedule buffer is a perfectly good “baseline” for any time-based buffer, and PMs typically have good intuition for thinking of budget and scope in tradeoffs of schedule, so all 3 project buffer types can take a time-based form and still be intuitive and simple, especially given that CCPM tools already show buffers as time-based.
Beyond project selection, there is another area that has great potential for maximizing the Goal Impact (ROI) of project portfolios–the possibility for engineering maximum ROI during execution, taking advantage of shifting circumstances on both the cost and value sides of the ROI equation, in both single projects and across the portfolio. One of the cool aspects of this is that a well-developed set of CCPM/CPM scheduling algorithms already carries most of the logic necessary to guide such decisions; along with sound project selection methods that are guided by ROI, we just need to graft a set of value-side factors to the already mature cost and scheduling logic. There are a couple of interesting books by Stephen Devaux on this, for those who may be curious (it was new to me until last year).
LikeLike
Eli, I understand where this is coming from. Trying to “fit” CCPM on any project just fails, especially as you mention on projects with a very high level of uncertainty like developing entirely new products, or providing service to clients that themselves don’t know what they want.
Ever since I first learned of CCPM, I always struggled with how it fits well with projects that are well defined – and how it probably works best with projects that are repetitive in nature, like building the same product over and over again, but CCPM protects against uncertainty during the project by utilizing buffers.
Regarding solving the wrong problem – after reading Bob & Bruce latest book “Focus & Leverage,” I now better understand that CCPM is a tool that should be used in some cases where it is needed. But in other cases, trying to use CCPM just because it exists can bring more harm than good. This is basic ToC really, “An hour saved at a non-bottleneck is a mirage”, a shorter project where projects are not the bottleneck is a waste of time. Just like in Lean going and removing waste all over the place and optimizing ALL the processes will have zero effect on the system as a whole. CCPM is a tool that should be used only if projects and scheduling are the bottlenecks, and they don’t necessarily have to be in every environment.
I am interested in learning what ToC can do in situations like finding a cure for cancer. There is a whole segment of the business that develops innovative products, or companies that rely on people experience to solve “any” problem while getting into uncharted waters on every project they do. There is a great competitive advantage in these kinds of projects, but I am not familiar with any ToC BoK that brings advantages to something that is not well known in advance. What are your thoughts on this?
LikeLike
Eli Goldratt told me once that he failed to find a way to ensure being able to evaporate a cloud. While he believed every conflict can be resolved, there is no guaranty we would resolve a specific conflict. It means the “inspiration” is still something we should look for, but we cannot make sure we’ll have it when we badly need it. I think there are ways to stir inspiration and make the probability higher and several of those ideas come outside of TOC current BOK.
Regarding the oft example of finding a cure for cancer. There is a missing step: understanding the core cause – what makes the body cells go astray. Without the full cause-and-effect we can only try and miss and look for possible signals, not knowing whether it leads to something substantial or not. Overall I believe that more synchronization between all experiments is the only way – until Science finds the full cause-and-effect and then it would be easier.
So, TOC does not currently offer much to come up with the inspirational idea.
Once we do have an idea, the six questions can be used to check it better and getting to know what else is required to make it work. Organizing all the tasks in a network has not invented by CCPM, and it can work only until the point where the new knowledge gained can be used to plan the next step. Whether you need time buffers for such a project is another matter. I still like to have a mechanism, like buffer management, helping me to assess where I’m at a certain point in time. But, I don’t need a time buffer to protect a due-date, which I don’t have.
The TOC BOK is far from being complete. Question for all of is: what do we do about it? Should each of us try to find the best solutions or should we unite to progress the knowledge?
LikeLike