Identifying the Technical Goals and Objectives to Implement Windows Server 2003

Although an operating system upgrade Windows Server 2003 may not initially seem integral to the highest-level company goals, its importance will become 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 client relationship management software for sales executives" is more actionable.

Departmental technical goals can include "1,000-foot" itemsfor example, implementing a new software application or set of functions that require other network changes, such as an operating system upgrade Windows Server 2003. The Marketing department may require some of the advanced features of the latest version of Exchange, as well as enhanced Web site capabilities that necessitate the implementation of Windows Server 2003 and the .NET family. Or the Sales department may require better remote access to the company's data through mobile devices and the Internet, and a solution was already chosen that involves the Windows .NET 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 to $250,000? If a year is too long, but 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 may 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 may 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. This section focuses on the server components, but later chapters will focus on other hardware and software areas that should be reviewed.

Upgrading to the latest version of a key network application (CRM solution, document management system, or remote access solution) may require a network operating system upgrade, but it may need to involve only a limited portion of the network (perhaps only one server). Yet 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 between offices, a full NOS upgrade may make more sense. An upgrade Windows Server 2003 enterprisewide can allow centralization of resources, consolidation of servers, enhanced management tools, and other features that may 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 may well affect the migration process and limit changes to the network to weekends or after hours. Or a goal that involves a dramatically short timeline may likewise affect the strategy and require a partial NOS upgrade.

Questions raised at this point may require further discussion and even research. The section, "The Discovery Phase: Understanding the Existing Environment" later in this chapter examines some areas that generally need review. 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 requires not only a core operating system upgrade (to Windows 2000 or Windows Server 2003) but also requires that the Windows Active Directory is properly implemented. On the other hand, for an organization implementing SharePoint Team Services (STS), because STS does not require Active Directory to make the application fully functional, the organization can choose to implement just Windows Server 2003 as an application server and can delay the implementation of Active Directory or other Windows Server 2003 services 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 may 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. But this can be an effective way to implement the new technology in a faster method than an enterprisewide operating system upgrade. A partial upgrade also may 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.

As will be discussed in Chapter 8, "Integrating Active Directory with Novell, Oracle, Unix, and NT4 Directories," Windows Server 2003 is designed for compatibility and co-existence with a variety of other network operating systems in addition to NT Server and Windows 2000 servers. An important point to consider during the design process is whether it makes sense to upgrade the entire NOS even though doing so may not be absolutely essential. There may be convincing arguments for a complete upgrade because management of a uniform environment can be easier to administer organization-wide, and an upgrade Windows Server 2003 may solve a number of existing issues.

Again, the answers may 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 needs 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 may 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. As this chapter discusses, the project has several key phasesdiscovery, design, prototype, and implementationand 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 between 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 may 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 may be missing the mark because it may not be clear exactly what is being tested, and the implementation may 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 more often than not be flawed. In fact, the result may never even be reached because "show stoppers" 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" hardwarethat is, the fastest processors and largest-capacity drivesmay take longer to arrive than those a step down. The new equipment should still be tested or "burned in," in a lab environment, and fine-tuned, 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; this step will be discussed in more depth in the section, "The Prototype Phase: Creating and Testing the Plan" later in this chapter.

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.

While 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 Windows Server 2003 may enable a company to consolidate and reduce the number of servers on the network and replace "flaky" applications with more stable ones. An upgrade may also introduce brand-new tools that may 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 2003 handling one new application can benefit from outside assistance. Some tight time frames necessitate delegating 90% of the tasks to outside resources, while other, more leisurely projects, may 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 may 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 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.