Running one job is a full-time fight. Running four at once is a different animal, and the thing that kills you isn't any single project — it's the seams between them. The same drywall crew you promised a Monday start on the Elm Street podium is the crew your other super needs to hold over on the medical office because inspection slipped. Nobody double-booked them on purpose. It happened because two schedules that never looked at each other made the same reasonable assumption about the same finite resource. Multiply that across a portfolio and you get the familiar chaos: crews standing around, subs mad at you, and a Friday spent apologizing instead of planning.
This is the real problem multi-project coordination has to solve. Not dashboards for their own sake — the honest question of who is where next week, and whether the promises you've made add up to more people and hours than actually exist. Here's how experienced teams handle it, and where good scheduling software earns its keep versus where it just makes a prettier version of the same mess.
See the whole portfolio, but plan at the crew level
Executives love a portfolio dashboard — red, yellow, green across every active job, milestones and budget variance at a glance. That view has its place for the people who sign the contracts. But it's the wrong altitude for preventing the collisions that actually hurt you. A green project can quietly be stealing the exact crew a yellow project needs on Tuesday, and no status roll-up will show you that.
The coordination that matters lives one level down, at the crew and trade level, inside the weekly work plan and the two-to-six-week look-ahead. That's where a body-count conflict becomes visible. So the useful setup is two views stacked: a portfolio summary for the office, and a resource-loaded look-ahead that spans jobs for the people who make the assignments. If your software only gives you the first, you'll find out about the second the hard way — at 6 a.m. when two foremen call the same electrician.
Resource conflicts: find them three weeks out, not three days out
The single highest-value thing a multi-project system does is surface the moment two jobs reach for the same resource before either one has committed to a sub. That's the whole game. A conflict caught in the three-week look-ahead is a scheduling conversation. The same conflict caught the morning of is a broken promise and a crew you're paying to stand around.
Track shared resources across projects deliberately, and keep the list short and real:
- Self-perform crews and key foremen. The people you actually control. If your framing crew is booked on Job A, the system should scream when Job B's look-ahead pencils them in the same week — before you tell the owner a date.
- Shared subs at capacity. A regional electrician or a specialty waterproofer working three of your jobs can only rough-in so many buildings at once. You don't control their headcount, but you'd better know how much of their week you've already claimed before you claim more.
- Big-ticket equipment. One crane, one concrete pump, one man-lift shuttling between sites. Double-booking a crane isn't a scheduling nuisance; it's a five-figure day lost and a pour that doesn't happen.
The rule of thumb that's saved me more times than I can count: don't hand a start date to an owner or a sub until you've checked that resource against every other job's look-ahead for that week. It takes ninety seconds when the data's in one place and it prevents the phone call that costs you a day.
Know your subs' real capacity — including the jobs that aren't yours
Here's the trap that sinks people who only look at their own portfolio. You've got a tile sub on two of your jobs, you check your schedule, you see they've got room, so you load them a third. What you can't see is the two jobs they're running for another GC across town. Their crew is maxed and you just wrote them into a corner. They'll say yes because subs always say yes, and then they'll no-show, and it'll read as their failure when it was really your blind spot.
You can't schedule what you can't see, so make it a habit to ask. When you're loading a sub across multiple projects, the look-ahead conversation shouldn't be "can you start the 14th" — it's "walk me through your whole month, all your jobs, not just mine." A rolling look-ahead you share with your key subs — where they can see their upcoming work across your projects and flag when you've stacked them — turns a guessing game into a planning one. LookAheadWall's shared, location-based plans are built for exactly that back-and-forth: the sub sees what you see, on the same board, and can push back before the week arrives instead of no-showing when it does.
Batch the same trade across jobs to kill mobilization waste
When the same crew works several of your projects, there's real money in sequencing them thoughtfully instead of letting each job pull independently. Every mobilization — trailer, tools, the half-day of guys figuring out where the gang box goes — is dead time you pay for. If you can line up your painter to finish Building 2 on the west job and roll straight to the east job the following Monday, you've saved a demob and a remob and given them a continuous run of work, which is exactly what keeps a good sub loyal to you.
This is where cross-project trade-flow sequencing pays off. Map each trade's path through all your jobs and look for the handoffs. It won't always line up cleanly — inspections slip, weather hits — but even smoothing half your mobilizations across a portfolio is a meaningful number over a year, and it's the kind of thing that makes subs prioritize your calls over the next GC's.
Standardize the plan so a super can move between jobs
One quiet benefit of running multiple projects on the same system: your people can move between them without relearning anything. When every job uses the same activity naming, the same location breakdown, the same look-ahead cadence and the same weekly planning meeting rhythm, a superintendent you pull from a finishing job onto a struggling one is productive on day one. When every job is a snowflake — one runs off a whiteboard, one off a spreadsheet, one off somebody's memory — that same transfer costs you a week of orientation you don't have.
Standard doesn't mean rigid. Jobs differ and the plan should reflect that. But the structure — how you name a location, how you phase a floor, what a weekly work plan looks like — should be boringly consistent across the portfolio. Boring is good. Boring is transferable.
Measure planning reliability across all your jobs
If you run weekly work plans, you should be tracking how many committed tasks actually got done each week — the plan-percent-complete number from the Last Planner world. On a single job it tells you how good your look-ahead is. Across a portfolio it tells you something more useful: whether a problem is this job or your whole operation.
When one job consistently completes 80% of its committed work and the rest sit at 55%, that's a team difference — go learn what the good super is doing and spread it. But when every job hovers around 55%, stop blaming the supers. That's a systemic issue: your look-aheads are committing work that isn't really ready, or your subs are chronically overpromising, or your constraint-clearing is broken upstream. You only see that pattern when the numbers sit side by side. A single project's metrics can't tell you whether you have a people problem or a process problem — the portfolio view can.
Match access to responsibility
Last practical piece: not everyone should see everything. Your field crews and foremen should see their assigned jobs clean and uncluttered — the plan for their building, this week and next, nothing else. Cross-project and portfolio views belong to the supers and PMs who actually make assignments across jobs. And your subs should see only the projects they're contracted on. It's partly security and partly just noise reduction: a foreman buried in five projects' worth of data he doesn't own will tune all of it out, including the part that's his.
The bottom line
Multi-project coordination isn't about a fancier dashboard. It's about making the invisible seams between jobs visible early enough to do something about them — the shared crew, the maxed-out sub, the one crane, the pattern that shows up on every job at once. Do it on whiteboards and you'll catch the collisions the morning they happen, which is to say too late. Put your look-aheads and weekly work plans for every job on one shared, location-based board — which is exactly what LookAheadWall is for — and the same conflicts show up two and three weeks out, back when they're still just a conversation. That's the difference between a portfolio that runs you and one you actually run.