This is the part of the sub-web covering the Implementation of Applications Software. To go to the overview of this sub-web, please click Overview. To go to the web-site home page, please click Home.

There are many problems, which can occur during the implementation of a system. This area will, gradually expand, but, initially, I would draw your attention to a few potential problem areas:

• • unrealistic timescales. When the implementation plan is drawn up, it should, obviously, take into account any constraints, such as deadlines imposed by the business, legislation, et cetera. It is important, however, to identify timescales that are unachievable, and try to revise the plan so that by adding resources, changing priorities, and rescheduling other tasks, achievable timescales are set. There is no point setting a timescale which cannot be achieved. It de-motivates staff, and it tends to produce an attitude which allows slippage in other areas which, with realistic timescales, could be avoided;
  • project creep. During the process of an implementation, additional, or changed, requirements often emerge. These can lead to significant changes being required to the system, often when the appropriate parts are already being implemented. A fairly firm approach is needed to handling such requests, and often consists of three elements:

* small requirements which can be met by simple report / enquiry procedures are treated as simple add-ons which can be provided after the system is live,

* larger requirements which are not needed immediately. Unless they drastically affect the a significant part of the system, hold them back until the system is fully operational. Then set up a separate project to plan and implement these changes, with adequate testing to ensure that they have no significant impact on the rest of the system,

* larger requirements which are required immediately, or which, while required later, have significant effect on the system. STOP and think. You need to analyse where the changes will have an impact. The plan will need to be revised to incorporate modifications, changes to programming, and configuration and will, probably, involve some re-testing. Only when you have identified the impact of the changes can you continue with those parts that are not affected, and start work on the areas which are affected. The total impact of the changes should be determined, and the affect on resources, including cost and timescale, should be reported back to the steering committee, who may decide that the change is not worth the effort;

• user commitment / acceptance. A system is less likely to work successfully if the users resent it, or do not believe that it will help them. Accordingly, it is advisable to plan, from an early stage, to involve key users in major decisions, and keep the ultimate users well informed about what is happening, and any positive impact on their jobs, especially any current problems that the system will remove. This helps to create an atmosphere of interest and acceptance.

We are happy to expand this page. Please contact us with problems that you have encountered and, if we feel that they have general relevance, we will be happy to incorporate them.