Danica Michaela MancaoProject Portfolio Management Specialist| Aboitiz Power CorporationLey, Philippines
Hello everyone,
I just wanted to know how you do your escalation process? When and what issues are to be escalated to the executive team? Saving Changes...
Sort By:
Sergio Luis ConteHelping to create solutions for everyone| Worldwide based OrganizationsBuenos Aires, Argentina
It will depends on the governance process defined into your organization. In my case, what I am using from years is a pyramid where we have (from top to bottom): -Steering Committee: 1% of open risk and issues. -Operating Committee: 14% of open risk and issues. -Project Team: 85% of open risk and issues. Depending on the type of initiative we have one session per month with the steering committee, two sessions per month with the operating committe and weekly sessions with the project team. But all these will depends on the approach you will use too. For example, in our case, from some time we are using SAFe expanded to all the organization then meetings cadence could be not the same than if we use some agile based method. Saving Changes...
That is often something defined in either the governance plan for a project or the communications plan. In general, escalation is a response to an action, issue, or risk when it falls above the authority level of the PM and team to address on their own or when they have attempted to address it on their own and have been unable to successfully do so through direct action, influence or persuasion.
Kiron Saving Changes...
Thomas WalentaGlobal Project Economy ExpertHackenheim, Germany
Danica,
agree with Sergio and Kiron, it should be defined in governance policies about projects.
In addition to formalities, it is wise not to surprise the sponsor and the steering committee, and use risk management to address potential situations before they become issues that can not be handled by the project.
And, most important: before sending a report, call these guys so they understand a torpedo is headed their way.
Your policy can be started at least semi-formally with a discussion among the policy owners. I find this conversation is an extremely valuable part of risk management.
There are a lot of opinions about what risk level to assign to individual items. What counts as a big risk at the working group level often doesn't at the C-suite level. My current employer uses a "Big Rocks" to "Pebbles" analogy of water flowing around obstacles in a stream, but even that scale still follows a general means or ranking.
Sometimes the levels are very quantifiable; other times they are not. I like to start with a risk matrix to frame the discussion. 3x3 for High Med Low is an example although I think a 4x4 or 5x5 sometimes works better at least for the discussion itself. Using examples, discuss where you would put them on the grid and why. Even if you don't all agree on the exact grid position, frequently you are still fairly close.
The actual criteria can still be somewhat subjective, but the conversation allows everyone to share their values. It's much easier to gain a general consensus, when you know others' thought processes in their own prioritization. Then you can document the general criteria for future use knowing they are not set in stone. Saving Changes...
Thomas WalentaGlobal Project Economy ExpertHackenheim, Germany
Hi Danica,
there might be unwritten rules, habits how things are done, decided in your organisation.
Escalations from projects then come to executives by surprise (raising adrenalin levels), may be intense (using much of their time) and lacking appropriate handling options. So they probably already feel a problem here.
A policy and its implementation can mitigate that problem by setting rules, principles and processes how and when to handle exceptions. And making sure they are followed.
The benefit to executives is that it can reduce their stress level and free up their time for progress instead using it for trouble shooting. This is a good business case for establishing policies.
Thomas Saving Changes...
Peter RapinSubject Matter Expect; Project Delivery| Independent ConsultantOntario, Canada
Escalation is clear when: 1) the impact extends beyond the project, and 2) a decision exceeds your level of authority (financial, human resources, procurement).
Other than that escalation is a risky business (for the project manager). Too quick to escalated results in lost confidence in your abilities to manage the project. Too slow and you're open to criticism and possibly discipline.
Best approach is: a) through proper governance structure with clear role and responsibility documentation, and b) thorough risk identification and assessment including the if and when to escalate.
There is also a distinction between advising of a proposed action and asking for a resolution or direction. Make sure when you escalate that you know and clearly define what you expect in response - acknowledgement, support, or direction. Saving Changes...
