Most software development teams keep track of risks and mitigations throughout their project lifecycle. I think we often stop there and don’t really think about what it would mean to deploy the mitigation.

It would be frustrating for a project risk to manifest itself, but the mitigation is impossible to do because it needed prior planning or approval.

For example, let’s say you have a project with two broad phases. (1) a planning/architecture phase that would be done by a very small team (2) a long, mechanical phase that requires little coordination and is very parallelizable. An example of this might be converting a large front-end from Angular to React.

There is a risk that you underestimated how long it would take. Possible mitigations are:

1. Add more engineers to the project (we are stipulating that that would help since coordination requirements are low).
2. De-prioritize any other work your engineers might be assigned.
3. Ask engineers to work longer hours and delay large blocks of time off.

These are if-then mitigations that you only do if a risk happens. If-then mitigations seem good, but the problem is that you are free to list them, and it seems that you have done something about the risk, but you really haven’t.

Let’s say we are in month 8 of 12 of the planned work, and you know you are going to slip to 16 months. If the work is important enough to care about that date and you want to deploy the mitigations, you must

• Get budget approval
• Find a source of engineers (contractors/internal)
• Onboard the engineers to the project
• Have management agree that other projects can be de-prioritized
• Be prepared for engineers to leave the company

If-then mitigations have their own risks that must also be mitigated. For example:

• Get budget pre-approval
• Keep track of other projects engineers are on and keep in constant communication with their stakeholders.
• Ask Engineers to plan for time off way in advance so that it can be accounted for in schedules.
• Create project onboarding documents and plans.
• Pre-identify engineers on other projects that would be moved to yours.
• Pre-negotiate with an outsourcing company, and possibly include them in the project at the beginning of the parallelizable phase.

The benefit of these mitigations is that they can be deployed immediately, and so whatever risk they have should manifest early, thus ending the cycle of Risk->Mitigation->Risk.

Rewrite of Mitigating the Mitigations based on Old, Flawed Work is the Jumping Off Point