Book review: The Phoenix Project

This book is about IT project management, but unlike most management books, instead of being a series of case studies, it is written like a novel. The main character, Bill, is suddenly promoted from head of middleware technology to CTO at a time when the company, Parts limited, is failing apart at the seems.

What I found most surprising was that the book actually worked as a novel. I found myself genuinely caring about Bill and people he worked with and getting sucked in to the drama of delivering the project.

Also for a book about IT project management it’s amazing what a page turner it is. Especially in the early sections of the book where everything is going wrong. I found myself wondering how I would deal with his different problems which made me really wish there was a deathtrap dungeon style “choose your own adventure” book based around IT project management:

Your CEO is demanding you release the project at the pre-agreed date though you have major worries that it will not scale in production, do you:

Accept his demands release the change: turn to page 72

Refuse to do the release: turn to page 143

Maybe one day…

As a developer I also found it interesting learning how other aspects of the IT organization work. There is quite a lot of details on what a CIO, CEO and head of sales actually do.

Also though I’m sure the transformations they make in the book are possible, many companies have successfully made it, I found the time scale for these changes a little improbable and it seemed too easy to get buy in from people who were initially so sceptical.

Things to take away from the book

In order to mange anything you need to know what work is actually happening.

If you have a constraint on any system improving anything but that constraint is not actually going to make things better. In the book a single operations guy is the constraint for half the IT organization.

IT should be integrated into all aspects of an organization not seen as an external department in itself.

Systems thinking: The flow of work from business requirements through development and ops to the customer.

Amplify feedback loops: Make sure issues found in any part of the process are fed back to where they can be fixed. If ops had a problem it may have started with dev. If dev had a problem maybe it needs to go back to the requirements.

Culture of continual experimentation and learning: Take the time to improve things, it will be worth it.