By Kevin Lees
published: Wednesday, March 12 2008
Ok, so far I’ve covered considerations to take into account during the Initiating
and Planning components of PMI’s project management lifecycle in the context
of a virtualization project. In this, the final installment of the PMP’n Virtualization
series, I’ll address the final three components of the lifecycle: Executing,
Monitoring & Controlling, and Closing. Fortunately, virtualization’s affect on
these three components differs little from the considerations that should be taken
during any IT project of reasonable complexity. That said there are aspects of
these three components worth reinforcing and amplifying as they relate to a
virtualization project.
Executing
During Planning you planned the work to be completed for the virtualization
project. The Executing component focuses on work results. According to PMI,
Executing includes: directing and managing project execution; performing quality
assurance; acquiring and developing the project team; distributing information;
requesting potential supplier responses and selecting suppliers. While in no way
meaning to diminish the importance of any of these processes, I want to explicitly
call out aspects of a couple requiring further attention in a virtualization project.
First, directing and managing project execution – my friend Tiana Conlon of
Foedus, LLC put it well: “Timing and communication are key elements to the
successful execution of a virtualization project.” In order to fully realize all of the
benefits of virtualization its impact can be far reaching. It can touch business,
operations and, of course, IT. Thus the dependencies, coordination and, hence,
required communication can be extensive. Particular attention must be paid to
the affected dependencies between, and impact on, business processes, inprogress
programs, and departmental schedules. The timing and coordination of
tasks with these non-project activities should be accounted for during planning
but as all of us know, execution doesn’t always have the luxury of following the
initial plan – unknowns occur despite the best laid plans. As a result, ongoing
communication with all IT and non-IT stakeholders is critical during execution to
ensure close coordination and to mitigate the risk of unintended consequences.
Second, developing the project team – do you train internal resources, outsource
implementation to a third party, or something in-between? If you have enough
time, train your internal staff. The advantage being you then have the knowledge
in-house for ongoing operations and future projects. Even if you have the time
to train internal staff, you might consider hiring a consultant familiar with
implementing your chosen virtualization technology. Not only will this help
ensure your project’s success but it will also serve to supplement the training
your staff received. If you don’t have time, or the resources, then you have no
choice but to hire a virtualization-savvy professional services organization for
your implementation. If this is the case, be sure to include explicit knowledge
transfer requirements and, if at all possible, have someone from your staff
intimately involved in the implementation. You may take a hit in the short term,
but strategically it will pay off.
Finally, relative to selecting and working with vendors, be sure your hardware
vendor’s servers, storage, and components (NICs, fibre channel cards, etc.) are
certified to support the virtualization software you select. This may seem obvious,
at least relative to server and storage hardware, but don’t be caught in the trap of
assuming the included components are compatible just because the base server
is. Also, make sure your existing application vendors support their applications in
virtual machines. I recommend getting this in writing. The last thing you want is
to successfully complete your virtualization project only to find out down the line,
when you experience a hiccup with an application, that the vendor pushes back
just because the application is running in a virtual machine.
Monitoring & Controlling
While Executing focuses on work results, Monitoring & Controlling is all about
maintaining the project plan and making adjustments when the project team
encounters variances to the plan. The key supporting action is adherence to a
change control process so only formally accepted changes are implemented. In
addition, PMI defines scope, schedule, cost and quality control as well as
managing the project team and stakeholders, along with performance reporting,
risk monitoring and controlling, and contract administration to round out the
Monitoring and Controlling component of their project management lifecycle.
Like in the Executing component all of the PMI-defined processes are important
to any IT project, but a couple are worth expanding on in the context of a
virtualization project.
Managing the stakeholders, which has an impact on scope control as well, is one
of the more important processes during Monitoring & Controlling. I believe this is
so because of the potential far-reaching impact and easily recognizable benefits
of virtualization. Once stakeholders begin seeing the tangible benefits as
virtualized components begin coming on-line, it’s natural for their minds to begin
racing to other areas that would benefit from implementation of the technology.
Don’t get me wrong, this is a good thing, but the downside is the resulting desire
on the part of the stakeholders to change the scope to expand the virtualization
“footprint.” I’ve seen it. It’s great for acceptance of virtualization but not
necessarily good for the project at-hand. Just be aware of it and be prepared to
“rein them in” as gently as possible without dampening their new found
enthusiasm.
The other, and in my opinion, perhaps the most important process within the
Monitoring & Controlling component is monitoring and controlling risk. Again,
Tiana suggested, “It is imperative to ensure that appropriate fallback scenarios
are in place and that all owners of those systems are completely in the loop.”
While I believe virtualization is now mainstream, it is still a “new” technology to
many if not most companies. Anytime a company is implementing a technology
that is new to them, I believe extra care must be taken to identify potential risks
and how to mitigate them or what their fallback plans are. I suggest, as PMI
promotes, assigning specific individuals as owners of each identified risk. It is
that person’s responsibility to monitor for triggers associated with the risk(s) for
which they are responsible and initiating the appropriate response if a trigger is
“fired.”
Closing
The Closing component of PMI’s project management lifecycle deals with
(surprise!) closing the project as well as closing contracts entered into for the
project.
Relative to closing a virtualization project, I recommend defining early on, as in
the project plan, what constitutes the end of the project and the beginning of
maintenance and on-going operations. I pointed out in the Planning article that
virtualization’s impact on IT operations should be explicitly considered as IT
operations’ processes may need to be updated. It’s really a matter of scope
definition whether these process modifications are included in the project or are
considered a part of on-going IT operations. I believe it’s worth explicitly
addressing in the project plan if for no other reason than to ensure process
modifications to accommodate virtualization aren’t overlooked.
Also, DON”T FORGET TO CAPTURE LESSONS LEARNED! Unfortunately,
whether it’s just due to the relief felt in completing a project or the pressure to
move resources to a new project, capturing lessons learned always seems to be
short changed if not overlooked completely. I can just about guarantee that once
virtualization is successfully implemented in your company there will be an
ongoing recognition of its benefits and therefore an ongoing desire to see where
else it can be applied. Without capturing lessons learned, the risk increases that
the discussions and thought processes that went into overcoming challenges on
the project will be revisited in subsequent virtualization projects and if this
happens, to quote one of the current presidential candidates, “Shame on you.”
Finally, relative to contract closure, make sure that, as I mentioned in the
Executing section, if you used an outside consultant or professional services
organization, they have satisfactorily transferred knowledge to your team. I
would suggest a final session between the outside source and your internal team
to explicitly answer questions and review aspects of the implementation for which
your staff would like clarification or more information.
Well that’s it. I’ll finish where I started……Virtualization is HOT! It is a disruptive
technology that is driving an IT transformation. While powerful, and as positive
an impact this disruptive technology may have, disruption implies risk; potentially
serious risk. Structured project management is one way to help mitigate this risk.
And, the project management lifecycle defined by PMI is, in my humble opinion,
an excellent framework for applying a structured project management approach
to your virtualization project. I hope this series of articles helped reinforce that
notion.
Related Links:
Foedus , PMP'n Part One , PMP'n Part Two
|
