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.

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.

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.