America’s Favorite Flavor

Almost every system implementation I’ve worked on has started with the goal of a “vanilla” implementation, otherwise known as an implementation without any customizations. And, you might ask, how many of these projects have achieved that goal?

Zero.

A vanilla implementation is possible in theory, but it rarely comes to fruition in the real world, and including that goal, or even requirement, in a Request for Proposal (RFP) can set you up for trouble. Experienced, reputable consultants know that, while it is quite common for clients to want a vanilla implementation, it is highly unlikely that will be the actual outcome, so they build contingency into their estimates so that they don’t have to bombard you with change requests later.

Unfortunately, you might also get a response from a consultant who will estimate EXACTLY what you put in your RFP. Since they aren’t including any hours for customizations, their bid will be lower than those who do. If your selection process includes ranking, as many do, and one factor in ranking is the amount of the bid, you could end up selecting a vendor that appears to cost less on the front end, but will likely end up being much more expensive in the long run. Remember that part of what you are paying for in a consulting partner is their experience and expertise, so be open to them telling you what you actually need, and not just what you’ve asked for in an RFP.

So why do vanilla implementations prove to be so unattainable? There are far more reasons than I could go into in a single blog post, but a lot of it comes down to change enablement. Your business processes exist for a reason, and every change to process to make it fit an off-the-shelf technology means an increase in the total burden of change to your employees. In some cases, the cost of the customization can be less than just the increased training costs to prepare people for that change. And, for those of you who are in the public sector or highly-regulated private sector, the change in business process might not be possible, or it could require such a lengthy approval process by a state or federal agency that it isn’t even worth the attempt.

It’s important to remember that technology exists to enable your business, and not the other way around. The ideal project would undertake a detailed business process improvement effort first, and then select technology based on those optimized processes. Unfortunately, in the real world, many companies delay process improvement, thinking they’ll bundle it in with the system replacement or upgrade. Then, the technology timeline takes over and process improvement is deemed too time-consuming and, next thing you know, you’ve customized the new system to match your old processes.

While going vanilla reduces your technology costs for future upgrades, you have to look at the total cost of the change. Include a change enablement expert in your initial analysis and RFP development to help make sure you’re looking at the full picture and what makes sense for your business as a whole.