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!
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.
See how poor requirements analysis puts enterprise software purchases at risk of partial to outright failure...and how to fix the problem.
There are multiple reasons why major software purchases fail, but one of the most common is that of an inadequate requirements analysis. The problem is caused by people being unfamiliar with requirements gathering techniques, and by grossly underestimating the amount of work involved.
Requirements are to software selection as foundations are to a building. Get them wrong or leave things out and there always will be problems. This article examines the consequences of missing requirements in the analysis phase and describes how to avoid the problem in the first place.
I loathe the banality of “the devil is in the detail”, but you can’t discount its wisdom when it comes to IT agreements. Let me tell you a true story about what happened during a software deal as a result of a divestiture. The original agreement provided for a divestiture re-assignment to another party with the vendor’s written permission, which permission would not be unreasonably withheld. I’m facing the vendor’s vice-president of sales and with a straight face he states; I’m allowing the assignment, I’m giving written permission but I never said there wouldn’t be a transfer fee and proceeded to demand a $900,000 fee.
The pain of a major software purchase going wrong can lead to wishing the project had never been started. However, by then contracts are signed and it is too late to do anything about it. Read and be warned!
In some ways selecting enterprise software is like painting a house - the key to success lies in the preparation. Rather than doing the work demanded by a mature software selection process, some organizations take shortcuts and create unnecessary pain for themselves. By the time they realize just how much pain they are in for, contracts are signed and it is too late to do anything about it. This article lists many of the pains caused by partial or outright software failures to help justify the effort of doing the up-front software selection work.
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.
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:
What can successful CIOs share about delivering technology value to the organization? Read how CIO and VP of service operations Abe Lietz at Curves Jenny Craig transformed IT’s relationship with the business, and how he keeps ahead of technology.
From the context of enterprise applications, how do CIOs achieve success? I asked Abe Lietz, CIO and VP, Service Operations at Curves Jenny Craig about his challenges and successes, particularly from the perspective of IT delivering value to the business. This article shares his insights.
Key to providing technology guidance to the business is transitioning from an order taking role to a business advisory role. In the order taking role, the business decides how to solve a problem, and asks IT to help implement that solution. In the advisory role, IT moves upstream in the problem-solving process. The business first asks for advice about how to solve the problem, and a solution is jointly developed. It’s moving from “Yeah, you're the expert, but I'll bring you in when I have a problem to solve.” to “Hey, before we go and do something new, let’s tee up the problem together and then we can find a solution.”
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.
With marketing taking a growing slice of the IT budget and the rise of shadow IT, some people are asking if IT is still needed. See how to harness the power of vision to increase the relevance of IT to the C-suite.
For many organizations or departments, a vision or mission statement is de rigueur. The problem is that this statement isn't used to drive decision-making. Properly understood and used, a vision or mission can bring a laser-like focus to a business, department or even an individual and help achieve new heights and relevance. In this article, vision and mission are treated as synonyms. Other synonyms include aim, purpose, and direction.
A vision statement answers the question “What is the direction?” The fundamental concept of a vision or mission is that it can never be achieved, except in a trivial sense. The statement exists to guide and align the setting of goals, objectives etc., all of which can be achieved.
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.