Real Work, Necessary Friction, Optional Chaos

Philip Armour in The business of software rejects the notion of estimting software by effort and advocates looking at the social component instead. WHat he has to say has implications way beyond the software industry though. He makes a good case for why putting pressure on teams can exponentially increase the cost fo the final deliverable.

Traditional estimating tools aren't effective, he argues. Lines of Code, for example, is inaccurate because in reality it's non-linear (1000 people can't do 1 line each). Indeed adding people can just create further delay (as set out in the classic "The Mythical Man-Month"). Armour attributes total project time to:
1) "the time it takes to factor our knowledge into an executable product" - this is what things like 'lines of code' measure.
2) Know-we-don't-Know situatuations where exploration required. Spiral (iterative) methodologies acknowledge that not everything we do goes into the end product, but instead goes into creating knowledge to make the product. i.e. fillling the knowledge gaps to the point where you've learned how to make it. Armour calls this "necessary friction".
3) "Optional Chaos" is co-ordination overhead, bickering and stress-induced chaos. Anything that does NOT disclose knowledge.

1) is a function on Know-We-Know and Know-we-Don't-Know factors
2) is a function of don't-know-what-we-don't-know, team capability and experience, team size and 'pressure', but the variability in the impact of this low.
3) is a function of team size and 'pressure' and highly variable in impact.
"When we attempt to accelerate projects, we introduce a high lelvel of [optional chaos]. High-stress projects put pressure on people to make quick, sometimes unvalidated decisions" [whose impact can then be catastophic].

Adding more people: "large numbers of people...increases the levels of both communication and mis-communication." More people means less equally distributed knowledge, so more chance for mis-understanding, and more time spent sharing knowledge that already 'known' rather than tackling learning gaps.

Outside of software, the implications are very similar: if you want a deliverable quickly, be aware that doublign the team size is unlikely to reduce the time to delivery that much, and in fact may make the deliverable cost far more than double. As a project manager, Armour offers a useful set of questions about how your team is spending its time. I particularly like that it clearly sets out that "knowledge work" is both 1 & 2, and that pressure just amplifies what takes most of the fun out of being a knowledge worker. Not the pressure per-se, but the side-effects it creates.