"You should have paid attention in ITIL class, Bill!"

I just finished reading "The Phoenix Project ," a book by Gene Kim, Kevin Behr and George Spafford. I give it two thumbs up for drama and realism; I honestly could not put it down, and finished it in less than 24 hours, not counting the hours when I dozed off during the flight from San Francisco to Los Angeles and on to Boston.
Given that I've been in IT for some 39 years, one would think that the book would have generated flashback after flashback of many a harrowing day, chasing the tail of the dragon, and leaving nothing but cinders along the way… but it was nothing of the sort. The story did give me plenty of flashbacks, but rather to my years as an ITIL trainer, trying to instill an understanding of best practices in IT Service Management to over 5,000 students all over the world, all of whom remember me as the Crazy Puerto Rican -- for better or worse. If there's a common theme in this book, it should be this:

Throughout the entire book, I kept wanting to step into the story and ask Bill why in the world was he choosing to ignore the entire point of attending a class about best practices in IT service management. Instead, he seemed hell-bent on making every single mistake IT organizations make simply because they don't know there are best practices.
I know what some of you are going to say… DevOps is everything that ITIL is not, and ITIL just slows everything down…
Nothing could be further from the truth. For one thing DevOps is not fast or slow -- it's about trust . It's about the Dev side of the house earning the trust of the Ops side of the house so they are able to work together, rather than constantly be at odds with each other.

20Because the Dev side produces only 20 of the value that a service creates for its internal or external customers. That 20 is the functionality, or what the application does. In ITIL, we call that the "utility" of the service.
80The other 80 of the value of the service that ITIL calls "warranty" is created solely by Ops , and is composed of the availability, capacity, continuity and security of the service that must be implemented and maintained long after the deployment is finished and Dev moves on to their next sprint. This 80 is what ensures the service will be usable according to the customer's needs, and will continue to be usable throughout its entire lifecycle.
Then again, if DevOps is not about fast or slow, then what is? That's where Agile comes into the picture. Processes designed with guidance from ITIL best practices are not slow because of the best practice recommendations -- they are slow because the people who design and operate them are running them into the ground. ITIL doesn't say anything about what project management methodology to use. It just says that you will need one if you want to be able to herd the cats, and that it needs to align to the needs of your organization. For some, that will be Agile. For others it will be Waterfall, Scrum, PMBOK®, PRINCE2®, Six Sigma, RUP or any of many other options. And you can bet your bottom dollar that it is just as easy to screw up your processes with Agile as it is with ITIL.
Can DevOps replace ITIL as an ITSM framework ? Absolutely not! In reality, DevOps can be neatly inserted into the portion of the ITIL framework between the Service Design and Service Transition lifecycle stages. No service that requires software should ever have any development work done without a design, right? And what was the biggest challenge for Bill and his team to manage? It was Change , the process that is - and should be - the heart of all transition in IT.
Now, I want to go through the problems that Parts Unlimited had in the book, and the way that they went about discovering solutions. I will cross-reference the issues they encountered to the ITIL framework, so that you may understand why Bill and his staff should have paid more attention in that ITIL training.

ITIL is referred to as a framework, not a methodology, because it does not have enough detail to be implemented. It is essentially a pharmacy, where people go when they have pain and want to find some way to mitigate that pain. Everything in ITIL is suggestions, not set-in-stone rules, primarily because what is most important is the satisfaction of the customer, not the books. However, the suggestions come from the best minds in managing IT services, so it may be worth while to pay attention.
The ITIL framework is divided into five stages:

1. Service Strategy

2. Service Design

3. Service Transition

4. Service Operation

5. Continuous Service Improvement - an overarching stage that applies to all of the first four.

However, majority of organizations only turn to best practices when all options have been exhausted, which usually happens in the phase where the consequences from bad decisions in the previous ones most become evident, and cause the majority of customer complaints: Service Operation.

While Parts Unlimited's CEO's major pain was the tardiness of the Phoenix Project, a major portion of that was associated with problems in operations , and the constant firefighting that was required just to keep the lights on. Right off the bat, the payroll system blows up. One would think that such an issue would be easy to avoid, but the problem in operations was caused by a lack of process in several key areas: Change Management (=Service Transition), Incident Management and Problem Management (=Service Operation).

• The reason Change Management failed is that it was viewed as extremely bureaucratic, and someone decided to go around it and implement an untested change that damaged the payroll system at a critical point in time.

• Problem Managemen t failed because of not having an effective and efficient process to identify root cause, a temporary workaround if available, and a solution that would prevent a minor incident from blowing up to a major disaster.

• To add insult to injury, their Incident Management process didn't even have an appropriate business-focused incident prioritization scheme!

• And then there's Brent: there's a recurring theme all through the book regarding the utilization of a resource by the name of "Brent." There is a function in Service Operation, Technical Management, which specifically talks about utilization of staff with technical skills that are in high demand, or which are of high value to the IT organization. Had Bill checked out the guidance for a strategy on how best to utilize a resource like Brent, he would have saved himself a huge amount of grief.

• The next chapter introduces us to John, the IT security person at Parts Unlimited. Now there's a character for you; a person so focused in the decorations in his little cave that he has no clue what is really going on around him. This person has become so obsessed with his little world that he thinks he can goosestep around the company intimidating IT employees into making unannounced changes to the infrastructure… just because. Of course, the lack of a Change Management process (or in reality, the failure of a very bureaucratic process implemented by someone who had no idea how to do that) is what gave John free rein. The problem John had trouble understanding is that he was not considering security from a holistic point of view, and did not understand that the organization already had controls in place that caused many of his measures to be completely unnecessary, as he found out at the end of the audit. This type of risk management analysis is a key function of the Information Security Management process in the Service Design stage of ITIL. In addition, his actions were not aligned with the needs and pain points of senior management, something that he did not realize until after his major mental malfunction.

The good news is that by page 45 we finally start to see a glimmer of understanding of one of the deeper root causes of what's happening at Parts Unlimited -- a disconnect between the work IT thinks is important and what is truly important to the business, otherwise known as their customer. Put bluntly, IT strategy is not aligned to the Business Strategy, because they are missing something in ITIL without which such alignment is literally impossible: Business Relationship Management , which is part of the much earlier Service Strategy phase.
I'll pause here to point out something that is very common in IT Service Management. I've mentioned that organizations usually come to ITIL in response to pain, and that that pain usually comes from operations. But I've also said that the pain in operations is but a symptom of deeper problems. What happens during the book is very, very common in the process of adopting and adapting ITIL best practices -- the order of implementation flows opposite to the order of the lifecycle in order to first stabilize the patient and then deal with what's causing the symptoms.

This is also a good place to talk about the place of Dev in ITIL's worldview; it doesn't exist.
Surprised? Some think that's the reason why Dev should ignore ITIL altogether, and that is a terrible mistake. Dev used to be very much part of ITIL as of version 2.0 of the guidance. There used to be an orange book published as part of the framework entitled "Application Management." However, the architects behind the ITIL framework made a very wise decision when plans were made to publish the version 2007 edition. At that time, Application Management was deprecated from an entire book to a mere twelve pages in Service Operation's guidance.
I don't doubt that the decision incensed many application developers, who often consider themselves to be the most important component of IT! (Refer to the 20 value section at the beginning.) Nevertheless, the decision was a wise one, because it stems from the realization that Dev has its own frameworks, methodologies and processes (for better or for worse) and ITIL should not be trying to tell Dev what to do. It should instead be limiting itself to providing guidance for the activities with which Dev must interact in order to avoid disrupting the services that are being provided to the customer.
The reduced Application Management section, though, is a function rather than a process, and provides guidance on how Dev should provide support and other services in order to maintain applications in a state where they can provide the value the customer needs. ITIL also makes it clear that Dev must be an active participant in the testing of services that an application will be part of, and can't just throw things over the wall and forget about it, like the Dev group at Parts Unlimited was thinking it could do. In this, ITIL very much supports the concept of DevOps and close cooperation.

Right about this time, on page 54, we run into another major problem, what we in the ITIL world refer to as a showstopper risk -- lack of senior management support. This presents itself as an interpersonal issue between Steve, the CEO, and Sarah, the conniving head of marketing, who is much more interested in her career than in the company, and is essentially trying to manipulate the CEO out of the job in the hopes that the Chairman will give her the top position when projects fail and the company is split in two.
Good ITSM consultants know two things about this; these issues need to be flushed out as part of any process improvement initiative, and there must be a plan to deal with the risks. Most of them focus around communications, but interpersonal relationships are up there on the list as well. That's why the practice of Business Relationship Management has the word "relationship" right in the middle of everything.
Then there's Erik, the mysterious, quirky and eccentric ex-military officer who turned around the manufacturing processes of Parts Unlimited and is now trying hard to mentor Bill, in his own weird, cryptic way. Essentially, he is trying to get Bill to understand that Ops needs to be run just like the manufacturing floor. Resources must be managed, bottlenecks need to be identified and dealt with, and innovation embraced before the competition makes a smoking hole out of your strategy.

"In business, the term ‘Operations Management ’ is used to mean the department, group or team of people responsible for performing the organization’s day-to-day operational activities – such as running the production line in a manufacturing environment or managing the distribution centers and fleet movements within a logistics organization."
Maybe now you understand why I, as an ITIL and ITSM practitioner, trainer, assessor and examiner, kept getting blindsided by all these flashbacks as I read The Phoenix Project.
To make a long story short, by the time we get to the end of the book we have finally arrived at the beginning of ITIL's service lifecycle, and a born-again John who has now morphed into the perfect business relationship manager, quite capable of understanding the true business goals and strategy and helping to align the IT strategy to it with pinpoint accuracy. An Agile methodology has been adopted in both Dev and Ops, blended with adoption and adaptation of ITIL best practices in a practical manner, rather than in the follow-the-book manner that never works because the guidance was never intended to be used that way.
My advice to you DevOps devotees is to remember that the wheel was not reinvented in 2013 . ITIL was not invented in 1989 either -- it comes from a methodology known as GITMM (yes, it's pronounced like that) and it means "Government Information Technology Management Methodology." Instead of pretending that the past always leads to the wrong path, I recommend you embrace it, because the truth is that the saying that "There is nothing new under the sun" is in fact very, very true.
ITIL® and PRINCE2® are registered trade marks of AXELOS Limited. PMBOK® is a registered trademark of the Project Management Institute, Inc.
* Image credit: Sakena , Getting smarter #itil