Managing Project Assumptions & Risks

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.”

Management Plans

The project management plan [1] 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:

The templates, tools, and systems for tracking these items;
The processes and cadence for identifying, documenting, reviewing, and reporting items;
A prioritization framework that balances rigor with ease of use; and
Decision-making, escalation, and resolution procedures that ensure timely resolution.

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.

Definitions

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.

Risk and Assumptions Logs

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 assumptions log can include:

Description. Describe the assumption using the most specific and definable information available. For example, “assume that X event must be completed by Y date” instead of “X needs to be completed timely.”
Status. Open or Closed are the most common. Deferred can be used for future items.
Dates. Date opened and closed are always used. A target resolution date may be helpful.
Priority. Priority can be used to denote urgency or criticality. High, Medium, and Low are generally sufficient categorizations.
Owner. The person responsible for resolving or validating the assumption.
Category. See common elements below.
Notes. See below.
Cross-reference. See below.

Elements in the risk log can include:

Description. Use IF/THEN statements to describe the risk. IF this event occurs, THEN this is the impact. Creating unique items for each impact ensures we develop suitable response strategies.
Type: Opportunity vs. Threat
Owners. Multiple owners may be used, the person who:
identified the risk,
monitors the risk event,
creates the response plan,
implements the response plan, and
decides if the response should be executed.
Dates: Multiple dates may be documented in the log: Opened, Closed, Next Review.
Likelihood, Impact, and Exposure Score. The exposure score is often a numeric score based on the likelihood and impact of the risk. The exposure score can be used to prioritize the risk.
Response Plan. A response strategy or strategies should be documented for each risk. The plan should provide well-defined steps to respond to the risk should it occur.
Response Trigger. Criteria for implementing the response strategy. The trigger may be either event- or date-driven.
Category. See common elements below.
Notes. See below.
Cross-reference. See below.

The following fields should be common to both lists:

Category. Large projects or programs can use categories to organize items by area.
Notes. A free-form text field will be invaluable for capturing status updates, next steps, and resolution items.
Cross-reference. Commonly used to cross-reference assumptions and risks. It can also be used to track these items in other project documents.

Risk Exposure Score

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.

Identifying and Managing

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:

Has the item been resolved?
Have events impacted the current prioritization, assessment, or planned response?
Is this item becoming critical to the project’s success?
Does the item need to be escalated to leadership or other parts of the organization?
Are there new items?

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.

Project Team. The project team should review the detailed issues and risk logs at least weekly. The logs should be detailed, and items should be clearly articulated.
Management Reporting. The project manager should communicate summaries of the most critical project assumptions and risks no less than monthly.

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.

See related articles:

To learn more about our training and consulting services or subscribe to our newsletter, visit our website: http://www.pmessentials.us/ [6].

Image courtesy of: https://www.memproperty.com