Fresh Links Sundae – January 27, 2013 Edition

http://www.dreamstime.com/-image28379626Fresh Links Sundae encapsulates information I have come across during the past week. They maybe ITSM related or not entirely. Often they are from the people whose work resonates with me, and I hope you will find them at least thought-provoking or something of value.

Big data was a hot technology topic in 2012. Bob Lewis discusses the trend and its suitability to organization in terms of the organizational players involved, the degree of affordability, and the disruption to the enterprise. Don’t expect big-time results from big data (InfoWorld)

Although IT Asset Management can be an under-appreciated function with many organizations, Jon Hall suggests four tactics that IT Asset Manager can use to make their value to the organization more visible and impactful. ITAM 2015: The evolving role of the IT Asset Manager (Evolving ITSM)

In a two-part post, Andrew Horne looks at seven common pitfalls that cause scorecards to fail and outlines some metrics currently used by the most progressive organizations. The Seven Pitfalls of IT Scorecards and Five Metrics for Your 2013 IT Scorecard (CEB IT Blog)

A popular ITSM metric is the measurement of incidents and how quickly we were able to help our customers recover from them. Dan Kane advocates that simply measuring incident resolution rate is not sufficient – focusing on the overall customer experience is. Rethinking the Role of Incidents in Service Management (Hazy ITSM)

With the general technology competency level rising amongst the end users, the notion of self-supported user population may result in the eventual phasing-out of the service desk. Patrick Gray explains why general users’ familiarity with technology doesn’t necessarily translate into troubleshooting capability. Don’t be premature in closing your help desk (TechRepublic)

In an era where companies accumulate a great deal of information about us, Anna Farmery talks about big data as a business opportunity for companies that embrace the concept of trust, transparency, and responsibility. Big Data – Being Open Can Bring Success (The Engaging Brand)

An effective speaker is often an audience-centric speaker. In a three-part post, Andrew Dlugan describes what audience analysis is and the types of questions a speaker should be asking about his audience. Part 1: How to Conduct Audience Analysis Part 2: Audience Analysis: A Guide for Speakers Part 3: How to Improve Your Speeches Through Audience Analysis Part 4: Worksheet Download (Six Minutes)

In comparing “I don’t” vs. “I can’t,” Heidi Halvorson talks about why one mindset is much more empowering than the other. The Amazing Power of I Don’t (rather than I Can’t) (Dr. Heidi Grant Halvorson)

In every discipline, there are stars recognized for their extraordinary results or contribution. Adriana Beal discusses three traits that star business analysts have in common. 3 Characteristics of Star BAs (Bridging the Gap)

Although the terms “purpose” and “goal” may appear to be similar in definition, Marshall Goldsmith explains what makes those two terms different. Mission Control: Putting Our Purpose Above Our Goals (Marshall Goldsmith Personal Blog)

Change Management Process Design – Part 2

http://www.dreamstime.com/-image25302740

This post is part two of a series where we discuss the ITIL-based Change Management process and how to put one together. In the previous post, I presented some design considerations such as goal/purpose; the intended scope; and roles and responsibilities. In this follow-up post, I will discuss additional process governance and planning elements.

Categorization and Prioritization

Why do we categorize? Proper categorization can facilitate or drive certain governance decisions. Categorization can drive the lead time required for review and approval. Categorization can also determine what process workflow or approval authorities may be required to facilitate the change. ITIL recommends three types of change request: Standard, Emergency, and Normal. If ITIL’s definitions work for your organization, go ahead and adopt them. However, that categorization alone is probably not sufficient to describe the changes and how they affect the business operation. Finding a way to describe the risk and impact associated with a change is also important. Risk can be used to measure the level of the potential disruption of business operation associated with a change request. Impact can be used to measure how far-reaching a change can be. The key idea here is to find a way of properly assessing changes and managing risks.

When designing a categorization scheme for changes, I recommend examining your existing incident and problem categorization scheme and make an attempt to have a consistent categorization across the ITSM processes. I believe that a uniform categorization will make risk assessment more reliable than not having it. A consistent categorization could also make the design and analysis of the reports more meaningful. Some organizations choose to use separate categorization schemes for incidents, problems, and changes – a decision sometimes influenced by the organizational boundaries or the tools on-hand. Just keep in mind that a change management exercise is also a very much a risk management exercise.

Workflow and Documentation

Once you have the change requests categorized, you will need a workflow to process the change requests for review and approval with a well-defined lead time. These lead-times are necessary to provide the adequate time required to review and to approve the change request by the change manager and the stakeholders. Many organizations I was with have had either weekly or semi-weekly CAB review cycles. That means the approval and scheduling timing need to be well defined so CAB and change manager can review, discuss, approve, or even escalate the change with sufficient time. Also, different types of change or change risks/impacts will likely require different lead-times or maybe different work-flows to process them. Some organizations may be required to impose change freeze windows in order to support critical business systems or processes.

Just like other ITSM artifacts, change requests should be documented and, ideally, captured in a tool. The levels of detail needed to be capture will vary from one organization to another, but most organizations should capture the baseline of required data such as:

  • Change requester, owner, and implementer
  • Type, category, risk, impact, priority as defined in the process document
  • Configuration items (systems, applications, devices, etc.) affected by the change
  • Summarized and detailed description of the change
  • Business justification
  • Proposed schedule or implementation timing
  • Dependencies and required resources identified
  • Key approvers needed
  • Final report on the closure of the change

Once the changes are captured and processed, the process guide also needs to define the necessary communication and coordination mechanisms to support the change management activities.

Metrics and Measurements

Tracking and measurement are the key elements to the continual process improvement. Depending on the goal and purpose defined for the change management process, we can further define the critical success factors and the key performance indicators we will need to track in order to measure the effectiveness, efficiency, and the quality of the process. The process design should spell out the metrics requirements and make sure the tools can support the required metrics.

Process Integration

It will also be useful to define some potential connecting ITSM processes to CHM. Incidents, problem, change, configuration, and release management process all have activities that are closely tied to one another. Which processes will trigger the CHM process from an upstream workflow or will receive the CHM output downstream? If you have an incident identified and it requires changes implemented to restore the service, how will those changes be handled? If you practice problem management in your environment, how will CHM process be injected into the root-cause remediation or deficiency remediation activities? Will the incident tickets, problem records, configuration items, and requests for change be linked in some fashion? These are just some governance related questions that should be considered upfront as they will affect how you plan and design the CHM process.

In the last two posts, we just went over a number of governance and planning elements for the change management process. We talked about the scope and purpose of the process, how we categorize and prioritize changes, the essential roles for executing the process, the necessary categorization, workflow, metrics, and integration with other ITSM processes. On the next post, we will go over and example process flow and spell out more details for the change management activities.

Fresh Links Sundae – January 20, 2013 Edition

http://www.dreamstime.com/-image28379626Fresh Links Sundae encapsulates information I have come across during the past week. They maybe ITSM related or not entirely. Often they are from the people whose work resonates with me, and I hope you will find them at least thought-provoking or something of value.

While some may hold the belief that DevOps and ITIL are in conflict with each other, Robert Stroud explains why that is not the case and why proper application of the DevOps concept can further strengthen an organization’s IT capability. Does the emergence of DevOps mean the end of ITIL? (CA Technologies)

The Bring Your Own Device (BYOD) trend was a hot technology topic in 2012. Bob Lewis discusses the trend and its suitability to organization in terms of the organizational players involved, the degree of affordability, and the disruption to the enterprise. The realist’s guide to BYOD and why it’s a long-term trend (InfoWorld)

By leveraging four key consideration elements, Roman Jouravlev suggests a model that can make an IT initiative clearer and easier to assess. ITSM ORBIT or How to help a tail to wag the dog (ITSM Portal)

With a two-part series, Matthew Selheimer describes a four-level model of social IT maturity and discusses how to avoid the most common pitfalls. The part-two of the post is available here. Getting Started with Social IT (The ITSM Review)

Although the concept of the ITIL problem management may be straight forward, few people fully understand it or appreciate its importance. Ian Aitchison defines what Problem Management process is, describes its value, and gives pointers on how to get started. Problem Management: The Teenager of the ITSM Household (LANDesk Blog)

Questioning some of the recent criticism on consultants and their contribution to the ITSM community, James Finister discusses the operating parameters consultants must work with and how the parameters differ from those of ITSM practitioners. Them and us – again (Core ITSM)

Building on the premise that people who have positive influence on us is that they also have real presence when they communicate. Mark Goulston examines the three essential elements that make up the presence. Real Presence, the Foreplay to Real Influence (Usable Insight)

By using a drinking water example, Anna Farmery talks about why brands should focus their effort on filtering and distributing the ocean of data to their intended audience. How to Quench the Thirst of Your Customer (The Engaging Brand)

After observing a magician performing his card tricks on a train, Adrian Reed draws a parallel with his BA work and explains the lesson he took away. Avoiding Elitism in Your Business Analysis Templates and Techniques (Bridging the Gap)

Peter Drucker was once quoted to have said, “Half the leaders I have met don’t need to learn what to do. They need to learn what to stop.” Marshall Goldsmith outlines 20 interpersonal behavior challenges that leaders can work on to correct. Bad Behavior (Marshall Goldsmith Personal Blog)

Change Management Process Design – Part 1

http://www.dreamstime.com/-image25302740This 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.

Fresh Links Sundae – January 13, 2013 Edition

http://www.dreamstime.com/-image24270014Fresh Links Sundae encapsulates information I have come across during the past week. They maybe ITSM related or not entirely. Often they are from the people whose work resonates with me, and I hope you will find something of value.

Referring to a recent LinkedIn discussion on the Change and Release Management processes, Jan van Bon discusses how the two processes relate to each other and offers suggestions on how to best leverage both processes in an organization. The one-and-only Change Management process (ITSM Portal)

Cloud computing was a hot technology topic in 2012. Bob Lewis compares three types of cloud services and discusses their suitability to organization in terms of the organizational players involved, the degree of affordability, and the disruption to the enterprise. The realist’s guide to cloud services and what they’re good for (InfoWorld)

With cloud computing transforming how businesses consume technology services, Robert Stroud lists some guidelines that can help effectively implement services in a hybrid cloud-computing environment with effective service operations. Hybrid Service Delivery Guidance for the New Year (CA Technologies)

Change and configuration management practices have always been an important part of IT operations, but implementing the practices well can also take a significant effort and may not appear to add much value to the business operations. Sasha Gilenson suggests that IT Operations Analytics maybe a way for organizations to handle this important area and make it worth-a-while. Change and Configuration Management Is Sexy Again! (Evolven Blog)

Drawing similarities between cloud offerings and the K-cup concept, Patrick Gray explains how the popular per-cup pricing model can also be leveraged by IT in providing similar value proposition to organizations. K-cup coffee and a lesson for IT (TechRepublic)

Inspired by the ShamWow commercial, Aprill Allen describes seven goods self-service forum can bring to an organization. 7 Ways Self-service is like a ShamWow (Knowledge Bird)

Observing from the IT Risk/Reward Barometer survey and the technology trends, Brian Barnier believes there is a serious disconnect between IT and business and how we can make a difference. IT risk leaders: Does 2013 pose triple threats or triple treats? (ISACA Now)

With his usual skeptical humor and insights, Rob England outlines some of the IT and general computing trends between now and 2020. The IT Swami predicts the Twenty-Teens (The IT Skeptic)

After observing leadership development professionals are looking for a way to build executive presence in their organization’s high potential managers, Scott Eblin explains what is executive presence based on his research and coaching experience. What Is Executive Presence? (Eblin Group)

While an asynchronous communication like email has become a big part of our communication paradigm, the lack of interaction in real-time has its short-coming. Seth Godin advocates building resilience into how we communicate with one another. Toward resilience in communication (the end of cc) (Seth’s Blog)