In my books, articles, and seminars, I talk a lot about how clients must take ownership of the solutions that we, their consultants, propose. I emphasize repeatedly the risks of allowing clients to "throw projects over the wall" to us, thus abdicating responsibility for the results.
In this column, I'll explain the "throw projects over the wall" theory and make a case for why consultants should position the client to make choices and decisions.
Empowering clients to make choices
In my consulting practice, one trend is clear: Clients want you to tell them what to do. They yearn for the consultant to deliver a solution, which they can then tweak, paint with their team colors, and roll out seamlessly. The typical client's desire for a preconceived solution is really reflective of the trend in purchasing in which the convenience factor drives buying decisions. The riskier the purchase, the more the client craves a packaged, proven, all-in-one solution. In IT and consulting no less, clients want to select, and perhaps integrate, an existing solution, not build one. And they want their consultant to select it for them.
In my engagements, I do all the research and then prepare a presentation of the options that could solve the client's problem. I present pros and cons, talk about the implications of one decision versus another, and help the client walk through different scenarios. Ultimately, however, the choice must be the client's. I usually don't even make recommendations because even that simple act can provide the opportunity for a client to say, "This was the consultant's idea!" as soon as problems or conflicts arise. And arise they do, even on the most worthy and well-run projects.
But clients resist this approach. Clients often come into engagements expecting the consultant to give them the answer, rather than work with them to discover the right answer for the circumstances. Is it a good idea to present options, knowing that the client is probably expecting recommendations instead? On the other hand, is it prudent to present recommendations if there really is no one perfect answer, just an answer that fits the culture, organization, and situation at hand? This issue is particularly relevant for IT consultants: How do you ensure that the client takes ownership of the solution and collaborates with you to select, design, and develop it, rather than "throwing it over the wall" to you?
Dealing with incoming project lobs
Understanding the concept of "throwing projects over the wall" is the first step in managing client expectations. Thrown-over-the-wall projects often occur in dysfunctional corporate environments, where responsibility is seen as a hot potato, and the best survival technique consists of passing the project ball to the next guy, thus ensuring that he becomes the "blame agent" when issues arise.
Here are some well-known signs of incoming project lobs:
- The client displays little enthusiasm for the project, thus indicating that it's risky, has failed before, or is being imposed.
- The client wants to deliver a requirements document rather than collaborate on developing specifications.
- The client wants to short-circuit any assessment, discovery, or due diligence, saying, "You don't need to talk to anyone; I'll tell you everything you need to know about our organization."
- The client states that schedules, budgets, and expectations are nonnegotiable.
- The client is reluctant to commit time or resources to joint project activities like issues and status meetings.
- The client presents you as "the gal (or guy) who's going to solve our problem."
Consultants must heed these signs and develop strategies for ensuring that the client understands the rules of engagement. Here are a few strategies I use:
- If a client introduces me as "the guy with the solutions," I make sure to say something like, "This is a collaborative effort, and everyone works to find solutions together."
- If the client resists my participation in specification or discovery, I tactfully point out that every engagement is different, that there are no "one-size-fits-all" installations, even with off-the-shelf products, and that my discovery efforts encourage participation and buy-in. In addition, I mention that even shrink-wrapped solutions like Windows need unique configuration based on the goals and requirements of the organization. I help clients understand that broad participation, agreement, and shared vision are necessary for project success.
- I never accept nonnegotiable project elements such as fixed prices or schedules without an opportunity to do my discovery. Rather than simply telling the client I don't do fixed bids, however, I use the opportunity to reinforce the importance of mutually developed expectations. Once engaged, I prepare a detailed presentation of the strategies the client can apply to solve his or her problem. I view that presentation as a key deliverable of my engagement, the opportunity to ensure that the client understands the options and their implications.
- Finally, I go over each permutation and combination for each option with my client. I then help the client select a solution that the client's enterprise can communicate, sell, and support. It's a plus if the client believes, when all is said and done, that he or she invented the solution.
It's our responsibility as consultants to drive clients to the best result, and that result is often counter to the client's intuition or preconception. We often need to remind the client that there's no single solution and that the commitment and action of the client are the key determinants of a successful result.
How do you react when clients attempt to simply throw projects at you and remove themselves from the process? Post a comment in the discussion.Get weekly consulting tips in your inbox TechRepublic's IT Consultant newsletter, delivered each Monday, offers tips on how to attract customers, build your business, and increase your technical skills in order to get the job done. Automatically sign up today!
Rick Freedman is the author of three books on IT consulting, including "The IT Consultant." Rick is an independent consultant and trainer, working, through his company Consulting Strategies Inc., to help agile teams and organizations understand agile practices and migrate successfully.