Spreadsheets vs scaffolding software: when to switch

Spreadsheets run a surprising number of scaffolding firms perfectly adequately, and the point at which they stop being adequate is genuinely hard to spot — because they do not break. They develop quiet inaccuracies that nobody can date.

The behavioural tell

The signal worth watching for is not a row count. It is when somebody asks a simple question — which structures are standing, which jobs have unbilled variations, whose card expires next month — and the answer involves phoning somebody rather than opening a file. At that point the sheet has stopped being the record even though everyone still maintains it.

Where spreadsheets specifically struggle here

• –Anything captured on site: adaptations and variations need recording as they happen, not typed up later
• –History — a sheet shows the current state and not how it got there
• –Concurrency, once more than one person needs to update it
• –Dates that need to prompt somebody, such as card expiry or hire periods
• –Linking things that belong together: a structure, its inspections, its adaptations and its variations

The switch does not have to be wholesale

Firms that move successfully tend not to switch everything at once. Taking the single area causing the most pain — usually variation capture, because it is the one costing money — and running it properly in one place proves the point without betting the whole operation on a migration.

Common mistakes

• –Waiting for a visible failure when the failure mode is quiet inaccuracy
• –Multiple copies with no agreed master
• –Comparing a licence cost against zero rather than the admin time it replaces
• –Migrating every historic row rather than what is currently live
• –Keeping the sheet running alongside indefinitely, so neither is trusted
• –Underestimating how much of the sheet's meaning lives in one person's head

In practice: three versions of the truth

A firm discovered it had three copies of its job tracker in circulation — one on the office machine, one on a shared drive, one emailed to a contracts manager who worked from it on site. Each had been updated independently for several months.

Reconciling them took two days and could not be done completely, because for a handful of jobs there was no way to establish which version was right. The firm had not lost data; it had lost the ability to know which data was true, which is worse because it is invisible.

Start where the money is

Firms that move successfully rarely start with compliance. They start with variation capture, because it is the area where a fortnight of proper recording produces a number somebody can see — and that number is what makes the rest of the rollout easy to argue for internally.

It also happens to be the hardest thing to do on a spreadsheet, since it needs capturing on site as it happens rather than typed up later.

Worth knowing: one person usually holds the sheet together

Every spreadsheet-run firm has somebody who understands why the sheet is laid out as it is, which columns matter and which are historic. That dependency is invisible while they are there and total when they are not, and it is frequently the real reason a firm moves.

• –Identify who actually holds the sheet's logic
• –Test what happens when they are away for a fortnight
• –Treat that dependency as a risk with a cost, not a quirk

Where this connects: one person usually holds it together

Every spreadsheet-run firm has somebody who understands why the sheet is laid out as it is, which columns still matter and which are historic. That dependency is invisible while they are there and total when they are not, and it is frequently the real reason a firm moves — not the features, but the realisation that the business cannot answer questions about itself without one person.

Worth testing deliberately rather than discovering. Ask somebody else to answer a routine question from the sheet — which structures are standing, which jobs have unbilled variations — and watch how far they get. What they cannot do is the actual risk.

• –Identify who genuinely holds the sheet's logic
• –Test what happens when they are away for a fortnight
• –Treat that dependency as a risk with a cost attached
• –Move the area causing most pain first, not everything
• –Set a date the sheet actually stops being maintained
• –Migrate what is currently true, not every historic row

One practical test: ask somebody else to use it

Ask a person who did not build the spreadsheet to answer two routine questions from it — which structures are standing, and which jobs have unbilled variations. Watch how far they get without asking anybody.

What they cannot do is the actual risk, and it is usually larger than anyone expects. The sheet is not the problem; the problem is that its meaning lives in one person's head, and that dependency is invisible until the fortnight they are away.