Spending August sailing a small yacht from Southampton to Falmouth in Cornwall and back, along the south coast of England, is Chapman's idea of a summer holiday project. Bad weather is the central source of uncertainty. It can be designed out only by staying at home. Monitoring, keeping options open, and modifying objectives when appropriate, are the basic response strategies.
The trip each way is planned to take a week to ten days, with four or five stops on the way, sailing in daylight. The most desirable stops are anchorages in sheltered bays, which are usable only in certain wind conditions. A buoy in a quiet river is the next preference and a marina a poor third, unless water or fuel are required. Stopovers are for walks, pub meals, and visits to historic houses, gardens, and other places of interest. Staying in port is also a response to a poor weather forecast. Avoiding planning long passages without alternative ports if the weather is bad, or potentially bad, is an important variant of this response to the monitoring process. If the forecast is bad for a week, going anyway becomes almost inevitable as priorities change. Further responses once under way include shortening sail (reefing or, in extremes, changing to a storm jib and/or trisail), putting on lifelines, and securing the main hatch. The basic objective is enjoyment while on passage, but extensive delays can make getting there more of a priority, and the ultimate priority is the safety of the boat and crew. Sometimes carrying on to the planned destination has to be replaced by heading for the nearest port in a storm, and in extremes that option may have to be abandoned in favour of making sea room.
Many new strategic information system projects for competitive advantage share most of these characteristics, as do a wide range of other projects, even if having fun is not the basic intent and ending up dead in the water is not a potential outcome in a literal sense.
Most experienced sailors and most experienced managers in other contexts, where the basis of risk management is monitoring, keeping options open, and modifying objectives when appropriate, can recount tales of when it all went wrong, with disastrous or near-disastrous consequences. Yachting magazines carry regular features in this vein, which make educational as well as interesting reading. Corporate disaster stories also receive such attention (e.g., Lam, 1999). Common features are a series of largely unpredicted events whose significance was not recognized, coming together at a time when options were reduced for predictable reasons, and there was a failure to take radical action based on a change of objectives early enough.
In a risk management process centred around monitoring, keeping options open, and modifying objectives when appropriate, a further characteristic of actual or near disasters is a presumed set of primary responses that don't work. For example, on a sailing trip the radio needed for a Mayday may not work because the mast carrying the aerial has fallen down and the emergency aerial, perhaps tested when new, has been stored for many years in a way that has led to its failure.
In a first pass at least one response should be identified for each primary source, if only because the consequences of a source cannot be considered without some assumed response. This initial response may be simply 'accept the uncertainty', but such a response may not be feasible and a more active response may need to be identified. For example, in Example 7.6 there is a range of things that can be done, but just accepting the exposure to possible buckles is not one of them. On a first iteration, one response per issue may be enough, especially for those issues that are clearly unlikely to prove significant. Later iterations can add additional responses for issues of importance. Very important issues may warrant careful consideration of possible options under each type of response in Table 7.3.
Sometimes it is particularly important to stress, and extensively develop, the primary response part of the identify phase as early as possible in the very first pass. One reason is to address low project team morale. Looking for problems can be very depressing when a project that is your sole source of income is already looking decidedly risky. Encouraging the project team to look for responses to each problem before going on to the next can be a vital aspect of success.
Another reason to stress early primary response development arises where a project is based on a design that is so tentative that a major source is best dealt with by redesign.
A third reason arises where a project's objectives are receptive to the response: 'if at first it doesn't look like you will succeed, redefine success.' Software projects with a shopping list of deliverables ranging from 'must have' to 'nice to have' are obvious examples, but not so obvious possibilities may be worth consideration in these terms.
In general it is useful to see this early response development as part of the process of searching for risk efficiency that needs to go beyond simple threat management.
Whether or not early primary response development is stressed for the kinds of reasons just cited, it is very important to see responses in terms of all six Ws as part of a process concerned with maximizing flexibility and enabling appropriate monitoring.
Was this article helpful?