2. Change Management
Any deliberate action that alters the form, fit, or function
of Configuration Items (CI) that impacts the production
IT infrastructure.
Scope: Defined by business need/statutory regulatory compliance
2
In Scope Out of Scope
Production Services, systems, and
applications
Data management – backup and
restore
Test/Dev Environments that
interface with Production
environments.
Sandboxed test/dev environments
Service Design Packages (Service
support and configuration)
3. Change Management
Benefits
• Implementing changes in required times
• Meet SLA, while optimising costs
• Reducing failed changes and rework
• Assessing and managing risks
• Managing egress of Services from ELS
• Agile
Risks
• Non-compliance/subversion
• Legacy perception
• Executive support lacking
3
4. Service Introduction Process
Project Delivery Framework:
•Considerations
– Design
– Build
– Solution BAU functional testing
– Component testing
– Service readiness
•Output:
– Approved as a Service and made available in the Service
catalogue.
6
5. Service Introduction Process
Aim
To provide a robust and stable mechanism for the controlled
delivery of IT Services and Environments, to satisfy a
business appetite
Scope
ALL Services/Environments including Development, Build,
Test and Production
7
6. Service Introduction Process
Benefits
– Establish a new or changed service WITHIN predicted cost, quality
and time estimates.
– Ensures integrity of all customer assets, service assets and
configurations.
– Coordinate activities across projects, suppliers and service teams.
– Communications with customers, users and stakeholders.
Risks
– Non-compliance
– Lengthened time frames for delivery
– Perception of “blocker”
8
7. Service Introduction Process Tools
Gated process
• Inception, Design, Build, Test, Operational acceptance
Checklists
• Ask the questions at each stage/checkpoint to
transition to the next
Evidence artefacts
• Living documents that form the core of the SDP when
the Service is in production
9
9. Service Introduction Tools
Implementation Checkpoint:
• Business Change
• Design
• Testing
• Disaster Recovery
• Technical Readiness
• Production Readiness
• Release Management
• Training & Communication
• Security
• Deployment Plan
11
10. Sample Criteria
Production Readiness
Support Agreements and SLA: Support RACI defined and agreed. Support
agreements, and associated SLA, in place with ServiceProviders and 3rd
Parties (as required) and are either activated or ready to be activated.
Technical Readiness
Implementation Strategy & Plans: Implementation / cutover / fall back plans in
place and ready to be activated. Data creation, conversion and/or cutover
mechanisms in place and are ready to be executed. Deployment ownership
and responsibilities defined and accepted.
Disaster Recovery
Have the business accepted risks to Service on go live, and who has accepted
them? If the RTO/RPO can not be met with the design have the business /
service owner been made aware and agreed to revised RTO / RPO?
12
11. Sample Criteria
Security
Have all priviledge access accounts been identified and handed over to
Production?
Release Management
Release necessitates a significant outage to the business which impacts beyond
Business Continuity Plans
Deployment Plans
Has the go-live/hand-over date been confirmed and communicated to all relevant
teams?
13
12. Sample Artefacts
Organisational Readiness Assessment:
• Financial Assessment: Cost of implementing and supporting the service;
• Technical Assessment: Effect on IT infrastructure – Hardware, software, interfaces;
• Resource Assessment: More/less people?
• Organisational Assessment: New functions required to support the service?
Service Lifecycle plan
• Service Program
• Service Transition Plan
• Service Operational Acceptance Plan
• Service Acceptance Plan
14
17. Delivery of Approved Service
Define deployment method:
• User self install/Package push/Assisted
install/Announcement/Pilot/ELS deployment
Engage Change Management
• Present at CAB
• 7 R of Change Management
• Approved deployment plan
• Validates deployment readiness
19
18. Change Management Process flow
20
CAB requirements Yes NO
RFC completed fully? Consider at CAB Reject RFC
CP5 completed Continue to next Refer to PMO
Required artefacts handed over to Run
organisation
Continue to next Refer to CP5
Knowledge transfer/training completed Continue to next Enter ELS process
Deployment plans confirmed Continue to next Create
deployment plan
Deployment & Support resources
confirmed
Continue to next
Schedule approved Approve RFC for
Implementation
Reschedule RFC
& resubmit
19. Service Introduction & Change Management
Same concept
• Identify, define, design, build, test, validate, deploy
Appropriate rigour
Aligned but different focus
• Ready to launch –v- launch ready
21
20. Service Introduction & Change Management
Change Management facilitates Service
Introduction
Service Introduction supports Change Management
function
Change Management outputs include addendum to
SDP
22
22. Contact details
Anthony Oxley, MBCS
IT Change Manager, Rolls-Royce Plc
24
anthony.oxley@rolls-royce.com
+44(0)7730957808
http://uk.linkedin.com/in/tonyoxley
@transitionthis
Editor's Notes
Change Management Process
To accommodate new technologies and constantly changing business requirements, controlling “change” to the existing IT environment becomes a necessity. A formal Change Management process is essential to ensuring that standardized methods and procedures are used for efficient and prompt handling of all changes, in order to meet changing business requirements, minimize the impact of Change-related incidents or problems upon service quality and, consequently, to improve the day-to-day operations of the organization. If Changes can be managed to optimize risk exposure, severity of impact and disruption, and of course to be successful at the first attempt, the bottom line for the business is the early realization of benefits (or removal of risk), with a saving of money and time.
Standard Change: A recurrent change that is well known and has been proceduralised to a follow a pre defined, low risk path that is the accepted response to a specific requirement or a set of circumstances where authority is effectively given in advance of implementation. For changes that are done frequently a Standard Change Procedure can (should) be created and approved in the CAB. This Change will then become pre-approved as long as the procedure is followed in detail. Emergency Change: A Change that must be introduced as soon as possible. For example to resolve a Major Incident or implement a Security patch. The Change Management Process has a specific Procedure for handling Emergency Changes. The Change Management process includes mechanism for implementing urgent change where these are due to operational problems in the deployed IT estate or urgent and unforeseen business imperatives. Poor project planning will not normally be accepted as a reason for urgent
Benefits
Plan and coordinate the resources to establish successfully a new or changed service into production WITH predicted cost, quality and time estimates.
Plan changes required that ensures integrity of all customer assets, service assets and configurations as they evolve through service transition.
Coordinate activities across projects, suppliers and service teams.
Communications with customers, users and stakeholders.
Organisational Readiness Assessment: Asks the question “Do we have the right people skills and competencies in place to deliver the service?” A key component of the SDP, it includes the Skills, Competencies, and Capabilities needed to deliver the service:
Business Benefit: , Value created/delivered; Financial Assessment: Cost of implementing and supporting the service; Technical Assessment: Effect on IT infrastructure – Hardware, software, interfaces; Resource Assessment: More/less people?
Organisational Assessment: Do we need new functions required to support the service
Service Lifecycle Plan: Overall plan to cover the tactical and operational stages of the service lifecycle including details for transitioning, operation, and CSI of the new service. Cradle to grave. The Service Lifecycle Plan incorporates the Service Programme (Service Retirement Plan is also included here since the SDP will follow the service to the grave.)
Service Program: Covers all stages of the lifecycle of the service. Phasing, transition, operation, improvement. How do we manage the service from a-z?
Service Transition Plan: Overall transition strategy. Define objectives. State policy and do risk assessment. The "how to" of the build and transition of a service form development to live status. It provides guidance and process activities for the transition of services in the operational business environment. This information would be used to support the Change Management process.
Service Operational Acceptance Plan: Refers to the overall operational strategy, objectives, policy, risk assessment and plans for interface dependency management and planning, event reporting for service issues, and final service acceptance. Management of the operational environment.
Service Acceptance Criteria: Defined criteria showing development and usage of the service through each stage of the service lifecycle for all environments covering guaranteed and pilot criteria, and their associated time frames based on quantifiable testing standards,
Based on evidence, it should cover all areas of the service including: User Acceptance Testing, Functional testing, Component testing, System compatibility and integration, including failure, and alarm, testing, Logistics and release testing, and management requirements testing, incorporating control, monitoring, measuring, reporting, and backup and recovery testing.
Define deployment method:
User self install/Package push/Assisted install/Announcement/Pilot/ELS deployment
Engage Change Management
Present at CAB
7 R of Change Management
The following questions must be answered for all changes:
· Who RAISED the change?
· What is the REASON for the change?
· What is the RETURN required from the change?
· What are the RISKS involved in the change?
· What RESOURCES are required to deliver the change?
· Who is RESPONSIBLE for the build, test and implementation of the change?
· What is the RELATIONSHIP between this change and other changes?
Approved deployment plan – Supporting infrastructure resources capable;
Validates deployment readiness – All communications issued/training completed/Servicedesk aware
