How many hours does your team spend copying a program into Revit?
I've spent a good part of my career watching architectural technologists retype space programs into area spreadsheets, then into Revit. Not by choice. Because that's how it's done, and always has been, in just about every firm I know. No space programming software in the loop — just Excel and patience.
The scenario is always the same. A new public project kicks off. Among the inputs is the functional and technical program (the PFT, as we call it in Quebec), a beautiful document of 1,000+ pages built to the health ministry's (MSSS) methodology or the SQI's requirements. Everything is in there: the needs, the functional units, the room data sheets, the target net areas, the technical requirements for every room. It's structured, it's rigorous, it's complete.
And it's a PDF.
So someone on the team opens Excel, and the scribe work begins.
The program is a database disguised as a document
Take an 800-room project. Every room has a code, a name, a target area, a functional unit, plus a dozen technical requirements: finishes, ventilation, power outlets, equipment, IT. That's a lot of information. All of it already written, validated, and approved by the client.
Revit needs a good chunk of that data to do its job. But Revit doesn't read PDFs. It expects shared room parameters, properly named, properly typed.
Between the two sits a human being with two screens (or three, these days). Program on the left, Excel on the right. Copy, paste, clean up merged cells, rebuild subtotals, map columns to another sheet to enable the Excel-to-Revit export, import into the model, re-export, double-check the concatenations and the XLOOKUPs... For a project this size, count on one to two weeks. Pure transcription. The information already existed; we just moved it.
And that's the easy part. Because at least you only do it once.
Then revision 2 of the program lands
The MSSS says it in its own guides: developing a program is an iterative process. Concrete translation: the program will change. Possibly several times.
Version 2 arrives by email on a Thursday afternoon. Sixty rooms modified, twelve added, eight removed. Which ones exactly? Good question. The document doesn't always say. So you check the Excel, put the two versions of the program side by side (a great use of AI, if you've never tried it), compare line by line, highlight in yellow, carry the changes into the model, verify again.
On a cultural centre project, I watched this cycle happen 8 times. And every time, the risk is the same: a change that slips through the cracks. Room 2.145 gets renumbered in the program but not in Revit, and suddenly an entire room data sheet points at the wrong room. Nobody notices until the area schedule gets formatted the night before the submission.
The area schedule, the deliverable that never dies
The area schedule isn't just an internal working tool. It's an administrative project-control deliverable that clients require. At every milestone — concept, preliminary, final — you have to demonstrate that what you've designed matches what was programmed, functional unit by functional unit, with variances and justifications.
In practice, that means: export the actual areas from Revit, paste them into yet another sheet, rebuild the variance formulas and the XLOOKUPs, format, send. The next day, a colleague moves three partitions and the schedule is already wrong.
I've seen teams redo this exercise every week for months. Two to four hours each time. Do the math over 18 months of design.
Let's put numbers on it
On a typical institutional project, being conservative: 30 to 40 hours for the initial data entry, 12 to 16 hours per program revision, 16 to 20 hours per area schedule submission, plus all the time lost reconciling versions and chasing errors. You can easily exceed 100 hours per year on a single project. Time spent not designing, just moving data.
Excel isn't the culprit
I want to be clear on this, because I love Excel. The problem isn't the tool; it's the role we make it play. Excel is excellent at analyzing data at a fixed point in time. It's incapable of maintaining a living link between two sources that evolve in parallel. Every export creates a frozen copy, and every frozen copy is a divergence waiting to happen.
What space programming software actually fixes
What's needed is to treat the program as what it really is: a central database, connected to the Revit model. Requirements entered once. Every room in the model linked to its program record through a stable identifier. The program-versus-designed comparison computed in real time instead of rebuilt by hand every Friday. A revision history that says who changed what, and when.
That's the problem we decided to solve with RoomStack: a space programming platform with bidirectional Revit sync, built for the reality of projects here. Not because it's an elegant technology problem, but because I've lived those 100 hours a year, per project, myself.
If you recognized yourself anywhere in this text, we're looking for pilot teams to test RoomStack on real projects. Get in touch.