When to Deliver Bad News
Monday, March 12, 2012 at 8:00AM
Gary L Kelley in Bad News, IT, Project Management, program

Timing around delivering “bad news” can be tricky.  Deliver too quickly, and you’ll be accused of panicking.  Wait too long and it will be suggested you hid a problem.

It’s our experience giving people bad news sooner rather than later is the key.  If you are working on a major program, you might list “bad news” on a Risk/Issues register…where a risk is something that might happen, and an issue is something that has happened.

We always try to work an issue before raising a red flag.  After all, it’s our job to work items and make them non-issues.  Sometimes there just is no way out.

When you identify an issue, always try to suggest mitigations…so the issue just doesn’t lay on the table without hope.

A few other factors always come in to play:

One time a subordinate sent out an email with a CFO’s name on it.  The CFO had not seen or approved the email.  When this was uncovered, we went to the CFO, explained the situation, let him get a little red-faced, and then knew we would live for another day when he said, “All we can do now is backfill, so how do we do that?”

Execs are people, too.  Sometimes they just need the privacy to drop an f-bomb and then get their game face on.

When an executive feels they are the last to hear bad news, trust erodes quickly.  Executives may not like bad news, but they appreciate knowing about it first.

Simple?  In a blog, it is simple.  In the real world it is much more complicated and gets into the personalities involved:

Our rule of thumb is the bigger the risk, the quicker we must act.


Article originally appeared on Gary L Kelley (http://garylkelley.com/).
See website for complete article licensing information.