Project Management Central

Please login or join to subscribe to this thread

Topics: IT Project Management, PMI Standards, PMO
Risks and Issues Communication

One struggle our PMO is facing is the communication and escalation of Risks/Issues/Blockers. We keep RID logs, track the issues, etc. but are getting feedback from upper mgt that, if and when we have a blocker, we are not communicating it enough. As an example, there was a pending decision that needed to be made, but every time the PM tried to set up a meeting, the decision maker kept re-scheduling, couldn't make it, etc. However, when it came up later, said person stated they didn't know they were being a blocker. Not all of our PMO team members work in the same office, so it's difficult to just "pop in" someone's office to grab their attention, so we rely a lot on email and conference calls.
Does anyone have any procedures on how they escalate these types of items? We'd like to include it as a part of the project weekly report to the Project Sponsor, who could potentially help, or on our biweekly reports distributed to other members of the organization, but also do not want that to be the first time that someone finds out they are a blocker ("throw them under the bus").

Thank you!
Sort By:

These are the things which can help in such situations:
- Agree on the escalation protocol as part of the project kick-off
- Communicate the deadline by when a decision has to be made
- Remind the deadline each time you are re-scheduling/communicating with the person
- Explain to them why it is important to make a decision by the set date and how it will affect the project if a decision is not made
- Offer your help to assist them in the decision making practice

Ps. There are different reasons people delay a task. Try finding out why they are not acting on the item assigned to them. In my experience, a lot of times they don't take action because they don't understand what is needed from them.

Sounds like certain stakeholders might prefer to complain rather than take ownership for an issue!

In such cases, I'd meet with the stakeholder, review a recent incident and ask them what might be a more effective method of making them aware of the issue. You might also want to confirm that what was presented/shared was meaningful - I really like Dr. Hillson's definition of risk as "uncertainty that matters". If what you've shared didn't matter (as stated), it's no surprise if you didn't get the desired outcome.

If they don't provide a reasonable explanation for why risks or issues were neglected, escalation might be your best option - either to the sponsor or another appropriate key stakeholder.

The other question is could you have acted without their permission? If you were merely looking for their support, is that really necessary?

Thank you both! Those are both helpful responses and I appreciate it!

Transparency is the key here. If key stakeholders can see the decisions that are coming up, the ones making decisions are more likely to make the decisions on time. Similar to milestones and deliverables, you can create a Decision Timeline that is shared on some platform where everyone can look at it in bright colors (ie. traffic light) to indicate things like criticality. As the time for the decision approaches, reminders are sent out. Have a flag system to highlight the decision process, such as number of decisions made on time, number of decisions made early, and number of decisions made late. There's nothing like an billboard of decision flow to get stakeholders into action. It forces a team attitude which is what you want.

communication with stakeholders with transparency is very true. If you have a process defined with them, it will be helpful when they are not able to make to meetings. There maybe others in team who can resolve the issue when it occurs on time. Usually issues coming in are given priority hence the urgency to resolve is known.

Sounds familiar. I've seen stakeholders complain about a problem, then shrug off meeting after meeting that a PM tried to set up to resolve it, and then complain that the PM wasn't doing enough to resolve the issue.
When I feel a stakeholder is purposefully avoiding a decision, I typically send them an email in which I describe the decision they need to make, and I state very clearly that the project can't move ahead or will be delayed if they do not make the decision. This tells them what is expected of them, and the consequences if they fail to act. This makes it pretty much impossible for someone to later say they didn't understand what needed to be done.

Ultimately, the model best to facilitate transparency is to centralize the log with automated workflows. One potential solution is setting up an automatic workflow, say in SharePoint, for the RID log. A newly submitted item will trigger a workflow, notifying the predefined team/individual of a new request. In the list, the item will show as pending 'team/individual' review. JIRA allows for workflows as well.

Please login or join to reply

Content ID:

"I went into a McDonald's yesterday and said, 'I'd like some fries.' The girl at the counter said, 'Would you like some fries with that?' "

- Jay Leno