Book Review: The Phoenix Project

The Phoenix Project: A Novel About IT, DevOps, and Helping Your Business Win

by Gene Kim, Kevin Behr, and George Spafford
Publisher: IT Revolution Press; 1st edition
ISBN: 0988262592
Number of Pages: 345
Date Published: 1/10/2013


Let me first say that it is incredible how many different lessons are packed into Gene Kim's latest book, “The Phoenix Project: A Novel About IT, DevOps, and Helping Your Business Win.”  It was a really quick read because the story line was so easy to follow. (Hey, where are the hidden cameras in my office anyway?  I actually know all the characters in this story.)  But I've spent a few extra days going back over the parts of the book where the real instruction is interleaved into the plot.

The Phoenix Project combines the teaching of the several "management / improvement" genre books such as:

• Eliyahu M. Goldratt's "The Goal" which teaches the Theory of Constraints (ToC),
• Patrick Lencioni's "Five Dysfunctions of a Team",
• David J. Anderson's use of kanban boards to control the release of work and Work in Progress (WIP) for Development and IT Operations,
• Mike Rother's “Toyota Kata: Managing People for Improvement, Adaptiveness and Superior Results”,
• As well as TPM / LEAN strategies and many others...
• And last by not least, Kevin Behr, George Spafford and Gene Kim's previous research in Visible Ops Handbooks.

The narrative tells the story of Bill who reluctantly gets promoted to VP of IT at Parts Unlimited, an automotive parts manufacturing and retail company, after his previous boss and boss's boss get canned due to poor performance.  Bill inherits all of the typical problems that come with an overworked, dysfunctional IT team that is so busy fighting fires, that they don't have time to look at the long view of their situation.  And as if that weren't enough, the whole company is on a death march to deploy their latest home grown system, "Phoenix" that was intended to save the company's poor performance and lack of profitability for the past several quarters.

Sprinkled throughout the novel, the themes from the Visible Ops Handbook are intertwined as Bill takes measures to implement a new Change Management process, identify critical systems and get his team out of the fire fighting business and into something that resembles productivity.

The Four Steps From Visible Ops:

1. Stabilize the Patient
2. Catch & Release and Find Fragile Artifacts
3. Establish Repeatable Build Library
4. Enable Continuous Improvement

Bill has some good ideas and starts to make some progress for his team, but it is obvious that there is more work piled on Bill's team than they have cycles to work on.  Bill quickly realizes that one of his key resources, Brent, is the bottleneck that is holding up a lot of work from getting done as well as a silo of critical knowledge for managing and maintaining his systems.  Using the techniques from Goldratt's ToC, Bill instinctively starts to put some processes in place to manage work getting assigned to Brent.

Things really start to get interesting for Bill when he meets a potential new board member named Erik Reid, who turns out to have worked with Part
Unlimited years ago to help solve a crisis at their manufacturing plant by implementing what sound remarkably like the same solutions recommended by Jonah in "The Goal".  Erik befriends Bill and takes on the role of mentor with the same Socratic approach to helping Bill find a way to fix all the troubles he is having.  Erik first introduces Bill to "The Three Ways" in Chapter 7, page 91.

• "The First Way helps us understand how to create fast flow of work as it moves from Development into IT Operations..."
• "The Second Way shows us how to shorten and amplify feedback loops..."
• "The Third Way shows us how to create a culture that simultaneously fosters experimentation, learning from failure, and understanding that repetition and practice are the prerequisites to mastery."

Erik's first assignment for Bill is to identify the four types of work that he manages.  By the time Bill gets around to taking Erik seriously (and for a raving mad man), it is already chapter 15, page 160, and the wheels are really starting to fall off at Parts Unlimited.  There have been outages to the POS systems and a "small credit card breach".  Bill gets the first assignment right recognizing that the four categories of work are:

1. Business Projects
2. Internal IT Projects
3. Implementing Changes
4. Unplanned Work

Bill and Erik discuss other progress that Bill's team has made with trying to simplify the input of change requests into the change management process, the use of kanban boards in the CAB meetings, and the first step in ToC identifying Brent as the constraint.  Bill's next assignments are to figure out how to take needless work out of the system as much as it is to control WIP already in the system, and further define how to control the flow of work to Brent.

The Five Steps From The Theory of Constraints:

1. Identify the constraint (the resource or policy that prevents the organization from obtaining more of the goal)
2. Determine how to exploit the constraint (get the most capacity out of the constrained process)
3. Subordinate all other processes to above decision (align the whole system or organization to support the decision made above)
4. Elevate the constraint (make other major changes needed to break the constraint)
5. If, as a result of these steps, the constraint has moved, return to Step 1. Don't let inertia become the constraint.

Despite all of Bill's progress, he is quickly falling out of favor with his new boss, CEO Steve.  After another major outage and some harsh words, the two finally make up and get the team back together to figure out how to actually fix the problems that the company has created for itself.  Erik helps Bill convince Steve to institute a project freeze to free up resources to work on the critical Phoenix project, which they are banking is the only hope to save the company from going under.

By Chapter 20, page 208, Erik and Bill are discussing WIP again and defining what a work center is... "every work center is made up of four things: the machine, the man, the method and the measures."  Having personnel assigned to too many work centers is so ineffecient and is the crux of Brent being the constraint to so many projects.  Erik introduces an interesting concept on page 213 showing that the wait time for any piece of work can be calculated by dividing the percentage that a resource is busy by the percentage that resource is idle.  "When a resource is ninety-nine percent utilized, you have to wait ninety-nine times as long as if that resource is fifty percent utilized." 

Another interesting character in the story is John, the CISO.  John is a fanatic about security, but in typical Infosec fashion runs around barking out orders that he claims are mandated by some policy or regulation or auditor.  In Chapter 22, Erik finally puts John in his place by showing that none of the controls that he has attempted to put in place have any impact on the business' ability to manage risk.  After that John disappears for several weeks.  And finally re-emerges as a changed man ready to finally look IT through the lens of the business' priorities.

Once Bill and John realize what the business' metrics for success are, they come to a hard realization that the Phoenix project will never fulfill the needs of the business in the project's current form.  Bill puts together a proposal to build a SWAT team that will work in parallel with the Phoenix project but with permission to break all of the rules in order to help the business make its numbers.  The new processes that emerge from this SWAT team are the fundamentals of #DevOps.

Like I mentioned earlier, the book is phenomenal, extremely well written and easy to follow. [Spoiler Alert] Of course everything works out by the end of this fictional tale, but most of the lessons really do work in real life... IF

Now here's where the story becomes somewhat of a fantasy apart from real life.  In several of the situations I have been in or seen unfold in the past, senior management hasn't been willing to really look in the mirror and recognize that they don't really understand technology.  And if they are having trouble understanding it then they are really going to have trouble managing it.  Some of this stuff should be basic project management 101.  It always amazes me how many project managers and senior management figures at some companies measure success by completing a project on time, and slightly over budget.  But they don't analyze the success of the project in terms of actual return on effort to the business (maybe because they don't want to admit their pet project didn't achieve the objectives they claimed it would).

Not everyone in the IT world gets a personal Jonah or Erik to guide them through the murky waters of IT management and give credibility to the ideas and initiatives that you want to champion.  If you find yourself with a team to manage, hopefully this book along with some of the other resources mentioned can strengthen your decision making abilities to help your team and your company to succeed in this crazy new world of #DevOps.

One other thing to note is that the artwork on the cover of the book is pretty cool!