Locking scope before work began cut design time from 40 hours to 24.

The scope document named exactly what design would deliver

Each request now carried a scope document, and both sides agreed to it before work began.

Where an open question could change the work enough to put the date at risk, the document said so. Design committed to the deliverables it could deliver with confidence. Later sets of deliverables were tied to that first set as dependencies, and each got its own date once the first set was done.

A change to scope came in as a new request, linked to the open project

Team leads and designers could raise a change themselves, so the process did not block a project that needed to move. Change requests needed less review than new work, and each one left a record against the project.

Nine team leads moved to the process in two months

All nine team leads ran it. The first month was a trial: leads could still use the old process, as long as at least half of their new requests went through the new one. From the second month every new request used it, and the old process needed an exception approved in operational review. Pushback came with learning a new process while still delivering, and the trial month gave leads room to adapt.

The leads who ran it most consistently saw the largest gains

Results followed how each lead ran the process. Teams whose leads used it consistently and with intent saw the biggest improvements in delivery time and in the quality of what they delivered. Coaching for the others started from three questions: what actions could close the gap, what outcome each would produce, and how they would know the outcome was useful.