CRM and Job Management
Job Scheduling for roofing contractors
Having a crew free on Tuesday is not the same as being able to start on Tuesday. Something else has to have finished first.
Work laid out in the order it can happen
A sequence where every step names what has to finish before it. Not the order things usually go in — the order they must, which is a shorter and more useful list.
Anything blocked recorded together with what it is blocked on. A job marked as waiting tells you nothing you can act on; a job waiting on a specific thing held by a specific party is a task.
And a slip you can trace. When a date moves, the reason moves with it, so that the question of why a job finished when it did has an answer six weeks later.
The constraint is order, not capacity
Most scheduling frustration in a roofing company gets diagnosed as not having enough people. Sometimes that is true. Frequently the crews were available, the calendar had space, and the work still did not happen, because something upstream had not finished and nothing on the schedule said so.
Roofing is unusually exposed to this because so many of its gates are held outside the company. A permit is issued by an office. Material arrives from a supplier. An inspection happens when an inspector comes. Each one blocks everything behind it, none of them responds to how many crews you have, and all of them are invisible on a calendar that shows only dates and names.
The characteristic failure follows from that. A date is set by working backwards from when the customer wants it rather than forwards from what has actually finished, and it holds right up until the first gate does not open. Then a single slip that nobody propagated leaves a chain of dates downstream that are individually plausible and collectively impossible — and the discovery happens on site, on the morning, in front of the customer.
So the deliverable is dependencies made explicit and kept honest. It does not make anything faster. It makes the plan describe what is actually possible, and it makes a slip visible on the day it happens instead of three weeks later.
What a dependency has to be to be worth recording
The temptation with sequencing is to record everything, which produces a plan so rigid that people work around it — and a plan people work around is worse than none, because it still gets reported.
The test we work to is whether the later step can genuinely proceed without the earlier one. If it can, they are not sequenced, however strongly they are associated in habit. Most jobs have a handful of real gates and a long tail of things that merely tend to happen in an order, and separating those is most of the work.
The second thing that makes a dependency useful is naming who holds it. A gate held inside the company is a scheduling matter; a gate held by an office, a supplier or an inspector is a waiting matter, and the two get managed completely differently. A plan that does not distinguish them gives every delay the same texture and lets the ones you could actually influence hide among the ones you cannot.
None of this determines how the work should be built or in what order it is technically correct to do it. That belongs to whoever is responsible for the roof. This desk takes the order the work requires and makes sure the schedule reflects it rather than contradicting it quietly.
Where a job stops being a plan
This desk sits inside CRM and Job Management, and the department boundary — including how job information is held and where administering it stops — is set out there rather than repeated here. What is particular to this page is its unit: everything else in the department works on a record, and this one works on the relationship between records, which is where the dates live.
What owners ask when a date moves
How is this different from scheduling the crews?
Crew scheduling asks who can do the work; this asks what has to be true before anyone can. They fail differently. A crew problem shows up as nobody available; a sequencing problem shows up as a crew standing on a driveway with nothing they are allowed to start, which is worse because it looked fine on the calendar.
What does a real predecessor mean?
Something that has to be finished, not something that usually happens first. Permit issued before work starts. Material on site before install. Inspection passed before the next stage. If a step can genuinely proceed without the one before it, they are not sequenced and pretending otherwise makes the plan more rigid than the job.
Our dates slip constantly. Does sequencing help with that?
It does not stop the slip; it makes the consequence visible immediately. When a date moves in a properly sequenced job, everything downstream moves with it and you can see the whole effect at once. Without that, a slip stays local until somebody discovers three weeks later that a date nobody adjusted has quietly become impossible.
Why record what a job is waiting on rather than just that it is waiting?
Because "waiting" cannot be acted on and "waiting on the permit office since Tuesday" can. It also aggregates: once blockers are named, the same one appearing across a dozen jobs stops looking like bad luck and starts looking like a supplier or an office worth doing something about.
Do you decide the order the work happens in?
The technical order comes from the work itself and from whoever is responsible for how it is built — that is not ours to determine. What this desk does is take the order you work in, make the dependencies explicit, and keep the dates honest against them. Where a customer wants a sequence the work will not support, that is a conversation for you to have.
Is this not what the calendar already does?
A calendar holds dates; it does not hold reasons. Two jobs on the same day and two jobs where one cannot start until the other finishes look identical on a grid. The difference only becomes visible when something moves, and by then a calendar cannot tell you what else should have moved with it.
The constraint here is dependency, not statute
This page argues from practice rather than from a rule, because no rule reaches the question it answers. That is stated here rather than covered over with a citation that would not survive being read. The constraint this function works against is physical and contractual rather than regulated: a stage cannot start until the one before it has finished, and no external body sets that order. Where a gate in the sequence IS statutory it is the permit, and that axis belongs to estimating-project/permit-applications, which argues it from the permit-as-precondition statute. Taking it here would be axis collision, and the honest description of the rest of the sequence is that it is arithmetic about dependencies rather than compliance with anything.
What it is held to instead: Every stage has a predecessor that is actually finished, and a date that moved because something moved rather than because somebody hoped.
Where the regulated part of this subject lives: estimating-project/permit-applications for the permit gate.
Take a job that slipped and find the first gate
Everything after it moved too. The question is whether anybody adjusted those dates or simply left them there.