If the new year brings thoughts of a major software purchase, help is at hand! Just published: Rethinking Enterprise Software Selection: Stop buying square pegs for round holes is written to help you make your purchase an outstanding success.
Buying enterprise software is a minefield of immature selection processes, conflicting interests, and predatory vendors. Over 90% of purchases fail to meet expectations, and close to 30% are outright disasters. This failure rate is astounding when you consider that the total cost of ownership over the software's operational life is a significant fraction of annual revenue.
A major software acquisition is an opportunity to "kick it up a notch" but, despite the best of intentions, few deliver. Far too many organizations squander the opportunity and remain mired in mediocracy.
It doesn't have to be that way!
Many companies think they know how to purchase software when in reality they have no idea of how little they know about the process! This article looks at the four places where money is squandered.
Companies tolerate the growing pains of inadequate software for years, but once they have made a decision to replace that software, they can rush headlong into disaster. Enterprise software is a substantial investment for any organization, especially when you consider the total cost of ownership over the lifetime of the software. Part of the problem is caused by inadequate attention to the return on the investment in that software.
Software itself has no intrinsic value. Rather the value comes in the form of the value of the benefits that flow from using that software. To illustrate the point, suppose an insurance company spends $1 million per year on labor to process a particular type of claim. If the company introduces new software that reduces labor costs by 20% annually, then the value of that benefit is worth $200k per year to the company.
Cubic Corporation invested in an ERP system to streamline operations and improve profitability. More than two years later software and implementation costs are over $61 million and climbing. Is this another ERP boondoggle?
Based in Southern California, Cubic Corporation is a public company that operates in the defense and transport industries. In February 2015 the CEO announced steps to streamline operations and improve profitability, which was expected to yield about $16 million annualized pre-tax savings in the financial year 2016. This would be about $160 million savings over 10 years.
The ERP project was started in late 2014 and was expected to be completed by the end of 2015. But as of mid-2017, the implementation was still going strong. Based on published financials, as of March, 2017 Cubic had spent $61 million on the project so far. With completion currently estimated to be in 2018 (assume Q2) and extrapolating implementation costs, Cubic will have spent a total of about $86 million on their new ERP software project by the time it goes live.
Enterprise software implementations usually take substantially longer and cost more than planned. When going live they often cause major business disruption. Here's a look at the root cause of the problem, with suggestions for resolving it.
Whether it is in the cloud or the data center, so often enterprise software takes much longer to implement than expected. There are three main reasons for this.
1. Unknown requirements
New requirements are discovered during implementation that should have been found during the analysis. When these new requirements are found, the organization must decide what to do with them. If they are weighted as important or higher, the consultants must determine how to implement them: by configuration, writing code, business process re-engineering, or adding new modules or third party products. All of this takes time, and when too many new requirements are found implementation schedules slip.
Given the rapid rate of innovation in the software field, the costs of obsolete systems are usually much higher than most people realize. The only way to know for sure is to estimate that cost.
Some things in life are inevitable: death, taxes, and obsolete software. For extreme examples of obsolete software see this article by Kenneth Corbin: U.S. CIO aims to cut legacy spending, proposes IT modernization. While technologies fall out of favor, companies change, their markets grow, they are familiar with their software and may hang onto it long past its prime. Though there are many reasons not to change enterprise software, possibly the biggest is inertia. If it isn’t broken, why fix it?
The cost of not replacing old software must be estimated to answer the above question, especially for systems that have been in place for more than ten years. This cost is often much higher than expected and is incurred every year. Start the process by estimating the common costs of obsolete software listed below:
When it comes to enterprise software, value is far more important than price.
The corporate procurement process traditionally focuses on achieving the best purchase price. While this may be the right approach when buying commodity items, when it comes to buying enterprise software it is completely wrong. A far better approach is to focus on the value provided by the software rather than its price.
To paraphrase Benjamin Franklin “The bitterness of poor functional fit remains long after the sweetness of a low price is forgotten.” If you pay too much for software, all you lose is a little money. If you buy on price, you risk losing everything, because software that does not adequately meet requirements will eventually be replaced.
The TCO is a vital part of the ROI calculation for enterprise software, yet too often it is ignored or underestimated. See what should be in the TCO estimate, and use that to make better software selection decisions based on the ROI.
The Total Cost of Ownership (TCO) for enterprise software is the sum of all direct and indirect costs incurred by that software, and is a critical part of the ROI calculation. However, it is often ignored or woefully underestimated. In this article, we look at the lifetime costs incurred by the three main types of enterprise software, namely:
Ultimately, enterprise software is bought to deliver value, and that value flows from how well the software meets requirements. To maximize returns on software investments you need to complete a value analysis before making the purchase.
Buying enterprise software is not like buying a car or a house where there is pride of ownership. Nobody buys software for the sheer joy of owning it. Rather it is bought for the value of the benefits that flow from using it.
Market leading software is often seen as delivering this value, but without a detailed value analysis, there is no way to know this before making the purchase. Too often, software is bought only to find that it does not deliver the expected value because it is not a good match for the particular requirements. However, once the purchase has been made it is too late to do anything about it. Invariably organizations buying software because it is the market leader tend to be near the bottom of the Software Selection Maturity Scale.
Selecting best-fit enterprise software is a difficult task, and you can’t please all the people all the time. This article outlines a data driven and auditable process to pick the software that maximizes ROI and minimizes buyer’s remorse.
Over the last few months, articles in this column have focused on detailed aspects of evaluating and selecting enterprise software. This article draws many of those ideas together in a high-level overview of the software evaluation and selection process and includes links to the more detailed articles.
The primary goal of an evaluation and selection project is to identify the software that best meets the needs of the organization. By definition, this has the greatest ROI. Also, the evaluation should provide the information necessary to drive down risks in the software implementation phase of the project.
The opportunity for new enterprise software doesn’t happen too often, and yet it presents a real chance for an organization to make significant improvements. With so much at stake, how do you find the cloud or off-the-shelf software most closely aligned with your particular needs? This article answers that question.
Is your evaluation spreadsheet tying you up in knots? See why spreadsheets don’t deliver when evaluating enterprise software.
Enterprise software evaluations often start out as spreadsheets but soon run into problems. Why does this happen? For the same reason that accounting systems don’t run on spreadsheets: spreadsheets are too manual. They don’t scale up to handle the many hundreds or thousands of requirements found in a typical enterprise software evaluation.
The scaling problem is familiar to people in growing companies. Systems that originally worked well begin to fail as they are scaled up. Likewise, spreadsheets that worked well when starting an evaluation struggle as the number of requirements grows.
Evaluating enterprise software is a lot of work. Managing this work in a spreadsheet seems the obvious choice, but that is deceptive. What many people don’t realize is that at the enterprise level, they will end up building a complete evaluation system in a spreadsheet, which is always far more work than expected. In this article, we look at the limitations of using spreadsheets to evaluate enterprise software and conclude with suggestions.
Don’t gamble when prioritizing enterprise software projects. See why you should prioritize by ROI, and how to do it using the risk-adjusted value method.
Erik Nelson, an accomplished IT professional, once said in the course of a conversation with me that when it comes to prioritizing IT projects there are really only two things to consider: 1) Should a project be done at all? and 2) In what order will selected projects be done? Nothing else matters. Erik offered very sage advice because all complicated prioritizing schemes eventually reduce to this.
When managing a portfolio of enterprise software projects, you can use the ROI to eliminate those projects with a poor return. They are the ones that should not be done. For the projects that should be done, prioritize them by ROI for maximum value to the organization.
It’s all too easy to skip vendor due diligence when buying enterprise software. This is an important part of the evaluation and selection process that can help avoid starting a business relationship with a vendor that just will not work in the long term.
When making an enterprise software purchase, even a relatively small one, you want a long-term relationship with a software vendor. You really want them to be a reliable and productive part of your team. When considering a long-term relationship, what signs might suggest there are storm clouds on the horizon?
It is too easy for organizations to be caught up in the excitement of a new purchase and not perform due diligence on the vendor. This can be a big mistake, especially when buying business critical software from smaller enterprise vendors. Due diligence is investigating vendors before the purchase so comments like this are not made: “If I had known that about this vendor, we would not have bought their product!”
While organizations use committees to select business-critical software, real world experience shows this doesn’t work as expected. Here's a look at why committees struggle with software decisions and what path leads to more successful enterprise software projects.
Enterprise software is always purchased to solve business problems. For example, vendors no longer support the current software, new functionality is wanted, new compliance regulations must be met and so on. In all cases, business needs drive the decision to move forward with acquiring new software. Unfortunately, as the horror stories that so regularly appear in the technical press attest, buying enterprise software is inherently risky.
Finding the best-fit software for the organization’s particular needs and budget will minimize that risk and deliver the greatest ROI. The question that arises is this: What process should be used to identify that best-fit software?
If you fail to do the work upfront to select the best-fit enterprise software, you will pay the price.
A successful enterprise software deployment can be defined as one that meets or exceeds planned ROI. A previous article examined the ROI benefits that accrue from selecting best-fit enterprise software. This article considers the flip side of the coin, namely the costs incurred when an organization purchases software that is not best-fit for their particular needs, i.e. they purchase the wrong software. Under these circumstances, one of the following things happens: