Tag: Responsibilities

Change Management Process Design – Part 1

This is the first post of a series where we do the tutorial and some deep-dive of an ITIL-based change management (CHM) process design. In the next few posts, we will go over some of the process design considerations such as the goal/purpose; the intended scope; roles and responsibilities; RFC categorization and prioritization; scheduling; integration; and metrics and measurements. Towards the end, we will examine how all these planning considerations come to together as we design the example process flow.

Goal and Purpose of Change Management

When designing an ITSM process such as change management, one of the most fundamental questions to ask is why your organization needs a formalized process. By ITIL’s definition, the intention behind the change management process is to control the lifecycle of all changes. By exercising proper control over the changes, we put ourselves in a better position to benefit from the changes and to minimize any potential disruptions to our IT environment. Do most organizations need a formalized change management process for their IT environments? I believe so because changes are a part of our complex IT and business environments. There are a number of reasons and objectives for an organization to implement a well-organized change management process. Some of those reasons include

Accommodate changes but not at the expense of system or application availability
Identify and categorize changes that may have different approval workflow or implementation lead time
Determine a better approach of assessing the levels of risk and the potential impact
Ensure that request for change (RFC) is properly evaluated for technical merit and balanced with the business needs

Depending on your organization’s intent or requirement, it is important to determine your objectives and fully answer the question of “why.” For many organizations, having a well-thought-out and documented change management process can help reduce the risks brought on by poorly planned changes. That, in turn, can go far in strengthening the IT organization’s ability to deliver timely and useful technology services that meet the needs of business.

Scope and Policy Implications

In defining your change management process, it will be useful to define a few scope or policy related items upfront. Some of my thoughts are:

To what organizational boundaries will the CHM process be applicable? Who should initiate, review, and/or authorize the CHM activities? Like implementing most ITSM processes, the benefits will be more far-reaching and visible when everyone is adopting the unified approach and vocabulary. Consider just how connected many business systems are these days in order to support the business processes or services, it will be important to understand and determine scope boundaries of the CHM process beforehand.
What activities constitute changes and will all changes receive the CHM treatment? Fundamentally, I believe all alterations to the enterprise-wide computing environment should be treated as changes, and those changes should be handled, in some fashion, by the CHM process. Depending on the technical nature and business implication of the change, some organizations may require different levels of review or scrutiny for different categories of change. To have an effective CHM process, all changes should be identified, addressed, and documented by the process in some ways.

Roles & Responsibilities

A change management process can involve a number of participants. Here are some typical roles to be factored into the design.

Requester: Who can initiate a RFC? How will the requester participate in the overall CHM process?
Change Management Process Owner: The process owner makes sure that the process is defined, documented, maintained, and communicated at all levels within the organization. The process owner is not necessarily the one doing the actual work, but the process ownership comes with the accountability of ensuring a certain level of quality for the process execution. The process owner also drives the continuous improvement activities for the CHM process.
Change Manager: The change manager is the main actor in the CHM process and has the most visible role within the CHM process. The change manager ensures all RFCs receive the proper handling and review by chairing the Change Advisory Board (CAB). As an outcome of the CAB meeting, the change manager publishes and communicates schedule of changes. The change manager is also responsible for reporting the metrics to the process owner for quality assurance and continual improvement purposes.
Change Implementer: The change implementer role is often played by the subject matter experts who perform the implementation work. After the change is executed, the change implementer also reports the outcome of change to the change manager for documentation and further actions.
Stakeholder: There could be several different types of stakeholders involved in CHM process. The stakeholders should be identified as members of the CAB or for RFC approval purposes. Ideally, the CHM process could use at least one executive-level stakeholder who can act in a governing or mediation capacity when conflicts arise.

We will discuss additional topics such as RFC categorization and prioritization; scheduling; integration; and metrics and measurements on the subsequent posts. Stay tuned, and I welcome your feedback.

Problem Management Process Design – Part 3

This post is the third and the final installment of the series for designing a problem management (PM) process for your organization. Previously we discussed the elements and considerations that should go into designing a problem management process. We elaborated those considerations further with a sample list of process requirements, a sample process flow, and a sample RCA form. We will assemble all the information together into one process design document that can be used to implement the process.

Problem Management Process Design Example

In addition to the process requirements and the process flow, I believe a process design document should call out the following information pertinent to the implementation of the process. For example…

The Policy section outlines what policy statements (IT or corporate) governs the process and what expectations the organization wants to set for the process.
The Scope section specifies which incidents or events will generate a problem record. Your organization may have a pre-defined set of criteria on how problems are triggered, and those criteria can go into this section. Some organizations may also choose to group a series of closely related incidents and trigger a problem record for those incidents.
The Roles and Responsibilities section outlines the roles that will be involved in the process and their corresponding activities and responsibilities.
The Artifacts and Communication section describes what documentation methods will be utilized by the PM process. It provides the procedural information necessary to carry out the PM process. The communication protocols section describes the recommended communication methods and their frequencies.
The SLA and Metrics section describes the metrics that will be used to measure the process performance. The tutorial document has outlined some examples. Develop and measure the metrics that you can capture reliably and that your organization also cares about.

To reiterate, the primary goal of the Problem Management process is to identify the problems in the IT environment, so we can eliminate them by performing root cause analysis on the problems. As a capable IT organization, we should be able to correctly diagnose the root causes of just about everything that goes wrong within our IT environment and to implement solutions so similar problems or incidents will not reoccur. With proper documentation, the Problem Management database is a great learning tool. Also, another benefit of having a well-run problem management process is having the ability to review organizational decisions made about addressing a particular problem. Known errors do not need to be purely technical. They could also be the documented decisions about how we plan to address certain problems. The root causes, solutions (proposed or implemented) and the workarounds documented as part of the Problem Management process will benefit the Incident Management process immensely when similar incidents surface due to the recurrence of a problem.

I hope the information presented so far has been helpful. Please feel free to suggest options or other approaches that have worked for your organization.

SACM and CMDB Tools – Some Planning Considerations – Part 2

In the previous post of the series, we discussed what initial considerations should be taken into account when deciding whether your organization needs a full CMDB solution. Let’s say you went through the analysis and decided that a more functional CMDB solution is needed. You need the solution to have a better ability to assess the impact of a change, incident or problem on a service because your current analysis capability is not meeting the business needs. What other considerations need to come into the planning of a CMDB solution? I would suggest the following…

Scope: What data need to be captured, stored, and processed? What processes and activities will make use of that information? At this point, you should have some pretty good ideas how to answer those two questions, at least with some degree of precision. If you need a better handle on managing the changes within the data center, what sort of hardware and configuration information will you need to capture from the servers and the networking gears in the data center? Do your needs for CMDB/asset management involve needing configuration information from the client devices? If so, how do you plan to reliably capture that very fluid information? What processes do you plan to target the CMDB information for in the near term, just change and incident or more? What services or processes will the CMDB enhance in the long run? I would recommend start with what you absolutely need right now to show improvements in service and gradually build it up over time.
Data Model: Talking about what data you need conceptually need is one consideration. Translating those concepts into actionable data model design is another. I am a believer that a CMDB is an information cornerstone to an organization’s IT service management activities. I often compare how an ITSM system relates to IT as how an ERP system relates to an organization. The CMDB is the foundational information store for that “ERP” system for IT. With that said, it pays to implement the data model well upfront because frequent structural changes to CMDB afterward will easily kill the productivity you gain from using CMDB.

There are some potential benefits and understanding that can be derived from the data model:

How all CIs within the scope of the process relate to IT services provided to the business
How various total cost of ownership components are related to an IT service
How individual availability or capacity figures can relate to groupings of CIs and overall availability or capacity targets
Which CIs facilitate or enable which IT services
Prioritization of CIs in relation to disaster recovery or continuity management

If your organization has one, now is the great time to get in touch with your Enterprise Architecture (EA) folks and work on the data model. They should be your organization’s information and data architecture expert, and designing (or assisting in design) an ERP data model for IT should be the very part of their charter. Design a data model with a long-term end in mind. Try to put into as much forethoughts into the design as possible. The data model should remain structurally stable for the most part, with an occasional addition or removal of fields or attributes. If you find yourself needing a brand new entity or object in the schema due to legitimate business needs, that is OK, too. In any case, my experience tells me data model design is something to be taken very serious of, because it frequently plays a big part in making or breaking a CMDB effort. Get some competent, professional help and start collaborating across the organization boundaries.

Roles and Responsibilities: Who is your configuration management process owner that has the overall accountability for governance matters with access to senior IT management team for escalating policy discussions, if necessary? A CMDB manager role should be named and responsible for managing the operational activities of the process and ensuring integration with the other service management processes. The process owner or its delegates need to work on developing the CMDB data model (with EA’s help), the core policies, maintenance processes and procedures, key performance indicators and producing ongoing management reports.

Also, another important topic to work out is the data ownership issue. Another word, who will own which portions of the data in CMDB? Naturally, I think it is most productive for the organization when the CMDB data repository structure is centralized. Does that also mean the CMDB care-taker team will also be able to own all data within CMDB? By owning I am referring to the acquisition, maintaining, validation, and reconciliation of the data. Will your CMDB team or the server admin folks manage the server device data in the CMDB by themselves, or will there be some kind of collaborative arrangement in place between the CMDB team and the server admins? How about the ownership for the networking device data in CMDB? How about the ownership for the application specific information in CMDB? The data modeling exercise may give us more insights into what data we need. I would strongly recommend the data ownership issue get thoroughly reviewed and agreed upon during the planning phase.

In the part 3 of the series, I will discuss more planning considerations such as Control and Verification, Key Performance Indicators, and Awareness Campaign, Communication & Training. Planning for a CMDB solution can be a complex but also a fun and educational exercise. You are doing the organization a great service by fulfilling its on-going need for great information and knowledge to carry out its mission. Do this value-add project well by planning ahead and think things through.

Links to other posts in the series