Three Projects At Once: What Actually Ships

You have three projects and one team, and every client has been told theirs is moving. Everything is progressing. Nothing is finishing.

Running three projects in parallel usually delivers all three later than running two in sequence and one alongside. The reason is switching cost: every move between projects burns time that produces nothing, and that time scales with how many things a person holds in their head. Sequencing does not mean anybody works less. It means less of the work is spent reloading context.

Do the arithmetic with your own numbers

Do not take a figure from an article, including this one. Use your team's real numbers, because the shape of the answer matters more than the size.

Pick a person and count, honestly, how many times in a day they move between projects. Then ask them how long it takes to get properly back into a piece of work after moving away from it. Most people can answer that within a few minutes of accuracy.

Multiply. Say the answer is six switches and fifteen minutes each. That is an hour and a half a day gone before anyone has done anything wrong, roughly a day and a half a week, per person. Change the inputs to whatever your team reports and the conclusion holds: the cost is much larger than people assume, and it is invisible because it never appears against a task. It is the same sum behind what two interruptions an hour do to a day.

Then do it again for a person working on two projects rather than three. Fewer things to hold means fewer switches and shorter reload time. That difference is the whole argument.

Why parallel feels faster and is not

Three reasons parallel keeps winning arguments it should lose.

• Everything looks alive. Three projects with movement feel healthier than two finished and one not started, even when the second version delivered more.
• Nobody wants to say no. Sequencing means telling a client they are third. Parallel lets you avoid that conversation and pay for it later, although there is a way of saying no without sounding difficult.
• Progress is easier to show than completion. A status update with three lines of movement reads well. It is also how a project reaches ninety percent and stays there for two months.

The cost lands somewhere less visible. Unfinished work has no value. A project that is eighty percent done is worth nothing to the client until it ships, and three projects at eighty percent is three things worth nothing.

What sequencing actually looks like

Sequencing does not mean freezing two projects and telling those clients to wait in silence. It means being deliberate about where the concentrated effort goes.

• Pick a lead project. The one with the nearest real deadline, or the one where finishing unblocks the most other things.
• Give it the whole team's mornings. Not the whole day. A protected block that nothing else interrupts.
• Keep the other two moving on a maintenance level. Answer questions, unblock others, do the small items. Do not start large pieces on them.
• Say the order out loud, to the team and to the clients. "You are second, and here is when you become first" is a manageable message. Being quietly deprioritised is not.
• Finish, then rotate. The finished project leaves the list entirely. That is the payoff, and it only exists if you actually stop.

Where parallel is genuinely correct

There are real exceptions.

• The projects need different skills and different people, so nobody switches at all. Two projects on one person's plate is the problem, not two projects on a team's, so watch for the signs someone is drowning when the load lands on one person.
• One project is blocked on someone outside the team and there is nothing to do but wait.
• A project is small enough to finish in a day or two. Sequencing overhead exceeds the switching cost.

If none of those apply, you are probably paying the switching cost without getting anything for it.

The conversation with the client

The hardest part is not the plan. It is telling somebody they are second.

What works is being specific rather than apologetic. Give a date when their project becomes the lead one, say what will move in the meantime, and then actually hit that date. Clients are far more tolerant of a clear position than of three months of "it is progressing".

What does not work is claiming everything is on track when it is not. That buys a few weeks and costs the relationship.

Run the test for one month

Pick one project, protect the mornings, drop the others to maintenance and see what ships. Compare that month against the previous one, counting only finished work rather than movement.

Most teams are surprised by the size of the gap. Not because anyone worked harder, but because far less of the month went into remembering where they were.