Integrating technology: Ensure success with an evolutionary approach
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”.
|
