On this page
The project existed because West was consolidating distributed telecom infrastructure into VMware on Cisco UCS. IVR had historically run near 1:1 on dedicated hardware because RTP timing and I/O latency directly affect call quality, and getting sizing wrong meant either millions in overprovisioning or insufficient capacity. Leadership needed a data-backed answer, and existing tooling didn't combine infrastructure telemetry with telecom workload analytics well enough to give one. The source summary is: Led the benchmarking work that decided whether latency-sensitive IVR telecom systems could safely move from dedicated hardware to VMware on Cisco UCS — a multi-million-dollar infrastructure call. The risk was specific: IVR/VoIP is latency-sensitive, and hypervisor contention can introduce jitter and packet loss that degrade live calls, so the question wasn't "can it run virtualized" but "at what density before call quality breaks.". The role was: Project owner and analytical lead — testing methodology, workload simulation, telemetry correlation, and the recommendation. Led large cross-functional teams across five departments (telecom, infrastructure/VMware, network, application, and QA engineering) plus executive stakeholders, directing the work and driving the decision **without direct reporting authority** over those teams. This was leadership by influence — aligning specialists who didn't report to me around one methodology and one recommendation, then preparing leadership for the architecture review. The work sat squarely inside the existing business, so the goal was never to add complexity for its own sake.
Operating flow
- Map the current system and the constraint first.
- Choose the smallest change that can hold the load.
- Build against the real workflow instead of a toy case.
- Roll it out with enough monitoring to catch the edge cases.
This series follows the build in the order it happened: discovery, the solution direction, the implementation steps, and the operational result. Each post stays on one decision or one build step so the reader can see how the system moved from the initial constraint to a working result.
The details come from the project files and the company context, not from a generic template. That keeps the story grounded in the mechanics of the work: what was built, what it replaced, and what changed when it shipped.
The implementation stayed close to VMware ESX/vSphere, Cisco UCS, SIP/RTP, Linux IVR platforms because the new system still had to live inside the same operating environment as the old one. That kept the work from drifting into a clean-room exercise that would look better on paper than it would in production. The practical question was always whether the implementation could hold up under the real workflow and the real users. If it could not do that, it was not finished.
The constraint behind the step was that West was consolidating distributed telecom infrastructure into VMware on Cisco UCS. That is why the work had to trade one kind of cost for another instead of trying to eliminate cost altogether. In almost every case, the useful move was to spend a little more effort on clarity, validation, or control so the business would spend less effort on repeated manual work later. That is the pattern the project files keep pointing to.
The role in the work was Project owner and analytical lead — testing methodology, workload simulation, telemetry correlation, and the recommendation. That meant the implementation could not stop at the code boundary because the operating model, handoff, and support path were part of the outcome. The relevant outcome was Supported enterprise approval of IVR virtualization across distributed datacenters and informed a multi-million-dollar modernization. The build only earns its place if the new result is visible in the way the business works after launch.
The specific step in this article was Led the benchmarking work that decided whether latency-sensitive IVR telecom systems could safely move from dedicated hardware to VMware on Cisco UCS — a multi-million-dollar infrastructure call. That is the piece that moves the story from analysis into execution. It is also the part that shows the difference between a conceptual fix and a system people can actually use. That distinction matters more than style or novelty.
The point is to show how the system works, not to turn the project into a slogan or a summary stub.
When the architecture changes, the real question is what the new system allows the business to do that the old one could not. That shows up here in throughput, reliability, operating cost, turnaround time, and how much manual work disappears once the workflow is redesigned.