Recently one of the students taking my Better Project Status Reports course got in touch with some questions about risk and issue reporting. I thought it would be worth sharing my responses with everyone.
To give you some background, we were talking about a large project which would run over several years with 4 workstreams covering technical build, data migration, change management and testing. The student wanted some advice about how best to communicate risks and issues to senior management.
Here’s a summary of what we discussed.
Are there guidelines about what risk information should be reported to senior management?
No, not that I am aware of. The PMI Risk Practice Standard doesn’t include anything. The PMBOK® Guide talks about ‘Project Performance Reports’ but provides no detail as to what these should include. I think you’ll have to define the content of your reports yourself.
What should you include in a graphical risk management dashboard?
For a senior management report I would only report the open risks per project and/or open risks per category (scope, budget, schedule etc). This would let you see if there is one area like schedule that has a big risk impact on all projects.
I wouldn’t include:
- Total number of risks overall
- Closed risks
- Risks with an impact status of Low or Medium
This is because the senior management team can’t do much, if anything, with this information. The number of risks alone is pretty meaningless. Some may be very small, some projects may only have a few but they could be significant. A better way would be to report risk impact – what is the cost of all the risks if they happened?
The best approach would be to ask the key stakeholders what they are interested in seeing. I don’t think closed risks or number of risks is of any use as it doesn’t give them information they need to make decisions about the project. Risks by category, or risks with an impact rating of ‘High’ is more meaningful.
Should I show risk trends over the months?
No. What would the senior management team do with this information? At the beginning of the project you’ll identify lots of risks and then close some and open new ones. If you have a risk review meeting one month and identify another 50 risks this will skew the trend data. I would advise only showing a snapshot in time. You could use an arrow to indicate whether the overall risk profile of this project is going up or down, using a metric like whether there are more or less High risks or whether the cost implications for risk mitigation are going up or down.
What about reporting on issues?
For senior management, only show the high priority open ones. Typically I report also on ‘high priority closed this month’, then those issues drop off the report for the next month. This shows that you are making progress in resolving issues, even if new ones come along. If you don’t do this, your report could show that there are 20 open issues with a status of High Priority this month, and 20 next month. However, they could be 20 completely different issues! Without more detail, like issue names and descriptions (which, frankly, your sponsor is not going to want to wade through), your stakeholders will not know that you are dealing with issues and may assume that you are not tackling problems on the project.
As well as a graphical representation in a pie chart or dashboard, I would also include the top 10 issues in more detail – descriptions and action plans. If you need senior management input to resolve any issues make sure that these are included in the report and that you highlight where they need to make decisions.
Again, the best approach would be to ask your senior management team what they want to see. If they don’t know, present them with your graphs and report for a few months and then ask for feedback about what they think and what else they need to know in order to carry out their roles on the project i.e. decision making, governance and oversight.
Want more guidance on project reports? Get my Better Project Status Reports course here.