Here’s a common scenario for contractors: Both you and the client agree on the job that needs to be done, but you think that development tool X will do the best job while the client prefers development tool Y.
Obviously, the client—who will have to live with the results—will have the final say. After all, it’s the client’s money, company, and project.
But because you’re handling the project development, you have a say, too, even if you don’t have the same approval or veto power.
In this article, I’ll discuss how to discover the root of your client’s objection and address it appropriately.
Isolate the reasons
You can do little to sway your client if you don’t know the reasons behind his or her objection to your chosen development tool. Often, the first reason the client gives isn’t detailed (and may not even be the real issue). The only way to find out for sure is to address his or her reasoning; if further objection follows, it’s time to ask, “What’s the real problem?”
Occasionally, the client’s objection involves a quality concern: The client doesn’t believe that your tool is as good as the one he or she prefers. Sometimes, it’s simple inertia: The client has always used tool Y.
The most common root of a client’s objection, however, is financial, in some way or another. With a little patient digging, you’ll probably uncover one of the following scenarios:
- The client doesn’t want to purchase the software or hardware necessary to implement your recommended tool.
- The client doesn’t want to use your tool because he or she will have to train his or her own people to use it after you’re gone.
- The client doesn’t want to retrofit existing processes or technologies to work with the new tool.
And then address them
Sounds simple: Just address the problem. Why, doesn’t everyone know that Dreamweaver is better than FrontPage? Even if that statement were true, it’s a sad fact that some people will always side with the familiar over the superior.
The only way to effectively address any client objection is to appeal to the client’s bottom line. It isn’t enough to say that the end result will be better with tool X vs. tool Y. You must prove that using tool X will save the company money by either:
- Making the end result more profitable; for example, by producing a Web site that will be easier for customers to use and require less ongoing maintenance; or
- Shortening development time, thus decreasing contractor expenses and realizing revenue sooner because the project deploys more quickly.
Your financial case must be short term, reducing costs or increasing income during the next six months to a year. Few companies can afford to care if something more expensive pays off in five years.
If you can’t make the case for your preferred tool on these criteria, then don’t bother. Also, don’t forget to figure related expenses. It won’t matter, for example, if you can set up the new database in one program in half the time when the data is already in the existing program.
Outline not only the benefits of using your tool but the consequences of using an inferior tool, if appropriate. These consequences should be unique and not merely the flip side of the good points about using your preferred tool.
A case in point
I’ll share with you a development-tools disagreement I often encounter and how I deal with it according to the procedures I’ve outlined for you.
Although I provide all sorts of solutions for clients, including user manuals, procedural documents, and system specifications, the common denominator is that I deal in the written word. As a result, clients usually assume that simple word processing software is the best solution. Besides, everyone in their office has it, so (the thought goes) it won’t be any problem for them to update the documents after I’m gone.
Unfortunately, clients are usually wrong on both counts. Not all documents are equal, and word processors are rarely capable of creating long, graphics-rich documents that will be continually updated without sustaining massive document corruption and application crashes.
As for the client’s employees updating my documentation, my follow-up surveys show that none of my clients have performed even basic information maintenance, much less a complete update. No one has the time or inclination, so it doesn’t get done.
Usually, clients don’t want to have to purchase the software I want to use or train anyone to use it.
The financial case
Depending on the specifics, the solution I want to use will cost the clients between $250 and $950 to purchase and install for their own use after I leave. (I already have my own copy, so they can choose later whether to do this.) On the other hand, they pay far more than that when an inferior tool delays the project and increases development time.
I outline alternatives and list the pros and cons. On one project, using software to produce PDF files would increase document security and integrity, thus reducing the potential for introducing errors that could cause the company to ship a flawed product.
For another project, true document-publishing software would not only prevent my having to recover and rebuild corrupted documents, but it would also allow the source material to be easily repurposed, such as for use on an intranet, the Internet, or in online help files.
To address the issue of wanting to update the work, I let the client know the results of my survey. I also offer to provide at no charge a specified amount of training on the new software for an employee toward the end of the project.
If clients insist that I use an unsuitable development tool, I insist on additional compensation. I also require the clients to sign off on a statement saying they have been informed that their preferred development tool is inadequate for the task and that they release me from liability for missed deadlines or damaged documents caused by that software.
Resolving conflicts over tools
How do you settle disagreements over the tools that you, the consultant, want to use vs. the ones that your client prefers? Share your comments in the discussion below or send us your strategies in an e-mail.