In many ERP and CRM selection processes, it is hinted that cost is only a small part of the selection process, or at least, not the driving decision point. There may be some truth to that, given the effort that is put in to compare the solutions on the benefits, like functionality, ease of use, and overall future proofing of the roadmap. But in the end, cost - be it acquisition cost, implementation cost, or as most commonly considered, the "total cost of ownership" is a major deciding factor. Value is calculated and expressed over the cost factor (be very alarmed when in the sales cycle you are hinted to not look at the cost, but the value alone!). As value is a factor over cost, there are two viable ways to increase that value - 1. lower the cost, and 2. increase the difference between cost and return (value). The latter is what is the preferred sales method (cost is just not interesting), the former is not to be neglected. Expectations of value are usually overstated, where on cost remain understated.
The value trade off
No matter the construct of the program - there is a finite amount of money that can be allocated to the program. For that money, one has to balance speed (time to value), specification (functionality) and quality (ability and longevity to realise value). Each dollar falling in one pocket, is subsidised by one or both of the others (assuming no additional funding is found). The actual return on investment is in that sense a function of the investment itself. Sounds sensible, and when the experienced sales professional explains this, it sounds even reasonable. It sounds reasonable, because there is a truth in it, just not the whole truth.
Impact of cost on value
Cost itself remains a major driver of the value. the unfortunate situation is that we know the costs are stated in favourable terms - and most likely, the cost will increase due to unforeseen (or foreseen but omitted) additional requirements to spend. These are not expenditures that increase the perceived value, rather maintain the current expectations. Over the first three years, in a typical business application program, but far the biggest impact on cost is the implementation itself - typically between 2 to 3 times the license cost is spent on implementing the software. The more functionality and options the software offers, the more implementation effort is required to get it up and running, the more unforeseen additional costs will appear. The more complex the software, the more expensive it is to implement, maintain, and the higher the chances of errors (complex systems simply fail more often). Spend too little, and you cannot run your business at scale (i.e. try managing a larger business with only spreadsheets); spend too much, and the value returned decreases at accelerated rate.
Too much functionality
"You get what you pay for" - this usually holds true. But you also have to pay for what you've got - regardless of use or return on investment. This is often not taken into consideration. Total cost of ownership includes all things owned (or in modern terms, subscribed to), whether it is used or not. Completeness of functionality is lower on the decision hierarchy than suitability of functionality. For example - it is better to have something that covers 95% of the functionality, than something that is only used for 80%. It is better to have less functionality and add to it, than all functionality but needs to be modified.
To change, or not to change - costs are involved
Changing your business systems? You will have to ensure the adoption rate is within standards - low adoption is low realised return on value. The challenge with adoption is, that it can only peak at 100%, so realistically speaking, we are investing in change and adoption management services to minimise the value leakage. Various change management models are out there, such as Prosci's ADKAR model, but whatever model you choose - it should not be expected that everybody will accept the change voluntary. Awareness, Desire, Knowledge, Ability and Reinforcement are components of a very sensible adoption program. However, it should not be assumed that this is enough, there has to be a driver to change, and a consequence of not going along with the program. The best executed change and adoption programs have a strong consequence for those, despite all the efforts and investments, are not with the program.
The alternative is not to change, and therefore adoption is less of a problem. Assuming there are compelling reasons to change the system (out of support of legacy system, lack of scale, etc.), and it is opted to have minimal change in process with the new system. It is very expensive to make a new system behave like the one it replaces. It also immediately puts a low bar on the additional value to be realised (if you do the same things the same way, there is very little opportunity to unlock additional value) - therefore this is not a realistic option.
Selecting your solution and implementation partner
A great sales tactic is to shift focus from cost to value - and there is merit to that approach. However, cost should never be ignored. It does not mean "buying the cheapest on the block" - "you get what you pay for" does apply. You should expect and be willing to pay for:
· Experience - it takes a decade to accumulate a decade's worth of experience; it is not about tenure, it is about having had the opportunity already to make mistakes and learn from them. Hiring experience on the program will provide the eyes and ears to spot the pitfalls, and the knowledge on how to best overcome these, or minimise their consequence.
· Functionality - expect functionality to add to cost. Core functionality typically provides the highest return on investment, it is the differentiating functionality that adds that value compared to the competition. As long as this is differentiating value that your customers will notice.
· Support and maintenance from the solution provider and the vendor. Expect some component of the cost (license and/or maintenance fee) for the vendor and solution provider to be able to sustain this.
· Roadmap and continued development - whether you subscribe to software or buy the license outright - software needs to evolve to stay inline or ahead of expectation trends.
The cost of software and implementation covers a lot - but it is a fallacy that everything is costed in relation to return. Here are some elements to consider, that you should not be paying for:
· Everyone is expensive - experience is valuable, but you don't need everyone in the project to have equal experience. The project pyramid is essential (for more detail on the project pyramid, read "Rate Structures - Ignore the Pyramid at your Program's Peril").
· Pay for what you don't get - it is not a one to one relationship between the cost of goods or service, and the price. take away the margin, there are indirect costs to consider as well as the direct costs. It would be unreasonable to expect otherwise. However, one should stop to ask the question: is the rate a reasonable representation of costs and margin? If an organisation has a significant portion of the workforce not working on the product, or not working directly with customers, then they are working to create and maintain a complexity in the business (keep the business running). Especially dealing with large vendors or service providers, it pays to look at the ratio of direct and supporting staff- especially in larger and complex (matrix) organisations - for every person working directly with customers or with the development of the product, how many staff (directly employed or contingent) are supporting them as managers, HR, Marketing, Finance, etc.
· Pay for what you don't use - functionality is great, but for it to represent value, it needs to be implemented, adopted, and increase revenue, or decrease cost.
· Pay to maintain the current system in a newer and shinier version - "the new system will be everything we have now, plus...". This sounds great, but it sets an expectation that will rarely be met against project budget. With a new system, some functionality of the old system will be deprecated.
Cost and expectations
Cost of a program has a significant bearing on the expectation management. First to consider is the "confirmation bias" - the costlier a program, the more we expect it to come with all the bells and whistles. If these bell and whistles are not present, it is tempting to spend "that little bit more". After all: why would you not try to get the maximum out of such large investment?
Secondly, the law of diminishing returns applies. The higher the total cost of the program, the less opportunity for error before the value is significantly impacted. Costs of a program tend to go up, whereas value from the business case is unproven, and likely skewed upwards with the cost of the program. Following are guidelines to keep the cost in line with realistic value projections:
· Keep the system as simple as possible - simple integration versus complex orchestrations or manual processes
· Keep the implementation as simple as possible - iterative (fail fast and adapt), focus on Minimum Valuable Product, and Minimum Valuable Iteration.
· Keep the program pyramid in shape - the cost layer is where the average cost rate should be managed. If you compare two service providers for the same program, what is the ratio of difference between them (in extreme cases, I have seen a difference of 250% - you can fail twice with the cheapest provider, and still have half the budget of the most expensive provider in the bank!)
· Be (a)ware of confirmation bias - a high cost program will be driven into higher cost because of it.
Originally posted: 23 January 2018