10 things I hate about you – The worst mistakes in GIS project history (and how to avoid them)

10 things I hate about you – The worst mistakes in GIS project history (and how to avoid them)

Jeff Meyers
Miner & Miner
4701 Royal Vista Circle
Fort Collins, CO 80529

Abstract
Despite the fact that few GIS implementations are declared out right failures, most projects are not as successful as they might be. Nearly all projects, when subjected to disinterested analysis, would reveal things that might have been done better. Are there some common threads among the issues that surface? The author’s experiences show that there is indeed a top ten list of sins that have plagued spatial deployment and integration projects. The focus of this paper will be the real-life experiences (minus the utility names) that have been, in the author’s humble opinion, some of the worst ever.

Along with the obvious, the attendee will hear a few surprises, and be presented with a summary of the things that any manager, project team, or implementer can do to avoid these common mistakes, and deliver their GIS implementation in a reasonable amount of time and for a realistic amount of money.

Introduction: On why it ought to be easier, but isn't
It has often seemed to the author, and no doubt to others, that designing, building, and deploying an enterprise GIS ought to be less difficult. Let’s face it: GIS projects have a pretty lousy track record for delivering the promised business benefits within a reasonable time frame and budget. Why is that, we wonder? Shouldn’t it be easier?

At first glance, and for a long time after that, it just seems to make sense that you could follow a recipe for success. You know, kind of a one-size-fits-all, can't-miss sort of approach. Maybe we just need to sit down and think about it for a bit. Of course, once we do that, we can only conclude that there isn't a secret fix. Books have been written (including one by yours truly) about this stuff. These learned volumes give the guidelines on all kinds of things, and some of them are even helpful. When starting a new phase of your project, you should obtain and read all the reference material you can stand (did I mention that I wrote a book?). Nevertheless, the truth is that there are so many variables in the equation that it is just about impossible to concoct an approach that won't need to be adjusted to your local conditions to work well.

So, even if there isn't a guaranteed single technique for success, there certainly is a list of things that ought to be avoided, if we want to have a chance. Goodness knows that there have been enough mistakes made in this business to get going a pretty good catalog of things that may have gone wrong. The following are ten characteristics of utility GIS projects or their participants that had an impact on their success. Call it the Top 10 List of Infamy, in reverse order of commonality, or severity:

You can probably think of other mistakes, and maybe you've even made some. However, the list up above represents the most common, and in some ways, the most serious obstacles to delivering business benefit, in the author’s experience, and if it doesn’t sound too self-serving, the author has had a fair bit of experience in the mistake department. Here then, is a paragraph or two of some of the awful things that can and do happen to GIS projects everyday.

The Top 10

10. Didn’t Have Enough IT Support
Today’s GIS world is a technical one. While modern GIS technology goes pretty far to make the user experience easier, that doesn’t necessarily mean that administering the data and applications is getting easier – quite the opposite. The current state-of-the-art systems require DBA and other technical support to get them up and keep them running in a major enterprise. There are utilities, and probably other kinds of businesses, where the IT or MIS or IR department or division or group thinks of GIS as ‘just mapping’. Usually, that means that IT doesn’t allocate enough resources to help the system get off the ground and thrive in an integrated environment, and problems are germinating. Databases are not maintained, operating system or application software patches and upgrades can't be applied, and before you know it, there are conflicts between the GIS and all the ‘enterprise’ systems (not to mention conflicts between most everyone in GIS and IT).

That doesn’t mean that you need a huge team of IT experts, or that there aren’t some pretty creative teams out there that are making their GIS work with business users who have learned what they needed to know about RDBMS and applications support. One way or another, somebody has to provide the care and nurture that will keep your GIS working, and it won't be the elves. Enterprise GIS works best when there is a balance between meeting IT standards and business needs, and when it is enthusiastically supported by business users and IT technical resources. Ok, maybe enthusiasm is too much to ask, but involvement right from the start, and an on-going commitment from qualified technical resources, are vital to your systems success.

9. Had too much IT support
At the risk of offending all the IT folk who are reading this, it can happen that the need to meet all IT standards and procedures can become a major impediment to delivering a successful enterprise GIS. If that seems counter-intuitive, remember that it is a business system, after all, which means that it is supposed to be delivering benefits for the business. Sometimes, the well-meant constraints imposed by an IT group have made it difficult to get any GIS task done in a timely enough way to meet the needs of the business.

Someone once said: “Enterprise GIS works best when there is a balance between meeting IT standards and business needs, and when it is enthusiastically supported by business users and IT technical resources.” Today’s utility business world can be pretty demanding, and dynamic. In this context, balance may mean that IT has to be flexible enough to serve the business first, without unduly compromising good practice that will come back to bite everyone.

8. Failed ‘the Bus’ test
More often than one would suspect, we have seen a GIS implementation become entirely dependent on a single technical resource. Usually, this person is a combination of project manager/programmer/guru/spokesperson, and without this sole source of all that is good, the GIS doesn’t stand a chance of success. That’s what we mean when we say ‘the Bus test’, if that person gets run over by a bus, the system is in big trouble.

Fortunately for us, most people who fit the profile of project manager/programmer/guru/spokesperson are dedicated professionals who love their technology, or at least like it better than they like most of their co-workers. Still, we have seen the loss of just such a person, through illness or recruitment or bad luck, result in catastrophic setbacks for a project so beware. Try to distribute technical know-how and steer clear of single-point-of-failure, if you can. It is always wise to avoid having all your eggheads in one basket.

7. Lacked a sponsor (at a high-enough level)
It isn't exactly a secret that no IT system ever had much of a chance of success without some highly-placed person to steer it through the occasionally-rough waters of implementation to maturity. The industry refers to her as a champion or a sponsor, and she is not a nicety, but a requirement. The purpose of including that factor here is not to get on the bandwagon (the author hardly thinks himself above bandwagonism), but rather to point out that a champion or sponsor for GIS nearly always exists. The problem is not that there isn't a sponsor, but that she doesn’t have enough clout in the organization.

For a sponsor to be effective, she must possess through organizational role or personal relationships enough juice to convince her management peers to stay the course when things appear to bogging down, and to coach/encourage/coerce the GIS team to stick to the important business problems and not go wandering off into their own world. Please make note: the latter is just as important as the former. Both must be done, and each enterprise GIS needs someone who can do them.

6. Had a poor project manager
Much has been written and said about the need for a solid project manager, but the lack thereof is such a devastating blow for any project that it is worth repeating. An ineffective PM, or one that loses the confidence of his boss or his teammates, can be fatal in enterprise GIS. In fact, the role of the project manager is so important that some people have defined the job as requiring a superstar to perform it adequately. To these folk, a good PM has to have in-depth knowledge of the technical content, mastery of the science of management, long and varied experience in building systems, and the personality of a talk show host. Wait – maybe that last example wasn’t a very good one. Anyway, you get the idea.

This elevated view of personal qualifications for a good PM may not be helpful. It is the author’s opinion that a solid person who is empowered by his boss doesn’t need to be a wizard to deliver a successful project. There are in fact four characteristics that this individual should possess for success: an understanding of the company culture, a clear view of the business drivers that must be met to be successful, the support of both his boss and teammates, and a project methodology that he understands and is tuned to the environment. You could argue that these are inter-related, that to have the first two means having the third, and that interpersonal skills can fill in some of the blanks when needed. You’d be right on all counts, but that last point can be overdone. It is also the case that many good PMs are not sparkling cocktail party conversationalists; they are plodders, people who understand the goals and stick to their knitting (more about methodology later) until they are achieved. If you happen to have or be a superstar, great. If not, remember the four factors above, and look for someone, not forgetting yourself, who has them.

5. Had a poor methodology, or none
Having started out by saying that there isn't a single silver bullet for a successful GIS project, the author will now appear to reverse his field and claim that a good methodology, or roadmap, can make all the difference in delivering enterprise GIS within a reasonable timeframe and budget. This isn't really a reversal (he wrote persuasively); the truth is that any good methodology must be adjusted to meet the business conditions of a specific implementation, or it probably won't work. You have to start somewhere and using a proven set of tasks as the basis for a project just makes sense. Yet, it is amazing how many GIS implementations get rolling with no clearly-understood set of tasks for getting from here to there, there being a successful delivery.

Fortunately, it doesn’t have to happen to you. Of all the things you need for a successful project, this one is the easiest to obtain. As we may have mentioned, there are any number of books on the topic. Of course, mere book learning won't do it; you’ll need to carefully adjust any plan that you find to meet your company’s needs (your company may already have a sanctioned approach). Once you have the plan, you’ll have to do the most important thing: make sure that everyone in your core GIS team, from PM and sponsor to programmer or data converter, understands the methodology and supports it.

4. Had unrealistic schedule expectations
People, especially utility executives, are in a hurry. It is dangerous for us to ignore
the fact that today's utility executive doesn't really want GIS, or any other IT system for that matter. She just wants to concentrate on core business, using tools that will help her to drive down costs and improve customer service. And, she wants those tools now. With all the changes that have been and still are taking place in the industry, there is tremendous pressure to deliver (or to say that you’ll deliver) business solutions in very short time frames. Going public with the most aggressive schedule possible, and then hoping for the best, is an excellent way to take some of the glitter off an otherwise shiny project. And occasionally, it can lead to death and dismemberment.

Although this is tough nut that is getting tougher all the time, it is our experience that some relief can be had by creating the right expectations from the beginning, and then carefully managing them throughout. A good technique for setting expectations is to divide your project into small packages, and deliver them according to some combination of priority and convenience. That sounds hard, and it might be, but here are a couple of ideas that could help. Take the smallest component that solves a significant part of the critical business problem, and call that a delivery. Estimate the time to delivery, and be conservative. Then add some things that are good but not critical to that delivery. If you are under pressure, be a little more aggressive in the timing for those components. You probably get the idea: if the schedule slips, let go of some of the good but not critical components.

At the very least, you’ll deliver the critical component in the timeframe that you estimated.

3. Didn’t plan for technology change
This is one of the least discussed, yet toughest, implementation problems. Today’s GIS suppliers (if they are worth their salt) are providing you with new tools and capabilities on a regular basis, and on a release cycle that is measured in months rather than years. These new things are likely to be coming at you more quickly than you can absorb them in your implementation cycle. Some major technology jumps require equally major implications for production sites. Even if they don’t, they can be disruptive and challenging. What to do when that new function that your business users are dying to have is finally released, and you are just about to start acceptance testing the previous release? How about when your VP comes back from that conference all fired up about some Star Wars technology that one of his peers was touting, and your core team is just getting ready to rollout some core, mundane, extremely valuable-but-not-Star-Wars tools?

This problem has, in the author’s humble opinion, no easy solution. Participation with your vendor is certainly a key; go to user group meetings, sit on steering committees, respond to surveys. Guide your vendor’s direction as best you can, and learn about what is coming down the pike. Building on open technology from strong vendors may reduce your risk of being stuck with obsolete or proprietary , but more important than your vendor is the creation of a culture of continuing releases of improving functionality. Give your users and management the idea that enterprise GIS implementation is a process, not an event. If you work at it, your customers will get used to the idea that new stuff is coming down the line. If they didn’t get everything they wanted this time, they can expect more in a few months, instead of in a few lifetimes.

2. Didn’t/couldn’t/wouldn’t take internal ownership
You are no doubt getting the idea that there just isn't one thing that a GIS team has to do to be successful. Unfortunately, the opposite is still true: there are several things on this list that you have to do or you won't be successful, and this item is among the most important of them. Various components of an enterprise GIS can be provided by people outside the organization, but at the end of the day, healthy organization-wide implementations are always owned by the people they serve. Some teams start very small and are undereducated, and have to suffer the growing pains that come from implementation. A vendor can help, but only so much.

Mostly, this is a matter of expectations. Expect that the system you are building or
improving will continue to need care and nurture, if you want it to continue to deliver business benefits. Who is going to guide that growth and development, to ensure that your GIS meets the changing needs of your business? Chances are good that that impetus will come best from inside your organization.

1. Had unrealistic scope expectations, or none
The final killer. Of all the ways that GIS teams can get into trouble, this is it. Numero Uno. The phenomenon known as scope creep is the single most common cause of death among GIS projects, and has been the primary agent in even more projects that limp along to completion, behind schedule and over budget. And do you know who is to blame? Well, ok, it isn't one person, it’s a combination of people. It’s people who write TV shows and movies, making everyone think that computers can do amazing things effortlessly. It’s GIS salespeople (present company excluded, of course) making unsuspecting users believe that the technology will just work, and that all applications can function flawlessly, regardless of the quality or even existence of data to support them. And it’s visionaries, talking to all of us about how it will be someday, and conveniently forgetting that someday isn't today. (Remember when there were just a handful of visionaries? Now they’re absolutely everywhere. Could the world do with a few less visionaries, or is it just I?)

But closer to home, it is GIS core team members and project managers, who sometimes find themselves under pressure to say ‘yes’ to ever-demanding users and managers, adding to the project scope, and leaving reason behind. The reasons that GIS teams have to allow scope expand are many and varied, and the solutions to controlling scope are just as broad. If any of the answers were effective and easy, people would already be using them. Even the best approaches to scope management problems have complexities. But here is one simple suggestion, relating back a bit to the earlier discussion about planning for smaller, discrete releases of ever-improving tools.

Try to create a culture of continuous improvement in your enterprise implementation. Use smaller, shorter delivery cycles, and control the scope of each. When someone wants you to say ‘yes’ to a scope expansion, but you need to say ‘no’, stop and try saying ‘yes, but not in this delivery’. Let your constituents know that your strategy is to make a series of deliveries, and be public about what is included. Be conservative, and let everyone understand that deliveries can change. It takes time to build credibility in this incremental style of delivery, but the benefits far outweigh the patience required. And remember that managers and users have selective hearing; they need to be trained to perceive the difference between ‘GIS can do that’ and ‘it is in this delivery.’

Things that are missing from the top 10
Few readers will be surprised by very much of what is written above, but there are probably some who are a little startled by the factors that are not mentioned in the Top 10 List of Infamy. For example, some of you expected to see unrealistic budget expectations, or poor technology selection, or lack of change management. And all of those factors are good ones that have done their share of damage. Come to think of it, we could start another Top 10 List. But that, of course, would have to be the subject for another paper.