The 2 Most Common Workflow Problems & How to Fix Them

This article is an excerpt from the Shortform book guide to "The Phoenix Project" by Gene Kim, Kevin Behr, and George Spafford. Shortform has the world's best summaries and analyses of books you should be reading.

Like this article? Sign up for a free trial here.

What are the most common workflow problems? How can these problems lead to a complete standstill of work? How can they be overcome?

According to the book The Phoenix Project, the two biggest workflow problems when it comes to IT departments are unexpected work and bottlenecks. Unexpected work often results in bandaid solutions and bottlenecks limit the speed of production.

Here’s a deeper look at why these two workflow challenges are so problematic.

Workflow and What Stops It

Throughout their narrative, Kim, Behr, and Spafford illustrate the common workflow problems 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—unexpected work and bottlenecks.

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’s 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—unexpected work that grinds the system to a halt.

Sources of Work in IT

The way the authors differentiate between “business projects” generated by the company at large and “internal projects” generated by IT might at first glance seem to imply that IT is inherently separate from the rest of the organization, an attitude that the authors discourage later in the book. A potentially more useful distinction is that business projects advance the company’s business goals directly, while internal projects serve those same goals indirectly (for example, by improving overall efficiency). To make sure projects stay on track and maintain buy-in from the people involved, it’s important that any project be clearly aligned with the company’s goals—whether that project is internal to IT or in support of another division.

From a layman’s perspective, the type of IT changes the authors describe can often seem perplexing—such as when a program you’re using or your operating system mysteriously updates itself with no discernible change in performance. Nevertheless, these seemingly constant updates are vital to keep up with advances in technology, fix software bugs, close security vulnerabilities, and stay in compliance with ever-changing legal regulations. From a business perspective, these changes also arise as a result of user feedback and market research to determine how to better match a company’s products with customer demand.

Unexpected Work

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’t prioritized by importance, but rather by how vocal the person complaining about the issue is. What’s worse, unexpected work creates even more work 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.

(Shortform note: In the authors’ fictitious company, as well as in many real-world organizations, people have learned that the quickest way to get IT’s attention is to treat every problem like an emergency. However, this makes prioritizing difficult. One solution may be to implement a priority matrix, as described by Steven Covey in First Things First. While those tasks that are truly urgent will require immediate attention, Covey argues that the most important work is that which will have a significant impact but hasn’t yet risen to the level of an emergency. Making this category of work a priority will ideally prevent problems from becoming emergencies at all.)

The Bottleneck

The authors say that the other work stoppage in any system is the bottleneck (which the authors refer to as the constraint), defined as the one link in the chain that limits the speed of the entire production process. In the fictional example, the bottleneck is Brent, the lone engineer whose unique and exhaustive knowledge of Parts Unlimited’s computer systems makes him the indispensable go-to guy for every task IT tries to perform. As a result, IT can’t 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’t have time to document his work, which means his knowledge isn’t shared and IT becomes even more reliant on him as a crutch.

(Shortform note: One danger of the particular type of bottleneck Brent represents is that employees overloaded with so many tasks risk burning out from the combination of high demands, insufficient resources, and little or no recovery time between switching from one emergency to another. Though The Phoenix Project doesn’t address this directly, 75% of workers experience burnout at some point. Preventing workplace burnout requires listening to employees’ needs, curbing excessive overtime, and building a workplace culture based on clearly defined roles and expectations.)

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 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’s bottleneck is, the authors are clear that you can’t push work through your department any faster than your bottleneck will allow. 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.

(Shortform note: Though the authors derive most of their ideas about managing bottlenecks directly from The Goal, Goldratt makes some recommendations that aren’t echoed in The Phoenix Project. One is to decrease workstations’ idle time, which Kim, Behr, and Spafford caution against, as we’ll see in the following section. Another is to outsource the bottleneck’s functions, which The Phoenix Project’s authors also don’t recommend. In The Goal, Goldratt doesn’t discuss pesky human factors such as personality clashes, bureaucratic hold-ups, and company values that also contribute to the problem of bottlenecks and trying to unstop them.)

The Solution? The Three Ways

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 Ways can be summed up as 1) fast workflow, 2) quick feedback, and 3) continual improvement.

The 2 Most Common Workflow Problems & How to Fix Them