The Framework Outlived the Manual

The ITIL manuals were heavy enough to prop open a door. That was the first thing you noticed about them—not the content, the mass. Shelves of binders, thousands of pages, prose so dense and circular you could read a section twice and come away less certain than when you started. I owned four of the processes those binders described. I can tell you what most of that paper was actually for.

It was for looking thorough.

Length reads as rigor. A framework that runs to thousands of pages looks like it has thought of everything, and a framework that looks like it has thought of everything is very hard to argue with. That was the problem. Not that ITIL was wrong—the ideas at its core were sound, and most of them still are. The problem was that its bulk made the sound part impossible to find, and impossible to question.

---

Scripture gets obeyed, not adapted

The conventional story about ITIL’s early years is a maturity curve. Organizations adopted it, implemented it clumsily, and got better with practice. Growing pains, since outgrown.

That story is wrong in a specific way. The early clumsiness was not immaturity. It was obedience, and whatever its authors intended, the framework’s scale and posture rewarded it.

ITIL began reasonably enough. At the end of the 1980s, the UK’s Central Computer and Telecommunications Agency set out to bring consistency to the way government organizations managed IT services, so that every department wasn’t reinventing the same practices badly. A sane goal. But the thing that grew out of it kept growing. By its second and third editions it had become a comprehensive body of doctrine—functions named, roles catalogued, interfaces between them specified.

Comprehensiveness has a psychology. When a framework presents itself as having anticipated everything, the rational response is not to adapt it. It is to comply with it. You do not redline scripture. You implement it as written, because the document’s whole posture tells you that any gap is your failing rather than its. The manuals were built in a register that quietly discouraged the exact judgment that would have made them useful. They invited the wrong kind of adoption, and then the industry spent years supplying it.

---

What compliance looked like on the floor

Compliance had a texture, and anyone who lived through it remembers it.

A change advisory board convened to approve a change that carried no meaningful risk, because the process said changes go to the board. Roles filled because the framework named the role, not because the work in front of anyone required a person in it. Approval chains standing between routine work and its completion. A responsibility matrix drawn up for a process every person in the room already understood—because the matrix was an expected artifact, and its absence would have been noticed where its presence never was.

That last one is the tell. The ceremony did not have to be useful to be mandatory.

I drew those matrices. I knew, drawing them, that the work would have moved without them. I drew them anyway, because the culture that had grown up around the framework expected the artifact, and producing the artifact was faster than explaining why it wasn’t needed. Set that against every process in every account and you have the real cost of literal ITIL. Not catastrophe—drag. Motion converted into paperwork. A system kept busy proving it was following the process, while the process slowed the work it existed to organize.

---

What one owner could actually author

Then somebody had to take the doctrine and turn it into something a team could actually run. In my case that somebody was me.

I was the process owner for Change, Release, Major Incident, and Problem, and for a stretch I ran the last two operationally as well. In practice that meant I was the person who read the doctrine, kept the small part of it that carried weight, and left the rest on the page.

What survived that translation was startlingly compact. A working Major Incident process is a definition sharp enough to separate a major incident from an ordinary one, a clear path for raising it, a short list of who gets pulled in and who gets told, and a discipline for closing it out and learning from it. That is close to the whole of it. The useful core of something the manual treated as a chapter fit comfortably on a handful of slides—and the sharpest move available was almost always subtraction. Stating plainly what the service would not do, so no one mistook its edges. Drawing the one distinction—this is a major incident, this is merely a severity-one, this is a crisis, and they are not the same thing—that a chapter of doctrine had somehow managed to blur.

The lesson arrived early and it was not subtle. The load-bearing part of an operational discipline is small enough that one person can hold it, own it, and write it down. Everything past that size is not rigor. It is padding with a process number.

---

The concepts, minus the ceremony

Walk into a competent operations organization today and the concepts are still there. Incidents get managed. Changes get controlled. Problems are distinguished from the incidents that expose them. Releases are staged rather than thrown over a wall. The vocabulary is intact and the disciplines are real.

What is gone is the apparatus. The binders. The exhaustive role catalogue. The governing assumption that there exists one correct and complete way to do this, and the job is to conform to it.

The framework’s own stewards eventually conceded the point. The 2019 edition set aside much of the prescriptive process machinery in favor of a smaller set of guiding principles—start where you are, keep it simple and practical—and an explicit instruction to adapt the framework rather than adopt it wholesale. Stated in the framework’s own late vocabulary, that is precisely what the operators quietly gutting the manuals had been doing for two decades. The official version spent twenty years catching up to the unofficial one. This is where it should have started.

It did not stay there. ITIL Version 5 followed, and with it the familiar machinery—fresh modules, fresh certifications, fresh volume to study and be examined on. That is worth watching without alarm, because it is the framework doing what frameworks do. The documentation regrows, because producing comprehensive documentation is the business the framework is in. What does not regrow, and does not need to, is the operator’s judgment about which part of any of it actually carries the service. That is the thing that settled. Not ITIL’s size—ITIL will expand and contract with every edition and every certification cycle. What settled is the discipline of telling the framework apart from the implementation, and keeping the second one in the hands of the people running the system.

---

Completeness was never correctness

There is a temptation to read this as a story about ITIL, and it isn’t. ITIL was one instance of a mistake that holds its shape across the frameworks that try to capture how work should be done. The mistake is believing that completeness is a form of correctness—that a document which has anticipated everything is safer than one that hasn’t, that the longer manual is the more responsible one.

The deeper cost isn’t the length. It’s what the length does. A document that promises to have anticipated every case invites the organization to believe judgment is no longer required—that the answer must already be in the book, and the job is to find the right page rather than to think. Completeness transfers judgment from the operator to the document. That is the transaction, and it is a bad one, because the document cannot actually do the deciding. It only convinces everyone that the deciding has been handled.

The manuals were long because length was reassuring, not because the work demanded it. Every page past the load-bearing core was insulation—something to point to, something that made the framework hard to argue with. None of that paper ever made a single incident resolve faster. It only made the framework look like it might.

The useful part of any discipline is small enough to fit in the head of the person who actually does the work. That was true of ITIL the entire time. It took the industry the better part of two decades, and an enormous volume of paper, to arrive at a conclusion the people running the systems could have written on a whiteboard—and mostly did.

The rest was trees.