Management Skills:Bearing Bad News

Bearing Bad News

The worst has happened. The slippage you thought could not occur, did. The overrun you promised would be contained, wasn't. The risk that could not arise, did. You must now report to your management and the client that all is not well and that you need more money, time, and resources. How can you present the bad news without losing your job or, at the least, being made to feel like a schoolchild who has not done last week's assignment?

Because projects are replete with unwelcome, unplanned events, bearing bad news is a job requirement for project managers. All projects, even those that are wildly successful, are replete with replanning, backtracking, and much fancy footwork.

What makes bearing bad news difficult is a sense of personal responsibility. Which would you rather report: that the project will be two months late because the clerical staff is on strike and your people will not cross the picket line, or that the project will be one week late because one of the development activities has slipped? You would probably prefer the first. After all, you have no control over strikes, but the schedule was your responsibility. If it slipped, you messed up.

Responsibility is frequently confused with blame, leading to the notion that because you are responsible, problems are your fault. If you believe this, you will be more concerned with self-protection than with solutions, and your demeanor will destroy your effectiveness in presenting the problem. The first prerequisite for bearing bad news, therefore, is to differentiate between responsibility and blame.

Sometimes the distinction is not obvious; it does not seem unreasonable to say, "I was responsible. I accept the blame." Yet, except for those instances where you really did mess up, accepting the blame is unproductive, improper, and wrong.

Consider an example. You have just learned that Mary, one of your key resources, whose skills are unique within the company and who is essential to your project's success, has been severely injured in a traffic accident. You have been concerned about your exposure with Mary as your only expert, so you have had her train others, but their skills are still rudimentary and they will not be able to finish her work on schedule. Furthermore, if they take over Mary's work, they will no longer be available for their own. As you review the situation, you conclude that the project will suffer a delay of about one month.

Is this your fault? Are you to blame for Mary's accident? Given that you attempted to backstop her, are you even to blame for the project's predicament? Of course you are not to blame. But you are responsible. You are responsible for solving the problem and, to the extent possible, getting the project back on track. While it would be unreasonable for your management to blame you for the situation, it is their right to expect you to find the best solution.

"Well," you may object, "in that example, assigning blame is ridiculous, but what about more normal problems like a schedule slippage? If I am responsible for the schedule, am I not at fault if it slips?" No. You were responsible for gathering estimates and assigning people to activities, but to say that the slippage is your fault is to claim that you are to blame for faulty estimates or underperforming staff. While good project managers challenge estimates or extract commitments from their people, it is a massive conceit to assume that you can control them so that they will never err. Just as you are not to blame for the traffic accident that sidelined Mary, neither are you to blame for schedule slippages that you took all reasonable steps to avoid.

The difference between responsibility and blame is the timeline. Blame lies in the past, responsibility in the future. Blame asks, "Who did this?" Responsibility asks, "How do we fix it?" Blame says, "You are unworthy." Responsibility says, "Let's get on with it." Those who fully accept responsibility are too busy to accept blame.

Without the pall of blame, bearing bad news becomes easier. There are three strategies that will make you even more effective in presenting problems: Lay the groundwork, plan the response, and involve management in the solution.

Laying the groundwork means that you set realistic expectations and that you alert management of potential problems. Setting realistic expectations is part of responsibility. If you assured your management that absolutely there would be no problems and you must now report a schedule slippage, your fall from grace is a direct result of irresponsibility: You made commitments that you could not keep. The responsible answer when you are asked for a commitment is that you will do your best but that you cannot give any guarantees. This is not setting up an expectation of failure, it is insisting that reality accompany the commitments you make.

Alerting management of potential problems means keeping them apprised of your concerns. If, early in the project, you report that you doubt the validity of one set of estimates, and if you periodically confirm your suspicions as the project progresses, you are doing three things: soliciting assistance in solving a potential problem, preparing your management for the bad news if it materializes, and making your concern a management problem. The normal impulse is to hide emerging issues in the hope that you can solve them or that they will go away. Resist the impulse. If you do solve the problem, you can let management know how great you are. If you do not, at least they will have been forewarned so that when you present the bad news, they will not be surprised.

The second bad news strategy is to plan a response to the problem. If you simply inform your management that the project has slipped, you will deserve their wrath. As project manager, you are more than a courier. If, however, you tell them of the slippage, let them know the impact, describe what you are doing about it, and solicit their advice and assistance, then you are practicing responsibility; you are in control of the situation and not merely reporting it.

The final strategy is to involve management in the solution. There are two reasons for this: They will probably be able to take action you cannot, and the more focused they are on solving the problem, the less they will be concerned about blame.

The first two strategies, laying the groundwork and planning a response, are central in keeping your management up to date. But involving management is more than a tactic. You want to involve them because they are a resource that can help the project succeed. Conscientious managers want to help and are willing to contribute their experience and position. Conscientious project managers use whatever resources are available.

Comments

Popular posts from this blog

The Conversion Cycle:The Traditional Manufacturing Environment

The Revenue Cycle:Manual Systems

HIPO (hierarchy plus input-process-output)