Every Word Is Like An Unnecessary Stain On Silence And Nothingness – Eugenio Ampudia

The majority of people don’t want to plan. They want to be free of the responsibility of planning.

B. F. Skinner (Walden Two)

I once heard a senior manager declare that they didn’t consider disaster planning useful as their staff did their best work under pressure…

So, why should we plan?  I think we may all accept the need for detailed project planning to ensure a project’s success.  Or careful, holistic planning of a release, with due regard to the four dimensions (Organization & People, Information & Technology, Partners & Suppliers, Value Streams & Processes) – although you may have used “People, Process, Partners and Products” as a mnemonic.

If goal directed planning perhaps doesn’t need defending, what about other sorts of planning?  For example, as we’ve got a Major Incident Process, do we need a rollback plan for a specific release?

It does not do to leave a live dragon out of your calculations, if you live near him.

J.R.R. Tolkien (The Hobbit or There and Back Again)

The goal directed plan will attempt to minimise any uncertainty in achieving that goal, but since we know what we’re planning on doing, we can imagine what might go wrong and plan a response to this specifically.  What might go wrong might be risking our success, or there might be a side-effect; immaterial to our direct goals, but undesirable from an organisational perspective.

We can have contingency plans to act if the risk is realised.  As noted before, we can attempt to minimise the scale of the issue (i.e. mitigation) or reduce the duration of it (e.g. rollback), however these are not mutually exclusive.  The mitigation plan could be used either in parallel with the rollback plan, minimising the scale and the duration of the undesired consequences.  Or the mitigation plan could be used first, to see if the impact is reduced sufficient to avoid the need to rollback.  We might even have an alternative “fix-forward” plan which preserves the benefits of the release, should the issue not merit rolling back.

So now we have various interlocking plans (without any claim to exhaustiveness!):

• a release plan designed to maximise success, minimise uncertainty and minimise undesirable impacts.  This may even include proactive mitigation, e.g. a phased release with a smaller group of early adopter, or a “safer” design.
• a contingent mitigation plan, should certain uncertainties come to pass, to minimise their impact after they’ve occurred.
• a contingent rollback plan, should we need to back out the release.
• a contingent fix-forward plan, should the undesirable impact not merit abandoning the release altogether.

These can all be geared to the specifics of the release, considered and discussed in advance, documented and tested before they are needed.  Triggers, roles and responsibilities, work instructions can all be ready and waiting, should something untoward (but not unexpected!) happen.

Such contingency plans make for calm, considered and effective responses tailored to the individual circumstances.

We mustn’t panic! We mustn’t panic!

Bunty

What then do we gain from Major Incident or Continuity planning?  Contingency planning as above, is driven by our actions –  so specific plans are made around those actions.  But not all our incidents or continuity events arise in this way, so we need planning for the unexpected or unanticipated.

Before eyebrows are raised too much – these plans are necessarily much more generic than the specific plans above, yet without them we have to respond in the heat of the moment without the benefit of considered forethought.  We can imagine typical trigger points, roles, responsibilities, communications plans, etc that will be predictably useful and plan for these.

Clearly these will be much less effective than the specific plans we might otherwise have developed, but they are better than nothing and help fill in the gaps between what we can foresee and what we haven’t.

There is a middle ground – we can imagine a scenario (a major incident, or a continuity event) and step through our generic plans against this.  We might do this as a paper exercise or as a simulation, with everyone playing their role as for real.  The generic plans can then be refined and enhanced based on such simulated experience, just as with actual experience.

We can go further and have scenario based plans which supplement our generic plan for particular eventualities – perhaps the ones considered most likely or most damaging.  Most recently the University planned for a continuity event in the form of staff and students being unable to use buses to travel to the University.  This was triggered by notice of a bus strike; action which was unexpected in the long run, but could be planned in advance even though short notice.

In preparing for battle I have always found that plans are useless, but planning is indispensable.

Dwight D. Eisenhower

These libraries of plans may not actually fit the situation that arises (the bus strike was called off), but can either be reused later, or can provide documented and tested elements that can be used reliably and effectively as part of the response to a different event.  For example, a plan for safely evacuating a building can be used for a fire but can also be used for any event which structurally compromises the building and risks staff safety.

In the unfortunate situation that a Major Incident (or even a Continuity Event – eek!) has been caused by a release, then the contingency plans will help in a similar fashion – however these are unlikely to have anticipated the scale of the impact created!

I’m now off to re-watch the planning masterclass that is Chicken Run.

Plans within plans within plans – what’s the point? / ITIL Tattle by blogadmin is licensed under a Creative Commons Attribution CC BY 3.0