Construction Scheduling Software: A Worked Crew-Conflict Decision

Test a scheduling tool by changing a real constraint, then asking the team to publish a workable response. Moving bars on a chart is one step. The project manager still needs to check readiness, crew availability, commitments and who has accepted the new plan.

Existing products can already handle substantial parts of this work. A custom workflow is worth investigating when a specific decision or handoff remains difficult after configuration has been tested. It is not a prerequisite for dependencies, mobile updates or approval records.

The example below is a hypothetical software evaluation, not a delivered Ekyon project or a claim of savings. It shows what to ask a vendor or developer to demonstrate. For the wider product and budget choice, see construction software for a small business: buy versus build.

Start with what existing scheduling products support

The primary documentation linked here was checked on October 22, 2026. Verify the required package, permissions and current behaviour with the provider before purchase.

• Buildertrend: its schedule overview documents predecessor links, baseline comparisons, schedule history and publishing controls. Its advanced scheduling guide describes conflict notifications and confirmation requests. These are reasons to test native configuration before commissioning similar features.
• JobTread: its tasks and scheduling page describes assignments, calendar/Gantt/list views and status updates. Check how your proposed review, crew and communication process works in the account you would use.
• Fieldwire: its task views documentation and Gantt guide explain task scheduling and date-based views. Demonstrate the dependencies, resource checks and approvals you require rather than inferring them from the presence of a Gantt chart.

A feature list helps select a demo. Completing the decision below is a more useful acceptance test.

The worked example: one delay, two jobs, one crew

Assume a contractor has one two-person installation crew. It can work on only one job per day. The business works Monday through Friday; there are no holidays or other assignments in this example.

Job A needs a supplier delivery and site release before installation. The site lead owns the readiness decision. Job B already has the same crew booked for one day of preparation on Friday. Its customer has confirmed that access window.

These are the original approved dates:

On Tuesday, the supplier reports that the delivery will arrive on Thursday. After checking the site arrangements, the site lead says Job A can be released for installation on Friday at the earliest.

The field update should report that constraint. It should not silently change the approved installation dates or tell the customer that a new handover date is agreed.

Why shifting dependent dates is not the complete answer

Moving Job A installation to Friday and the following Monday preserves its two-day duration. It also double-books the crew on Friday, when Job B needs it.

The dependency calculation and the resource decision are different. The project manager needs both views before publishing a plan.

Suppose Job B's access cannot move and Job A's customer accepts Wednesday. The project manager chooses the second option. The resulting approved plan is:

The dates follow the assumptions above. They are not technical construction sequencing advice. On a real job, the responsible team must establish readiness, durations, required reviews and commitments.

If Job A cannot accept Wednesday and no suitable alternative crew or access window is available, the system should expose an unresolved decision. Publishing incompatible promises is not a successful scheduling outcome.

The workflow to demonstrate in software

Use the same example in an existing product demo and any custom prototype. Ask the people who will run the process to complete it.

1. Report the constraint against the current task

The field lead selects Job A and its affected task, records the new delivery information, identifies the source and requests review. A note or photograph may provide useful context. The update records who reported it and when.

The current approved plan remains distinguishable from the proposed change. The receiving project manager can find the update without searching a separate message thread.

2. Prepare a draft and inspect the conflict

Show Job A's dependent tasks and the shared crew's assignments across both jobs. Identify the Friday conflict, the original baseline and the proposed dates. The project manager checks the working calendar and the people or equipment needed, not only the selected crew.

Demonstrate whether the product detects the conflict, requires a manual check or needs an additional resource view. Record that result instead of assuming every scheduler automatically prevents double-booking.

3. Record the decision and publish one revision

The project manager records the selected option, the confirmed customer arrangements, the readiness condition and the reason for the change. The published revision identifies who approved it and which earlier revision it replaces.

Keep the previous dates and decision history. A reviewer should be able to answer why Job A moved, why Job B stayed on Friday and which commitments are still conditional.

4. Confirm that affected people received the plan

Show each crew or subcontractor only the information and jobs their role permits. Send the relevant change and request acknowledgement where the process needs it. A queued notification or sent email is not the same as a person accepting a new assignment.

Give unacknowledged changes a responsible follow-up owner. The office still needs a practical route for people who cannot access the application.

5. Send a cost question for review, if needed

If the change could affect a supplier charge, subcontract, estimate or billing milestone, create a review item with a link to the scheduling decision. The authorised person determines the commercial treatment.

A delay entry does not itself establish a chargeable change order, approved cost or invoice. Connecting scheduling to another system requires agreed record mapping, access and exception handling. A simple reference may be enough for the first scope; financial automation needs its own acceptance tests.

Test weak connectivity and conflicting updates

Include the field conditions your team actually encounters. Ask what can be read or entered without a connection, where pending changes are stored and what happens when the device reconnects.

Use a specific test: the field lead opens revision 6, loses connectivity and prepares an update. The project manager publishes revision 7 before that update reaches the server. On reconnection, the older update must be identified for the agreed conflict-resolution process. It should not silently overwrite the newer approved plan.

Also test repeated submissions, failed attachments and notifications that do not reach the recipient. Someone must see the exception and know what to do next. Offline entry and reliable synchronisation require design, testing and ongoing support in a custom application too.

Be precise about terminology. Buildertrend's schedule overview uses Offline mode for private drafting with restricted visibility and notifications. That setting alone does not establish what a mobile device can do without connectivity. Ask the provider to demonstrate the actual device behaviour required.

Decide whether configuration or custom work is justified

A native workflow may be sufficient if the team can report the constraint, inspect dependencies and crew availability, approve a plan and communicate it reliably. Configuration, training and clear responsibility may be the useful investment.

A focused custom layer may deserve investigation when, for example, a field approval must combine information from two systems and the supported connectors cannot represent the required review. Write the exact missing step and test access before choosing the implementation.

A first scope might be a delay-review queue feeding an existing scheduler. It need not include a new scheduling engine, accounting system, client portal and offline application. Decide which system owns the approved schedule and how an integration handles failed or repeated transfers.

Ekyon's construction workflow service can assess that defined gap. The minimum engagement is US$5,000. This is a fit floor, not a quote for the workflow described here or a complete construction platform. Hosting, paid services, retained subscriptions, support and later changes need their own budget.

Measure the pilot before assigning a financial benefit

During a pilot, record how long a reported change waits for review, how much coordination it requires, whether the crew sees the approved revision and which exceptions still need manual work. Keep comparable observations from the existing process and include training and operating effort.

Released staff time is not automatically a cash saving. Missed disputes or delay charges cannot be counted as avoided losses without evidence of the event, responsibility and financial effect. A useful scheduling pilot can establish clearer decisions and a workable process without claiming a payback period.

Dhairya Purohit

Co-Founder, Ekyon

Co-Founder of Ekyon. Engineers custom platforms and AI-powered tools for operations teams. Focused on replacing expensive subscriptions with software you own.