Many of the shorter term / highest pressure engagements the Consulting teams get involved with are projects which are in the middle of a death spiral. Consulting are typically called in to attempt a rescue – superhero style – because the usage of the technology is failing to achieve on expectations. Whilst on most occasions there are some amazing things the team can do to work with the salvage, these are often temporary measures to achieve stability so the project can refocus from fire-fighting to build/develop phases.
The key word in all of that paragraph was “Expectations” – many projects begin with a set of expectations which clearly aren’t fully defined and are regularly not measurable. If it’s not measurable in some way, by definition it’s impossible to achieve (Well I suppose you could equally say it’s also impossible to fail!). The Citrix Consulting Methodology has been around for ages and we stick to it with good reason.
A common problem is diving straight from proof of concept directly into implementing a pilot. In the Consulting methodology, proof of concept environments are generally hastily put together with minimum requirements to test if the overall concept is likely to work. During the POC stage we would want to capture further requirements and define success criteria, along with looking for improvements in the planning. Those details all combine to allow us to create a complete design for the solution which can eventually be taken into the pilot stage. Without the requirement gathering stage, the design is essentially a boilerplate design which eventually leads to the environment being designed around the technology stack, rather than around expected functionality.
Defining a clear set of requirements at the outset of any project is a key element in any successful deployment. All too often I see projects where the requirements look a bit like this:
1) Virtualize the entire desktop estate into a single image solution
2) Improve logon times
3) No disruption to the existing environment
4) Work from home capability
Which sounds like a very competent copy/pasta chef has been examining the marketing slides from a recent trade show! Each of those things needs to be examined, extrapolated and the measurable outcomes clearly defined. For example:
1) Improve logon times
- Current logon times vary from between 90 seconds and 8 minutes
- Target logon times of less than 60 seconds
- Logon time will be defined as time from user connecting to their desktop and <Insert Application> being available for use
So we clearly know what the target to be achieved is, and we can design a solution which delivers the required improvements. For those of you paying close attention, you will have noticed I clearly missed out the first item on the list to use as an example… I often see this as a “Project Driver” with no clear definition of what is expected, but it’s such an enormous elephant in the room that everyone carefully ignores it in the hope that it goes away! Once we start to define what that might look like as a set of specifics, it might start to look a bit like:
1) Virtualize the entire desktop estate
- Application discovery should be undertaken to define application sets and user segments
- Based upon the application discovery and user segmentation outcomes, define application delivery mechanisms
- Define an application strategy which addresses all application sets and user groups
- Based on the application strategy, define a FlexCast infrastructure capable of delivering all the various delivery platforms (XenApp, App-V, XenDesktop, RemotePC etc)
Defining this driver is in everyone’s interest – generally this driver is signalled by a C level executive and passed down from on high as a strategic direction. What happens next defines how well the project is likely to go – either the solutions teams make a set of assumptions and hope for the best, or they break it down into the component parts and attempt to clarify the requirements before moving into any design stage. Clearly this is going to go beyond the scope of this blog, but it’s a huge area that needs discussion with the project sponsors. Without very strict clarity around these areas, it’s impossible to define any criteria other than some very basic “Get the OS virtualized” or “Put Cloud Gateway in to provide mobile access”. I’ll attempt to address this in a later blog, but for now feel free to comment on how you’ve managed to define that in your experiences below. I’ll come back to it again in a later blog.
So back to the start – why do projects wind up in what appears to be a death spiral, and what do we do once it’s all stabilised? We return to the requirements and ensure we get them as clear as is humanly possible. Once we have the requirements clear (and agreed), the perfect next step is to revisit the design and examine where the weaknesses are compared to what the newly clarified expectations are. Generally once that dialogue is re-opened it’s not too difficult to salvage and improve the project, which makes us all look like heroes!
The views expressed here are mine alone and have not been authorized by, and do not necessarily reflect the views of, Citrix.