Everything Moves an Inch, Nothing Moves a Mile: The Math of Running Too Many Projects

"In general I find companies run about three times as many projects as they actually have the bandwidth for." That was Mike Dalton of Guided Innovation, opening his session on what he calls the high-flow portfolio at the PDMA summit in Atlanta this October. Then he spent the next half hour showing us, with a board game and a pencil, exactly what that costs.

His summary of what happens to all those projects: "everything's moving an inch and nothing's moving a mile."

One extra yes a quarter

Dalton's simulation is simple enough to run on a whiteboard. Picture an organization that can do 12 units of work a quarter, where any single project can only absorb three of those units at a time. That team's bandwidth is four projects. Run four at a time and each one finishes in two quarters, and new products roll out at a steady clip.

Now say yes to just one extra opportunity per quarter. It doesn't sound like much, and that's the point – it's the kind of yes that gets made in a hallway because the idea is good and somebody important likes it. In the version he ran for us, after eight quarters the overloaded pipeline had a 27-month cycle time and only nine products selling. The throttled pipeline, which only let in two new projects a quarter, ended with 14 products selling and 44% more cumulative cash flow, from doing less.

He's published a version of the same exercise with slightly different settings, where one extra project a quarter stretches cycle time from six months to 22 and cuts two-year cash flow by about two-thirds. The exact numbers depend on the setup, and it is a simulation, not field data. But the shape doesn't change: every extra project makes every other project slower, and the slowdown compounds.

Dalton's real-client results point the same direction. At one industrial equipment manufacturer whose projects had slowed to a crawl, he set a limit of five projects in execution at any given time, and within a year they'd cut time-to-market in half and launched more successful products the next year than in the previous three.

Why it compounds

Part of it is plain arithmetic. If your team can run four projects at full speed and you run six, Dalton points out, everything takes at least 50% longer on paper, because the same people are spread across more work.

The bigger part is switching. He had the whole room do a quick exercise: write out a couple of short sequences straight through, then do it again while switching back and forth between them, a letter at a time. Most people found the switching version took around twice as long, a few said three times, and the mistakes went up – even people's handwriting got worse. That's a two-minute pencil exercise. A product team switching between six half-finished initiatives is doing the same thing all week, with much more expensive mistakes.

Software teams have it worse in one way, because we can't see our pile. As Dalton has written, a factory with too much work in progress can walk the floor and see parts stacked to the ceiling waiting for the bottleneck, but in knowledge work "most of the WIP is hidden." Six half-finished initiatives sitting in a project tracker don't look like a jam. They look like everyone being busy, which is exactly how it gets mistaken for productivity.

The yes that causes it

The portfolio doesn't get overloaded by accident. It gets overloaded one reasonable yes at a time.

Robert Cooper, who created the Stage-Gate process and gave the keynote at the same summit, has a name for the specific kind of yes that does the damage. In his paper on pipeline gridlock, he calls a project approval without a commitment of people a "hollow Go decision," and he argues that if the people aren't available now or in the immediate future, the project can't get a Go. When the yes doesn't cost anyone their time, he writes, there's effectively "no limit to the availability of people, and thus too many projects get approved."

At the governance workshop the same day, one of the facilitators quoted a client who'd put it about as well as I've heard it: "I'd rather have two out the door than 10 stuck in stage four." And Cooper's latest writing suggests this isn't getting better. In a piece for PDMA this fall, he describes executives telling him "they have lost control of their project portfolio."

Incentives make it worse. Dalton told a story about a client whose product development team needed supply chain's help to get new products out, and supply chain said no, because their bonus that year was tied to cost-reduction projects. Both teams were doing exactly what they were paid to do, and the new products sat. The fix was an explicit mix by segment – in one segment, three product development projects for every cost-down project – so that everyone was working from the same priorities instead of their own.

The backlog is a waiting room, not a parking lot

Dalton's answer is a backlog with a real job. When a new project is proposed, you evaluate whether it's a good project on its own merits, and then separately, whether you have the people to run it right now. If you don't, it waits in the backlog with a planned start date that won't interfere with the work already underway, and it starts when something else finishes.

I'd add one condition, because I've seen backlogs turn into exactly the problem they're meant to solve. A backlog only works as a waiting room for things you've actually decided to do. When "just add it to the backlog" becomes the way a team avoids deciding, you end up with hundreds of maybes and a team that feels like it's drowning in them. I once closed hundreds of backlog issues and nobody was upset. The things that were never going to happen were already costing us attention, and closing them cost nothing.

So the backlog that helps has two rules: everything in it is a project somebody has said yes to, and everything in it has a rough idea of when it'll start. Everything else gets closed.

Lead people to the change

The hardest part of all this isn't the math. It's getting a leadership team to say no to good ideas, which feels like going backward. Dalton's advice on that: "Never lead with the change. You lead people to the change." Get agreement on the problem first, then the direction, and then let people find the holes in it themselves.

The tool he's found works best for that is the simulation itself. It's hard to argue with a board game you just lost, and a leadership team that watches its own cash flow drop by playing one extra yes a quarter tends to remember it longer than a slide.

If you run a software company, you can do a rough version of this today. Count the initiatives your team is actively working on right now, the real number, including the ones nobody has formally started but somebody is quietly working on. Then ask how many your team could run at full speed. If the first number is a lot bigger than the second, you don't need more people yet. You need fewer yeses.