NOTE: I originally posted this at my old company's website in 2010, but as that blog has been taken down, I thought I'd resurrect this post here.
There’s an old joke that goes something like this:
A young woman went to her doctor complaining of pain. “Where are you hurting?” asked the doctor.
“You have to help me, I hurt all over”, said the woman.
“What do you mean, all over?” asked the doctor, “be a little more specific.”
“The woman touched her right knee with her index finger and yelled, “Ow, that hurts.” Then she touched her left cheek and again yelled, “Ouch! That hurts, too.” Then she touched her right earlobe, “Ow, even THAT hurts”, she cried.
The doctor checked her thoughtfully for a moment and told her his diagnosis: “You have a broken finger.”
So what does this have to do with software development?
Too many times consulting companies get customers to tell them what they want and then they build it. What’s wrong with that? Isn’t there an old saying that says the customer is always right?
If you build what the customer asks for without digging deeper into the underlying business problem, then I guarantee that you will not build what they need. If you are just delivering a technical solution to a customer without figuring out whether you are solving the right problem in the best way, you aren’t giving your customer value for money. In fact, no matter how low you put your rates, you are short changing your customers, because you are charging them money to not fix their problems.
Just like a doctor’s patient can describe their symptoms, but doesn’t necessarily know the correct prescription to cure their ills, a customer is typically able to describe the business problem they are facing – but that doesn’t always make them the best person to come up with the solution. You need to collaborate with the customer and dig deeper to understand what the underlying issues are.
Of course, the customer is typically the expert in their domain and you should be the expert in yours, but you have to be more than just a technical expert to deliver business value. You need to be creative and passionate, you need to establish trust with the customer and build a collective sense of ownership of the problem so that you and the customer can both contribute to the solution.
You can use techniques like the Five Whys to perform root cause analysis, but ultimately you need to be interested and involved with your customers and care about their business. Only after defining the root cause of the problem can you then relate the problem to a solution you can provide with your domain expertise.
Ultimately, it’s not about delivering a project on time and under budget if that project isn’t effective; only by helping your customers succeed have you given value for money.