Rarely does a project run it’s course where there is no bad news to share with the customer.  There’s always something.  Whether it’s a minor schedule delay or a major project budget overrun, there’s almost always something that goes wrong and presents us with the need to share bad news with the customer.  How we handle these situations often separates the good Project Manager from the bad Project Manager.

The Bad News

Has anyone really run a decent sized project without anything negative occurring?  Sometimes that can happen on a very small project.  However, every project of any significant size that I have led has always had something come up.  How we deal with it can be a major factor in project success and customer satisfaction.

I have led IT engagements for a very diverse group of companies…so I’ve had to tell customers everything from “additional scoping is going to be required resulting in ‘x’ budget increase” to “our CEO was fraudulent, killed himself, and now the company is shutting down.”  With the former, you have a chance to put a positive spin on things.  With the latter there is nothing you can do but give them the news, work with them on knowledge transfer and hope that it doesn’t affect your career.  Believe me, that was the strangest news I ever have had to deliver, but the way I handled it resulted in a job offer for me from the client organization.

The Action

Withholding the news is almost never a good option.  If you are absolutely certain that the issue can be corrected and any budget overrun will be eaten by the delivery organization and this can be handled without the customer knowing it, then possibly it’s ok to work through the issue without bringing the customer into it.  But customers are smart – and in order to preserve your professional reputation, it is almost certainly the right thing to do to tell the customer the bad news as early as possible.

Project gone bad

I ran into a budget overrun issue on a project I had taken over when it went from “dead-in-the-water to a “re-start” mode.  While the development team was performing a necessary upgrade to the software in the development environment, a portion of the upgrade was missed and it wasn’t apparent for a couple of weeks.  The two-week setback plus the surprisingly slow data load process (it was the first time the company had taken on a data load this large) we lost several weeks on the schedule as well as tens of thousands of budget dollars. 

I drew up the details and wanted to present the issue immediately to the customer project sponsor.  However, our PMO Director put a stop to the breaking of the news as he wanted to work through it further.  If you’re reading this….you know who you are.  Ultimately, he knew my info was right and about 3 weeks later he let ME break the news….MUCH later than I wanted to. Unfortunately it was too late to save the project because after putting the project on hold temporarily to deliberate on the issue and decide if they wanted to throw more $$ at it, they decided to pull the plug instead.  And this was a visible project with a government agency.  Thankfully, the customer didn’t directly blame me and I’ve remained cordially in contact with them to this day.  But it was very disappointing to me to lose that client and the entire issue may have been avoidable by working with the customer on the issue earlier in the process.

Summary

To sum this up – from my view – if the project reaches an issue point that is going to adversely affect the customer, the budget, the project timeline, etc., then let the customer know as soon as possible.  By all means, take a couple of days to map out how the issue will affect the customer and the project and identify some possible decision points or workarounds, but don’t delay very long the breaking of the news to the customer.  It is critical to the project and to customer satisfaction.