| Previous | Table of Contents | Next |
Just as you should clearly define where you are headed, you should also define your timeframe. Some SGML projects can be planned, designed, and put into full production in two or three years. Others, more broad in scope, can span 10 or 15 years and be an integral part of an organization’s central strategic direction.
Your timeframe can have a central bearing on some of the decisions that you make in implementing your SGML system. For a larger, more ambitious development project, you might want to consider rapid prototyping across a range of document types or with several SGML implementation teams.
Your document production environment and related organizational factors can have key impacts on how you implement your SGML system. Oftentimes, a combination of your environmental factors will work together to necessitate a specific approach in how you implement SGML into your organization.
For example, suppose that your company has a dedicated publications department that produces a range of technical publications. You are using an older publishing package with which the staff is quite comfortable. The personnel in the publications department are quite accomplished writers, but generally are not highly sophisticated computer users.
In this case, you might want to stay with your existing production systems and opt to convert the document output to SGML after the actual production phase. Using this approach, you could minimize the impact of change on the organization compared to the introduction of new software systems for producing documents via structured SGML authoring.
In another circumstance, you might actually be seeking radical changes in the way that you do business. In this situation, you might include a major work process redefinition as part of your SGML initiative. Some common environmental factors that can come into play when introducing SGML are:
The team that you assemble to implement your SGML project is the single most important ingredient for your project’s success. How you put it together is, therefore, a critical element to the process.
In short, diversity in your team is very important. A broadly based team can give you a wide perspective on the role of the documents that you will be converting into SGML, the factors that come into play when they are produced, and the environment in which they are used. All of these issues can be important to you as you go about designing, constructing, and implementing your SGML system.
As you put your team together, strive to include all the players. Include the writers of the documents that your SGML system will process. If there are other departments “upstream” that produce the content with which your writers create these documents, include them.
Whenever possible, include representatives of the “end user” community, those who read (and use) the documents. “Not so easy,” you say. “I can’t involve outside customers in this project.” Well, maybe not, but there are other alternatives. In the case of operations and maintenance manuals, your company might have field personnel who also use them. Individuals in your spare parts organization might use your illustrated parts lists on a daily basis. In short, you can often find “customers” much closer at hand than you first realize. Table 23.1 lists some of the knowledge that your team can gain from individual members.
| Team Member(s) | Knowledge They Bring |
|---|---|
| Content “Owner” | Accuracy of data sources and schedule of data availability |
| Writers | Production schedule and volume, current tools and methods, authoring process, and document structure |
| Readers | Document usage(s), desired changes to documents |
| Computer Personnel | Existing computer infrastructure, current computer-based authoring tools |
| Marketing Personnel | Customer desires and preferences |
Involving a wide variety of players on your team need not mean having a cast of thousands. In fact, you will want to balance a variety of perspectives with a manageable team size. But the benefits of having diversity on your team usually include the chance to gain a rich understanding of the roles that your documents play in your organization.
On the computer side, the question comes up as to whether you use in-house personnel or outside consultants. You might think that the question is easily answered if your in-house information systems staff does not have SGML experience. As with many things, however, the answer is usually not decided so easily.
As is illustrated in table 23.2, there are pros and cons to using both in-house staff and outside consultants in your SGML projects. While the in-house staff might lack SGML experience, they are committed to making it work over the life of the project. The consultants’ experience in a range of SGML projects will bring a valuable perspective to your team, but they may also bring in biases from previous experience (which may or may not be applicable to your situation).
| Previous | Table of Contents | Next |