The key to buying a new system is the specification, not the RFP

After 23 years in the publishing business, the Information Technology Director wore the scars and the stars of more than a dozen major computer system installations. Editorial, advertising, pagination, circulation, accounts receivable, color systems, output management subsystems. You name it; he'd bought it. He'd installed it. He'd replaced it.

He brought this terabyte of experience with him as he walked into the executive conference room to join the kick-off meeting for the new classified and display advertising system. The supplier's team sat to his left, all suited up with laptops poised. The customer team -- his team -- sat together on his right. Without a word, the IT Director faced the white board at the head of the table, picked up a red dry-erase marker and wrote in large, neat upper-case letters: "Windscale." Turning to his audience, he pointed to the board and punctuated each letter with the red marker as he spoke. "What Is Not Down in Specification Costs A Lot Extra," he said to the group. Then he turned and left the room in strategic, deferential silence.

Through this simple, melodramatic gesture, the IT Director communicated to the entire team his belief in the importance of the specification process when launching a new project. In addition, as the project's sponsor, he acknowledged the specification as the unifying document that describes what the system will and will not do -- and ultimately, what his company will and will not pay for.

There's a problem, however, right out of the launch pad. Even if every person sitting at that table agrees the spec is important, there are probably two widely different views as to what a specification actually is and does. Most members of the customer team would say that the specification defines what they want the system to do. The supplier team, on the other hand, is likely to say that the specification describes how the system will work. The distinction between what and how often leads to misunderstandings that can jeopardize the success of the project.

In the customer's eyes, the focus is on needs and requirements. The system search and selection process often begins with a Request For Proposal (RFP) detailing all the things the customer wants in a new system. In the supplier's eyes, the focus is on implementation. The supplier may respond to the customer's RFP with a proposal describing all the features and functionality that their system has to offer.

The customer is talking expectations, while the supplier is talking execution. Disconnects occur whenever the customer feels their RFP very clearly states what they want the system to do, and the supplier feels their system proposal defines exactly what the customer will be getting. As soon as a disagreement arises, each party has a natural tendency to perceive the problem from their own point of view.

The key, therefore, is to recognize from the outset that the specification must encompass the requirements as well as the solutions. The what is certainly important. So is the how. But, to ensure that the specification meets the objectives of both the customer and the supplier, the focus also needs to be on the why. If every individual gathered around that conference table can agree why a particular item appears in the specification, then both parties will begin to see the issues from the other's perspective.

RFP problems
Take, for example, a customer requirement that the system contain a full-featured text processing component. By stating this requirement in the RFP, the customer team believes it is telling the supplier what it wants. In addressing this requirement, the supplier's proposal may state that its system uses Word from Microsoft Corp. of Redmond, Wash., as the text processor. Microsoft Word, with all its built-in capabilities, is how the supplier's system will satisfy the customer's requirement.

The potential problem crops up when trying to interpret why the customer wants a system with a full-featured text processor. From the customer's point of view, this requirement will allow the users to have a fast and flexible means of creating complex formats with the ability to switch to different typographic styles by using a single keystroke.

In the supplier's view, Microsoft Word is an industry-standard document generation tool. When you buy this supplier's system, in other words, you get all the tools that MS Word provides to handle all of your text processing needs. Anyone can learn to write Word macros that can handle all sorts of complex formatting requirements.

But who's going to take responsibility for writing these formats? Who's going to debug them, test them, document them and integrate them? And, when you think back to the IT Director and his Windscale admonition written on that white board, who's going to pay for the time and effort necessary to implement these formats?

As part of the cross-functional spirit that is vital to the success of any project, the supplier and customer team members always should ask themselves why a particular requirement is needed before putting it down in the specification. The focus should be on desired outcomes. This approach will help foster clarity, consensus and a clear set of expectations and deliverables. Using the example above, the requirement for a full-featured text processor could be written in the specification as follows:

"The system will include a text processing program that allows user-definable formatting and programmable keyboard commands. The standard system will include a library of documented, pre-defined formats that can be customized and expanded by users with appropriate authority levels."

In addition to the why rule, here are five corollaries to the Windscale Principle that can be used by the combined supplier and customer teams to help produce good, clear specifications and to avoid communications troubles -- and potential accounts receivable battles -- once the project gets under way.