Ten golden rules to avoid delays in ERP projects

The transformation of businesses today is, more often than not, enabled by underpinning IT which automates the transformed business processes,write Mark Watmough, director atBarnsnape Consulting, and Amanda Lewis, partner atDenton Wilde Sapte.

Increasingly this automation is achieved through the adoption of single integrated software packages that provide 'leading practice' business processes. These processes require configuring to meet the business need and avoid the comparatively risky bespoke developments previously undertaken. The consequence of this is that package-based IT has moved centre stage in delivering major business change, and the specification and control of the delivery projects is more critical than ever in achieving the desired outcome.

The authors both have extensive experience of the definition and delivery of package based solutions; and find that the strategic nature of these solutions has now more than ever made the correct initiation of such projects absolutely critical to achieving the desired outcome. Initiation has many aspects: this article focuses on delivering the transformation project. These experiences are captured in the ten Golden Rules described below. These Golden Rules are derived from experiences with SAP based projects, but are applicable to any major package based implementation.

The risk that the newspapers regularly report on package based projects is that they have taken years to implement. Package based projects are likely to experience delay when clients do not realise that an integrated package implementation is not an IT implementation but a business transformation enabled by IT. Such projects involve the client making important decisions about the extent to which it will either adapt its business processes to fit the package or customise the package to fit its business processes (the former is in general preferable).

This means that clients must ensure:

1. Clear scope, cost and benefit. The project scope, estimated cost and predicted benefits have all been clarified and established.
2. Stakeholder support. The relevant stakeholders have bought into the project. This involves adequate consideration of communication and training issues.
3. Clear service descriptions. Clients must have clear service descriptions setting out which actions they are responsible for and which actions the supplier is responsible for, otherwise:
   • The failure to document the supplier's obligations means that the supplier can make an additional charge for additional work carried out, which may undermine the business case for implementing the package.
   • The failure to document the client's obligations may make it more difficult for the client to appreciate the extent of its obligations and hence to ensure that it has appropriate and adequate resources.
4. Supplier due diligence. If the client is appointing an external supplier to implement the package, it is essential that the client carried out adequate due diligence relating to the supplier. It may be helpful if the supplier has a 'leading practice' model from implementing a package in a similar business which they can start from.
5. Appropriate contractual documentation. Contractual documentation needs to reflect the particular nature of a package implementation and the particular risk transfer envisaged for the specific project hence generic IT implementation contractual documentation is not helpful. For example, is the supplier providing consultancy services on a resource basis or is the supplier responsible for ensuring that the customised package meets certain pre-determined acceptance criteria?
6. Sufficient resources. The implementation team includes sufficient business and IT people to make decisions and take the necessary resulting actions such as making changes in business processes.
7. Informed decisions. The relevant people need to be empowered and able to make informed decisions in line with the project plan so that they are aware of the implications on the business of adapting the clients' business processes to fit the package and the implications on the implementation of future releases of the package of adapting the package to fit its business processes.
8. Project management. The project is adequately project managed. Project deadlines are realistic and changes to the project plan are managed under strict change control.
9. Contractual incentives. The agreement with the supplier includes sufficient contractual incentives to ensure that the project is implemented on time and to budget, meaning that engaging the supplier on a time and materials basis may be inappropriate.
10. Data Migration. The data migration ultimately determines the exposure to risk that the operating business has as the package solution delivered by the project takes on live data. The magnitude of the data migration drives the number of staff who are impacted by the migration and the scale of the training required before the migration is undertaken. The cleanliness of the data determines the degree of 'after shock' felt by the business once the data has been migrated and is being used in the live environment.

These rules distil the author's experiences of avoiding project delays, gained from multiple projects undertaken over many years. Adhering to them will help to reduce the risk of implementing major package based programmes.