Give good news frequently; give bad news early

I’ve been a consultant for a lot of years now and as any experienced consultant knows, good communication is one of the key pillars to the successful delivery of a project. It’s so obvious, it’s really almost boring to talk about.  This isn’t a post about generic communication.  Instead, I’m writing about the darker side of communication — communicating bad news.

It goes without saying that giving good news to the client is done all the time, as often as possible.  Who doesn’t want to give good news?  Who doesn’t like to hear good news? 

On the flip side, bad news is no fun at all.  I have always struggled with this.  In the earlier days of my career, I would know something was awry with a project and instead of telling the client, I would work longer hours to try and solve the problem.  I would enjoin my team to work harder.  It’s a natural enough impulse to think that a super-human effort can save the day.  Some times this works, some times it does not.  Even when it "works" it’s often a mixed bag.  Is the quality of the deliverable really up to spec when key parts have been developed over several 60 to 80 hour weeks? 

What is the best way to handle bad news?  The answer is: tell it early.  Don’t wait until one week before the project budget will be consumed.  If you know six weeks out that there simply isn’t enough time to deliver some bit of promised functionality, tell the client right then and there.  The client may get upset (probably will), there may be incriminations and accusations and hurt feelings.  But, when emotions cool off, there’s still six weeks left on the project.  Six weeks is a good chunk of time.  There’s time to adjust plans, change schedules, get the ball rolling on budget extensions (good luck!) and just generally come to grips with the "facts on the ground" and devise a new plan that still results in a successful project. 

Case in point: I’m working on a project characterized by:

  • T&E budget with a capped "Not to exceed" dollar amount.
  • A "best efforts will be made" promise to deliver X, Y and Z by project’s end.
  • Lack of promised key resources on the client side.  These resources were not withheld on purpose, nor for any "bad" reason, but they were withheld.
  • A dawning realization as the project passed the half-way point that we were not going to be able to deliver "Z" (mainly because the promised resources were not actually available).
  • Regular status reports and "CYA" documentation that backed us (the consulting team) up. 
  • Tightly knit implementation team with members drawn from the consulting organization (my company) and the client.
  • Distant management team, in both a metaphorical and physical sense.  The management team was focused on another large enterprise project and due to space constraints, the implementation team was housed in a separate building on campus, down a hill and relatively far way from "civilization".

With roughly six weeks left on the project budget, we (the implementation team) knew that we were trouble.  The contract said that we needed to deliver "Z".  Even though the project is time & materials and even though we only promised "best efforts" to deliver Z and even though we had great justification for missing the delivery … the bottom line is that it wasn’t looking good — we were not going to deliver Z in a shape a quality that would make anyone proud.

Recognizing this, we went to management and told them that the project budget would be consumed by a certain date and that we were in trouble with Z.

A mini firestorm erupted over the next few days.

Day 1: Management team calls in its staff for a special meeting (we, the consultants are not invited).  Contracts are printed and handed out to everyone and a line-by-line review ensues.  Management puts the staff members on the defensive.  I don’t think the phrase "Stockholm Syndrome" is *actually* used, but you get the picture.  We’re a tight-knit group, after all, and the staff has been working with us consultants day in and out for several months now.

Day 2: Management calls another staff meeting.  They feel a little better.  They want options and ideas for moving forward.  They realize there’s still six weeks remaining in the current project budget, which is still a decent bit of time.  One of the action items: schedule a meeting with full implementation team (including consultants).

Day 5: Full team meets, constructive meeting ensues and a new achievable plan put into place.  Even better, we’ve already begun discussing phase two and the client invites us to prepare proposals for that phase immediately.

If we had waited until just three weeks remained, or even worse, one or two weeks, it would have been much different.  Instead of a constructive meeting to re-align the project, we would have been pulling out status reports, parsing the contract and reviewing old emails to justify this or that decision.  We would have "won" but is it really "winning" in this case? 

So, if you have to give bad news, give it early.  Bad news given late isn’t just bad, it’s horrible.

Leave a Reply

Your email address will not be published. Required fields are marked *