Please enable JavaScript in your web browser to get the best experience.

Switching Programme: Change Management

Guidance

Publication date: 22 June 2018
Industry sector: Supply and Retail Market; Distribution Network

Related links

The Switching Programme is now in the Enactment phase. During this phase, DCC will procure the CSS and the other services needed to secure the successful delivery of the CSS, and other parties will be expected to mobilise in preparation for the Design, Build and Test phase (DBT). Ofgem will also draft and make the required changes to market participant licences and industry codes that will give effect to the new switching arrangements.

Work during the Enactment phase of the programme may identify potential changes to the baselined requirements and other baselined products already produced by the programme. We will manage these through a defined and transparent change control process. Note that this change control process will run until the start of the DBT phase; we will review this process ahead of DBT.

Any programme participants can raise a change request, and all programme participants can input into discussion of change requests.

To submit a change request please complete the Change Request Form and submit it to SwitchingPMO@ofgem.gov.uk. Please note that only one change must be submitted per CR form; if there are multiple changes then separate CR forms need to be submitted. A change to one policy position that impacts multiple products can be submitted on one CR form. The date you submit the completed CR form to us will determine the change window the CR will be part of; this tells you the key dates in the review and decision making process that your CR will follow (change windows, and the subsequent process, is explained in more detail in the ‘How the process works’ section below).

We will maintain and publish a Switching Programme Change Control Log. We will update this Log at the end of each change window, and whenever there is a change to the status of a change request. Products that are updated as a result of a CR will be up-issued and republished on the relevant product page on the Ofgem website once they have been approved – see links to product pages under 'Related Links' above.

If you wish to be informed of changes

We will issue email notifications to an industry-wide distribution list whenever we receive a change request and when change requests, and their impact assessments, are submitted to the relevant governance groups for industry engagement e.g. the Design Forum. This one distribution list will be used to for changes covering the full scope of the Switching Programme (Design, Delivery/Implementation, Procurement, Regulatory and Governance).

If you wish to be on the distribution list for receiving these emails, please email us at SwitchingPMO@ofgem.gov.uk. We suggest that you have these emails sent to a central ‘shared mailbox’ with a generic email address that several people at your organisation can access. If preferred, you can provide the names and email addresses of multiple people in your organisation to receive these emails.

The change control process outlines how we will manage change during the Enactment phase up until the beginning of DBT. It also sets out the high-level roles and responsibilities of various parties at different parts of the process (Raise, Assess and Do phases). For example, we would expect the person or party that raised the CR to support the Impact Assessment (IA) team and to contribute to the production of the IA.

A programme-led IA team will produce an IA for every CR received; this will be the primary channel through which industry input on the CR will be captured (through discussion at the relevant governance group e.g. Design Forum), and it will form the basis on which the decision on the CR is made. Whilst the effort and detail in producing the IA will be proportionate to the change being proposed, an assessment will be carried against the following criteria:

Cost to implement the change – who will those costs fall to, what impact does that have on the programme business case;
Benefits of the change – what will be achieved by making the change, who do those benefits accrue to, is there a clear cost benefit case for the change;
Resourcing – what sort of costs will be incurred in the process of making the change (e.g. updating products or systems), who will those costs fall to, how will they be met, is the resource available to do the work on the required timescales;
Timing impact of the change – what does it do to the programme timelines, taking into account any impact on the procurement process, parties implementation activities, drawing resources away from other areas of the programme etc.;
Security – what, if any security or privacy impacts or implications need to be considered as part of this CR?
Is the change consistent with the programme’s Design and Architectural Principles?

NB - A change will only be approved where there is a clear and justifiable case for it.

Change Windows

To aid the management of the change control process, and to give stakeholders visibility of when they can/will be able to provide input, CRs can be submitted during two-week rolling change windows. A new consideration and approval process, as outlined in the process map, will start when each change window closes. As a new change window will start every two weeks, there will be multiple consideration and approvals processes running at the same time, albeit two weeks behind each other.

By arranging the process in this way we can map out all the governance and industry engagement meetings up until the beginning of DBT – see provisional dates in the below table. This provides industry with advanced visibility of when they will be required to provide input into the process and when decisions on specific CRs will be made. The table below will be regularly updated to show which CRs are being considered in each change window, further allowing industry to ensure that the right people are available to provide input at the required point e.g. attend a specific Design Forum meeting to discuss a specific CR.

Provisional Change Window Dates:

Change Window	CR Submission Window	Design Forum Paper Day	Design Forum Meeting	Design Authority Paper Day	Design Authority Meeting
10	29 Oct 18 - 09 Nov 18	19-Nov-18	26-Nov-18	30-Nov-18	07-Dec-18
11	12 Nov 18 - 23 Nov 18	03-Dec-18	11-Dec-18	14-Dec-18	02-Jan-19
12	26 Nov 18 - 07 Dec 18	17-Dec-18	07-Jan-19	11-Jan-19	18-Jan-19
13	10 Dec 18 - 01 Jan 19	09-Jan-19	16-Jan-19	22-Jan-19	29-Jan-19
14	02 Jan 19 - 11 Jan 19	21-Jan-19	28-Jan-19	01-Feb-19	08-Feb-19
15	14 Jan 19 - 25 Jan 19	04-Feb-19	11-Feb-19	15-Feb-19	22-Feb-19
16	28 Jan 19 - 08 Feb 19	18-Feb-19	25-Feb-19	01-Mar-19	08-Mar-19
17	11 Feb 19 - 22 Feb 19	04-Mar-19	11-Mar-19	15-Mar-19	22-Mar-19
18	25 Feb 19 - 08 Mar 19	18-Mar-19	25-Mar-19	29-Mar-19	05-Mar-19
19	11 Mar 19 - 22 Mar 19	01-Apr-19	08-Apr-19	12-Apr-19	19-Apr-19
20	25 Mar 19 - 05 Apr 19	15-Apr-19	22-Apr-19	26 Apr-19	03-May-19
21	08 Apr 19 - 19 Apr 19	29-Apr-19	06-May-19	10-May-19	17-May-19
22	22 Apr 19 - 03 May 19	13-May-19	20-May-19	24-May-19	31-May-19
23	06 May 19 - 17 May 19	27-May-19	03-Jun-19	07-Jun-19	14-Jun-19
24	20 May 19 - 31 May 19	10-Jun-19	17-Jun-19	21-Jun-19	28-Jun-19
25	03 Jun 19 - 14 Jun 19	24-Jun-19	01-Jul-19	05-Jul-19	12-Jul-19

Where a particular CR is especially complex and requires discussion/input at multiple Design Forums, this CR will move change windows to the one related to the Design Forum it was last submitted to. This will provide industry with visibility of where the CR is in the process and when a decision is expected to be made.

Variations to the Process

The process map also explains the variations to this default process and when they will be used. Very broadly these are:

An expedited process for changes where a decision is needed quicker than the default process would allow e.g. changes that would have an impact on the procurement process
An abridged process will be used for very minor changes e.g. typographical changes or for example to correct an error in a diagram (as long as the correction to the diagram would bring it into line with the policy outlined in the rest of the document; if the change to the diagram would change the policy outlined in the rest of the document then the full default process would be followed)
Changes to Security products will be broadly considered and approved via the same process, but we will also utilise the input from our Security Working Group.
During the procurement process, once CSS tender packs have been issued (expected mid-end August 2018) we will not issue any updated or re-baselined products until the best and final offer (BAFO) stage of the procurement is reached (expected end November 2018). This is to ensure that bid submissions and evaluation activities are carried out against a stable baseline. During this period we will still accept and consider CRs, but any updated products will not be published until the period ends.Note, for products that are to be updated as per an approved change request, but the product(s) can not be updated ahead of CSS tender packs being issued, the updated versions of these products will not be published until the BAFO stage is reached.