Like sales & marketing, software acquisition has a funnel. See how to use this funnel to reduce the pains so prevalent with major software purchases.
In science, everything that is observed to happen must have a cause. Although the root cause of most problems with major software purchases can be traced to inadequate requirements, what is the cause of that problem? Why do so many organizations have inadequate requirements? The answer is that few know how to evaluate and select enterprise software. While it looks deceptively easy, in practice it is anything but.
Anybody who has worked with sales & marketing would be familiar with the sales funnel, which describes the steps needed to sell a product or service. The software acquisition funnel is similar but views the process from the perspective of the buyer rather than the seller. Note that in the diagram below the volume of each of the four buying phases corresponds to the amount of work in that phase, and shows that most of the work in a successful software selection is in the requirements analysis. This article looks at each part of the funnel.
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.
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.