FSC Change Management Process

1. Change Control Information

1.1. Record of Changes

2. Introduction

2.1. What is a Change?

A Change is a piece of work that alters the state of a system or component so that it functions differently from the way it did previously. A Change is usually made in support of:

1. General service improvement
2. Resolving Problems

However, there are other circumstances in which Changes can be made or are recommended.

A Change is different from:

1. Maintenance (keeping things running as they should)
2. Fixes (returning a system or component to its previous working state)

2.2. Example of Changes

Change Management is responsible for managing Change processes involving:

1. Hardware
2. Communications equipment and software
3. System software
4. ‘Live’ application software
5. All documentation and procedures associated with the running, support and maintenance of live systems

Some broad examples of Changes include:

1. Adding new applications / systems to the infrastructure
2. Upgrading / changing the client software available as part of a service
3. Upgrading / changing server software
4. Making alterations to a management or business process

3. The Change Management Process

3.1. Change Types

Change Management is split into two distinct areas:

1. Standard admin Changes
2. Change Requests (CRs)

3.1.1. Standard Admin Changes

Standard admin Changes refer to Changes to the infrastructure where the effects of the Changes are understood and/or can be easily undone, and/or have a low impact. These include:

• URL blocking/unblocking
• Mailbox creation
• Password changes
• Account creation
• DNS record additions, changes and deletions
• DNS zone creation & tag transfers inbound

The full list of standard admin Changes is detailed in the FSC to LEA Service Level Agreement (SLA).

Requests for standard admin Changes are recorded on the Help Desk management system and are handled using the Incident Management process (as admin requests). Response and resolution of these requests is in line with the timescales outlined in the FSC to LEA Service Level Agreement (SLA).

If there is any doubt about whether a specific Change is a standard admin Change or a full Change Request, the latter process must be used as the default until a decision can be made.

3.1.2. Change Requests (CRs)

All full CRs are handled using the Change Management process. This process functions very differently from the Incident Management process and is detailed below.

3.2. Roles and Responsibilities

3.3. Submitting CRs

Change requesters must first seek approval for their CR from a nominated approver. The approver is there to make sure that submitted CRs are in line with an individual LEAs overall requirements and priorities, or the overall requirements and priorities of the Regional Broadband Consortium (RBC) and also that there is, in principle, money to pay for requested Changes.

Customers must indicate the priority of the CR when submitting it. This will ensure that initially those CRs regarded by the Customer as high priority will be assessed and assigned first. During the assessment and assignment phase, the CR priority may be upgraded or downgraded by the Change Board.

3.4. Processing CRs

Once a CR has been approved the requester, via telephone, email, or web interface, passes it to the FSC.

The Change Administrator logs all new CRs on the Help Desk management system, including the requester’s details. Each CR is assigned a unique ID by the system. Internally generated (i.e. within the FSC) or Supplier generated Changes always require an CR: This is so that all CRs are recorded and can be referred to at a later date for Change Review Meetings and audits.

When a new Change record is added to the system, the Change Manager will receive an email notification alerting them that a new CR has been submitted and directing them to the relevant Change record.

Where CRs are submitted as a proposed resolution to a Problem, it is important that the original Problem record ID is recorded so that the link between the Problem and the proposed resolution can be easily identified.

3.5. Acknowledging Receipt of (Customer) CRs

When a CR is received and logged by the FSC the requester will be given the ID of the Change record. This will be confirmed in an automated email notification.

Receipt emails will include:

• Date of receipt.
• CR reference number.
• A date by which a further response will be provided. This will usually be 5 working days from the date of the notification email. This response is intended to keep the Customer informed of the progress of the Change, i.e. 'still being assessed', 'Change Proposal being developed', etc.
• A short paragraph indicating that the request has been logged (hence the reference number), that it has been passed to the Change Manager for evaluation and that the Customer should contact the Foundation Service Centre if they require any updates on the progress of the request.

3.6. Filtering of CRs

When new CRs are logged the Change Manager should consider each request and filter out any that are totally impractical. These should be returned to the requester, explaining why the CR has been rejected and the Change record updated to show that it has been rejected.

Changes can also be rejected at this stage if there are clear technical, security, legal, cost or other reasons for doing so.

In addition the Change Manager should seek to filter out CRs similar to any that have already been received and processed.

3.7. Assessing a Change Request

Following the Change Manager’s review of the CR it is sent to all core Change Board members to assess it. Where additional expertise is required to assess specific CRs, relevant members of staff should be invited to sit on the Change Board. Changes can also be rejected at this stage if there are clear technical, security, legal, cost or other reasons for doing so.

The assessment should include:

• Setting a priority for the CR
• A risk assessment
• Assigning the CR a category

Only once this assessment has been conducted can the CR be assigned.

3.7.1. Setting the Priority

The Change Board needs to give each CR a Priority. This is based on the impact of the associated Problem and how urgent resolution is, or how necessary the requested improvements to the service are. In general the highest priority Changes are likely to be those needed to deal with Problems that are having the biggest impact on Customers. It is possible for a high Impact Change to have a low Priority and vice-versa.

The Priority given to each CR will dictate how quickly it is dealt with and/or how high in the list of Scheduled Changes it is placed.

Each Change should be classified as being:

• Emergency (see section 3.20)
• High
• Medium
• Low

Where CRs have been submitted as a proposed resolution to a Problem, the Change should assume the priority of the Problem with which it is associated, unless there are good reasons for not doing so.

3.7.2. Risk Assessment

A risk assessment is critical to ensure that nature of the Change and its potential impact on the infrastructure is understood. The Change Board will need information on the consequences of approving or rejecting the Change (including the financial, technical and business implications).

3.7.3. Change Categorisation

The Change Board should examine each CR and determine which category it falls into. The three categories are:

• Minor impact
• Significant impact
• Major impact

These categories define the impact of a Change on the organisation in general and also in terms of the resources needed to affect the Change.

When assessing the impact, the following items should be considered:

• The impact that the Change will have on the Customer and end-users
• The effect on the infrastructure and Customer service, as defined in the SLA, and upon the capacity and performance, reliability and resilience, contingency plans, and security
• The impact on other services within the infrastructure or on development projects
• The impact on the Foundation Service Centre
• The effect of not implementing the Change
• The staff (both technical and non-technical) required to implement the Change. This should cover the likely general costs, and the number and availability of people required
• Any new infrastructure elements required (software or hardware)
• The effect on the current Change Schedule
• Any additional resources required in the ongoing support of the Change if it is implemented

3.8. Assigning a CR

Once the CR has been assessed and given a priority, the Change Manager will assign it to the appropriate Change Board member to develop a Change Proposal. The person to whom the Change is assigned becomes the Change Owner. The Change Owner might then either assign the CR to a group of team members, an individual team member, or undertake the development of the Change Proposal themselves, depending on the nature and complexity of the CR.

3.9. Informing the Release Manager

Once a new CR has been assigned the Change Manager will inform the Release Manager. This is to keep the Release Manager informed as to possible upcoming Changes that may require a release date.

3.10. The Change Proposal Phase

This phase of the Change Management process deals with the development of a proposal based on the Change being requested. The proposal is intended to examine all the options available (if any) to satisfy the request and to make a recommendation (including rejecting the Change).

3.10.1. Developing Change Proposals

Once the CR has been assigned to a Change Owner it is the responsibility of the Change Owner to produce a Change Proposal, the recommendation of which will be subject to approval by all Change Board members and the requester before the Change can be implemented.

The Change Proposal is a document that provides a high-level description of:

• The basic Change requirement.
• Any options available to meet the requirement.
• The recommendation (if there is more than one option available).
• Resource estimates, hardware and software requirements, and scheduling.
• The Impact that the recommended Change might have on users, support, other systems or SLAs and supplier contracts.
• Any risks identified.
• The test strategy to be used.
• Regression - Detail of the measures that will be put in place to ensure that any Change undertaken can be reversed.

When a Change Proposal has been completed it needs to be submitted to the FSC. Once received the proposal will be appended to the relevant record in the Help Desk management system. The Change Administrator then assigns the Change Proposal to all Change Board members for review.

3.10.2. Setting an Implementation Date

It is important that a proposed implementation date is provided as part of the Change Proposal. The implementation should be scheduled to minimise the impact to FSC staff, Customers and end-users, and on any other scheduled work. In addition it should be set so that, if possible, enough time is allowed to communicate the Change to FSC staff and Customers.

It is also the responsibility of the Change Manager to liase with the Release Manager to set the release date for the Change.

3.11. The Approval Process

Once the Change Manager has reviewed the Change Proposal each Change Board member is required to approve or reject it. The Change Board members required to approve an individual Change Proposal will depend on the Impact rating applied to the Change.

3.11.1. Approving Change Proposals

An individual Change Board member should approve a Change Proposal if:

• They are happy that the Change proceeds as recommended.
• They are the Change Owner and therefore have made (or are aware of) a recommendation that they are happy with.
• The Change has no impact on their area of responsibility and therefore they have no reason to reject it.

Once the Change Board has approved a Change, the Change Manager needs to review the section on costs and, if appropriate, prepare a quote for the requester. The quote should include a detailed breakdown of the work to be carried out. Once prepared both the quote and the Change Proposal are sent to the requester for approval (see section 3.12.2).

3.11.2. Rejecting Change Proposals

An individual Change Board member should reject a Change Proposal if:

• They have sound financial, technical or business reasons for rejecting the proposed Change.
• The recommended Change will have an adverse impact on staff resources.
• If they feel the proposed Change does not provide sufficient benefit when weighed against the amount of work required to make the Change. This issue will usually have been identified in the Change Proposal, however.

Change Board members should not reject a Change Proposal because they do not like the particular solution being recommended, unless it is for sound technical reasons or has an impact on staff resources in their area.

If a Change Board member rejects a Change, they must provide the Change Manager with their reasons for rejecting it. The reasons for rejection must then be looked at and, if possible, addressed. If they can be addressed then the Change Proposal should be altered accordingly and re-issued for approval.

If the reasons for rejection cannot be resolved, then the Change cannot be re-issued for approval and therefore cannot be implemented.

3.12. Informing the Customer

Once a decision has been taken on a specific CR, it is the job of the Change Manager to inform the requester of the decision.

3.12.1. When a CR has been rejected

If the CR has been rejected the requester must be provided with an explanation as to why it has been rejected and any information on further steps (if any) to be taken as a result.

3.12.2. When a CR has been approved

As well as Change Board approval, it is necessary to give the requester the opportunity to review and approve the Change Proposal, including any proposed charges for the work (see section 3.13). The requester must then either approve or reject the recommended solution and inform the Change Manager. If the requester rejects the Change Proposal then they must provide the Change Manager with a detailed explanation as to why they have done so. This can then be fed back to the Change Owner.

If a response is not received within three days then any timescales associated with the Change cannot be guaranteed. It is the responsibility of the requester to ensure that, if they are unavailable, Changes can still be progressed by a nominated deputy.

3.13. Change Costs

Chargeable Changes will be done so on the basis of time spent, in addition to any software or hardware items that are required to be purchased in support of the Change. The Customer will be billed for all chargeable Changes in the same period that the Change is accepted.

3.13.1. Customer Approval of Change Quotes

Approval of the Change Quote by the requester will be required. If a response is not received within three days then any timescales associated with the Change cannot be guaranteed. It is the responsibility of the requester to ensure that, if they are unavailable, Changes can still be progressed by a nominated deputy.

If the requester rejects the quote, then the Change Manager should review the quote with them. If the quote cannot be changed, then the CR is closed. There may still be a charge made for work already done in support of the CR.

3.13.2 Raising an Invoice

Once the Customer has approved a Change Quote, an email [hopefully this will be an automated email generated by the Help Desk management system] should be sent to the Foundation Finance Manager in order for an invoice to be raised.

3.14. Building Changes

The actual building of Changes is the responsibility of the Change Developer assigned to the task. Detailed documentation on the Change does not need to be reviewed as a matter of course by the Change Manager or the Change Board.

3.15. Testing Changes

All Changes should be tested to ensure, as far as possible, that the implemented Change would be successful. The testing of Changes is the responsibility of the Change Owner and the Change Developer assigned to the task.

The Change Proposal should include a high level Test Strategy, but detailed Change testing documentation does not need to be reviewed as a matter of course by the Change Manager or the Change Board.

3.16. Implementing Changes

Following successful Build and Test phases, the proposed implementation date identified in the Change Proposal needs to be confirmed.

It is incumbent on the Change Manager to recommend a change of implementation date, if the proposed date is likely to have impacts on any day-to-day or other planned work.

Once the date has been confirmed, the Change Manager needs to inform both the requester and the Change Board. If the Change requires any system or service downtime the Change Manager will also need to inform FSC staff and Customers via the service downtime notification procedure.

3.17. Rolling Back Implemented Changes

A back out or rollback plan must be identified prior to any Change being made. If a Change is ultimately unsuccessful, a back out plan must be available so the service or system can be restored to its previous working state.

The development of a back out plan is the responsibility of the Change Owner and the Change Developer assigned to the task. The back out plan does not need to be reviewed as a matter of course by the Change Manager or the Change Board.

3.18. Closing a Successful Change

Once a Change has been implemented, the Help Desk Management system must be updated with the Actual Implementation Date. Once this date is entered the Change record is assigned to the Configuration Manager. The Configuration Manager is then responsible for ensuring that all documentation associated with the Change is completed and the Configuration Management database updated.

Once this has been done the Configuration Manager assigns the Change record back to the Change Administrator. The closure date is then added to the Change Management system and the Change closed.

It is the responsibility of the Change Manager to inform the Customer that the Change has been successfully implemented, along with any other information that the Customer may need to know as a result of the Change (e.g. up-to-date documentation).

3.19. Reviewing Unsuccessful Changes

If a Change is attempted, but is ultimately unsuccessful, then there must be an investigation into why the Change didn’t work. Two basic options will probably present themselves as a result of this investigation:

• The Change is rolled back, rescheduled, re-tested and attempted again.
• It is decided that the Change should not be reattempted. If this happens then the original Change Proposal needs to be revisited. If no other options exist, either in the original Change Proposal or as a result of the unsuccessful Change, then the Change must be rejected and closed. If alternatives do exist then the Change Proposal must be resubmitted to the Change Board for approval.

It is the job of the Change Manager to provide updates to Change Board members and the Customer, as required, on the status of unsuccessful Changes.

3.20. Change Reviews

The Change Board is responsible for reviewing all implemented Changes at regular intervals. These reviews will look to establish that:

• The Change has had the desired effect and met its objectives
• Customers are content with the results, or to identify any shortcomings
• There have been no unexpected or undesirable effects on the systems or services that were changed. This may be to their functionality, performance, security, maintainability, etc.
• The resources used to implement the Change were used as planned
• The implementation plan worked correctly
• The Change was implemented on time and to cost. If not why?
• The back out plan worked as anticipated (if relevant)

Where a Change has not achieved its objectives any issues should be recorded and, if necessary, follow-up action taken. This could include raising a revised CR. If the review is satisfactory or the original Change was abandoned, then the CR should be closed.

4. The Emergency Change Process

In certain circumstances it may be necessary to affect an emergency or urgent Change. These proposed Changes should be kept to an absolute minimum, as they are generally more disruptive and prone to failure, as well as being reflective of poor proactive Problem Management and Configuration Management.

The basic steps in the Emergency Change process are similar to those in the standard Change process. These are:

• Calling an emergency Change Board meeting
• Assigning a CR
• Developing a Change Proposal
• Approving a CR
• Building a Change
• Planning and testing a Change
• Implementing a Change
• Rolling back implemented Changes
• Closing a successful Change
• Reviewing unsuccessful Changes

4.1. Building an Emergency Change

Approved Changes should be assigned to a Change Owner for building, testing and implementation. The Change Owner may conduct this work or assign it to a team or individual member of staff to complete.

The Change Manager and Change Board members should ensure that sufficient staff and resources (e.g. machine time) are available to complete this work.

[Procedures need to be in place to enable this.]

The costs of any emergency call-outs associated with an Emergency Change requested will be born by the Customer.

Back out plans are a pre-requisite for undertaking Emergency Changes and should be developed in line with section 3.17 of the Change Management process.

4.2. Planning and testing an Emergency Change

Unplanned and untested Changes should not be made. As much testing of the Emergency Change as is possible should be carried out. Completely untested Changes should not be implemented unless it can be avoided, as this may cause even more problems.

Changes may still be tested even after implementation and corrective action taken if testing uncovers any issues.

4.3. Implementing an Emergency Change

The Service Centre will provide as much advance warning as possible to Customers of any imminent Change. This process starts as soon as the decision to undertake an Emergency Change has been taken by the Change Board. The Service Centre will then provide regular updates on the progress of the Change to Customers, including the planned date and/or time for the Change, and relevant details.

When Emergency Changes are implemented, particularly those that haven’t been adequately tested, the Change Manager should ensure that suitable technical staff are available to deal with any Incidents that occur as a result of the Change.

[Procedures need to be in place to enable this.]

4.4. Rolling back implemented Changes

If an implemented Change fails to rectify the outstanding Problem(s) then it should be quickly rolled back. If successive attempts to implement a Change are unsuccessful then the Change Manager and appropriate technical staff will need to establish that:

• The Problem has been correctly identified
• The proposed resolution has been adequately tested
• The Change has been properly implemented

In such circumstances the Change Board will then take the decision either to:

• Keep attempting the Change
• Provide only a partial service until the Problem and associated Change can be reassessed, possibly resulting in the Change being rebuilt and retested, prior to implementation
• Provide only a partial service until the Change can be thoroughly tested (if adequate testing was not done initially), to temporarily suspend the service and then implement the Change.

5. Appendices

5.1. Change Management Process Flowchart

See attachments to this topic (below).

5.2. Emergency Changes Process Flowchart

See attachments to this topic (below).