Template



NRM Transition to Operations Checklist[Project Name][Project Name]Ministry: Business Sponsor: Project Manager/Lead: Last Updated: May 14, 2020Version: 1.5Document: NRM_Transition_to_Operations_Checklist.docmThis page is purposely left blank.Table of Contents TOC \o "1-3" \h \z \u 1.0Version Control PAGEREF _Toc40261423 \h 42.0Purpose of Document PAGEREF _Toc40261424 \h 53.0Scope PAGEREF _Toc40261425 \h 54.0Assumptions PAGEREF _Toc40261426 \h 55.0Checklist Process/Governance PAGEREF _Toc40261427 \h 66.0Project Transition Overview PAGEREF _Toc40261428 \h 67.0Transition Deliverables Inventory PAGEREF _Toc40261429 \h 88.0Operational Subject Matter Expert Sign-off PAGEREF _Toc40261430 \h 109.0Operational Sponsor Transition Sign-off PAGEREF _Toc40261431 \h 1810.0Project Team Sign-Off PAGEREF _Toc40261432 \h 1811.0Product Owner/Project Sponsor Transition Sign-off PAGEREF _Toc40261433 \h 18Appendix A – Transition Inventory Glossary PAGEREF _Toc40261434 \h 19Appendix B – Procedural Instructions PAGEREF _Toc40261435 \h 24Appendix C –Operational Service Description PAGEREF _Toc40261436 \h 28Appendix D –Operational/Advisory Team Acronym Definition PAGEREF _Toc40261437 \h 29Appendix E –Operational/Advisory Team Contact Information PAGEREF _Toc40261438 \h 29 Version ControlDocument VersionRevisionDateAuthorChange of Reference1.0OriginalDec 5, 2019IIT TransitionChris Cocker /Bogdan BeznaOriginal 1.1Corrections/ Additions09-Dec-2019IIT Transition – Bogdan BeznaDefinition/Inventory Updates1.2Corrections/ Additions16-Dec-2019IIT SC Secretary – Joey LundgrenFormatting/Content Updates1.3Corrections/ Additions/Published16-Dec-2019IIT Transition – Chris CockerAccept changes, update Middle-Tier team naming convention, corrected in-document links.1.4Additions/Updates14-Jan-2020IIT Transition – Bogdan BeznaDefinition/Inventory Updates: Information Security Data Classification. App Deliveries and DBA deliverables updates.1.5Additions/Updates13-May-2020IIT Transition – Chris CockerAdded Sections 6.1/6.2, appendix D, and RTFS SME review. Added RIA/FRCR to deliverables. Updated Process workflow. Purpose of DocumentThe Transition to Operations Checklist is provided to guide and document completion of key transition deliverables outlined in the Natural Resource Ministries Systems Development Lifecycle (NRM SDLC) as well as other pertinent activities and artifacts relating to a product’s successful deployment into IIT environments and operational support. To ensure the success in transitioning applications and services into operational support, coordination is required between the project team and the IIT operational subject matter experts (SME) to identify transition requirements and confirm delivery. The objective of this document is to support awareness of transition deliverables and to provide risk identification and assessment from IIT operational teams regarding any unspecified, incomplete or missing transition acceptance criteria and/or operational support requirements. Any deferred items should be included into a backlog for the product’s lifecycle beyond the project close. The recommendations outlined in this document will form the basis of product acceptance into IIT operational support. ScopeThis checklist tracks deliverables pertaining to requirements for accepting a new/updated application(s) into IIT operational support. Deliverables that are outside of IIT operational support concerns (e.g. project management documentation/reports) are out of scope for this checklist and sign-off. AssumptionsThis document assumes the following conditions are met:The project has been provided with the SDLC and defined expectations based on the size/complexity of the project for the relevant deliverables.For large/complex projects, a stabilization period is defined for the product to assess operational readiness and transition criteria acceptance prior to the project close. Checklist Process/GovernanceDeliverables in Section 7.1 of this checklist are defined by operational subject matter experts (SME). They should be reviewed in the project planning phase by the project team and any additional project specific transition deliverables identified by the project team are to be outlined in Section 7.2. Checklist items are associated with the operational areas that view the deliverable as a requirement. During the transition phase, prior to project close-out, operational SME will complete the review outlined in Section 8 to:Validate the delivery of the identified itemsOutline any items that are incomplete or missingComment on the status of the product (accepted, not accepted) outlining any outstanding/associated risk and if necessary, mitigation strategyFollowing completion of the assessment provided by the operational teams, acceptance of transition to operational support is provided by the operational support sponsors in Section 9. Final sign-off and acknowledgement of the product transition review and, if applicable, any outstanding risk is provided in Section 10 by the project team lead and Section 11 by the product owner/project sponsor. Successful completion of this checklist and review process constitutes formal acceptance of a product into IIT operational support.See Appendix B for step-by-step instructions on completing the document. Project Transition OverviewComplete this section to give context of the product(s) the project is transitioning into IIT operational support, including any known relationships or dependencies to other existing NRM projects as well as the targeted infrastructure (e.g. ISSS, AWS Cloud, etc.). It should speak to high-level goals and objectives to be achieved during the transition phase. Link to external sources of project data (Project Charter, etc.) as necessary.The overview should consider the kind of transition approach taken, such as: Big Bang – implementation happens in a single deploymentPhased – implementation in phases over an extended period with multiple deploymentsParallel – legacy and new system run at the same time. A decommission plan should be considered for legacy systems that are being replacedCombinations of the above*Please remove this instruction text from the final document*Operational ServicesThe following table outlines the standard operational services involved in helping deliver the project and/or supporting project outputs as well as the operational support/advisory teams involved. This list will help define the operational scope of the project and the teams required to review transition deliverables. See Appendix C for Operational Service definitions and see Appendix D for operational team acronym definitions.In ScopeStandard Operational ServicesOperational Team(s)?Business Application SupportBSD, RTFS?Application Hosting ServicesBSD, AD, AIMT, QA?Database AdministrationBSD, DBA?Workstation Hardware Management – under developmentRTFS?Workstation Software Management – under developmentRTFS?Radio and Weather Station Services – under developmentRTFSAdditional Operational RequirementsComplete this section should any additional operational requirements from the project need to be outlined. Remove heading 6.2 if not applicable.*Please remove this instruction text from the final document* Transition Deliverables InventoryStandard Deliverables The following table(s) outlines deliverables that are typically considered for transition to IIT operations. See Appendix A for descriptions and interested support teams for each transition deliverable. The ‘Comments & Location’ section of the table should describe the current state of the deliverable and provide a link to its repository location where appropriate. Note: A copy of the table below is required for each application involved in the project.[Application Name]COMPLETED /ENABLED TRANSITION DELIVERABLECOMMENTS & LOCATION (LINK)Choose an item.Access RequirementsChoose an item.Architecture Diagram(s) Choose an item.Data Model (Logical/Physical)Choose an item.Database Capacity PlanChoose an item.Database Operations GuideChoose an item.Database Environment Rebuild GuideChoose an item.Defect BacklogChoose an item.Deployment PreparationChoose an item.Design DocumentationChoose an item.Developer GuideChoose an item.External contracts for support [in place]Choose an item.Financial Risk and Control ReviewChoose an item.Incident Management ProcessChoose an rmation Security Classification of Data???Choose an item.IRS UpdatesChoose an item.Licensing/Hardware/Software – transfer existing & renewal planChoose an work DiagramsChoose an item.Operations Manual Choose an item.Privacy Impact Assessment (PIA)Choose an item.Records Impact Analysis (RIA)Choose an item.Requirements DocumentationChoose an item.Resourcing ReadinessChoose an item.Role Based Access Control DefinitionsChoose an item.Security Threat and Risk Assessment (STRA)Choose an item.TrainingChoose an item.Transfer of testing documentation and artefactsChoose an item.User Acceptance Testing Sign-OffChoose an item.Vulnerability ScanAdditional/Project Specific DeliverablesThe following table(s) lists any project specific deliverables key to the transition phase and outlines the operational support area(s) that would consume the specified deliverable. A copy of the table below is required for each application involved in the project that has project specific transition deliverables.[Application Name]COMPLETED /ENABLED TRANSITION DELIVERABLEDESCRIPTIONOPERATIONAL SUPPORT TEAM(S)COMMENTS & LOCATION (LINK)Choose an item.Choose an item. Operational Subject Matter Expert Sign-offThis section is to be completed by the IIT Operations/Advisory teams. For each item, please consider if it has been delivered/enabled appropriately for your team. Comments should speak to current state and any recommendations, residual risks and workarounds/risk mitigation strategy. Deliverables marked not accepted require a comment. Information Security:Team Review Applicable:Choose an item.Team Lead/Representative:Date:Click or tap to enter a date.DELIVERABLEACCEPTED RESIDUAL RISKS/ RECOMMENDATIONS/WORKAROUNDSInformation Security Classification of DataChoose an item.Security Threat and Risk Assessment (STRA)Choose an item.Vulnerability ScanChoose an item.Additional Comments:Information Privacy:Team Review Applicable:Choose an item.Team Lead/Representative:Date:Click or tap to enter a date.DELIVERABLEACCEPTED RESIDUAL RISKS/ RECOMMENDATIONS/WORKAROUNDSPrivacy Impact Assessment (PIA)Choose an item.Additional Comments:Radio, Technology & Field Services (RTFS):Team Review Applicable:Choose an item.Team Lead/Representative:Date:Click or tap to enter a date.DELIVERABLEACCEPTED RESIDUAL RISKS/ RECOMMENDATIONS/WORKAROUNDSAccess RequirementsChoose an item.Architecture Diagram(s)Choose an item.Deployment PreparationChoose an item.Design DocumentationChoose an item.Developer GuideChoose an item.Incident Management ProcessChoose an item.CMDB/IRS UpdatesChoose an work DiagramsChoose an item.Operations Manual Choose an item.Requirements DocumentationChoose an item.Resourcing ReadinessChoose an item.TrainingChoose an item.Project Specific DeliverablesChoose an item.Additional Comments:NRS Business Service Desk – Tier 1 Operational Support (BSD):Team Review Applicable:Choose an item.Team Lead/Representative:Date:Click or tap to enter a date.DELIVERABLEACCEPTED RESIDUAL RISKS/ RECOMMENDATIONS/WORKAROUNDSAccess RequirementsChoose an item.External contracts for support [in place]Choose an item.Incident Management ProcessChoose an item.CMDB/IRS UpdatesChoose an item.Licensing/Hardware/Software – transfer existing & renewal planChoose an item.Operations Manual Choose an item.Resourcing ReadinessChoose an item.TrainingChoose an item.Project Specific DeliverablesChoose an item.Additional Comments:Maintenance & Support - Tier 2 Operational Support (MaS):Team Review Applicable:Choose an item.Team Lead/Representative:Date:Click or tap to enter a date.DELIVERABLEACCEPTED RESIDUAL RISKS/ RECOMMENDATIONS/WORKAROUNDSAccess RequirementsChoose an item.Architecture Diagram(s)Choose an item.Deployment PreparationChoose an item.Design DocumentationChoose an item.Developer GuideChoose an item.Defect BacklogChoose an item.Incident Management ProcessChoose an item.CMDB/IRS UpdatesChoose an work DiagramsChoose an item.Operations Manual Choose an item.Requirements Documentation Choose an item.Resourcing ReadinessChoose an item.TrainingChoose an item.Project Specific DeliverablesChoose an item.Additional Comments: Application Deliveries - Tier 3 Operational Support (AD):Team Review Applicable:Choose an item.Team Lead/Representative:Date:Click or tap to enter a date.DELIVERABLEACCEPTED RESIDUAL RISKS/ RECOMMENDATIONS/WORKAROUNDSAccess RequirementsChoose an item.Architecture Diagram(s)Choose an item.Deployment PreparationChoose an item.Incident Management ProcessChoose an item.CMDB/IRS UpdatesChoose an work DiagramsChoose an item.Operations Manual Choose an item.Requirements Documentation Choose an item.Resourcing ReadinessChoose an item.TrainingChoose an item.Project Specific DeliverablesChoose an item.Additional Comments:Application Infrastructure & Middle-Tier - Tier 3 Operational Support (AIMT):Team Review Applicable:Choose an item.Team Lead/Representative:Date:Click or tap to enter a date.DELIVERABLEACCEPTED RESIDUAL RISKS/ RECOMMENDATIONS/WORKAROUNDSAccess RequirementsChoose an item.Architecture Diagram(s)Choose an item.Deployment PreparationChoose an item.Design DocumentationChoose an item.Incident Management ProcessChoose an item.CMDB/IRS UpdatesChoose an work DiagramsChoose an item.Operations Manual Choose an item.Requirements Documentation Choose an item.Resourcing ReadinessChoose an item.TrainingChoose an item.Project Specific DeliverablesChoose an item.Additional Comments:Database Administration – Tier 3 Operational Support (DBA):Team Review Applicable:Choose an item.Team Lead/Representative:Date:Click or tap to enter a date.DELIVERABLEACCEPTED RESIDUAL RISKS/ RECOMMENDATIONS/WORKAROUNDSAccess RequirementsChoose an item.Architecture Diagram(s)Choose an item.Deployment PreparationChoose an item.Design DocumentationChoose an item.Incident Management ProcessChoose an item.CMDB/IRS UpdatesChoose an item.Requirements Documentation Choose an item.Resourcing ReadinessChoose an item.TrainingChoose an item.Database Capacity PlanChoose an item.Data Model (Logical/Physical)Choose an item.Database Environment Rebuild GuideChoose an item.Database Operations GuideChoose an item.Role Based Access Control DefinitionsChoose an item.Project Specific DeliverablesChoose an item.Additional Comments:Quality Assurance & Testing (QA):Team Review Applicable:Choose an item.Team Lead/Representative:Date:Click or tap to enter a date.DELIVERABLEACCEPTED RESIDUAL RISKS/ RECOMMENDATIONS/WORKAROUNDSAccess RequirementsChoose an item.Defect BacklogChoose an item.Design DocumentationChoose an item.Requirements Documentation Choose an item.Resourcing ReadinessChoose an item.TrainingChoose an item.Transfer of testing documentation and artefactsChoose an item.User Acceptance Testing Sign-OffChoose an item.Project Specific DeliverablesChoose an item.Additional Comments: Operational Sponsor Transition Sign-offNAME - ROLEACCEPTED(YES/NO)COMMENTSDATEFUNCTION REPRESENTEDPete Walter, Director Business Service Desk & Product Transition Choose an item.Click or tap to enter a date. REF _Ref520124554 \h \* MERGEFORMAT Product TransitionTier 1 & Tier 2 Operational Support: REF _Ref520124194 \h \* MERGEFORMAT Business Service Desk, Maintenance & Support.Adam Dewey, DirectorInfrastructure ServicesChoose an item.Click or tap to enter a date.Tier 3 Operational Support: REF _Ref520124367 \h \* MERGEFORMAT Application Infrastructure & Middle Tier, REF _Ref520124376 \h \* MERGEFORMAT DBA Team, REF _Ref520124388 \h \* MERGEFORMAT Application Deliveries, REF _Ref520124395 \h \* MERGEFORMAT GIS Services, QAJoel Murphy, DirectorRadio, Technology & Field ServicesChoose an item.Click or tap to enter a date.Radio, Technology & Field ServicesProject Team Sign-OffNAME - ROLEAPPROVED(YES/NO)COMMENTSDATEFUNCTION REPRESENTED[PM/ AEA/ MaS/ VENDOR LEAD]Choose an item.Click or tap to enter a date.Project TeamProduct Owner/Project Sponsor Transition Sign-offNAME - ROLEAPPROVED(YES/NO)COMMENTSDATEFUNCTION REPRESENTED[PRODUCT OWNER/ SPONSOR]Choose an item.Click or tap to enter a date.Business AreaAppendix A – Transition Inventory GlossaryThe following glossary outlines transition deliverables typically required by operational teams as outlined in Section 6 - Transition Deliverables Inventory. Standards, guidelines and templates that may apply to certain deliverables can be found on the NRS Standards Inventory webpage.See Appendix D for operational team acronym definitions.DeliverableDescriptionOperational Team(s)Access Requirements: Access for all support team members to necessary tools/sites such as: Jira ProjectApplication/infrastructure (servers)Code RepositoryAutomation tools Application id’s/usersSiteMinder/profile infoPassword pass-off (completed)Access management plan/documentation (who has access where)BSD, MaS,AD, DBA, AIMT, QA, RTFSArchitecture Diagram(s) Architectural diagrams show the relationship and/or interactions between different software and/or hardware components. MaS, AD, DBA, AIMT, RTFSData Model (Logical/Physical)Data Modeling aims to establish the entities, their attributes, and their relationships. Logical data model defines the structure of the data elements and set the relationships between them. Physical Data Model describes the database specific implementation of the data model.DBADatabase Capacity PlanThis plan should consider the following: Initial data size, Expected data growth, Backup requirements, Archiving Requirements, Data Classification, Data Replication (Warehousing), and Data Retention Policy.DBADatabase Operations GuideThis guide should consider the following: Data Refresh cycles [identified], Scheduled DB jobs/maintenance, and Database deployment/refresh procedures.DBADatabase Environment Rebuild GuideCreate/update the procedures and SQL scripts for recreating the application database. This guide can be used to rebuild an environment if the database is lost and there is no backup.DBADefect BacklogLocation of identified backlog of defect/bug lists – defining what has been deferred/addressed/accepted for the product. QA, MaSDeployment PreparationAs per TRCM Process which should include:-RFC/RFD-Deployment package-Deployment walkthroughMaS, AD, DBA,AIMT, RTFSDesign DocumentationDesign documentation includes: wire-frames/screen mock-ups, individual modules/components, and what the responsibilities, functions of the modules and classes are. Also, what they can/can’t do and what design patterns can be used.MaS, AD, DBA, AIMT, QA, RTFSDeveloper GuideA developer guide provides insight into developer on-boarding, API references, and other technical components. The guide should be useful to developers for continuous development as well as for troubleshooting purposes. MaS, RTFSExternal contracts for support [in place]Any support agreements to external parties are completed and in place.BSDFinancial Risk and Control ReviewA Financial Risk and Control Review must be conducted for any system that records financial transactions. Mark this as ‘Not Applicable’ for systems that do not.If the application will contain financial transactions, a Financial Risk and Controls Review must be conducted which requires involvement of Ministry of Finance resources and verifies that Chapter 13 of core policy is being followed.Tracked for completion, but not reviewed by operational teams.Incident Management Process Incident Management process has been mapped for the application. Ideally, this should fit the current IIT standard (contact the Business Service Desk team if a copy of this standard is required).Any new process/procedures (break/fix, incident, problem, etc.) need to be identified and migrated into the current process as part of the transition to operations.Consider the following items:Incident workflow & incident logging requirementsApplication criticality assessmentVendor requirements/responsibilitiesSecurity incident managementBSD, MaS, AD, DBA, AIMT, RTFSInformation Security Classification of Data??? The Information Security Classification of Data ensures government information and systems are protected in relation to value, sensitivity, and public need. The classification of the data is completed by the business units and stored and tracked by the Information Security team. This information, for example, may be used as part of a data move (PROD to DEV) in order to know what data needs to be sanitized.A completed Information Security Classification of Data template (available from the IIT Information and Security team) constitutes the completion of this rmation SecurityCMDB/IRS UpdatesUpdates to any relevant CMDB. All IIT managed applications should be catalogued in the Infrastructure Reporting System (IRS), the inventory management tool used by IIT to keep track of application dependencies and related infrastructure information. All information should be correct and up-to-date.IRS is used by support teams to ensure:Key Contacts are communicated to for application changes: (Vendor, Data custodian, App owner, stakeholders(s)Identifying integration points and identifying dependent applications: Servers, Environments (INT, TEST, PROD)Any Technical Change freeze periods are respected (Critical/Dark Periods)BSD, MaS, AD, DBA, AIMT, RTFSLicensing/Hardware/Software – transfer existing & renewal planOwnership of any licenses, hardware or software has been transferred to IIT (IMIT Financial and Contract Management), the length of validity has been identified and a plan is in place for upcoming renewals.BSDNetwork DiagramsFirewall information, proxy/reverse proxy, ports, protocolsMaS, AD, AIMT, RTFSOperations Manual Technical Documentation for troubleshooting, FAQ, known issues and exceptions, maintenance activities (security certificate renewals, etc.), application/error log locations, scheduled jobs (cron, etc.). BSD, MaS, AD, DBA, AIMT, RTFSPrivacy Impact Assessment (PIA)A PIA is created to ensure compliance with the Freedom of Information and Protection of Privacy Act when collecting, using or disclosing personal information.A privacy impact assessment must be completed for any new or changes to applications. The initial assessment must be completed for all initiatives to determine whether personal information is rmation PrivacyRecords Impact Analysis (RIA)A Records Impact Analysis (RIA) provides a structured manner of identifying the records that are used as inputs to the system and records and reports generated from the system.Additional information and templates are available on the NRM SDLC.Tracked for completion, but not reviewed by operational teams.Requirements DocumentationBusiness Requirements, Functional Requirements (include storage requirements and tier of SAN), Non-Functional Requirements. Link to Business Requirements Document, Software Requirements Specification Document and/or User Stories.MaS, AD, DBA, AIMT, QA, RTFSResourcing ReadinessAny additional resourcing requirements to implement operational support are in place. Link to resource plan.BSD, MaS, AD, DBA, AIMT, QA, RTFSRole Based Access Control DefinitionsDefine access privileges assigned to roles and the user types that should be assigned these roles.DBASecurity Threat and Risk Assessment (STRA)A STRA must be conducted when developing, implementing major changes to, or acquiring an information system.The Security Threat and Risk Assessment is a component of overall Risk Management. The STRA pertains to information, whereas the Risk Assessment covers all aspects of a project including equipment, funding, resources, etc.A signed Statement of Acceptable Risk (SOAR) constitutes the completion of an STRA. The SOAR documents all risks identified in the STRA, their ratings and planned treatment action, and that appropriate reviews and acceptance has rmation SecurityTraining Training on the product, procedures & technology completed for all operational support areas.Provide a link to training plan and any training documentation.BSD, MaS, AD, DBA, AIMT, QA, RTFSTransfer of testing documentation and artefactsIncluding:Test Plan Test StrategyRequirement Traceability ReportSoftware Test Scenarios and Test CasesTest DataDefect Report/Bug ReportTest MetricsTest Execution ReportTest Scripts (automation)Test Trace-ability MatrixConfiguration & Installation GuideUser GuideTest Execution ReportBugs/Defects ReportRelease NotesFinal (Test Project Closure) Test Status reportQAUser Acceptance Testing Sign-OffClient sign-off accepting User testing as being completed and accepting any outstanding defects as being deferred.QAVulnerability ScanVulnerability scans (finds vulnerabilities in your web application dynamically):Required by policy (Information Security Policy) and standards (Security Standards for Web Development and Deployment)Scans are to happen anytime there is significant change (OCIO defines significant as “requires a contractor/skilled employee to develop the change”)Scans should happen annually even if no changes have been doneRemediation timelines for found vulnerabilities should be based off risk (higher risk should equate to faster remediation)Recommend vulnerabilities be ranked based off CVSS score (Common Vulnerability Scoring System)Consideration of risk should include other applications if in a shared environment (i.e. your application is low sensitivity, but you share the environment with a highly sensitive application)CVSS scores of 9 to 10 (critical) are expected to be remediated immediatelyInformation SecurityAppendix B – Procedural Instructions In this appendix, the procedure for completing the checklist, operational team review and sponsor sign-off is outlined. A workflow diagram is provided as are step-by-step procedural instructions. Workflow:In Figure 1 below, the high-level workflow outlines a visual representation for the intended process for completing this document and achieving review and sign-off from all stakeholders.Figure 1: Transition to Operations WorkflowTransition to Operations Checklist Procedure:Project Team Process: Update the document metadata from the template: Rename this template to include the application name: Transition to Operations Checklist – [PROJECT NAME].Update the fields on the title page and document footer (Application Name, Ministry Name, PM/Lead name, Business Sponsor Name).Update Section 10 with the PM/Project Lead information.Update Section 11 with the Product Owner/Project Sponsor information.As project planning progresses, complete the Transition Overview (Section 6), identify the operational service requirements (Section 6.1), review the Transition Deliverables Inventory (Section 7) and determine what deliverables are/are not applicable for the project.For non-applicable deliverable, update the Section 7.1 deliverable(s) status’ with ‘Not Applicable’. Enter a comment to provide support for this decision.Example:Completed /Enabled Transition DeliverableComments & Location (Link)Not ApplicableDatabase Operations GuideProject has no database dependencies.* Tip:Contact the operational/advisory teams to assist with questions regarding specific deliverable(s)Update Section 7.2 with any project specific deliverables not already included in the inventory outlined in Section 7.1.As the project work progresses: Update the checklist for each deliverable:Update the status field with Yes/Partial/No as applicable.If applicable, provide a link to the artefact’s repository location (or alternatively provide a comment on status or location).Provide any additional comments that may help guide operations teams in reviewing the deliverable.Add and update any other project specific deliverables as required to Section 7.2 and update the fields as described above in steps a, b and c.Update Section 6 as required.Prior to anticipated go-live/production deployment (ideally 2-4 weeks), collaborate with the operational/advisory teams identified in Appendix E for completion of their review.Be prepared and available to answer questions that may arise during the review and sign-off process and aggregate the reviews into a master document when completed.Once all operations teams have completed their review, collaborate with the operational sponsors identified in Appendix E for their review.* Tip:Reviews can be assigning to teams/assignees using IMB Jira tasks. SharePoint or other collaboration tools can also be used as appropriate for teams/sponsors to add their plete the project team sign-off in Section 10 and coordinate with the Product Owner/Project Sponsor for the sign-off in Section 11.Once final sign-off is completed, notify stakeholders as appropriate and archive this document along with all other project documentation.IIT Operational/Advisory SME ReviewThis section is to be completed by the Operation Support Teams identified in Section 8.On receiving the assignment to complete the transition review, a team member will action the team lead to complete or delegate review of the checklist document per the defined action items found in Section 5 (Checklist Process & Governance):The assigned reviewer will then:Update the relevant section on behalf of your area in Section 8:Confirm review is applicable for your team (review Transition Overview in Section 6 and Section 6.1 if necessary). Provide a comment if review is not necessary.Add their name.Add the current date.If review is required, for each item, confirm if it is an acceptable state for your team/area and add appropriate comments regarding any residual risk, recommended next steps and/or workarounds/mitigation strategies.Add any additional comments at the bottom of the section.Notify the project team that the review has been completed on behalf of your team/area and return the completed document. The team/reviewer should be prepared and available to answer questions and escalate issues back to the project team that may arise during the sign-off process.Operational Sponsors Sign-Off:Once all operational SMEs have completed their assessments, the project team will notify the operational sponsors identified in Section 9 to:Review the operational SME assessments from their area of responsibility.Follow up with the SME should any additional questions or clarification be required. Provide Yes/No for acceptance of transition of the outlined applications into IIT support.Provide any additional comments that should be documented as part of the transition acceptance/rejection.Notify the project team that your sign-off has been completed.Product Owner/Project Sponsors Sign-Off: Following Operational Sponsor sign-off, the project team will coordinate with the product owner/project sponsor to:Review all assessments as necessary.In Section 10 and Section 11: Provide Yes/No for confirmation of review/acceptance of the transition to IIT operations and acknowledgement of any identified risks.Provide any additional comments that should be documented as part of the transition.Appendix C –Operational Service DescriptionStandard Operational ServicesDescriptionBusiness Application SupportApplication support calls are directed to the IIT Business Application Support Desk. Requests will be triaged and potentially escalated to other support teams (internal and external to IIT) as needed.Application Hosting ServicesApplications will be deployed and hosted on IIT managed infrastructure (e.g. ISSS) and supported by the various tiers of IIT operational support/advisory teams.Database AdministrationProject output(s) include a database component (e.g. database change, deployment, data insertion, data refresh).Workstation Hardware ManagementIncludes:Workstation/Printer/Plotter/MFD DeploymentsTesting and PackagingSpecial Hardware RequestsWorkstation RefreshesHardware InventoryMobile Training LabIT Asset Disposal ManagementWorkstation Test EnvironmentWorkstation Software ManagementIncludes:Software License ManagementSpecial Software RequestsTesting and PackagingOne-off Software InstallsSoftware InventoryRadio and Weather Station ServicesIncludes:Natural Resource Sector (NRS) Radio Repeater SystemBC Wildfire Service Fire Weather Stations (FWx)Handheld portable radiosMobile vehicle radiosRadio accessoriesRadio base stationsPortable Fire RepeatersFire Quick Deploy Weather StationsFire Camp radio communicationsRadio Over IP (ROIP)Vehicle GPS tracking unitsNRS Radio TrainingAppendix D –Operational/Advisory Team Acronym DefinitionOperational Support/Advisory team acronyms used in this document are defined in the table below.AcronymOperational TeamADApplication Deliveries - Tier 3 Operational SupportAIMTApplication Infrastructure & Middle-Tier - Tier 3 Operational SupportBSDNatural Resource Sector Business Service Desk – Tier 1 Operational SupportDBADatabase Administration – Tier 3 Operational SupportMaS Maintenance & Support - Tier 2 Operational SupportQAQuality Assurance & TestingRTFSRadio, Technology & Field ServicesAppendix E –Operational/Advisory Team Contact InformationOperational Support/Advisory teams and sponsors are outlined in the tables below. Note, this list is up to date at time of publication, roles and contact information are subject to change.TeamTeam Lead(s)Team ContactADAndreas WilsonCSNRApplicationDelivery@gov.bc.caAIMTLucas MontebelloInfrastructure.Middletier@gov.bc.caBSDJames Pinskenrsenquiries@gov.bc.caDBARaja PethanasamyCSNRDBA@gov.bc.caMaS Matt Brandwood/Stuart HallIIT.Tier2@gov.bc.caQALizette MonteiroIIT.QualityAssurance.TestingTeam@gov.bc.caRTFSDan Stoelwinder/Ewon Rose/Blaine AndersonNRM.TechServices@gov.bc.caSecurityEric ValikoskiCSNR.Security@gov.bc.caPrivacyEileen PadgettNRM.Privacy@gov.bc.caOperational SponsorContactPete Walter, Director Business Service Desk & Product Transition Peter.Walter@gov.bc.caAdam Dewey, DirectorInfrastructure ServicesAdam.Dewey@gov.bc.caJoel Murphy, DirectorRadio, Technology & Field ServicesJoel.Murphy@gov.bc.ca ................
................

In order to avoid copyright disputes, this page is only a partial summary.

Google Online Preview   Download