Where we explore the individual elements of the change process and how you might expect to engage
It sets out the path that a change takes - from the raising of a Change Proposal to decisions on implementation. It identifies the various opportunities for stakeholder engagement. And it details the obligations on the Code Manager at each turn.
In this section, we will guide you through each element of the process, providing explanation about the various activities, how you can expect to find information, and how you can engage in the process yourself.
We will cover the following areas - you can click the links to be taken straight to the relevant page:
How do I submit a Change Proposal?
How does the Code Manager validate Change Proposals?
How do I view information related to a Change Proposal?
How are impacts to other codes assessed?
What is the Initial Assessment process?
What is the Initial Assessment Report?
What is Solution Development?
What is the Impact Assessment process?
What is the Preliminary Change Report?
What is the Code Manager Recommendation?
What is the role of the Responsible Committee?
What is the process for Consultation?
What is the Final Change Report?
What is the process for raising an appeal?
What does it mean when a Change Proposal is Withdrawn?
What is an Alternative Change Proposal?
What is a Housekeeping Change Proposal?
What is the Category 3 Change Process?
Have a question about the Change Management process that isn't addressed in this User Guide? Email Service Desk
Any interested person, stakeholder, REC Party or the Code Manager can submit a REC Change Proposal.
We'd welcome a conversation with you before you decide to raise a Change Proposal. We can help you decide whether a Change Proposal is the right route to resolve an issue, help clarify your (and our) understanding, support you in developing the Change Proposal, or explore the issue with you in more detail. It's possible that we might already be exploring a similar issue, so it can be efficient to engage with us early.
Send us an email or raise a Service Desk ticket, we'll get back to you no later than the next working day.
Email the Service Desk
Raise a Service Desk ticket
Decided to go ahead and raise a Change Proposal? Great! You can do this directly through the REC Portal by completing a Change Proposal form. This is accessed through the 'Change and Release' page. It's a wizard that will lead you through the stages of raising a Change Proposal, detailing the information we will need from you.
As you complete the form, it automatically saves as you go. If you start to complete a form but do not complete it, your part-completed form will be saved and available when you later return.
When you're ready to submit, the Portal will check that all mandatory information has been included, and alert you if anything is missing. You won't be able to submit without all mandatory information.
After you have successfully submitted your Change Proposal you will receive automatic confirmation that it's been received for review by the Change Management Team.
Click on to learn about what happens next, as the Code Manager validates the submission.
Once you have submitted a new Change Proposal, the Code Manager is responsible for its review and validation.
We might reject your Change Proposal if it meets one of the following criteria:
The Change Proposal is incomplete or insufficiently clear
The Change Proposal and/or issue it seeks to address is not materially different from (or could appropriately form part of) another Change Proposal that has not yet been decided upon
The Change Proposal concerns matters that are outside the scope of the REC
The Change Proposal has no reasonable prospect of being approved.
We will consider whether the issue is something that actually needs a Change Proposal to resolve, or whether it could be better addressed by another method such as additional training.
You will be notified of our decision to accept or reject the Change Proposal within three working days. If we need longer, we'll inform you of the timeline and our reasons for the extension.
Whether we accept or reject your Change Proposal, you'll be notified on the REC Portal. Keep an eye on the bell icon in the top right corner. If we reject it, we'll also send you an email to explain why.
Once we've accepted your Change Proposal, we give it a reference number and create a brand new Change Proposal page to hold the relevant information.
This page is accessible through the Change Register on the REC Portal.
It’s at this point we’ll identify if change should be progressed as a Housekeeping Change Proposal. You can find out more about Housekeeping Change Proposals later in the guide.
If we reject your Change Proposal, in addition to letting you know we'll also inform the Change Panel. It will be added to the next Change Panel meeting agenda.
You may query the reason for rejection by contacting the Code Manager. You may also contact the Change Panel with a dispute.
The Change Panel will consider whether the Code Manager was right to reject. They'll decide to either overturn the decision of the Code Manager or to uphold the rejection.
If our decision to reject is overturned the Change Proposal will be recorded as accepted and the process will continue.
The Change Proposal Page is where you can find out all information related to a Change Proposal in one handy place on the REC Portal.
You can access the Change Proposal Pages by navigating through the Change Register or using the Portal's search function.
Click on the image overleaf to view an example Change Proposal Page. All Change Proposal Pages contain key information including:
A progress bar
Title and reference number assigned
Change Proposer name/organisation
Lead Change Analyst details
Latest update
Change Summary
Brief description of the Problem Statement
Current status of the change
Change Path
(whether it’s a Self-Governance or Authority Determined change)
Responsible Committee
Implementation date (once known)
Priority Score and Status
Whether the Change Proposal is Urgent
The Fuel the change relates to
Any accompanying documents and also related links/documents
We're committed to delivering effective cross-code working with our colleagues across the industry and have arrangements in place to ensure that cross-code impacts are identified early in the process.
It's one of the core principles of the Code Administration Code of Practice (CACoP) that we've designed our processes to support.
All Change Proposals are referred to the Cross-Code Steering Group (CCSG) during initial assessment, so other code bodies can assess if there may be impacts on their code.
Where a Change Proposal is expected to impact both the REC and another code (or codes), the CCSG will determine which code is likely to be most affected and which code should lead on the development of the Change Proposal as the Lead Code.
The Lead Code is responsible for leading the development of the proposal, the development plan and the impact assessment, and ensuring that the views of different code parties and service providers are represented in decision making process. They will also be responsible for the eventual approval or rejection of the Change Proposals to their code and other codes, with other code body decisions acting as a recommendation to the Lead Code.
Where the REC is the Lead Code in relation to a Change Proposal, the Change Proposal Plan will include the plan for identifying the impacts to other code parties and service providers as well as its own.
Where another code is the Lead Code, the Code Manager will align the Change Proposal Plan with the timetable set by the Lead Code and co-ordinate any REC Impact Assessments with that timetable.
Learn more about wider industry codes:click here to visit the CACoP website
Once a Change Proposal has been accepted, we assign it a Lead Analyst who is responsible for carrying out the initial assessment. If there are significant impacts to areas involving REC Technical Services or REC Performance Assurance, we might also nominate a Technical Lead and/or Assurance Lead to be named on the Change Proposal page as a further point of contact.
The Lead Analyst will be the main point of contact for the Change Proposal as it progresses through the Change Management process. You can find their contact details on the relevant Change Proposal page.
The Lead Analyst has a wide range of responsibilities with respect to each Change Proposal:
They define a problem statement, setting out the problem the Change Proposal is attempting to address
They define a set of solution requirements that need to be met to achieve success
They assess the impacts to REC Products, Parties, Service Providers and stakeholders
They define which committee will be the Responsible Committee for approval of the Change Proposal
They assess wider impacts to the REC ecosystem: impacts to the Performance Assurance Framework, Portal, EMAR
The output of the initial assessment is the Initial Assessment Report (IAR). This is a summary of our assessment of the Change Proposal, and our determination on the urgency, Priority Status, Change Path and Responsible Committee.
It's published on the REC Portal before it's presented to the Change Panel alongside a Change Proposal Plan. That Plan sets out the proposed timetable for the Change Proposal (and whether it's sufficiently developed to proceed straight to Preliminary Assessment and Consultation, or in need of further development/impact assessment).
We invite stakeholders to comment on the IARs we publish. To be notified when new IARs are published, make sure you are subscribed to our Weekly Change Bulletins.
This will provide you with an opportunity to comment on the assessment and recommendations in the IAR ahead of consideration by the Change Panel.
At this stage, views are only sought on the recommendations in the IAR and the Change Proposal Plan to assist the Change Panel with its review of these two documents. General support or objection to the Change Proposal or a particular solution will not be relevant to the decision of the Change Panel at this stage.
You will have a defined timeframe for adding comments on an IAR via the REC Portal. After this window has closed you will no longer be able to add comments.
Subscribe to the Weekly Change Bulletin
Now, the Change Panel will review the IAR, Change Proposal Plan and your comments to determine whether to approve the progression of the Change Proposal as proposed. This includes consideration of the suggested activities and approach in the Change Plan, as well the Change Path, Responsible Committee and Priority Status. Following approval, we update the Change Proposal Page with key information, activities, and milestones.
Where a Change Proposal does not have a fully formed solution upon submission, Solution Development is required. We assign a Solution Lead from the Code Manager: someone with the right skills and expertise for the job.
The approach and timeline for Solution Development is set out in the Change Proposal Plan. This can include engagement with REC Committees, RECCo Subject Matter Expertise, wider industry forums or industry subject matter experts. The engagement and involvement in developing a solution for a Change Proposal is defined on a case by case basis.
During the Solution Development phase, the Solution lead will complete the following activities:
Requirement AnalysisCompletion of the Problem Statement, Solution Requirements and Root Cause Analysis.
DesignSetting out the high-level Solution options for initial consideration, capturing potential impacts to people, processes, systems, commercial and financial interests of stakeholders. At the end of this phase, the Logical Solution is defined.
Quality AssuranceSolutions assessed against quality gate criteria, assuring that they solve the original Problem Statement and meet Solution Requirements, are fully formed and address root cause, documentation is written using Plain English, where appropriate the solution can be assured, measured, and enforced, and technical aspects of the solution have been assured by REC Technical Design Authority (TDA).
DevelopmentBusiness requirement definition for Solution options. Where required by a Technical Service Provider (TSPs), functional and technical requirements specifications developed and sent for impact assessment to TSPs, Parties and/or other affected stakeholders.
Impact Assessments (IAs) ensure that impacts on REC Parties, Service Providers, and stakeholders are identified, validated and, if possible, quantified.
Service Provider Impact Assessments
Used to identify REC Service Provider impacts, with specific targeted questions.
Two levels of Service Provider IA (Preliminary IA and Detailed IA) are initiated together. Service Providers can immediately build on Preliminary responses, or agreed a delay between IAs to enable development activity.
Return of Service Provider Impact Assessments is managed via email.
Party Impact Assessments
Used to gather information from impacted market participants to identify, validate and quantify the impacts a solution would have on their business/market role. IAs include targeted questions to allow the Code Manager to develop a benefits case.
IAs are extended beyond REC Parties to any impacted/interested stakeholders, including industry service providers, consumer bodies and innovators.
IAs include a copy of the Problem Statement and Solution Requirements, a high-level solution overview, Plain English explanation of the proposed solution(s), outputs of any Service Provider IA, and a detailed list of assumptions and dependencies.
Party IAs and responses are uploaded onto the REC Portal. Subscribers of the Change Management updates will be notified by email about new IAs. Click images to zoom.
Following approval of the Initial Assessment Report, we prepare a Preliminary Change Report (PCR), incorporating:
Description and analysisBackground to the Change Proposal, details of the issue being addressed.
Details of the proposed solutionHow it addresses the issue, legal text that has been prepared, information about how the solution was developed.
Proposed Implementation DatePlus any dependencies, and implementation technique (e.g. big bang or parallel test).
Summary of Impact AssessmentsOutcomes of any IAs conducted, including summary of approach and responses, plus details of any expected changes to Service Provider systems including cost and timescales.
Cost Benefit AnalysisKnown costs/industry effort against tangible/intangible benefits case.
Change PathWhether or not the Change Proposal will follow Self-Governance processes.
Code Manager RecommendationOur initial view on whether the Change Proposal should be approved.
Once the PCR is drafted, it will be added to the Change Proposal Page. If you have subscribed to Change Management emails you will be notified when a PCR is published.
Where stated within the Change Proposal Plan, the PCR will be added to the Responsible Committee meeting agenda.
Comments are now invited on the PCR. Comments are to inform the Responsible Committee decision on whether to proceed with the plan for consultation. For example, if material representations have been omitted, the period of consultation is insufficient, or the solution is not sufficiently developed. The opportunity to voice support for (or objection to) the Change Proposal or Code Manager recommendation will be during the consultation.
You should provide comments via the relevant Change Proposal Page on the Portal.
For each Change Proposal, we will make an independent recommendation on whether the Change Proposal should be approved or rejected. This recommendation is included in the Preliminary Change Report, subjected to industry consultation, and confirmed in the Final Change Report.
The Responsible Committee that votes on whether to approve or reject a Change Proposal (or recommend approval or rejection to the Authority) shall consider the recommendation of the Code Manager when making its determination.
Although the Responsible Committee can disagree with the Code Manager's recommendation, they are unable to unilaterally overturn this recommendation. In this instance, the decision on whether to approve or reject the Change Proposal will be automatically appealed to the Authority (Ofgem).
The decision to recommend approval for a Change Proposal will be based on the business case made for the change (for Self-Governance changes) or the REC Objectives being better facilitated by the implementation of the change (for Authority Determined changes).
Where Alternative Change Proposals are made and the Code Manager's recommendation proposes the approval of a particular solution, this will be based on the assessment of which solution presents the best case for change, or better enables the achievement of the REC Objectives. The Code Manager may also recommend the rejection of all Change Proposals.
Where a Change Plan defines that the Responsible Committee is to review a Preliminary Change Report, we add it to the next meeting agenda and provide all comments received.
The Responsible Committee reviews the Preliminary Change Report and comments, and decides to approve or reject the progression of the change in line with the plan for consultation detailed in the report.
Where the Preliminary Change Report is approved, the Code Manager prepares the consultation in line with the agreed plan.
If the Responsible Committee rejects the Preliminary Change Report, as they believe further information or assessment is required prior to proceeding to consultation, we'll address this feedback and revise the Preliminary Change Report for resubmission to the Responsible Committee.
Once a Preliminary Change Report has been approved by the Responsible Committee (or where the Change Proposal is to proceed directly), it is published for Consultation.
All Consultations can be accessed through the Consultations Register on the REC Portal.
If you have subscribed to receive Change Management emails, you'll be notified when Consultations are published, including the window for responses.
The Consultations Register shows open Consultations that are available for comments. Closed Consultations will be added to the relevant Change Proposal Page.
When accessing a Consultation through the Consultations Register you will be presented with the details of the Consultation and its closing date for comments. From the Consultation page you can download accompanying documentation and respond by clicking Add Response.
Once the consultation period has closed all consultation comments will be collated and addressed in the Final Change Report for consideration by the Responsible Committee.
Following consultation, solutions go through a final refinement stage to address any inaccuracies or points of clarity addressing consultation responses. Amendments made during refinement will be included in the Final Change Report (FCR) issued to the Responsible Committee for its decision on implementation.
The FCR also includes:
An overview of those who responded to the consultation, a summary of responses, whether or not they support the Change Proposal and their reasons;
A summary of any minor variations to the Change Proposal following consultation and the reasons for this;
Confirmation of the appropriate Change Path (Self-Governance or Authority Determined); and
A recommendation by the Code Manager on whether the Change Proposal should be accepted.
The Responsible Committee will vote on whether to approve or reject the Change Proposal, considering the recommendation of the Code Manager.
Within two working days of the vote, the updated FCR will be published on the REC Portal, incorporating a confirmation of the vote outcome. The Change Register will also be updated. If you have subscribed to receive Change Management emails, we'll notify you of the publication.
Subscribe to Change Management emails
Anyone can appeal the decision of the Responsible Committee for a self-governance Change Proposal within ten Working Days of notice of the decision being given.
An Appeal Form can be downloaded from the REC Portal.
The appeal form and relevant documentary evidence must be submitted to Ofgem by email to industrycodes@ofgem.gov.uk within the appeal window. The Appellant also should inform the REC Code Manager that they have submitted an appeal to Ofgem by emailing a copy of the form to: enquiries@recmanager.co.uk.
The Authority may dismiss your appeal if it is brought for reasons that it considers trivial or vexatious, does not meet the grounds for appeal, or has no reasonable prospect of success.
The Authority will consider whether it has sufficient information on which to form an opinion. If the Authority has sufficient information on which to make a decision it can accept the appeal and determine whether to uphold or overturn the decision of the Responsible Committee.
If the Authority does not have sufficient information to make a decision it can request the provision of additional information until it has clarity on the basis for the appeal.
If you have submitted a Change Proposal, you can withdraw it at any time by giving notice to the Code Manager.
On receipt of the notification, the Code Manager will consider if we wish to adopt the Change Proposal. We'll do this if we consider that the proposal may deliver overall benefits to the market or consumers.
Where we decide not to adopt, a notification will be sent to the Change Management email subscribers to invite them to adopt it. If - within 10 working days - we receive notice that another person wishes to adopt the Change Proposal, that person will become the new Proposer. Where the Change Proposal is adopted, we'll update the Change Register and the Change Proposal will continue its progression.
Where it's not adopted, the Change Proposal will be withdrawn. The Change Register will be updated, and the process will end.
In reviewing a published Change Proposal, if someone feels there is a different solution that would better address the problem statement of the Change Proposal, they may choose to raise an Alternative Change Proposal.
Alternatives to a Change Proposal can be raised at any time prior to the publication of the Preliminary Change Report. After that date they may be rejected by the Code Manager.
There is no restriction on the number of Alternative Change Proposals that can be raised in relation to a Change Proposal.
The Alternative Change Proposal must be a valid Change Proposal in its own right and will be subject to the Validation Rules set out in the REC Change Management Schedule.
The Code Manager may also raise an alternative to the original Change Proposal where the Proposer does not wish to vary their Proposal and the Code Manager believes an alternative solution would better address the issue/opportunity or could achieve a similar or better effect at reduced cost or effort.
Alternative Change Proposals will be linked to the original Change Proposal, and follow an aligned Change Proposal Plan so that the consultation and voting will be carried out at the same time, and votes will be cast on the basis of an order of preference.
The Lead Analyst of the original Change Proposal shall also become the Lead Analyst of any Alternative Change Proposals associated with this.
Alternative Change Proposals will be included on the Change Proposal Page and added to the Change Register.
Housekeeping Changes are minor in nature and include (but are not limited to) the correction of errors, inconsistencies or factual changes, for example:
updating names, addresses (including email addresses) listed in this Code;
correcting minor typographical or grammatical errors;
correcting formatting and consistency errors, such as Paragraph numbering; or
updating out of date references to other documents or Paragraphs
As with the standard Change Process, any interested person will be able to raise a Housekeeping Change Proposal.
If the Code Manager decides to reject the Change as a Housekeeping Change Proposal, but they believe it should be progressed as a Change Proposal, subject to the standard Change process, they will advise the Proposer and progress the Change through the standard processes.
If the Code Manager decides to accept the Housekeeping Change Proposal, it will be assigned a Change reference number and published on the REC Portal.
We will produce a Housekeeping Change Report 5 Working Days in advance of the Change Panel meeting where the Report will be presented for a decision. It will include:
a description of the Housekeeping Change Proposal;
the proposed legal text required to give effect to the change;
the proposed implementation date of the Housekeeping Change Proposal;
the Code Manager’s Recommendation as to whether or not to approve the Housekeeping Change Proposal.
The publication will allow REC Parties, REC Service Providers and other interested persons to review the proposed Housekeeping Change Proposal in advance of the Change Panel’s determination and, if necessary, raise an objection to the change being made.
A notice of objection can be raised to the Code Manager before the Change Panel meeting by either a REC Party or the Authority. A notice of objection should be raised via the REC Service Desk.
If there are grounds for the objection to be accepted, we will terminate the progression of the Housekeeping Change Proposal and update the Authority and REC Parties. Unless the change is withdrawn by the Proposer, they will re-classify the Housekeeping Change Proposal to be a Change Proposal subject to the standard change process.
Before making its decision, the Change Panel:
must unanimously agree that the Housekeeping Change Proposal meets the criteria to be a Housekeeping Change Proposal before progressing to the decision;
will reject the Housekeeping Change Proposal if they don’t unanimously agree it meets the Housekeeping criteria, the Code Manager will then consider whether the change should be progressed as a standard Change Proposal;
need to be satisfied that all parties and the Authority have been notified of the proposed Housekeeping Change Proposal and the planned Implementation Date in advance of the meeting, and that no one has objected to the change being made, in advance of the meeting, before they make their decision.
Following the decision of the Change Panel, the Code Manager will, within 1 Working Day, update the Housekeeping Change Report to record the decision of the Change Panel and will send this to the Authority, to each REC Party and will publish it on the REC Portal.
If any interested party objects to the decision made by the Change Panel, they may raise an objection to the Code Manager within 10 Working Days of the publication of the decision. The objection must include an explanation of why the person objects to the change being made. The only valid reason for raising an objection is that the change has been incorrectly classified.
Within 1 Working Day of receiving an objection notice after a Change Panel decision the Code Manager will notify the Authority, REC Parties and the Change Panel that the objection has been raised.
At any point before or following the Change Panel meeting, if the Authority determines that the Housekeeping Change Proposal should not be approved, the Housekeeping Change Proposal will be cancelled or not implemented (if this is following the Change Panel’s determination). If the Change has already been implemented, then it shall be reversed.
Implementation of the Housekeeping Change Proposal will be at the next scheduled Release, unless another more suitable date is agreed by the Change Panel.
Category 3 documents are maintained by the Responsible Service Provider or REC Committee named in the REC Baseline Statement.
That entity will be responsible for identifying and making changes to their Category 3 documents as required. This will usually be driven by the Responsible Service Provider; however, the Code Manager may also identify the need for amendments.
Where the Code Manager identifies a required change that hasn’t been proposed by the Responsible Service Provider, we will contact them to discuss the need for change.
If you identify an issue with a Category 3 document, you can report this to the Code Manager via the Service Desk.
Where this relates to an issue on the Issues Log, the issue will remain open until the updated document has been implemented.
Where this relates to a REC Change Proposal or REC Release, the requirement to update the Category 3 document will be included in the Release Plan. The dependency will be noted in the Final Change Report and/or registered on the Release RAID Log.
Once the Responsible Service Provider has proposed a change to a Category 3 document, the Code Manager will review the proposed changes. Our checks validate that the proposed change only impacts Category 3 documents, is accurate and of sufficient quality. If the proposal impacts require changes to Category 1 and/or 2 documents, the change will need to be held while a new Change Proposal is submitted.
Once we've validated a change, we'll assign it a reference number and add it to the Category 3 Change Register on the Portal.
In some cases it is appropriate to invite wider stakeholder comments on a proposed change. If requested, the Code Manager will add this to the Portal and invite responses.
Once the window for responses has closed, we will collate all the comments and provide them to the Responsible Service Provider for review. Once the Responsible Service Provider have completed its review and made any relevant updates, they will confirm the change and agree a release date.
Once the required changes are agreed, we'll update the new document on the Portal. If you've subscribed to receive Change emails, we'll notify you of the changes this way too.
Once published, the Category 3 Log will be updated and acts as an audit record for changes implemented to Category 3 documents.