Published in the Project Post-Gazette, Issue 2014-03
by Cheryl Wilson
The concept of Deliverables Centered Project Management (DCPM) is all about the project manager (PM) and the project team managing all components of the project towards the completion of fit-for-use (FFU) deliverables. If the PM or the project team does not know what the deliverables are, the project has little chance of success.
Understanding the importance of managing the risk program under this same concept, towards the completion of FFU deliverables, will in turn focus the management of the project’s risk potentials towards those events that could impede the completion of the project’s goal.
In order to fully understand how to manage risk within the DCPM framework, a clear understanding of the word ‘risk’ needs to occur. “Risk is an uncertain future event that if it were to occur, would have a negative impact on the production of a project’s ‘fit-for-use’ deliverables.” Let us break down this definition for more clarity. While I know this definition is contrary to some of the current project management bodies of knowledge, I have found while working in the industry for over 20 years, the risk definition under the DCPM framework is in alignment with successful projects more often than failed projects.
A good place to start is with the definition of “fit-for-use” deliverables. A project is a unique enterprise that has a beginning and an ending with the purpose of producing agreed upon deliverables. The deliverables are defined by the project sponsor and are deemed “fit-for-use” by the sponsor. The sponsor signs off on the deliverables only when are they deemed fit for immediate and valuable application to the business environment of the project sponsor’s operations. Deliverables that are ‘fit-for-use’ are in a condition to be of business value to the project sponsor at the moment of sign-off – not sometime in the future, or not in some other condition or level of quality.
Risk is a concept that has a potential negative impact to one or more of our FFU deliverables. In this context, risk can be synonymous with the word threat and has the probability of a loss. Although many current bodies of knowledge will talk about opportunity risks, from many years of working in the industry, I have found that when people talk about opportunities as “positive risk events” they are talking about an opportunity that is simply something good about our current or future situation and not positive risk potentials. We should closely watch out for potential positive future events as they could be events that cause scope creep and should be an event managed outside of the risk environment.
In managing risk in projects:
Risk is a future event.
There are popular bodies of knowledge that would disagree that risk is in the future; in fact removed the word “future” from its definition, but any risk that is NOT a future event is an event that must be responded to and is now an issue. ALL risk potentials are in the future and therefore should have mitigation plans in place to reduce or eliminate the potential negative impact.
Risk in an uncertain event.
The rest of this article will talk about risk as an uncertainty and the importance of measuring uncertainty by a set of probabilities or probability distributions. We will also talk about risk being an uncertainty but that not all uncertainty is a risk to your project.
Risk is currently defined and managed differently depending on the area of business: financial, project, portfolio, and organizational. But in all areas of business risk is defined as uncertainty. Uncertainty is the lack of complete knowledge about the future event which means
1) We do not know if it will happen and
2) There is more than one possibility in which the outcome can be realized.
If we were to talk about risk as a certainty, then we would be talking about an issue at this point or some known event. This is important to understand, because the only way to manage uncertainty is to put into place a mitigation plan to reduce the impact of the risk potential should it occur or reduce the risk potential altogether. Furthermore, the only way to measure uncertainty is by a set of probabilities assigned to the various outcomes.
An example of measuring an uncertainty would be that you calculated that there is a 75% chance it will snow tomorrow and therefore there is a 25% chance it will not snow since for a specific uncertainty with mutually exclusive outcomes all probabilities of occurrence have to sum to 100%.
Risk(s) are tied to your Project Deliverables.
In managing projects, risk is a state of uncertainty where there is possibility of a negative outcome (something bad could happen) to one or more of the project deliverables. The result could be a possibility of loss, injury or catastrophe or other undesirable outcome. When we talk about not all uncertainty is risk, we are talking about known problems that are common on projects, but the actual probabilities of the possible outcomes are not completely known. To help clarify this concept, let me give an example. All software projects have software requirements but statistics have indicated one of the top reasons project fail is because of unclear requirements. This is a known problem with software projects going into the start of the project. To list “unclear requirements” as a risk would actually be incorrect because we already know this problem exists – it is not entirely uncertain, but it is a future event. The PM should already be managing this problem with their project team as a part of being an experienced PM. Let me remind you of the famous saying: “if you do not know where you are going, any road will take you there.” Experienced PM know the road in front of them and know where they are going. Not all uncertainty is listed as a risk on their projects. This leads me to make the comment here, PM should not have other attitudes about risk other than that of being proactive! Risk attitudes belong at the portfolio level and not at the project level.
Although this article does not go into depth on measuring uncertainty, as a PM, we must measure project risk by a set of possibilities, each with quantified occurrence patterns and quantified cost impacts. While risk is uncertain, probabilities are of the risk potentials can be discovered. We are not managing our risks if we are not quantifying them. An example of a quantifiable statement for project risk is: there is a 60% chance we will not deliver the proposed software to the client on the date promised which will incur a loss of USD $ 20K due to the requirement of addition resources.
Uncertainty is not well understood by most and is often defined by most humans based by some personal bias. This inconsistency in human judgment needs to be removed as much as possible. There is no difference in managing risk on our projects. If risk is not defined by a set of probabilities this opens the door to subjective guesswork, personal bias judgment and a risk register with data that is skewed and flawed and eventually risks that are improperly scored. The purpose of a risk program is to provide the PM and the team with valuable information that can help the PM make informed decisions towards the goal of producing FFU deliverables. The PM needs to replace subjective guesswork with probabilistic models to help eliminate the human factor for more accurate risk management results.
One view that is popular in the risk community is the Bayesian view which Thomas Bayes, an English mathematician born in 1702, felt that: probabilities that represent our degree of certainty and uncertainty can be represented by probabilities and calculated.
DCPM is an important concept to understand as more and more projects today end in failure. Focusing all work of the project on the production of FFU deliverables will keep the PM and the team focused on the right work to be done and doing the work right. Understanding the definition of risk and how managing our project with deliverables as the center of our risk environment will also increase our project success rate.