Post-Sale Management

A customer success team analyzed their onboarding data and found that projects with detailed implementation plans completed 23 days faster on average than those that started with "let's figure it out as we go."

More telling: projects without upfront plans had a 47% chance of missing their original timeline by 30+ days. Projects with comprehensive plans? Only 12% missed by that much.

Here's what separates successful onboarding from the chaotic mess most teams experience: treating implementation like a real project with defined phases, dependencies, resources, and accountability—not a casual "we'll help you get set up" conversation.

If you're building onboarding operations that consistently deliver value on time, you need implementation planning discipline. Not corporate bureaucracy, but real project management that keeps everyone aligned and moving forward.

What Implementation Planning Actually Means

Implementation planning is the process of defining how you'll take a customer from signed contract to productive use of your product, including all tasks, dependencies, timelines, resources, and success criteria required to get there.

This isn't a one-page checklist. It's a detailed roadmap that breaks down the implementation into manageable phases, identifies who does what and when, maps dependencies and critical path, sets realistic timelines with buffer, defines success criteria for each phase, and anticipates risks with mitigation plans.

Why this matters: Implementation without a plan becomes reactive firefighting. With a plan, you proactively manage the project and intervene before small issues become big delays.

The Planning Spectrum

On one end, you have insufficient planning—"Here's a link to get started, let us know if you have questions." Generic checklist with no dates or owners. CSM keeps track in their head or scattered notes. Customer has no visibility into next steps.

On the other end, you have over-planning: 40-page project plans that take a week to create, daily status meetings with formal change request processes, more time spent managing the plan than executing it. Customer overwhelmed by process.

Right-sized planning sits in the middle. Clear phases with milestones and dates. Documented tasks with ownership (vendor and customer). Dependencies identified and tracked. Simple status tracking and communication. Customer knows exactly what's happening and what's next.

Your planning approach should match complexity. A 3-person SMB implementing a simple tool needs a different plan than a 5,000-person enterprise rolling out across multiple business units.

The Implementation Planning Process

Creating an effective implementation plan follows six steps. Let's walk through each one.

Step 1: Discovery and Requirements Gathering

Before you can plan the implementation, you need to understand what you're implementing.

Start with the basics: What exactly will they use the product for? What processes, tools, and data exist today? Then dig into technical requirements—integrations, security, compliance, infrastructure. Data migration needs: what data, how much, from where, and how clean is it?

You also need to map the people side. Who needs to be involved, trained, or consulted? How will you know implementation succeeded? What constraints are you working within—budget, timeline, resource availability, dependencies?

Most of this should come from the sales-to-CS handoff documentation. If it doesn't, you'll need technical discovery calls with IT, security, and data teams. Workflow mapping sessions with end users help. Review contracts and SOWs for commitments. Send a pre-implementation questionnaire for the customer to complete.

Red Flag: If you're missing critical information (like "Do they need SSO?" or "How many records need migrating?"), stop. Get the answers before creating the plan. Bad inputs create bad plans.

Step 2: Scope Definition and Boundaries

Define exactly what's in scope for this implementation and what's not.

For in-scope items, be specific. Not "implement the product" but "Automate invoice approval workflow for Finance team." List features and capabilities being implemented, integrations being configured, training being delivered, data being migrated, customization being built.

Then define what's out of scope: additional use cases (phase 2), advanced features not needed initially, integrations that can wait, custom development beyond standard configuration, training for roles not involved in phase 1.

Why This Matters:

Scope creep is the number one cause of timeline slippage. Customers will discover new needs during implementation. That's expected. But without clear boundaries, every new idea becomes "let's just add this" and suddenly your 60-day project is on month four.

Document the scope in a written statement in your project plan. Get customer sign-off on scope. Establish a change request process for additions. Keep a "Phase 2" parking lot for good ideas that wait.

Step 3: Creating the Project Timeline

Build the timeline working backward from the target go-live date, accounting for dependencies and realistic task durations.

Your timeline needs phases (major stages of work like setup, migration, training, go-live), milestones (key checkpoints that mark phase completion), tasks (specific activities within each phase), dependencies (what must finish before something else can start), duration estimates (how long each task will take), and buffer (padding for unknowns and delays).

Here's what a 60-day mid-market implementation might look like:

Week 1-2: Setup and Configuration

Kickoff meeting on Day 1. Account provisioning and access setup wrap up by Day 3. Core configuration and settings run from Day 4-10. Branding and customization happen Day 8-12. Milestone: System configured and ready for integration.

Week 3-4: Integration and Data Migration

Integration setup and testing run Day 15-25. Data export from legacy systems happens Day 15-20. Data cleaning and transformation take Day 21-25. Data import and validation finish Day 26-28. Milestone: Data migrated and integrations live.

Week 5-6: Testing and Training

User acceptance testing runs Day 29-35. Training sessions for admins happen Day 32-34. Training sessions for end users go Day 35-40. Documentation creation spans Day 35-42. Milestone: Team trained and testing complete.

Week 7-8: Go-Live and Support

Final validation and checks on Day 43-45. Go-live execution on Day 46. Intensive support period Day 46-52. Success validation and celebration Day 53-56. Onboarding completion review Day 57-60. Milestone: Successfully live and achieving value.

Critical Path: The sequence of dependent tasks that determine minimum project duration. In this example: Configuration → Integration → Data Migration → Testing → Go-Live. Any delay on critical path items delays the entire project.

Step 4: Resource Capacity Verification

Verify that both vendor and customer have the capacity to execute the plan.

On the vendor side, you need CSM availability for meetings and support, implementation specialist time (if that's a dedicated role), technical resources for integrations or custom work, training delivery capacity, and support team awareness and readiness.

On the customer side, look for a project champion with real availability, IT/technical team time for integrations and security reviews, subject matter experts for workflow design, end users for testing and training, and an executive sponsor for escalations and approvals.

Ask the hard questions: Does the customer have someone who can dedicate 5-10 hours/week to this? Are customer resources available when you need them (or are they on PTO, traveling, etc.)? Do you have enough CSM capacity to support this customer plus others? Are technical resources available for the integration weeks?

If capacity is insufficient, you have four options. Extend the timeline to match available capacity. Reduce scope to fit available resources. Add resources (hire a contractor, shift workload). Or escalate to leadership for a prioritization decision.

Don't create plans that require resources you don't have. That's fantasy, not planning.

Step 5: Stakeholder Alignment

Get key stakeholders on both sides aligned on the plan before execution starts.

On the customer side, confirm with the executive sponsor about timeline, commitment, and escalation path. Confirm with the project champion that they own day-to-day execution. Confirm with IT/technical team about integration and security timeline. Confirm with end user managers about training schedule and expectations. Confirm with procurement/legal about any outstanding contractual items.

On the vendor side, confirm with sales that scope matches what was sold. Confirm with the implementation team about capacity and task assignments. Confirm with the support team about readiness for go-live support. Confirm with the technical team about integration and development capacity. Confirm with leadership that this project is prioritized appropriately.

Review the plan in the kickoff meeting. Send written plan with a request for confirmation. Have 1:1 conversations with key stakeholders who need convincing. Address concerns and objections before starting execution. Document alignment (doesn't need to be formal, just clear).

Red Flag: If you can't get customer executive sponsor to confirm the plan, you don't have real commitment. Escalate this before starting.

Step 6: Plan Documentation and Approval

Document the plan in a format that's accessible, useful, and actually gets referenced.

Your plan should include project overview and objectives, scope (in and out), timeline with phases, milestones, and key dates, task list with owners and deadlines, RACI matrix (who's Responsible, Accountable, Consulted, Informed), risk register with mitigation plans, communication plan (who gets updates, how often, what format), and success criteria and completion definition.

For format, you have options. Gantt charts work well for complex projects with many dependencies (use project management tools). Kanban boards work well for iterative implementations with less rigid sequencing (Trello, Asana). Spreadsheets work well for simple implementations with straightforward timeline. Documents with timeline work well for narrative explanation with dates embedded.

Best Practice: Use the simplest format that captures the necessary information. Don't make customers learn your project management tool if they won't engage with it.

For customer approval, send the plan with an explicit request for approval. Review in kickoff meeting and get verbal commitment. Follow up with email summary: "As discussed, here's the plan we agreed to..." Track approval in CRM.

Managing Dependencies Throughout Implementation

Dependencies kill timelines. Proactive dependency management keeps projects moving.

Types of Dependencies

Sequential Dependencies (Finish-to-Start):

These are straightforward. Data migration can't start until data export completes. Training can't start until system is configured. Go-live can't happen until testing passes. Build these into your timeline with buffer between dependent tasks.

Internal Customer Dependencies:

IT security review before API access gets granted. Legal review of data processing agreement. Budget approval for additional licenses. Data team to export legacy system data. Identify these early, engage stakeholders proactively, and escalate delays quickly.

External Dependencies:

Third-party vendor providing integration. Data provider delivering files. Consultant building custom integration. Legacy system access from previous vendor. Get commitments in writing, build extra buffer, and have backup plans.

Vendor Internal Dependencies:

Implementation specialist availability. Custom development from engineering. Security review from compliance team. Legal review of customer's contract addendum. Reserve resources in advance, communicate early, and escalate internally if blocked.

Critical Path Analysis

The critical path is the sequence of dependent tasks that determines minimum project duration. Any delay on critical path delays the entire project.

Here's how to identify it. First, map all tasks and dependencies. Then identify the longest sequence of dependent tasks from start to finish. Those tasks are your critical path.

Example:

Path A: Kickoff → Configuration → Training → Go-live (35 days)
Path B: Kickoff → Integration → Testing → Go-live (42 days)
Path C: Kickoff → Data Migration → Validation → Go-live (38 days)

Path B is the critical path at 42 days. That's your minimum project duration. Delays on Path B delay everything. Delays on Path A or C only matter if they exceed 42 days.

To manage your critical path, focus attention on those tasks. Add buffer to critical path items. Monitor their progress closely. Intervene immediately if critical path items slip. Look for opportunities to parallelize or compress the critical path.

Dependency Tracking and Communication

Track dependencies actively throughout the project.

Here's a simple dependency register format:

Dependency	Owner	Due Date	Status	Blocker	Escalation Plan
IT security review	Customer IT	Day 10	In Progress	Waiting on questionnaire	Escalate to sponsor Day 12
API access granted	Customer IT	Day 12	Blocked	Security review pending	Same as above
Legacy data export	Customer Data team	Day 15	Not Started	Resource assigned next week	Check-in Day 8
Integration partner API	External vendor	Day 20	On Track	None	Monitor weekly

Check dependency status in every customer touchpoint. Proactively reach out to dependency owners 3-5 days before due date. Escalate blocked dependencies within 48 hours. Update customer on dependency status in weekly updates.

Project Management Best Practices for Onboarding

Status Reporting and Communication

Set up a communication cadence that matches project phase. Week 1-4: Twice-weekly check-ins (calls or emails). Week 5-8: Weekly check-ins. Post-go-live: Tapering to bi-weekly.

Your status report should cover completed this week (what got done), planned for next week (what's coming), blockers and risks (what needs attention), customer action required (what they need to do), and milestone progress (where we are in overall timeline).

For internal vendor communication, update CRM with status after every customer interaction. Flag at-risk projects in weekly CS team meeting. Escalate blockers to manager within 24 hours. Share wins and learnings with team.

Risk and Issue Management

During planning, identify risks (what could go wrong?). Assess likelihood and impact (high/medium/low). Define mitigation plans (how to prevent or minimize). Then monitor risks throughout the project and communicate risks to customer and internal team.

Here's a risk register example:

Risk	Likelihood	Impact	Mitigation	Owner
Data quality issues delay migration	High	High	Pre-migration data audit, cleaning plan	CSM
Customer resources unavailable	Medium	High	Get backup person identified upfront	Customer Champion
Integration complexity exceeds estimate	Medium	Medium	Early technical review, buffer in timeline	Implementation Specialist
User adoption resistance	High	Medium	Early user involvement, champion program	CSM + Customer

For issue management, track issues in a shared location (CRM, project tool, or spreadsheet). Assign an owner and target resolution date. Escalate issues that aren't resolved within SLA. Review open issues in every customer check-in. Document resolution for future reference.

Change Request Handling

Change requests happen when customers want to add scope (new integration, additional use case), want to accelerate timeline, technical discovery reveals more complexity than expected, or external dependencies create timeline impact.

Your process should look like this. First, document the requested change and reason. Then assess impact on timeline, resources, and cost. Present options to the customer (add time, reduce other scope, add resources). Get approval for the change and revised plan. Finally, update project plan and communicate to all stakeholders.

Try this communication template: "You've requested [change]. To accommodate this, we have three options: 1) Add 2 weeks to timeline (new go-live: [date]), 2) Move [other feature] to phase 2, keep current timeline, 3) Add [resource] at [cost], keep current timeline. Which option works best for you?"

Timeline Management and Recovery

When projects get off track, your response depends on the severity.

Minor Delays (1-3 days):

Try to make up time in upcoming tasks. Work with customer to prioritize and compress where possible. No need for formal timeline revision.

Moderate Delays (4-10 days):

Assess whether you can recover time or need to extend. Compress non-critical path tasks. Add resources temporarily if possible. Communicate revised timeline to stakeholders.

Major Delays (10+ days):

Formal timeline revision required. Root cause analysis: Why did this happen? Revised project plan with new milestones. Executive sponsor notification and approval. Post-mortem to prevent recurrence.

Timeline compression techniques include parallelizing tasks that were sequential, reducing scope (move items to phase 2), adding resources (more people or vendor support), reducing perfection (good enough for go-live, refine later), and fast-tracking approval processes.

Tools and Documentation Templates

Project Plan Format

Your project plan should include these sections: Executive Summary (project goals, scope, timeline, stakeholders), Phases and Milestones (high-level timeline with key dates), Detailed Task List (all tasks with owners, dependencies, dates), RACI Matrix (who does what), Risk Register (identified risks and mitigations), Communication Plan (cadence, channels, reporting), and Success Criteria (how we'll know we succeeded).

RACI Matrix Template

Task/Activity	Customer Champion	Customer IT	CSM	Implementation Specialist	Support Team
Kickoff Meeting	A	C	R	C	I
Account Setup	I	C	R	R	I
Integration Configuration	I	A	C	R	I
Data Migration	C	R	A	C	I
User Training	R	I	A	C	I
UAT	A	C	C	R	I
Go-Live	A	C	R	C	R

Key: R = Responsible (Does the work), A = Accountable (Ultimately answerable for completion), C = Consulted (Provides input), I = Informed (Kept in the loop)

Risk Register Template

Risk ID	Risk Description	Likelihood (H/M/L)	Impact (H/M/L)	Mitigation Plan	Owner	Status
R001	Customer resources unavailable	M	H	Identify backup resources in kickoff	CSM	Open
R002	Data quality issues	H	M	Pre-migration data audit	Data Specialist	Monitoring
R003	Integration complexity	M	M	Early technical review, add buffer	Implementation	Mitigated

Status Report Template

Week of [Date]

Completed This Week:

Account setup and user provisioning complete
Initial integration testing successful
Data export from legacy system received

Planned Next Week:

Complete data cleaning and validation
Finish integration configuration
Schedule training sessions

Blockers/Risks:

IT security review delayed by 3 days (now expected Day 12)
Data quality lower than expected, adding 2 days to cleaning process

Customer Action Required:

Provide list of training participants by Friday
Schedule UAT sessions for Week 6

Milestone Progress:

Phase 1 (Setup): 100% complete ✓
Phase 2 (Integration/Migration): 60% complete (on track)
Phase 3 (Training): 0% (starts next week)

Complex Implementation Scenarios

Multi-Site or Multi-Business Unit Rollouts

You have three approach options.

Sequential Rollout (Recommended):

Implement site 1 completely. Learn and refine approach. Roll out to site 2 with improvements. Continue until all sites are live. Pros: Lower risk, learning between sites, manageable complexity. Cons: Longer total timeline.

Parallel Rollout:

Implement all sites simultaneously with centralized project management and shared resources across sites. Pros: Faster total timeline. Cons: Higher risk, more complexity, requires more resources.

Phased Rollout:

Pilot with 1-2 sites. Validate approach and refine. Roll out to remaining sites in waves. Pros: Balance of speed and risk management. Cons: Requires coordination across phases.

Planning considerations: Are sites similar or unique? (Unique = sequential safer). Shared or separate data? (Shared = more complexity). Centralized or local decision-making? (Local = sequential easier). Resource availability across sites? (Limited = sequential required).

Phased vs Big-Bang Approaches

Phased Implementation:

Implement one use case or department at a time. Expand to additional use cases after success. When to use: Complex products, multiple use cases, risk-averse customers, limited customer resources.

Big-Bang Implementation:

Implement everything at once. All users, all use cases, all at go-live. When to use: Simple products, single use case, urgent need, customer has full commitment.

Most common approach: Phased. Start with highest-value use case, prove success, expand from there.

High-Complexity Technical Implementations

You're dealing with high complexity when you see multiple integrations (3+), custom development required, data migration from multiple legacy systems, regulatory or compliance requirements, or high availability or performance requirements.

These need additional planning: technical discovery phase before planning, technical architect involvement, extended timeline with buffer, more formal testing process, detailed technical documentation, and risk mitigation for technical unknowns.

Don't rush the planning phase to start execution. Don't underestimate technical complexity. Don't skip technical validation steps. Don't let customer expectations get ahead of technical reality.

Managing Scope Expansion

Common scenario: Project starts with defined scope. Customer discovers new needs or opportunities. Requests to add scope.

Here's how to handle it.

Step 1: Acknowledge and Validate

"That's a great idea. Let's make sure we understand the requirement and impact."

Step 2: Assess Impact

How much work does this add? What's the timeline impact? Do we have required resources? Is this phase 1 critical or phase 2 nice-to-have?

Step 3: Present Options

"To add this to scope, we have three paths: 1) Extend timeline by [X days], 2) Move [other feature] to phase 2, 3) Defer this to phase 2 and revisit after go-live"

Step 4: Get Decision and Update Plan

Customer chooses option. Update project plan. Communicate change to all stakeholders. Document in change log.

Prevent scope creep with clear scope definition upfront. Regular scope validation: "We're still on track with original scope, right?" Use "phase 2" language for new ideas: "Great idea for phase 2!" Keep a parking lot of phase 2 ideas to show you're listening.

The Bottom Line

Implementation planning separates onboarding programs that consistently deliver value on time from those that turn into chaotic firefighting exercises with unpredictable timelines.

The planning discipline is simple: Understand what you're implementing (discovery). Define scope and boundaries (what's in, what's out). Build realistic timeline with dependencies mapped (project plan). Verify resources exist (capacity check). Align stakeholders (commitment). Document and execute (with ongoing management).

Teams that treat planning as "unnecessary overhead" pay the price in missed deadlines, scope creep, customer frustration, and low retention.

Teams that invest upfront in solid planning deliver faster implementations, happier customers, and predictable outcomes that scale.

The choice is clear: plan the work, then work the plan.

Ready to build your implementation process? Explore kickoff meeting best practices, account setup configuration, and time to value optimization.

Learn more:

Tara Minh

Operation Enthusiast