After the thrill is gone: Institutionalizing GM
William J. Meehan, P.E. Boston Edison Company 800 Boylston Street Boston, MA 02199 Abstract Nearly every trade magazine targeted to the Electric, Gas, Telco and Water/Sewer Industries is full of articles and ads about Geographic Information Systems. Billions of dollars are spent yearly on GIS software, hardware and services. The ads tout that a GIS can change your business, give you the competitive advantage and make your workforce more productive. The thrill of this fascinating technology is widespread. The good news is that the ads are all true, the technology is wonderful. The bad news is that getting meaningful change to occur is difficult. Boston Edison’s GIS project is complete. Yet there continues to be on going issues of deriving the full value of the system. This paper will focus on the obstacles to full institutionalization of the GIS, interventions and strategies to fully realize the most out of the GIS. Introduction GIS projects are not about computers, data conversion, land-base or Global Positioning Systems. They are about cultural change, significant, often painfi-d change. The goal of any GIS project is to institutionalize the system~or the purpose of dramatically improving the bottom line. Parachuting a GIS into an existing process without a vision for business reform will likely result in lukewarm effectiveness. The late Senator Robert Kennedy noted, “progress is a nice word. But change is its motivation. And change has its enemies.” Kennedy knew full well that people resist change, often violently. There are at least four human responses to change:
10) Management might figure out what the workers do. 9) The workers will figure out what management does. 8) Change brings up bad memories of giving up my binky (security blanket). 7) Workers might have to talk to management about what really matters. 6) Management will have to ask workers what they think. 5) Management might have to admit that workers were right all along. 4) Workers might have to admit that managers do have intelligence. 3) People might get blamed for the messed up processes. 2) I will get fired. And the number one reason to avoid change: 1) It hurts! Conventional wisdom suggests that an effective change program ought to occur swiftly. After all, if change hurts, it’s better to suffer the quick pain and then get on with it. The inherent problem of a GIS implementation is that it takes so long. Often the thrill is gone even before the program begins because it has been studied, prototype, piloted, costhenefited, analyzed and dissected to death. Boston Edison’s GIS has been no exception. The implementation time has been a serious detriment to institutionalizing the GIS. Our learning is: since change is painful, do it fret. We wrote the original prototype functional specification for the GIS project (called CAD-Image) early in 1986. The first significant activity, the pilot project began in 1989 and was completed late in 1990. Analysis, justifications and lobbying for fill implementation occurred during 1991. Full project implementation was authorized in 1992. December of 1999 was to be the original completion date for the complete system. Thus the total time from original concept to completion would have been (if completed according to plan) a whopping 14 years! Even with the acceleration, the project took 10 years: three presidents, several completed wars, a total upheaval of the electric power industry, at least five generations of PC’s, the fidl and rise of the US auto industry and the deregulation of the telephone industry. The nature of conventional large GIS projects is that they take a long to time to complete, by design. Long Projects Prolong the agony of change Long projects carry these serious liabilities: The Withering Patience Curse Or``Eve~one's Patience is Equal to Halfthe Project Schedule.'' Eventhough theproject is on schedule and on budget, management runs out of patience halfivay through the project, even though the schedule was well publicized. At the hali%ay point of our project, people assumed the project was way behind schedule, even though the schedule had never slipped but had been accelerated. No one wanted to look at the plan. The Disappearing Advocate Hex Or “Management Advocates Retire Halfway Through the Project.” Since the project has taken years to get to where it is, the most ardent advocates have retired. They have been replaced by managers who have no ownership in the decision to authorize the project. Some people do not even recognize the signature on the original authorization papers. The Mushrooming Scope Puzzle Or “No one Remembers the Scope of the Project.” Even though the scope of the project was clearly defined when the project was initiated, by the time the users get to use the system, the expected list of applications grows without an increase in budget. This is a classic case of overselling the product. Sure the GIS can do this or that. Note the operative work is “can.” But “does” it do it now? Too often the answer is no. Why, because it wasn’t in the scope of the project. The Incredible Shrinking Labor Savings Or “Much of the Labor That Was Supposed to be Saved Has Gone.” A common justification for a GIS project is based on labor savings. With down sizing and taking full attrition, much of the labor that was supposed to be saved by the project is already gone without the benefit of the improvements promised by the project. Beat You to the Punch Syndrome Or “Users Have Figured Out Alternative Systems Before You Get There.” Impatient users will find their own way to automate their processes before the GIS project reaches them and they are reluctant to give them up when the project finally arrives. This Better Be Good Enigma Or “After Waiting This Long, You Better Deliver.” Applications that take months or years of development and anticipation carry a huge weight of expectation. Users will be not be satisfied with bugs, poor performance or data errors after having waited so long. The solution to the long project problem is simply to shorten it and to provide tangle user benefits quickly. We had decided to focus very heavily on converting all the data before providing a large suite of applications. This lefl those divisions that had the converted data very little to do with the data that was different from what they had in the past. In hindsight, we should have begun the change process earlier in the project. A GIS project will probably carry this long project baggage. Further, given the user’s natural fear of change, I would offer these things that may help to ease the pain:
I listed education three times because that is where the institutionalizing will happen or not. By this I mean, explaining what GIS is, describing “what’s in it for me,” showing users’ possibilities, detailing the data structure, exciting users with applications and asking for questions. Once this is done, it needs to happen again and again. Above all, we need to demonstrate that a GIS is a tool to positively reform processes. A key piece is of the education process is to accurately define what a GIS can do and cannot do. A GIS will NOT re-engineer a faulty process. A GIS CAN create opportunities to re-engineer a process that otherwise would not have been thought of without the GIS. Over that last several years, we have been having a running debate about whether we should define the process we want and then get the tools or find the tools and define the processes around the tools. The debate goes like this: Define Ihe process, thenjnd the right tools: this school of thought says that you should analyze your existing process, do process re-engineering to simpli~ the steps, eliminate unneeded tasks and identi@ the end product. Once that is done, then find or develop the right tools to accomplish the new process. This school of thought tends to make instead of buy since the requirements tend to be very unique. Find new tools, then use the tools to discover the new process: this school says that you find out what tools are available, such as a GIS, and that stimulates creativity about how to solve your process problems. This school of thought tends to buy, then adapt processes to accommodate the tools. I believe that you need a bit of both. It would be difficult to redefine a new complex process without some knowledge of what tools are available to help you solve the problem. On the other hand, just applying a new tool to an old problem is a prescription for failure. What the education step does regarding GIS is help put the debate to rest. The education program should beat a level that stimulates invention while staying away from the cure all solution. We need to communicate that the GIS is not a map machine, not a CAD system and not a road atlas. We need to describe how it is a new way to view 427?data to create information that previously did not exist. Armed with that new information users can discover new ways to improve their business and business processes. While the technology is essential, it can dominate the other dimensions of successful integration. The fact remains that the vast majority of people that are expected to use the GIS are not GIS experts. Their interests do not lie in hardware, software and the latest trends in object oriented data bases. They are interested in doing their job predictably at a speed and quality that will ensure that they can make the next orthodontist payment for their eleven year olds. We have tended to spend more time on the technology and less time on the people. Again the education will help put the GIS in perspective. Training Last year’s paper entitled “Training Critical in AM/FM Culture Change” spoke about the initial lack of attention to training issues. About halfivay into the project, it was clear that users were not embracing the project and were looking for ways to avoid using the system. In that paper I listed these schools of thought: “On The Job Training” CamP This school of thought espouses that people will only learn by being thrown into the water to sink or swim. Give them the tool and the users will figure out the best way to use it. We originally thought that the users would be challenged and excited by the new technology. We further thought that they would be very tolerant of system bugs and problems. As it turned out, when something went wrong, the users couldn’t tell whether they were doing something wrong or the system was not working correctly. Eventually, they just assumed that all problems were the fault of the system. “Programmers Make the Best Trainers” Circle of Friends Programmers have the best knowledge of the inner workings of the applications so it should follow that they are best qualified to train others on the use of their creations. There are two serious problems with this school of thought. First, programmers know the system too well, in fact, so well that they avoid getting trapped or into trouble (unlike users). Second, they are so wrapped up in the development effort that they view training as a serious interruption to their work. “No One Reads Documentation Anvwav” Gang This school of thought says that a good application is intuitively obvious, so you shouldn’t spend a lot of time and money developing manuals because no one ever reads them. It is true that people don’t read manuals often, especially cover to cover. However, when something goes wrong or when people cannot remember what the correct sequence of steps is, a good easy to read reference material is essential. “We’ll Worry About Training Later” Club A GIS project is complex and expensive. There are data conversion issues, software and hardware and performance issues. This school of thought says that we have enough to worry 428?about now and if we could just get through this next phase, we could think about training. Once training became an activity in our critical path schedule of the project and the dependencies developed, it became clearer to us that training was as important a component of the project as any other aspect and that it could not wait until later. Once improperly trained users began using the system, undoing bad habits added an additional burden to the training staff. “Training is the Responsibility of the User Community” Community The job of the GIS project is to deliver data, hardware and software. It’s up to the user department to get their people to use it, not the projects’. This school of thought ignores the fact that usability is an essential component of development. It is the job of the trainers to make sure that the developers make the applications easy to use. Thus the training has to be developed in parallel and in concert with the applications programs. “No Need to Budget for Training” Bunch This school of thought would say that compared to all other tasks and costs, training is such a minor cost, that we don’t have to budget for it. It will just happen. The lure of this flashy technology is so great that it tends to blur the need for normal people to use the technology to do their normal tasks. A successful project will provide training in the schedule and in the budget. During the course of this project, we have embraced all the above schools of thought at one time or another. We now would say that we subscribe to the school of thought that says: “Build training into your implementation plan from the beginning.” Creating Realistic Implementation Expectations The worst thing we can do is to create unrealistic implementation expectations. After all, we are turning the business upside down. There are some implementation issues that can create serious obstacles to successful institutionalization. Records Backlog Prior to the data conversion, there was a healthy backlog of completed work that had not been posted to the paper facility maps and records. Over the last ten years, the number of people who were responsible for posting these records has been reduced due solely to attrition. Since the processes hadn’t changed much, it is not surprising that the backlogs tended to grow. Increasingly the records people became fi-ustrated that the work was falling behind. Then the GIS project came. All this did was increase the workload. The records people then had to collate and package all the drawings for the conversion contractor, answer the millions of questions about the inconsistencies and then accept the converted data. Further, they had to be trained on a computer system and essentially undo all the learning they had accumulated about drafting, which drawing showed what detail, what scale was what and what symbol meant what. In the meantime the backlog continued to grow. Thus afler complete conversion of the first geographic division, the backlog had doubled. What really needed to happen was to foreshadow the awkwardness of the transition from a paper system to the GIS. Instead, we underestimated the impact of the backlog. What resulted was that even with solid applications, the data was essentially delivered out of date. We could rightly argue that the digital file was no worse in terms of timelines of data than the old manual maps. That’s probably the wrong answer to our users’ management. To them it sounds like, “Now it takes less time to get the wrong answer.” The Output Products One of the project’s original goal was to be a paperless. The vision was that anyone on any terminal could view the GIS data. Printouts or plots were to be ad-hoc and be very personalized. However, during the transition from complete manual to complete digital, paper maps and records are still used. Even after the complete transition of a vast majority of our system, plots are still the communication of choice of our users. The problem is that the digital output products do not look exactly like the old paper maps. First, the people who made the old maps took great liberties in scale and placement. Annotation appeared wherever there was room with long arrows pointing to devices. The primary electrical maps were a combination of schematic and geographic. If a new section did not fit on the map, little randomly placed blow-ups were scattered about. The original grid layout that was created in the 1930’s turned out not to be rectilinear. While the new digital information was correct, it looked quite different on paper from the original. Thus users of the maps were concerned about the accuracy and often preferred the old manual maps. Process Changes The strength of the GIS is to enable process simplification. However changing processes and introducing a new computer system is not easy. The first editor applications tended to mirror the original manual processes and proved ineffective. Despite the fact the data was fully integrated, users still tended to segment the data into the same packages that existed on the manual sheets. Certain people were assigned to update primary electrical data, others to update secondary data, even though the data resided in the same place. Without continuous reinforcement of the vision of the project, users naturally tended to resort to old familiar methods of performing their job, attempting to adapt the new system to fit the old processes, instead of creating new processes to simplifj their jobs. Data Conversion An observer might view the GIS project as a computer program development project. Yet, the majority of effort has been in the data conversion. Most of the value of the project is in the converted and coordinated data. The data existed on a variety of records, in a variety of representations and in a differing level of detail. For example, on the Primary Electrical Diagrams, the scale is one inch equals four hundred feet; only primary 430?devices are shown, streets are shown at twice their actual width, and no intermediate poles or manholes are indicated. On the secondary sheets, the scale is one inch equals 50 feet, no primary devices are shown and there is no clear indication if there are primary conductors are on the poles or not. Pole plans (scale one inch equals forty feet) show pole offset from the street right of ways and guying but no pole sizes. Finally pole records show foreign attachments and size but do not show electrical equipment. The underground plans are similarly fragmented. When each of the drawings are plotted at the same scale, none tit together. These facts tended to complicate the conversion process significantly. We found that in crowded areas, symbols could not be plotted because of data and annotation overlap. It was only until after the data conversion was completed that we made decisions about some of the symbology and output product scales. We found that we had to abandon the 400 scale Primary Electrical Diagrams in favor of a 100 scale. Had we done this earlier, we wouldhave avoided some of the user acceptance issues. Applications The target platform is a mixed system of UNIX Servers, off the shelf relational data base software, Arc/Info and PC’s as workstations. The user applications are essentially macros, data base forms, custom menus and dialog boxes. It is an “Open System.” However, not all UNIX servers and workstations are alike. The UNIX operating software had been somewhat unstable causing crashes and hang ups. In the old days, there was only one software product running at any time. Today, the GIS has many running programs concurrently. Occasionally, the products do not work smoothly with each other. Upgrading the data base software to a new version may create a compatibility problem with the PC networking software. We have had a number of integration difficulties. Testing We have a developmental system for the project team. All testing is done on this system. However, the field configurations are slightly different. In theory, the testing of the applications and data should be independent of the configuration. This has often not been the case. Since the data is so varied, it is difficult to anticipate the complete set of user responses to the data. Often users discover a bug or a trap or some function that they do not understand. They respond perhaps by shutting the system down or by rebooting. This tends to either mask the problem or make it worse. Setting up an effective testing of new versions of the applications is an on-going challenge. Thus adequate pre-release testing is a major outstanding issue as we roll out new applications. Sharing the Vision The GIS project and production operations can get mired in the details. What could happen is that as the system gets to be “normal.” Invention may slow down or stop. People will get comfortable and used to the system. What needs to happen is an on-going sharing of the vision. Our vision of the GIS is:
Above all, the system must work. It has to be easy to use and fast. It must be able to move with the technology. Fast today is slow tomorrow. The hardware, software, data base and network need to be designed to work together. So, successful institutionalization might look like:
when there is a continuous flow of wondefil new initiatives utilizing GIS. We will be there when those ideas dramatically reduce operating costs, facilitate the growth of the business and delight the employees. | ||
|
|