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 is the first of the Three Ways from The Phoenix Project? How can you create a faster, more efficient workflow among your IT team?
In their book The Phoenix Project, authors Kim, Behr, and Spafford lay out the three ways to improve your IT department. The First Way involves improving the department’s workflow, which isn’t always an easy task.
Here’s a look at The First Way and how you can increase the speed of your IT department.
The Pillars of Production
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.
In this article, we are going to focus on The First Way.
The First Way: Fast Workflow
The First Way, “fast workflow,” may sound like a goal 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.
To begin with, managing workflow is impossible without a way to monitor its progress. The authors repeatedly recommend using a kanban board (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.
(Shortform note: The kanban boards the authors mention are a production tool first developed by Toyota to visually track issues on their car production lines. They have since become a standard tool for tracking work through any kind of production process, and while kanban boards can be digital, the simplest ones—as depicted in The Phoenix Project—are just whiteboards with vertical columns depicting each stage in the production process and sticky notes representing each project moving through the system. In Personal Kanban, Jim Benson and Tonianne DeMaria Barry describe how kanban boards can be used by individuals to manage tasks in their daily work and personal lives.)
As you monitor your department’s workflow, you’ll also become aware of all the different avenues by which work—often unexpected work—enters and confounds the flow of operations. People in many organizations have grown used to calling IT staff directly to fix what they perceive as “urgent” 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. The authors stress that doing so is vitally important to speeding up IT production.
(Shortform note: Unexpected interruptions are doubly deadly to IT workflow. Not only do they back up the whole production process, as the authors describe, but they also hinder individual workers’ ability to focus on any given task. In Eat That Frog!, Brian Tracy details the cost of multitasking—or “task shifting,” as he more accurately describes it. After being interrupted, it takes 17 minutes to completely refocus and continue with your work. Multiply that by the number of IT personnel who are interrupted by one crisis after another, and it’s clear how badly unexpected disruptions can impact overall efficiency.)
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’ 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, sometimes on the order of days or weeks instead of months or years. If there’s 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.
Individual Focus Applied to a Team The authors’ suggestion to break large projects into small, discrete units is a common piece of advice that productivity experts usually prescribe to individual workers. For example, in Eat That Frog!, Tracy lists breaking tasks into actionable steps as both a cornerstone for making large goals achievable and an effective way to avoid distraction. In the context of The Phoenix Project, that distraction takes the form of nonstop demands on IT’s time. At Google, software designer Jake Knapp devised a method for addressing that form of distraction by taking personal productivity tools and applying them to achieving team goals. In Sprint, he and co-authors John Zeratsky and Braden Kowitz describe a process for gathering a team and shutting out distractions such as email and meetings for a specific amount of time—such as a week—in order to complete the design of a tightly focused product with an incredibly rapid turnaround. |
Open Your Bottleneck
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’ll quickly identify where the bottleneck is—most likely one overburdened workstation. Though it may be counterintuitive, workstations need idle time in order for work not to pile up. 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:
Wait time = Percent of time busy / Percent of time idle
According to this formula, wait times at a station that’s 80% busy and 20% idle will be four times longer than at a station that’s 50% busy and 50% idle.
(Shortform note: The authors’ suggestion that workstations and employees should have a certain amount of idle time goes against the grain of using efficiency as a way to cram in even more work. In addition to the authors’ mathematical reasoning, some studies have shown that downtime on the job is vital to mental health and productivity. Some research has revealed that the brain requires regular rest periods throughout the day to maintain its full cognitive function. Nevertheless, we must note that in order to be productive, downtime should be planned and not the result of unforeseen equipment breakdowns or poor communication.)
Once you’ve identified your bottleneck, you can arrange your workflow so that you don’t send work to the bottleneck faster than it can handle. Tracking work will also let you know if any of the bottleneck’s 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, 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.
(Shortform note: What the authors describe is a formalized process to convert individual knowledge into institutional knowledge. However, individual knowledge includes more than practices and procedures that can be written down. Individuals have skills and intuitions that can only be acquired and passed on through training and experience. Documentation is certainly vital, but to truly build institutional knowledge, a business must make its knowledge easily accessible to employees while encouraging seasoned workers to mentor new team members, even as early as the onboarding process.)
———End of Preview———
Like what you just read? Read the rest of the world's best book summary and analysis of Gene Kim, Kevin Behr, and George Spafford's "The Phoenix Project" at Shortform.
Here's what you'll find in our full The Phoenix Project summary:
- Why a poorly-run IT department will destroy a business
- The three pillars of IT management recommended for any modern business
- A fictional case study about a man who turns around an auto parts company