.png)
So what? Now what? How to talk about project problems
Risks and issues are some of the key health indicators Project Managers need to report on. They can be quite challenging to communicate on, particularly on IT projects where technical problems are often difficult to understand for non-specialised audiences. Poor communications about issues or risks can lead to costly and time-consuming misunderstandings. And for those problems that require escalation to more senior levels in order to be resolved or mitigated, it is essential to be crystal clear about what you’re saying (and why you’re saying it).
Is it a risk, is it an issue? Who cares?
There are plenty of official (and sometimes different) definitions on what risks and issues are and how to differentiate them. Personally, I like to keep it simple:
Issues = actual problems (happening right now and impacting your project)
Risks = potential problems (they haven’t materialised yet but will impact your project if they do).
So in a nutshell, risks and issues are problems that can disrupt your project. Though for a long time I used to keep them in separate registers (as per traditional project management methodologies), I now manage them in a single problems log which I try to keep as lean as possible. I still distinguish them within it, but why have two lists when you can have one…
Do you need to be scientific about it?
My short answer is no. You can report on all kind of attributes when it comes to risks and issues: severity, impact, priority, likelihood, types, categories, sub-categories, who raised it, who’s assigned to it, who works on it, etc. You can spend a lot of your time (over)analysing issues and risks like looking at ageing patterns, detailed trends, categories breakdown and so on. Whilst detailed analysis can be useful to the Project Manager (particularly on large projects) in terms of ongoing project control and priority management, when it comes to communicating about problems, what people (like your sponsor) want to know is:
So what does it mean for the project (why are you telling me this?)?
Now what are you going to do about it (can you make it go away please?)?
To answer these two questions simply and clearly:
Be clear and succinct about what the problem actually is and focus your communication on the impact and the solution (there is nothing more frustrating for a busy senior executive who’s been called in to help resolving an issue than being presented with a problem and no solution).
Be mindful: adapt your language and be sensitive to your audience’s ability to understand what you’re talking about; if you need to report on a major technical infrastructure issue, make sure you put in in words that are understandable to your non-technical stakeholders (they won’t mind if you don’t tell them the name of the server that keeps falling over).
Be selective about which problems you report on: you don’t need to report to everyone on every single risk and issue. It’s your job as the PM to select the key problems that need to be brought to attention – they should be the ones that have a serious impact on the project, and where you need other people’s help to fix them.
Be specific about resolution: tell people what you need from them (and when) to get the problem fixed.