Two people can hold the same job and produce different work
A firm hires two people of similar seniority and gives them similar assignments. One takes three weeks to shape a proposal; the other takes five. One runs a project review the client praises; the other generates a variation request. Neither difference shows in the firm's reporting, which counts proposals submitted and billable hours.
This is the defining problem of professional services, and its shape differs from the other industries in this collection. The output of the business is judgement, and the people are the asset.
Where the method actually lives
A method is not a document. It is the set of decisions a practitioner makes, the order they are made in, and the reasons behind them.
- The public layer: proposals, deliverables and case studies written for clients. Often silent on how a decision was reached.
- The working layer: templates, checklists, standard data models and partner review notes. Maintained unevenly, with overlapping versions.
- The tacit layer: what an experienced practitioner knows about a client's real constraint. Unrecorded, and lost when people leave.
Efforts to systematise delivery usually attack the first layer, which is already in reasonable shape, and leave the third, where the variance lives. The useful work is to move judgement from the tacit layer into the working layer.
That work is an editorial and governance problem before it is a technical one. A captured method decays quickly: the people who know why a step exists are busy, and the document is updated by whoever complains first. What distinguishes a method that survives is ownership, a recorded reason for each step, and routine use rather than exception.
Proposal preparation is a knowledge retrieval problem
Proposal preparation is the clearest example of a knowledge-intensive process treated as a writing problem. The senior judgement is not in the prose; it is in deciding what the client is buying, which constraints are real and what will go wrong. A new consultant preparing a bid reconstructs that judgement from documents and advice.
Here retrieval genuinely helps: the relevant knowledge already exists, is written down somewhere, and is not connected to the moment of use. A system that surfaces the right prior engagement, the relevant regulatory constraint and the partner's recorded view of a comparable situation saves work that would otherwise take two days.
What it must not do is draft the client's position. The most damaging outcome is a plausible narrative nobody believes will survive the client's first challenge, because it was assembled without the person who can answer it. A retrieval system showing the material and its provenance, and leaving the argument to the person, is safe. A system that writes the argument for the consultant to edit is not.
Staffing decisions are made on judgement the firm cannot see
Resourcing is where professional services economics are set. The billable rate depends on the mix of people assigned, and the gap between a well and badly staffed engagement is often several times the margin of a mediocre one. Yet staffing is decided in a conversation, from a partner's memory of who is good at what.
The available data is not small. It includes the skills people hold, the history of who worked on what, and the outcome of past engagements. A support layer over this makes the constraint visible: a named expert needed on a Tuesday, a conflict with an existing commitment, an engagement that needs someone who has left.
The decision itself should stay with the partner. Utilisation figures and experience histories are inputs to a staffing conversation, not a substitute for it. The distinction is the one in building reusable enterprise AI capabilities: the reusable asset is the context and the method, not the decision.
Quality assurance that happens too late to be cheap
Quality control is usually a review at the end, by someone more senior, who comments on a document that is already largely written. The review is valuable and expensive, because the rework it prevents has already been paid for. The alternative is review moved to where the decision is cheap to change: the framing of a proposal, the structure of an engagement, the method chosen.
| Checkpoint | Cost of getting it wrong | Where review belongs |
|---|---|---|
| Engagement framing | Rework across the whole engagement | Before the team is named |
| Method and work plan | Rework in delivery, and a schedule that cannot be met | Before the first work package starts |
| Deliverable content | Rework by the reviewer and the author | At the point of drafting |
| Client-facing outcome | Reputational cost, which internal rework does not recover | Partner review, and it cannot be delegated |
What to start with on Monday
- Choose one recurring deliverable with a reliable external reference point, and measure the variance between the best and worst examples.
- Interview the three people who produced the strongest and weakest examples, and write down the decisions a less experienced practitioner would not have made.
- Record those decisions as method, with the reason attached, and test whether a capable colleague can follow it on an unfamiliar assignment.
- Name the owner of that method, and the review point at which it is checked against outcomes.
The measures are ones the firm partly measures and rarely reads together: the spread in review effort between engagements of the same type, the reuse rate of captured methods, and the proposal effort of the most and least experienced people.
The argument of this article is deliberately narrow. A professional services firm does not become repeatable by templating its output, but by making its judgement inspectable and putting that judgement where a developing practitioner can reach it. The application engineering required is in business application engineering, and the discovery method is in how to map a business process before building an AI agent.