77. Piling On

Stakeholders profess support for a project but then keep adding bloat until the project founders.

“Piling on” in American football is a penalty called when defensive players leap onto an already downed ballcarrier. The weight of massive linemen landing on the ballcarrier’s back is intended to send him a message, just in case he might ever again have the temerity to carry the ball into their territory. It is justly called a foul.

Piling on in project work usually takes the form of adding marginal features to a product whose cost/benefit ratio hangs in the balance. While seeming to be constructive, the covert goal of such behavior is to add dead weight. This is a variation on what author Peter Keen calls “counter-implementation.” In his classic paper,¹ Keen offers the intriguing observation that those who would defeat a new project have no need to take the risky step of actually coming out against it. Rather, they can give it the ultimate vote of confidence by suggesting a few dozen additions and improvements that will “help the project achieve its extraordinary promise.”

¹ Peter G.W. Keen, “Information Systems and Organizational Change,” Communications of the ACM, Vol. 24, No. 1 (January 1981), pp. 24–33.

Project teams that practice a lot of iteration are not immune to piling on, but they do have a natural and powerful defense against it: As they plan the sequence of iterations, they are obliged to assess features from the essential to the piled on and to allocate priorities accordingly. The early implementations have the essential features and the others are added to the tail end. When adding the next feature promises an incremental benefit that’s less than its incremental cost, the project may well be declared finished. Since all the meat has been delivered early, the impetus to keep the project going is negligible.

Counter-implementation in all of its forms (you really need to read Keen’s paper) is so common that if you don’t see it, you’re not looking hard enough.