Most customer implementations start with good intentions and a shared document. A kickoff deck lists the phases, someone pastes a checklist into a spreadsheet, and the team agrees to "keep it updated." Two weeks later the checklist is out of date, the customer's answers are buried in an email thread, and nobody can say with confidence who owns the next step.
The problem is not effort. It is structure. An implementation is a project: it has a goal, a deadline, owners on both sides, dependencies between steps and inputs that only the customer can provide. When it is run like a project, with owners, tasks and blockers in one place, the team spends less time chasing and more time delivering.
This guide explains how to run customer implementations as projects, from building a reusable template to tracking health and effort across every rollout at once. It draws on Quivly's Projects page, which describes an agentic workspace for customer delivery from kickoff to launch.
Why Implementations Need Project Structure
A checklist answers one question: what needs to be done? A project answers several more. Who owns each step? When is it due? What is it waiting on? Is it on track, and if not, why? Without those answers, three things tend to go wrong.
- Ownership blurs. Tasks assigned to "the team" or to nobody in particular sit untouched until someone notices.
- Customer inputs get lost. Files, credentials, screenshots and answers arrive through whatever channel the customer happened to use, and the person who needs them may never see them.
- Status becomes opinion. When the plan lives apart from the work, "how is it going?" gets answered from memory rather than evidence.
Project structure fixes these by making ownership, dates, inputs and status explicit and keeping them next to the work itself. If your team is still running rollouts from a flat list, our piece on why you should stop managing enterprise implementations like a task list covers the case in more depth.
Start Every Implementation From a Template
Most implementations for the same product follow the same shape. The customer kicks off, the team runs discovery, the product is configured and connected, data is migrated and validated, users are trained and the account goes live. Rebuilding that shape from scratch for each customer wastes time and invites gaps.
A good implementation template sets three things up front:
- Milestones. The major phases and the order they happen in, such as kickoff, discovery and go-live.
- Owners. The role responsible for each milestone. In Quivly's example onboarding template, kickoff sits with the account team, discovery with solutions and go-live with the CSM.
- Relative dates. Timing expressed as days from kickoff, so the plan adapts to whenever the project actually starts.
Underneath the milestones sit the tasks. A typical platform onboarding might include completing technical discovery and architecture sign-off, setting up SSO and access policies, configuring integrations, running an initial data migration and validation, conducting end-user training with a handoff checklist and establishing success metrics and a review cadence. Templates should be living documents. When a step keeps getting added by hand, add it to the template.
Quivly Projects lets teams build repeatable projects from templates that set the milestones, owners and dates, so every new customer starts from a proven plan rather than a blank page.
Give Every Step a Single Owner
Shared ownership is no ownership. Every milestone and every task should have exactly one named owner, even when several people contribute. The owner is not necessarily the person doing all the work; they are the person accountable for it moving.
A few practical rules help:
- Assign owners by name, not by team, once the project is created from the template.
- Name a customer-side owner for every step that depends on the customer, such as an IT admin for SSO or a data lead for migration.
- Give each project one overall owner who watches the whole plan and escalates when milestones slip.
- Record priority alongside ownership so owners know which projects to work first when everything feels urgent.
Quivly's project list shows each project's customer, owner, priority, progress and due date in one view, which makes it obvious when one person is carrying too many urgent rollouts at once.
Collect Customer Inputs on the Project, Not in Inboxes
Implementations stall more often on customer inputs than on vendor work. The vendor is waiting for identity provider metadata, an admin console screenshot, a sample data file or an answer to a security question. These requests are easy to send and easy to lose.
Treat each one as a formal information request that lives on the project:
- Be specific. Ask for exactly what you need, in the format you need it.
- Track status. Mark each request as waiting or received so everyone can see what is outstanding.
- Use the customer's channels. Send requests where the customer actually works rather than forcing them into a new tool.
- Link to the dependent task. Make it clear which step is blocked until the input arrives.
In Quivly Projects, forms collect the files, screenshots and answers the team is waiting on, and requests go out through Slack, email and a customer portal. Tasks, customer replies and approvals stay on the project, so the context does not scatter across inboxes. For more on keeping both sides aligned, see our guide to vendor and customer collaboration during implementation.
Turn Conversations Into Tasks, Risks and Blockers
A lot of implementation work happens in conversation. A customer mentions in a chat thread that SSO is waiting on their identity team. A call surfaces a new requirement. An engineer notes that a migration test failed. If nobody logs these moments on the project, the plan drifts away from reality.
The discipline is simple to describe and hard to keep: every blocker, risk or new piece of work mentioned in conversation should become a task, risk or blocker on the project, with the evidence attached. The challenge is that people forget, or assume someone else has logged it.
This is where agents help with project hygiene. Quivly's agents watch the conversation and turn it into a proposed task, risk or blocker with the evidence attached, and a person still decides whether to apply it. The human stays in control of the plan, while the busywork of transcribing updates goes away.
Track Status, Health and Effort Honestly
Percent complete is a useful number, but it is not the whole story. A project can be most of the way through its tasks and still be in trouble if the one remaining step is blocked. Good implementation tracking separates a few distinct dimensions:
- Status: not started, in progress, on hold or completed.
- Health: on track, at risk or off track, judged on whether the project will hit its date.
- Progress: the share of tasks done.
- Timing: days left or days overdue against the due date.
- Effort: hours logged against hours planned.
Planned versus actual effort deserves special attention. When a project consistently takes more hours than planned, it usually means the template underestimates a step, the scope grew or the customer needs more support than expected. Each of these is worth knowing before the next similar project starts.
Quivly Projects keeps health, blockers and planned versus actual effort in one place, and makes the same context available in AI assistants and Slack, so people and agents work from a single source of truth.
Manage the Whole Portfolio, Not Just One Project
Implementation leaders rarely run one project at a time. They need to know which rollouts are at risk this quarter, which are blocked and where the team's hours are going. A portfolio view answers those questions without a status meeting.
Review the portfolio on a regular cadence and look for patterns:
- Projects blocked on the same kind of customer input, which may call for a better request template.
- Owners with several at-risk projects, which may call for rebalancing.
- Milestones that slip across many projects, which may point to a step the template underestimates.
When a project wraps up, close it deliberately. Confirm go-live, complete the handoff checklist and pass the full history to customer success. Our onboarding milestones guide covers how to define the checkpoints that make that handoff clean.
FAQ
A checklist lists what needs to be done. A project adds owners, due dates, dependencies, customer inputs, status and health, so the team can see who is accountable for each step and whether the rollout will hit its date.
At minimum: milestones in order, an owner role for each milestone, dates relative to kickoff, the standard tasks under each milestone and the information requests the customer typically needs to answer.
Log each one as an information request on the project, track whether it is waiting or received, send it through the channels the customer already uses and link it to the task it blocks.
In Quivly Projects, agents propose tasks, risks and blockers from conversations with the evidence attached, but a person still applies them, so the plan stays accurate without losing human control. Ready to spend less time chasing and more time delivering? See how Quivly Projects brings your team, your customers and AI agents into one workspace from kickoff to launch.
