Pre-Kickoff Readiness Gap Detector

If the team cannot open the systems the statement of work assumes, Monday's kickoff is a performance. You can walk through scope, introduce the team, and agree a weekly cadence. None of that is delivery. Delivery starts when someone can log in, query the data, and reach the named client people who own the answers.

The quality problem is a first week billed against a wall: warehouse tickets still in IT, a sandbox that does not exist, a data steward who has not been told they are on the project, and a security packet sitting with legal. The meeting still happened, so the plan still shows day one as complete.

A pre-kickoff readiness pass exists to make those blockers visible while they can still be cleared: what the SOW requires, who owns the unblock, and whether it actually works.

Assembling a kickoff deck does not substitute for this. A polished deck with dead credentials is still theater.

The checklist has to come from this engagement's dependencies. A firm-wide kickoff template will ask about a war room and a welcome pack. It will miss the VPN group, the warehouse role, the staging schema, and the data-processing addendum this SOW actually named.

Use a general LLM as an extractor, not as a verifier. Paste the signed SOW and any annexes on access, environments, client responsibilities, and information security. Ask for prerequisites the client or your firm must complete before work can start. Do not ask whether access is ready. The model cannot ping IT, open a VPN, or see a ticket queue.

Force the extract into four buckets. If a SOW line does not fit, keep it. Do not drop it because the template is full.

• Access. Systems, datasets, folders, and credentials week one needs: VPN or zero-trust groups, warehouse roles, source extracts, collaboration tenants, repos. Name the system the way the SOW names it. "Data access granted" is not a line.
• Environments. Sandboxes, staging, non-prod copies, integration endpoints, and whether they must match production schema. "Environment to be provided" is a gap until it has an owner, a date, and a login.
• Named client FTE. Sponsor, day-to-day counterpart, data steward, process owner, security reviewer. Extract the role, the name if one exists, and the implied time. A title with no name is not staffed. A name with no confirmed hours is not staffed.
• Legal and security paperwork. Data-processing terms, security questionnaires, background checks, device standards, subcontractor NDAs, access-request forms. Paperwork in progress still blocks credentials.

Put the list in the project tool you already run the engagement from: Asana, Jira, or Smartsheet. One shared board, visible to the client sponsor. A spreadsheet on a consultant laptop is not a readiness process.

If the model returns almost nothing, that is a finding about the SOW. Dependencies that were never written down belong in an assumption gap detector, not as invented rows on a kickoff checklist.

The failure mode you will hit is a green checklist and a red first week.

Someone marks warehouse access, the named steward, and the sandbox done because IT was notified, a name is on the RACI, and a project code exists. The model, if you let it, will treat those sentences as evidence. They are not.

Access granted on paper and access working are different states. The only proof that counts is a named consultant completing the path the workstream will use: connect, authenticate, reach the object, run a harmless query or open the folder. Until that happens, the line stays open, even if the ticket is closed.

The model cannot do that proof. It cannot ping IT, sit in the client's access-request portal, or know that group membership takes days after legal signs. Prompt it to verify readiness and it will narrate confidence from the SOW and the last status email. Ignore that narration.

Treat these as still blocked even when the board is green: credentials on the wrong identity, access to a reporting layer when the work needs the warehouse, a sandbox on last year's schema, a named FTE who is real but out the week you start, and corporate paperwork that still needs business-unit approval before data can leave the tenant.

Each open line needs an owner on the client side, an owner on yours, the next action, and a date that is before day one. A gap with no owner is not being worked.

This is an illustrative scenario, not a case study.

A ten-week commercial-analytics engagement. The SOW says the client will provide warehouse access, a non-production sandbox that mirrors production schema, a named data steward, and completion of the firm's security pack before fieldwork. Kickoff is the first Monday after signature.

You paste the SOW into a general LLM and ask for prerequisites in the four buckets, each with the clause, the implied owner, and what done would mean. You do not ask it to score readiness.

The extract is usable because it is specific: VPN group plus warehouse analyst role on the commercial mart; sandbox with production-like schema, not a blank project; a named steward for extract questions in week one; security questionnaire, data-processing terms, and laptop standard, because credentials wait on those.

You load those as tickets in Jira, or the Asana or Smartsheet equivalent, and share the board with the sponsor. Status is not a traffic light the sponsor picks. Status is: not requested, requested, granted, or proven by a named consultant.

Two weeks out, the board looks healthy. IT closed the warehouse ticket. The steward's name is on the RACI. Legal said the processing terms are with the other side. The sandbox project exists.

The week before kickoff, an analyst tries the path. VPN works. The warehouse role does not include the commercial mart. The sandbox has last year's schema. The steward is on leave the first five days. The processing terms are signed; the questionnaire is not, so additional extracts are frozen.

None of that is surprising if you treat granted and proven as different columns. All of it is invisible if you let a green board, or a model summarizing email threads, stand in for a login.

You do not need a tool that claims to verify VPN access. You need a person to click through once, and a board that will not let "IT notified" count as done.

Run the extract as soon as the SOW is stable. Re-run it if the SOW or annexes change. The value is a list that stays honest until the first working day.

Share it with the client sponsor on a fixed cadence before kickoff, in the same tool as the rest of the project. A readiness memo the client never sees changes nothing. Escalation is the point: the sponsor is the only person who can move IT, legal, and the named FTE.

Keep the list short enough to work. Collapse anything that is not on the critical path for week one. A long board is how everyone learns to mark things green.

Do not run project setup automation as if the engagement were live while access is still theater. Folders and channels can wait a day. A board full of tasks nobody can start is worse than a late setup.

Gaps that will still be open on day one belong on the risk register, with the same owner and the same proven test, not as a polite note in the kickoff appendix. If you cannot name a workaround (synthetic data, a delayed workstream, a client-side extract), you are staffed against a wall.

Role-specific onboarding briefs help people know the client. They do not open the warehouse. Do not treat a well-read team as a ready engagement.

Skip this on a small, collocated piece of work where the counterpart can walk you to the laptop. Use it when week one depends on systems, paperwork, and named people you do not control. Kickoff quality is whether the path works, not whether the slides were assembled.