Tell Them What They Need to Hear, Not What They Want to Hear...Diplomatically

I don’t espouse the concept “the customer is always right.” Let’s face it, customers are humans and no human is always right. Additionally, customers hire us because they know they are not the experts in the area where they need help. You, the consultant, are the expert. By design, you know more about the subject matter than they, have seen numerous situations similar to what they are experiencing, and have the battle scars to help them through this challenging time.

With that said, it is not your job to tell them what to do or to push them to do what you want them to do. As Peter Block wrote in his book, Flawless Consulting, your job as a consultant is to help the customer “ask and answer” his own questions. So, first, you need to work very hard to understand this customer’s political, economic, technical, and environmental situation. You then need to understand the current state of the challenge at hand, including what they have already tried to do to resolve the issue. You also need to determine their desired future state...what does success look like for them?

This isn’t easy to do. Often times, the customer has a vision for how they want to solve the problem. They may want to rely on you to implement the solution and worry less about whether you have a perspective to bring to the table that may present a better solution.

In the past, I have had to discuss risky decisions that put my company or my customer’s company in unacceptable levels of risk, concerns with scope changes that may affect project timelines and budgets, and process and standard operating procedures (SOPs) that are making the work harder to complete than it should be. In most cases, when I have approached the customer, making it clear why I could not do what they asked but provided alternatives that either solved the same problem or came close, I ended up with a happy customer. Sure, I may have caused some amount of grief initially when I explained the concerns and challenges with their request, but they soon forgot that when I delivered on my promise of what I could do.

A few years ago, I was managing a consulting team that worked on ongoing projects for our customers. We had a project manager (PM) change on our side. The project was well underway, certain SOPs were in place, and the customer had well engrained expectations for how things would work. They had extremely high expectations with regard to turn around times on certain pieces of work, and timeliness and quality could not be sacrificed.

My new PM identified a serious policy violation in one of the SOPs employed by our team and the customer. He knew we were handling a key aspect of the project in a dangerous way, but he felt the customer’s PM had provided instruction and we had to “trust” that their PM new what he was doing.

It didn’t take long for our customer’s management team to learn about the SOP, and when they did, their PM and we were in a lot of trouble. The management team felt exactly as my PM did – this is wrong and we have to stop now. The only difference was that they said something. Additionally, while both parties, their PM and our team can share the blame for letting this SOP stand, our customer’s management team held us MORE accountable. Why? We are the experts. They hired us to do this right, and we let a poor practice stand. They were right. We should have had the courage to discuss our concerns about the practice with the customer’s PM and, if he didn’t agree to a change, let that PM know that we had to escalate because of the seriousness of the risk we saw in the practice.

Back when I was a PM implementing software solutions, it was not uncommon for a customer to request a change that was difficult or costly to implement. It was my job to ensure we understood the need, why the customer was asking for the change, and the specifics of the change. It was also my job to work with my project team to understand the implications of the change: What is the technical solution? Do we have all of the information we need? Does the requirement conflict with any other requirements already in play? What is the level of effort required? Will we stay within the customer’s budget or meet their launch date if we move forward with the change? If the answers to these questions are negative, it was then my job to have a heart-to-heart with the customer. If, for instance, this new request conflicts with the project charter or other requirements to which we have already agreed, we need to discuss the impact on the overall project and whether this change will fundamentally change the objective and outcomes? We may need to call on our executive sponsors to make the ultimate decision as to how to move forward, and for some stakeholders, our suggestion to call in the sponsor may not be seen as “working with” them as a team. It can get sticky pretty quickly…”You want to go over my head?” Well, yes, as a matter of fact we do. How you do it requires tact and probably support from senior members of your team.

If the new requirement does not create a conflict with the charter, but does introduce significant rework, many man hours of new development, and/or put the project budget or schedule at risk, you need to have that conversation, too. Notice, in neither scenario am I suggesting you say “no” to your customer. Rather, you must be clear what the implications of the change is and let them decide. If this change is critical and getting it in is more important that the budget or schedule, they will sign your Change Request (CR) and you will get what you need to move forward.

In another example, I worked with a customer a few years back who insist in implementing a custom process to manage the workflow for a key part of the program managed by my services teams. While there are times when a custom workflow is necessary, this custom request not only added no additional value, it created significantly more work to implement and maintain than our standard process used by countless other customers. The custom process introduced too many opportunities for human error that caused us and the customer pain. We struggled to identify a way to illustrate to the customer why this process was flawed. We were not able to be clear with regard to the pros and cons of the process. We needed to do a better job to help the customer understand and acknowledge the risk he is introducing. I often wonder if the team has ever been able to tell the customer what they needed to hear and implemented a solution that recognized the clients situation as well as what we knew to be best practices.