VMware Rollout to 142 Sites Through Standardization

by | Feb 16, 2026 | 0 comments

VMware wasn’t the hard part — making the work repeatable was.

Virtualization was viewed as a major cost-savings opportunity.

But when I took over the program, the constraint wasn’t the platform.

The constraint was repeatability.

Each site proposal was essentially a custom job: custom equipment scope, custom pricing, and custom analysis to estimate savings. Even basic baseline questions—like what a site was paying for its current infrastructure—weren’t easy to answer consistently.

I was brought in to take ownership from an internal resource who was overloaded. The job was to take a real savings opportunity and make it executable at scale—across 142 manufacturing sites, with a portfolio that could have more than 20 projects moving at once.

A global program where standardization made the savings actionable.

Outcomes

  • Enabled deployment of VMware virtual computing platforms across 142 global manufacturing sites
  • Supported execution across a portfolio that included up to 23 simultaneous projects
  • Reduced lead time by ~50% by standardizing readiness, server acquisition, and deployment steps
  • Built a template-driven assessment that reduced site analysis time from weeks/months to minutes
  • Helped convert a savings thesis into an executable program (cited at ~$12M annual savings)

The problem

We were working with Hewlett-Packard as the equipment provider, but the program was operating in “one-off mode.”

Without standard packages or a consistent way to build the business case, every site assessment became a slow, bespoke effort. That slowed decisions, slowed procurement, and limited the program’s ability to scale.

What I did

I focused on building a simple engine: standard options + standard inputs + repeatable recommendation.

1) Standardized the offer with HP.

I worked with HP to understand the available product line and define a set of standard infrastructure packages that could be priced consistently. That gave sites clear options and made scoping and procurement faster.

2) Standardized the baseline using source data.

The next bottleneck was that “current state cost” wasn’t easy to see. I identified the system source for the existing infrastructure data and built a consistent export so we could understand what a site was effectively paying today—and what hardware/applications were in scope.

3) Built a template that turned analysis into a repeatable workflow.

I created a template that let me load the exported site data, identify in-scope assets, map the site to the appropriate standard package, and generate a savings estimate and recommendation in minutes instead of weeks.

4) Used that engine to scale decisions and implementation.

Once the analysis and recommendations were fast and consistent, the program gained traction quickly. Leadership could see the savings with less debate, sites could see what was being proposed and why, and implementation scaled across the network. Another program manager supported parts of deployment and sunset activity, while I continued driving the analysis-to-approval engine that kept the pipeline moving.

Why this mattered

This wasn’t a story about a tool rollout.

It was a story about turning a savings idea into a repeatable system.

Standard packages removed friction from scoping and pricing.

Standard inputs removed friction from baseline and savings estimates.

A repeatable template removed friction from decisions.

That’s what made it possible to scale across 142 manufacturing sites, manage a large active portfolio, and cut lead time by standardizing readiness, acquisition, and deployment.

Takeaway

Global rollouts don’t scale on effort. They scale on repeatability.

If every site needs a custom business case, you don’t have a rollout—you have a consulting exercise.

The playbook that worked here:

  • Standardize the offer (packages)
  • Standardize inputs (source data export)
  • Standardize the decision (template-based recommendation + savings)
  • Standardize execution (readiness + acquisition + deployment)

If you’re leading a multi-site rollout—IT or operations—my advice is simple:

Don’t start with the tool.

Start with the system that makes the tool deployable at scale.

0 Comments

Submit a Comment