Most Australian contractors run project controls on spreadsheets. For a long stretch of a company's life that is the correct decision, and pages like this usually skip straight past that to the sales pitch.
A spreadsheet is genuinely right for one project, run by the person who built the model, over a period short enough that its assumptions stay true. Flexible, universally readable, no procurement conversation. Do not let anyone tell you that is amateurish.
It stops being right at five specific points, listed below — and every one of them is structural rather than a question of how carefully the spreadsheet was built. A better spreadsheet does not fix them.
The honest test is not company size. It is whether a project going wrong quietly would materially hurt the business.
Taken seriously, because it is a strong case and because anyone who dismisses it has not run a small contracting business.
Spreadsheet controls do not fail because the spreadsheet is bad. They fail because the conditions that made it the right choice quietly stop being true, and nothing announces it.
Two workbooks built at different times by different people cannot be compared. The percentage complete in one does not mean what it means in the other, contingency is calculated differently, and rolling them into a portfolio view means someone manually reconciling definitions every month. This is usually the first crack, and it is normally papered over with a third spreadsheet.
A client disputes a claim, or a financier asks how the forecast was derived. A spreadsheet holds the current state — not who changed what, when, or why. The audit trail a claim needs is exactly the thing the format does not keep, and reconstructing it from emails and saved copies is where weeks disappear.
The model lives as much in the author's head as in the file. When they are on leave, or they resign, what remains is a workbook nobody wants to touch — because breaking a formula they cannot see is worse than producing nothing. This is the single most common way a controls function is lost.
Two or three days a month assembling the pack, and an hour looking at what it says. The analysis is the point and it is getting the leftovers — so the interesting question, what changed and does it matter, never gets asked properly.
Accelerate or not. Claim or absorb. Take the next job or hold capacity. A spreadsheet has no notion of an invalid result — a formula pointing one row off returns a number with the same confidence as a correct one, and nothing flags it. On decisions of that size, "probably right" is a position, not a fact.
Rarely a dramatic failure. Usually a slip found in month nine that was visible in month three, and a conversation with a client that could have been a conversation with your own team.
Structures that do not reconcile. A whole PERT had been built out that did not align to the work breakdown structure — both internally coherent, neither able to speak to the other.
Fixing it took three weeks: mapping the PERT milestones back to the WBS and rebuilding it into P6 work pack by work pack. Nothing was wrong with the analysis in either artefact. They simply could not be reconciled without a person doing it by hand, one pack at a time.
This is what off-system controls really cost. Not a wrong number — a structure nobody can join to anything else, discovered at the point you need the two halves to agree.
| Spreadsheet | Controls software | |
|---|---|---|
| Flexibility | Total — it does whatever you build | Bounded by what it models |
| Setup | None, it already exists | An import, and a decision to make |
| Consistency across projects | Only if one person builds all of them | Structural — the same definitions every time |
| Audit trail | None inherently | Recorded — who changed what, and when |
| Error detection | None. A wrong number looks like a right one | Computed from source data, with the working shown |
| If the author leaves | Effectively unmaintainable | Continues |
| Monthly effort | Rebuilt by hand every period | Import, review, publish |
| Cost | Already paid — plus the hours, which are not free | A line item you can see |
The comparison usually offered is software against nothing, which is dishonest. The real comparison has three columns.
A project controls engineer runs roughly $120,000 to $160,000 a year plus on-costs, and does far more than any software: judgement, negotiation, sitting in the room. Software starts at $395 a month including GST, priced on combined contract value rather than per seat. The spreadsheet appears free and is not — it costs the days spent rebuilding it each month, plus the value of whatever gets missed because nobody had time to look properly.
These are not substitutes for each other and any page telling you otherwise is selling something. The honest statement is narrower: software does the computation and the reporting a person would otherwise do by hand. It does not do the judgement, and it will not sit in a meeting with your client.
Aegis reads spreadsheets — it does not ban them. Excel and CSV are first-class imports alongside P6 and MS Project exports, and the column-mapping step tells you what is missing before it computes anything rather than silently assuming.
What it is built to retire is the standing monthly pack: the status workbook, the cost tracker, the risk register and the hand-assembled report that have quietly become your reporting system. Those are the tools Aegis genuinely displaces — not P6, not Procore, and not the spreadsheet you open to model a one-off question, which will always be the right tool for that job.
Every figure traces to the input that produced it, the analysis is recomputed rather than retyped, and the assessment is written against numbers the engine calculated — so the monthly question moves from can we trust this? to what is it telling us?
Yes, and most contractors do. It is the right tool for one project run by the person who built the model. The failures are structural and arrive at predictable moments — a second project, a disputed number, or the author leaving.
Any one of the five triggers above is enough. The most reliable signal is the fourth: when rebuilding the pack takes longer than reading it, the analysis has stopped happening.
The test is exposure, not headcount. If one project going wrong quietly would materially hurt the business, finding out early is cheap.
No, and don't try. Keep it for modelling one-off questions and exchanging data. Retire the standing monthly rebuild.
Most first imports are. The mapping step names what is missing rather than assuming, and a contract value is enough to start — the schedule can follow.
Aegis imports Excel, CSV, P6 and MS Project exports and computes earned value, float, risk exposure and a probabilistic forecast — with every number traceable to the input behind it.
Start your 14-day trial →