- Management Reference Guide
- Table of Contents
- Introduction
- Strategic Management
- Establishing Goals, Objectives, and Strategies
- Aligning IT Goals with Corporate Business Goals
- Utilizing Effective Planning Techniques
- Developing Worthwhile Mission Statements
- Developing Worthwhile Vision Statements
- Instituting Practical Corporate Values
- Budgeting Considerations in an IT Environment
- Introduction to Conducting an Effective SWOT Analysis
- IT Governance and Disaster Recovery, Part One
- IT Governance and Disaster Recovery, Part Two
- Customer Management
- Identifying Key External Customers
- Identifying Key Internal Customers
- Negotiating with Customers and Suppliers—Part 1: An Introduction
- Negotiating With Customers and Suppliers—Part 2: Reaching Agreement
- Negotiating and Managing Realistic Customer Expectations
- Service Management
- Identifying Key Services for Business Users
- Service-Level Agreements That Really Work
- How IT Evolved into a Service Organization
- FAQs About Systems Management (SM)
- FAQs About Availability (AV)
- FAQs About Performance and Tuning (PT)
- FAQs About Service Desk (SD)
- FAQs About Change Management (CM)
- FAQs About Configuration Management (CF)
- FAQs About Capacity Planning (CP)
- FAQs About Network Management
- FAQs About Storage Management (SM)
- FAQs About Production Acceptance (PA)
- FAQs About Release Management (RM)
- FAQs About Disaster Recovery (DR)
- FAQs About Business Continuity (BC)
- FAQs About Security (SE)
- FAQs About Service Level Management (SL)
- FAQs About Financial Management (FN)
- FAQs About Problem Management (PM)
- FAQs About Facilities Management (FM)
- Process Management
- Developing Robust Processes
- Establishing Mutually Beneficial Process Metrics
- Change Management—Part 1
- Change Management—Part 2
- Change Management—Part 3
- Audit Reconnaissance: Releasing Resources Through the IT Audit
- Problem Management
- Problem Management–Part 2: Process Design
- Problem Management–Part 3: Process Implementation
- Business Continuity Emergency Communications Plan
- Capacity Planning – Part One: Why It is Seldom Done Well
- Capacity Planning – Part Two: Developing a Capacity Planning Process
- Capacity Planning — Part Three: Benefits and Helpful Tips
- Capacity Planning – Part Four: Hidden Upgrade Costs and
- Improving Business Process Management, Part 1
- Improving Business Process Management, Part 2
- 20 Major Elements of Facilities Management
- Major Physical Exposures Common to a Data Center
- Evaluating the Physical Environment
- Nightmare Incidents with Disaster Recovery Plans
- Developing a Robust Configuration Management Process
- Developing a Robust Configuration Management Process – Part Two
- Automating a Robust Infrastructure Process
- Improving High Availability — Part One: Definitions and Terms
- Improving High Availability — Part Two: Definitions and Terms
- Improving High Availability — Part Three: The Seven R's of High Availability
- Improving High Availability — Part Four: Assessing an Availability Process
- Methods for Brainstorming and Prioritizing Requirements
- Introduction to Disk Storage Management — Part One
- Storage Management—Part Two: Performance
- Storage Management—Part Three: Reliability
- Storage Management—Part Four: Recoverability
- Twelve Traits of World-Class Infrastructures — Part One
- Twelve Traits of World-Class Infrastructures — Part Two
- Meeting Today's Cooling Challenges of Data Centers
- Strategic Security, Part One: Assessment
- Strategic Security, Part Two: Development
- Strategic Security, Part Three: Implementation
- Strategic Security, Part Four: ITIL Implications
- Production Acceptance Part One – Definition and Benefits
- Production Acceptance Part Two – Initial Steps
- Production Acceptance Part Three – Middle Steps
- Production Acceptance Part Four – Ongoing Steps
- Case Study: Planning a Service Desk Part One – Objectives
- Case Study: Planning a Service Desk Part Two – SWOT
- Case Study: Implementing an ITIL Service Desk – Part One
- Case Study: Implementing a Service Desk Part Two – Tool Selection
- Ethics, Scandals and Legislation
- Outsourcing in Response to Legislation
- Supplier Management
- Identifying Key External Suppliers
- Identifying Key Internal Suppliers
- Integrating the Four Key Elements of Good Customer Service
- Enhancing the Customer/Supplier Matrix
- Voice Over IP, Part One — What VoIP Is, and Is Not
- Voice Over IP, Part Two — Benefits, Cost Savings and Features of VoIP
- Application Management
- Production Acceptance
- Distinguishing New Applications from New Versions of Existing Applications
- Assessing a Production Acceptance Process
- Effective Use of a Software Development Life Cycle
- The Role of Project Management in SDLC— Part 2
- Communication in Project Management – Part One: Barriers to Effective Communication
- Communication in Project Management – Part Two: Examples of Effective Communication
- Safeguarding Personal Information in the Workplace: A Case Study
- Combating the Year-end Budget Blitz—Part 1: Building a Manageable Schedule
- Combating the Year-end Budget Blitz—Part 2: Tracking and Reporting Availability
- References
- Developing an ITIL Feasibility Analysis
- Organization and Personnel Management
- Optimizing IT Organizational Structures
- Factors That Influence Restructuring Decisions
- Alternative Locations for the Help Desk
- Alternative Locations for Database Administration
- Alternative Locations for Network Operations
- Alternative Locations for Web Design
- Alternative Locations for Risk Management
- Alternative Locations for Systems Management
- Practical Tips To Retaining Key Personnel
- Benefits and Drawbacks of Using IT Consultants and Contractors
- Deciding Between the Use of Contractors versus Consultants
- Managing Employee Skill Sets and Skill Levels
- Assessing Skill Levels of Current Onboard Staff
- Recruiting Infrastructure Staff from the Outside
- Selecting the Most Qualified Candidate
- 7 Tips for Managing the Use of Mobile Devices
- Useful Websites for IT Managers
- References
- Automating Robust Processes
- Evaluating Process Documentation — Part One: Quality and Value
- Evaluating Process Documentation — Part Two: Benefits and Use of a Quality-Value Matrix
- When Should You Integrate or Segregate Service Desks?
- Five Instructive Ideas for Interviewing
- Eight Surefire Tips to Use When Being Interviewed
- 12 Helpful Hints To Make Meetings More Productive
- Eight Uncommon Tips To Improve Your Writing
- Ten Helpful Tips To Improve Fire Drills
- Sorting Out Today’s Various Training Options
- Business Ethics and Corporate Scandals – Part 1
- Business Ethics and Corporate Scandals – Part 2
- 12 Tips for More Effective Emails
- Management Communication: Back to the Basics, Part One
- Management Communication: Back to the Basics, Part Two
- Management Communication: Back to the Basics, Part Three
- Asset Management
- Managing Hardware Inventories
- Introduction to Hardware Inventories
- Processes To Manage Hardware Inventories
- Use of a Hardware Inventory Database
- References
- Managing Software Inventories
- Business Continuity Management
- Ten Lessons Learned from Real-Life Disasters
- Ten Lessons Learned From Real-Life Disasters, Part 2
- Differences Between Disaster Recovery and Business Continuity , Part 1
- Differences Between Disaster Recovery and Business Continuity , Part 2
- 15 Common Terms and Definitions of Business Continuity
- The Federal Government’s Role in Disaster Recovery
- The 12 Common Mistakes That Cause BIAs To Fail—Part 1
- The 12 Common Mistakes That Cause BIAs To Fail—Part 2
- The 12 Common Mistakes That Cause BIAs To Fail—Part 3
- The 12 Common Mistakes That Cause BIAs To Fail—Part 4
- Conducting an Effective Table Top Exercise (TTE) — Part 1
- Conducting an Effective Table Top Exercise (TTE) — Part 2
- Conducting an Effective Table Top Exercise (TTE) — Part 3
- Conducting an Effective Table Top Exercise (TTE) — Part 4
- The 13 Cardinal Steps for Implementing a Business Continuity Program — Part One
- The 13 Cardinal Steps for Implementing a Business Continuity Program — Part Two
- The 13 Cardinal Steps for Implementing a Business Continuity Program — Part Three
- The 13 Cardinal Steps for Implementing a Business Continuity Program — Part Four
- The Information Technology Infrastructure Library (ITIL)
- The Origins of ITIL
- The Foundation of ITIL: Service Management
- Five Reasons for Revising ITIL
- The Relationship of Service Delivery and Service Support to All of ITIL
- Ten Common Myths About Implementing ITIL, Part One
- Ten Common Myths About Implementing ITIL, Part Two
- Characteristics of ITIL Version 3
- Ten Benefits of itSMF and its IIL Pocket Guide
- Translating the Goals of the ITIL Service Delivery Processes
- Translating the Goals of the ITIL Service Support Processes
- Elements of ITIL Least Understood, Part One: Service Delivery Processes
- Case Study: Recovery Reactions to a Renegade Rodent
- Elements of ITIL Least Understood, Part Two: Service Support
- Case Studies
- Case Study — Preparing for Hurricane Charley
- Case Study — The Linux Decision
- Case Study — Production Acceptance at an Aerospace Firm
- Case Study — Production Acceptance at a Defense Contractor
- Case Study — Evaluating Mainframe Processes
- Case Study — Evaluating Recovery Sites, Part One: Quantitative Comparisons/Natural Disasters
- Case Study — Evaluating Recovery Sites, Part Two: Quantitative Comparisons/Man-made Disasters
- Case Study — Evaluating Recovery Sites, Part Three: Qualitative Comparisons
- Case Study — Evaluating Recovery Sites, Part Four: Take-Aways
- Disaster Recovery Test Case Study Part One: Planning
- Disaster Recovery Test Case Study Part Two: Planning and Walk-Through
- Disaster Recovery Test Case Study Part Three: Execution
- Disaster Recovery Test Case Study Part Four: Follow-Up
- Assessing the Robustness of a Vendor’s Data Center, Part One: Qualitative Measures
- Assessing the Robustness of a Vendor’s Data Center, Part Two: Quantitative Measures
- Case Study: Lessons Learned from a World-Wide Disaster Recovery Exercise, Part One: What Did the Team Do Well
- (d) Case Study: Lessons Learned from a World-Wide Disaster Recovery Exercise, Part Two
This is the first of a three-part series on change management, one of the most critical processes within IT management. A recent survey of 240 senior IT directors at the May, 2004 IT Directors' Forum listed change management as the biggest challenge in IT this year. This section introduces the major aspects of this important infrastructure activity. I begin with the definition of change management and explain the subtle but significant difference between change control and change management. Next I summarize the 13 steps required to design and implement an effective change management process.
The first nine of these steps are preparatory to process design. I discuss each these steps in the remaining portion of this section. Part two will describe in detail step ten which comprises the actual design of a change management process. Part three will cover the remaining three steps of implementing and maintaining the process, along with a method to assess the change management environment of an IT infrastructure.
Definition of Change Management
Change managementa process to control and coordinate all changes to an IT production environment. Control involves requesting, prioritizing, and approving changes; coordination involves collaborating, scheduling, communicating, and implementing changes.
A change is defined as any modification that could impact the stability or responsiveness of an IT production environment. Some shops use the terms change management and change control synonymously, but there is an important distinction between the two expressions. Change management is the overall umbrella under which change control and change coordination reside. Unfortunately, to many people the term change control has a negative connotation that warrants some further discussion.
To many IT technicians, change control implies restricting, delaying, or preventing change. But to system, network, and database administrators, change is an essential part of their daily work. They view any impediments to change as something that will hinder them as they try to accomplish their everyday tasks. Their focus is on implementing a large number of widely varying changes as quickly and as simply as possible. Since many of these are routine, low-impact changes, technicians see rigid approval cycles as unnecessary, non-value-added steps.
This apparent dichotomy is a challenge to infrastructure managers initiating a formal change management process. They need the individuals who will be most impacted by the process and are the most suspect of it to buy into the process. This is why marketing a change management process properly by pointing out its benefits, and by gaining early buy-in by those most affected by it, is so important.
Steps To Implementing a Change Management Process
There are 13 steps required to implement an effective change management process; they are listed below in Figure 1. I discuss each step in some detail and augment where appropriate with examples and forms.
Identify executive sponsor.
Assign a process owner.
Select a cross-functional process design team.
Arrange for meetings of the cross-functional process design team.
Establish roles and responsibilities for members supporting the design team.
Identify the benefits of a change management process.
If change metrics exist, collect and analyze them; if not, set up a process to do so.
Identify and prioritize requirements
Develop definitions of key terms.
Design the initial change management process.
Develop policy statements.
Develop a charter for a change review board (CRB).
Use the CRB to continually refine and improve the change management process.
Figure 1 Steps Required to Develop a Change Management Process
Step 1: Identify an Executive Sponsor.
An effective change management process requires the support and compliance of every department in a company that could affect change to an IT production environment. This includes groups within the infrastructure such as technical services, database administration, network services, and computer operations; groups outside of the infrastructure such as the applications development departments; and even areas outside of IT such as facilities.
An executive sponsor must garner support from, and serve as a liaison to, other departments; assign a process owner; and provide guidance, direction, and resources to the process owner. In many instances, the executive sponsor is the manager of the infrastructure, but he or she could also be the manager of the department in which change management resides, or the manager of the process owner.
Step 2: Assign a Process Owner.
As I mentioned previously, one of the responsibilities of the executive sponsor is to assign a process owner. The ideal process owner will possess a variety of skills and attributes to accomplish a variety of tasks. These tasks include assembling and leading teams, facilitating brainstorming sessions, conducting change review meetings, analyzing and distributing process metrics, and maintaining documentation. High on the list of desirable attributes are the abilities to promote teamwork and cooperation and to effectively manage highly diverse groups.
Step 3: Select a Cross-Functional Process Design Team.
The success of a change management process is directly proportional to the degree of buy-in from the various groups that will be expected to comply with it. One of the best ways to ensure this buy-in is to assemble a process design team consisting of representatives from key functional areas. The process owner, with support from the executive sponsor, will select and lead this team. It will be responsible for completing several preparatory steps leading to the design of the initial change management process.
Step 4: Arrange for Meetings of the Cross-Functional Process Design Team.
This sounds routine but it actually is not. The diversity of a well-chosen team can cause scheduling conflicts, absentee members, or misrepresentation at times of critical decision making. It is best to have consensus from the entire team at the outset as to the time, place, duration, and frequency of meetings. The process owner can then make the necessary meeting arrangements to enact these agreements.
Step 5: Establish Roles and Responsibilities for Members of the Process Design Team.
Each individual having a key role in the support of the process design team should have clearly stated responsibilities. The process owner and the cross-functional design team should propose these roles and responsibilities and obtain concurrence from the individuals identified.
Step 6: Identify the Benefits of a Change Management Process.
One of the challenges for the process owner and the cross-functional team will be to market the use of a change management process. If an infrastructure is not used to this type of process, this will likely not be a trivial task. Identifying and promoting the practical benefits of this type of process can help greatly in fostering its support. Figure 2 lists some examples of common benefits of a change management process.
Step 7: If Change Metrics Exist, Collect and Analyze; If Not, Set Up a Process to Do So.
An initial collection of metrics about the types and frequencies of change activity can be helpful in developing process parameters such as priorities, approvals, and lead times. If the existing environment is not producing meaningful metrics, then process design team members should gather some initial set of metrics, even they must collect them manually.
Step 8: Identify and Prioritize Requirements.
One of the key preparatory tasks of the cross-functional design team is to identify and prioritize requirements of the change management process. Prioritizing is especially important because budget, time, or resource constraints may prevent all requirements from being met initially. The Strategic Management portion of this guide contains techniques for effectively brainstorming and prioritizing requirements. In Table 1
Visibility. The number and types of all changes logged will be reviewed at each week's CRB meeting for each department or major function. This shows the degree of change activity being performed in each unit.
Communication. The weekly CRB meeting is attended by representatives from each major area. Communication is effectively exchanged among board members about various aspects of key changes, including scheduling and impacts.
Analysis. Changes that are logged into the access database can be analyzed for trends, patterns, and relationships.
Productivity. Based on the analysis of logged changes, some productivity gains may be realized by identifying root causes of repeat changes and eliminating duplicate work. The reduction of database administration change is a good example of this.
Proactivity. Change analysis can lead to a more proactive approach toward change activity.
Stability. All of the above benefits can lead to an overall improvement in the stability of the production environment. Increased stability benefits customers and support staff alike.
Figure 2 Benefits of a Change Management Process
I present some examples of prioritized requirements from a composite of prior clients.
Step 9: Develop Definitions of Key Terms.
Change management involves several key terms that should be clearly defined by the design team at the beginning to avoid confusion and misunderstandings later on. Table 2 shows some common terms and definitions used by several clients. Planned and emergency changes are especially noteworthy.
This concludes the first of the three part series on change management. As mentioned previously, part two will continue with a detailed description of step ten which comprises the actual design of a change management process. Part three will cover the remaining three steps of implementing and maintaining the process, along with a method to assess the change management environment of an IT infrastructure.
References
ComputerWeekly.com, Change Management is Biggest Challenge This Year, June 22, 2004
John Jones, DeAnne Aguirre, Matthew Calderone, Resilience Report-Strategy+Business, Booz Allen Hamilton, February, 2004
Schiesser, Rich, IT Systems Management, Prentice Hall, 2002