How to plan crew from a schedule you did not write.

The GC's schedule tells you when. It does not tell you how many people. That gap is where most of a specialty contractor's money is made or lost, and it is almost always crossed in somebody's head on the way to a Monday meeting.

It does not have to be. The arithmetic is simple. What makes it hard is doing it for four hundred activities, and doing it again every time a revision lands.

The arithmetic, once

For any activity, the crew it needs is:

crew = hours of work ÷ (working days × hours one person does in a day)

So you need three things: the hours behind the work, the days the schedule gives you, and what one person gets through in a day. The schedule supplies the middle one. The other two come from you, and they are the only two numbers you have to produce.

That is the thing worth internalising: you do not estimate crew per activity. You estimate hours per scope, once, and let the schedule divide it.

Step one: hours by scope, not by activity

Take your contract value or your estimate and break it into the scopes you actually manage: framing, drywall hang, tape and finish, ceilings, insulation, whatever your trade divides into. Put the total hours against each. If your estimate already has them, this takes an hour. If it does not, you have a bigger problem than scheduling.

Then break each scope into subscopes if the production rates differ meaningfully. Hanging board on a flat Level 2 wall and hanging it in a mechanical room are not the same work, and if you average them you will be short in one place and fat in the other.

Step two: hours per person-day, honestly

This is the number people get wrong, and they get it wrong in the same direction every time. A person is on site eight hours. They do not do eight hours of production. Between mobilising, breaks, material movement, waiting on the trade in front and cleaning up, a realistic figure is six to seven on a good job.

If you plan at eight you have built a 15–25% shortfall into every single activity, and it will not show up until the week it bites. Pick a number you can defend from your own historical cost reports, not from the working day.

Try it on your own numbers

One activity, three inputs. This is the whole of crew planning; everything else is doing it four hundred times and keeping it current.

Hours of work

Working days

Hours a person-day

13people on the wall, every day it runs

1,200 hours ÷ (15 days × 6.5 hours a person-day) = 12.3, so 13 people on the wall every day it runs.

Change the hours a person-day from 6.5 to 8 and watch the crew drop to 10. That is the same job, planned with a number nobody achieves, and it is the most common way a labour plan is wrong before it starts.

Step three: let the schedule do the dividing

Now every activity in your scope has a crew size, derived rather than guessed. Three things fall out of that immediately, and all three are decisions you otherwise make blind:

• Your peak. Add the crews across all concurrent activities, by day. The peak is the number you are actually committing to when you sign. If it is thirty-two and you employ eighteen, you have found out now rather than in month four.
• Your shape. A flat curve is a job you can staff. A curve with two spikes and a trough is a job that will cost you in hiring, in travel, or in idle time. The shape is a negotiating position: it is the thing to take back to the GC before the sequence is fixed.
• The impossible activity. Twelve hundred hours in a four-day window is nineteen people in one area. Sometimes that is fine. Usually it means the duration is wrong, and you now have a number to say so with instead of an opinion.

The curve the schedule is really asking for

An example: a 5,557-hour package over sixteen weeks at 6.5 hours a person-day, one column per week. The crew on every bar is derived from the schedule's own durations. Nobody typed it in.

Three weeks sit above the crew this contractor has, and the peak is 22. That is the conversation to have before the sequence is fixed, not in month four. Illustrative figures, not a real project.

See the numbers

Week	People
Week 1	2
Week 2	3
Week 3	5
Week 4	7
Week 5	9
Week 6	12
Week 7	16
Week 8	19
Week 9	21
Week 10	22
Week 11	18
Week 12	14
Week 13	10
Week 14	7
Week 15	4
Week 16	2

Step four: re-run it every revision

This is the part that gets dropped, and it is the part that matters. Durations change. A fifteen-day activity becoming a nine-day activity does not change the hours (the work is the same), so your crew on it just went from eight people to thirteen, quietly, in a revision nobody flagged to you.

If your crew plan lives in a spreadsheet built off Rev 4, it is wrong the moment Rev 5 lands and it will stay wrong until somebody rebuilds it. Most people rebuild it two or three times on an eighteen-month job, which means it is stale most of the time.

Step five: look across jobs, not just within one

A crew plan per project tells you whether a project is staffable. It does not tell you whether you are staffable. Three jobs each peaking at fourteen in the same three weeks is forty-two people, and no individual project plan will ever say so.

The portfolio view is also the only honest input to a bid. "Can we take this one on" is a question about the fortnight it lands in, against everything already committed.

What this looks like in GanttAI

You give it the two numbers, hours per scope and hours per person-day, with subscopes where they differ. It derives the crew behind every activity in your scope from those totals against the schedule's own durations, and shows it as a Persons Required column and a curve. Override any activity with a number of your own and yours is used instead.

Because it is derived rather than typed in, a new revision re-plans itself. Load Rev 8 and the curve redraws: you see the peak move before you staff to it.

Across jobs, the portfolio overview adds up trade-level manpower from every live project and shows it by day, week, month, quarter or year against the crew you actually have. Utilisation and shortfalls, before you bid the next one.