Common Project Issues: Keeping Bad News from the Customer
Posted by Brad EgelandRarely 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.
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.
Related posts:











Common Project Issues: Keeping Bad News from the Customer … says:
[...] Go to the author’s original blog: Common Project Issues: Keeping Bad News from the Customer … [...]
Paul Chandler says:
Something else to consider is how you deal with bad news delivered to you by your team.
Having worked on many IT projects it makes a huge difference to the project how the bad news is dealt with internally within the team.
By creating an atmosphere where bad news is greeted by positive management looking to find solutions and involving the team in finding these solutions, you will encourage the team to raise issues early and allow plenty of time to deal with the bad news.
On the other hand if bad news creates a witch hunt and a blame culture you will find the team hiding bad news, or trying to deal with the issues in isolation without helping collaboration an open approach will bring.
By all means work out the “blame” of the issues, but don’t do so in the heat of the moment. Investigate “how we can do better next time” or “what we can learn from this problem” doing that will allow people to contribute without so much the need to defend themselves.
My bottom line is: work at getting the bad news out in the open early, whether it is to your customer or from your team, it will make everything work a lot smoother in the long run.
Tim says:
I don’t understand your governance structure. In my experience the PMO is a small group that manages the documentation – a service to the PM. Information flow is entirely under the control of the PM. How can you manage a project with split responsibilities like this?
It sounds like your PMO Director was working as a Commercial Director and thinking of the profitability of the customer as a whole, and you were only handling part of the picture?
Brad Egeland says:
In the organization I was working for at the time, the PMO did much more than manage documentation. All projects funneled through the PMO and the PMO Director assigned them to the various PMs based on expertise, experience and availability.
That PMO Director also made some bad decisions, IMO, on how to deal with customers. This example I mentioned in my article was one of them.
Jack Vinson says:
One of my problems with project management is that we wait to deliver news about delays, scope and other changes.
What I don’t understand is why these things are considered bad news (other than “the project is dead”). If you are in communication with your client on a regular basis, they should know the status of the project and where it is with respect to expectations. Of course some elements are going to take longer than expected. And you had better see other elements be shorter than expected. Remember the plan is just a picture of where you thought the project would go when you started.
Brad Egeland says:
Jack-
I agree. Waiting to deliver bad news is almost never a good thing. And yes, usually the customer knows it’s coming – especially if the PM is good and has kept everyone well informed with status reports, status meetings and an up to date project schedule. If those deliverables are happening on schedule, then the customer is not likely going to be surprised with bad news. Rather it will be issues that are already part of the weekly discussion and joint decision making will happen between the delivery organization and the customer.
Edward J. (Ed) Fern, MS, PMP says:
In my view, the project manager has a responsibility to anticipate, to the extent possible, both the opportunities and the threats that may be associated with a project. In this effort, the project manager must call on the vision of as many others as possible, including the customer. The intelligent customer will require the developed lists of opportunities and threats along with any triggers or symptoms that may suggest either of them is about to occur. The intelligent customer will also want to know the project manager’s strategies for minimizing threats and maximizing opportunities. So, in a well run project, hiding bad news will be impossible unless the bad news arises from causes that either were not, or could not have been, foreseen. In most cases, the customer will be well aware of the possibilities long before they materialize.
Roman says:
Personally, I treat “Keeping Bad News from the Customer” as “Lying”.
For me Lying to the customer results in the following:
1. The lie “eats” you morally.
2. You need to spend more time on managing all the information flow to the Customer, especially when other people in the team are interacting with him (check the reports, emails etc.)
3. When the results audit times come then bad things are discovered and you look like a fool.
For me, it is better to recognize that you made a mistake and work out the solution for the situation with the Customer, then lose him when he is not happy with the results.