Implementation cost overrun - mostly preventable

22.04.18 05:50 PM By Matt Koopmans

Business Systems Implementation is hard, and expensive. The company is investing significant time and money to get the new system up and running, with an expectation of Return On Investment. The ROI is determined by two factors - the cost, and the benefits. Today we are diving into the cost, the unforeseen (or at least, unbudgeted) cost. 

 

Accuracy of estimation

Transformation projects are complex - especially when it involves moving from one business system to the next. The more complex your current system, the more complex the transition will be (regardless of the simplification of the end result). Underestimating the complexity will result in significant project overrun. It seems prudent to err on the side of caution. That is a fallacy - overestimating complexity will not give more insight in the "unknowns" of the project - it just allocates budget to where it is not needed. And budgets on projects behave like storage space in a home - it gets allocated to stuff you do not need. A thorough analysis of the current systems and processes, and based on that building a comprehensive transition plan, will uncover the knowable complexities. Budget contingency should cover the unknowns.

 

Data migration

The more data you have, the more likely it needs thorough cleansing, and the more expensive that process will be. As this is a known fact, and since most companies have done at least one ERP implementation in the past and have the tools to minimise the risk on data migration: limit scope (especially finding alternatives for historical transactions), as well as starting the master data cleansing program well before the implementation of the new system starts.

 

Integration

There are three main categories of integration: integration to third party systems (i.e. banks, vendors, customers), integration to other line of business applications and hardware systems (i.e. MES, CNC systems, IoT), and transition integration (temporary integration to systems that are due to be replaced as part of a future release in the current committed program). A well-defined enterprise architecture provides prescriptive guidance to the long-term integration. The nature of the existing or third-party integrations is known (as only one end-point changes). Therefore, the first two types of integrations can be well defined prior to the commencement of the program. The third type - temporary integrations to applications that are to be deprecated because of the program - will be in place for a few weeks, months up to a few years (pending the length of the program). Whilst the permanent integration can be built with the robustness long term supportability demands, the temporary integration is orchestrated to the constraints of volume and frequency - long term supportability is not a major concern.

 

The most common cause of overrun - and it is totally preventable 

Over the last two decades, many expensive lessons have been learned with regards to estimating the complexity, data migration, and integration. Whilst still project cost overruns can be attributed to these factors (more than they should be!), they are no longer the most common factor. The most common element of project overrun - both in time and budget - is leakage of time. Whether the program is contracted on time and material, or outcome (fixed fee) basis, time leakage will have a financial impact on both cost and benefit of the program; such as cost of consultants, additional desk space, bandwidth, replacement staff for designated users, travel and expenses associated with the program, etc.

Prevention is the only cure. Once time is spent, it cannot be unspent. Here are a few steps to prevent leakage:

·  Prepare - not over-prepare: current systems analysis and audit, data analysis, integration preparation - these can be prepared in advance. But realise that there is no perfect - determine what is good enough (the point of "good enough" has been reached where the investment required to improve is less than the intended benefit);

·  Analyse - not over-analyse: detailed business requirements are helpful, necessary even; but the business is going to change with the new system, therefore over-analysing the process is an exercise in futility.

·  Lather, rinse, repeat: small iterations in a program after the preparation and analysis keeps the complexity under control. A small iteration has less tolerance for slack than a large iteration - allowing for a more robust mechanism of control of leakage.

·  Keep score: create a convertible score of the three main levers in the project - Scope (benefit), Time, and Resource - each converted into a "tradable currency" (points, dollars, minutes - it does not matter what it is, if they are convertible to time, scope and resource). Set ownership and accountability to the business groups for making trade-offs with that currency. Across the business groups, it is not a zero-sum game - the currency can grow as a total (increased benefits) or shrink (leakage). A group incentive (gamification) and a company incentive can be published and reported.

 

 

Facilitator

As business do not implement a new business system often, and the decisions that do need to be made can have a lasting impact, it is highly recommended to employ an independent facilitator, who spells out what the cost of a decision is in practical terms: the cost of delay (for further analysis, debate, etc.), the cost of rework - offset to the intended benefit. There seems to be an inverse relationship between the impact (benefit) of a decision, and the time it takes to get to consensus (so-called bike-shed effect - C. Northcote Parkinson). Independent advice moving the project along may prove to be a worthwhile investment.


Originally posted: 31 July 2017

 

Matt Koopmans