The reason you care about the transition is that when the indicator fires, you intend to take some action. Before the transition, it’s too early to take the action—it may be expensive and time-consuming—so you are justified in hoping that it won’t be necessary. However, while you may be able to defer some of the corrective action, other parts may not be deferrable. There may be some steps you have to take before the transition, in order to keep your options open and to make correction possible afterward. That work is called mitigation.
Consider an example of mitigation from a domain outside our own: the U.S. court system. Realizing that a juror might become sick, drop out, die, or become otherwise unfit to continue, the courts appoint a number of alternate jurors to each jury case. If the original slate is able to finish, the alternates have no role; if a spare juror is required, however, an alternate—fully versed in the proceeding by virtue of having been present throughout—steps in and completes the requirement for a full jury. The risk here is the loss of a juror, leading to an aborted case, a retrial, and all the attendant expense and delay. The mitigating action is to carry one or more alternate jurors from day one. If and when the risk materializes, it can be contained at minimal cost.
The IT project analog to loss of a juror is personnel turnover, one of the core risks on all software projects. And the counterpart to appointment of alternate jurors would be to overstaff slightly from the beginning, with the fully qualified extra hands temporarily filling apprentice and support roles. When turnover occurs, the manager doesn’t have to hire new staff. One of the extras can move up from the apprentice role to assume the duties of the person departing, with minimal time lost to ramp-up.
Mitigation costs both time and money. Yet in the rosiest of rosy scenarios, that expenditure of time and money turns out to have been unnecessary. We’ll come back to this point, because it leads to a kind of pathology that can make risk management virtually impossible.