Two questions, one equation
The forward mode answers “I have this many labor hours and this many calendar days — how many workers?” The reverse mode answers “I have this many labor hours and this crew — how long?” Both solve the same relationship, so the right moment to use either one is after the takeoff and before the schedule exists. If the crew that comes back is not a crew you can actually field, supervise, and fit on the work face, the problem is the date, not the crew.
The inputs, and which one moves the answer
Total labor hours comes off your takeoff as man-hours. Work days per week accepts 1 through 7 and hours per work day accepts 1 through 24. The productivity factor is entered as a percentage between 10 and 100 and defaults to 75; it converts paid hours into installing hours, and it is the input with by far the most leverage because it multiplies every hour of every worker on site. Then you supply either calendar days until the deadline or a crew size, depending on the mode.
Worked example on the default numbers
The page loads with 1,200 labor hours, 21 calendar days, a 5-day week, 8-hour days, and 75% productivity. Productive hours per worker per day are 8 × 0.75 = 6.00. Calendar weeks are 21 ÷ 7 = 3, so work days available are 5 × 3 = 15 (capped at the 21 calendar days, which does not bind here). Capacity per worker over the period is 15 × 6 = 90 hours, and 1,200 ÷ 90 = 13.3, rounded up to 14 workers. Crew capacity then reads 14 × 90 = 1,260 hours against 1,200 needed, leaving 60 hours of slack — about three-quarters of a single day of output for a crew that size, which is a thinner cushion than it looks. Switch to reverse mode and the same 1,200 hours with a 5-worker crew gives 5 × 6 = 30 team hours a day, 1,200 ÷ 30 = 40 work days, which rounds to 8 whole weeks and reports as roughly 56 calendar days.
Calibrate the productivity factor against your own jobs
Everything downstream of that factor is a planning estimate, not a measurement. Effective productivity moves with the trade, the site, whether material is staged at the work face, crew tenure, and how much rework the job is generating — the 75% default is a starting point, not a finding about your company. The only way to fix it is to divide installed quantity by paid hours on jobs you have already closed out and work backwards, which is exactly what the productivity rate calculator is for. Two contractors bidding identical scope from an identical takeoff will land on different crew sizes here and both can be right, because their factors differ. Recalibrate after every few jobs rather than carrying one number forever.
Where the model is deliberately simple
Labor is treated as perfectly divisible and infinitely stackable. There is no crew composition — a 14-person crew is foremen, journeymen, and apprentices, not 14 identical units — no trade sequencing or dependencies, no learning curve, no work-face congestion limit, and no weather. Two rounding behaviors are worth watching. Calendar weeks round up, so a window that is not a whole number of weeks can be credited with more work days than the calendar actually holds; check the work days available row against a real calendar with holidays marked. Crew size also rounds up to a whole worker, which is where the slack figure comes from. Note too that nothing here is priced: the estimate button pushes total labor hours across as a quantity at zero unit price, so you supply the rate, and it should be a fully burdened one from the labor burden calculator rather than a base wage. If the answer is pushing you toward longer days instead of more people, price that decision in the overtime calculator, and once the crew number is settled, sequence it in the critical path calculator to confirm the work can be fed fast enough to keep that crew busy.
Frequently Asked Questions
Do I enter man-hours or crew-days?
Man-hours. The field wants the total labor hours from your takeoff, not crew-days and not calendar duration. If your estimate is in crew-days, convert first: crew-days × workers per crew × hours per day = man-hours. Entering crew-days by mistake understates the work by roughly the size of a crew and the tool will hand back a crew that cannot finish.
Why did the crew size change so much when I moved the deadline one day?
Calendar days are converted to work days in whole-week chunks: calendar weeks = calendar days ÷ 7 rounded up, then work days = work days per week × calendar weeks, capped at the calendar days themselves. At the defaults, 21 days rounds to 3 weeks and 15 work days, which needs 14 workers. Moving to 22 days rounds to 4 weeks and 20 work days, which needs only 10. The jump is the rounding, not the arithmetic. Sanity-check the work days available row against a real calendar before you act on a swing like that.
Where do weather and absences go?
Nowhere, unless you put them there. The model assumes every scheduled worker is present every scheduled day and there is no weather input at all. You have two honest options: lower the productivity factor to absorb the expected loss, or take the calculated crew and add workers on top of it, which is what the on-page note suggests for outdoor work. Do one or the other, not neither.
Does doubling the crew really halve the duration?
In this model, yes, exactly — daily team output is crew size × productive hours per worker, so the relationship is perfectly linear. In the field it is not. Beyond a certain density the work face gets congested, supervision thins out, and trades start tripping over each other, so the marginal worker produces less than the one before. Treat large crew numbers from the reverse mode as a signal to rethink the sequence rather than a plan to staff.