Four of the common project management terms that seem to cause huge confusion with many project professionals are Assumptions, Constraints, Risks and Issues. The reason for the confusion may have its origins in the close relationship between these four terms. Another reason may be that as project managers we are sometimes tempted to employ C.Y.A strategies to protect ourselves.
Making invalid or sometimes ridiculous assumptions are one of our favourites in our C.Y.A strategy. For instance: “We assume that management supports our project.” How about asking them? And if we are worried that their support will not last the whole project then we should revisit our stakeholder management strategy to ensure their continuing support! A problem with assumptions in everyday life is that in order to continue with life we are forced to make them every day – without assuming that somebody will find this discussion interesting I may as well stop writing it. What we do not do in everyday life is to document our assumptions and for effective project management that is a big problem. So what is a valid assumption in project management? If we look at the standard definition of an assumption we find (a) it is something that cannot be proved to be true or false. That eliminates all the things we know already exist. If we are uncertain we can find out and it may or may not be a limitation (constraint) to the project. And (b) it is something that we need for planning purposes. That means that the assumption must in one way or another have an impact on our project planning.
A valid assumption may therefore be assuming that the exchange rate between the local currency and a foreign currency will stay within a certain range. We cannot prove it to be true or false at this stage and we need some conversion figure for project cost or income estimations. From this we can see the close relationship that assumptions have with risks. What if the exchange rate moves outside this assumed range?
This one should not be a problem. We either have enough time to do the project or we don’t. If we don’t have enough time, money, skills or whatever it is a constraint and we must find ways to complete the project successfully within the boundaries of these constraints – this we normally do by working smarter or getting the limitation relaxed.
A close relative to assumptions. Risks are, just like assumptions, also based on uncertain future events. The important aspects of risks are (a) uncertain future event and (b) impacts positively or negatively on one or more of the project’s objectives. Many risks can be uncovered by playing devil’s advocate with our assumptions. What if the assumption is not true? What is the probability of it (the risk) happening? What will be the impact on which of the project’s objectives if it happens? One of the typical risks on a project can be defined as: “Due to the complicated nature of the project, the key sub-component to be delivered by a vendor may be of unacceptable quality causing rework that will result in delays, cost overruns and / or stakeholder management problems.”
Issue / Problem / Benefit
An issue or problem is something that has already happened and requires our attention. As in the previous example, if the risk occurred namely that the sub-component delivered is of unacceptable quality, it is not a risk anymore. It is now a problem that needs to be dealt with. Issues are not always risks that have materialized. Issues can be anything that happened that is causing a problem or a benefit to the project. However, most of the times when we analyse the issue, we may find that it was a risk that we should have identified – but then again, we know hindsight is an exact science.
How do they impact each other?
Let’s look at a simple example of how these different aspects relate to one another.
Constraint: Lets imagine a project where we have identified a limitation that we do not have enough funds to finance the total project. One of our solutions to this problem may be that we plan to finance the latter part of the project by generating income from the sales of a scaled down version of the product while enhancing the product to meet all of the requirements.
Assumption: One of the critical assumptions we made in the above scenario is that we will be able to generate enough income to fund the latter part of the project. Asking the “what if” question can in turn help us to identify a risk.
Risk: From the analysis of above assumption we could have identified and defined the threat (negative risk) as: “As a result of a competitor releasing a similar product before us, the sales of the scaled down version of the product is slower than anticipated with the result that we cannot raise enough funds to complete the project.” We need to analyse the probability of occurrence and impact of this risk and, if required, define a plan of action on how to cope with this risk.
Issue / Problem: If this concern we have with a competitor beating us to the finish line occurs, we will be confronted with slow (or possibly no) sales and therefore not enough income to finance the latter part of the project. If we have identified this issue previously as a risk then we would hopefully already have a plan to address the problem.
How does this impact our project?
Murphy’s Law stating “There is never enough time to do it right the first time, but there is always enough time to do it over” comes to mind. Sometimes we are so busy fighting fires that we do not allow ourselves the time to do a proper job and not doing a proper job in the first place is the reason why we are fighting the fires!