ContingencyUncertainty is an inevitable and integral part of even simplest of all projects. Let’s discuss about the Project Plan. A Project Plan is developed usually at the early stage of a project life cycle based on a number of facts and a set of relevant assumptions. Together these facts and assumptions model a future static landscape of the project. The plan thus developed remains valid as long as the landscape holds true. In reality, that is seldom the case – project landscape or environment is always dynamic. Some assumptions that are made during the planning phase may change over time, some may found to be erroneous, and some assumptions may not be even considered. All these and various tasks and project interdependencies result in uncertainties in project environment.

While speaking at a press conference on Feb 12, 2002, about the absence of evidence linking the Government of Iraq with the supply of Weapons of Mass Destruction to terrorist groups, Donald H. Rumsfeld, the 13th and 21st US Secretary of Defense, made the following comments:

“Reports that say that something hasn’t happened are always interesting to me, because as we know, there are known knowns; there are things we know we know. We also know there are known unknowns; that is to say we know there are some things we do not know. But there are also unknown unknowns – the ones we don’t know we don’t know. And if one looks throughout the history of our country and other free countries, it is the latter category that tends to be the difficult ones.”

Rumsfeld got it right – at least in the context of Projects. Project landscape/environment is based on following three elements:

  1. known knowns (facts),
  2. known unknowns (known = identified, unknowns = risks); these are the risks that are identified for the project, but the project team just does not know how much these will impact the project, if realized),and
  3. unknown unknowns (unknown = unidentified, unknowns = risks); the project team cannot identify these risks until they are realized.

Items 1 and 2 above are the two key ingredients in managing uncertainties or risks in project environment. There is always a cost (in terms of dollar and/or time) in managing project uncertainties. Now let’s see how PMBOK and PRINCE2 recommend addressing these uncertainties.

In order to address known uncertainties/risks, PMBOK recommends adding Contingency Reserves in terms of funding and/or time to project estimates. This is to accommodate all accepted and residual risks. Therefore, a contingency reserve should always be included in each project estimate and typically such reserve is determined at the outset of a project.

Cost Baseline = Nominal Cost Estimate + Contingency Reserve

To address unknown uncertainties/risks, PMBOK recommends adding Management Reserve. The management reserve should not be included in the cost baseline but it is a part of the overall project budget and funding requirements. Management Reserve is controlled by someone outside the project team, at the executive level.

Project Budget = Cost Baseline + Management reserve

So, how can we determine the magnitude of these reserves? There are several analytical methods and rules of thumb can be found in the Project Management literature to determine the magnitude of contingency reserves: they can be certain percentage of the estimated cost, a fixed number, or may be developed by using quantitative analysis (i.e., based on the sum of expected values of all risks). However, it is very difficult to give a guideline on the magnitude of management reserve. The magnitude should depend on the uncertainty of the project landscape, organization’s risk tolerance, and the Project Manager/Executive’s comfort level. My only suggestion is to allocate the management reserve at the portfolio level.

PRINCE2 approach to address uncertainties is very similar to that of the PMBOK. PRINCE2 recommends setting aside a risk budget. The risk budget should be set to cover both known risks (identified risks) and unknown risks (yet to be identified). If a risk budget is included, there may be a tendency to treat it as just another pot of money available for the project manager. This culture should be discouraged. The project risk management strategy should define how to control and access the risk budget.

In addition to the risk budget, PRINCE2 also recommends setting aside a change budget – the sum of the money that the client and the project team agree would be used to fund the cost of requests for change, including the analysis costs. According to PRINCE2, including a change budget provides a more realistic expectation of the overall costs/timeframe of the project. The change control process is defined such that it controls access to the change budget.

So as a Project Manager, Executive, Sponsor, or Key Stakeholders, how can we manage these uncertainties? In a nutshell, not going into details of the mechanics of it, in following two-steps:

  • Adding “buffers” (both financial and schedule) at the project level and also at the management level.
  • Having regular and short project review cycle for progress and change; also having flexible approach to revise the plan when the situation demands.