Identifying the Technical Goals and Objectives to Implement Windows Server 2008 R2

1/15/2011 3:49:54 PM
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.

  •  Working with Windows 7
  •  Installing and Using Windows 7
  •  Improvements in Server Roles in Windows Server 2008 R2
  •  Windows Server 2008: Improvements for Thin Client Remote Desktop Services
  •  Improvements in Windows Server 2008 R2 for Better Branch Office Support
  •  Improvements in Mobile Computing in Windows Server 2008 R2
  •  Windows Server 2008 R2 Benefits for Administration
  •  Visual Studio 2010 : Understanding Solutions and Projects (part 3)
  •  Visual Studio 2010 : Understanding Solutions and Projects (part 2)
  •  Visual Studio 2010 : Understanding Solutions and Projects (part 1)
  •  Becoming an Excel Programmer : Macros and Security
  •  Becoming an Excel Programmer : Where's My Code?
  •  Becoming an Excel Programmer : View Results
  •  Becoming an Excel Programmer : Start and Stop
  •  Windows Server 2008 : Configuring and Monitoring Terminal Service Resources
  •  Visual Studio 2010 : Understanding Debugging
  •  Visual Studio 2010 : Structured Exception Handling to the Rescue
  •  Implement an Observer (aka Subscriber) Pattern
  •  Use a Stopwatch to Profile Your Code
  •  Combine Multiple Events into a Single Event
    Most View
    Developing Applications for the Cloud on the Microsoft Windows Azure Platform : Accessing the Surveys Application - Geo-Location
    SharePoint 2010 : SharePoint Fundamentals (part 2) - Site Templates
    Devolo dLAN 500 AV Wireless+ - Is This The Ultimate Homeplug?
    Encrypt Your Entire Hard Drive with FileVault
    Storage, Screens And Sounds (Part 1)
    Canon EF 24-70MM F2.8L II USM – A Standard Zoom Many Canon Users Desire
    Vodafone Smart Tab 2 – Hard To Buy
    SharePoint 2010 : Outlining the Inherent Threat in SharePoint Web Traffic
    Windows 8 Tips And Tricks – Jan 2013
    AMD A10-5800K - Processor in a Box
    Top 10
    Thermaltake Cases Are Suitable For Everyone’s Budget (Part 7)
    Thermaltake Cases Are Suitable For Everyone’s Budget (Part 6)
    Thermaltake Cases Are Suitable For Everyone’s Budget (Part 5) : Thermaltake Armor Revo
    Thermaltake Cases Are Suitable For Everyone’s Budget (Part 4) : Thermaltake Level 10 GTS
    Thermaltake Cases Are Suitable For Everyone’s Budget (Part 3) : Thermaltake Commander MS-III
    Thermaltake Cases Are Suitable For Everyone’s Budget (Part 2)
    Thermaltake Cases Are Suitable For Everyone’s Budget (Part 1) : Thermaltake Commander MS-I
    LG Optimus L9 - A Cheap Middle Class Android Phone (Part 3)
    LG Optimus L9 - A Cheap Middle Class Android Phone (Part 2)
    LG Optimus L9 - A Cheap Middle Class Android Phone (Part 1)