Previous Table of Contents Next


Before the Consultants Come

The more prepared you are for the consultant, the more value you’ll get for your dollar per hour after he arrives. Most of what the consultant does depends on understanding your operation. If you can clearly communicate to the consultant what he needs to know, you’ll make his job very easy, and your checkbook will reward you (it won’t deflate as quickly). You should try to do three things before the consultant arrives: define your project, understand your essential document structure, and examine your legacy data issues.

Defining Your Project. You’ve chosen SGML because of the value it can add to your documents. You need to know which benefits you are most interested in. Which benefits are necessary and which are simply beneficial? For example, do you need to electronically deliver documents to your customers over a network? Must you publish books on CD-ROM? Will you need to query a database of SGML documents? You need to be able to list all the uses for your SGML documents so the consultant doesn’t overlook any design features that must be built into your operation.

Understand Your Essential Document Structure. The difficulty here is that if you’re hiring consultants in the first place, you’re probably a fairly large operation, and you may be a manager who is not intimate with the documents you need to deal with. If you are very familiar with the documents, that’s great. But if you aren’t, you either need an in-house expert who is, or you need to become familiar with them yourself.

You’re probably safest by both becoming as familiar as you can with the documents, but also involving your in-house expert(s) as early in the SGML process as you can. When the consultant asks questions like, “Do your service bulletins ever omit effectivity coding?” you must have the right answer. If you don’t, you’ll be wasting valuable time. And if you try to guess your way through and give a less than accurate answer, you could cause a bigger problem that you’ll have to pay to resolve later.


Tip:  
If you must depend on one or more in-house experts, make sure they will be available to the consultants at any time. This may require you to reschedule their other responsibilities to allow them the flexibility they’ll need in their schedule. Try to keep several people “up to speed” with your SGML project to prevent delays due to sickness, vacations, and so on.

Understand Your Legacy Data Issues. One thing your consultants will want to know is how much of your old data (legacy data) needs to be converted to SGML documents.


• See “Tricks, Traps, and Pitfalls,” p. 103

Legacy data can be challenging because of gross inconsistencies between older documents and newer documents. For example, a service bulletin could appear nice and orderly if it’s a current vintage. But if you intend to scan in service bulletins from 15 years ago, you’ll run into instances where they don’t even look like the same type of document. They could have been typed on manual typewriters, and there might not have been any authority for style and structure. So, heaven only knows how many variations you’ll have to account for in your DTD if you insist on dealing with very old document types. Your consultant will want to know how intent you are about converting old data. It will make life much easier if you are able to omit converting very old documents.

After the Consultants Arrive

By doing the preparatory work above, your time with the consultants will be very productive. Your initial meetings will be smoother because you have a specific project definition. When the consultant asks detailed questions about the documents and their structure, you’re ready to give accurate answers. And when the question of legacy data comes up, you’re clear about what document conversion you need and what would be merely convenient.

Consultants need some specific guidelines for their relationship with you during your project together. You’ll need to agree on specific performance objectives and when they’ll be completed. The following are common points to agree on:

  Develop mutually agreeable milestones
  Agree on test and acceptance criteria
  When converting existing documents, agree on how you’ll handle data that does not conform to your normal document structure
  When starting an SGML authoring process, expect to establish a long-term relationship with consultants; you’ll need one, because it takes time to become confident in SGML


Note:  
One of the first things the consultants want to see is your document samples. Try to take them into your library so they can examine a range of samples of each document type. Be sure to include a lot of old documents if you plan on converting them. Show them the ugly old typewritten service bulletins as well as the brand new service bulletins with the fancy tables. The only way to ensure an adequate design is to have a large document sample for each document type.


Previous Table of Contents Next