Managing too many projects: rebalance one person's work

A person planning the week on a large wall calendar

When one person owns too many projects, decide what to move by comparing priority, dependencies, and acceptance criteria—not by counting projects alone. Map the work, identify what depends on that person, then reassign or pause a project and review the effects.

How do you map ownership across too many projects?

Start with a list of active projects, but do not use the list as a workload score. A project can take little attention this week and become urgent when a deadline approaches. Another can demand daily decisions even if its deliverable looks small.

For each project, record the accountable owner, the next concrete deliverable, its deadline, and its current status. Separate the owner from people who contribute. If several people help, name who answers for the outcome and who owns each piece of work.

Write down the source for the status and deadline. A status copied from an old meeting note may not describe what is happening now. Check the work or ask its owner before using it to make a change.

Describe what counts as done with acceptance criteria. A deliverable is easier to move when the next person can tell what they are expected to finish and how it will be checked. Brainis maintains a live model of company state with sources, freshness, and confidence. The company state page describes that product capability.

Use the number of projects as a reason to inspect the work, not as proof that one person is overloaded. The useful question is what decisions, deadlines, and unfinished work currently depend on that person.

Which dependencies make a project hard to move?

Trace each deliverable both backward and forward. Backward, list the work or approval that must happen first. Forward, note what waits for this deliverable. This shows what might stop or slip if the owner changes.

Then mark dependencies that rely on the current owner's knowledge or authority. The person may hold context that has not been written down, or may be the one who can approve a decision. Those are real handoff needs. A preference for keeping the same person is not, by itself, a dependency.

For each unresolved handoff, name a person responsible for the next step. Specify what they need to learn, decide, or provide, and when the team will check it. If there is no clear next step, the proposed move is not ready.

Approved strategies in Brainis compile into dependency-aware missions with owners, budgets, and acceptance criteria. The missions page describes those elements. You can also use the mission blocker response guide to think through work that cannot proceed until a blocker changes.

A dependency map should help you make a choice, not preserve every current arrangement. If a task depends on one person's knowledge, consider whether that knowledge can be transferred, documented, or replaced with a clear decision from someone else.

A business owner reviewing plans at a desk in the evening

How should you compare projects before changing ownership?

Compare projects by their intended outcomes, not by how visible or familiar they are. Write down what each project is meant to achieve and the acceptance criteria that show whether it achieved it. If either is unclear, settle that before comparing the work.

Next, consider the deadline, what depends on the next deliverable, and the consequences of waiting. A project with a later deadline may still block work that matters now. A near deadline may be movable if the cost of delay is low and the handoff would create less risk.

Estimate what a new owner would need: time, authority, budget, context, and support from other people. Separate information you have from guesses about effort or delay. Label uncertain points as assumptions, then decide whether you need to check them before moving the work.

Finally, record why each project should continue with its current owner, move, or pause. The reason makes the choice easier to revisit if conditions change. The binding constraint guide can help you examine which limit is controlling progress.

Example: A fictional small design studio has one person leading a client launch and an internal billing change. The launch depends on that person’s approval of the final work, while the billing change has a clear checklist and another team member who can take it. The studio compares deadlines, the work waiting on each deliverable, and what the new owner needs. It moves the billing change after transferring the checklist and open questions, rather than choosing by project count.

When should you reassign a project, and when should you pause it?

Reassign when another owner can take the work with the authority, context, and acceptance criteria needed to finish it. A handoff is more than changing a name in a tracker. Transfer the current state, open questions, key dependencies, and the next acceptance check. Make clear who can make decisions after the transfer.

Pause when a missing dependency or decision means further work is unlikely to help. A pause should have a reason, a condition for restarting, and a person responsible for checking that condition. Without those, the work may quietly disappear or return without anyone knowing what changed.

Before either move, check what it blocks elsewhere. Reassigning a person can shift pressure to another owner or delay work that depends on them. Pausing one deliverable can leave another team waiting without a usable next step. If the change creates a new gap, make that gap part of the decision rather than hiding it in the handoff.

For a handoff, agree on when the new owner will review the work against its acceptance criteria. For a pause, set when the decision owner will check the restart condition. The abort conditions guide offers another way to make the conditions for stopping or restarting explicit.

A manager talking with a small team in a calm office

What should you review after the change?

Set the review point around the next deliverable or decision, rather than picking a date with no connection to the work. At that point, check whether the new owner received enough context and has the authority to proceed. If not, fix the handoff before treating the person as responsible for a missed outcome.

Compare progress with the acceptance criteria. Do not use the number of projects on the owner’s list as the measure of whether the change helped. Ask whether the deliverable moved, whether anything became blocked, and whether the reason for moving or pausing still holds.

Record new blockers and decide who will address them. If the handoff created a dependency that no one expected, update the work plan and assign a next step. If the pause condition has changed, the decision owner can choose whether to restart, keep the work paused, or stop it.

Start with one project change. Review what happened before applying the same approach to the rest of the list. That gives you a chance to improve how you describe ownership and handoffs. The missions page describes how Brainis represents owners, budgets, dependencies, and acceptance criteria in missions.

The aim is not to make every person's project list look balanced. It is to put work with an owner who can move it, make the cost of a pause visible, and check whether the change improved delivery.