Construction crew scheduling goes wrong when it starts with the calendar. On a company running 5 to 40 jobs, the real limit is usually a handful of people — the lead carpenter, the finish carpenter, the tile setter, the super who walks every inspection — and every job wants them in the same three weeks. Schedule those people first, as one queue across all jobs, and the job calendars mostly resolve themselves. Schedule each job's calendar first and the conflicts surface at 6:30 on a Monday morning, in a truck, on the phone.
A calendar assumes people are unlimited
A job calendar answers one question: when does this task happen on this job. It doesn't ask who else needs the person doing it. When each PM — or the owner, late at night — builds dates job by job, every job gets a reasonable-looking schedule and the company gets an impossible one. The lead carpenter is on three jobs on Tuesday. Nobody sees it until he does.
The usual fix is the loudest-client rule: whoever calls most gets the crew. That isn't a method. It hands the decision to clients, and it pushes the slip onto the job whose owner is patient — which is often the job with the better margin and the relationship worth keeping.
Most advice on construction crew scheduling starts with views, colors and drag-and-drop. Those matter later. The calendar is the output of the schedule, not the input. The input is the short list of people who can't be in two places at once.
Find the constraint before you touch a date
A constrained resource is anything more than one job needs in the same window that can't be swapped for someone else on short notice. Usually it's a person. Sometimes it's a machine, a trailer or one inspector's open slots. Three tests sort it out:
- Substitution — if this person is out, can someone else do the work within a week at the same quality? If not, they're constrained.
- Overlap — does this person appear on two or more jobs in the next three weeks? If yes, they're constrained.
- Stoppage — if this person doesn't show, does the next trade wait? If yes, they're constrained and they go to the top of the list.
Run the tests honestly and the list is short — often fewer names than there are active jobs. Laborers, a framing crew that can be hired in, the drywall sub with several crews: those are not the constraint. Planning time spent fine-tuning their dates is time not spent on the people who actually decide when jobs finish.
Schedule the constraint as one queue
Once the constrained people are named, change the unit of scheduling. Stop building per job. Build one line per constrained person, running across every job, in this order:
- Pull every task in the next four to six weeks that needs a constrained person. Take the hours from the estimate, not from memory — if the estimate priced 64 hours of trim on a kitchen, the queue gets 64 hours, not 'about a week'.
- Put those tasks into a single sequence per person. The finish carpenter's line reads job A trim, job C built-ins, job B casing — one line, not three calendars.
- Where two jobs want the same days, apply the written priority rule (next section). Don't negotiate it fresh each time.
- Pin the queue. Those dates are now fixed inputs for everything else.
- Schedule the rest around them: subs, deliveries, inspections, unconstrained labor. The drywall finish on job C stops being a free-floating guess and becomes 'complete before the finish carpenter arrives on the 14th'.
- Leave slack. Book constrained people about four days in five. The fifth absorbs callbacks, rain and the inspection that moved.
Step 5 is where most of the calendar actually gets built, and it goes fast because the hard dates are already set. Subs have more flexibility than the lead carpenter does. Let them flex.
Decide the priority rule before the conflict
When two jobs want the same person the same week, one of them loses. Decide in advance what decides it, write it on one page and use it every time. The common tiebreakers, roughly in the order contracts force them:
- Liquidated damages or a hard completion date — a contractual cost per day late; goes first when the date is genuinely at risk, not merely because the clause exists.
- A booked inspection or utility appointment — rebooking can cost far more days than the task itself; the crew work feeding it goes ahead of open-ended work.
- Critical-path work — a day lost here moves the finish date, a day lost on float doesn't; the logic is in critical path in construction.
- Work that releases another trade — framing that lets the plumber rough in keeps two crews moving; trim nobody waits on can slide.
- Client pressure — last. It's a reason to communicate, not a reason to reorder.
The rule doesn't have to be perfect. It has to be the same every week, so PMs stop lobbying for the crew and clients hear a reason instead of an apology.
Never let the constrained crew wait
An hour the lead carpenter spends waiting on a delivery isn't lost on one job. It's lost from the company, because his queue shifts and every job behind it shifts too. An idle laborer costs a day's wage. An idle constraint costs a day on every job in its queue.
So most of the planning effort goes into readiness, not into the constrained crew's dates. Before each constrained start, confirm four things: the prior trade is complete, material is on site and checked against the order, access and permits are in hand, and the previous trade's punch items are closed. A Thursday call that confirms all four is cheaper than a Monday that confirms none.
The reverse holds too. Unconstrained resources can sit idle without much harm. A sub's crew waiting half a day is a real cost. Rearranging the finish carpenter's week to avoid it is a bigger one.
The most expensive scheduling mistake isn't the double booking — it's the promise. A PM who tells an owner 'trim starts the 14th' before checking the finish carpenter's queue has committed the company to something the constraint can't deliver. When it slips, the record shows a promised date and no reason. Give dates only from the resolved queue, and when the queue moves, log why on the day: which job took the crew and what forced it. Disputes over late finishes turn on that contemporaneous record, as set out in types of construction delays.
Rebuild the queue weekly, not daily
Rebuild the queue on one fixed day — Thursday or Friday — for the following two weeks, and look out to six weeks for anything that might collide. Daily reshuffling moves the constraint so often that nobody can prepare the site for it, which breaks the readiness check. Inside the week, a slip goes into the slack day. Only when the slack is gone does the queue change mid-week, and then every downstream job hears about it the same afternoon.
What the software does and doesn't do
In BuilderSolve the schedule is built from the estimate, so the hours on a crew task come from the line items that priced it. Crew management assigns people to those tasks, and the work planner shows the work in Gantt, calendar or table view. The table view sorted by person is the closest thing to the per-person queue described above.
When something slips, the AI assistant drafts the schedule shift — moving the dependent tasks and noting the change — and a person approves or rejects it. It does not decide which job loses the finish carpenter. That's the priority rule, and it's yours to set.
Two more limits worth stating plainly. The software won't tell you who your constraint is; that's the three-question test, done by someone who knows the crew. And purchase orders are in development and not shipped, so confirming material is on site before a constrained start is still a step in your own process — a call, or a check against the supplier's confirmation. If the weekly lookahead is the thing nobody has time to build, that's part of what the BuilderSolve operations team does on the services side.
What to do this week
- Run the three tests on everyone who has worked a job in the last month. Keep the names that fail at least two.
- For each name, list every task they own across all jobs in the next four weeks, with hours from the estimate.
- Lay those out as one line per person and mark every overlap.
- Write the priority rule on one page and resolve the overlaps with it.
- Reissue client dates only from the resolved queue, and log the reason for any date that moved.
- Pick the weekly rebuild day and put it on the calendar as a standing appointment.
The first pass takes an afternoon. After that the weekly rebuild is shorter, because only the next two weeks change and the hard dates are already in place.
Common questions
how do you schedule construction crews across multiple jobs
Schedule the scarce people first, as one queue per person across every job, then fit everything else around them. Identify who can't be substituted quickly and who appears on several jobs at once. Sequence their tasks using estimated hours, resolve overlaps with a written priority rule, pin those dates and then book subs, deliveries and inspections around them.
what is a constrained resource in construction scheduling
A constrained resource is a person, crew or machine that more than one job needs in the same window and that can't be replaced on short notice. A practical test: nobody else can do the work within a week, they appear on two or more jobs in the next three weeks, and the next trade waits if they don't show.
what to do when two jobs need the same crew the same week
Apply a priority rule written before the conflict, not one negotiated on the phone. Common order: jobs with liquidated damages at genuine risk, then work feeding a booked inspection, then critical-path work, then work that releases another trade. Client pressure comes last. Log which job got the crew and why, on the day the decision is made.
how far ahead should a crew schedule be planned
Firm up two weeks and look out four to six. Rebuild the queue for constrained people on one fixed day each week, usually Thursday or Friday. Daily reshuffling moves key crews too often for sites to be ready for them. Inside the week, absorb slips in a slack day rather than reordering the whole queue.
does construction scheduling software decide crew priorities automatically
No — and in BuilderSolve it isn't meant to. The schedule is built from the estimate and crews are assigned to tasks, and the AI assistant drafts schedule shifts when something slips. A person approves or rejects each draft. Which job gets a contested crew is a business decision set by your priority rule, not by the software.