Checklist: Deployment
Synopsis
The following checklists identify key management, engineering, acquisition, and support issues to address during a deployment.
Top
Management Activities Checklist
 |
The Deployment Project Plan considers the following activities: configuring and releasing products, operational testing and evaluation in the user area, installation on-site platforms, deactivation and removal, advertising and marketing, training, pilot support, and inventory of site resources after deployment. |
 |
The deployment project plan considers change management issues such as stakeholder involvement, political sensitivities, culture shifts, and resistance to change from user communities. |
 |
Deployment project plans are synchronized with the business events, according to calendar occurrence, business process synchronization, or staging per program directive (cost of living adjustments). |
 |
Deployment project plans include explicit decision points at appropriate management levels for significant events, such as starting a pilot or full cutover (IT Division, CIO, HS Agency). |
 |
The deployment project plan explicitly identifies actions for monitoring key assumptions and risks to the deployment. |
 |
For high risk deployments, the Pilot Team either coordinates among or consists of members from each of the user communities. |
 |
The deployment project plan considers the number of target sites, the configuration differences for each site (variants), and the unique support each site and variant would require. |
 |
For gradual deployments, one or more Pilot Teams are established with expertise in the site and configuration technologies, and in the business processes or practices. |
 |
Deployment project plans consider backward compatibility issues of platform upgrades for applications, interfaces with external systems, infrastructure load balancing, and throughput. |
 |
Deployment project plans consider information security issues such as computer configurations, network services, data classification and accessibility, user authentication, intrusion detection, backup and recovery procedures, and security policies. |
 |
The deployment project plan considers the interoperability between old and new applications, data, business processes, and work procedures-allowing them to coexist as necessary. |
 |
A pilot process is defined to address the specific technologies and operational concerns within each pilot area. |
 |
Pilot areas are identified by considering sites that may pose unique usage or support difficulties, such as many users distributed over large geographic regions, or a mix of sites with novice and advanced user skills. |
 |
Pilot activities are synchronized based on business cycles to avoid changes and upgrades during high user demand. |
 |
Individuals on the pilot team have all the appropriate technology and business skills to directly support the initial users. This may require outside (contracted) services augmented with internal HS Agency technical and business expertise. |
 |
The Deployment Project Plan has activities to collect, analyze, and archive lessons learned when a deployment project is completed. |
 |
CM and QA participate in the deployment planning to ensure that their concerns are addressed adequately before the plan is approved |
 |
Executive management and site representatives should review, approve, and monitor execution of the plans. |
Top
Engineering Activities Checklist
 |
Adequate resources (tools, travel, equipment) are provided to the deployment (Pilot) Teams. Lessons learned from previous deployments are used to assess the adequacy of the resources. |
 |
The technical staff on the deployment (Pilot) Team should have a thorough understanding of the application design, implementation, and use. They should be able to identify and isolate faults and provide a work-a-round in the field, if necessary. Individuals may include lead developers or testers (contractor or HS Agency staff). |
 |
The deployed configuration is certified to be correctly configured through operational testing/execution in the actual usage environment, using real user data, as needed. |
 |
Interfaces with external systems in the actual operational environment are thoroughly tested, including likely failure scenarios. This may involve setting up a piloting environment, running test decks, and conducting live testing of interfaces as part of a formal qualification. |
 |
Realistic application usage scenarios are used during testing. |
 |
Testing covers time-based requirements such as generating reports daily, weekly, monthly, quarterly, annually, or based on significant events. |
 |
Testing uses live data and extends beyond just the technology to include the entire business practice (putting a notice in an envelope and verifying that the printed zip+ 4 code appears in the envelope window). |
 |
The electronic version of forms, policies, and procedures should be synchronized with user handbooks (binders). Multiple versions may be necessary on a site-by-site basis. |
 |
Technical training is provided to State and contractor users, side-by-side in the usage environment. Technical training is coordinated with business training (processes and procedures). |
 |
Anyone who will administer or use the system should be considered for training. Trainers consist of field staff who know the old way of doing things, and can relate it to the new (e.g., code "07" now in a dropdown text box). |
 |
All key site-specific configuration parameter settings are recorded. |
 |
A backup of the before and as-installed configuration is made, as appropriate. |
 |
When necessary, emergency, onsite fixes are thoroughly documented, and problem reports are filed. When a formal correction is released, the temporary emergency fix is removed. |
 |
When products are taken out of service, they are de-activated, removed, and archived (including data), as appropriate. Destruction procedures are detailed as necessary to ensure protection of sensitive data (e.g., magnetic media). |
 |
Initial operational measurements are recorded and retained, establishing a baseline for the initially-deployed system. |
Top
Acquisition Activities Checklist
 |
A Contractor Management Plan is created and maintained for each supplier relationship. |
 |
Contracted services that assist in deployment should be integrated into the deployment plans and assessed for impact to the critical path. |
 |
There should be adequate assistance where and when it is needed, such as with a State-wide deployment. This may include individuals or groups that help with telecommunications, networking, installation of platforms, movement of equipment, facilities, on-call (vendor) maintenance, Internet Service Providers, operations support, and other areas. |
 |
Skills and knowledge of individuals providing contracted deployment services should be assessed against explicit qualifications (technical certifications, years of relevant experience). |
 |
Contractor status reports are received periodically or after significant events. These are reviewed for individual performance, as well as possible effects across other contractors (critical path). |
 |
Coupling of tasks across contractors (services) should be minimized to allow for measuring individual performance with limited cross-contractor dependencies. |
 |
Criteria to accept the product or services should be explicit, objectively defined, and measurable as the work proceeds. |
Top
Support Activities Checklist
 |
Configuration Management (CM) and Quality Assurance (QA) personnel have adequate understanding of the business and technology domain for the deployed products. |
 |
CM includes inventory control of both new and retired equipment. |
 |
The useful lifespan of data is determined and its archival or destruction is planned, as necessary. Records are retained, as needed. |
 |
CM allows a fast track for emergency bug fixes, but assures that these changes are removed once a production quality change is released. |
 |
CM controls and administers multiple site configurations within and across sites. Differences and similarities among sites should be identified. |
 |
A Configuration Control Board (CCB) with site representation tracks and approves major configuration changes. |
 |
Site change requests are managed and tracked. |
 |
QA reviews the deployed product to ensure that the key product attributes are properly exhibited (i.e., reports, notices, or other key items are reasonable and correct). |
 |
QA reviews the deployment processes to ensure that key deployment procedures are adequately performed (testing of external interfaces). |
 |
QA activities are objectively performed against applicable documented policies, standards, procedures, practices, or conventions and guidelines. |
 |
An independent QA function is maintained, possibly through an independent vendor. |
Top