A Few Lessons Learned for Project Managing VMware Enterprise-wide Virtualization Projects

A May 2008 engagement for a major pharmaceutical facility has ventured past the targeted project close date for reasons beyond our control.  And while virtualization undertakings are complex and necessitate quite a bit of planning among the client and service provider, many issues can be avoided from the onset: pre-sales technical support sessions and/or the post-contract proof of concept processes. 

This article is primarily based upon VMWare’s cutting-edge Virtual Desktop Infrastructure end-to-end solution, which to a large extent, has been pioneered by New Age Technologies and its Senior Consulting Engineers.  However, technical prowess and all the branches of the proverbial tree that come into play do not always equate to a smooth sailing endeavor.  Due to the nature of VDI’s reliance on redundancy (both virtual and physical) and other components that encompass a wide-array of technical architectures, these undertakings demand cohesive planning by the Service Provider and client. 

With this particular engagement, lessons learned documentation loomed as an ongoing process within the big picture.  In effect, these projects rely heavily upon client-vendor team building methodologies, where everyone should comprehend the ensuing (cost-saving) infrastructure makeover that serves as the foundation of the VDI model.  

The client-vendor project management team and upper management, along with the reporting procedures, need to be clearly defined.  Communication is especially vital for such complexities and to that end, all parties involved need to be cognizant of what will transpire.  Therefore, I have outlined some important items that need to be discussed and perhaps projectizedeither during the pre-sales cycle or infancy of the implementation itself.

·         Active Directory:  How does the client implement Active Directory within their environment?  These detailed questions and design considerations must be extensively explored at the very beginning of the project lifecycle.  If needed, the engineers must devise a detailed plan since VDI relies heavily on redirection to users’ folders et al.  Consequently, it may be disclosed that a separate AD project may occur in parallel with VDI or serve as a preamble to the consolidation and virtualization efforts.    A flat or poorly designed AD infrastructure may pose a rather limiting foundation for VDI initiatives. 

·          Upcoming medium or large-scale applications-based (non VMware) rollouts?  This is an equally vital topic to discuss. There may be a conflict of priorities on the client-side since IT staff might need to shift focus and responsibilities; thus, delaying the virtualization efforts.  We have also found that planning and executing a VDI project amid a large application rollout can be cumbersome, while often adding or altering the project scope/plan.  Issues such as hi-resolution display, and applications testing might toss a proverbial wrench in the works.   With our pharmaceutical client, this project in particular went thru many (after-the-fact) iterations, complete with all the delays and indecision that followed. 

·         Storage:  In some instances, IT directives are communicated towards certain staff.  During the presales technical dialogues it is imperative to talk about the client’s storage environment.  Virtualization configurations vary per SAN, i.e. direct attached or ISCSI, for example.  To that end, the client’s existing direct-attached storage architecture was to undergo a change to ISCSI; however, this information was not conveyed to us and we found ourselves assisting/consulting with the client and EMC immediately after contract signing.  This could have been avoided if the client had invited more than just a few IT personnel to attend the initial meetings and tech discussions.  In turn, we found ourselves working through a storage-ESX redesign shortly upon project commencement.   It is important that initial due diligence covers a broad spectrum of IT architectures prior to project kickoff.  And from a lessons learned perspective, I created a checklist for future engagements so both parties can cover all bases during the project development phase.   In addition, it is important to engage the client’s CTO’s and CIO.  No doubt, executive management needs to be in tune with the overall picture, whether it entails risks, or future IT initiatives/methodologies.

·          Does the Client use asset mgmt software and/or have an accurate inventory of the desktop environment?  For Virtual Desktop Integration, it is important to know how accurate the client’s desktop inventory is.  Are they old and outdated inventory spreadsheets, where a hefty portion of the user population has either left the company or moved to another department?  Our pharmaceutical client went through numerous iterations.  Data was roughly 70% accurate and at times, decelerated the project and affected targeted milestones.  

·         Authority/Communication/Structure:  Our client project-lead assumed very little authority and wasn’t able to focus; hence, an ongoing sequence of delays and shifts in strategy ensued.  When design issues arose, there was no semblance of structure.  War rooms where never instituted and existing applications slated for VDI templates were never tested.  Client-initiated, new technology testing was not documented as the list goes on.  And our client project manager frequently shot from the hip and was remiss with providing statuses or discussing risks and not adhering to the project plan.  In turn, situations of this ilk simply mushroom matters into heated free-for-alls.  It often evolves into problematic scenarios and can be difficult to address.  But to avoid major risks, and liabilities, we narrowed down our responsibilities into more of an onsite/remote staffing model due to an amendment in the contract.  Simply put, ineffective or inattentive project management can result in a disastrous situation.

Naturally, all complex projects require dedicated resources.  Yet, large VMware endeavors may warrant the buy-in of IT personnel, spanning Service Desk, Systems Engineering, WAN Engineering, Applications owners, Business Analysts and others, namely because the VMware methodologies touch cross-platform elements within the overall scope of execution.   It’s hard work upfront that makes things go easier at the end.  Nonetheless, these lessons learned and others not cited here, should prove to be a good resource for subsequent VDI projects.  Although the continual evolvement of technologies warrant project- centric adjustments and changes, which is a scenario that remains consistent as the IT industry frequently reinvents itself. 

-Glenn