Three Spreadsheets Means the Software Lost

Here is a free diagnostic for anyone running a property development business.

Count the spreadsheets your team maintains alongside the project management platform. If there are three or more, and at least one of them is treated as more trustworthy than the system itself, the software has already lost. That is not a discipline issue and more training will not touch it.

The interesting question is why it happens so consistently, across different companies using different products. The answer is three specific modelling failures.

Failure one: everything is built on durations

Standard project software asks how long a task will take, then schedules what follows.

In development, the dependencies that matter do not have durations. You cannot begin foundations until permits clear, and permits take however long the authority takes — unknown, unbounded, outside your control. Enter an estimate because the field demands a number and the schedule is wrong immediately.

What is actually needed is a dependency that resolves on an event rather than after a period. You can keep an estimate for planning, but it must never move anything. The moment an estimate is allowed to change state, the same problem returns wearing different clothes.

Failure two: cost, schedule and money are stored separately

This one causes the most ongoing human work.

A change order is a single fact about the world. It alters the budget, moves the programme and shifts the drawdown, all at the same moment, because it is one event.

Software that stores these as three unrelated records has not modelled reality — it has modelled three reports. Somebody then spends part of every week making the three reports agree, forever, and that job never finishes because change orders never stop.

Model them as three views over one commitment record and the reconciliation does not get faster. It disappears.

Failure three: ownership is treated as a field

A project frequently sits inside a joint venture whose reporting obligations do not match your internal structure. Most tools assume one project has one owner.

The usual workaround is duplicating the project so it can be reported two ways. The duplicates then diverge within a quarter, and now you have two wrong records instead of one right one.

Ownership needs to be a proper dimension so a single project can be reported differently to a partner and to an internal committee without duplication.

Where AI genuinely helps here

Not the generated summaries, which are pleasant and change nothing.

The application that pays is reading documents. A development accumulates thousands of contracts, variations, inspection reports and lender covenants, and the operationally important facts inside them get typed in by hand or never captured. Extraction is now reliable enough that people verify rather than transcribe, which turns keeping a system current from prohibitively expensive into routine.

Second is early warning: noticing that a pattern of small delays across several subcontractors predicts a serious schedule break in two months. Your own historical data contains that signal, and a model finds it more reliably than a weekly meeting.

Third is the chasing — unreturned variations, unbooked inspections, unevidenced lender conditions. Rule-based, high volume, currently consuming project manager time.

All three remove clerical work. The applications that attempt judgement — will this deal pencil, what should we bid — are not dependable yet, because data is thin and every market is local in ways that resist generalisation.

The option most people skip

The choice is usually framed as buy a platform or build your own. There is a third option that suits mid-sized developers better than either.

Keep accounting, document storage and site tooling as bought products. Build only the pipeline logic, stage-gate model and reporting layer on top, and integrate the rest. You own the part that makes you different and rent the parts that do not, and you avoid rebuilding commoditised capabilities that carry permanent regulatory maintenance.

Frequently Asked Questions

What does counting spreadsheets tell you?

Three or more alongside the platform, with one treated as more authoritative, means the software cannot represent how the business works. The problem is structural, so more configuration will not resolve it.

Why do duration-based schedules fail?

Because the dependencies that matter — permits, inspections — have no predictable duration. An estimate entered because the field requires one makes the schedule wrong the day it is created.

What causes most manual reconciliation work?

Storing cost, schedule and capital draw as three unrelated records when a change order alters all three simultaneously. Treating them as views over one commitment record eliminates that work rather than speeding it up.

Why is duplicating projects for reporting a bad idea?

Because the duplicates diverge within a quarter, leaving two inaccurate records. Ownership should be a modelled dimension so one project can be reported several ways without duplication.

Which AI applications work in this sector?

Document extraction, early variance detection across subcontractor delay patterns, and automated chasing of missing evidence. All remove clerical load. Judgement applications such as deal prediction remain unreliable.

What is the alternative to buying or building?

Assembly — buying accounting, document storage and field tooling, then building only the pipeline logic and reporting layer. This avoids rebuilding commoditised capabilities while owning what differentiates the business.

---

Full version: https://techcirkle.com/blog/real-estate-project-management-software

TechCirkle builds these systems: https://techcirkle.com/development/custom-software-development