Major software purchases can cause significant pain to the organization, employees and, of course, the project sponsors. We look at why this happens, and how to avoid that pain in the first place.
Cloud or off-the-shelf: major software purchases like ERP seldom deliver all that is hoped. The first signs of trouble are when the implementation does not proceed as planned. When the software finally goes into production, the results are distinctly underwhelming. While outright failures happen, partial failures are much more common. These projects suffer from many or all of the pains below:
How CIO Ryan Fay uses the techniques of active listening and empowered developers to resolve issues before they affect the business.
Traditionally the role of the CIO has been to keep the data center humming, but increasingly CIOs are becoming active members of the C-suite and involved in business decisions. In a previous article, I describe how Abe Leitz, CIO at Curves Jenny Craig, transitioned IT from an order taking role into a consultative role. For this article, I interviewed Ryan Fay, Global CIO at ACI Specialty Benefits, to learn how he uncovers and solves business problems before the business units even know they have a problem.
ACI Specialty Benefits is a global provider of employee assistance programs (EAP), corporate concierge and multiple work-life services. They partner with clients to improve employee engagement and productivity with benefit programs that improve morale, productivity, and ROI. ACI looks at what they can do to ensure clients’ employees know and understand all of the benefits their employer provides, and design systems to help accomplish that.
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.
While many companies regret building enterprise software because it is much more expensive than expected, there are times when custom software is best. This article describes how to answer the build vs. buy question.
Recently I was talking to somebody at Oracle who recounted the case of a potential CRM customer that got away. Oracle had beaten out Salesforce, Microsoft, etc., and was poised to close the sale. Then the customer decided not to purchase, but rather to continue developing their homegrown CRM system.
This customer was faced with the build vs. buy question and decided to build. Always a difficult question to answer, it is too easy to make the wrong choice. There are two responses to this question:
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.
What is meant by a successful enterprise software project, and why is that success sometimes so difficult to achieve?
It doesn’t make any difference whether enterprise software is purchased or developed; project success can be elusive. So, what do we mean by “success”? Most people would say there are three parts to success, namely completing the project on time, with in budget and that the stakeholders / users must be satisfied.
I would argue that while these are important, they do not in and of themselves define a successful software project. The ultimate definition of success is whether the software meets the ROI that was used to justify the project in the first place. Of course, this means the ROI must be defined up front before the project starts. That is often not done, which means the project is at risk right from the get go.
The lack of stakeholder involvement can doom new enterprise software. Learn how to increase end user and executive sponsor buy-in, which helps drive projects to successful conclusions.
Conventional wisdom is that stakeholders must be involved when selecting enterprise software. But who are the stakeholders and why must they be involved? How can you maximize that involvement? Note that this is not a technical issue, but a people issue that directly affects the outcome of a software acquisition project.
Who are the stakeholders?
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: