[Previous] [Next]

Assembling implementation teams

Many experienced system developers and implementers say that a system's implementation is the phase where the most discipline, planning, and leadership is required. There are several reasons for this:

• it is very difficult to back out once implementation has actually begun, so a premium is placed on planning for this stage;
• the system is now quite visible to the campus community and is on trial in some ways; and
• decisions will need to be made that cannot be deferred for very long, placing great reliance on the judgment of the project management team.

• System integration team
  A system integration team will be necessary for the implementation phase of the project. If the system is purchased or co-developed with a vendor, the team should include functional, technical, and vendor representatives. Functional and technical representatives alone will constitute this team in the case of an in-house-developed system. Where other options for acquisition have been selected involving one or more institutional partnerships, much more complicated coordination will be necessary at this stage. Usually each institution is implementing the system for its own campus community, and it is during actual system implementation that differences begin to emerge from institution to institution. This is especially true if the partnership involved a co-development effort among the members of the partnership. As is the case with the project in general, the functional unit must take the lead role during implementation and arbitrate any problems that arise.

  The primary areas of responsibility for the technical members of the integration team are the application, network, and hardware components of the system. The version control of the application will need to be carefully managed, especially at the beginning. Is the application to be launched from the local hard drive or from a file server? With hundreds or perhaps thousands of potential users, version control of a client/server application is a major administrative challenge.

• Training team
  Almost certainly, the functionality of the new system will be different enough that users will need to be trained. Additionally, the technology used may bring with it the requirement for a separate training program aimed just at that. An example of this might be a switch from terminal-based systems to one using a graphical user interface (GUI). If the new system is based on client/server technology, there will be a considerable learning curve for both the technical support team (see below) and the users on just the hardware and software from a look-and-feel standpoint.

  Depending on the scale of the project, it may be necessary to assemble a team of trainers. At a minimum, a training coordinator needs to be identified from the functional area and, if possible, assigned this responsibility at the start of the project, perhaps even to the extent of participating on the project management team. There is a tendency at times to shortchange this implementation area by putting lower-classified personnel on this team. At least initially, the most knowledgeable functional people available should be selected for this training role. Key system designers are obvious candidates, provided they have some requisite training skills. This may seem wasteful at first glance, but most users' first contact with the system will be in these training sessions, and it will be vital to their ultimate acceptance of the system to make this a successful experience. The in-depth knowledge of the design that these key players possess will ensure that the inevitable difficult questions will be answered by those who have the best grasp of the system.

  After the system is stabilized, other staff can assume the training duties. The one caveat about this relates to the level of staff being trained. Users usually relate best to someone who is at their level of responsibility. This is a credibility issue as much as anything.

  The training team needs to work side by side with the documentation team described below. There may be some complementary possibilities here. Trainers will eventually have some of the best knowledge of the system and how the users have to learn it, and documentation staff will at least have the knowledge of the proposed functionality. There may well be a very blurred line between trainers and documentation staff, and the same people may do both. One way to ensure good documentation is to have an instructional technology specialist write or review the training material.

  The training coordinator will need to handle training logistics such as facilities, equipment, and scheduling. This needs to be an individual with considerable initiative and resourcefulness unless the institution has designated a substantial budget for training. The training and customer service responsibilities are often commingled, and in fact doing this can foster a very effective environment. Obviously the knowledge and experience gained in each area complements the requirements of the other area. Staff can rotate such assignments and build a very effective and knowledgeable team.

  The institution needs to be prepared to establish this team as early as possible in the project and leave it in place for a considerable length of time after implementation. New staff will need to be trained and existing staff will need both refresher courses and training on new functionality that may be added over time.

• Technical support team
  Depending on the nature of the system (especially, for example, when making a significant technology change), there may be a need for a technical support team in addition to the primary functional training team and program. For example, in a client/server implementation, such a team will support the technical support personnel in the units more than the actual users, because there is a significant system configuration dimension to a mission-critical client/server application that the average user may not want to manage alone.

  In addition, central technical staff will also need training. The most significant land mine discovered by Lafayette College in a recent systems implementation that involved new relational database technology was not devoting more time to the training of computing staff in the new technology in advance of implementation. Their experience highlighted for them the importance of taking time prior to implementation to "train the experts to be experts" so that they can later concentrate on learning the new modules and helping users.

  If the system is vendor-developed, the vendor may be able to provide training and support materials for technical staff members. On the other hand, if it was developed in-house, there will be a greater burden on technical support staff, because they will not have prior experience to draw upon. This is usually the case in mainframe-based systems, but it is far more significant in the case of a client/server application. The fundamental reason for this is that there are significantly more points of failure in the latter. Dumb terminals never needed configuration. There was only one version of the software operating. The network was rarely stressed, especially if it was a proprietary network implementation. In a client/server scenario, however, every user device is operating the client system, even if the latter is served from a central server. There is also a much larger network burden, both in terms of traffic and in network complexity. All of this places a huge burden on the technical support team.

• Documentation team
  As with any complex system, documentation is a necessary but sometimes neglected aspect. In this era of electronic publishing, online help, and World Wide Web hypertext capabilities, there is increasingly less excuse for not providing good documentation, and it is difficult to imagine a modern system being implemented without it. Training alone will demand it, and documentation should be seen as an integral part of the training process. Vendor-supplied systems will presumably come with documentation, but there may still be a need for local customization of these materials. If the system is developed in-house or in a consortium, the documentation demands will be enormous. They will easily consume a full-time employee for the period preceding implementation through complete deployment of the system.

[Previous] [Next]