A chief technology officer is preparing the company’s three-year delivery plan.

The product roadmap is expanding.

Enterprise customers expect faster implementations.

Artificial intelligence is changing how software is designed, built, tested, and operated.

Cybersecurity requirements are increasing.

The company wants access to global capability but does not want to lose product knowledge or strategic control.

The board asks a familiar question:

“Should we establish a delivery center?”

The next question is less clear.

What kind?

An Offshore Development Center?

A Global Capability Center?

A Virtual Delivery Center?

The terms can sound similar because all three promise access to capability beyond the company’s existing local workforce.

But they represent different organizational decisions.

An ODC usually creates a dedicated offshore team, often operated through a service provider.

A GCC creates a permanent enterprise-owned organization in another location.

A VDC creates a persistent, governed execution environment without requiring every capability to be permanently employed, located, or assigned.

The difference is not merely whether the work happens in an office or online.

The models differ in:

• What the enterprise owns

• What it transfers

• What remains permanent

• How quickly capability can change

• How knowledge is retained

• How artificial intelligence participates

• What happens when demand falls

• How difficult the structure is to exit

The right model depends on what the company is trying to build.

A stable engineering organization may justify an ODC.

A strategically important global function at significant scale may justify a GCC.

A changing portfolio of outcomes requiring different combinations of internal leaders, specialists, delivery teams, platforms, and AI agents may fit a VDC better.

The mistake is treating all three as cheaper ways to hire.

They are different architectures for enterprise execution.

---

The Delivery-Center Question Has Changed

For decades, the central question was:

“Where should we place the people?”

A company examined:

• Labour cost

• Talent availability

• Time-zone coverage

• Office infrastructure

• Government incentives

• Language

• Attrition

• Political stability

• Proximity to major customers

The work was then moved to a delivery location.

The organization created a team around it.

That logic produced the offshore development center and later the global capability center.

Both models created substantial enterprise value.

They helped companies:

• Access large talent pools

• Reduce operating costs

• Build twenty-four-hour delivery cycles

• Consolidate fragmented functions

• Develop global engineering capability

• Standardize operations

• Expand into new markets

But the nature of work is changing.

Human labour is no longer the only productive input.

AI agents can research, code, test, document, monitor, and coordinate.

Capabilities can be accessed globally without moving the entire function.

Specialist requirements change from one outcome to another.

Cloud platforms reduce the need for location-owned infrastructure.

Customers expect rapid adaptation rather than stable multi-year delivery plans.

As argued in The New Labor Arbitrage Is Not Geography. It Is Orchestration., competitive advantage is shifting from finding lower-cost labour to designing a better execution system.

The new question is:

“How should the people, agents, systems, partners, governance, and internal ownership required by this outcome be composed?”

Location remains relevant.

It no longer answers the entire question.

---

Part I: Understanding the Three Models

What Is an Offshore Development Center?

An Offshore Development Center is usually a dedicated technology or delivery team established in a lower-cost or talent-rich location.

The ODC may be:

• Operated by an outsourcing provider

• Dedicated exclusively to one customer

• Structured as a build-operate-transfer arrangement

• Established as a captive team in some interpretations

The terminology varies across companies and markets.

For this comparison, ODC refers primarily to a dedicated offshore delivery team managed through or substantially supported by an external provider.

An ODC commonly includes:

• Software developers

• Quality engineers

• Business analysts

• Architects

• Project managers

• Support professionals

• Delivery leadership

The customer typically receives a more stable team than it would through project-based outsourcing or staff augmentation.

The provider may handle:

• Recruitment

• Payroll

• Facilities

• Local compliance

• Day-to-day people management

• Delivery infrastructure

• Replacement capacity

• Administrative operations

The customer provides product direction, requirements, priorities, and varying levels of delivery governance.

---

What Is a Global Capability Center?

A Global Capability Center is an enterprise-owned operation established in another geography to provide strategic, technical, operational, or shared capabilities to the wider company.

GCCs have also historically been called:

• Captive centers

• Global in-house centers

• Shared-service centers

• Global delivery centers

Modern GCCs often extend far beyond back-office support.

They may own:

• Product engineering

• Artificial intelligence

• Data science

• Cybersecurity

• Finance

• Supply-chain operations

• Legal operations

• Research

• Customer experience

• Enterprise platforms

The defining characteristic is ownership.

The enterprise usually establishes or controls:

• The legal entity

• Leadership

• Employment relationships

• Operating culture

• Intellectual property

• Technology environment

• Career architecture

• Governance

A strong GCC is not merely a lower-cost workforce.

It becomes part of the company’s institutional core.

---

What Is a Virtual Delivery Center?

A Virtual Delivery Center is a persistent, governed execution environment organized around an enterprise mandate rather than a fixed location, provider workforce, or permanent team.

Examples may include:

• Product engineering

• AI modernization

• SaaS implementation

• Compliance operations

• Supply-chain analytics

• Customer onboarding

• Growth execution

The VDC can combine:

• Internal outcome owners

• Permanent employees

• External specialists

• Delivery Units or pods

• Service providers

• AI agents

• SaaS platforms

• Customer systems

• Governance controls

• Verification mechanisms

Its defining characteristic is composability within continuity.

The execution mandate persists.

The capability mix changes.

The enterprise does not need to hire every specialist permanently.

It also does not transfer the complete mandate to one opaque provider.

The canonical What Is a Virtual Delivery Center? pillar explains the model in detail.

At its simplest:

A VDC maintains the context, governance, access, relationships, and institutional ownership around work while allowing the contributors and tools performing that work to evolve.

---

Part II: The Evolution of Global Delivery

Project Outsourcing Solved Access

The earliest outsourcing relationships often began with bounded projects.

Build an application.

Maintain a platform.

Test a product.

Migrate data.

The provider brought skills and labour that the customer lacked.

The engagement had a beginning and an end.

This solved an access problem.

But repeated project engagements created repeated startup costs.

Every project required:

• Procurement

• Team formation

• Context transfer

• Access provisioning

• Commercial negotiation

• Governance setup

• Relationship building

Customers wanted continuity.

Providers wanted stable demand.

The ODC emerged as a more persistent structure.

---

The ODC Solved Dedicated Capacity

The ODC gave customers a dedicated team.

Instead of assembling a new project team repeatedly, the company could maintain:

• Familiar contributors

• Continuing product knowledge

• Predictable capacity

• Established processes

• Long-term provider relationships

This reduced project-by-project friction.

The ODC became an extension of the customer’s engineering or technology organization.

But the team still usually existed inside the provider’s employment and delivery structure.

The customer influenced the work.

The provider controlled much of the workforce architecture.

That model worked well when demand remained relatively stable and the required skill mix changed slowly.

---

The GCC Solved Ownership and Strategic Depth

As global enterprises became more dependent on offshore and outsourced capability, some wanted greater control.

They wanted to retain:

• Intellectual property

• Product knowledge

• Career development

• Leadership

• Culture

• Strategic capabilities

The GCC brought capability inside the enterprise boundary.

The company established a permanent organization in a global talent market.

A mature GCC could become a source of innovation rather than merely cost reduction.

It could own global platforms, products, data, cybersecurity, and transformation.

But this required substantial commitment.

A GCC is not a capacity switch.

It is an institution.

---

The VDC Addresses Reconfigurability

The VDC responds to a different problem.

What happens when the enterprise needs continuity but cannot assume that the same team, skill mix, location, or human-to-agent ratio should remain permanent?

The company may require ongoing product-engineering capability.

But one quarter may emphasize:

• Frontend modernization

The next:

• Data architecture

Then:

• AI integration

Then:

• Security hardening

Then:

• Performance and scale

A permanent center can attempt to hire for every possible requirement.

An outsourcing provider can reskill or rotate people.

But both models retain a strong relationship between capability and workforce structure.

A VDC makes the execution environment persistent while allowing the workforce and machine configuration to change more freely.

It is designed around variable capability inside stable governance.

---

Part III: Offshore Development Centers

Where an ODC Is Strong

Dedicated team continuity

An ODC can provide a stable team that learns the product and customer environment over time.

This is a major advantage over transactional staff augmentation.

Faster setup than a captive center

The provider may already possess:

• A legal entity

• Offices

• Recruitment operations

• HR systems

• Management

• Local compliance

• Delivery infrastructure

The customer avoids building these from the beginning.

Access to an existing talent engine

Large providers may recruit at scale and maintain strong pipelines across technical disciplines.

Predictable operating model

The structure is familiar to procurement, technology leaders, and finance.

Rates, roles, governance, and service expectations can be negotiated through established methods.

Provider-managed administration

The provider carries much of the employment and operational burden.

Scale

An ODC can grow into a large engineering or support operation relatively quickly when the provider has sufficient capability.

---

Where an ODC Becomes Constrained

The team may be dedicated, but the economics remain labour-based

ODCs commonly use:

• Monthly resource rates

• Role-based pricing

• Utilization assumptions

• Team pyramids

This can create tension as AI reduces the amount of human labour required.

The customer wants productivity.

The provider may still depend economically on workforce volume.

The provider boundary remains

The ODC may feel like part of the company operationally while remaining outside it institutionally.

This affects:

• Authority

• Culture

• Access

• Career incentives

• Strategic context

• Customer ownership

Capability changes can become staffing changes

When the work changes, the customer may need to request:

• New roles

• Replacements

• Upskilling

• Contract modifications

• Team expansion

The unit of adaptation often remains the person.

Management layers can accumulate

The ODC may include:

• Team leads

• Project managers

• Delivery managers

• Account managers

• Governance leaders

These roles can improve control.

They can also increase execution distance.

Knowledge can become provider-dependent

The dedicated team may accumulate more system knowledge than the internal enterprise.

If the relationship ends, transition risk can be substantial.

Location remains structurally important

Although remote work has changed delivery, an ODC is still typically associated with a particular provider operation or talent location.

---

When an ODC Is the Right Choice

An ODC remains strong when:

• The company needs a stable, dedicated technical team.

• Demand is expected to remain reasonably predictable.

• The required roles are well understood.

• The provider has a strong talent and delivery engine.

• The enterprise wants to avoid establishing its own legal and employment structure.

• The customer can provide effective product and execution leadership.

• The cost and speed benefits of the provider model outweigh the loss of direct ownership.

• The work benefits from long-term team familiarity.

An ODC can be an excellent choice for sustained application development, maintenance, testing, and technology operations.

It should not be dismissed simply because newer models exist.

---

Part IV: Global Capability Centers

Where a GCC Is Strong

Strategic ownership

A GCC sits inside the enterprise.

This creates strong alignment around:

• Intellectual property

• Product vision

• Customer responsibility

• Security

• Risk

• Long-term strategy

Institutional knowledge

Employees accumulate deep context over many years.

Knowledge remains within the company rather than primarily within a provider.

Leadership development

A GCC can develop future global executives, architects, product leaders, and domain experts.

Cultural integration

The organization can build a common enterprise identity across geographies.

Direct control

The company controls:

• Hiring

• Compensation

• Priorities

• Career paths

• Technology

• Operating methods

Scale economics

At sufficient scale, a GCC may provide strong long-term economics by reducing provider margins and building reusable internal capabilities.

Innovation potential

Advanced GCCs can own products, platforms, patents, research, and strategic transformation.

---

Where a GCC Becomes Constrained

High setup commitment

A GCC may require:

• Legal formation

• Local leadership

• Tax planning

• Compliance

• Facilities

• HR operations

• Employer branding

• Recruitment

• Technology infrastructure

The company is building an institution, not hiring a team.

Permanent cost

The GCC workforce remains part of the enterprise’s fixed cost structure.

When demand falls or capability needs change, the company must:

• Redeploy people

• Reskill teams

• Freeze hiring

• Reduce headcount

• Close functions

Scale is often necessary

A small GCC may carry disproportionate overhead.

The model becomes more attractive when the expected size and strategic value justify the infrastructure.

Skills can become trapped in yesterday’s mandate

A GCC may have been created for:

• Application maintenance

• Shared services

• Testing

• Infrastructure support

As the enterprise shifts toward AI, automation, product ownership, or cloud-native systems, the center must reinvent itself.

Institutional inertia can slow this transition.

Geographic concentration risk

A GCC creates deep capability in a location.

This provides scale and culture.

It can also create exposure to:

• Talent-market competition

• Wage inflation

• Local regulation

• Infrastructure disruption

• Political change

• Concentration risk

Exit complexity

Closing or significantly reducing a GCC is operationally, legally, reputationally, and humanly difficult.

The structure should not be created around temporary demand.

---

When a GCC Is the Right Choice

A GCC is compelling when:

• The capability is strategically important.

• The enterprise expects substantial, durable demand.

• Direct ownership of knowledge and intellectual property matters.

• The company can justify the setup and management overhead.

• A large talent ecosystem supports the required skills.

• The organization wants to develop global leadership.

• The center can own outcomes rather than merely receive tasks.

• The company is willing to build a long-term institutional presence.

A strong GCC can become one of an enterprise’s most important strategic assets.

The model should not be reduced to labour arbitrage.

Its greatest value is institutional capability.

---

Part V: Virtual Delivery Centers

Where a VDC Is Strong

Persistent mandate without permanent workforce rigidity

The VDC remains active around an important area of execution.

But the exact human, agent, and specialist configuration can change.

Faster capability activation

Once the VDC’s governance, commercial structure, integrations, and context are established, new capabilities can be activated without rebuilding the complete relationship.

Broader capability access

The VDC can draw from:

• Internal teams

• Global specialists

• Delivery partners

• AI agents

• Software platforms

• Domain experts

It is not limited to one location or one provider’s employee base.

AI-native composition

A VDC can be designed around work allocation between humans and agents.

This becomes increasingly important as enterprises operate more machine actors than employees, as explored in When AI Agents Outnumber Humans.

Granular governance

Access can be:

• Task-scoped

• Role-scoped

• Time-scoped

• Outcome-scoped

External participation does not have to mean broad, permanent access.

Reduced dependence on fixed headcount

The enterprise can retain a smaller permanent core while activating specialist or temporary capability when needed.

This follows the capacity architecture described in The Company After Headcount.

Reconfigurability

The VDC can change its internal execution graph as priorities evolve.

The organization does not need to restructure an entire center each time the capability mix changes.

---

Where a VDC Becomes Constrained

It requires a strong internal owner

A VDC does not allow the enterprise to abandon accountability.

If no internal leader owns the mandate, the VDC can become an uncoordinated collection of external contributors.

Capability composition requires discipline

The organization must understand:

• The outcome

• Required capabilities

• Dependencies

• Decisions

• Verification

Without execution architecture, composability becomes fragmentation.

Not every outcome is easy to modularize

Some work is highly ambiguous.

Some depends on years of implicit context.

Some requires permanent teams with deep trust.

A VDC should not force every activity into artificial modules.

The model may be unfamiliar

Procurement, legal, HR, security, and finance may understand employees and vendors.

A mixed execution environment requires new governance language.

Continuity must be designed

A changing capability mix can create instability if context, documentation, relationships, and decision history are weak.

It can be misused as rebranded staffing

If the customer requests CVs, manages each contributor directly, pays only for hours, and owns every coordination burden, the structure is not meaningfully different from staff augmentation.

It should not hollow out the enterprise core

Strategic judgment, customer responsibility, architecture, risk ownership, and critical knowledge must remain protected internally.

---

When a VDC Is the Right Choice

A VDC is especially relevant when:

• The execution mandate will remain important.

• Capability requirements will change frequently.

• The work crosses multiple functions.

• AI agents and external specialists will participate.

• The enterprise wants control without employing every contributor permanently.

• Traditional outsourcing would create too much distance.

• A GCC would create too much fixed infrastructure or headcount.

• The company needs faster activation than hiring allows.

• Context and governance must persist across changing projects.

• Outcomes can be bounded and verified.

• The company is willing to retain real institutional ownership.

---

Part VI: VDC vs ODC vs GCC Comparison

Decision Dimension	ODC	GCC	VDC
Primary structure	Dedicated offshore provider team	Enterprise-owned global organization	Governed, composable execution environment
Ownership	Usually provider-employed	Enterprise-employed	Mixed capability; institutional ownership remains internal
Location dependence	Usually tied to offshore provider location	Strongly tied to chosen GCC location	Location-flexible by design
Setup speed	Moderate to fast	Slowest	Fast after governance and platform setup
Initial investment	Lower than GCC	Highest	Lower physical and legal setup burden
Permanent headcount	Provider carries most employment	Enterprise carries employment	Smaller core; variable capability can be accessed
Control	Shared through contract and governance	Highest direct organizational control	High governance control without full employment ownership
Capability flexibility	Moderate	Moderate; constrained by workforce structure	High
Knowledge retention	Strong within dedicated team, but provider-dependent	Strongest inside enterprise	Preserved through persistent context and governance
Scale model	Add provider resources	Hire and expand the center	Activate people, pods, agents, platforms, and partners
AI readiness	Depends on provider economics and maturity	Depends on internal transformation	Can be designed natively for human-agent composition
Cost model	Resource rates, team cost, managed capacity	Salaries, infrastructure, legal and operational overhead	Subscription, outcomes, modules, capability activation, hybrid models
Best for	Stable dedicated delivery capacity	Large strategic, permanent capability	Persistent work with changing capability composition
Exit complexity	Contractual transition	Highest	Lower structural exit burden, though knowledge transition still matters
Main risk	Provider dependency and labour-based rigidity	Fixed-cost institutional inertia	Weak ownership and fragmented composition
Strategic value	Reliable extended delivery capacity	Deep enterprise-owned global capability	Adaptable governed execution capacity

The table should not be read as a competition in which one model must win every category.

Each optimizes a different combination of ownership, commitment, flexibility, and scale.

---

Part VII: Comparing Setup Time

ODC Setup

An ODC can often be established faster than a GCC because the provider already possesses:

• Local entity

• Recruitment

• Offices

• HR

• Delivery management

• Compliance systems

The customer must still complete:

• Vendor selection

• Contracting

• Security review

• Team formation

• Knowledge transfer

• Governance design

Setup can take weeks or months depending on scale and complexity.

---

GCC Setup

A GCC generally requires the longest runway.

The company is creating a permanent operation.

Setup may include:

• Location strategy

• Entity formation

• Tax and legal design

• Leadership hiring

• Facilities

• Employer branding

• Technology

• Recruitment

• Operating processes

• Enterprise integration

A GCC can become powerful.

It rarely becomes powerful instantly.

---

VDC Setup

A VDC avoids much of the physical and legal setup associated with a GCC.

But it still requires serious design:

• Execution mandate

• Internal ownership

• Governance

• Commercial structure

• Access controls

• Tool integrations

• Capability model

• Verification

• Context

A poorly designed VDC may launch quickly and fail quickly.

The objective is not zero setup.

It is reusable setup.

Once the environment exists, successive outcomes can move faster because the company does not rebuild the operating relationship each time.

---

Part VIII: Comparing Strategic Control

ODC Control

The customer directs priorities and may work closely with the team.

But the provider typically controls:

• Employment

• Compensation

• Career paths

• Administrative management

• Some delivery methods

Strategic control can be strong when the customer has capable internal product and engineering leaders.

It weakens when the provider becomes the primary holder of knowledge.

---

GCC Control

The GCC provides the strongest direct organizational control.

The company owns the employment relationships and operating structure.

But control should not be confused with effectiveness.

A company can directly control thousands of employees and still suffer from slow decisions, silos, and execution friction.

Ownership is valuable.

It does not eliminate the need for good design.

---

VDC Control

A VDC separates institutional control from employment ownership.

The enterprise can retain control over:

• Outcome

• Architecture

• Customer relationship

• Access

• Data

• Risk

• Acceptance

• Budget

• Verification

while using capabilities it does not permanently employ.

This model requires stronger explicit governance because it cannot rely only on organizational belonging.

The boundary must be designed rather than assumed.

---

Part IX: Comparing Capability Flexibility

ODC Flexibility

An ODC can add, replace, or rotate people.

Large providers may offer broad skills.

But changing capability often involves resource management:

• Find a new person

• Replace a role

• Retrain the team

• Modify the contract

• Add capacity

The model remains workforce-centric.

---

GCC Flexibility

A GCC can recruit new capabilities and reskill existing teams.

At scale, this can be powerful.

But changing the workforce may take time.

Permanent employees cannot be treated as instantly interchangeable capacity.

The company must consider:

• Careers

• Learning

• redeployment

• Organizational design

• Leadership

• Employment obligations

The strength of the GCC—its institutional depth—also makes it less fluid.

---

VDC Flexibility

The VDC is designed around capability activation.

A requirement may be met through:

• A specialist

• A temporary delivery pod

• An AI agent

• A partner

• A SaaS platform

• An internal shared team

The question is not always:

“Whom should we hire?”

It is:

“How should this capability be provided inside the governed execution environment?”

This makes the VDC more adaptable when demand is variable or uncertain.

---

Part X: Comparing Knowledge Retention

ODC Knowledge

A stable ODC can develop strong customer and product knowledge.

The risk appears when that knowledge lives mainly with the provider team.

The enterprise should maintain:

• Internal architecture ownership

• Decision history

• Documentation

• Product leadership

• Transition mechanisms

Otherwise, the dedicated team becomes difficult to replace.

---

GCC Knowledge

Knowledge retention is one of the strongest arguments for a GCC.

Employees belong to the enterprise.

Their work, relationships, and career paths can compound internally.

But employee attrition still creates knowledge loss.

A GCC also needs durable systems for documentation and institutional memory.

Employment alone is not a knowledge-management strategy.

---

VDC Knowledge

A VDC must preserve knowledge at the environment level.

Context should remain connected to:

• Outcomes

• Decisions

• Systems

• Customer history

• Verification

• Delivery artifacts

People may enter and leave.

The VDC should not return to zero.

This follows the principle that persistent context is stored time, developed in Time, the Timeless Oil.

The VDC succeeds when continuity is larger than any one contributor.

---

Part XI: Comparing AI-Agent Readiness

ODC and AI

An ODC provider may invest significantly in AI and reusable automation.

But commercial incentives matter.

If the engagement is priced through headcount and utilization, aggressive automation can reduce billable labour.

The provider and customer must agree on how productivity gains are shared.

Otherwise, AI adoption may remain incremental.

---

GCC and AI

A GCC can become a powerful enterprise AI hub.

It can build:

• Agent platforms

• Governance

• Data products

• AI engineering

• Automation

• Domain workflows

Its advantage is enterprise ownership.

Its risk is replicating the old workforce structure while adding AI on top.

The GCC must redesign workflows and roles rather than treating AI as another tool.

---

VDC and AI

A VDC can be built from the beginning as a mixed human-agent execution environment.

The work can be decomposed into:

• Human-owned outcomes

• Agent-owned bounded tasks

• Automated verification

• Human exception handling

• Specialist review

Agent identity, access, ownership, and lifecycle can be integrated into the governance layer.

This is one of the strongest strategic distinctions between a VDC and conventional labour-centered delivery structures.

---

Part XII: Comparing Economics

ODC Economics

The customer generally pays for:

• Dedicated resources

• Provider management

• Infrastructure

• Margin

• Replacement capacity

• Delivery overhead

Costs are relatively visible and predictable.

But productivity may still be measured through workforce inputs.

---

GCC Economics

The company pays for:

• Salaries

• Benefits

• Facilities

• Entity administration

• Leadership

• HR

• Compliance

• Technology

• Recruitment

• Retention

• Transformation

At scale, the GCC may create compelling long-term economics.

At insufficient scale, overhead can be significant.

The company also carries the full risk of demand change.

---

VDC Economics

A VDC may combine:

• Persistent subscription or governance cost

• Outcome modules

• Specialist capability

• Platform and agent consumption

• Delivery Unit pricing

• Verification

• Internal ownership

The economics should increasingly connect to:

• Outcome

• Complexity

• Risk

• Speed

• Capability

• Verification

rather than only to the number of people assigned.

This can align incentives more closely with enterprise value.

It also requires clearer outcome design.

---

Part XIII: Comparing Exit Complexity

Exiting an ODC

The company may need to:

• Transfer knowledge

• Revoke access

• Transition systems

• Replace the team

• Resolve contract obligations

• Maintain service continuity

Exit can be difficult when the provider holds deep operational knowledge.

---

Exiting a GCC

A GCC exit is the most complex.

It may involve:

• Employees

• Legal entities

• Facilities

• Tax obligations

• Customers

• Reputational consequences

• Local regulations

• Leadership

• Knowledge transfer

A GCC should be created only when the company is prepared for durable commitment.

---

Exiting or Reconfiguring a VDC

A VDC should allow capabilities to be reduced or replaced without closing the complete execution environment.

An individual project may end.

A specialist may leave.

An agent may be retired.

A pod may be dissolved.

The persistent mandate may continue with a different composition.

If the entire VDC closes, the company still needs:

• Knowledge retention

• Access revocation

• Commercial closure

• Outcome transition

• Data handling

• Contributor offboarding

A VDC is not consequence-free.

It is structurally lighter than closing a permanent center.

---

Part XIV: When to Choose Each Model

Choose an ODC When

• You need a stable, dedicated offshore delivery team.

• The work is reasonably predictable.

• Roles and skills are well understood.

• You want provider-managed employment and infrastructure.

• You have strong internal product and execution leadership.

• Cost and talent access justify the offshore model.

• You are comfortable with a long-term provider relationship.

• The team will benefit from continuity.

---

Choose a GCC When

• The capability is strategic and permanent.

• The expected scale justifies institutional investment.

• Knowledge sovereignty matters deeply.

• You want direct control of leadership, culture, and careers.

• You intend to build a lasting enterprise presence in the location.

• The center can own important outcomes.

• Global talent development is part of the strategy.

• You are willing to carry long-term fixed cost and exit complexity.

---

Choose a VDC When

• The mandate persists but the capability mix changes.

• You need control without employing every contributor.

• Work crosses departments and organizational boundaries.

• AI agents and external specialists are part of delivery.

• You need faster activation than hiring or center setup allows.

• You want continuity without a permanently fixed team.

• The company can retain a clear internal outcome owner.

• Governance and verification can be defined.

• A GCC would be too heavy.

• A conventional ODC would be too workforce-centric or inflexible.

---

Part XV: The Models Can Coexist

A GCC Can Use VDCs

A large enterprise may maintain a strong GCC for:

• Core engineering

• Data

• Security

• Finance

• Product ownership

The GCC may then use VDCs to extend capability around:

• Temporary transformation programs

• Niche technologies

• Market expansion

• AI use cases

• Customer implementation surges

• Independent verification

The VDC does not replace the GCC.

It increases its reconfigurability.

---

An ODC Can Participate Inside a VDC

A VDC may include an ODC provider as one delivery source.

The provider may supply a stable engineering pod.

Other capabilities may come from:

• Internal employees

• Specialist partners

• AI agents

• Independent experts

The VDC becomes the broader governance and execution environment.

The ODC becomes one node inside it.

---

A VDC Can Precede a GCC

A company entering a new capability area may begin with a VDC.

This allows it to:

• Test demand

• Understand capability requirements

• Develop operating methods

• Build market knowledge

• Identify permanent leadership needs

If the work becomes strategic, large, and stable, the company may establish a GCC later.

The VDC becomes a learning and activation layer before institutional commitment.

---

A VDC Can Help Modernize an Existing ODC

An enterprise may not need to terminate its ODC.

It may redesign the relationship.

The ODC can remain the stable delivery base.

A VDC layer can introduce:

• Outcome orientation

• Specialist activation

• Agent governance

• Verification

• Cross-provider composition

• More dynamic capability management

The transition can be evolutionary rather than disruptive.

---

Part XVI: Common Misconceptions

“A VDC Is Just a Virtual ODC”

No.

An ODC is primarily a dedicated delivery-team structure.

A VDC is primarily a governed execution environment.

An ODC may exist inside a VDC.

The models operate at different levels.

---

“A GCC Always Gives More Control”

A GCC gives more direct organizational ownership.

But actual control depends on:

• Visibility

• Decision speed

• Leadership

• Governance

• Architecture

• Knowledge

A large internal organization can still become opaque.

Employment ownership is not the same as execution control.

---

“ODCs Are Only About Cheap Labour”

The best ODCs provide:

• Continuity

• Talent access

• Delivery maturity

• Domain capability

• Scale

Reducing the model to cheap labour ignores its real value.

However, labour-cost economics remain influential in many ODC relationships.

---

“VDCs Eliminate the Need for Permanent Teams”

They do not.

The enterprise needs a sovereign core.

Some capabilities should be hired into permanent roles.

The VDC extends the core.

It should not dissolve it.

---

“Virtual Means Unstructured”

A VDC should be more explicitly governed than many traditional delivery structures.

Because capability crosses organizational boundaries, the model needs precise:

• Identity

• Access

• Accountability

• Verification

• Conflict rules

• Decision rights

Virtual does not mean informal.

---

“GCCs Are Obsolete in the AI Era”

They are not.

A strong GCC may be one of the best places to build enterprise AI, data, engineering, and governance capabilities.

But the GCC must evolve from a workforce scale model into a high-leverage capability institution.

---

Part XVII: A Decision Framework for Leaders

Step 1: Define the mandate

What must the enterprise be able to deliver repeatedly?

Do not begin with a location or workforce number.

---

Step 2: Determine strategic permanence

Will this capability define the company for many years?

If yes, stronger enterprise ownership may be justified.

---

Step 3: Estimate scale

Does the expected long-term scale justify building a GCC?

Would a dedicated ODC be sufficient?

Is the demand too variable for either?

---

Step 4: Map capability variability

Will the required skills remain stable?

Or will they change significantly by quarter, product, customer, or technology cycle?

High variability strengthens the VDC case.

---

Step 5: Decide what must remain sovereign

Identify the capabilities, decisions, relationships, data, and knowledge that must remain inside the enterprise core.

---

Step 6: Assess internal leadership

Who owns the outcome?

No global delivery model compensates for missing institutional ownership.

---

Step 7: Include AI in the design

Do not estimate the future workforce using only today’s human delivery process.

Determine:

• Which tasks agents can perform

• Which decisions remain human

• Which verification is required

• How the human capability mix changes

---

Step 8: Compare total commitment

Include:

• Setup

• Payroll

• Provider margin

• Management

• Infrastructure

• Governance

• Rework

• Time to value

• Exit

• Human impact

The cheapest monthly rate may create the largest long-term commitment.

---

Step 9: Design the transition path

The answer does not need to remain static.

The company may move:

• From VDC to GCC

• From ODC to VDC

• From project outsourcing to ODC

• From GCC ownership to a hybrid structure

Design for evolution.

---

The Decision in One View

Choose an ODC when you need a stable, dedicated offshore team without building the full enterprise institution yourself.

Choose a GCC when the capability is strategic, permanent, large enough, and important enough to justify direct enterprise ownership.

Choose a VDC when the mandate is persistent but the human, machine, specialist, platform, and partner configuration must keep changing.

---

The Future Is Not One Center

The global enterprise of the future may not rely on one delivery model.

It may have:

• A permanent headquarters

• Several strategic GCCs

• Trusted ODC partners

• Multiple VDCs organized around execution mandates

• AI agents operating across all of them

• Specialist capability activated globally

The question is not which acronym will replace the others.

It is how the complete execution architecture works together.

This is the larger shift described in The Enterprise After Borders.

The company is no longer one workforce inside one boundary.

It is a governed network of owned, accessed, automated, and partner capabilities.

---

From Location Strategy to Execution Strategy

The ODC and GCC were born in an era when moving work required moving or establishing a workforce.

The VDC emerges in an era when capability can be activated without reproducing the entire organization around it.

That does not make location irrelevant.

Talent ecosystems still matter.

Culture matters.

Regulation matters.

Data residency matters.

Physical proximity matters.

But location strategy is becoming one component of execution strategy.

The enterprise must decide:

• What it owns

• What it accesses

• What it transfers

• What it automates

• What it composes

• What it keeps permanent

• What it allows to change

An ODC answers part of that question.

A GCC answers another.

A VDC answers a newer part.

---

Build the Structure the Work Deserves

An ODC can become a trusted, high-performing extension of the enterprise.

A GCC can become a strategic engine of innovation and institutional capability.

A VDC can provide adaptability, governance, and mixed human-agent execution without requiring permanent workforce ownership.

Each can succeed.

Each can fail.

An ODC fails when the provider relationship becomes more important than the outcome.

A GCC fails when institutional scale becomes inertia.

A VDC fails when flexibility is introduced without ownership, context, or governance.

The leadership task is not choosing the newest model.

It is aligning the structure with the work.

When the capability is stable and dedicated, an ODC may be right.

When it is strategic, permanent, and large, a GCC may be right.

When the mandate persists but the execution system must continuously recompose, a VDC may be right.

The future of global delivery will not be defined by whether the center is offshore, captive, or virtual.

It will be defined by whether the enterprise can turn global capability into verified outcomes without losing control, knowledge, adaptability, or time.

That is the real evolution.

From delivery centers built around where people sit—

to execution environments built around what the enterprise must make true.