The Phoenix Project
Are you looking for a book that breaks apart from the mainstream content and one that provides a fresh change on how a management and leadership book is written? If you excitedly said “yes”, then this is the book for you.
When someone recommended this book to me to read, I was a little hesitant as I was looking
for a book to continue my learning mindset, currently focused on increasing my leadership knowledge and skills. This book was not a typical management or leadership book; one that is filled with facts, statistics, studies, etc. It was a fictional story. What kept my initial interest in reading it was my hope it was going to be as interesting, engaging, and informative.
To say the least, I was thoroughly engaged and took away numerous ideas and thoughts and
immediately incorporated several of the concepts into my daily routines, activities, and how I manage and lead.
I Power Ideas Warning: The following contains a glimpse into the book. For those of you who avoid spoilers at all costs – alert – read the book before reading the following. For those who can handle a preview and some takeaways, keep on reading.
The book contains fictional situations that will resonate and stick with you and you will find yourself reflecting back on, again and again. I found myself several times having “water cooler” conversations about the characters in the book which elicited lots of laughs and meaningful meanings at the same time.
You will really dislike Sarah and you will see the constraint of Brent within your own organization. Pay attention to Erik, he has some excellent insights. Ok, I have said too much – go get the book! (even the audio is excellent, I recommend it) So, if you have not already done so, read this book! You will not regret a single minute’s reading (or listening).
It is an easy read and thus a quick read. It left deep impressions on me and evoked several “ah-ha!” moments.
A few I Power Seeds based on The Phoenix Project
They took a lot of time to dig down into the root cause of a problem they experienced – they asked what was done that could have caused a significant outage. They could have come to the same conclusion if they had just asked what was done throughout the organization/business units. This does not always work, but many times it does. For example the authors offer a comparison to Occam’s Razor. Occam’s Razor is the problem-solving principle that essentially states that “simpler solutions are more likely to be correct than complex ones.” When presented with competing hypotheses to solve a problem, one should select the solution with the fewest assumptions.
The lack of most of the character’s positions of being proactive caused other issues (domino effect) with the company. They did not follow up on work in progress (WIP) or implemented changed from other business units (should have used systems thinking and the inter-dependencies), such as the possible hard drive failures on the SAN. This is a great example in the book and once you read it, you will be able to better recognize the same issues or inter-dependencies within your own work environment.
From the story, Erik explains there are 4 types of work. They appear to be common sense but they all play an important part.
1. Business Projects
These are business initiatives, of which most Development projects encompass. These typically reside in the Project Management Office, which tracks all the official projects in an organization.
2. Internal IT Projects
These include the infrastructure or IT Operations projects that business projects may create, as well as internally generated improvement projects (e.g., create new environment, automate deployment). Often these are not centrally tracked anywhere, instead residing with the budget owners (e.g., database manager, storage manager, distributed systems manager).
3. Changes
These are often generated from the previous two types of work and are typically tracked in a ticketing system (e.g., Remedy for IT Operations, JIRA, or an Agile planning tool for Development). The fact that two systems exist to track work for two different parts of the value stream can create problems, especially when hand-offs are required.
4. Unplanned Work or Recovery Work
These include operational incidents and problems, often caused by the previous types of work and always come at the expense of other planned work commitments.
Why Do We Need To Visualize IT Work And Control WIP?
From the book: “My favorite (and only) graph in The Phoenix Project shows wait time as a function of how busy a resource at a work center is. Erik used this to show why Brent’s simple thirty-minute changes were taking weeks to get completed. The reason, of course, is that as the bottleneck of all work, Brent is constantly at or above one hundred percent utilization, and therefore, anytime we required work from him, the work just languished in queue, never worked on without expediting or escalating.
Here’s what the graph shows: on the x-axis is the percent busy for a given resource at a work center, and on the y-axis is the approximate wait time (or maybe more precisely stated, the queue length). What the shape of the line shows is that, as resource utilization goes past eighty percent, wait time goes through the roof.”
One of the memorable concepts I took away was regarding constraints and work in progress (WIP). With constraints and too much WIP, you are not focused and thus it’s like chasing your tail. If you have so much WIP and you have no time in your schedule for unplanned work, then things will continually get put on the back burner and your backlog will only continue to grow. That is one of the powerful examples written in the book and once the characters finally identified the constraint(s) and resolved it, only then did the backlog begin to shrink. This is what the Japanese saw in production and found ways to keep the work in progress (WIP) while removing or bypassing the constraints.
Another example that is provided in the book is changing focus of programmers and how it wastes brain cycles to constantly refocus (context changes) and is considerably less productive and causes one to be more tired and fatigued. There are many recent studies I have read that strengthen this that multitasking is significantly less productive than just focusing on one thing and getting it done.
Another great point highlighted in the book is how to find ways to automate and deliver simpler chunks. We know that, for one example, this was key in the auto industry (Ford and Toyota). We also see it in the technology world with scripting and how it automates processes to be significantly more efficient. And smaller chunks or work is a Scrum concept and rather than a legacy process of waterfall development, smaller simpler projects (stories) are put into place making the go to production significantly faster, more efficient, and with consistent results.
There is so much more in the book. Get it, read it, learn from it, and implement its concepts. You will see results right away.
Leave comments and share your thoughts and ideas.
Synopsis from Amazon:
Bill, an IT manager at Parts Unlimited, has been tasked with taking on a project critical to the future of the business, code named Phoenix Project. But the project ismassively over budget and behind schedule. The CEO demands Bill must fix the mess in ninety days or else Bill’s entire department will be outsourced.
With the help of a prospective board member and his mysterious philosophy of The Three Ways, Bill starts to see that IT work has more in common with a manufacturing plant work than he ever imagined. With the clock ticking, Bill must organize work flow streamline interdepartmental communications, and effectively serve the other business functions at Parts Unlimited.
In a fast-paced and entertaining style, three luminaries of the DevOps movement deliver a story that anyone who works in IT will recognize. Readers will not only learn how to improve their own IT organizations, they’ll never view IT the same way again.
Buy the book on Amazon
