These days, with software increasing in flexibility (but also complexity) and users becoming more aware of the power of computing systems the "out of the box" software implementation is effectively a thing of the past.

Most companies looking for new software will be replacing a current system and will not want to loose existing data or functionality (often bespoke).

Key aspects of successful implementations are to have top management commitment and to involve and empower the users.

Users have considerable influence over the success of a project, if they believe the new system will benefit them, and they gain status/credit for a successful implementation, they will work to ensure its success. If they are having the system imposed on them without due consideration of their agendas, make sure they cannot influence the implementation (difficult) and that they do not have the ear of senior management. (A user is somebody who tells you what they want the day you give them what they asked for.)

Bearing this in mind, the path to a successful implementation could look like this:

Preparation

Document the project scope and timescale, outline tasks. Understand and use a leading methodology, but be aware that it is unlikely to be an exact fit. Experience of several methodologies is an advantage, then it is possible to extract the relevant aspects of each.

Create a project plan using a project management package and keep it up to date throughout the life of the project, Microsoft Enterprise Project Manager is suitable for this and offers full multi user functionality. (If you fail to plan, you are planning to fail.)

Create templates for issue logs / error reports. (Of several possible interpretations of a communication, the least convenient is the correct one.)

Personnel

Ensure senior managerial commitment for the project, this can come for many reasons but the key is usually the potential of the software to improve profitability or reduce risk.

Personnel seconded to the project can retain their normal day to day tasks but this will result in extended implementation timescales. It is best to have a small dedicated full time project team built from key personnel than an extended number of part timers. Fewer people reduces the communication/scheduling issues and creates an "expert pool." (Too few people on a project can't solve the problems - too many create more problems than they solve.)

First steps

Confirm the roles of project manager(s) and project sponsor (senior end user director/owner). If a consultancy/supplier is used, two project managers may be required, one for the customer, one for the consultancy/supplier. (A problem shared is a buck passed.)

Project manager creates outline project plan with high level tasks. (If you don't know where you're going, any road will take you there.)

Have a project kick off meeting to collect the project team together and assign tasks and other roles.

If applicable either before or after the project meeting, investigate/document the business processes that the software will cover. (What you don't know, hurts you.)

Update project plan. (A badly planned project will take four times longer than expected - a well planned project only twice as long as expected.) 

The action takes place

Project manager(s) add detail to the project plan and manage the scheduling and achievement of the tasks. (The sooner you get behind schedule, the more time you have to make it up.)

The tasks may include, data take on, customisations/configuration, project team training.

Training is often a contentious issue, users want the software to reflect the way they currently run their business, software "out of the box" will rarely allow this. So the project team needs to be trained on the "out of the box" software, then manage the creation and testing of the customised system.

"Train the trainer" - do not use outside experts to deliver the end user training, have the project team trained and then make them train the end users. This will both add to their expertise and validate any end user change requests. They will also talk the same language as the end users and will be the initial line of support after go live.

Understand the software fully before embarking on customisations, could you be overlooking a better way of working? (The sooner you start coding, the later you finish.)

Update project plan regularly

Periodically, as appropriate, have project meetings, as a minimum - one kick off and one before go live.

Testing

Simulation exercises, where the system is tested by the project team/end users and the results validated, provide useful indications as to the fitness of the solution. These exercises are an iterative process, initially probably involving only the project team, but in the later stages increasingly utilising end users who will use the software daily. This increases the user familiarity with the software, validates the user training and highlights possible gaps in functionality.

The final simulation exercise should replicate the procedure to be adopted for go live, using fully representative data and timescales. All the steps to be followed during go live should be documented and tested.

Until the final simulation is successful, both in terms of system integrity and the time taken in setup and execution, the go live success will be in doubt.

Update project plan regularly

Go live

In preparation to going live, notify any external contacts that may be affected (customers/suppliers) and aim to reduce as far as possible the initial load on the new system.

If the simulation exercises have been followed, go live should just be a repeat of the final simulation and offer few surprises, but be prepared and allow time for any that do arise!!

After implementation, undertake a review to investigate the performance of the software.

(I like deadlines, especially the wooshing sound as they fly by.)