The Science Behind ITIL
# ITIL
What the Research Actually Says (and Where It Goes Quiet)
August 18, 2026
Farooq Hussain
The Science Behind ITIL: What the Research Actually Says (and Where It Goes Quiet)
Somewhere around year eight or nine of doing this job, I started getting suspicious of my own confidence. I'd tell a room full of stakeholders that a structured change process reduces risk, that mature incident management improves customer satisfaction, that ITIL "works," and I believed every word of it. But I'd never actually gone looking for the evidence behind those sentences. I'd absorbed them the way most of us do, from training material, from consultants, from repetition.
So a while back I went and read the actual academic literature on ITIL and ITSM, the peer-reviewed kind, not vendor white papers. Some of what I found backed up what I already believed. Some of it didn't, or at least not cleanly. I think that's worth talking about honestly, especially in a community built around a certification.
The closest thing to a definitive study
The most cited empirical work on this is a 2011 paper by Mauricio Marrone and Lutz Kolbe, published in Business and Information Systems Engineering, based on a survey of 491 firms internationally. It set out to answer something surprisingly basic: as organizations mature their ITIL implementation, does the perceived benefit actually go up, and does the perceived difficulty actually go down?
The answer, broadly, was yes. Companies further along in maturity reported more realized benefits and fewer perceived challenges than companies earlier in adoption. That sounds obvious in hindsight, but it hadn't been tested at that scale before, and it matters because it rules out a less comfortable alternative: that ITIL benefits are mostly a story organizations tell themselves regardless of how far they've actually implemented it. The data suggested the benefit tracks the maturity, not just the belief.
What the study didn't do, and doesn't claim to do, is prove causation in the strict sense. It's a survey of perception and self-reported process counts, not a controlled experiment. Correlation between maturity and benefit is not the same as proof that ITIL itself caused the improvement rather than, say, the kind of organization disciplined enough to mature its ITIL implementation in the first place also being disciplined enough to improve in other ways simultaneously.
Where the literature gets quieter
A systematic literature review on ITSM implementation research (the kind of paper that exists specifically to summarize what's been studied and, just as importantly, what hasn't) found that most existing research clusters around four areas: why organizations adopt ITSM in the first place, the critical success factors for implementation, how far along implementation typically gets, and the benefits realized. That's useful, but notice what's missing. There isn't a deep well of research directly comparing organizational outcomes, actual incident volumes, actual downtime, actual cost, between otherwise similar organizations with and without mature ITSM practices. Most of what exists is self-reported and cross-sectional, meaning it captures one point in time rather than tracking change over years.
I don't say this to undercut the framework I've built two decades of a career on. I say it because pretending the evidence is more settled than it is doesn't serve anyone, least of all people newer to the profession who deserve an honest picture of what's proven versus what's plausible and widely believed.
The one place the science is unusually solid
There's an exception, and it's the part of ITIL (Version 5) I find most interesting precisely because its intellectual roots are unusually well documented: Complexity Thinking, borrowed from the Cynefin framework.
Cynefin comes from a 2007 Harvard Business Review paper by David Snowden and Mary Boone, built explicitly on complexity science rather than the classical, cause-and-effect organizational theory most management frameworks quietly assume. Their argument, in short, is that leaders default to treating every situation as "complicated," meaning solvable with enough expert analysis, when a meaningful share of real situations are actually "complex," meaning cause and effect can only be understood in hindsight, not predicted in advance no matter how much analysis you throw at it. The paper went on to win a 2008 Academy of Management award and an Emerald Citation in 2011 for being among the fifty most-cited business articles across fifteen thousand candidates, which is a genuinely unusual level of academic traction for something that started as a practitioner framework.
What that means practically, and what I didn't appreciate until I'd lived it on a service desk floor, is that Cynefin isn't offering ITSM a management fad. It's offering a piece of actual complexity science, tested and cited well outside the ITSM world, applied to a domain that badly needed a way to name the situations its older categories couldn't hold.
Why this distinction matters more than it sounds like it should
I bring this up because I think our profession sometimes blurs two different kinds of claim together. "ITIL improves outcomes" is a claim resting on decent but not airtight survey evidence. "Some IT problems behave like complex systems and need to be handled differently than complicated ones" is a claim resting on a much more rigorously tested body of complexity science, one that happens to have been imported into ITIL rather than invented for it.
Knowing which kind of claim you're making changes how confidently you should say it out loud. When I tell my team that mature change management reduces risk, I'm leaning on reasonably solid but imperfect survey data, and I try to say so. When I tell them that our abandoned-call pattern needs to be treated as complex rather than complicated, I'm leaning on a body of science that's been independently tested well beyond our industry, and I can say that with more confidence.
This is also, in a smaller way, why I've spent time building my own KPI framework rather than relying purely on the standard scorecards our industry defaults to. If the published research on ITIL benefits is mostly cross-sectional and self-reported, then part of closing that gap has to happen at the practitioner level, by actually tracking outcome-linked metrics over time inside our own organizations rather than waiting for someone else's survey to catch up. I published that framework late last year specifically because I think our field needs more of that kind of practitioner-generated evidence, not less.
What I'd actually tell someone reading this
Believe in ITIL because you've tested pieces of it against your own operation and watched them hold up, not because the certification told you to. The research broadly supports that mature ITSM correlates with better outcomes, and the complexity science underneath the newest edition is genuinely solid. But "broadly supports" and "proves" are different words for a reason, and our profession is better served by practitioners who know the difference than by ones who don't.
I'd be glad to hear if others have come across research I've missed here, particularly anything more longitudinal than what I found. That's the gap I'd most like someone to fill.
References
Marrone, M., & Kolbe, L. M. (2011). Impact of IT service management frameworks on the IT organization: An empirical study on benefits, challenges, and processes. Business & Information Systems Engineering, 3(1), 5–18.
Snowden, D. J., & Boone, M. E. (2007). A leader's framework for decision making. Harvard Business Review, 85(11), 68–76.
Marrone, M., Gacenga, F., Cater-Steel, A., & Kolbe, L. (2014). IT service management: A cross-national study of ITIL adoption. Communications of the Association for Information Systems, 34, 865–892.
Sign in or Join the community
Where conversation, connection, and real-world practices come together.
Create an account
Where conversation, connection, and real-world practices come together.
6
Comments (0)
Popular
