| People are often reluctant to change. The effect of change will
manifest itself in people finding endless ways to rubbish the new and applaud
the old, reverting to old ways, committing sabotage and even having to
take time off through a stress related illness. Resistance will happen
so it is best to be prepared.
You will gain more credibility with users if you understand the domain
and the legacy system. However it may take time to obtain this status and
it will be easy to loose if subsequent problems arise.
Making it clear to users what to expect serves two purposes. It lessens
the shock of change by making them aware that change will happen. By being
explicit about the scope of the change, they will also be less inclined
to insist on new features which could affect the main objectives of the
project.
The phased approach introduces change gradually which should lessen
the impact on users.
If users are involved and consulted, they gain a sense of ownership
and empowerment. They will also be less inclined to offer good advice after
things have gone wrong. However, it is unlikely that all users can be directly
involved in the project and those that are not may feel disenfranchised
- unless they feel their seconded colleagues are their representatives.
Prototypes can show users what is possible and what has changed well
before they are faced with having to adapt during their normal work.
When faced with a new system users may feel intimidated. By providing
training they can become familiar with the new situation away from their
normal working environment and pressures.
Changing UIs or printouts may be unavoidable, but if the changes can
be minimised the users will provide greater acceptance of the new system.
When the users are disrupted by errors in the new implementation, they
will be less inclined to trust the system, even when the errors are fixed.
By comprehensive testing, the risks of them encountering problems are reduced.
Also, since an incremental migration strategy is being adopted, bugs are
easier to find and quicker to fix in each small new release.
Whilst coercion may be useful in some circumstances, for example offering
rewards in return for supporting the project, it may be less appropriate
here. Firstly, rewarding users for silence and compliance will not encourage
positive support for the project, whereas rewarding developers for enthusiasm
and action will. Users are less well placed to take action and artificially
heightened enthusiasm may overload the project's requirements. Secondly,
it may be more expensive to reward users than developers since there will
probably be more users. Finally, for some, rewards will not affect the
perceived stress that change will create. |
