Fresh Links Sundae – June 8, 2014 Edition

????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????Fresh Links Sundae encapsulates information I have come across during the past week. Often they are from the people whose work I admire or resonate with me. I hope you will find these ideas thought-provoking at the minimum. Even better, I hope these ideas will, over time, help my fellow IT pros make better decisions, be awesome, and kick ass!

Many companies are struggling to add piecemeal elements to their existing IT operations in order to compete in the digital era. Some experts have suggested that reinventing the IT function may be another way to deliver the digital capability the companies need to compete. Henrik Andersson and Philip Tuddenham have identified seven elements that are critical to achieving the IT performance improvements required for the new digital world. Reinventing IT to support digitization (McKinsey & Company)

When moving towards a more “digital” enterprise, many organizations are adopting what Dion Hinchcliffe called the ‘bolt-on’ strategy, which typically means adding a few new digital channels to existing touch point. He explains why companies should consider another more transformative approach when going digital. Going Beyond ‘Bolt-On’ Digital Transformation (Enterprise Irregulars)

Today’s website and web applications contain many distributive technical components. Maintaining and diagnosing performance issues can be complex. In a five-part series, Clare Kirlin discusses the considerations and decisions required to ensure the performance of your websites and web application meets your business needs. New Blog Series: #OptimizeDigital (Part 1) 3 Miles and 14 Bottlenecks: Know Your Performance Enemies (Part 2) Optimize Measurements to Optimize Web Performance (Part 3) Real Users: A Common Web Performance Blind Spot (Part 4) The Quick and Easy Audit that Every IT Manager Should Perform (Part 5) (In the Limelight)

The technologies used in software development have changed radically in the last two decades. Mike Loukides reflects on the technology stacks in use today and describes the essential components everyone in the software development or operations team should know. Beyond the stack (O’Reilly Radar)

Leveraging his recent system migration experience, Andreas Grabner explains why by monitoring all your system components and correlating the results with deployment tasks will you be able to deploy with more confidence without disrupting your business. Web Service Monitoring 101: Identifying Bad Deployments (About: Performance)

With today’s complex projects, some are convinced that the current project management processes are obsolete for dealing with complexity on projects.  Glen Alleman believes that the notion is untested and recommends ways to deal with project complexity. How to Deal With Complexity in Software Projects? (Herding Cats)

In light of what we may have read about the discovery of mismanagement at the US Veterans Administration, Bob Lewis reminds us the importance of collecting and reporting on the right metrics that truly matter to the business. Your own personal VA scandal (IS Survivor Publishing)

We all want to stand out in some way, but we also want to fit in. Reflecting from a personal experience, Jeff Haden outlines the approach for working towards fitting into a larger community. The Best Way to Fit In and Truly Become Part of…Anything (

Food for Thoughts…

Many schools hold graduation commencement during the month of June.  Michael Schrage gives us a playful, but not implausible, look at a future commencement speech. The First Robot Commencement Address (Harvard Business Review)

Fresh Links Sundae – April 27, 2014 Edition Links Sundae encapsulates information I have come across during the past week. Often they are from the people whose work I admire or resonate with me. I hope you will find these ideas thought-provoking at the minimum. Even better, I hope these ideas will, over time, help my fellow IT pros make better decisions, be awesome, and kick ass!

Many IT organizations are transforming themselves to be a service provider to the enterprise, and there are quite a few different ways for the service provider model to work. Bob Lewis outlines the potential business models in case you’re serious about pursuing the plan of running IT like a business. More business models for ITaaS  Yet more ITaaS business models (IS Survivor Publishing)

When making your data analysis case persuasive, assembling and interpreting data alone is fine but probably not sufficient. Scott Anthony believes you need to take a step further by generating your own data and experiment with them. Why You Have to Generate Your Own Data (Harvard Business Review)

Data Architecture and Data Governance, when done effectively, can support each other in a variety of ways. Kelle O’Neal explains how DA and DG help by increasing operational efficiency, decreasing costs and mitigating risk. What Is the Relationship between Data Architecture and Data Governance? (Blog: Kelle O’Neal – BeyeNETWORK)

Creating a continuous improvement mindset is about creating the conditions for all IT stakeholders to improve their work, processes and services. Dave van Herpen gives an example of how explains how agile and lean elements can work with ITSM and help the IT function deliver great services. Agile CSI: continual service improvement done right (ITSM Review)

To effectively influence the IT employee mindsets, leaders must send messages that powerfully communicate IT’s objectives and priorities. Andrew Horne suggests how IT leader can decide what metrics to pick and to emphasize. When Designing an IT Scorecard, Don’t Forget the Message Behind the Metric (CIO Leadership Council)

Processes underpin organizational capability, which in turn support the strategy execution. Pearl Zhu outlines the criteria to consider when mapping and evaluating processes to support business capability. How to Evaluate Processes (Future of CIO)

Robert Stroud believes that the transition of the IT Service Management department to a Service Broker model has only just begun. He explains the rationale behind the movement of IT organizations to embracing the IT Service Broker model. From Service Manager to Service Broker (CA Service Management)

When starting out on a career, it’s important to build credibility with new people, learn about your organization, and make a solid contribution. Through a four-part series, Laura Brandenburg gives a detailed run-down of what a new Business Analyst can do to be effective on the job from day one. Starting a New Business Analyst Job (Part 1): What To Expect on Your First Day  Starting a New Business Analyst Job (Part 2): How to Prepare for Your First Day  Starting a New Business Analyst Job (Part 3): How to Make the Most of Your First Week  Starting a New Business Analyst Job (Part 4): Your First 60 Days (Bridging the Gap)

Why is asking so important for leaders in today’s Information Age with the knowledge workers? Marshall Goldsmith explains why leaders need to do more asking, listening and learning from everyone around us. Why Don’t We Ask? (Marshall Goldsmith Personal Blog)

Change Management Process Design – Part 2

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.

Change Management Process Design – Part 1 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.