We make hundreds of assumptions and take small risks daily. Without them, we would spend innumerable hours worrying about everything. We assume our car will start. Our air conditioner will work. The weather forecast is accurate. These daily assumptions are banal. Recovering from these risks may be inconvenient but not horribly impactful.
Project assumptions and risks are not as casual. Thoughtlessly making assumptions or ignoring risks can lead to critical problems. Sound practices can help us avoid or be prepared for these undesirable outcomes.
I have seen many projects derailed because assumptions were never documented or validated. Or risks were identified, but a response strategy was never created. In nearly all cases, “an ounce of prevention would have been worth a pound of cure.”
The project management plan is created at the beginning of the project and describes how the project will be executed. The plan should describe the process for managing assumptions, constraints, and risks, including:
Context and environmental factors should govern process requirements, specificity, and formality. Large, complex projects will require more highly structured processes than smaller ones. Enterprise frameworks or standards may also inform the practices.
Assumptions are things we know we do not know. Until we validate them, they are risks. So, we want to document them in an assumptions log and proactively review and address them.
Constraints are things that limit our projects. Budgets, timelines, and agreements are familiar sources. Constraints may also be assumptions that need to be validated. For example, the projects must be delivered by X date. Constraints also create risks. For example, IF the project costs more than planned, THEN there are multiple potential impacts.
Risks are future events with a likelihood of occurrence and potential impact. They can be opportunities (good) or threats (harmful). We tend to focus on the negative, which creates a blind spot to potential benefits. Risks may be described qualitatively or quantitatively.
The assumptions and risk logs are primary tools for managing these processes. Spreadsheets are often used as simple lists. More sophisticated tools are integrated databases such as Smartsheet, SharePoint, or purpose-built tools.
The logs are working artifacts for the project team. Team members should be able to easily access the logs, add items, and make updates. Reducing “friction” increases the likelihood the tools will be used.
Elements in the risk log can include:
The following fields should be common to both lists:
The risk exposure score is used to qualitatively describe the risk based on its likelihood and potential impact. A relative sizing scale of high, medium, and low, or a 1-5 scale can be used. The risk management plan should include a rubric for assessing risks.
I prefer using a high, medium, and low scale and then assigning numeric values of high=6, medium=3, and low=1. In my experience, it is easy to sort risks into three categories. Using the non-linear scale accentuates items requiring greater attention.
Multiplying the likelihood and impact of the risks yields the risk exposure score. The exposure score is used to establish guidelines for the risk response plan, frequency of risk review, and management visibility. A low/low risk may be accepted, whereas a high/high risk may require more than one response strategy and be reviewed frequently.
Risks and assumptions should be actively managed throughout the project. Identifying and addressing them starts with the business case and charter and continues until implementation. A common and costly mistake is losing focus as the project progresses.
The project manager is responsible for facilitating and managing the process. However, the project team and stakeholders are active participants. Use the team charter to set the expectation that everyone is involved.
The assumptions, constraints, and risk logs should be reviewed at least weekly. There will be many items, so focus on assessing:
The project management plan should describe the process for communication and reporting issues and risks. The frequency, method, and level of detail will depend on the stakeholder group.
There may be hundreds of items in the detailed logs. Management reporting should be limited to a dozen or so items. Clear summaries of the items, their potential impact, and resolution or response strategy should be communicated.
© 2023, Alan Zucker; Project Management Essentials, LLC
See related articles:
Image courtesy of: https://www.memproperty.com