This Focused Performance Weblog started life as a "business management blog" containing links and commentary related primarily to organizational effectiveness with a "Theory of Constraints" perspective, but is in the process of evolving towards primary content on interactive and mobile marketing. Think of it as about Focusing marketing messages for enhanced Performance. If you are on an archive page, current postings are found here.
Wednesday, June 18, 2003
Death March and Critical Chain -- Having read Edward Yourdon's online draft of the Critical Chain chapter of the next edition of his book, Death March, his opening paragraphs immediately grabbed me.
"An implicit premise of this book, at least for the last several chapters, is that a death-march project represents dysfunctional behavior on the part of the customer, end-user, stakeholders, or entire organization -- which the project manager has to cope with, survive, and hopefully overcome in a successful fashion. After all, what kind of rational, intelligent, ethical, fair-minded person would ask a project manager to accomplish something in half the amount of time that would normally be scheduled, or with half the budget or half the number of software engineers?
"But here's a radical thought: what if the "twice-as-fast" schedule actually represents normal behavior for an IT project, and it's been the dysfunctional behavior of the organization that prevented that kind of accelerated schedule from ever taking place? Instead of desperately looking for strategies to enable a project to take place twice as fast as "normal," what if we decided that our objective was to remove the dysfunctional obstacles that traditionally doomed our projects to take twice as long as they should have?"
In this introduction, Yourdon eloquently lays out the underlying basis of the origins of Critical Chain. It is related to the conflict/dilemma described here...
The assumption -- the "because" associated with the lower horizontal arrow -- that there's not enough safety in typical project plans to deal with project uncertainty, therefore resulting in pressure to extend schedule, cut scope, or overrun budgets, just might not be true. In many cases, as alluded to by Yourdon (and by Goldratt before him), the safety is there, but is too often wasted.
I got a kick out of another passage, as well.
"...the ideas have been so widely praised and endorsed, and have achieved such impressive results, that one wonders why they have not become the "mainstream" of project management. One plausible answer is that many organizations are dysfunctional, and it's very difficult to change deeply-entrenched dysfunctional behavior in the absence of a skilled "therapist," and in the absence of a crisis that threatens the organization's very survival."
I never thought of myself as a "therapist," but in some crazy situations I've been in, that job description might very well have fit.
Over all, this chapter is an excellent high level intro to the basics of Critical Chain for single projects, all the more impressive -- and important -- that it comes from someone both outside the TOC/CCPM community and with substantial project management credentials to boot. I've only got two quibbles worth mentioning. One is a technical confusion of a feeding buffer for a resource buffer in one of the graphic depictions of a Critical Chain schedule. The other is with his mention of software supporting CCPM.
"The actual planning and calculations behind such a scheduling activity can be formidable, and as one might expect, software packages are becoming available to carry out all of the "grunt-work" automatically; examples of such packages are ProChain (from ProChain Solutions Inc., www.prochain.com), and Resonance (from Thru-Put Technologies, www.thru-put.com)."
Whoops...Resonance is not a project management package -- it's a production management package which is now in the MAPICS family. That said, there are other software solutions for Critical Chain, including cc-Pulse (currently -- June, 2003 -- in beta), PS8, and Concerto.