Study Thy Customer

Tom Kelly is an Industrial Designer for one of the most successful industrial design firms, IDEO. He writes in his book The Art of Innovation, “Your customers may lack the vocabulary to explain what’s wrong and especially what is missing.” Bingo! One has to start to ask the question, “If your customer does not know what he or she wants or cannot articulate what is wanted, then how exactly should the requirements process work?” Kelley writes, “It is common for well-meaning clients to duly inform us what a new product needs to do. They already ‘know’ how people use their products.” His firm does not rely on customers telling them about their problems. His book is full of stories recounting where customers were wrong about problems and possible solutions. His firm has learned to study customers and not rely on what they say. Kelley’s views are not unique, and his views are shared by many other industrial designers. Now if Kelley is right, and customers cannot articulate what they want, and especially what is missing, then how should the requirements process work?

The worst possible way for the requirements process is to have customers write up requirements and toss them over some imaginary wall. The software development team works on the project for months and then shows up with a semi-completed project during acceptance testing. Of course, the software is missing functions and does not work as desired by the client. The problem is not that the business problem and solution changed during this time; the problem is the business problem and solution were never defined.

Another common practice is sitting in a conference room with a customer and asking, “What do you want?” Sitting in a conference room asking questions may not be a useful way to gather requirements, and it certainly should not be the only way. This has nothing to do with how smart or how good you are at asking questions. Some developers will code what they thought the customer said and then show it to the customer. This is commonly known as a code/test iteration. A logical question is, “Why does it take so many code/test iterations to determine what a customer wants?” What were the reasons the developer and customer did not get it right in one or two tries (iterations)? While this method is known as code/test, it is really a trial and error method to gather requirements. The problem with trial and error is there are a lot of errors made along the way.

None of the solutions I mention actually address the root cause of the problem. Many software professionals have thrown up their hands and accept that growth and changing functionality is just the nature of software development. They incorrectly conclude the best strategy is to learn to adapt as the customer changes his or her mind. In this scenario the solution to the problem is adaptation. The teams need to be formed in such a manner so as to react as quickly as possible to the growing and changing environment.

The range of growth is not consistent across software development organizations. Some organizations have little growth while others have growth exceeding 300 percent. One of the qualitative factors impacting growth is core business domain knowledge. There is a correlation between domain knowledge and project growth. Those software organizations with a lot of domain knowledge have small rates of growth while those organizations with little domain knowledge have high rates of growth.

Those projects that have a lot of user involvement have growth and churn rates lower than those projects with little user involvement. The mediating factor between project success and user involvement is how the problem and solution were understood. In other words, it is not user involvement that makes software projects successful; it is understanding the business problem that makes projects successful.

Many of my clients create software applications in the scientific domain. These type of software applications have little growth, small churn rates, and are relatively small. Keep in mind, these applications are extremely functionally complex. It is common to have those with scientific backgrounds writing much of the software programs. In this case, the software developers are intimately familiar with the business problem. Many years ago I wrote software programs for physicists at the Texas A&M University, Cyclotron. My job was to write programs to help solve very complex mathematical equations. I learned quickly that the physicists expected me to understand numerical analysis, and they were not about to explain it to me. This forced me to learn the mathematical and problem domain, and it helped me write better software programs.