Project Setup Automation Agent

The job is to stand up folders, chat channels, a task board, and named role slots from the signed SOW so day one has a place to put work. It does not design the engagement. Speed is the only outcome. Most of the cost is integration against the stack you already run.

The cheaper path is already familiar: duplicate last quarter's SharePoint, rename the top folder, open a channel whose topic still carries the previous shortname, and paste a board that still holds leftover epics. That path is why people file into the wrong client-share, why a contractor from another account still has a key, and why the board does not match what was sold.

Derive every container from the signed statement of work. Do not run this on a discovery draft, including one produced by a SOW drafter from discovery transcript. An unsigned document will provision workstreams that legal later cuts.

Do not run it on "we're selected." Run it after the client has confirmed: signed SOW, a named kickoff date, and a sponsor note that the date is real. Setup before the win is real leaves client-named channels and folders to delete if the deal dies, and it teaches the team that a workspace is permission to start.

Chat targets sit in the Slack and Microsoft Teams class. Boards sit in the Asana, Jira, and monday.com class. Files sit in the SharePoint and Google Drive class. Some PMOs also open an intake record in ServiceNow. Map the same three objects onto whatever you already operate.

Workstream titles in the signed SOW are the only names the folders, channels, and board sections get.

• One parent folder named for the legal entity and engagement, with a child folder per workstream, plus the admin and working folders your PMO already uses.
• One internal channel (or Teams team) whose topic lists those workstream names, not a nickname the SOW never used.
• Board sections, epics, or groups titled character for character as the workstreams.

A fixed house skeleton is how a three-workstream contract gets five columns nobody will update. Do not add a folder because the template had one.

Role names on the board come from this week's staffing plan. If names are still moving, take them from a skills-to-project matching engine and write them as assignees or a roster file. That list is not an access-control list.

Keep client-share off the same run as working. Do not create guest channels or external sharing links while you create internal folders. Guest access is a later, manual step, and only after a pre-kickoff readiness gap detector has shown the client wants a shared space and has named who may enter it.

A kickoff deck auto-assembler fills the room agenda. This agent does not touch the deck.

Automate structure first. Leave every permission grant manual until the mapping from role to group has been proven on a dry run that created no client-data access.

Over-provisioned access at setup is a real exposure. The usual failure is not a stranger on the internet. It is a broad practice group, a leftover "project team" security group, or a contractor still nested in last month's directory group, all dropped onto a folder that will hold client extracts. Slack guest invites and SharePoint links visible to anyone in the org do the same damage faster.

The agent may create empty channels, empty folder trees, empty board sections, and empty role slots. It may create a named security group with no members. It does not add users, guests, or everyone in the practice. The engagement manager copies names from the staffing plan and grants, one group at a time, after checking that each person is on this engagement and that client-data folders stay on the smallest group that needs them.

Prove the mapping on an internal-only replay: take a closed SOW, run create with grants disabled, and inspect who would have been added. If the dry run would have invited a person from another account into client-share, leave grants off.

This is a worked example with made-up firms, written to show the cuts, not a case study with results.

Kestrel & Pike kicks off a 16-week operations engagement with Harborline Ports Authority on Wednesday. The signed SOW names three workstreams: berth-utilization baseline, gate-process redesign, and a 60-day staffing plan. Priya Shah is engagement manager. Jordan Hale, Sam Okonkwo, and Mei Lin are staffed this week.

Tuesday night Priya does not duplicate last month's West Quay workspace. She feeds the signed SOW and this week's roster. The agent proposes SharePoint children named for those three workstreams plus _admin and _working, a Slack channel #hp-berth-internal with the workstream names in the topic, and a Jira project with three epics titled as the SOW.

It also does three things that would have shipped if she had clicked through.

The mapping still resolves "project team" to a directory group that includes a contractor from the West Quay job. That group would have been granted to _working and to a _client-share folder the template always creates. That is over-provisioned client-data access. She drops _client-share from this run (the sponsor has not named an external recipient) and grants nobody. In the morning she adds Jordan, Sam, and Mei by hand to _working.

Jira rejects the project key because an old sandbox already owns it. Slack and SharePoint would have been created anyway. That is a half-built project. She does not announce a workspace. She files the Jira failure, picks a free key, and re-runs until all three targets exist or none of them do.

She almost ran this the previous Tuesday, when Harborline procurement said "you're selected" and the SOW was still in redlines. That would have been setup before the win was real: a Harborline-named Slack channel and a folder tree while legal was still cutting the staffing-plan workstream. The sponsor confirmed Wednesday by email after signature. That email is the gate, not the verbal win.

Do not paste a stakeholder onboarding brief synthesizer into the new channel. Briefs stay with the people they are for.

Partial success is the default failure. Chat succeeds, the board key collides, files never start. If people are already invited, they file into the one surface that exists and ignore the rest. Treat any incomplete run as a ticket queue: which object was requested, which target accepted it, which error blocked the rest. Roll back or finish before anyone is told the space is ready.

Do not invite the team, the client, or a practice-wide announcement until the queue is empty. Empty rooms with no members are cheap to delete. Occupied half-built spaces are not.

If the MSA, the SOW, or the kickoff date is still open, the run does not start. Confirmation is a signed document plus a named date from the client, not a sales thread. If data-processing terms are still open, skip any folder that will hold client extracts until the pre-kickoff readiness check is clear on that point.

Re-running on the same signed SOW should leave correctly named objects alone and only create what is missing. It must not spawn a second #hp-berth-internal-1.

Week-one renames and deletions are the mapping you keep. A fourth board section nobody touched is not a workstream. If they rename the channel to the client's spoken shortname, use that, and keep the legal entity on the parent folder.

Change the mapping to match that behavior. The engagement manager still owns grants. Speed is wasted if week one is spent deleting extra rooms, or if client data sat in a group that was too wide.

Keep using the agent when Tuesday night produces empty rooms that match the SOW, grants stay in a person's hands, and incomplete runs stay in a queue. Drop auto-grants if a dry run would have added the wrong person. Drop the whole run if the client has not confirmed. This is plumbing. Trust is the permission list.