The schedule that only one person trusts
The tender package needs a door schedule. The technician exports it from the model: door number, room, size, type, fire rating, ironmongery set, finish, vision panel. Half the fire ratings are blank. Some doors say 'FD30' and some say 'FD30S' and some say '30 mins'. The ironmongery set is typed as free text. A few doors from an early design option are still in the model on a hidden phase.
So the export goes into Excel, and the technician spends a day fixing it. The Excel version becomes the one that goes to the contractor. Two weeks later a design change moves three doors, the model is updated, and the Excel schedule is not.
Why schedules and models part ways
Scheduling in Revit, ArchiCAD or Vectorworks is only as good as the parameters in the model, and those parameters are filled in by different people at different times, often under pressure. Naming conventions are not enforced. Values are typed rather than picked from a list. So the schedule export is untidy, and the natural response is to tidy the export rather than the model, which breaks the link.
- Parameters are typed as free text with inconsistent values.
- Required fields, such as fire rating, are left blank.
- Old design options or phases leave extra elements in the model.
- Fixes are made in Excel, not in the model.
- Later design changes do not reach the fixed schedule.
What a drifting schedule costs
Doors ordered to the wrong fire rating or ironmongery, windows made to superseded sizes, and time on site sorting it out. Contractors lose trust in the schedules and start asking for confirmation on every item. Technicians spend skilled time on data entry. And if fire door information matters to a building's safety documentation, getting it right in one place becomes more important still, with the requirements set by your own obligations and advisers.
Fix the model, then publish the schedule
- We read door and window elements and their parameters from the model, using the design software's API or its data export.
- Each element is checked against rules you set: required parameters present, values from your agreed list, such as fire ratings in one format, sizes consistent with the type, no elements from inactive options or phases.
- A list of issues is produced, grouped by type and linked to element IDs, so the team can find and fix them in the model.
- Where a value is clearly a variant of an agreed one, such as '30 mins' for FD30, a correction can be suggested for a person to apply in the model.
- Once the checks pass, the schedule is produced in your layout, with revision information, directly from the model data.
- When the model changes, the checks run again and the schedule is regenerated, with the changes since the last issue highlighted.
We keep the model as the single source. The Excel fixing step disappears, because fixes happen where the data lives.
Checks that run before issue
| Check | Example issue found |
|---|---|
| Required parameter present | Fire rating blank on a door off a corridor |
| Value from agreed list | '30 mins' instead of FD30 |
| Size matches type | Door leaf width differs from its type |
| Element in active design | Door on an abandoned option still scheduled |
| Changes since last issue | Three doors moved, highlighted |
Schedules the contractor can rely on
The schedule that goes out always matches the model, because it comes from the model. Design changes flow through without anyone remembering to update a spreadsheet. The technician's time goes on fixing real data problems once, rather than tidying the same export again and again. And the same approach extends to other schedules, such as sanitaryware or finishes, once the rules exist.
Recognise this?
- Door and window schedules are fixed in Excel after export.
- Model parameters use inconsistent values.
- Design changes have not reached an issued schedule.
- Only one technician really trusts the schedule.