Given that there are so many ways to fail ERP and CRM projects, it is no surprise that so many has been written about failure. But what about success? It seems that there is only one way to succeed, but all the planets and stars must be aligned, every duck needs to be in the row, and after singing the right mantra in the right key, maybe, just maybe, success is within reach. Surely this sounds much harder than it should be.
Limiting options to succeed
The first thing we do when we embark on an ERP or CRM project, is to limit the options for success. We negotiate a scope and sign off on a statement of work. Now success is defined as "delivering the scope by executing in accordance to the statement of work within the budget and timeframes agreed in the contract". The terms for success are narrowed down to the point that only one thing must go "wrong" and the whole thing tends to cascade into failure. Of course, there are always the change requests to bail any project out of any situation - and of course, that is just kicking the can further down the road.
Have you defined success?
Is executing the program against the statement of work and contract really defining success? Usually these contracts are very far removed from the actual benefits that are sought via the implementation project. The criteria for success start at the business case, where the project benefits are weighed against the costs. Each benefit should have a timeframe when they are expected to be realised. These benefits are the north star.
Trading costs and benefits
Everything is a trade-off between cost and benefit. Every overrun is going to affect the business case - but not necessarily in a 1:1 relationship. For example, one element is causing an overrun on the project. Often the actions are about getting the project back on track with schedule. Instead, ask this: "what is the actual benefit that this element brings, when is that benefit realised, and can it be realised in a different way?" The first part of the question validates that you really need this, if there is no benefit that can be quantified, move on. The second question determines when the benefit is due to the realised. If it is planned to be realised at the end of the program, you have room to manoeuvre. If it is planned to be realised upon the next release - then a choice is imminent: 1) - keep the benefit against extra cost, 2) - change the solution to a workaround, keeping some of the benefit, at lower cost (with the potential to revisit later), and 3) - move the benefit to later in the project, but move another benefit earlier in its place. Options 2 and 3 allow for an offset in benefits to partially pay for the extra cost in achieving the benefit.
Risk and Reward
Classic contracts have an isolated risk and reward model: Time and Material seems to focus all the risk on the company where the software is implemented, and the rewards at the implementation partner (contractually, you buy time and material, not an outcome). Vice versa - a fixed fee engagement, all the risk is quantified and calculated into the price. The more risk the project bears, the more risk reserve is calculated. As a customer, you know the costs, but at the same time, you are also locked in to the letter of the contract. Both options assume a zero-sum game - there is only a fixed amount of money associated with the program, and it will flow in one direction only.
An alternative take on implementation projects is that it is not a zero-sum game - money is generated because of this program in the form of realised benefits over the cost. The measurement of this is difficult (i.e. are the benefits truly realised? If not, is that cause attributable to the program?). It requires a firm trust between the partners in the implementation - the customer and the service provider - potentially independently "refereed". Let's assume that we crossed that hurdle - what would a risk and reward model look like? One such model could be tapering profit margins - when the number of hours exceeds the contract, the contracted rate against which the service provider declines to a certain level. Sounds good in theory - the service provider is incentivised to deliver on time to keep the profit margin high, and both the service provider and the customer feel the "pain" during an overrun - as the costs may be less, but still flowing out to the implementation. In practice, there are several issues with this model. Not in the last place while it shares the pain, it does not share the benefits. As service provider, it seems that there is no way to claw back to original profit model, and as implementing company, you are over budget - damage done.
Benefit-bound Commercial Model
Here is a thought experiment: imagine the project is not governed by a statement of work, but a statement of achievement. Each achievement is linked to a benefit. Each benefit is calculated, and a conservative benefit is agreed between customer and implementation partner. The cost of the project delivery itself is split between execution - a per hour per person rate that is heavily discounted from the standard commercial rate, and a benefit realisation rate that is a monthly payment based on a shared ratio of the pre-calculated benefits over a predetermined amount of time. Immediately, potential issues jump into mind on why this would be very difficult to realise - the challenge is to see if those issues can be overcome, and I believe with a good partnership between customer and implementation partner, any issue can be resolved upfront by a comprehensive (yet simple) framework, which also caters for new issues occurring during execution of contract; early exit, or buyout, clause; and triage and arbitration.
Disruption is necessary
Whatever the new commercial model may be, the disruption is inevitable. A benefit based contractual model will have the benefit of significantly increasing the common ground between customer and implementation partner. It also moves the emphasis away from scope to benefit realisation. From a customer point of view, the costs of the project are more aligned to the expected benefits. From the viewpoint of the implementation partner, it is possible to scale up cash-flow by realizing benefit ratio payments of one or more projects, whilst having the scarce resources available to execute new work. Both parties have a vested interest in minimizing cost and time, whilst maximizing realised benefit.
If you want to further explore such model, wither as customer or implementation partner, Aurelian Group provides a structured process to enable a benefit based commercial model.
Originally posted: 7 September 2017