Planning for Deployment
Planning for Deployment |
|
When you plan to deploy an operating system and network infrastructure, plan for the unexpected. Even the best deployment plans can be affected by changes in business needs, economics, user requirements, or disruptions such as power outages or storms.
A risk management plan helps you identify potential risks before they occur and prepares you for a quick response if they do occur. A well thought-out and proactive risk management plan can help you:
Reduce the likelihood that a risk factor will actually occur. If only one person on your staff fully understands your security infrastructure, losing that person in the middle of the deployment could have serious repercussions. You can reduce the risk by training a backup for each key expert and keeping documentation up-to-date and accessible.
Reduce the magnitude of loss if a risk occurs. If you suspect that your Windows 2000 Server deployment project has been under-budgeted, you might be able to identify several backup sources to cover unexpected expenses.
Change the consequences of a risk. A sudden reorganization, business acquisition, or divestiture in the middle of a deployment can seriously disrupt your plans. If you have established a process for making abrupt changes, you can meet the challenge with little or no impact to the project schedule.
Be prepared to mitigate risk during your deployment. You can do this by strategically planning your installation and rollout. For example, you can start by adding new Windows 2000 domain controllers to an existing Windows NT 4.0 domain. Alternatively, you could build a new Windows 2000 domain, establish a trust relationship with the existing accounts domain, and then clone the user accounts. Or, you could install new Windows NT 4.0 domain controllers into your domain, move them to a private network, and then upgrade them to install the new domain. In each of these examples, you could easily roll back to the previous environment if you needed to.
To manage risk effectively, your risk management plan needs to:
Risk management needs to be a part of your team's regular activities and cover all key people, processes, business, and technology areas of your Windows 2000 deployment. You need to:
Assess risk in all areas that could affect your project. Ask each team to identify and to manage the potential risks associated with its area of responsibility, such as security, networking, facilities, support, or training.
Prioritize your risks. Risks can vary in severity and likelihood. Determine which risks pose the greatest threat to your organization. Address your primary risk factors first.
Meet with those who support line-of-business and existing applications. Older and line-of-business applications present special risks. Meet early with those who have a broad knowledge of these applications. If a third party is responsible for any of these applications, involve them in the process as early as possible.
Avoid making a viability judgment based solely on the number of risks uncovered. A project with 20 identified risks is not necessarily more stable than a project with 40 identified risks. A risk assessment that identifies a higher number of risks could simply be more thorough than one with fewer risks. Use this document to pinpoint the risks that could derail a project as well as those that have lesser impact.
Foster an environment where people who identify risks are not judged negatively. Workers who do the hands-on tasks in an organization often recognize problems before their supervisors do. If they are reluctant to communicate bad news, your risk assessment could be compromised. Consider implementing a reward program for those who identify risks as well as for those who help provide resolutions for those risks.
To fully identify potential risks, develop a solid understanding of the interdependencies between the various elements of the deployment. A risk matrix can help you identify and link these elements.
Table 3.4 contains a sample risk assessment matrix that lists issues, such as probability that the risk will occur, the degree of impact any particular risk might have on your project, and the strategy that is necessary to mitigate the risk.
Table 3.4 Sample Risk Assessment Matrix
| Risk | Probability | Impact | Owner | Date resolved | Mitigation strategy |
|---|---|---|---|---|---|
| A merger is under consideration. | Medium | High | Deployment Team Manager | mm/dd/yy | Create a strategy for a rapid integration with team counterparts in other organizations. |
| Not all users will have a computer configured to minimum hardware requirements before Windows 2000 is deployed. | Medium | Medium | Program Management, Help Desk, and Logistics teams | mm/dd/yy | Make a decision whether to upgrade hardware at the time of installation, or to wait for a hardware upgrade throughout the organization. |
Create the matrix early in your planning phase and update it at regularly-scheduled intervals, or when there is a change in schedule, specification, management, team, scope, or rollout strategy.
Few elements of a deployment can do more to create risks than a poorly conceived schedule. For example, if your organization institutes a fourth-quarter freeze on deployments, squeezing in too many key steps at the last minute might diminish the quality of your testing and rollout. If you schedule the simplest components of your deployment first and leave the most complex and riskiest components to the end, you reduce the amount of time available to resolve more complex problems.
A schedule that considers risk assessment can minimize the likelihood of serious problems. The following guidelines can help you create a risk-driven schedule:
Base the schedule on task-level estimates. Begin with task-level estimates and work up through team schedules, then integrate the schedules of multiple teams. Basing your schedule on bottom-up, task-level estimates forces you to identify and resolve the issues that can delay or even derail a project.
Develop high-risk components first. Address the high-risk elements of your deployment first. The consequences of delays, design changes, or other problems have less impact on the rest of the deployment when they are addressed early.
Establish major and interim milestones. Milestones are checkpoints against progress that are verified by testing. Frequent interim milestones let you reevaluate progress against new information early in the process and reduce the risk of missing the major milestones.
Allocate time for unforeseen circumstances. Few major deployments are completed without being affected by events that disrupt schedules, like the illness of key personnel, a hardware back-order, or problems with funding. Cushion your schedule with extra time for those unforeseen circumstances.
Schedule time for project management. It takes time to define the vision, secure funding, and do all the other project management tasks. Schedule the appropriate amount of time to manage the project.
Use a project scheduling tool. Project scheduling tools allow you to link tasks with dependencies and interdependencies, and to identify task owners and task status quickly. They can also be useful in tracking the progress of the different teams and their tasks to ensure your project stays on schedule.
Keep the schedule up-to-date. Update the schedule whenever business or deployment circumstances change, new activities are added, and milestones are reached.
Keep project leads informed when changes to the schedule are needed. Defining objectives lets people know when to stop deployment. For example, if you rolled out Windows 2000 on ten computers and found that you had a compromised third-party service, you might want to resolve the issue before continuing.