Although
an operating system upgrade to Windows Server 2008 R2 might not
initially seem integral to the highest-level company goals, its
importance becomes clearer as the goals get close to the “1,000-foot
view.” When the business goals are sketched out, the technical goals
should fall into place quite naturally.
At this point in the process,
questions should focus on which components and capabilities of the
network are most important, and how they contribute to or hinder the
goals expressed by the different units.
As with business goals,
the technical goals of the project should be clarified on different
levels (50,000-foot, 10,000-foot, 1,000-foot, and so on). At the highest
level, the technical goals might be quite vague, such as “no downtime”
or “access to data from anywhere.” But as the goals are clarified on a
departmental and individual level, they should become specific and
measurable. For example, rather than identifying a goal as “no
downtime,” ferreting out the details might result in a more specific
goal of “99.99% uptime during business hours, and no more than four-hour
downtime during nonbusiness hours scheduled at least two days in
advance.” Instead of stating a goal of “access to data from anywhere,” a
more specific goal of “high-speed remote logon from any corporate
regional office around the world and dial-up or VPN access from the home
offices of the organization’s senior managers” can more reasonably be
attained.
Part of the art of defining
technical goals and objectives also resides in limiting them. Data can
be accessed in many different ways, and the complexity of the network
environment can boggle even the veteran IT manager’s mind. So, for
example, rather than setting a goal of “remote access to all employees,”
a more focused goal such as “access to email for all employees, remote
access to email and the accounting software for the finance department,
and remote access to email and the customer relationship management
software for sales executives” is more actionable.
Departmental technical goals
can include “10,000-foot” items—for example, implementing a new software
application or set of functions that require other network changes,
such as an operating system upgrade to Windows Server 2008 R2. The
marketing department might require some of the advanced features of the
latest version of Microsoft Exchange, as well as enhanced website
capabilities that necessitate the implementation of Windows Server 2008
R2. Or, the sales department might require better remote access to the
company’s data through mobile devices and the Internet, and a solution
was already chosen that requires Windows Server 2008 R2 as the core
operating system platform.
Two
key components should also be included in these discussions: budget and
timeline. A huge amount of time in the design phase can be saved if
these components are clarified (and agreed upon) early in the process.
Some projects have to happen “yesterday,” whereas others can happen over
a period of quarters or even years. In most cases, the budget will vary
with the time frame involved because longer timelines enable
organizations to train resources internally and migrate in a more
gradual fashion. Even if a firm budget or timeline isn’t available,
order of magnitude ranges can be established. If $500,000 is too much,
how about $250,000? $100,000? $50,000? If a year is too long, but the
budget won’t be available for four months, the time frame becomes better
clarified.
Defining the Scope of the Work
By now, the list of
goals and objectives might be getting quite long. But when the myriad of
business and technical objectives as well as the overall priorities
start to become clear, the scope of work starts to take shape. A key
question to ask at this point, to home in on the scope of the project,
is whether the migration is primarily an operating system upgrade or an
application upgrade. Often the answer to this question seems clear at
first but becomes more complex as the different goals of the business
units are discussed, so the scope of work that is created might be quite
different than it appeared at first.
Specifically, a decision needs to
be made whether the entire network operating system (NOS) needs to be
upgraded or only a subset of it, and what other infrastructure
components need to be changed or replaced.
Upgrading to the latest
version of a key network application (CRM solution, document management
system, or remote access solution) might require a network operating
system upgrade, but it might need to involve only a limited portion of
the network (perhaps only one server). However, if this application
needs to be accessed by every member of the organization, in several
offices, and requires upgrades to data storage solutions, tape backup
software, antivirus software, remote access, and connectivity among
offices, a full NOS upgrade might make more sense. An upgrade to Windows
Server 2008 R2 enterprisewide can allow centralization of resources,
consolidation of servers, enhanced management tools, and other features
that can make a larger project more attractive.
It is important to also
examine how the business and technology goals fit into this plan. If one
of the goals of the organization is 99.99% uptime during business
hours, this might affect the migration process and limit changes to the
network to weekends or after hours. Or, a goal that involves a
dramatically short timeline might likewise affect the strategy and
require a partial NOS upgrade.
Questions raised at this point might require further discussion and even research. But with a solid understanding of the different departmental and
companywide goals for the project, you can sketch out a basic outline of
the required configuration.
You need to get answers to these sample questions:
How many servers need to be upgraded?
Where do these servers reside?
What core business applications need to be upgraded?
What additional applications and devices need to be upgraded or modified to support the new servers and applications?
How will this affect the desktop configurations?
Based on the goals and
objectives for the project and the answers to these types of questions,
the high-level scope of the work begins to take shape. Here are some
general rules to consider:
Keep it as simple as possible.
Break up the project into logical segments.
Don’t forget that the staff and user community will need to learn new skills to be productive.
Often, it makes sense to
upgrade the operating system first; then add directory services and file
and print functionality; and, finally, ensure the system is properly
protected with a compatible backup solution, virus protection, and
disaster recovery plan. When this foundation is in place, the
applications can be migrated in a more gradual process. In other cases,
the new application must be installed in advance of the operating system
upgrade, for testing purposes, or because of budget limitations or a
tight timeline.
Implementing the latest
version of Exchange is a good example; this implementation not only
requires a core operating system like Windows 2003, Windows Server 2008,
or Windows Server 2008 R2, but also requires that the Windows Active
Directory is properly implemented. On the other hand, for an
organization implementing Windows SharePoint Services (WSS), because WSS
does not require Active Directory to make the application fully
functional, the organization can choose to implement just Windows Server
2008 R2 as an application server and can delay the implementation of
Windows Server 2008 R2 Directory Services or other Windows Server 2008
R2 components to a future date.
Note, however, that if the NOS
in use is too old or no longer supported by the manufacturer, the
upgrade choices might be limited. You might simply have to implement a
completely new collection of servers with compatible network
applications and phase out the old ones.
Often, an application-focused
upgrade will introduce a limited number of new servers but also set the
stage for the eventual migration. This can be an effective way to
implement the new technology in a faster method than an enterprisewide
operating system upgrade. A partial upgrade can also defer the costs of
purchasing new server licenses, client access licenses, and other
enterprisewide applications, including virus protection and tape backup.
Ideally, the servers that are upgraded for the new application(s)
should be designed
to integrate into the NOS after a full-fledged upgrade. In other words,
ideally these servers won’t need to be rebuilt later.
An
important point to consider during the design process is whether it
makes sense to upgrade the entire NOS even though doing so might not be
absolutely essential. There might be convincing arguments for a complete
upgrade because management of a uniform environment can be easier to
administer organizationwide, and an upgrade to Windows Server 2008 R2
might solve a number of existing issues.
Again, the answers might not be
obvious at this point in the design process. But by asking the
questions and engaging in “what-if” discussions and speculations, the
primary pieces of the puzzle can be identified. The next step is to
determine how best to fit those pieces together.
Determining the Time Frame for Implementation or Migration
An equally important
component of the migration is the time frame, and this component will
affect the path and process that need to be followed to create the
results desired. Often, the goals for the project will dictate the
timeline, and the technology upgrade can drastically affect other
critical business project dependencies. Other upgrades might not have
strict timelines, and it is more important that the process be a smooth
one than a quick one.
Dependent on the scope of the
project, a time frame of two to four months could be considered to be a
short time frame, with four to six months offering a more comfortable
window. Within these time constraints, several weeks are available for
discovery and design, a similar amount of time is available for the
testing process, and then the implementation can proceed.
A fundamental point to
remember is that change will bring with it a learning curve to both the
user communities and the administrative staff. And the greater the
amount of change that employees need to adjust to, the more support and
training will be required to ensure their productivity when the new
platform is rolled out. This is especially true when the applications
change along with the operating system.
A safe strategy to take when
sketching out the timeline is to start by setting a completion date and
then working backward from it, to get a sense for the time available to
each component of the process. The project
has several key phases—discovery, design, prototype, and
implementation—and sufficient time should be allowed for each one of
them. Although there are no hard-and-fast rules of how the time should
be split up among each of these phases, each phase tends to take longer
than its predecessor, and the discovery and design phases typically take
as long, combined, as the testing phase (that is, discovery + design =
prototype time frame).
The
implementation phase will vary tremendously based on the scope of the
project. For simpler projects, where the implementation consists only of
a new server housing a new application, the implementation might be as
simple as “flipping a switch” over a weekend (assuming the solution has
been thoroughly tested in the lab environment). At the other end of the
spectrum, a full NOS upgrade, happening in several locations, with
changes required on the desktop, can take a period of months or
quarters.
Even when the deadline for
the completion of the project is the infamous “by yesterday,” time
should be allocated for the design and planning process. If time and
energy are not invested at this point, the prototype testing process
might be missing the mark because it might not be clear exactly what is
being tested, and the implementation might not be smooth or even
successful. A good analogy here is that of the explorer who sets off on
an adventure without planning what should go in her backpack or bringing
a map along.
Slower, phased migrations
typically occur when the existing environment is fairly mature and
stable, and the vertical applications are still fairly current and meet
the company’s needs.
Slower time frames should allow
a period of weeks or months for the staff to fully understand the goals
of the project and requirements of the key stakeholders, review the
existing environment, and document the design. Time will also be
available to choose the right partner for the project, train the
internal resources who will assist in (or lead) the process, and
prototype the solution in a safe lab environment. Assuming the testing
is successful, a phased implementation can further limit the risks of
the project, and the pilot phase of the implementation will allow the
staff to learn lessons that will smooth out the remaining phases.
Milestones should be set for
the completion of the phases, even if they aren’t essential to the
project’s success, to keep momentum going and to avoid the “never-ending
project.” Projects without periodic dates set as interim milestone
points will almost certainly not meet an expected completion date.
Projects that extend too far beyond the allotted time frame add costs
and risks such as employee turnover, changing business conditions, and
new revisions of hardware and software products.
Naturally, projects with
shorter timelines bring their own challenges, and typically, some
compromises need to be made to successfully complete a large project in a
limited amount of time. However, it is important not to abandon the
basic principles of discovery, design, and testing. If these steps are
skipped and an upgrade is kicked off without planning or a clear
understanding of the desired results, the result will often be flawed.
In fact, the result might never even be reached because “showstoppers”
can suddenly appear in the middle of the project.
It is usually possible to
meet a quick timeline (a number of weeks at the very least) and have the
results make the stakeholders happy. The real key is to understand the
risks involved in the tight time frame and define the scope of the
project so that the risks are controlled. This might include putting off
some of the functionality that is not essential, or contracting outside
assistance to speed up the process and leverage the experience of a
firm that has performed similar upgrades many times.
Hardware
and software procurement can also pose delays, so for shorter time
frames, they should be procured as soon as possible after the ideal
configuration has been defined. Note that often the “latest and
greatest” hardware—that is, the fastest processors and largest-capacity
drives—might take longer to arrive than those a step down. The new
equipment should still be tested, or “burned in,” and fine-tuned in a
lab environment, but can often be moved right into production with the
pilot implementation. For most medium and large organizations, it is
recommended that a permanent lab be set up.
Defining the Participants of the Design and Deployment Teams
Division of labor is a key
component of the implementation process. Organizations should evaluate
the capabilities of their internal staff and consider hiring an outside
firm for assistance in the appropriate areas. If the organization
understands and defines the roles that internal staff can play, as well
as defines the areas where professional assistance is needed, the
project will flow more smoothly.
The experience levels of
the existing resources should be assessed, as well as the bandwidth
that they have available for learning new technologies or participating
in a new project. If the staff is fully occupied on a daily basis
supporting the user base, it is unlikely that they will be able to “make
more time” to design and plan the new implementation, even with outside
assistance. The track record of the existing staff often reveals how
the next project will turn out, and if there are existing half-finished
or unsuccessful projects, they can interfere with a new project.
Although classroom-style
training and manufacturer-sponsored training do not guarantee expertise,
they do indicate the IT staff’s willingness to learn and illustrate
that they are willing to dedicate time to learning new technologies. A
new implementation can be a great opportunity to test the commitment
levels of the existing staff and also to encourage them to update their
skills.
Consider also how the
changes to the environment will affect the complexity of the environment
that will need to be supported. For example, an upgrade to Windows
Server 2008 R2 might enable a company to consolidate and reduce the
number of servers on the network and replace “flaky” applications with
more stable ones. An upgrade might also introduce brand-new tools that
can add support duties in unfamiliar areas to the existing staff.
After the organization
takes an inventory of resources at this level and determines roughly
what percentage of the project can be handled internally, an external
partner should be considered. Even a smaller organization faced with a
relatively simple project of, say, installing a Windows Server 2008 R2
server handling one new application can benefit from outside assistance.
Some tight time frames necessitate delegating 90% of the tasks to
outside resources, whereas other, more leisurely projects might require
only 10% assistance levels.
A
key distinction to make at this point is between the design resources
and the deployment resources. The company or individuals in charge of
the design work must have significant experience with the technologies
to be implemented and be able to educate and lead the other members of
the project team. For projects of moderate or greater complexity, these
resources should be dedicated to the design process to ensure that the
details are fully sketched out, and the solution designed is as well
thought out as possible. Often, the design team has the challenging task
of negotiating with the key stakeholders concerning the final design
because not all the staff will get everything they want and wish for in
the project. The deployment team can contain members of the design team,
and these individuals should have training and hands-on experience with
the technologies involved and will have more end-user interaction.
There are certain
prerequisites to look for when choosing an independent consultant or
solution provider organization as a partner. Without going into too much
detail, the individual or firm should have proven experience with the
exact technologies to be implemented, have a flexible approach to
implementing the solution, and have specialized resources to handle the
different components of the project. No one person can “do it all,”
especially if he gets sick or goes on vacation, so breadth and depth of
experience should be considered. Obviously, the hourly fees charged are
important, but the overall costs, if a firm is willing to commit to a
cap or not to exceed a certain price, can be more important. In the
current business environment, it makes sense to invest your time wisely
in choosing a firm that is very good at what it does, or it might not be
around in future months when your project reaches its critical phases.
Soft skills of the
partner are also important because many projects are judged not only by
whether the project is complete on time, on scope, and on budget, but
also by the response of the stakeholders and user community.
Communications skills, reliability, and willingness to educate and share
knowledge along the way bring great value in the long run.
