Do you ever get a Big Idea? You’ll be talking or reading about ITSM and the proverbial light bulb comes on. You see a connection or an underpinning concept that you hadn’t seen before. Sometimes it appears to be an original insight, one you haven’t heard expressed exactly that way before. And very occasionally it really is novel and it really is right: you subject it to the scrutiny of others and it stands up.
It happens to me. Because I’m privileged to spend so much time interacting with some of the best minds in ITSM worldwide – and thinking and writing about what I learned in those discussions, and applying that knowledge as a consultant – it happens to me quite often, about once a year. In fact I will be presenting on some of these big ideas at the upcoming Pink Elephant IT Service Management Conference and Exhibition (PINK14).
A couple of years ago my Big idea was Standard+Case, a topic which I will berunning a half-day workshop on at PINK14.
Standard+Case is a synthesis of our conventional “Standard” process-centric approach to responding, with Case management, a discipline well-known in industry sectors such as health, social work, law and policing.
The combination of Standard and Case concepts gives a complete description of ticket handling, for any sort of activity from Incidents to Changes.
Standard tickets are predefined because they deal with a known situation. They use a standard process to deal with that situation. They can be modelled by BPM, controlled by workflow, and improved by the likes of Lean IT and ITIL.
Case tickets present an unknown or unfamiliar situation. They rely on the knowledge, skills and professionalism of the person dealing with them. They are best dealt with by experts, being knowledge-driven and empowering the operator to decide on suitable approaches, tools, procedures and process fragments.
ITIL and Lean do fit this S+C paradigm, if you use them in the right situation: Standard responses. S+C extends them with better tools for non-Standard cases: Adaptive Case Management, Kanban, Knowledge Centered Support(KCS)… Better still, this S+C approach might let the ITIL and anti-ITIL camps live in peace and harmony at last.
Last year it was Slow IT. Slow IT is a provocative name. It doesn’t mean IT on a go-slow. It means slowing down the pace of business demands on IT so as to focus better on what matters, and to reduce the risk to what already exists. Think Slow Food, and more recently Slow Business and mindfulness etc.
The intent of Slow IT is to allow IT to deliver important results more quickly. It does this by concentrating on the interfaces between business executives and CIOs. Slow IT highlights the importance of Governance of IT and of Service Portfolio in order to make the right decisions to do the right things in the right way at the right time, to maximise benefit and minimise risk.
Right now the pace of change in IT is approaching human limits. Many IT shops are overwhelmed by change, drowning in projects. More are overheating: working at lunatic pace because the IT community convinces us we have to. Slow IT challenges the hysterias and fads of IT to ensure that these results are really needed as quickly as we think they are. Slow IT is about trying to introduce more measured responses, to bring some sanity to the current dangerous madness that is organisational IT (you can read more on this here).
I’ll be presenting on Slow IT at PINK14. In addition we’ll talk about my Meet-In-The-Middlestrategy to address the Slow IT issues by offering a quid pro quo: Fast IT. If the organisation will slow down the demands on IT, IT will have the breathing space to implement approaches to respond faster, such as Lean, Agile, DevOps, and good old CSI. Right now too many IT teams are so flat out serving the business they don’t have the bandwidth to introduce better methods properly. It’s the old catch-22 of being so busy putting out fires that you can’t improve fire-fighting or fire-safety. Slow IT takes off a bit of pressure, giving the team some headroom, to make improvements.
I hope to see you at the Pink Elephant ITSM conference. I’m honoured to be assembling some of those great ITSM minds at the Pink Think Tank, to address one of the biggest issues facing IT today: how to manage a multi-sourced IT value chain. We’ll be looking to produce tangible actionable advice, so look out for the results. I have a feeling it may be the catalyst for my next Big Idea.
Today we begin our competitive analysis of Change, Config and Release. As with previous reviews our goal will be to highlight the key strengths, competitive differentiators and innovation in the industry.
Widely recognised as key to the successful preservation of production systems, the ITSM processes of Change, Config and Release are perceived as pivotal to maintaining the integrity and stability of the IT environment.
In a nutshell:
Change Management is the process used to track and communicate any changes in service that may impact the customer such as when systems are taken offline for updates.
Configuration Management is the process used to track individual CI’s (Configuration Items) and the way in which they interact with one another.
Release Management is the process of managing software releases from development right through to release.
Each process can be used individually but more often than not you will find these processes intertwined. When considering either a Change or Release you will need to know the CI’s that will be affected before you begin.
E.g: Your organisation needs to upgrade your in-house software package to all of its desktop pc’s, tablet devices and kiosks.
Release Management is used to track the in-house development of the software in question, Config management is used to scope the number of devices, number of people and types of people affected while Change Management is used to ensure the changes take place on a date that will cause the least disruption and that the why, how and when the changes will take place are communicated to the relevant people.
The criteria we will be using for our assessment is published below.
Ability to maintain a detailed record of each system’s configuration
Ability to interface with all internal Management Data Repositories (MDR) allowing the tool to compare reported configuration with actual configuration stored in the MDR
Ability to define dependency relationships between CIs
Ability to assign maintenance windows to CIs
Ability to auto discover CIs
Ability to interface with Inventory Control tools (to automate gathering of asset and inventory information) and barcode scanners
Ability to create automated alerts when a CI is found to be in an unauthorised state
Ability to link Release records to Change records
Ability to provide a Change/Release calendar with scheduled change viewing by group, and to customize the sorting and filtering of calendar views and link to existing calendar products
Calculate an objective risk assessment considering business impact and affected services
Show logical links between components included in a service in order to carry out business impact analysis
Ability to automatically create a Change Request when unauthorised changes are made to CI’s
Ability to schedule recurring events and maintenance
Ability to create and select pre-approved Change/Release from a pre-defined list
Pre-determined fields to auto-populate when Standard Change/Release from list used
Ability to capture the Change/Release date and time and who will be responsible for implementation
Ability to automatically send approval requests to the appropriate approvers
Ability to notify the assignee of the task and due date
Ability to link resources/approvers to Changes/Releases
Ability to assign tasks to individuals to be accomplished within specific time frames
Ability to alert Change/Release managers when approvals are past due
Ability to change status of Change/Release approvals
Ability to easily identify scheduling conflicts and reschedule appropriately
Ability to attach and store documentation with a Change/Release record
Ability to authorize and schedule Release deployments in conjunction with Change Management processes
Ability to change status of Release and linked Changes
Automatic notification for scheduled start/end and when the status of a Change associated with a Release changes
Ability to build, bundle and schedule different types of release packages for deployment
Ability to change status of Change/Release documentation
Ability to create sub activities or tasks for separate assignment to an individual, group or vendor
Ability to version release components and packages
Ability to assign tasks to teams/resolver groups
Ability to track the physical location of contracts and agreements, and identify the individuals responsible for them
Ability to define Change and Release Windows (including freeze windows)
Ability to document back-out procedures
Ability to ensure that Release deployments are subject to scheduling and approval requirements managed by the Change management process
Ability to provide proactive notification to stakeholders and Change Advisory Board (CAB)members for Changes with critical business impact and provide fully configurable filtered views of scheduled changes to multiple stakeholders
Ability to designate back up approvers
Ability to set thresholds for automated approval process
History of approval requests logged
Ability to easily identify affected CIs whenever a change is made
Ability to maintain an audit trail of changes made to a CI
Ability to track Asset status and lifecycle management
Support of multiple software audit options
Ability to perform software license management including automated notification of license expiration and non-compliance
Ability to create and publish a Master Release Schedule
Ability to associate the Master Release Schedule with Service Level Agreement information
Ability to store approver comments with the approval, and store approval history for a Release
Ability to track and trace post deployment activities
Ability to trace implementation to the authorized version in the Document Management Library (DML)
Bulk import of licensing data
Ability to track costs of CI’s
Alignment with industry frameworks
Ability to support a “virtual” CAB (i.e. approvals/issues stored electronically)
One of the biggest challenges I’ve been put up against this year is probably the view that, if something wasn’t invented here, it’s no good. And boy, have I struggled with trying to make things look like we actually invented them here.
I won’t try to figure out why the ‘not invented here syndrome’ is so rooted in our organization. There are probably lots of reasons, historical, organizational, cultural, previous experiences and what not. Some experts tell me I have to change the attitude among my co-workers and kill the opinions that abound and are aimed towards massacring external influences. That would probably be a good thing, if you had the support and means to do it. I, and my ITSM colleagues, went for another approach.
The post-it walls
We have a ‘war-room’ on the third floor of the building where most of operations and tech department are located. That’s where people gather whenever there are major incidents going on, or just for debriefing when the nightshift go off and the dayshift starts. The walls of this room were once covered with whiteboards and huge post-its. Every now and then some manager would move the post-its around and write stuff on them during the meetings that were held there.
When we looked into this room we discovered that they had built a sort of an incident and problem management ticketing system with post-its on whiteboards.
As we are interested in having people working in the ITSM-tools we have, and actually following the defined processes, we of course asked:
Why don’t you use the ITSM-suite and the incident and problem management processes?
We mostly got mumblings and a lot of staring at shoes in response. The ones who spoke back did so in a quite animated manner. Some claimed that the processes were over complicated and useless, others argued that the ITSM tool didn’t meet their requirements or that it was too hard to understand how to use it.
No problem, we thought, let’s work together to change what doesn’t work well enough in the tool and the processes. However, the people in the room were not so interested in that.
First of all, they didn’t recognize what they did as incident or problem management, it was the ‘8:45 war-room meeting and that’s where we actually work’. So even if we had some shiny processes to help them do their job more efficiently, we weren’t welcome. Just for that reason.
Furthermore, not only did we miss the opportunity to control, but also the ability to measure the processes and activities. Apart from that, you had to be physically present in the room to be able to get all the information needed to work on the cases. The various managers had different ideas on how to do things as well, so we never got a chance to actually work in a process oriented way or with commonly agreed routines.
Inventing it here
We started by accepting the methods used in the room with the post-its and slowly but patiently planting small but important changes to the methods and the vocabulary. We did some parallel registration of the data on the post-its in the problem management ticketing tool, and we began to show the advantages of a tool that wasn’t physically restricted to a single room.
By now we’ve lost the post-its and we register and follow all PM tickets in the ITSM tool. We’ve started to deliver some metrics on what we believe should be important to the company, and we show that our methods get the job done faster and with better results than before.
There’s still a long way to go to make this stick throughout the entire organization and to be able to convince all the people involved that it makes a difference.
But, just the same, we have actually invented problem management here at my company and we are proud of it!
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.
Thanks, Jarod, for taking the time to answer the hefty questions. I look forward to some lively debate when the new analysis is released.