Tag: policy

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.

Problem Management Process Design – Part 1

This is the first post of a series where we do the tutorial and some deep-dive of problem management (PM) process design. In this post, we will go over some of the process design considerations, such as the goals/purposes, the intended scope, problem prioritization, and roles and responsibilities. In the subsequent posts, we will go into more of the execution topics such as data capturing, process flows, as well as metrics and measurements.

Goal and Purpose of Problem Management

When designing an ITSM process, one of the most fundamental questions to ask is whether you need a particular process for your organization. By ITIL’s definition, a ‘problem’ is a cause of one more incidents. By managing problems, we are attempting to manage how we document, diagnose, and learn from the root causes after handling the incidents. Do most organizations need a problem management process of their own? I believe so. Even though most organizations may not have a formal problem management process defined, the act of diagnosing and finding root causes is practiced universally. Having a well-thought-out and documented process for root cause analysis can only help to strengthen the organization’s learning and knowledge management effort.

Scope and Policy Implication

In defining your problem management process, it will be useful to define a few scope or policy related items upfront. For example:

What organizational boundaries will the PM process be applicable to? Who can initiate, undertake, and/or authorize the PM activities? Like implementing most ITSM processes, the benefits will compound when everyone is adopting the unified approach and vocabulary. If you need to share the root cause data between organizations, it will be important to define the process scope beforehand.
Will all incidents receive the PM treatment? If you don’t plan to run all incidents through the PM process, what criteria will you use to decide which incidents to focus the PM effort on? Depending on the number of incidents you receive, practicing PM on every single incident may not be feasible, so you may need to be selective. Some organizations will initiate the PM process for incidents that meet certain criteria based on the incident priority (impact vs. urgency), the nature or category of the incident, the business segment affected, or some other factors.
It will also be useful to define what are some of the connecting processes to PM. Incidents, problem, and changes are typically closely tied to one another. What processes will trigger the PM process from upstream or receive the PM output downstream? Will your organization perform PM without having an incident? It is possible if you practice some type of proactive PM. Will all changes related to a problem be required to go through the change management process? Will the incident tickets, problem records, known errors, and requests for change be linked in some fashion? These are some governance related questions that will affect how you design the PM process.

Problem Categorization and Prioritization

When designing a categorization scheme for problems, I recommend using the same categorization for PM and for Incident Management. Having a consistent categorization for both problems and incidents will make designing, generating, and analyzing reports much easier. Some organizations use two separate categorization schemes for incidents and problems – a decision sometimes influenced by the tools. I personally think that is making things more difficult than it needs to be.

Prioritizing problems can help you focus your RCA efforts on problems that need the most attention. When prioritizing incidents, many organizations take the impact to the business community and urgency into consideration. For problems, I believe those two considerations are essential, and I would suggest adding two additional considerations into your problem prioritization matrix. The first one is the frequency of the incident. I think the higher frequency of the incidents; the higher priority should be assigned to problem. Also, the potential risk of not addressing the problems should also be taken into account.

Roles & Responsibilities

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

Requester: Who can initiate a PM exercise? How will the requester participate in the overall PM process
Problem Management Process Owner: The process owner ensures 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.
Problem Manager: The problem manager is the main actor in the PM process and has the overall responsibility of implementing the PM process end to end, according to the process laid out by the process owner. The problem manager is also responsible for meeting the service level targets and reporting the metrics to the process owner for quality assurance purposes.
Problem Assignee: The problem assignee role is often played by the subject matter experts who does the actual RCA work and determine what the final root cause is. The problem assignee can also be assigned to ensure all changes get properly executed through the Change Management process.
Stakeholder: There could be several different types of stakeholders involved in PM exercise. At a minimum, the PM process needs at least one key stakeholder who can approve the handling of the problem records and the closure of the problems. The stakeholder could also act in a governing or mediation capacity when conflicts arise.

In summary, we just went over some of the planning elements for the PM process. We talked about why we want to PM in the first place, the scope of the process, how we categorize and prioritize problems, and the essential roles for executing the process. On the next post, we will go over the process flow and spell out more details for the PM activities.