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:
Today’s technology has solved most of the software, hardware, integration, and networking problems:
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.
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. Understanding client fears Throughout the course of the project, the feelings of the users of the system must be addressed. Many users will fear that the system might take away their jobs, which is (in our experience) never the case. Instead they must be shown that the goals of the effort are to make their work more rewarding and remove much of their drudgery. Users must see the system as a way to help them do their work more effect ively, not as a way to take their work away. In one project for a small city, users from one department were so afraid that the system would eliminate their jobs that they initially refused to participate. Only after management assured them that the project was not intended to eliminate jobs did they join in, and only after the project was substantially completed did they feel secure. Evaluating benefits in relation to costs This is often the most difficult of the planning process, because it requires the organization to evaluate its existing costs to perform individual actions, such as “How much money does it cost to per year to maintain each sign?” or “How much to perform an emergency workorder?” However, if all costs for existing processes are evaluated, it often becomes obvious that there are opportunities to increase efficiency, thereby reducing costs. How these costs are to be reduced is again an issue of concern to staff, and the typical response is by attrition or by transfers. While reducing staff is often a way to cut costs, the most dramatic savings can often be made from the better decisions that result from the better information provided by a new system. Having a good preventative maintenance program can add years to the life of equipment, and having an accurate utility GIS can mean better decisions in the field digging holes, and better decisions in the office when planning capital improvements. These are the real benefits of most new systems. Role-playing new procedures The planning process must include understanding of existing processes, staffing, and organizational structure. This understanding must be documented in a quantifiable way, so that potential changes can be evaluated against the “as is” system. Then, new processes must be proposed, discussed, and playtested. Once the new processes have been established on paper, they then must be tested within the software. The proposed processes must also be documented in the plan, so that during implementation, the understanding of the team can be referenced. This Implementation Plan is the key to the success of the project. Testing assumptions The next evolutionary step is pilot testing. The pilot test should be rolled out to a small, select group. The members of the group must be volunteers who are motivated to make the system succeed, and who are willing to overlook the inevitable startup problems. The pilot stage must continue until all major “bugs” have been worked out of the system, and the system is ready to proceed to the next stage. In some projects, this stage is the most important step, because it is where the theory becomes reality. On more than one occasion, the pilot stage showed that the theory didn’t work, and that key elements of the project would have to be redesigned. This is also a time to reassess that the project appears to on target to meet the goals that were defined initially, and if not, evaluate whether or not the project should proceed. In one project, in which a large municipality was attempting to implement a computerized maintenance management system, the pilot stage demonstrated that the organization was not capable of making the organizational and procedural changes necessary to successfully implement the system, and the effort was halted-to be continued four years later, when the organization was ready. Staged implementation The next stage is the rollout to a “super user” group, made up of a larger number of users, but still less than 1/2 of the total user population. This group should be selected to be a cross-section of the entire user base, to more thoroughly test the system before it is introduced to all users. Success at this level must be demonstrated, and must be publicized to all users. By building momentum, the system can ensure success as it moves to the final stage. Sometimes this stage is skipped, often with disastrous results. In one instance, an E-mail software upgrade was rolled out automatically to the entire user base after a short and successful test with the pilot group. However, all of the members of the pilot group were using high-powered systems that did not reflect the systems used by the bulk of the users. When the new system was rolled out automatically, the users came in to work and found out that their E-mail no longer functioned. Because of the destructive way in which the upgrade was implemented, all mail that users had saved was also lost. To make matters worse, there was no easy way to go back. Each system had to be manually updated to re-install the original E-mail application, a process that took days. The aftereffects, in the form of lost user confidence and fear of change, lingered much longer. Rolling out the systems to the main group of users should be the last step in the process. This final stage of implementation should be almost anticlimactic. By now there should be no surprises, and only minor tweaks to the process should be required. In successful projects, the bulk of users wonder why “everybody is making such a big fuss” because this stage goes so smoothly. After a successful startup, the most common feedback will be “I don’t know how we got along without it”. | ||
|
|