Scheduling support maintains the administrative layer around a construction schedule: collecting progress, updating activity status, preparing two- and six-week look-aheads, distributing them to trades, logging delays with causes, and tracking constraints. Sequencing logic, durations, float decisions, and any delay or claim position remain with your project manager and scheduler.
Where this fits: This lane maintains and distributes the schedule. Project administration covers RFIs, submittals, and document logs; ConTech operations covers configuring the scheduling platform itself.
A reliable service lane starts with controlled inputs and a named client reviewer—not a broad list of tasks with unclear authority.
The exact format is agreed during onboarding. These are the operating records the service is designed to keep current.
Establish what the approved baseline actually is and how far current status has drifted from it, before any update rhythm is promised.
Name field contacts by area and agree how progress arrives, since unreliable input is the usual reason schedule updates stop being credible.
Lock the format, issue day, and distribution list so trades learn to expect it rather than request it.
Agree constraint and delay coding so the log supports later analysis by your team instead of needing reconstruction.
Answers describe how the service is scoped and where authority stays with your team.
The desk collects progress, updates activity status against your reporting method, prepares and distributes look-aheads, and maintains constraint and delay logs. Sequencing logic, activity durations, float decisions, and baseline changes are made by your scheduler or project manager. The desk maintains the schedule; it does not author the plan.
Most commonly Microsoft Project, Primavera P6, and the scheduling modules inside Procore, Buildertrend, and JobTread. The desk works in your existing file and licence at an agreed permission level rather than rebuilding the schedule in a different tool.
Typically the two- and six-week activity window, responsible trades, constraints and their owners, need-by dates for materials and approvals, and changes since the last issue. The exact format is fixed during onboarding and then held constant, because a look-ahead only builds trust if it arrives in the same shape on the same day.
It maintains a contemporaneous delay log with causes, dates, and supporting records against your coding standard, which is what makes later analysis possible. Forming a delay position, assessing entitlement, or issuing contractual notice is work for your project team and advisors, not the desk.
Then that is the first problem to solve, and onboarding will say so. The desk can chase, simplify the reporting route, and make non-reporting visible, but it cannot manufacture progress data. Teams without a workable field reporting route usually start with project administration instead.
The first cycle is an assessment: how far status has drifted from baseline and how reliable the progress route is. Teams with a defined baseline and reachable field contacts typically have a credible updated schedule and a first look-ahead within the first operating cycle.
We’ll map the source information, recurring output, responsible roles, client approvals, and a measurable first scope.