Rolling off a client

The point of our work is a client who no longer needs us for it. Rolling off is how we get there on purpose. It is not the last day and a folder of documents; it is planned from the start and done a little at a time, so that leaving is an event nobody has to brace for.

Plan the exit from the start

We design an engagement to be handed over. Ownership moves across during delivery, not in a rush at the end, which is the same idea the delivery process is built around. If the only plan for the ending is “write it all up later”, the ending will go badly.

The transition model

Handing something over has three gears, and healthy engagements shift down through them:

• We do it, you watch. Early on, we run the work while the client’s team sees how.
• We do it together. We work alongside them, sharing the doing rather than describing it.
• You do it, we are on hand. They run it, and we are there if something gets stuck.

By the time we leave, the client’s own people are already running what we built. The handover confirms that; it does not create it.

Getting out well

• Agree it internally first. Who is leaving, by when, and what they currently hold.
• Map what you hold. The roles, access, knowledge and relationships that need a new home, written down rather than carried in one person’s head.
• Design the end state. Who picks up each of those things, and what they need to do it well.
• Plan the conversations. Tell the client and the wider stakeholders in the right order and in good time, never by surprise.
• Hand over for real. Walk people through it, leave the notes and guides they will actually use, and check they can run it without you in the room.

Leaving cleanly

The handover is the visible half of leaving. The other half is making sure nothing of the client’s travels with you, and nothing of yours stays behind. The engagement lead owns this list; the rules come from the Access Control Policy, the Information Transfer Policy and the Disposal and Reuse of Equipment Policy.

• Access. Your access to client systems is revoked when you leave the engagement, and the engagement lead confirms the revocation to the client in writing. Access to our own client-related tools goes at the same time, along with any external sharing links created for the engagement. The engagement lead’s access record is what makes this complete rather than approximate.
• Data. Delete client data from your devices and from any location that no longer needs it. For cloud environments, delete under the client’s instruction, confirm the deletion in writing, and tell the client when the provider’s backups will expire so they know when the data is fully gone.
• Kit. Return any client-issued device or media and get written confirmation of receipt and erasure. Keep courier receipts until the client confirms.
• Credentials. Remove client credentials from 1Password and from the less obvious places they hide: cloud CLI profiles, SSH keys, git configuration and the keychain.
• Reuse. Nothing of the client’s is kept for reuse without their written permission, and physical records never leave a client site without it.
• Check. A day or two later, confirm your logins no longer work. If one still does, tell the engagement lead.

If the whole engagement is ending rather than just your part in it, the Standard Operations Policy and Procedure adds three things: deliverables are formally accepted against the agreed criteria and the acceptance recorded, documentation and runbooks are handed over so the client is not dependent on us to run what we built, and within four weeks Ben asks the client for feedback while the team holds a short retrospective with owned actions.

What good looks like

• The client can run and change the work without calling us.
• Nothing important lived only in the head of the person who left.
• The relationship is warm enough that they would ask us back.