So I have started documented all risk related issues in a RAID log. I am showing my stakeholder it weekly, so that he is aware of all product related risks, but not sure if there is much value in doing so?
What do you think?
Add a comment
|
3 Answers
The purpose of the log is to keep you, as the PM, and your team on the same page as to the high priority things on which you are working. It is not a communication vehicle. To communicate with it means you need to scrub it and make it customer/stakeholder ready. You will end up working on the log as if it were a product of and in itself and that is not what it is supposed to be for. Who cares if the log is ugly, with spelling errors, grammar errors, etc. But you would care if you have to "deliver" it.
Extracting the elements in the log and communicating it out in other communication vehicles--weekly reports, monthly reports, audit analysis, etc.--is not only a good thing but is your job. And of course, exposing or hiding information based on the stakeholder is a political action you need to consider, too. Be transparent but be smart about it.
answered Jan 30, 2017 at 12:18
-
Wouldn't it be fair to say that anything that the PM shares with the project team and/or sponsor is a communication product of the project? If I have to re-write the log to be shared with the customer because it's unprofessional, full of mistakes and spelling errors, and doesn't say what actually needs to be communicated, then how does my team know what is happening and what needs to be done? Jan 30, 2017 at 13:51
-
Obviously, the tool needs to be written clear enough so people can understand. I am trying to point out the difference between a tool that is clear with a customer-ready product. These are two very different things. I've struggled with this very issue, spending way too much time trying to get a risk log customer ready that our entire risk program became about the log instead of navigating threats. There's a difference here. Jan 30, 2017 at 15:00
-
1Totally agree with @DavidEspina, I extract the Risks and Issues that I want wider stakeholders to take notice of and add them into the pack for my project boards. Stakeholders don't need to see all manner of risk/issue churn that doesn't concern them, it only gets them excited and makes more work for the PM. Manage the communications flow for a happy life... Jan 30, 2017 at 19:48
-
I may have been spoiled. I have customers who have a very good understanding of the world that my company operates in (IT/Software), so they already know the risks for our projects. I can freely share the information back and forth because there's nothing there to surprise them. Jan 31, 2017 at 13:45
-
@JennieK_NS, I haven't been that lucky. Intellectually, everyone knows they must do "risk management" but, when you do it, there seems to be some degree of resistance, both those raising threats and those to whom you raise the risks. No one wants to share their dirty laundry and no one wants to see their dirty laundry. A weird paradox I have been trying to understand and overcome...not with great success, I might add. Good for u that u're experiencing something different. Jan 31, 2017 at 14:33
In my experience, there is certainly value in keeping a RAID log, and making it accessible for project stakeholders to view. However, I wouldn't take it to them weekly unless specifically requested to do so. At most I'd send them a link to it, or attach it in my regular project update emails, and then they can choose to view it or not if they have the time/inclination to do so.
The exception to this would be if I came across a major risk, but then I would flag it independently of the RAID log to the stakeholders, and document it in the log also.
TL;DR: Give them the choice by making it accessible.
Depending on the current state of your project, the frequency of you sharing RAID Logs with your stakeholder depends, IMHO.
In an average project, risks may not need review each week, but in a high-risk project the risk log may need to be reviewed more often. Each project has a different makeup, which should dictate the frequency with which each category in a RAID log needs to be considered & discussed.
Based on the current state of your project, and also based on how your customer is "perceiving" the project state, you can determine if showing RAID logs is adding any value or not.
If your customer is asking you to discuss "weekly" these RAID logs, then I suggest you should properly prioritise your RAID Log items. Make sure to discuss high priority RAID Log items upfront such as High risks, important dependencies etc.
answered Apr 30, 2017 at 17:37
