| What you are deciding on | Large integrator | Specialist agency (us) |
|---|---|---|
| Best fit | Multi-year programmes, ERP-scale change, several countries or business units at once. | A defined process, a fixed scope, a result in a quarter. |
| Who does the work | A pyramid. Senior people scope and present; delivery is largely juniors under supervision. | The people in the meeting. That is the whole model, and it is also the constraint on how much we can take on. |
| Capacity | Effectively unlimited. They can staff twenty people next month; we cannot. | Limited by design. If we are full, we will say so rather than staff it with strangers. |
| Speed to first result | Months. Governance, steering committees and a discovery phase come first, and on a large programme that is appropriate. | Weeks. Days for the mini-audit, four to eight weeks to a first production flow. |
| Cost | Higher, and part of it buys things you may genuinely need: contractual scale, insurance, procurement compliance, a name your board recognises. | Lower for equivalent scope, mainly because there are fewer layers between the decision and the code. |
| Process weight | Heavy and documented. A real advantage in regulated, audited environments; an overhead on a two-month project. | Light. Fixed scope, one owner, weekly demos. Fine for a process; insufficient for a fifty-person programme. |
| Technology stance | Often anchored to partnerships and a preferred platform, which brings support and licensing leverage. | Stack-agnostic within your existing systems, which means fewer licences and no partner-driven bias. |
| Risk if it goes wrong | A large contract, a long recovery, but a counterparty with the balance sheet to make it right. | A small contract and a fast exit — and a smaller counterparty, which is a real difference you should price in. |
This is a comparison of shapes, not of quality. Good work comes out of both, and the failure mode in each is the same: a supplier taking on work of a size it is not built for.
The scope is one process or a small group of processes, and you want it in production rather than in a roadmap.
You want the people who scoped it to be the people who build it.
Speed matters more than the scale of the contract behind it.
You would rather not add platform licences to solve a problem inside systems you already own.
The programme spans several business units or countries and needs twenty-plus people staffed at once.
Procurement requires a supplier of a certain size, insurance level or audited methodology. That is a legitimate constraint and we will not meet it.
The work is inseparable from a major platform migration where the platform vendor’s partner network is genuinely useful.
You need a supplier who will still be contractually on the hook in five years at that scale.
A common and sensible arrangement is a specialist agency proving one process quickly while a larger programme runs alongside it. The fast result funds and de-risks the slow one, and the integrator gets a working reference implementation instead of a slide.
The failure mode to avoid is the reverse: a large programme that absorbs the one process which could have shown a result in six weeks, and then delivers it in eighteen months alongside everything else. If a process has a clear number attached and a clean boundary, take it out of the programme.
We have worked as a subcontractor inside larger programmes and we have worked beside them. Both are fine. What does not work is pretending a specialist agency can carry programme-scale governance, and we will say so at the first meeting rather than in month four.