Readiness Review

Summary

Just before deployment, the Readiness Review Board will examine the final stages of deployment and support planning. The Readiness Review Board consists of (a) all affected parties in IS,  (b) all resource (funding) providers, and (c) all IS and other affected Decision Makers. They review the Deployment Plan and Support Plan, which includes:

• Planned implementation steps, including backout (contingency) plans
• Implementation roles and responsibilities
• Monitoring, Trouble resolution, and Capacity planning procedures
• Security, configuration and change procedures
• Training procedures for deployment and operations support personnel

Preparing for the Readiness Review

A: Review the Deployment Plan and Support Plan templates found in (http://xxx.xxx/NetImprove/Templates/).

B: Work with the managers of the groups who are likely to be deploying and supporting this architecture. Ask them to assign someone from their groups to help you in the detailed planning required by these forms.

C: Ask the managers of the deployment and support teams to review the templates when you are through,.

D: Send the Deployment Plan and Support Plan to the Network Improvement manager to have it posted on the Architecture Review web site (http://xxx.xxx/NetImprove/).

E: Within 3 days you should receive a scheduled date (based on your date selection) stating when you will be able to go before the Architecture Review Board for the third review (the "Readiness Review").

F: Prepare a summary viewgraph presentation (no more than 2 slides per Summary heading). You will have up to 30 minutes to present each plan, with another 10 minutes for questions (40 minutes per plan, 80 minutes total). Please try not to go overtime. If you think your project plans are so complex that they cannot be fully explained in this time, please call the Network Improvement manager to request an extension.

During the Readiness Review

A: During the presentation, note any concerns or problems raised, and make sure that these issues are dealt with after the meeting.

B: After the presentation, the representatives will discuss with you whether or not you should continue with this project, and why. At this point, it is likely that their objections can be met through changes to your implementation and/or support plan.

After the Readiness Review

A: After the presentation, write down the Readiness Review meeting notes for your project. Focus on the decision made: either to continue the project without conditions, or to continue the project under the condition that some issues are dealt with. If there were conditions or problems raised, then resolve those issues and record the resolution in your meeting notes. When complete, send these notes to the Network Improvement manager. They will be posted along with your Project Plan.

B: If there were problems or conditions attached to the acceptance of your project, rethink and rewrite those parts of the Deployment Plan and Support Plan documents that required further work, send it in again and request a new scheduled Readiness Review date.

This step, the most important one of this entire process, will vary tremendously from one project to another.

A: Follow the steps in the Deployment Plan, and keep a log of any problems that come up.

B: Problems that result in Schedule changes: The Deployment Plan should be updated regularly as schedule changes are made. This will help in planning and scheduling steps further along the Deployment Plan. Also, a clear record of the actual schedule will help future planners understand how long things take in the real world. (Another reason to use Microsoft Project is that you can update the entire schedule simply by changing the single slipped milestone date. Since dates do slip, you'll find this a helpful feature.)

C: Problems that result in Configuration changes: The Architecture Design, the Deployment Plan and, possibly, the Support Plan should be updated as configuration changes are made.

1. The Architecture Design should be updated since this is the only record available to Cisco as to exactly what has been deployed and where: if slightly different hardware, or software, or scripts are deployed, then this public record must be updated.

2. The Deployment Plan should be updated for any configuration changes that might affect downstream deployment. If a hardware, software, or script change is made to one site, then any parallel sites will probably need the same change. Even if the same people will be doing the deployment at these parallels sites, the written description of the deployment process should still be updated, since it may help guide you in determining the best way to perform the changed deployment. And if different people will be doing the deployment at these parallel sites, they will be relying on your guide.

3. The Support Plan may need to be updated if any changes are made to the Monitoring or Management interface, or any equipment software scripts are changed. The Operations Support staff will be expecting a single and predictable deployment based on the Architecture Design and the Support Plan; any changes to the actual configurations will catch them by surprise as they're attempting to troubleshoot the actual system, under difficult circumstances. They need an accurate and up-to-date guide.