What startups should know about ITIL®

While some IT professionals encounter this ITIL thing on their first day in a new job, some others have reached the role of Senior Software Engineer at the ripe age of 26 before being exposed to it. What is it and why would anyone working in a startup care about a 30-year-old IT framework? The article sheds some light on this 250,000-exams-a-year phenomenon.

TL;DR

• Startups face new challenges as they grow and optimize; their context is different from that of Enterprises but some of the challenges are similar and there is guidance out there that could be useful to address these
• ITIL is mostly known as the Enterprise approach (of the past) to IT Operations management, but there’s some less known rather useful stuff in there, too — mostly around services, customer value, and improvement
• The concept of “service” is similar to “product”; its end-to-end view of value creation covers strategy, design, transition-to-live, and operation of the service, powered by feedback loops for continuous improvement
• The scope of IT Service Management is wider than some approaches to (digital) product management — it puts less focus on product development and more on helping customers achieve their outcomes
• ITIL in the books and ITIL in the wild tend to be very different things; many organizations claiming to ‘use ITIL’ have implemented some practices while ignoring or going against the principles — fair enough, the imperceptibility of the principles would have made even Waldo proud
• You should read the ITIL books for ideas, not recipes; considering that you’re unlikely to even consider reading those 2000 pages anyway, the best way to familiarize yourself with the approach and get pointers to what might be useful for your context is to read ITIL Practitioner (2016)
• Skip to the “Useful stuff” section if you’re interested in examples, not the back-story and context-setting

Introduction

Different contexts require different approaches — if there is one thing that the Cynefin framework has taught us, then this is it.

The IT industry has spent a lot of effort and so much, oh so much money on optimization and standardization initiatives, often leading to business-halting rigidity. Yes, stability can be nice and is sometimes even required, but there are many situations where fewer controls are required to enable innovation, and more flexibility is required for decision-making.

Where the “old world” of IT focused on costs, standardization, and stability, the “new world” focuses on speed, resilience, and value delivery. No, they did not “do it wrong” back in the day, but what is possible has changed. The IT Service Management (ITSM) industry was born in the old world, yet some of the concepts there seem to be even more relevant today than they were a few decades ago — especially the (renewed) focus on customer value.

Startup challenges

As startups grow and scale, they start worrying about things like paying customers, the stability of core operations, repeatable processes, and getting rid of that sheen of red on their balance sheets. Because some of these concerns might hit them by surprise, there’s often a sense of urgency in addressing them. One option would be to invent solutions from scratch, but in a growing company, not everything needs to be artisanal anymore. The other option would be to check what others have done, learn from it, and see how to adopt the learnings to their context, and continuously improve.

The IT industry has seen some of the aforementioned challenges before and has tried to address them in various ways, some more successful than others. As startups labour on finding the best ways of working for their context, familiarizing themselves with “prior art” could be useful — not to blindly copy solutions, but to learn about what worked or not, and why. Learning what should not be done is as useful as finding ideas to try out.

I believe that in ITIL, the best-known framework for ITSM, there are indeed some (hidden) nuggets of wisdom relevant for startups. The following is a mix of history, context-setting, development-tracking, and practice-mapping to create a link between ITIL and today’s world of startups. I will spend only a few paragraphs on pure history at the beginning — I think it is important for understanding the rest. Bear with me, please.

The history

ITIL is an IT Service Management framework that consists of publications, qualifications, a membership scheme, and accompanying services. ITIL is old, like really old — the first version was released in 1989, which means it turns 30 this year. At the same time, it’s new, like v_not_even_released_yet new — the latest edition of ITIL, called ITIL 4, is scheduled to be published in February 2019.

Over time, the number of publications one has to read to get a full picture of what the framework is all about has been shrinking. The first version had the guidance distributed across more than 30 loosely coupled books which shrank down to 20+ mostly-ignored-except-for-two books for v2, and five only-trainers-have-read books for v3 / 2011. ITIL 4 comes with one book, at least initially, with plans for several more in the coming years. We shall see.

ITIL originated in the UK, so we can say it’s a European thing — for the time being, at least. Some countries have embraced it fully —e.g. the Netherlands, where to-be IT professionals get their ITIL certificates already bundled with their birth ones, or the Scandinavian countries with hourly ITIL Foundation courses. Former colonies, on the other hand, do sometimes have a strong “not invented here” vibe going on, which might explain why ITIL is relatively more widespread in Europe than in the US.

Those who have even heard about ITIL without the experience of working for years in Enterprise IT often associate it with “tickets” or the ever-wonderful combination of lengthy forms and weekly meetings commonly known as the “CAB”, or Change mistakenly-used-as-Approval Board. For some with just startup experience, the only exposure to ITIL might be the bedtime stories presented at DevOps conferences.

Something sounds familiar

It is important to remember that the need for ITIL came from a very different IT setup compared to that of today’s startups. IT had a supporting, not central role in the organizations’ daily operations and many IT projects were about digitalizing existing processes, rather than true innovation.

Funnily enough, many organizations are still doing this today — or, in some cases, just starting to — under the name of Digital Transformation. But hey, the future is most definitely not evenly distributed.

IT was there to support business processes, to make them faster or cheaper or more mature or black-belt-worthy, whatever the sales pitch from the vendor or consultancy was, and while sometimes it seemed to work rather well, in many other cases, lots of new challenges emerged, sometimes with devastating consequences. Some of the practices that seemed to be working well were collected and documented, and this later came to be known as ITIL. I believe those more familiar with the DevOps world can relate.

The name “ITIL” used to stand for “IT Infrastructure Library”. Yeah — that’s where the focus was at that time. Nowadays it is all so completely different, with all the discussions about cloud computing and containers and serverless and … but I digress, apologies.

The need for not speed

Over time, the focus in Enterprises shifted away from the novelty aspects of managing IT (infrastructure) to understanding the rationale of spending even a dime to fund the growing budgets of IT departments. The initial questions of ‘What can IT do for us?’ and ‘How can we make it work?’ were replaced with ‘We need IT to do more, for less!’ and ‘Make sure it doesn’t break!’ edicts. The cute IT pony had turned into an Enterprise draft horse.

This also brought a stronger specialization into IT — from different specialists (e.g. infrastructure, software development, databases, operations) working together in one team to being split into specialist teams, with all the usual communication and alignment challenges one can expect to see in the Enterprise. In other words, we moved away from DevOps.

The ITIL guidance evolved accordingly. There now was more talk about costs (including outsourcing) and stability (including change controls), less talk about technical practices (including for software development and testing), and a few largely-ignored inklings of ideas about business value.

The disconnect

One of the concepts that was strongly advocated in the ITIL guidance was the service provider / customer collaboration view, which over time in real life morphed into “The Business” telling to “IT” what they want in the form of requirements, and “IT” responding to that with new applications that they now called “services” because of their recent ITIL “implementation”.

Some of those applications were built in-house, but more and more software coming to the Enterprise was either Commercial Off The Shelf (COTS) or developed by partners under the watchful eye of the PMO. The wall between Development and Operations that was heightened with specialization became ever higher with outsourcing, and organizations encountered various interesting situations where e.g. the cost of changes to the application even before it was released exceeded that of the initially agreed development work. And, well, “The Business” was still rather unhappy when they finally saw what their money had paid for — both the applications and the ever-growing wall of confusion, to be honest.

The problems resulting from the disconnect between various parts of IT that were still in-house became too big to hide, not to mention the growing disconnect between “IT” and “The Business”. Innovative organizations (by the measures of that time, at least) started paying more attention to the end-to-end visibility and collaboration. “IT and Business alignment” in service management was supposed to be replaced with “IT and Business convergence” and such. Ahem.

There is still disagreement even in the ITSM world over whether this model even makes sense, because why would you want to treat your colleagues as customers, rather than partners. My experience tells me that “service” can indeed be a useful concept to use for a value delivery vehicle, as it shifts the focus from the technical aspects to customer objectives and improvement. In some cases, at least — so this is not guaranteed to happen the moment you start claiming to be using service management.

Towards a more holistic view

In 2007, ITIL v3 was released. As you will quickly find out even when talking to “the ITIL guys”, v3 is a sensitive topic for more reasons than one, but it did bring in the concept of the end-to-end service lifecycle to replace the loosely coupled and often-siloed-in-reality practices (that ITIL still calls “processes”, although they’re anything but). The 2011 edition of ITIL, released in, well, 2011 partially addressed the challenges of v3, but for some, it was too late to replace the pulled-out hair or hide the grey patches.

In 2014, the ITIL framework was taken over by the newly formed UK-based joint venture called AXELOS. By this time, the DevOps movement was in full swing and agile software development was the norm, not the exception, practicalities and real-world success aside. New ways of working were in conflict with what had become known as “ITIL” in many organizations — slow-moving queues of tickets bouncing back-and-forth between teams, lengthy request forms, rigid procedures, draconian controls, useless meetings, and the general feeling of disconnect and despair.

Some say these problems are symptomatic of ITIL because of its nature. Some disagree. And some are too busy getting work done to take part in social media debates. I have seen too many organizations benefitting from leveraging the guidance in ITIL to believe it’s evil by nature, but I have also seen many organizations struggling with making sense of it and/or avoiding the aforementioned problems. ITIL Practitioner guidance that was released in 2016 was a part of the response to this challenge.

Wheels and spokes

The ITIL framework has seen the IT industry go through several shifts, sometimes completely novel, sometimes iterations on what was there before. It is unlikely you’d find copious guidance in the tomes of ITIL on how to innovate or pivot because that was never the focus of the framework. There might be something useful for when you have found your product-market fit, though.

At the same time, I’m not saying that startups can just copy guidance from the pages of ITIL and apply it, verbatim, to their organization. That would be an unwise thing to do for both startups and Enterprises alike. I’m also not saying that the ITIL books are an easy read — at 2000 pages, and with a lot of jargon, they are definitely not.

The next section will introduce some of the concepts covered in ITIL and, in my opinion, also relevant in the context of a scaling startup. I’ve brought these out so that you don’t have to read all the ITIL books or go through the certification program — there is a lot of (free) additional guidance available, and this way you know what to search for if you want to learn more.

The useful stuff

Not all of the things described in ITIL have found their way into organizations claiming to have “implemented” ITIL. Also, some of the real-world practices in those organizations often falsely attributed to ITIL ignore all the warnings in the books or go directly against the recommendations.

The main focus areas for ITIL in the real world have been in IT Operations (e.g. incident management), planning (e.g. availability management and capacity management), collaboration-but-actually-reporting (e.g. service level management) and the intersection of IT Operations and Software Development (e.g. change management, release management, etc.). Aspirationally also configuration management (CMDB, anyone?) but the success of this can mostly be measured in fees paid, not results achieved. Some of the key value-enabling areas — such as Continual Service Improvement and Service Design — and the core principles have often not received the attention they deserve or have been completely ignored.

Those more familiar with what they have come to know as ITIL might want to read the following through the ‘ITIL: do as I say, not as I do’ lens because it might not align with their experience of “ITIL in the wild”. Again, not a new approach to those familiar with e.g. “Agile in the wild” and “Agile in books and social media exchanges”.

Customer focus

ITIL uses the concept of “service” to describe a vehicle for customer value delivery, keeping in mind the aspects of expected outcomes, costs, and risks. For any of this to work, the first step with services is to figure out who the customers are and what it is that they (think that they) need.

This links well to current discussions in the software product management domain, where a lot of work effort can be spent on assumed needs of imaginary customers, rather than on data-based customer insights.

Of course, a startup in its early days can be quite unsure about who their customers are or even whether the service they want to provide is of any value to anyone. The customers themselves might not know what their expected outcomes are. Searching for the right product-market fit works differently before there’s a satisfactorily large number of paying customers.

It is important to note that we are talking about outcomes, not outputs here. Any investment remains output-focused (delivering e.g. additional computing power or new functionality), and is, as such, an unjustified expenditure and a potential waste until it has been connected to expected business outcomes. I’m not suggesting that the link should be made after the fact, quite the opposite, but potentially significant savings can be made today by assessing the current investment and initiative portfolio through a quick ‘And what exactly do we want to achieve with this, and why?’ analysis.

Continual improvement

Services, architectures, tooling, processes, and procedures — all of it needs to be continually reviewed and improved as appropriate, to ensure the delivery of customer value and the achievement of business outcomes.
(Oh, this sounds so textbooky … apologies.)

The trouble is that continual improvement is often addressed as an afterthought, which in terms of “when” means “never, except in PowerPoint”. There seems to be a widely held belief that we should start thinking about continual improvement once everything else has been completed according to the plan and to required standards — because then the “real work” is done and we finally have time for this extra stuff, right?

It’s amazing how we still sometimes think that basing developments and improvements on 5-year plans is a viable approach, given that the events in 1991 should have conclusively shown where it leads. We still seem to think that the world just stands still, waiting for us to hit the 5-year targets. Sure.

Instead, continual improvement should be part of the work. A fundamental part, not a nice-to-have part. Continual improvement should start on day one, not scheduled for after achieving that coveted level 5 maturity.

Hint: most maturity models are context-insensitive and come with high costs and low gains; you might want to reconsider basing your improvements on a maturity assessment unless all highlighted action items are clearly linked to business value. Maturity assessments can be useful in some contexts, but they are often abused and extended beyond their usefulness.

Also, continual improvement is usually best run as a continual activity, not as a project or a program. Think about asking for funding for a program that would immediately start fixing what you delivered earlier that week. ‘Can’t you do it properly the first way around?’, your sponsor might ask. So yeah, don’t do that.

An end-to-end view of value delivery

This could be seen as somewhat aspirational, as the context of ITIL is IT Service Management (ITSM) and in the real world, ITSM rarely has the mandate to manage the whole value stream from ideation to customer value realization. It has kind of worked for internal services (in some organizations) that sit in the domain of the IT Department, but not so well for externally focused and sold services. Usually, there are many teams and decision points before and after the work done by the tech teams.

The concept is cool, though. Remember when the early DevOps community realized — not like Patrick hadn’t painted it red many times — that there was more to the world than Dev and Ops? Things like QA and Security, for instance. So we got things like DevSecOps. The most recent discovery is the usefulness of the budget holders, so now we sometimes talk about BizDevOps. Or BizDevSecQAOps. I’m obviously biased here, but I think the old name “ITSM” is just so much shorter and simpler, isn’t it!

The sad thing is that in the real world, the ITIL “implementations” often ended up creating process-based silos along with the “not my job” attitude. So, instead of collaboration and flow, we got separate ticket queues, conflicting priorities, lack of transparency, and unhappy customers. At the same time, if you look around those organizations, then there’s a high chance you will see many silos across the whole organization, not just in IT. Go figure.

You might have noticed that I use double quotes around “implementation”. This is because no organization should implement ITIL, at least not in the common sense of “implementation” as encountered in the wild. The common approach usually leads to the means becoming the ends, and the business rationale of “implementing X” is described as ‘then we have X’. The best approach to ITIL is to a) figure out if it could be helpful to your organization, b) adopt the service mindset, and c) adapt the guidance to your context and requirements. There is no one right way to adapt ITIL.

Single Point of Contact for support

I believe you are aware that your customers do not care what your organization’s internal structure looks like, how many teams are involved in developing and maintaining the products and services, and which exact module or microservice is the one causing problems if things break.

The customer usually appreciates a single point of contact for any issues or questions or requests they might have, not a list of email addresses for different support teams. It is your job to figure out how to route the work internally while maintaining transparency and capturing the gold-worthy data the customers are providing after you messed something up or when they realized they’d like to give you more money.

There are various models for how to design your support structures but in most cases, it is unproductive to have e.g. your developers answering customer emails or complaints tweets. As much of support as possible should be either automated or enabled by simple self-service. You don’t want to have more tickets — you want the customer to get what they need, as quickly and as simply as possible. And you should probably capture the data about repeating incidents and requests, as this allows you to make relevant improvements to your products and services.

The Guiding Principles

This is a relatively new addition to ITIL and part of the ITIL Practitioner Guidance. The nine Guiding Principles create a kind of net of constraints around service management initiatives — they won’t tell you what to do or how to do it, but they do help you to check whether you’re on the right path. Although they were initially developed to show how some of the underlying key ideas of ITIL link to those in DevOps, Agile, and Lean, I’ve seen these resonate really well with non-ITSM professionals, too.

Here they are, in no particular order (although always ordered like this):

1. Focus on Value
2. Design for Experience
3. Start Where You Are
4. Work Holistically
5. Progress Iteratively
6. Observe Directly
7. Be Transparent
8. Collaborate
9. Keep It Simple

Whatever your idea is, when putting together the action plan and before execution, check whether you have thought about the relevance of all of these principles to what you’re about to do and what you want to achieve.

Wrapping up

I decided to limit the scope of this article to some of the higher-level ideas in ITIL, rather than going for the specifics of each of the 26 processes (not processes). Whether you’re thinking about product/service portfolio management or supplier management or event management, there could be information in ITIL that shows what others have been battling with before, and what worked (and didn’t work) for them. This could be useful when you’re trying to find your own ways of working and avoid repeating mistakes and/or reinventing the wheel.

Feel free to get in touch here or on Twitter with any questions or comments.