How to Build a SaaS Implementation Team from Scratch

IDC research identifies talent shortage as the third most common cause of SaaS implementation delays, cited by 38% of organisations that experienced significant project overruns. The more specific finding behind that statistic is instructive: it’s rarely a shortage of general technical talent. It’s a shortage of people with the specific implementation skills the project required, people who knew how to manage a complex SaaS rollout, not just how to build software or manage projects in general.

Implementation work is a distinct discipline. The skills required to plan and execute a complex SaaS rollout are meaningfully different from the skills required to build a product, manage a development team, or run operational technology. People who are excellent at one are not automatically equipped for the other. Organisations that staff implementation projects with people whose expertise lies elsewhere, and don’t recognise the gap until midway through the project, are creating the talent shortage problem from the inside.

Here’s what the six core implementation roles are, what each one does, when they join the project, and what the cost is of not having them.

 

The Implementation Project Manager

The implementation PM is not a generic project manager. This distinction matters more than most hiring managers appreciate when they’re building the team.

 

What Sets an Implementation PM Apart

A generic PM manages scope, schedule, and budget. An implementation PM does all of that plus: manages the vendor relationship as a distinct workstream with its own governance; coordinates across functional areas that have conflicting priorities and no natural reason to agree; understands enough about integration, data migration, and configuration to identify when a vendor’s proposed solution is technically risky even if the schedule looks acceptable; and maintains accountability for both technical delivery and business outcomes through go-live and into the adoption period.

 

When They Join and What Happens Without Them

The implementation PM joins at the very start of the project, before the contract is signed ideally, so they can review the implementation scope and timeline in the vendor agreement before it becomes a contractual commitment. They stay through the full post-go-live stabilisation period, which is typically eight to twelve weeks after a major SaaS launch.

The cost of not having an implementation-experienced PM is schedule overrun and escalating costs as problems that an experienced PM would have anticipated become crises that require expensive remediation. According to McKinsey, large IT projects run 45% over budget on average and 7% over time. The variation in those numbers tracks closely with project management quality.

 

The Business Analyst

The BA role on a SaaS implementation is requirements capture and process mapping, but in the specific context of a system that already exists, with a configuration model that has constraints, and processes that need to change to fit the new system rather than the new system fitting the existing processes.

 

A Subtler Skill Than It Sounds

This is a subtler skill than it sounds. SaaS platforms are not infinitely configurable. They have an opinionated model for how business processes should work, and the implementation BA’s job is to understand that model deeply enough to know when a client’s existing process can be adapted to fit the platform’s native workflow, when configuration can accommodate the existing process with acceptable trade-offs, and when a process genuinely needs to be redesigned rather than mapped across.

Getting this wrong in either direction is expensive. BAs who map every existing process into the new system without questioning whether those processes make sense create over-configured, brittle systems that are expensive to maintain. BAs who push clients to adopt platform defaults without understanding the operational reasons behind existing processes create systems that don’t work for the team that has to use them.

 

When They Join and How to Resource Them

The BA joins at project inception and is most heavily engaged during requirements gathering and sprint design. They typically step back after the major configuration work is complete, though they remain available for scope change assessments through to go-live. Whether to hire, contract, or embed depends on the scale of the implementation: for a complex multi-module rollout, a dedicated BA for six to twelve months is warranted; for a more contained implementation, a contractor engagement covering the first half of the project is often sufficient.

 

The QA Specialist

The most consistently misplaced role in SaaS implementation teams is the QA specialist. They’re typically brought in during the final phase of the project, a few weeks before go-live, to run user acceptance testing. This is the wrong model, and it produces the defect profiles that drive implementation cost overruns.

 

Sprint-Embedded from Day One

A QA specialist on a SaaS implementation should be sprint-embedded from the first sprint that produces testable functionality. That means writing test cases as configurations are built, testing each sprint’s output before it’s carried forward into the next sprint, and surfacing defects when they’re in a configuration that can be changed in hours rather than an integrated system where the same change takes days.

IBM research consistently shows that defects found in design and development cost five to ten times less to fix than defects found in testing, which cost five to ten times less to fix than defects found in production. The arithmetic of sprint-embedded QA is straightforward: catching a configuration error in sprint three costs a fraction of finding the same error in UAT and a fraction of a percent of the cost of finding it in production.

 

Compliance Documentation

The QA specialist is also the person who owns the test documentation that may be required for compliance purposes, particularly in regulated industries. This documentation needs to be built systematically throughout the project, not assembled retrospectively before go-live.

 

How to Resource Them

Whether to hire, contract, or embed: for most SaaS implementations, an embedded specialist from an implementation firm is the most cost-effective option. Building an in-house implementation QA function for a project is expensive and creates a capability that may not be needed again at the same intensity. A contracted specialist who brings both testing expertise and implementation context is typically more effective and more cost-efficient.

 

The Technical Lead

The technical lead owns the integration architecture and data migration strategy, the two areas most likely to produce serious, late-stage implementation problems if they’re not given experienced, dedicated ownership.

 

Integration Complexity

Integration complexity is consistently underestimated in SaaS implementation scoping. The new platform needs to exchange data with existing systems, whether CRMs, ERPs, billing platforms, identity providers, or data warehouses, and each integration has its own authentication model, data format, error handling requirements, and maintenance overhead. Integration work that looks straightforward at the contract stage frequently expands significantly as the actual data structures and API behaviours of the existing systems become visible during implementation.

 

Data Migration Risk

Data migration carries a different category of risk. Moving production data from an existing system to a new one involves data cleansing, transformation, validation, and in regulated industries, documentation of the migration process sufficient to satisfy audit requirements. Data migration problems discovered on cutover weekend, when there’s limited time and high pressure, are among the most expensive outcomes in implementation projects.

 

When They Join

The technical lead joins after the requirements phase, when the integration scope becomes clear, and is most heavily engaged through the build and testing phases. For smaller implementations with limited integration scope, this role may be covered by a senior vendor consultant. For complex, multi-system implementations, a dedicated technical lead with experience in the specific integration patterns involved is warranted.

 

The Change Manager

The distinction between change management and training is one of the most important and most frequently missed in SaaS implementation team design. Training teaches people how to use the system. Change management addresses whether people choose to use it, and that’s a different problem requiring different skills and earlier involvement.

 

The Quiet Killer of Business Cases

Adoption failure is the quiet killer of SaaS implementation business cases. The system goes live technically on schedule. Six months later, active user rates are at 50%. Key workflows are still running through the old system or through spreadsheets. The efficiency gains in the business case haven’t materialised. The implementation was technically successful and commercially ineffective.

 

What They Actually Do

A change manager on an implementation project starts work in the early sprints, mapping the people who are most affected by the change, identifying the likely sources of resistance, developing business champion networks within each functional area, and designing the process redesign workshops that need to happen before go-live. They’re not running training in sprint one; they’re building the organisational conditions in which training will actually produce lasting behaviour change.

 

Why This Role Is Not a Luxury

This role is the most commonly omitted from implementation teams, particularly for mid-market organisations that consider it a luxury. It is not a luxury. It is the function that determines whether the system gets used after go-live. The cost of not having it is the gap between the business case and the actual outcome, which is typically measured in months of unrealised efficiency gains and, in some cases, in a second implementation programme to address what the first one failed to achieve.

 

The Vendor Liaison

In larger implementations, the vendor liaison is a distinct role, someone whose primary responsibility is managing the relationship with the SaaS vendor’s implementation team. In smaller implementations, this function is typically carried by the implementation PM. Either way, it needs explicit ownership.

 

Managing Structural Tensions

Vendor relationships on SaaS implementations have structural tensions that require active management. The vendor’s implementation consultants are commercially accountable for the scope and timeline they signed up to, not for the scope and timeline your business actually needs. If requirements evolve, as they always do on complex implementations, the vendor’s default response is change control, which means additional cost and schedule impact. Managing that process professionally, with documentation and mutual agreement, is vendor liaison work.

 

Establishing Escalation Paths

Vendor escalation paths need to be established and tested before they’re needed. When a critical defect is found three weeks before go-live, the question of who at the vendor organisation has the authority and the motivation to resource the fix quickly should already be answered. Building those relationships during the calm of mid-project is far more effective than trying to establish them in the pressure of a pre-go-live crisis.

 

Hire, Contract, or Embed: The Decision Framework

For most organisations running a significant SaaS implementation, the answer to “build or buy” for implementation talent is some version of embedding external specialists rather than hiring for a time-limited need.

 

Why Hiring for a Single Project Rarely Works

Hiring implementation specialists for a single project creates a resourcing problem at the end: what does the organisation do with an implementation PM, QA specialist, and change manager once the project is complete? The answer is usually redundancy or redeployment into roles that don’t fully utilise their implementation-specific skills. Neither outcome is efficient.

 

The Case for Contracting

Contracting experienced implementation specialists, either as individuals or through an implementation firm, brings the full capability for the duration of the project and exits cleanly at the end. The trade-off is higher day-rate cost relative to permanent salary. The economic comparison needs to account for the full cost of a failed or significantly delayed implementation: the McKinsey data on 45% average cost overrun for large IT projects makes the premium for experienced implementation talent look reasonable by comparison.

 

The Decision That Actually Matters

The most important decision is not hire versus contract. It is whether to staff the implementation with people who have genuine implementation experience in the relevant domain, or to staff it with capable people whose experience lies elsewhere and hope the gap doesn’t matter. Implementation history suggests it usually does.