A colleague of mine sent me an interesting article today called Don't give customers what they think they want. This article has a great quote from the early 1900's by Henry Ford, the inventor of the Model T. While talking about user requirements, Henry stated:
"If we ask customers what they want they’ll ask for faster horses".If Henry would have implemented exactly what the users asked for (if he even could accomplish that) he never would have created the Model T. Instead of asking users what they want, we should ask them what problem they are trying to solve. The article recommends asking this same question in a more eloquent way by asking, "What is the desired outcome?" After all, it is the job of IT people to design systems, not the business. The business should know what they want to accomplish and IT should devise a few potential solutions and offer those to the business.
I have ranted in the past in a post called Why are you still generating reports?, how IT has a tendency to let the business design systems. If the IT industry would get the business to focus more on defining business problems and desired outcomes instead of telling us what to build, perhaps there would not be such a huge need for business process reengineering these days. In my 20+ years of IT experience, I have seen huge amounts of waste due to IT building low value solutions. This often occurs because a user with limited visibility into the entire workflow asks for a point solution for their small part of the world. Over time, IT builds hundreds of these point solutions which wind up creating redundant data entry steps and the need for more reports and "quality" checks to accommodate for bad processes. The business person has good intentions but typically does not have enough knowledge of the end to end processes to offer up proper solution. This is precisely why we should not build what they think they need.
As we all know, IT does not have a great track record for delivering projects on time and on budget. I believe that a major contributor to this is IT's inability to gather good requirements. If we focus the requirements gathering process on business issues and desired outcomes, I believe we give ourselves a much greater chance of success.
What do you think?
