As someone who works on a cross-project planning tool, a good chunk of my week goes on calls with project managers. After enough of them, you start hearing the same conversation, almost word for word.
It goes like this:
We’ve got people spread across three or four projects. Every project has its own board. Nobody can see what a person is actually holding. And it always surfaces at sprint planning, because that’s the moment somebody has to commit to something.
The questions are always some version of the same thing.
If this person drops to four hours a day, what happens to everything else?
If half of this moves to somebody else, does the date still hold?
Who’s actually free in three weeks?
And the answer is always the same one, too: there’s nowhere in Jira to ask.
Let’s say it plainly. Jira has no object representing one person’s total commitment. It has projects, boards and sprints. A person is a field on a work item inside them.
So before you go looking for a fix, examine which kind of resource conflict you’ve actually got. There are three. They occur for different reasons, they need different responses, and Jira sheds light on a different amount of each.
Kind 1: overallocation
One person, more work than hours, same window. The simplest kind, and the only one Jira will almost show you.
You can get close natively.
Put Original Estimate on your work items, then run assignee = sam AND duedate >= startOfWeek() AND duedate <= endOfWeek() and add it up.
Or drop a Workload Pie Chart gadget on a dashboard with a saved filter as its source and Original Estimate as the statistic. Not elegant. Does the job.
Here’s where it falls over, though. That number has no dates inside it.
It’ll happily tell you Sam has 150 hours this month and never mention that 60 of them land in launch week.
And it assumes everybody has the same capacity, which stops being true the second somebody goes part-time, picks up support duty, or books a holiday. In recent years that’s got harder, not easier — most teams I talk to now have people in two or three countries, and a public holiday in one of them is invisible to everyone else.
That’s where you might need an additional allocation layer to account for differences in individual capacity, working schedules, and local holidays.
In Planyway for Jira, each person’s capacity is based on their own work schedule, so a 30-hour week counts as 30, and time off and country-specific holidays are factored in before availability is calculated.
Resource overallocation turns into a bar crossing a line instead of a number you have to sit and interpret.
Kind 2: contention between projects
Two projects need access to the same person in the same window, and neither project has any idea the other exists.
This is the one from that conversation, and native Jira structurally cannot show it. Boards are scoped to a project. Each project manager looks at their own board, sees a perfectly reasonable plan, and commits. The conflict lives in the gap between two boards, and nothing in Jira is looking there.
So what happens instead? A status meeting. Where the decision runs on anecdotal evidence and whatever the power relations in the room happen to be, and whoever describes their deadline most convincingly walks away with Yana. That’s not resource management.
A more reliable approach is to look at each person’s workload across all their projects.
In Planyway, for example, you can group the timeline by assignee across spaces, so Yana appears once with all her assigned work, regardless of which project it belongs to. This makes overlapping commitments easier to spot and gives the team something concrete to discuss when priorities conflict.
(P.S. Watch a more detailed walkthrough of our workload view here.)
Kind 3: the key-person conflict
One person is the only one who can do the thing. Everything that needs them queues up behind them, and rescheduling doesn’t help, because there’s nowhere to reschedule to.
Jira has nothing for you here. There’s no skills data in Jira — no field for what somebody can do, no way to ask who else could pick this up. You either know your development team or you don’t.
Still worth naming, because the nature of this one is different and so is the fix. It isn’t scheduling. It’s pairing somebody alongside them for a quarter, or accepting that this person is a hard constraint on every plan that touches their area. Teams that keep hitting the same name every month don’t have a scheduling problem. They have a staffing problem in a scheduling costume.
How to resolve conflicts: resource leveling, in order
Once you can see the thing, there are only three moves. Resource leveling is just making them deliberately instead of at 9pm the night before. There are many other ways to slice it, but these three are what you actually control.
- Move the dates. Cheapest option, always try it first. If one project has float, slide it. Check dependencies before you drag anything, though — moving a task that three others are waiting on is never free.
- Move the people. Reassign to whoever else can do it. Works when skills overlap, which is exactly what Kind 3 tells you whether to expect.
- Move the scope. Nobody’s favourite. Frequently the right answer. If the dates can’t move and nobody else can do the work, then the work gets smaller or something gets cut. Pretending otherwise doesn’t solve anything, it just relocates the problem to the end of the sprint.
(Here's what it looks like in Planyway)
Try them in that order. Teams that jump straight to “we need more resources” usually haven’t tried the first two — and Brooks’s law still applies, so adding people to something already late mostly leads to it being later. Hiring doesn’t fix a conflict that lands next Tuesday.
Keeping them from coming back
Three habits. None of them cost anything.
- Check availability before you commit, not after. Most conflicts get created the moment a project manager agrees to a date without looking at who’s free. The check takes a minute, if you have somewhere to do it.
- Agree priorities above the project level. When two projects collide, somebody has to say which one wins. That’s a governance question, not a scheduling one, and it belongs to whoever runs the business — not to the two of you at 4pm on a Friday. Cooperation between PMs helps enormously, but it needs something to cooperate about. Without it, every conflict turns into a negotiation and the loudest interest takes the prize.
- Look two weeks out, every week. A conflict spotted a fortnight ahead is a scheduling decision. The same conflict on Monday morning is a crisis, and crises get resolved badly. Doing this weekly also gives you something useful for future planning: after a couple of months you can see which factors keep contributing to the same collisions, and that’s research you can actually act on.
None of this makes the underlying resource scarcity go away. The arithmetic is boring and it doesn’t change: more work than people, in most teams, in most years, and no tool has ever fixed that.
Though scarcity isn’t the only shape it takes. There’s a "resource curse" in project management too, and it catches people out. The worst conflicts aren't those in short-staffed teams — they are often in teams big enough that nobody ever had to say no. So everything got a yes, and the collisions moved downstream to where nobody was looking.
Resource availability on paper isn’t the same thing as anybody being free.
So what changes isn’t how many people you have. It’s who finds out about the collision, and when.
And honestly, that’s the whole difference. Between a plan you adjust on Tuesday, and a plan you explain to everyone on Friday.
