The BCP Software Sales Pitch
Sun, 09/12/2010 - 8:00pm
Having recently survived the grueling process of identifying, evaluating, and selecting a BCP software tool, I thought this would be a good time to reveal some of the unique marketing techniques that I discovered during the process.
BCP software has been around for more than 20 years in one form or another, and the days of limited choice have given way to today’s myriad products. But a major problem with the greater selection is that determining if a particular BCP software package will be the right fit for your organization has become difficult at best. Clever marketing techniques can mask the shortcomings of a software package, costing your organization money, time and value. These techniques, coupled with a lack of third-party evaluators or true public forums for advice, make it very difficult to get to the heart of what is real and what isn’t.
But there’s good news. By arming yourself with information and making yourself aware of the kinds of marketing techniques to watch out for, you can go into any search with open eyes. Check out these common software vendor marketing techniques:
Charge Per User
It’s no surprise that effective business continuity planning involves many people in the development, testing and emergency use of a plan. It’s those same people that need access to the software to conduct that planning and where marketing technique #1 – charging per user – comes into play.
Business users need to provide input on how they operate and how they will keep the business up and running during an outage. Information Technology (IT) supports this business and is responsible for restoring each essential part of the IT infrastructure during an outage. Crisis management personnel run the recovery effort and handle essential personnel and facility-related issues. So each person in the planning and exe-
cution effort needs to be involved to build effective plans and to be able to use them in an event.
Some software providers charge to license each of these users. In a medium-sized company, this could involve dozens of people – and as company sizes increase, even more people will be involved. To control costs, the people in charge of the planning efforts may decide to limit user licenses and perform actions by proxy or sending out surveys to gather complicated BCP information, instead of using functionality already built into the software. Under the charge-per-user system, continuity plan development can quickly become more cumbersome as a single person ends up performing functions that other people could easily do in order to save on seat charges.
Other vendors restrict activities like reporting or certain system functions to specific (administrator) licensed users. The challenge here is that distribution of plans becomes a manual process: An administrator must print/send files to each user without a license. During an outage, people are limited to static plan information as they will only have access to the most recently distributed plan.
If your goals include building a scalable plan and minimizing administrative burdens, consider carefully before selecting a charge-per-user model. Too many licenses and you’re wasting precious dollars, but with too few licenses you could find yourself scrambling to get additional licenses in the midst of a disaster.
We all know it’s not just the tip of the iceberg you need to be aware of, and marketing technique #2 – iceberg pricing – can catch you unawares if you’re not careful.
With this pricing model there is usually a low-cost offer on basic functionality, then more extensive charges are assessed for what might be essential components for your organization. In a corollary technique known as “modularization” the vendor separates essential items required for BCP (like business impact analysis or incident management) into separate pieces of software, frequently called modules. You pay for each module you choose to add on. It’s also possible that modularization can compromise the functionality of the software – more on that later.
Another part of the below-water price is configuration and customization, also known as consulting. How much configuration/customization is required before this becomes a software that you can use for your BCP efforts? With some tools, it can require hundreds or even thousands of hours. It’s almost a given that some customization will be required to make any software package meet the individual requirements of the company, but in the worst case the pay-for-customization model can become very bad news for your budget. And if you do manage to avoid the customization fees, you may still find that you burn precious cycles and money doing it yourself or using internal resources.
Modularization is a fancy word for splitting up something into parts and then selling them separately. As mentioned above, modularization and iceberg pricing can go hand in hand. And if handled incorrectly, modularization could leave you paying more for your final package. With this pricing model, you end up in a bit of a conundrum: Do you leave out what may be key functions in order to control costs, or do you risk paying for modules that you may end up using only occasionally (think activation)?
And in addition to a potentially bigger price tag, integration and customer support amongst all of the parts can become obstacles of their own. By separating the modules, you can end up with your data residing in multiple databases – not an ideal situation when you need your modules to work seamlessly together. Sometimes this separation is managed using integration via dashboards and links – but that isn’t even close to true integration. If data are stored in multiple databases, they will need to be exchanged between the applications with pristine integrity or you run the risk of having inconsistent information (or much larger problems). “Seamless integration,” then, is actually quite elusive with modularization and is often a much greater feat than simply having everything reside in the same database. And don’t forget, this data exchange is your responsibility, so you’ll likely end up paying for the vendor to do this for you as part of a customization package, putting the cost right back into your budget.
As an aside, a particular caveat with modularization is that some vendors use another company’s code or software product and brand it as their own. Rarely is this code/product integrated effectively. In this situation, support becomes a real issue because you can get caught in-between the party that supports the code and the other party supporting the information exchange within the product. So proceed with caution and ask lots of questions when considering a modular product.
The Pre-Staged Reference
It’s pretty typical for vendors (of any product) to have a pre-vetted list of references who will provide a so-called “unbiased” review of a particular product. For a clearer and less biased view, look to consultants or analysts who are not affiliated with any particular company and have experience with different software packages. Also, take some time to look at who is posting and what is being posted on all of those user boards, while keeping in mind that not everything is as it seems on the Internet. That glowing review could have been written by a sales rep, or that scathing diatribe could have been penned by the company’s competition. Better to reach out to your own bona-fide contacts at companies that have recently bought software, or are currently in the buying cycle, and get their input on what they’ve learned.
Another thing to remember is that vendor events, meals, tickets, golf outings, etc. are all techniques used to enhance the vendors’ sales position. You need to be especially cautious of these techniques to be sure that they do not violate your company policy or blind you to what the software can truly do for you.
Bring Out the Big Logos
We’ve all seen the big splash pages on vendor websites showing who has purchased (notice I didn’t say implemented) the software. Vendors want to provide big logos to prospective buyers to show how great their product is. But when making a decision, it should be less about who uses the product and more about making sure that it will work for you. And keep in mind, some vendors have essentially “purchased” these logos by offering their software for free to a small part of that big-name company you’re wowed by. You don’t want to make your decision based on what you think is a huge functioning installation at Company X, only to learn too late that just a handful of people at Company X are actually using said software.
Another name-dropping trick to watch out for is the use of perpetual licenses from past sales to large companies. Some vendors who sold these perpetual licenses still count those companies as active clients, even though the vendor’s software now sits on a shelf at those big fish.
And speaking of big fish, the big fish in a small pond truism is very relevant in the BCP software industry. Consider well that if your company is not a big fish, you might not be as much of a priority to the vendor after the sale as you expect.
One of the best business books on software, The Innovator’s Dilemma, provides case studies on how software companies who are dominated by large clients can compromise services to their other clients. When the large customer consumes the resources of the software company, you’re stuck with the leftovers to address your concerns and issues. And that’s something you certainly can’t afford when you’re in the thick of a crisis.
The Big, Beautiful Plan
For years, BC professionals have been touting the big plans we’ve generated using our software tools. The problem is, we’re the only ones patting ourselves on the back because resilience has never been directly correlated to a document. Further, compliance has moved past just having the right documents to actually demonstrating true preparedness using detailed analyses and exercises.
If the software is built on a document-based system, the best possible outcome is…a document. Some BCP vendors haven’t evolved and continue to base their products in a document generation mindset, which is unfortunate because closed-source vendor platforms and inflexible code bases have pigeon-holed these products.
Challenge your prospective vendors when they say they’re not focused on generating documents. Review the typical output of the software closely. Take a minute to imagine trying to use a big document during a disaster – rifling through endless pages trying to find the bit of information you actually need in seconds. It just doesn’t work. When it comes to keeping your business moving, you need a leaflet, not a phone book. CI