Microsoft Windows 2000 Server Administrators Companion (IT-Administrators Companion)

A recent study commissioned by Microsoft identified six characteristics of successful IT departments. None of the conclusions are startling, but they bear repeating. Companies with successful Information Technology departments will

• Make IT a business-driven line function, not a technology-driven staff function. In other words, the function of the technology people must be firmly connected to business strategies and the everyday work that advances these strategies.
• Base technology funding decisions on the same considerations as any other corporate expenditure. Cost/benefit and ROI analyses must be as much a part of every IT investment decision as they would be in the decision to buy a new building.
• Insist on simplicity and flexibility throughout the technology environment. Reduce the number of technologies and platforms deployed, and aim for maximum flexibility and ease of implementation.
• Demand near-term business results from development efforts. Incremental project rollouts are preferred, as is packaged software over custom software wherever possible. When custom development is necessary, focus on the 20 percent of the functionality that typically adds 80 percent of the value.
• Drive constant year-to-year operational productivity improvements. Measure performance against internal and external benchmarks and standards, and strive for constant improvements.
• Aim for an IT department that is smart about business and a business organization that is smart about IT. Simply stated, in the better-performing companies the IT and business organizations work together. They speak the same language, talk to each other, and understand each other's capabilities and needs.

These are all grand statements that are difficult to argue with in the abstract but hard to implement in the real world. However, we all have to start somewhere, and keeping these aims in mind and working toward implementing them can only benefit the enterprise overall.

After you've analyzed your present situation as well as the business goals you need to achieve, the next step is to design a roadmap that will take you where you want to go. The roadmap will include a definition of the goals, a risk assessment, and an implementation plan.

Defining Goals

Your deployment goals must be specific, achievable, and measurable. Spell out the problems that have to be solved and how you will address constraints such as end user requirements, costs, schedules, and reliability.

Your plan must then address specifically what you want to accomplish at each stage and how you will measure whether you have done what you set out to do. When deploying Windows 2000 in a particular department, approach the task as a vendor to that department. As a minimum, you'll need to

• Determine who has to agree to the scope of the project and who can sign off at the end of it.
• Determine the scope of the project: what needs to be installed, what needs to be configured, and what the users will be able to do at the end of the project. Involve as many people in the department as possible.
• Get agreement as to what will constitute completion of the project. For example, a project might be considered complete when all workstations are connected to the network with specified software installed, all users can log on, and data can be retrieved under all conditions in n seconds or less. Again, be specific.
• Define a method that will test all areas of the project. Get a sign-off on the method. Allow ample time for testing. Regular, short-loop testing as you go will save much time and aggravation later.
• When the project is complete, get a sign-off that it is in fact complete. Additions and changes that are not in the original scope should be addressed as a new project—a different phase of the deployment. It's very important that every stage have a point of closure.

Some of these steps seem obvious, but it's surprising how often people have no idea whether their upgrade to the system has actually accomplished anything and, if it has, whether the results are what was wanted and needed. All too often the IT people go away dusting their hands and congratulating themselves, while the actual "customers" are far from satisfied.

Assessing Risk

It's not possible to predict everything that can go wrong in a deployment, but you can be sure that something will. Typical problems include sudden changes in business needs or user requirements, costs running higher than expected, and the almost inevitable schedule slippage.

Risks can be managed proactively or reactively. Preventing difficulty is obviously better than reacting to trouble after it pops up, although (just as obviously) this is not always possible. Nevertheless, it's feasible to draw up a risk assessment/risk management plan. Such a plan would include the kinds of problems that might occur, an appropriate response to each problem, and how to minimize the potential loss in case of a problem.

Few things can hurt you more during deployment than a poorly thought-out schedule. At the same time, a schedule that considers risks can go a long way toward minimizing the likelihood of serious problems. The following precautions will help you minimize schedule-related perils:

• Develop high-risk components first. Any areas that are already an ongoing tangle—such as messaging or your Web server—should be developed first and independently. New components that haven't been part of your network before should also be tested separately and understood completely before you install them where they can affect critical operations.
• Include a fudge factor for unforeseen circumstances. Nothing ever works exactly as you expect. The "five-minute install" turns out to require a change in hardware to work correctly. The quick change of hardware requires an unexpected half-hour of configuration. Estimate how much time each stage of deployment will take, and then double it.
• Update the project plan and schedule. When circumstances change and milestones are reached, notify everyone involved in the project by updating and distributing the plan and schedule. If you find yourself two days behind after the first stage of the deployment, don't just plan on working faster to catch up. Instead, update the plan and determine whether the delay is due to a defect in the plan (and therefore likely to multiply over time) or merely a one-time failing. Optimism is a fine quality, but it's more important to be realistic.