The first step to dealing with project risk is to list mitigations—the steps you will take to avoid or handle the risk. But, don’t stop at just listing them.

The very next step should be to think about whether those mitigations themselves have obstacles.

For example, let’s say you have a project with a large mechanical portion, which doesn’t require communication or coordination to implement. If this work can be done in parallel, then adding engineers mid-way (once the a core has been established) could speed up the project, but even at the start, you must

• Get budget approval
• Find a source of engineers (contractors/internal)
• Structure the work so that at some point it can be done without coordination and in parallel.

Projects like converting a lot of code from Objective-C to Swift or from an unsupported version of a framework to the current one work well for this. Projects that require a lot of cross-developer coordination are famously made later by adding engineers.

Depending on the stakes, it might be right to ask engineers to temporarily put in more hours, or to schedule time-off earlier in the project if possible. These things are easier to do if you talk about them earlier and gauge the impact.

A third option would be to clear off all other work so that everyone can concentrate on the high-priority work at hand. In that case, those projects have risks that need to be communicated to the project managers so that they can list and mitigate them.

It would be frustrating for a project risk to manifest itself, to have identified that early, and to have come up with an effective mitigation, which is not possible to do because it needed prior planning.