HyperTeamsPhase 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