The Phoenix Project: Summary and Org Chart

I was looking for a good summary of The Phoenix Project and was unable to find one that wasn’t simply a list of DevOps methods and principles, so here you go. I also found it hard to follow the character’s roles within the organization, so I have included an org chart below.

The Phoenix Project is an allegorical tale of DevOps—the needs, the transition, and the business impact—as told through the main character, Bill Palmer, who has recently been named VP of IT Operations, much against his will.

DevOps is the application of Lean manufacturing methods, architecture, and ideology to the world of software development and operations. I like The Phoenix Project because my background is mostly *not* IT, so it was helpful to see the theories put into practice.

Here is the cast of the company in focus, Parts Unlimited:

The Phoenix Project Org Chart MD.png

It’s also worth noting that the cover gives each character an avatar (John and his 3 ring binder is my favorite):

The Phoenix Project Cover Labeled MD.png

In the book’s opening, Steve Masters, the excitable and persuasive 50-something CEO, promotes Bill Palmer to VP of IT Operations as Steve has just fired both of Bill’s bosses--the CIO and the VP of IT Operations. Steve explains that he himself will stand in as CIO for the time being.

Bill, a former Marine, liked his old job in Middleware and did not want to assume a position where the last three people to hold it only lasted for two years each before they “left the company” (were fired). Steve persuades Bill to take the role and explains that Parts Unlimited’s fate rests on the shoulders of an important IT project, project Phoenix, which is already late and over budget.

The board recruits a quirky IT hot shot, Erik Reid, to mentor Bill in cleaning up the IT organization. Erik uses visits to Parts Unlimited’s manufacturing facility to explain the value of Lean methods and draws parallels to IT operations.

Through Erik’s mentorship, Bill dives into learning “the three ways”, the “four kinds of work”, and learns why WIP is the quiet killer of both manufacturing and IT alike.

The Phoenix Project is relatable to people who may be new to IT because of the parallels between IT and operations based jobs. For example, in one scene symbols (think Wingdings font) have replaced social security numbers in the payroll data and in an attempt to scramble and fix the issue so that employees can get paid, the team ends of crashing some servers which only makes the problem worse. I think we have all been there.

All in all, the book is a pretty good read which will introduce, or bring to life, concepts that are laid out in my next blog post entitled “Theory to Practice: How to make the DevOps shift.”