Tag: scope

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.

ITSM Tools Operation Continuity Plan – Part One

If your IT organization is like most others, you rely heavily on your IT service management (ITSM) tools for delivering IT services to your business customers or constituents. Many IT shops also have a comprehensive suite of ITSM tools they use as part of the various aspects of their operation. It is my personal belief that the ITSM tools operate like the ERP systems for many businesses – the ITSM tools are providing a critical service to the IT organizations.

While many ITSM products on the market today are well made and come with industrial strength resiliency, technology failures or other disasters can still cause the tools to become unavailable for use. When the tools unavailability or outage stretches out from merely minutes into hours or days, you need to have a continuity plan to get the tool services restored so your IT organization’s operations can continue normally without further hindrances. The ITSM tools operation continuity plan needs not to be fancy or sophisticated, but it does need to be well thought-out with as many details called out beforehand as possible. This is the part one of a two-part post where we will go over what components should go into such plan.

Introduction
This section provides an overview of the plan. Why the plan exists? Who is the owner accountable for drafting and/or executing plan? How will the plan be maintained and tested for validity or accuracy? Any other high-level, overview information about the plan will be helpful to include in this section.

Invocation
This section includes the comments on what conditions will trigger the actions to invoke this plan. It is important to point out who will be authorized to invoke and to implement this plan. It is also important to outline the availability requirements and targets once the plan is invoked.

Scope
This section describes the ITSM modules, systems, infrastructure, services and facilities that will be part of this plan. A number of ITSM systems do not operate in isolation these days, so identifying all components required for a functional ITSM system could be daunting. That is OK. Just have a boundary in mind and do your best. If possible, include and provide as much information on the infrastructure that hosts the ITSM products as feasible. This could include the actual server names, databases, and other components deemed essential and critical for the operations of the ITSM tools. If you have a CMDB with the relationships documented, those relationships between the system components and your plan should be consistent with each other.

Depending on your operation, not all ITSM modules need to be part of this continuity plan. For example, I surmise tool modules or services such as Incident Management, Change Management, or anything the Service Desk uses could be high on the priority list to get restored ASAP. Problem Management module probably can wait and get restored as part of the normal system recovery cycle.

Data Dependencies and Considerations
This section includes comments about the data requirements that need to be met before the recovery plan can be implemented. What data is needed for the recovery and what preparation activities are required to get the data in place? This is more than just calling out what database servers are needed for recovery, which should have been discussed in the Scope section. I am talking about things such as how current the data need to be before the recovery procedures can be executed. Another consideration is how the data that was captured during the recovery phase will be incorporated back into the main database once the original systems come back online. The key objective here is not to lose data, during recovery and post recovery.

Security and Access Considerations
This section includes the important details about the security and access related matters. For example, what access rights will your systems and personnel require in order to fully execute the plan? Often we have the security and access considerations on the back burners and forget about them. During the recovery phase, things are not working as expected and, after many rounds of discussions and trouble-shooting exercises, we realize the security access might be preventing things from working. Don’t put yourself in the position of being unprepared and wasting time. Figure out those security and access details beforehand and document them in the plan.

External Dependencies and Considerations
This section calls out the systems, infrastructure, service, facility or interfaces that are external to the ITSM system but have inter-system dependencies that should be documented. Essentially, anything that has not been identified in the Scope section but still required for recovery should be mentioned here. That way, all dependent systems and the nature of dependency can be identified and taken into account during the plan execution. For example, we might want to include information about the email system and its key interface points because most ITSM systems have a reliance on the email systems for communication.

That is all for now. On the next post, we will conclude the discussion of the plan and cover the remaining topics:

Recovery Team and Communication
Recovery Procedure and Configuration Details
A Checklist of Key Actions or Milestones
Testing and Validation
Return-To-Normal-Operation Procedure

DIY Process Assessment Planning – Problem Definition, Scope, and Stakeholder Analysis

In the previous post, we talked about some potential information resources you can use to set up an internal ITSM process assessment effort. In this post, we will discuss some of the planning considerations that should be taken into account.

Problem Definition (Purpose and Opportunity)

It is always important to answer the question of “Why Bother?” In order for an assessment to produce meaningful results, it needs to address one or more business problems at hand. Document what are the drivers for conducting the assessment. Document why it is important to address the drivers now. Clearly identify what the organization or the sponsor intends to do with the assessment results. Once the purposes have been articulated with the agreement and support from the sponsor, the assessment team can use them as part of future communications to the stakeholders and participants.

Scope (Process and Organization)

The scope usually comes in two aspects, process scope and organization scope. An assessment can cover one or more ITSM processes, and the assessment purposes defined in the previous section should help to guide the scope definition.

The organization scope also needs to be defined for the assessment. Ideally an ITSM assessment should cover the entire IT organization but that may or may not be needed depending on the business problem you are trying to solve. Defining the organization boundary for the assessment can also be tricky partly because people and political considerations inevitably get involved. It is possible that the assessment will cover only a portion of the organization where the sponsor has more control over, infrastructure operations vs. application development as an example. When that happens, it is important to define clearly just how applicable the assessment’s scope is organizationally. That way, the assessment results will not be misinterpreted, and the follow-up action plans can be appropriately planned and executed.

For the process scope, the assessment should focus on assessing a process’ end-to-end effectiveness, or customer experience from the business perspective. It is quite possible that an overall assessment for a particular process will yield a score that may be different than what an individual team or organization expects. When that happens, it is important that the assessment can provide data to back up its finding or to explain the difference in expectation.

Also, don’t lose sight of the following. One reason to conduct assessment is to baseline what your organization is currently doing. Take advantage of the assessment opportunity to document the baseline performance of your processes, even for those which have had very little formal implementation or performance record.

Analysis of Stakeholders and Participants

Identifying and understanding the interactions stakeholders may have with the assessment is a critical aspect of the assessment planning. The stakeholders or participants of the assessment project can include a number of individuals such as the process owners, the IT staff, senior IT management team, key suppliers, and business customers. There are a number ways of mapping and understanding the stakeholders’ impact to the project. For most assessment projects, I would suggest thinking about the following factors. Customize the list further if your organization requires it.

The stakeholder’s view of the assessment effort: Some participants feel strongly about the assessment for whatever reasons, and some feel less so. Try to gain a better understanding of the participants’ views towards the assessment.
The stakeholder’s power to influence the assessment: Understand what role a participant will play in the assessment and how much influence they may have over the direction and execution of the project.
The stakeholder’s work or responsibility impacted by the assessment: The assessment will have variable degree of impact to the participants’ work or functional areas. Take this factor, along with the view and influence considerations, you can gauge what impact a stakeholder may have on your project more effectively.
The stakeholder’s need for communication or training: Understand and map out the communication strategy based on the information or reporting needs of the stakeholders. Some stakeholders will require periodic updates (say weekly) from the assessment team. Some participants may require more frequent or less frequent communication. Also understand whether the participants will require some form of awareness training or education prior to the actual start of the assessment activities.

At the next post, we will discuss the additional planning factors such as the assessment model, the schedule and deliverables, as well as the risks and constraints.