7.2 The Politics of Bad News and Escalation

 < Day Day Up > 



7.2 The Politics of Bad News and Escalation

This has two components: one is internal and the other is external to the project team. You have obligations to both sides of the project team fence. You want to keep the trust of the team lead who is mired in difficulty, so you do not want to brainlessly and perhaps cruelly announce to the world that Joe and his bunch, for instance, have fallen behind the eight ball. On the other hand, you are also responsible to your manager, the project sponsor, and potentially impacted customers or beneficiaries so you may need to alert them to brewing trouble. If you are really lucky, this issue will go away. If you are sort of lucky, the problem is one you anticipated as a potential risk, and you have a Plan B poised to kick in.

But if you are just not lucky at all, you have to step up to the plate because sticking your head in the sand just will not do. Elsewhere in the book, I mention that bad news has a way of getting out. You want to be the source, that is, the first to get the news out on the street. It must be packaged in such a way that people's reactions are: "That is too bad, but it sounds like you have it under control" as opposed to "How did you let this happen? Why did you not prevent this?"

Before you start sending out disingenuous e-mails that are little more than "CYA," think this problem through with your troubled partner. I follow a diagnostic process that is instinctive at this point because it is so simple. Also, I have had so much practice I can do it standing on my head. You simply need to ask, and understand, the following questions:

  1. What went wrong?

  2. What is the worst-case scenario in terms of project impact?

  3. What is the best way to fix this?

  4. What is the most realistic way of fixing this?

In other words, you need to understand the problem in terms of impact to the project and how best to effect repairs. Note the two "how to fix it" questions listed previously. The difference between the two is more obvious if:

  • Question 3 is prefaced with "In a perfect world "

  • Question 4 is restated as "What can we really do about this mess?"

One would be ecstatic if the answers are identical, but this circumstance, if serious enough, probably comes up during the project's "no luck at all" phase. The issue here is that the perfect fix may not be realistic in terms of timeframes, resource skills, headcount, funding, process conflicts, or technology issues. The other reason I ask the question both ways is to satisfy my packaging requirement for publicizing this negative information to the outside world. Once I understand the problem and possible remedies, I use the script from Exhibit 1 to prepare the information for public consumption.

Exhibit 1: Preparing Information for Public Consumption

start example

The ability of Project X to meet Deadline Y for Deliverable Z has come into question because of [event/condition] A that recently transpired, despite the expectation that [event/condition] B would have been the case. The potential impact to the project could be [missed date/incomplete deliverable/disrupted users/etc.]. Two approaches can be taken to alleviate this situation:

  1. Approach E requires [hiring/buying/rescheduling/postponing] at an estimated [cost/impact] of F.

  2. Alternatively, we could take Approach G. That would require the [hiring/buying/rescheduling/postponing] with an estimated [cost/impact] of H.

The project office recommends Approach E because it is [less/more] costly but does not require [schedule changes/hiring/recoding/etc.]. I have scheduled a meeting for tomorrow at 1:30 p.m. to review the situation and hopefully come to a decision regarding the best course of action to take so we can move forward ASAP.

end example

The script works very well. Its most notable characteristics are listed in Exhibit 2.

Exhibit 2: Escalation Script

start example

  • Describe the issue being escalated in terms of project impact.

  • Provide just enough detail to support any impact statements.

  • The packaging is antiseptic (i.e., free of emotion and hyperbole).

  • The issue is totally depersonalized; no names mentioned or blame assigned.

  • Two options are presented even if one is highly preferable to the other.

end example

Regarding the last point, never present a single option. This is particularly compelling if the preferred option is:

  • Going to put stress on the organization

  • A way out of the box

  • Considerably more expensive than the alternate

You definitely want to have, and present, an alternative. This is the rationale behind asking the "How can we fix this?" question two different ways. I do this with the assumption that Question 4, the "What can we get away with?" question, yields the more politically correct answer than does Question 3, which asks what the best-case solution would be (i.e., solicits the perfect-world answer).

So as you present an option, you can play the preferred resolution against the one that, at first glance, is less onerous to senior management. In this scenario, you are probably asking senior management to cough up additional money or grant other concessions - something they are instinctually loath to do. If you anticipate this, offer a solution path that is in line with their comfort zones, and "yes but" them to death when they ask why you are pressing for the more complicated or expensive solution that, in fact, is the better approach. Keep in mind that effective communication starts with knowing your audience. Never forget to test their hearing because what they are apparently hearing is far more important than what you think you are saying.

Also remember that the team lead you are trying to help in this situation may have internal issues. His or her manager may not be willing or able to tackle the problem. If this is the case, then you must handle this with additional tact less you step on the wrong toes and possibly put your team lead in hot water with his or her boss, too. You just cannot be too careful with this one.



 < Day Day Up > 



Complex IT project management(c) 16 steps to success
Complex IT Project Management: 16 Steps to Success
ISBN: 0849319323
EAN: 2147483647
Year: 2004
Pages: 231
Authors: Peter Schulte

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net