Assumption-based Planning (ABP) is the standard work in how to reduce the effect of unintended consequences when planning. Although the technique has its roots in high-level strategic activities such as military planning, it is also directly applicable to systems development activities. There are also interesting links between the techniques in ABP and between scenario-based software development.
ABP is used best when a plan has already been constructed; the techniques are used to improve the robustness and adaptability of the plan by reducing the number of surprises that occur by decreasing the risks posed by assumptions made during the planning process.
Once a plan has been written, the ABP team identifies those assumptions made during the planning process that are those most likely to being overturned and derail the plan, to the detriment of the organisation concerned.
Dewar suggests the following ways of finding assumptions:
* using conventional brainstorming techniques;
* examining current corporate goals and values;
* investigating corporate traditions - "we've always done it this way"; and
* examining the actions in the plan and identifying those that do not have associated assumption: these so-called "orphan" actions are often based on undocumented assumptions.
The author also stresses that the more detailed an assumption is, the more useful it is in the ABP process. High-level assumptions such as "interest rates will remain below 5%" are more difficult to mitigate than the more detailed "as a result of low interest rates, consumers will continue to have disposable income that is higher than the historical average".
Once a list of assumptions has been obtained, the next step is to identify which of these are:
* load-bearing (ie those that if they fail, they will jeopardise the plan); and also
* vulnerable (ie those that are likely to fail within the lifetime of the plan).
Once a list of load-bearing, vulnerable assumptions has been documented, then each assumption is given a signpost - an event or measure that, when reached, indicates that the assumption has failed.
Dewar then identifies two types of actions that will help improve the original plan:
* shaping actions - put in place to shore up the assumptions identified; and
* hedging actions - put in place to mitigate against the assumption failing.
Hence, if the shaping actions failed to bolster the assumption sufficiently and the assumption fails, the hedging actions ensure that the plan has a greater chance of survival.
The author suggests that mitigating a plan by considering only "worst-case" assumptions likely to be very expensive to implement. In most cases, a cost-benefit analysis shows that some risk can be borne, traded for a reduced cost.
One of the most interesting things about this book is the link between ABP and other modern systems development practises and techniques. Much of what the author says can be applied to the planning and risk management techniques in project management frameworks such as PRINCE2.There are some subtle differences, though. It is worth noting that ABP "hedging actions" are not the same as PRINCE2 "contingency actions": hedging actions are taken before an assumption breaks; contingency actions are those that would be triggered after an assumption breaks.
Dewar states that the construction of scenarios as the main technique in developing hedging actions. He defines "scenario" as "internally consistent and challenging descriptions of possible futures". In ABP, scenarios are used to develop hedging actions by envisioning a future state and then to plot the path from the current state from the future state. Dewar states that they must be credible (ie believable) to the community for which ABP is targeted and have sufficient detail from which hedging actions can be generated.
This echoes the increasing popularity in scenario-based approaches to systems development - the most popular of which are Use Cases. In addition, scenarios can be used in other parts of the ABP process, most notably to identify signposts and to generate shaping actions.
He also notes other uses for ABP, namely that ABP can be used beneficially during the planning process to ensure that the initial plan is robust and once assumptions have been identified, they can be examined for entrepreneurial opportunities.
The author concludes by giving a list strengths and weaknesses of ABP along with review of similar planning techniques and an exhaustive bibliography. There are also some excellent tips on running facilitated workshops - useful for any planning session, not just ABP sessions.
This is a must-read book for all those who plan and manage large mission-critical projects, including systems development projects. It is also an interesting read for other systems-development practitioners, especially those who have an interest in scenario- or use-case-based requirements specification.
