{"id":101917,"date":"2023-05-12T09:31:00","date_gmt":"2023-05-12T13:31:00","guid":{"rendered":"https:\/\/www.shortform.com\/blog\/?p=101917"},"modified":"2023-05-12T12:31:00","modified_gmt":"2023-05-12T16:31:00","slug":"the-phoenix-project-book","status":"publish","type":"post","link":"https:\/\/www.shortform.com\/blog\/the-phoenix-project-book\/","title":{"rendered":"The Phoenix Project: Book Overview and Lessons"},"content":{"rendered":"\n

Is the book The Phoenix Project <\/em>worth reading? What can IT departments learn from the business parable?<\/p>\n\n\n\n

In The Phoenix Project<\/em>, Gene Kim, Kevin Behr, and George Spafford present a fictional case study of a business that\u2019s failing because it doesn\u2019t align the work of IT services with the company\u2019s goals. The authors then show how an IT department can turn itself around and get back in the game.<\/p>\n\n\n\n

Keep reading for a The Phoenix Project<\/em> book overview, as well as the lessons you can learn from the authors.<\/p>\n\n\n\n\n\n\n\n

The Phoenix Project<\/em><\/strong> Book Recap<\/h2>\n\n\n\n

A business today lives or dies based on the strength of its IT department. Because information technology is so deeply integrated into everything a business does\u2014from producing goods and services to interacting with customers, processing orders, and even paying its own employees\u2014every company in the modern age has to be proficient in how to optimize IT services. Not doing so risks heavy consequences, up to and including the failure of the business.<\/p>\n\n\n\n

The Phoenix Project<\/em><\/a> book was published in 2013 and presents a fictional case study of just such a scenario\u2014an imaginary auto parts manufacturer that\u2019s falling behind its competitors because it\u2019s unable to align the work of IT services with the company\u2019s larger goals. A new business initiative, dubbed \u201cThe Phoenix Project,\u201d promises to bring the company into the 21st century by integrating online ordering, in-store sales, inventory management<\/a>, and marketing campaigns<\/a>. However, by botching the Phoenix rollout, the auto parts company almost implodes from a disastrous series of technical failures.<\/p>\n\n\n\n

The authors of The Phoenix Project<\/em> are Gene Kim, founder of the digital security company Tripwire<\/a>, Kevin Behr, who co-founded the IT Process Institute<\/a> along with Kim, and George Spafford, Vice President Analyst for the business consulting firm Gartner<\/a>. Together, they use their combined expertise in technology management and business practices to paint a picture of how a company that does everything wrong when it comes to IT can turn itself around, revamp its core practices, and get back in the competitive game.<\/p>\n\n\n\n

In this guide, we\u2019ll begin by summarizing the decline and phoenix-like resurrection of the fictional Parts Unlimited\u2019s IT department. We\u2019ll then dissect the story\u2019s central message, first by explaining the authors\u2019 diagnosis of what makes IT processes fall apart, then by describing the three fundamental pillars of IT management that Kim, Behr, and Spafford prescribe as a remedy\u2014speeding up workflow, providing quick feedback, and encouraging a culture of perpetual improvement.<\/p>\n\n\n\n

In addition, we\u2019ll provide clarification on IT, business, and production concepts that the authors assume the reader\u2019s already familiar with. We\u2019ll discuss the practice of using fiction as a teaching tool for real-world situations and explore other authors\u2019 ideas on management, leadership, workplace culture, and maximizing<\/a> workplace productivity<\/a>.<\/p>\n\n\n\n

The Saga of an IT Department<\/strong><\/h3>\n\n\n\n

Our story focuses on the character Bill Palmer, a mid-level director at Parts Unlimited who\u2019s promoted to vice president (VP) of IT Operations shortly before the grand rollout of the Phoenix Project, an online sales management tool that\u2019s been years in the making. What he finds, though, is an IT department in utter disarray, stretched to its limit by constant demands and arbitrary deadlines it can\u2019t possibly meet. Right out of the gate, Bill must cope with an emergency payroll issue, an ongoing conflict between IT Operations and the software development team, and a prospective board member who suspects that Bill\u2019s IT department is going about its business all wrong.<\/p>\n\n\n\n

On his first day as VP, Bill is thrust into trying to solve a payroll data problem that could result in many workers not receiving their paychecks. The difficulty resolving the issue is compounded by the lack of communication within the department. After sleepless nights and much departmental overtime, Bill determines that the root of the problem was a system change enacted by a vendor without the department\u2019s knowledge. This clues him into what the authors say ought to be obvious in hindsight: A process for tracking and approving system changes is essential to IT management.<\/strong><\/p>\n\n\n\n

With the launch of the Phoenix Project on the horizon, Bill also has to mediate between his own department (Ops) and Application Development (Dev). Development accuses Ops of not prioritizing work such as Phoenix because Ops spends all of its time putting out fires like the payroll debacle. Operations fires back that Dev hasn\u2019t left Ops enough time to properly test Phoenix before launch, nor has Dev provided the system specifications and operating instructions Ops will need to roll it out, meaning that Ops will still be fixing Phoenix problems even after the new system has already gone live. Much of that work will have to wait on Brent, the only software engineer who fully understands the company\u2019s systems and can fix them.<\/p>\n\n\n\n

While trying to come to grips with the chaos in IT and the impending Phoenix launch, Bill meets Erik Reid, a management expert whom Parts Unlimited is courting to be a board member. Speaking on behalf of the authors, Erik understands Bill\u2019s problems even better than he does, but Erik doesn\u2019t spill his knowledge all at once. Instead, he gives Bill a few guiding pointers such as the need to understand the different types of work, the danger of bottlenecks, and the three pillars of IT management<\/strong>\u2014fast workflow, quick feedback, and perpetual improvement (all of which we\u2019ll expand on in this guide).<\/p>\n\n\n\n

The Phoenix Disaster<\/strong><\/h4>\n\n\n\n

In spite of Bill\u2019s apprehensions, the Phoenix Project launch goes even worse<\/em> than anyone could have imagined. Thanks to the combination of a dysfunctional corporate culture, unrealistic expectations<\/a>, and a lack of collaboration between Dev and Ops, the Phoenix release crashes not only the company\u2019s online ordering system, but also the ability of their brick-and-mortar stores to make sales<\/a> or process credit card transactions. <\/em>The authors use the crisis to illustrate many points of failure\u2014between management and IT, between Dev and Ops, and within IT Operations itself.<\/p>\n\n\n\n

Even before the failures begin, Bill goes to the CEO begging for more resources, as well as permission to prioritize Phoenix above any other demands on IT. The CEO refuses to budge, demanding that IT make do with what it has and give equal weight to every request made by the organization. Meanwhile, Ops is unable to get Phoenix to work in a simulated test environment. Nevertheless, since the company\u2019s marketing has already announced Phoenix\u2019s release to the media, IT is forced to move ahead with implementation.<\/p>\n\n\n\n

The Phoenix release almost destroys the company, making it hemorrhage money and customers as sales become nearly impossible to complete and users\u2019 credit card data become unsecure. The CEO lays all the blame on IT and even threatens to outsource the whole department if Bill can\u2019t find a way to meet the company\u2019s bloated expectations. The authors show how this is a point of common ground between Dev and Ops because Operations and their counterparts in Development are frequently asked to perform miracles with little or nothing to go on.<\/strong> Bill despairs about finding any solution, and he considers leaving the company altogether.<\/p>\n\n\n\n

The Turnaround<\/strong><\/h4>\n\n\n\n

Bringing the company back from the brink is a larger job than merely IT\u2019s. With some nudging from potential future board member Erik, the CEO admits his own culpability while Bill begins to envision new ways to correct IT\u2019s problems and prevent them in the future. These include the short-term solution of stopping all work on everything except Phoenix while restructuring for the long term to produce faster, smaller product releases that allow for quicker testing and releases.<\/p>\n\n\n\n

Bill suggests stopping any work unrelated to Phoenix. This includes not accepting any new projects into the IT workstream until enough of the work in progress is completed and his team can assess IT\u2019s technical debt\u2014the amount of future work that\u2019s accrued by taking shortcuts and quick fixes in the past. It also gives them time to better manage Brent, the one engineer whose skills are so essential that he acts as a bottleneck to all of IT\u2019s work.<\/p>\n\n\n\n

The freeze on new tasks gives IT enough space to correct some of Phoenix\u2019s problems while also giving Bill room to explore how IT\u2019s work impacts the company as a whole. According to the authors, that impact is huge. IT\u2019s functions support every single business goal of a modern corporation in one way or another. From his research into the company\u2019s needs, Bill realizes that the Phoenix Project\u2014one giant platform, years in the making, designed to do everything, everywhere, all at once\u2014was ill-conceived from the start. What\u2019s been needed all along are smaller applications that are faster to design, test, and roll out,<\/strong> and that can therefore be more responsive to customers\u2019 needs in real time.<\/p>\n\n\n\n

The Unicorn Project<\/h5>\n\n\n\n

While Bill keeps some of his team on the job to stop Phoenix from sinking the company\u2019s boat, he devotes the rest of IT\u2019s resources to a new initiative called \u201cProject Unicorn,\u201d which merges Dev and Ops in a collaborative cycle that automates their redundancies and allows them to design, test, and implement software solutions at a rapid pace. Using the Unicorn structure, Dev and Ops are able to bypass Phoenix entirely and deliver on its promised functions by creating smaller, more versatile applications. <\/p>\n\n\n\n

After the success of the Unicorn Project, Bill builds on IT\u2019s work by launching a program to continually test their systems for weakness and introduce improvements, both to the software they create and to the process by which IT functions. As a result of Bill\u2019s success in IT, the CEO places him on a fast track to become Parts Unlimited\u2019s next Chief Operating Officer (COO). The authors predict that in the future, most corporate COOs will have backgrounds in IT because IT is now so heavily integrated into every business function a company performs.<\/p>\n\n\n\n

Work and What Stops It<\/strong><\/h3>\n\n\n\n

Throughout their narrative, Kim, Behr, and Spafford illustrate the common workflow challenges that plague IT departments. At the root of these issues, when they occur, is a failure to recognize, prepare for, and manage the two greatest disruptors of productivity\u2014unexpected work and bottlenecks.<\/p>\n\n\n\n

In the story, Erik challenges Bill to identify and understand the four types of work IT performs. The first of these are business projects initiated by the company or one of its divisions, such as sales, marketing, or human resources. The novel\u2019s titular Phoenix Project is a business initiative on the largest scale. The second type of work constitutes internal IT projects, such as upgrading servers or migrating data. The third class of IT work is made up of changes, often minuscule, to databases, app configurations, and lines of code. The authors suggest that such changes are a major source of work and potential problems that, if unmanaged, contribute to the fourth type of work IT does\u2014unexpected work that grinds the system to a halt.<\/p>\n\n\n\n

Unexpected work is almost always an emergency, or at least is made to seem that way, and it gets in the way of doing anything else. Unexpected work includes fixing a nonstop flood of technical problems, many of which aren\u2019t prioritized by importance, but rather by how vocal the person complaining about the issue is. What\u2019s worse, unexpected work creates even more work<\/strong> by taking time away from the system testing and preventive maintenance that would stop such problems from arising in the first place. To correct unexpected problems quickly, the solutions implemented are often untested patches and workarounds that build up technical debt in the system, laying the groundwork for more unexpected problems.<\/p>\n\n\n\n

The Bottleneck<\/strong><\/h4>\n\n\n\n

The authors say that the other work stoppage in any system is the bottleneck<\/em> (which the authors refer to as the constraint<\/em>), defined as the one link in the chain that limits the speed of the entire production process.<\/strong> In the fictional example, the bottleneck is Brent, the lone engineer whose unique and exhaustive knowledge of Parts Unlimited\u2019s computer systems makes him the indispensable go-to guy for every task IT tries to perform. As a result, IT can\u2019t do anything without involving Brent in some way, and so no work gets done any faster than Brent is able to get to it. Because Brent is so overburdened, he doesn\u2019t have time to document his work, which means his knowledge isn\u2019t shared and IT becomes even more reliant on him as a crutch.<\/p>\n\n\n\n

Brent is merely one example of the kind of bottlenecks that can constrict a system. The authors list other types of bottlenecks based on those described in The Goal: A Process of Ongoing Improvement<\/em><\/a> by Eliyahu M. Goldratt. These include the creation of test environments for software, installing large amounts of new code, and getting approval for changes from committees. Whatever your system\u2019s bottleneck is, the authors are clear that you can\u2019t push work through your department any faster than your bottleneck will allow.<\/strong> Any attempt to do so will result in a traffic jam of work piling up at one station while the rest of the production line sits idle.<\/p>\n\n\n\n

The Pillars of Production<\/strong><\/h3>\n\n\n\n

None of the problems of IT are insurmountable, but Kim, Behr, and Spafford argue that addressing them requires completely rethinking how IT work is done. In their fictional case study, they demonstrate how work management principles developed on factory production lines can be applied in an IT environment, where the production of software, databases, and networks can be likened to manufacturing physical products. The three foundational pillars of production can be summed up as 1) fast workflow, 2) quick feedback, and 3) continual improvement.<\/p>\n\n\n\n

Because the authors\u2019 point-of-view character is a vice president of IT operations, one might assume that their advice is intended for readers in corporate management positions. However, understanding the principles that follow will be essential for everyone in the production process, since implementing the authors\u2019 recommendations will require buy-in from many people in a company and certainly everyone in IT.<\/p>\n\n\n\n

Pillar 1: Fast Workflow<\/strong><\/h4>\n\n\n\n

The first keystone, \u201cfast workflow,\u201d may sound like a goal <\/em>and not a place to start. However, the authors lay out a series of procedures that can establish a faster flow of work through IT from the outset. These include creating a visual tracking method to monitor and schedule work through IT, reducing the paths by which work enters the pipeline, breaking projects down into smaller, independently manageable components, and opening up your bottleneck so that work flows through it as quickly as possible.<\/p>\n\n\n\n

To begin with, managing workflow is impossible without a way to monitor its progress.<\/strong> The authors repeatedly recommend using a kanban board<\/a><\/em> (a visual tool that shows the status of tasks as they pass through IT) both for tracking work and for scheduling tasks as they come in. A visual tracking tool lets you document how much time a task takes at each station, and therefore it indicates how much work you can afford to take on. If certain tasks are regularly repeated, then documentation will allow you to plan for exactly how much time they will take. It will also make you aware of how many time-consuming handoffs occur as a task is passed from one station to the next and whether you can reduce those handoffs in order to speed up workflow even more.<\/p>\n\n\n\n

As you monitor your department\u2019s workflow, you\u2019ll also become aware of all the different avenues by which work\u2014often unexpected <\/em>work\u2014enters and confounds the flow of operations. People in many organizations have grown used to calling IT staff directly to fix what they perceive as \u201curgent\u201d computer problems, interrupting and backlogging whatever projects your staff was meant to be working on. Identifying where and how unexpected work interrupts production is the first step in limiting the amount of work in progress.<\/strong> The authors stress that doing so is vitally important to speeding up IT production.<\/p>\n\n\n\n

Another key component of speeding up workflow is to reduce the size of the projects you take on. Huge projects meant to accomplish multiple business goals at once, such as the authors\u2019 disastrous Phoenix Project, are so unwieldy that identifying design problems and errors is that much more time-consuming and difficult. Dividing large projects into small, discrete units can let each part move through design, testing, error-fixing, and rollout in a timely manner,<\/strong> sometimes on the order of days or weeks instead of months or years. If there\u2019s any fundamental flaw in one of the smaller components of a project, it can be caught and corrected that much sooner, before it can have a devastating impact on the whole.<\/p>\n\n\n\n

Open Your Bottleneck<\/h5>\n\n\n\n

The authors insist that to truly speed up workflow through IT, you should make the most efficient use of your bottleneck. By visually monitoring the work through IT, you\u2019ll quickly identify where the bottleneck is\u2014most likely one overburdened workstation. Though it may be counterintuitive, workstations need idle time in order for work not to pile up.<\/strong> The authors provide a simple formula to determine how much time a task will spend in the queue at any given station (the wait time) depending on how much time that station spends idle:<\/p>\n\n\n\n

Wait time = Percent of time busy \/ Percent of time idle<\/p>\n\n\n\n

According to this formula, wait times at a station that\u2019s 80% busy and 20% idle will be four times longer than at a station that\u2019s 50% busy and 50% idle.<\/p>\n\n\n\n

Once you\u2019ve identified your bottleneck, you can arrange your workflow so that you don\u2019t send work to the bottleneck faster than it can handle. Tracking work will also let you know if any of the bottleneck\u2019s work can be automated. If the reason for the bottleneck is unshared skills or knowledge, as in the fictional example of Brent the software engineer, you should document everything the bottleneck does so that knowledge and skills can be shared among your team,<\/strong> eventually leading to sharing of the workload. Once one bottleneck has been opened up, you may find another in your production line. If so, apply the same steps as before.<\/p>\n\n\n\n

Pillar 2: Quick Feedback<\/strong><\/h4>\n\n\n\n

In order for a streamlined, faster workflow to be beneficial, your system must generate and implement corrective feedback<\/a> all along the production chain. Feedback cycles<\/a>, like your projects themselves, should be small and efficient so that problems can be identified quickly, connecting both Development and Operations, and resolved in a way that generates new information.<\/p>\n\n\n\n

The authors note that systems such as large software packages and sprawling computer networks are far too complex for any one person to fully understand. Therefore, work on those systems must be designed in such a way that errors can be detected and corrected quickly. Small project sizes let you catch and fix problems before they become disasters, but to enable this, your production process must generate feedback at every step in which work is performed. <\/strong>One example of a way to create this kind of feedback is to institute checklists for every task being done, especially at any point in the process where work is passed from one station to another.<\/p>\n\n\n\n

Feedback cycles can\u2019t be confined to Operations\u2014they must include Development as well. Developers must know if their code is effective or problematic as quickly as possible, not months down the line after they\u2019ve moved on to other projects. The authors say that feedback from Ops must be incorporated into the very beginning of the Development process,<\/strong> in effect merging the two departments into one cohesive DevOps gestalt. Ideally, the feedback and response time between designing and installing new systems needs to be fast enough to keep up with customer demand, whether those \u201ccustomers\u201d are clients of your company or other departments inside your organization.<\/p>\n\n\n\n

The moment your feedback measures detect a problem, it should be fixed immediately, not patched with a workaround and put off until later. The authors insist that problems should be tackled by the people closest to them as part of their regular responsibilities.<\/strong> More than that, those people should bring in as much help as they can get from their department to resolve the issue. This way, the issue becomes a learning opportunity that generates new knowledge for the organization. By documenting the whole solution process, that knowledge becomes embedded in IT’s procedures and toolkit for future problems.<\/p>\n\n\n\n

Pillar 3: Constant Improvement<\/strong><\/h4>\n\n\n\n

The last and perhaps most important component to harnessing IT\u2019s\u2014or any system\u2019s\u2014full productivity is to create a culture of continual improvement through practice, repetition, experimentation, and <\/strong>useful <\/em><\/strong>failure. <\/strong>Using the story of their fictional company\u2019s ill-conceived \u201cPhoenix Project,\u201d the authors provide a negative example of a company with a toxic workplace<\/a> culture and a blueprint for a better way to encourage growth, development, and innovation that benefits your business as a whole.<\/p>\n\n\n\n

The defining characteristic of a toxic workplace is that employees\u2019 behavior is guided by a constant fear of failure<\/a>. In such a culture, administrators address mistakes and malfunctions by assigning blame<\/a> and taking punitive action. As a result, people are discouraged from identifying errors and problems in a system. Feedback is silenced, because who will provide it when the default cultural response is to kill the messenger? Toxic work cultures stifle any improvement, and without constant improvement, a system will stagnate and problems will fester until they become catastrophic.<\/p>\n\n\n\n

On the other hand, a productive company culture<\/a> will encourage people to report problems at once.<\/strong> The authors show that if employees can trust that they won\u2019t be reprimanded\u2014and may in fact be rewarded<\/em>\u2014for identifying and helping solve issues detrimental to the company, then those employees will feel an ownership stake in seeking out ways to improve the whole system. If they\u2019re encouraged to take risks in the process by trying solutions that may or may not work without fear of reprisal from on high, then your company will foster a culture of innovation in which even failed attempts at improvement are seen as a way to generate knowledge that can be shared across the organization.<\/p>\n\n\n\n

Finally, the authors state that businesses should formalize their systems of continual improvement. IT staff can hone new solutions and practices while refining them through repetition and practice. Teams within DevOps can root out flaws in their products by pushing their products\u2019 limits, forcing errors to emerge before they crop up on their own. One way to accomplish this is to deliberately introduce faults and design flaws into the production line <\/strong>so that staff can practice identifying errors, providing feedback<\/a>, and coming up with resolutions. Not only can you identify systemic deficiencies in this way, but you\u2019ll also promote a culture in which experimentation, risk-taking, and learning become an institutional way of life.<\/p>\n","protected":false},"excerpt":{"rendered":"

Is the book The Phoenix Project worth reading? What can IT departments learn from the business parable? In The Phoenix Project, Gene Kim, Kevin Behr, and George Spafford present a fictional case study of a business that\u2019s failing because it doesn\u2019t align the work of IT services with the company\u2019s goals. The authors then show how an IT department can turn itself around and get back in the game. Keep reading for a The Phoenix Project book overview, as well as the lessons you can learn from the authors.<\/p>\n","protected":false},"author":8,"featured_media":28170,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_jetpack_memberships_contains_paid_content":false,"footnotes":""},"categories":[40,45,14],"tags":[1016],"class_list":["post-101917","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-books","category-business","category-management","tag-the-phoenix-project","","tg-column-two"],"yoast_head":"\nThe Phoenix Project: Book Overview and Lessons - Shortform Books<\/title>\n<meta name=\"description\" content=\"The Phoenix Project is a fictional story about a company that's struggling because of its poorly run IT department. Here's a book overview.\" \/>\n<meta name=\"robots\" content=\"index, follow, max-snippet:-1, max-image-preview:large, max-video-preview:-1\" \/>\n<link rel=\"canonical\" href=\"https:\/\/www.shortform.com\/blog\/the-phoenix-project-book\/\" \/>\n<meta property=\"og:locale\" content=\"en_US\" \/>\n<meta property=\"og:type\" content=\"article\" \/>\n<meta property=\"og:title\" content=\"The Phoenix Project: Book Overview and Lessons\" \/>\n<meta property=\"og:description\" content=\"The Phoenix Project is a fictional story about a company that's struggling because of its poorly run IT department. Here's a book overview.\" \/>\n<meta property=\"og:url\" content=\"https:\/\/www.shortform.com\/blog\/the-phoenix-project-book\/\" \/>\n<meta property=\"og:site_name\" content=\"Shortform Books\" \/>\n<meta property=\"article:published_time\" content=\"2023-05-12T13:31:00+00:00\" \/>\n<meta property=\"article:modified_time\" content=\"2023-05-12T16:31:00+00:00\" \/>\n<meta property=\"og:image\" content=\"https:\/\/s3.amazonaws.com\/wordpress.shortform.com\/blog\/wp-content\/uploads\/2021\/03\/glasses-on-book.jpg\" \/>\n\t<meta property=\"og:image:width\" content=\"1184\" \/>\n\t<meta property=\"og:image:height\" content=\"700\" \/>\n\t<meta property=\"og:image:type\" content=\"image\/jpeg\" \/>\n<meta name=\"author\" content=\"Hannah Aster\" \/>\n<meta name=\"twitter:card\" content=\"summary_large_image\" \/>\n<meta name=\"twitter:label1\" content=\"Written by\" \/>\n\t<meta name=\"twitter:data1\" content=\"Hannah Aster\" \/>\n\t<meta name=\"twitter:label2\" content=\"Est. reading time\" \/>\n\t<meta name=\"twitter:data2\" content=\"17 minutes\" \/>\n<script type=\"application\/ld+json\" class=\"yoast-schema-graph\">{\"@context\":\"https:\/\/schema.org\",\"@graph\":[{\"@type\":\"Article\",\"@id\":\"https:\/\/www.shortform.com\/blog\/the-phoenix-project-book\/#article\",\"isPartOf\":{\"@id\":\"https:\/\/www.shortform.com\/blog\/the-phoenix-project-book\/\"},\"author\":{\"name\":\"Hannah Aster\",\"@id\":\"https:\/\/www.shortform.com\/blog\/#\/schema\/person\/f39f52830e4f7039a16e45d12354542f\"},\"headline\":\"The Phoenix Project: Book Overview and Lessons\",\"datePublished\":\"2023-05-12T13:31:00+00:00\",\"dateModified\":\"2023-05-12T16:31:00+00:00\",\"mainEntityOfPage\":{\"@id\":\"https:\/\/www.shortform.com\/blog\/the-phoenix-project-book\/\"},\"wordCount\":3843,\"commentCount\":0,\"publisher\":{\"@id\":\"https:\/\/www.shortform.com\/blog\/#organization\"},\"image\":{\"@id\":\"https:\/\/www.shortform.com\/blog\/the-phoenix-project-book\/#primaryimage\"},\"thumbnailUrl\":\"https:\/\/www.shortform.com\/blog\/wp-content\/uploads\/2021\/03\/glasses-on-book.jpg\",\"keywords\":[\"The Phoenix Project\"],\"articleSection\":[\"Books\",\"Business\",\"Management\"],\"inLanguage\":\"en-US\",\"potentialAction\":[{\"@type\":\"CommentAction\",\"name\":\"Comment\",\"target\":[\"https:\/\/www.shortform.com\/blog\/the-phoenix-project-book\/#respond\"]}]},{\"@type\":\"WebPage\",\"@id\":\"https:\/\/www.shortform.com\/blog\/the-phoenix-project-book\/\",\"url\":\"https:\/\/www.shortform.com\/blog\/the-phoenix-project-book\/\",\"name\":\"The Phoenix Project: Book Overview and Lessons - Shortform Books\",\"isPartOf\":{\"@id\":\"https:\/\/www.shortform.com\/blog\/#website\"},\"primaryImageOfPage\":{\"@id\":\"https:\/\/www.shortform.com\/blog\/the-phoenix-project-book\/#primaryimage\"},\"image\":{\"@id\":\"https:\/\/www.shortform.com\/blog\/the-phoenix-project-book\/#primaryimage\"},\"thumbnailUrl\":\"https:\/\/www.shortform.com\/blog\/wp-content\/uploads\/2021\/03\/glasses-on-book.jpg\",\"datePublished\":\"2023-05-12T13:31:00+00:00\",\"dateModified\":\"2023-05-12T16:31:00+00:00\",\"description\":\"The Phoenix Project is a fictional story about a company that's struggling because of its poorly run IT department. Here's a book overview.\",\"breadcrumb\":{\"@id\":\"https:\/\/www.shortform.com\/blog\/the-phoenix-project-book\/#breadcrumb\"},\"inLanguage\":\"en-US\",\"potentialAction\":[{\"@type\":\"ReadAction\",\"target\":[\"https:\/\/www.shortform.com\/blog\/the-phoenix-project-book\/\"]}]},{\"@type\":\"ImageObject\",\"inLanguage\":\"en-US\",\"@id\":\"https:\/\/www.shortform.com\/blog\/the-phoenix-project-book\/#primaryimage\",\"url\":\"https:\/\/www.shortform.com\/blog\/wp-content\/uploads\/2021\/03\/glasses-on-book.jpg\",\"contentUrl\":\"https:\/\/www.shortform.com\/blog\/wp-content\/uploads\/2021\/03\/glasses-on-book.jpg\",\"width\":1184,\"height\":700},{\"@type\":\"BreadcrumbList\",\"@id\":\"https:\/\/www.shortform.com\/blog\/the-phoenix-project-book\/#breadcrumb\",\"itemListElement\":[{\"@type\":\"ListItem\",\"position\":1,\"name\":\"Home\",\"item\":\"https:\/\/www.shortform.com\/blog\/\"},{\"@type\":\"ListItem\",\"position\":2,\"name\":\"The Phoenix Project: Book Overview and Lessons\"}]},{\"@type\":\"WebSite\",\"@id\":\"https:\/\/www.shortform.com\/blog\/#website\",\"url\":\"https:\/\/www.shortform.com\/blog\/\",\"name\":\"Shortform Books\",\"description\":\"The World's Best Book Summaries\",\"publisher\":{\"@id\":\"https:\/\/www.shortform.com\/blog\/#organization\"},\"potentialAction\":[{\"@type\":\"SearchAction\",\"target\":{\"@type\":\"EntryPoint\",\"urlTemplate\":\"https:\/\/www.shortform.com\/blog\/?s={search_term_string}\"},\"query-input\":{\"@type\":\"PropertyValueSpecification\",\"valueRequired\":true,\"valueName\":\"search_term_string\"}}],\"inLanguage\":\"en-US\"},{\"@type\":\"Organization\",\"@id\":\"https:\/\/www.shortform.com\/blog\/#organization\",\"name\":\"Shortform Books\",\"url\":\"https:\/\/www.shortform.com\/blog\/\",\"logo\":{\"@type\":\"ImageObject\",\"inLanguage\":\"en-US\",\"@id\":\"https:\/\/www.shortform.com\/blog\/#\/schema\/logo\/image\/\",\"url\":\"https:\/\/www.shortform.com\/blog\/wp-content\/uploads\/2019\/06\/logo-equilateral-with-text-no-bg.png\",\"contentUrl\":\"https:\/\/www.shortform.com\/blog\/wp-content\/uploads\/2019\/06\/logo-equilateral-with-text-no-bg.png\",\"width\":500,\"height\":74,\"caption\":\"Shortform Books\"},\"image\":{\"@id\":\"https:\/\/www.shortform.com\/blog\/#\/schema\/logo\/image\/\"}},{\"@type\":\"Person\",\"@id\":\"https:\/\/www.shortform.com\/blog\/#\/schema\/person\/f39f52830e4f7039a16e45d12354542f\",\"name\":\"Hannah Aster\",\"image\":{\"@type\":\"ImageObject\",\"inLanguage\":\"en-US\",\"@id\":\"https:\/\/www.shortform.com\/blog\/#\/schema\/person\/image\/\",\"url\":\"https:\/\/secure.gravatar.com\/avatar\/0302cb2690b70a21639bc6873e587f42d39d02385b7e59d8efd0d3e000ae7681?s=96&d=mm&r=g\",\"contentUrl\":\"https:\/\/secure.gravatar.com\/avatar\/0302cb2690b70a21639bc6873e587f42d39d02385b7e59d8efd0d3e000ae7681?s=96&d=mm&r=g\",\"caption\":\"Hannah Aster\"},\"description\":\"Hannah is a seasoned writer and editor who started her journey with Shortform nearly five years ago. She grew up reading mostly fiction books but transitioned to non-fiction writing when she started her travel website in 2018. When she's not writing or traveling, you can find Hannah working on home reno projects, crafting, or taking care of plants.\",\"knowsAbout\":[\"Graduated summa cum laude with a bachelor's degree in English and minors in professional and creative writing\"],\"jobTitle\":\"SEO Team Lead\",\"worksFor\":\"Shortform\",\"url\":\"https:\/\/www.shortform.com\/blog\/author\/hannah\/\"}]}<\/script>\n<!-- \/ Yoast SEO Premium plugin. -->","yoast_head_json":{"title":"The Phoenix Project: Book Overview and Lessons - Shortform Books","description":"The Phoenix Project is a fictional story about a company that's struggling because of its poorly run IT department. Here's a book overview.","robots":{"index":"index","follow":"follow","max-snippet":"max-snippet:-1","max-image-preview":"max-image-preview:large","max-video-preview":"max-video-preview:-1"},"canonical":"https:\/\/www.shortform.com\/blog\/the-phoenix-project-book\/","og_locale":"en_US","og_type":"article","og_title":"The Phoenix Project: Book Overview and Lessons","og_description":"The Phoenix Project is a fictional story about a company that's struggling because of its poorly run IT department. Here's a book overview.","og_url":"https:\/\/www.shortform.com\/blog\/the-phoenix-project-book\/","og_site_name":"Shortform Books","article_published_time":"2023-05-12T13:31:00+00:00","article_modified_time":"2023-05-12T16:31:00+00:00","og_image":[{"width":1184,"height":700,"url":"https:\/\/s3.amazonaws.com\/wordpress.shortform.com\/blog\/wp-content\/uploads\/2021\/03\/glasses-on-book.jpg","type":"image\/jpeg"}],"author":"Hannah Aster","twitter_card":"summary_large_image","twitter_misc":{"Written by":"Hannah Aster","Est. reading time":"17 minutes"},"schema":{"@context":"https:\/\/schema.org","@graph":[{"@type":"Article","@id":"https:\/\/www.shortform.com\/blog\/the-phoenix-project-book\/#article","isPartOf":{"@id":"https:\/\/www.shortform.com\/blog\/the-phoenix-project-book\/"},"author":{"name":"Hannah Aster","@id":"https:\/\/www.shortform.com\/blog\/#\/schema\/person\/f39f52830e4f7039a16e45d12354542f"},"headline":"The Phoenix Project: Book Overview and Lessons","datePublished":"2023-05-12T13:31:00+00:00","dateModified":"2023-05-12T16:31:00+00:00","mainEntityOfPage":{"@id":"https:\/\/www.shortform.com\/blog\/the-phoenix-project-book\/"},"wordCount":3843,"commentCount":0,"publisher":{"@id":"https:\/\/www.shortform.com\/blog\/#organization"},"image":{"@id":"https:\/\/www.shortform.com\/blog\/the-phoenix-project-book\/#primaryimage"},"thumbnailUrl":"https:\/\/www.shortform.com\/blog\/wp-content\/uploads\/2021\/03\/glasses-on-book.jpg","keywords":["The Phoenix Project"],"articleSection":["Books","Business","Management"],"inLanguage":"en-US","potentialAction":[{"@type":"CommentAction","name":"Comment","target":["https:\/\/www.shortform.com\/blog\/the-phoenix-project-book\/#respond"]}]},{"@type":"WebPage","@id":"https:\/\/www.shortform.com\/blog\/the-phoenix-project-book\/","url":"https:\/\/www.shortform.com\/blog\/the-phoenix-project-book\/","name":"The Phoenix Project: Book Overview and Lessons - Shortform Books","isPartOf":{"@id":"https:\/\/www.shortform.com\/blog\/#website"},"primaryImageOfPage":{"@id":"https:\/\/www.shortform.com\/blog\/the-phoenix-project-book\/#primaryimage"},"image":{"@id":"https:\/\/www.shortform.com\/blog\/the-phoenix-project-book\/#primaryimage"},"thumbnailUrl":"https:\/\/www.shortform.com\/blog\/wp-content\/uploads\/2021\/03\/glasses-on-book.jpg","datePublished":"2023-05-12T13:31:00+00:00","dateModified":"2023-05-12T16:31:00+00:00","description":"The Phoenix Project is a fictional story about a company that's struggling because of its poorly run IT department. Here's a book overview.","breadcrumb":{"@id":"https:\/\/www.shortform.com\/blog\/the-phoenix-project-book\/#breadcrumb"},"inLanguage":"en-US","potentialAction":[{"@type":"ReadAction","target":["https:\/\/www.shortform.com\/blog\/the-phoenix-project-book\/"]}]},{"@type":"ImageObject","inLanguage":"en-US","@id":"https:\/\/www.shortform.com\/blog\/the-phoenix-project-book\/#primaryimage","url":"https:\/\/www.shortform.com\/blog\/wp-content\/uploads\/2021\/03\/glasses-on-book.jpg","contentUrl":"https:\/\/www.shortform.com\/blog\/wp-content\/uploads\/2021\/03\/glasses-on-book.jpg","width":1184,"height":700},{"@type":"BreadcrumbList","@id":"https:\/\/www.shortform.com\/blog\/the-phoenix-project-book\/#breadcrumb","itemListElement":[{"@type":"ListItem","position":1,"name":"Home","item":"https:\/\/www.shortform.com\/blog\/"},{"@type":"ListItem","position":2,"name":"The Phoenix Project: Book Overview and Lessons"}]},{"@type":"WebSite","@id":"https:\/\/www.shortform.com\/blog\/#website","url":"https:\/\/www.shortform.com\/blog\/","name":"Shortform Books","description":"The World's Best Book Summaries","publisher":{"@id":"https:\/\/www.shortform.com\/blog\/#organization"},"potentialAction":[{"@type":"SearchAction","target":{"@type":"EntryPoint","urlTemplate":"https:\/\/www.shortform.com\/blog\/?s={search_term_string}"},"query-input":{"@type":"PropertyValueSpecification","valueRequired":true,"valueName":"search_term_string"}}],"inLanguage":"en-US"},{"@type":"Organization","@id":"https:\/\/www.shortform.com\/blog\/#organization","name":"Shortform Books","url":"https:\/\/www.shortform.com\/blog\/","logo":{"@type":"ImageObject","inLanguage":"en-US","@id":"https:\/\/www.shortform.com\/blog\/#\/schema\/logo\/image\/","url":"https:\/\/www.shortform.com\/blog\/wp-content\/uploads\/2019\/06\/logo-equilateral-with-text-no-bg.png","contentUrl":"https:\/\/www.shortform.com\/blog\/wp-content\/uploads\/2019\/06\/logo-equilateral-with-text-no-bg.png","width":500,"height":74,"caption":"Shortform Books"},"image":{"@id":"https:\/\/www.shortform.com\/blog\/#\/schema\/logo\/image\/"}},{"@type":"Person","@id":"https:\/\/www.shortform.com\/blog\/#\/schema\/person\/f39f52830e4f7039a16e45d12354542f","name":"Hannah Aster","image":{"@type":"ImageObject","inLanguage":"en-US","@id":"https:\/\/www.shortform.com\/blog\/#\/schema\/person\/image\/","url":"https:\/\/secure.gravatar.com\/avatar\/0302cb2690b70a21639bc6873e587f42d39d02385b7e59d8efd0d3e000ae7681?s=96&d=mm&r=g","contentUrl":"https:\/\/secure.gravatar.com\/avatar\/0302cb2690b70a21639bc6873e587f42d39d02385b7e59d8efd0d3e000ae7681?s=96&d=mm&r=g","caption":"Hannah Aster"},"description":"Hannah is a seasoned writer and editor who started her journey with Shortform nearly five years ago. She grew up reading mostly fiction books but transitioned to non-fiction writing when she started her travel website in 2018. When she's not writing or traveling, you can find Hannah working on home reno projects, crafting, or taking care of plants.","knowsAbout":["Graduated summa cum laude with a bachelor's degree in English and minors in professional and creative writing"],"jobTitle":"SEO Team Lead","worksFor":"Shortform","url":"https:\/\/www.shortform.com\/blog\/author\/hannah\/"}]}},"jetpack_sharing_enabled":true,"jetpack_featured_media_url":"https:\/\/www.shortform.com\/blog\/wp-content\/uploads\/2021\/03\/glasses-on-book.jpg","_links":{"self":[{"href":"https:\/\/www.shortform.com\/blog\/wp-json\/wp\/v2\/posts\/101917","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.shortform.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.shortform.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.shortform.com\/blog\/wp-json\/wp\/v2\/users\/8"}],"replies":[{"embeddable":true,"href":"https:\/\/www.shortform.com\/blog\/wp-json\/wp\/v2\/comments?post=101917"}],"version-history":[{"count":1,"href":"https:\/\/www.shortform.com\/blog\/wp-json\/wp\/v2\/posts\/101917\/revisions"}],"predecessor-version":[{"id":101918,"href":"https:\/\/www.shortform.com\/blog\/wp-json\/wp\/v2\/posts\/101917\/revisions\/101918"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.shortform.com\/blog\/wp-json\/wp\/v2\/media\/28170"}],"wp:attachment":[{"href":"https:\/\/www.shortform.com\/blog\/wp-json\/wp\/v2\/media?parent=101917"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.shortform.com\/blog\/wp-json\/wp\/v2\/categories?post=101917"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.shortform.com\/blog\/wp-json\/wp\/v2\/tags?post=101917"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}