We've all heard it: the customer is always right.
This seems counter intuitive to our daily lives - we tend to react negatively when someone says that so-and-so is right because of their position or office. We laugh when we hear things like, father is always right. We get scared when a preacher says he's always right (think cult). And we get ticked off when our manager thinks their always right. So why would we assume a customer is always right?
The customer is certainly paying and the customer certainly has needs. In fact the customer probably understands the problem better than anyone. But is the customer always right? The Guru Red Manifesto talks to this by saying that the customer is negotiating for a position that wants it free, perfect and now. This is over the top language, but does highlight a reality of working with customers.
We also see this in organizations were customer service is separate from engineering. Customer service will be driven by customer dates and needs (a good thing) and engineering will be driven by what they can do and have resources for (a good thing). The right answer is to negotiate to the needs of both. The problem is when both organizations see themselves as more important. The customer service groups says, 'this is what the customer needs', and engineering says, 'we can't do that'.
The successful deployment of a system always involves four things: Design (branding, navigation, customer experience), business (ROI, risk, cost savings), technology (programming languages, standards), and process (program management, development life cycle). Here's the thing, none of these are automatically more right than the other. Each of these will negotiate with each other and the key to good negotiation is to know the needs of each other. For an excellent book on negotiation, see Getting to Yes, if you can, get the audio version. Risk management also becomes important here, for example, a highly visible enterprise wide system will have a greater impact if each of these core areas aren't addressed.
The successful deployment of a system always involves four things: Design (branding, navigation, customer experience), business (ROI, risk, cost savings), technology (programming languages, standards), and process (program management, development life cycle). Here's the thing, none of these are automatically more right than the other. Each of these will negotiate with each other and the key to good negotiation is to know the needs of each other. For an excellent book on negotiation, see Getting to Yes, if you can, get the audio version. Risk management also becomes important here, for example, a highly visible enterprise wide system will have a greater impact if each of these core areas aren't addressed.
Someone needs to make visible what's on the plate and it might as well be you. Make a list of projects and have a clear description of the purpose, deliverable, resource requirements, and assumptions of each. Get concurrence on priorities and status each project as: not planned, planned, in progress, etc. Engineering or customer service - someone needs to do it.
So the next time you hear, 'the customer is always right', or '90% is customer and 10% is engineering', be prepared to address reality, and manage this as a partnership.
So the next time you hear, 'the customer is always right', or '90% is customer and 10% is engineering', be prepared to address reality, and manage this as a partnership.
Posts
