Previous | Table of Contents | Next |
Similarly, the consultants lack of knowledge of an organizations culture can be both positive and negative. On the positive side, they may be unencumbered by the organizations 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.
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 organizations computing environment | Unfamiliar with organizations 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 shouldnt 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.
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 dont mean to delve into issues of Freudian psychology. The issue is more a focus of an individual team members 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.
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.
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 |