Orangescrum
Documentation index for AI agents (llms.txt). A markdown version of this page is available at /optimization/multi-project-scheduling.md or by requesting this URL with the header Accept: text/markdown.
Planning technique

Multi-Project Scheduling, Explained Properly

Each project plan is fine on its own. The problem is that they all assume the same engineer. Here is how to plan above the project, and what Orangescrum shows you.

What is multi-project scheduling?

Multi-project scheduling means planning several projects at once when they draw on the same finite pool of people. The difficulty is rarely any individual plan. It is that each project is scheduled as though it had the team to itself, so one engineer ends up committed at full capacity to three projects simultaneously. The technique is to plan capacity at the level above the project: know who is shared, decide in advance which project wins when they collide, and sequence the demand instead of accepting all of it at once. In practice this usually means running fewer projects concurrently and finishing each of them sooner, rather than having everything in flight and nothing delivered.

Where portfolios quietly fall apart

  • Every plan assumes the whole teamThree project managers each build a sensible schedule around the same six people. Each plan works. The three together need roughly twice the organisation you have.
  • Priority is set inside projects, never across themEach project has its own ranked list, so when two of them want the same person on Tuesday there is no rule for who wins, and the loudest sponsor decides.
  • Too many projects are in flight at onceStarting a project feels free. Every extra one adds context switching and stretches the ones already running, so the whole portfolio slows down together.
  • Leadership cannot tell which project to stopStatus arrives one project at a time, all of it amber, with no view of who is shared. Without that view the only available decision is to ask everyone to try harder.

How to schedule across projects

  1. List the people who are genuinely sharedUsually a small number of specialists cause most collisions. Name them. The portfolio schedule is really a schedule for those people.
  2. Rank the projects once, in one placeOne ordered list for the whole organisation, agreed by the people who fund the work. Without it, every collision is escalated and decided by whoever pushes hardest.
  3. Limit how many projects run at the same timePick a number and hold it. A new project starts when one finishes. This single rule tends to do more for delivery dates than any amount of replanning.
  4. Stagger demand for the scarce skillsSequence the phases that need the shared specialist so they do not overlap, even if it delays a start date. A queue you planned beats a queue you discover.
  5. Review capacity above the project, every weekLook at the workload view across projects, not the individual plans. The collisions only ever appear at that level.

What Orangescrum does not do here

Orangescrum shows you the portfolio. It does not schedule it. There is no solver that takes five projects, one shared team, and a set of deadlines and returns an optimal allocation. Programmes roll several projects into one view, resource management shows a person's commitments across all of them, and the workload heat map shows who is over-allocated and when. What it will not do is decide which project should give way, move work between projects on your behalf, or rebalance the portfolio automatically. Programmes, resource management, and the workload heat map are on the Cloud Premium plan and included in Self-Hosted.

Multi-project scheduling <em>FAQ</em>

Does Orangescrum automatically schedule work across multiple projects?
No. There is no portfolio optimiser and no cross-project allocation engine. Orangescrum makes shared capacity visible, through programmes, resource management, and the workload heat map, so a human can see the collision and decide which project gives way. The decision is not calculated for you.
Can I see one person's total load across every project?
Yes. That is exactly what resource management and the workload heat map are for. Allocation is held per person rather than per project, so their commitments across the portfolio appear together and over-allocation is visible.
How many projects should run at once?
Fewer than you are running now, almost certainly. The useful test is whether your shared specialists are committed to more than two things in the same week. If they are, the portfolio is already past its limit and everything is running slowly.
What happens when two projects need the same person on the same day?
Orangescrum shows it as over-allocation on the workload view. It does not resolve it. Somebody with the authority to decide has to choose which project waits, which is why a single ranked list of projects matters so much.
Which plan or edition do I need for this?
Programmes, resource management, and the workload heat map are on the Cloud Premium plan and included in Self-Hosted. The project calendar is in all three editions. The Gantt chart and dependencies are in Cloud and Self-Hosted, with critical path on Cloud Premium and in Self-Hosted.
Is a programme the same as a portfolio?
Not quite. A programme is a set of projects delivering one connected outcome, so they share goals as well as people. A portfolio is everything the organisation has running, connected or not. Orangescrum groups projects into programmes, and most teams use that grouping for portfolio reporting too.
What is the single biggest fix for multi-project scheduling?
Reducing the number of projects in flight. It is unpopular because starting a project feels like progress, but it usually improves every date on the board at once, without hiring anyone.

See the portfolio, not just the project

Free 14 day trial, no credit card. Every plan includes unlimited users.