Stop multitasking; it just slows you down

By Peter Longini, Managing Editor

Until a few years ago, Confluence - a Pittsburgh-based developer of specialty software for the financial industry - considered itself to be a top-tier conventional project management shop.  As company COO Kirk Botula recently recalled, "We were doing complete project plans and critical path project management.  We were using best practices, or at least what still pass for best practices.  We were doing it by the book."  Yet the company's projects kept falling behind schedule, wandering out of scope, and exceeding their budget expectations - just as those of its competitors did. 

Today, however, the company's projects take anywhere from half to a quarter the time they used to, and the level of resources they devote to those projects is essentially unchanged, providing the firm with a huge competitive advantage.  So how could that happen?  How can a project which used to take 200 days get done in as few as 10?  According to Botula, it required looking at the flow of work in an entirely different way.  And a book by Israeli physicist Eli Goldratt on the ‘theory of constraints,' or TOC, provided him with an early glimpse.

Originally created to help maximize manufacturing throughput, Goldratt's theory provided a general approach for analyzing and understanding constraints within systems and then managing them.  "Around 1999, he applied it to project management, which was really about how to make a single product as fast as possible.  Then the next year, some other people developed this idea of applying the theory of constraints to a multiple-product environment," Botula explained.  For Confluence, that represented the breakthrough.

Sophie's choice

In essence, the theory requires managers and executives to make choices.  It is a point Botula makes by citing a scene from the 1982 movie ‘Sophie's Choice,' a World War II drama in which a mother is forced to choose which of her two children will live.  "You achieve speed by what really boils down to Sophie's Choice - being willing to decide which one is more important than the other," he said.  If you can actually say ‘no' - which most executive managers can't do because the biggest problem in management is the inability to say no - then you can prioritize.  And if you can prioritize, you can gain speed.  The reason why the Standish Group's yearly Chaos Report shows that only about 30 percent of software projects are on time, on budget, and within scope is multitasking - because no one can say ‘no.'  Instead, they're trying to run everything through the system at the same time. 

At the heart of the TOC approach is the notion that a chain of resources is involved sequentially in creating a product.  In the case of software development, those links include product management, engineering, architecture, testing, quality assurance, and production.  Each of those steps takes time, and in conventional project management, time estimates tend to be conservative.  Then, when the overall timeline is constructed, these bloated estimates are stacked end to end. 

"What's really happening is that when a task completes early, it just sits around for the deadline.  When the task goes late, it still pushes the whole project late.  So in normal project management there's a bias, there's a filter, that essentially says the project will never be early because there are deadlines to make sure nothing can come in early," Botula noted.  "That's why you almost never hear of projects completing early - because the system is designed to prevent it." 

Protecting the drummer

Whichever of those resources is the most constrained - in essence, the bottleneck where work backs up - is the one that effectively limits the speed for all the rest.  It is what Botula refers to as the ‘drum' resource, because it sets the pace for all the remaining steps.  So protecting that resource from being pulled off task to do other chores is critical.  "The constrained resource really becomes the money pump for the entire shop.  No matter how efficient, no matter how fast all the business units are, the chain is only as strong as its weakest link  That's where the analogy ‘critical chain' comes from," he said.  "As a result, we identify that resource in the project and protect them: we get them out of standing meetings because they're the valve that regulates the flow through the shop.  You allow them to focus, you don't distract them, you protect them, and protect their time."

"When you put projects in the system, make sure your drum resource has only one project at a time; the system can't go any faster than that anyway," Botula observed.  "We frequently see people saying that we need to do more than one thing because the client came in and said we had to do both.  But guess what?  Every time they say ‘do both' they're slowing down the process.  It's like pushing a lawnmower into high grass or pushing a pencil into an electric pencil sharpener - you overload the machine.  And that's what happens when you push projects into the system.  What we do is we allow the drum resource to pull projects in at the rate it can take them." 

Shifting resources

But there are also other ways of dealing with constraints and speeding the flow of work, Botula suggested.  "Let's say our business is constrained, that we can build stuff faster than we can test it.  The first thing you do is free up your testers' time, make sure that testing is all they're doing.  The second thing you do is you begin to move people out of coding and into testing because if you're coding stuff faster than you can test it there's no point in coding any more.  So you move resources over.  Then if you've moved as many resources as you can and you're still backed up, that's when you hire more people.  But you can do a couple of things with the exact same level of resources that maximize the flow through the system before you have to add to staff," he said.  

In adopting Critical Chain methodology, Confluence followed the path of conventional change management.  They hired an experienced consultant, made sure the executive team was on board, crafted a detailed plan, and communicated it relentlessly to the company's staff.  Training in the method's techniques was also required.  And the company acquired some specialized software to track the program's various metrics.  Even so, according to Botula, interested companies can greatly accelerate their product development without incurring either the cost or complexity of those systems. 

"It just boils down to prioritize, sequence, staff the project so it can't take anymore people, and then let the people do their work without multi-tasking," he said.  "If you wanted to do it free, that's how you do it and the system will go as fast as it can.  On the other hand, it's kind of complicated and twitchy with statistics and things like that, and a lot of my peers don't use it because they think it's project management stuff.  But the fact is that there's profitability in speed.  It's the gun that everyone wants to bring to the knife fight, but it's just not on their radar."  

Comments can be submitted to the editor at This e-mail address is being protected from spam bots, you need JavaScript enabled to view it . 

To read our latest articles in Inside Product Strategy™, click here.