Typically, a formal escalation revolves around major problems like a system stand-still. For example, the entire solution or a core business process is completely down. Such severe problems should get escalated through formal channels.
A second class of formal escalation drivers involve issues that cause a “substantial negative business impact” — severe performance issues, functional gaps, implementation or operational issues. Again, these are usually dramatic and clearly topics that require formal escalation.
More tricky are less-defined issues like legal, compensation, public relations, or security problems. Many project managers aren’t aware of these issues, especially if they’re caught up in issue solving. Security escalations are particularly pernicious. The most damaging breaches don’t interfere with system function…because, of course, they’re making the solution function “too well” for the wrong folks.
Informal escalation skills are hard to define generically. My experience is that the most effective techniques are organization-dependent. One example: many customers think it is best for SAP resources to enter support tickets to SAP. Nope, not in my experience. Our support and development colleagues want to hear from the customer directly!
We suggest that the customer enter the ticket, then the SAP colleague on-site follows up. In fact, one of the first things I do with a new customer is to ensure they know how to use our support resources.
Filed under: Leadership, Organizational Change Management, Performance Management, PMO, Project Success Factors, SAP, Skills vs. competencies, Troubled Projects, Turnarounds | Tagged: de-escalation, escalation, formal escalation, informal escalation |
Crossderry Blog 
Yes…but.
Agree with the organization dependence – you have to deal with the culture and personalities that you’re given in your governance structure.
I do think that PMs as a group have issues with escalation due to their personal bias toward problem solving (ie they hold on to a problem/issue for too long trying to solve it themselves)
Part of escalation is being aware of that tendency as a start.
Part is adopting a different view of escalation. It need not be an admission of failure on your part. You could consider it as a gearbox – switching up a gear to address an issue.
Part is also formally defining escalation path and using it carefully early (get over the cry wolf syndrome) so that the organization learns how to escalat (switch up a gear) in a controlled way.
See similar post (referenced) on my blog.
Thanks for the comment Andrew. In other lots of posts — in the escalation series as well — I discuss this topic. My take is that this bias towards problem solving is what makes taking realizing it isn’t failure problematic. When one’s self-worth is defined by problem-solving, then admitting there’s a problem that you or your project can’t solve is a blow to the ego.