Friday, 18 July 2014

Product or Promise? (Spend Control Demystified - Part 6)

Continuing on from "How Does a Mouse Eat an Elephant" in the Spend Control Demystified blog series, here is another mistake to avoid.  

The most remarkable aspect of investigating Spend Control Solutions is that every supplier says “YES!” to everything, all of the time.
Just count the number of “NOs” you get in the RFP/ITT selection process. Treat it as a challenge!
How can this be true?
To satisfy the very diverse requirements of large corporate bodies, Spend Control has been developed using the most advanced rapid application development tools that enable the vendor to build anything you want, just for you, within a technology framework.
So everything is possible, but there is a price to pay. You will be unique, your training will be unique, and your solution will be unique. Which roughly translated, means that it is expensive to deliver and expensive to change.
Any suggestion that a significant cost is associated with the ‘scoping’ of your business needs after you have placed an order, can be translated into:
“We know roughly what you want, enough to quote, but we can’t afford to find out exactly what you want, until you are prepared to pay for it.”
If scoping is required post sale, you are in the world of ‘design and build’.
In which case, you had better know exactly what it is you want before you start, because that is exactly what you’re going to get.
Mistake #4: To misunderstand the difference between a product-based cloud solution (where a significant proportion of what you need has already been produced) and is available as a Commercially Off-the-Shelf (COTS) offering. Any ‘design and build’ promise is heavily dependent on your ability to specify your requirements. This, of course, assumes you know the scale and size of the task in detail.
TIP: Common sense rules
If a package solution is selected (in most cases this should be the decision) try to understand that the cost of acquisition and ownership is much lower than building it from scratch or from a technology half-and-half solution. This may mean that small areas of functionality are not available. You either have to adjust your requirements or better still work in collaboration with the package vendor to accommodate the most important ones. Set expectations for all day-to-day/casual users lower than reality and that way people will be delighted with the eventual result.

Copyright © 2014 PROACTIS Group