Fresh Links Sundae – April 29, 2012 Edition

Fresh Links Sundae encapsulates some pieces of information I have come across during the past week. They maybe ITSM related or not entirely. Often they are from the people whose work I admire, and I hope you will find something of value.

Managing the Business of IT Needs More Than Just Good Project Management Robert Stroud discussed the three key elements of “Business of IT,” Portfolio Analysis, Financial Transparency, and Performance Management, and why it is critical to execute them well. (CA on Service Management)

End users: should we put them in padded cells? David Johnson discussed the term “end user” and why people oriented considerations are important in any infrastructure design decisions. (Computerworld UK)

Do you have a people strategy? Seth Godin argued that strategies for communication medium such as email, web, and mobile are not addressing the most important strategy of it all. (Seth’s Blog)

Help Desk 101 – 10 Things to Consider for your EMAIL ONLY Support Team Joshua Simon gave ten solid suggestions on running an email only support operation. (ITSM Lens)

What is Service Management? Rob England gave a detailed run-down of the service management concepts using a railway example. (The ITSM Review)

ITSM Customer Relationships: Mad Customer Disease Julie Montgomery talked about ways to help customers with getting things done effectively, efficiently, economically and equitably to get value for money. (Plexent)

SDITS 12 – A New Beginning? James Finister shared his recent experience at SDITS 12. (Core ITSM)

The cult of innovation Rob England discussed why innovation for its own sake is counter-productive and why instead we need to concentrate on the efficiency and effectiveness of what we do for the organization. (The IT Skeptic)

You Don’t Need This “Recovery” Umair Haque discussed we might be in a eudaimonic depression, in his terms, and suggested what to do about it. (Harvard Business Review)

Overcome the Addiction to Winning Marshall Goldsmith discussed the importance of not winning on everything; include the meaningless or trivial stuff. (Marshall Goldsmith)

COBIT 5 and What You Can Leverage for ITSM Work

ISACA recently released COBIT 5, a governance and management framework that can help organizations create optimal value from IT. If you are familiar with COBIT, hopefully you have already downloaded the framework documents. If you are not familiar with COBIT or ISACA, follow this link to get more information on the framework. In this post, I will outline some of the useful information you can leverage from COBIT to help you in your ITSM journey, based on my early perusal of the framework.

Good Practices

For a number of processes we use in ITSM, there is a corresponding one in COBIT. For example, DSS02 in COBIT “Manage Service Requests and Incident” maps approximately to the Incident Management and Service Request Management processes in ITIL. Within the process DSS02, COBIT breaks the processes down further into seven management practices. Within each management practice, there are a number of activities associated with each management practice. If you want to implement or improve an ITIL Incident Management process for your organization and wonder what are considered as good practices, these management practice activities can provide some valuable insights for your effort. Tailor those activities further into exactly what you would do in your organization and you have a list of good practices for your shop.


For each process, COBIT 5 has outlined various IT-related and process goals that a process contributed directly towards. Next to each goal, COBIT outlines a list of recommended metrics to measure for those goals. Of course, depending on your organization and the availability of certain service management data, you will have to find tune those metrics for your environment. It offers an excellent starting point for defining the list of metrics you plan to capture.

RACI Chart

For each process, COBIT 5 has a RACI chat that talks about who is responsible and/or accountable for certain key management practices within the process. Granted, the RACI chart can be high-level and somewhat generic. It nevertheless offers a good starting point for those who are working on a process design exercise or just want to better define the roles and responsibilities within your environment.

In summary, I must say I like what I have seen from COBIT 5 so far because the framework offers a great deal of good information to use for your ITSM work. I definitely recommend downloading and checking out the new framework further. On Tuesday, April 17, 2012, Debbie Lew of Ernst & Young and Robert Stroud of CA hosted an education session on COBIT 5 during ISACA Los Angeles Chapter’s annual spring conference. Normally the presentation deck is available only to the attendee of the conference. Ms. Lew has graciously given me the permission to make the presentation deck available via this blog. Check out their deck for more information on COBIT 5 and feel free to post questions and comments.

DIY Process Assessment Wrap-up – Constructing the Report and Presenting the Results

This is the concluding post on the DIY Process Assessment series. In the previous posts, we went from lining up the approaches and resources, planning various aspects of the assessment, running the assessment and collecting the data, and eventually making sense of the data collected. The last major steps are to write up the report and present the results to the stakeholders.

Writing up the Report

The final report should summarize the assessment effort, provide solid findings on the current maturity level, and suggest both near-term and long-term actions for improvement. Generally, the assessment report will contain the following elements:

  • Executive Summary
    • Short summary of project background and problem definition
    • Brief description of the assessment methodology used
    • Summary of maturity scores for each process assessed
    • Discussion on the integration between processes and other comparative benchmark information
    • Project Scope – mention the processes and organization units covered under the assessment
    • Overall conclusion, recommendations, and next steps
      • Did the conclusions appear to be logically drawn based on data gathered?
      • Did the results confirm the perceived problem?
      • Are the recommendations aligned logically with the conclusions?
      • A roadmap showing the sequence of actions and dependencies between actions
      • Analysis of the Processes (for each process)
        • Scores or maturity levels by processes
        • Process goals, intended outcomes, and perceived importance
        • Process specific conclusions and recommendations
        • Organizational Considerations
          • Any noteworthy factors encountered during the assessment that could provide more insight or context on the conclusions
          • Any other organization related factors that should be taken into account when implementing the recommendations or actions

Presenting the Results

When presenting the results, keep the following suggestions in mind.

  • Depending on your organization, you may use different types of meetings or communication vehicles to present the results. At a minimum, I feel the project sponsor should host at least one presentation with all assessment participants and senior leadership team.
  • Hold additional meetings with the process owners to discuss the results and to identify quick-wins or other improvement opportunities.
  • Anticipate questions and how to address them, especially the ones that could be considered emotional or sensitive due to organization politics or other considerations.

It took seven posts in total to cover this process assessment topic, and I feel we have only covered this subject at a somewhat rudimentary level. There are more things to drill down in-depth, but everything we have covered so far will make a very good starting point. As you can see from the steps involved, the assessment is not a trivial effort. Before you go off and start planning the next assessment, some people might ask one important question “why bother?” I can think of a few good reasons for taking the time to plan and to do the assessment.

  1. Most organizations do not have the processes at a minimally effective level they need to support their business or operations. They want to fix or improve those processes, and a process assessment effort can help to identify where things might be broken and need attention. The problem definition is a key area to spend some effort on.
  2. Many organizations undertake process improvement projects and need some ways to measure progress. Process assessment helps not only for establishing the initial benchmarks but also for providing subsequent benchmarks that can be used to calculate the progress. A lot of us do measurements by gut-feel. Intuition and gut-feel can be right sometimes about these things but having the more concrete measurement is much better.
  3. Along the same line of reasoning for having the concrete measurement, I cannot think of another better way to show evidence of process improvement or ROI to your management or project sponsor than with formal assessment. Many people do process improvement initiatives via a grass-root or informal effort with internal funding due to organizational realities. At some point, you may find yourself needing to go to management and ask for real budget for time, people, and tools. Having a structured approach to show the potential contributions or ROI down the road can only help out your cause.

In conclusion, process assessment can be an effective way to understand where your process pain points are, how to address those pain points, and how far your organization has come along in term of improvement. All meaningful measurements usually take two or more data points to calculate the delta. Conducting process assessment periodically can provide the data points you need to measure your own effectiveness and to justify further improvement work.

Links to other posts in the series

Fresh Links Sundae – April 22, 2012 Edition

Fresh Links Sundae encapsulates some pieces of information I have come across during the past week. They maybe ITSM related or not entirely. Often they are from the people whose work I admire, and I hope you will find something of value.

Why a “rules based” approach to Change Management always fails Glen Taylor discussed why rule-based change management practices have limited effectiveness and why risk-based approach is the better target. (ITSM Portal)

COBIT 5 Miscellany Geoff Harmer gave his initial impression of COBIT 5 and how it differs from the previous version of the framework. (ITSM Portal)

IT Metrics Planning: The Business Meeting Julie Montgomery suggested ways for IT and business to work together and come up with metrics that can help both organizations. (Plexent Blog)

At the Helm of the Data Refinery: Key Considerations for CIOs Perry Rotella discussed that “data refinery” is the new strategic operating model for companies and why CIO is the executive best positioned to lead the enterprise forward in this new model. (Forbes)

5 Ways to Access the Power of the Hive for ITIL Initiatives Jeff Wayman discussed ways to leverage a diverse group of people for the benefit of ITSM initiatives. (ITSM Lens)

7 Benefits of Using a Known Error Database Simon Morris gave an in-depth discussion of KEDB and suggested ways to extract values and benefits from it. (The ITSM Review)

The ABC of ITSM: Why Building The Right Process Matters Ben Cody discussed the human aspect of ITSM and why a positive dedication to “process” should be at the heart of how organizations solve complex IT services challenges. (The ITSM Review)

How to Make Your Company More Like Apple Daniel Burrus talked about how companies, large or small, can build their future by competing on things other than price. (Strategic Insights Blog)

An Asshole Infested Workplace — And How One Guy Survived It Surviving a toxic work environment is not a trivial undertaking – you do what you could and had to do without spreading the toxic atmosphere further. (Bob Sutton)

How to fix IBM in a week Robert Cringely wrote a long series of blog entries discussing what is going on within IBM, what is wrong, and how to fix it, maybe. (I, Cringely)

ISACA Los Angeles Chapter Spring Conference, Week of April 16, 2012

Apologies to the readers of the blog.

There will be no posting this week due to my volunteer work with ISACA Los Angeles Chapter Spring Conference Committee. ISACA LA is celebrating 40th anniversary for their annual 3-day conference. This education event covers fundamental information systems auditing concepts and emerging technology risks. The conference also provides rich opportunities for its attendees to network with other governance, assurance and security professionals.  The Spring Conference has turned into the leading IT governance, security, and assurance event for the Southern California area. The 2012 conference attracted over 300 participants.

I have been working with the Spring Conference organizing committee for the last nine years. The committee has always come with dedicated volunteers who gave their time and superb effort to deliver a professional quality event for the benefits of the Chapter’s members. I have nothing but great things to say about this group of people with whom I have come to know and respect.

I will be back next week. In the meantime, if you are curious about the ISACA LA Spring Conference, head over to the Spring Conference website and check it out.