Monday, 09 July 2018 09:50

Risk, Uncertainty and Continuous Planning

Written by

When a project kicks off it is like rolling the dice, you never really know how things will turn out until the end.

Experienced and rational project managers understand that risk management is an integral part of planning and that planning is a continuous process throughout and beyond project life into the operational process that the project sets in motion. These PMs consider uncertainty to be a certainty. They realize that everything is subject to change and that each change has ripple effects.

Project managers expect change in resource availability, requirements, organization structures, policies and procedures, and technology. They realize that the duration and outcome of testing cannot be predicted with certainty. It is testing, and it is done to find defects. How many defects there will be and how long it will take to fix them can be estimated but cannot be known until testing is complete.

Other stakeholders may not be as understanding about risk and uncertainty as PMs. Many are uncomfortable when they do not have a solid sense of what will happen. They want a guaranteed end date, deliverable, and cost.

The project manager is responsible for managing expectations using risk management, incremental and continuous planning and effective communication.

Case Study

Let's look at an example:

A complex organization decides to acquire a commercial off the shelf (COTS) software package as the vehicle for transforming its operation by automating key business functions, including tactical decision making. The decision to go the route of a COTS solution was in keeping with generally accepted best practices to avoid the costs and risks of unnecessarily developing custom software.

The risks of the COTS approach were considered. They included the realization that the organization would be reliant, to at least a degree, on the continued support of the vendor and constrained by the vendor's release cycle. There was a commitment to minimally customize the software to minimize cost and complexity, make needed changes to the existing business process and moderate the risk associated with significant changes to the product.

The project was planned and kicked-off. A qualified vendor was selected in a formal and well-regulated procurement process.

The vendor, assuming a large ongoing revenue stream from other services to be offered to the client, cut its price and in effect "bought" the contract. They took a risk (consciously or not). The expected revenue stream did not materialize.

The first phase of the project - the implementation of automation of point of sale operations at over 1200 locations went like clockwork. The organization's financial systems were easily fed the data from point of sale in an interface that required no customization of the package.

The second phase did not go as smoothly. It was discovered during detailed requirements analysis and design that the package would not fully satisfy the needs of the organization without significant customization. A choice had to be made - 1. customize the product, 2. build phase II software in-house or 3. create interfaces between the package and in-house business applications to create a hybrid system.

The hybrid approach was chosen based on the assessment of the cost and risk of the options and the desirability of avoiding unnecessary business process changes.

As the second phase of the project progressed some of the risks recognized early on began to appear as issues that required rethinking the plan forward. The vendor was losing key staff and was thinly resourced. In addition, the client perceived that the loss of expected revenue would affect vendor motivation. That made it even more necessary to ensure local autonomy for future enhancements.

The internal business organization also lost staff that had been dedicated to the project and was not able to provide requirements and sign-offs in a timely manner. The training department did not engage in the project planning until late in the project, resulting in last minute discovery of business process issues requiring business decisions and systems enhancements.

The internal application development group faced significant turnover and resource shortages coupled with more extensive programming requirements than originally expected.

Risk Management and Planning Process

A risk management process was put in place from the start of the project. Risks were identified, described, assigned an owner and scored based on assessments of probability of occurrence and impact. Monthly risk meetings were held at which existing risks were reviewed and reassessed and new risks identified. Risks that materialized were identified as issues and action taken to resolve them. The plan was modified accordingly. At times, because uncertainty was great, the plan did not commit the project to a fixed delivery date.


The planning took risk into account, though did not perform probabilistic planning. Probabilistic planning is planning that allows for multiple scenarios and a range of cost and time outcomes. PERT is a classic example. Each task is estimated using a weighted average of pessimistic, most likely and optimistic outcomes. Monte Carlo approach adds a statistical capability that runs a large number of possible outcomes to predict a statistically accurate range of outcomes and probabilities.

Deterministic planning is the alternative. Here, the tasks are estimated with a single point, and the project end date and costs are predicted based on the single scenario.

Many projects are planned with the deterministic approach. One reason for this is the extra effort and skill required for the probabilistic approach. Another is that in some organizations capital budgets may not be presented as a range and may not include a contingency fund.

This was the case in the example project. As a result, the planners presented a worst-case scenario based on pessimistic assumptions - the result of risk assessment. They faced a time box that limited funding and contracts to five years.

As incidents occurred risks became issues, and the plan was adjusted to keep it as a realistic picture of the predicted outcome. The base budget was used as a bench mark. Because it was based on pessimistic assumptions, the project remained on and under budget. Resource shortages made it necessary to under spend. The time line restriction led to a reduction in scope.

Because of the scope reduction, there was a need for subsequent projects to fully implement the overall program. Operational accommodations had to be made. The changes in the vendor relationship prompted an increased need for autonomy from the vendor regarding enhancements.

The good news was that stakeholders on all levels were prepared for uncertainty. They were kept abreast of risks, issues, and changes. Expectations were managed using risk management as a means for highlighting and working with uncertainty in a concrete and understandable way.

Read 3657 times

© 2019

macgregor logo white web