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.

Customers aren’t paying you to work hard, they are paying to to add value and drive results

My husband and I hired a contractor about 18 months ago to install new siding and a new roof on our home. I wanted the siding done because I hated the original color, and I wanted something that looked more like shingles. So, the work was a “want,” not a “need.” The roof wasn’t urgent - it wasn't leaking, we didn’t have any issues with it, but we knew we only had a year or two left on it. So we decided to do it all at once.

We interviewed 3-4 contractors, checked references, and even did drive-bys on past work before we hired anyone. We felt we had done our homework and made a good choice.

Before the work was done, our new roof starting leaking into the bathroom. Every major rainstorm resulted in water in my linen closet. This problem was never solved by the contractor. About 2-3 months after the project was completed (less the leak in the bathroom that was still unresolved), a new leak formed in the den. This was a tough one since the den is on the first floor..there is another floor above it. My husband and I, not the contractor, identified the problem, but he did fix it.

Then about 18 months after the work was done (again, the leak in the bathroom still persisted), another, third leak formed in the kitchen. Again, my husband and I did some digging, pulling down sheet rock in the upstairs closet to expose the underside of the roof, and found the leak.

At this point we had had enough! We called the contractor and asked him to come out to the house, which he did. He was rightfully frustrated, but he wanted to get on the roof to take a look. We had other plans. We were fed up and concerned that there was a real possibility that there were all kinds of smaller leaks that had made it through the new roof that we had not seen yet. We were afraid that hiring this guy had increased our risk for things like mold and rot that would cost us thousands of dollars down the road. We simply wanted him to pay us our money back and let us hire a roofer to put on a new roof.

Strangely enough, he agreed to do so on the spot...no arguments. We were surprised but happy. There was a hitch, though...he didn't have the money. He had to pay us in installments. Knowing you can’t get blood from a stone, we agreed, but I was afraid that we could not start the work on the new roof until we had all the money, not because we needed the money, but because he would pull a fast one and stop paying us saying we violated the warranty or something once the new contractor started his work. So I called our attorney. On her advise, I wrote up a letter that spelled out the agreement. The letter would be signed by both parties and be certified by a Notary. The contractor agreed to go forward with the letter.

In the meantime, my husband was collecting bids from other contractors. Each stated that to do the work, part of the new siding had to come down. Fine...no problem, except that the siding is under warranty by the original contractor. The new contractors with whom we were talking are not siding guys, and I did not want to give the original guy any reason to not honor our warranty on the siding. So, I added a clause to the letter stipulating that the original contractor had to remove the siding temporarily and put it back up properly before and after the new roofer did his work.

Well, this new clause put the original guy over the edge. We met at the Notary to sign the letter, and I explained the new information I had and why I changed the letter. I asked him to read it before signing so that we could discuss any questions he had before we both signed. He reviewed the letter, but I’d be stretching the truth if I said we “discussed” anything. Instead, we stood on the sidewalk outside the Notary’s office making our cases “with raised voices” as to why the letter should or should not be signed as is. Ultimately, the letter did get signed just as I wrote it. What pushed this guy to my side, you ask? Easy, his closing argument for not signing went something like this:

“Andrea, do you not understand how hard my team and I worked. We are giving you back $6500 of hard earned money, and you want me to come back and help the other contractor do his job. He should hire someone to deal with the siding. We worked really hard.” said the contractor. (I’ll call him Joe.)

To which, I said, “Joe, first of all, if the other contractor hires a siding guy to handle it, that cost will get passed on to me. We are only in this situation because of the work you and your guys did. I understand you and your guys all 'worked hard,' but my husband and I did not pay you to work hard. We paid you to put on a roof that does not leak, and that did not happen. This is not about how hard you worked. Its about whether we got what we paid for, and we didn't.”

“Joe” looked stunned, frankly, but he quickly changed gears and agreed to sign. (We have a new, non-leaky roof, including in the bathroom issue, and we have received all of our money back from the first guy.)

I didn't share that story with you for therapeutic reasons, although that did feel very good. Thanks!! Rather, I share it with you because it is an appropriate story for any service provider, including consultants, to keep in mind. Our customers do not hire us to work hard. They hire us to make something happen, get something done, and, generally, add value. If you can work less hard and still meet their value needs, they see that as a win. Assuming a time and materials relationship, they get the value faster and at a lower cost.

As you work with your clients, it is important that you first understand what “value” means to the customer. This can be expressed as “success criteria” or “goals” as well. Then, you have to work with your client to define a plan to achieve those goals and deliver that value. Let’s face it, some of your ability to deliver is dependent on them, so they need to be part of the plan. Then, you need to work tirelessly to ensure that you are delivering that value...assuming it is in scope, of course.

Don’t fall in love with your ideas, don’t mistake hard work for value, and be sure wrap up every day knowing what value you added to your clients, to your firm, and to yourself.

If You Assume, You Don’t Know

When I was a kid, I watched an episode of The Odd Couple, the quirky sitcom about two divorced men living together in NYC. Felix is the neurotic neat-freak; Oscar is the lackadaisical slob. ("Can two divorced men share an apartment without driving each other crazy?”) There was an episode in which Felix was arrested for ticket scalping, when in fact, he was trying to give away the tickets. Felix decided to represent himself in court. He challenged the police officer who had arrested him and during the interrogation on the stand, the officer said something to the effect that he “assumed” that Felix was trying to sell the ticket. Felix proceeded to walk over to a flip chart and right the word “ASSUME” on the board. As he did so, he replied, to the officer, “Do you know what happens when you assume? You make an ass out of you and me.” Circling “Ass”, “U”, and “Me” as he spoke. Classic 1970s American TV moment!

How many times have you started to answer a question with, “Well, I assume…?” How many times have your assumptions been wrong? And when your assumptions have been wrong, what have been the implications been?

A lot is left unsaid, and it is those unsaid words, requirements, needs, etc. that are most likely to cause problems on your project. I try to remind myself, and my team, that if I am assuming, then I don’t know. If I don’t know...I need to ask.

Consulting and Consulting managers often times find themselves having to make assumptions in order to proceed with a scope of work or estimate. In many cases, the best you can do is provide the estimate based on a set of assumptions, and that is OK, so long as those assumptions are clearly documented and agreed upon with the customer. Clarity will come during the early stages of the engagement (requirements gathering), and if any assumptions are proven to be untrue at any point in the project, then the project manager will issue a change request (CR) to address the new assumptions, changes in scope, and, potentially, impact on cost and timelines. (The CR is any project manager's best friend, at least between normal business hours.) If you don’t have the assumptions documented and shared across teams, the “agreement” is left to interpretation, and scope creep, missed expectations, and customer dis-satisfaction are sure to ensue.

So what do you do when you realize that you are assuming and don’t know? Simple...you ask. It is important that you don’t delay. Challenging situations need to be addressed early and often, and it is best to not wait. The longer you delay, the harder it is to address. If you realize you are assuming an important detail (and those that may not seem so important right now) or don’t know for sure what is need, and you don’t tell your customer straight away, they may think that you are well on your way to addressing the pain, when in fact, you are not. When you come back to them days or weeks later for clarity, they will quickly realize (or assume) the lack of progress and get frustrated. Now you have two problems: You don’t have all the information you need to make progress, and your customer has lost some amount of trust that you will do what you say you are going to do.

Don’t assume, don’t delay, get the information you need...Now. You should have plenty of opportunity to do so if you are running your project correctly. All project details should be captured in a requirements document, including agreed upon assumptions, you should have a periodic (weekly) status report that documents progress, action items and dependencies, and issues and challenges (great place to capture a gap in your knowledge or apparent difference of understanding), as well as periodic (weekly) status meetings during which such details can be brought to the attention of all.

You will find some will be frustrated that “this is coming up now,” but the amount of frustration will be significantly less than the frustration that comes with a project missing a deadline, a budget, or the intended need.