The Phoenix Project

Time for a book review! The book is called: The Phoenix Project.

The Phoenix Projects follows in the footsteps of Eliyahu Goldratts “The Goal: A Process of Ongoing Improvement” and focuses on the best way to achieve project results in IT. Amazon has a nifty preview tool, which I included to give you a free preview, below:

The Phoenix Project: Synopsis & Review

The novel centers on Bill, the recently promoted VP of IT Operations as he tries to save his company, Parts Unlimited, from failure in a viciously competitive market. The CEO, Steve Masters, fired the previous VP of IT Operations and promoted Bill because he is a straight-shooter known for getting results – which they desperately need.

Parts Unlimited’s major software initiative, The Phoenix Project, is wickedly behind schedule and well over budget. Point blank: Our hero needs to save the project in order to save the company.

The novel’s characters and plot lines are essentially allegorical instruments used to teach us about IT DevOps. Despite the simplified story-telling, the lessons are incredibly valuable.

DevOps is broken into three core notions known as the Three Ways. They are as follows:

  1. Systems thinking: Emphasize the performance of the entire system, not the performance of the specific localities within the system
  2. Create, shorten, and amplify feedback loops.
  3. Continually experiment, take risks, fail, and learn

The First Way

There is a great quote from the book that states the idea behind The First Way simply, “Global goals outweigh local goals”. This means that we must think of our entire business as one, complete, system.

Our function in IT (Salesforce) is to improve entire system performance, not optimize just for specific departments. Necessarily this involves a deep understanding of “the system” that is our business and Salesforce application, which is one of the tenets of the first way.

This involves identifying and exploiting “the bottleneck”, which is the single biggest constraint on performance, in the system. This is the key resource that, if suddenly taken away, would bring everything grinding to a halt. It could be a person, process, resource, etc.

Once identified, we exploit the bottleneck by reducing the load on it as much as possible, ensuring the bottleneck never works on the same item twice, and then increasing the flow through the bottleneck.

The Second Way

Imagine a microphone on a stage with speakers located very closely nearby. If you turn the microphone on and put it near the speakers, you’ll hear that sound we all know so well. A loud, awful, screech. The sound heard by the microphone is played by the speaker, which is heard by the microphone and then played by the speaker, which the microphone hears and the speaker plays, until… forever!

Not actually forever but, the concept of feedback is the driving notion behind The Second Way. We want to use feedback loops in our work to our advantage. A feedback loop simply takes inputs and turns them into outputs. These outputs are then used as the new inputs. Repeat. Repeat. Repeat.

We want to do this as fast as possible to improve our processes. This includes taking in customer and internal employee complaints or feedback (in our example this would be noise from the speakers) and building the systems required to resolve those complaints and implement that feedback quickly.

We also need to build the means whereby we can collect feedback (in our example this is the microphone). Examples of this include customer NPS surveys, internal case resolution times, or data points on the number of errors our application is experiencing.

By collecting this feedback we can use it as knowledge to improve items we’ve already delivered or the methods we are using to deliver work.

The Third Way

The rate at which we succeed is directly related to the rate at which we experiment and fail. The Third Way embraces this reality.

The Third Way encourages us to invest in ourselves with daily learning, daily improvement of work processes, rewards us for calculated risk-taking, and encourages us to continually stress test our operations in order to find weaknesses in both our deliverables and how we deliver them.

The Phoenix Project: Conclusion

This book had a large effect on my thinking and was part of the inspiration for my How To Do Less Part One and How to Less Part Two posts.

In my time as a Salesforce administrator, I’ve definitely noticed a knowledge gap when it comes to effectively delivering projects – delivering value – on schedule in a systematic way. Sometimes it seems there’s no rhyme or reason to why we’re working on what we’re working on and I think part of the problem is rooted in an insufficient understanding of the best way to proceed.

It’s a difficult game we play, where we must respond rapidly and effectively to the needs of our business. Many times the requests for work that we receive have good intent, but the suggested implementation is faulty. This book gives a process on how to handle that scenario.

The book provides us a lens we can use to look at the entire gestalt of how we build out projects for our users, and clients, to make sure it’s being done in the best way possible. It does a great job of mapping certain manufacturing concepts – one example being “value stream” – onto how we work in IT.

I highly recommend reading the book. The story is amusing and the concepts are fresh. I’m continuing to learn more – up next on my reading list is: The DevOps Handbook: How to Create World-Class Agility, Reliability, and Security in Technology Organizations

Furthermore, this post, by the author of the book, is also a great primer on “The Three Ways” – if you’re curious to learn more.

Read the Phoenix Project!

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.