Although some initial implementation planning has already been done, project ownership has to now devolve to the business unit and the users. Management functions must focus on marketing the innovation or technical changes, while technical issues such as reliability and delivery become critical considerations. Managers of innovation and technical change must take on the dual role of technical developers and implementers.
There is a tendency to under-estimate the importance of planning. Most people are in a hurry to get going. Someone once said, "The sooner you begin, the longer it will take you to it get done." This is the essential issue regarding implementation planning. The more you plan, the more you think through the issues now, the more you consult with and involve people, the easier it will be for you to install the innovation or technology later on.
At this point, it is important to begin to work out the details of what you are going to do during roll-out and how you plan to get it done. You can use traditional project management techniques or any planning methodologies with which you are comfortable. It is assumed you have the necessary technical skills such as project planning, scheduling, estimating, budgeting, and cash flow analysis.
In this section, we address several issues related to the human side of change, that you must consider as you develop your detailed implementation plans.
[See related information on securing resources and cost justification.]
Relate
your implementation objectives to your business objectives.
Specific goals and objectives
for adoption must be set, and requirements must be
specified for the technical implementation. At the
same time, however, you must not lose sight of the
greater business and strategic objectives. Take a
look at your organisational strategic planning documents
and your mission/vision/values statements. Be sure
to find out what initial implementation planning has
been done. Make your local implementation plans with
these strategic and organisation-level plans and documents
in mind.
Planning
for feedback and re-design.
As mentioned in relation to initial implementation planning, you will
be most successful if: (1) top management supports the effort, and encourages the team to
define the procedures to be used, (2) the technicians involved provide expertise and
computer resources, and are partners in, not drivers of the implementation, and (3) the
"users" manage the implementation and ensure coordination with both top
management and technical personnel. Unfortunately, this is rarely the way it works in
reality. Frequently, technical professionals have the task of implementation when
management support is minimal and users are uninterested, if not hostile. Otherwise,
management has decided not only what should be done, but exactly how it should be done,
and you are asked to make it happen. You must, therefore, plan for the fact that there are
going to be problems that need to be identified and addressed.
Feedback and re-design refers to the process by which information is collected about a new technology or innovation, and re-design activities are initiated to enhance its operation. The more complex a project is, the greater the number of iterations through this cycle you will have to travel. Whether you are dealing with a social innovation, such as moving to a team-based work organisation, or a piece of new technology, you will not have it all worked out upon installation.
A simple way to think about this is in terms of your level of certainty regarding what you need to do and how you will get it done. If you know exactly what you need to do and how you will do it, this is the easiest case. In this situation, you will need to involve users throughout the process and you will need to manage top management, but the process should be relatively straightforward. You must, therefore, plan for the fact that users and top management will need to be involved, and continually informed, from initiation and initial planning, through development, pilot-testing or proto-typing, installation, further testing, final hand-over, and routine operations.
In the case where you do not know exactly what you want to do, or exactly how you will get it done, you will need even more user and top management involvement and education. In this case, you will need to go through the same basic processes described above, but you must plan for a greater number of iterations through the planning, development, testing cycle. You will need more feedback and re-design loops as you work out exactly what needs to be done and how to do it, while you balance the technical requirements and risks with business and user needs.
Understand
your business processes.
Conduct a self assessment of your information and data flows,
information needs, and business processes. Have people explain the information flows of
other areas, as well as their own. This exercise
will be instructive as it points out the roots of many problems, and it facilitates the
awareness and learning process across functions, departments and other areas.
Market
your product.
Remember that an innovation's technical superiority and strategic
importance will not guarantee its acceptance. See related information on relative
advantage as part of an innovation
analysis.
You must plan to market your innovation or technical change. It is important to view innovation and technology implementation as internal marketing, not selling. You do not, therefore, start with the finished product and begin to sell it. You must plan a process of marketing. Do not over-sell an innovation or new technology. There is a distinction between marketing promotion and hype. Hype unrealistically raises expectations that can never be met. That invariably leads to disappointment and skepticism. As a good marketer, you plan to research who the users are, what their needs and preferences are, and you consider the positioning of the product in relation to all other competitive products, the distribution channels, and the infrastructure to support its use.
Establish
a specific migration plan.
Be sure you know (1) where you
are, (2) where you want to be, (3) how you plan to
get there and (4) how you will know when you are there.
Be sure to identify as many of the changes, dependencies,
and priorities as possible. Also be aware that you
may need to plan the construction of interim systems
as you migrate toward your goal. You may need to run
two systems in parallel for a time. You may need to
develop new procedures and to modify existing policies.
It is a good time to consider any second and third-order
effects of your proposed changes. For example, will
human resource policies and procedures be affected,
will sales and marketing procedures and systems need
to be modified?
Risk
analysis: Develop a realistic plan.
Take the time to thoroughly plan and study. You will be better off if
you take twice as long as you are used to taking during this detailed implementation
planning stage. This will lead to your taking far less time to iron out the bugs later.
You will need to involve managers, supervisors, engineers, technicians, quality people,
and operational employees in a thorough examination of your plans and their expected risks
and effects.
When we are considering risk in the implementation of innovation and technical change, we are asking broad questions such as:
There are three distinct activities involved in an implementation project risk analysis: (1) risk identification, (2) risk projection, estimation, assessment, and (3) risk management and monitoring.
(a) project risks - budgetary, schedule, personnel,
organisation, resource, customer/user, complexity, size, structure;
(b) technical risks - design, interfacing, verification, maintenance problems,
specification ambiguity, technical uncertainty, and
(c) business risks - market risks such as users not needing the innovation or technology;
management risks such as the innovation or technical change not solving the initial
problem, not fitting within the culture which is too resistant to change, not getting
senior management commitment and support; and budget risks such as the actual costs far
exceeding anything anyone expected.
1. Critical risk which is unacceptable (e.g.,
catastrophic).
2. Potentially critical risk which is acceptable on its own, but not in combination with
other risks.
3. Probably non-critical risk which is acceptable but must occur in combination with other
risks to lead to an unacceptable result.
4. Non-critical risk that is inconsequential.
The levels of risk involved in the implementation of
innovation and technical change vary with a host of organisational and technical factors
such as the size, scope, and level of complexity of the changes.
When assessing the level of risk consider four broad questions:
1. How structured is the project? Do users know exactly
what they want, and what the innovation or new technology should do for them? Do those
responsible for implementation know exactly how they will go about delivering the
innovation or new technology? Do the implementers, developers and users agree on these
points? If the answers are generally "Yes", then the project is well structured.
If the answers are generally "No", then the project is more risky. Less
structured implementation projects will (1) take longer, (2) require more iterations
through the design, develop, test, and re-design cycle, (3) present those involved with
greater dissatisfaction and reason for disharmony, and (4) be more likely to fail (i.e.,
they are more risky).
2. How experienced with the innovation or new technology being implemented, are those
involved? If you are moving to a team-based work organisation, and no one involved has
ever worked in this type of organisation or has ever moved an organisation to a team-based
work structure before, your level of risk is high. If you are implementing a new MIS in a
division when people in other divisions have already done so, the risk is less as you have
personal and organisational experience from which to draw.
3. How large is the project? Quite simply, the larger
the project, the more complex the project, the more
risky the project is likely to be. That is why pilot-testing
and prototyping are discussed and recommended as
part of the initial and detailed implementation planning
activities.
4. How big is the gap between where you are and where you want to be? If you have no
technology in your firm, and you are planning to implement a state-of-the-art
computer-based system to fully automate all aspects of your business, the gap between
where you are and where you want to be is large, and so is your level of risk. Likewise,
if you are a hierarchically organised firm, with strong centralised power relationships
and you are planning to move to empowered work-teams, the gap and your level of risk is
high. [See related information on the scale and scope of change. ]
Make
your vendor a partner in the implementation.
Most successful implementation efforts show a strong link between the
user and the vendor. If your vendor will not work with you in this manner, find a new
vendor. Consider what services the vendor supplies. Will they provide product support,
training, implementation assistance, planning aids, or other types of assistance?
Implement
a subset of the new technology.
Use pilot-testing and prototyping.
There are at least two good reasons for conducting a pilot project before introducing an
innovation: (1) to serve as an experiment/training ground and prove feasibility to top
management, and (2) to serve as a credible demonstration model for other units in the
organisation. Therefore, the choice of the site is critically important. First, be clear
whether the purpose of the pilot is experimentation or demonstration. Then choose the site
that best suits that need. Be sure to follow-up the pilot implementation. You are going to
have to learn from the pilot, to be flexible, and to use the feedback to make corrective
action.
Execute
your migration and implementation plans without getting
locked into doing exactly what they say.
Plan for the fact that once you begin roll-out, or once the pilot is
in place for a while, the organisation for which the migration and implementation plans
were made, will have changed. Implementation will have changed the systems on which you
are working. It is logical, therefore, that some adjustments will need to be made. You
will need to plan to revisit and revise your migration and implementation plans as
necessary. Do not lose sight of the end goal of the implementation process. The end goal
is related to business and strategic objectives. The end goal is not to follow the
migration and implementation plans exactly as they are. Therefore, your earlier plans are
best used as guidelines and as reference points to help ensure the direction of progress,
rather than as the ends toward which everyone is working.
Resources for more information on project management techniques:
Project management: A systems approach to planning, scheduling, and controlling (5th edition) by Harold Kerzner. New York: Van Nostrand Reinhold, 1995.
The handbook of project-based management: improving the processes for achieving strategic objectives by J. Rodney Turner. London: McGraw-Hill Book Co., 1993.
Managing high-technology programs and projects (2nd edition) by Russell D. Archibald. New York: Wiley, 1992.
Project management in manufacturing and high technology operations by Adedeji Bodunde Badiru. New York: Wiley, 1988.