POL00337653
POL00337653
Post Office Limited - Document Classification: INTERNAL
@
HM IT Release Management Process
(Branch Counters)
Version - VO.4 Draft
POL00337653
POL00337653
Post Office Limited - Document
Classification: INTERNAL
For Internal Use Only
Contents
1 INTRODUCTION ....
11 PURPOSE .....
12 Score ..
13 DEFINITIONS
14 PRINCIPLES AND BASIC CONCEPTS OF RELEASE MANAGEMENT.
15 BENEFITS AND VALUE OF RELEASE MANAGEMENT ..
1.6 TRIGGERS...
1.7.1 Ideation...
1.7.2 Product Management.
1.7.3 Service Design and Transition
18 Process OUTPUT:
19 GOVERNANCI
YannnouurR eRe Bb
N
RELEASE MANAGEMENT OVERVIEW...
wo
3.1 SCOPING...
3.2 BUILD RELEASE..
3.3 SOLUTION VALIDATION AND INTEGRATION (SV&l)
3.4 ‘SYSTEMS ACCEPTANCE TESTING ..
3.5 PACKAGING.
3.6 Live Support Test (LST)
37
3.8 MovetOrtice (MO).....
3.9 GATING APPROVA\
3.10 DEPLOYMENT...
3.10.1 Early Life Support.
3.11 RELEASE CLOSURE
4 TYPICAL TIMESCALES...
5 PLAN RELEASE...
5.1 RELEASE PACKAGE ...
5.2 RELEASE TYP!
5.3 RELEASE SIZING
5.4 RELEASE APPROVAL .
5.5 UNAUTHORISED RELEASE...
6 COMMUNICATIONS ....
RM-HM-IT Release Management Process V0.4 - draft 20f 22
POL00337653
POL00337653
Post Office Limited - Document
Classification: INTERNAL
For Internal Use Only
7 MEETING STRUCTURE ...
71 Post OrFice RELEASE FORUM...
7.2 ‘SERVICE PROVIDER RELEASE FORUM...
7.3 RELEASE AUTHORISATION BOARD (RAB).
8 POLICY / PROCESS REVIEWS
9 CONTINUAL SERVICE IMPROVEMENT...
10 DOCUMENT CONTROL...
11 REFERENCES ..
12 COMPANY DETAILS ..
APPENDIX A — RELEASE ACCEPTANCE CRITERIA .
APPENDIX B — RELEASE MANAGEMENT RESPONSIBILITIES ..
Table of Figures
Figure 1 Release Management Overview...
Figure 2 Post Office Release Management Process ...
RM-HM-IT Release Management Process V0.4 - draft 3 of 22
POL00337653
POL00337653
Post Office Limited - Document
Classification: INTERNAL
For Internal Use Only
1 Introduction
1.1 Purpose
The purpose of this process is to establish a standard way of working for any functional additions or
updates to Horizon Next Generation Application (HNGA) at Post Office Ltd moving away from an
individual project driven specific deployment.
The aim is to establish a regular heartbeat of a quarterly counter releases moving away from an
individual project driven specific deployment.
Ownership of the Release process has moved from suppliers back to Post Office, through
collaborative working with project and service providers to review and manage Release
requirements and scheduling.
The process ensures that all testing, communication, and deployment mechanisms are in place, and
in line with those tested prior to deployment of new or modified functionality.
By collating changes into a single Release, controlled through the central schedule, the risk to branch
operations will be reduced by decreasing the number of unique deployments.
1.2 Scope
This document provides an overview of the Release Management process, which has been designed
in accordance with best practice, ITIL V3 (u. 2011).
The scope of this process covers only the Release Management process for the Horizon (HGNA)
Branch Counter Releases. Back office, infrastructure and client applications will utilise the release
management processes in place with the application Service Provider and are excluded from the
scope.
1.3. Definitions
Release Management defines a standardised process of managing, planning, scheduling, and
controlling the rollout of IT Service new products, updates and releases to the production
environment. It controls the lifecycle of releases with minimum disruption to Post Office, it’s
customers and end users. The focus of Release Management is the protection of the live
environment.
As defined in ITIL, a Release (also known as a Release package) is a set of authorised changes to an IT
service or system. This may include hardware, software, processes, documentation or any other
components that are necessary to successfully implement an approved change within the IT Services
environment.
1.4 Principles and Basic Concepts of Release Management
Release Policy — Policies attaining to the Release and Deployment in place to achieve a balance
between service stability, cost and agility
RM-HM-IT Release Management Process V0.4 - draft 4 of 22
POL00337653
POL00337653
Post Office Limited - Document
Classification: INTERNAL
For Internal Use Only
Release Identification — All releases identified uniquely with an identification number as defined in
Section 5.2 — Release Type
Release Component/Unit — A Release Component (also identified as a Release Unit) consists of the
functional changes to an IT system which are usually released together
Release Package — It describes the one or more Release Components which are being built, tested
and deployed together as one release
Release Deployment — Deployments can be made with all components released in one deployment
or a phased release. The deployment can be manual or automated.
1.5 Benefits and Value of Release Management
Other important objectives of Release Management are as follows:
© Ensures faster delivery of changed services at an optimum cost in a consistent process
e Reduces risk by ensuring that only authorised releases are deployed removing the likelihood
of illegal copies of software and introduction of viruses or malicious software
e Ensures that the new or changed services can meet the agreed requirements
¢ Improved use of resources through combined efforts when testing new Releases
© Minimisation of regression testing requirements by offering greater coverage than is
possible with small Changes that occur too frequently or too close together
Ensures proper knowledge transfer to Users, Operations & Support Staff
Error reduction through the controlled Release to the live environment
e Agreater success rate in the Release of hardware and software, therefore an improved
quality of service delivered to Post Office
¢ Acomplete audit trail of functional Releases to the live environment is maintained
1.6 Triggers
Release Management works closely with Demand and Change Management as a control for
deploying new or modified functionality into the production environment. The introduction of
Release components originates from a fully approved demand request.
¢ Post Office Demand Management
co Ensure each Demand is aligned to Post Office future strategic outcome (excludes
Ops Change)
o Ensure each Demand ID has an RTQ (where applicable)
o Each Demand ID has a respective Operational Change, Prove Plan, Business Case or
Project Change Request
o Notify key stakeholders to ensure robust delivery planning and execution (POL Test
Team, Service Teams, Release Team and Suppliers)
« Reference Data
o Requests for changes to Reference Data will be routed through a condensed process
as less complex and repeatable
o Requests will be submitted to the Reference Data Change Advisory Board (CAB) for
approval
RM-HM-IT Release Management Process V0.4 - draft 5 of 22
Post Office Limited - Document
Classification: INTERNAL
For Internal Use Only
Defect / Incident PEAK —
o. Acritical fix to a live issue resulting from a failure within the production
environment
© Present in the LIVE system
°
o. Isa fault that may need fixing
The Release Management process will work with the existing Business Readiness Assurance (BRA)
gating process to ensure completeness of awareness and approvals. Additional checks have been
integrated into the BRA Gating template for the Release Management process.
1.7.1 Ideation
e = Ideas raised, analysed
Approved
1.7.2 Product Management
<<Talk to Chris L>>
1.7.3 Service Design and Transition
<<Sangita/Stuart>>
1.8 Process Outputs
Release Management co-ordinates or provides the following outputs:
Release policy and planning
« Forward Release schedule calendar
e Release acceptance
* Details of Release contents
Release design, build and configuration
© Extensive testing to predefined and acceptance criteria
Roll-out planning
Sign-off of Release for implementation
Communication through the Release life cycle
Closure acceptance criteria
RM-HM-IT Release Management Process V0.4 - draft
Is, or appears to be, inconsistent with the agreed design or service specification
6 of 22
POL00337653
POL00337653
POL00337653
POL00337653
Post Office Limited - Document
Classification: INTERNAL
For Internal Use Only
1.9 Governance
The entry point for Release assignment will only be accepted through the Post Office Service Design
and Transition process. All requests will be considered approved and prioritised in readiness for the
Release assignment.
Throughout the Release lifecycle, stakeholders will be informed of progress through the weekly
Release Forum, chaired by Post Office Horizon Release Manager.
Release plans for HNGA will be audited periodically to ensure compliance to the Post Office Release
Policy.
Requested changes to HNGA are expected to be delivered in line with the Post Office Release Policy
and Process. Individuals who violate the change management policy may be subject to disciplinary
action.
RM-HM-IT Release Management Process V0.4 - draft 7 of 22
POL00337653
POL00337653
Post Office Limited - Document
Classification: INTERNAL
For Internal Use Only
2 Release Management Overview
Build System
“Reasest Plan Release Release Acceptance
(Scoping) (SV&1) Teron Test
tT
Prepare ,I Deploy Early Life Release
4 piaen Release I oo soymem Support Closure
(Packaging) I "3°23 cose PP
Rejected
Falled Deployment
Figure 1 Release Management Overview
High level summary of Release Management stages
1. Plan Release (Scoping) — Approved requests or defect received via the Post Office Service
Design & Transition process following evaluation and prioritisation. All other routes and
requests will be considered unauthorised.
2. Build Release (SV&l) — Issue all necessary work orders and purchase requests for the
development or customisation of the Release components.
3. System Acceptance Testing — Verification of the release through Post Office Horizon Test
Team. A Release cannot proceed until a Test Exit report has been signed off.
4. Prepare Release (Packaging) — In line with the agreed HNGA Release and Compliance
Baselines Scheduling ensuring a Release is prepared for the deployment.
5. Deploy Release — Deployment of the Release into the live production environment via a
Change Record, approved via the Post Office Change Advisory Board (CAB).
6. Early Life Support — To resolve any operational issues quickly during an initial period
following the Release deployment.
7. Release Closure -Formal closure of the Release verifying all activity logs and Configuration
Management System (CMS) are up to date.
RM-HM-IT Release Management Process V0.4 - draft 8 of 22
POL00337653
POL00337653
Post Office Limited - Document
Classification: INTERNAL
For Internal Use Only
3 Release Process Summary
The Release Management process will integrate with the existing Post Office Change Excellence
Framework following the steps defined by the BRA process. Projects will need the correct Gating
approval prior to progressing through the Release lifecycle.
Link to Business Readiness Assurance - Engaging the Business (sharepoint.com)
3 a Soe woaiene I [2
: << sr note
Pett ote we — Teneo
Testing Testis
tandove = covenant
Gee a ras stan
‘root
od senor
sen IT oh - *
Teor
Figure 2 Post Office Release Management Process
3.1. Scoping
On approval by Post Office Service Design and Transition the Post Office Horizon Release Manager
engagement with the Project Manager will be initiate to gather data to co-ordinate the planning of
the release content.
A deadline is set within the Release calendar for the content gathering of an individual Release, after
which additional items cannot be accepted to the committed work order. If project is delayed or the
original date unobtainable a future Release will be provided.
Once the timescales are understood agreement is sought from Fujitsu and the assignment confirmed
to the Project Manager. This will ensure sufficient capacity, resource and time to complete the work.
Regular meetings will be scheduled to maintain awareness of the project progress and impacts to
proposed schedule.
RM-HM-IT Release Management Process V0.4 - draft 9 of 22
POL00337653
POL00337653
Post Office Limited - Document
Classification: INTERNAL
For Internal Use Only
3.2 Build Release
Fujitsu are responsible for the development of each Horizon component within the release. (Refer to
Appendix B for Release responsibilites) An existing process has been agreed as defined in “Fujitsu
Services RMG BU Release Policy” (see Section 11 - References).
Monitoring of progress is undertaken through weekly meetings and reports with Fujitsu.
Delays to the development may impact the Release assignment resulting moving the component to
a future Release.
3.3 Solution Validation and Integration (SV&I)
Fujitsu will own the Unit and System Testing types, but the remaining test phases (e.g. System
Acceptance, Regression, UAT, Performance, Security and OAT) will be Post Office owned, as part of
the Software Development Lifecycle
Any development or change across the Post Office IT Landscape will need to be tested before
moving the code into the production environment.
3.4 Systems Acceptance Testing
All software changes to be implemented into Live must have undergone adequate verification and
validation subject to POL testing standards before release.
Any exception to the above must be underwritten by the Change Director and agreed with the Head
of Testing.
As a minimum, it is expected that all changes where testing is required have the following Minimum
Test Standards (MTS):
¢ Asigned-off Test Plan
e Test cases with expected results
¢ Traceability to requirements to assess coverage
° Test Results and defects recorded
Testing risks and issues documented
e Asigned-off Test Completion Report
Any remaining defects should be documented and mitigations in place with the signed approval to
proceed.
Release Management will ensure the completion of Release testing prior to moving to the next
phase.
Regression Testing of a Release is MANDATORY.
3.5 Packaging
Preparation of deployment package is undertaken by the End User Compute (EUC) provider,
following the “POL — EUC BCR — Counter Deployment Design -V2-30" (see Section 11— References)
RM-HM-IT Release Management Process V0.4 - draft 10 of 22
POL00337653
POL00337653
Post Office Limited - Document
Classification: INTERNAL
For Internal Use Only
For any new release of HNGA, the individual components that make up the release will first need to
be setup. These include:
© HNGA Component Applications
e¢ HNGA Install Task Sequence
HNGA Pre-Cache Task Sequence
¢ Configuration Item
Configuration Baseline
Baseline collection and sub-collections
HNGA Task Sequence deployment
Maintenance Windows
The revised code is transferred to the EUC Provider who will prepare the release for deployment
using the agreed tool set. Usually this comprises of a set of scripts and tools created by Provider that
is used to generate the personalisation functionality required when deploying Branch Counter
machines for Post Office.
All the individual files that make up the Release are packaged into a single MSI bundle before
importing into SCCM for distribution to client machines. This is to ensure that individual components
cannot be directly modified once they have been uploaded to the SCCM software library. If any
changes or updates are needed, a new MSI package is created with a new, unique version number
and GUID.
Further details are available in the reference documents “Post Office Counter Deployment Design”;
“HNGA Release and Compliance Baselines”; “BCR Counter Deployment Design”. (See Section 11 —
References).
Areadiness assessment for the deployment will be undertaken to check for any issues or risks in the
delivery of the Release that may affect the roll-out.
3.6 Live Support Test (LST)
Before a Release is deployed there are several additional layers testing that the must be successfully
completed.
The objective of the LST testing is to prove that the new version of HNGA can be deployed to a set of
physical devices of all hardware types that have been personalised and are in use, to confirm that
the HNGA application functions correctly and then to prove that the same devices can be rolled back
successfully to the previous HNGA version.
The Post Office LST environment is in a Fujitsu testing facility at Bracknell, being personalised to test
all deployments, including new HNGA releases.
Details to be inserted
RM-HM-IT Release Management Process V0.4 - draft 11 of 22
POL00337653
POL00337653
Post Office Limited - Document
Classification: INTERNAL
For Internal Use Only
3.8 Model Office (MO)
Post Office has 2 simulated branch environments located in Finsbury Dials, London. The Model
Office provides a live environment for final proving. Confirmation of successful deployment will be
requested prior to commencement of the deployment phase.
3.9 Gating Approval
No Release can be deployed until all criteria as documented with the Release Checklist — Appendix A,
have been met. It is the responsibility of the Release Authorisation Board to authorise the
deployment to the live production environment.
3.10 Deployment
The deployment of the new Release into the production environment will be undertaken in line with
agreed Release Plan following the procedures outlined in the POL-EUC BCR Counter Deployment
Design. (Refer to Section - 11 References further information.)
A Change Record will be raised for the deployment and presented to the Post Office CAB for
approval. Only approved changes will be actioned into the production environment.
A back out plan must be produced to document the actions to be taken to restore the service should
the deployment of the Release fail, either partially or full.
Change Management will ensure backout plans are in place for each Change within the Release, but
Release Management has a role to ensure that these operate together to create a Release back out
plan.
Horizon deployments will follow the agreed Computacenter process — “POL — BCR —- HNGA Release
and Compliance Baselines — vO-21” (see Section 11 — References)
Failure within deployment will require the Release and Change record to be updated, a Post
Implement Review to be conducted and the Release process to commence at the planning stage.
3.10.1 _ Early Life Support
Following deployment of a Release a period of Early Life Support (ELS) will be provided by
transitioning team (i.e. Staff involved in the Release process activities) as agreed within the Release
Plan.
The scope includes:
¢ Operational Support and knowledge transfer — working collaboratively with the operational
staff to resolve incidents and issues. Therefore, knowledge transfer will take place.
¢ Measuring and Improving — service compared to requirements to ensure fit for business.
Users — where applicable the new components or service are introduced to the users to gain
initial feedback. Improvements will be initiated if required
3.11 Release Closure
Closure of the Release will be actioned on completion of the Gate to Close. Any outstanding
concerns from a BRA representative will have to be resolved before approval to close can be given
by the SPO.
RM-HM-IT Release Management Process V0.4 - draft 12 of 22
POL00337653
POL00337653
Post Office Limited - Document
Classification: INTERNAL
For Internal Use Only
The outcome of release requests should be communicated post implementation by email to Release
Management and all relevant stakeholders within 24 hours.
A Release will be considered closed following approval from the Gating to Close. The Project
Manager must submit the Request To Close Report to the Portfolio Review Board.
4 Typical Timescales
Based on the average timeframes from previous deployments the following table provides estimated
timescales as a guide.
Phase Typical Timeframe (Working Days)
Scoping Release inclusion closes 1 month prior to SV&I
commencement
Solution Validation and Integration 25
System Acceptance Testing 10
Packaging 10
Live Support Testing 10
Gating - Approvals 5
Reference Data Testing 2
Model Office 2
Deployment — Friendly Site 1
Deployment — Production 500 1
Deployment — Tranche 1 4
Deployment — Tranche 2 1
Deployment — Tranche 3 1
RM-HM-IT Release Management Process V0.4 - draft 13 of 22
POL00337653
POL00337653
Post Office Limited - Document
Classification: INTERNAL
For Internal Use Only
5 Plan Release
The main aim of Release Planning is to provide a set of guidelines regarding what should be included
in a Release and how it will be deployed into production. Establishing a standard planning process
ensures better communication between Service Transition, Demand, Change and Configuration
Management, and all stakeholders impacted by the various changes included within a Release
Package.
The plan shall include:
5.1
Summary of Release including
release owner type of release,
reason for release,
changes included in the release
Risk analysis of Release
Identification of stakeholders
Communication plan for customers, stakeholders, internal and external service teams
Definition of the chain of approval, including approval of Change Management
Definition of the strategy for deployment
Determine a time schedule
Criteria for Release measurement of success and closure
Release Package
The type and the authorisation level for a release request is established based on an assessment of
the following factors:
The amount and complexity of Change included in each Release Component
The number of resources and time required to build, test, distribute and deploy the Release
Package
Ease of implementation, including the complexity of interfaces between the proposed
Component and the production environment
The capacity availability to build, test and deploy to the production environment
Whether the change had been made previously or is a new product/Customer
5.2 Release Type
Type Definition Identification
HNGA Contains large areas of new functionality xy.2z e.g. 72.10, 72.20...
Quarterly (project driven), of which some may be
intervening fixes to Problems. x = Horizon Counter
Quarterly Release
Ty. = Year (e.g. 2022, 2023...)
RM-HM-IT Release Management Process V0.4 - draft 14 of 22
Post Office Limited -
Document
Classification: INTERNAL
For Internal Use Only
POL00337653
POL00337653
Outstanding defects (PEAKS) will be added
based on priority and capacity within the
Release.
.22 = Quarter (xy.01 first,
xy.02 second..)
Data Centre
Data Centre services and systems may require
2.x
Release updates to be compatible with the Branch
Counter Release. First digit “2” denotes Data
Centre
PED Device Pin Pad devices can require updates for 9x.xx
updates and/or security. These will involve the
3"? Party Provider — Ingenico
First digit is “9”
Maintenance Non-counter Confirmed Live Defects will be TBC
Release automatically targeted at a numbered
Maintenance Release (existing or new) so a
dated route to live is proposed as quickly as
possible.
Security Undertaken monthly to ensure branch devices I Month.Year
Patching are protected from latest vulnerabilities.
Release Testing, packaging and deployment is
undertaken by the EUC provider.
Reference Data
Contains only amendments or additional
Reference Data.
5.3
Release Sizing
To determine the packaging requirements (capacity, processing etc.) the risk and impact considered.
High Medium Low
High Large Large Medium
Medium Large Medium Medium
Low Medium Low Low
Release Risk
The Risk to the business is considers the complexity, type of change, technology and completeness
of testing. There are three risk categories.
Remediation plan unavailable, not fully tested or fix forward only
Release validation dependant on user testing
Release to business critical services & Cl’s or of high IT security relevance
RM-HM-IT Release Management Process V0.4 - draft
15 of 22
POL00337653
POL00337653
Post Office Limited - Document
Classification: INTERNAL
For Internal Use Only
Deemed to be very complex
Release involves input from multiple support areas and/or partners
Release not tested pre-deployment
First time of release type in live production environment, no previous experience
Remediation plan available
Release can be validated immediately post implementation or may be dependent on user testing
Release to business critical services & Cl’s or of medium IT security relevance
[Deemed to be of moderate complexity
Release may involve input from multiple support areas and/or partners
Pre-deployment testing possible
Successful implementation of pilot & subsequent phased rollout
Previous experience of release type, expertise moderate/high
Remediation plan known and tested
Release can be validated immediately post implementation
Release to a non-critical component
Non-complex release
Release does not require input or support from other areas/partners
Release tested successfully in an environment that fully replicates the live environment
ISignificant history of successful implementation
Release Impact
Impact is a measure of how the Release component will affect IT Service, business processes, users
and other partners. Releases that impact or require support from more than one partner must be
categorised High.
There are three impact categories:
Causes major impact to service, which may be during working hours
Affects Critical or Essential services, applications or infrastructure
Affects entire business or all branches
Another partner is impacted or required to support the release
Comms required
Causes impact to service outside working hours
Affects Critical or Essential services, applications or infrastructure
Affects whole departments or parts of the business
May impact another partner or require support
Comms may be required
Causes minimal or no impact to service
No impact or support required from another partner
No comms required or defined comms plan in place
RM-HM-IT Release Management Process V0.4 - draft 16 of 22
POL00337653
POL00337653
Post Office Limited - Document
Classification: INTERNAL
For Internal Use Only
5.4 Release Approval
The standard BRA template will be used to capture the Release Management requirements and
associated approvals.
5.5 Unauthorised Release
All unauthorised releases are subject to a formal Post Implementation Review (PIR) having not met
the requirements of the Release Management Process. They have been implemented:
¢ Without being fully approved and scheduled via the Release Management Process
¢ Without following the agreed and approved process, plans, procedures or actions
© Before the agreed start time
© After the agreed end time
6 Communications
Communications in relation to the Release will be provided as agreed within the Release Plan.
Where communications are required to a branch to inform of downtime or impact on operational
duties, the Release should be approved a week in advance to allow for the 5 day lead time for
branch notifications, as required by the POL Comms team.
7 Meeting Structure
7.1 Post Office Release Forum
The forum will be responsible for:
@ managing future release schedule, including awareness of any conflicts
review and maintain risks/issues for all Releases
Representation for on-going or future projects to be assign to a Release is required to assist with on-
going issues and future scheduling. The forum aims to resolve scheduling conflicts where content
capacity of a Release is breached.
7.2 Service Provider Release Forum
Outputs from the Post Office Release Forum will be taken forward to the Service Provider meeting to
agree content, scheduling and manage risks/issues.
RM-HM-IT Release Management Process V0.4 - draft 17 of 22
POL00337653
POL00337653
Post Office Limited - Document
Classification: INTERNAL
For Internal Use Only
The forum provides a base to discuss future work ensuring planning of best fit for upcoming
releases.
73 Release Authorisation Board (RAB)
The objective of the RAB is to ensure that the all components of the Release package have approved
sign-off prior to deployment.
Key consideration factors include:
Development Completed to the requirement specification with change control sign off
for any deviations
Testing Full system, integration, business acceptance has been agreed with defects
resolved or acceptance documented
Deployment Deployment plan is the same as tested with no defects, back out plans in
place, preparation of the environment has been actioned and change
requests in place
The board will consider the evidence for each element and provide the “Go / No-Go” for the
deployment to live.
8 Policy / Process Reviews
The effectiveness and efficiency of the Release Management process is reviewed continuously as
such the process may release at any time.
9 Continual Service Improvement
The Continual Service Improvement (CSI) process is owned by the service performance team. It is the
responsibility of Release Management to capture information that feeds into the CSI plan for
Release Management. Post-implementation reviews are mandatory for failed Releases where the
end-to-end process for that release is reviewed. Lessons learnt & actions are outcomes of this
meeting. These improvements feed into continual service improvement.
RM-HM-IT Release Management Process V0.4 - draft 18 of 22
POL00337653
POL00337653
Post Office Limited - Document
Classification: INTERNAL
For Internal Use Only
10 Document Control
Date Version Updated By Details
01-Sept-2021 0.1 Draft I I Humphries Initial draft
30-Sept-2021 0.2 Draft I Humphries 2°? Revision — Revision in line with BRA
process
19-Nov-2021 0.3 Draft I Humphries Amendments to roll-out planning.
21:Dec-2021 0.4 Draft I Humphries Revised in line with developed processes
11 References
Document Version/Date Location
Post Office Counter V2-30, 6-Jul-2018 POL — EUC BCR — Counter Deployment Design —
Deployment Design V V2-30.docx
HNGA Release and Compliance I 24 September 2018, POL-BCR — HNGA Release and Compliance
Baselines Vo-21 Baselines — VO-21.docx
BCR Counter Deployment 6 July 2018, V2-30 POL-EUC BCR — Counter Deployment Design —
Design V2-30.docx
Fujitsu Services RUG BU PA/STR/003, 14-Sept- I PASTROO3.doc
Release Policy 2010
IT Release Management Policy I TBC TBC
12 Company Details
Post Office Limited and Post Office Management Services Limited are registered in England and
Wales. Registered numbers 2154540 and 08459718 respectively. Registered Office: Finsbury Dials,
20 Finsbury Street, London EC2Y 9AQ.
Post Office Management Services Limited is authorised and regulated by the Financial Conduct
Authority (FCA), FRN 630318. Its Information Commissioners Office registration number is
ZA090585.
Post Office Limited is authorised and regulated by Her Majesty’s Revenue and Customs (HMRC), REF
12137104. Its Information Commissioners Office registration number is 24866081.
RM-HM-IT Release Management Process V0.4 - draft 19 of 22
POL00337653
POL00337653
Post Office Limited - Document
Classification: INTERNAL
For Internal Use Only
Appendix A — Release Acceptance Criteria
RM-HM-IT Release Management Process V0.4 - draft 20 of 22
Post Office Limited - Document
Classification: INTERNAL
For Internal Use Only
Project Name:
Release Stage:
Planned Start Date:
/Planned completion Date:
[snow Project Ref:
PENDING: Work still needs to be done.
IN/A: This item cannot logically apply.
IWAIVED: This item could apply, but the stakeholders deem it unimportant.
DONE: The stakeholders agree that the item has been satisfied.
FAILED: This item has forced us to abandon this release.
STATUS KEY
Requirements and user stories for this release have been agreed upon.
All issues from the prior release have been identified and added.
The product owner and other stakeholders agree with the release plans.
BUILD
All needed design work has been completed.
All needed design work has been reviewed.
All development work has been completed.
All development work has been peer reviewed.
All defects assigned to this release have been fixed.
All development documentation has been updated.
All unit test code has been updated,
The development team is satisfied with this release.
The testing plan and test cases have been updated.
The testing plan has been completely carried out.
All discovered defects have been logged.
Any change requests or spec updates due to defects have been addressed
All fixed defects have been verified as fixed.
The Testing team is satisfied with this release.
PREPARE
Packaging handed over to EUC partner
Packaging of release complete
Business approval completed
The User documentation has been updated.
Communication with the Branchess has been planned and executed.
Model Office testing was successful, and issues were fixed.
The impact of any changes on other products / operations has been determined and
addressed
Support documentation has been updated.
The tech support and operations teams are satisfied
Training materials have been updated.
Training is satisfied with this release.
DEPLOYMENT
All target devices have been properly tagged for release, and the release configuration
is clearly defined.
Change-control practices have been followed, meaning that the released product does
not contain unapproved changes.
this release.
The rollback plan has been prepared.
Create a backup of the build environment, and place the development environment
under change control.
Depoyment completed as plan
RELEASE MANAGEMENT
Formally announce the release internally.
Release Plan in place.
Post release, check in with the project stakeholders for feedback on the release.
STATUS
STATUS
STATUS
STATUS
PLAN STATUS PARTY RESPONSIBLE
PARTY RESPONSIBLE
TESTING STATUS PARTY RESPONSIBLE
PARTY RESPONSIBLE
PARTY RESPONSIBLE
PARTY RESPONSIBLE
RM-HM-IT Release Management Process V0.4 - draft
21 of 22
POL00337653
POL00337653
Post Office Limited - Document
Classification: INTERNAL
For Internal Use Only
Appendix B — Release Management Responsibilities
POL00337653
POL00337653
Stage Responsible
Demand Management Post Office Ltd
Scoping Post Office Ltd/Fujitsu
Development Fujitsu
SV&I Fujitsu
System Acceptance Testing Post Office Ltd
Packaging Computacenter
LST Fujitsu
Gating Post Office / Fujitsu (own process)
RDT Fujitsu
Mo Post Office
Deployment Computacenter
RM-HM-IT Release Management Process V0.4 - draft
22 of 22