What a firm should record about an engagement, and what it never does

Every firm records its engagements. Open the practice management system and you will find client name, matter code, partner, dates, fees billed, and a folder of deliverables.

Now try to use that record for something. Pick an engagement from four years ago and try to answer the questions that come up in real situations: is this relevant to a bid we are writing, who should be on the team, what should we warn them about.

You will find that almost nothing you need is there.

What the existing record holds, and why

The finance system records what it was built to record: revenue, by client, by period, attributed to a partner. That is exactly right for the purpose and it is a purpose that has nothing to do with the firm's memory. The document store records what was produced, filed by whoever produced it, under a taxonomy that assumes you already know where to look.

Neither was designed to answer a question asked three years later by someone who was not there. Nobody made a mistake. The records simply have a different job.

A matter code tells you an engagement happened. It tells you nothing that would help you do the next one.

The twelve things that turn out to matter

Working backwards from the questions firms actually ask, this is the list. It is short, it is unglamorous, and most of it is never written down anywhere.

About the work

1. What was actually delivered, described in the language a colleague would search in, not in the language of the engagement letter. "Regulatory price control submission" rather than "Project Meridian, phase two".
2. What capability it demonstrates. The general thing this specific piece of work proves the firm can do. This is the field that makes an engagement reusable rather than merely historical.
3. What changed during delivery. Scope moves, methodology changes, the thing that turned out not to be possible. This is the single most useful item on the list for anyone scoping similar work and it is essentially never recorded.
4. What the firm learned. Not a lessons-learned template. One or two specific things that would change how the next one is run.

About the people, internal

5. Who led it, distinct from who is credited in the finance system, which is often the relationship partner rather than the person who did the work.
6. Who else did substantive work, and what part. The manager who built the model, the associate who handled the data protection question and turned out to be good at it.
7. Who to ask now. The subset of the above who are still at the firm and would actually remember.

About the people, client side

8. Which client-side individuals were involved, and in what role. Sponsor, budget holder, technical reviewer, sceptic.
9. How the relationship went. Where it was easy, where it was difficult, what recovered it.
10. What they cared about, in their own words where possible.

About the commercial shape

11. How it was won, and against whom. Competitive tender, extension, direct award.
12. What it opened or closed. Follow-on work that resulted, or a door that shut.

Where each item actually lives, right now

The interesting thing about the list is that almost all of it already exists in written form. It is just not anywhere a system is looking.

| Item | Where it exists today | |---|---| | What was delivered | The final report, in the document store | | What capability it proves | Nowhere, but inferable from the deliverable | | What changed during delivery | The email thread where the scope change was agreed | | What the firm learned | A partner's memory, and occasionally a debrief email | | Who led it | The proposal team page, and the thread traffic | | Who else did substantive work | The thread traffic, more reliably than any system | | Who to ask now | Inferable, if you know who is still here | | Client-side individuals and roles | The recipient lists, over the life of the engagement | | How the relationship went | The threads, particularly the difficult ones | | What they cared about | Their own emails, in their own words | | How it was won | The tender correspondence | | What it opened or closed | Later threads, if anyone connects them |

Nine of the twelve are in email. That is the argument for treating correspondence as the primary record rather than as overflow, and it is why a system that only reads the document store can reconstruct the engagement but not the knowledge.

The rule that makes any of this usable

One property matters more than the completeness of the list: every recorded item has to name the thing it came from.

An engagement record that says "the relationship was difficult during procurement and recovered" is an assertion. A reader three years later has no way to judge whether that is a considered view or somebody's impression, so they discount it, and a discounted record might as well be empty.

The same line with the thread behind it is different in kind. The reader can spend ten seconds establishing what happened, and then act on it. This is the credibility dimension, and it is what separates a record people use from a record people are told to use.

An engagement history without sources is a rumour with a date on it.

How to get it without asking anyone

The list above is what OrgAtlas assembles, and the design constraint was that no part of it may require a form.

Material arrives the way the account team already works: outgoing mail blind copied to the account address, threads forwarded when something concludes, documents dropped in the browser. From that, the atlas extracts the people on both sides, the engagement the material belongs to, and the capabilities it evidences, and links them to each other with the source attached to every link.

Two consequences worth being explicit about.

The record is only as complete as what is sent. Material nobody forwards is material the atlas does not have, and we would rather state that plainly than imply a completeness the design does not provide. In practice the account correspondence is where nine of the twelve items live, so blind copying outbound mail covers most of the list as a side effect of sending it.

And what cannot be evidenced is not asserted. Where the firm has no proven capability in something, the atlas draws the gap rather than filling it. An engagement history that is honest about its holes is one you can rely on about the rest, which is the only property on this page that actually determines whether anyone uses it.

Next: how to tell a proven capability from a claimed one, and why the difference is drawn on the atlas