Xoserve Change Management: Guiding Principles

Context This deck details a set a guiding principles for future change management at Xoserve The principles set out how Xoserve plans to engage with stakeholders to identify, assess and schedule future IT changes Xoserve is keen to discuss the principles with industry stakeholders before developing the detailed mechanics of a future change management process A glossary is also included within the deck to clarify the definition of a number of key terms Additionally, an indicative process diagram has been drafted to illustrate (at a high level) how the guiding principles could be employed in practice

Glossary of Terms The table below provides definitions for the key terms used throughout this deck N.B. The definitions are specific to the context in which the terms are applied within the deck rather than an industry standard definition Term Definition Change Management An overarching term encompassing the processes, tools and governance associated with the identification, assessment and scheduling of all IT changes A ‘Release’ An approach for delivering IT change whereby multiple changes are targeted for a common delivery date Release Management The processes, tools and governance associated with delivering change in releases Continuous Delivery Stream An on-going change function which is utilised to deliver low risk minor change. Deployments are ‘as required’ and are not bound by defined release dates Change Packages A significant volume of change comprising of multiple changes bundled together Impact Assessment A process for assessing the scale and complexity of a proposed change. Impact assessments can be high level or detailed Stabilisation Period A period following an implementation where it’s anticipated that system stability issues may be encountered. Accordingly the deployment of further change during this timeframe is closely controlled with implementations focused on addressing stability issues rather than delivering additional functionality

Draft Change Management Principles A draft set of guiding principles for Xoserve’s future change management process are detailed below Change Management Principles Benefits / Rationale Release Management Xoserve will adopt a change management approach which allows for change to be delivered at different paces Enables Xoserve to balance agility and speed of delivery with levels of delivery risk Xoserve will deliver low risk / incremental change via a continuous delivery stream To prevent low risk change from being unnecessarily constrained by a release date Xoserve will deliver change packages at agreed target release dates Provides clear target delivery dates for significant changes and thus enables more effective planning (for Xoserve and industry stakeholders) Certain changes may necessitate deviating from an agreed release date (e.g. regulatory change with a mandated implementation date such as Faster Switching) The release management process must be able to accommodate such requirements To ensure that the release management process is sufficiently flexible to deliver priority change All change will be categorised to determine whether it is best delivered via a release or by a continuous delivery stream To enable effective management of the change pipeline and to ensure all sources of change are routed into an appropriate delivery lifecycle The number of releases (release strategy) may vary between delivery years depending on the pipeline of change To allow the release strategy to flex to accommodate major change programmes such as UKLP Scope Management A demand ‘cut off date’ will be used to set a deadline by which changes must be identified in order to be factored into a change package for the next delivery period To encourage the industry and internal teams to focus efforts on readying change for assessment in a cyclical manner Criteria are needed to define the requisite level of maturity/requirements certainty necessary for a change to be factored into a change package To ensure that the requirements of each change package are sufficiently defined to enable impact assessment and delivery planning The demand ‘cut off date’ will be at fixed junctures within each delivery year To enable Xoserve to align processes (e.g. the IA process) around fixed dates To enable external stakeholders to align their internal change process to set date(s)

Draft Change Management Principles Benefits / Rationale Scope Management All change raised by this deadline will be impact assessed to determine resource requirements (all types) needed to deliver the changes as a change package within the next delivery period Following impact assessment the change package is baselined (at this point the target delivery date may also be refined) To ensure the delivery approach and precise timeline is defined on the basis of an impact assessment (which will include inputs from service providers) A mechanism is needed to amend a baselined change package to accommodate priority changes (an exception process) The exception process may alter a change package composition (adding, removing or replacing changes) and / or release date The exception process will employ clear, commonly understood criteria to determine whether a newly proposed change can be considered as an exception To enable Xoserve to respond to priority change To enable scope to be modified without jeopardising delivery To ensure there is suitable justification to amend an agreed baselined change package Customer / Stakeholder Engagement Delivering change within releases will require stakeholders to proactively manage their pipeline of change requirements and engage early with Xoserve on these requirements To ensure change management is proactive rather than reactive The scope of each release will be defined collaboratively with Xoserve’s stakeholder groups (including updates to an agreed baseline) and engagement will begin well in advance of the demand cut off date To ensure that change package definition considers the key priorities of the all stakeholders To improve stakeholder ‘buy in’ within the process and of the ultimate baselined scope For regulatory change, release management will be facilitated by existing industry governance fora e.g. UNCC & UKLC Managing change falls within the vires of existing industry fora To enable a process to be operationalised efficiently (as it won’t be dependent on the establishment of a new governance body) Stabilisation A ‘stabilisation’ period will be applied following the implementation of a change package To enable any post implementation issues (code issues and increased exception levels) to be addressed before further significant change is introduced During a stabilisation period further deployments will be closely controlled (low risk / deployments addressing specific stability issues will be permitted) To safeguard against further adverse impacts to system stability but not unnecessarily prevent the deployment of essential or low risk change The stabilisation period will vary in length depending on the quantity / complexity / criticality of the change deployed As increased levels of instability are expected following a major deployment The stabilisation period will be extended if significant post go-live instability is experienced (incident and exception numbers will provide metrics) and this extension may impact a subsequent target release date Prioritisation of existing service over future change Will ensure future change is deployed into a stable environment

Release Management High Level Process The diagram below applies the guiding principles outlined on slides 4 & 5 into a high level process The diagram shows a planning cycle and delivery cycle. In practice both planning and delivery would operate in a given year with the planning in year 1 defining the delivery in year 2 Demand definition soft deadline Demand definition cut off Continuous Delivery Stream Target Release Date Change Package CP CP1 Baselined CP1 Lock Down / CP2 Baselined CP2 Lockdown CP1 Impact Assessment (IA) CP1 Exception Process CP2 IA CP2 Exception Process Early Engagement Planning Cycle Delivery Cycle Exception Process for ‘Fixed Implementation Date’ Change CP2 Delivery CP1 Delivery Service development will lead continuous engagement activities with industry stakeholders to develop changes prior to each demand cut off date An on going exception process is needed to manage changes with fixed implementation dates (e.g. Faster Switching). Irrespective of when such a change is raised it will need to be assessed to ascertain the impacts of delivering it by the mandated date. This may necessitate an alteration to an already defined change package (scope or delivery date) Target delivery dates are predefined but not fixed and will be refined following impact assessment. Target delivery dates may vary between delivery years

Next steps Continued engagement with industry stakeholders via the appropriate forums e.g. UKLC Develop the mechanics of the processes and tools required to operate the future change management process Employ the newly defined processes and tools for the next major implementation following UK Link Programme go-live