Many armies fail because they put all their emphasis into creating a plan that becomes useless ten minutes into the battle.

A similar problem occurs when planning a software development project.  A significant amount of planning can occur and then when the developers start writing code, the plan goes out the window.

So what is the solution?  The Heaths explain the answer to the traditional case: a concept called Commander’s Intent that was developed by the Army in the 1980s.  I had not heard of CI before reading their book, but came across it again today in James Surowiecki’s The Wisdom of Crowds.  For those not familar, here is the explanation from Made to Stick:

CI is a crisp, plain-talk statement that appears at the top of every order, specifying the plan’s goal, the desired end-state of an operation.

The CI never specifies so much detail that it risks being rendered obsolete by unpredictable events.  “You can lose the ability to execute the original plan, but you never lose the responsibility of executing the intent.”

Perhaps in the software development case the notion of CI manifests itself as a release theme or goal?  If this is true, it’s not clear to me how much value it actually provides because there are no details.

With the CI at the top of any order a soldier essentially knows the minimum amount of work that needs to be done.  With a CI in a software project plan it doesn’t seem to define the scope of the release well enough.  Or does it?