Home > Blogs > VMware Operations Transformation Services > Tag Archives: john worthington

Tag Archives: john worthington

IT Transformation and Organizational Process Maturity

John WorthingtonBy John Worthington

Regardless of what process framework you use, and especially if you’ve done some ‘adaptation’ of processes, building process capability over the long haul goes hand-in-hand with building the organization’s process maturity.

Having thought about my comment, ‘so go ahead, adopt and adapt’, in one of my previous posts I thought further discussion might be in order.

Measuring Organizational Process Maturity

Based on the ISO standard[i], an organization’s process maturity is measured by establishing base and extended process sets at each stage of maturity. These base and extended process sets are tailored based on the domain and scope of the assessment and/or client-specific requirements.

For example, if a company decided that process A, B and C are critical to achieving organizational objectives they may determine that these represent the base process set. They could not achieve a process maturity of Level 1 (Basic) unless process A, B and C all met a Level 1 process maturity.

At Level 2, the organization may determine that there are additional processes that must be established. These would represent the ‘extended process set’ at a Level 2. To reach an organizational maturity of Level 2 (Managed), both the base and extended process sets would need to achieve Level 2 process maturity. Additional extended process sets might be added at higher levels of maturity as shown in the figure below.

Process Maturity

Process Capability versus Maturity

Capability

Process capability is focused on the ability of the process to achieve its desired outcomes based on business objectives. The process ‘base’ practices are directly related to the process objectives; which means the base practice attributes of a process are different for each process. So rating the degree to which each process expected outcome is met (or not) is a quick way to provide insight to its capability, which may (or may not) be adequate for a given organization’s business objectives. An example for Incident Management is given below. (Note: A formal process assessment will also review the process inputs/outputs, supporting people/technology and other evidence

Process Maturity

Process Capability Attribute  – Incident Management
(i.e., objectives/process desired outcomes)
Rating
An incident and service request management strategy is defined and implemented
Incidents are reported, prioritized, analyzed for business impact, classified, resolved and closed
Customers are kept informed of the status and progress of their incidents or service requests
Management of potential service level breaches are communicated to and agreed with the customer
Incidents which are not progressed according to agreed service levels are escalated by customers

If all the objectives of the process are either Largely or Fully achieved, the process will meet Level 1 (performed) requirements.

Maturity

Process maturity attributes apply to all processes, and are considered ‘generic’ attributes. These ratings are usually taken across a group of processes (such as the base and extended process set). Each level of process maturity builds on the next:

  • Level 1 – Performed (Process Performance)
  • Level 2 – Managed (Process Performance Management, Work Product management)
  • Level 3 – Established (Process Definition, Process Deployment)
  • Level 4 – Predictable (Process Measurement, Process Control)
  • Level 5 – Optimizing (Process Innovation, Process Optimization)

How mature are your processes?

Download this simple exercise using the ISO standard generic process attributes. Identify what you feel would be your ‘base process set’, and if you want a ‘extended process set’ as well. Then answer these questions for each process.

Organizational Process Maturity and ITaaS Transformation

Each organization has different starting points, different goals and objectives, and different levels of capability/maturity. So while we can effectively leverage our extensive experience with ITaaS transformations, each transformation path will be unique.

As processes are adapted along an ITaaS transformation path, changes in process boundaries, roles, controls and supporting technology can dilute organizational process maturity. This is another reason why ‘slow and steady’ may win the IT transformation race; frantic attempts to speed up the hill (again and again) increase the costs associated with the transformation effort an ultimately exhaust IT staff.

So go ahead, ‘adopt and adapt’, but be careful to maintain your hard-earned gains in organizational process maturity.

[i] ISO15504 – http://www.iso.org/iso/catalogue_detail.htm?csnumber=54175

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

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

Adopt Before You Adapt Your IT Processes

worthingtonp-cropBy 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:

  • Process AdoptionEnsure 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.

What Does It Mean for IT to Be Customer-Focused?

By John Worthington

worthingtonp-cropBy definition a service is a means of delivering outcomes that a customer wants to achieve, so it’s important not to forget where these outcomes originate in order for IT to be customer-focused.

Transforming IT from a technology-oriented to a services-oriented organization is at the heart of IT service management.  The “specialized organizational capabilities for delivering value to customers in the form of services” must be developed, refined, and continually improved with business outcomes in mind.

If IT is working well, with a true service orientation, your customer will see that:

  • IT actions align with the business, particularly in ways that help the business serve external business customers
  • IT costs are controlled and reduced wherever possible
  • Quality of end-to-end IT services is improved
  • IT agility in responding to business needs is improved
  • IT is focused on customer results
  • Prioritization of IT expenditures and actions is based on business priorities

For the IT organization, this service orientation starts with defining what constitutes a “service” in the context of the particular business and cataloging all the services available. Then the resulting service catalog, and the full service portfolio of which it is a part, become the means of ensuring that IT and the business are always completely in synch around IT services and their value.

What your customers want from IT
When I work with IT organizations that are building their initial catalog of services, I’m interested to see who views whom as the “customer.”  This is fundamental, however, since it is IT’s customer who defines value.

Frequently, service definition work is driven between particular IT groups, which can essentially put the entire effort within the boundaries of the IT organization, as illustrated in Figure 1.  This can result in an internally focused view of the customer/supplier relationship.  The focus is on supporting services, and parts of the IT organization itself end up being treated as “customers” of other parts of IT.

Figure 1 – Supporting Service Focus

Undoubtedly supporting services are important, since these are the building blocks that provide the capabilities that enable the customer-facing, outcome-oriented services.  But they are not what the business is ultimately concerned with.  Enumerating supporting services does not provide for the benefits the business expects – surely we don’t intend the service catalog to be limited to the IT organization!

Another approach I see my clients commonly take is to begin defining services that face the internal customers — the business — which establishes service catalog boundaries within the enterprise as illustrated in Figure 2.  Services are defined as what IT does for the business itself, without reference to the external customers of the business.

Figure 2 – Internal Customer Focus

This approach reflects a critical step in the evolution of an IT organization’s maturity as a service provider.  IT has begun to look at customer outcomes, with the customer being the business the IT organization serves.  I believe such an approach can lead to a more coordinated, collaborative way of working within IT; the various IT groups focus their attention on end-to-end service provisioning, not merely on their own IT silos.

So while initial service catalogs often start with the existing applications and infrastructure and package that for customers, a best practice approach that I recommend is to begin with the outcomes that customers desire and define services based on them as illustrated in Figure 3.

Figure 3 – External Customer Focus

The truth is, there will need to be multiple cycles of service definition and re-definition that need to continue indefinitely, since customers’ desired outcomes and perceptions are under constant change.

Defining services from the top down, starting with external services, is also a recommended approach. But this is easier said than done, since it quickly exposes a need to define both internal customer-facing services and supporting services.

Accelerating the journey to IT as a Service
This is the exciting part of being part of VMware. By establishing re-usable supporting IT services enabled by a software-defined data center and transformation road maps that make sure people and process changes are in place to realize the IT-as-a-service vision, I can help the IT organizations I work with to accelerate their ability to be truly customer-focused.


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