Resource loadMultiple projectsConflict

Four projects all “fully staffed”? If the load board cannot show conflicts, overtime becomes the default fix

The same key employee was singled out by four project managers, yet all four Gantt charts showed green lights. It's not that people are not dedicated; the conflicts are simply never calculated for you to see. A common pattern of multi-project failure: each project is reasonable locally, but combined, they overwhelm the key personnel.

Updated 2026-08-27 ~8 min read Manufacturing digitalization · PMS · Projects

What you'll take away

  • Resource allocation is constrained by available working hours; humans are not unlimited containers.
  • Conflicts should be exposed during the planning stage, not buffered with weekend overtime.
  • Priority arbitration rules take precedence over a poaching culture; the results are recorded in the plan changes, and private personnel swaps are prohibited.
  • In the early stage, look at capability gaps by role, and during the four-week execution window, assign to named resources.
  • Overload warnings should be brought to the program portfolio meetings and the war room, so that the person involved is not left to handle it alone.

The four green lights at the assembly

The program manager asked, 'Will there be enough architects next week?' The four project managers nodded at the same time — each of their Gantt charts listed the same engineer Zhang, and none of them had filled in the allocated working hours. After the meeting, Engineer Zhang opened his calendar: reviews, integration testing, client site visits, three days stacked together. At the planning level, 'resources are sufficient,' but physically, he is already overworked.

A common pattern in multiple project failures is not that a particular project manager is incompetent, but that the organization defaults to using overtime as a buffer until key personnel leave or critical milestones suffer a chain reaction of failures. The task of resource management is not to find out who is not working hard, but to visualize conflicts during the planning stage and arbitrate them using priority rules.

A table that only shows names, without binding force

statementactually happenedConsequence
Engineer Zhang took on this projectOnly listed by name, without filling in a personReal conflicts are invisible
Everyone hang in thereUse overtime to eat away the overloadQuality drops, risk of resignation rises
Save client A firstIrregular private poaching of personnelClient B promises to be sacrificed and has no record
All the roles have been assigned.It was only discovered during the execution that no one had signed.Temporarily conscripting workers results in losses in both cost and quality
The load dashboard looks too ugly to open.Keep pretendingGroup decisions lack a single source of facts

On-site spot check: randomly select a key personnel and see if they can view the planned work hours broken down by project for the next four weeks, available percentages, vacations, workload rate, and conflicting task list. If they can't see it, scheduling the portfolio is just flying blind.

How should the load be calculated to be considered valid

Minimum algorithm (threshold adjustable):

  • Available working hours = Calendar working hours × Availability percentage − Approved leave
  • Assigned = Sum of planned working hours for each project task (including approved but not yet started)
  • Load factor = Assigned / Available Work Hours

Full-load alarms, obvious overload escalation; consecutive two weeks of overload → forced entry into arbitration agenda. Looking at only this week is not enough: this week may seem manageable, but the third week, when two milestones overlap, will trigger a breakdown. Portfolio managers should retain key personnel and not allocate them lightly, specifically for handling changes and firefighting—fill up the schedule before discussing change control, conflicts will almost inevitably lead to overtime.

Common reasons it can't be calculated: by default, each person can be assigned infinitely, tasks have only start and end dates without people assigned, each project's Gantt chart is independent and not consolidated, there are no arbitration rules, project initiation is executed by roles without implementation, and overload is not governed. Fill in whichever part is missing; don't jump to 'intelligent recommendations' first—when skill tags are missing, recommendations will only lose trust faster.

Character layer, named layer

Identify capability gaps in roles for project approval and pre-sales (need several senior implementers and one data engineer); during the four-week execution window, responsibilities must be assigned by name, otherwise the gaps will explode during the on-site week. Skill tags do not need to be very detailed at the beginning, just cover scarce roles first. For part-time and production line support, be sure to set an availability percentage: by default, full allocation is the primary source of load distortion.

JEDP-PMS supports multi-project planning, work reporting, project portfolios, and command centers; planning modes include waterfall/agile/incremental and Gantt, kanban. Resource capabilities need to be applied to load calculation, conflict lists, and arbitration results written back to the plan, rather than to the address book. Availability is connected to personnel calendars and vacations; assignments are based on task-level planned hours and named individuals; the load board provides views by person/role/project combination; at the role level, gaps are identified first, then matched with skills and named resources; actual work reporting and overtime are written back to discover systematic underestimation.

Arbitration: Rules come first, then voices

Example sequence for writing system and making system options:

  1. Customer contract commitments take precedence over penalties for breach
  2. Safety / Regulatory / Line-stop Related Priority
  3. Same level by combination strategy (strategy, output value, payment node)
  4. The results must be documented in the plan changes and stakeholder notifications; private verbal personnel changes are prohibited.

Without a written decision, overload tasks will be privately added back to conflicting tasks by the project manager after the meeting. Arbitration can suggest a delay, but cross-project sacrifices must be confirmed at the portfolio level—otherwise, strong projects will always win by raising their voices, and weak projects will silently postpone.

Regular meetings should focus on 'people', not just project indicators.

The regular joint meeting always looks at a single table: which personnel are significantly overloaded in the next four weeks, which projects the tasks come from, and which milestones are in conflict. The suggested discussion sequence is: first confirm the data (whether the estimated time is unrealistic, whether leave has not been recorded) → then apply arbitration rules → finally form a written decision (which milestone to keep, which task to postpone, whether to use external help or reduce the scope).

Useful observations: the number of people overloaded and the number of consecutive weeks (don't just look at the average), planned load vs. actual reported work, the proportion of overtime hours, the time taken to close conflict resolutions, and the number of unnamed role gaps. If overtime increases while the load indicator is still green, it indicates that the metric is being masked by physical effort. Relying on overtime to maintain a green indicator in the long term essentially means overdrawing human capital, which will eventually manifest in project costs as quality incidents or turnover.

Check the lights against the cost and changes

Overload often comes with both explicit overtime and implicit rework. When resource red lights and worsening cost forecasts occur simultaneously, first check whether manpower is being used to fill scope gaps — the correct action is to request change additions or cut scope, rather than just adding more names. Task estimates being systematically underestimated pollutes both load and cost; first conduct a two-week "plan vs. actual" calibration before emphasizing red alerts, otherwise the team will attack the metrics instead of adjusting the plan. If key roles are continuously overloaded, risks can also be generated or linked according to the rules, entering a rhythm with owners and review dates, instead of just writing "manpower tight" in the weekly report.

The pace of advancement can be simple: identify key roles and personnel, fill in available percentages → pilot projects must estimate time and assign names, produce the first conflict chart → release arbitration rules, regularly review red-light personnel in combined meetings → promote project portfolios and include overtime and load deviations in weekly reports → review tasks with frequent estimation deviations to improve templates. When a single project has a fixed small team, the load board is of limited benefit; once multiple projects run in parallel, it should be upgraded immediately. When priorities change frequently, first stabilize the combination strategy, otherwise arbitration will turn into weekly rescheduling noise.

Listing names without recording work hours, counting overtime as official capacity, project managers privately poaching staff, only looking at the current week instead of a four-week window—these anti-patterns will make the Kanban either always show a green light or always be noisy. When task time estimates are seriously inaccurate and reconciliation is refused, and skill tags are missing, first improve the master data and reporting quality before discussing load optimization.

Pre-sales commitments and execution capacity need to handshake

Half of the overload doesn’t come from the execution phase; it comes from presales putting key people into multiple parallel plans. If the presales phase could quantify the 'weeks occupied by scarce roles,' the bidding and project kick-off scheduling would be much more realistic. Putting the same architect into three different start plans, no matter how diligent the combination is, only distributes already overcommitted people. The delivery center’s scheduling should reserve an 'unsellable buffer' to specifically deal with the situation where multiple bids win at the same time—if the buffer is consumed by presales, the overload will flow directly from the sales funnel into the project portfolio.

Foreign aid and subcontracting can help relieve peak loads, but the available percentage of foreign aid and the safety margin need to be included in the same workload account: if foreign aid is not counted in the dashboard, the dashboard will pretend there is still internal capacity; if foreign aid is counted but lacks skill and confidentiality boundaries, a site overload will only happen during that week. If working hours are reused with the EHR, vacation and position status need to be synchronized, otherwise the 'person has left but is still listed on three projects' green light will persist for a long time.

The cost-side comparison is very practical: for the same person, projects that are continuously overloaded are often projects with both high work hours and high rework costs. If the resource red light never triggers scope or schedule changes, it indicates that the organization is still using manpower to fill the gaps. Only after linking 'continuous overload' with risk items can regular meetings simultaneously ask: have countermeasures been taken to procure, seek external help, or cut scope, rather than just changing the load color.

You can see it for half a day without the system

Export the task list for key personnel for the next four weeks, and sum up hours in a table — in half a day, you can often see who has already been 'planned' into obvious overload. Seeing it is the beginning of governance. Write conflict resolutions into plan changes and notify stakeholders, so that overload won't be quietly added back after meetings. A board that is open but has no arbitration is worse than not opening one: it gives the illusion that things are 'already managed.' If after summing there is no one overloaded, but there are weekly emergencies on site, first check whether estimates were systematically underestimated, and whether nominal tasks never entered the hour field. Seeing conflicts but not changing the plan means the workload board is just another pretty light.

  • PMS Project Plan: Project Portfolio and Situation Room
  • Project cost visibility
  • Scope Change Control
  • Milestone Acceptance

FAQ

Quick answers on this topic—still stuck?Contact

Sort by person or by role?

In the early stage, the gaps are assessed by role (whether there are enough senior implementers), and in the execution phase it comes down to the people; both are needed, if either is missing, it will either result in idle operations or overload prominent individuals.

How is the availability of part-time staff calculated?

Use the available percentage, not the default 100%; at the same time, subtract approved leave and fixed shifts.

Can the task be automatically postponed when overloaded?

Suggestions can be given, but delays across projects require the confirmation of the portfolio manager and must go through a plan change, to avoid one project 'optimizing' on its own at the expense of another contractual commitment.

Do you want to show individual overtime?

Yes. Hiding overtime is equivalent to encouraging filling gaps with your body; the board should make both planned workload and actual overtime visible.

At what load rate is it considered a red light?

A common practice is to trigger alarms at full load, upgrade when there is significant overload, and hold a joint meeting if there is overload for two consecutive weeks. Thresholds can be adjusted according to the position, but they must be recorded in the system and used consistently.