Group/Individual
Level
You have finally reached the stage that most people
equate with implementation. You have done all of your preparatory work and have dealt with
as many people-related issues as you can. It is now time to execute your plans, to
activate any facilitating structures not yet in action, and to manage the transition
process from the present state to the desired state. This is the phase in which many of
the major changes you are trying to implement actually take place.
Many of your detailed implementation planning activities
carry on into this stage, while the activities in this roll-out stage flow seamlessly into
the confirmation stage that follows. There are no clear-cut boundaries between any of
these stages. Nevertheless, there are several issues to be considered at this point. To
access information on these issues you can click on the listing below, or scroll down the
page:
- Go to related information
on initial
implementation planning.
- Go to related information
on detailed implementation
planning.
Training
on the system or in the new processes
Once you have addressed the issues in the previous three sections
at this level (i.e., knowledge and awareness, facilitating structures, and persuasion,
decision, commitment), you should be ready to actually begin installation of the
innovation or technical changes. You will have completed initial education and training of
the appropriate people, made them aware of what is going to happen, put in place any
necessary structures, policies and procedures, and helped people reach the point of
committing to, or at least being convinced of, the fact that implementation will occur.
As mentioned during
the knowledge and awareness stage, during the early
parts of your program, people will need education and
training in areas such as communication skills, working
in groups, and an introduction to the specific technology
or innovation you are implementing. That initial knowledge
and awareness-raising training is not enough. At this
point of roll-out, people must have more specific training
on, for example, how to use the basic functions of
the new technology or how the new strategy, structure,
innovation or changes will operate. In other words,
although you warned people 'it would be coming', they
need to know how to 'turn it on' and how to do the
basic operations now required. After a period of time,
people will be ready for a third wave of more advanced
'training for mastery'.
Go to related information
on education
and training.
Top of
Page.
Conversion
At this point, you can finally attend to the logistical processes of installation. You
can execute your plans (as developed in your initial and detailed implementation planning)
to deliver and set-up the innovation or new technology. You may be converting prototypes
into fully operational systems or switching from old systems to new ones. If it is social
or administrative innovation with which you are concerned, it is time for you to move from
the small-scale, pilot-testing stage, toward a full roll-out of the processes.
This is the point when you turn-off the old system, and
turn on the new one. It is the point when you make the transition from your old work
arrangements to your new team-based structures. There are, in reality, any number of
different ways to make these transitions. Nevertheless, there are three broad conversion
options that should be considered: (1) slow migration from old to new, (2) run parallel
systems, (3) quick switch from old to new. Each option has it pro's and con's and some
options are not possible with certain innovations or new technologies.
- Slow migration from old to new. This conversion option
gives you time to learn from early trials and make necessary adjustments, and it allows
users time to adapt to changes. Unfortunately, it takes longer than a quick switch-over,
and may be seen as evidence of uncertainty. With some new technology, such as a computer
integrate manufacturing (CIM) system, this incremental change strategy is not an option.
Installing a number of islands of automation and slowly linking them together is
frequently not possible.
Much technology is purchased piece-by-piece. When people try and link those islands of
automation, they find a qualitative leap in complexity from stand-alone to integrated
systems. Much more than interfacing equipment is involved if the system is to work
properly. For example, production and support functions need to be reorganised and
integrated as well. Research shows that the more integrated the equipment, the greater the
training needs. Also, it has been shown that successful manufacturing plants using
integrated CIM equipment had operators spend an average of 12% of the work-week
identifying process improvements, while successful plants with stand-alone equipment had
operators spend an average of 4% of the work-week identifying process improvements. This
illustrates that human resource issues, as well as the organisation of work, frequently
need to be modified in order to successfully integrate new technology. If integration is
an issue for you, consider the other two conversion options. If integration is not a
problem, consider this conversion option.
- Run parallel systems. This allows you to have a back-up
system, as you are trying-out your innovation or new technology. This is a particularly
good option if the continual operation of your systems is critical. Unfortunately, it
frequently costs a great deal of money to run redundant systems, or it may not be feasible
technically. Before choosing this option, however, you must consider the issues of
reliability and rigidity discussed below. If reliability is an issue for you or if your
systems are rigid, then you should consider this conversion option.
Reliability. The reliability of a system does not only depend on the characteristics of
the machine (e.g., its design, materials, and construction). Reliability depends a great
deal on the knowledge and activities of operators, support functions, and managers. For
example, on-line financial data processing in banks has huge implications for training and
the need for reliability as data input has instantaneous effects throughout the system.
Therefore, operators' actions become critical. The data's internal coherence is vital.
Electronic systems checks and filters catch a great many potential mistakes. However, the
errors that remain are costly and complex.
Rigidity. To find out how rigid a system is, one must ask questions such as "Are
there alternative paths for products/services to take, if a certain path or machine breaks
down, or does it become a bottleneck?" In service firms such as a bank, for example,
similar questions are "If the computer goes down, can transactions continue?"
"Can we continue doing business without our technology?" This issue is related
to the concepts of centrality and interdependence of tasks and functions. If the automated
task is central to the operations of the organisation, or if many other operations
"down-stream" from the computer are dependent on it for their inputs, then the
systems are highly rigid.
High rigidity requires higher priorities of the equipment for maintenance, for repair, and
more importance needs to be placed on reliability. Also, if systems are highly rigid and
critical to successful operations or service provision, then back-up, redundant, or
emergency systems become necessary.
- Quick switch from old to new. While this option is
decisive and may be more cost-effective in the short-run than operating parallel systems,
the danger is in terms of operational effectiveness. If the conversion is not successful,
it could cause major problems. If reliability, as discussed above, is not an issue for you
or if your systems are not rigid, as discussed above, then you could consider this
conversion strategy.
- There are several other conversion issues to consider:
- Budget sufficient time, money and effort for conversion,
especially data conversion.
- Educate and involve everyone who will use the innovation
or new technology before installation.
- Begin training long before the innovation or new
technology is actually delivered and ready to be "turned on".
- Do not make the innovation or new technology operational
before it is fully ready. Even if you are over time and over budget, rolling out a product
while it is still incomplete, will only make it worse.
- If appropriate, develop quality documentation that is
written from the user's, not the developer's, perspective.
- Provide people, money and time for proper evaluation,
modification and maintenance.
Top of
Page.
Project
termination
Before you get too far into your roll-out process, you must consider project
termination. There are several reasons projects are terminated:
- Completion. If the implementation was a success, you
eventually reach the point where you need to hand over the project to those responsible
for "normal' operations. If you are a consultant, this may mean handing the project
back to the organisation and terminate your involvement with the project. Project
completion is a process, not a single event. This is where this roll-out process blends
into the confirmation stage.
- Convenience. Termination
for convenience is often a difficult decision. There
is often the connotation of project failure. Very
often business objectives change, senior executives
or management personal change, markets and technology
change, cost expectations are over-run, progress is
too slow, etc., and the decision must be taken to
discontinue the project. If this happens, it is best
to manage the process right away by communicating
the truth to everyone involved and affected. (See
related information on communication
and on processing.)
There is always the potential for serious negative
reaction when a project is terminated for convenience.
We frequently try to lay blame, to clear our names
and reputations from the failure, and to make it seem
that it was not a decision we actually made by choice,
but we were forced into it. It is very rare, however,
that failed projects are a total waste of time, money
and effort. People gain experience and much technical
and non-technical knowledge is generated and can be
captured and learned from if managed properly.
- Default. Projects may also be terminated by default.
Unsatisfactory technical performance, contract and legal violations, delivery
delinquencies, and quality discrepancies are all valid reasons for project termination by
default. In this case, the project has gone beyond the boundaries and scope of what we are
addressing in this manual.
Case
Study Template
As a final activity related to the Project termination step a Case Study of the
Implementation should be completed. The purpose of this is to establish a formal
documented case history of projects for later use. This Case Study can then be used to
share your ideas with others in the organisation that may stimulate further creativity and
innovation.
[Click
here to access the Case Study template ]
Top of
Page.
- Evolution
planning
Lastly, as part of your roll-out efforts, you must monitor progress, conduct testing,
breaking-in, and debugging, and make any necessary modifications. The process of
re-invention, discussed in relation to the topic of a technical analysis, becomes
relevant. Re-invention is defined as the degree to which an innovation is changeable or
modifiable by the user(s). In the process of its adoption and implementation, certain
innovations will be more or less modified by the users. Issues such as customisation and
incremental improvements via experimentation and adjustments, therefore, are relevant as
well.
At this point we find great overlap between this roll-out
phase, what we have discussed previously, in relation to facilitating structures and
detailed implementation planning, and the next stage in the process, confirmation.
Go to related information
on re-invention in the section on innovation
analysis.
Top of
Page.
Copyright © 1999,2000
Holistic Management Pty. Ltd.