A minimum viable product (MVP) is, according to the Wikipedia, “a product with just enough features to gather validated learning about the product and its continued development.” No doubt you have seen a meme about this in social media where this is depicted as a series of transportation methods that starts with a skateboard, then a scooter and so on as opposed to just providing the customer with pieces of the car.
I started thinking about this and how it relates to IT service management (ITSM) and I thought that, although you don’t necessarily make the association between something that is “hip” and “cool” and building an MVP for the practices and capabilities that support IT services, there is one way that we can approach this to at least build something that ensures “enough features to gather validated learning about the product and its continued development.” That way is the ISO/IEC 20000 standard.
You see, unlike ITIL, which is considered the best practice for ITSM practices, ISO/IEC 20000 is an international standard, based on ITIL, which companies have to follow in order to show adherence to service management standards. If you, as a service provider, want to show the world and its dog that you follow standardized, repeatable ITSM practices, you go for the ISO/IEC 20000 standard certification. You will get an outside auditor to come ask you questions related to the standard and, if you pass the audit, you get a shiny nice certificate that you can brag about.
Achieving ISO/IEC 20000 certification is no easy feat, but it is a transformative experience for the organization that undertakes it. You see, the standard presents the minimum that you need to do in order for your organization to be compliant. And there, I think, it’s the secret to achieving some sort of MVP state for the capabilities and practices that support your IT services.
The standard itself is quite unremarkable and, to be fair, very generic. For example, in incident management the standard states, “When prioritizing incidents and service requests, the service provider shall take into consideration the impact and urgency of the incident or service request.” That’s it. In order for you to meet the requirements in the standard, you need to be doing what the clause says. It will not say how, though. The how, or the suggestion of the how, can be found in ITIL.
But then think about this: Why do many organizations overcomplicate their incident priority matrix if the actual clause for this in ISO/IEC 20000 certification is so simple, so lean? A potential answer: scope.
You see, the way that ISO/IEC 20000 works best is when you have a narrow well-defined scope of service. When everything related to your service management system (SMS) revolves around this, it becomes relatively simple to maintain.
Stroll through the directory of ISO/IEC 20000 certified companies and you’ll see what I mean. Many of the scope statements you will read are very specific to a service, customer or location. This then provides the lens through which everything within the SMS is designed. What does it mean, for example, to have a Priority 1 incident when all you do is “support the provision of application support and remote infrastructure management services to external clients and their customers and internal IT”? Well, total loss of a remote access server for one. Is email covered here, and would loss of an email server be considered a Priority 1 incident? Maybe. But reading through this scope prima fascie does not tell me this.
So here’s how I think you can leverage the idea, if not the certification itself, of ISO/IEC 20000 as the “MVP” your organization needs to fix some of the issues in the ITSM space:
- Define scope. There is something that your business stakeholders (note that I said “business” and not “IT” — BIG difference!) value above everything else. It certainly can’t be everything. Something that would cause major embarrassment, or have clients running en masse to the competition. That is your vital business function (VBF), and that could be your scope. Define that, and be comfortable in treating the things that fall out of scope differently
- Put consistency over maturity. If you read many of the clauses in ISO/IEC and take them at face value, they do not express any specific level of maturity. What they do express (and require in order for any organization to pass the audit) is consistency. Things need to be done. You need to prioritize your incidents, your CMDB needs to be updated, and requirements have to be agreed-upon with the customer and so on. Make sure that people are actually doing it, and most important…
- Do it all! A big mistake that many organizations do when adapting ITIL is just focusing on operations (incident, problem, request) and a bit of transition (change, configuration) and design (availability and capacity in a reactive mode, and poorly). For example, ISO/IEC 20000 asks for an actual availability plan with targets, procedures to be implemented recovery requirements, etc. Do you have one, or do you just have availability targets “somewhere in the tool”?
All of this will not work if management is not 100% committed to this, which — coincidentally — can be found in Clause 4.4.1 of the standard: Management Commitment. It starts by saying, “Top management” (yes — top management) and goes on to talk about establishing, communicating, ensuring, management reviews, etc. It starts and ends with top management.
So take time and check your service scope, and see if you can get your people to consistently deliver to an “MVP” state as it relates to your processes and procedures. Get them to understand it and to execute consistently. To do that, focus on those services that directly provide value to your customers, and execute upon all of the minimum requirements needed — the ones found in the ISO/IEC 20000 standard. And ITIL? Use it for ideas as to how to do things, but keep the idea of the ISO/IEC 20000 requirement front and center.
Oh, and remember who the real MVP is. It’s your customer and the value you provide through well-defined services.
This article is published as part of the IDG Contributor Network. Want to Join?