Book review: "Assumption-based Planning" by James A. Dewar

Introduction

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.

Principles

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”;
Examining the actions in the plan and identifying those that do not have associated assumptions – 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”.

Assumption-based planning overview

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 gives many examples, two of the most interesting are Royal Dutch Shell and post-war American foreign policy.

Royal Dutch Shell identified that the strategic plan’s assumption that oil prices would remain persistently high throughout the 90s was a vulnerable, load-bearing assumption; ie that a fall in oil price would put the company at risk. It put in place several hedging actions:

the creation and marketing of a premium petrol, which would command a premium price however low the oil price fell;
not over-investing in new oil-fields;
the creation of an oil-futures trading system to take advantage of the anticipated increase in oil-price volitility that a price-fall would bring.

When the oil price did fall, Royal Dutch Shell fared better than its rivals by having put these hedging actions in place.

After the Second World War, American strategists identified that the hedging action of containing the Soviet Union would be increase the likelihood of its collapse. Hence, this became a major facet of America and its allies’ foreign policy; four decades later, the use of this hedging action as part of a wider geo-political plan paid off.

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.

Links with Systems Development Techniques

One of the most interesting things about this book is the link between ABP and other modern systems development practises and techniques such as PRINCE2 and scenario-based development.

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;
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.

The author concludes by giving a list strengths and weaknesses of ABP along with review of similar planning techniques and an exhaustive bibliography.

He also notes other uses for ABP, namely:

ABP can be used beneficially during the planning process to ensure that the initial plan is robust;
once assumptions have been identified, they can be examined for entrepreneurial opportunities.

There are also some excellent tips on running facilitated workshops for ABP – useful for any planning session, not just ABP sessions.

Summary

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.

Additional Thoughts