Project Management

When to recommend a research project to a client

Chip Camden explains how to know when you should recommend a research project to a client and what two priorities are extremely important to get right when you do.

When you don't know how to do what the client is requesting, and two or three googles don't get you anywhere, you say "I think this will require some research." Just kidding.

You shouldn't measure the client's need for research by your own cluelessness. Research projects can cost your client a lot of time and money. You can't know how much it will cost until you're finished. More importantly, you can't know what its benefits will be other than gaining knowledge about the problem domain. The degree to which that knowledge will help you solve the client's specific problem remains to be seen, so you should only recommend a research project when the client really needs new information.

Thus, the first thing you want to do is find out whether anyone has ever solved this problem (or a similar problem) before, and whether the same approach looks like it could work for your client. This type of search requires more diligence than a handful of googles and resembles a mini research project. But you should focus this investigation on the question "Is there an easy answer to this problem?" When it starts to consume too much time, then you need a full-blown research project.

Even if you find a ready-made answer, you also need to ask whether it will be appropriate for your client. Sometimes subtle differences in the specific problem you're addressing can make adopting the same solution as futile as trying to squeeze the glass slipper on the feet of Cinderella's stepsisters. So identify all of the differences between the two cases to see if any of them are likely to indicate a different approach.

Sometimes, your client can benefit from research simply because they want to invent a better way of doing things rather than adopting the same old approach that everyone else uses. That should be pretty clear from their stated goals.

Hilary Mason recently posted an article about how to prioritize research projects. She lists five questions to ask:

  1. State the research question.
  2. How do we know when we've won?
  3. Assume we've solved this question perfectly. What are the first things that we'll build with it?
  4. If everyone in the world uses this, how does it change human behavior?
  5. What's the most evil thing that can be done with this?

Consultants usually start with a problem posed by the client, so the answer to #3 probably started this whole process. Pondering the last two items may reveal some insights into your client's motivation, but the first two items are extremely important to get right — and to make sure that your client agrees with your answers.

State the research question. "We need more information" is not focused enough. Your initial exploration of the available options should reveal exactly what it is you do not know. However, you need to state that so you stay on topic rather than following every wiki-hole until you reach Philosophy (see the Alt text). How do we know when we've won? This question insures that you state your answer to the first item in terms of concrete goals. "We need to learn about X" doesn't have a clear goal (do you intend to learn everything about X?), so state it instead as "We need to know how to make an X do Y." Then, the answer to the second item becomes "When we can make an X do Y."

After you start doing the research, you might find out that you're asking the wrong question. Part of what makes research projects so difficult to estimate is this need to revise your goals as you go. Far worse, though, is to doggedly stick to your original question. When you detect the need to change focus, get your client to approve that decision and reformulate your question just as rigorously as when you started.

Above all, set the correct expectations for your client, and keep them informed of your progress. After all, you want them to pay you for this.


Chip Camden has been programming since 1978, and he's still not done. An independent consultant since 1991, Chip specializes in software development tools, languages, and migration to new technology. Besides writing for TechRepublic's IT Consultant b...

Editor's Picks