So in my previous blog, I talked about the need to set clear requirements at the start of the project lifecycle.  In that blog I began tackling the elephant in the room – let’s make “Virtualize the entire desktop estate” a project requirement.  I promised I’d return to it later, so let’s see if we can make that any clearer and make it an easier beast to discuss with the project sponsors!

Where do we begin with that statement?  Normally it comes down from C level executives as an expectation for the VDI project they have just agreed to, but on the way down to the IT teams it gains mystical properties!  “We must virtualize everybody’s desktops because <Insert Executive> says so!”  Personally I beg to differ and I spend a good proportion of my time discussing all the various nuances of the FlexCast model, and how they all have a purpose in most people’s organizations.   Taking a blanket approach to VDI projects is asking for unhappy users and failed projects.

So where do we start slicing up the FlexCast methods of delivery?  I like to start by working with specific user groups and understanding their application sets, so whilst mapping out the project plan we discuss a “Boilerplate” design which includes all delivery platforms to ensure we can have open discussions and define the best possible solution.  We define the expected technical requirements (See my previous blog) and then the next steps typically are as follows:

1)      Examine the desktop estate

  1. Application discovery should be undertaken to define application sets and user segments
  2. Based upon the application discovery and user segmentation outcomes, define application delivery mechanisms
  3. Define an application strategy which addresses all application sets and user groups
  4. Based on the application strategy, define an infrastructure capable of delivering all the various delivery platforms (XenApp, App-V Streaming, XenDesktop, Remote PC Access etc.)
  5. Define solutions for flexible working (Cloud Gateway, AppController, ShareFile, Podio etc.)

There’s a reasonable breakdown of what it takes to define a FlexCast model, but we’ve been making decisions based upon our understanding of what users do with their work time.  Thinking about the technical delivery mechanisms is fine, but it takes acceptance from the end users to make the project truly successful.  User engagement is critical to the success of any change project, and with the integration of Remote PC Access into the FlexCast model, we can take a staged approach to demonstrate to users the benefits associated with the new flexible IT solutions.  By deploying Remote PC Access initially to desktops and allowing users to work from home but on their existing PC, we enable them to learn one new thing at a time.  Once that is comfortable we could begin the process of migrating the PC into the datacentre – would you P2V the existing machine to the datacentre or build a new desktop?  This is something that needs serious discussion, and is dependent upon all kinds of factors (cost/scale, user acceptance etc.).

One of the best approaches I’ve come across is the idea of a “Demo Suite” in the organisation – the IT function creates a demo centre of all of the various models for user groups and allows department representatives to try out the technology.  With this being a truly “IT as a service” model, each type of deployment (thin clients, hybrid clients, tablets, BYOD etc.) can be demonstrated and a service cost attached to each method for the department.  Rather than IT deciding on the right strategy for the department, the department reps are buying (literally) into the process!  With a well-crafted solution it’s also easy enough to attach an “Upgrade” path if departments find they require a different style of technology later on down the path.  As an IT team behind the scenes we need to be building that flexibility in to the design, so capacities of each model can flex over time.  By ensuring that the IT service teams as a whole start to work together in this way, we can build an IT service which has the flexibility to change as differing demands are created across the business.

So back to the initial statement of “Virtualize the entire desktop estate” – have we addressed it correctly?  Well we still haven’t clarified what the executive sponsor might have meant by that, but we’ve definitely positioned the project to deliver on the vision.  It would also be a good idea to understand the primary drivers behind the move to virtualization – Mobility, Agility, Cost Reduction etc.  The more information gathered here, the more finessed the solution can be.  How do you guys handle these types of discussion?

The views expressed here are mine alone and have not been authorized by, and do not necessarily reflect the views of, Citrix.