In Part I of this series, we discussed why you should adopt an acquisition model that re-uses what you already have, buys what you can't re-use, and builds what you can't buy.

We briefly discussed that one of the reasons why you shouldn't just buy something by just looking at the price tag because of the total cost of ownership (TCO), but we didn't go in details.

This article explains why you should consider TCO when looking at buying a new software.

What is TCO?

The term TCO was originally coined in the late 1980s by Gartner research to describe the cost of owning and deploying personal computers.

Their findings showed that each PC costs an enterprise nearly $10,000 per year.

Originally, it caused quite a stir in the technology community and among CFOs who scrutinized their methodology and -- eventually -- accepted it as a standard way to evaluate total costs.

Simply put, TCO consists of the costs, direct and indirect, incurred throughout the life-cycle of an asset, including acquisition, deployment, operation, support and retirement.

Some sources say that the amount on the price tag represents less than 10 percent of the total cost spent on IT assets over its lifetime.

In other words, the price tag of software is like the visible part of an iceberg, while the hidden costs are just like the submerged parts.

Iceberg showing partially submerged portion
Total cost of ownership and icebergs have a lot in common

Like other tools, TCO does not solve all problems. For example, TCO does not assess risk or help align technology investments with your strategic goals. Nevertheless, TCO is an important tool for the analysis of IT costs and for the management of those costs in an IT organization.

Cost areas

When calculating your software's total cost of ownership, consider two areas:

  • Obvious costs
  • Hidden costs

Obvious costs

Those are the costs that everyone who was involved in planning and vendor selection is familiar with, such as:

  • Capital expenses:  License fees and/or subscription fees. If buying an on-prem solution, you may also need to purchase new hardware.
  • Operating expenses: Services, support & maintenance fees to keep the equipment running. Consider additional license costs each year (or the price increase at the end of each term is purchasing a subscription) and the number of years until a major upgrade.

Hidden costs

These are the costs people usually forget about when planning to purchase new software.

The hidden costs are less obvious cost that are easy to overlook, but they can be very large.

Large enough to matter.

When calculating your TCO, consider the following "hidden" costs:

  • Acquisition costs: the costs of identifying, selecting, ordering, receiving, inventorying, or paying for something. Will you have to go through an RFP process to purchase your software? Consider the cost of preparing the RFP.
  • Installation costs: Year one install & setup costs.
  • Upgrade, enhancement, or initial setup costs: Most software may require some initial set-up, even if you don’t intend to customize them or integrate with other systems.
  • Reconfiguration costs
  • Customization & Integration: Keep in mind that the more you customize your software, the more you will have to maintain and update when major upgrades occur.
  • Data migration: When deploying a new system, it's often necessary to migrate your data from your existing system. The cost of this migration depends on the amount and format of the data. You may first need to convert the data to another format, consolidate it with other sources, or “scrub” it for duplicate, obsolete, or otherwise bad entries. When moving to the cloud, you also need to consider that some SaaS providers may charge egress costs which are often proportional to the amount of data transferred.
  • Operating costs: for example, human (operator) labour.
  • Change management costs:  for example, costs of user orientation, user training, workflow/process change design and implementation. Training users is critical to get the most out of your new software. It may involve sending employees to training centers, bringing trainers on-site, participating in webinars, or creating custom courses and documentation. Keep in mind that you will also need to train new employees as they join your organization.
  • Infrastructure support costs:  for example, costs brought by the acquisition for heating/cooling, lighting,  or IT support.
  • Environmental impact costs: for example, costs of waste disposal/clean up, or pollution control, or the costs of environmental impact compliance reporting.
  • Security costs:
    • Physical security: If buying an on-prem solution, you may need to increase security measures in your building, including new locks, secure entry doors, closed-circuit television, and security guard services.
    • Information security: for example, security software applications or systems, offsite data backup, disaster recovery services, etc.
  • Financing costs: for example, loan interest and loan origination fees.
  • Disposal / Decommission costs: Some jurisdictions may require you to pay disposal fees. You may also need to shred or demagnetize your electronic storage media.

this is not a comprehensive list by any means. It is just a list of costs I've tallied up over the years. You may have to consider other areas specific to your own situation.

How does the saying go? "Your mileage may vary".


When purchasing new software, you have to consider more than just the price tag.

Thankfully, more and more software companies (and research companies) have created online TCO calculators to help you identify those hidden costs.

I've found a couple so far:

Did I miss any obvious costs? Did you find any TCO calculators out there? Let me know in the comments.

Photo Credit

Piggy Bank Image by 3D Animation Production Company from Pixabay

Iceberg Image created by: Ralph A. Clevenger
Credit:© Ralph A. Clevenger/CORBIS
Copyright:© Corbis. All Rights Reserved


A tale, inspired by a true story:

Once upon a time, there was an IT guy who had been tasked to buy a piece of software. He wasn't asked to do research or to investigate whether his company had the required infrastructure (or staff) to run the software. He was told to buy it and not to ask any questions.

The boss had already made up his mind. He wanted this software because the adverts in the magazine told him it would solve all his problems. He had already talked to the salespeople over a game of golf and a lavish dinner with copious amounts of alcohol.

The salespeople -- really nice and friendly folks -- had assured the boss that the software would not need any configuration or installation, and it wouldn't affect any of his systems or cause any downtime.

When the IT guy started asking questions about whether the software the boss wanted was the right choice, the boss pretty much told him that if he didn't want to take care of it, the boss would find someone who would. From what he had seen from the marketing videos on YouTube, the boss was pretty sure that even he could do it himself.

Eventually, the IT guy gave in and installed the software.

But not before discovering that the software required a whole bunch of new servers and needed to run on an operating system that no one in the IT department had any experience managing. So they hired a new IT guy that knows that particular operating system.

Meanwhile, the database administrators found out that the only database platform that was supported by this new software was not the database platform the company had standardized on. They bought more servers and hired a new DBA that was familiar with that database platform.

When it came time to customize the software to meet the company's needs, they found out that none of the application development team had the time or the skills required to do such customization. Luckily, one of the top contractors in that programming language happened to be available and could start immediately -- at a premium rate.

One day, as the exasperated IT guy was eating a sandwich and staring blankly at the lunchroom wall, the Webmaster guy -- who usually works on another floor, but was in the neighbourhood for a meeting -- walked in.

- "Whoa, you look like you have had a rough few months!" said the webmaster. It was meant as a joke, but it was also true.

The IT guy and the webmaster had known each other for a long time. They worked together when the IT department was just a handful of guys. Back then, the webmaster was just running the company's web site, but he had since started managing the company's intranet and portal.

- "Agh! I just found out that we're going to have to start a nightly export of our user data because the [expletives deleted] isn't compatible with our Active Directory. Of course!", was the IT guy's response. "And our first migration to the new system is going to take a lot longer than we expected and we'll need to ask the accounting department to stop working for two whole weeks while we migrate the system. And they're unhappy because it is the end of the fiscal quarter."

The webmaster asked cautiously: "And... what exactly does this new software do?"

The IT guy explained what the new software did.

- "Uh, you mean like what our current portal platform has available out of the box?" asked the webmaster. "That's what [redacted]'s team has been using for about two years now. The boss even sent an email congratulating the team for doing such a good job. I even demoed it to the boss!".

The rest of the tale isn't appropriate for this blog. But there was a lot of cursing and yelling. Let's just say that they lived miserably forever after, having to maintain that software that never truly worked the way it was intended.

Sadly, this kind of scenario happens more often than you'd think. You may have experienced this yourself where you work.

This post will explain some of the tips and tricks to use when buying new software that will help you make an educated decision.

Software acquisition model

I often hear people talk about "Buy vs Build" when discussing their software acquisition model.

In reality, you should always consider Re-use, Buy, and Build.

st=>start: Start
d1=>condition: Can I re-use?
d2=>condition: Can I buy?
e1=>end: Re-use
e2=>end: Buy
e3=>end: Build


Do you already own a piece of software that will meet your needs? It may be an unused part of something you already bought, or it may be an internal application that another department has already developed.

You should also consider open-source solutions as part of the re-use decision. Can you re-use open-source software that already exists out there, for free, to meet your needs?

Is there an add-on feature available for of the software you already own that would meet your needs? Even if it would cost you a little more to enable that feature?

If the answer is yes (or mostly yes), you should explore the possibility of re-using what's already available before buying.

Don't compromise, but don't miss what's already right in front of you either.

I recently went through this process with a client that uses Office 365 -- with SharePoint, Flow, and PowerApps at their disposal. They wanted to buy a piece of software because it called a third-party API and made it possible to trigger data workflows from the results of the API... which is something that they could already do with Flow.

They just didn't know that feature was available.

Before considering to buy a new piece of software, it is a good idea to take an inventory of what you already have.


If you can't re-use -- or doing so would deliver a less-than-optimal solution -- by all means buy something!

However, before you pull out your credit card, make sure to do a proper gap analysis. Compare what your existing software (if any) actually offers against what you really need it to do. Then use that same gap analysis criteria to compare with the software you want to purchase.

When considering buying, keep in mind the Total Cost of Ownership of that comes with every piece of software.

Don't know what Total Cost of Ownership means? Check this blog for an upcoming post on the subject.

After considering your gap analysis and total cost of ownership, if you can't find software that meets your needs (within the budget you've been given), consider building something.

Whatever you do, resist the urge to skip the buying option and go straight to building.


Don't listen to developers (like me) who'll tell you "Oh, that'll take me a couple of weeks to build". Because it never does.

This may sound weird coming from someone who considers himself a developer at heart, but it is true.

They're not lying to you on purpose to protect their jobs. And it isn't a reflection of their skills. They really do mean well.

But most organizations suck at building software projects.

Don't take my word for it: The Standish Group is an organization that publishes a yearly Chaos Report. The report describes the state of the software development industry and seeks to identify the scope of software project failures, the major factors that cause software projects to fail, and the key ingredients that can reduce project failure. I highly recommend that you buy your own copy -- it is worth it. And I am not affiliated with The Standish Group in any way.

Last time I bought the report, a staggering 31.1% of software projects will be cancelled before they ever get completed. 52.7% of projects will cost 189% of their original estimates.

Back in 1995, the Standish Group estimated that American companies and government agencies spent $81 billion for cancelled software projects. They paid an additional $59 billion for software projects that were being completed but exceeded their original time estimates.

The average number of software projects that are completed on-time and on-budget is only 16.2% -- a number that goes a low as 9% in larger companies.

And once completed, those "successful" projects will only deliver approximately %42 of the originally-proposed features and functions.

It doesn't need to be an all-or-nothing situation

Nowadays, software is so much more open and versatile than it was many years ago. Yet, we still deal with software acquisitions as a giant monolith that cannot integrate with anything.

The ideal solution for your needs may very well be a hybrid solution: using the software you already own (re-use), adding a component or an app that meets most of your needs (buy), and making minor customizations to meet your exact needs.

Although this post isn't about Office 365, I often see organizations running Office 365, SharePoint Online and Dynamics 365, but they fail to fully recognize the capabilities available at their disposal.

Take a look at the various Office add-ins and Dynamics 365 AppSource for solutions that you can buy that will handle most of your needs. And, with Flow and PowerApps, you can easily configure your solutions to do exactly what you want. There are countless connectors available that may allow you to build a low-code or no-code solution that can adapt as your company's needs evolve.

The same applies to other products -- not just Office 365. Understand what you have so that you can fully leverage it before you look at buying or building something new.


Impulse buying is something that may be suitable for a pack of gum while you're waiting to pack at the grocery store, but it should never be an option when it comes to enterprise applications.

Make an educated decision, and follow an acquisition model that will help you find the ideal solution for your organization's needs.

I hope this helps?


Image Credit

Image by Arek Socha from Pixabay