 |
|
     |
|
|
| digg (discuss or comment) on this article. Show your support for DITY! |
Print page |
Subscribe
Its Free! |
RSS Stay up to date! |
PDF Pass it around! |
|
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...
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 27 years experience working with IT and ITSM enabling software, following I present my 7 steps to properly choosing a software vendor and package. 7 Steps 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. Analyze Your Needs 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. Specify the Requirements 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. Identify Suppliers
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). Do Research 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. Kick the Tires 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). Recommend 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 the interested parties. Talk to Your Peers 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. Its 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. Summary 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.
Where to go from here
Related programs Related articles
|
 |
|
|
