Start Small, Think Big, Scale Fast: Ivan Teh's Framework Explained

Why sequencing matters

Enterprise technology adoption fails in predictable places. It fails when an organisation commits at full scale before it has evidence, and discovers the cost of being wrong only after the contract is signed. It fails in the opposite direction too, when a successful pilot sits in one department for years because nobody designed it to travel and nobody owns the decision to expand it.

Ivan Teh's three stage framework exists to address both failure modes with one sequence. Each stage answers a specific question, and the organisation is not supposed to move forward until that question has an honest answer.

Stage one: Start Small

The question this stage answers is not whether the technology works. Vendors will happily demonstrate that in a controlled setting. The question is whether this organisation, with its data quality, its systems, its politics and its people, can operate the technology and get a result from it.

A good pilot therefore has three properties. It is attached to a measurable business question, so that success is defined before the work starts. It is contained enough that failure is affordable and reversible. And it is staffed by the people who would run the system at scale, so that fluency is being built while the stakes are still low.

A common mistake is to select the easiest possible pilot in order to guarantee a positive result. That produces a clean report and no useful information. The pilot should be representative of the conditions the full deployment will face, including the messy data.

Stage two: Think Big

The question here is whether what was built in stage one can travel. Most pilots cannot, because they were designed to succeed rather than to generalise.

Thinking big means the data model, the governance rules and the integration approach are chosen for the organisation the business intends to become, not for the department that happened to host the trial. It means asking early which other functions would use this signal, what they would need it to look like, and who would be accountable for the model once it sits in front of decisions with real money attached.

This is also the stage where ambition is set at the level of strategy. The framing shifts from a project with a budget line to a change in how the enterprise makes decisions. That reframing is what unlocks the sponsorship required for stage three, and it is the reason this stage cannot be skipped just because the pilot went well.

Stage three: Scale Fast

Once evidence exists, delay becomes the expensive option. Sponsorship has a half life. Executive attention moves on. The team that built the pilot gets reassigned. Every month between proof and rollout raises the probability that the organisation quietly loses the capability it just paid to develop.

Scaling fast means standardising the pipeline, removing the manual steps the pilot tolerated because it was small, and putting the output in front of the people who actually hold the decision rights. It also means accepting that the version which scales will be less elegant than the version that was piloted, because it has to survive contact with the rest of the business.

Speed at this stage is a governance decision rather than a technical one. The constraint is almost never engineering capacity. It is the number of approvals, the clarity of ownership and the willingness of leadership to make the operating model change that the technology implies.

Where organisations get it wrong

Three errors account for most of the disappointment.

• Piloting forever. Stage one becomes comfortable. The pilot is renewed, extended and celebrated, and never scaled. This is usually a sponsorship problem wearing a technology costume.
• Skipping stage two. A successful pilot is rolled out directly, and the organisation discovers at month four that the data model only made sense for the original department.
• Starting at stage three. A large commitment is made on the strength of a vendor demonstration. When it underperforms, the organisation concludes that the technology does not work, when what actually failed was the sequence.

The framework does not remove risk. It moves risk to the point in the programme where it is cheapest to carry.