Implementation Methodology and Principles

Implementations of this nature will differ according to each customer’s unique requirements, but in general the principles that will be applied are as follows:-

1. Establish key role players and project teams

Both the customer and FleetDomain will need to determine the key personnel that will oversee the implementation project. An overall project manager, as well as a project committee consisting of members from both organizations, will need to be appointed. A project plan is then drawn up, including details such as timelines, meeting schedules, responsible persons, and critical measurement points (sometimes called Quality Gates).

2. Establish a detailed customer requirement

This step is the most critical component of the entire procedure. FleetDomain will follow a detailed process to map out each unique requirement, usually by drawing up process flow diagrams in conjunction with key role players and users within the customer organisation. These documents will be used to create a User Requirement Specification (URS), which is then approved by management, and which will be used later as template for user acceptance testing and sign off.

3. Establish interface requirements

All interfacing requirements need to be established, both within the customer organization and with any 3rd party vendors. If FleetDomain already has some of these interfaces in place, permission will need to be obtained from the vendors to supply their information to FleetDomain and if not, then discussions will need to take place between the technical staff on both sides to establish the exact specifications.

4. Draw up a Technical Requirement Specification (TRS)

Once the above two steps have taken place, a TRS can be created, which is a document used by the FleetDomain development staff to develop all of the necessary configuration and functionality changes that are required.

5. Development & unit testing

Based on the TRS, development of the system will take place at this point. Also included in this phase is unit testing i.e. in-house testing of each component, as well as stress and volume testing.

6. Data clean-up and migration

In parallel with the above steps, a sub-project to establish the accuracy of legacy data and the steps required to migrate this information to the new system will be created. This component typically forms the baseline for the entire project, although it is often overlooked. It is usually also a sensitive issue, as information needs to be obtained from the legacy system supplier, and this transition has to be handled with respect and diplomacy. Once the data has been imported into conversion tables and verified, scripts to export the information must be created and tested.

7. Change management

Humans have an inbuilt resistance to change, and it is important to prepare the users for acceptance of the new system. The decision to move to a new application is usually done at senior management level, and users can feel disgruntled and resistant when presented with a new methodology without prior warning. It is important that, in parallel with the other phases, users are kept informed of the progress of the project and the projected go-live date, and are reassured by the knowledge that their work experience will be improved.

8. User acceptance testing

On completion of the development phase and preferably using legacy data obtained via the migration phase, user acceptance testing needs to take place. It is vital that this is strictly controlled through the use of a test plan based on the User Requirement Specification, and each user department will need to sign off each component as it is completed. Changes that result from this phase will be documented and looped back to the development cycle, and the project plan will be adjusted as necessary if the timeline is to be affected.

9. User training

This phase must not begin until the user acceptance testing has been completed. A fine balance needs to be achieved in that training should not begin too early or should not be delayed until after go live. Training should consist of both general usage of the system, as well as focused training on specific aspects of the system. If possible, training should happen in a simulated live environment, using legacy data if the data migration phase has been completed.

10. Go live

The go-live phase consists of the preparation of the system environment, deployment of the system and database, data migration, final unit testing, and switch on.

11. Post implementation support

Sometimes referred to as “hand holding”, this is a critical time in the life of the project. The first two weeks after go-live can easily determine whether a project is successful or not, and users often need the comfort of knowing that help is at hand when required. FleetDomain would usually assign support personnel to be physically on-site at the customer’s premises during this period, although this is not always possible if spread over multiple locations, in which case support personnel would be constantly available to help via telephone or email.

12. Project closure

It is important to analyse the project upon completion, and to take note of both the successes and the failures. Feedback from the customer and the users can be used to correct shortcomings, and to improve the life cycle of future projects.