Delivery — 5th “D” for Leading Project Escalations

Good leadership never passes the buck… — Anonymous

The hardest part of an escalation is commiting to it; just like the first steps someone goes through when confronting crises such as alcoholism, drug addition, chronic smoking, etc.

Recognizing the need to change and the unmanageability of your situation — the first step of a typical 12-step program — corresponds to the Discovery layers of the Escalation pyramid.

The Discovery, Definition and Dialogue layers correspond to the second, third, fourth, and fifth steps of such programs:

  • Coming to believe that something outside of the project can “restore the project to sanity,”
  • Making a decision to turn that part of the project over
  • Taking an inventory of what is wrong (and right) about the project.
  • Admitting the faults in that inventory to another.

However, once the ball has started rolling, the situation becomes more normal. In other words, you manage an escalation just like any other project deliverable: plan, execute, monitor, control, and hopefully, close.

Dialogue — Going private with bad news

NOTE: This post leverages material from a TechRepublic article (here).

Of course, be prepared to have the “bad news” conversation with facts, figures, etc.  Use the following tips to be honest… tactfully!

Never simply say “Never” or “Can’t”

  • Gut reactions are not accepted without evidence
  • Some bosses then set out to prove that it can be done
  • Investigate all of the angles, present the information, THEN make the decision

Don’t point fingers — YES: We have a problem, NO: These guys screwed up

Do NOT go around your manager — If you have to escalate beyond him/her, say so!

Maintain Emotional Balance — Understand your reasons for the meeting; if you are upset, anxious, etc., talk to a surrogate first!

Use non-threatening questions to raise difficult issues — YES: “What are the implications if we do/don’t do X?”; NO: “Won’t senior management want us to do X?”

Navigating office politics — Slow down…Stay positive…Know when to fold ‘em, one can’t always win!

Dialogue — 4th “D” for Leading Project Escalations

 “AND to be able to explain it …” — Pericles on leadership

The great Athenian recognized that leadership required mastery of analysis and rhetoric.  As one figures out “What is to be done?”, some explanation and dialogue is inevitable.  But once you know what to do, one must carry the message to the world, and there is a way to deliver bad news.

Rule Number 1 is to save bad news for private meetings.  It just doesn’t make any sense to jump up in a public forum, though I never cease to be amazed by the number of folks who don’t understand that one should never criticize your superiors or their ideas in public. A great and simple tip from ArLyne Diamond from an interview (here) to short-circuit a potential pitfall or misunderstanding is that:

If you learn about the idea in a meeting, try to get the topic tabled with a suggestion that some research about it might be helpful.  Take your boss aside privately and share what you know in a friendly, noncondescending manner

Definition — Getting the bad news out the right way

In the previous post on defining the scope of an escalation, I highlighted the risk of appearing to be a “Chicken Little”.   Below are some quick tips on how to assemble timely facts, consequences, and answers before starting any conversation:

  • Make it real (time) — Quickly collect real data and evidence; you don’t want it to seem like you’re spouting personal opinions.
  • Keep it real — Don’t exaggerate the situation just for effect; hyperbole only gives your boss an excuse to dismiss you as overly dramatic.
  • Build coalitions — Your boss will be much more apt to listen if you have a group of colleagues who share your views about what’s going wrong. Even better is if you have suppliers, business partners, or customers who will corroborate the case you’re making.
  • Have solutions — Be ready to discuss what you’re prepared to do to fix the situation, not what you think others ought to do. Suggesting workable solutions builds your reputation as a person of action, not a complainer

Definition — 3rd “D” for Leading Project Escalations

To know what must be done…   — Pericles on leadership

In my experience, the informal escalations just discussed (here) are the hardest; nothing’s tougher than confronting the boss with a bombshell:

  • Implementation issues may involve resources one’s boss has sourced for the project.
  • Functional gaps may have been created by one’s own poor scope management practices.

You want to give the boss the heads up — without getting your head handed to you.  Preparing for conversations like these, however, is not always a strong point for technology professionals. Technology professionals often get a (sometimes deserved) reputation for knee-jerk overreaction to any new plan of action.  Nothing is worse than explaining why you don’t think a project is viable and then discovering you are wrong, so:

  • Proceed in a deliberate and measured way to gather the full scoop
  • Have all your facts checked before explaining your position

Decision — Formal vs. Informal Escalation Leadership

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.

Decision — 2nd “D” for Leading Project Escalations

“If it walks like a duck, quacks like a duck, and looks like a duck, then it must be a duck” — Italian proverb

Many project managers don’t like to escalate because they have trouble answering two questions:

  • Even if we know of a problem, is it worthy of escalation?
  • Why do you feel like you should fix it yourself?

The answer to the first question is pretty simple — if you can’t fix it within the project, it is by definition an escalation.  We’ll get into the difference between formal customer escalation vs. informal escalation in another post.

Addressing the second question requires project managers to look within.  There is a strong tendency among new leaders to revert to what brought them to their leadership position — technical or functional excellence.  As we’ve blogged before (here and here), avoiding this temptation is paramount during escalations. 

Project leaders must be aware of escalation dimensions beyond technology — e.g., stakeholder perceptions, legal, security, public relations, etc.  How much awareness can one have with one’s head “under the hood” solving an issue?

%d bloggers like this: