Overview of Implementation Planning

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

Introduction

Recent IT history has been littered with examples of major IT Systems, often in the Public Sector, where the implementation has gone horribly wrong. We do not claim that we can prevent such problems but we hope that, by using our experience, you may avoid some of the problems.

Functionality

Before you start implementing any system, you need to ensure that the system provides the functionality that is required. If, subsequently, it is found that something has been omitted, the supplier is likely to decline responsibility if the system has been accepted. There are a number of steps, which should be taken:

• ensure that there is a document clearly identifying the detailed requirements, usually a Statement of Requirements, or Invitation to Tender, which has been produced by the customer and documents the requirements in business terms, not in technical IT language. Details of the contents of, and how to produce, a Statement of Requirements, are contained in one of our other sub-webs (Selecting Computer Applications Software), especially in the page on Producing a Statement of Requirements and there is a guide (see Downloads);

• ensure that this document forms part of the contract;

• if a Systems, or Program, Specification is produced, by the supplier, for approval by the customer, it should clearly identify which requirement points it covers and how. The commonest problem is where the specifier thinks that they understand the requirement and mis-understandings are only identified further down the track, when modification is more expensive. A technique, which was used, many years ago, on major projects, was a Structured Walk-Through, where the designer had to describe the system, in detail, to other designers, not directly involved in that area. It may be appropriate for a customer representative to attend such discussions, to ensure that the understanding is correct;

• the user test should ensure that all the major functional requirements, and as many of the lesser requirements as can be fitted in, are thoroughly tested. To assist this, it may be appropriate to annotate a copy of the Statement of Requirements with details of which tests ensure that a particular requirement is working properly.
  

Approaches

The approaches, to the actual implementation, vary a little, depending on whether you are implementing:

• a purpose-written, also called ‘bespoke’, system;

• a standard ‘packaged’ system; or

• a ‘packaged’ system with ‘bespoke’ amendments / additions
  

Below, we have identified the major elements in each approach, and these are the explored in more detail later.

Bespoke

In considering this approach, we assume that the system is being developed to meet an agreed set of requirements. If this is not the case, then the first requirement is to produce a statement of requirements, as mentioned above, as this is the benchmark, against which the suitability of the bespoke software can be assessed. If you require guidance on how to produce such a document, see our advice on Selecting Computer Applications Software / Preparing the Statement of Requirements.

Packaged

In considering this approach, we assume that the a standard ‘packaged’ system is being installed, which is being ‘tuned’, usually by setting parameters or selecting from a range of standard modules, mini-modules, or ‘granules’, to meet an agreed set of requirements. If this is not the case, then the first requirement is to produce a statement of requirements, as mentioned above, as this is the benchmark, against which the suitability of the ‘tuning’ of the system can be assessed. If you require guidance on how to produce such a document, see our advice on Selecting Computer Applications Software / Preparing the Statement of Requirements.

Mixed

With this approach, you are implementing a ‘packaged’ system, with some purpose-written additions. In this case, implement the standard package, as described in this document, with the additions being implemented as bespoke software.

Implementation Process

Now the hard work starts. You need to:

• set up the Project Management Structure;

• prepare an Implementation Plan;

• for Packaged systems, Configure both the system and your internal procedures;

• for Bespoke systems, Test the software;

• Train the users;

• Set up all the files of information;

• Parallel run the system to ensure that it works as well as the existing system (either manual or computer);

• Be aware that problems can occur and plan for them.

Finally

At the end of this process, the system is said to be running LIVE. The usual practice, however, is that dependence on the new system gradually increases so that there is no sudden point at which this can be said to have occurred.

Other Areas of Advice

There are certain other areas of advice, relating to IT systems, where we can help, and which may arise before, during, or after the implementation process. These include:

• Resolving Conflict;

• Part-Time Management;

• IT 'Guru;

• Contingency and Disaster Planning;

• Computer Effectiveness;

• Staff Appraisal;

• Recruitment;

• IT Awareness.
  

For information on any of these topics, see Other areas where we can help