One of the outputs from Qualitative Risk Analysis is project Risk Score, which is an indicator of project success probability. This indicator explicitly tells a project manager what is the likelihood of project completion within the given scope, time, and budget. The indicator is very important for the PM, but should it be disclosed to the project sponsor and other stakeholders?
-
The indicator number itself - no. The fact that risk exists, and your level of concern, yes.– gef05Commented Jul 23, 2012 at 23:43
Add a comment
|
6 Answers
I firmly believe that risk should be communicated to the customer. Open communication and clear expectations can spell the difference between grave financial losses and an action plan for scenarios where the problems occur.
For instance, if the customer knows there is a chance that the project may be delivered with more than zero defects, and there is a strong likelihood that there will be defects in the product, the customer then has the opportunity to make backup arrangements.
For instance, if the client is moving from a legacy system to a new system, they may then use the information you've reported to have a skeleton team -- one that is less sensitive to system failures -- use the new softwware while the team that is fault-intolerant can continue to use the old legacy system.
This is just one example. I've seen clients who were told our systems may not be 100% reliable make backup arrangements and still be successful with as low as 80% success rates, while I've seen clients who were told nothing lose millions of dollars because of one missed opportunity that they missed because they expected 100% success.
If you communicate with your customers and set clear expectations, they'll be more satisfied with you for watching their back and making sure they look good in front of their managers.
In all of the larger programs I've worked on the customer requires, by contract, that risk analyses be reported to them on a regular basis. In addition to reporting a list of risks identified, the contractor reports on the mitigation plan, and status of the mitigation plan. The customer reviews and approves the mitigation plan or accepts risks.
If risk reporting is not required by contract and if you are tracking risks I think it's a good idea to report it to the customer. It demonstrates that you are working to prevent problems for occurring.
Generally speaking, not just around risks, I try to run as transparently as possible. What I know, my client will know; what I do not know, my client will know I do not know.
Like the WBS, you have an RBS. There are a ton of lower level risks with lower level impacts with which the client sponsor does not need to waste his/her time. I may withhold reporting on those but they are readily available on the risk tool and the tool is available to the client sponsor. But higher level risks with more material impacts I will always report.
In fact, for those more major threats, the course of action--mitigation, contingencies--will likely involve the client in some way.
Caveat: if under a firm fixed price contract, there are a ton of risks that do not affect the client at all. For example, if you are running hot and blowing your budget, the client will not care. No reason to raise this up.
answered May 7, 2011 at 13:17
If the project sponsor is the customer, it is imperative that he be informed about the risk. Only the project sponsor and / or the project board should have the ultimate authority as to whether to take the risk: the PM should only be the means by which the project is delivered within the environment that the sponsor has agreed.
If the customer is someone else (eg a third party who has commissioned a piece of work from your company), and if (and only if) the customer doesn't carry any financial risk around the failure of the project, then there may be an argument to not inform him, although if I were the customer I would want to know whether there was a risk that I may not get what I had commissioned. A better model may be to inform the Project sponsor (internally to your company), and allow him to decide on the communications with the customer.
The key issue here is the roles that the individuals have. I appreciate that the PM may also be the salesman, or the customer may also be the sponsor, or the company hierarchy may not map against the project hierarchy, but I suggest that the roles need to be carefully analysed and understood. Only then can you truly unpick the complexity of the situation, and decide what needs to be communicated to whom, by whom.
There have been some very good comments so far. What I see missing is any discussion of severity or type of risk though.
First let's be clear, we're talking about risk in terms of the probability of a negative outcome, so anything less than 50% probability is a non-issue.
From there, then you have to look at 'who's risk is it'? As David pointed out - is it a risk or the contractor not making projected margin or budget? Then no, the client doesn't need to see that, but the Sponsor (senior mgmt) does.
Is it a risk of the project failing? Then everyone needs to know. Is it a risk that the client can help mitigate? Then everyone again.
So really, the answer is - who needs to see it? Whoever's going to be affected. You're the manager of the project, not the owner. It's your job to present all the relevant information to the concerned parties. There's no justifiable reason for hiding information.
answered May 9, 2011 at 18:19
In several different PMP related classes, the instructors pointed out that only two documents are described as registers - the Stakeholder Register and the Risk Register. According to several people, the term implies that contents of those two documents where intended to be handled differently and that language was proposed for the 4th addition that the information on these two documents were supposed to be kept private. However, the actual "privacy" language was not included.
This is only 2nd hand hearsay, unfortunately. As far as I can tell, the PMPBoK is quiet on whether or not risk information should be shared or not shared.
However, if the customer is also a project sponsor and part of the overall managing group of the project, then they should be informed as any other project sponsor would be.
