SaaS Implementation Roles: PM, BA, QA, and Dev — Who Does What?
A common mistake organisations make when planning a SaaS implementation is to staff it like a software development project. The assumption is that the same roles that build software will implement it. That assumption consistently produces problems, because implementing someone else’s software platform is a fundamentally different discipline from building your own.
The skills are different. The activities are different. The failure modes when roles are missing or poorly filled are different. Here is what each key role actually does in a SaaS implementation, when they join the project, and what the consequences are of getting the role wrong.
The Implementation Project Manager
What they do: The Implementation PM owns project governance, vendor management, timeline and budget, and stakeholder communication. They are the single point of accountability for the project delivering against its objectives. In a SaaS context, that means managing the relationship with the vendor’s implementation team, tracking commitments and delivery against them, running the steering committee, and making the call when trade-offs between scope, time, and cost need to be escalated.
What they are not: An Implementation PM is not a Scrum Master. Agile ceremonies such as standups, retrospectives, and sprint reviews are coordination tools that the PM facilitates, but the PM’s primary accountability is to the project’s business outcomes, not to sprint velocity. An Implementation PM is also not an account manager who manages the vendor relationship diplomatically. Their job is to hold the vendor accountable to contractual commitments, escalate when those commitments are missed, and protect the project timeline.
Skills required: Vendor management experience, risk management discipline, stakeholder communication at senior level, and ideally experience with the specific platform category (ERP, CRM, HRIS, etc.) being implemented.
When they join: Before vendor selection. The Implementation PM should be involved in defining requirements, evaluating vendor responses, and structuring the implementation contract. Joining after contract signature puts them in a reactive position from day one.
When this role is missing or poorly filled: Projects lose coordination at the critical path. Vendor commitments are missed without consequence. Scope changes accumulate without governance. Stakeholders receive inconsistent information. Timeline slippage begins early and compounds.
The Business Analyst
What they do: The BA elicits business requirements from stakeholders, documents them in a format that can be given to the vendor and QA team, maps current-state processes against the new system’s capabilities, and identifies gaps that require configuration or custom development. They own the requirements documentation for the project and are the primary liaison between the business stakeholders and the technical implementation team.
What they are not: A BA in a SaaS implementation is not a Product Owner in the product development sense. They are not prioritising a backlog of features to be built. They are capturing what the business needs from a system that already exists. They are also not a business process improvement consultant. Their scope is to document the current and target state accurately, not to redesign business processes unless that is an explicit part of the project scope.
Skills required: Requirements elicitation, process mapping, gap analysis, and the ability to translate business language into technical specifications. Familiarity with the platform category being implemented significantly reduces ramp-up time.
When they join: At the requirements phase, before vendor selection if possible. Requirements quality is the single biggest determinant of implementation success, and the BA is the person responsible for that quality.
When this role is missing or poorly filled: Requirements are captured informally by whoever is available, often the PM or a developer, which produces incomplete, ambiguous documentation. Vendors are then asked to implement against unclear requirements, which generates change requests, scope creep, and rework throughout the project.
The QA Specialist
What they do: The QA specialist writes the test plan, authors test cases from acceptance criteria, executes testing within each sprint, raises and manages defects, tracks quality metrics, and confirms that each deliverable meets the agreed acceptance criteria before it is marked as complete. In a well-structured implementation, the QA specialist is embedded in the sprint team from the first sprint, not brought in at the end of the project to do a “testing phase.”
What they are not: A QA specialist is not an end-of-project sign-off resource. The model of “development builds everything, then QA tests everything” is a waterfall pattern that consistently produces late-stage defect discovery at the highest possible cost. The QA specialist’s value is in catching defects within the sprint they are introduced, when developer context is fresh and the cost of resolution is lowest.
Skills required: Test planning, test case design, defect management, and the ability to work across functional and technical testing scenarios. For SaaS implementation specifically, experience with integration testing and data migration validation is particularly valuable.
When they join: Before sprint one. The QA specialist needs to be involved in requirements review to assess testability, and in sprint planning to estimate testing effort and identify test data requirements. A QA specialist who joins at sprint three has already missed the opportunity to improve the quality of the work being tested.
When this role is missing or poorly filled: Defects are found late, in UAT or production, where they cost 15 to 30 times more to fix than they would have in sprint. Go-live dates are delayed. The post-launch period is dominated by emergency defect resolution rather than adoption and value realisation.
The Technical Lead or Developer
What they do: In a SaaS implementation, the Technical Lead is responsible for integration development (building the connections between the new platform and existing systems), data migration scripting and execution, platform configuration beyond standard settings, and technical environment management. They translate the functional requirements documented by the BA into technical implementation decisions.
What they are not: The Technical Lead in an implementation is not building a product. They are configuring and connecting an existing product. This distinction matters because it shapes both the work and the seniority requirements. An engineer with deep experience in the specific platform’s APIs and data model is more valuable than a more senior engineer who is unfamiliar with the platform.
Skills required: API integration development, data migration scripting, platform-specific configuration knowledge, and ideally certifications or documented experience with the vendor’s technical stack.
When they join: At the technical design phase, after requirements are substantially complete. Bringing technical leads in too early results in them making technical decisions in the absence of complete requirements, which creates rework.
When this role is missing or poorly filled: Integrations are built by developers unfamiliar with the platform’s architecture, producing fragile connections that fail under edge cases. Data migration scripts produce inaccurate outputs. Technical issues escalate to the vendor without the internal expertise to evaluate the vendor’s proposed solutions.
The Change Manager
What they do: The Change Manager is responsible for stakeholder engagement, communications planning, training design and delivery, and adoption measurement. Their goal is to ensure that the people who will use the new system are prepared, willing, and able to use it at go-live, not just that the system is technically ready.
What they are not: A Change Manager is not a project coordinator who books training rooms and sends calendar invites. Change management in a SaaS implementation context involves assessing change impact at the role and process level, designing communications that address resistance, and measuring adoption to identify where additional support is required after go-live.
Skills required: Stakeholder engagement, adult learning design, communication planning, and the ability to work with resistant stakeholders constructively. Prosci ADKAR or similar methodology experience is a reliable indicator of professional grounding in the discipline.
When they join: Early in the project, when the change impact assessment is being conducted. Many organisations treat change management as a late-project activity, starting training preparation a few weeks before go-live. This consistently produces low adoption scores because resistance that was identifiable months earlier has not been addressed.
When this role is missing or poorly filled: The system is technically delivered but not adopted. Workarounds and shadow processes emerge alongside the new system. The business case for the implementation is not realised because users continue to use the old system or manual processes in parallel.
The Role Combination Problem
The most common staffing error in SaaS implementations is combining roles that should be separate. The BA who is also the QA specialist cannot be objective about requirements quality. They are testing their own interpretation of the requirements. The PM who is also the Change Manager cannot prioritise both governance and adoption when they are competing for time. The Technical Lead who is also writing acceptance criteria is introducing the exact blind spot that acceptance criteria are designed to prevent.
When Role Combination Is Unavoidable
Small implementations sometimes require pragmatic role combination. When that is necessary, the risk should be explicitly acknowledged in the project risk register, and the activities of each combined role should be clearly scheduled as separate workstreams, not assumed to happen naturally by a sufficiently capable individual.
