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:
Based on your software budget, here's how to estimate the resources needed to ensure you select the best-fit enterprise software for your particular needs.
With more than half of all IT projects still failing, this article by Sharon Florentine suggests the odds are not in your favor when making a major software purchase. Software evaluation and selection projects are an enormous amount of work for any organization because there are so many factors to consider. It can take months from the start of the project to making the selection and purchasing the software. Is it worth doing all this work up front, either internally or by hiring outside consultants?
A thorough requirements analysis takes time and money, but helps an organization to truly understand what they need and want. That understanding is a critical part of the ultimate success of the new software.
In the cloud or in the data center, few organizations realize just how critical the step of developing requirements is to the ultimate success of a major software purchase. At the start of a software selection process, most people have only a very high-level idea of their needs. It is the act of looking at potential products and seeing what they do that helps them flesh out those needs in greater detail.
When developing software requirements it can be helpful to use existing products for inspiration. It is also useful to have several tools that can be used to manage those requirements.
When considering new enterprise software, it is usually a good idea to start with an evaluation even if the outcome is a decision to build the software yourself. See my previous article: Why most enterprise software projects should start with an evaluation. This article considers using features from existing products to inspire the writing of requirements for either buying or building software. We conclude by mentioning several tools to manage those requirements.
Anybody involved with purchasing enterprise software will do a lot of business writing. See how using text-to-speech can dramatically improve that writing.
Although this has nothing to do with enterprise software per se, almost everybody in business does lots of writing, and proofreading that writing is always a pain. I know this pain first hand after once being hauled over the coals in a performance evaluation for the errors and typos in my emails. Let me share a technique that I have found to be very effective for both proofreading and improving writing.
While grammar-checking tools are a huge help when it comes to catching writing mistakes, many authors still struggle with proofreading, especially with things like emails and blog articles. One technique is to leave the writing for a few days and then proofread it, but that only goes so far. Unfortunately, you still miss too much because you read what you think you wrote, not what you actually did write.
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.
Requirements wish lists can paralyze a major software purchase. This article considers ideas for dealing with the problem.
When an organization recognizes they have outgrown their software or that it has become obsolete, they may decide it is time to replace it. When these projects start, there is only a fuzzy picture of the general needs. The purpose of the requirements discovery process is to bring those needs into sharp focus where they can be expressed as specific requirements. In particular, the discovery process must uncover requirements the organization does not know they need. Significant requirements missed during discovery can cause sub-optimum software to be selected. Even if best-fit software was purchased, too many “new” requirements uncovered during implementation can cause project delays and unexpected costs.
Much has been written about combating rogue IT. Peter Kraatz from Datalink offers the perspective of a cloud service provider.
With the migration to the cloud in full swing, rogue IT can be a problem for companies when employees bypass corporate IT and sign up for cloud services. To get his take on the problem and solutions, I spoke with Peter Kraatz, national practice director of cloud service management at Datalink.
Peter opened the conversation by commenting that if IT does not change the way they engage the business, rogue IT will only get worse. Part of the problem is that IT does not understand the business.
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.