Why Customer Needs and IT Requirements Don't Always Intersect

One thing I have learned in my career is that what a customer needs in a software solution is often very different from what winds up in a requirements document. The software that is delivered then becomes a source of contention between the customer and IT:

"It's not what I need."

"It's what you asked for."

That's the crux of the problem. Requirements to an IT team, especially in a Waterfall environment (or one of its Lipstick-On-Pig alternate names), are elements which lead to architecture and design. They need to be reasonably complete and precise. A customer's needs are likely to be far more imprecise and incomplete. They are likely unaware of how software is actually developed, and may even be unfamiliar as to what is possible and are thus unable to know what to ask for.

The difficulty in most corporate environments is to find someone able to comfortably communicate with both groups. Typically you find a "Business Analyst" who's job it is to extract requirements from the customer and present them in some kind of document to the IT staff responsible for building the solution. Most larger companies do not typically allow programmers to interact directly with customers.

IT leadership usually hear the customers complaints and react by trying to "nail down" the requirements even harder by more rigorous and complicated methodologies changes. More meetings, more documents and especially "signoff" contracts to force the user to agree on what will be done are an attempt to deflect any finger-pointing later on. All of these tactics are to enforce the "It's what you ask for" point of view.

In my experience, putting more emphasis on the "what I need" point is view is more difficult but ultimately the right thing to focus on. Customers often don't know precisely what they need, or if they do they are unable to articulate how a solution might look. Often they are unaware of the range of possible ways to derive a solution and thus ask for the wrong things. Sometimes customers may read of solutions or imagine themselves as knowledgeable in software and demand inappropriate things.

All of these things require a different kind of "analyst": one who is equally as comfortable talking with customers as they are of building software solutions. I call this type of person a "project architect". Part teacher, part analyst, part architect: they need to be able to understand the customer's business, listen and interpret the customer's comments, teach the customer what is possible, and then derive a potential solution.

Ideally these potential solutions need to be demonstrated in prototypes or mockups so that the customer can give feedback; the advantage of having a programmer/architect in this role is that they can easily build things to show the customer instead of relying on explaining to others to get something to show. People react much better to something they can see and interact with than long lists of requirements or complex documents or (gasp) UML diagrams.

Despite the apparent obviousness of all this most larger companies and government agencies continue to follow the age-old waterfall methodology and the traditional business analyst role. I have seen and read of so many project disasters where the inability to adequately determine the customer's needs torpedoed the project before it any code was even written, even if the project continued thereafter.

Example

In the Corporate Air Pricing project I did at Sabre in 2000-2001, the customer group took contract information from travel agencies who served corporate customers (who had made contractual agreements with the airlines for discounts), and programmed the details into the reservation system. It was all managed with data in a Word template file, emailed or faxed from the travel agency and then coded by the 100+ person team at Sabre. Any errors caught by the airlines later after tickets were issued and used were charged back and usually Sabre had to eat them (to the tune of millions of dollars per year) since it could not prove if they or the travel agencies were to blame.

The CAP group was unable to interest the IT staff to help, other than write up a simplistic web application spec for the TA facing website, so they contacted the consulting group I worked for help on implementing the spec. After building it (it was more of a design document than anything else) I asked a simple question, "OK, now what are you going to do with the data?".

Since the IT "help" had been so minimal they had no idea. What followed was a lot of learning their business, teaching them about what one could do in a web application, both for the TA customers and internal to the CAP group. The customers needed to know the status of a contract, make corrections and add updates, track who made the changes and when and know when they could start pricing tickets. Sabre needed to be able to demonstrate when and what changes were made, manage the workload of the CAP team, track the employees workflow and other management functions. The process needed to become more efficient (even though the programming into the reservation system itself was ugly and slow).

During the process I continued to build and demonstrate HTML mockups so that we had something to look at and discuss. The people I worked with were eager to learn, and once they saw something they could respond with more pointed questions. Even after development began constant access to the work in progress allowed us to gain feedback (I had a team of 2.5 including me) and guide the project to correctly match the needs of the CAP group.

In six months the project was essentially complete. At this point Sabre IT got involved (and then EDS) and proceeded to hold up the project for an additional six month to implement a login screen so we added more functionality and managed an extensive live beta during that time.

Eventually my partner in the project continued when our employee went out of business for another consulting firm and ultimately the project became completely automated, sadly eliminating the CAP group entirely, but saving Sabre a ton of money.

Lessons

• Find people comfortable and able to communicate with customers and programmers and have experience actually building solutions.
• Use iterative and interactive processes to discover the customer's needs.
• Use mockups, prototypes and pictures to converse with the customer, not words.
• Learn the customer's business and ask lots of questions before, during and after development.
• Don't spend worthless time building systems to defend bad software solutions.

Sadly it is difficult to convince large corporate or governmental entities how a real customer-focused methodology works. The bottom line remains that IT built software solutions exist to serve the customer's actual needs, not necessarily what they ask for.

Ask any child lemonade stand vendor, if you serve lemonade to your customers without the sugar they need, they get mighty sour.