We’re living in the Digital Age, and Information Technology (IT) is crucial to any organization. Yet, in many companies, there’s a dysfunctional relationship between IT and other business functions. Using a novel, the authors illustrate the complex processes, interlinkages and dynamics involving IT. They also explain how leaders can leverage IT to create a real competitive advantage. In this free version of The Phoenix Project summary, we’ll outline the key points in the book.
More specifically, we’ll give a short synopsis of the novel following by some of the key principles and insights for using IT to win. These ideas are useful not only for IT professionals, but for any manager, business owner or leader who wants to leverage IT effectively in their businesses. The insights are especially relevant for large organizations. Do get our complete book summary to see the ideas below come to life in the story, and get additional details/tips for real-life application.
The Phoenix Project: Novel Synopsis
The story is centered around Parts Unlimited, a fictitious automotive parts manufacturer that’s lagging behind its competitors and suffering from declining profits and share prices. The lead character, Bill Palmer, had just been promoted to the Vice President of IT Operations, after the former VP and Chief Information Officer were asked to leave. Bill reluctantly took on the role, only to find himself besieged by endless problems and seemingly-impossible goals.
With the help of Dr. Erik Reid, a potential board member and tech hotshot, Bill gradually turned the situation around. The story followed Bill’s journey as he uncovered how to (i) apply process-engineering concepts to IT Ops, and (ii) deliver real business value through IT capability. Other key characters in the novel include:
- Steve Masters: Chief Executive Officer (CEO)
- Sarah Moulton: Senior VP of Retail Operations
- Chris Allers: VP of Application Development
- John Pesche: Chief Information Security Officer (CISO)
- Key members on Bill’s team including:
– Wes Davis: Director of Distributed Technology Operations
– Patty McKee: Director of IT Service Support
– Brent Geller: Lead engineer
The Phoenix project was supposed to help Parts Unlimited to catch up with its competitors, but it was way over budget and schedule after $20mil and 3 years of development. Bill’s top priority was to ensure that the existing IT systems operated reliably, so the team could focus on the successful deployment of Phoenix in a few weeks. He soon realized how impossible this goal was. In our complete version of The Phoenix Project summary, we’ll illustrate how the various factors below—from office politics to communication issues, silos, lack of discipline and rigorous process, firefighting and regular IT outages, conflicting goals/priorities—all come together to trap Parts Unlimited in an IT “spiral of death”.
In our full Phoenix Project summary, we’ll see exactly how Bill was stuck in the vicious cycle of severe IT outages, lack of proper change management and ticketing processes, lack of support and resources to do so. We’ll also see the conflicts (i) within IT functions such as Development vs Operations vs Information Security, (ii) between IT and other business functions such as Finance, Marketing, Sales, and Retail Ops, and (iii) the dilemmas faced by the CEO.
So, how did Bill manage to turn around the seemingly-impossible situation, and gradually get things under control? Let’s take a quick look below at the key concepts and principles covered in the book, and how the team applied them to transform Parts Unlimited.
Maximizing Value from Information Technology (IT)
It’s a myth that IT work is too complex to be standardized like factory operations. In fact, because of its complexity, IT work requires even more rigor and discipline.
The key is to focus on the value stream, or how value flows through the production process. In the context of IT, it’s crucial to look at the entire DevOps (Development + IT Operations) Value Flow. Many of these concepts are now used in Lean or Agile methods.
In the book, many powerful concepts and frameworks are illustrated in the story, but the authors don’t explicitly lay them out. We’ve distilled and organized the key principles and ideas below in our full version of The Phoenix Project summary. Here’s a quick overview:
THE 4 TYPES OF IT WORK
There are actually 4 types of IT work:
- Business projects generate revenue or strategic value for the company, e.g. new software/features that add value to customers.
- Internal projects help internal customers in the organization to become more efficient and productive, e.g. maintaining/upgrading existing systems, or adding new security patches.
- Scheduled changes are required to stabilize and improve the original output from the 2 categories above, e.g. fixing bugs, updating versions, or refining the features.
- Unplanned work (or firefighting) is the most dangerous type of work, because it disrupts all 3 types of planned work above. Any resource spent on unplanned work (e.g. environment outage or database failure) means that the resource is not being used for other priorities. Firefighting also leaves you with no time/energy for planned work (nor to plan your work). This leads to more problems and more unplanned work in a vicious downward spiral.
If you’re caught in the IT spiral of death, the first step to regaining control is to (i) take stock of your true capacity and constraints, and (ii) eliminate as much unplanned work as possible.
THE THEORY OF CONSTRAINTS
The Theory of Constraints is explained in The Goal by Eliyahu Goldratt. It says there there’s no point in improving parts of the production line without first addressing the bottleneck.
In our full 14-page summary, we’ll break down how you can apply the theory to your IT factory to maximize your DevOps Value Flow. This includes:
- Visualizing your work flow and work centers for various types of IT projects.
- Identifying your biggest bottlenecks, optimizing it, and allowing the constraint to drive your pace of work.
- Minimizing work-in-process (WIP). WIP code is useless. It only has value when it’s being tested and deployed. To reduce WIP and maximize throughput, you’ll need to reduce batch sizes, minimize backflow, build in buffers (to reduce wait time between work stations).
Through the details in the novel/summary, you’ll be able to see how manufacturing concepts can be applied to complex/intangible IT processes, and get concrete ideas to start improving your IT value flow. For example, every IT project requires “raw materials” (e.g. user-specs, model numbers, version info etc.) and involves manpower and processes. Your key constraint may very well be a brilliant engineer who’s bogged down by too many projects/tasks and unplanned work.
UNDERSTANDING THE THREE WAYS
The Three Ways capture the overarching philosophy to maximize value from DevOps. Here they are in a nutshell:
- The First Way = Systems Thinking. In IT, value moves from the business to customers as work flows from Development to IT Ops. To optimize the value stream, you must go beyond individual parts to see how the entire organization can best achieve its goals. In the full Phoenix Project summary, we’ll touch on approaches and tools (e.g. the Kanban board) you can adopt.
- The Second Way = Feedback. Amplify and shorten the feedback loops from IT Ops back into Dev. This is closely linked with the ideas above about reducing WIP and improving overall throughout.
- The Third Way = Continuous improvement. Create a culture that embraces experimentation, repeated practice and learning from failures. Use drills and stress-tests to train your people and strengthen your systems.
HELPING THE BUSINESS TO WIN
It’s not enough to prevent IT screw-ups. The ultimate goal should be to leverage IT to help the business to win. In the complete version of The Phoenix Project summary, we’ll show how Parts Unlimited managed to do just that.
Obviously, the changes won’t happen overnight. However, you can get a glimpse of how it can be achieved, by following Parts Unlimited’s progress, from their originally-disastrous situation to the point where they achieved record-high sales and profitability, could respond nimble to customers’ needs, and had a happy, cohesive and productive team.
Getting the Most from The Phoenix Project
In this article, we’ve briefly outlined some of the key insights and strategies you can use to achieve desired change. For more examples, details, and actionable tips to apply these strategies, do get our complete book summary bundle which includes an infographic, 14-page text summary, and a 28-minute audio summary.
Through a story, this book illustrates how various concepts—including production principles, IT challenges, workplace politics, conflicting business goals, and resource constraints—can come together in the real world to make or break a company. Such complex challenges can’t be addressed overnight, and the novel makes it possible to see how the issues and moving parts are inter-related. You can purchase the book here for the full details and nuances which can (i) help IT professionals to see the bigger picture and get ideas for improving their work, and (ii) help non-IT business leaders to understand IT processes/challenges, and how they can better leverage IT in their organizations. You can also visit the official website for more details.
[You can read more about The Theory of Constraints present by Eliyahu Goldratt in our complete summary for The Goal.To learn more about the Three Ways and how to start your DevOps Transformation, do check out The DevOps Handbook summary!]
About the Authors of The Phoenix Project
The Phoenix Project: A Novel About IT, DevOps, and Helping Your Business Win is written by Gene Kim, Kevin Behr, George Spafford.
Gene Kim is a multiple award-winning CTO, researcher and author. He was founder and CTO of Tripwire (which has been adopted by >5,500 enterprises worldwide) for 13 years, and has written 6 books. Since 2014, he has been the founder of IT Revolution and the organizer of the DevOps Enterprise Summit.
Kevin Behr is the founder of the Information Technology Process Institute (ITPI) and the general manager and chief science officer of Praxis Flow LLC. Kevin has 25 years of IT management experience and is a mentor and advisor to CEOs and CIOs.
George Spafford is a research director for Gartner, covering DevOps, technical change, and release management, in addition to the use of bimodal IT and the pace-layered application strategy. He has written for hundreds of articles and numerous books.
The Phoenix Project Quotes
“IT is not just a department. IT is a competency that we need to gain as an entire company.”
“Unplanned work kills your ability to do planned work, so you must always do whatever it takes to eradicate it.”
“Improving daily work is even more important than doing daily work.”
“IT is not merely a department. Instead, it’s pervasive, like electricity. It’s a skill, like being able to read or do math.”
“In these competitive times, the name of the game is quick time to market and to fail fast.”
“Outcomes are what matter—not the process, not controls, or…what work you complete.”
Click here to download The Phoenix Project summary & infographic