A key aspect of planning any large-scale IT deployment of an operating system is determining the overall objectives for the deployment and the scope of users, computers, networks, and organization divisions that are affected. The fundamental question of scope is: What can you realistically expect to accomplish in the given time within existing project constraints, such as staffing and budget?
Some of the objectives that you identified in the early stages of the project are likely to change as constraints become more apparent and new needs and requirements emerge. To start with, you must identify who will be affected—which organizational subdivisions, which personnel, and who will be doing what? These are questions that map to the business goals that must be accomplished.
You also must identify the systems that will be affected—which WANs, local area networks (LANs), subnets, servers, and client systems? In addition, you must determine the software that will be changed—which server software, client software, and applications?
Inside Out: Planning for scope creep
Projects grow, it's inevitable, and although the scope of some projects creeps, others gallop. Here are a few tips to help you keep it to a manageable level:
When an addition to the project is proposed, never say yes right away. Think through the consequences thoroughly, examining the impact on the rest of the project, and the project team, before agreeing to any proposed changes.
Insist on management buyoff on changes to the plan. In at least some cases, you won't get approval, automatically deferring the requested changes.
Argue for trade-offs in the project when possible, so that adding one objective means removing another, rather than just adding tasks to your to-do list.
Try to defer any noncritical proposed changes to a future project.
Many goals of the various business units and IT are only loosely related, while others are universal—everyone wants security, for example. Take advantage of the places where goals converge to engage others in the project. If people can see that their needs are met, they are more likely to be supportive of others' goals and the project in general.
You have business objectives at this point; now they must be prioritized. You should make lists of various critical aspects of projects, as well as dependencies within the project plan, as part of the process of winnowing the big picture out into a set of realistic objectives. Determine what you can reasonably accomplish within the constraints of the current project. Also, decide what is outside the practical scope of this Windows Server 2003 deployment but is still important to implement at some later date.
The objectives that are directly related to the IT department will probably be clearer, and more numerous, after completing the analysis of the current network. These objectives should be organized to conform with existing change management procedures within your enterprise network.
When setting goals, be careful not to promise too much. Although it's tempting and sometimes easier in the short run to try to do everything, you can't. It's unlikely that you will implement every single item on every person's wish list during the first stage of this project, if at all. Knowing what you can't do is as important as knowing what you can.
Inside Out: Gauging deployment success
It is difficult to gauge the success of a project without clearly defined goals. Make sure that you define specific, measurable goals that you can use to determine when each portion of the project is complete. Everyone on the project team, particularly management, should agree on these milestones before the rollout gets under way.
Some goals should map to user functionality (i.e., the XYZ department is able to do ABC), while others will correspond to administrative tasks. Be granular in your goals: "Security policies will be followed" is difficult to quantify; however, "Virus definition files are updated daily" or "Operating system patches will be installed within 48 hours of release" is easy.
You should create a project schedule, laying out the time line, tasks, and staff assignments. Including projected completion dates for milestones helps you keep on top of significant portions of the project and ensure that dependencies are managed.
It is critical that you are realistic when considering time lines; not just a little bit realistic, really realistic. This is, after all, your time you are allocating. Estimate too short a time and you are likely to spend evenings and weekends at the office with some of your closest coworkers.
A number of tasks will be repeated many times during the rollout of Windows Server 2003, which should make estimating the time needed for some things fairly simple: a 1-hour process repeated 25 times takes 25 hours. If, for example, you are building 25 new servers inhouse, determine the actual time needed to build one and do the math.
Once you have a rough idea of the time required, do the following:
Assign staff members to the various tasks to make sure you have adequate staff to complete the project.
Add some time to your estimates—IT projects always seem to take more time than you thought they would. This is the only buffer you are likely to get, so make sure you build in some "extra" time from the start.
As much as possible, verify how long individual tasks take; you might be surprised at how much time you spend doing a seemingly simple task, and if your initial estimate is significantly off, you could end up running significantly short on time.
Develop a schedule that clearly shows who is doing what and when.
Get drop-dead dates, which should be later than the initial target date.
Post the schedule in a place where the team, and perhaps other staff, can view it. Keep this schedule updated with milestones reached, changes to deliverable dates, and so on.
Determining the budget is a process constrained by many factors, including, but not limited to, IT-related costs for hardware and licensing. In addition to fixed IT costs, you also must consider the project scope and the non-IT costs that can come from the requirements of other departments within the organization. Thus, to come up with the budget, you will need information and assistance from all departments within the organization and with consideration for all aspects of the project.
Many projects end up costing more than is initially budgeted. Sometimes this is predictable and preventable with proper research and a bit of attention to ongoing expenses. As with time lines, pad your estimates a little bit to allow for the unexpected. Even so, it helps if you can find out how much of a buffer you have for any cost overruns.
In planning the budget, also keep in mind fiscal periods. If your project is crossing budget periods, is next year's budget for the project allocated and approved?
Tip
Budget for project changes
Keep in mind there are likely to be changes as the project is under way. Each change will probably have a cost associated with it, and you might have to fight for additional budget or go back to the department or individuals that want the change and ask them to allocate moneys from their budget to cover the requested change.
No matter how carefully you plan any project, it is unlikely that everything will go exactly as planned. Accordingly, you should plan for contingencies that might present themselves; by having a number of possible responses to unforeseen events ready, you can better manage the vagaries of the project.
Start with perhaps the most common issue encountered during projects: problems in getting the assigned people to do the work. This all too common problem can derail any project, or at least cause the project manager a great deal of stress. After all, the ultimate success of any project relies upon people doing their assigned tasks. Many of these people are already stretched pretty thin, however, and you might encounter times when they aren't quite getting everything done. Your plan should include what to do in this circumstance— is the person's manager brought in, or is a backup person automatically assigned to complete the job?
Another possibility to plan for is a change in the feature set being implemented. Should such shifts occur, you must decide how to adjust to compensate for the reallocated time and money required. To make this easier, identify and prioritize the following:
Objectives that could slip off this project and onto a later one should the need arise
Objectives that you want to slip into the project if the opportunity presents itself
Items on both of these lists should be relatively small and independent of other processes and services. Avoid incurring additional expenses; you are more likely to encounter extra time than extra funding during your deployment.
In general, ask yourself what could happen to cause significant problems along the way. Then, more important, consider what you would do in response. By thinking through potential problems ahead of time, and planning what you might do in response, you can be prepared for many of the inevitable bumps along the way.
Inside Out: Padding project estimates
Many consultants pad their project estimates, primarily as a means of ensuring that the inevitable project scope creep isn't problematic later on. After all, it's preferable to have a client who is happy that the project came in early and under budget rather than one who is unhappy at the cost and time overruns. You might want to use this approach by adding in a little extra time and not allocating quite all of the available money. If you come in early and under budget, so much the better—but you probably won't.
You have goals, know the time line, have a budget pinned down—now it's time to get serious. Starting with the highest-priority aspects of the project, estimate time and budget needed to complete each portion. Work your way through the planned scope, assessing the time and costs associated with each portion of the project. This will help ensure that you have enough time and budget to successfully complete the project as designed.
As you finalize the project plan, each team member should review the final project scope, noting any concerns or questions he or she has about the proposal. Encourage the team to look for weak spots, unmet dependencies, and other places where the plan might break down. Although it is tempting to ignore potential problems that are noted this late in the game, you do so at your own peril. Avoiding known risks is much easier than recovering from unforeseen ones.
Inside Out: Get management approval for your plan
Executive business and IT management should approve the deployment plan, especially if they are not on the planning team. This executive sign-off on the plan should occur at a number of points along the way. After the project team agrees upon initial goals is a good time to get approval, as are critical junctures, such as once the plan has been validated in the lab and again after a successful pilot. In any case, make sure you have management sign-off before you perform any installations in a production environment.