≡ Menu

Book Review: The Phoenix Project

In my most recent class on improving the throughput and reliability of IT project portfolios, one astute class participant noticed the similarities between many of my techniques, and those she was being introduced to in a book she was reading. The book, which had escaped my notice, is The Phoenix Project: A Novel about IT, DevOps, and Helping Your Business Win, by Gene Kim, Kevin Behr, and George Spafford, published January of last year. I just finished this book, and found a whole lot to like…but also found a few puzzling blind spots. Overall, I highly recommend it—here’s my rundown:

1) Excellent storytelling. The characters are authentic, and their challenges and dilemmas are highly relevant to today’s IT environment. Even better, the way in which the authors weave in their harmonious mix of solutions shows how your average earnest, competent, and moderately brave IT professional can do so, too.

2) Integrates powerful concepts from Theory of Constraints (TOC) and Lean very effectively, with masterful examples showing where manufacturing and IT processes are highly analogous. The best example of this is the identification of “Brent” as the super-developer, who is also the system bottleneck (constraint).  The story introduces the reader to an effective mix of Lean/Kanban techniques used to get the most out of Brent, to subordinate other company resources to further exploit him, and to improve other aspects of the flow of IT work to “elevate” Brent for the benefit of overall organizational performance.

3) Provides an excellent reference point for how business leaders should view IT as a strategic asset that has the power to strengthen all key performance indicators, as opposed to viewing it as a cost center or “necessary evil.” In the same breath, the story addresses the issue of when not to devote strategic IT resources, such as when the cafeteria POS system was wisely outsourced.

4) I was surprised at the omission of TOC’s most impactful solution for project-centric environments:  Critical Chain Project Management (CCPM). While the authors do make reference to Drum-Buffer-Rope (DBR), a closely related TOC solution that properly focuses attention on Brent as the system constraint, CCPM offers additional performance-enhancing benefits designed for multi-project environments like the one in the book. For example, CCPM not only identifies the project portfolio resource constraint (Brent), but also shows what capacity for project throughput the organization has, identifies specific project due dates that can be committed to with high reliability, and provides a project-prioritization “what-if'” capability that allows executives to see the impact on due dates of re-prioritizing and re-sequencing projects. If I were Bill (VP of IT and lead protagonist), I’d be pretty interested in at least hearing about those high-value capabilities…I’d also question Erik (the TOC/Lean guru) about why he chose to avoid even mentioning CCPM (“You keeping the best solution techniques for yourself, Erik?”). All I can figure is that the authors may have feared introducing more techniques than readers might be ready to handle…but they did such a good job highlighting the common-sense underpinnings of TOC, DBR, and Lean/Kanban techniques, why be afraid of doing the same for CCPM?

5) The story makes reference to Agile/Scrum techniques that many leading Agile practitioners have begun to abandon, in favor of many of the same Lean techniques that the authors apply so effectively elsewhere. The best example of this is the story’s reliance on “sprints,” or artificially time-boxed sets of tasks that are batched together. To the authors’ credit, they do focus on some batch-size reduction when shrinking sprints from 3 weeks to 1 week, but why not go all the way, and just manage a continuous, single-piece flow of developer tasks, doing away with sprints altogether? When they introduced the section encouraging 10 software deployments per day, I was sure this was where they were headed, but somehow the “task batching” (sprints) survived.

In the end, I think this book is a useful and engaging read for any IT manager or executive challenged with improving the performance and relevance of IT to their organization, but this is especially the case for IT operations managers, given the book’s emphasis on IT operations that are most like manufacturing processes. If CCPM and more evolved Agile techniques had also been offered to help execute the portfolio of projects with unmatched throughput and reliability, this would have evened things out nicely—after all, a big problem that many IT organizations face is how to balance project work with operations work, while managing the unpredictable aspects of both. Adding CCPM to the mix of DBR, Lean/Kanban, and Agile could have accomplished this in an even more comprehensive and practical way…perhaps in the sequel?

Pending the arrival of such a sequel, if you’re interested in a business novel that takes a similar problem/solution approach to overcoming similarly daunting circumstances, check out The Project Manifesto: Transforming Your Life and Work with Critical Chain Values, by Robert C. Newbold and Bill Lynch. It came out just this past March, and is simply the best CCPM novel I’ve had the pleasure of reading (review forthcoming!). Once you get through both The Phoenix Project and The Project Manifesto, you’ll have an even higher-powered arsenal for dramatically improving the performance of your project portfolios and your IT operations.

Special thanks to Roberta for suggesting The Phoenix Project—much appreciated!

0 comments… add one