Manage Learn to apply best practices and optimize your operations.

A CTO reflects on VDI implementation trials and errors

CTO Niel Nickolaisen reflects back on the reasons some of his VDI implementations never made it past the experimentation stage.

I have dreamed of and hoped for the promise of desktop virtualization (VDI). It all sounds so good: the ability to deliver a personalized end computing experience independent of location and device; the ability to simplify and improve end computing support; a way to reduce operating costs; and a way to get out of the device management business.

Niel NickolaisenNiel Nickolaisen

The promise is compelling. As a result, I have experimented with virtual desktop infrastructure (VDI). Sometimes, my experiments succeeded. Other times, they never advanced beyond experimentation. What was the difference? As I reflect back on my VDI implementation successes and failures, this is what I have learned:

The business case is exciting but ambiguous. There are hard dollar costs and benefits but those are sometimes dwarfed by the more nebulous costs, benefits and considerations. For example, what are the customer's expectations of the experience? Do they expect that all enterprise technology is available on their device? Or merely a subset? If we need to deliver the entire portfolio of applications, it can be a challenge because some apps are not designed for the VDI experience.

To do my experiments, I convince the technology providers to let me borrow their products for the duration of the experiment.

Also, we have to worry about bandwidth consumption and latency. Can our remote users enjoy a solid experience given the inherent latency and bottlenecks of the available connections? Sometimes the organizational culture simply is not ready for VDI. Most everyone expects a high-powered device on which they can do any and all things. To take that away is an act of sabotage in their lives (and they will punish the person who did it). Sometimes, even with a solid hard and soft business case, VDI is simply not a priority given the other pressing IT needs. If our VDI experiment has gone on for months without progress, it could be that it's a good but not high-priority project.

VDI implementation: If at first you don't succeed

The technology ripple effects can be significant. If we are supporting remote VDI users, we need to think about the quality of the connection. VDI shifts the compute power away from the device and toward distant compute power. One bottleneck in this shift is the connection. If someone in a remote location types a word and the letters appear on the screen in anything more than about a nanosecond, we will be buried in complaints. As a result, some remote users are not VDI-able and we end up with a hybrid model. Another bottleneck might be our distant compute power. The processing that was done on the device now needs to happen somewhere else. That somewhere else must have the capacity to handle the workloads.

The only way I have found to determine whether or not VDI makes sense, delivers a solid return and is a priority is to try it out. And, this cannot be a half-effort try. We have to commit the resources and acquire the technology and make it a priority -- just on a small scale. My best VDI experiments have been with small but cross-functional groups of customers. What works for the customer service team might not work for the finance group and so my experiment should include both groups. Same for local and remote users.

More of Neil Nickolaisen's tips

10 steps to IT transformation

Rolling out a mission-critical app the right way

Core ITSM principles keep pace with tech pace of change

To do my experiments, I convince the technology providers to let me borrow their products for the duration of the experiment. They usually grouse about this but eventually accede to my request. We then do a real -- but small -- VDI implementation and measure the results, impact and experience of the pilot group. We then extrapolate the results across the organization and decide whether or not to expand the implementation.

If the experiment indicates that VDI is not a good solution, plan on repeating the experiment at least once a year -- the technology changes all the time as do customer expectations. The next experiment might indicate it is time to expand the experiment to a full implementation. Using this trial approach has saved me lots of heartache and pain and also resulted in some extremely successful VDI implementations.

About the author:
Niel Nickolaisen is CTO at O.C. Tanner Co., a Salt Lake City-based human resources consulting company that designs and implements employee recognition programs. A frequent writer and speaker on transforming IT and IT leadership, Niel holds an M.S. degree in engineering from MIT, as well as an MBA degree and a B.S. degree in physics from Utah State University. You can contact Niel at

Dig Deeper on Enterprise systems management

Join the conversation


Send me notifications when other members comment.

Please create a username to comment.

What has led to your company's VDI successes versus failures?
Our VDI success came from a trial run delivered to our heaviest RDP users. Toward the end of the trial they were sold and after demonstrating the 30-seconds the solution allowed us to rebuild a broken VM for a user in the event of an issue management and IT were fully sold. We're now 18-mths into our VDI deployment and soon 75% of all system will be replaced by it.