It is 8:00 p.m., and Alex has been trying all day to get a technical expert to comment on the pre-sales proposal he must submit to the customer by tomorrow morning. The technical expert refuses to assist, saying he is too busy. Alex does not know what to do or who else to ask for help.

 

He finds out who the technical expert reports to, sends an email seeking intervention and finally goes home, hoping a response will come by the morning.

 

The next day, there is still no response; he is already late submitting the proposal.

 

What went wrong here? Why didn’t the expected response come?

 

Alex works in a matrix organization. The boss to whom he sent the escalation saw the email, 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. By then, it was already too late.

 

This is a familiar scenario. As project managers, you may face similar situations in your work lives when you escalate —yet nothing happens.

 

Situations Requiring Escalation

Resource and inter-group conflicts, incorrect expectations about roles and responsibilities and risks to key project indicators are some of the typical situations that could require escalation.

There are several types of escalation to consider:

 

Sometimes you need a yes or no answer to a critical question (such as scope expansion) that is beyond your authority.

 

Conflicts may require mediation from someone at a higher level with a broader view of the project/program.

 

An information-only escalation simply keeps management informed of potential issues that may arise and require their attention in the future.

 

Knowing When the Time is Right

Ask yourself these questions to help you decide whether it is time to escalate:

Have you made a sincere attempt to reach an appropriate resolution but 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 need to be consulted?

 

Can you approach these experts or stakeholders directly, 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 or deliverables?

 

If you escalate very frequently, management may perceive that either you are not competent at your job or the project is in dire risk. If you rarely escalate, critical issues may be missed and it may be too late for management to step in and facilitate the needed timely resolution.

 

Doing it Right

Once you’ve decided to escalate, it’s important to do it in a mature and professional way. Here are six tips for effectively escalating problems with your project or on your project team.

 

• You need to determine the right person to escalate to. The immediate manager may not be the one to escalate to, especially in a matrix organization.

 

• Escalate to an appropriate level in the hierarchy in which there is someone empowered to make the decision or intervene. Going “too high” may result in your request being sent down to a lower-level employee.

 

• Provide a 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.

 

• State explicitly what you need. Don’t leave any ambiguity. Make sure you say when you need it and the impact or consequences if the expected action is not taken in time.

 

• Follow up, even after sending that email and/or making the telephone call—do not assume that when you escalate, the ball is now in the other person’s court.

 

• Use appropriate, respectful content. Harsh e-mails and/or telephone calls complicate more things than they solve.

 

Getting back to Alex— a few proactive measures probably would have ensured that he would have been able to submit the proposal on time.

 

Instead of waiting until 8:00 p.m., he should have escalated during office hours. Before escalating, he should have found the right person to influence the technical expert’s priorities, rather than just the expert’s boss.

 

If he had trouble finding the right person, sending an issue summary that included the fail-to-respond impact to the expert’s boss would have helped him or her find the right people to set the correct priorities for the expert.

 

As with any other activity in project management, escalation is as much of an art as it is a science. Following these best practices helps us avoid the most common pitfalls.