Glen Alleman over at Herding Cats has a great presentation up on the importance of risk handling by having a Plan B based on the Shackleton Expedition. This is an important point and one that goes against the oft-heard assertion, particularly in software development, that we are “exploring,” that our systems are evolutionary, that we are delivering value one increment at a time.
Murphy’s Law of combat operations states that “No OPLAN ever survives initial contact.” This experience is in line with Eisenhower’s comment that “When preparing for battle, I have always found that plans are useless but planning is indispensable.” What these observations mean is that we know that once tested by reality–the reality of combat in the case of the examples given–that almost nothing will go according to plan.
As part of operational planning, the staff identifies risks, alternatives, and contingencies. Everyone in the planning process is made familiar with these alternatives–Plan B, Plan C, etc. We may “think” that the plan we have chosen is the best one, based as it is on certain assumptions and the 80% solution. But when in the midst of an operation no one can anticipate everything. Knowing, however, that during the planning process that what one is seeing before them is very much in line with one of the alternative scenarios allows us to initiate the alternative plan. Rather than having to throw everything out, including the progress that has been made, or having to improvise from zero, we have a basis to make well-informed decisions based on the alternatives. To do otherwise is folly and may lead to defeat in the case of military operations. For more workaday situations, like project management, to do otherwise is folly and may lead to project failure.
This is why our community should be following the ACA roll-out, regardless of the surrounding politics, as I stated in a previous blog. The ACA program is a fascinating real-life and highly visible experiment in program and project management. Much of the publicity in the press focused on the federal government’s website roll-out. But that fails to distinguish two important concepts: that a program is not the same as a project, and that the website was not the entire project for the initial enrollment period for the ACA. It is, to quote Macbeth, “…a tale told by an idiot, full of sound and fury, signifying nothing.”
The reason for my unsympathetic assessment of the critics of the roll-out is because they are using the wrong measures of success, which was the number of people ultimately enrolled. (Now projected to be about 7.8 million for the website alone, and for between 14 to 20 million overall). There was a plan B and a plan C. The facilitators turned out to be very important in the early stages and represented an effective Plan B. Adjustments in the enrollment period also allowed for some flexibility, giving the digital systems time to recover, and provided a Plan C.
There will be more detailed postmortems as the players begin to publish once the dust has settled. Early controversy within the IT community has focused on whether the failure rested with Agile or Waterfall. I think this is a false debate since no software methodology can credibly claim to inherently handles risk or rises to the level of a project management method. I think the real issue of interest to IT professionals will focus on the areas of testing and recovery: the first because early reports were that testing was insufficient and the latter because the recovery was remarkably fast, which undermines the credibility of the critics of testing.
Life, Project Management, and Everything 