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.
  • Operations and development need to be integrated.
  • Limit work in progress.
  • Understand The 3 ways:
    • 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.
  • For IT there are 4 types of work:
    • Business projects
    • Internal projects
    • Operational changes
    • Unplanned work