Digging for Treasure

The tricks and traps of managing an enterprise gis
Charles Rogers, Jr., P.E.
South Carolina Electric and Gas
Mail Code J-19
Columbia, SC 29201

Abstract:
After managing a GIS project for 9 years through data conversion(s), software migrations, application interfaces, there are several pieces of advice I would give to new project managers. In addition to the technical issues that are now becoming solvable, there are the people issues that can trip even the most successful technical project. How do you prevent the user community from sabotaging the project? How do you prevent senior management losing faith? How do you finish your project? These issues will be explored in this presentation.

After having managed a GIS project at South Carolina Electric and Gas for the last 9 years, it is common to have people visit us from all over the world. I think that the closer their project is aligned with ours, the more specific and more useful is the advice that we can give them. Sometimes we can give them specific RDBMS or GIS platform advice, or even advice about some of the 3 rd party vendors that we might be using in common. But, no matter how disparate our projects might be, there is some advice that I can give anyone who visits.

First let’s talk a little bit technical. For better or for worse, there are a handful of GIS platforms that can support your project’s needs. Each will have its own advantages and disadvantages, of course, but there are no clear standouts among that handful. You can probably make your project work regardless of which platform you use. So, when I am asked, “What is the most difficult technical challenge that I can expect to encounter?”, my answer is simple. Try not to buy software that doesn’t exist!

I guess a corollary to that would be try not to buy applications that don’t exist and that need other software that also doesn’t exist. It seems silly to write these words, but I long ago stopped worrying about being silly. The fact is that people buy software that doesn’t exist every single day. They buy the “demo”. Most vendors will actually direct you away from the software and applications that they have in production at the time that you are making your purchase. They describe functionality that you will need that is “just around the corner”. They confidently state, “By the time you are ready to implement, we will have released our next version”.

Maybe their latest, greatest version will be ready when you need it. Maybe it won’t be the bug ridden, feature deprived, pseudo-beta version that is so common in large version releases today. Maybe. But are you willing to bank your career on it? If there is one lesson that I have learned over the years it is that nearly everyone is chasing some new release, some future enhancement, some bug fix that is due out next month. Then, it is next month, and the month after that. Finally the release arrives, but the fix isn’t in it, or it doesn’t work, or there are 15 other problems that prevent you from being able to apply that release to solve your problems.

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.

To sell your users, though, you first have to sell their management. The basic mechanics of cost justifying your project are well documented and discussed, so I am not going to bother with that. After senior management agrees to sponsor your project, however, how well middle management will support it will be a determining factor in the success or failure of the project. You see, they have to at least pretend to support any project that is openly supported by senior management, but they can subtly sabotage your project when you aren’t looking. It is counterintuitive to suggest that middle management will encourage your project to fail, but I have seen it enough times to know that it is more the norm than the exception. But, why would your user’s management want your project to fail?

First of all, you are implementing a technology that you claim will improve productivity. That sounds good. But, if you aren’t careful, the only message that the user’s management will hear is that they were unproductive before, under their direction and leadership. In simplest terms, your user’s management can perceive that senior management thinks that you are saving their users from bad middle management. The only way that they can discredit that perception is to discredit your project.

Secondly, where does senior management come from? Someplace far away sometimes. But, often, senior management is selected from middle management and your user’s management is simply attacking any threat to their career path to the top. Simply, if you succeed, you will have leveraged your career ahead of theirs.

So, if you want your project to succeed, you have to find a way to not be perceived as a threat to your user’s management. One way to do that is to involve them in the project. Let some of the user’s management sit on a steering committee and take input and direction from them. As long as they have some say in the outcome of the application, they can claim at least partial credit for its success. So maybe you won’t be able to take full credit for the projects success, but you might overcome some obstacles that could have caused your project to fail, and we didn’t want that, did we?

In conclusion, it seems strange to think wistfully of the days when we were out slaying dragons every day to try and bring home an application to our users that would help them do their jobs better. Our dragons of old, the actual technology we were implementing in, were a clear enemy, cold and impartial, and, in its own way, understandable. Today, with those dragons a quickly fading memory, we find that there are new, different battles to be fought and won. These battles, the people battles, are much harder to understand and combat. But, understand and combat them we must, if we are to win the war in the end.