Don't discourage the reporting of bad news
Bill was beginning to see the light at the end of the tunnel with his program for installing a manufacturing software package at a new plant. The program consisted of eight individual but related projects. Most were moving as expected, but the last project was becoming problematic. When I met with Bill, I could tell he was angry.
The dilemma
“The project manager on this last initiative is really causing me heartburn,” Bill grumbled. “Every week in our status meeting, we discuss problems. Every status report contains exceptions. The other project managers got their work done relatively smoothly, but this guy may not cut it.”
I asked Bill for a short description of the types of problems the project manager was reporting.
“It’s always something,” Bill replied. “One week, he warned about an implementation risk that was overlooked before. Then he reported a problem getting the floor managers to complete their acceptance testing. This week, he said that he is at risk of missing his implementation deadline. Every week, it’s something else.”
“Are you upset about the way the information is being communicated?” I asked.
“I’m upset for two reasons,” Bill explained. “First, the sponsor and other manufacturing executives read those status reports. They’re getting nervous about our whole team’s ability to pull this off. Second, he’s the project manager. I expect him to take care of these matters and complete the project on time.”
I knew how I was going to respond, but before I could, Bill proceeded to express a classic management blunder.
“In fact,” Bill continued, “if he can’t keep this project running smoothly, I may have to replace him with someone who can.”
Mentor advice
This discussion was leading up to a classic mistake that far too many managers repeat. We implement status meetings and status reports on our project, but we only want people to tell us good news. I’ve known managers who have adopted that philosophy for interacting with subordinates. They only wanted to hear that the work was going to be done on time. They didn’t care how you did it or what problems you faced—just as long as you delivered on time.
There is merit in holding people accountable for their performance, but one of the major purposes of status reporting and status meetings is to manage expectations and to communicate the exceptions. From what I could see, Bill’s project manager was not doing anything wrong. Warning of a potential risk is absolutely a valid use of the status reporting process—even if the risk ultimately does not materialize. If he’s having trouble getting the users to complete their testing, he should raise the flag. If he’s at risk of going past his deadline, he should communicate it as soon as possible. The project manager should certainly be communicating these matters in the status reporting process, along with what is being done to remedy them.
Bill’s response to all of this is also puzzling. Status reporting was great on all the other projects, since they had few problems. However, now he’s talking about replacing the project manager who is reporting bad news. To a certain degree, he’s following the bad advice of the anonymous soul who said to “shoot the messenger.” Bill is not as upset about the underlying project problems as he is about the fact that they have been communicated.
My advice to Bill will be strong. The project manager may or may not have to be replaced. But Bill needs to base that decision on the project manager’s performance in managing the work—not because he is communicating problems. If the project is experiencing issues, such as identifying new risks or receiving major scope change requests, they should absolutely be communicated to both the program manager and the client sponsor. The reporting of bad news should be encouraged. And reporting bad news early gives you as much time as possible to resolve the matters. It also helps you manage expectations. Reporting bad news should not be a problem—but reporting surprises definitely is.