The tricks and traps of managing an enterprise gis
As I stated earlier, our whole system of GIS software vendors, third party developers, hardware developers
and consultants support buying vaporware. And, lest we forget, we the user support it most of all. How
many times have we seen a production software demo and asked the question, “Can that product be
customized to meet my particular needs?” Because, you see, the last thing that anyone at my company
would want to do would be to change the way we do business to match any other utility’s practices. But,
that leads me to the other side of the equation – the people side.
Those of us who have toiled for years to deliver enterprise GIS solutions to our companies have spent those
years fighting the technical battles. Our servers weren’t powerful enough. Our networks had insufficient
bandwidth. The applications didn’t work the way we thought they should. Now, there is good news and bad
news. The good news is that, for the most part, we have been able to overcome the technical barriers to
implementing an enterprise GIS. The bad news is that, for the most part, we have been able to overcome the
technical barriers to implementing an enterprise GIS, and we have nothing else to blame for our
application’s failures.
You see, we forgot about the people who would be using this software. We kept promising them, and
promising them that this new software would make their lives easier. We told them that they would be able
to do their work in half the time, or less, than they used to be able to. But that means different things to
different people. Management thought that they would get twice the work from the workforce that they used
to get. Actually we told management that, didn’t we? So, our management made plans to use the money
elsewhere that they would have been paying the workforce to do their work the old way.
But our loyal users didn’t see it the same way. I think we are guilty, some of us, of allowing our users to
think that our software was going to make their jobs easier. If they could accomplish 4 jobs a day before our
applications and we are expecting them to do 8 jobs a day after, how does that help them? They are still
working just as hard as they used to, but now they are being asked to step out of their comfort zone to do it.
No matter how difficult a job is, or how stressful it was to learn to do it, once someone learns to do a job
one way, they hate the idea of learning another way to do it.
What are the main reasons that people don’t want to use new technology? The first is change. People do not
want to change. That is the most important point in this paper. People do not want to change, ever. The only
person who wants a change is a baby with a wet diaper. Watch the people that you work with every day.
They dress the same way, park in the same parking place, eat the same food. People take the same route to
work every day, and, even if you prove to them that you have a faster route, they will find some excuse to
take the route that they have always taken. People have a favorite pencil, a favorite coffee cup, and a
favorite sweater. Most of us cope with the uncertainties of life by controlling the things that we can control
with a firm hand. If people do want to change, they want to be in absolute control of the change. Which
leads us to another reason that people don’t want to change – fear.
Fear motivates us every day to do, or not do, so many things. We are afraid of losing our hair, getting fat,
getting old. We are afraid of being rejected. We are afraid of being laughed at. We are afraid of failing. We
are afraid of dying. New technology plays on those fears. Now, in addition to all of the fears that everyone
is already dealing with, we introduce entirely new opportunities for our users to be afraid. Now they can be
afraid of losing their jobs too.
So, taking these two problems together, how can we overcome our user’s fear and reluctance to change?
The first step in solving the problem is to understand it. Now that we know why, we have to figure out what
to do about it. Start by communicating from the beginning of the project to the end of the project.
Communicate openly and honestly to your users what their world will be like when they start using your
applications. Make sure that the message to your users is the same message that you are sending to their
management. If jobs are going to be eliminated, make sure that you have ways for those impacted to find
other jobs, and get training for them. If you expect them to be able to double their work output, tell them,
but also make sure that you tell them when they are going to be expected to come up to speed.
Begin their training before the applications are scheduled to be released by training them in any ancillary
skills that they are going to need. If they are going to be using a PC for the first time, make sure that they
get sufficient basic PC skill training. Don’t assume that everyone can use a computer just because everyone
that you know can. Get them Windows training. They may even need some beginning typing training to at
least develop a general comfort level with the keyboard before you start application training. It is important
to give good training in increments so that the training isn’t so overwhelming that they simply shut down.
But, even if they can overcome their fears, why should they change? They shouldn’t. That is, they shouldn’t
if nothing else changes around them. We are always trying to implement time saving applications, or
productivity improvement applications, but, many times we have never measured the individual user’s
performance that we are planning on improving. And, heaven forbid that we should ever reward or incent
them based on their job output. But, if we want to improve productivity, then our system of rewards needs
to support those improvements. At a large company I spoke with recently, they had a user community who
claimed that the application was unusable, and, indeed refused to use it. The users claimed that they could
do less than half of their previous volume of work using the new tool. However, when they began to be paid
based on the units of work done, they were able to more than double their pre-application volume. People
who were still being paid their old hourly wage were begging, or demanding, to be allowed to use the same
application that was deemed unusable before.
