Pressure, Error, and Leading Project Escalations

While we’re on escalated projects it’s a good time to hearken back to Dietrich Dorner’s book on The Logic of Failure: Recognizing and Avoiding Error in Complex Situations.   Such projects are a high-pressure leadership environment, for sure.  It is critical to have no illusions about what lies ahead, especially in the Discovery (here and here) and Decision (here and here) parts of the leadership pyramid.

Ken Thompson’s The Bumble Bee blog at bioteams.com highlights two “tangents” identified by Dorner.  These are common leadership failure modes, largely because they are very tempting to pursue during a crisis.

We may resort to “horizontal flight,” pulling back into a small, cozy corner of reality where we feel at home … Or we may resort to “vertical flight,” kicking ourselves free of recalcitrant reality altogether and constructing a more cooperative image of that reality. Operating solely within out own minds, we no longer have to deal with reality but only with what we happen to think about it.”

Read all of Ken’s post here.  Note his great tips on how to deal with a “flying” leader.

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?

Discovery — Getting bad news out in escalations

To really “know” your project, make the project safe for bad news.  I’ve adapted the following — from Scott Kirsner’s 2002 Fast Company piece (here) — seven tips on getting bad news in time to do something about it.

1. Dead people don’t walk through open doors. I make it very clear that bad news is OK, to the point of encouraging someone who has come to me privately to speak up in a meeting so I can publicly show that it is OK.
2. Bad news travels in packs. If any bad news does reach me, it probably is traveling with friends.
3. You must have your ways of finding things out. This works two ways: sometimes you need to socialize topics informally, sometimes you need to have an informal network of frontline contacts who don’t report to you directly.
4. Join your own organization.  This is harder to do in a virtual organization, but try spending time outside your office, hefting boxes at the loading dock or taking calls in the call center.
5. Can the canned presentations.  We switch up on use of PPTs…sometimes we use them, but sometimes I ask for impromptu updates w/out slides.
6. Make bad news legit.  The CIA used to have a group of “Team B” analysts provide contrarian, worst-case perspective.  Team B’s, however, were “too often” right, so the CIA ended the practice.  Learn from that mistake.
7. Do something. (More on this later…)

Discovery: 1st “D” for Leading Project Escalations

Ignorance is not bliss – it is oblivion” — Philip Wylie

Over the last ten years we’ve seen plenty of examples of senior executives who ignore bad news — until it turns into worse news.  Enron, Arthur Andersen, Bear Stearns, Yahoo, Tyco, the FBI, the CIA, the Catholic Church…

What you don’t know — and don’t even want to know — can and will hurt you.  So the question is: How well do you know your project?

On the “positive” side, projects are filled with high-achieving and performing technicians.  Many are used to solving complex problems, so there is a natural bias towards optimism that hides problems.  Per Chip Heath at Stanford Business School:

There’s a bias for optimism in humans and in organizations. Individuals don’t ever go looking for bad news, and we don’t like telling it to others. So bad news is unlikely to get to the people who can actually do something about it.