It is 8:00 p.m at night, and Alex has been pushing all day to get some comments from a technical expert on the pre-sales proposal he must submit to the customer by tomorrow morning. The technical expert refuses to provide comments, citing that he is too busy. Alex does not know what to do or who to ask for help. He opens his email client to see who the technical expert reports to, sends out an e-mail asking for intervention and help, and finally goes home, hoping a response will come by the morning. Alex wakes up early the next morning and hurries to the office only to see no response; he is already late submitting the proposal.
What went wrong here? Why didn’t the expected response come?
Well, Alex works in a matrix organization, and the boss to whom he escalated was actually just a people manager. He did see the e-mail on his Blackberry but had no idea what to do with it. With good intention, he flagged it for follow up the next morning but got busy with other things and could only check with the expert in the afternoon, when it was already too late.
Although slightly exaggerated, this is a familiar scenario. Don’t we face similar situations in our work lives when we want to escalate, do escalate, yet nothing happens?
Let us take a deeper look at the phenomenon of escalation: what it is, when it is needed, how it is incorrectly done, often abused and, most importantly, how to do it right.
What is Escalation?
Webster defines escalation as “to increase in extent, volume, number, amount, intensity, or scope.”
In a project management context, escalation means initiating an additional sequence of actions over and above the normal process flow that is required to release a “blockage” or solve an “issue” to achieve a particular objective; in most cases, involving management levels above you to facilitate the resolution.
Typical situations requiring escalation
The situations demanding escalation are as varied as the types of projects. Following are a few of the most common situations faced in the typical workplace:
Resource conflicts – to secure, retain, and engage the most appropriate resources for the project’s needs
Risk to key project indicators – When risk is introduced to one of the key project health indicators — scope, schedule, quality or cost—and that cannot be mitigated without seeking appropriate stakeholder attention and/or approval
Inter-group conflicts – Stakeholders disagreeing over critical issues or priorities that need a relevant authority to mediate and facilitate resolution
Incorrect expectations about roles and responsibilities – to seek clarity in disputes related to roles and responsibilities as seen by different stakeholders.
Escalation is not a dirty word
Escalation does not mean complaining—it is simply the process of bringing attention to an “issue” from the relevant stakeholders who have the authority to facilitate the resolution of the conflict and/or decide on the next steps to be taken.
What prevents us from escalating?
- · Fear of conflict
- · Lack of confidence because of not having a detailed understanding of the issue(s)
- · Protecting someone
- · Not sure if it is the right time to escalate
- · Not understanding the criticality of the issue(s)
Types of Escalation
Approval – yes/no answer. Often escalation is needed because it is beyond the project manager’s authority to make that decision (e.g., seeking a few-week extension on a project schedule because of a new scope being introduced might need a project sponsor’s approval). The sponsor must make the decision to approve an extension or to reject the new scope.
Mediation needed – A conflict of interest between two groups over a particular issue (e.g., priorities might need someone at a higher level with a broader view of the project/program to address the conflict).
. Information only – This type of escalation is to keep management informed of the potential issues that may arise and that might require their attention in the future.
Knowing when the time is right
Escalation is a double-edged sword: escalating too few issues is as bad as escalating too many. If you escalate very frequently, it may be perceived that either you are not competent at your job or the project is in dire risk. On the other hand, if you rarely escalate, critical issues may be missed and it may be too late for management to step in and facilitate the timely resolution needed.
The following questions can help set the proper context and help guide that decision:
- · Have you made a sincere attempt to reach an appropriate resolution and have found that you are at a dead end?
- · Is this an issue that your boss would expect you to handle or to escalate?
- · Do you have all the appropriate know-how to make the decision, or does another subject matter expert or stakeholder(s) need to be consulted (and that input could change your decision)?
- · Can you approach these experts or stakeholders directly (without going through the escalation route) or is escalation the only way to obtain their input?
- · Have you exhausted all other options and any further delay could have a detrimental effect on the project outcome/deliverables?
How to do it right
Once it has been concluded that the next step needed in the issue resolution process is indeed escalation, the seven R’s described below can facilitate in going about it in a mature and professional way:
· Right Person – Escalate to the right person with the power to influence, More often than not, when there are problems, people tend to escalate to the bosses. Depending on the issue, oftentimes, the immediate manager may not be the right person to escalate to, especially in a matrix organization. This could become just information for him and he may have to further escalate by finding the right person— something you should have done in the first place. And, in the worst case scenario, he may do nothing about it.
· Right Channel – Escalate via the proper channel. It may not always help to know the right person to escalate to; you must find the right channel to escalate to make sure the person you are escalating to gives the proper attention the issue deserves.
· Right Level – Escalate to an appropriate level. Escalate to the appropriate level in the hierarchy in which there is someone empowered to make the decision or intervene. Escalating a few levels up will not necessarily always solve your problems, because those at the top may send the same e-mails down to a lower-level employees anyway.
· Right Problem – State the problem very clearly. Provide another concise summary of the problem and also indicate where detailed information can be found. Do not assume that the people you are escalating to have the required background information.
· Right Needs – State explicitly what you need. Don’t leave any ambiguity; clearly and explicitly, indicate what you expect from the person to whom you are escalating to get what you want, and more importantly, when you need it and the impact/consequences if the expected action is not taken in time.
· Right Follow up. Follow up, even after sending that e-mail and/or making the telephone call—do not assume that when you escalate, the ball is now in their court. Escalation is a means of issue resolution. As a project manager, you still own the issue and the ball is still in your court.
· Last, but not the least, Right Communication. Use appropriate, respectful content and escalate in a mature and respectful manner. Harsh e-mails and/or telephone calls and inappropriate behavior complicate more things than they solve. Always remember that resolution of the “issue” is of utmost importance and this is what must be highlighted in such communication.
Going back to our case study in the beginning of this article—a few proactive measures from Alex probably would have ensured that he would have been able to submit the proposal on time. These proactive measures are as follows:
- · Instead of waiting until 8:00 p.m. that night, it probably would have been wiser to make that decision much earlier, during office hours, to stop pushing that expert himself and seek escalation.
- · Instead of blindly sending the e-mail to his boss, a few telephone calls to the right people would have probably gotten him the right person to influence the technical expert’s priorities.
- · An issue summary would have given the people manager some background information to get the right people to set the correct priorities for the expert.
- · Explicit communication about the urgency of the situation, and the impact if a response had not been received within a stipulated period, might have triggered a much faster response from the people manager.
After all is said and done, as with any other activity in project management, escalation is as much of an art as it is a science. Following a few best practices helps us avoid the most common pitfalls.
A little more attention, discretion, and thought given before and during an escalation will go a long way in achieving a more amicable and favorable response; eventually, this will contribute in a significant way to managing the six constraints of scope, time, cost, quality, risk, and resources in the project in the most effective and efficient way.
To quote Andrew Sparks from one of his blogs,
Escalation in a project is like driving a car with manual transmission.
You can drive everywhere in second gear, but it is bad for the engine, makes a lot of noise, and it's just plain inefficient.
Changing gear up or down at the appropriate time delivers a smoother ride for everyone.
(Note: The article was first published on www.pmi.org by the same author)