Team decisions / Three location models
Choose where each part of the work belongs.
A whole project does not always need one location model. Business discovery, implementation, specialist review and ongoing operation can have different needs. Compare the actual people and responsibilities for each part, then check whether dividing the work adds more coordination than it solves.
Separate the choices
Where work happens is one decision among several.
Onshore development uses a team in the buyer's country. Nearshore uses a team in a nearby country. Offshore, as used here, means a more distant country. These labels describe relative location. Choose the actual arrangement through work requirements, assigned capability, usable collaboration, complete cost and clear responsibility, including any handoffs between locations.
- Location and presence
- A same-country supplier may work remotely, and an overseas contributor may make agreed visits. Confirm where the assigned people work and whether any physical presence is actually needed.
- Location and management
- A nearby team can still require substantial client direction. A distant supplier may own a bounded delivery scope. Set the responsibility model separately from the country choice.
- Location and work allocation
- You can keep the work together or divide it into explicit parts. Each split needs an input, a receiving owner, a reviewable result and an agreed way to resolve changes.
Three illustrative hybrids
A combination needs a reason and a tested interface.
These examples show possible allocations, not roles that inherently belong in particular regions. The same work could be allocated differently if the proposed contributors meet its requirements. Keep a single arrangement when splitting adds no supported benefit.
Onshore discovery, nearshore implementation
01Possible allocation: A domestic contributor develops business context with stakeholders; a nearby-country team implements agreed changes.
- Reason to consider it
- The discovery contribution has a practical reason to remain close to the business, and implementation can proceed from shared context.
- Interface needed
- Business rules, examples, open questions, acceptance conditions and direct access to decision makers.
- Test the split
- Ask the implementation team to explain the proposed change and surface ambiguities before coding. Check that discoveries reach the business owner without repeated relaying.
- Accountable owner
- The product owner owns business decisions; the technical owner accepts the integrated result.
- Inspect
- A shared decision record and a representative change both groups understand.
- Failure to avoid
- The discovery contributor becomes a permanent translator of undocumented requirements.
- Reject or revise when
- The work cannot be separated without repeated loss of context.
Nearshore core, offshore specialist work
02Possible allocation: A nearby-country team maintains the main delivery flow while a more distant contributor handles a bounded specialist task.
- Reason to consider it
- There is evidenced capability for that task and its inputs, outputs and integration boundary can be defined.
- Interface needed
- Interfaces, permitted data, expected findings or artifacts, review criteria and an integration owner.
- Test the split
- Have the specialist produce a small representative result. Ask the receiving team to explain, validate and integrate it from the available record.
- Accountable owner
- The technical owner resolves architectural decisions and accepts the combined change.
- Inspect
- A usable artifact, checks, limitations and an acknowledged receiving handoff.
- Failure to avoid
- Specialist output is technically plausible but cannot be used by the main team.
- Reject or revise when
- The task depends on constant undocumented interaction with the core work.
Distributed build, onshore operation
03Possible allocation: Development occurs across agreed locations while a domestic service owner and receiving team operate the result.
- Reason to consider it
- The operating arrangement has a specific business requirement and the receiving team can participate before delivery ends.
- Interface needed
- Operational responsibilities, deployment authority, known issues, support boundaries and transition conditions.
- Test the split
- Have the receiver work through a representative operational question using the supplied documentation and permitted environment.
- Accountable owner
- The service owner accepts operating readiness; authorized people retain release and access decisions.
- Inspect
- A receiving exercise, current knowledge and a clear escalation path.
- Failure to avoid
- An end-of-project document is mistaken for established operating capability.
- Reject or revise when
- The receiving team lacks the knowledge, access or capacity to operate the result.
Neutral model comparison
Apply the same evidence standard to all three.
These are considerations to investigate in the actual proposal. A location label provides no standard price, quality level or working schedule. Domestic delivery also needs explicit diligence and a usable agreement.
| Location model | Meaning here | Potential fit to investigate | Evidence to request | What the label cannot prove |
|---|---|---|---|---|
| Onshore | Same country as the buyer | Required local participation or domestic delivery needs | Actual people, work locations, access and visit commitments | On-site presence, shared hours, capability or lower risk |
| Nearshore | A nearby country | Practical proximity and usable cross-border collaboration | Assigned-role schedules, relevant work and operating responsibilities | Cultural fit, identical obligations, price or decision access |
| Offshore | A more distant country | Suitable capability with workable task boundaries and handoffs | Demonstrated contribution, review path and receiving capability | Lower total cost, continuous progress or a particular quality level |
Allocate the work
Decide the boundary before assigning a location.
Illustrative allocation: business-rule discovery onshore, a build package nearshore and specialist review offshore. This is a planning example, not a recommendation. Each allocation must earn its place through the task requirements and the evidence below; keeping all three together remains an option.
- 01
Separate requirements from preferences
Write down required physical participation, permitted access, decision availability and receiving responsibilities. Have qualified owners resolve consequential requirements. Do not turn an untested preference into a hard constraint.
- 02
Identify work that can stand apart
Map dependencies between discovery, implementation, review and operation. Describe the inputs and acceptance conditions for any proposed split. Keep tightly coupled work together when the interface remains unclear.
- 03
Inspect actual people and schedules
Compare relevant contribution and the working arrangements of the proposed participants. Reserve necessary decision and review time. Make routine context available in writing without assuming every question can be settled asynchronously.
- 04
Exercise the receiving handoff
Transfer a representative task with its current state, findings, checks and next action. Have the receiver acknowledge responsibility and continue. Inspect clarification, waiting and integration effort.
- 05
Compare the complete arrangement
Cost supplier work, retained client effort, tools, coordination, transition and operation on the same basis. Choose the supported arrangement and record which changes would require another review.
Ownership across the boundaries
Keep the combined result accountable.
Multiple locations need an explicit way to become one accepted result. The number of suppliers and the location model are separate decisions.
- Name the integration owner
- Identify who accepts the combined change and resolves conflicting technical or business assumptions. Separate contributors can complete their tasks while leaving the overall result incomplete.
- Keep one current work record
- Share decisions, interfaces, acceptance conditions and open issues with the permitted participants. Assign changes and unresolved questions to people who can act on them.
- Count the added coordination
- Include handoff preparation, clarification, review, integration and retained client work in the comparison. A lower line-item rate does not establish a lower cost for the complete arrangement.
- Review access and transition
- Confirm who can use which systems and data in each part of the assignment. Authorized owners and qualified advisers resolve applicable obligations. Maintain the ability to transfer work and remove access as responsibilities change.
Questions before choosing
Choose the arrangement, then verify that it works.
A supported decision can use one model or a deliberate combination. More locations do not automatically create a better setup.
- Is onshore development the same as an in-house team?
- No. Onshore describes the country relationship. An onshore supplier can be external, and an internal organization can have people in several countries. Clarify employment, contract and delivery responsibility separately.
- Does nearshore always provide the best balance?
- No universal balance is established by the label. Compare actual capability, required collaboration, cost scope and obligations. The arrangement must fit the task and the client's ability to direct, review and receive the work.
- When does a hybrid arrangement make sense?
- When different parts have distinct requirements and the proposed split has a usable interface and receiving owner. Test whether each part can proceed and integrate as expected. Reject the split when it mostly adds relaying, waiting or unclear accountability.
- Can one supplier use all three models?
- A supplier may propose people in multiple locations. Inspect the actual contributors, subcontracting and responsibility map rather than counting supplier names. One commercial relationship does not remove the need to understand internal handoffs and access boundaries.
- How should we compare cost across the three models?
- Use equivalent work and responsibilities. Include supplier charges, client effort, tools, review, coordination, transition and ongoing operation where relevant. Keep unknown inputs explicit and use current scoped quotes rather than assuming a rate hierarchy from location.
Source basis
Definitions and guidance behind the allocation method.
- 01
IBM
Business process outsourcing: location modelsSame-country, nearby-country and more-distant-country definitions reviewed. Used for terminology only; broader promotional benefits and regional cost assumptions are excluded.
- 02
GOV.UK Cabinet Office
The Sourcing PlaybookComponent-level delivery assessment and whole-life cost sections reviewed. Its hybrid discussion concerns in-house and market delivery; the geographic examples here are Werkon's planning illustrations. Government mandates are not generalized.
- 03
GitLab Handbook
All-Remote MeetingsBefore, during and after meeting guidance reviewed; modified August 2026. Informs actual participant schedules, prepared context and recorded decisions. Fixed timing, tool and recording practices are not universal requirements.
- 04
GitLab Handbook
Handoffs and ContinuityMain guidance reviewed; modified August 2026. Its on-call example informs current context, next actions and receiving acknowledgement. The rotation, timings and support coverage are not adopted for development work.
Start with one real workflow
A Systems Audit is the usual starting point. If the opportunity is already clear, we can move directly into a focused build.
Show Us the WorkflowStart with the free automation readiness checklistOBSERVEQUANTIFYDECIDEBUILD