Logo GISdevelopment.net

GISdevelopment > Proceedings > GITA > 2001


GITA 2002 | GITA 2001 | GITA 2000 | GITA 1999 | GITA 1998 | GITA 1997 |  
Sessions

A tangled web of pure opportunity

Directions for data

Forging the future

How they did it - and what's next

Integrating work management

Mobile solutions- taking it to the streets

Operations support

People make the difference

Systems architecture

The local government perspective

Tying IT all together

Vertical applications


GITA 2001


The Local Government Perspective


“Are we There Yet?” Experiences and Lessons in a GIS Conversion Project

The Nature of Project Failure
Recent industry research estimates that 40% of IT projects fail (“IT Project Management Research Findings,” www.techrepublic.com). Why then do we continue to attempt to implement IT projects in the face of such stiff odds? We keep trying because the potential benefits are so large or because our organizational strategy demands aggressive IT implementations just to keep up with the competition. Either way, we are faced with daunting odds against success. Even if we view “failure” as an inability to meet budget or stay on schedule, can we as managers thrive in such an environment? Clearly it is in our best interest to understand the causes of major project failures and plan to reduce or avoid this risk.

Failure in the COT electric GIS conversion project stems from several root causes: poor communication within the project team, underestimation of project complexity, and resource limitations. Each of these causes will be discussed. Poor Communication Within the project team

The project team was composed of managerial and technical staff from both the conversion consultant and COT. The first instance of failure was perhaps the most fundamental and laid the groundwork for many of the problems that were to follow. The conversion consultant made a verbal commitment that the new system would have “all the functionality that existed in the old system.”

Two mistakes occurred here. First, the consultant set itself up for failure by making such a sweeping, non-specific statement. Secondly, COT staff set themselves up by believing it. The two systems in question had numerous technical differences in the ways that they store and process data, making an exact reproduction of existing functionality unlikely if not outright impossible. By making a general claim to preserve all the existing functionality, the consultant encouraged the client to believe that the end product would be essentially identical in operation and function to the initial system. This might not have been what the consultant meant, but it is what the client heard. Once these expectations are set, they form the basis for all future discussions and it is very difficult to change them.

Lesson One: Don’t make broad, sweeping claims. If you can’t stop yourself, follow the claims with specific details of exactly what those claims mean. This protects both parties.

Lesson Two: Don’t accept broad, sweeping claims at face value. Question how these objectives will specifically be accomplished.

Page 2 of 8
| Previous | Next |

Applications | Technology | Policy | History | News | Tenders | Events | Interviews | Career | Companies | Country Pages | Books | Publications | Education | Glossary | Tutorials | Downloads | Site Map | Subscribe | GIS@development Magazine | Updates | Guest Book