Ask About the Handoff Before You Sign Anything

Picture a project that wrapped up a month ago. The engineers who built your system are working for other clients now. Something small has broken, or someone in operations wants a minor change. Would anyone on your side know where to start looking?

If nobody would, you don’t fully own what you paid for. That’s why I think the handoff needs attention at the start of a project, and why you should ask any firm about it, including us.

What should be in it

At a minimum, I’d expect:

• Instructions for setting up the code, running the tests, and deploying, written for someone who wasn’t on the project
• Tests that cover the important behavior, so your team learns they’ve broken something before your users do
• Short notes on the big decisions, such as why this database or that vendor, and what was ruled out
• A list of known issues and loose ends, since every system has some
• Every account in your organization’s name, including hosting, domains, code repositories, and third-party services
• A live walkthrough with the people who’ll own the system, recorded if your policies allow

The decision notes are the easiest item to leave out. Without them, someone eventually reverses a choice without knowing why it was made.

Why it belongs in the scope

Handoff work takes real hours. When it isn’t written down as a deliverable, it tends to get trimmed as the schedule tightens, which is what usually happens to unlisted work at the end of a project.

So write it into the scope. List the handoff items as deliverables, name who on your team will receive them, and leave some time after the walkthrough for the questions that come up once people are alone with the code.

A quick test

When you ask a firm how they hand work over, notice how specific the answer is. A vague answer here often predicts how the rest of the engagement will go. If you want to know what ours would look like for your project, ask us early.