Organizations that Work on Fewer Projects at a Time Get More Done

On This Page

Get Your Personalized Guide to Agile

Get Your Personalized Guide to Agile

Instead of you sifting through thousands of agile articles and resources, I’ve handpicked some recommendations just for you.

By this point, most people seem to understand that multitasking is a myth and does not boost productivity.

It will undeniably take me longer to write you this email if I am concurrently attempting to finish an expense report, clean my kitchen and read yesterday’s sports news.

But we have yet to extend this thinking to our organizations.

Multi-Tasking at the Organizational Level

Just as individuals get less done when they attempt to multitask, organizations accomplish less when they attempt to do too many things at once.

Organizational multitasking is attempting to do too many projects concurrently.

I mentioned this to a senior vice president of a large company a few years ago.

She said, “Follow me,” and walked me into a large, theater-style meeting room where she and her direct reports had recently completed an annual planning exercise.

Sticky notes, each representing a project, dotted a 40-foot wall. Long lines were drawn to the right of each, representing the expected duration of the projects.

She asked, “Do you think we’re doing too many projects?”

I was far enough away I couldn’t read a single word on the sticky notes. But so many projects were on the wall, I simply said, “Probably.”

She told me she thought so, too.

And the next morning, all of her direct reports returned to that room where she said, “We’re trying to do too much. Start taking things off the wall.”

Everyone looked relieved as they started removing the lowest priority projects.

I followed up with her at the end of the year and asked how the year had gone and whether reducing the number of concurrent projects had helped.

“We had our best year ever. But we didn’t go far enough. We should have dropped more projects.”

Steve Jobs Focused on the 3%

When Steve Jobs returned to Apple in 1997, there were 350 products being developed. Within two years, Jobs reduced that by 97%, down to only ten products.

Every time an organization says yes to a product, it is saying no to some other product. Or at least it should be saying no. Often the organization says yes to both products and makes unbearably slow progress on both.

Instead, focus on the higher priority product and get it out. Only then should you start the second.

At the 1997 Worldwide Developers Conference, Steve Jobs addressed this the idea of focus by saying, “When you think about focusing, you think, ‘Well, focusing is saying yes.’ No! Focusing is about saying no.”

Forty Developers Shouldn’t Work on Eighty-Five Projects

One of my clients was struggling with this. On a pre-visit call they’d told me they had 40 developers. But in my first meeting with them, they said they had 85 ongoing projects.

I quickly flipped back through my notes and said, “But when we talked on the phone a few weeks ago, you said you have 40 developers.”

And my client said, “Yeah. 40 developers. 85 projects.”

He didn’t seem to think this was a problem until I pointed it out.

This was a small company and most new projects were initiated by a request from the CEO. I got him to agree that he’d only allow one new project to start for every two that finished.

I put no restrictions on him regarding the size of the projects. But I knew this would gradually bring down the number of ongoing, concurrent projects in that organization.

He wanted to know how long he’d have to abide by that rule. He was expecting me to give him a number of projects--perhaps 40 or 50 or 30, I suspect.

Instead I told him to keep starting one new project for every two that finished until he felt that every project was getting done fast enough. That would be the sign that the organizations could handle additional concurrent projects.

It was hard, but this CEO and organization lived with that rule until they were down to 18 concurrent projects, less than a quarter of what they’d started with.

The CEO, as well as senior developers, confirmed that things were going better than they ever had before.

More Gets Done If Less Is Done at a Time

In a Harvard Business Review article (“Getting the Most Out of Your Product Development Process”), the authors conclude that “projects get done faster if the organization takes on fewer at a time.”

This is absolutely my experience as well: organizations that work on fewer projects at a time get more done.

Focusing your organization on its most important projects, and delaying work on the less important, is a surefire strategy for delivering the most value as quickly as possible.

Mike Cohn

About the Author

Mike Cohn specializes in helping companies adopt and improve their use of agile processes and techniques to build extremely high-performance teams. He is the author of User Stories Applied for Agile Software Development, Agile Estimating and Planning, and Succeeding with Agile as well as the Better User Stories video course. Mike is a founding member of the Agile Alliance and Scrum Alliance and can be reached at hello@mountaingoatsoftware.com. If you want to succeed with agile, you can also have Mike email you a short tip each week.