368 Part III • Acquiring Information Systems
system in the rest of the organization. For example, in a
company with many branch offices, it might be feasible to
convert to the new system in only one branch office and
gain experience solving data conversion and procedural
problems before installing the system company-wide. If
major problems are encountered, company-wide imple-
mentation can be delayed until they are solved. Pilot ap-
proaches are especially useful when there are potentially
high technological or organizational risks associated with
the systems project.
For a large, complex system, a phasedconversion
strategy might be the best approach. For example, with a
large order processing and inventory control system, the
firm might first convert order entry and simply enter cus-
tomer orders and print them out on the company forms.
Then it might convert the warehouse inventory control
system to the computer. Finally, it might link the order
entry system to the inventory system, produce shipping
documents, and update the inventory records automatical-
ly. The downside to this approach is that it results in a
lengthy implementation period. Extra development work
to interface new and old system components is also typi-
cally required. On the other hand, a phasing strategy en-
ables the firm to begin to achieve some benefits from the
new system more rapidly than under other strategies. A
phased strategy may relate to not only the implementation
of a system but also prior steps in the SDLC, thus break-
ing a large project down into a series of smaller, coupled
projects. Later in the chapter we will describe a formal
process that takes this incremental approach called agile
methods.
In the cutover(or cold turkey) strategy, the organiza-
tion totally abandons the old system when it implements
the new one. In some industries this can be done over holi-
day weekends in order to allow for a third day for returning
to the old system in the event of a major failure. The cu-
tover strategy has greater inherent risks, but it is attractive
when it is very difficult to operate both the old and new
systems simultaneously. Some also argue that the total
“pain is the same” for a system implementation, whether
implemented as a cutover or not, and that this strategy
moves the organization to the new operating environment
faster.
Combinations of these four strategies are also possi-
ble. For example, when implementing system modules via
a phased conversion strategy, one still has the option of a
parallel or cutover approach for converting each phase of
the system. Similarly, a pilot strategy could include a par-
allel strategy at the pilot site.
OPERATIONS The second step of the Implementation
phase is to operate the new application in “production
mode.” It is common for IS organizations to maintain three
versions of an application:- a development version (in partial states of comple-
tion as new capabilities are being added or correc-
tions are being made), - a test version (a tentative new release of the applica-
tion going through the testing process described ear-
lier), and - a production version (the version actually “run”).
In the Operations step, the IS responsibility for the applica-
tion (or the next release of an application) is turned over to
computer operations and technical support personnel. The
project team is typically disbanded, although one or more
members may be assigned to a support team.
New applications are typically not moved into pro-
duction status unless adequate documentation has been
provided to the computer operations staff. Implementing a
large, complex system without documentation is highly
risky. Documentation comes in at least two flavors: system
documentation for IS specialists who operate and maintain
the computer system and user documentation for those
who use the system.
Successful operation of an application system re-
quires people and computers to work together. If the hard-
ware or software fails or people falter, system operation
might be unsatisfactory. In a large, complex system, thou-
sands of things can go wrong, and most companies operate
many such systems simultaneously. It takes excellent man-
agement of computer operations to make sure that every-
thing works well consistently and to contain and repair the
damage when things do go wrong.
MAINTENANCE The process of making changes to a
system after it has been put into production mode (i.e.,
after the Operations stage of its life cycle) is referred to as
Maintenance.The most obvious reason for maintenance
is to correct errors in the software that were not discovered
and corrected prior to its initial implementation. Usually a
number of bugs in a system do elude the testing process,
and for a large, complex system it might take many
months, or even years, to discover them.
Maintenance could also be required to adapt the sys-
tem to changes in the environment—the organization,
other systems, new hardware and systems software, and
government regulations. Another major cause for mainte-
nance is the desire to enhance the system. After some ex-
perience with a new system, managers typically have a
number of ideas on how to improve it, ranging from minor
changes to entirely new modules. The small changes are
usually treated as maintenance, but large-scale additions
might need approval as a new development request.