Containment Building

Problem: A project is failing and is too visible.

Context: A project is about to melt down. People are leaving or are severely disgruntled due to the continuous external pressure and visibility. Much criticism is directed at the project, its staff, and its leadership.

Forces: Solution: Add the failing project to another, larger project, changing its name, if required, and apparently altering its scope.

Resulting Context: This effectively contains the mess originating from the project, protected as it is inside the larger context. This move also appears as a reorganization, when in fact absolutely nothing but the org charts themselves have changed, just as in CargoCult. Sheltered from direct scrutiny and filtered through the layers of reporting that have been added and/or obfuscated, the still-intact team can find the breathing room it needs to rebuild morale, redirect, and recover. This pattern is frequently used in conjunction with others such as ScapeGoat.

Rationale: Sometimes, you just gotta be sneaky, I suppose. Actually, this is a strategy I've seen in actual use and indeed it has worked. At first the name ContainmentBuilding seems inaccurate; containment buildings are built around nuclear reactors to contain disasters like leaks and meltdowns, preventing radiation from altering the gene pool of the cows that graze and the people that picnic nearby. But given the infectious destruction to morale that can spread if not contained through bureaucratic or other means, perhaps it is, after all, appropriate. The idea, of course, is to have the containment building in place before the meltdown occurs. If no meltdown occurs, cool. If it does, then your other projects, and your career, won't suffer any unwelcome mutations.

Author: DonOlson 95/10/17 (revised 96/04/10)


EditText of this page (last edited February 9, 2006) or FindPage with title or text search