By Gene Kim, Kevin Behr, and George Spafford
The short version: The Phoenix Project is to IT what the best of the Harvard Business Review cases are to a business. It’s fictionalized, it’s realistic, and it provides the best set of lessons on running a complex IT operations environment that I have seen anywhere. This should be required reading for senior-level IT leadership everywhere. If you’re prone to TL;DR, you can stop here!
For Parts Unlimited, the Phoenix Project is a make-or-break IT project for the company. It’s of course way behind schedule, over budget, and going live in two weeks no matter what. BIll, our protagonist, has just been promoted from Director of Midrange Technology to VP of IT Operations. He inherits a department that’s behind on many projects (ranging from make-or-break-the-company to irrelevant), an over-stretched team, broken or nonexistent processes, and some real bottlenecks.
With help from his mentor Erik (a potential board member and/or investor), Bill slowly starts to bring order to the chaos. There’s a painful initial triage to get Phoenix out the door, followed by a strong push towards process (starting with change management). Erik helps Bill learn what work is, how to manage work, and how to move IT from an impediment to the business to a key stakeholder and strategic partner. Erik uses a well-run factory to help Bill understand workflow — bottlenecks, the harm that re-work causes, Kanban, Kaizen, and the similarities between custom manufacturing and information technology.
Some of the crucial changes include:
- Truly understanding the four kinds of work that an IT organization does
- A simple, clear change management process, with regular CAB meetings
- A focus on removing the crucial bottleneck — in this case, a very talented system/network admin named Brent who has a great deal of knowledge but has written down very little
- Prioritization of projects — business-critical and preventative maintenance, and removing projects that don’t add value
- Limited work in progress, to ensure team effectiveness
- Cleaning up and standardizing processes, using what’s effectively a Kaizen Blitz on key bottlenecks
- Cultural and technological adoption of DevOps processed and tools
- A move from quarterly deploys to multiple deployments per day
The book itself is very accessible (you do NOT need a deep technical background to appreciate the lessons!), the characters have depth, and the story is coherent and flows well. Most readers will see pieces of themselves in the characters’ roles, personalities, and challenges. Kanban is called out by name and explained well; Kaizen is embedded deep into the story but is not mentioned by name.
The tools and techniques discussed do require some real leadership and willingness to be an agent of change, but they do not require expensive or complex tools, long ramp-ups, or enterprise software. All you need for a Kanban board is a wall and a pack of post-it notes, good change management is really about process, and brainstorming and bottleneck analysis really just need everybody in a room, talking around a whiteboard.
Clear the non-critical items from your book backlog, move the Phoenix project’s card to the “Reading” column on your literary Kanban board, and start thinking about actually managing work instead of having work manage your team, department, or business unit.
Have More Questions? Contact our team at Taos. We’d be happy to help.
Links:
http://www.methodsandtools.com/archive/archive.php?id=104 — An excellent description of Kanban
http://itrevolution.com/books/phoenix-project-devops-novel/ — The Phoenix Project