1. Application name OPERATIONAL READINESS Stage Gate Review Version 1.0
The Operational Readiness Review is a formal inspection conducted to determine if the final IT solution that has been developed or acquired, tested, and implemented is ready for release into the production environment for sustained operations and maintenance support.
This is a formal inspection conducted to determine if the final IT solution that has been developed or acquired, tested, and implemented is ready for release into the production environment for sustained operations and maintenance support.
Presented By:
Project Manager:

2. PROJECT STAGE GATE REVIEW STATUS
Review Date
Status
Project Selection
<insert date>
Project Baseline Review
Preliminary Design Review
Operational Readiness

3. PROJECT OVERVIEW Number of anticipated users:
Project Manager:
Project Sponsor
Project Description:
Number of anticipated users:
Impact on the organization:

4. IMPLEMENTATION DETAILS
Implementation dates:
- behind NIAID firewall: <date>
- anticipated to the general public: <date>
Training dates: <date>
Date Notification sent to users: <date>
(for evaluation by external users before publication) <date>
URL:
(Development)
(Production)

5. ENTERPRISE RESOURCE REQUIREMENTS
Example:
Dev: entirely done locally on developer computers with RStudio; applications build and ran locally with R Shiny package. All codes are shared through GitHub.
Cloud QA:
Application: 1+ Docker containers running on QA ECS Cluster
1 x Application Load Balancer
Internal & External Route 53 Records
1 x S3 Bucket (stores application deployment configuration)
1 x DynamoDB table (supports application deployments)
1 x Logentries QA LogSet   
Cloud Prod:
Application: 1+ Docker containers running on Prod ECS Cluster
1 x Logentries Prod LogSet
1 x DataDog External Site Monitor
External niaid.nih.gov DNS record provided by CIT
Source: OEB

6. STATUS OF SECURITY Security package:
Initial submission to ? on <date>
Review with ? on <date>
Final submission by ? to ISSO on <date>
ISSO sign-off on security documents <date>
Security scan results
Type/name of scan: ?
Date of scan: <date> 6

7. IDENTIFIED RISKS Examples: Risk Probability (L, M, H) Impact (L, M, H)
Mitigation Strategy
Handling user inputs L
Input validation and inform users the correct input format, robust handling of different input types
Security vulnerabilities
Perform appscans often; work closely with SEB; use newer technologies

8. VARIANCES FROM PROJECT BASELINE
No variances from the project baseline

9. Questions? 9