5.13 Plan B Triggers

< Day Day Up >

There must be a trigger, an event or circumstance, that everyone agrees causes Plan B to kick in. This is also known as the "go/no go" decision point. It can be as critical to Plan B as the actual planned actions. We exited the previous section with the phrase "long lead times." Suppose, as in the last strategy described in Exhibit 6 ("Alternates"), we need to consider engaging a different team, renting new space, or arranging for processing data a different way. These are practical and common alternate actions you find in Plan Bs. Invoking them probably adds expense, which you can thumbnail at a cost equal to the cost of the deliverable or condition being "replaced" before drilling down into the detail.

It takes time to get alternate floor space to address a data center or end-user facility issue, provision an alternate high bandwidth circuit into the site, or engage a service bureau. Lead times could be 3 months or more, particularly if the product, service, or resource is constrained, or contracts are required. That being the case, the worst thing about these types of "cures" is that once you think you may need to use one of them, you pretty much have to go ahead and implement them. This, in turn, could mean that you have to cough up hundreds of thousands of dollars months in advance of actually knowing whether you need to invoke that costly Plan B or not. If the lead time is that long, what choice do you have? Of course, that brings the budget back into play. If the financial hit is onerous enough, other harpoons may soon fill the air, but to avoid doing the right thing because you fear getting a bloody nose suggests that perhaps it is time for you to entertain a career change.

I previously alluded to the Plan B trigger as an event or condition that, once detected, "triggers" or kick starts a Plan B. This precipitating event depends, of course, on the project and the risk that your Plan B addresses. Nearly any such instance in the IT world can be tagged as "readiness," however, as in "If such and such is not complete by September 16, then we will invoke Plan B." Other instances may be cited as well. Testing may be a trigger if threshold levels are not met in terms of performance, throughput, error rate, and so on. Again, this will depend on the nature of your mission.

Suffice it to say that, similar to success metrics, Plan B triggers should be as clearly and finitely defined well in advance of the potential requirement to invoke them. There should always be a human fail-safe, of course, like that last finger on the ballistic missile launch button. In the absence of this precision, you will likely be faced with endless hand-wringing and debate down to the wire, particularly if the money has not yet been spent or weekend hours are at stake.

< Day Day Up >