10
Implementing Change

We have finally arrived at the pivotal point of the entire change process; the previous phases have been essentially a preparation for this, and the subsequent phases will consist of the lengthy and sometimes monotonous tasks of finishing up. This is the phase during which you will travel across the bridge from the familiar, comfortable, and less than optimal world of today and take the first tenuous steps into the modern and interesting environment you have envisioned. It is no accident that we use the expression “first tenuous steps,” because the manner in which change is effected is a series of small, steady steps.

There will be no overnight miraculous and dramatic improvement in productivity, but rather a gradual and sometimes almost imperceptible acceptance and adjustment on the part of your users. Finally one day it will be clear to users and management alike that there has been a definite change. As they reflect on this fact, it will also occur to them that this is a desirable situation and that they are proud to have been a part of it. That they have indeed been a part of the process is unquestionably true because their participation and involvement is what made it a success. As an agent of change, one of your most valuable functions in all phases is to enable your users to understand and appreciate the productivity product, and then feel comfortable enough to incorporate it into their lives.

Facing the Insurmountable

Up to the present, you have been assessing, selecting, evaluating, selling, listening, analyzing, and planning, all of which has allowed people many opportunities to understand and appreciate what you are doing. Now you will begin the process of actively modifying your organization. This can be an exhilarating thought, but it may also be quite overwhelming. It can be a moment of substantial self-doubt: Can I really get all those people to use Project Workbench, or can I really load all the data into the dictionary? It is understandable that the job might seem insurmountable, and because of this fact, many change agents just cannot get started. However, take heart, because we have practical and reliable techniques to share for this phase too.

First, in order to restore our confidence, let’s examine the timeline provided in Figure 10–1, which provides an example of the data management implementation. Each phase is charted, along with the month and year that it was completed or slated for completion. (Please note that specific months and years are for illustrative purposes only). It is reasonable to be impressed by the fact that from the very beginning, when we were assessing the target area, up through now, when we have completed our detailed plans, only 8 months have elapsed. A great deal has been accomplished in a very short time. Moreover, there have been considerable achievements on the intangible side; many users are already converted, and the implementation proper has not even begun.

Now that you are ready to begin, your very first activity is actually to face the fact that the task is truly insurmountable! It is not possible for you and your small group to modify (or in some instances reverse) the current mode of operation of all the individuals in your organization. Nevertheless, the situation is not hopeless, because the way to resolve this apparent paradox is to divide the change effort into manageable chunks. You cannot change everything for everyone on day 1 of the implementation phase; you must set some reasonable limits and realistic goals. When you reflect upon the concept of manageable chunks, you will realize that many activities you performed in earlier phases were designed with this idea in mind.

Figure 10–1 Implementing Data Management.

Remember when we set a course of direction during the gathering information phase? We spent considerable time and effort analyzing the situation and attempting to determine which alternative had the highest probability of success. We also emphasized this concept of searching for successes during the development of the implementation plan by the project team. In addition, we stated that selecting tasks that were quite likely to succeed was not enough; the team must select intermediate deliverables that can be completed quickly. Hopefully, this is exactly what you and the project team did when you developed a schedule. Finally, given the fact that the task as a whole is insurmountable, the scope of your implementation must not be excessive at any one time.

An Apocryphal Tale

Truly, the most common mistake people make when they are attempting to improve productivity is that they undertake “too much too soon.” A typical scenario might be similar to the following apocryphal tale. In our fictitious department, the situation at the start was somber indeed. Not only had the systems been defined, designed, and implemented under considerable time constraints, but the staff had recently been substantially reduced and morale was at an all-time low. (This situation should seem familiar because it does match the profile of an organization ripe for change we described in Chapter 1.)

The change agents accurately identified a need for productivity improvement and then selected multiple tools and techniques to address the situation. They followed every step of every phase to perfection and the result of the planning phase was an impressive, comprehensive, and detailed schedule of activities and tasks. During the early stages of the implementation phase, all software packages and appropriate data were loaded onto the designated PCs. Members of the user community were sent to training classes for all the tools and techniques. However, when the users attempted to resume their everyday work, some serious problems arose. Since many days were spent acquiring all the necessary training, they were behind schedule on their individual development projects. Moreover, there was almost nothing familiar about the routine in which they performed their jobs because their manual mode of operation had been replaced with the installation of the tools. While they had been exposed to interesting information, how to apply that knowledge with their new tools and techniques under severe pressure was not obvious. Our crusaders were undaunted, because they were highly skilled in all the tools and techniques, understood the functions being mechanized, and were totally committed. But they were only three in number, and there were only so many hours per day. They could help only a limited number of users. The organization’s collective frustration expanded on a daily basis.

As the days went by, completing tasks on everyone’s schedules (projects and productivity improvement alike) became increasingly impossible. There had been no significant progress with the implementation of any one tool or technique, and everyone (upper management, change agents, and users) was thoroughly disenchanted. This sad end to our tale was in no way inevitable, because there were several critical success factors in place: the time was right, the tool and techniques were good, there was management support, and the change agents were both competent and committed. The disaster was caused by not being selective, not setting realistic goals, not carving out a manageable chunk, and generally attempting too much too soon.

The situation was further aggravated because the change agents did not reevaluate the plan when they encountered substantial obstacles. As we all know, it is often true that carefully prepared plans are never considered after they are completed. The up-front planning is usually demanded by upper management, but the tracking and controlling often get lost in the heat of the actual implementation. The message here is that you need to develop a plan that not only accounts for the tasks to be accomplished but also allows for unforeseen problems (remember the slippage capability in PW). As you implement the change, you need to monitor the plan to ensure not only that you are on schedule, but that each task still makes sense. There is absolutely no advantage to blind adherence; you need to constantly mentally apply sanity checks.

Let’s pause and attempt to distill some of the lessons we might learn from our apocryphal tale:

• The task of actually implementing the change is virtually insurmountable.

• The way to overcome this apparent obstacle is to divide the change effort into manageable chunks.

• It is not enough to develop a detailed plan: you must also check constantly during the actual implementation to ensure that you are on schedule and that each task remains relevant.

• The most common mistake people make during this phase is attempting too much too soon.

Do not delude yourself either, there are several very attractive reasons that lead change agents into this trap. The primary cause is simply ambition; the crusader has staked a tremendous amount on the success of the change. Thus it is extremely tempting to prove the worth of the mission by setting glorious goals. The flaw in this line of reasoning is that it is virtually impossible to deliver glorious results during a productivity improvement. Remember the twin objectives— search for a series of small successes (not one glorious end), and establish a set of intermediate deliverables (not the ultimate product).

Meet Each User on His Own Ground

Moreover, the manageable chunk axiom is important not only for your sanity, but also because of the fundamental philosophy of effecting a cultural change. Remember the main issue is overcoming resistance, and that is equivalent to discovering the concerns and fears of your users, and then enabling them to feel comfortable with the change process. If you begin implementation by presenting them with several productivity tools and techniques, panic is the only possible result. The objective is to change one aspect of their environment at a time. When people are accustomed to that improvement, then add another tool or technique (see Figures 10–2a and 10–2b).

Figure 10–2a Changing Multiple Aspects of the Environment at once Yields Chaos.

Figure 10–2b Incremental Improvements Yield Results.

For example, when we were in this phase of our ever so pleasant Excelerator implementation, our section was reorganized and I found myself reporting to a different boss. (This can really be a problem; we will cover unexpected reorganizations in Chapter 12.) Mercifully, this man came to us not only with an enlightened view of development, but with a high degree of belief in what we were endeavoring to achieve. However, he had begun his career in a more theoretical sector of the company and thus expressed concern that we had not planned to train all our users in structured systems analysis. His opinion (and rightly so) was that in order to maximize our benefit from the tool, people needed to become proficient in methodologies, such as those associated with data flow diagrams.

I assured my new boss that we had thought about the possibility of simultaneously training everyone to utilize Excelerator and become structured systems analysts. We had also discarded this option because we truly believed that the task of mastering either Excelerator or structured systems analysis would in itself provide a hearty challenge to our users. In reality, our user community was quite diverse in background; some people were already structured systems analysts, while others were untrained in any methodology. The course of action we adopted was one of flexibility. We did not set some artificial standard mode of utilizing the tool for our whole organization. An example of that type of approach might have been to mandate that no one was going to use the tool without first mastering the methodologies, which certainly would have placed a heavy burden on many individuals. Nor did we mandate that for the sake of consistency no one was to use the tool for any diagrams, which certainly would have set a senseless limit on the tool’s initial benefit to many people. (These possibilities are not ridiculous because we have actually been in situations where this type of mentality prevails.)

The approach we did take was simply “to meet each user on her or his own ground.” For example, if an individual understood structured systems analysis, we provided a copy of the tool and the minimal standards the project team had established, and then sent him off on his merry way. On the other hand, if the person was untrained in structured methods, he could still benefit from the integrated dictionary, and he could certainly understand the record layouts and screen design facility. Was he getting 100% benefit from the tool? No! Was he getting a 40% benefit from the tool? Yes! Surely a 40% benefit is better than 0; more important, he felt good about himself, the tool, and what he was doing. When he became really confident; then he could learn about the methodologies, and realize the tool’s total benefit.

We had been through the change process before, so we understood the significance of making our users comfortable and the importance of incremental improvement. We knew we only had to provide intermediate deliverables quickly. Finally, we knew that if we accomplished those three objectives; then we would be permitted the time required to implement our change in its entirety. However, you must not make the mistake of underestimating the difficulty of this flexibility. It is not a simple matter constantly to assess each individual and his or her relationship to the change process; and then tailor the implementation to suit the situation. But as with other techniques you must apply during the productivity improvement, it is a skill that becomes easier to use the more you utilize it. To capture the essence of this flexibility, let’s summarize the approach adopted during our Excelerator implementation:

• Effective implementation translates to manageable chunks for change agents and incremental improvements for users.

• Providing incremental improvements for users means enabling them to modify exactly one aspect of their environment at a time.

• The form that aspect will assume during the implementation will vary from user to user depending on experience levels.

• You provide that customized (and hence comfortable) situation for your users by exhibiting flexibility and meeting each user on his or her own ground.

Now that we have reviewed the fundamental tenets of actually implementing change, it is appropriate to discuss the steps that comprise it. There are very specific tasks that you will perform when you are actually implementing the productivity product: It is not merely a question of all the change agents charging about making all the users feel comfortable. After all, you and the project team spent considerable effort on the planning phase. Certainly the activities will vary considerably, depending on the product; however, there are aspects of this phase that you can depend on experiencing, regardless of what productivity improvement you are implementing. Some of these aspects are listed below:

• No matter how well you have planned, you will encounter unforeseen obstacles.

• You will utilize your informal network to surmount some of these obstacles.

• You will also capitalize on the information gathered about key people (situational leaders) to help resolve some of the difficulties.

• Dealing with these problems and the accompanying frustration is the heart of the doing phase.

• You must be prepared to deal with a renewal of discouragement and the accompanying self-doubt.

• The secret of success lies in utilizing your inherent abilities to form strategy and persist.

An Idyllic Tale

We want to provide you with a realistic view of the tasks that might be involved as well as how they might be implemented. We also want to describe some specific examples of dealing with the aspects of doing listed above. To accomplish these objectives, we are going to look at a case study consisting of the real events that took place during the implementation phase of data management. We have referred to the data management implementation several times thus far; now let’s examine the list below to understand the activities that took place prior to its actual implementation.

• In the past in our organization, there had been a departmental data catalog facility that had been discontinued during a major reorganization.

• The data for our systems was definitely out of control; elements had as many as three dozen known aliases in the logical views of the systems and hundreds of names in the programs.

• A definite need for data management was assessed and sold to upper management.

• A group that consisted of two people was formed for this purpose.

• There was a period during which we reawakened awareness of the value of data management in the minds of our users.

• We spent some time gathering information from our users and developed a course of direction (see Chapter 6).

• An interproject team was formed to develop:

Phased implementation plan
Schedule of activities
Standards and naming conventions
Roles and responsibilities

We, as change agents, had made a commitment never to interfere with our users’ very important everyday activities or slow down their progress in any way. Therefore, we decided personally to perform all the initial data analysis and then hire some temporary clerical support to enter the data into the dictionary. The first thing we did was gather all the documentation that existed about any system for which we were providing the data management service. The documents that we collected were these:

• User requirements

• System definition

• Logical design document

• Physical design (databases)

• User guides

• Interface specifications

• Data element profiles

• Data catalog (outdated)

• Program documentation

• Data structures from the programs (e.g. COBOL data division)

The amount, type, and quality of documentation varied enormously from system to system. For example, the Service Order System (SOS) suffered from overdocumentation; every day piles of paper were delivered to each project team member. Needless to say, there were many instances of inconsistency from document to document, and the sheer quantity was overwhelming. At one time I had been a project leader of the programming staff; and I (and my boss) always promptly threw all the papers in the trash as soon as they were delivered. At the other extreme, dealing with the Equipment Repair System (ERS) was tantamount to entering the twilight zone; we were lucky to obtain encrypted paper napkins. If a system is virtually undocumented, you might infer that there had been a notable lack of definition and design. It would not surprise anyone to hear that the system was extremely error-prone and crashed on a regular basis. In fact, I was once in charge of production management of this system and was beeped once an hour for three long months.

Since we had been part of the organization for a number of years, we were in an extremely favorable position. We were familiar with many of the systems and their associated data, which facilitated our analysis, as well as greatly aiding our credibility. Moreover, we knew many of our users and hence were starting from a position of trust and confidence. The relevance of these two facts has been noted in previous chapters, and it certainly was true in this case. We understood the modality of the organization—who to ask for help or information, who to avoid. Another way of framing this is to state that we were acquainted with the informal organization and in general understood how to get things done quickly and without fuss. All these facts enabled us to perform the analysis speedily and without distraction to our users.

Over the course of the next several weeks, while the clerks entered the data into our dictionary, Sally and I prepared all the data model diagrams that were required to represent the organization’s data. This was a bottom-up view of the data architecture as it currently existed, and the data was not normalized. We had elected to provide the diagrams personally so that we could ensure a consistent foundation for all future data work in the organization. Does this sound idyllic? Of course, and to be honest, this was not exactly how the implementation proceeded. What did happen was that at every step of the way we were met by concrete and substantial impediments. We constantly had to replan the change process while simultaneously persisting in our efforts to do the job. During the course of the implementation, it sometimes seemed that we no longer had a plan.

The Real Story

When we began to gather the documentation, we encountered our first stumbling block. This obstacle took the form of noncooperation on the part of our users. Some of this resistance was unintentional; they were just too busy to stop and search for outdated and useless documentation, so they promised to get back to us. Sometimes they did and sometimes they forgot, but almost never was the information provided speedily. We addressed this problem in a simple and straightforward manner; we proceeded with sensitivity and perception, and we gently persisted. For example, if they were about to hand a release over to system test in a few days, we waited until they were not so busy. Since we were extremely courteous and we had already established friendly relations with most of these people, our patience was usually rewarded, and after a few gentle reminders we received what we needed. If not, we offered to come over (at their convenience), and help search for the material.

Occasionally we met with political barriers. The project manager of SOS was one of the less cooperative members of our interproject team and continued in that role during this phase. No matter how simple our request was, it presented a problem for him and he took forever to provide the document. We handled this resistance in exactly the same manner as we handled the behavior of our busy friends. We timed our requests opportunely, we were patient, and we politely persisted. Once when we simply could not obtain the necessary document, we went to one of his staff members, who was a friend of ours. After we had the document in hand, I wrote a laudatory memo to my boss commending the interest and cooperation of this man and his group, despite their heavy workload. I carbon-copied the SOS project manager, who found it very difficult to complain about us after a public display of praise about him and his people.

When we approached the ERS group, they stated unequivocally that our request was impossible because all that existed was the software itself. We sweetly reminded them that we had both written many programs in our time and we would be delighted if they would just provide us with copies of the COBOL data division, the PL/1 structures, etc. Then Sally helped them retrieve the copy lib members so it required less than one hour of time from one programmer.

The morning the temporary clerks were scheduled to arrive for their first day at work, my boss informed us that he had arranged for us to give a status report to upper management. There was no possibility of rescheduling the status report, nor was there any benefit to delaying the start date of the clerks. We squelched any stirring of disquiet and hastily prepared the status report. Then we placed on the clerks’ desks two manuals that described the editor they would be using, along with a note telling them to start reading and practicing. (Happily, the meeting lasted only two hours, so this turned out not to be a major conflict.)

As we progressed with the data load, it became apparent that one of the clerks was less than useless. Worse than the fact that she could not cope with the assignment was the fact she continually interrupted the other clerk for help. After a brief hesitation, we terminated her services at the end of the first week. Our reasoning was that if we had to prepare the information for her in great detail, her involvement did not add any benefit, and we could not afford any extra work when we had such a demanding schedule. Moreover, we were not dealing with one of our staff members to whom we owed an obligation as a supervisor. (We did after all have our more ruthless moments.) We hired another temporary clerk who seemed even less competent than the one we had just dismissed, so Sally dismissed him while I negotiated with our boss. I told him that the one clerk was so superior we did not want to hire another one, but preferred to keep him twice as long. With his agreement, we chewed our fingernails as PW automatically recalculated our schedule and the critical path on our dependency diagram. We heaved gigantic sighs of relief when it became clear we had built enough slippage into our schedule to still have a chance at meeting our commitments.

Do we sound like a couple of superwomen who were on top of every situation? Well, it surely did not feel that way. It would be a conservative estimate to say that we were extremely discouraged at least half of the time. It was so hard to believe that the small portion of data that comprised phase 1 could possibly make a significant contribution to productivity. Indeed, there were many days when it seemed doubtful that we would be able to deliver even that small piece. But in spite of our doubts, we persisted. Actually, we did not give serious thought to any other option; we still believed as fervently as ever. Moreover, we had laid our collective careers on the line to upper management. Finally (and perhaps most important) it would have been mortifying to face our users after the marketing blitz, if we just gave up. Our only choice was to continue.

As soon as we had any portion of the work completed, we distributed it to all the first-line managers for review and sign off. This policy served multiple purposes. The political reason was to protect ourselves from repercussions later on in the change process. For example, it is not unheard of for people to suddenly emerge, months into the implementation, from their own personal crises with loud lamentations that they had not the slightest idea about what was happening. However, if you distribute results and ask for comments, suggestions, and questions by a specific date, the lamentations are much less impressive to upper management. Another benefit that we gained from this procedure was that the quality of the information was vastly improved. Each manager parceled out the information that we had distributed to subject matter experts. The result was that the information was reviewed several times, and in addition was reviewed by the very people in the organization who knew it best.

Figure 10–3 By Soliciting the Input of Many People, the Change Process Became an Organizational Effort.

The third benefit related to the process of increasing the number of people who buy in to the productivity improvement. This one had not even occurred to us, and yet it turned out to be the most significant of all. This involvement of such a large proportion of our organization resulted in a quality product that belonged, in fact, to the entire organization. In other words, the dictionary was not a product developed by my group and offered to the other groups; by virtue of the extensive participation, it became everyone’s product (see Figure 10–3).

Official Acceptance

By this time the project team had been disbanded; there was truly nothing they could do during this phase. We did, however, keep everyone in the organization very well informed as to the status of the scheduled activities and availability of deliverables. Finally, after three months, the data had been loaded, reviewed, and signed off. One day I was at a meeting where the discussion revolved around which one of the 35 possibilities was the real system technician name. A manager, who was a peer of my boss, asked the question: “Why don’t you ask the data management group?” After all the time and effort invested, this was the first instance of official acceptance; this was the moment when our vision became a part of reality.

Did widespread usage begin the next day? No. Did we begin to have users? Yes. In fact, our first and perhaps most cherished users were the strategic planners. Exactly why this group was the first to recognize the value and thus receive the benefit will probably never be totally clear to me. Nonetheless, I do have some understanding of how it came to be that way. The planners had requests for information from all levels of management (including directors), from many people external to the organization, and naturally from the end user community. None of those individuals had any extensive data processing background, and most of the planners themselves had a business background as opposed to a technical one. Furthermore, the requests were frequently urgent and in order to be addressed thoroughly, multiple systems had to be polled for information. Prior to the advent of data management, they had several equally unattractive options available to them when they needed information. If they were interested in accuracy, the only alternative was the programmers and the code itself. However, that choice had the serious disadvantage that it was highly unlikely they would get the data in a form that would be readily comprehensible to the requestor or even to them. The other alternative, which involved working through the systems analysts, meant that they would have to deal with all the various documents and their inconsistencies. Both options had the additional disadvantage that the planner would have to interact with a substantial number of people.

Once the data management group had accurate information available, there was a third and obviously more palatable option. For example, one of our first requests was initiated by a planner who wanted all the information that we had about system technicians. He did express some concern about timeliness because he needed the report by the next day. We were able to supply him with all the information he required in a few succinct reports, and we had no trouble meeting his deadline. The following day he expressed tremendous gratitude; he told us that everyone else came to the meeting with armloads of documentation. He further stated that without our assistance, he would have had to track down about 25 people in order to obtain the information he needed (see Figures 10–4a and 10–4b).

Figure 10–4a Before Data Management, the Alternatives for Obtaining Information were Equally Unattractive.

Figure 10–4b After Data Management, Information was Readily Available that was Consistent, Concise, Comprehensible, and Accurate.

There were an increasing number of requests for data as time went by. Ultimately, there did come a moment when our group and our function was unequivocally accepted as the single source of information about our organization’s data. This does not mean that every piece of data in every single system was loaded and 100% accurate or that every individual in the organization was wholly committed to our cause. There was an enormous amount of work still ahead of us. But we knew that we had truly and fundamentally changed the way people viewed and utilized data in our environment. We knew beyond a doubt that we had in some profound way improved productivity, and it felt good!

Summary

• The task of actual implementation may seem insurmountable, but you will proceed by dividing the effort into manageable chunks. In fact, many activities of the preliminary phases have set the stage for this.

• If you present your users with too much too soon, they will not be comfortable enough to change. The secret lies in managing change implementation via incremental improvement.

• You can also promote a comfortable situation for people by being flexible and meeting each user on his or her own ground.

• No matter how well you planned, you will encounter numerous unforeseen problems. Dealing with them and the resultant frustration is the essence of the doing phase.

• You may experience a renewal of discouragement and self-doubt, but the secret to success lies in utilization of your abilities to form strategy and persist.