Building a Delivery Playbook Your Firm Will Actually Use
Every firm has a method. The question is whether it lives in a document people use or in the heads of four people who are always busy.
Playbooks fail in a predictable way. Someone senior writes a thorough methodology, it is launched, and within a year it describes a version of the firm's work that no longer exists. The reason is not laziness. It is that the playbook was written as a document rather than as a working artefact, so using it and improving it are separate activities, and only the first ever happens.
A playbook that survives is one that is instantiated: starting a new engagement from it creates the actual plan, the actual deliverable list and the actual checks, so improving the playbook improves the next engagement automatically and using it costs less than not using it.
What belongs in one
- The phases, with an entry and exit condition for each. Not durations, which vary, but the conditions that say a phase is genuinely finished.
- The deliverables produced in each phase, with their acceptance criteria and the number of review rounds assumed.
- The quality checks, stated as things somebody performs at a named point, with who performs them.
- The standard risks and assumptions for this type of work, so a new engagement's registers start populated rather than blank.
- The information the client must provide, in the form of a request list that can be issued on day one.
- The effort shape: the proportion of effort by phase and by grade, which is what makes the next estimate defensible.
What must stay out
Anything that varies by client, by sector or by size does not belong in the playbook. Putting it there produces a document full of caveats, and a document full of caveats is one people stop reading because the caveats are doing the work.
Judgment also stays out. A playbook should say that an approach must be agreed with the client before the analysis begins; it should not attempt to specify which approach. The most useful playbooks are notably thin on advice and thick on structure, because structure is what a competent person needs and advice is what they already have.
Making improvement automatic
The mechanism that keeps a playbook alive is a closing question in every engagement debrief: what changes in the template. Not what did we learn, which produces observations, but what changes, which produces an edit.
Give the playbook an owner and a version, and record when each version was adopted. Then the second question becomes answerable: which engagements ran on which version, and did the change help. Without versioning, a playbook accumulates edits and nobody can tell whether it is getting better.
Adoption without mandate
Mandating playbook use produces compliance behaviour: the template is instantiated and then ignored, and the firm learns nothing except that its reporting looks good. Adoption comes from the playbook being the quickest route to a defensible plan.
That means it must start the engagement rather than describe it. If choosing the playbook populates the plan, the deliverable list, the initial risks and the information request list, nobody needs persuading. If the playbook is a document to read before writing all of that yourself, it will be read once by each new joiner and never again.
How many playbooks a firm needs
Fewer than most firms build. One per distinct type of work, where distinct means the phases genuinely differ, not where the sector differs. A firm with four service lines usually needs four playbooks and a small number of sector variations expressed as additions rather than as separate documents.
The signal that you have too many is that nobody can say which one applies to a given engagement without asking. At that point the taxonomy is serving the library rather than the work, and consolidating is almost always the right move.