Large IT consultancies do not usually fail because they lack talented people.
They fail because their operating model often separates senior expertise from day-to-day delivery, rewards billable activity rather than results and creates more coordination overhead as programmes grow.
For CIOs, CTOs and transformation leaders, the result can be slower decisions, weaker accountability and greater supplier dependency — despite paying a premium for scale, brand recognition and perceived safety.
The question is not whether large consultancies are capable. Many are.
The question is whether their commercial and delivery model is suited to complex software work where progress depends on senior judgement, rapid feedback and clear ownership of outcomes.
Why does the large consultancy model break down?
The traditional consultancy model is designed to scale people and revenue efficiently. That does not always mean it is designed to deliver the client’s outcome efficiently.
Common weaknesses include:
| Structural issue | What the client experiences |
|---|---|
| Pyramid staffing | Senior specialists sell the engagement but junior teams perform much of the delivery |
| Utilisation-based economics | More billable activity can generate more supplier revenue, even when progress is slow |
| Large delivery teams | More meetings, reporting lines, handovers and coordination |
| Rigid commercial controls | Changes become slow, expensive and contractually defensive |
| Standardised methodologies | The delivery model is applied to the organisation instead of adapted to its constraints |
| Weak knowledge transfer | The client becomes dependent on the supplier to operate or change the system |
None of these problems is inevitable. But they are predictable consequences of the way many large consultancies are structured.
Senior people sell the work. Junior teams deliver it
A common consultancy pattern is that the most experienced people lead the pitch, shape the proposal and establish credibility with senior stakeholders.
Once the contract is signed, their involvement reduces.
Delivery is then transferred to a larger team of consultants who may be capable but lack the same level of technical authority, organisational context or decision-making power.
This creates several problems:
- Important assumptions are lost during handover.
- Decisions are escalated through multiple management layers.
- Client stakeholders repeat the same context to different people.
- Senior expertise becomes available intermittently rather than continuously.
- The people doing the work may not have the authority to challenge the original plan.
The client believes it has bought access to senior expertise. In practice, it may have bought occasional oversight supported by a much larger delivery pyramid.
For routine implementation work, that model can be acceptable.
For legacy modernisation, regulated systems, complex integrations or distressed delivery programmes, intermittent senior involvement creates risk. The hardest decisions cannot always wait for the next steering committee or escalation call.
Billable activity is not the same as delivery progress
Many traditional consultancy engagements are built around day rates, utilisation targets and team size.
This creates a basic commercial tension.
The client wants the problem resolved with the least necessary time, cost and complexity. The supplier makes more revenue when more people remain engaged for longer.
That does not mean consultants deliberately slow the work. It means the system does not automatically reward speed, simplicity or reducing the client’s dependency.
A programme can appear busy while making limited progress:
- Backlogs grow.
- Discovery continues without firm decisions.
- Reporting becomes more detailed.
- Governance expands.
- More specialists are added.
- Delivery dates continue to move.
Activity is visible. Outcomes remain uncertain.
The commercial model should therefore be judged by where it places risk.
Does the supplier carry meaningful responsibility for delivering a result? Or is the client paying for effort regardless of whether the programme achieves its intended outcome?
Bigger teams create more coordination overhead
Adding people to a complex software programme can increase capacity. It can also increase communication costs.
Every additional team, supplier and management layer introduces more interfaces:
- More meetings
- More reporting
- More approvals
- More dependencies
- More handovers
- More opportunities for context to be lost
As the programme expands, people spend more time coordinating the work and less time resolving the underlying problem.
This is particularly damaging when the work requires fast technical decisions.
A small, senior team can often investigate an issue, agree an approach and test it quickly. A large programme may need the same decision to pass through architecture governance, commercial review, programme management, security and multiple supplier teams.
Governance is necessary. Excessive governance becomes a delivery constraint.
The objective should not be to remove controls. It should be to keep decision-making proportionate to the risk and complexity of the work.
Fixed price does not fix a weak delivery model
Fixed-price delivery is often presented as the answer to open-ended day-rate consultancy.
It can provide useful cost certainty, but fixed price does not automatically create accountability or protect the client.
A poorly structured fixed-price contract can produce different problems:
- The supplier adds substantial contingency to cover uncertainty.
- The scope becomes rigid before the problem is properly understood.
- Necessary changes are pushed into expensive change requests.
- Teams optimise for contractual acceptance rather than long-term quality.
- Both sides spend time debating whether work is in or out of scope.
- Technical debt is created to protect margin or meet a deadline.
Time and materials is not automatically irresponsible either. It can be appropriate where the problem is genuinely uncertain and the client retains strong product and technical control.
The real issue is not simply fixed price versus day rate.
It is whether the commercial structure aligns the supplier with the client’s desired outcome.
| Commercial model | Main advantage | Main risk |
|---|---|---|
| Time and materials | Flexible where scope and complexity are uncertain | The client carries most of the cost and delivery risk |
| Fixed price | Greater budget predictability | Can encourage defensive scope management and hidden contingency |
| Outcome-based | Supplier incentives are tied more closely to a defined result | Outcomes must be measurable and partly within the supplier’s control |
| Phased fixed price | Limits exposure while evidence is gathered incrementally | Requires clear decision points and disciplined scope management |
For a more detailed supplier assessment framework, read How to Evaluate a Software Consultancy Before You Sign.
Standard methods can ignore organisational reality
Large consultancies often bring mature frameworks, templates and delivery methods.
That can be valuable. Proven patterns reduce unnecessary reinvention.
The problem begins when the method becomes more important than the context.
Complex organisations rarely operate under ideal conditions. They may have:
- Legacy platforms that cannot be replaced immediately
- Regulatory or security constraints
- Multiple incumbent suppliers
- Weak documentation
- Limited internal capacity
- Political or organisational sensitivities
- Critical systems that cannot tolerate lengthy disruption
A delivery approach that worked in another company may not work in this environment.
Strong consultancies use frameworks as starting points. They do not force the organisation to conform to a predetermined transformation model.
The work should begin by understanding the system as it actually exists: its dependencies, constraints, risks and operating realities.
Large engagements can create long-term supplier dependency
A consultancy should leave the client more capable than it found them.
Too often, the opposite happens.
Knowledge remains distributed across supplier teams. Documentation is incomplete or quickly becomes outdated. Internal employees are kept at a distance from key decisions. Proprietary processes make transition difficult.
The client may own the software but still depend on the consultancy to understand, maintain or change it.
This dependency can be commercially attractive to the supplier. It is rarely healthy for the client.
Common warning signs include:
- The supplier is the only party that fully understands the architecture.
- Important operational knowledge is held by individuals rather than documented.
- Internal teams cannot deploy or support the system independently.
- The exit plan is discussed near the end of the contract.
- Transition requires a separate, expensive programme.
- The client cannot change supplier without significant delivery risk.
Knowledge transfer should not be an activity scheduled for the final weeks of an engagement.
It should be designed into the delivery model from the beginning.
When is a large consultancy the right choice?
Large consultancies are not always the wrong choice.
Their scale can be valuable where an organisation needs:
- Rapid mobilisation across multiple countries
- A large volume of implementation resources
- Broad regulatory or sector coverage
- A single supplier across many workstreams
- Significant procurement and commercial capacity
- A widely recognised assurance brand
- Access to established platform partnerships
The problem is assuming that supplier size automatically reduces delivery risk.
A large brand may provide commercial reassurance. It does not guarantee that the most experienced people will remain close to the work or that the programme will move quickly.
The right supplier depends on the nature of the problem.
Where the work is repeatable and resource-heavy, scale may be an advantage.
Where the work is ambiguous, technically difficult or highly constrained, a smaller senior team may resolve the problem faster and with less overhead.
Large consultancy versus specialist consultancy
| Area | Large consultancy | Specialist consultancy |
|---|---|---|
| Mobilisation | Can provide large numbers of people quickly | Usually mobilises a smaller, focused team |
| Senior involvement | Senior leaders may oversee several engagements | Senior experts are more likely to remain involved in delivery |
| Delivery method | Established, standardised frameworks | More adaptable to the client’s specific context |
| Governance | Extensive programme and reporting structures | Leaner governance with shorter decision paths |
| Commercial model | Often based on team size, utilisation and long-term programmes | More likely to use phased, fixed or outcome-led delivery |
| Knowledge transfer | Can be treated as a separate transition phase | Often embedded directly into delivery |
| Best suited to | Large-scale rollout and repeatable implementation | Complex, high-risk and technically ambiguous problems |
Neither model is universally better.
The commercial mistake is choosing a supplier based on perceived safety rather than fit.
What does a better consultancy model look like?
A better delivery model reduces the gap between the people making commitments and the people doing the work.
It should include five characteristics.
1. Senior expertise stays involved
The people who diagnose the problem and shape the approach should remain close to delivery.
This reduces handovers, shortens decision paths and ensures difficult issues are addressed by people with sufficient experience and authority.
2. Outcomes and risks are explicit
The engagement should define:
- The business or operational outcome
- How progress will be measured
- Which assumptions must be tested
- Which risks could prevent success
- What evidence is needed before further investment
- Who owns each decision
A backlog is not an outcome. A team being busy is not evidence of progress.
3. Teams stay small and multidisciplinary
Complex software delivery usually requires a blend of engineering, architecture, delivery, security and product judgement.
That does not necessarily require a large team.
A small group of experienced people with clear authority can often move faster than a larger organisation divided into specialist functions and reporting layers.
4. Delivery is phased around evidence
Large commitments should not be made before critical assumptions are tested.
A stronger approach is to divide the work into controlled phases:
- Diagnose the current position.
- Identify the highest-risk assumptions.
- Test those assumptions quickly.
- Prove the proposed approach.
- Scale only when the evidence supports it.
This reduces the risk of committing to a large programme based on an incomplete understanding of the problem.
5. Independence is designed in from the start
The client should retain control of:
- Intellectual property
- Source code
- Architecture decisions
- Environments
- Documentation
- Operational knowledge
- Supplier transition options
A successful consultancy engagement should make the supplier progressively less essential.
Five questions to ask before appointing a consultancy
Who will actually deliver the work?
Request names, roles and expected time commitments. Do not accept a proposal built entirely around senior people who disappear after contract signature.
What outcome are you prepared to own?
Look for a clear business, operational or delivery result. Be cautious when the answer focuses only on providing resources or completing activities.
How will you test the riskiest assumptions?
Strong suppliers identify uncertainty early. Weak suppliers offer false certainty before discovery has taken place.
How will you transfer knowledge to our team?
Ask how documentation, pairing, training, operational ownership and handover will work throughout the engagement.
What happens if the original plan is wrong?
Software delivery involves uncertainty. The supplier should explain how evidence will change the plan without creating commercial conflict or uncontrolled cost.
How Catapult approaches complex software delivery
Catapult is structured around small, senior teams that remain closely involved in delivery.
We focus on understanding the actual constraint before recommending a large programme. That may mean reviewing an existing architecture, stabilising a critical delivery, proving a proposed solution or helping an internal team regain control from an incumbent supplier.
Our approach is based on several principles:
- Start with the problem, not a preferred technology or framework.
- Test high-risk assumptions before scaling investment.
- Keep senior engineering and delivery expertise close to the work.
- Use existing systems and internal capability wherever practical.
- Make progress visible through working evidence.
- Build knowledge transfer and operational ownership into delivery.
- Avoid creating unnecessary long-term supplier dependency.
For some organisations, that leads to a focused diagnostic or technical review. For others, it leads to a phased delivery or Build. Operate. Transfer. engagement in which Catapult builds and operates a capability before transferring it into the client’s organisation.
The aim is not to maximise the size or length of the engagement.
It is to resolve the problem, reduce delivery risk and leave the organisation able to move forward without avoidable dependency.
Talk to Catapult about your software delivery challenge.
Frequently asked questions
Why do large consultancy projects fail?
Large consultancy projects often fail when senior expertise is separated from delivery, commercial incentives reward billable effort, decision-making passes through too many layers and the client becomes dependent on the supplier.
Are large consultancies always a bad choice?
No. They can be effective where an organisation needs significant implementation scale, international coverage or a large volume of repeatable delivery work. The model is less effective when success depends on rapid senior judgement and close adaptation to a complex environment.
Is fixed-price software development better than time and materials?
Neither model is automatically better. Fixed price provides greater cost predictability but can create rigid scope and expensive change control. Time and materials provides flexibility but leaves more risk with the client. The appropriate model depends on uncertainty, governance and how clearly outcomes can be defined.
What is the difference between a boutique and a large consultancy?
A boutique or specialist consultancy typically uses smaller teams, retains greater senior involvement and adapts its approach more closely to the client’s context. A large consultancy offers more scale, broader coverage and greater mobilisation capacity, but may introduce more management layers and handovers.
How can organisations avoid consultancy vendor lock-in?
Organisations should retain ownership of code, environments, architecture and documentation. Knowledge transfer, internal pairing, operational training and exit planning should begin at the start of the engagement rather than being delayed until the contract ends.
