What scaffolding software should include as standard

Most products in this space will hold a job, a take-off and a list of operatives. What separates them is whether the things that are connected in reality are connected in the system — because almost every expensive problem in scaffolding happens at a join.

The joins that matter

• –An adaptation that should generate a variation, so work done on site becomes work that gets paid for
• –A structure and its inspection history, so coverage can be stated rather than assumed
• –A take-off and what was actually issued from the yard
• –An operative's card and training and the work they are allocated to
• –A hire period and the date a structure was actually struck

A product that stores all five and joins none of them has replaced several spreadsheets with one more expensive system. The join is the value.

Capture has to work on site

The second distinguishing feature is whether site can actually use it. Adaptations and variations are recorded properly or not at all depending on whether a chargehand can log one in under a minute, in poor weather, with gloves on and no signal. A product designed for an office and issued to a site tends to be used for the first fortnight.

Where it is fair for a product to stop

No system determines whether a structure needs bespoke design, judges whether an inspector was competent, or notices something nobody recorded. It can hold the picture, join the parts, prompt on dates and produce a job's history on request. Claims beyond that are worth probing.

Common mistakes

• –Assessing modules separately without testing whether they connect
• –No route from an adaptation to the variation it should generate
• –Evaluating on an office machine and never on a phone in bad conditions
• –No offline behaviour, on sites where signal is unreliable
• –Expecting the product to make design or competence judgements
• –Buying on a feature list rather than on the joins your jobs actually need

In practice: testing the join

A firm evaluating two products asked both the same question: log an adaptation on site, then show me the variation it generated. One product produced it in two steps. The other stored the adaptation in an operations module and the variation in a commercial one, with no route between them — a chargehand would log the adaptation and somebody in the office would separately have to know to raise the variation.

Both products listed adaptations and variations as features. Only one of them connected the thing that happens on site to the thing that gets invoiced, which was the entire reason the firm was buying anything.

Ask to see it fail

Demonstrations show a product succeeding. More informative requests: show me a job where the data is incomplete, show me what happens when somebody logs something wrong, show me a structure that was struck without being recorded.

How a system behaves when reality is untidy is how it will behave most of the time, because reality is untidy most of the time.

Worth knowing: ask what leaving looks like

Job history, adaptation logs and inspection records may be needed years after a job closes — potentially after the relationship with the vendor has ended. What exports, in what format, and whether attachments come with it, are questions far easier to settle while signing than while leaving.

• –Establish export format and scope before signing
• –Confirm attachments and photographs export alongside records
• –Ask how long data stays available after termination

Where this connects: ask to see it handle bad data

Demonstrations show a product working on complete, consistent records. Real operations are neither. The informative requests are the opposite of what a vendor will offer: show me a job where the data is incomplete, show me what happens when somebody logs something wrong, show me a structure struck without being recorded.

How a system behaves when reality is untidy is how it will behave most of the time. A product that handles the clean case beautifully and has no answer for the messy one will be abandoned within a year, because the messy case is the operation.

• –Ask to see incomplete and incorrect data handled, not the clean case
• –Check whether a mistake can be corrected without losing the audit trail
• –Test what happens when a record is created out of order
• –Confirm an adaptation can become a variation in one step
• –Check offline behaviour where signal is worst
• –Confirm one structure's full history can be produced on request