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:
Ever wondered why selecting enterprise software is so difficult? Use the Software Selection Maturity Scale to evaluate the state of your organization’s selection process, and as a roadmap for improvements.
Buying business-critical enterprise software entails significant risks for an organization. The goal of an evaluation and selection project is to purchase software that maximizes the ROI and minimizes the risks, but the sheer number of requirements make this difficult to achieve. For example, a comprehensive ERP selection for a larger company can approach 10,000 requirements. Also, there is the risk described by the Dunning-Kruger effect where IT professionals overestimate their software selection abilities and underestimate the project effort.
Gathering requirements is simple: just ask the users what they want. However, experience shows this fails dismally. In this article, we look at why gathering requirements is so hard, and what can be done about it.
When purchasing enterprise software, most project failures can be traced back to faulty requirements. As we often say, requirements are to software selection as foundations are to a building. Get them wrong and there always will be problems.
Why is it so difficult to gather requirements when selecting enterprise software, and what can be done to improve the situation? Why doesn’t asking users provide all the requirements? This article attempts to answer those questions.
Use software rationalization to prevent the cost of maintaining existing applications from stifling strategic software initiatives.
From a high-level perspective IT budgets have two parts: maintenance and strategic initiatives. Maintenance tends to grow at the expense of strategic initiatives and, left unchecked, ultimately stifles innovation. In mid to large IT organizations, this has resulted in the emergence of Application Portfolio Management or APM. APM is a disciplined approach to aligning enterprise applications to maximize business value while minimizing lifecycle ownership costs.
A lack of APM results in uncontrolled application growth, which is sometimes called application sprawl. See Appendix 1 for typical causes of application sprawl and Appendix 2 for the resulting problems. Note that APM is a continuous process and not an objective. The essentials of APM are:
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.
When purchasing enterprise software, detailed requirements must be developed at the start of the project or during implementation. By examining uses for requirements, we make the case that front-loading requirements development reduces risks and improves project success rates.
An adequate requirements analysis is the foundation for a successful enterprise software implementation. However, it can take hundreds or even thousands of hours to develop requirements for large software projects. Is it worth spending that time on the requirements analysis up front?
Surprising as it may seem, there are at least nine different ways to use a thorough requirements analysis when purchasing enterprise software. This article makes the case for properly developing requirements up front. It considers the different ways requirements can be used to reduce software selection risks and accelerate implementations leading to successful software deployments.
The traditional RFP process fails to deliver consistent results when purchasing off-the-shelf or cloud enterprise software. This article examines problems with the RFP process specific to selecting software and suggests appropriate resolutions.
Why does the traditional RFP process return such poor results when selecting off-the-shelf or cloud software?
A primary purpose of software RFPs is to discover how well potential products meet requirements at an acceptable price. Vendors respond to the RFP with their proposal. The organization selects the “best” proposal and makes the purchase. However, problems frequently appear after starting the software implementation, leading to missed deadlines, increasing costs and occasionally outright failures.
Sadly, the traditional software RFP process is broken. In fact, when it comes to purchasing off-the-shelf or cloud enterprise software, this process never worked properly in the first place. It is the reason stories about software failures regularly appear in the technical press. These stories are only the tip of the iceberg; people don't talk about most partial or outright failures because they don't want to be associated with them.
Buying enterprise software can be a risky proposition. Having an idea of the risks faced when selecting such software helps organizations to develop mitigation strategies.
Organizations always seek a return on enterprise software investments. All too often, that planned ROI doesn’t materialize because the best-fit software is not selected. This article examines the more common software selection risks, along with suggestions to alleviate those risks.
1) Unknown requirements
Unknown requirements are those that the software buyer doesn’t know they need. They usually surface as problems during software implementation, where workarounds can cause delays and cost overruns.