(February 13, 2004) - Customer satisfaction is not all that it's cracked up to be. We have had the pleasure of enjoying press releases from several companies claiming top scores in this or that customer satisfaction survey. The trouble exists in the definition of "customer".

We once had a car that the kids loved. Had they been interviewed for a customer satisfaction survey, they would have given it wildly positive reviews. We would have preferred that it ran regularly. They liked the extra back seat accessories. We were interested in dependability.

The beginnings of failure in an installation project involve the development of the basic requirements document. A Requirements Document (or something similar) is the foundation of any significant engineering project acquisition, budgeting and scheduling process. The Requirements document answers the question "What is it supposed to do?"

In any departmental setting (except the very smallest), there are a myriad of ways to accomplish the basic task. While process standardization around an ideal method is a useful point of departure, all knowledge processes have a broad degree of variation. (and Recruiting is nearly unique in its variability). From the simple big boss recommendation (hire this person, forget the process) to the peculiarities of hard to fill positions to high volume high turnover slots (as in retail), the essence of large scale recruiting is broad variability around an ideal process.

Unfortunately, the kinds of people who are likely to be at the core of developing a spec for a new recruiting system are not likely to be representative of the broad dimensions of the current practice. People with that level of expertise are left to recruit. The unraveling begins with the construction of the initial team. Inevitably, the person with the highest level of expertise is left off of the team because they are either too valuable or disinterested.

It is not really possible to develop a useful Requirements Document that incorporates all of the needs of all of the members of a team. While NASA must provide that level of clarity, Recruiting is not rocket science. There is a difficult balance that must be drawn here.

The risk associated with purchasing any enterprise software (risk, not schedule, price or satisfaction) can be reduced to the degree a Requirements Development process is comprehensive. At some point during the process of changing systems, someone has to sit down with each team member and understand their unique approach to their job. That happens before, after or before and after acquisition if the system is going to be routinely used.

It doesn't happen. As a result, most systems are installed in a way that guarantees that they are never going to be used by some of the department-hiring team. In other words, their failure is guaranteed from the outset.

John Sumser