A contingency in project management is a reaction plan to an untoward event; in short, we plan ahead for the failure of a given task. In order for a trigger to “fire,” we must set a threshold value that activates the trigger; otherwise, the trigger should never fire.

Thresholds can be set based on financial, schedule, and quality anomalies. For example, if our project is running more than a pre-decided percent of the budget at a specific milestone, we would expect to trigger corrective action up to and including executive involvement in the project. Budgetary deviations are bad enough, but it not uncommon for projects to run into scheduling issues. We want the schedule triggers to fire as early as possible for the following reasons:

• Immediate corrective action
• Inform the customer, even if internal
• Bring in upper management to see if barriers need to be removed

Unfortunately, quality issues and their associated triggers are often unfired until late in the product development. Part of the explanation lies in the fact that we typically rely on testing to ascertain quality and we generally cannot test until we have at least a prototype version of the product.

It is insufficient to simply have a trigger when we pass a threshold—we should also plan for the reaction explicitly and in detail. Even better is to use failure mode and effects analysis (FMEA) to assess our tasking and see if we can anticipate the failure and remedy the issue, thereby preventing the failure from ever occurring.