Creating Services Specifications that Get
the Results You Expect

Whether you are sole-sourcing for services or writing a request for proposal (RFP), creating the specifications for intangible services can be a sobering experience. It takes time and thought. Vague specifications usually produce equally vague and often high-priced proposals. In brief, specifications that get results state:

• The need or problem that now exists
  
  
• What you want
  
  
• Why you need it
  
  
• When you need it
  
  
• Roles and responsibilities of both the buyer and the services firm
  
  
• Working relationships between parties
  
  
• Media preferences
  
  
• Budget range
  
  
• Selection criteria.
  

The example which follows is based on the creation of specifications for instructional design (course development) services. The principles, however, apply for all kinds of professional services. Here are some rules of thumb.

Rule One: Always bear in mind that you are buying services, not products.

This is often an area of confusion. If you were in the market for an off-the-shelf course, creating detailed vendor specifications would clearly be a waste of time and effort. Thousands of off-the-shelf courses are available at relatively low unit cost per student. A quick review of the trade journals in your business is all that is needed to turn them up. A few telephone calls and you will be inundated with presentations and offers.

But, sometimes off-the-shelf courses don't fit your training needs. They are too "generic," too basic, too expensive, or simply do not relate to your problem. Then, you are faced with looking for someone to create a unique course.

Actually, you are in the market for a creative service, not a course. Once that (admittedly intangible) service has been successfully delivered, the more tangible course will result as a by-product. Once you accept this premise and line of reasoning, you are well on your way to developing services specifications that will get the results you expect.

Rule Two: Communicate your need, not a preconceived solution.

This rule relates closely to the first. An analogy will help make it clear.

Two patients go to a doctor, both with identical symptoms -- severe and persistent abdominal pains. Patient A says, "Doctor, I need an appendectomy." Patient B says, "Doctor, I have this severe pain - right about here. I've had it off and on for three days, and it keeps getting worse." Most doctors, of course, will not perform an appendectomy without many other questions, a physical exam, perhaps an X-ray, and the like. But if you prescribe the solution rather than defining the problem, as Patient A did, you simply invite an unprofessional response.

It is important to communicate your problem or need, not prescribe a solution. Here is a business example to illustrate the difference:

By specifying a videotape as the only acceptable solution to the need, the preconceived solution ties the proposal submitter's hands. The professional services firm may have better, more cost-effective alternatives in mind, but they are unlikely to submit such suggestions for fear of appearing unresponsive to your proposal request. Yet, in the situation described, it is almost certain that a single videotape will be too "broad-brush" to be acceptable to all the audiences specified. It will be:

• Too detailed for the executive, or
  
  
• Too general for the sales staff, or
  
  
• Will address issues you don't want brought to the customer's attention.
  

And, even if an effective videotape could be produced for all those audiences, it certainly wouldn't be inexpensive.

The idea, then, is to state the business and/or training problem, perhaps identify unacceptable solutions, then let the professional services firm do the work of creating and proposing an acceptable solution.

Rule Three: The purpose of developing services specifications is to communicate.

This rule relates to the language you use in your specifications. Simply stated, if you had people in-house with the talent and time to do the job, you would have no need to solicit outside services. Since you've determined that outside services are necessary, and since you want an effective solution, it makes sense to communicate – not obfuscate. Here are some tips:

• Avoid in-house shorthand.
  
  You cannot expect outsiders to know all of your company's shorthand, abbreviations, acronyms, and pet phrases. Avoid them or explain them.
  
  
• Use and expect the services firm to understand the standard language of your business or trade.
  
  Standard trade language (as opposed to company-unique acronyms and jargon) is quite acceptable in your specification. Within reason, you have the right to expect the services firm to know enough about your business to be able to perform. That means the services firm should be able to read and understand the standard language of your trade.
  
  On the other hand, you cannot expect any professional services firm (even an industry expert) to know the intricacies and inside workings of your business as well as you do.
  
  
• Avoid professional services jargon.
  
  By the same token, services bidders do not expect you to be experts in their areas of expertise. Avoid using specialized terminology such as "criterion referenced instruction," "program validation," "formative evaluation," "multilevel branching, multimedia, CD-ROM, on-line help" and the like unless you really understand the terms and they are specific requirements for proposal acceptance.
  

Services Specifications that Get Results

With this look at some "overall" rules, let's move to specifics - items that need to be in your specifications if you expect responsive proposal submissions. Please note, the intent is not to prescribe the order or arrangement of specifications, but rather to suggest content that should appear somewhere if you are to get the results you expect.

Whatever the services you are seeking, the outside services provider will need information in these broad content areas:

• General project information
  
  
• Description of your need or problem
  
  
• Business constraints related to the need
  
  
• Audiences affected
  
  
• Definition of scope of effort
  
  
• Availability of information and people resources
  
  
• Time-frame expectations
  
  
• Work product acceptance criteria -- what is acceptable/unacceptable
  
  
• Proposal selection criteria (if a request for proposal is submitted to multiple organizations)
  
  
• Decision date, planned project start date, and method of notification
  
  
• Publishing standards (if they exist)
  

To bring these content areas to life, let's try them with a specific example. Assume you are seeking support requiring instructional design and documentation development services for the introduction to the market of a new product. It is likely your specification would include the following content areas:

General Information

This section sets the stage for the professional services firm. It lets them know who you are, what your organization does, and what your general expectations of the services firm are. Contents of this section may include such items as:

Description of the Need or Problem

This is the most critical section of a successful services specification. As stated earlier, it should not be a predetermined "prescription" but rather, a statement of the problems and needs for which you are seeking outside help. It will include topics such as:

Let's explore that last item in more detail, since it is the core of your specification. The details you should provide might include these elements:

• Why is the documentation or training needed?
  
  
• What results do you expect from the documentation or training?
  
  
• When is the documentation or training required to be ready? Is the date needed a significant issue? What are the business consequences were the date not met?

Business Needs and Constraints

What are the important business considerations? Are you seeking ways to:

• Reduce customer dependence on "hot-line" support through better documentation?
  
  
• Improve customer satisfaction with a product or service?
  
  
• Meet governmental regulatory requirements?
  
  
• Reduce the travel and/or lodging costs associated with training?
  
  
• Free up instructor staff for other requirements?
  
  
• Provide just-in-time training in lieu of periodically scheduled formal classes?
  

Audiences - Who are the Documentation Users? Who is to Be Trained?

This is a description of the people whose skills, knowledge, or attitudes you expect to influence with the training, or an identification of each major group that will be using documentation. Typical information you might provide includes:

Outline Description of Training / Documentation Content and Scope

For training, this may take the form of a brief list of the key topics, or an outline of the material you anticipate will need to be covered in the course.

For documentation, this may take the form of the types of documents required:

• User guide
  
  
• Reference guide
  
  
• Installation guide, etc.
  

You should also provide information such as:

Availability of Content Information, Product Information, Existing Documentation, and Subject Matter Expertise

What additional information (other than your specification statement) is available to the proposing services firm? You should take it as a positive sign when services firms want more information. It indicates that you are dealing with interested professionals, not a "proposal mill."

In what form does content for documentation or training now exist? Information which is already compiled and organized will require less effort and, therefore, will entail a lower dollar investment than if the information must be gathered from a variety of sources and organized.

But, also be aware that the use of a professional services firm to select, screen, and organize information from a variety of sources can be a very cost-effective use of such resources, since this is one of the most time-consuming aspects of course design and documentation.

Several means exist to make additional data available. Depending on the circumstances you may wish to:

• Provide the professional services firm copies of such existing documentation as draft operator/user guides, existing course materials, and the like, (or make them available for on-site review).
  
  
• Provide the opportunity for on-site, hands-on experience with equipment and software for which documentation or training is to be developed.
  
  
• Schedule question/answer sessions with product developers, engineers, instructors, etc.
  
  
• Make available a subject matter expert for telephone inquiries.
  

Acceptable/Unacceptable Methods and Environment

The purpose of this section is, at least in part, to reduce your proposal review labor. Since you do not want to have to read proposed solutions that clearly do not fit your needs or circumstances, it makes good sense to communicate up front what is, and what will not be considered, acceptable.

• If on-line documentation must be backed up with print documentation, say so.
  
  
• If print-based self-study is not acceptable, be sure to so state.
  
  
• If the training audience typically uses personal computers as part of their job and computer based training is an acceptable alternative, state that.
  

Be careful, however, not to be too narrowly prescriptive. One of the reasons for going to outside resources is to obtain new ideas and new perspectives.

Media and Media Quality Expectations

The same principle applies here as above. If certain media delivery systems are in place, let the services firm know. For example:

• If your RFP is for sales training and you have just invested in laptop computers for your entire sales force, this can be valuable information for the professional services provider.
  
  If you expect two-color page design for customer user guides, but only black-and-white for internal documentation, the services provider needs to know.
  

Here is some other information you may want to include:

Expected Delivery Dates and Review Turnaround

To make a reasonable bid, and to assign adequate resources to the task, professional services firms need a clear picture of your delivery expectations.

• What is the expected delivery date? What are the business constraints that will be adversely affected if this date is not met? Examples of such constraints include planned product announcements, pre-scheduled training, and the like.
  
  
• What scheduling factors should the services firm be aware of? Typical examples are product Alpha and Beta tests, company holidays, known schedule conflicts of key people such as subject matter experts.
  
  
• What is the typical turnaround time for reviewing large documents (150-300 pages) in your organization? When you can honestly commit to quick, thorough reviews and sign-offs, you save the services provider expensive" dead time." Be realistic in your estimate, since services firms are likely to pass on the costs of review delays.
  

• Commit the time and resources to prepare a services specification that clearly communicates your needs and the business problems for which you are seeking solutions.
  
  
• Avoid company jargon.
  
  
• Express both expectations and business constraints.
  
  
• Make resources available to answer questions.
  
  
• Review proposals thoroughly for match between your needs and the solution(s) proposed.
  
  
• Notify services firms of your selection decision.