Asana Project Setup & Management
Learn the company standard for building one shared implementation project, keeping it customer-safe, running the work, and completing a clean handover.
Chapter 1 · Before building
Confirm the setup owner and access
- 1Confirm the Delivery Lead is the Implementation Setup Owner, or follow Appendix B for interim ownership.
- 2Verify Asana project-creation rights, Slack Connect administration, and authority to invite external users.
- 3Do not ask the broader implementation team to create the project when the named setup owner lacks access.
No customer invitation is sent before project QA is complete.
Instruction module
Eight chapters, in operating order
Work through each chapter and use the checkpoint to confirm you can perform the step without relying on memory.
- 01SOP §§2–3 and Appendix B
Chapter 1 · Before building
Confirm the setup owner and access
One Implementation Setup Owner is accountable for creating the project, completing QA, and issuing Asana and Slack invitations.
- 1Confirm the Delivery Lead is the Implementation Setup Owner, or follow Appendix B for interim ownership.
- 2Verify Asana project-creation rights, Slack Connect administration, and authority to invite external users.
- 3Do not ask the broader implementation team to create the project when the named setup owner lacks access.
No customer invitation is sent before project QA is complete.Checkpoint: You can name the accountable setup owner and confirm all three required permissions. - 02SOP §§4–14
Chapter 2 · One project
Create one shared implementation project
There is a single implementation project. Everyone works in it, including the customer. No second copy is created.
- 1In the correct company workspace, choose Create, Project, then Use a Template.
- 2Select the current approved Enterprise Implementation Project Template; never rebuild it from scratch when the template exists.
- 3Name the project “[Customer Name] — Implementation.”
- 4Confirm all seven template sections and the nine standard task fields loaded correctly.
Do not duplicate the project to create a separate customer view. One shared project only.Checkpoint: One correctly named project exists, built from the approved template, with all sections and fields intact. - 03SOP §§15–26
Chapter 3 · Customer-specific build
Align the template to the signed engagement
The approved template is the starting point; the contract, scope, handoff, and discovery records determine the final plan.
- 1Review the MSA, Order Form, SOW or addendum, approved scope, sales handoff, discovery, products, integrations, data, training, custom work, commitments, and target dates.
- 2Remove non-applicable template tasks during initial build and add missing customer-specific work.
- 3Adjust descriptions, dependencies, owners, dates, and milestones.
- 4Populate every required field, including Visibility, on every task before inviting anyone.
Checkpoint: Every active task is applicable, fully described, owned, dated, and ready to be seen by the customer. - 04SOP §§27–35 and §88
Chapter 4 · Opening the project up
Quality check, then invite the customer
The shared project is reviewed against the pre-invitation checklist, then the customer and Slack Connect channel are opened.
- 1Read every task as the customer will see it: clear titles, plain descriptions, real owners and dates.
- 2Remove or rewrite anything that is internal-only commentary rather than shared delivery work.
- 3Complete the full pre-invitation QA checklist with the Implementation Setup Owner.
- 4Issue the approved Asana invitations and set up the Slack Connect channel.
Never duplicate the project or maintain a parallel copy; there is one record of the work.Checkpoint: The project passes QA and the customer is invited to the one shared project. - 05SOP §§36–58
Chapter 5 · Daily task discipline
Work once, in the shared project
Everyone updates the same tasks in the same project, so there is one current answer at all times.
- 1Open and update tasks in the shared implementation project.
- 2Use one assignee, a meaningful due date, a clear description, and all required fields.
- 3Keep task-specific questions, decisions, blockers, files, and completion notes on the task.
- 4Use subtasks and dependencies deliberately, and keep them readable to the customer.
- 5Complete a task only after the deliverable, approval, and dependencies are confirmed.
Checkpoint: A task is updated once, has clear ownership, and reads correctly to everyone who can see it. - 06SOP §§59–65
Chapter 6 · Change during delivery
Classify every new task the same way
New work is created directly in the shared project and held to the same field standard as template work.
- 1Create the new task in the shared implementation project.
- 2Set title, description, assignee, due date, status, customer action, visibility, workstream, priority, meeting requirement, owner role, and dependencies.
- 3Write the task so the customer can read it without additional explanation.
- 4Never create a second copy of a task in another project or list.
Checkpoint: Every new task is fully classified and lives only in the shared project. - 07SOP §§66–80
Chapter 7 · Status, meetings, and Slack
Maintain the formal project record
Task status, project health, meetings, and communication each have a defined place in the operating model.
- 1Keep task status current and review overall project health at least weekly.
- 2Use On Track, At Risk, Blocked, or Complete for the project-level status, supported by a meaningful narrative update.
- 3Prepare in Asana before customer meetings and record decisions, actions, owners, dates, and dependencies immediately afterward.
- 4Use Slack for quick coordination, then transfer every decision, approval, requirement, risk, task, dependency, or timeline change into Asana.
Automation can support administration, but it cannot replace the Implementation Lead’s judgment.Checkpoint: Anyone opening Asana can understand current health, progress, decisions, owners, and next steps. - 08SOP §§81–94
Chapter 8 · Governance and completion
Protect shared content and finish cleanly
Customer-safe communication, launch controls, handover, and final QA close the operating loop.
- 1Treat every task, comment, attachment, and subtask in the project as externally visible.
- 2Never place credentials, private security information, internal commentary, commercial strategy, legal discussion, or internal escalation content in the project.
- 3Continue managing open issues, hypercare, deliverables, and transition after go-live.
- 4Complete Customer Success and Support handover, assign all remaining open items, confirm approvals, archive according to policy, and close the project.
- 5Use the setup, creation, launch, and daily checklists in the SOP as the final control.
Checkpoint: The implementation is closed only after delivery, approvals, training, launch, open-item ownership, and handover are confirmed.
