6 min readUpdated: Category: Shoring
Weeks 1-2: define the work before defining the team
Write down which work packages leave the organisation and which stay. Anything involving design authority, business sign-off or regulated approvals normally stays. Everything else — development, configuration under a specification, testing, monitoring, second-level support — is a candidate.
Weeks 2-4: roles, access and legal groundwork
Access is the most common cause of a slow start. Order everything in week two, not in the onboarding week.
- Named roles on both sides: delivery lead, technical lead, business contact, escalation contact
- System access: named accounts, VPN, authorisation roles, ticket-tool licences
- Data protection: processing agreement, rules for production data, where data may be stored
- Working agreement: overlap hours, meeting cadence, response expectations, language
Weeks 4-8: onboarding against real work
Onboarding by documentation alone does not work. Give the new team small, real tickets in the first week with a reviewer attached, and increase scope as the review comments shrink. Track how long it takes for a ticket to pass review first time — that curve is the honest onboarding metric.
Weeks 8-12: hand over ownership
By the end of the first quarter, the nearshore team should own defined areas end to end: a module, an interface set, a test suite. Ownership means they are the first name on the ticket, not a pair of hands waiting for instructions.
Checkpoints that tell you the truth
- First-time-pass rate on reviews, trending upwards
- Backlog throughput per sprint, stable and predictable
- Number of clarification loops per ticket, trending down
- Business feedback on responsiveness, gathered directly rather than through the provider
What to fix immediately if it stalls
Almost every stalled nearshore setup traces back to one of three things: unclear acceptance criteria, a single overloaded person on the client side acting as the only knowledge source, or overlap hours that exist on paper but are filled with other meetings.
Frequently asked questions
- How long until a nearshore SAP team is productive?
- Expect meaningful throughput after four to eight weeks if onboarding runs against real tickets with a reviewer, and full ownership of defined areas by the end of the first quarter.
- What should never be moved to a nearshore team?
- Design authority, business sign-off and regulated approvals normally stay with the client. Development, configuration, testing and monitoring transfer well.
- What is the most common setup mistake?
- Ordering system access too late. VPN, named accounts and tool licences should be requested in the second week, long before onboarding starts.
Next step
Let's work out how this applies to your own SAP landscape and delivery plan.
Set up a nearshore team