Category Archives: Software Buying Guide

If a Deal Is Too Good To Be True, IT IS!

This is just as true in technology and services as it is in products. If you get four bids for a new technology platform and / or (integrated) services package and three are plus or minus 20% and one is 1/3 of the price, I guarantee that lowball bid is too good to be true. And if you did your homework, you’d instantly know it and disqualify it.

You buy a product or service because it’s cheaper to buy than to build or perform it in house. However, that product or service still has a cost to the vendor, in terms of manpower and resources — costs the vendor has to meet in order to deliver you a quality product or service. If the vendor doesn’t cover these costs, and make a fair profit, one of two things is going to happen — the vendor is going to go out of business trying to serve you at an unsustainable level or the vendor is going to deliver a significantly inferior product or service to stay afloat.

I’m reminding you of this because a number of companies have not only been looking for new solutions now that we’re into a slow recovery, but because a number of companies, desperate to reduce costs, have been rebidding everything under the organizational umbrella, including the supply management platform(s) and service contracts. And in doing so, many of them have been getting unbelievably low bids from a handful of vendors who are desperate to win (new) market share — and the companies are seriously considering these bids. These bids are unbelievable for a reason — they’re not real. They’re up front costs, and as soon as you sign on the dotted line, you’re going to be hit with “change fees”, “service costs”, “upgrade fees”, etc. if you want the same level of service being offered by the competition, who are all in the same ballpark at sustainable bids. Or, even worse, the vendor is just going to give you the platform or an initial spending report, and then disappear until renewal time because the cost only covers platform support, not project or customer support. Or, and this is the worst situation of all, the vendor is trying to build a new business (in a new vertical) and thinks it can use you as a marquis customer to attract new customers, who it will overcharge to make up for the loss on you. If it works, you’re in luck, but the vast majority of the time what happens is that either the vendor fails to deliver, because they didn’t understand the true success requirements or they didn’t understand how much it would cost and how long it would take to make you a success, and then shuts down the business. If you’re lucky, they just shut down the vertical and you get to keep using the platform until you can find a new vendor. If you’re, not, the whole vendor goes tits up and you’re left holding the empty bag.

The worst part is that every month, if not every week, I hear of yet another company who signs on the dotted line with one of these vendors offering “unbelievable” deals that “can’t be matched” — and, even worse, the company is one that should know better (because there are success stories that illustrate it understands many of the precepts of good supply management). Especially when it’s so easy-peasy to determine if a bid is reasonable or not.

It’s easy to determine a reasonable range for a (bundled) technology platform (and /) or service. All you have to do is build a should cost model. Let’s say you’re buying a SaaS e-Procurement platform and want regular project management support, best-practice training, and custom integration to your in-house technology platform. Then you know the vendor will have, at least, the following costs:

  • Platform Delivery & Maintenance
  • Account & Project Management Personnel
  • Development Personnel

If the SaaS license will require 1/50th of their data centre resources, then the base overhead to support you will be 1/50th of their data centre and support team costs. If you require about 20 hours a week of account and project management support and training, then you will require half of a senior resource who has expertise in your industry and categories. If the custom integration is expected to take two man years, than you will need the equivalent of two developers on the vendor’s staff dedicated to you.

Now, if the average cost to maintain a small data centre, or rent part of a data centre, that will support 50 similar-sized enterprise clients is 3M, then you can quickly estimate that it will cost the vendor 60K (+- 10K for a margin of error) just to have you on the books, before it lifts a finger. If the senior resource required to support you on your projects is a 120K to 150K resource, then it will cost the vendor 60K to 75K to dedicate this resource to you half of the time. And if the average developer with the necessary skills is going for 70K to 90K, that’s another 140K to 180K that the vendor needs to outlay to support you. Then, there’s the vendor’s cost of sale, which, depending on commissions structures and expenses, is probably in the 15% to 25% range, and the need for the vendor to make a fair profit, say 10% to 15%, to keep investors happy. If you add it all up, you get:

Cost $ Range
Platform Delivery & Maintenance 050K to 070K
Account & Project Management Personnel 060K to 075K
Development Personnel 140K to 180K
Subtotal 250K to 325K
Cost of Sale 040K to 070K
Profit 025K to 050K
Total 315K to 445K

This tells you that any bids you get in and around the 315K to 445K range are reasonable, that if you get any bids that are more than 600K, the vendor either doesn’t understand what you want or is trying to rip you off (up front), and that if you get any bids less than 250K, either the vendor is planning to not support you to the level you need to be supported, the vendor is planning to make it up later with “change fees” and “service fees” when you’re locked in to a long term contract and held captive, or the vendor is looking to make a poster child out of you and take unfair advantage of the relationship (and then leave you holding the empty bag if things go south).

Regardless of why the vendor gave you the unbelievable bid, one thing is clear. If you accept it, you will get screwed.

An Enterprise Software Buying Guide, Part VIII: Contract Definition & Management

In this, our final post in this intial series on the successful acquisition of enterprise software, including e-Sourcing, e-Procurement, and other Supply Chain Software Solutions, we discuss the contract review and performance management steps.

7. Comb the Contract

The legal minds behind traditional software vendor contracts excel at including all kinds of seemingly benign terms and conditions that can turn out to be big cost gotchas if you’re not careful. My personal favorite is the mandatory maintenance clause that states if you stop paying maintenance, you lose the right to run the software. Sure you still own the perpetual license you paid big bucks for up front, but you’re not allowed to use it unless you pay maintenance, which usually has you paying the entire cost of the software every 4 to 5 years.

Other good examples of “gotchas” that you need to watch out for include:

  • The mandatory upgrade on the vendor’s schedule
    The vendor will usually try to insert a clause along the lines of “you must upgrade within 90-365 days or lose support” if you’re not careful, regardless of how long they say they will support an older version.
  • The free lunch
    There’s no free lunch. Someone always pays … and in enterprise software, that someone is YOU! Either the “free” training, support, or modules are included in the price or being offered as an incentive to lock you in for a long term that will ultimately increase the vendor’s margin and salesperson’s commission.
  • The toothless SLA
    The majority of SLAs are designed for one purpose — and one purpose only — to give you a false sense of security that causes you to overlook the fact that the wording was carefully designed by the vendor’s legal counsel to insure that the vendor gets to keep your money for the length of the contract, no matter what.
  • The Escrow
    You get the code if the vendor goes belly-up. Whoopee. Unless you have a large team of expert software developers in house that can quickly familiarize themselves with an application that contains (tens of) millions of lines of code and get you up and running again quickly, escrow is pointless. What matters is that you have guaranteed complete data access 24x7x365 and that the vendor is required to give you 30 days warning and a complete data export in a standard, product neutral, format before a material change in operations or ownership, so that you can shunt your data into another system and keep on truckin’ if, for some reason, the system stops working for you.

8. Manage Performance

You can do everything right up to the time you sign the contract and still have everything go to hell in a handbasket (and your costs go through the roof) if you don’t carefully manage vendor delivery and support throughout the contract lifetime.

It’s critical to create a project management team who will mange the implementation, monitor uptake, collect feedback, quickly identify issues, and work with the vendor to get those issues resolved in a timely manner. Otherwise, you might not get the uptake, utilization, productivity improvements, and savings you expected to get.

That’s it for this initial series on how to successfully buy enterprise software. I hope you found it useful. And remember, if you’re planning on acquiring RFX & e-Auction,
Spend Analysis,
Optimization,
Contract Management,
e-Procurement,
Supplier Networks & Catalogue Management,
GPOs & Marketplaces,
Market Intelligence,
Strategic Sourcing Services,
Trade Data Management,
Supply Chain Optimization, or
e-Payment platforms, a good starting list (that you can customize to your needs based on the outputs of Step 2) can be found in the X-emplification series. Have fun!

An Enterprise Software Buying Guide, Part VII: Negotiations

In our last two posts, we discussed the creation of cost models that would allow you to approximate, at least to a well-defined order of magnitude, the total lifetime cost of ownership of the software solutions under consideration, which can then be refined during negotiations to understand the true cost of each proposal put forth by avendor. Today we discuss the process for formulating your objective and negotiations.

5. Define Your Objective

Your objective is defined as a price-performance goal based upon your identified needs, your cost models, your budget, and your ROI expectations. Your objective will be to obtain the solution required to meet all of your key functional requirements, along with as many of your nice-to-have but non-critical functional requirements as possible, at a specific price-point with as much support beyond a minimum level as you can negotiate.

You’ll go into each vendor negotiation with an identified solution blueprint, a support requirement, and a maximum price that you’re willing to pay and be prepared to walk away (and move on to the next solution) at any time if it looks like your minimum objective is not obtainable. This keeps you focussed on your goal and prevents you from getting lost on a vendor led joyride through the backwoods byways which ultimately lead to gator infested swamps.

6. Negotiate Professionally

Traditionally, enterprise software has a lot of margin and even more empty calories. This means that there is usually a significant opportunity to reduce the price through a serious negotiation.

If the purchase is over a million, it’s critical to have someone from procurement lead the negotiation, backed up by the cross-functional team, and if the purchase is over two million, you should strongly consider bringing in a professional deal architect. A skilled negotiator in the enterprise software market can undercut the range every time and save you as much as 40% off of “best-price” on multi-year deals that include significant maintenance and support requirements.

After all, professional enterprise software negotiators are used to the vendor tricks and rhetoric like we have never accepted that price point or legal clause that the vendor sales representatives are trained to deliver at the start of every negotiation. They know when thy vendor is using the “partner” ploy. They know when a vendor is trying to blind you to their failings by pointing out their competitor’s failings. They know that a market quadrant or wave ranking is pointless if the solution doesn’t do what you need it to do at the price point you need it at to get ROI. In fact, they know all the standard stupid salesperson tricks and how to combat them to get you the best deal.

And they’ll be watching out for the Big Lie, which happens when a vendor says “yes, we have that capability” even though they don’t, and don’t plan to, and then price the missing capability ridiculously high in hopes you’ll decide you don’t really need that capability and buy their product anyway.

Tomorrow, in our final post in this initial series on enterprise software buying, we will discuss the importance of carefully reviewing any contract put before you, some common “gotchas” that vendors will try to hide in the fine print, and the secret to long term solution success.

An Enterprise Software Buying Guide, Part VI: Cost Model Calculations

In our last post, we talked about how you defined lifetime total cost of ownership models and what the key cost components of each major software delivery model were, reviewed below. In today’s post, we discuss how you will usually calculate each of the cost components.

On-Premise Hosted ASP (True) SaaS
  • License Cost (Up Front)
  • Maintenance & Support (Annual)
  • Dedicated Server Costs
  • Supporting Software Costs, usually Database and Application Server at a minimum
  • Implementation & Customization Costs
  • Integration Costs
  • Training Costs (Up-Front)
  • Internal Support Costs
  • Major Software Upgrade Costs, usually every 2-3 years
  • Hardware Upgrade Costs, approximately every 3 years
  • (Re)Training Costs (on Upgrade)
  • Annualized License and Maintenance Cost
  • Annualize Hosting Cost that consolidates hardware, bandwidth, and support costs
  • Major Software Upgrade Costs, usually every 2-3 years
  • Implementation & Customization Costs
  • Integration Costs
  • Training Costs (Up-Front)
  • (Re)Training Costs (on Upgrade)
  • Annualized License, Hosting, and Maintenance Cost
  • Implementation & Customization Costs
  • Integration Costs
  • Training Costs (Up-Front)

Based on these model requirements, you can build a spreadsheet that allows you to calculate and capture each cost component using all of the information available to you. These spreadsheets can then be modified during negotiations to capture the true total cost of ownership over the projected lifetime to understand the true cost of each proposal put before you, or your expert negotiator. Each of the costs above can be calculated as follows:

  • License Cost
    The license cost will either be a fixed price or an annual fee. In the first case, it’s a simple input, and in the second case, it’s the annual license fee times the number of years you intend to use the solution. (It’s a good practice to also calculate the costs for a range of years in multiple columns. If you think you’ll use the application for 10 years, calculate values for at least an 8 year and a 12 year ownership term as well to understand how costs change over time.)
  • Maintenance and Support Cost
    This is usually a percentage of the license cost each year. As such, it’s easily modeled as a percentage of the license cost multiplied by the number of years you intend to use the solution.
  • Dedicated Server Costs
    You’ll likely have to add servers to support your new acquisition. The cost will be the number of new servers required times the expected server cost. (Note that tough times will get you great deals on hardware using a reverse auction.)
  • Supporting Software Costs
    Many enterprise applications require database licenses and application server licenses (and some will require middleware licenses as well). These applications generally have license fees, maintenance fees, and per CPU and/or per seat fees. If you are lucky enough to already be licensing the supporting software, the cost will just be the costs to support the new application, calculated either as the number of new CPUs times the per CPU cost or the number of new seats times annual seat cost. If not, you’ll have to add in the license costs and the annual maintenance costs of the supporting applications as well.
  • Implementation & Customization Costs
    In the world of enterprise software, there really is no such thing as “it works out of the box”. At the very least you have to load your data. Usually, you’ll have to bring in a hired gun to install it, customize it, and get it working efficiently on your systems. If you’re lucky, this will be a reasonable fixed fee. If not, it will be a by-the-hour fee (and you’ll need to ask current/past customers to get an idea of the number of person-hours that will be required.)
  • Integration Costs
    If you need your new system to talk to, or work seamlessly with, other systems, you’ll likely have to do some integration. You’ll probably have to consult with a third party integrator to get an idea of project size, which will determine what will likely be a day rate based quote.
  • Training Costs
    Although it’s getting better, most enterprise software is still a long way from “Web 2.0” and your staff will generally need to be (extensively) trained to take full advantage of the system. This will usually be a fixed rate per course or student.
  • Internal Support Costs
    Even if the vendor installs and configures the software and includes “support” as part of maintenance, the support will generally be limited to bug fixes. You’ll still need internal IT resources to manage the instances, manage the servers, and support your users (and the required operating environments). The annual cost will be the estimated number of annual resources required times their average annual salary.
  • Software Upgrade Costs
    Depending on the vendor, every 2 to 4 years they’ll release a major new version of their (on-premise/ASP) solution and discontinue support for an older version around the same time. This means that, every 2 to 4 years, you’ll have to upgrade, for a hefty fee, or risk losing support. This cost can be estimated by looking at the vendors historical major release cycle and average upgrade cost as a percentage of previous system price.
  • Hardware Upgrade Costs
    Every 3 years, your hardware will need to be replaced. Even though the cost per performance unit continually decreases, you’ll need a more powerful machine at upgrade time as your users will be using the system more heavily, the software upgrades will demand more computing power, and you’ll need to support your (hopefully) growing business. A safe bet is to expect the upgrade costs will be roughly equal to the initial hardware costs.

In our next post, we will tackle negotations and how you should go about defining your ultimate objective.

An Enterprise Software Buying Guide, Part V: Cost Model Definition

In our last post on the buying of enterprise software, we discussed the process by which you could identify potential solutions capable of meeting your needs. In today’s post, we talk about how you identify the components required in your cost models, define the appropriate lifetime calculations, and why these cost models are critical to good solution identification.

4. Build Your Cost Models

Those of you who know software know that there’s the up-front price and then the true back-end cost that materializes after you sign on the dotted line, and that the back-end costs can often outweigh the up-front pricing by an order of magnitude, especially if you are going to be tied to the system for a number of years. Thus, before you enter into negotiations for any piece of software, it’s important to understand the range that your total lifetime ownership costs are likely to fall in, how this range compares to other solutions, and whether the ROI is likely to be there. If the annualized total cost of ownership is in the millions and you only have a quarter million per year in the budget, if the median cost is three times as much as the median cost of other solutions being considered, or if the ROI is negative, then you immediately know that a solution isn’t appropriate and can narrow your search, evaluation, and negotiations to other potential solutions.

While the total cost of lifetime ownership will depend on the delivery model of the software being delivered, the pricing structure used by the vendor, the skills of your internal IT support department, the price concessions you get in negotiations, and a host of other factors, it is possible to build a reasonably accurate model based on the delivery model of the software, the supporting platform requirements, and benchmark costs (which can then be refined during negotiations with the shortlisted vendors).

Furthermore, there’s no fast and simple rule as to when a certain type of application will be cheaper. Some people will argue that SaaS is always more expensive in the long run, on the faulty premise that rental models are always more expensive than up-front buys, and some will argue that SaaS is always cheaper on the faulty premise that SaaS does not require back-end hardware costs or internal support personnel, which can cost hundreds of thousands of dollars a year. The fact of the matter is that each buying scenario is different. It strongly depends on the solutions being considered, current market pricing, whether or not the space has recently seen any disruptive entrants, and how long you are likely to keep the application. If the trend is to replace the application you are buying every 5 years, and the rental model only becomes more expensive in year 15, the on-premise advocates don’t have a leg to stand on. If the solution you are buying does not require much in the way of compute power (as all it does is suck data in, aggregate it, and spit out some basic reports), your racks are only running at 50% capacity, and it’s a product your new network admins are already familiar with, it might not require that much in the way of support, knocking the legs out from under the SaaS evangelists. You’ll never know which solution is truly cheaper until you build the model, get the facts, do the math, and then negotiate for the best deal you can get.

On-Premise applications will generally entail at least the following costs:

  • License Cost (Up Front)
  • Maintenance & Support (Annual)
  • Dedicated Server Costs
  • Supporting Software Costs, usually Database and Application Server at a minimum
  • Implementation & Customization Costs
  • Integration Costs
  • Training Costs (Up-Front)
  • Internal Support Costs
  • Major Software Upgrade Costs, usually every 2-3 years
  • Hardware Upgrade Costs, approximately every 3 years
  • (Re)Training Costs (on Upgrade)

Hosted ASP applications will generally entail at least the following costs:

  • Annualized License and Maintenance Cost
  • Annualize Hosting Cost that consolidates hardware, bandwidth, and support costs
  • Major Software Upgrade Costs, usually every 2-3 years
  • Implementation & Customization Costs
  • Integration Costs
  • Training Costs (Up-Front)
  • (Re)Training Costs (on Upgrade)

True multi-tenant SaaS Applications, that don’t require a dedicated instance and the costs that go along with the classic ASP model, will generally entail at least the following costs:

  • Annualized License, Hosting, and Maintenance Cost
  • Implementation & Customization Costs
  • Integration Costs
  • Training Costs (Up-Front)

In our next post, we will discuss the calculation of each of these primary cost elements.