Rolling out scaffolding software without losing a job

Implementations in this sector rarely fail on configuration. They stall on data and on adoption — specifically on discovering how much of how the firm works has never existed anywhere except in the heads of two or three people.

What actually takes the time

Job lists that disagree with the accounts system. Rates that vary by client for reasons nobody can fully explain. Structures standing on sites with no record of when they went up. Materials in the yard that do not match what the last take-off said was issued. None of this is created by the implementation; it is simply the first time anything has required it to be consistent.

Which is why plans that allocate more time before go-live than after it tend to go better, and why an implementation finding a lot of data problems in week one is usually going well rather than badly.

Sequence by risk, not by ease

The instinct is to start with a simple job. It proves very little. Running one genuinely awkward contract early — several structures, a design change, adaptations, a disputed variation — surfaces the real gaps while there is still time to act on them.

Site adoption decides the outcome

Office adoption is usually straightforward because the office chose the system. Site adoption is where rollouts are won or lost, and resistance from a chargehand is nearly always information: it is slower than what it replaced, it asks for something they do not have to hand, or it duplicates a form they still have to complete anyway. Treated as feedback, most of that is fixable in a fortnight.

Common mistakes

• –Planning around vendor configuration time rather than your own data cleanup
• –Starting with simple jobs and hitting the hard cases when it is too late
• –Training the office thoroughly and site briefly
• –Leaving the old process running in parallel indefinitely
• –Treating low site usage as resistance rather than as feedback
• –Declaring completion before chargehands are using it daily

In practice: the rates nobody could explain

A firm three weeks into an implementation stalled on pricing. The system needed rates per client; the firm had rates that varied by client for reasons that had accumulated over a decade, and the two people who understood why were the managing director and an estimator who had retired.

The implementation did not cause that problem. It was the first thing that had ever required the pricing to be written down coherently, and the fortnight spent resolving it was work the firm needed to do regardless.

Pick the go-live date carefully

Scaffolding has busy periods and a rollout during one will lose. Equally, a quiet period may not generate enough live work for the system to be properly tested before the pace picks up.

The workable compromise is usually to go live just before activity rises, so there is enough real work to exercise it and enough slack to fix what breaks.

Worth knowing: decide when the old way stops

Rollouts stall most often because the previous process is never switched off. Both run in parallel, neither is complete, and people use whichever is quicker for the task in front of them — which means the new system's data is partial and therefore not trusted, which justifies continuing to use the old one.

• –Set a date the old process actually stops, and hold it
• –Accept a short parallel period, not an indefinite one
• –Check whether anybody is keeping private notes alongside — that is the real signal

Where this connects: decide when the old way stops

Implementations stall most often because the previous process is never switched off. Both run in parallel, neither is complete, and people use whichever is quicker for the task in front of them — which means the new system's data is partial, therefore not trusted, which justifies continuing with the old one. The loop is self-sustaining and very hard to break later.

Setting a date the old process stops, and holding it, is the single most useful decision in a rollout. So is watching for private notes running alongside, which is the clearest available signal that the system is not yet doing the job somebody needs it to — and a far better prompt than a usage dashboard.

• –Set a date the old process stops, and hold it
• –Accept a short parallel period, not an indefinite one
• –Watch for private notebooks running alongside — that is the real signal
• –Sequence by dependency: the register before the routines that reference it
• –Allocate more time before go-live than after
• –Train the people on site as thoroughly as the office