Previous Table of Contents Next


Similarly, the consultants’ lack of knowledge of an organization’s culture can be both positive and negative. On the positive side, they may be unencumbered by the organization’s traditional mind set, willing to propose and examine radically new ways of doing business. On the negative side, they may be unfamiliar with organizational issues that are critical to the successful implementation of new systems.

Table 23.2 SGML Information Systems Staff Issues: In-House vs. Consultant
In-House Information Systems Staff Outside Consultant
Lacks SGML experience Experienced in SGML systems
Unencumbered by previous SGML experience Subject to bias based on previous SGML experience
Will be around for the “long haul” Short involvement cycle
Understands the dynamics and workings of organization Lacks in-depth organizational knowledge
Familiar with organization’s computing environment Unfamiliar with organization’s computing environment

Even though information systems or computing staff involving in-house resources or outside consultants is often looked at as an either/or issue, it really shouldn’t be. When starting an SGML project from the ground up, you normally can benefit from having both on your team. In many respects, they can be used in different (and complementary) ways, with the consultant serving as an outside tutor and facilitator and the in-house staff being the team nucleus responsible for bringing about the implementation of your SGML system.

Team Member Personalities

As with most human endeavors, the personal quirks of your team members will add to the richness of your experience. But when talking about the personalities of team members, I don’t mean to delve into issues of Freudian psychology. The issue is more a focus of an individual team member’s attitude toward technology.

In some projects that I have worked on, team members were selected (at least in part) on the basis of their enthusiasm for new technology. In these cases, it was felt that the “skeptics” would only slow a project down because of their resistance to new technologies and methods.

To put it simply, this philosophy should be avoided whenever possible! Just as you want balance in your team from all the areas involved with your documents, you also should seek a balance between the technology enthusiasts and the skeptics. They both have a contribution to make.

In most organizations that I have seen, there is a fairly wide range of attitudes toward technology. Because they will all be living with the system that you develop, they should all participate in its development. The skeptics, in particular, often provide a useful function in pointing out flaws in your approach that might otherwise be overlooked by the more enthusiastic participants.

Conversely, the most skeptical participants in your project can often become the biggest proponents of your system once they are convinced. As a result, the extra time that it might take to win over the skeptical members of your team can be time extremely well spent. Their skepticism will often serve as a useful sanity check on the practicality of your SGML system design and implementation.

The Dynamics of Participation

To gain the maximum benefit from the combined talents of your SGML team, it is helpful to remember a few central concepts. By following them, you will encourage enthusiastic participation by all the members.

  Concept #1 is that you should arrive at decisions by consensus whenever possible. In the early stages of your team’s work, it might seem to take forever to reach decisions. Persevere! This extra time spent up front can pay great dividends if it convinces the team of the importance of each member’s contribution. Often, in long involved discussions of particular issues, a resolution might, at last, seem to be at hand. Just as a decision seems to be reached, however, a quieter (and perhaps more thoughtful) participant might make a seemingly small comment or observation that throws the whole decision into doubt. This is a common part of the consensus-based decision-making process. Using this approach, you have the best chance of covering all of the significant issues involved in developing the optimum SGML solution for your organization.
  Concept #2 is that you must strive to maintain the pace. (Although it may sound somewhat at odds with concept #1, it really isn’t.) This concept really means that each working session of your team should be focused on reaching specific objectives. While the consensus-based approach might result in an unpredictable schedule for reaching individual objectives as you examine all the intricacies, details, and nuances involved with a particular issue, this second concept ensures that you accomplish the objectives that you set for each team meeting.
  Concept #3 is that you empower your group to make decisions and judgment calls. If you have put your team together to benefit from its collective knowledge, wisdom, perspective, and experience, make sure that you use it. If your team is not empowered to make decisions, it will probably quickly tire of the process, deciding that it is a waste of time.

An SGML consultant with good skills as a facilitator will pay dividends in the teaming process. By emphasizing these concepts, you will be able to aid your team in designing the optimal SGML solution for your organization.


Previous Table of Contents Next