The project managers in your organization should be tracking project risk on a regular basis. This allows them to log and respond to situations as they arise, to avoid issues before they happen. Preparing action plans that allow risks to be addressed, and then working through those plans is the core of project risk management.
But if that’s all happening at a project level, how do business leaders get an overall view of the risks across the whole project portfolio?
Risk reports are a way of communicating project and business risks to the people who need to know. Below, we explain four different types of risk reporting that enable teams to communicate risk to the right people at the right time.
1. Project Risk Reporting
Project risk reporting is at the lowest level in the project risk hierarchy. This is carried out by each project manager and the appropriate members of the project team.
Project-level reporting covers risks that are relevant to the scope of the project work, and external factors that may affect the project in some way. For example:
- The risk of price changes for key materials
- The risk of resources not being available to carry out work at the required time
- The risk of suppliers not being able to complete their contracted work.
Each project should have a risk log that documents the risks specifically related to the project. The risk log records the tasks that are being done to actively manage the risk and the owner – the person responsible for completing the action plan.
The project risk report is used by the project manager, and created with input from the project team members. All the risks will be in the risk log; only the top risks make it into the risk report as these are the ones that need management attention right now. While the risk log is likely to be in use weekly, if not more frequently, risk reporting is probably only done as part of a management reporting cycle, such as at the end of each month.
Read next: What to consider with risk reporting
2. Program Risk Reporting
When a project is part of a program, the program manager will also have a record of relevant program-level risks.
Program-level risks are those that relate to:
- A particular project within the program where the risk is significant enough to need to be escalated to the program manager
- Overlaps or dependencies between projects within the program
- The program overall, and do not naturally link back to a specific project.
“Significant” project risk is a determination that you can work out with the project and program managers, but would typically relate to things that had a high financial, operational or strategic implication.
The program risk report is used by the program manager and created by the program team. It is produced at a frequency determined by your program management framework, which could be monthly.
3. Portfolio Risk Reporting
Portfolio-level risk reporting is a way of showing the aggregated risk profile for all the projects and programs in the portfolio.
The major risks per program (or per project, for those projects that do not form part of a program) are drawn together and presented in a way that makes it easy to see an overall summary. The report should highlight areas where management teams need to be aware, for example, where risk action plans could take two or more routes. This draws attention to the decisions that need to be taken so that program and project teams can get on with executing the work.
The portfolio risk report is created by the PMO, with data drawn from program and project risk reports. Ideally, this should be pulled directly from an enterprise project management software tool to ensure it reflects the most up-to-date information.
This report is likely to be produced monthly.
4. Business Risk Reporting
Finally, there is business-level risk reporting. Some businesses include operational activity in the scope of the portfolio, so wouldn’t have a need for this level fo reporting. However, it’s common to see projects managed across the organization with a portfolio approach, and operational work falling outside that.
If this sounds like your company, a risk report that shows the aggregated risks across the portfolio isn’t the true risk profile for your business. Each business unit and function will have their own risks that relate to their operational activity. These risks can be significant.
Enterprise-wide risk reporting should focus on the most significant risks across the business. It can also include emerging risks, a competitor analysis, and current market outlook. Generally, the more that can be displayed visually, the better. Use heat maps, charts and graphs to display information, and make the most of the automated charts that are produced by enterprise project management software tools like Primavera P6.
This report can be produced by the PMO or a different team responsible for board-level consolidation and management information. It can be produced at a frequency required by the board, which could be quarterly. It’s likely to run to over 10 pages, so it helps to have an executive summary pointing out the key concerns.
Information flowing up and down the risk reporting hierarchy should be consistent and aligned. In other words, the significant risks flow up, and management actions are clear at all levels.
A risk management maturity assessment will help your teams work out where they are in the risk reporting stakes, and what actions should be taken to embed effective risk reporting across all project teams and beyond.