I believe that information should be as accessible as possible in a project context to get the maximum benefit. However, one area where this can become tricky is the information contained on a risk register.
For example - there could be a risk that a key member of the project team (critical to the success of the project) leaves the company - with the associated impact on deliverables. The probability may be rated as high due to information about the team member, or the demand for their skillset in the local area.
It’s unlikely that any response strategy (e.g. lining up a different resource) will be best communicated via a risk register.
So, we have a dilemma – do we record this risk in a register accessible to the whole project team? Do we control access to the whole risk register? Do we maintain a separate risk register for entries with sensitive information?
I’d love to hear how others are managing access to dynamic, potentially sensitive information, but hopefully without hiding information away in a dusty vault or generating excessive admin overheads?
Thanks, and I look forward to your thoughts,
Tom Saving Changes...
Sort By:
Drew CraigSr. Agile & Product Coach| VanguardPhiladelphia, Pa, United States
If you use SharePoint, you can manage permissions at that granular level. Saving Changes...
Thanks Andrew - we do indeed use SharePoint, and I'm intrigued by the use of list item level permissions. This is straightforward if you want to allow each individual access to only the items they've raised. Have you taken this further - for example giving access to specific groups based on criteria within the SharePoint list? Saving Changes...
Why is it "unlikely that any response strategy will be best communicated via a risk register" if the PM is or the PM team is constantly reviewing risks and the risk register, and presumably there is a risk management plan that includes the risk responses?
...
1 reply by Thomas Lyne
Jul 11, 2018 4:06 AM
Thomas Lyne
...
Sante - thanks for your query. I'm thinking here about how best to communicate with individuals about decisions which may affect how they feel, which in turn can impact the team dynamic, individual motivation and ultimately project performance.
For example - if the PM identified that a project team member was responsible for a deliverable on the critical path, had the necessary skills, but had a reputation for losing focus - it would be natural that a response would be planned.
I personally would speak to the individual 1-2-1, and it could easily be embarrassing for them for this "risk" to be discussed openly in a team meeting.
Your thoughts appreciated?
Saving Changes...
RAJESH K LProject Manager, PMP| Bharat Electronics, Bengaluru, IndiaBengaluru, Karnataka, India
Access control with necessary permission/duration/periodicity etc can be enforced through tools such as Sharepoint.
...
1 reply by Thomas Lyne
Jul 11, 2018 4:08 AM
Thomas Lyne
...
Rajesh - another vote for SharePoint, thank you. Seems a good area to explore further, have you had found a need for significant custom development, or is the functionality reasonably out of the box?
Why is it "unlikely that any response strategy will be best communicated via a risk register" if the PM is or the PM team is constantly reviewing risks and the risk register, and presumably there is a risk management plan that includes the risk responses?
Sante - thanks for your query. I'm thinking here about how best to communicate with individuals about decisions which may affect how they feel, which in turn can impact the team dynamic, individual motivation and ultimately project performance.
For example - if the PM identified that a project team member was responsible for a deliverable on the critical path, had the necessary skills, but had a reputation for losing focus - it would be natural that a response would be planned.
I personally would speak to the individual 1-2-1, and it could easily be embarrassing for them for this "risk" to be discussed openly in a team meeting.
Your thoughts appreciated?
...
1 reply by Eric Simms
Jul 11, 2018 8:23 AM
Eric Simms
...
Thomas,
If you create your risks in List A, you can create a workflow that automatically copies a newly created risk from List A to List B. You can limit List B's permissions so only a few people can access it, and you can annotate the risks in List B with sensitive matters, such as a resource's lack of focus. This can be accomplished without special coding.
I believe you're right to consider resource-related risks as they can significantly impact a project.
Access control with necessary permission/duration/periodicity etc can be enforced through tools such as Sharepoint.
Rajesh - another vote for SharePoint, thank you. Seems a good area to explore further, have you had found a need for significant custom development, or is the functionality reasonably out of the box? Saving Changes...
Sergio Luis ConteHelping to create solutions for everyone| Worldwide based OrganizationsBuenos Aires, Argentina
Risk do not have to have the name of a person except for the person who is assigned to the risk. Then, if you detected that there is one and only one person to create a deliverable and you consider that the situation must be translated to a risk then you can record the risk and to assign it to the person that will define the action to deal witht the risk. No problem with that. The same with any type of risk. Saving Changes...
Much as we like to think that we are 100% transparent, there is going to be information which needs to be kept to a limited few. When it comes to individual team member issues, it's rare that you would need to share this with anyone other than the individual themselves or at most their people manager and that is what our personal journals are for.
Kiron Saving Changes...
Eric SimmsSenior Program ManagerBaltimore, Maryland, United States
Jul 11, 2018 4:06 AM
Replying to Thomas Lyne
...
Sante - thanks for your query. I'm thinking here about how best to communicate with individuals about decisions which may affect how they feel, which in turn can impact the team dynamic, individual motivation and ultimately project performance.
For example - if the PM identified that a project team member was responsible for a deliverable on the critical path, had the necessary skills, but had a reputation for losing focus - it would be natural that a response would be planned.
I personally would speak to the individual 1-2-1, and it could easily be embarrassing for them for this "risk" to be discussed openly in a team meeting.
Your thoughts appreciated?
Thomas,
If you create your risks in List A, you can create a workflow that automatically copies a newly created risk from List A to List B. You can limit List B's permissions so only a few people can access it, and you can annotate the risks in List B with sensitive matters, such as a resource's lack of focus. This can be accomplished without special coding.
I believe you're right to consider resource-related risks as they can significantly impact a project. Saving Changes...
Sergio / Kiron - Thanks for your comments; seems a pragmatic approach to assume that some information should be either kept private or at least anonymised.
Eric - Great practical suggestion, I think there's some mileage here for my situation as it removes barriers to the initial recording of risks, whilst also giving some breathing space to apply the suggestions from Sergio & Kiron. Saving Changes...
