11
Finishing the Implementation: Following Up

This is the phase that in reality never ends; there will always be new users to train, new systems to incorporate, and new management to sell. However, time is finally a friend, and that fact has to do with the phenomena of inertia and momentum. There is a natural tendency to continue almost anything that has been established as an important way for us to be spending our time and effort. It is much easier to persist at a current endeavor than to stop and seriously consider whether or not this is still a valid way to proceed. The act of questioning makes us very uncomfortable because we may discover that whatever we are doing is no longer meaningful. Then we are faced with the possibility that we are wasting our time, which is certainly not an agreeable thought. Consequently, almost never do we initiate this type of reality testing—nor do we tend to react favorably when others initiate it for us. Our tendency is to let things to go on as they are.

This tendency on the part of your users will be perceived by you as the agent of change as inertia during all the phases up to and including implementing change. On the other hand, during the follow-up phase, the tendency will be perceived as momentum because just as it was difficult to get things going, so it is also difficult to stop them once they are in motion. We certainly experienced the phenomenon of inertia during the early phases of our Excelerator implementation. Not only did we assess the situation, analyze the product’s projected benefits, and sell them to many people, but the paperwork we completed was quite extensive. We prepared feasibility studies, a business case, a capital appropriations document, and the details of a budget. For each document we prepared, we had to interact with a different group that was providing the coordination function. The combination of document preparation and people interaction consumed considerable time and patience, and these events occurred when we still had other assignments. However, once we had obtained the commitment of management and a core of faithful users, we also experienced the momentum phenomenon. For example, although we were suffering from the effects of cutbacks in our department, our group did not suffer any reductions; in fact, our staff size even increased.

Our management had expended substantial resources in terms of time, people, and money and was not particularly interested in reevaluating that decision at a time when we were making noticeable progress. Our users demonstrated a similar lack of interest in any type of reevaluation when a centralized methods group recommended a different tool as our corporate standard. This recommendation occurred during the follow-up phase, when many of our users were feeling quite comfortable with the tool and beginning to enjoy its benefits.

You should feel very satisfied and proud because you have completed all the other phases of implementing change (see Figure 11–1). Due to the phenomena of inertia and momentum, you can relax a bit, knowing that you will now have substantial opportunities to complete the change process you have set in motion. Indeed, in the months ahead it may seem that change is happening a bit too fast. (In the next chapter, we will point out pitfalls to avoid and ways to combat the momentum.) Having described the existing climate of your organization (and yourself), let us look now at the particular activities you will want to pursue.

Figure 11–1 Implementing Data Management.

Training Your Users

One of the primary tasks of this phase will be the training of your user community. In earlier phases, you provided presentations, demonstrations, and generally informed them about the product, its capabilities, and its relevance to them. In other words, you supplied information so that they could understand and appreciate. However, that is not at all the same as providing sufficient detailed information and hands on experience using the product. There are several options that you might pursue to assist you with the provision of this essential service, and it will, as always, vary from tool to tool; however, here are some alternatives we have used successfully:

• Many vendors of the tools and techniques have a training center your users can attend.

• Often, these same vendors will bring the course to you if you have a substantial number of users to train.

• Most packages contain an in-depth demonstration or tutorial that will get many users started.

• Many vendors have developed extensive computer-aided instruction that you can purchase.

• Some vendors will work with the change agents to tailor a course to their specific environment.

• If your company has a training center, you can work with the vendor and your trainers to provide an ongoing course on the tool or technique.

• You can develop your own training course.

You must consider the particular needs of your users, your management, and yourself when you are deciding exactly which method is best for your implementation. The selection will depend on many factors. Here are some:

• The complexity of the product you are implementing• The quality of the courses that are commercially available

• The amount of money that is available in your organization’s budget

• The time your management is willing to allow for training

• The experience level and interest of your user community

• Your own interest and ability in the area of teaching

Although most of these training options are self-explanatory, several will profit from additional discussion. Based on our observations, utilization of the tutorial and computer-aided instruction should be seriously considered. These self-training aids can be so thorough and sophisticated that for data processing veterans and a highly motivated subset of your user community, they will be a sufficient introduction to the product. For example, Project Workbench has an exceptionally easy to use computer-aided instruction for beginners. Moreover, it is so comprehensive that more experienced users employ it as an on-line quick reference guide. For many of our project managers, this was all the training they ever received, yet they were rapidly able to become proficient and sophisticated users.

Bear in mind that budget money can be viewed creatively; the dollars for training may not have to come from the change process budget, but may be drawn from a more general training budget. This determination should be based on the general applicability of the training, because it may not be particularly specific to the productivity improvement. During the follow-up of our data management implementation, people began to seek and obtain training in data analysis and normalization. It was deemed that this training was generally useful to any data processing professional and thus had nothing to do with our budget. Moreover, in that change process there was no urgency on the part of our users or upper management, so time was not an issue.

Sometimes a combination of the various methods can be utilized to meet all the user, change agents, and management requirements. To offer a concrete example of how this was handled for at least one implementation, let us look at how we addressed the training situation when we implemented Excelerator. The first thing we did was to have the vendor give a two-day fundamentals course at our site. We arranged for each group in our organization to have at least one person attend the class. The intent was to supply enough trained individuals to act as seeds; they would then be in a position to train other members of their groups.

The teachers came and the class was taught in an informative and thorough manner; however, afterward we discovered that there were two problems with the way we handled that particular training class. Although the teachers were quite knowledgeable about the tool, they were ignorant about our particular environment. There was no way for them to relate the subject matter to our mode of operation, and many of the students were unable to absorb the material and simultaneously discern ways to apply this knowledge to their jobs. The other problem was related to the diverse abilities and experience levels of our users. The course material covered considerable ground, and what we observed was that the advanced students were bored on the first day, while the second day was beyond the comprehension of the less experienced users.

The technique we used to solve this problem involved one of the other alternatives. We obtained the course materials from the vendor, and with its permission developed our own workshops. This technique allowed us to include numerous real examples illustrating ways to employ Excelerator advantageously in our organization. We also divided the course into two one-day workshops. The fundamentals workshop focused on what a user would need to get started, and the advanced one covered sophisticated topics for the more experienced individual. Dividing the course into one-day workshops had the additional benefit of being less disruptive to the ongoing work of our user community. We found that most users and their managers did not mind sacrificing one day on the job, but they did begin to pause and consider consequences when we asked for two days.

We gained considerable expertise in the area of training while we finished up our implementation of Excelerator. Although we did not offer any diversity initially, by the time we were into the final stages of this effort, the choices available to our users were elaborate. When there was a new release, we had workshops that described the enhancements and how they differed from the earlier version. We had workshops targeted for specific functional groups, such as planners or programmers, since their application of the tool was perhaps not as obvious as that of the systems analysts. There were half-day sessions focused on a particular feature of the product, such as documentation preparation or utilizing the report writer effectively. Completing the tutorial was a prerequisite for the fundamentals course, but we found that many users had trouble setting aside enough time to do so. Therefore, we instituted a tutorial day. We set up half a dozen PCs in a conference room, and a member of our group was constantly in attendance to answer questions. Many users found this a more effective and pleasant way to complete the requirement.

The final chapter in the Excelerator training saga is that since the tool did gain substantial popularity throughout the company, the vendor and some of our corporate groups negotiated a deal. From our perspective, one result of the negotiation was that the course became part of a standard training curriculum. This was a tremendous relief for my group, as we were not particularly interested in becoming teachers.

Before proceeding with other activities of this phase, let’s summarize some of the more important aspects of training:

• Training is one of the primary tasks of this phase.

• There are many options available to assist you in providing this service to users.

• The options you select will depend on the product, your organization’s budget and time constraints, as well as you, your group, and your users.

• It is likely that you will offer a combination of the alternatives.

• By the end of this phase, you and your group will be quite sophisticated as trainers.

Becoming a Support Group

If your product is a tool, there will be software support issues that you will have to address at this stage. During our Excelerator implementation, these activities became part of our daily lives. Let’s look a little more closely at exactly what that support entailed. We did all the installations on all the PCs for our entire department. Since some of our users were quite inexperienced in technical matters, our installation usually began with a determination of their hardware needs; they might need a mouse or additional memory chips. If they did not have PCs, we facilitated this also; we would, for example, place an initial request with the group responsible for procuring equipment.

We found ourselves supporting not only Excelerator, but also MS-DOS and MS WORD, because it was seldom obvious to our users where one package ended and another began. At particularly frazzled moments it did occur to us to be more rigid about our duties, but we had begun our implementation with a service approach, and we continued it until the day we were reassigned to other jobs.

Since the follow-up phase extended through several releases of the package, we were also responsible for the upgrades. As our user community grew and their use increased, we began to perform some local quality assurance during releases before upgrading our users to new versions of the product. By that time, our staff was substantially larger, so this was an additional service that we were comfortably able to offer.

We also began to serve as trouble shooters. If any user had a problem, we were the first line of support. If we did not find a solution, we were the ones who called the vendor’s hotline. This was quite overwhelming at first, but actually turned out to be a reasonably easy service to supply. There was a core of problems and corresponding solutions that occurred and reoccurred, and within two weeks there were very few questions we could not answer immediately. By the end of this phase, the vendor had instituted a formal program that facilitated these interactions. The program assisted groups such as ours which functioned between our users and the vendor’s support groups. They provided us with supplementary documentation, bug lists, and priority hotline service.

Let’s sum up the activities associated with supporting a productivity tool:

• Determination of associated hardware requirements and facilitation of their acquisition

• Initial installation of the software and all upgrades

• Installation of related software

• First line of support for problems

• Quality assurance when new releases occur

You Will Make Mistakes

After the initial round of the workshops and numerous installations of the tool, we encountered some new and unsuspected sources of resistance. One instance revolved around the fact that many of the projects required additional attributes that were not available on the Excelerator element description form. It was not a question of each project needing different fields; they were all used to the same form of documentation, which included this information. Needless to say, we were worried; these were projects none of us had personal experience with, and somehow we had just overlooked this documentation type.

This story does have a happy ending because the vendor customized our user interface to include the additional fields. Our new users had fields for all their information needs, and the rest of our user community could ignore or use the new fields at their own discretion. This was certainly a shining example of enabling our users to be comfortable as the primary mode of overcoming resistance. There is another point being made here, and that is that anyone can (and will) commit a serious oversight, and this is no cause for a large-scale panic. You must calmly begin the search for a solution; you certainly are creative and resourceful, or you would not be a successful change agent. There is also a footnote to this story. In the midst of the customization process, the vendor replaced its logo with our corporate logo on the welcome screen. This small gesture may have mellowed the hearts of a few skeptics or it may not have; but I enjoyed it immensely.

Preparing Auxiliary User Documentation

Another goal that we recommend you accomplish during the early stages of the follow-up phase is to prepare a user guide. This document is not meant to replace any guide prepared by the vendor, which is meant to be employed when users are becoming acquainted with the tool or technique. Your user guide will be a supplementary document for survival in your specific and unique environment. A typical table of contents might be as follows:

1. Introduction

2. How to Get Started

3. Who to Contact

4. Standards and Naming Conventions

5. Change Control

6. Version Control

7. Roles and Responsibilities

This document should be quite easy to prepare. After all, the basis for virtually all the information it will contain has already been developed by you, your group, your interproject team, and your users. Another point worth mentioning is that this should be a living document because you are committed to never developing standards, naming conventions, etc., until they are actually needed.

Forming a User Group

Another pursuit you should seriously consider is the possibility of forming a user group at this time. User groups can be a powerful means for keeping the change process progressing in a vital manner. Below is a list of a few of the benefits to be gained from the formation, operation, and continuance of such a group:

• The group provides an effective means for obtaining information.

• It offers a vehicle to communicate your opinions, beliefs, and experiences to a large audience.

• There will be opportunities for beginners to learn from the experts.

• A user organization can establish a channel for sharing associated products, such as user-supplied software.

• The sharing that takes place can include unresolved problems users encounter.

• The group can present a strong, united, collective voice to the vendor.

Certainly there will always remain areas about which even the most experienced user would like more information. The advanced user will hear about unique and interesting applications of the tool and perhaps receive information about training that will be offered locally in the near future. The beginners (who may be experiencing severe problems or don’t even know how to get started) will be heartened by the success stories of others. You can also take advantage of the chance to extend your informal network; there is, after all, no reason to limit it to your company.

One user group to which I belonged established a user software library. Users were encouraged to donate routines they had developed to enhance the capabilities of the tool itself. These routines were made available to other users free of charge. We even sponsored a contest to boost the rate of software submission. I’m not sure how well we succeeded in our encouragement, but it was fun!

The last items on the list are probably the most important of all. It is critical that the user group arena be utilized to share not only success stories, but also the problems or even failures users encounter. It may well be that another user has had a similar disastrous experience. Moreover, she may have figured out a way to resolve the problem, which she can then share with the group. If there is no resolution, the group can present a substantial and loud protest to the vendor. This collective voice to the vendor leads directly into the final item on the list. It is certainly true that the group can be a powerful and effective lobby to achieve common goals in connection with the vendor. However, this may seem quite negative, considering that most of our experiences have indicated that vendors do actually welcome opportunities to have users’ needs clearly communicated.

Now that we have convinced you there are some definite advantages to be gained by the formation of such a group, let’s turn our attention to how you might accomplish this task. Since I was once involved in the formation of a local user group, the details of its history will be immediately shared. After conceiving the idea, the first thing I did was mention it to my current boss. This man was a very bright and enthusiastic individual, and consequently was quite taken with the idea. Moreover even though I was extremely busy at this time, he encouraged me to reserve some of my energy to pursue this possibility.

With his solid support behind me, I approached the vendor’s eastern region sales manager, Paul, with my idea. I wanted to determine if he was interested; and if he was, how much support he would give to the effort. He was an experienced data processing individual with exceptionally astute and progressive views. He immediately and fully grasped the benefits for us all. Paul and I drafted a letter stating the possibility of forming a local user group and soliciting interest. He had his clerical support staff prepare the letter and mail it to all current and potential users in the NY/NJ metropolitan area. We decided that we would both sign the letter to indicate that the group would be a joint endeavor of the vendor and user community. The response was overwhelming; apparently many people were able to perceive the usefulness of such a group.

We set the date for the first meeting, reserved a conference room, and began to plan the agenda. We decided to have several users share their experiences, and we elected to have a few people from the vendor company speak on topics such as features planned in the next release. Paul’s staff prepared and mailed the invitations while I, who was to give one of the user presentations, began to prepare for the event. The user group got off to a very nice start, and to the best of my knowledge is still active today. The group meets about three times a year, the users take turns providing the room, and the vendor’s staff still prepares and mails the meeting notices.

Here is a list of steps we recommend you follow to form a user group:

• Obtain management sanction for your endeavor because of the initial expenditure of effort on your part.

• Solicit the cooperation and support of your local vendor representative.

• Determine if there is sufficient interest on the part of the local user community.

• Arrange the first meeting with speakers representing both the users and the vendor.

• Maintain group continuity by holding meetings several times a year.

• Share the responsibility by rotating the hosting of meetings among the users, and arranging for continuance of support from the vendor.

Your Role as a Consultant

Thus far we have described several major activities that you will perform during the follow-up. There is an additional one that will be a critical success factor. Several months into this phase, you will begin to assume the role of consultant; in that capacity, you will present multiple services. You will consult to individuals, groups, and all levels of management. The most conspicuous aspect of this role is that you will be a paradigm of flexibility. For example, we provided individualized consulting to users who had taken the workshop, were ready to apply the knowledge, but were still unsure. One of us would spend several days with him, while he began the definition of enhancements to the next system release. Following that initial period, he might call us about once an hour for a week. Then the calls would become farther and farther apart. Finally, several months later, we would hear that he was consulting for another project!

We might approach a group and offer to help them use the product to perform their present assignment. We promised that we would work with them so they could accomplish it at least as fast as they always did. If our claims were even half true, they would complete the task in substantially less time. Our hope was that the next time they wanted to use the tool, they would probably not need our help. Did every group we approach accept our offer? Of course not. But there were certainly enough interested users to keep us busy. That was the most gratifying aspect of the follow-up phase; there are so many ways to continue the implementation. If you approached one group of users and they were disinterested or too busy, you could approach another group who was already amenable. Once the interested group began exhibiting some improvement, the first group you approached may well perceive some benefit, and find some time after all to become involved.

Residual Resistance

I would be untruthful if I did not admit that there were some individuals we just could not convert. They obstinately refused to even consider the possibilities, and continued to find problem after problem with the product. They did not understand what was wrong with the way they were currently doing their job. They were much too busy to spare even an hour to allow us to provide information. They thought the tool was far too expensive. (Since this comment was made a year after purchase, it was particularly irrelevant.) There was even one fellow who wanted to rewrite the user interface not because it was inadequate, but because he could do it. Moreover, most of these people were intelligent and aggressive, and many had considerable personal power in their groups.

If it was at all possible, we ignored the unconverted. After all, we had plenty of people who were interested and we were still few in number. When our director inquired about how we were handling the users who still exhibited considerable resistance, I told her not to worry about them. They would have to join us eventually, because ultimately there would be no other choice left. Some of these people we outlasted; they transferred or changed companies. In the case of a very few, their managers exerted considerable pressure and they did finally participate. There is no solution to this problem; you will just have to face some failures. It does not mean that your effort is not still a smashing success, but only that change agents are human beings not magicians.

The Strategy Meeting

One of the most successful means that we utilized in our consultant role was the strategy meeting. We would invite a project team to meet briefly with us for the following purposes:

• To ensure that they were fully aware of the value of the tool

• To allow them the opportunity to review all the information already available that could be used via the tool

• To allow us the opportunity to examine all the documents they were currently utilizing to help develop their system

• To jointly set a strategic direction for them to gradually incorporate the tool without disruption

At a typical meeting, they might discover that all the screens for their user guide had already been entered into Excelerator. This fact would certainly cause them to consider seriously the appropriateness of using the tool at this time. Usually they would bring every document they used as a development aid to the meeting, and we would go through every one page by page. There would be an exchange of ideas about the feasibility of using the tool for each portion of each document at this time. We would almost always recommend they use the tool for the record layouts, the screens, and the reports. Furthermore, we would point out how the data flow diagrams could be used to depict their functional requirements. But if they were not thoroughly familiar with the technique, we would also recommend they delay that use of the tool until their next release (and accompanying definition phase).

We were this cautious because we had not forgotten the principle of ensuring a series of small successes. There was also an element of the comfort factor at work. It was certainly a goal that each use of the tool should be accompanied by a corresponding increase in user confidence. We did not even hint that anyone should change the format of their documentation; every project still retained its individualized approach to system development. But we did offer some consistency in the piece parts that comprised each document (see Figure 11–2).

Figure 11–2 Regulation Bricks Ensure Consistency of Information Content but Allow Documentation to be Individualized.

The analogy of building houses is a good one. If one group preferred colonial style, they would still be building a colonial; if another group liked California ranches, they would still be building a ranch. What was new in the process was that everyone would now be building the foundation with regulation bricks that were the same size, color, and weight. The main aspect of this situation that facilitated the steady progress of the change process was that the documentation looked almost exactly as it always had to the systems analysts, the programmers, and the users. There was no abrupt and disruptive change; it was as always before in the process: unfaltering, smooth, and gradual.

During the implementation phase, we indicated that at the beginning of the follow-up phase you would have a small core of dedicated users. Furthermore, there would be a widespread belief throughout the organization that your productivity improvement was available and thus a part of the current environment. But we warned you not to deceive yourself into believing more has been accomplished than actually has. For example, the majority of the people will smile approval at you and your group, but proceed as they always have. We have also indicated that a certain level of disinterest is really not a problem, because you and your group are still small in number and there will be enough interested users to keep you very busy.

During the first stages of the follow-up phase, we have described many techniques you can employ to increase your user base. This should be a pleasurable part of the process; you will not be pressed to deliver specifics in a short time. You will have the luxury of selecting the groups you will work with. The fruits of your labor should begin to be apparent. In general, you will be solidifying your success. You earned it and you should enjoy it, because there are still some significant hazards ahead.

Summary

• This is the phase that never ends because there will always be new users to train and new managers to sell; however, due to the momentum of the change effort, there will be plenty of time to accomplish any task that needs to be done.

• One of the primary tasks of this phase will be teaching, and there will be a number of alternatives available.

• If your product is a tool, you will find yourself in the position of supporting the software itself as well as associated software and hardware.

• Consider the possibility of developing a user guide which will document aspects of the change that are particular to your specific environment.

• The formation of a local user group is an effective means to keep your change process vital. It will afford an arena for information sharing and collective communication with the vendor.

• Considerable time and effort will be expended during this phase in your role as a consultant; one of the most powerful techniques you will utilize will be the strategy meeting.