Key takeaways
- Site staff abandon software when it adds a second job to their day rather than replacing part of the first, so the rollout has to remove work before it adds any.
- The first thing to put in the system should be the record the builder already needs for other reasons, such as a site diary, an incident record or a variation trail, not the thing that is most convenient for the office.
- Adoption only holds when one rule makes the system the single source of truth, which means the version in the system is the version that gets paid, defended or handed over.
- Rolling out everything at once guarantees that nothing becomes habit, because nobody can build fluency in a tool they open twice a week across five different functions.
- You can judge whether the rollout is working after a month by whether the paper version has stopped being produced, not by how many people have logged in.
Most construction software is not abandoned because it was the wrong product. It is abandoned because the office bought it, the site never needed it, and within a fortnight the crew was back to a notebook in the ute and a phone call to the supervisor. The licence keeps renewing. The data inside it goes stale. Nobody cancels it, because cancelling it would mean admitting the rollout failed.
The pattern is consistent enough to plan around. Site staff do not resist software as such — they resist anything that adds a second job to a day that is already full. If the system asks them to write something down twice, once on paper and once on a phone, they will do the paper version and skip the other. If it asks them to enter something the office could have entered themselves, they will treat it as an admin tax and route around it.
Adoption, then, is not a training problem. It is a records problem. The system becomes real on the day it becomes the only place a particular record exists, and everything else in this article follows from that.
Why site staff go back to paper
Paper has properties that software often loses. It is instant, it works with gloves on, it does not need a login, it does not lose signal, and it produces a physical object you can hand to someone. A notebook also never asks you to categorise anything before you can write a sentence.
When a crew reverts, the cause is almost always one of a small number of things. The entry takes longer than the paper version. The system is slow on the phone they actually carry. The fields do not match how the work is described on site, so people guess and then distrust the output. Or the information goes in and nothing visible happens, which teaches everyone that entering it was pointless.
The last one is the most damaging and the least discussed. If a supervisor logs a defect, a delay or a safety observation and never sees it actioned, they conclude the system is a filing cabinet for the office. From that point the entries get shorter, then sporadic, then nonexistent. The fix is not more encouragement. It is making sure the first things entered produce a visible response within a day.
There is also a legitimate privacy and security dimension that builders sometimes get wrong in both directions. Storing site records, photos and personal information about workers and subbies on a phone or in a cloud tool carries obligations, and the Office of the Australian Information Commissioner publishes guidance for small business on how personal information should be handled. The Australian Signals Directorate also publishes small business cyber security guidance that is written for organisations without an IT department. Neither of those tells you which product to buy, but both tell you that “the supervisor keeps it on his phone” is not a records strategy.
A rollout order that survives a wet week
- 1Pick the record you already must keepChoose the diary, the incident record or the variation trail — something the business needs regardless of the software.
- 2Run it in parallel for one job onlyPut a single project on the system and leave every other job alone so the change has a boundary.
- 3Make the system copy the only copyStop printing, stop emailing the spreadsheet, and stop accepting the paper version as the record.
- 4Fix the first complaint in a dayWhatever the crew says is slow or clumsy gets changed before the second week, or they conclude nobody is listening.
- 5Add the second function only after the first is habitWait until the first record is being completed without prompting before you turn on anything else.
Roll out the record you already have to keep
The first function you turn on should not be the one that is most useful to the office. It should be the one the business is already obliged to produce, because that obligation does the persuading for you.
On a residential job, the obvious candidates are the site diary, the incident and near-miss record, the variation trail, and the photographic record of work before it is covered up. Each of these exists for a reason that has nothing to do with the software: you need the diary to reconstruct what happened when a defect appears, you need the incident record because SafeWork NSW expects notifiable incidents to be reported and because your own records are what you rely on afterwards, and you need the variation trail because that is how you get paid for work you did not quote.
Those obligations are also why the record has to be reliable. A diary that exists in two places, one on paper and one in an app, is worse than a diary that exists in one place, because now you have to reconcile them and you cannot prove which is authoritative. Supervision duties in NSW turn on being able to show what was inspected, when, and by whom; the related article on NSW builder supervision duties sets out how that expectation works in practice, and it is the reason a diary is a good first candidate for the system rather than an afterthought.
Once the first record is live, resist the urge to add the second one for at least a month. A crew that has to learn five functions at once learns none of them. A crew that has learned one function properly will accept the second far more readily, because the phone is already in their hand and the login already works.
The one rule that makes the system the source of truth
Adoption is decided by a single rule, and the rule has to be enforced by the person who pays the invoices, not announced in a toolbox talk. The rule is this: if it is not in the system, it did not happen.
That sounds like a slogan until you work out what it means commercially. It means the variation that was agreed on site but never entered does not get claimed. It means the delivery that was short but not recorded does not get back-charged. It means the defect that was pointed out verbally and never logged is your problem, not the subbie’s. The rule is not there to punish anyone. It is there because a record that only exists in some people’s memories cannot be used, and a system that is optional is a system that quietly becomes a duplicate.
The mistake that costs the most. Running the paper version and the software version side by side indefinitely, because it feels safer during the transition. It guarantees that the system never becomes authoritative, that the office spends its time reconciling two records, and that when a dispute or a defect claim arrives nobody can say which version is the real one. Parallel running is a short transition tool, not a permanent arrangement.
The rule has a second half that builders often miss. If the system is the only record, the system has to be usable when it matters. That means the phone version has to work in a basement, entries have to be possible in a few taps, and there has to be a clear answer for what happens when someone genuinely cannot get signal. A rule that cannot be followed in the conditions the crew actually work in will be ignored, and once one rule is ignored the rest follow.
It also means the office has to stop accepting the workaround. If a supervisor rings through a variation and the office enters it on their behalf, the system is still working. If the office lets the supervisor keep a paper list and enters it at month end, the system is not the source of truth and everyone knows it.
What to roll out first, second and never
A sensible sequence for a residential builder looks like this. First, the daily record: diary, weather, labour on site, deliveries, visitors. It is short, it is daily, and it creates the habit of opening the tool. Second, the exception record: incidents, near misses, defects, and anything that needs a photo. This is where the system starts earning its keep, because photos attached to a location and a date are far more useful than photos in a camera roll.
Third, the commercial trail: variations, instructions, and the correspondence that supports them. This is usually the point at which the office sees a return, because variations that get captured on the day get claimed instead of written off.
Fourth, and only if the earlier stages have stuck, the quality and compliance material: inspection records, hold points, and the evidence trail for work that is about to be covered. This is also where product evidence starts to matter. Non-conforming building products are a live regulatory issue in NSW, and the SWMS template guidance for residential builders covers the parallel paperwork problem on the safety side — both are areas where a record kept in the system is worth far more than a folder of certificates nobody can find.
What never to roll out first: anything that exists mainly to report upward. Timesheet approval workflows, dashboards nobody on site will look at, and progress claims that require a site person to enter data the office could derive themselves. Those can come later, once the crew trusts the tool. Introducing them first is the fastest way to teach everyone that the software is for the office.
What to check at the one-month mark
- The paper version of the first record has stopped being produced anywhere on the pilot job.
- The supervisor can answer a question about last week using the system without asking anyone.
- Entries are being made on the day they describe, not batched at the end of the week.
- Nobody is keeping a private spreadsheet as a backup copy of the same information.
- Subbies and suppliers are being asked for information through the system rather than by phone.
- The office is not re-typing anything that was already entered on site.
- At least one change has been made to the system because a site person asked for it.
A worked example: one builder, one job, one record
A builder in western Sydney with a handful of supervisors and a steady run of residential projects bought a project management platform after a difficult handover. The handover had gone badly because nobody could reconstruct when a wet area had been waterproofed, who had inspected it, and what the photos showed. The office assumed the platform would fix this by giving everyone a place to put things.
Six weeks later, almost nothing was in it. Supervisors were still keeping a paper diary, the office was still chasing photos by text message, and the platform held a handful of entries made in the first week and then abandoned.
The mistake was the rollout order. The office had turned on everything at once: diaries, defects, variations, safety observations, and a dashboard for the director. The first task a supervisor met on a Monday morning was a five-field diary form that asked them to categorise the day before they could describe it, and the second was a defect form with a list of categories that did not match the way the trades actually described defects.
The fix was to strip it back to one thing: the diary entry, with three fields and a photo, entered at the end of the day. The categorisation was removed. The dashboard was switched off. The office stopped accepting the paper diary on that job and stopped entering anything on the supervisor’s behalf. Within a fortnight the diary was being completed daily, and the director could answer the question that had caused the original problem — when was this area waterproofed and who saw it — without ringing anyone.
Only then did the second function go on: defects, with a photo and a location, and a rule that anything raised had to be closed out or explicitly deferred by the supervisor. That took longer to stick, because it required a visible response from the office. But it stuck, because the tool was already part of the day.
How to tell whether it is working after a month
Login counts tell you nothing. A crew can log in every morning and still keep the real record on paper. The measure that matters is whether the parallel record has stopped.
At the one-month mark, walk the pilot job and look for the paper version. Is there still a diary in the site shed? Is there still a whiteboard list of defects that never makes it into the system? Is the office re-typing anything that was already entered on site? If any of those are still true, the system is a duplicate and the rollout has not landed, regardless of what the usage report says.
The second test is whether the system can answer a question. Ask the supervisor something that happened last week — a delivery, a delay, an inspection — and see whether they reach for the phone or for their memory. If they reach for the system, it is working. If they reach for the notebook, it is not.
The third test is whether anyone has changed anything because a site person complained. A system that is never adjusted is a system nobody is using seriously. The first change might be a field removed, a dropdown simplified, or a photo requirement relaxed for a particular task. The point is that the crew can see that raising a problem produces a fix, which is what converts compliance into use.
If the month has gone badly, do not respond by adding training. Respond by removing scope. Cut back to the one record that matters, delete the fields nobody fills in, and enforce the single rule again. It is far easier to add the second function to a crew that trusts one than to rescue five functions nobody uses.
Where this fits with the rest of your obligations
None of this replaces the obligations themselves. A diary in a system is still a diary, and it still has to record what actually happened. An incident record in an app still has to meet the reporting expectations that apply to the event, and SafeWork NSW remains the regulator for notifiable incidents in NSW. A variation trail in a platform is still only as good as the contract it sits under.
What the system changes is your ability to prove what you did. For a licensed builder in NSW, that ability shows up in defect disputes, in insurance matters, and in the record-keeping that sits behind your licence obligations. The guide to how NSW builder CPD works covers the licensing and continuing development side, and the course catalogue covers the technical areas where records matter most.
The practical conclusion is not that every builder needs a platform. It is that a platform only earns its cost when it holds a record that nothing else holds. Choose that record deliberately, enforce one rule about it, and measure the rollout by what has disappeared from the site shed rather than by what has appeared in the dashboard.
Questions builders ask
Why do my site staff keep using paper after we bought software?
Usually because the software adds a second version of a record rather than replacing the first. If the paper diary is still being kept and still being accepted, the system is optional, and optional systems lose to a notebook every time. The fix is to stop producing the paper version, not to run more training.
What should we roll out first on a residential job?
Start with a record the business is already obliged to keep, such as the site diary, incident record or variation trail. Those have a reason to exist that has nothing to do with the software, so the crew does not need persuading. Leave everything else switched off until that first record is being completed without prompting.
How long should we run paper and software in parallel?
As a transition tool only, and as briefly as the job allows. Permanent parallel running guarantees that the system never becomes authoritative and that the office spends its time reconciling two records. It also creates a real problem in a dispute, because nobody can say which version is the true record.
Should we measure adoption by logins?
No. Logins measure nothing useful, because a crew can log in daily and still keep the real record on paper. Measure whether the parallel record has stopped being produced, and whether the supervisor can answer a question about last week using the system rather than their memory.
What do we do if nobody is using it after a month?
Cut the scope rather than adding training. Reduce the system to the single record that matters most, remove the fields nobody completes, and enforce the rule that the system copy is the only copy again. Adding more functions to a crew that has not adopted one makes the problem worse.
Does using software change our record-keeping obligations?
No. The obligations are the same whether the record is on paper or in an app, including how personal information about workers and subbies is handled. What changes is how quickly you can produce the record when a defect, a claim or a regulator asks for it.
Sources
- Small business cyber security · Australian Signals Directorate
- Privacy for small business · Office of the Australian Information Commissioner
- Small-scale technology certificates · Clean Energy Regulator
- Non-conforming building products · NSW Government
Published 22 June 2026. General information for builders, not legal, financial or engineering advice for a specific job. Check current requirements with the relevant regulator or standard before relying on them.
