Who was the late, great Billy Mays and why did he always seem to be yelling at us? You know, he was the guy who pitched products like Oxiclean on TV; where he extolled the virtues of the product with a booming voice that was at least several decibels above pain ... and urged you to act "right now" ... and if you did he would see to it personally that your order was doubled (of course there were those shipping and handling fees).
What got me thinking about Billy Mays was some recent research I'd done on software products that claim everything from "ITIL Compatibility" to "Ensuring IT Alignment with the Business" ... almost forgot "ITIL in a Box."
Before I go too far in this article, I think it would be best if I clearly stated my biases on the subject of software companies and products in the IT Service Management (ITSM) space. First, for quite some time, many software companies have jumped on the ITIL bandwagon, marketing their products as "ITIL compatible and verified." Because IT Service Management (ITSM) is a descriptive, not prescriptive, framework, the whole situation would have been laughable except for the fact that a significant number of IT shops bought these "compatible" and "verified" software products, thinking it would accelerate their ITIL adoption efforts.
It got worse when the IT shops discovered that the products came in a "few processes short," and they only learned after the fact that "compatible" really meant compatible in ITIL terms only and "verified" meant nothing as there was no standard to verify the product against.
I have both purchased and built ITSM-enabling software for the IT organizations I have run. Based on my 27 years experience working with IT and ITSM enabling software, following I present my 7 Steps to properly choosing a software vendor and package.
Today there is a whole new generation of software products that deliver the value IT practitioners are looking for. Many have been "purpose built" to "deliver the capabilities required to operate as a service provider integrated into the enterprise or mission value chain." Some of the larger software companies have banded together to establish a configuration management database (CMDB) standard that will enable various point solutions to be integrated into this evolving ITSM software "ecotechture." (See http://www.dmtfs.org/standards/cmdbf/ for more on the CMDB Federation Working Group.)
But, are they right for YOU? Here are seven time-tested, easy-to-follow steps when selecting enabling software technology.
While this seems blatantly obvious, I have lost count of the number of IT shops I have worked with over the years that started with a product search as opposed to a clearly defined need. This normally goes hand-in-hand with "doing ITIL" without understanding their current capability or a desired end-state of the ITSM processes in mind. A needs analysis is fundamental, and addresses the definition of the goals and objectives to be achieved as the result of acquiring new software. It is critical that any needs analysis should be conducted in parallel with an IT Service Management process maturity assessment.
Specifying requirements entails more than just writing down selected features from the vendors' marketing material. Your requirements are your requirements and should reflect what the product must do to enable the process that you either have or wish to have. Among the deliverables of your process design or redesign phase of a process implementation program should be a requirements definition.
Before you start looking for suppliers, your organization should determine its appetite for risk. Factors to consider include your current vendor, ability to integrate products from several vendors vs. a single-vendor product suite. No matter what the vendor or vendors tell you, "Some assembly is required." The scope of that assembly is where risks need to be assessed. The industry is trending toward the adoption of point solutions that are very good at what they do; but they do not do everything. If you can tolerate an appetite for risk associated with building a "best-of-breed" solution then those are the vendors you need to find.
Probably this should read, "Do your own research." In other words, the due diligence you put into this will directly impact the quality of your product decision. There is no substitute for hands-on research. That doesn't mean that you should preclude the use of analyst firms, as long as you understand where they make their money and how it might impact the inclusion (or exclusion) of various vendors or products. So, do some research on your own. You may find products or vendors that have not made it through the analyst maze (yet), but are worth a look.
I would prefer a test drive, but this is where you get into some level of detail in the actual evaluation of the product. If you didn't take someone's word that the product was "compatible" and "verified," and you have a good requirements list you can drill down to the necessary level of detail to determine the product's actual capability to meet YOUR REQUIREMENTS. While you'll be hard pressed to get a perfect match, at least you can avoid sitting in front of some of those pesky C-level folks explaining that it really depends on your definition of "compatible" and that "verify" is a verb and "capability" is a noun.
You should be able to clearly identify what works the way you want it to work, what can be "configured" to work the way you want it to work, and what you'll need to find another way to accomplish (yes, accomplish because you are selecting a product from a list of requirements, not a feature list).
By this time, you should be able to recommend a product, set of products or a suite of products and what it is going to take to make them work; now it is time to go on the hook. Your recommendation and how you arrived at it should be open and transparent to any stakeholder in the process. It should clearly document the process to this point and be able to withstand the scrutiny of any the interested parties.
Once you have made your recommendation, it is a good idea to seek out others using these products in a similar fashion (size, volume, etc). It is probably a good idea to reach out to these folks via a user's group or other non-vendor controlled association. It is one thing to see a demo, do a test drive and a detailed requirements evaluation. But it is another to have actually lived through implementation, configuration, integration and normal operations. This is also when you get the straight scoop on how things actually work.
If things still look good at this point, you have a lot of work in front of you getting it installed, tested and into production enabling your IT Service Management processes . . . but that is the topic for another DITY.
I really believe that all software products should have a warning label that says, "Caveat Emptor." It is up to you, not the software companies (or their paid "verifiers"), to do the work necessary to understand your needs, articulate your requirements, understand your appetite for risk, qualify prospective vendors, validate the product's capability to meet your requirements, and validate your selection/recommendation with others in the IT Service Management practitioner community.