19
Getting Help with Cross-Functional Issues
GETTING THE SPONSOR to help with cross-functional issues is very important. As a project manager, you will often bring stakeholders together to discuss issues, problems, and content. The sponsor can be a tremendous help when you are unable to resolve the issues and various stakeholders are taking different positions. In my years, these can become very emotional and entangled in the personal relationships of certain individuals, making them even more difficult to solve.
In looking at the way a project manager and the executive sponsor can work together on these issues, I want to remind you of the two critical principles that already were covered in earlier chapters:
1.Never surprise your sponsor.
2.Have a predetermined escalation process in place from the beginning (see Chapter 16).
Your sponsor will be aware that cross-functional issues are a place where she must step in. However, she will need your help to work on the problem and get you the answer that you require. I always let my sponsor know about cross-functional issues if it will require more than one meeting to resolve—which is most of them. At the beginning, I will just give the sponsor a high-level overview of the issue and the strategy for solving it. I will also let the sponsor know of progress in resolving the issue. I will not dump the problem in her lap until I and my team have really tried and failed to gain consensus.
One of the lessons learned over the years in these situations is that the disagreement often comes because the warring stakeholders are not actually defining the problem the same way. Therefore, they will come to different conclusions as to how to solve it. The root cause of this situation has actually eluded the stakeholders; that is, each side is really describing symptoms they see from their perspective. I share that learning with the sponsor so she recognizes that I am seeking the root cause. I want to make certain that if executives from these functional groups bring pressure to implement the solution from their team, the sponsor has a socially acceptable way to deflect the pressure. Few executives will object to a root cause analysis; they just want to be able to tell their constituents they have gone to bat for them and a solution is coming.
Uncovering Stakeholder Perspective
So the first task is to gather data from everyone’s perspective. I am trying to gather a timeline of events because I may need to review this with the sponsor to explain the issue. The data I am looking for is:
Define which part of the business process was affected.
From each stakeholder group, when does that problem seem to occur?
How frequently has the failure event occurred?
If possible, identify the exact time and/or location of the failure event.
To make this process work most effectively, I ask my sponsor’s blessing to create a working group that represents all the functional areas affected by the problem. This working group is tasked to review the data and identify each potential cause of the problem and what may have brought it about. I often ask that the working group not be people already on the Working Committee for the project. I am seeking a recommendation from the working group to the Working Committee. In these circumstances, I want the Working Committee making the decision on the recommendation, not the project. As already mentioned, pulling time away from the day job is hard enough on the Working Committee without adding the burden of a problem analysis and recommendation on top of everything else. However, I need my sponsor to approve that strategy and agree to support it.
Obviously the primary goal is to identify factors and outcomes in order to solve the problem. However, there is another motive in approaching it this way: I am getting the stakeholders to focus on solving the problem rather than “winning.” Once the situation devolves into a contest, you are putting your sponsor in a difficult situation. Plus, I now have substantial data that I can provide the sponsor if she must approach one or more of her peers to negotiate a solution.
One danger in this process is to think, at the outset, that you already know the root cause. If you start from that assumption, it will bias your investigation and cause you to steer toward your preconceived answer.
If the stakeholders review the root cause analysis and agree to our solution to the problem, the project moves on.
On the other hand, if consensus is not achieved, then I must get the sponsor involved. Because I have been keeping her informed as we attempt to achieve a solution, she is usually not surprised if a stalemate occurs. And that is exactly what I was trying to achieve so that she would not be surprised.
Escalating to Achieve a Resolution
If the cross-functional problem cannot be solved using the process just described, then the issue will have to escalate to the sponsor and other executives who represent the functional groups involved.
In this situation, there are at least two competing solutions and oftentimes more than two. In that case, the project team will have to put together a decision support package for the executives to use to make a decision.
Start with the Purpose of the Decision
You need to clarify the purpose of the decision you need from these executives, starting with the common definition of the problem. The decision should reflect the Business Case or goal that allowed the project to be sanctioned in the first place.
Options Considered
In this step, you want to give the executives a high-level overview of the options considered by the working group and the project team. Also, the risks and benefits for each option should be presented with the assurance of the business integrity of each of those options. Obviously, you should have substantial data to support each option. That will probably include:
Reports.
Any other relevant facts and figures.
All the source data collected during the root cause analysis and any other follow-on work should also be available to these executives if they want it.
Finally, you should provide an impact assessment for each option on the schedule, budget, scope, and quality of the project.
Time Sensitivity
Unfortunately, these types of decisions rarely happen quickly in my experience. You should attempt to keep the project on schedule as much as possible, but you must give your sponsor an assessment on the impact to the project if the project takes longer than your ability to juggle will allow. Again, do not surprise them. Have this information at the same time you begin this process.
To that end, I would recommend that your decision support package be delivered to the executives in advance of any meetings to discuss the issues. While it is my experience that they often do not look at the materials until about 20 minutes before the meeting, that should not discourage you from providing it anyway. Often executives travel to other sites as part of their responsibilities, and that may give them the opportunity to do a more thorough job of review than otherwise. I have also had an executive hand off the information to a trusted lieutenant to review in advance of the meeting. The executive will ask for their opinion and ideas.
Presenting the Information
Most of the time, the meeting includes the executives who are responsible for the various functional groups. If that is the case, you will want to plan carefully with your sponsor on the approach to the meeting. You should be interested in knowing the exact role you are expected to play in the meeting. For example, are you:
Presenting and defending the materials?
Supporting your sponsor, who will present the materials?
Supplying answers to questions that come up?
Also, be clear with your sponsor about the goal of the meeting. Are you there to just share information, or are you trying to motivate them to act in some way?
Also review the information on listening styles from Chapter 7 to assess who uses which style in most cases. If you are not certain, review the listening styles with your sponsor and get her opinion.
Handling Questions
When you work with executives and they ask you questions, the first thing you must do is understand the type of question because it will influence the way you answer. Let me explain in more detail:
Direct question: This is probably the type of question you most often think of. They are simply asking you for information, and they expect information or data in return.
Summary question: This question often begins with a phrase like, “Are you saying?” In this case, they are putting what they hear in their own words and seeking clarification that they are hearing you correctly.
Logic question: This question is challenging the logic of the facts and/or conclusions in the presentation or supporting materials. Basically what they are saying is that it does not add up to them. Resist the urge to become persuasive in answering this type of question. Simply lay out the facts as you see them. You will need to rely on your experience, tied to the facts, to explain your rationale for your answering the question.
Me question: This type of question generally centers on the personal experience of the executive. For example, they say, “We tried that solution in our group before, and it didn’t work.” Again, resist the temptation to challenge someone’s experience—you cannot. People’s experience is their experience. Instead, focus on your experience or the experience of certain subject matter experts who may have had a different experience to explain the recommendation or process. Just as you cannot challenge their experience, they really cannot challenge your experience either.
Paraphrase if necessary: If you are not certain, use the technique of paraphrasing for clarity. Put the question into your own words, and they will tell you whether you are correct, or they will provide additional information for any part they believe you have misunderstood.
To recap, first be certain to assess the type of question you are hearing, and then respond in the appropriate way. If you answer a direct question with a personal experience answer, the impression you leave with the executive is that you are either avoiding the answer or do not know the answer. If you handle the questions correctly, you will have left a very positive impression on the executives you are working with.
Finally, one of the most difficult questions will begin with “why.” “Why do you believe this?” “Why did you assess the risks in that particular way?” For these types of questions, I have utilized a simple acronym to help me answer: REP:
Reason or rationale for answering the why question
Example or evidence that supports the reason
Point that is your logical conclusion
When you finish your answer, confirm that the person who asked it feels you have responded. Realize he may not agree with your reason or example, but you have given an answer he can consider.
To review, these are the points to remember in getting help from your sponsor in dealing with cross-functional issues or problems.
Use the technique of root cause analysis to help define the problem and gather the data.
Ensure that there is clarity about the purpose of the decision that must be made.
Review all the options considered and who worked on assessing the options.
Make the executives aware of the time sensitivity in an attempt to create a sense of urgency.
Plan with your sponsor who and how the information will be presented.
Handle questions effectively by first assessing the type of question before answering.
Points to Remember
Use root cause analysis.
Use the escalation process to achieve resolution.
Be sure to let your sponsor know about any time sensitivity.
Prepare to present the information carefully.
Provide answers based on the type of question asked.
