Recently we held Junior PM Challenge – a recruitment event for those, who want to become Project Managers. During the journey of the future PMs, one of the paths we went through was risks management.
Our event attendees enhanced their knowledge about its process: how to analyse, handle and monitor risks. Learned how to respond to the risk and identify one. Victory seemed inevitable, yet at the very end of the route, hiding quietly in the darkness of the last page were… assumptions. Not big enough to be seen by everyone, still having great power of sinking any project in the sea of uncertainty.
Risks versus Assumptions
As per PMI definition of risk, it is „an uncertain event or condition that, if it occurs, has a positive or negative impact on project objectives”.
While the risk management equips project manager in tools to help managing the unknowns, could we apply it to assumptions?
To answer this question, let’s look at below list of project assumptions from a real software project:
- The system will be developed using Azure Storage infrastructure and deployed on Azure environment.
- All users’ actions will be authenticated against Azure Active Directory.
- There is no dependency on data.
Following the definition, are we able to find an event or condition which must occur for each of the above assumptions so it could have an impact on the project? Apparently, it is not possible for the example, as assumptions are “factors that, for planning purposes, are considered to be true, real, or certain without proof or demonstration” (PMI, 2008, p 148).
Project in our example used Azure technology and infrastructure. Its’ specific implementation could not be applied in a straightforward way to any other cloud provider (e.g. AWS). This assumption is a priori input into the planning process, which could not proceed without it. If any of the assumptions are false, then the project goals, deliverables, budget, and schedule may need to be reassessed.
Don’t be misled by assumption, although it is not a risk, it can carry a one. In our example the following risk has been defined:
If one of the selected Azure services is updated, deprecated or replaced by new service we may end up in additional development effort (potential re-work), additional infrastructure costs and as the result change of the expected ROI.
While we recognize the relationship between risks and assumptions, the use case is different – the assumption is a driver for the planning process and a stated expectation.
Are all project assumptions known and confirmed?
Let’s consider Apollo program or Wright Flyer – did they know, at the time, humans can safely fly and put their footprint on the Moon? Not at all, the assumption was it was possible. What would happen if it turned out it wasn’t? These projects wouldn’t be delayed or more expensive. Their goals would be invalidated.
Assumptions don’t have to be confirmed or don’t need to have a proof, but they are to be absolute for the project.
Safe approach to assumptions
Depending on our project reality and common sense – assumption could be treated as some form of risk. Hence, we could attempt to use the same tools and techniques, formalize it and have a process of identifying and analysing. Assumptions are an integral part of our projects and shall not be omitted, forgotten or misplaced with risks. Don’t allow assumption to hide in the reports on project charters, make it visible!