Docstoc

Procedure Name How to Complete the Datacentre Request For Change RFC and Release Documents Procedure - Download as DOC

Document Sample
Procedure Name How to Complete the Datacentre Request For Change RFC and Release Documents Procedure - Download as DOC Powered By Docstoc
					 Procedure Name         How to Complete the Datacentre Request For Change (RFC)
                                        and Release Documents
    Procedure
    Reference
      Author                                       Rob Brain
 Version History
 DATE       Version            BRIEF DESCRIPTION OF CHANGE                      Changed
            Number
                                                                                  by
27/11/06       2.0    Change and Release documents – How to Complete          Rob Brain




Process Description

A guide to enable completion of the Datacentre Request for Change and Release Forms


Contacts

Office hours:- Rob Brain and Ed Wadey (or designated deputy)




92b73369-5d3e-4a75-8b90-5565d16579dc.docversion number 2.0
Author Rob Brain                      Page 1                                  19/07/2011
GUIDELINES

This document is intended to give a brief guide on how to complete the Request for Change and
Release Documents. The Change team is always willing to help should you require any further
assistance.

Templates

The templates used must always be the latest version. Requests made on previous
versions will be refused.

Current versions of the „Request For Change (RFC) and „Release‟ documents can be found in
\\Pcms-fs01\global\Change_Control

\\pcms-fs01\global is mapped as the „G‟ drive as part of the automatic log-on script for
PCMS.net

Planning

RFC‟s to be submitted at least 5 days before the change is required

If the date of receipt by the Change Management Team of an RFC is less than 48 working week
hours (2 days) before the Release date/time, then the RFC must be re-classified to „Emergency‟
(Weekends & Bank Holidays do NOT count in this period) This does include receipt by E-Mail

Renegotiation of the implementation date/time of the change is to be commended, not resisted,
as this prevents the system from becoming stressed, especially if this takes the change outside
the 48hour period.

The Change Management function classifies the change according to our criteria not those of
the user/customer. Remember that an Emergency Change is not a get out of jail card for a
poorly organised implementer/Project Manager. If this scenario is suspected, then the change
will be refused and a re-schedule insisted upon.

The Change Management team will ALWAYS resist Emergency Changes that are NOT due to a
broken piece of hardware/software.

Approval

All RFC‟s and Releases must be approved by the The Change Advisory Board (CAB). The
CAB is a body that exists to approve changes and to assist Change Management in the
assessment and prioritisation of changes. The members of the CAB will be capable of ensuring
that all changes are adequately assessed from both a business and a technical viewpoint. To
achieve this, the CAB will include people with a clear understanding of the Customer business
needs and the User community, as well as the technical development and support functions. The
composition of the CAB will vary according to the change.




92b73369-5d3e-4a75-8b90-5565d16579dc.docversion number 2.0
Author Rob Brain                      Page 2                                     19/07/2011
EXPLANATION of CHANGE TYPES

„Requests For Change‟ fall into three categories.

   Basic
   Emergency
   Standard

The type of change you need to action, will result in a slight difference in how you complete the
RFC and Release documents. For this reason users must familiarise themselves with the
following explanations of the change types to enable the process to run smoothly.

Basic Change
A Basic change is a „one off ‟ change. It is planned in advance and is to be submitted at least 5
days before the change is required.

Emergency & Retrospective Changes

Emergency
An Emergency change is also a „one off‟ change. It is still a „basic‟ change, but is usually a „fix‟,
hence the term „Emergency‟, and therefore hasn‟t been planned in advance. A change will be
classed as an „Emergency‟ if it is submitted to the Change Team less than 48 working week
hours (2 days) before the Release date/time.

Retrospective
In the event that an Emergency change has to be carried out prior to any documentation being
raised, then the user/implementer must advise the Change team to get verbal
authorisation to allow the change to go ahead.

The change will be classified as ‘Retrospective’. Failure to inform the change team (of any
changes) may result in disciplinary action.

The RFC and Release documents will still need to be raised and authorised after the event.

Standard Change
A Standard change is „Repeatable‟. It follows a common set of procedures and is pre-
authorised. The „user‟ can action the Pre-authorised Standard change at any time by simply
filling out a „Standard Release Notice‟ and emailing to changecontrol@pcmsgroup.com

Examples of Standard Changes are:-

   Adding users to a system
   Adding/Removing hardware from a rack
   Patching Network Cables

To view all current Standard Changes please see the „Authorised Standard Changes‟ Spreadsheet
which can be found in the Change Control Folder by following the link below:

\\PCMS-FS01\Global\Change_Control\Authorised Standard Changes.xls

Third parties who do not have access to the above spreadsheet can contact a member of the
Change Team who will be able to provide the latest version upon request.

If any PCMS users require access to the Change Control folder then please contact the „Technical
Support‟ team.

92b73369-5d3e-4a75-8b90-5565d16579dc.docversion number 2.0
Author Rob Brain                      Page 3                                          19/07/2011
EXPLANATION of Change Priority
Every RFC is allocated a priority that is based on the impact of the problem and the urgency for
the remedy.

Change Management are responsible for assigning this priority. The priority of RFCs ideally
should be decided in collaboration with the initiator and, if necessary, with the CAB; but it
should not be left to the initiator alone, as a higher priority than is really justified may result.

The following priority ratings are used:-

       Urgent. Causing loss of service or severe usability problems to a larger number of
        Users, a mission-critical system, or some equally serious problem. Immediate action
        required. Urgent CAB meetings may need to be convened. Resources may need to be
        allocated immediately to build such authorised Changes.

       High. Severely affecting some Users, or impacting upon a large number of Users. To be
        given highest priority for change building, testing and implementation resources.

       Medium. No severe impact, but rectification cannot be defered until the next scheduled
        Release or upgrade. To be allocated medium priority for resources.

       Low. A Change is justified and necessary, but can wait until the next scheduled Release
        or upgrade. To be allocated resources accordingly.


EXPLANATION of Change Categorisation
The issue of risk to the business of any Change should also be considered prior to the approval
of any Change. Change Management should examine each RFC and decide how to proceed
based on the (predefined) category into which the RFC falls. The categorisation process
examines the impact of the approved Change on the organisation in terms of the resources
needed to effect the Change. Note that the structure and complexity of these categories will
very much depend on the needs of the business, including the range of priority ratings as
mentioned earlier.

The prioritisation process above is used to establish the order in which Changes put forward
should be considered. Any of the above priorities given might apply to a Change that falls into
any of the impact-assessment categories below.

It is expected that the majority of RFCs will fall into the first two categories. Minor or Significant.

   Minor impact only, and few 'build' or additional 'runtime' resources required.Prior
    to Authorisation the RFC & Release should be circulated to the CAB for impact and resource
    assessment. All Signatures are required for the Change to be accepted.

   Significant impact, and/or significant build or runtime resources required. Prior to
    Authorisation the RFC & Release should be circulated to the CAB for impact and resource
    assessment. All Signatures are required for the Change to be accepted.

   Major impact, and/or very large amount of build or runtime resources required,
    or impact likely upon other parts of the organisation and it’s Customers.Where a
    major Change pertains directly to IT, the RFC should be referred to the organisation's top
    Management Board for discussion and a policy decision. Such Changes, once approved
    should be passed back, via the CAB, for scheduling and implementation. All Signatures are
    required for the Change to be accepted.



92b73369-5d3e-4a75-8b90-5565d16579dc.docversion number 2.0
Author Rob Brain                      Page 4                                             19/07/2011
RAISING THE DOCUMENTATION

Whatever type of change you are raising (Basic, Standard, Emergency), an RFC and a Release
document are ALWAYS required.

Raising the Request for Change Document (RFC)

Open the Request for Change (RFC) template from the specified folder as mentioned on page 2
under the heading „Templates‟

Fill out the form ensuring all relevant fields are completed following the guidelines further on in
this document

All sections of the RFC must be written in plain terms, to be clearly understood by a person
without technical or specialist knowledge, as this document is purely to state the Business
requirement of the change

A soft copy of the completed RFC is to be sent to the Change Control E-Mail account
changecontrol@pcmsgroup.com No soft copy means there can be no authorisation.

The hard copy must be circulated to get the relevant signatures. The hard copy of the document
must be signed off by all parties as stated in the „sign off‟ section of the document, and then
handed to the Change Management Team for final authorisation to go ahead.

If authority is given the Change Team will allocate a Change Number to the RFC. The Change
Number format is 3-4 Characters of Customer Name + 3 digits starting at 001.

Example of a World Duty Free RFC number – WDF 123

If authority is not given, consultations on the reasons for rejection will take place. It is
anticipated that most rejections will be as a result of typographical errors. The implementer will,
in this case, correct the document and re-submit the RFC. This may be iterative.

The Change Team add an event to the „Forward Schedule of Change‟ stating the RFC has been
authorised with its planned date.

Communicating the RFC Authorisation

The Change Management Team will issue an E-Mail to the Implementer/s indicating that the
RFC has been authorised, stating its allocated Change Number, and the details of the change
summary. A copy of this E-Mail will be sent to Operations, the PCMS Service Desk and the
relevant Customer Service/Account Manager/s. A Release document will be attached for the
Implementer to complete (as detailed in the next few paragraphs).

Raising the Release Document

Once the ‘RFC’ has been authorised the Implementer can begin to build the change, test it and
prove the regression plan works

When the release is successfully built then the implementer can submit a „Release Request‟ form
(as attached in the corresponding RFC Authorisation email).

Fill out the form ensuring all relevant fields are completed following the guidelines further on in
this document


92b73369-5d3e-4a75-8b90-5565d16579dc.docversion number 2.0
Author Rob Brain                      Page 5                                          19/07/2011
A soft copy of the completed Release document is to be sent to the Change Control E-Mail
account changecontrol@pcmsgroup.com No soft copy means there can be no
authorisation unless otherwise agreed by the Change Management Team.

The hard copy must be circulated to get the relevant signatures. The hard copy of the document
must be signed off by all parties as stated in the „sign off‟ section of the document, and then
handed to the Change Management Team for final authorisation to go ahead.

Once the Signed Release Form is received, the Change team check the details to ensure all
areas have been covered (Proof of Testing results, regression plan worked Ok etc)

Authority will not be given if the documentation supporting the testing plans is not adequate. In
this case the change will need to be rebuilt / retested as appropriate. This process may be
iterative.

The Change team will then provide an agreed timeslot for the Release after discussions with the
implementer

The Change Team add an event to the Forward Schedule of Change stating the Release has
been authorised with a scheduled start and finish date & time.

NOTE:
If the change type is ‘Standard’ then an agreed timeslot isn‟t relevant at this stage. To action a
„Standard Change‟ at any time, the user will need to complete a „Standard Release Notice‟
document but only AFTER the initial „Release‟ document has been authorised as per the „Raising
and Communicating the Release Document‟ processes above and below.

Communicating the Release Authorisation

The Change Management Team will issue an E-Mail to the Implementer/s indicating that the
Release has been authorised, quoting the previously allocated RFC Number, and the scheduled
date and time of the Release. A copy of this E-Mail will be sent to Operations, the PCMS Service
Desk and the relevant Customer Service/Account Manager/s.

A Release will only remain valid for 1 week after authorisation – any delays past this point
requires a new Release document and will have to go through the above process again, which
will mean obtaining all relevant signatures for authorisation – all alterations to the timings to be
agreed with the Change Management Team.

If for any reason the authorised scheduled date and time of the Release is to be altered within
the seven day window, then the Implementer must send an email to the Change Management
Team, stating the revised timings. This enables us to update to the Forward Schedule of
Change, and inform the relevant parties of the rescheduled Release timings - all alterations to
the timings to be agreed with the Change Management Team.

If a change „fails‟ then a new RFC will need to be raised to cover the fix.

Review of the Change
Once the release is actioned, a period of time will be allowed for any issues arising from the
change to become obvious. The change will then be reviewed by the implementer.
The Review process is carried out via email. The Change Team email a „Review‟ template to the
implementer who populate the form if there were any issues with the change/s. The completed
form is emailed back to the Change Team @ changecontrol@pcmsgroup.com

The Change team can then update „The Forward Schedule of Change‟ status to „Reviewed‟.

92b73369-5d3e-4a75-8b90-5565d16579dc.docversion number 2.0
Author Rob Brain                      Page 6                                         19/07/2011
REQUEST FOR CHANGE
    DOCUMENT
      (RFC)




92b73369-5d3e-4a75-8b90-5565d16579dc.docversion number 2.0
Author Rob Brain                      Page 7                 19/07/2011
This page summarises the fields that appear on the RFC form, and
explains briefly what information is required to complete each field.

     REQUEST FOR CHANGE (RFC) – Details Required
     (all sections to be completed unless otherwise stated)

1)   Change prepared by – person writing the Change request.
     Date:- Date document raised.
     Job Number:- PCMS job number as allocated by Purchasing Dept
     Change Type:- Basic, Standard or Emergency (see „Change Types‟ on page 3 of this
     document)
     Platform:- Operating System of machine/s.
     Machine/s – Systems affected – PCMS Machine name/s
     Client:- name of client – could be one client, a list of clients, or “all”.
     For Change Management Use Only
     Priority: - Low, Medium, High or Urgent (see notes on page 4 of this document)
     Change Number: Number allocated by the Change Management function, format is 3-4
     Characters of Customer Name + 3 digits starting at 001.
     Category: - Minor, Significant or Major(see notes on pages 4 of this document)

2)   Planned Date & Time
     (What are the requirements for the end user i.e. desired implementation date/time of the
     release?)

3)   Planned Implementer(s)
     (The Resource carrying out the change)

     Reserve Implementer(s)
     (Alternative Resource in the event the above are not available to perform the change. If no
     reserve is possible state „why‟. We are trying to avoid single points of failure)

4)   Summary of Change
     (In a non technical way give an overview of change taking place and why?)

5)   Impact of change
     (In a non technical way give the impact/effect of the Change on the following)
     Business of the Client
     (Give the impact of the Change on the business of the Client)

     Confidentiality of the Data/System(s)
     (Assess the risk of whether confidential information relating to the change will be
     compromised)

     Integrity of the Data/System(s)
     (Assess whether the change will affect the correctness of Data used directly or indirectly
     with this change)

     Availability of the Data/System(s)
     (Assess whether the change will impact on the availability of this or related Systems and
     Resources)

6)   Identified Risks of Change
     Risk(s) associated with the change. What could go wrong by carrying out the change?

92b73369-5d3e-4a75-8b90-5565d16579dc.docversion number 2.0
Author Rob Brain                      Page 8                                        19/07/2011
7)   Mitigation of Risks
     Steps taken to reduce the risk(s) as previously stated.

8)   Testing Methodology
     A description of the planned processes to test the Change

9)   Regression Methodology
     Is it possible to regress the Change? A list of vital Considerations to be completed if so. If
     not, why not?

10) Sign-off
    Implementer(s) – Resource doing the change
    Reserve Implementer(s) – Resource doing the change in case the above are unavailable
    Customer Service / Account Manager – PCMS Customer Service or Account Manager
    Change Management – Normally Rob Brain or Ed Wadey.




92b73369-5d3e-4a75-8b90-5565d16579dc.docversion number 2.0
Author Rob Brain                      Page 9                                          19/07/2011
               THE ‘REQUEST FOR CHANGE‟ DOCUMENT (RFC)
1)   Enter details in the Table below against the BOLD BLACK TEXT fields(Red Italic
     fields for Change Management use only)

Change Prepared by                                Date

Job Number                                        Change Type
                                                  (Basic/Standard/Emergency)

Platform                                          Machine

Client                                            Priority
                                                  (Change Mgmt use only)
Change Number                                     Category
(Change Mgmt use only)                            (Change Mgmt use only)



2) Planned Date & Time
(What are the requirements for the end user i.e. desired implementation date/time of the
release?)

3) Planned Implementer(s)
(The Resource carrying out the change)

Reserve Implementer(s)
(Alternative Resource in the event the above are not available to perform the change. If no
reserve is possible state „why‟)

4) Summary of Change
(In a non technical way give an overview of change taking place and why?)

5) Impact of change
(In a non technical way give the impact/effect of the Change on the following)
Business of the Client
(Give the impact of the Change on the business of the Client)

Confidentiality of the Data/System(s)
(Assess the risk of whether confidential information relating to the change will be compromised)

Integrity of the Data/System(s)
(Assess whether the change will affect the correctness of Data used directly or indirectly with
this change)

Availability of the Data/System(s)
(Assess whether the change will impact on the availability of this or related Systems and
Resources)

6) Identified Risks of Change
(What could go wrong?)

7) Mitigation of Risks
(What measures are we taking to reduce the above risks?)

8) Testing Methodology
(How is the change to be tested?)

92b73369-5d3e-4a75-8b90-5565d16579dc.docversion number 2.0
Author Rob Brain                     Page 10                                        19/07/2011
9) Regression Methodology
(e.g. What are the regression possibilities if the change is terminated? i.e. Briefly, how will the
change be backed out?)




92b73369-5d3e-4a75-8b90-5565d16579dc.docversion number 2.0
Author Rob Brain                     Page 11                                          19/07/2011
10) Sign-off

Sign off

Implementer(s): -
Print and Sign Name

Reserve Implementer(s): -
Print and Sign Name

Customer Service / Account Manager(s): -
Print and Sign Name

Change Management: - Rob Brain / Ed Wadey
Print and Sign Name



Roles – Note: No person can sign a document in more than one role.

Implementer(s) – Resource actually doing the change and will know all the ramifications.
They are signing to say that the change is as sound and safe as possible, and what will be done.

Reserve Implementer(s) – Resource who will carry out the change in the event that the
Planned Implementer/s are unavailable. They must have the required technical ability and
understanding of the change.

Customer Service / Account Manager(s) – PCMS Customer Service or Account Manager/s
They are signing off from a Customer Business perspective, e.g. consider timings and mitigation
of the impacts on the customer. Where authorisation is required from the Client prior to any
change being implemented, the PCMS Customer Service/Account Manager/s will only sign once
the Client/s have approved the change.

Change Management – Normally Ed Wadey, or Rob Brain. In an Emergency escalate to
Service Support manager or Operations Team Leader. We are signing for approval and
acceptance of the Request for Change. Info - A ‘Release’ document has to be raised and
authorised prior to implementation




92b73369-5d3e-4a75-8b90-5565d16579dc.docversion number 2.0
Author Rob Brain                     Page 12                                      19/07/2011
                      RELEASE
                     DOCUMENT




92b73369-5d3e-4a75-8b90-5565d16579dc.docversion number 2.0
Author Rob Brain                     Page 13                 19/07/2011
This page summarises the fields that appear on the RELEASE form,
and explains briefly what information is required to complete each
field

RELEASE – Details Required
(all sections to be completed unless otherwise stated)

11) Implementer(s) – person(s) doing the release
    Job Number - PCMS job number as allocated by Purchasing Dept
    Start Date & Time – Date Release requested to start – dd/mm/yy @ hh:mm
    Finish Date & Time – Date Release requested to finish - dd/mm/yy @ hh:mm
    NOTE: If this is a „Standard‟ change then the Start and Finish times should be left out and
     quoted „As Required‟. This is because a „Standard Release Notification‟ is to be used to
     action Standard changes
     Change Number: Number previously allocated by the Change Management function when
     the RFC was authorised, format is 3-4 Characters of Customer Name + 3 digits starting at
     001.
     Client - name of client

12) Summary of Change - Summary details Copied and Pasted from the corresponding RFC
     to allow signatories to understand what the change is about

13) Implementation Instructions – A sequential list of tasks/processes to be followed in
     order to put the Release live.

14) Regression Procedure - A sequential list of tasks/processes to be followed in order to
     back the Change out.

15) Testing Results - This section to show results of testing process – this may be a
     reference to another document if testing was extensive – document to be provided before
     sign-off is given.

16) Data Centre Implementation Form – all sections to be completed if the change
     involves installation or removal of hardware, otherwise to be left blank.

17) Sign-off
    Implementer – Person doing the release. Always required
    Operations – Team Leader / Shift Leader (Paul Davies, Steve Jones). This person is
    signing to say that they are aware of all needs / requirements to allow ops to cope with this
    change.
    Service Desk – Service Desk Manager / Team Leader. This person is signing to say that
    they are aware of all needs / requirements to allow the Service Desk to cope with this
    change.
    Technical Review – Review to be carried out and signed off by a suitably qualified team
    member with a skill-set that matches that of the Implementer. This person is signing to say
    that the change is as safe and sound as possible.
    Release Manager – always required. This will be Rob Brain or Ed Wadey.




92b73369-5d3e-4a75-8b90-5565d16579dc.docversion number 2.0
Author Rob Brain                     Page 14                                      19/07/2011
                              THE „RELEASE‟ DOCUMENT
11)
Implementer(s)                                                Job Number
Start Date & Time                                             Finish Date & Time
(dd/mm/yy @ hh:mm)                                            (dd/mm/yy @ hh:mm)
Change Number                                                 Client
(from corresponding RFC)



12) Summary of Change
(Summary details Copied and Pasted from the corresponding RFC to allow signatories to
understand what the change is about)


13) Implementation Instructions
(Step by step instructions to be taken to carry out the Release. E.g. process to change current configuration, files to be
used & locations, Cobol version number, if appropriate, software licence details, if appropriate, hardware serial numbers,
if appropriate, hardware model numbers, if appropriate)




14) Regression Procedure
(e.g. Step by step instructions to back out the change)


15) Testing Results
(Show testing results giving filenames, directories, etc)




92b73369-5d3e-4a75-8b90-5565d16579dc.docversion number 2.0
Author Rob Brain                     Page 15                                                            19/07/2011
(16)    HARDWARE at COVENTRY and LONDON

TYPE of REQUEST                                LOCATION
New Implementation                             Coventry
Amendment                                      London Redbus
Removal                                        London Telehouse

RACK Information
Rack ID                                        Rack Mounted?
‘U’ Number (from? to?)                         Freestanding?
                                               Will HW fit in
Are rack rails Supplied?
                                               standard Knurr rack?

HARDWARE Information
Make                                           IP Address
Model                                          Operating System
Serial Number                                  Label Name on kit
                                               PCMS PAT test
PAT Tested?
                                               reference number

POWER Requirements
Amount of power                                Sufficient Amps in
supplies required                              rack?
Increase Power to                              *If ‘Yes’ to Increase of Power then raise relevant
Rack? See note opposite*                       P.O documentation

KVM & NETWORK Requirements
Is there spare capacity on KVM to accommodate Hardware?
Number of Network Connections Required?
Type of Network Connections Required (i.e. cable types etc)

MAINTENANCE Information
Start Date                                     Expiry Date
Contract Number                                Cover/Response
Company                                        Phone Number
Address

SECURITIES & MONITORING
Tape back up required?                         Monitoring required?
ESCALATION (Who do Operations call in case of a problem?)
Service Owner/s                             Owner/s Tel Number
                                            Support Contact Tel.
Support Contact Names
                                            Numbers
Hours of Support                            Email




92b73369-5d3e-4a75-8b90-5565d16579dc.docversion number 2.0
Author Rob Brain                     Page 16                                        19/07/2011
(17) SIGN OFF (ALL signatures required for authorisation)


Implementer(s): -
(Print and Sign name)


Operations: -
(Print and Sign name)


Service Desk: -
(Print and Sign name)



Technical Review: -
(Print and Sign name)



Release Management: -
Rob Brain or Ed Wadey
(Print and Sign name)



Roles

No person can sign a document in more than one role.

Implementer – person actually doing the change and will know all the ramifications. This
person is signing to say that the change is as sound and safe as possible, and what will be done.


Ops sign-off – Team Leader / Shift Leader (Paul Davies, Steve Jones). This person is signing to
say that they are aware of all needs / requirements to allow ops to cope with this change.


Service Desk – Service Desk Manager / Team Leader. This person is signing to say that they
are aware of all needs / requirements to allow the Service Desk to cope with this change.


Technical Review – Review to be carried out and signed off by a suitably qualified team
member with a skill-set that matches that of the Implementer. This person is signing to say that
the change is as safe and sound as possible.


Release Management – Normally Rob Brain or Ed Wadey. In an Emergency :- Operations
Manager/ Team Leader. We are signing for Final Approval and acceptance of the Release.




92b73369-5d3e-4a75-8b90-5565d16579dc.docversion number 2.0
Author Rob Brain                     Page 17                                      19/07/2011
     STANDARD RELEASE
          NOTICE
        DOCUMENT




92b73369-5d3e-4a75-8b90-5565d16579dc.docversion number 2.0
Author Rob Brain                     Page 18                 19/07/2011
This page summarises the fields that appear on the STANDARD
RELEASE NOTICE form, and explains briefly what information is
required to complete each field

STANDARD RELEASE NOTICE– Details Required
(all sections to be completed unless otherwise stated)

18) Implementer(s) – person(s) doing the Release
    Date Raised– Date document Raised
    Client - name of client
    Job Number - PCMS job number as allocated by Purchasing Dept
    Standard Change No.: Number previously allocated by the Change Management function
    when the RFC was authorised, format is 3-4 Characters of Customer Name + 3 digits
    starting at 001.
    Machine/s – Systems affected – PCMS Machine name/s

19) Implementation Instructions – A sequential list of tasks/processes to be followed in
     order to put the Release live.
     Item to be Changed – name of hardware/software/code/script/document etc (Use PCMS
     Identifier where possible)
     Date(dd/mm/yy) – date the change is to be actioned
     Time(hh:mm) - time the change is to be actioned
     Duration(hh:mm) – expected length of time for the change to be implemented
     Change Detail – Summary of the change . What is being changed and why?

20) Regression Procedure - A sequential list of tasks/processes to be followed in order to
     back the Change out.

21) Data Centre Implementation Form – all sections to be completed if the change
     involves installation or removal of hardware, otherwise to be left blank.




92b73369-5d3e-4a75-8b90-5565d16579dc.docversion number 2.0
Author Rob Brain                     Page 19                                     19/07/2011
                  THE „STANDARD RELEASE NOTICE‟ DOCUMENT
 18)
 Implementer(s)                                   Date Raised

 Client                                           Job Number
 Standard Change No.                              Machine/s
 (from corresponding RFC)



  Implementation details
  (Details Changed)
  19)
Item to be      Date       Time    Duration      Change Detail
Changed         (dd/mm/yy) (hh:mm) (hh:mm)




 Regression Procedure
 (e.g. Step by step instructions to back out the change)
 20)




 92b73369-5d3e-4a75-8b90-5565d16579dc.docversion number 2.0
 Author Rob Brain                     Page 20                    19/07/2011
21) HARDWARE at COVENTRY and LONDON

TYPE of REQUEST                                LOCATION
New Implementation                             Coventry
Amendment                                      London Redbus
Removal                                        London Telehouse

RACK Information
Rack ID                                        Rack Mounted?
‘U’ Number (from? to?)                         Freestanding?
                                               Will HW fit in
Are rack rails Supplied?
                                               standard Knurr rack?

HARDWARE Information
Make                                           IP Address
Model                                          Operating System
Serial Number                                  Label Name on kit
                                               PCMS PAT test
PAT Tested?
                                               reference number

POWER Requirements
Amount of power                                Sufficient Amps in
supplies required                              rack?
Increase Power to                              *If ‘Yes’ to Increase of Power then raise relevant
Rack? See note opposite*                       P.O documentation

KVM & NETWORK Requirements
Is there spare capacity on KVM to accommodate Hardware?
Number of Network Connections Required?
Type of Network Connections Required (i.e. cable types etc)

MAINTENANCE Information
Start Date                                     Expiry Date
Contract Number                                Cover/Response
Company                                        Phone Number
Address

SECURITIES & MONITORING
Tape back up required?                         Monitoring required?
ESCALATION (Who do Operations call in case of a problem?)
Service Owner/s                             Owner/s Tel Number
                                            Support Contact Tel.
Support Contact Names
                                            Numbers
Hours of Support                            Email




92b73369-5d3e-4a75-8b90-5565d16579dc.docversion number 2.0
Author Rob Brain                     Page 21                                        19/07/2011
                      REVIEW
                     DOCUMENT




92b73369-5d3e-4a75-8b90-5565d16579dc.docversion number 2.0
Author Rob Brain                     Page 22                 19/07/2011
      Review checklist
      All questions should be answered with Y, or N in the boxes on the right unless otherwise stated

1) Has the Change had the desired effect & met its objectives? If No, detail shortfalls below.

1a)



2) Are the Users / Customers content with the result? If No, detail shortcomings below.

2a)



3) Have there been any unexpected/undesirable side effects? If Yes, input detail below

3a)



4) Were the resources required to implement the Change as planned? If No input detail below.

4a)



5) Did the Implementation plan work correctly/as planned? If No, detail differences below.

5a)



6) Was the Change implemented on time? If No, detail why not below

6a)



7) Was the Regression Plan needed? If Yes, detail reasons below?

7a)



8) If Yes to question 7, Did the Regression Plan work correctly? If No detail errors/reasons below.
Otherwise enter N/A
8a)




      92b73369-5d3e-4a75-8b90-5565d16579dc.docversion number 2.0
      Author Rob Brain                     Page 23                                        19/07/2011

				
DOCUMENT INFO
Shared By:
Categories:
Tags:
Stats:
views:35
posted:7/19/2011
language:English
pages:23
Description: Rfc Acceptance Form Template document sample