Standard Delivery Method (Kickstart)

Time to value

Typical ERP projects last between 6 and 24 months. This is a broad range, with ERP meaning different things to different businesses, therefore comparing your project against “typical” may not be helpful. However, it can be assumed that the faster that you can get started on the new system (with the desired benefits being delivered) the faster your business will be receiving value from the project.

By using a standard approach many “unknowns” are removed or controlled, as it brings previous project experience into the template and bridges gaps where unknown-unknowns can often sneak in. This helps to address many of the failure points detailed above.

Quick delivery reduces cost

As the age-old adage goes: Time is money. The cost of an ERP procurement has been speculated on for decades, with metrics of software:services being estimated at 1:1, 1:1.5, 1:2, etc. However, supplier costs are only part of the cost of the project, internal costs often exceed the external expenditure on long projects.

Each passing month on a project not only elongates the supplier cost, and the internal resource cost, but also the opportunity cost of having received the benefits of a new system.

There are some specific measurable benefits that can be seen; even when other services are not being delivered, even when a project is in hiatus, there is likely to be a project management overhead for every week/month that elapses. In order to re–plan & restart project activity the PMs must be involved throughout, even in low-activity periods.

There is also a general rule of human forgetfulness, long projects tend to require repeated phases of testing and training as the users tend to forget the new system if not “touching” it regularly. This repeated activity also drives up project costs.

Identifiable deliverables + Scope control = Measurable success

Being able to look back at the origins of a project and clearly identify that the pain points have been ameliorated, the desired outcomes have been achieved, and stakeholder goals have been reached is an ideal result for a project. This is, self-evidently, only achievable if the goals have been identified, the desired outcomes mapped, and the pain-points documented.

By starting a project with these things, and then implementing scope control (using the mantra “does _______ help us achieve the stated aim of ________?” in control meetings), will allow one to measure success at the end of a project. If everyone knows on day one of the project that the CEO wants dashboard reporting then it should come as no surprise at the end of the project that if the dashboards are not delivered the the CEO will not see the project as a success. The likelihood of this occurring if the aim becomes integral to the project (i.e. this outcome is kept in mind as the project continues e.g. asking the following throughout “are we capturing the data for a dashboard?”, “do we have a way of measuring x?”, etc.).

Project success can only be achieved if your business knows what success looks like. Similarly, scope can only be controlled if a) scope is known, b) desired outcome is known.

Business process review time savings

There are clear benefits to adopting best practice, those being: modernisation of process or introduction of process, and standardisation of processes across the business. The problems in different businesses may be different, however they can be viewed in the same way, with the same solution.

• Absence of process? Start with best practice.
• Inefficient process? Start with best practice.
• Entrenched process (quality unknown)? Start with best practice.

This is not a glib suggestion that the ERP supplier knows best, but rather pointing out that a large amout of time can be automatically saved by cutting out extraneous dialogue and prevarication over what the best approach to take is. If in doubt, start at “best practice” and go from there. This has the benefit of saving internal and external resource time, and can take the “heat” out many decisions by removing personalities and introducing an objective start point.

Supplier resource interchangeability

A hidden, but non-trivial, benefit of adopting a standardised delivery methodology is that the supplier is more capable of swapping resources within a project, flattening the learning curve on a new project, allowing easier hand overs, and collaboratively improving the framework.

This significantly increases the resilience of this project by bolstering the supplier resource. This interoperability of resources also allows for the introduction of new ideas/best practice from other consultants/PMs, etc. as more people can be easily involved in the project.