Logo GISdevelopment.net

GISdevelopment > Proceedings > GITA > 1998


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

Application

Data Distribution

Data Evolution

Field Applications

Integration of the Enterprise

Invited Presentation

People Issues

Scada and Real-Time systems

System Development

User Presentations

User Solution


GITA 1998


Integration of the Enterprise


Integrating technology: Ensure success with an evolutionary approach

John M. Przybyla

Director of Technology, Woolpert LLP
409 E. Monument Avenue, Dayton, Ohio 45402
john.przyby la@)woolpert.com



Today, enterprise-wide technology projects are the key to building efficiency into any operation. GIS systems, and related applications, are among the most important and complex enterprise-wide technology projects to implement successfully.

Not too many years ago, the most difficult problems in implementing such systems were of a technical nature:
  • Most systems required development of custom software, which required talented (and expensive) programmers, and took many years to develop.
  • Computer hardware often limited design capabilities because it was much more expensive, less powerful, and more prone to breakdown.
  • Problems with computer integration also limited system design options because different computer systems often had virtually no chance to talk to each other, making information exchange difficult to impossible.
  • And, finally, communicating across distances at high speeds was prohibitively expensive and—for large files-technically difficult.
Because of these problems, we concentrated on getting data to people rather than integrating data. For example, if your agency has any networked financial or maintenance or modeling systems more than five years old, it is unlikely that these systems are truly integrated.

Today’s technology has solved most of the software, hardware, integration, and networking problems:
  • We can find off-the-shelf applications to meet most any need.
  • Our clients can buy powerful, inexpensive workstations for a few thousand dollars, and even servers--for much less than the cost of workstations of just a few years ago. And the computers our clients buy are much more reliable than in the past.
  • Interoperability is also becoming a standard with both industry standards and market pressures providing the motivation for every software vendor to implement interoperability capabilities into their applications.
  • And, finally, high speed communications options are now available at affordable prices.
Like us, our clients enthusiastically welcomed such technical advances. However, our clients’ expectations have grown along with the advances. In our experience, clients are likely to have unrealistic expectations about what GIS can and cannot do and about the difficulty of integrating products from different vendors. For example: In one scenario, the client’s staff had seen so many demos of GIS being used to display information about tax assessments, permitting data, and utility maintenance data, that they were ready to scrap all three existing (homegrown) system, and replace them with one application - the GIS ! We had to spend a significant amount of time educating them that the GIS could not perform the functions of all those applications by itself, rather that it could help them as a way to visualize the data that was maintained by those applications. They did need to replace the applications, but with new, off-theshelf versions that tied to the GIS.

Another area in which client’s expectations don’t mesh with the real world is when clients try to integrate packages from multiple vendors. All vendors now claim that their solution is “open”, and most claim compatibility with the dominant products (“Oracle compatible”) and standards (“ODBC Compliant”). Yet actually getting two products to be integrated to the degree that the users’ desire (“We can enter data once and it will end up in both places”) often requires expensive customization, Perhaps because our clients underestimate the complications non-technical situations can create during the implementation of enterprise-wide systems, we sometimes find it harder to meet clients’ expectations now than in the past. This paper defines a methodical, evolutionary process that has proven to be successful in implementing such systems. In the paper, I’ll concentrate on eight methods for ensuring successful implementation of an information system.
  1. A unified project team
  2. Permanent client committees
  3. Defining needs as opposed to “wants”
  4. Understanding client fears
  5. Evaluating benefits in relation to costs
  6. Role-playing new procedures
  7. Testing assumptions
  8. Staged implementation
A unified project team
The process begins with a planning session involving all stakeholders. The purpose of the planning session is to define the needs that the new system is to meet, and define specific goals that the system will be measured by. This planning session and subsequent meetings of the team are essential in getting buy-in from users. The members of this team must themselves be committed to the success of the project, and must convey their belief in the value of the system to those who are not involved. For many clients, this is where the project success story begins. In one instance, this initial goalsetting session was the first time two key department heads had worked together towards a common goal in many years, and their long-standing animosities disappeared as a result. A truthful airing of everyone’s agenda is essential at this point.

Permanent client committees
Another goal of this effort is to create an ongoing team made up of management and users that will stay involved in the project throughout its implementation.

For most large GIS projects, we recommend two committees, a policy committee made up of elected officials and key decision makers, and a technical committee made up of those who understand the processes and who will be using the new technology. For non-GIS projects, often one implementation committee will be enough.

Defining needs as opposed to “wants”
Often projects fail because they attempt too much, because no one has told the designers to stop designing until they have designed an unbuildable dream. This is time for a reality-check: Do we really need all those capabilities now? Can some things be delayed until a second phase? Are some of the “requirements” just not necessary? One good way to test each of the needs is to pose the question: How are we meeting this need today? If the answer is “we aren’t” then you need to objectively evaluate whether or not the need is critical to the new system.


Page 1 of 2
| 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