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)