Consultants don't technically own the project they're working on. The project belongs to the client, and they're the ones who will have to live with whatever monster you create for years to come. Nevertheless, the project feels like your baby. You care about the quality of your work, and you can't bring yourself to mar it with inelegance or stupidity. But you may sometimes encounter a situation when that's exactly what your client wants you to do.
They don't think it's bad, because to them, it's a matter of following standard, documented practices. But you see that the standard has outlived its usefulness and that, in fact, it poses serious threats to the client's success down the road. You explain your thoughts and give your advice on the matter. But your client's technical lead is adamantly opposed to these strange new ways. What do you do? Here are five suggestions.
Note: These tips are based on an entry in our IT Consultant blog.
1: Go with the flow
It is the client's system, after all, and they're paying you to do what they want. You've given them the benefit of your wisdom, and they've chosen to ignore it, so just do things their way. Who knows, maybe they're right after all -- there's always more than one way to look at the pros and cons of anything. Of course, this makes you less than excited about working for them. In fact, you may subconsciously start to think of the whole project as tainted, which could lead to quality slippage in other areas as well.
2: Go away
Ask to be excused from the project because you have irreconcilable differences with the approach. If they won't listen to you, why stick around for the inevitable train wreck? On the other hand, it's highly likely that by dropping out, you could eliminate all future opportunity for engagements with this client. It might also be seen as a scare tactic or even a suicidal cry for attention.
3: Go up the ladder
Take your argument to the technical lead's boss. If you can convince the boss, maybe you can bring pressure back around from the top. Of course, this is likely to create other problems. If the technical lead has to give in, he or she will look for ways to assert control in the future. Watch for hidden daggers.
4: Go out to the masses
Discuss the pros and cons with as many people in the organization as might be interested. Create a buzz over your new ideas until the new ideas overwhelm the old ones. This approach can also cause resentment -- nobody likes to give in to mob rule. So you'll have to figure out how to build that support without casting yourself in the role of demagogue.
5: Go back to the drawing board
Look for new ways to make your argument. How can you express the benefits of the new approach more clearly? Is there a valid way to compromise -- getting essentially what you want, while satisfying whatever need is driving your client? Stop and think: Why is the client so attached to the current practices? What benefits from them, or what threats from your proposal, do they perceive? Maybe you should ask the technical lead just that question -- not in a snarky way, but really looking for reasons. Of course, if the answer is "because I said so" (in so many words), you've reached a dead end.
This situation isn't entirely hypothetical for me right now, so I'm keeping the details vague and the participants anonymous. I'm also genuinely looking for your help. What do you think? What combination of the above would you use? Do you have another idea that doesn't fit into these five strategies?
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 blog, he also contributes to [Geeks Are Sexy] Technology News and his two personal blogs, Chip's Quips and Chip's Tips for Developers.