All enterprise software eventually becomes obsolete. Here's how to decide exactly when enterprise software should be replaced.
Recently a client asked if they should keep their existing ERP software or consider replacing it. Like many companies, they had purchased various software products over the years to tackle different problems in their environment. These purchases inevitably resulted in creating silos where it is hard to keep duplicated information synchronized. Old software meant new hires had no experience in that technology (think green screen terminals) and needed extensive training. Also, reporting was simply so much work that the business didn’t get the information they wanted when they needed it. The client’s question was this: Do they add something like a business intelligence layer over the top of the existing systems, or is it time to consider upgrading to a modern ERP?
We look at four places where requirement descriptions are used, and consider how writing better description details can help make a major software purchase more successful..
When developing requirements for a major software purchase, two questions that come up are 1) How much detail should the requirements list contain? and 2) How much detail should there be in each requirement description? Where a previous article examined the different parts of a requirement, this article focuses on how to write better requirement descriptions. For an idea of how detailed requirement descriptions themselves should be, we must first examine why description detail is important and where it is used. Then we can look at how to write good requirement descriptions.
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?