The fifth stage of the classical six stage
systems analysis model.
- To put
into practical effect; carry out: implement the new procedures.
- To supply
The “GO” button of the
systems analysis lifecycle, the implementation of the plan drawn up and codified
in the design stage, implementation is the fulfilment of the efforts so far made
and (given our analysts are any good) the realisation of the dreams and hopes of
workers and managers alike.
Now any code required will be
written, hardware assembled and training manuals will be assembled.
All the choices have already been made and any graphics will have already
been produced. This stage is so
called because it is the implementation of the designs made in the previous
Every team member will now be
working on his or her assigned task. It
is not necessary for any team member to know what the whole will be like if the
planning of the design stage has been done fully and skilfully. However one
should consider the example of Microsoft who are renown for not telling
programmers what they are programming and the result – software that requires
years of fixes and often simply doesn’t work.
It is important to remember that while it is possible to do much in
theory - in practice things are never quite the same. While engaged in the implementation of a project plan never
forget that human beings are involved. This
may sound trite but in actual fact this is a vital distinction for the
successful market leader to recognise.
After the alpha testing of the
system, which takes place “in house”, there are a couple of implementation
- Full and sudden replacement
- Gradual phasing in of new system (usually with concurrent operation of systems)
Option two is the only one that
becomes feasible as the size of the system increases; this is not necessarily a
good thing. A popular
implementation of the second implementation option is department by department
(or room by room) full training followed by replacement.
Sometimes the beta testing forms
part of the final implementation of the system but this is not always possible.
Even if it is there is the danger of early versions remaining in the
system creating security holes and even endangering the data.
The systems analyst must be aware of these dangers and take appropriate
steps to avoid them.
However one of the major problem
groups that should have been dealt with during the design stage are the problems
associated with a gradual phasing in of a system and these can easily be over
- Incompatibility between the two systems
- Data conversion time-scale
- Data input requirements
- Interruption to work often running over many weeks
- Limitation of ability of users to function normally
Implementation can be one of the
most volatile and disruptive processes the user / client can encounter.
If done poorly then the interruption caused by this stage can be many
orders of magnitude greater than the in-depth study.
The planning carried out during
the design stage should have anticipated this and this stage should pass without
a hitch. However this is never
going to be the case in a real life scenario so as this stage prepares to be
started the analysts should have clearly specified their plans and systems in
place to minimise the negative effects of implementation.
Part of this planning requires
liaisons with management to discuss the planned timescale of implementation.
It is often noted that most of the loss control during this stage
depends solely on the clients themselves.
Points to be considered
during this process are:
- What will works be doing while normal work is
impossible due to interruptions?
- How customer requests will be dealt with?
- How will an image of “business as usual” while
this is going on?
- What temporary measures will need to be implanted
After a few messages back and forth I feel it necessary to point out that the implementation options come in a number of different flavours but they are basicly one or the other.
Classical Model of Systems analysis. AKA the System Life Cycle
- Project Selection
- Feasibility Study