Don Sull's blog

Throughout history, leaders have relied on a linear process of predicting how events will unfold, planning a sequence of actions far into the future, and proceeding to systematically implement their plan. A diverse range of leaders–including central planners managing the Soviet economy; army generals who plotted attacks on World War I trenches to the last bullet; and programmers scheduling a detailed plan for a multi-year software development project–have followed this methodical approach. The linear process of predict, plan, and proceed instills a sense of control over an uncertain future. This sense of control is illusory, however, and this confidence misguided for two reasons.

• Premature lock in. A linear planning approach by necessity must exclude information that will only emerge in the future.  The implementation of a plan produces new information about the validity of the underlying assumptions, and the passage of time generates other data that bears on the initial plan. By locking into a plan at the onset of an initiative, leaders voluntarily exclude critical information that will emerge in the future. Software programming illustrates the disadvantages of following a linear plan into a turbulent future. Traditionally, large software development projects assessed users’ need, translated them into features, parceled features for coding, and assembled the code at the end. In 1995, the Department of Defense published a study (summarized here) reviewing software project costing the taxpayers’ over $35 billion, and found that only 2% of the code was used as written, with the rest requiring either significant revision or going unused. Software developed for the private sector did not do much better, with less than 5% of code used. The problem was not a failure to deliver the planned features. The same Defense Department study found that half of the software features met the requirements requested by users in the design stage. By the time programmers delivered the software, however, the customers wanted something different. Users changed their minds for many reasons: They struggled to articulate what they wanted until they could play with a prototype; software interacted with hardware in unexpected ways; the new software spawned new requirements; or competitors upped the ante. By freezing features too early, the linear approach prevented programmers from incorporating information that became available before they shipped the software.
• Escalating commitment to a failing course of action. The predict, plan, proceed approach often induces leaders to escalate commitment even as evidence mounts that their strategy was predicated on flawed assumptions. The US escalation in Viet Nam is the archetypal example. Leaders believe their initial plan is correct, commit to it publicly, and stake their credibility on the plan’s accuracy. When things go awry, they refuse to rethink their assumptions to avoid admitting that they were wrong in the first place. Instead they attribute failure to “unexpected setbacks,” another way of saying new information. Alternately they blame subordinates for inadequate execution, without stepping back to re-examine the initial plan. The costs of escalating commitment can be appalling. After two years of heavy losses in the First World War demonstrated the futility of frontal assaults on entrenched positions, the British Field Marshall Sir Douglas Hay sent over 100,000 soldiers to attack fortified German trenches in the Battle of the Somme. Hay ordered the action despite no evidence that circumstances favored an assault, and by the end of the day, 20,000 died and twice as many suffered injuries. This tragic persistence in the face of a flawed plan is not the exception, but the norm. The great military historian Sir Basil Henry Liddell Hart concluded his sweeping history of 2,500 years of warfare-from the rise of Athens to the fall of Hitler-by arguing that generals throughout history they have “chosen to batter their head against the nearest wall.”

Rather than follow a linear process of predict, plan, and proceed, leaders would do much better to bend the line into a loop that explicitly builds in a step to incorporate and act on new information. Colonel John Boyd‘s OODA loop is one example of an iterative approach that alternates between action and reflection. My next few posts will introduce severaliterative loops that help to guide action in uncertain contexts including scientific inquiry, new product development, and business.