- 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
Change Management: Process Design
This is the second of a three part series on change management. Part one described the first nine steps of the 13 required for planning, designing, implementing and maintaining a robust change management process. This section discusses the tenth step which consists of the actual design of the process and includes the prioritization of changes, action matrices for approving and communication changes, and a sample change request form.
Designing the Initial Change Management Process
As mentioned in part one, there are 13 steps needed to implement an effective change management process. Figure 1 below lists these steps.
|
Figure 1. Steps Required to Develop a Change Management Process
This section will focus on step 10 which focuses on the design of the initial change management process. I use the term 'initial' because the process is very much a living entity that expands and alters its scope as infrastructure environments change. Several of my clients decided to pilot their new change management processes using just a small subset of their total IT department changes to get a feel for how the process is going to work. One financial company decided to only process infrastructure hardware changes at the outset. They soon realized that software changes also needed to be included to prevent undocumented and untested changes from jeopardizing system stability. Many companies elect to pilot infrastructure changes first and to add applications development changes later. In my experience I recommend starting slow and small but to include all departments on the design team who will eventually be participating in the final process.
Step 10: Design the Initial Change Management Process.
This is one of the key activities of the cross-functional team because this is where the team proposes and develops the initial draft of the change management process. The major deliverables produced in this step are a priority scheme, a change request form, a review methodology, and metrics.
The priority scheme should apply to both planned changes and emergency changes (these two categories should have been clearly defined in the previous section). A variety of criteria should be identified to distinguish different levels of planned changes. Typical criteria includes quantitative items such as the number of internal and external customers impacted, as well as the number of hours to implement and back out the change. The criteria could also include qualitative items such as the degree of complexity and the level of risk.
Some shops employ four different levels of planned changes to offer a broader variety of options. Many shops just starting out with formalized change management begin with a simpler scheme of only two levels. Table 1 lists some quantitative and qualitative criteria for four levels of planned changes, and Table 2 does the same for two levels.
Table 1. Criteria for Four Levels of Planned Changes
|
Criteria |
Priority Level |
|||
|
1 |
2 |
3 |
4 |
|
|
Narrative descriptors |
Very High Substantial Significant Substantial "A" |
High Major Important Principal "B" |
Medium Moderate Standard Nominal "C" |
Low Minor Optional Time-Permitting "D" |
|
Percent of total external customers impacted |
> 90 % |
50–90 % |
10–49 % |
< 10 % |
|
Type of total external customers impacted |
Customers of critical apps |
Customers of high-prty apps |
Customers of med-prty apps |
Customers of low-prty appls |
|
Percent of internal users impacted |
> 90 % |
50–90 % |
10–49 % |
< 10 % |
|
Type of internal users impacted |
Customers of critical apps |
Customers of high-prty apps |
Customers of med-prty apps |
Customers of low-prty apps |
|
Critical applications impacted |
Yes |
No |
No |
No |
|
Noncritical application downtime required |
Yes |
Yes |
No |
No |
|
Amount of additional budget required |
> $10,000 |
< $10,000 |
0 |
0 |
|
9. Hours to implement |
> 8 |
5–8 |
1–4 |
< 1 |
|
Backout plan required |
Yes |
Yes |
No |
No |
|
Hours to back out |
> 4 |
< 4 |
n/a |
n/a |
|
Broadness of scope |
Very high |
High |
Medium |
Low |
|
Extent of impact |
Very high |
High |
Medium |
Low |
|
Degree of complexity |
Very high |
High |
Medium |
Low |
|
Level of risk |
Very high |
High |
Medium |
Low |
|
Strategic value |
Very high |
High |
Medium |
Low |
|
|
|
|
|
|
Table 2. Criteria for Two Levels of Planned Changes
|
Criteria |
Impact Level of Planned Changes |
|
|
High |
Low |
|
|
Any impact to subscribers |
Yes |
No |
|
Percent of total external customers impacted |
> 25 % |
< 25 % |
|
Type of total external customers impacted |
Customers of critical apps, and high- & med-prty apps |
Customers of low-prty apps |
|
Percent of internal users impacted |
> 50 % |
< 50 % |
|
Type of internal users impacted |
Customers of critical apps, and high- & med-prty apps |
Customers of low-prty apps |
|
Critical applications impacted |
Yes |
No |
|
Noncritical application downtime required |
Yes |
No |
|
Amount of additional budget required |
> $1,000 |
< $1,000 |
|
Hours to implement |
> 4 |
< 4 |
|
Backout plan required |
Yes |
No |
|
Broadness of scope |
High |
Low |
|
Extent of impact |
High |
Low |
|
Degree of complexity |
High |
Low |
|
Level of risk |
High |
Low |
|
Strategic value |
High |
Low |
I have worked with some clients who prefer only the two-level priority scheme, other who prefer only the four-level scheme, and still others who start out with a two-level scheme and then revise it over time to three or four levels. The type of priority scheme an organization uses depends on factors such as how experienced they are with infrastructure processes, the number of changes executed each week, the number and variety of customers, the number and variety of applications, and the ratio of emergency to planned changes. Smaller, less diverse shops usually start with a lower level of priority scheme than larger, more complex shops that use higher level priority schemes.
After the team determines priority levels, it will need to develop lists of actions to be taken depending on the level of planned or emergency change. These actions include such items as who will approve changes, when the approvals will be made and who will be notified about the change. Table 3 shows some sample actions for planned changes by impact level and time frame. An IT department will customize these actions to suit its individual needs. Similarly, Figure 2 describes sample actions for emergency changes.
Table 3. Action Matrix for Planned Changes
|
Actions |
Impact Level/Time Frame |
||
|
Low/Anytime |
High/Prior to Review Meeting |
High/After Review Meeting |
|
|
Types of approvals required |
Supervisor of implementer |
Supervisor plus 2 board members or reps, preferably 1 familiar with change and 1 familiar with impact |
Change Review Board |
|
Advance approval time |
1 hour |
1 day |
At CRB meeting |
|
Advance notification time |
n/a |
1 day |
1 day |
|
Groups to be notified |
n/a |
Customers impacted |
Customers impacted |
|
Preferred time of change |
Anytime |
Not prime shift |
Not prime shift |
|
Backout plan required |
No |
Yes |
Yes |
|
Figure 2. Action Procedure for Emergency Changes
The team next develops a change request form. Two characteristics are always present in such a form: simplicity and accessibility. The form needs to be simple enough to use that minimum explanation is required, yet thorough enough that all pertinent information is provided. The form also needs to be easily accessible to users, preferably through a company's intranet or in a public email folder on a shared drive. Change requests should be stored in a database, preferably a relational database, for subsequent tracking and analysis. Figure 3 shows a sample change request form.
|
Information Technology Change Request Form
Requester_______________________ Request Date_________Priority_______ Summary Description of Change ______________________________________
__________________________________________________________________ Customers Impacted ________________________________________________ Systems Impacted __________________________________________________ Expected Start Date/Time of Change ___________ Estimated Duration______ Actual Date/Time of Change ___________ Actual Duration ________ Detailed Description of Change_______________________________________ __________________________________________________________________ __________________________________________________________________ __________________________________________________________________ __________________________________________________________________ ===============================================================
For Low-Priority Changes, Requester's Manager's Approval_______________ Disposition of Change ________________________________________________ ===============================================================
For High-Priority Changes, CRB Approval _______________ Backout Plan in Place?_________ Downtime Required?________ Estimated Time to Back Out?________ Downtime Notices Sent Out?________ Final Disposition of Change___________________________________________ |
Figure 3. Sample Change Management Request Form
A recent client of mine involved in law enforcement developed an in-house electronic form for change management that is now widely used in his organization on their Intranet. The client has enhanced the form, called eChange, to include electronic signatures, automatic distribution, and provisions for feedback and help commands. If you are interested in more information on this home-grown enhancement, please contact me and I will put you in touch with him.
The next part of this step involves the establishment of metrics for tracking, analyzing, and trending the number and types of planned and emergency changes occurring every week. Shops with robust change management processes place special emphasis on the analysis of these metrics, particularly the ratio of emergency to planned changes.
The final task for the cross-functional team is to devise a methodology for reviewing all changes. Most shops constitute a Change Review Board (CRB) that meets weekly to review the prior week's changes and to discuss upcoming changes. Steps 11 and 12 of this process discuss policy statements and the charter of the CRB, respectively. Part three of this series covers both of these steps in more detail, along with step 13 on how to use the CRB to continually improve the change management process.
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