Any company offering consulting and advising to an outside organization should be focused on delivering the best possible solutions. To that end, managing client expectations presents moments when the consultant should exercise their expertise to inform the client that what they are asking for is not in their best interest. In other words, sometimes you just have to say “no”.
To define the problem a little more clearly, we need to look at why organizations hire outside consultants in the first place. Naturally, there are many reasons that a company would need help. Regardless of what those reasons are, they hire a specific consultant because they believe that organization has the resources and expertise to accomplish their goals. That belief in the consultant’s expertise implies trust: a trust that the consultant can understand the business problems and offer a solution that accomplishes the company’s goals. At appendTo we confirm that trust up front when we set the expectations for the project (I’ll touch more on that in a bit). If we, as consultants, deliver a solution which does not serve our client to the best of our ability then we have failed.
Saying “no” to a client is not easy. There are plenty of pitfalls, not the least of which is that a client may not want to hear those words. In this article I’m going to talk about how we set up an environment in which saying “no” is possible, and how we make sure our clients appreciate it.
Setting Roles and Ownership
One of the first tasks we tackle at appendTo with a new client is identifying the roles on both sides for that project. This may seem obvious, but it is important to be sure that not only are the specific people and their titles identified, but also what role they are performing in this specific project. Who owns the product? Who can make design decisions? Who makes technical direction choices?
Just as important as identifying the key roles for the client are those for the consultants. Most of our projects involve multiple people in development, project management, and administrative roles. Making sure the client knows who is making decisions on our end and who they should contact for specific concerns is vital to the project’s success. And more importantly for this article, it is vital to negotiating those aspects of the project that we feel need to be changed. For example, we want our clients to know who will be suggesting framework changes (the project technical lead) or a new communication strategy (the engagement manager).
It is not our policy to allow anyone on our project team to simply tell the client “no”, in fact, saying “no” always comes with additional options and information (see “Discussing the Options” later). On the contrary, there is a dynamic that emerges between the project lead, engagement manager, development team members, and the executive team. I discuss this support network in a later section, but what is most important here is that there are defined roles which relate to “ownership” over certain aspects of the project. This does not mean that people act independently, it means that both the client and the internal team understand who is ultimately responsible for certain decisions.
Understanding the Business Domain
Before ever saying “no” we always strive to understand why a particular direction, decision, or tool is important to the client. Simply stating that a client should use jQuery without understanding why they’ve implemented a native DOM selection tool could miss the point. Part of a consultant’s expertise should be the ability to evaluate an existing implementation and understand why it was implemented in that manner originally.
This investigation often entails questioning the client on ancient history (relatively) that few people recall. That in itself can aid in the argument for saying “no”. If there isn’t a single person that the company that understands why a particular tool was used, and there is substantial evidence that changing could improve the technical landscape, then saying “no” to those tool updates will be much easier.
As an added benefit, having the client aid in this discovery could help them realize that a new direction is warranted and worth the effort. In many cases this negates the need to say “no” at all. Ultimately the choice to go in a new direction will always be up to the client, but having them steer that conversation can make the process much less painful to both parties.
With the proper roles identified and ownership (and responsibility) established it is easy to identify who is going to be making decisions on both sides of the table, and who would be in the position to make the “saying no” call. That is, it is clear who will be the one to make the argument, but that person needs support. And while moral support is great, we’re talking about factual, technical, and administrative support.
First of all, there needs to be general support from the executive team at an organization to allow their people to exercise their expertise. The understanding by project leads and engagement managers that they are empowered to advise clients not only on what _can_ be done, but also what _should_ be done is imperative. It opens the thought processes of all team members and allows for the free exchange of ideas, even those that may stray from the norm. In fact, this sentiment goes beyond the exectuve team. Project leads should encourage discussion on difficult topics and welcome new ideas. The larger the support network, the more credence a new idea will have.
Beyond support of the decision by the team, there must be facts to back up a “no”. Simply telling a client you won’t do something is grossly insufficient. Present them with an analysis of the decision. Why is tool X preferred? Is there better community support? Is it less expensive? Will there be efficiency gains? Take the time to flesh out the details of the change as well. Will this require additional up front costs? If so, will they be gained in maintenance? To what degree?
Different people will respond to different data and different arguments, so instead of focusing on one piece of information that the team feels is important, present the client with an abundance of data that itself argues the decision. Remember that the client hired a consultant for their expertise. If that experience and knowledge is demonstrated well they will respond to it in kind.
Discussing the Options
After getting this far in the article, it is probably evident that we don’t just say “no” to a client and leave it at that. When a situation arises that requires us to advise a client against their current course of action, we attempt to understand the problem from their point of view, gather supporting arguments and data on our end, and eventually present the client with our position. But our position is rarely static.
When we do suggest a change in direction, we like to present the client with our arguments and then a limited set of options. One of those options will almost always be the status quo or the client’s already-chosen direction (the one we’re trying to say “no” to). Presenting their current direction as a choice also involves identifying the risks involved, including any potential financial implications in terms of development, support, and maintenance.
In addition to the status quo and the expert’s recommendation it is important to identify a third option in most cases. If we take the example of a custom-built library (the status quo) and the suggestion that it be replaced with an open source alternative, we may offer the suggestion of refactoring the custom code to be a plugin/extension/etc to the open source library. This offers the possibility to continue using the custom code in legacy modules while affording the benefits of the separately maintained OSS module. Of course, it is still important to identify the costs and risks of such a move, which will vary greatly from project to project.
This entire discussion is focused around setting appropriate expectations and then exceeding them. If a client has the expectation that the consulting firm they hired will provide expert advice and help guide them to a better solution then hearing “no” will not be a shock, it will be welcome. The goal should always be to form a partnership with the client which benefits both parties. Such a partnership can only succeed if there is trust, and part of that trust is managing expectations.
This is not the same concept as under-promising and over-delivering. On the contrary, we promise exactly what we expect to deliver. We deliver on what we promise, and we manage that expectation appropriately. Our agile process then allows us to change course if necessary, re-evaluating expectations, and still delivering above our client’s expectations. Saying “no” is just one of the many ways that we manage these expectations and ensure that our clients are delivered the best possible solution.