I am teaching entry-level IT students at a Masters' level that ITIL and PMBOK (more generally, IT service management and project management) are often unnecessary and sometimes harmful. I have incorporated these perspectives into my survey text for digital management.
It's easy to find criticism of these delivery models, especially from Agile folks, but this criticism is often emotional and anecdotal and not helpful in terms of teaching. There is a legitimate question of "are we throwing out the baby with the bathwater"? The real question with these frameworks is, why do they exist? What are they trying to achieve? If we don't understand that, we'll continue struggling with these debates in the digital industry.
The first thing to understand with both IT service management and project management is that they are combinations of more fundamental practices and concerns:
Project management today serves both a role of investment management and coordination/execution. It has, through a sort of "sleight of hand," combined these two objectives into often-unquestioned assumptions: that we manage investments through tracking their execution against a plan, and the planned deliverables are a good proxy for value. The trouble is that project managers are trained to deliver deliverables, not value. That's why companies like Target are discarding project management in favor of product management. It's essentially "cutting out the middleperson." Fund ongoing teams with continuously re-prioritized backlogs... and you realize you don't need PM any more (or at least, not as much).
IT service management is often seen as primarily process management (that is how most experience it). But there are also elements of product management. And process management itself is a combination of more fundamental operational concerns such as sequencing, cadence, synchronization, repeatability, variability, and even lower level concepts. My biggest concern with ITIL is as a comprehensive attempt at an operating model. Tickets, artifacts and work packages are bounced around amongst functional specialists, implying unworkable queuing and execution -- I've seen it tried. (This does not mean that Change and Incident processes are useless!)
Because they are combinations of more fundamental concerns, I did not give either project management or service management a chapter in the textbook. Instead, I chose to write chapters on:
- Product management (including service experience and positioning)
- Work management (assuming single team, includes Kanban, Lean IT and process fundamentals including checklists & case management)
- Operations management (including essential core ITSM processes)
- Coordination (multiple teams problem, and process management as operating model)
- Investment management (multiple products; also IT finance & sourcing)
These chapters represent a re-factoring of the traditional "build it with PMBOK and run it with ITIL" approach, which is now breaking down as delivery cycles accelerate.
As I broke out of the project and service management frames I realized there was useful research that I'd previously overlooked. In particular I give Troy Magennis credit for leading me to Diane Strode's work on the coordination problem in general; I relied heavily on her insights for my Chapter 7. By viewing coordination as a general problem, we can break out of dogma like process and project management. They are not necessarily wrong, but there are other ways to solve the problem of dependencies. Recently, I've been experimenting with 3-dimensional spaces, for example proposing Diane Strodey's work as as a 3d cube.
So, is there any room left for ITIL and PMBOK? Rather than throwing them out, I think we need a new approach that transcends them. Process management can be understood as a particular coordination strategy, appropriate when synchronization can be delayed, using artifacts (tickets) as a form of boundary-spanning (in Strode's terms). It's a pattern. Project management still may be appropriate for large-grained, one-time, lower-variability work; the example I use is a retailer upgrading the RAM in 80,000 POS devices across 50 states.
More details and references in the book.
