Phase 4 — production rollout

What you will learn The four things the scale-up phase actually requires, and how to stop the quiet collapse that happens three to six months after rollout.

The purpose of this phase

Scale the verified solution across the organisation and build a continuous improvement loop.

The emphasis lands naturally on "scale," but the hard part is the second half — the continuous improvement loop.

Scaling is not widening access. It is embedding.

Something that worked in the POC quietly falling out of use after a company-wide rollout is extremely common. It happens because of something the POC had and the rollout does not — attention. During a POC someone looks at it every day; after scaling, nobody does.

Four activities

1. Build and deploy the production environment

Mind what differs from the POC environment.

Item	POC	Production
Scope	5 suppliers	80
Exceptions	all by hand	needs automatic routing
On failure	the owner improvises	needs a fallback procedure
Access	one person	the whole team, by role

The "on failure" row is the key one. Work must not stop when the system stops. A manual fallback path has to be ready.

2. User training and onboarding

One person used the POC; now ten people use it. Those nine have no context.

Training must include:

Content	Why
What it does for you	sets expectations
What it does not do	prevents incidents caused by misunderstanding
How you know it was wrong	the check point
Who to tell if something is off	prevents things being left

The second matters most. Misunderstand it as "it handles everything" and people stop checking.

3. Monitoring and alerts

Decide what you will be watching.

That third alert matters. Errors are visible; not being used is silent. You have to catch declining usage with an alert.

4. Establish the improvement process

If it is not scheduled, nobody does it.

Cadence	What
Weekly	review errors, look for recurring patterns
Monthly	metric review, compared against Phase 1 numbers
Quarterly	review scope expansion (fold exceptions into automation)

Output

Operations manual & KPI dashboard

What goes in the operations manual

The KPI dashboard

Phase 1's numbers have to live somewhere people keep seeing them. If they only exist in a report, nobody looks three months later.

Gate — to call this phase finished

Does it run without hand-holding, and do metrics land on a dashboard?

If "the owner has to check it every day for it to work," it is not finished.

The real test is months 3–6 after rollout

What commonly happens in that window:

Point	What happens	Countermeasure
Month 1	unforeseen exceptions	caught by the weekly review
Months 2–3	initial attention fades	automatic alerts watch instead
Months 3–4	the work changes and it no longer fits	found in the monthly review
Month 6	the owner changes	you need the operations manual

The last row is the most frequently missed. When the person who built it leaves, nobody can fix it, and usage quietly declines.

And back to Phase 1

graph TD
  A["Phase 4 complete"] --> B["Data accumulates in operation"]
  B --> C["New improvements become visible"]
  C --> D["Phase 1: define the next project"]
  D --> E["Faster this time<br/>baseline, experience, and trust exist"]

An organisation that finished one project is much faster on the second. It knows how to measure, who to work with, and above all that this works.

Common misconceptions

"The POC went well — can't we just open it to everyone?"

That is precisely the most common failure. There are things a POC has and a rollout does not: training, monitoring, fallback procedures, an improvement cadence. Without them it quietly falls out of use in three to six months.

"Building monitoring too — isn't that the tail wagging the dog?"

Without monitoring you cannot keep proving the effect. And then you do not get budget for the next project. One dashboard is the key that opens the next one.

Check yourself

1. What does "scaling is not widening access but embedding" mean?

Answer

That opening up access company-wide is not enough. Training, monitoring, a fallback procedure, and an improvement cadence have to go with it; without them it quietly falls out of use in three to six months.

2. Why do you need a "volume dropped below half of normal" alert?

Answer

Because not being used is silent. Errors are visible; abandonment gives no signal at all. Catching the usage drop as an alert is what lets you find the cause early.

3. What breaks when the owner changes at six months?

Answer

When the person who built it leaves, nobody can fix it, problems get left alone, and usage quietly declines. The operations manual (does / does not do, responses, fallback, escalation) is what prevents this.

Once deployed you have to prove the effect. Most stop here → Measuring and reporting results