Client 101

© 2001 Sherry Heinze

I work as a test analyst for a consulting company. Every 6 to 12 months, I start on a new project for a new client. I love the variety and the opportunity to learn about a new business or a new part of the business. With each new project, we have to work to convince the customer of the benefits they will receive for the money they spend on testing. I can become very tired of fighting the same battle with each new client. Most clients actually believe that I do useful work by the end of the project. Then we move on to another project and start all over again, fighting the same battle. That part gets boring really fast. If you work on test projects, you've probably encountered the same challenge.

On my last project, our client gave us an idea that may make selling the value of testing easier. As we approached the end of development and the "testing phase", the onsite client representative started to object to the amount of testing planned and the cost. This is hardly an unusual occurrence. The only oddity was that the complaint was not raised as strenuously earlier. Long discussions with the project manager eventually convinced her that we were not just padding the bill. The steering committee was not convinced. Certainly testing by anyone available at their office would be just as useful and a lot cheaper. After all, our developers were supposed to be good, so why would there be problems with the software?

But the client representative brought up a very good point when she suggested that we should have spent time at the beginning of the project explaining our methodology, specifically, but not exclusively, with testing, both to her and to the steering committee. She even spent a considerable amount of time with the project manager, and then with me, explaining what she thought we should have covered.

I should mention that every proposal we submit has an explanation of our methodology, from the beginning of the project through to implementation. From our point of view, we did tell them. However, most of us realize that we are lucky if the client browses through it. As much as we hope they do, we don't really believe they focus on it. The Project Charter contains more information on what we plan to do and how. Again, if it gets read at all, it is not remembered.

A couple of weeks ago, the head of the Project Management Office at another client asked me to provide any information that I had on the value of testing. She had to make a brief presentation to a user group in an attempt to justify bringing in professional testers on a project they were funding. I have several presentations, all variations on the same theme, which I give to testers, quality assurance practitioners and project team members. While the details are often useful, I am preaching to the converted. Even the junior developers on the project teams are almost all on side these days. But the clients are not yet convinced.

The clients deal primarily with the sales people. Sales may be aware of what we want to sell, but they don't really understand why. Sales people are not often knowledgeable enough to make a convincing argument for quality. They do not understand our jobs much better than we understand theirs. So we are trying a new approach. We are developing a new course for clients, "Client 101". Perhaps if we try preaching to the unconverted at the very beginning, we won't have to fight so hard later. If it works, I will be very grateful to the client who suggested it.


Email this article to a friend.


Comments to: