After the thrill is gone: Institutionalizing GM
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:
- Education
- Education
- Education
- Training
- Creating realistic implementation expectations
- Sharing the vision
- A good technical solution
Education, Education, Education
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.
