1. Xoserve Change Management: Guiding Principles

2. 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

3. 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

4. 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)

5. 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

6. 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

7. 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