Please login or join to subscribe to this thread
Having actually read Critical Chain, I am a believer. The reason I think it is genuinely different is that it takes human nature into account. Rahter than making just some theoretical model of the "way things SHOULD work" it shows an understanding of the human tendency to overestimate and then still start late (and finish late).
It also doesn't claim to be a silver bullet, which I inherently distrust. No one approach, tool, or philosophy will magically make projects on time and on budget. Critical chain does not pretend to reinvent project management technique, but rather augments them to help solve a common problem in projects.
I wouldn't necessarily say it will revolutionise projects for a couple of reasons. One, in order to be successful, it really needs to be implemented on a enterprise level, with everyone in the organization understanding how CC works. There also has to be buy-in from the team and a genuine guarantee that they will be able to make estimates and not be executed if they are wrong. Two, it doesn't remove risks, it only helps with one aspect of scheduling allowance for risk. Three, there are certainly a number of situations where CC principles can simply not be applied.
Certainly business (and especially business management) has more than its share of fads and management-theory-of-the-week. My approach to fads and theories is to realize that each probably has some worthwhile elements to implement in my particular situation. I then try to take the best parts and apply them to my workplace, rather than trying to do a complete implementation of the ideas I read in a book last weekend. Just one or two good ideas, implemnted well in a company can make a world of difference.
I have found the critical chain method very useful in the planning process, especially when dealing with the issues of multi tasking and shared resources. However, when I've tried to use in either construction or Aerospace where Earned Value is employed, I've hit a complete stop and resistance. Has anyone had any experience in trying to use buffer management in a earned value environment?
When I first heard about Critical Chain, I had my suspicions as well. Famous author, lots of books, all novels. Sure didn't sound like a good place to find a methodology for Project Management. Maybe an interesting read with some car chases or something.
However, I was pleasantly surprised. Goldratt's approach is not all that different from standard PM in many ways, but it addresses a lot of problems that have been part of the core PM methodology for the last forty years or so. When you stop and think about it, very few significant changes have been made to traditional project management techniques since the 1960's. Critical Chain is the first new approach to say, "Hey, maybe we can do this better." I think it'll be one of those things where people will be afraid of it at first, and suspicious, but eventually, it'll develop a larger and larger following.
I've been looking at TOC and Critical Chain methodology for nearly a year, and have decided that it is indeed a fad.
The first reason is the claim that it "needs to be implemented on a enterprise level" to be successful. I have heard this claim many times from different consultants. To me this is a key indicator that it is a fad. Especially since one organization that I have worked with has implemented it successfully on a single team disproving the argument.
Secondly, several of the concepts are rather old indeed. The "critical chain" is just the critical path through a resource-leveled CPM schedule. TOC's Buffers and commonly used concepts of contingency management are very similar.
So it is indeed a fad, but is that a bad thing? If you can use the fad momentum to bring a good project management technique to a team then it can be a very good thing. Certainly TOC is a fairly well thought out, easy to explain package of techniques based on solid common sense principles.
Nothing really new or revolutionary, but a palatable package to help the medicine go down.
Have enjoyed the dialogue on CC. I have a few observations to share. First, selling enterprise wide solutions rarely works. Second, the key to successful PM is to get your hands dirty and walk the site (so to speak). Too many PM's spend too much time tracking and not managing their projects. They are more historical reporters than they are forward looking strategists. Third, unless all resources are dedicated and under the control of one person (never happens), managing resource scarcity and windows of opportunity loom large as critical success factors. And finally, simple is always better - and face to face hands on management wins the day. We can all learn from those who are successful in the construction industry. Observing progress first hand always trumps stacks of reports and charts. Label your methods, debate the intellectual, but focus on fundementals.
I'm in the process of working on a number of responses to the recent postings on this thread. The first one follows here, but I've also moved it to it's own thread in Project Central. The questions raised in the postings above go to a number of topics, and some, like the CC/EV question probably deserv their own forum.
Martin Wartenberg asked . . .when I've tried to use [Critical Chain] in either construction or Aerospace where Earned Value is employed, I've hit a complete stop and resistance. Has anyone had any experience in trying to use buffer management in a earned value environment?
Around April of 2000, a team of government and government contractors (chaired by representatives from the Air Force and Boeing) convened on this very topic. The initial outcome or their review was that there is no real inherent conflict between CC and EV. Thier initial findings can be found at the Critical Chain Project Management & EVMS Working Group website. Other firms associated with the study included Raytheon, Northrupp-Grumman, Proxicom, and Lockheed-Martin. Not all of these may have actually implemented CC, but they are apparently intrigued.
Success in merging the two approaches has typically been accomplished by treating EV reporting as simply a necessary condition of the contract, and use the data gathering of EV to satisfy that need. However, operational decisions and assessments of the health of their projects - the actual management of the project - are driven by buffer management.
Some open-minded folks in the EV-centric community of government work initially recognized the possibilities of using buffer management to apply a rigor to one of the fuzzier parts of EV practice - the reliance on relatively subjective "thresholds" for indication of the need to take corrective action. But as time has gone on, the trend (where both have been assessed) seems to have been to replace EV's supposed predictive tools (and other traditional methods of tracking their projects) with buffer management. This is supported by situations where the two systems occasionally show conflicting indications regarding project health that usually proved out that reality was in far closer alignment with the buffer management indicator.
Another government contractor, BAE Systems, a maker of training simulators for aricraft and other military systems, has publicly talked about their success with Critical Chain-based multi-project management and other applications of TOC thinking. Part of their presentation at July's TOC World conference talked about reducing project carrying costs by $400,000, avoiding unecessary expenditures, and providing a new level of confidence in the ability th bring their projects in on or ahead of schedule.
They did not let EV requirements stop them from using CC to achieve these accomplishments.
If you plan to respond to this post, please do so on the Critical Chain and Earned Value topic at Project Central.
Gordon also wrote . . . "I wouldn't necessarily say it will revolutionise projects for a couple of reasons. it really needs . . . snip . . . everyone in the organization understanding how CC works."
I would think that a broad understanding of how that management is to be carried out is a pre-requisite. At least with Critical Chain and it's expanded Multi-Project application, the approach is not rocket science, without complex combinations of EV formulae or ratios or Monte Carlo simulations, and the basics can be sufficiently introduced to most players in less than a day, to management in a couple days, and to keepers of the process in a couple weeks, most of which is related to managing behaviors and not techniques. I don't see that as a real obstacle to "revolutionizing" projects, although I'm satsified with simply improving project performance. One of the other posters in this "fad" discussion attributed "common sense" to Critical Chain. That characteristic helps a great deal in achieving understanding.
"There also has to be buy-in from the team and a genuine guarantee that they will be able to make estimates and not be executed if they are wrong."
Yes, but a critical chain schedule also involves taking into account the team's assessment of what can go wrong, and including that in the project promise as well. Who cares whether individual estimates are met as long as the project is brought in on time without excessive midnight-oil burning or hoop-jumping? The beauty of explicitly solicited range estimates (longer, safe, commitment level estimates at one end, and aggressive, yet achieveable estimates at the other) used to develop buffered schedules is that the safety that people usually want in their estimates to protect their meaningless individual commitments is instead aggregated and concentrated where it can protect something meaningful -- the project promise and the critical tasks. Critical Chain can help to replace CYA behavior with true teamwork related to making the project successful.
"Two, it doesn't remove risks, it only helps with one aspect of scheduling allowance for risk."
I beg to differ. It does remove several sources of risk inherent to some aspects of "traditional" project management -- including the wasted safety associated with Parkinson's Law or with the response of cutting estimates arbitrarily to meet project demands as well as with the failure to consider the statistical nature and impact of multiple chains of tasks feeding into or integrating with subsequent tasks.
Another source of risk that is minimized is that when faced with deadlines, task due dates, or scheduled milestones, there is pressure to meet them. That pressure can result in shortcuts impacting quality of the handoffs, which then can grow into bigger issues downstream. Without task due dates, and with a well-established "relay race" workstyle, the tasks can simply take as long as they take to do right. The projects are then only subject to corrective action when buffer management identifies an accumulation of buffer consumption that threatens the project promise. One of the neat things about a highly visible buffer is that if consumption starts trending in the wrong direction, the team often goes into self-correcting mode before real trouble arrives. I've heard in one presentation by Lord Corporation that buffer management allows them to "panic early." (But I'm getting off the topic of risk into buffer management, which should be the topic of another thread, despite the interdependency of the pieces of the solution.)
While these risks are not necessarily individual project-related, they are associated with the traditional processes of managing projects. Change the process, and there is a chance of influencing these risks.
"Three, there are certainly a number of situations where CC principles can simply not be applied."
And they might be . . . ?
Wow, I had no idea I would be quoted so much. Perhaps I should ask for royalty payments so I can afford to buy a book and learn more about CC. :-)
With a single-thread message system like this, I find it helpful to use quotes from previous posts to keep my ramblings in some reasonable context.
I'd gladly share royalties with you on a percentage basis. What percent of what I get for my postings would you like?
Please login or join to reply