Your construction schedule, always measured against real progress
Plan with real dates, dependencies and work fronts, see the critical path, and know how closely you're tracking to the plan.
Matterial's schedule organizes your project into activities with dates, durations and dependencies, and calculates the critical path so you know which line items can't slip without moving the delivery date. Because field progress lands in the same place, you can see at any moment how close you are to the plan and where a delay is opening up—without building the report by hand.
What problem it solves
The schedule gets built once in Project or Excel, and a week later it no longer reflects the job: nobody updates it, the dependencies live in the superintendent's head, and a delay only shows up once it has already pushed the delivery date. With no clear critical path, the crew runs to put out the wrong fire while the activity that actually holds everything up stays stuck.
How it works
Define the activities
Capture the line items or work fronts with their duration and start and finish dates, or start from your budget so you don't begin from scratch.
Connect dependencies
Link which activity depends on which, and Matterial calculates the critical path: the line items that can't slip without moving the delivery date.
Log real progress
The team reports physical progress from the field and the schedule compares what's built against what was planned, front by front.
React in time
You see the delayed activities and their effect on the delivery date, so you can reassign fronts before the delay becomes irreversible.
What's included
- Schedule with start, finish and duration per activity
- Dependencies between line items and critical-path calculation
- Organization by work fronts
- Real physical progress vs. plan, activity by activity
- Early delay detection and its impact on delivery
- Baseline pulled from the budget so you don't capture it twice
Inside Matterial's construction schedule
What the critical path is and why it decides your delivery date
On a job site, not every activity carries the same weight on the delivery date. Some can move a few days without any consequence; others push the delivery out a full day for every day they slip. The critical path is exactly that chain of dependent activities with no float: the longest sequence in the project, the one that sets the minimum possible time to finish. Protecting that chain is protecting your delivery date.
The trouble is that in a hand-built schedule the critical path lives in the superintendent's head, and it changes every time an activity moves. When something slips, the natural reaction is to run to the front that's making the most noise, not the one that actually holds everything up. You end up throwing an extra crew at an activity with plenty of float while the one that was truly on the critical path stays idle.
Matterial calculates the critical path from the dependencies you link between activities. Instead of guessing which line item is untouchable, you see it flagged: which ones can't move without pushing delivery and which carry float. That distinction is what tells you where to put the extra crew when time gets tight, instead of spreading effort blindly.
- Critical path: the chain of activities with no float that fixes the delivery date.
- Float: the days an activity can move without pushing delivery.
- Dependency: which activity can't start until another finishes.
- Recalculated whenever you change the dependencies or durations you capture.
- Tells you where to add the extra crew: on the critical activity, not the noisy one.
From budget to schedule: line items, crews and duration
A construction schedule is only useful to the extent that its activities and durations match how the job will actually be built. That's why Matterial lets you start from the budget: the line items you already estimated—foundations, structure, masonry, MEP, finishes—come in as the schedule's baseline instead of re-entering the whole project from scratch. Cost and time start from the same list, not from two files nobody reconciles later.
The duration you assign to each activity doesn't come out of nowhere: it comes from the quantity of work in the line item and the productivity of the crew that will execute it. How many cubic yards of concrete, how many square feet of wall, how much a crew of that size advances per day, and whether the crew is paid by the day or by unit price—which changes the pace of execution. That construction logic is yours to decide; Matterial pulls the line items from the budget and stores those dates and durations to measure against.
With the line items in, you chain dependencies following the real sequence of the job: no wall goes up without the slab-on-grade, no finishes without the rough-ins closed, no deck poured without formwork and rebar ready. That chaining is what turns a list of line items into a schedule with a critical path, and what makes a delay in one activity visibly push the ones that depend on it.
- Budget line items come in as the schedule baseline, with no double entry.
- You set the duration from the quantity of work and the crew's productivity.
- Day rate or unit price changes the pace you plan to execute the line item at.
- Dependencies follow the real sequence: slab before wall, rough-ins before finishes.
- Cost and time come from the same list of line items, connected from the start.
Physical progress vs. plan: reading a delay while it can still be fixed
There are two ways to measure how a job is going, and it pays not to confuse them. Financial progress counts how much money you've spent or billed; physical progress counts how much of the work is actually built—the wall raised, the deck poured, the linear feet of pipe installed. You can be far along on spend and short on built work, or the other way around. The schedule is measured against physical progress: how much of the plan is already built, front by front.
In Matterial that physical progress is reported by the team from the field and lands in the same schedule where the plan lives. So the comparison between what's built and what was planned isn't a report someone assembles on Friday from whatever people remember: it's each activity marking its own progress against the date it was given. You see activity by activity which is on time, which is opening up, and by how much.
What changes the decision is that a delay doesn't stay locked inside its own activity. Because the dependencies are loaded, Matterial shows you the effect of that delayed activity on the ones that follow and on the delivery date. If it falls on the critical path, you know every day lost is a day off delivery and you reassign fronts now; if it carries float, you know you can wait. That's the difference between reacting while there's still room and finding out about the delay once it has already moved the date.
- Physical progress: work actually built. Financial progress: money spent. Not the same.
- The team reports physical progress from the field, on the same schedule.
- Comparison of built vs. planned, activity by activity and front by front.
- A delay shows its effect on the activities that depend on it and on delivery.
- The money-per-line-item view lives in cost control, not in the schedule.
Construction Gantt chart: a living tool, not a file that dies
A construction Gantt chart is the schedule shown as activities over time: each line item is a bar with its start, its finish and its duration, chained to the ones that depend on it. It's the classic way to see a planned job and where the critical path and float come from. The Gantt was never the problem: the problem was that the Gantt gets built once in Project or Excel, printed nicely for the kickoff meeting, and a week later no longer looks like the job because nobody updates it.
The difference with running it inside Matterial is that the same schedule where you plan is where real progress lands. There's no master file someone has to open, cross-check against what the superintendent said, and save again. The plan and what's built live together, so the schedule doesn't age in an inbox: it keeps reflecting the job because it's fed by it.
On that same base you organize the job by work fronts, which is how a build actually advances: several crews on different line items at the same time. Seeing the schedule by fronts lets you know which front is ahead, which is dragging, and—crossed with the critical path—which of those delays actually threatens delivery and which is just noise.
- Each activity is a bar with start, finish and duration, chained by dependencies.
- The plan and real progress live in one place: the schedule doesn't fall out of date.
- Organization by work fronts, the way a build really advances.
- You cross a front's delay with the critical path to know if it threatens delivery.
- No separate file to keep by hand that goes stale within a week.
Scheduling the job in Excel or Project vs. with Matterial
Most teams build the schedule in Project or Excel and maintain it over text. Here is the difference against running it inside Matterial.
| Today (Excel/Project and texts) | With Matterial | |
|---|---|---|
| Critical path | Guessed by eye; lives in the superintendent's head | Calculated from the dependencies you link |
| Starting point | The whole job is re-entered from scratch | Starts from the budget line items |
| Real progress | A separate report someone assembles each week | The team reports physical progress on the same schedule |
| Plan vs. built | Two files nobody reconciles | Built against planned, activity by activity |
| Effect of a delay | Noticed once it has already moved delivery | Its impact on the following activities and the date is visible |
| Work fronts | Loose rows never crossed with the critical path | View by fronts crossed with what actually holds up delivery |
| Staying current | Falls out of date within a week; nobody updates it | Lives with the job because it is fed by real progress |
Illustrative example: a delay on the critical path vs. one with float
Hypothetical numbers to show why the critical path changes how you react to a delay. Not a market figure or a promised result.
Illustrative example. The deck pour is on the critical path: its 4-day delay pushes delivery a full 4 days, so that's where the extra crew belongs. Landscaping carries 8 days of float; even a 3-day slip makes noise but never touches delivery. Without seeing the critical path, it's easy to rush the wrong front.
Use cases
Before the weekly meeting, reviews which activities are running late and which fall on the critical path. Reassigns the crew to the front that actually holds up delivery, instead of running to the one pushing hardest by phone.
Opens the physical progress against the plan and knows whether the job will deliver on time without asking the superintendent for the report. When a critical activity opens up, they see it the same day, not at the month-end cutoff.
Reports the physical progress of their front from the field—what was raised, poured, installed—and that progress lands directly in the schedule, without going through a sheet someone has to key in later.
Builds the schedule starting from the budget line items, chains the dependencies according to the real sequence of the job, and flags the critical path so the field knows which line items are untouchable.
Who it's for
Works with the rest of Matterial
Guides to go deeper
Related terms
Frequently asked questions
What is the critical path and why does it matter on a job site?
The critical path is the chain of activities that can't slip without pushing the delivery date. Matterial calculates it from your dependencies so you know which line items to protect first and where to add an extra crew when time gets tight.
What is a construction Gantt chart?
It's the schedule shown as bars over time: each activity or line item has its start, its finish and its duration, chained to the ones that depend on it. That's where the critical path and float come from. In Matterial that Gantt doesn't fall out of date, because real physical progress lands in the same schedule.
What does construction scheduling software do?
It organizes the job into activities with dates, durations and dependencies, calculates the critical path, and compares physical progress built against what was planned. The difference from a loose file is that the plan and real progress live together, so the schedule keeps reflecting the job instead of going stale within a week.
How does Matterial calculate the critical path?
From the dependencies you link between activities and their durations. With that it identifies the chain with no float—the one that fixes the delivery date—and recalculates it whenever you change a dependency or a duration.
Can I see real progress against the planned schedule?
Yes. The physical progress your team reports on site is compared against the plan, so you see front by front and activity by activity how closely you're tracking and where the delay is opening up.
What is the difference between physical progress and financial progress?
Physical progress is how much of the work is actually built; financial progress is how much money you've spent. They're not the same: you can be far along on spend and short on built work. The schedule is measured against physical progress; the money-per-line-item side lives in cost control.
Can I build the schedule from my budget?
Yes. You can start from the budget line items so you don't capture the job twice and keep cost and time connected from the same list.
Can I organize the job by work fronts?
Yes. The schedule is organized by fronts, the way a build really advances, with several crews working in parallel. Crossed with the critical path, it tells you which front delay threatens delivery and which is just noise.
Does it replace MS Project or the scheduling spreadsheet?
It covers what the job needs day to day—dates, dependencies, critical path and real progress—without you having to update a separate file that falls out of date within a week. The advantage isn't just drawing the Gantt, but that the plan and what's built live in the same place.
Get started today with Matterial
From blueprint to build, with clarity. Try it free, no card.