When The Customer Is Not Always Right

| No Comments | No TrackBacks

November 12, 2004 • Vol.26 Issue 46
Page(s) 20 in print issue

While trolling the newsgroups this week, I came across a sad, but not that atypical, story. A consultant was asked to convert a functioning SQL Server (MSDE) database application to use JET. In his post, he said not to bother trying to convince him that this was a terrible idea. I didn't even bother to respond: He was beyond my help.

Sure, it's possible to convert a SQL Server application to use JET, but I can think of only a few (fairly transparent) reasons to do so. Yes, MSDE is harder to deploy than JET, but SQL Express (which should be here soon) addresses that issue pretty well. Beyond that, I just don't get it. I guess the customer (who is presumed to be right) must have a reason to want to regress his application's security, performance, and scalability and move to a paradigm that is harder to develop and costs far more to support. In this case, I doubt if the customer is right.

Is The Consultant Always Right?

As consultants and mentors, we're usually hired to give advice based on our experience, training, and skills. Unfortunately, we have to overcome the information that's been given to management and the decision makers who decide what to implement when building an application. Consultants, like doctors, often have one or more specialties—and usually not very many. When approached by a customer with a problem, they're likely to choose the "best" solution based on this prior knowledge.

For example, a C# developer that's worked with ASP.NET and Oracle is likely to suggest that to the customer, although it might not be the solution someone with a broader set of skills might choose. When a surgeon examines a patient in pain the first thing he might think is that surgery is needed. When a chiropractor examines the same patient, he'll start thinking about ways to "adjust" away the problem, just as a podiatrist might suggest a set of lifts or orthopedic shoes. Sure, a good doctor knows how to diagnose a variety of problems, but how often does a patient go to a general practitioner for a referral? All too often they diagnose themselves based on what they saw on television, read on the Internet, or heard from Aunt Harriet. Some doctors are all too willing to take the money and attempt to treat the illness, regardless of how appropriate the treatment.

When a customer in pain comes to a consultant, is the consultant prepared to say, "No, I can't help. You really need a specialist in X, which isn't something I do. Let me give you the name of some people that work in that area."? We all know how hungry some consultants are, but I know plenty of consultants that refer business to other competent consultants, especially when they understand that their skills or experience can't cure the illness. Sure, some of these guys are hungry, but they also have a reputation and recognize that if the customer isn't happy with their work, it's even harder to get more.

What's a consultant supposed to do when a customer asks for something that won't help or might actually cripple their business? It's idealistic to think that the consultant should just stand up to the boss and say what he or she thinks. You also need to consider that the customer might actually be right—as strange as it seems. They might actually know more about the problems the company faces on a day-by-day basis. Let's hope not all customers and managers are as dim-witted as Dilbert's pointy-haired boss. The problem is that if you're the consultant or developer responsible for implementing the project and don't believe in the design, it can't possibly succeed, and you're probably not the best person to do the work.

Get The Facts Straight

I expect one of the better approaches to this problem is to first get the facts straight. Hold a meeting with the development team and discuss the design. Use this as a forum to point out your reservations and the problems you anticipate. Who knows, one or more of the others on the team might agree with you, or others might help you understand why the supposedly awful design makes sense. Most managers got where they are because they're rational. Sure, others were promoted because of the "Peter principle" or because their mom owns a lot of stock, but most are smart enough to listen to reason if it's presented intelligently. If after getting a thorough understanding of the issues and not being able to convince the boss that the decision is wrong, it's time to knuckle down and do your best on the project or on your resume.

No TrackBacks

TrackBack URL: http://betav.com/blogadmin/mt-tb.cgi/103

Leave a comment

Pages

Powered by Movable Type 4.21-en

About this Entry

This page contains a single entry by William Vaughn published on November 12, 2004 7:04 PM.

Curing A Plethora Of Performance Problems is the next entry in this blog.

Find recent content on the main index or look in the archives to find all content.