I use a slightly different model when deploying virtual desktop solutions. The first and foremost phase is assessment and discovery. The focus should be on high-level strategy and business drivers during this phase. This is the most critical element since all future decisions will hinge on this analysis. Once all the requirements and expectations are defined, determining the best solution for your environment can proceed.
Once the base analysis is complete, the project moves to a design phase. During design, the results of analysis and business requirements are translated into a high-level technical architecture. This includes determining the hardware, software, and all infrastructure components. Once approved, this high-level architecture becomes the design plan.
During the build phase, all of the technology and infrastructure is put in place. This might include building out the data center presence or simply creating the VDI components on top of the existing infrastructure. Once a base build is complete, the environment is ready to test and validate.
The testing phase should include base functionality testing, capacity testing, application integration testing, and user acceptance testing. Testing results are used not only to validate functionality and performance, but also to validate scalability and design decisions. If testing reveals a change in the baseline, the design should be modified as well. Testing is an iterative process that must be repeated with each change to ensure optimal quality and project success.
In smaller environments, or when time is sensitive, the design, build, and testing phases can be consolidated into a single effort (building and testing while designing). However, this is risky and can sometimes lead to delays or overruns.
The pilot phase should be integrated as part of the overall project plan. This may be part of the testing and validation phase, or it may occur once the initial testing is complete. Successful pilot programs are phased in to increase server loads and user counts, and they should encompass multiple use case scenarios. A pilot should mimic production just on a smaller scale. Pilot testing results may lead to baseline or design changes, and subsequent testing cycles may be necessary. However, note that an extensive pilot program is critical to organizational acceptance and project success. You are better off identifying critical issues during a small pilot phase than during a major production rollout.
The last step, of course, is production rollout. Production rollout should be established in phases to keep support manageable as well as to monitor impact on the infrastructure and the overall system performance. An often overlooked key component to production rollout is communication. This includes setting management and end user expectations properly and user training. Open communication will also ease concerns users may have over the state of their desktop. The time spent properly communicating, or over communicating, is quickly recouped through reduced help desk calls.
The following diagram represents the iterative process of IT project management. Notice the weight on analysis as well as the iterative processes, check points, and the phased rollout:
Enhanced project methodology
Communication is critical not just for customer satisfaction, but also to manage the project as a whole, including identifying any changes in scope, timelines, and budget. There are six key factors to ensure your project is successful, which are:
Managing the scope (what is being done)
Managing the schedule (timelines)
Managing the budget (avoiding cost overruns)
Ensuring quality (everything works as planned)
Managing risk factors (avoiding the big pitfalls)
Ensuring customer satisfaction (did you meet the project goals)
The following figure represents the six components for successful project management:
Project management components
Customer satisfaction is critical. This is often overlooked in the IT world as our customers are commonly our coworkers. I was involved in one project that was on time, on budget, and worked. However, the project was a failure because the end users were never properly assessed and what was delivered was not what was needed or wanted.
According to a 2012 survey by McKinsey & Company of large IT projects:
45 percent go over budget
7 percent go over time
56 percent deliver less value
17 percent fail so miserably that they threaten the company's existence