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.

Don’t Say “Yes”...Yet (or “No” for That Matter)

One of the hardest things to do with a customer is to deliver bad news, and saying that you can’t do something for which they have asked, at least not in the current scope of work,  is often viewed as a form of delivering bad news.

The pressure to be seen as working on behalf of the customer, to recognize their needs and help them address them quickly and with precision, often sends consultants down a path of scope creep that, in the end, causes more harm than good. Learning how to strike the right balance takes experience, and a few missteps, to get right.

It is natural to want to be viewed as helpful and as an expert who can ease the pain. All too often, though, we say "yes" before we really understand the need or requirements. The result is a premature commitment and the customer may have one view of what was committed, whhile we have another. We may, for instance think that what is needed is a few minutes of work that we can simply slip in. After we jump in - already having made the commitment, we find out that this commitment is a major engineering effort that will take months and multiple resources and teams to pull off. While pushing back initially may have been a little painful, pushing back now is virtually impossible.

Years ago, I was working for a SaaS company running consulting services. By design, the Services team did not implement software and we did not have developers on staff. We had technical consultants and analysts, but not developers. While visiting one of our largest clients, our CEO agreed to having Services build a “custom report” at no cost to the customer. His motivation was logical - we had a large expansion contract on the table, and he wanted them to sign quickly. He felt he could use this custom report request as a “give/get” - give them their custom report, get the large contracted we needed to make our numbers.

The problem was, as smart as our CEO was - one of the best with whom I have ever had the chance to work - he did not really understand the requirements. As services dug in, we quickly learned that the request was not a customer report (think 2 dimensional), it was a custom application (think 3 dimensional). As an experience project manager in the software development world, it took me one, one-hour meeting with the client to know that the customer was not looking for a report that we could implement in a couple of days, but rather an application that would require months to develop and that we did not have a team with the skills to do the work.

At that point, though, the train had left the station, and we had to figure it out. It took us 4 months with 1.5 FTEs. Since the customer was promised something in a couple of weeks, they were not at all happy with the delays, and in the end, what we delivered was only a portion of what they needed.

We can’t always protect ourselves against situations where sales or executives make ill-informed promises on our behalf, and we have to pick up the pieces. It happens and will happen in every organization. We can, however, protect ourselves against doing the very same thing to ourselves. So what do you do when a customer asks for something that is not in scope or is otherwise unique, big, hard, unclear, or has never been done before?

First, you make sure that you understand in detail the pain the customer is trying to solve. Without knowing the pain - the problem - you are not going to be able to assess the requirements’ ability to meet the customer need and, potentially, provide alternative solutions. You won’t be able to look, for instance, at the long list of existing requests for enhancements (RFEs) in the product management/engineering queue to see if there is something similar that will address the pain, even if it is not precisely what the customer is requesting.

I don’t at all mean to be disrespectful to my clients, but sometimes what they ask for initially and what they really want or need are not the same. Understanding the "why" behind the request is a critical first step.

Next, capture as much of the requirements (the what) as you can. This allows you to 1) understand how the client thinks about solving the problem and 2) ensure that your client feels listened to. Document the requirements and send to the client for review and confirmation...include the problem statement in the requirements.

Lastly, avoid brainstorming on options at this time and do not, and I mean not ever, commit to doing the work in the initial discussions. Don’t say no either. Its too soon. Brainstorming too soon can lead to a perceived commitment without intention or may set expectations that you have to change - painfully - down the road. At the end of the day, anything is possible. It depends on how much time and money you have, but anything is possible. Your job initially is to collect information and confirm with the client that you understand both in terms of the request and the reason behind the request.

Now what - the client needs help and wants an answer now, right?

Its simple, let the customer know that there are a few folks with whom you need to review the requirements to understand what options we have, what is feasible, and how to proceed. Don’t commit to anything (yeah or nah) other than when you will get back to them and with what. Once you are off the call or out of the meeting, you then need to engage with the right people and departments to assess the request, determine what is feasible, and develop options for the client to consider. For instance:

1. Is there an existing RFE that meets most of the highest priority requirements? Is the client willing to go with that solution knowing they may have to wait a bit, it may not address all of their requirements, but it won’t cost them any additional money?
2. Is there a smaller custom solution that we can implement now at little or no cost, maybe to earn back some good will, that they can accept?
3. Is there a larger, custom piece of services work required that will cost them some additional money but meets all of their requirements?

Remember, your job is not to be a “yes man” (or woman) and you don’t want to be perceived as simply saying “no.” Your job is to understand the pain/need and present a number of options for the customer for them to consider, involving them in the final decision but helping them see the pros and cons of each option. Digging into options before you know what is feasible can create pain, so focus first on understanding the problem, then come back to them a few hours or days later to discuss alternatives.

I'm Back!

I have been feeling a little less than inspired in the last couple of years. Well, that isn't really a true statement. In reality, I took on a new role with a new company in the fall of 2012. So, as you can imagine, I have been drinking by the fire hydrant getting familiar with a new company, team, industry, and customer base.

I have been in the role for about 15-16 months, and I am feeling inspired now. My focus is a bit different than my previous focus. I wrote a lot about building and running an effective PSO in 2011 and 2012. While that is still a very interesting topic for me, one about which I am passionate, my current focus is helping those around me to be the best consultants they can be. So over the coming months, I plan to post some "Andrea-isms," what they mean to me and how an up-and-coming consultant should think about developing as a world-class consultant.

I hope you will find this series helpful, and I look forward to your comments. My first post in this serious is on its way.