By John Worthington

Many people familiar with ITSM have heard the expression ‘adopt & adapt’ as a good practice, but it’s worth noting the order in which these words are placed. You must adopt before you can adapt. This leads to the question, when has a process been ‘adopted’?

Incomplete Process [i]

If a process doesn’t have a purpose, or if the process purpose is not understood by the organization, it is hard to consider it implemented. If a process is performed so inconsistently or irregularly over time or in different business units, that it does not systematically achieve its purpose, it has not been adopted.

At this level, more efforts are needed to adopt the process. This may require transitional change efforts that may include strategy, structures, and/or systems.

Performed Process

If the process achieves its purpose it’s normally considered ‘adopted’, even if the relative maturity is low. The organization understands the purpose of the process and there is evidence that the outcomes of the process are achieved, such as the production of a document, change of state or meeting a goal.

Reviewing the base practices associated with the process can help determine whether all the desired outcomes of the process are achieved, even if some specific outputs (i.e., work products) are not in evidence.

At this level of maturity, the process can be adapted and improved. This requires developmental change efforts; project plans that should communicate the changes and provide knowledge transfer to key stakeholders.

Why is this important?

When we are adapting multiple processes as part of an ITaaS or SDDC transformation, even a single incomplete process can significantly increase the scope of the effort. You cannot adapt what has not been adopted!

ITaaS Transformation and Established Processes

Incident Management is typically a process that has been adopted. For example, all these objectives[ii] may be met:

• Ensure that standardized methods and procedures are used for efficient and prompt response, analysis, documentation, ongoing management and reporting of incidents
• Increase visibility and communication of incidents to business and IT support staff
• Enhance business perception of IT through use of a professional approach in quickly resolving and communicating incidents when they occur
• Align incident management activities and priorities with those of the business
• Maintain user satisfaction with the quality of IT services

Even if the process documentation is not elaborate the process may be achieving its purpose and providing its expected outcomes. It’s not uncommon for organizations to have this process formally described, have trained practitioners, be well supported by tools and standardized across the organization. These would characterize this as Level 3 (Established) maturity.

In this case, vRealize Operations can integrate easily with the process (i.e., by automatically creating Incident records in the tool) as appropriate.

ITaaS Transformation and Incomplete Processes

In an ITaaS transformation, capacity management can be an example of an incomplete process. For example, the following objectives[iii] of capacity management may be difficult to achieve:

• Produce and maintain an appropriate and up-to-date capacity plan, which reflects the current and future needs of the business
• Ensure that service performance achievements meet all of their agreed targets by managing the performance and capacity of both services and resources
• Assist with the diagnosis and resolution of performance and capacity related incidents and problems

If IT services are not well defined, if the problem management process is not established, or if the capacity management process is not well supported (by people and technology) then it is common that it would not meet Level 1 (Performed) requirements.

The use of vRealize Operations can address the technology process support requirements, but you will still need to define services to manage service performance and you will still need to establish problem management as a process in order to assist with capacity related problems. You may also need to establish roles associated with capacity and performance management that are not currently well defined in the organization.

[Note: it is not required that an ITIL-based process be in existence, but the process will still need to be considered performed (adopted) in order to adapt.]

Adopt or Adapt is not a matter of choice

You do not choose developmental, transitional or transformational change; you discover what change is required based on organizational demands[iv]. This is why assessment and discovery activities are so important. These activities make sure your implementation plans have the inputs needed to ensure a complete plan, and the appropriate developmental, transitional and/or transformational strategies.

In the examples provided, we can easily adapt the existing incident management process to ITaaS. However, there may be more work needed to establish capacity management and related processes. The level of effort needed to achieve this can vary significantly based on organizational requirements, objectives and your starting point.

Understanding this is key to establishing a transformation path that minimizes effort and maximizes the value out of the people, processes and technology — in other words, developing ITaaS organizational capabilities.

[i] Process Assessment and ISO/IEC 15504, Van Loon
[ii] ITIL^© Incident Management
[iii] ITIL^© Capacity Management
[iv] Beyond Change Management: How to Achieve Breakthrough Results Through Conscious Change Leadership, by Dean Anderson and Linda Ackerman Anderson

=====================

John Worthington is a VMware transformation consultant and is based in New Jersey. Follow @jMarcusWorthy and@VMwareCloudOps on Twitter.