{"id":194,"date":"2015-12-22T03:51:54","date_gmt":"2015-12-22T03:51:54","guid":{"rendered":"http:\/\/it-toolkits.org\/blog\/?p=194"},"modified":"2016-07-11T09:06:38","modified_gmt":"2016-07-11T09:06:38","slug":"how-to-implement-basic-change-management","status":"publish","type":"post","link":"https:\/\/it-toolkits.org\/Blog\/how-to-implement-basic-change-management.html","title":{"rendered":"How to Implement Basic Change Management"},"content":{"rendered":"

\"IT-Toolkits_change_3\"<\/a><\/h2>\n

1. Start small and keep it simple<\/h2>\n

Identify key technical folks from each of the functional IT group (Network, Development, etc) to serve as a\u00a0 Change Advisory Board (CAB). Meet face to face with these key people weekly to review all planned changes.<\/p>\n

Basic game plan:<\/p>\n

    \n
  • Identify a Change Manager to facilitate a weekly CAB meeting.<\/li>\n
  • All changes will be reviewed at the CAB ( Make CAB the place to be, and over time, the value of the review will attract \u201call\u201d.<\/li>\n
  • CAB is comprised of technical folks and decision makers<\/li>\n
  • The role of CAB is to review proposed changes and determine if they\u2019re likely to cause harm to the business. (Keep CAB focused on protecting the business from adverse impact, and don\u2019t allow CAB to become a bureaucratic roadblock!<\/strong><\/em>)<\/li>\n
  • Maintain some form of Change Log to keep track of proposed and approved changes. (I\u2019d recommend a spreadsheet, so you stay focused on the value<\/strong><\/em>of the process, and not the details)<\/li>\n
  • Track Change and outcomes<\/li>\n
  • Establish an emergency change process to handle urgent and critical changes via email. (This is important to avoid the \u201ctoo slow and bureaucratic\u201d criticism)<\/li>\n
  • Over time, you want to see failed and rolled back changes decrease.<\/li>\n<\/ul>\n

    You\u2019ll need to develop your own groove, based on the culture, but that\u2019s the short of it. Keep it simple and\u00a0 focus on protecting the business from harm.<\/p>\n

    2. Improve the CAB process<\/h2>\n

    Principle: Use failed changes as opportunities to improve! (not finger point)<\/em><\/p>\n

    Use the outcomes data to identify ways to improve the CAB. For instance, for a failed change, are there things CAB could have anticipated and avoided the failure?<\/p>\n

      \n
    • Take time at CAB meetings to review changes from last week<\/strong><\/em>. If any rolled back or failed, are there any lessons to be learned that<\/strong><\/em>\u00a0 could improve the CAB process?\n
        \n
      • If the lessons learned are small and doable, make them part of the CAB culture immediately<\/li>\n
      • If the lessons learned require more work, keep a prioritized list, and implement the high priority ones as opportunity allows.<\/li>\n<\/ul>\n<\/li>\n
      • Ensure Service Desk and Operations staff are part of the CAB, and have access to the details of changes.<\/li>\n<\/ul>\n

        3. Celebrate Successes<\/h2>\n

        By just bringing the CAB team together, this basic ITIL Change Management process is sure to uncover some sources of unintended consequences from proposed changes. When the CAB heads these off at the pass before causing customer impact, celebrate! Let senior management and key business stakeholder know that the process discovered and avoided business impact.<\/p>\n","protected":false},"excerpt":{"rendered":"

        1. Start small and keep it simple Identify key technical folks from each of the functional IT group (Network, Development,<\/p>\n","protected":false},"author":1,"featured_media":271,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[16],"tags":[],"class_list":["post-194","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-it-change-management"],"_links":{"self":[{"href":"https:\/\/it-toolkits.org\/Blog\/wp-json\/wp\/v2\/posts\/194"}],"collection":[{"href":"https:\/\/it-toolkits.org\/Blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/it-toolkits.org\/Blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/it-toolkits.org\/Blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/it-toolkits.org\/Blog\/wp-json\/wp\/v2\/comments?post=194"}],"version-history":[{"count":0,"href":"https:\/\/it-toolkits.org\/Blog\/wp-json\/wp\/v2\/posts\/194\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/it-toolkits.org\/Blog\/wp-json\/wp\/v2\/media\/271"}],"wp:attachment":[{"href":"https:\/\/it-toolkits.org\/Blog\/wp-json\/wp\/v2\/media?parent=194"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/it-toolkits.org\/Blog\/wp-json\/wp\/v2\/categories?post=194"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/it-toolkits.org\/Blog\/wp-json\/wp\/v2\/tags?post=194"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}