10 things I hate about you –
The worst mistakes in GIS project history
(and how to avoid 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.
