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 |