How to Fix Delivery Problems in a Consultancy Before They Cost You Clients

Clients rarely leave a consultancy over a single bad project; they leave because the third invoice arrived alongside the second apology, and somewhere between the two they stopped believing that the next phase would be different. If you lead a technology services firm where quality holds on smaller engagements but wobbles the moment a contract gets serious, this piece is about how to fix delivery problems in a consultancy before that quiet loss of belief turns into a formal notice period, and it starts with an uncomfortable observation: the problem is almost never the people doing the work.

Firms at this stage usually have talented consultants, reasonable clients and a healthy pipeline, which is precisely why the delivery problems are so confusing to the leadership team. The work that used to go well now goes badly in ways nobody can quite explain, and the explanations offered internally, that the client was difficult or the scope moved or the team was stretched, are all true and all beside the point.

The three root causes that sit under most delivery problems

When delivery slips in a firm of roughly twenty to sixty people, the cause is almost always one of three structural weaknesses, and often all three at once, reinforcing each other.

Hero-driven delivery

The first and most common is what we call delivery by biography, where the outcome of a project depends less on your firm's approach than on which individual happens to be leading it. Your best two or three people run excellent projects because they carry a method in their heads, and everyone else improvises, which worked fine when those heroes could touch every engagement but breaks the moment you win more work than they can personally oversee. The tell is simple: if you can predict a project's health from its staffing list before it starts, you do not have a delivery capability, you have some capable individuals.

No standard way of working

The second cause follows from the first. Because the method lives in people rather than in the firm, every project reinvents its own estimation approach, status reporting, risk log and definition of done, which means every project also reinvents its own mistakes. Larger contracts expose this brutally, since a big client's procurement and governance teams will ask how you run projects, and a firm without a standard answer ends up adopting the client's method instead, playing away from home on every engagement.

Weak project governance

The third cause is the absence of any mechanism that surfaces trouble early. In most struggling firms, project problems travel by corridor conversation, reaching leadership only when a client escalates or a milestone slips publicly, and by then the options are limited and expensive. Weak governance is also the fastest route to margin erosion, because scope creep, unbilled rework and quiet over-servicing all thrive where nobody is looking, a dynamic we cover in more depth in how to improve delivery margins in a professional services business.

A delivery health check you can run this week

Before fixing anything, establish where you actually stand, which you can do in a week with honest answers to eight questions. Score each one as yes, partly or no, and resist the temptation to be generous.

1. Could a competent new hire find a written description of how your firm runs a project, from kickoff to closedown, without asking anyone?
2. Do all live projects report status in the same format, on the same cadence, with the same definition of red, amber and green?
3. Does leadership learn about a project problem from a report before learning about it from the client?
4. Are estimates produced by a shared method rather than by whoever happens to be scoping?
5. When a project goes well, can you say why in terms other than the names of the people on it?
6. Is there a defined point at which a delivery lead must escalate, rather than a cultural expectation that they will cope?
7. Do change requests get priced and agreed, or absorbed to keep the client happy?
8. Has a post-project review changed how the next project was run at any point in the last year?

Fewer than five clear yeses means delivery is running on goodwill and talent, both of which are finite, and a bigger contract will find the gaps faster than you can patch them.

How to fix delivery problems without killing flexibility

The reason many consultancies resist standardisation is a legitimate fear that it will turn a responsive, senior-led firm into a process factory, and that fear is justified when standardisation is done in the wrong order, starting with heavy methodology documents nobody reads. The right sequence standardises the skeleton and leaves the craft alone.

First, standardise the connection points: one kickoff checklist, one status report, one risk escalation rule, one closedown review. These are the moments where projects touch the rest of the firm, and making them uniform costs your consultants almost nothing in autonomy while giving leadership visibility across every engagement. Second, standardise the commercial artefacts, meaning estimation, scoping and change control, because these are where inconsistency costs real money. Third, and only third, codify how your best people actually run the middle of a project, not as a mandate but as a default that a delivery lead can depart from provided they can say why. The goal is a firm where flexibility is a decision rather than an accident.

A standard is not a cage; it is the thing you are allowed to deviate from on purpose.

Alongside the artefacts, install one governance mechanism: a weekly delivery review, thirty to forty-five minutes, every project on one page, exceptions discussed and everything else left alone. This single meeting does more for delivery quality than any methodology document, because it makes trouble visible while it is still cheap. It also matters that the founder chairs it at first and then, deliberately, stops chairing it, since a review that only functions when you are in the room has merely relocated the hero problem. How this fits into the wider operating model as you grow is covered in how to scale a technology services business without breaking delivery.

Your first three fixes, in order

You cannot do all of this at once, and attempting a forty-point transformation plan is how these efforts die, so the honest answer is three fixes that, if they hold, materially improve delivery within a quarter.

• Fix one: the weekly delivery review. Start it next week with whatever reporting you have, however rough, because the cadence creates the demand for better information rather than the other way round.
• Fix two: one status format and one escalation rule. Every project reports the same way, and every delivery lead knows the specific conditions under which they must raise a hand rather than absorb the problem.
• Fix three: change control on your two largest engagements. Big contracts are where over-servicing and scope drift do the most damage, so pricing and agreeing changes there first protects the accounts you can least afford to lose.

Where Vitori fits

Everything above is work you can do yourself, and some leadership teams will, particularly those with an operations lead who has run delivery at scale before. The difficulty is rarely knowing what to do; it is holding the changes in place while the day job keeps pulling everyone back to firefighting, which is why so many standardisation efforts produce a template library and no change in behaviour.

Vitori works with founder-led technology services firms at exactly this point, using our Operational Scale Framework to assess where delivery actually stands across Growth, Delivery and Operations, and then either advising your leadership through the fixes or, through our Operator model, embedding as fractional leadership to run the delivery review, install the governance and stay accountable until the changes hold rather than until the report is submitted. Traditional consultants have their place in this work, but diagnosis without implementation is a different purchase, and delivery problems are solved in the doing.

Whether you do this with Vitori or on your own, the destination is the same: a firm where project quality no longer depends on which hero is available, and a business that runs, and scales, without the founder in every decision.