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.