"Vanilla Fudge"
Some years ago a prospect announced that they were going to implement a certain package ‘vanilla — straight out of the box’.
Why this was surprising to me was that the next week the vendor of this package stated in a presentation to my organization that his product did have a 'vanilla' version, 'you have to configure it to your needs’.
The prospect started with high hopes but the project failed.
The Argument for 'Vanilla'
The system software industry has made ‘vanilla’ the preferred flavour. They use two primary arguments in its favour
- our software is an easy and quick way to get to ‘best practice’
- this approach avoids the technical risks (and costs) of a detailed ‘customisation’ of the software.
Let’s review these two arguments.
“Best practice”
What vendors are saying is that their software incorporates ‘better practice’ than your current processes. This is probably true because your processes are unlikely to be formally designed or managed, and are probably constrained by the existing systems.
So, adopting the way the software works will improve your operations.
BUT, you will often lose some of the operational aspects that make you different and will realize less of the improvement opportunity than if you decided to make the software work for you. (More on this later.)
“Customisation”
The threat of customisation is significant. “You’ll not be able to upgrade, your new systems will become obsolete very quickly,…” True in some cases, but this is a false alternative. The real alternative is ‘system configuration’ which does not have any of these downsides.
If you point out that the configuration option has been omitted, a series of arguments is used to promote 'vanilla'.
Don't Know What's Possible
The first argument used for 'vanilla' can be, “You’ll reinforce current practice because your staff don’t know what’s possible.” But the question is not, “What is possible?” but “How do you want to do business, compete and make money in the future?”
When you’re buying a car you don’t want or need to know “What’s possible in a car?” as you cannot afford many of the answers and others will be irrelevant to your driving needs. You want to know “What are my needs of a car? — EG I need space for two adults and three teenagers, camping or sports gear, fuel economy of at least….” Then you want to see cars that will fill your needs. All other cars, regardless of their attributes, are irrelevant.
One of the greatest dangers with software is looking to see what features and functions it has — “lolly shopping” we call it. “Oh look, this has a reversing camera, fog lights, alloy wheels, special baby restraints, ….” The issue is not what features the software has or what can do, but what you need! If you lolly shop your systems costs will sky-rocket.
Don't Know How to Specify Your Requirements
The second version of the 'take vanilla' argument is “But your staff don’t know how to specify their requirements.” This is largely true because the systems-implementation industry has lost the art of defining business requirements. Left to their own devices, incumbent staff will often re-specify what they have today with some improvements. This is obviously now what is wanted and is a waste of time and money.
The real answer is to take your staff through a process of defining how you want to do business, compete and make money two to three years out.
This specification of your detailed requirements requires a rigorous approach to business process understanding and redesign but it is not difficult to learn and apply.
Specifying Your Requirements Will Take Time
The third version of the 'take vanilla' argument is, “But defining your requirements will take twelve months or so.” Nonsense! The most comprehensive approach will take less than 100 days.
Increases the Technical Risks
Finally they use the 'killer argument', “But this will significantly increase the technical risks of the project!” Whoa, ‘technical risks’? We, the business who don’t understand these technical risks, cannot have that.
Does defining your own requirements and then configuring the software to meet these requirements increase the technical implementation risks? Yes. The software of today is so complex that it cannot automatically ensure that all of your configurations are compatible and will work. So the technical risk does go up, and so does the time to implement and the importance of thorough testing (which is not that hard if you’ve specified your requirements correctly).
But wait. This technical risk is a one-time risk. Once the system has been configured, tested and installed, the technical risk has been addressed.
Increasing the Ongoing Business Risks
The alternative is an increase in your ongoing business risks. If you adapt your business to fit the software you have to change how you work to fit how the software works and you (usually) have to forego and lose capabilities you have had for years because this ‘best practice’ software does not support it, and so on.
This increased business risk is an ongoing risk and performance loss to your business. It can damage your competitiveness, responsiveness and profitability.
So What’s a (Wo)Man to Do?
Firstly, get real. “Vanilla” is not a real option. Even supposed ‘vanilla’ implementations spend weeks and months on configuration. Then, the team finds ‘mandatory’ changes to meet either regulatory or some other need and these require customisation. Progressively, the ‘vanilla’ implementation becomes more complex, higher risk, takes longer and is more costly. Sound familiar? You then find you’ve ended up with either a customised system (which you wanted to avoid) and one that does not fit your needs—which you also want to avoid.
In Conclusion
We find that, for the same or less cost, the same company can have specified its own unique future needs, configured the system to fit these needs, evaluated any ‘required’ customisations on the basis of the business value and risks involved, and delivered itself a competitive weapon.
Secondly, remember that ‘vanilla’ is a flavour, not something that is neutral. So if you’re going to make changes by configuring the system and considering customisations, do you want to be in control of the process or reacting to the vendor’s and ad hoc staff ideas and demands?
