Staffing a SAP Commerce Project: The Roles You Need and When You Need Them

The most common staffing mistake on a commerce project is not too few people; it is an unfilled role. A team can be busy and still fail because nobody owns integration architecture, or because the person who can approve sprint acceptance criteria is never in the room. The delivery framework guide notes that one person can cover several roles, but the roles themselves cannot go vacant, and knowing which roles exist is how you avoid discovering a gap three sprints in. This guide is the role map: oversight, day-to-day delivery, and subject-matter expertise, with the caveat that team shape changes across the project's phases, so you staff for the phase you are in, not one static roster.

Oversight: Decisions and Escalation#

These roles do not write code or requirements; they own the money, the direction, and the unblocking:

• Executive Sponsor: owns objectives and success criteria, the overall budget and schedule, the go/no-go, strategic direction, and the top escalation. Without a real sponsor, the project has no one who can make the hard scope-versus-date call the delivery framework demands.
• Engagement Manager / Delivery Director: accountable for overall delivery, aligning client and delivery organization, managing expectations and staffing, and sitting on the steering committee.
• Program / Project Manager: the responsible party for budget, staffing, reporting, release planning, and resource planning, working with stream leads to manage scope per release and reporting up to the steering committee.

The steering committee (sponsor, delivery director, PM, and key stakeholders) is where the escalations that day-to-day cannot resolve get resolved. A project without a functioning steering committee escalates into a vacuum.

Day-to-Day: The Delivery Engine#

The roles doing the actual work of turning requirements into a running solution:

• Business Analyst / Product Owner: gathers requirements, knows e-commerce and SAP Commerce, liaises between business and technical, and translates requirements into epics and user stories. The functional-requirements owner.
• Solution Architect: captures non-functional and technical requirements, translates functional and non-functional requirements into data model, design, and code direction, owns integration points, and performs sizing. The technical-solution owner (the solution-architecture-definition guide is their core deliverable).
• Architect (project/system level): on larger projects, owns the overall technical solution across all systems, the point of contact for integration and interface decisions. Distinguished from the solution architect on multi-system programs.
• Development Lead: assists with design and sizing, owns code management (branches, merges), leads and mentors the development team, owns overall code delivery, and runs peer code reviews (the code review guide). The person accountable for the code actually shipping.
• Quality Assurance Lead: owns the testing strategy and code quality, may stand up the automation or test framework, writes test plans and cases, leads QA. The person accountable for quality being real (the delivery framework's "quality baked in").
• Stream Leads (optional, for complex scope): named per stream (master data, checkout, fulfillment, and so on) to interact with SMEs and keep a large project's coordination tractable.

The Empowered Business Representative#

One role deserves singling out because projects fail without it and staff it as an afterthought: the Business Representative. Usually on larger projects, an internal or contract analyst who:

• Holds real customer business knowledge and coordinates across business units on the roadmap.
• Acts as the single point of contact when the project team needs a business decision.
• Refines functional requirements per sprint with the BA and prioritizes the backlog.
• Approves sprint acceptance criteria and runs post-sprint user testing and UAT with business users.

This is the "empowered customer representative in the room" the delivery framework insists on, given a job title. A project where every business question routes through a committee that meets weekly is a project that loses a day of velocity per question. Staff a decision-maker, not a message-relay.

Subject-Matter Experts: The Requirements Source#

SMEs are not full-time team members; they are the authoritative source for their domain's requirements, brought in when their area is being analyzed (just-in-time, per the delivery framework). The commerce project's SME map:

• Commerce / eCommerce Manager: product lifecycle, pricing and promotions rules, omni-commerce expectations.
• Merchandiser: merchandising requirements, and day-to-day merchandising training.
• Marketer: marketing requirements, onboarding and training.
• Fulfillment / Inventory: logistics and the inventory-model requirements (the inventory guide).
• Finance: fraud, financial, and reporting needs.
• Customer Service: support requirements.
• Data Protection: the GDPR and compliance requirements (the data protection guide), and sign-off that the solution complies.
• CRM / Business Intelligence: customer-knowledge and reporting/data needs.
• Brand Management: the front-end user experience per brand guidelines, producing UI screens with the design agency.
• Manufacturing / Procurement (for manufacturers): product lifecycle from the supply side.
• Operations / Support: analytics, IT, and SLA needs.

The pattern: every domain that has requirements needs a named SME who can speak authoritatively for it. Missing SMEs produce the requirements gap discovered in UAT.

One Person, Many Hats, No Vacancies#

The framework's key permission: one person can fill multiple roles, especially on smaller projects. A small build might have one person as BA and Product Owner, another as Solution Architect and Development Lead. That is fine. What is not fine is a role going unfilled: nobody owning QA strategy, nobody empowered to approve acceptance criteria, nobody accountable for integration architecture. The exercise is not "hire N people"; it is "ensure every role has an owner, then see how few people that requires."

Staffing Changes by Phase#

Team shape shifts across the delivery phases (the delivery framework's Discover through Run):

• Discover / Prepare: heavy on oversight, solution architect, BA; light on developers. You are deciding what to build.
• Realize: peak development and QA staffing; the delivery engine at full size.
• Deploy / Run: development ramps down, operations and support ramp up; the hypercare and BAU handoff (the go-live guide) needs its own owners.

Plan the roster per phase in Prepare, so you bring people on when their role is active and release them when it is not, rather than carrying a full development team through a discovery phase that has nothing for them to build.

The Staffing Checklist#

• Every oversight role owned: sponsor with real authority, delivery director, PM; functioning steering committee
• Day-to-day roles owned: BA/PO, solution architect, dev lead, QA lead; stream leads if scope demands
• An empowered business representative who can decide and approve acceptance criteria, not a relay
• Every requirements domain mapped to a named SME, brought in just-in-time
• Roles filled without vacancies; multi-hatting used to minimize headcount, not to skip roles
• Roster planned per phase; team shape shifts from architecture-heavy to build-heavy to ops-heavy

A commerce team is not sized by counting bodies; it is validated by checking that no role is orphaned and no decision waits on an absent decision-maker. The projects that stall are rarely short of developers; they are short of an owner for the thing that is currently blocked.