Your SlideShare is downloading. ×
Numara change & approval mgmt
Upcoming SlideShare
Loading in...5

Thanks for flagging this SlideShare!

Oops! An error has occurred.


Saving this for later?

Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime - even offline.

Text the download link to your phone

Standard text messaging rates apply

Numara change & approval mgmt


Published on

SFHDI November Meeting presentation by Numara Software

SFHDI November Meeting presentation by Numara Software

Published in: Technology

  • Be the first to comment

  • Be the first to like this

No Downloads
Total Views
On Slideshare
From Embeds
Number of Embeds
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

No notes for slide


  • 1. David Coffey Senior Solutions Engineer Numara Software Change & Approval Management Why is it important to have an integrated change solution?
  • 2. Change Management – The Heart of the IT Universe
  • 3. Change Management – The Heart of the IT universe?
    • The heart is critical for survival.
    • It should be maintained with healthy habits
    • Impacts many systems within the body
    Change Management is the same!!!
  • 4. Notes
    • This Presentation is Intended as a Guideline Only
      • Numerous ways to implement Change Management
      • Suggests Good Practice Methodology
    • Not All Inclusive
      • Different organizations may opt for different steps/statuses/etc.
    • Process Perspective not Tool Perspective
      • Process Must be in Place in Order to Properly Leverage any Change Management Software Solution
  • 5. What is Change Management?
    • Definitions:
      • Wiki - a structured approach to shifting/transitioning individuals, teams, and organizations from a current state to a desired future state.
      • ITIL - (Change) The addition, modification or removal of anything that could have an effect on IT Services.
      • ITIL - The primary objective of Change Management is to enable beneficial Changes to be made, with minimum disruption to IT Services
  • 6. Change Management Objective
    • To ensure that standardized methods and procedures are used for efficient and prompt handling of all changes to controlled IT infrastructure , in order to minimize the number and impact of any related incidents caused by the change, upon service.
  • 7. Reactive Change
    • Reactive:
    • 60 to 80 percent of failures in the IT infrastructure come from changes introduced by the IT department — many of which are not approved or authorized.
    • So…
    • Change Management shouldn’t be an after-thought!
  • 8. Don’t Be Naive
    • So it is negligent – or possibly just naïve – when many software vendors separate “the heart” out of Service Support and imply that Change Management is not needed or necessary.
    • This is analogous to saying that the body does not need a circulatory system – or is something that you can “tack on” later.
    • Having an integrated Change Management is crucial for a healthy IT organization.
  • 9. Why Change Management?
    • Change Management can:
      • Ensure standardized methods, processes and procedures are used for all changes,
      • Facilitate efficient and prompt handling of all changes
      • Maintain the proper balance between the need for change and the potential detrimental impact of changes.
    • Change Management acts as the control function for the CMDB. Without it, the CMDB will become inaccurate quickly!
  • 10. ITIL V3 Service Delivery Wheel Change Management resides within the ‘Service Transition’ arrow of the wheel.
  • 11. Typical Sources for Requests for Change Change Management
  • 12. Where to Start?
    • Start by defining ‘What is a Change’?
      • Each company may view this differently
      • Commonly, Change Requests are filed for any modifications or Status Changes to any item tracked in the CMDB, including:
        • Servers
          • This includes Planned Reboots!
          • Middleware
          • Services such as IIS
          • New Servers/Services
        • Network Components
        • Applications - License Adds/Removes
        • Databases
        • Storage Arrays
        • Desktops
        • Monitoring Tools
        • Anticipated Workloads
  • 13. What is NOT a Change?
    • Sometimes an easier approach
      • Remaining artifacts will by default, require RFC’s (Requests for Change)
      • Minor modifications to desktops (Unless tracked in CMDB)
      • Adds/subtracts to users
      • Password Resets
      • Office Moves (unless locations are tracked as part of CMDB)
      • Phone/monitor/keyboard changes
      • Automatic (Machine Controlled) alterations/updates
  • 14. Check Your Environment
    • Is anything in place now?
      • Activities that can be leveraged
      • Focus on Repeat-ability of existing practices
    • Interview existing users/actors in existing activities
      • Distribute the results of these interviews as ‘Findings’ to help enlist support
    • Remember: Just because you’ve always done it this way doesn’t mean it’s the right way
      • Use this as an opportunity to create much needed cultural change
  • 15. Strategy
    • Assign Owner
      • Change Manager Role
        • Acts as the CAB for ‘Standard Changes’
        • Should review Changes for accuracy and compliance with policy as first step
        • Is the ‘Accountable’ party for the Change Process
      • Additional staff as needed based on volume
    • Place Governance within a “Controls” Environment
      • Security
      • Audit
    • Avoid
      • Placement within Infrastructure or other support groups
        • No impetus to enforce process
        • Fox in the Hen House syndrome
  • 16. Strategy
    • Develop Policy
      • Enforceable ‘laws’ that Change Manager can use as indicator of compliance
    • Develop Process Steps
      • Map to RACI for clear Responsibility, Accountability
      • Also indicates where Consultation is required
        • Consultation typically implies Approval
      • Shows which parties should be Informed of upcoming Change
      • Map to Swim-lane Diagram
    • Select CAB Members
      • Fixed Members could include:
        • Security
        • Infrastructure Support
        • Operations
        • Customer Representative(s)
        • Network
  • 17. Strategy
    • RFC’s Content
      • Dates/Times
      • Type of Change
      • Goal of Change
      • Impacted CI’s (What is actually being changed?)
      • Business Justification
      • Description (Details of Change)
      • Plans
        • Back-Out Plan
        • Implementation Plan
        • Testing Plan
        • Communication Plan
      • Resources
  • 18. Strategy
    • RFC Content - Scope Assessment
      • Scope of Change is Typically Considered to be Based on 2 factors
        • Risk
        • Impact
      • Typical Scope Terminology Includes:
        • Major – For High Risk and Impacts
        • Significant – For Substantive Risks and Impacts
        • Minor – For Low Risk and Impacts
  • 19. Strategy
    • Scope Assessment Continued
    RISK Ability to Back-Out of a Change High Impossible or Unproven Medium Difficult or Time-consuming Low Direct or Straightforward IMPACT Impingement upon Systems or Services During or After the Change High Critical (Revenue Stream) Systems or Services Unavailable or Possibly Rendered Non-Functional Medium Important Systems or Services Unavailable or Possibly Rendered Non-Functional Low Non-Critical or Redundant Systems or Services Unavailable or Possibly Rendered Non Functional
  • 20. Strategy
    • Determine Change Meeting Schedule
      • Change Management Facilitates
      • Bring up for discussion:
        • Changes that are fully Reviewed
          • Offline Reviewers
          • May include Technical Review Board Members
        • Changes “Pended” in previous CAB session
        • Change Calendar showing Scheduled, Approved Changes 2 weeks out
        • Changes must be represented to be Approved by the CAB
    • Identify Emergency CAB Member(s)
      • Often Executive Role
      • Consider a Back-Up or Proxy
  • 21. Strategy
    • Determine Change Type
      • Standard Changes
      • Highly Repeatable
      • No Impact or Outage – VERY Low Risk
      • Proven Successful (Zero Failures in X number of attempts!)
      • Presented to CAB for Permission to Become Standard
      • Minimal Review/Approval (Effectively Pre-Approved)
      • Normal Changes
      • Full Review Process (Sometimes Including CAB)
      • Adheres to Lead Time Requirements
      • Changes will have Higher Potential for Impact
      • Driven by Incident Management
      • Emergency Changes
      • For Break-Fix Only!
      • Driven by Incident Management
      • Not Intended to Cover for Poor Planning
  • 22. Strategy
    • Other Change Types to Consider
      • Unscheduled Changes
      • For Changes that do not Meet Lead Time Requirements
      • Approved by Emergency CAB
      • Enables Clear Reporting of Poorly Planned Changes
      • Differentiates True Emergency Work from Poor Planning
      • Becomes a Goal to Reduce their Frequency and Volume
      • Latent Changes
      • For Break-fix Work Done ‘On the Fly’
      • Done in the Heat of an Outage where the ’Fix’ won’t cause Additional downtime
      • Filed ‘After the Fact’ as a Documentation/Paper Trail
      • Should always be Tied to an Incident Record
      • Never to be Used if Adequate Time for an Emergency Change
  • 23. Strategy Change Statuses Draft
    • Still Being Built
    • Ready for Review – Begins Review/Approval Cycle
    In Review
    • May be a Separate ‘Review’ Status for Each Review Step
    • Indicates all ‘Approvals’ have taken place (Typically Offline)
    • Precondition for Appear on CAB Agenda
        • Supply Pending reason
        • Typically used for additional clarification
        • Not ‘Intended’ to be halted
    On Hold
        • Change is still ‘valid’ but may be timed inappropriately
        • An ‘Intentional’ halt to the Change
        • Cannot be performed – A ‘Dead’ Status
        • Opted not to perform due to changes in conditions
        • Only CAB, E-Cab or Change Manager
  • 24. Strategy Completion/Closure Codes – Allows for Capture Results After Closure Status Success
        • Change was implemented successfully AND achieved goal
    Success with Issues
        • Change was implemented and achieved its goal but encountered issues during implementation
        • Change did NOT achieve goal
        • Even if implemented successfully
            • Patch to correct application errors
    Backed Out
        • Change caused an issue and had to be removed
        • For Changes that were Withdrawn during the process
  • 25. Cultural Acceptance
    • If starting from a largely ‘Blank Slate’ this will be your biggest hurdle!
      • Even attempts to make the existing process more ‘formal’ can be viewed with scorn by some groups/individuals
    • Enlist ‘Debunkers’ as Reviewers
      • Brings them into the process
      • Can become strongest advocates
    • Do you have Executive Support?
      • Absolutely necessary for success and acceptance
      • Debunkers will use Executives to skirt process
    • Consider CMDB!
      • Very difficult to Scope Change Management without it
      • Oversized Scope can make acceptance more difficult
  • 26. Planning
    • Who can Review and How Many Reviewers?
      • Different for each change
      • Change Manager should perform initial review
    • Who can Reject?
      • May Vary by Change Type and Scope
      • Does 1 detractor cancel (Reject) the Change?
    • Determine Processes
      • At which points are Reviews/Approvals necessary?
      • What criteria triggers the Review/Approval?
    • If SOX Compliance is a concern
      • All Approvals may be Required
      • One ‘No’ Vote Could Become the ‘I Told You So’ Vote from an Audit Perspective
  • 27. Planning
    • Determine Lead Times
      • Minimum of 3 weeks for Major Changes
      • At least 2 weeks for Significant Changes
      • 1 Week for Minor
      • “ Standard” Changes typically have a low lead time requirement
      • Changes that do not meet lead times are ‘Unscheduled’
    • Develop “Appeals Process”
      • For Changes that do not comply with Lead Times
      • Typically an ‘Unscheduled’ Change
      • Leverage Emergency CAB for this Process
  • 28. Operation
    • Stay Consistent
      • Flexing of rules will lead to violations
    • Take Attendance at CAB Meetings
    • Develop Reporting
      • Demonstrate
        • Number of Changes Processed
        • Number of Successes
        • Number of Failures
        • Number Backed-Out
        • Number of Emergencies
        • Failed Changes by Implementation Team
  • 29. Operation
    • Perform Post-Mortems (Post Implementation Review)
      • Target Failures and Successes
      • Lessons Learned
    • Develop CIP (Continuous Improvement Plan)
      • Observe weaknesses in process
      • Use Lessons Learned
      • Leverage Reporting
    • Be ‘Diplomatically Intolerant”
      • Don’t let violations of policy go un-responded
      • Stress importance of Change Process
  • 30. Critical Success Factors
  • 31. Summary
    • Change is often complex – but it doesn’t have to be.
    • The greatest ROI an organization can have with the automation and implementation of an effective Service Desk solution is in the area of seamlessly integrated Change Management.
    • Change Management is more than an after-thought, it is the end goal and…
    • The Heart of the IT universe!
  • 32. Questions? Thank You For Attending