My Client Onboarding Checklist, Rewritten After Three Bad Starts

Three separate engagements, roughly a year apart, each hit a wall in the first two weeks for a version of the same reason: I didn't have access to something I needed, and getting it took a week of chasing an IT ticket or a procurement approval I hadn't known existed. Each time felt like a fluke until the third time, when it stopped feeling like a fluke.

The actual root cause wasn't technical, it was that kickoff calls focus on scope and timeline and almost never on access logistics — who grants GTM container permissions, whether there's a security review for third-party consultants, whether the client even has an active license for the tool we're supposedly going to be using.

What's on the checklist now

• Exact list of systems I'll need access to, sent before kickoff, with a named internal owner for each — not "IT" but a person.
• A question about security/vendor-review processes asked explicitly, since clients rarely volunteer this until it blocks something.
• Confirmation of active licenses for any tool the engagement assumes exists, rather than assuming the SOW's mention of a tool means it's actually provisioned.
• A named point of contact for decisions, distinct from the point of contact for day-to-day communication — these are often different people and conflating them causes delays.

The slowest part of most engagements isn't the hard technical problem. It's the week lost waiting for someone to grant an access request nobody flagged until it blocked everything.

This checklist now goes out before the kickoff call, not during it, so access requests are already in motion by the time we're discussing scope. The projects since have started meaningfully faster, and the slow-start pattern hasn't recurred — not because the clients changed, but because the thing causing the delay got surfaced early enough to not be a surprise.