By Kevin Lees published: Wednesday, January 23 2008
Solid project planning is a critical factor in successfully completing any IT infrastructure project. Given virtualization's technical nuances and relative newness to most organizations, the criticality of planning when undertaking a project involving virtualization is even more pronounced. In fact, a recent survey undertaken by The Strategic Counsel, under contract to Computer Associates, entitled "Global Server Virtualization Survey" found that 81% of organizations who evaluated their server virtualization deployments as successful performed detailed implementation planning.
With that said, planning is not necessarily an easy undertaking. One of the most frustrating aspects of Planning can be resource availability. As Tiana Conlon, a senior project manager at Foedus, LLC, points out, “Within the planning arena there are a myriad of challenges to overcome. Keeping the momentum going while continuing through daily operations is indeed the highest. If the project team ensures that there are dedicated resources from each of the respective departments and/or teams and that communication is frequent and well thought out, this process can go very smoothly.” During Planning, dedicated resources are more often than not an exception rather than the norm. To overcome this, the project manager needs to be extremely well organized and prepared so the precious little time you do have with the resources you need during planning is optimized.
Okay, so how do I proceed? Well, PMI’s project management lifecycle model again gives us something to work with vis-à-vis the Planning component. There are a LOT of processes defined in Planning. They are divided into the nine knowledge areas: Integration, Scope, Time, Cost, Quality, Human Resources, Communication, Risk, and Procurement. These knowledge areas aren’t exclusive to Planning as each, to varying degrees, is applied to Executing, Monitoring & Control, and Closing as well. While a full treatment of each area is beyond the scope of this article, I will describe the key components in each and offer pragmatic considerations relative to applying them within the context of a virtualization project
Integration
Integration, as the name implies, serves to bring together two or more of the other eight knowledge areas as they relate to a given project management lifecycle component. In the case of Planning, this results in the Project Management Plan. Now, I know what you’re thinking – oh no not documentation! I know this is an anathema to many but without it it’s difficult to have a shared understanding of key project processes and considerations among the project stakeholders. Like the mechanism for shared understanding in the Initiating component, the Project Overview Statement, the Project Management Plan does not need to be a tome; in fact, the shorter the better as far as I’m concerned. Think of it as the project playbook. At a minimum, it should contain information pertinent to each of the eight knowledge areas described below plus an executive summary.
Scope
The Scope knowledge area as it relates to Planning, involves three primary processes: Scope Planning, Scope Definition and Work Breakdown Structure creation.
While Scope Planning can be more involved for a large project, for those the size of a typical virtualization project, I focus in on describing the process for managing scope changes. Having an accepted process for reviewing and approving scope changes can save a lot of headaches (not to mention finger-pointing) later in the project. This needs to identify to whom scope changes are submitted as well as who decides if the change is within scope and, if outside of scope, who approves it.
Scope Definition, the way I approach it, is a drill-down of the Project Overview Statement (POS) created during Initiating. The “Effective Project Management” book I referenced in the first article of this series calls it the Project Definition Statement (PDS). The PDS expands the POS to a level where it can serve to communicate the project scope to the technical team. For instance it details the objectives, assumptions, constraints and deliverables to a degree where the project manager and technical team can create the Work Breakdown Structure, activities and activity duration estimates. In addition it describes deliverable acceptance criteria as well as how the project success criteria are to be verified.
The final piece of this knowledge area is Work Breakdown Structure (WBS) creation. This includes identifying project phases as well as successively decomposing the work to be completed. PMI calls the lowest level of the WBS a work package. A work package consists of those detailed activities required to complete this bit of work. Work package activity details are typically defined after the overall WBS has been completed and agreed to by the project team. A good rule of thumb for knowing when you’ve arrived at a work package is if that work package can be completed in a two week period (note that this heuristic may vary by project but is typically no longer than two weeks). If the work package requires more than two weeks, it should be decomposed further.
Relative to virtualization project scope specifically, one of the easiest areas to overlook is how virtualization may impact IT Operations. Usually obvious IT Operations’ processes like backup and restore are considered but following is a list of other processes that should be addressed:
Alert monitoring and troubleshooting – first, how are you going to monitor the virtualized additions to your IT infrastructure; secondly you may need to address your alert reaction procedures as now you will have a hypervisor, virtual machines and the underlying physical hardware to monitor and troubleshoot.
Patching and updating – with virtualization you may now have the opportunity to truly implement zero downtime patching and hardware updating!
Asset / Configuration Management – how are you going to track virtual machines and their configuration, or where the virtual machines reside, or do you even care?
Change Management – how are you going to deal with the potential for virtual machine sprawl?
Help Desk – any checklist(s) or troubleshooting procedures to modify?
Time
Time – projects never seem to have enough of it. The Planning aspect of the Time knowledge area involves identifying the: activities and activity details that comprise the work packages identified during the WBS development effort; activities’ sequence and dependencies; resources (human and other) required to affect the activities; activity durations; project milestones; overall project schedule; and project’s critical path of activities.
When addressing the Time knowledge area during the Planning component of your virtualization project, consider the following:
Your project team’s level of comfort with the virtualization product with which they will end up working. While simple virtualization implementations are relatively straightforward, to really get the most out of virtualization, virtual machine pairings and computer resource allocation decisions, for instance, can have a significant impact on virtual machine performance. Consider some focused training for members of your team.
If you plan to perform an assessment of your existing application / system environment (and I hope you are), allocate extra time for setting up your performance collection tool(s). You will undoubtedly run into system access issues and login issues. Also be sure to not only collect performance data over a long enough period of time but during peak usage times as well to help ensure an accurate assessment.
How you plan to migrate from physical systems to virtual machines. If you plan to use one of the applications on the market, be sure all of the systems involved in any given physical to virtual migration are connected via a high-speed network (at least 1Gb). If not, the amount of time to complete those activities will "go through the roof."
Include activities to create, test and accept virtual machine "golden templates." During their virtualization project, David Boone, Operating & Planning Manager at Denver Health, found a “Project Management advantage of reduced cycle time when bringing up virtual machines once you have a tested and accepted "golden template." This affected overall task durations. Once the physical infrastructure [was] in place, virtual machine deployment was rapid.”
Cost
Projects always have too much of it, at least according to the finance department. The Cost knowledge area aspect of Planning is concerned with Cost Estimating and Cost Budgeting. Cost Estimating involves estimating all of the costs associated with the identified project activities. Undertaking this at the lowest level or activity level is known as bottom-up estimating and typically results in the most accurate estimates. Cost Budgeting involves rolling all of the cost estimates up to an overall project cost. Once this overall project cost is reviewed and accepted by the powers-that-be, it becomes the project’s cost baseline against which ongoing project costs are compared.
The PMI methodology says that after the Cost Budgeting process is complete, management should allocate final project budgets. We all know how well that works, at least in the IT world. Typically, at least in my experience, the project budget has been "allocated" before serious project planning even begins. That’s not to say that you shouldn’t go back to management at this point to review their idea of the budget versus the overall project cost estimate arrived at through this exercise. You may be surprised and management may allocate more funds, if that’s what the estimate shows, but more likely you will have to determine how you can adjust the project to meet the budget; unfortunate, but more often than not a fact of life. To help address this conundrum, one approach to suggest to management is to allocate sufficient funds for an initial assessment phase. This approach results in significantly more accurate implementation planning and cost estimating – and considerably happier management in the end.
Consider the following when estimating costs for your virtualization project:
Verify OS and application licensing requirements – In 2005, Microsoft reworked its licensing to better accommodate virtualization. You might want to check out their Windows Server Virtualization Calculator here.
Verify 3rd party application licensing as well – remember, some vendors charge by the CPU core.
As mentioned under Time, your internal IT staff may need training to truly optimize your virtualization implementation. You may not have to charge this against the project. Furthermore, it may be a depreciable item (project-specific training often is) so be sure to check with the finance department.
Be sure to consider any extra SAN storage you might need to store the virtual machines.
You may be able to save some money by re-using existing hardware. Candidates should be identified during the Assessment phase but it is important to verify compatibility with the virtualization product you use. Also, don’t forget to verify the compatibility of system components such as Network Interface Cards and Fiber Channel Cards.
Human Resources
This knowledge area deals with Human Resource Planning. It identifies the Project Organization Chart, Roles & Responsibilities, and Staffing Management Plan. The primary purpose of the Project Organization Chart is to graphically display project reporting responsibilities. Roles & Responsibilities identifies the types of personnel required to satisfy the project activities. It defines what each role entails, level of authority, and skill requirements. The Staffing Management Plan addresses how these roles will be filled, any timeframe considerations, how team members are released (which may affect contracting if outside resources are used), and any training requirements.
Probably the biggest consideration here relative to a virtualization project is the Staff Management component. Do you plan to train internal staff, use vendor or third party services and rely on knowledge transfer, or some combination there of. I believe the decision on how to approach this is extremely important because truly realizing the full benefits of a virtualized environment requires, in my opinion, a deep understanding of a vendor’s virtualization product during implementation.
Quality
Quality Planning is concerned with establishing the guidelines for verifying that the project results satisfy the quality requirements of the project. In other words how do you determine if you fall short or even exceed the desired outcome of the project? You should identify any quality standards to be employed, what metrics will be collected, and record any quality checklists to be followed in order to ensure certain, required steps are taken.
Relative to a virtualization project:
Will you regression test your applications, especially any interfaces they have with other systems and/or applications?
Will you performance test your applications? There is overhead with virtualization. You should consider testing your migrated applications in a simulated operational environment (multiple virtual machines running on a physical server) as you may be able to optimize the virtual machine mix on a physical server and/or the resources granted to a virtual machine.
Consider measuring your current server performance and network infrastructure performance prior to virtualization. This gives you a point of comparison not only for possible further optimization of the virtualized environment but a measure of any improvements resulting from implementation of a virtualization solution to help quantify benefits to upper management.
Communication
The key purpose for Communication Planning is to identify the communication needs of the stakeholders. This should address the what, who, when and how for project communications. Will you need to produce a weekly progress report and monthly status report? To whom do you need to distribute it and how? Will there be a project web site on the intranet? How often will you hold progress meetings with your team and who needs to attend?
Communication Planning for a virtualization project is pretty much the same as for any IT project. Its importance for a virtualization project should not be underestimated, though. As previously mentioned, a virtualization project tends to have involvement from more teams within a business, so the communication channel complexity tends to be greater. One exception I do have specific to a virtualization project is to publish a glossary of virtualization terms so all project stakeholders have a common understanding when reviewing reports and participating in meetings.
Risk
The Risk knowledge area as it relates to Planning is concerned with risk identification, analysis and response planning. The primary manifestation of this is the risk register. The risk register contains the identified risks, their probability and impact factors based on analysis, what trigger(s) indicate that the risk event could occur, who owns the risk, and what the response to the risk should be. It’s also important to plan for periodic reviews of the documented risks to identify any new risks or changes to previously identified risks. A great reference for the whole area of IT risk management is “Identifying and Managing Project Risk” by Tom Kendrick.
In my opinion, next to Scope, the Risk knowledge area has the biggest impact on whether a virtualization project is successful or not. In the case of a virtualization project, it’s not the risk of whether the product you choose will not meet expectations (depending on the product chosen of course) but rather the technical and operational risks of implementing virtualization in your IT environment.
Following are areas to consider when assessing potential risks for your virtualization project and its ongoing operation:
Technical solution completeness – there are a significant number of architectural components to consider when virtualizing your environment.
Hardware compatibility – hardware compatibility issues with your virtualization product can lead to ugly surprises down the road in the project.
Interface support – not all virtualization products support all component interfaces. USB is a good case in point.
Internal team members' / external professional services’ level of experience.
Current applications’ conduciveness to virtualization – not all applications are good candidates for virtualization.
Application support in a virtualized environment – verify 3rd party support for their applications running in a virtual machine.
Virtualization product configuration best practices – if these aren’t well understood and followed you could end up with very unhappy end users.
Current environment configuration documentation – not having accurate configuration information on your current environment can add time to the assessment phase as well as lead to poor implementation decisions.
Current IT management processes & procedures – if these aren’t reviewed to assess the impact of virtualization, your project may be successful but on-going operations could suffer.
Virtual machine migration – tracking shared resources may become more important if you plan to migrate virtual machines between physical machines. CPU family and revisions may also come into play though upcoming features, like Intel’s VT FlexMigration, will address this over time.
Procurement
Procurement Planning addresses project purchasing and contracting. While actual purchasing and contracting typically fall into the domain of dedicated departments, a couple of items to consider when planning your purchases and contracts for a virtualization project include:
Does your vendor provide pre-configured systems certified as compatible with your virtualization product?
Do your application vendors support their product running in a virtualized environment? As David Boone of Denver Health pointed out, “You really have to work and negotiate with vendors more.” For their project, they told vendors, “You can't dictate to us what type of equipment we have to use to implement your solution. You give us your requirements and we'll meet those requirements; it shouldn't matter if it's standalone or virtual.”
In closing, the amount of time I’ve spent on Planning directly reflects how important I believe it is to the ultimate success of a virtualization project. Unfortunately, more often than not, in my experience, there is rarely sufficient time allocated to planning a project, much less one as potentially disruptive as a virtualization project. In my opinion, regardless of this it’s the project manager’s responsibility to ensure that planning happens. Many times it has to happen in parallel with execution. While unfortunate, it’s a fact of life that must be accommodated.
Part three of this series will address the Execution, Monitoring & Control, and Closing components of PMI’s project management lifecycle and how they’re affected by a virtualization project.
Kevin Lees
Kevin is the principal consultant at Premier Project Management, LLC, where he specializes in IT infrastructure architecture development as well as planning and managing IT infrastructure, virtualization, and data center consolidation/relocation projects. He is a Project Management Professional and VMware Certified Professional with 26+ years of technical, management, and consulting experience in systems integration, project management and IT operations. Recent engagements include performing an enterprise-wide IT Infrastructure & Operations assessment as well as planning and managing a multi-datacenter consolidation / relocation, using virtualization, in the publishing industry; managing the implementation and operational "go-live" of two e-mail platforms for an international e-mail ASP; and providing technical project management and virtualization services for the assessment phase of a multi-datacenter consolidation / relocation project in the on-line, e-mail marketing service provider space. Kevin can be reached at
kevin.lees@premier-pm.com.
