How to Build a Virtual Delivery Center: A Practical Playbook

A Virtual Delivery Center sounds much bigger than it needs to be.

When people first hear the idea, they sometimes imagine a large transformation program. They picture a new operating model, new governance, new contracts, new technology, new dashboards, and perhaps a consulting team explaining the whole thing for six months.

That is not how I would start.

I would start with one piece of work that is already hurting.

Maybe customers are taking too long to go live. Maybe engineering has a backlog that keeps growing. Maybe an AI initiative has been stuck in pilot mode for nine months. Maybe a compliance team knows what needs to be fixed but cannot get the right people together long enough to do it.

That is enough.

You do not need to redesign the company. You need to take one important outcome that is not moving properly and build a better execution system around it.

That system can become the first VDC.

Start with the pain, not with the VDC

Imagine a SaaS company that has done well selling to enterprise customers.

Sales is happy because deals are getting signed. The problem begins immediately after the signature.

Every new customer needs integration work, configuration, security reviews, data migration, training, testing, and a surprising amount of handholding. What was sold as a six-week implementation often takes ten or twelve weeks.

The implementation team is tired. Engineering keeps getting pulled away from the product roadmap. Customer success spends too much time chasing internal teams for answers.

Leadership looks at the problem and sees three familiar choices.

They can hire more people. They can outsource the work. Or they can tell the current teams to become more efficient and hope things improve.

None of these choices is necessarily wrong. But before making any of them, I would ask a simpler question.

What exactly are we trying to make better?

The answer should not be "increase implementation capacity." That is still too vague.

A better answer might be that enterprise customers should reach production within thirty days, without lowering security, quality, or customer satisfaction.

Now we have something to work with.

That sentence is much more useful than a request for eight implementation engineers.

Do not start by asking how many people you need

This is one of the habits that is hardest to break.

A problem appears, and almost immediately we turn it into headcount. We say we need two architects, four developers, one QA engineer, and a project manager.

Sometimes that is exactly what we need. But we should arrive there after understanding the work, not before.

Take our customer implementation example.

A new implementation may need deep integration expertise for the first week. It may need a security specialist for only a few hours. Data migration could become heavy for three days and then disappear.

Documentation may happen throughout the project. Testing may be mostly automated. Customer communication may require a senior person even though it takes much less time than the technical work.

If you hire a permanent team around the busiest possible version of every implementation, you will probably end up with too much capacity in some areas and not enough in others.

This is where the VDC idea starts becoming practical.

You keep the mandate stable. You allow the capability mix to move.

Decide what the VDC is actually responsible for

The first useful document for a VDC does not need to be sophisticated.

It should simply explain what this VDC exists to deliver, where its responsibility begins, and where it ends. Everyone involved should be able to read it and understand the same thing.

For our example, the VDC might exist to take an enterprise customer from signed contract to successful production use.

That is a meaningful boundary.

It does not own the product roadmap. It does not own the sales relationship before the contract. It does not own long-term account management after the customer has stabilized.

It owns implementation.

Even that word may need more detail.

Does implementation end when the software is deployed, or when the customer has actually started using it? Does it include user training? Does it include data validation?

These questions may feel basic, but they are where a surprising amount of execution confusion begins.

A VDC becomes useful only when people know what it is there to make true.

Keep an internal owner

The VDC should have one clear internal owner.

This person does not have to manage every contributor directly. In fact, if the VDC is working properly, they probably should not.

Their job is to own the outcome from the company's side.

For the implementation VDC, this may be a VP of Customer Success, Head of Implementation, COO, or another senior leader. The title matters less than the authority.

They should be able to resolve priority conflicts, make trade-offs, bring internal teams into the conversation, and accept the final outcome.

This point matters because external capability can easily create a strange vacuum.

A provider thinks the customer owns the decision. The customer thinks the provider owns delivery. Engineering thinks customer success should decide. Customer success thinks product should decide.

The VDC needs someone who can say, "This is our outcome, and I own it."

That sentence removes a lot of confusion.

Decide what must stay inside the company

The next question is not what you can outsource.

It is what you should not give away.

Every company has a small set of capabilities, relationships, and decisions that should stay close to the core. In our SaaS example, customer ownership probably belongs there.

Product architecture may also belong there. Security policy, customer commitments, pricing decisions, and final acceptance may stay internal too.

This does not mean employees have to perform every task.

An external integration specialist may do most of the technical work. An AI agent may prepare documentation. A delivery pod may manage migration activities.

But the company should know which parts of the work still require its own judgment.

I think of this as the sovereign core.

We discussed the same idea in The Enterprise After Borders. The company should own what defines it, govern what affects it, and deliberately access the rest.

A VDC works best when that internal core is small, clear, and confident.

Map the work before you map the people

Once the outcome is clear, sit down with the people who actually understand the work.

Do not begin by discussing job titles. Walk through what really happens from the moment the customer signs until they are successfully live.

You may find that the process looks something like this.

First, someone has to understand the customer's current environment. Then integration decisions need to be made, data has to be prepared, security questions have to be answered, configuration has to be completed, and testing has to happen.

After that, somebody needs to train users, handle exceptions, prepare the production move, and verify that everything actually works.

You will probably notice something immediately.

These pieces need very different capabilities.

That is the point.

The real execution system was never "eight implementation engineers." It was always a changing combination of discovery, architecture, data, security, testing, communication, and customer judgment.

The old team structure simply hid that complexity.

Separate what is constant from what is occasional

Now look at those capabilities and ask which ones you need all the time.

Customer ownership may be constant. Implementation coordination may be constant. A product architect may need to stay involved across nearly every customer.

Other needs may appear only occasionally.

A specialist who understands a certain ERP system may be needed for one customer this month and not again for six months. A penetration-testing expert may join for a very specific stage.

That difference should affect how you source the capability.

The constant pieces may belong with employees or long-term members of the VDC. The occasional pieces can come from specialists, delivery pods, partner firms, AI agents, or software.

This is why the idea from Work Is Episodic. Why Are Teams Permanent? matters so much.

The work does not arrive in neat, permanent quantities.

Your execution model should admit that.

Look for work that should not require a person at all

This is where AI needs to enter the conversation naturally.

Do not create an AI workstream. Do not ask the team to "find some AI use cases" because leadership wants an AI story.

Look at the actual implementation flow and ask where people are doing repetitive work that machines can handle reasonably well.

Maybe customer discovery calls can be summarized automatically. Maybe missing information can be detected before a project manager notices it.

Maybe an agent can compare data mappings, generate configuration documentation, run standard test cases, prepare status summaries, or monitor whether dependencies are slipping.

The goal is not to remove humans.

The goal is to stop wasting human attention on work where human attention adds very little.

We looked at this more deeply in How AI Agents Fit Inside a Virtual Delivery Center. Inside a VDC, an agent should be treated as another capability with a clear purpose, owner, access boundary, and verification method.

That makes AI useful without turning it into a separate religion.

Build the smallest VDC that can deliver one real outcome

This is where many organizations make the first big mistake.

Once the idea feels promising, they start designing the complete model.

They want every governance rule. Every integration. Every talent category. Every pricing mechanism. Every dashboard.

I would avoid that.

Build enough VDC to successfully deliver one real outcome.

For our SaaS company, choose one customer implementation that matters but will not destroy the company if the experiment is imperfect.

Pick a real customer, not a fake internal exercise.

That matters because real work exposes the things presentations never show.

The customer changes requirements. A credential does not arrive. Security rejects an integration pattern. Somebody assumed a data field existed and it does not.

That is where you learn whether your VDC actually works.

The first VDC does not need a big team

You may discover that the first implementation VDC needs only a few stable people.

Perhaps there is one internal implementation owner, one product architect, and one customer success lead. Around them, the VDC brings in an integration pod, a data specialist for part of the work, and a security reviewer when required.

A couple of agents handle documentation and repetitive validation.

That is already a VDC.

You do not need fifty people.

You do not need a new legal entity.

You do not need an offshore office.

You do not even need every part of the eventual commercial model figured out.

You need a governed execution environment around the outcome.

Use the customer's existing tools wherever possible

This is another place where I would resist building too much too early.

The customer already works somewhere.

Their engineering work may live in Jira and GitHub. Their teams may communicate in Slack or Microsoft Teams.

Their support workflow may live in ServiceNow. Their customer records may live in Salesforce.

The VDC should work with that reality.

If the first thing you do is ask everyone to move into a completely new project-management system, you have added one more layer before you have delivered any value.

Let the work happen where the company already operates.

The VDC layer should help with composition, access, governance, continuity, economics, and verification.

It does not have to replace every tool people already use.

Be very careful with access

The moment external people and agents enter the execution system, security becomes real.

This is where many companies get nervous, and they are right to be nervous.

But I do not think the answer is to avoid external capability altogether.

The better answer is narrower access.

The integration specialist should see what they need for the integration. The data specialist should see the required data and no more.

The AI agent should access only the information required for its purpose.

Temporary access should expire.

Production access should be treated very differently from development or test access.

This was the heart of VDC Governance: Borderless Execution Without Losing Control. Employment should not be the only thing deciding trust.

Purpose should decide access.

Do not make governance bigger than the work

Security matters, but there is another failure mode.

The company becomes so afraid of doing something new that it creates a governance monster.

Every small action needs approval. Every specialist needs twelve forms. Every low-risk agent goes through the same process as a system touching regulated production data.

People stop using the model because it is simply easier to go back to the old way.

Governance needs to match risk.

A public research task should be easy. A production database change should be difficult.

That sounds obvious, but large organizations often struggle to make those distinctions.

A good VDC should make safe work faster, not make all work equally slow.

Decide how you will know the work is done

Before the first module begins, agree on what completion means.

This does not need to become a legal battle over every sentence.

For example, a data migration might be considered complete when the agreed records have been moved, reconciliation is within tolerance, critical errors are resolved, and the customer accepts the result.

That is already much better than saying "data migration effort, eighty hours."

The team knows the finish line.

The customer knows the finish line.

The provider knows the finish line.

This is also why we moved in Beyond Story Points and Timesheets: How Should Delivered Work Be Measured? toward the idea of a verified change in state.

The VDC should care about what became true.

Keep pricing simple in the beginning

There is no need to solve the future economics of work before the first VDC delivers anything.

Some parts can still be time and material.

That may actually be the most sensible approach for uncertain discovery work or specialist involvement.

Other modules can have a fixed price when the boundary is clear.

The VDC itself may eventually have a recurring fee because the persistent environment has value. Context, governance, access structures, integrations, and continuity do not disappear after one module ends.

But start with economics people can understand.

The bigger change can happen gradually as delivery history accumulates.

When you have completed twenty similar implementation modules, you know much more about what they actually cost.

Then pricing becomes smarter.

Watch the first implementation very closely

The first VDC is not only delivering customer work.

It is teaching you how the VDC should operate.

Watch where decisions get stuck.

Watch where people wait.

Watch where access takes too long.

Watch which specialist arrived too late.

Watch where an agent was genuinely useful and where it simply created more checking.

You are looking for friction.

Not to blame anyone.

You are trying to understand where the execution system is weak.

This is one of the biggest differences between building a VDC and simply assembling a project team.

The first project team is judged on whether it finishes.

The first VDC should finish and also leave behind a better execution system for the next outcome.

Keep what worked

After the first implementation, do not dismantle everything.

Some things should remain.

The customer implementation playbook may remain. The access model may remain. The useful agents may remain.

The relationship with a good specialist should remain too.

Maybe the integration pod now understands your product well enough that the next customer starts much faster.

The decision history matters as well.

You may now know that a certain security pattern is acceptable. You may know which questions customers repeatedly ask.

That knowledge is valuable.

It is what turns a temporary project into a persistent VDC.

Fix what did not work without being defensive

Something will fail.

Maybe the external specialist was technically good but poor with customers. Maybe the AI documentation agent produced polished rubbish because it lacked product context.

Maybe internal engineering became the bottleneck because too many decisions still required one architect.

Good.

You found the problem.

Do not turn the VDC into a doctrine that has to be defended.

Change the design.

If a capability should have been internal, bring it closer.

If an agent created more review work than it saved, remove it.

If a delivery partner became too distant from the customer, change the communication model.

The VDC should be allowed to learn.

That is one of its biggest advantages.

Recomposition is not failure

Traditional organizations sometimes treat changing the team as a sign that something went wrong.

In a VDC, the ability to change the capability mix is part of the design.

Perhaps the first few customers required heavy data migration expertise. Six months later, the product has improved and that need has almost disappeared.

Good.

Remove the extra capacity.

Maybe customers now need much more security support because you have entered a regulated market.

Add that capability.

Maybe a new AI agent can do work that previously required a junior engineer.

Use it if the economics and quality make sense.

The VDC should move with the work.

That is the point.

Do not change people just because you can

There is a danger on the other side.

A flexible model can become too fluid.

If every project brings a completely new group of people, context disappears. Relationships become shallow. Customers keep repeating themselves.

Trust never has time to form.

A good VDC should keep continuity where continuity matters.

If an external specialist has become deeply familiar with the product and performs well, there is real value in bringing them back.

If a delivery pod has built a good working relationship with the internal team, that relationship should compound.

Flexibility is not the same as randomness.

The best VDC probably has a stable center and a flexible edge.

Give people a reason to care about the VDC

This part is easy to underestimate.

Employees may initially see the VDC as a threat.

They may hear "external capability" and think the company is trying to replace them.

External specialists may see it as just another gig.

Managers may feel that they are losing control because fewer people report directly to them.

If those fears are ignored, the model can fail even if the architecture is sound.

People need to understand what the VDC is trying to fix.

Maybe internal engineering is tired of being dragged into every implementation. The VDC can protect their focus.

Maybe implementation managers spend half their lives chasing specialists. The VDC can give them a reliable capability network.

Maybe experts want interesting work without joining another full-time job.

The VDC should create something useful for all of them.

Otherwise it becomes another operating model imposed from above.

The internal team should become more important, not less

A strange thing happens when external and machine capability increases.

The internal core can become smaller, but the people inside it become more important.

They carry the company's context.

They know the customers.

They make judgment calls.

They understand the product history.

They decide what should never be compromised.

This is why I would not frame the VDC as a way to reduce employees.

It is a way to stop using employment as the only mechanism for getting work done.

Those are very different ideas.

A company may end up hiring fewer people in some areas.

It may hire more in others.

The better question is whether the people it employs are spending their time on work that truly needs to belong inside.

Let managers become outcome owners

A VDC can be uncomfortable for managers whose authority has always been connected to team size.

If someone managed forty people before and now works with eight employees, several specialists, and a network of agents, what does management mean?

It should mean more than headcount.

The manager becomes responsible for the execution system.

They need to know whether the right capabilities are present, whether decisions are moving, whether dependencies are being cleared, and whether quality is holding.

They also need to know when the system should change.

That is a harder job than approving timesheets.

It is probably a more valuable one.

Do not move everything into VDCs

Once a new model starts working, enthusiasm can become dangerous.

Some leaders will want to turn every function into a VDC.

I would not.

Some work belongs in a stable permanent team.

Some functions are mature enough to outsource completely.

Some capabilities belong in a GCC.

Some things simply do not need much change.

The VDC is most useful where the mandate is important and persistent, but the capability required to deliver it changes over time.

That is the sweet spot.

We made the same distinction in VDC vs Outsourcing vs Hiring and VDC vs ODC vs GCC.

Use the model where it fits.

A second VDC should be easier than the first

This is one way to know the system is improving.

After the customer implementation VDC works, perhaps the company decides to create an AI modernization VDC.

The mandate is completely different.

The capabilities will be different too.

But you should not be starting from zero.

You already know how identity works. You have legal structures. You understand how specialists are activated.

You have learned how access expires. You know how execution remains inside the customer's tools. You have a better idea of how modules can be verified.

That reusable operating layer is where the platform value begins.

The company is not only becoming better at one implementation problem.

It is becoming better at assembling execution.

Eventually, the VDC becomes boring

I mean that in a good way.

Nobody celebrates when a company creates a project team.

It is normal.

Nobody holds a strategy meeting because someone created a Slack channel.

It is just infrastructure.

A mature VDC should eventually feel similar.

A business leader has an outcome.

The company decides it should not build a permanent team around the whole thing.

A VDC already exists, or a new one can be formed quickly.

The right internal owners are attached.

Capabilities are activated.

Access is granted.

Work begins.

People should not have to spend weeks discussing the operating model every time.

When the VDC becomes boring, it has become infrastructure.

You will know it is working when the conversation changes

The biggest signal may not appear on a dashboard.

Listen to how people talk.

Before the VDC, the conversation may sound like this.

"We need five more people."

"Can procurement find us another vendor?"

"Engineering does not have capacity."

"This will have to wait until next quarter."

After the VDC matures, the questions should become different.

"What outcome are we trying to deliver?"

"Which capability is missing?"

"Does this need to be permanent?"

"Can an agent handle part of it?"

"Who should own the decision?"

"How will we verify completion?"

That is a much healthier conversation.

The company is thinking about execution instead of automatically thinking about organizational expansion.

A VDC should become a memory of how the company gets work done

This may be one of the most important long-term effects.

Every completed module teaches the company something.

It learns which specialists were good. It learns which capabilities repeatedly appear together.

It learns where customers get stuck.

It learns which work can be automated.

It learns which risks are routinely underestimated.

It learns how long certain decisions really take.

Over time, this becomes execution memory.

The next outcome starts with more knowledge than the last one.

That is difficult to achieve when every project creates a temporary team, performs the work, and dissolves with most of the context still living inside people's heads.

A VDC should remember.

You do not build the VDC once

There is no point where someone says, "The VDC is finished."

The VDC will keep changing because the work keeps changing.

The product changes. Customers change. AI changes. Regulations change.

People leave.

New specialists become available.

Old capabilities stop being scarce.

The job is not to freeze the perfect structure.

The job is to create an environment that can change without losing its memory, governance, or responsibility.

That is the real architecture.

A simple way to begin tomorrow

If I were sitting with a leadership team tomorrow morning, I would not start with a VDC workshop.

I would ask them to bring one outcome that has been painful for the last six months.

Something important enough that everyone knows it needs to improve.

Then we would spend time understanding why it is slow.

Which capabilities are missing?

Which permanent people are overloaded?

Where does work wait?

Which specialist is needed only occasionally?

Which repetitive parts could be handled by agents or software?

Who truly owns the outcome?

What should never leave the company?

By the end of that conversation, the shape of the VDC would begin to appear naturally.

Not because we forced a model onto the business.

Because the work told us what structure it needed.

Do not begin by building a VDC

That is perhaps the strange conclusion to an article about how to build one.

Do not begin with the VDC.

Begin with the thing your company is struggling to get done.

Understand it properly.

Keep the parts that need deep company ownership close.

Bring in capability where it is missing.

Let machines handle the work machines are good at.

Give people clear responsibility.

Keep access narrow.

Make completion visible.

Learn from every delivery.

Preserve the context.

Then do it again.

At some point, you will look around and realize that you did build a VDC.

It just did not arrive as a transformation program.

It grew around real work.

That is probably how it should happen.

Companies rarely become better because someone invented a more impressive org chart.

They become better because they find a more reliable way to turn an important intention into something real.

The Virtual Delivery Center is simply one way to make that happen.