In the Critical Chain as fad topic, Gordon Paisley wrote . . . 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 . . .
And Jack Dahlgren commented that he decided CC is a fad at least partly because of . . . 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 . . .
The good old "enterprise-wide" question . . . My opinion is that this probably deserves its own topic, so here goes . . .
As a Critical Chain practitioner who has been involved with a number of implementations -- on single projects, "enterprise-wide" situations, and in single projects in what should really be considered and managed as multi-project environments -- this question comes up all the time . . . and it should. The misinterpretation of it, however, drives me up the wall. Not only is it usually misinterpreted by people questioning the validity of the process, but also by some of my compatriots in the TOC world. Allow me to put my thinking on this topic into perspective.
When the Theory of Constraints (TOC) is applied to a system that needs to be managed, the first question that needs to be answered is "what is the system?" Projects exist is a variety of environments. For example: 1 - There is the "single project," which can be seen as a one time project that uses resources that are dedicated to it. In this case, the system is the project. 2 - There is the environment known as the "multiple single" organization, which involves a number of unrelated projects that use dedicated resources, or rely primarily on eternally acquired (contracted) resources. In this case, the individual projects can be seen as individual systems, or questions can/should be rasied about the validity and desirability of managing them separately, in which case, the organization becomes the system in question. 3 - There is the "multi-project" environment in which a variety of projects have value associated with their individual completion, but are related in terms of the fact that they share resources. Here, the system is the combination of the projects, their cumulative promises and the resources needed to accomplish them.
The application of TOC to single projects (or to individual projects in the "multiple single" or "multi" environments) is what we have come to call "Critical Chain Scheduling and Buffer Management." This is what you may have read about in Goldratt's book CRITICAL CHAIN, and is characterized by the Critical Chain (yes - it's simply a resource-constrained network of dependencies), the recognition of variation and uncertainty in the estimating process, and the system of Feeding and Project Buffers that are used to make rational promises and to track progress of the schedule. As important as these techniques are, they are merely techniques that 1) both require the support of AND allow the use of what we like to call "relay race" behaviors on the part of resources and 2) track the progress and health of the project without succumbing to the distortions and comprimises associated with milestone-based or task-due-date-based schedules. For more on the basics of the single-project solution, see my PM Network article, GETTING OUT FROM BETWEEN PARKINSON'S ROCK AND MURPHY'S HARD PLACE.
When resource contention across projects is a significant issue (as in a multi-project environment, or in a "multiple single" environment in which there is the sense that resources are being wasted or duplicated), the TOC application (usually known, not all-too creatively, as "Multi-Project Management") starts with Critical Chain Scheduling and Buffer Management for the individual projects, and then overlaid with a system of synchronization of projects so that the pressures to multi-task (and the resulting cross-project interference and inflation of project lead times) is minimized. In the Multi-Project Management approach, Buffer Management takes on the added role of providing guidance to resources and resource managers where the best use of their time is to support the larger goals of the organization. See PROGRAM MANAGEMENT - TURNING MANY PROJECTS INTO FEW PRIORITIES for more on the multi-project solution.
Critical Chain Scheduling and Buffer Management is suggested as a solution for speed AND reliability of promises for single or individual projects. It is based on subordinating the management of resources and tasks to the needs of the project. The expansion to Multi-Project Management is suggested if you want not only speed and reliability, but also enhanced throughput of an organization responsible for projects. It adds the subordination of the management of individual projects to the needs and goals of the larger organization.
So now I finally get to the question of the need to implement on the enterprise level . . .
The question comes down to "What's the system?" What do you want to manage or improve -- the delivery of a single project or a system/organization responsble for delivering projects?"
Critical Chain and Buffer Management can be applied to either a stand-alone project or to a single project in a multiple or multi-project environment and acheive results for that project. If that is good enough for what you want to do, either to simply work that single project or to test the concepts before rolling out to the rest of a portfolio, fine. As Jack mentioned, it's been done and it can work.
Many TOC consultants recognize that projects seldom live in a vacuum. Most projects are actually subsystems in a multi-project system, relying on shared resources. TOC tries to bring a systems thinking perspective to their engagements and TOC-savvy consultants like to try to assure that their clients get the biggest bang-for-the-buck of their efforts. Bringing one project in quickly and when promised is nice, but doesn't necessarily do much for the long-term success of an organization. Therefore, many TOC consultants like to strongly suggest that if one is living in a multi-project world, the multi-project solution should be applied. It's not that you MUST apply "critical chain" on an "enterprise level;" it's merely that to maximize real bottom line benefit in the shortest amount of time, the "enterprise-wide" multi-project solution is suggested as the shortest line between current performance and desired improved performance for the organization.
(Let me interject one additional comment regarding practicality here, as well. The one caveat I like to mention to clients who want to "pilot" CC on a single project in what is really a multi-project system, is that they may run into additional issues that need to be expected, considered, and addressed that is related to managing projects in two different ways. Let's say I'm a resource working on both a CC-managed project and a traditionally managed one, and I'm being torn between responding to the needs based on buffer consumption in one and a looming task due date in another. What do I do? If one project is being managed without task due dates and through buffer management, while all the other projects around it are being managed without buffers, there may be some additional steps and guidelines that need to be added to the implementation to minimize the confusion of two different management processes. These additional steps are not onerous or excessively difficult, but they do need to be recognized, put into place, and vigilantly maintained if the process is going to work effectively.)
Finally -- As in all management methodologies, there are practitioners who can be characterized as reformed, conservative, orthodox, and zealots. As in all things like this, often the zealots get the press and attention in saying what "should be done" while those of us reformed and conservative practitioners live with the realities of the politics and work with what "can be done." Sometimes a slower, individual project approach is a "good enough" approach for a particular circumstance.
. . .
. . . hmmmm . . .
. . .
Actually, come to think of it, when the "enterprise-wide" question really comes into play is when a multi-project implementation has resulted in a quantum-leap in project performance, what will the rest of the enterprise do with that new capability? If the organization's constraint was in its inability to quickly, reliably deliver projects, and that is no longer the case, to where else in the organization has the constraint moved.
But that's a whole 'nother topic.