Questions you should ask ANY IT Service Management Vendor

Having been a consultant and IT Manager for so many years, now to join the ranks of ITSM Software vendor, I find myself asking…Myself…  “Why did I make this switch?” 

Obviously, I found that the solution I currently represent, ICCM e-Service Desk, to be an extraordinary and compelling means of process orchestration.  However, prior to joining the “dark side”, I had been working on business process modeling, architecture modeling, and model driven orchestration of process underpinning applications for a number of years, and e-Service Desk approached that capability, especially around IT Service Management.  But it’s more than that. 

I have watched, observed and read about so many failures around IT Service Management and believe there has to be a better way.  I have a genuine concern that ITIL/ITSM could become a flash in the pan if it doesn’t start showing more demonstrable successes than failures.  I wrote in my last blog entry “Why ITSM programs fail” (http://tr.im/nTYb) highlighting many of the reasons ITSM programs fail, or do wonderful things, but fail to achieve the objectives that they were started for in the first place.  I think part of this is because people in IT expect non-traditional results from traditional approaches.

Over the past twenty years, I have written RFP’s, responded to RFP’s, met with many ITSM vendors, delivered a good many ITSM projects (people, process and technology) and implemented a good number of ITSM solutions.  I have found some fairly common characteristics in how customers and vendors interact- which leads to me writing this blog entry. I thought I would offer some basic information, suggestions and guidance that may help you in selecting the appropriate solution to address your ITSM program needs, and avoid the failures.

Some of the key tenants…

• “Don’t trust your ITSM vendor…” .. There, I said it.  Don’t trust me, don’t trust HP, BMC, Service-Now, CA, Frontrange, EMC, or any other vendor.  Start with that, and you will be on your way.  Yes, this makes the RFP process very difficult because you don’t know if the information is truthful.  Here’s some insider information; While ICCM doesn’t practice this, other traditional software vendors will answer “yes” to all the questions on your RFP response in hopes to get to the “next stage”.  Once there plan on a “kabuki dance” around those requirements that they don’t entirely meet.  At this point, they usually try to convince you out of your requirement, or propose a costly and complex solution that they hope never is realized.  Guidance: Obviously, trust should be earned, not something given because of brand name or stature.
• Pink Elephant or OGC Certification Only speaks to effectiveness – None of the certifications I have seen so far test anything other than process effectiveness.  If two solutions orchestrate Incident management identically, but the second cost 10 times as much and requires three times the resources, they will still be seen as equivalents.  The certifications do not factor in cost of ownership, complexity, etc.
• Check References – I worked with one of the larger ITSM software companies on the planet.  We had a great many references but rarely did we have any contact information, quotes/comments, from the specific customers.  Sales would often use customer comments and quotes from other products or services out of context.  Guidance: If it were me talking to ITSM software vendors, I would not only check references but ask very specific and direct questions of their customers (examples that I will provide below).
• Look beyond Waves and Quadrants.  This was a great webinar title conducted by Third Sky a few months back.  They made some very good observations about the IT think tanks.  Gartner and Forrester do highlight very well, the issues with the industry, but do very little, in my opinion, to drive and support innovation and new approaches.  They wonder why the industry hasn’t advanced – could it be because they continue to recommend the 800lb solutions as “leaders”?  Most of the information they provide are lagging indicators (looking in the rear view mirror), vs. leading indicators (looking to the future).  Guidance: Use the Gartner and Forrester research as a data point, not philosophy.  It’s interesting but not significant.  I don’t think even Gartner analysts expect you to consider their research infallible and it should be used in context.
• Request a Trial/Proof of Concept – I think this is the single best way to differentiate solutions.  An RFP provides a static, two dimensional, myopic view which as I stated before, may not be honestly responded to.  The state of modern technology and software should allow for quick “Try it before you buy it” scenarios and use cases.
  • If you don’t have the time to invest in understanding “What’s behind the curtain”, I wouldn’t invest anything at all in any solution.  If you do select a solution that doesn’t pass the tests of efficiency, you may be spending a lot of time (usually billable to a consultant) figuring out how to make what’s behind the curtain work for you.
  • If the software vendor doesn’t have the time to invest in you as a customer, they either aren’t interested in your business, or they have something they would rather you not see before you purchase.

Since RFP’s tend to be process/technology specific, and vendors can dance around the responses, I thought I would provide structural/context questions to ask any ITSM vendor, rather than drill them on requirements.  Their responses, but more importantly how they respond should be noted.  Hopefully, these questions allow you to answer most of your specific RFP/Requirements yourself.  Since we are talking about process solutions, I have included questions about effectiveness, efficiency, usability, and administration/maintenance. 

With regard to all these questions, it is important to note they are subjective, requiring elaboration – a simple yes/no will not suffice.  And if you get yes/no, follow it up with “How?”.

1. What is the “Design Basis” of your solution? In other words, can I see the process and/or architectural documentation, which drove the out of the box configuration?  This way you can determine how much gap exists between your processes and the solution processes.
2. Can your solution be used “Out of the box”?  This means, other than linking it into your people, locations, roles, etc, can the solution be used “as is”?  Many customers anymore want to take a more “Adopt and go” strategy as their current processes aren’t well documented and managed.
3. Are customers using it like this?  Can we speak to them?  Very important to understand what it means to use “Out of the box”.
4. Can your technology efficiently be used for purposes other than that of IT Service Management?  In other words, can I use it strategically with my business, vs. tactically, just within IT?  Does your solution support other processes I define without “major effort”, or do I need to adopt your processes as my design basis?  (Major effort meaning I will need to hire consultants to make it work)?
5. Does your solution orchestrate processes I need in the near term AND long term on my roadmap, or is it just geared at the processes I am looking to implement in the next six to twelve months?  Consider your ITSM roadmap and what processes you hope to implement and by when.  This will keep you from optimizing near term processes and sub-optimizing far term processes.
6. Does your solution provide a consistent set of metrics and measurement around process execution?  For example, can I easily determine lead times, wait times, queuing, etc.  Metrics needed for process optimization.
7. What is the reporting capabilities available from the solution and what reporting will have to be obtained from third parties?
8. How am I be able to perform process improvement activities efficiently?  Where do I get the data?  Will it be leading or lagging indicators? 
9. How many process improvement engineers will be needed to be able to perform any analysis across a number of processes?
10. How does your solution provide a means of version/source control from a process perspective?  Can I move “processes” around as a single object?
11. Does your solution have a common look and feel across all processes?  How much will my users have to train on different modules or components or can I train them once?
12. Does your system integrate to my common desktop tools such as Microsoft Office, Excel, and Word?  For example, can I link documents to objects in the ITSM database?  What options are available to integrate to SharePoint?
13. How much does your solution walk me through a process, vs. how much do my users have to know in order to get through the process?  This is probably an effectiveness question as well.
14. What technology add-ons will my users need on their desktops or laptops to utilize your solution?
15. Change Management is always an intensive process.  How many key clicks, mouse clicks, forms and data elements are included in getting an RFC from start to finish?
16. How many Administration resources will be needed to implement your solution? How many to support and operate it ongoing?  Are the fully loaded, or can they be shared in other areas of my organization/business?
17. When a major or minor release comes out, how much of my process design basis will be affected?
18. Can my “Configuration” be moved and provided via SAAS/ASP or vice versa?  How difficult is it to move my specific configuration (design basis) and data between environments?

Explore posts in the same categories: ITIL, ITSM

Tags: ITIL, ITSM

You can comment below, or link to this permanent URL from your own site.