If your helpdesk experience is anything like mine was, you’ve been taking calls and tracking tickets in whatever software solution the decision makers handed down. So, when I first heard my experienced ITSM colleagues discussing the Gartner Magic Quadrant, I wondered what they were on about (Let’s just call it the MQ).
Was it just some analytical mumbo-jumbo, or does it mean something to those of us who might still be in operational roles, today? When I met Gartner’s Jarod Greene at Knowledge12, he seemed like a nice enough guy, so I thought I’d throw a few questions his way for enlightenment.
Can you tell us about your role as Research Analyst at Gartner—what that involves and the career experience that lead you there?
I have been with Gartner for 8 years. I took a rather unconventional path to becoming an Analyst. I came to Gartner in 2004 with the end goal of becoming an Analyst at some point in the future. I started off working in Gartner’s customer support organization as Research Engagement Specialist, which positioned me directly between our customers and our research deliverables. My job was to properly align Gartner clients to the most appropriate analysts based on their needs, which required a deep understanding of the IT Operations Management market.
I used the tools at my disposal to learn the space from the inside out and identify trends. I would dissect client questions, probe vendors for details and reference materials, and listen in on analyst inquiries. I was learning IT operations from the most knowledgeable and influential minds in the industry. I made my analyst aspirations known to the analysts I supported who became my mentors with no hesitation. Specifically David Coyle and the late Kris Brittain served as my official mentors, but anytime I had a question I had places to go to get answers. For 3 years I played a de-facto duty analyst role, writing research and taking basic inquiries and continuing to working closely with our IT operations management analysts. I joined the team officially as a Research Analyst in February of 2011. It’s been quite the ride ever since!
I worked in operations for close to 15 years, and so much has changed, but so much has stayed the same. How have you seen the IT Ops sector change over the years?
In my 6 years of observing this space, I’ve found that we are still facing the same challenges associated with doing more with less and meeting the needs of the business at a competitive price. The difference is that it has been difficult for IT organizations to keep pace with the rate and pace of technology change they acquire to gain efficiencies.
These tools often introduce their own set of challenges, which compounds the issue! For example, when I began supporting IT Operations management, CMDB was the hottest topic on the planet. Organizations literally could not spell it CMDB right, but knew an IT service view CMDB would be their salvation and cure all organizational ails. Well, here we stand and we still don’t see as many in production as expected, and it still remains one of the most daunting challenges in IT. I see the same cycle with IT Service Catalog today – great value proposition (and ITIL says you need one), but it introduces challenges and requires a maturity level and resources that the vast majority of organizations do not have.
I’ve asked you to take part in this interview, so I could find out more about the Magic Quadrant. What is the MQ and how does it apply to people working in the IT Operations sector?
Ah, the million dollar question! Essentially the end user organizations looking at a Magic Quadrant should understand that is a visual snapshot of a market’s direction, maturity, and participants. It is designed to help organizations choose a product or service, but only if that organization properly understands the methodology.
The biggest misconception of an MQ is that it should be used as a vendor selection tool. That is not the case. It should help an organization analyze a market and help to focus their search on important criteria. MQ’s do not provide the details needed during the vendor selection process to align YOUR requirements to a vendor. This leaves the onus on the organization to make best vendor selection based on their specific set of requirements. Often making a vendor selection based on MQ positioning can be disastrous, as I’ve seen many times over the years.
What’s involved from the analyst perspective in putting the document together, and what input did you have, personally?
Jeff Brooks and I first have to identify a distinct and viable market. 2 years ago, Gartner retired the IT Service Desk MQ for a variety of reasons. Most significantly was the fact that the IT service desk market was very mature and well established, with low barriers to entry and little consolidation. MQ’s are for the middle phases of a market life cycle, so as a market begins declining, an MQ is no longer an appropriate methodology. Furthermore, the concept of purchasing a standalone IT service desk tool for ticking and reporting was all but gone.
IT service desk tool requirements (for organizations of all sizes) include modules that were pieces of a much larger IT service support strategy consisting of change, release, service request, and service level management, along with data center management components such as asset management, CMDB, and service Catalog. The personal input I have is in recognizing these changing dynamics and “creating” the market I’m set to analyze. The goal is to put forth an analysis that provides insights to help clients with planning and evaluating tools that fit common requirements.
From what I’ve heard, it’s a fairly rigorous exercise for the vendors aiming for inclusion in the document. What does Gartner look for from a vendor for consideration?
The biggest challenge with the document is setting the inclusion criteria. It is just not possible to include every vendor in the market, so you must focus your analysis on vendors we consider to be the most important best suited to our clients’ needs. When you set the inclusion criteria, you define what it takes to me considered for this market. It does not imply that a vendor is not viable or competitive; it just means a vendor may have a slightly different strategy or functional match, or it addressed a different target market. As Jeff and I research the market through various activities (client inquiries, vendor briefings, vendor provided-references, public sources, industry contacts, etc) we develop and understanding of vendors we believe meet the inclusion criteria, but also reach out through the community to see if we have missed someone.
This is where vendor briefings can be important – Gartner cannot get you on their radar if they don’t know you exist. Every vendor usually wants to be considered, but the criterion determines whether or not they will be evaluated. ITSSM annual license revenue for example may exclude a vendor from evaluation if they do not meet the pre-defined threshold. In some cases, being on a MQ can be a bad thing for a vendor if they do not have the resources to execute on increased demand. There are cases where vendors have been on MQ’s one year, and insolvent shortly thereafter.
The MQ is a bit of a hot-button topic out there in the community of ITSM vendors and consultants, and it seems to becoming an almost lofty goal for those vendors serving the small to medium enterprises (SMEs). In my view, every vendor (of ANY software solution) should be aiming for a consistent ability to execute and a completeness of vision, anyway, but is it really how a recent CIO article explained—are the MQ authors limited to highlighting those vendors who focus on large enterprises?
I loved Richard’s article– very timely! As he pointed out, the majority of Gartner clients are enterprise organizations. 76% of the Global 500 support their decisions with Gartner advice, and we have over 12,000 customers worldwide, the majority of which are larger organizations. Speaking only to ITSM toolsets, larger organizations typically have a much more robust set of requirements than SMB clients.
An organization that needs to manage multiple service levels in multiple geographies in multiple languages may narrow their focus to vendors who can demonstrate this scalability consistently. For an SMB customer who has simpler requirements, it may not make sense to choose the vendor who demonstrates scalability that is not 100% pertinent to their needs. I also think every vendor, regardless of whether or not they are in an MQ should strive to execute on their vision of the market. They should also understand that Gartner will question a vendor’s execution capabilities and may not agree with that vendor’s vision of the market, and that’s fine, because ultimately the IT organization has to make the decision on which tool is most appropriate, given their requirements, not Gartner’s. If your requirements are fairly common, then it may make your evaluation process easier. However it’s not a given that choosing a tool in the leader quadrant means your organization improves processes and services automatically.
I was too far down the food chain to be involved in any tool selection process, but I can tell you, in the last operational role I had (at a small financial institution) the data centre manager googled helpdesk software and chose the local product. What practical advice can you give IT managers about to embark on the tool selection process?
I’m not 100% against that approach!! The standalone IT service desk tools I mentioned before are commodities- you can get ticketing and reporting from just about anyone. The web can be a great start to your market analysis, but at some point you will need to rely on the guidance of a trusted advisor. My market analysis is based on over one thousands of end user inquiries per year. I validate vendor claims against customer references and I review a vendor’s ability to document and commit to development roadmaps. I have no agenda or any bias towards any one particular vendor. I can be one of your trusted advisors!
I can help you navigate this market, but I’m not naive enough to believe you cannot gain value in peer communities, particularly with users who live and breathe these tools on a day to day basis. There is a lot of good information out there, but I think it’s important to always understand who exactly is providing this information, what is their agenda for providing information, and what can you validate their information against.In terms of advice for IT managers set to embark on a tool selection process, I say purchase with your stomach, and not your eyes.
We find that organizations replace ITSM toolsets every 5 years, a trend our friend Karen Ferris calls “IT groundhog day” (I love that btw). That’s crazy when you think about it. There is a lot of conspicuous consumption in ITSM – meaning they think they are what they buy. IT managers buy what they think the mature shops use, as if the tool was the only thing that enabled them to be mature. The purchase of an IT service desk or ITSSM tool suite is often the first step in an organization gaining visibility and managing their infrastructure environment, and organizations believe that within a reasonable timeframe they will gain the process maturity necessary to implement industry best practices, mature and integrate processes, and integrate other systems management tools. This does not happen automatically. There is a considerable amount of effort required to mature across people, process, business management, and technology dimensions, and often that work is discounted.
No tool, in itself, will make you a mature shop – so first develop an IT roadmap to maturity and align your tool purchase accordingly. If you are a reactive, fire fighting organization with ad hoc processes and low customer confidence, start with point, basic IT service desk ticketing tools that come at a relatively low cost and do not require professional services. If you are on the path to higher levels of maturity, consider the ITSSM tools across both licensing models so that you have the capabilities you need when you are ready to use them. If you already are a mature shop, it’s very unlikely you are looking to replace your IT service desk tool, but consider tools that allow you to stay the course of continual service improvement and easily integrate with other systems management tools.
The next IT Service Support Management (ITSSM) Magic quadrant is coming next quarter, can you tell us if the formula may have changed from previous MQs and, without giving away any spoilers, if there are any new entries or surprises?
We are in the final stretch and I’m confident we will be done soon. The formula has changed considerably- keep in mind this is a new market, so it’s a new MQ. The players haven’t changed, but the game has. Yes, IT service desk (incident, problem, change, self service, knowledge, and reporting) is a component of the offering evaluated, but new to our analysis are release governance and SLA management (with regard to incident and service request management). We also wanted all vendors to offer qualifying products licensed in BOTH the perpetual and software as a service licensing models. This is becoming a requirement for customers who want the short term benefits of SaaS and the long term benefits of an on premise solution. Lastly, we wanted next generation support capabilities that offered usage of the product for mobile devices, social and collaboration capabilities, richer information analytics, and the ability to visually map an IT service view to support the incident, problem, and change management processes (so not quite CMDB, but providing similar visualization benefits).
We believe these are critical capabilities to meet the demands of the modern workforce. I don’t know how to describe the MQ without giving any spoilers away! There are some vendors who you did not see on the IT Service Desk MQ, but again, this is a new analysis. As per usual, where the dots are will be fiercely debated, but it may be more interesting to note where you don’t see dots.