16

Communicating Problems and Issues with the Sponsor

ONE OF THE most difficult tasks in project management has to be telling your sponsor about problems and/or issues related to the project. Whenever that happens, the palms of my hands become sweaty, and I breathe with faster, shallower breaths. However, I have learned that while you cannot change your body’s response to the situation, you can plan and act so that you can feel confident going into that situation.

Let’s start with a reminder from earlier in the book: Never let your sponsor be surprised by a problem or issue. There are political consequences to both of you if your sponsor does not know about a problem when another executive approaches him.

Predetermined Escalation Process

One of the best strategies for engaging your sponsor in problems is to have a set of predetermined steps in place to handle issues that cannot be resolved using consensus. It does not have to be complicated; in fact it should be fairly simple. It is much easier to get your sponsor and other senior management to agree to an escalation project at the beginning of the project. At that point, everyone is still looking forward to the wonderful benefits of the project, and the political aspects have been put aside for a while. And if you do not take the time to establish this at the beginning of the project, you may find yourself in the situation that a colleague of mine experienced during a difficult project.

Several years ago, a fellow project manager came to me for advice. He had a problem that had his project completely stalled and in danger of failing if he could not resolve it. In simple terms, he had a technical issue that affected two key stakeholder groups. However, they could not or would not agree on a solution. When I asked the project manager how he was attempting to resolve this problem, he said through meetings with the key stakeholders. I asked him how many meetings he had conducted to resolve the issue, and he responded that he had already had eight meetings with no resolution. Seriously, eight meetings! When I asked him about getting his sponsor involved, he responded that he did not really know how. In the meantime, his project was in a death spiral.

As a rule of thumb, I set a ground rule for my projects that we will have three meetings to discuss an issue or problem. If we have not solved it, the problem will be escalated to the sponsor. I recommend that you suggest an escalation process right at the beginning of the project and get your sponsor to agree.

My escalation process usually consists of four steps:

1.“We know there is a problem and have a plan to fix it.”

2.“The project team is working on plan B to keep the project on schedule if possible.”

3.“I will keep you informed on progress, and you will not be left in the dark should you be asked a question about the problem.”

4.“I need your support while we fix the problem.”

Finally, if I need to get the sponsor involved in solving the problem, then I will provide her with an overview that:

Defines the problem from each stakeholder’s point of view.

Identifies the option that each stakeholder sees as the solution and the risks associated with that option.

Includes input and/or recommendations from the project team.

Also, if the sponsor needs to discuss the problem with other senior managers, I will work to help build the message. My goal is to keep the message balanced and as positive as possible.

Probably the most important aspect of handing off an issue to the sponsor is to alert her if an answer or decision is time sensitive. Despite what you might think, the wheels of decision making grind slowly in most companies. I remember a project where my sponsor had to get the decision blessed by the CEO before we could act. You would think that a CEO could make a decision, and we could move on. However, it took the CEO three months to finally provide an answer to my sponsor! As you can easily imagine, that amount of time pushed the project timeline considerably. However, because my sponsor understood the effect on the schedule, he was able to deflect any criticism of the project’s delay with a politically acceptable response.

Using a Root Cause Analysis to Explain the Issue or Problem

In working with your sponsor on issues or problems that have occurred, I have found it very important to conduct a root cause analysis as part of preparing to address the issue. My rationale for that is simple—symptoms!

Figure 16.1: Sample Root Cause Analysis

Due to the perspective of stakeholders (often based on their functional roles), they are often reacting to symptoms of the problem. It is very hard to develop consensus if people perceive the problem differently. One of the very useful tools in root cause analysis is the use of the fishbone diagram (also referred to as a cause-and-effect diagram).

Figure 16.1 demonstrates a root cause analysis we did on a project where the team was building models and transferring them into the maintenance system of the vessel. When the client reviewed the models after the transfer, parts or sometimes sections were missing. The resultant rework was causing some delays. However, if the issue was something other than human error, getting the modelers to rework was not going to solve the problem.

In reviewing the problem/issue, it is important to recognize what is being affected. There needs to be a general recognition of four types of issues/problems:

1.Performance (operational)

2.Positioning (strategic)

3.Visible (aligned to results)

4.Invisible (aligned to impact)

You want to be able to describe the event or occurrence using facts, including any data related to the failure. Gather data and create a timeline of events leading to the failure, if possible. Determine how frequently the failure event has occurred and specifically which business process was affected. Finally, identify the exact time and location of the failure event as part of the data gathering.

It is important to ask why at each step and determine what may have caused that step. Then you are ready to create your fishbone diagram.

The fishbone diagram is used in several industries in the attempt to solve problems, prevent accidents, or control quality. The primary goal is to identify factors and outcomes in order to identify which actions or conditions need to be changed to prevent a similar occurrence.

The sponsor may need this background information if another executive complains that an issue is not being handled properly. Often the complaining executive’s opinion is based on data given to them by one of their trusted lieutenants. This is where perspective collides with the politics in the organization. Your sponsor will have your background material, which allows him to support the project team with hard data and analysis. That type of information is difficult to refute.

In my experience, root cause analysis has also uncovered problems that are outside the scope of the project. Many of my projects were systems projects, and one of the things I discovered is that system projects often uncover bad business practices. With data you have collected, you can make the case that your sponsor has a few options:

1.Hand off the issue to a working group completely separate from the project.

2.Turn the issue over to another executive where it might be more appropriately handled.

3.Expand the scope of your project to include a correction of the bad business practice.

My experience has been that sponsors generally choose option 1 if the issue is within their span of control or option 2 if it must be corrected elsewhere. Rarely do they chose an option that increases the time and budget requirements of the project (option 3).

Building Consensus

If your project schedule will permit, you should attempt to build consensus when problems or issues cross functional lines.

Consensus is the general agreement among stakeholders in which each exercises some discretion in the decisions and follow-up actions. Consensus usually involves collaboration rather than compromise.

In trying to build consensus, invite the key stakeholders to participate in the process. There are two key success factors to arrive at consensus, and they will be important to your sponsor and other key executives.

First, ask all who are working on the issue to understand the concerns that each group has. Too often, in my experience, people are prone to jump right into debating the solution. Another reason to seek understanding first is related to symptoms versus the root cause of the problem. Over my years of working with projects, the reason stakeholders disagree on a solution is because they do not have a common definition of it. They are actually describing symptoms that they observe because of where they interact with a workflow or process.

After seeking to understand the concerns of each stakeholder group, the next step is to find a common definition for the problem or issue. The reality is that if there is no common definition, there can be no real solution.

When you have followed these steps, most of the time you will arrive at a solution. This will be very important to your sponsor and other senior managers because you have demonstrated that the people who report to them provided input to the solution. As a result, whatever the solution, it will be supported much more enthusiastically. Plus your sponsor has the ammunition required to show how in control he is and how professionally the project is being managed.

However, there will be times when you cannot reach consensus no matter how hard you try. That is when the predetermined escalation process needs to be utilized.

Determining the Corrective Action

Once you have identified the root cause, you must determine the effort required to complete the priority actions. It will be important that your sponsor is at least aware of the issue in case they are questioned by another executive who is aware of it. Normally, I would share the following information with my sponsor:

Identification of the individual(s) who will be responsible for the corrective actions

Adjustments in effort required to fix the issue

Effects of the actions on the schedule for the project

Remember the goal is to give the sponsor confidence that the project is under control and being managed carefully. He may never need the data from the root cause analysis or the specifics of the remediation actions, but it is far better for him than not having it if questioned by his boss or one of his peers. He wants to be able to confidently answer that he has the information, and if the colleague wants to sit down and review the data in detail, all that is required is to check their calendars and schedule the meeting.

Points to Remember

Have a predetermined escalation plan.

Use root cause analysis.

Build consensus for a solution.

Determine and sell the corrective action.