Customer Control

Dear Bob …

I enjoy reading your articles, and your advice is sound and even insightful at times.

I would like to get your thoughts on the issue of “customer control.” By customer control I’m referring to those situations where the customer not just keeps changing requirements but tries to meddle in the design. This customer thinks that he is an expert or has fixed beliefs about how certain things should be done and does not want to listen to reason.

Since you are ultimately responsible for the success of the project, you don’t want to do something stupid just because the customer insists that his way is correct.

I’ve encountered this problem a number of times in varying degrees and find that it is difficult to walk the fine line between keeping a customer happy and letting the customer ride rough shod over you. I’ve gotten lots of practice at playing psychologist in order to keep a customer from running amok, but it gets wearisome and can take-up much valuable time. An out of control customer can wreck a project and put you in a very difficult situation.

– Managing the Customer, along with the Project

Dear Managing …

Let’s hope this is one of those times you find me insightful!

It isn’t clear whether you’re talking about a real customer or an internal customer. The two situations are quite different.

Let’s start with internal customers. IT’s job is to make internal “customers” (really, consumers, since they don’t make buying decisions) more effective. Making them happy is somebody else’s problem.

This doesn’t mean that disparaging them, treating them with disrespect, or assuming they’re idiots is appropriate, of course. In general, mutual respect is a good habit among employees. The point is, both you and they should share a common goal, which is to increase the success of your employer.

When internal customers try to “meddle” in the design, my experience has been that for the most part they’re really trying to participate in the design of the user interface, which is entirely appropriate. User interface design should be a collaboration.

Sometimes, though, internal customers do try to involve themselves elsewhere, in particular in the process of data design, and occasionally in even more abstruse matters such as software architecture. The best solution to this is prevention: Before the project launches, create a grid. The rows list the major types of decisions to be made during the project; the columns list the major stakeholder groups. As part of the project kickoff meeting, the matrix becomes a RACI chart (Responsible, Accountable, Consulted, Informed, if you aren’t familiar with it) so everyone knows which decisions they’ll be involved in, and in what capacity.

With that ounce of prevention, during the project you can explain to your internal customers that while you certainly do plan to consult them in the data design (for example) to make sure it will accommodate their requirements, in the end it’s your data design experts who have the final call as to the actual structure.

If you’re dealing with a real, paying customer, the situation is entirely different, but the solution is quite similar.

In many cases, an external customer will employ IT staff just as sophisticated in their understanding of the issues as you and your team. When that’s the case, the best solution is to make use of “blended teams” that include the customer’s experts in at least a consulting capacity on the design. Since the customer will have to live with the solution long after you’re gone, it’s quite appropriate that the customer’s experts are involved in it, to make sure you do a good job that adheres to their internal standards.

In other situations, you’re hired because it’s a small company that doesn’t have much in the way of internal expertise. All that’s happening here is that whoever hired you is worried. After all, what you’re proposing to do is to deliver a black box that in theory does what the customer asked for. There’s no way to verify its quality independently, and that’s almost guaranteed to make a business executive insecure. So the executive tries to get involved in the design details, with predictable results.

The solution, with either of these external customers? Sit down before the project starts, RACI chart in hand, and ask which decisions the customer will want to be involved in, and how. Very important: Do this before you’ve finalized and presented the project schedule, so you can deal with the impact of the customer’s involvement.

Last thought: You used the term “correct” in discussing the nature of design. It’s rarely that simple – there are trade-offs in any design that ensure there’s no such thing as the correct design. Instead, there is a family of designs that are correct enough, along with lots of design alternatives that are just plain bad.

Your job isn’t to make sure the correct design is the one that’s implemented. It’s to make sure everyone chooses one that’s correct enough.

– Bob

——–