When purchasing enterprise software, some organizations wait for the implementation phase to flesh out fully detailed requirements. See the advantages of moving this work to the requirements gathering phase of the project.
To some degree, purchasing enterprise software is a journey into the unknown. When projects start, organizations have only a very general idea of what they want and the problems the new software should solve. As the project continues through evaluation, selection and implementation, organizations learn more about their needs.
Like any journey, if you don’t know where you are going, how will you know when you get there? How will you bypass expensive detours like scope creep along the way? How will you avoid a project that does not deliver close to the promised ROI, or even an outright failure?
Aggressive salespeople and “over-optimistic” RFPs can doom enterprise software projects. Audit RFPs to verify they meet requirements as claimed before purchasing the software, and avoid software disasters.
When buying enterprise software, organizations usually rely on vendors responding to RFPs (or RFIs or RFQs). However, as real world experience shows, responses to RFPs do not always reflect software reality. In all cases of RFP inaccuracies, the buyer pays the price in more ways than one. Why does this happen and what can you do about it? The first reason is that salespeople always interpret unclear requirements in a way most favorable to their product. This is entirely reasonable.The second reason is that some salespeople are simply too "optimistic" or aggressive when responding to RFPs.
Enterprise software RFPs with open questions requiring short essay answers are difficult to evaluate. See how RFP scoring takes the gambling out of selecting best-fit software.
Most enterprise software RFPs (or RFIs or RFQs) contain hundreds or thousands of requirements. When vendors respond to these RFPs, how do you deal with so many requirements? How do you take the gamble out of selecting software? The CIO of one large organization told us that he sometimes reads RFP responses at bedtime. There has to be a better way. There is, and that is to use an RFP scoring system.
The purpose of the scoring system is to identify the best-fit software product for the particular organizational needs. This means evaluating products against the requirements, and distilling their ratings down into one number. We call this number the fit score and use it to rank products, and ultimately make the selection. Although this may seem like a gross simplification, ultimately only one product will be purchased. More complex scoring systems only get in the way of that final decision.
While weighting requirements for importance is critical to selecting best-fit enterprise software, other benefits that flow from the exercise are reduced implementation costs and improved end user buy-in.
Too often, RFPs (or RFIs, or RFQs) are just lists of requirements with little thought of how important those requirements are. In the absence of importance ratings, all requirements must be treated equally. This is never accurate because some requirements are always more important than others. Here's a look at why it is worth rating requirements for importance, and how to do it.
Rating requirements for importance means capturing who wants them, why they want them and how important they are. In doing this, the organization is exploring, discovering, and documenting their needs. Rating requirements should be done by the process owners and subject matter experts, and not by those who capture the requirements in the first place. While most organizations looking at a particular type of enterprise software have very similar requirements, it is the relative importance of those requirements that makes each organization unique.
Meet or exceed target ROI when buying enterprise software by selecting the best-fit product for your particular needs.
If you picked stocks based on what friends tell you or from miscellaneous articles read on the internet, you would be gambling because you hadn’t done your homework. Over the long run, this kind of investment strategy would almost certainly lose money. On the other hand, if you researched multiple companies and picked stocks that closely matched your strategy and risk tolerance, you would be investing in a portfolio capable of realizing your needs.
No organization buys enterprise software for the sake of owning it. The software is bought to realize the benefits that flow from using that product. The software that has the most valuable benefits generates the greatest return on the money invested in it (i.e. it has the greatest ROI).
By definition, the best-fit software is the product that maximizes the benefits and delivers the highest possible return compared to other potential products. No software product is perfect, and all involve some degree of compromise. Thus best-fit does not mean perfect; it means the best of the available potential products.
Use well-written software requirements to accelerate enterprise evaluations and reduce selection project risks.
Buying a car is much simpler than building one. Likewise, requirements for buying software are much simpler than those for building software. But don’t let that fool you. Poorly written requirements can be a problem in any software selection project. Consequences include missed deadlines, not selecting best-fit software, unrealized ROI, and occasionally outright failure. Writing good requirements accelerates software selection projects and reduces risks.
A while ago we were working with a client team and came across an incomprehensible requirement. The author of the requirement was in the meeting and was asked to explain. He answered: “I have no idea of what I meant with that requirement!” This type of situation is all too common. Why does it happen, and how can you avoid it? The answer is that requirements have meaning in a context. When writing the requirement, the context was assumed. Over time, context changes or is forgotten, and the meaning of the requirement dissipates.
Use the powerful reverse engineering technique to build a comprehensive requirements list for enterprise software evaluations.
We like to say that requirements are to enterprise software selection as foundations are to a building. Mostly out of sight, but very necessary. Get them wrong and there will be problems. Every time. When the software disasters that so regularly appear in the industry press are examined, almost without exception inadequate requirements were a significant contributor to the problem. Bear in mind that those cases appearing in the press are only the tip of the iceberg. Most cases, especially the smaller ones or the partial failures where expectations were not met are never reported.
A thorough enterprise software evaluation is more difficult and more work than most people realize. Surprisingly, few organizations have a robust evaluation methodology. When evaluation projects run into difficulty or run out of time, shortcuts are taken and it is all downhill from there.
The BIO annual conference is an annual life science event that rotates through several cities around the US.
This year BIO was held from June 24th to 26th in San Diego, southern California, the week right after the DIA conference. Wayferry had a prime booth on the exhibition floor where verybody had to walk past us.
The Wayferry team: Chris, Bridgette, Lisa and Kristy
The DIA (Drug Information Association) is an annual life science conference is an event rotated through several cities around the US every year.
This year the DIA was held from June 16th to 18th in San Diego, southern California. In addition to the subject matter presentations, it is an opportunity for life science software vendors to exhibit their products. Since any company making a major software purchase is also potentially a Wayferry client, we had a booth.
The Wayferry team: Chris, Bridgette, Kristi and Liz.
Wayferry was a sponsor to the 2014 Top Tech Exec Awards in San Diego.
While the 9 wild fires around the county knocked attendance, the folk who did make it really seemed to enjoy themselves. The sushi was very good! We had several conversations with people who see a clear need for Wayferry's services.
Bridgette, Wayferry Sales & Marketing, at our sponsor table.