30-60-90 day plan for implementation managers
On this page
- What does an implementation manager own that a project manager does not?
- What does the 30-60-90 day plan look like?
- Which data and contract terms does a new implementation manager check?
- Which numbers should a new implementation manager baseline?
- What does "on track" look like at day 30, 60 and 90?
- A filled example
- How should the hiring manager use this plan in the final interview?
- What should the head of services ask at the check-ins?
- What the head of services owes a new implementation manager
- Common mistakes
- Adapting the plan
- Questions people ask
A 30-60-90 day plan for a new implementation manager should spend the first 30 days auditing the live portfolio against each signed statement of work (go-live dates, phase, hours used against hours sold, risks) and mapping the handoff from sales; days 31-60 running the implementation rhythm (standard kickoffs, weekly status, change control, data migration rehearsals and user acceptance sign-off) while recovering the at-risk projects; and days 61-90 delivering go-lives, a handoff standard for customer success and one measured fix to time to go-live or scope creep. As of November 2026, any project that moves customer data also runs under the customer's contract terms, such as GDPR Article 28 processor terms for EU personal data and HIPAA business associate agreements for health data.
This plan is for the head of professional services, onboarding leader or services director hiring an implementation manager at a software or services company to lead customer implementations, often with a team of implementation consultants. After go-live, the customer belongs to the role in the 30-60-90 day plan for customer success managers; technical design sits with the 30-60-90 day plan for solutions architects; and a single internal project is covered in the 30-60-90 day plan for project managers.
What does an implementation manager own that a project manager does not?
| Area | Implementation manager | Project manager | Customer success manager |
|---|---|---|---|
| Starting point | A signed order and statement of work, handed over by sales | A project charter | A customer who has gone live |
| Main output | Customers live on time and in scope, data migrated, users trained | A project delivered to its plan | Adoption, renewal and expansion |
| Commercial side | Scope against the statement of work, change orders, services hours and margin | Budget and schedule | Renewal value |
| Customer data | Mapping, test loads, reconciliation, the data processing terms | Rarely | Usage data |
| Ends with | Hypercare and a documented handoff | Project close | Ongoing relationship |
The seat is several projects at once, each with a customer whose own staff have day jobs. Most slips come from the customer side (a late data export, a missing IT contact), so the plan measures how early the implementation manager sees them, not only whether they happen.
What does the 30-60-90 day plan look like?
30-60-90 day plan — [Name], Implementation Manager, [product / segment]
Reports to: [head of services] Start date: [date]
Portfolio: [N] live implementations Team: [N] implementation consultants
Packages: [standard / premium / custom] Typical duration: [N] weeks
Systems: [PSA or project tool], [CRM], [ticketing], [secure file transfer]
DAYS 1-30 — Audit the portfolio and the handoff
Goals:
- Build a portfolio board: customer, statement of work, contracted vs
forecast go-live, phase, hours used vs sold, risks, sentiment
- Read the statement of work and sales notes for the [5] largest
or riskiest projects; list where the build differs from scope
- Shadow a kickoff, weekly status calls, a data migration, a go-live
- Map the sales-to-implementation handoff: what is captured at
signature and what the team has to rediscover
- Learn configuration, integrations (SSO, APIs, import tools) and
environments
- Learn each customer's data terms: DPA or BAA, where migration
files live, who can access production data, deletion after load
Deliverables by day 30:
- Portfolio board with a status and a reason for every project
- Handoff gap list agreed with sales leadership
Check-in: day 30
DAYS 31-60 — Run the rhythm and recover the red projects
Goals:
- Own [N] projects directly, including the at-risk ones
- Standard kickoff: goals, success criteria, roles, milestone plan,
data and integration plan, acceptance and go-live criteria
- Weekly customer status with decisions needed; weekly internal
portfolio review
- Data migration: field mapping, test load, record-count
reconciliation, customer sign-off before the production load
- Change control: every out-of-scope request logged, sized, and
approved as a change order, deferred or declined
Deliverables by day 60:
- Recovery plan agreed with each at-risk customer
- Change log in use; a go-live with signed acceptance
Check-in: day 60
DAYS 61-90 — Make it repeatable
Goals:
- Go-live checklist and a hypercare period with exit criteria
- Handoff standard to customer success and support: configuration
record, integrations, open items, success criteria, contacts
- Fix one systemic cause from the handoff gap list and measure it
- Capacity plan: projects per consultant, hours by phase,
bookings forecast from sales
Deliverables by day 90:
- Handoff standard adopted by customer success
- One measured improvement; capacity plan approved
Check-in: day 90 — full reviewCounts and durations in brackets are examples; set them by package and segment.
Which data and contract terms does a new implementation manager check?
The statement of work and order form set scope, but the data terms decide how the team may handle what it migrates. The rules below are summarized as they read in November 2026; they are not legal advice, and the signed contract and the security team's policies govern each project.
| Area | What the rule says | What the implementation manager checks |
|---|---|---|
| EU personal data, vendor as processor (GDPR Article 28 and 33(2)) | The processor acts only on the controller's documented instructions, keeps staff bound to confidentiality, applies Article 32 security, uses other processors only with prior written authorization, deletes or returns the personal data at the end of the services, supports audits, and notifies the controller of a personal data breach without undue delay | Migration files stay in approved systems; any tool used to transform data is an approved sub-processor; test copies are deleted on schedule |
| Health data in the US (45 CFR 164.504(e)(2)) | A business associate contract limits uses and disclosures, requires safeguards, requires reporting of uses or disclosures the contract does not allow (including breaches), flows the terms down to subcontractors, and requires return or destruction of the information at termination where feasible | A signed business associate agreement before any protected health information is loaded, including into test environments |
| Breach timing for business associates (45 CFR 164.410(b)) | A business associate notifies the covered entity of a breach without unreasonable delay and no later than 60 calendar days after discovery | The escalation path to security on day one, so a misdirected file is reported in hours, not weeks |
| Security assurance (AICPA SOC suite) | SOC reports are assurance reports CPAs issue on a service organization's controls, used by customers to assess the risks of outsourcing; the AICPA published exposure drafts of proposed 2027 SOC 2 criteria in October 2026 | Security questionnaires and report requests go to the security team, not answered from memory by the project team |
The practical rule for the team: no real customer data in email, chat or tickets, and every migration file has an owner, a location and a deletion date.
Which numbers should a new implementation manager baseline?
The measures below are examples. Split each by package or segment, because a standard package and a custom enterprise project should not share a target.
| Measure (examples only) | What it shows |
|---|---|
| Days from signature to kickoff | Whether the handoff and staffing keep up with sales |
| Weeks from kickoff to go-live, against the package's planned duration | Delivery speed and where it slips |
| Go-lives on the contracted date | Whether commitments to customers hold |
| Services hours used against hours sold | Margin and estimating accuracy |
| Out-of-scope requests per project, and the share that became change orders | Scope control and handoff quality |
| Customer satisfaction at go-live; adoption 30 days after, with customer success | Whether "live" meant usable |
What does "on track" look like at day 30, 60 and 90?
| Checkpoint | On track | Worth a direct conversation |
|---|---|---|
| Day 30 | Every project on the board with a reason for its status; scope gaps listed; handoff gaps agreed with sales; data terms known per customer | Statuses copied from the project tool; statements of work unread; customer data handled before the terms were checked |
| Day 60 | Recovery plans agreed with customers; change log used; a go-live with signed acceptance | Out-of-scope work done for free to keep a customer happy; go-live dates moved without the customer's agreement |
| Day 90 | Handoff standard used by customer success; one measured improvement; capacity plan tied to bookings | Customers handed over with open items nobody owns; consultants far over planned hours with no plan |
A filled example
Implementation manager: Sofia Marin (invented), new implementation manager at a scheduling and patient-messaging software company for outpatient clinics, with 22 live implementations and four consultants. All details are examples.
Day 30: Six projects were red. In four, the clinic's export from its previous system had arrived weeks late, and the sales notes had not named the clinic's IT contact or its previous vendor. Migration files for two clinics sat in a shared folder with broad access.
Day 60: The files moved to the approved transfer location with deletion dates, and every clinic's business associate agreement was confirmed before new loads. Kickoff now required a named data owner and IT contact, and each migration had a test load with record counts the clinic signed. Of 14 out-of-scope requests, five became change orders and the rest went to a post-go-live list.
Day 90: A two-week hypercare with exit criteria and a handoff template were in use with customer success. Projects that started under the new kickoff reached go-live faster than the earlier ones, and her capacity plan showed the team over planned hours, which supported a new consultant hire.
How should the hiring manager use this plan in the final interview?
Give every finalist the same brief: the packages, a de-identified portfolio snapshot and one project in trouble. Score the plans with the rubric in how to evaluate a 30-60-90 day plan in an interview; the implementation specialist screening questions cover the consultants the new manager will lead or hire. Questions that test this plan:
- "Go-live is in three weeks and the customer's data export has not arrived. What do you do today?"
- "Sales promised an integration that is not in the statement of work. How does your first conversation with the customer go?"
- "How do you decide a project is ready to go live?"
- "What do you hand to customer success, and when?"
Strong candidates separate what the contract says from what the customer wants, name the customer roles they need at kickoff, and ask about data terms before talking about migration tools.
What should the head of services ask at the check-ins?
- Day 30: Which projects are red, and is the cause on our side or the customer's? Which handoff gaps cause the most rework?
- Day 60: What did each recovery plan change? How many requests became change orders?
- Day 90: Does customer success accept the handoff without chasing? What changed in time to go-live, and how sure are we?
What the head of services owes a new implementation manager
- Every statement of work, order form and data processing or business associate agreement for the live portfolio.
- Authority to raise change orders, and a commercial contact who will price them quickly.
- Services hours and margin data by project, not only at quarter end.
- A named security contact and agreement from sales leadership to fix the handoff gaps.
Common mistakes
| Mistake | Result | Fix |
|---|---|---|
| Doing out-of-scope work to keep the peace | Hours overrun and the next customer expects the same | Log, size and decide every request against the statement of work |
| Production loads without a test load | Bad data in the live system on day one | Test load, record counts and customer sign-off first |
| Go-live declared without acceptance criteria | "Live" customers who cannot use the product | Agree acceptance and go-live criteria at kickoff |
| Handoff by meeting only | Customer success relearns everything | A written handoff record with open items and owners |
Adapting the plan
- High-volume onboarding: fewer custom projects and more templates; measure time to first value and the share of customers who finish self-serve steps, and automate the kickoff.
- Enterprise and regulated customers: add security reviews, change advisory boards and the customer's own testing cycles to the milestone plan, and expect the data terms to drive the schedule.
- Partner-led implementations: the manager oversees a systems integrator; add partner scorecards and escalation paths, and read the partner agreement in month one.
- Managing several programs of implementations: the benefits and dependency tools in the 30-60-90 day plan for program managers help when one customer rolls out across many sites.
Questions people ask
What should a new implementation manager do in the first 30 days?
List every live implementation with its statement of work, contracted and forecast go-live dates, phase, services hours used against hours sold, risks and customer sentiment; read the statement of work for the largest and riskiest projects and compare it with what is being built; shadow kickoffs, status calls, a data migration and a go-live; map the sales-to-implementation handoff; and learn each customer's data processing terms before touching customer data.
How should implementation managers handle scope creep?
Log every request that falls outside the signed statement of work, size it, and decide with the customer whether it becomes a paid change order, moves to a post-go-live backlog or is declined, before the team starts the work. A change log from the first month shows which requests come from gaps in the sales handoff, which is usually where the fix belongs.
What data rules apply when an implementation team migrates customer data?
It depends on the data and the contract. As of November 2026, when a vendor processes EU personal data for a customer, Article 28 of the GDPR requires processing only on the customer's documented instructions, approved sub-processors, and deletion or return of the data at the end of the services. When a US vendor handles protected health information for a health care customer, 45 CFR 164.504(e) requires a business associate agreement first. This is not legal advice; follow the signed terms and the security team.
How is an implementation manager different from a customer success manager?
The implementation manager gets a newly signed customer from kickoff to go-live: scope against the statement of work, configuration, integrations, data migration, user acceptance testing and training. The customer success manager takes over after go-live and owns adoption, value, renewal and expansion. The handoff between them is a deliverable in its own right.