I believe that all ITSM enabling software solutions should carry a warning label that says, “Caveat Emptor.” It is up to you, not the software company or some "paid verifier” to understand your needs and validate your decision...
That is how I started this DITY over two years ago. This spring the OGC announced a new certification scheme for “ITIL Compliant Software.” APMG, the ITIL Accreditor is administering the scheme and has already certified two software products. The industry buzz was mostly negative and in some cases scathing. Since I wrote this article, the ITIL remains a descriptive framework, and it still takes a Clintonesque approach to defining words to apply “compliant” to anything associated with ITIL’s guidance. And as long as “it depends” is the most common answer provided to students and clients when asking about how something in ITIL is implemented, I felt it was only appropriate to dust this article off and run it again.
Who is Billy Mays and why does he always seem to be yelling at us? You know, he’s the guy who pitches products like Oxiclean on TV; where he extols the virtues of the product with a booming voice that is at least several decibels above pain … and urges you to act “right now” … and if you do he’ll see to it personally that your order is doubled (of course there are 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 space. First of all, 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 29 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://cmdbf.org/ 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’ve lost count of the number of IT shops I’ve 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’s 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 don’t 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.
If you want a “one-size-fits-all” solution, then your risks are associated with product limitations (“best practices” are defined by the vendor’s product limitations).
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 haven’t made it through the analyst maze (yet), but are worth a look.
I’d 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’s 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 of the interested parties.
Once you’ve made your recommendation it’s a good idea to seek out others using these products in a similar fashion (size, volume, etc). It’s probably a good idea to reach out to these folks via a user’s group or other non-vendor controlled association. It’s one thing to see a demo, do a test drive and a detailed requirements evaluation. But it’s 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’ve got a lot of work in front of you getting it installed, tested and into production enabling your IT Service Management processes . . . but that’s 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.