We have spent more than 1,000 hours embedded in developer workflows — sitting with development managers, in-house planners and consultant teams while they assembled responses to municipal comments, watching how the work actually gets done rather than how the process is described.
Then we did something slower. With our own in-house planners, we went back through completed approval files and reconstructed them: every requirement the city raised, every decision the applicant made in response, every number that moved, and every document that number was supposed to move with. Dozens of projects, rebuilt line by line from the record.
This piece walks through one of them, anonymized. The specific figures below come from that single file. The pattern does not. The same class of failure, in the same places, has shown up in project after project across the set — which is why we think it is worth writing down.
Who is involved, and how the loop works
Owns the site and carries its cost every month the project is not under construction. Hires and coordinates everyone below.
Usually five or more separate firms: an architect, a civil engineer who handles water and sewer servicing, a transportation engineer, a landscape architect, a planner. Separate companies, separate contracts, separate documents. Each produces and maintains its own drawings and reports.
A planner employed by the city coordinates the file. They circulate each submission to specialist city departments — transportation, water and servicing, urban forestry, urban design — and each department writes back with comments on the parts that touch them. Wherever this piece says “reviewer,” it means one of these municipal staff members: a city employee, not anyone on the developer’s payroll.
The developer's team submits a package. The city circulates it and returns written comments. The team revises and resubmits. The city comments again. Eventually city staff write a recommendation report telling council whether to approve. Each turn of that loop is measured in months, not weeks — which is what makes it worth understanding exactly why a loop happens.
The first full package of drawings + reports
Departments send back written comments
Laneway redesigned, servicing strategy set
The same requirements raised a second time
Height cut — the single biggest design change
Approved — with a condition attached
The first full package of drawings + reports
Departments send back written comments
Laneway redesigned, servicing strategy set
The same requirements raised a second time
Height cut — the single biggest design change
Approved — with a condition attached
A mistake goes in with the first submission, and nobody writes it down
The team files the opening package: architectural drawings, a transportation study, a servicing report, a landscape plan, a planning rationale. Hundreds of pages, five firms.
Inside it, already, is a contradiction. The transportation engineer’s study counts the parking spaces one way. The architect’s drawings count them another. The difference is small — a single space — and completely invisible unless you hold both documents open side by side.
No municipal reviewer writes a comment about it. That is the important part. Quality control on these files is comment-driven: what gets corrected is what a city reviewer thought to flag. An inconsistency nobody flags does not get caught late. It does not get caught at all.
Hold onto that one. It comes back at the end.
The city comments. The team responds. Nothing breaks.
City departments send their comments back. The planning department says the building is too tall for its context. The transportation department wants the laneway reconfigured. Urban forestry wants more soil volume for the trees. The servicing department challenges whether the sewers can take the additional flow.
The team responds properly. The laneway is redesigned and its area recalculated. The civil engineer picks a strategy for offsetting the additional stormwater flow. Modest, well-handled changes — our reconstruction records five dependencies moving in this round, and every one of them survived into the next submission intact.
If the story stopped here, this would be a post about a process that works.
The developer concedes the biggest point in the project — and that is when it goes wrong
The city’s planning department raises the height objection a second time. The developer concedes and cuts the building down.
This is a good outcome. It is what the process is for. City planning staff accepted the reduced massing, and that acceptance held all the way through to the final recommendation. On the question everyone was arguing about, both sides agreed.
But cutting a building changes the number of apartments in it. And the number of apartments is not just an architectural fact — it is an input. It drives the projected population. The population drives sewage flow. Sewage flow sizes the servicing strategy that the civil engineer built the entire drainage argument on.
The new unit count reached the architect’s own drawings. It did not reach the civil engineer’s servicing report. And it never reached the calculation underneath that report at all.
The concession was right. The arithmetic behind the concession never happened.
The stale number was not the old number
Here is the assumption almost everyone makes, us included when we started: the out-of-date document still shows the superseded figure. Find the fields that still say the old number and you have found the problem.
That is not what we found. After the height was cut, the architect’s drawings showed the new unit count. The servicing report showed a figure that matched neither the new count nor the pre-change one. A third number — updated at some point, from some intermediate version, by someone with no way of knowing which version was current.
This matters more than it sounds. It means a simple check against the old value catches nothing. Finding this requires comparing every claim in every document against every other claim, every round, across five firms. Which is exactly why it does not get done by hand.
The city can’t verify it — so instead of saying no, it attaches a condition
The reviewing engineer at the city’s servicing department reads the report and cannot make the numbers work. Nothing in it is obviously false. It simply cannot be confirmed against the rest of the submission.
So the municipality does not refuse the application. City staff recommend approval — with a legal condition attached that has to be satisfied before the project can proceed, and with several remaining details pushed into a later approval stage.
In the council chamber, this reads as a win. The project was approved. On the calendar it is another submission, another review cycle, and building permits sitting behind work nobody has scoped yet. The application was approved on schedule. The project was not.
For anyone reading this from outside the industry: this is the single most expensive move in the process, and it is almost invisible from the outside. An approval with conditions is not a green light. It is a green light contingent on resolving the exact thing that could not be resolved in time — and the developer keeps paying to hold the land throughout.
Deferral is what a review process does when verification is impossible. It is the city’s way of saying: we cannot check this, so it becomes your problem later.It never appears in the “we got approved” version of the story.
The approval document itself carried the mistake
Remember the parking count from the first submission — the one nobody commented on.
It survived both rounds of city comments untouched. It was still wrong at approval. And the final recommendation report, written by city staff and used to grant the approval, quoted two different parking figures in the same document, neither of which matched the drawings.
Nobody was careless. A municipal planner coordinating a file with roughly 370 individual comments across a dozen departments and five consultant firms cannot also be the system that checks whether every number agrees with every other number. Neither can the development manager on the other side of the table. That job is not assigned to anyone, because until recently it was not a job a person could realistically do.
None of the delay came from anyone wanting different things
That is the finding we did not expect and the one that has held up across every file we have reconstructed. There was no fight here. The city and the developer agreed on the height, agreed on the laneway, agreed on the trees. Every substantive question had an agreed answer well before approval.
The time was lost to three things, none of which is a disagreement:
- Changes that only half-landed. The response was correct; it just never reached every document that depended on it.
- Documents that could not be reconciled fast enough to be trusted. Not necessarily wrong — unverifiable, which costs the same.
- Conditions attached because verification was impossible in the room. Time borrowed from a later stage, at a worse rate.
Every one of these was detectable at submission time. None of them requires planning judgement, design taste, or an opinion about whether the building is any good. They require somebody to hold the project’s entire claimed state in their head at once and check it against itself — which is what nobody on a file this size can do, and what nobody is currently paid to attempt.
Across the projects we have reconstructed, what changes from file to file is which seam gives way. That it gives way somewhere has been consistent.
Five checks before the next resubmission
- List every number that moved this round, and name every document that quotes it. Not “the drawings” — the sheet and the table. If the team cannot produce that list in an afternoon, that is itself the finding.
- Look for third numbers, not old numbers. Partial updates are more common than no update at all, and they are invisible to a check against the superseded value.
- Re-derive, don’t re-read. If a calculation was sized on an input that has since moved, it is stale even when the answer still looks plausible. Especially when it still looks plausible.
- Price every deferral the day it is agreed. “We’ll resolve it at the next stage” is a schedule line item with a date and a carrying cost, not a resolution.
- Sweep for inconsistencies nobody commented on. The ones a city reviewer flagged will get fixed. The ones nobody flagged are the ones that reach the approval document.
One file gave us the numbers in this piece. Dozens gave us the confidence to generalize the mechanism — and the mechanism is structural, not behavioural. Any project where several firms maintain separate documents that quote each other’s numbers, revised in rounds, reviewed through written comments, will produce this class of failure. Hiring better consultants does not remove it. It just moves which seam it lands on.
What removes it is making the dependency between two documents into something that actually exists — an object with an owner, a current state, and something watching it — instead of an assumption living in five people’s heads across four firms.