How do I show a new manager the history of a project they inherited?
Give them the record set in reading order: the project's job index, the accepted handovers that show what was delivered and recorded off, the open items with their current states, and the access list showing which systems and agents the project touches. A history that lives in records survives the handover meeting; a history told in the meeting does not.
New managers inherit two projects: the work, and the story of the work. The story usually arrives as a predecessor's summary, generous to its author and silent on the three things the newcomer most needs: what was promised to the client, which decisions were already made and by whom, and what is quietly open, late, or disputed. Weeks of archaeology follow, in inboxes that may no longer be accessible.
The record set answers in the predecessor's absence because it was never the predecessor's narrative. The index gives the year's shape at a glance. The accepted handovers show the promises as the client recorded them, which is the version that binds. The open-items view shows the live edge: handovers awaiting decisions, jobs held, the states as they actually stand today rather than as they stood at the last status meeting.
Add the access list and the newcomer's first week changes character: instead of discovering the project's systems by accident, they see which agents and connections touch it, under whose ownership, and can reassign ownership deliberately, the same transfer discipline the leaver checklist in this set prescribes, run in the receiving direction.
Template: the inherited-project history pack
1. Job index for the project, by period, with states. 2. Accepted handovers, in order, with the client's decisions on them. 3. Open items: pending handovers, held jobs, open questions, each with its age and last owner. 4. Access list: systems, agents, connections, current owners. 5. Decisions log: scope changes and key calls, dated, with who decided. 6. One-page brief: the human layer, what the records cannot say (relationships, sensitivities), labelled as briefing, not record. Reading order is the order above; the brief comes last so the records speak first.
Worked example
The open-items section is built from objects like https://zambo.dev/handover/bd7e5325-33fd-4c5e-b029-76b781fa2f51 : five steps, acceptance pending, its state visible to the newcomer without asking anyone. An incoming manager who can see every open item in that shape on day one starts managing on day two.
Frequently asked questions
The predecessor is still available for questions. Is the pack still needed?
Yes, and their availability is when to build it: walk the pack with them, let them correct and annotate, and the project gains a history that outlives their availability. A pack built from a helpful predecessor is the best kind; it just cannot depend on one.
What if the project's history is mostly unrecorded?
Build the pack from what exists (invoices, deliveries, client copies of handovers) and mark the gaps as gaps, with dates. A new manager who knows exactly which period is undocumented can manage the risk; one handed a smooth story over a hole cannot.
Should the client see the history pack?
The client already holds their side of it: the handovers and their own decisions. The pack is the internal assembly, including open items and the brief, and stays internal, while any single record in it can be shared with the client on request, because it was always theirs to open.
By Brennan Zambo, founder of Zambo.
Last verified: 2026-10-17.
Try a handover
A handover gives your client one proof link with verifiable receipts to review, then Accept or Flag.
try it: say 'use zambo to hand this over to <client>' in your ai