Project

I've been a critical chain consultant in a very successful firm and have implemented successfully in soem pretty large companies. We did not agree with the "pilots don't work" notion, and in fact thought it necessary to pilot first. The lessons learned were very valuable to move forward with a larger-scale implementation.

Jack, one possibility is that TOC consultants do behave as you suggest -- that they routinely mislead their clients in an effort to secure larger contracts.

Another possibility is that there is more to Alan's recommendation than you understand.

Have you considered contacting Alan and giving him an opportunity to more fully explain the basis for his recommendation?

*****************
Note: The basis for his recommendation is pretty well spelled out in the podcast. I did not quote the whole thing, but if you are interested you can listen to it. I just reject some of the premises the argument is based on.

There are more than just the two possibilities you outline above - consultants are liars / I don't understand. One possibility is that I disagree with the assumptions the argument is based on (this is true...) Another is is that TOC consultants behave this way because that is the way that TOC consultants behave. Another is the possibility that it may be a learned behavior, knowledge passed unquestioned from one to the other. Perhaps you can think of some other possibilities.

Ultimately I can't claim to understand other peoples motivations, even if they explain them to me, but when the logic underlying the practices seems faulty, then I don't mind pointing it out. I'm just trying to evaporate a little bit of the cloud in my own way. I don't mean any disrespect to anyone, just trying to get a handle on things.

Thanks for your comment though. I would like to hear your experience in this regard if you don't mind sharing. Your "What Happens in Vegas" article seems to suggest that you believe that bad things in a small part of a company can ripple through the entire organization. Have you considered that good things in a small part of a company can ripple through the entire organization? If so, then why insist that TOC adoption is an all or nothing situation?

-Jack

Thanks for the clarification, Jack.

I don't see us as disagreeing on this issue. I also don't believe that there is a fundamental conflict with Allen's comments on the podcast, but I also have not verified this with Allen. I don't suggest that I speak for him.

I've tried to clarify this a bit with a brief article on my blog.

In closing, you've also mentioned some topics that I think are worthy of more discussion. As I can make the time, I'll be discussing them as well.

Jack, thank you for a valuable discussion.

John Sambrook

From my experience with pilots of CCPM, they certain DO work. The issue with piloting a new mechanism of running projects in an organization is around how do you isolate a group of people to do the pilot while the rest of the organization continues working in the old way. But it is not impossible.

*************
Good to hear your opinion here. Pilots are never simple, but I think that they can be extremely valuable. Certainly it would be risky to get married without the first date... (not that that doesn't happen in some cultures.) -Jack

I don't think TOC consultants have such an all or nothing approach to get a bigger contract. After all, they know that frightening a potential client away does not help them and they also know that a good pilot will get them more work.

It appears to be common knowledge (within TOC) that doing a pilot will not truly demonstrate the impact of Critical Chain. In doing the pilot (say with 3 projects) you either have to make sure the CC conditions actually apply to these 3 projects by somehow isolating them or they are negatively impacted by whatever is going on with the resources - multi-tasking in other projects ... So a pilot looks contrived since you isolate a few projects from the many rest, or you suffer the consequences of less performance than could be achieved. Either way, what will be the comments after your pilot?

These are obstacles to a valid pilot. A pilot can still be done but needs to be prepared so that the client knows what conditions for Critical Chain are not being met - and he allows for that.

A good project manager - with a good plan, good buffer management and active task management will be able to still show significant improvements - even if the rest of the organization is 'screwing things up' still. Just the reporting will show where trouble is coming from.

Consider also, can you implement Critical Chain across 50 projects all at once? Or should you start with the high priority ones first? So you have a 'pilot' be making sure projects are prioritized.

Rudi

I imagine a lot of the discussion could revolve around what the pilot is trying to accomplish to determine if Pilots "Work". I have just completed an 18 month program to pilot the use of CCPM in Nuclear Utility Engineering Modification and Design projects.

There are various ways to view the results.
1. 20 projects were completed using CCPM.
2. The average cycle time reduction was 36%
3. The corporations management decided not to implement CCPM throughout their engineering modification and design process.
4. There was a bottom line cost avoidance of 1.3 - 1.5 million dollars in engineering contract labor.

Result 1,2 and 4 could be considered successes if the goal was a proof of concept in a new industry. This is the first known use of CCPM in a Nuclear utility in the US that we are aware of. A company in europe started a pilot project at two plants in Spain 2 months before we did in the fall of 2006 so they are the first in the world we know of. They are doing almost exactly the same thing in the Modifications group, etc... Interestingly they have added a third plant this year and are achieving almost identical results in reducing cycle times as we have experienced.

Result Three could be considered unsuccessful if the goal was to attain acceptance and implemention throughout the organization.

In this organization as in others I found that a strong push by middle managers is not efficient or sufficient in getting a large organization run by committee's to integrate a new work process.

The CCPM implementation team viewed the pilot as successful in its originally defined scope and results. But when the pilot project was analyzed by a team sent from corporate they graded it using a large amount of scope creep. The result was a report to senior managers that detailed all the shortcomings of a pilot project without once discussing what the original project scope or project results were. As a result of the assessment further use of CCPM is not desired by this organization.

The irony of this outcome is that I will use the results of this pilot to entice competing firms to consider changing their work execution systems.

Hello!

I am reading this post many, many days after... But TOC is still around and some think that any resource-critical-path method that comes around is somehow tied to Goldratt or to his Theory of Constraints developed in the 80's.

Well, other things are around! And they are even older! They were simply kept away from us, in the whole Americas, because of COLD WAR! True, not kidding!

Have you heard of SDPM? Success Driven Project Management. It is based in principles of project management by resource-critical-path, not TOC. Such resource-critical-path development is from the 70's in the Old Soviet Union. Later, in the 90's it became a full Project Management Methodology with the addition of trends management and later success probability index trends. It first came out as a Critical Chain Method before the term Critical Chain was even thought of.

Some SDPM has in common to CCPM: It promotes schedules that are challenging to people and it keeps buffers for the project.

Some SDPM has improved: The buffer is virtual, not stuck to one critical path and then making it always critical, even when some scheduling optimization could be done. The buffer works for time and costs. The buffer is mathematically developed and controlled by an index of probability of success.

Imagine that your project is half done and has consumed half of the buffer. Is that good? It all depends where the most critical/risky/difficult activities are! If they are in the past, your buffer is great. If they are in the future, your buffer sucks.

SDPM keeps track not of the buffer itself, but the probability of achieving your goals with the remaining buffer. It has the ability to foresee the future by means of checking the risk scenarios built, so it "knows" if the remaining buffer will have to deal with harder or easier tasks to come!

You'll never see CCPM with the same eyes after you get to understand some of SDPM!

Regards,

Peter.