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

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

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.

What’s Your Experience?

Is your organization doing too many projects at the same time? How would focusing on the smaller set of most critical projects change your world? How have you been able to convince people? Please share your thoughts where this post was originally published, on the Mountain Goat Software blog.

If you liked this article, you can sign up to receive my one best, short tip about agile each week. These tips aren't online and signing up is the only way to receive them

Stelvio Gori

Senior Manager / Consultant at Knowità

4y

Fully agree. Start less, finish more!

Sure! I totally agree.

Like
Reply
Luke N.

Senior Export Grain Logistics Specialist at Bunge North America

4y

Makes complete sense. Rally the troops on a few tasks...amass more talent and knowlegde and laser focus to complete tasks. Sounds like SCRUM!

Like
Reply
Mansoor Shaikh

Vice President - JP Morgan Chase & Co | 3X-Oracle Cloud | AWS | Java | Rest Assured | Selenium | Cucumber | TestNG | Spring boot | Kafka | Micro services

4y

Very true. WIP should be kept to a minimum which can be managed.

Like
Reply
Jonathan Walker

Senior Business Analyst at Hadrian Consulting

4y

Agreed. Too many tasks on an individuals mind is a distraction; diverting the focus away from the priorities. Right now I’m ‘wearing too many hats’ on my current project and the workload is overwhelming. I find my time management skills are lacking and the pressures I put on myself cause more problems than they solve.

Like
Reply

To view or add a comment, sign in

Insights from the community

Explore topics