Scaling for a Rollout Programme Sized for something smaller than this.

• The programme is contracted, so the volume is not a forecast.
• The prototype was approved from a mock-up, and the drawings were reverse-engineered afterwards.
• Each site brings a condition the prototype never had.
• Release six no longer quite matches release one, and nobody can say when that happened.
• The people who drew the first release will not be the people drawing the twelfth.

Volume is the visible problem and it is the easier one. Consistency is what actually costs.

A programme runs for years. Staff change on both sides. Small unrecorded decisions accumulate: a detail adjusted for one site, a dimension corrected and not propagated, a hardware substitution made under pressure. Individually none of them matters. By release twelve the set has drifted from the one the brand approved, and unwinding it is far more expensive than preventing it.

The other failure is site variation treated as exception. The same column, the same slab fall, the same low soffit solved independently at every site, because the set never made the adjustment a documented option.

Talk to Us About Capacity →

Send the prototype and a recent site. What changed between them is the question.

Not a volume promise.

Scope is agreed per engagement and per release. What is committed is a calendar date against a defined scope, agreed at quoting.

Not a substitute for your programme management.

The drawing standard is held; the programme is yours.

Not automatic consistency.

Consistency comes from a record and a revision discipline, both of which require your input at the start. A supplier who says otherwise has not run a programme.