Jan
05

One Step Backward, Two Steps Forward

I am proud to announce that I have started a new position in November 2011. It is a one-year contract in Tokyo to help transform the local, shared IT service provider to a global infrastructure utility provider. My position involves the discovery and implementation of processes based on good practices from ITIL. The project involves a number of challenges that are typical of global organizations, ranging from technical to political, and involving people, process and technology. I am excited to take on these opportunities.

My blogging and social networking have been reduced as a result of the schedule change and demand loads, but I appreciate everyone’s support and I am adapting my production around my new schedule. Please stay tuned for lots of good things to come.

Nov
13

Should Incidents Be Re-Opened?

Should Incidents be re-opened? The simple answer is: yes, if it was Closed incorrectly. Incorrect closure may include incorrect or incomplete testing or failure to confirm service restoration with the customer or user. However, IT environments are complex and reality is seldom so simple. I advocate instead against reopening Incidents, after a 2-3 day Resolved period.

The best trade-off, in general, is to allow a 2-3 burn in period, during which the request is fulfilled or the Incident is Resolved. Resolved means service has been restored and all records have been updated. The customer or user now has 2-3 days to test and validate before the Incident record is Closed, generally automatically by the tool. Once Closed, the Incident cannot be reopened.

There exist perverse incentives to create multiple Incidents, particularly in a pay-per-issue billing model. On the other hand, there is also the opposite perverse incentive to re-open Incidents for new Incidents or requests, and to include multiple, unrelated requests in the same issue. Sometimes this happens just out of laziness, i.e. it is faster to re-open an existing issue than fill in a new one.

In addition there is gray area between what is a new Incident and what is an existing Incident. Some errors are intermittent. Restarting the device or application may restore service, but the Incident may occur again in a few hours, days, or weeks. In this case a Problem record should be raised, but the Incident may reoccur before the Problem Management and Change Management processes can run their course. Are these repeat Incidents new or existing? Every organization should have its own answer and it depends on the Incident. A 2-3 day separation between recurrences is a good, general policy to distinguish between new and existing ones.

Organizations who choose to re-open Incidents should track these Incidents. An independent party should verify they were re-opened appropriately, and any inappropriate activities should be managed through administrative or disciplinary actions, hand-slapping, or public humiliation. If this sounds bureaucratic or patriarchal, it is. In general it is easier to define in terms of time and enforce with a tool.

The 2-3 day Resolved period is not perfect for all situations and not suitable for all organizations. However, I have found through experience it is a good solutions that is flexible, widely applicable, unbureaucratic, conceptually simple, and generally fair to all parties. And once Closed, the Incident should remain Closed.

Oct
19

Cumulative ITIL Certs since 2008

These numbers are estimates based on number of exams taken multiplied by the pass rates. In some cases the pass rates are not available and I had to use a proxy pass rate. For ITIL V2 Foundation passrates I used the average V3 Foundation pass rate. For advanced ITIL V2 certifications I used 60% pass rates. These were as reasonable assumptions as I could make based on published data.

Click on the charts to see more detailed views.

My estimates for Foundation certificates awarded since 2008 are:

ITIL V2 Foundation: 142,000
ITIL V3 Foundation Bridge: 33,000
ITIL V3 Foundation: 548,000

My estimates for advanced ITIL certificates awarded since 2008 are:

V2 Practitioners: 9,000
V2 Service Managers: 18,000
V3 Experts (via Managers Bridge): 12,500
V3 Experts (via MALC): 2,500
V3 Experts (Total): 15,000

 

Oct
13

ITIL Certification Update for July 2011

The latest ITIL certification statistics are available here from APMG. As usual we have tried to make sense of the numbers. Click on the thumbnails to see more detailed views.

The graph above shows the number of ITIL Foundations exams taken since January 2009. Worldwide interest is continuing to grow a an annual 15% growth rate.

Worldwide interest is distributed roughly evenly between Europe, Asia, and North America. However, the North American share has declined from 29% in April 2010 to 20% in July 2011.

At the Intermediate exam level, the Lifecycle track continues to pull away from the Capability track. However, the Lifecycle track saw a large dip in July that wasn’t seasonal and wasn’t reflected in the Capability track. I suspect candidates were awaiting the arrival of the ITIL 2011 refresh before resuming Lifecycle track certifications.

By region, the Intermediate exams are dominated by Europe, which generates about half the total Intermediate certifications. North America, as a share of the total Intermediate certification market, has declined from 39% in January 2010 to 20% in July 2011.

The advanced certification include V2 Managers and V3 Intermediate, and V3 Managers Bridge exams. The V3 Managers bridge saw a huge spike in June 2011 just prior to the expiration of the exam. Afterwards it fell to a negligible level in July 2011. The number of newly minted ITIL V3 Experts dipped from 2,188 in June to 280 in July. It remains to be seen whether interest in the advanced V3/2011 certifications will grow now that the V3 Bridge track from V2 has been officially retired.

The graph below shows the growth in the total number of ITIL V3 Expert certifications since January 2009.

 

Sep
19

Gameplay is “a series of interesting choices”

Ivanka Menken has asked me to take part in a beta offering of a new course on Gamification. In this Blog I will detail some of my thoughts as I progress through the class and try to answer the questions when and how is Gamification significant, and is it an enduring feature of just a trend?

I found Sid Meier’s definition of gameplay interesting in its simplicity and completeness. Gameplay is a series of interesting choices.

It is also a brief summary of the concerns I’ve had about the idea of gamification of non-game interactivity. If the choices are not interesting, then adding achievement badges or levels, leader boards, and progress bars are not helpful. In fact they are distracting. Witness Exhibits A and B from the Audible iPhone app.

I listen to audiobooks from Audible.com (part of Amazon.com) for the content of the books. The interesting choices are in selecting and reading the books. To the extent Audible makes it easy to browse titles, see the reviews, and preview audiobooks (which I seldom do, I admit), I will enthusiastically continue buy their audiobooks. I will not listen to audiobooks in order to progress from AppNewbie to AppNovice, or to earn a All Nighter badge.

This seems obvious to me, but why did Audible gamify the app in this way? The simplest answer is: to try something new and see what sticks.

The more complex answer may be that Audible is trying to build a community around audiobooks the way Amazon builds communities through reviews, lists and discussion forums. Audible might be able to connect, for example, people who have done All Nighters or run a marathon using the same book or similar sets of books. But note that the “social networkfication” of the book experience does not depend on its gamification, which is a weak tool for that job.

The idea of gameplay as a series of interesting choices implies that uninteresting games or uninteresting choices cannot be gamified with any success. An example is Empire Avenue. I know a number of my Twitter followers have joined Empire Avenue. Judging by the low rate of their activities, the site isn’t very interesting, but it does stick a badge in your face every 5 minutes. This is distracting and may simply be an acknowledgement that the underlying concept isn’t viable. Gamification is a crutch and a weak one at that.

I do acknowledge that in some cases progress reports are helpful. This progress chart from the same Audible app is interesting, and additional charts by type of book would also be welcome. Progress charts are also useful in areas that aren’t necessarily interesting but where the viewer expects to receive benefits in the future. For example, Empire Avenue could benefit if their members could expect to win real rewards for superior trading activity.

Other examples might include profile completeness on professional sites such as LinkedIn, or in traditional job search site, or activity progress in educational software or sites, such as Khan Academy. Gamification in these areas shows a lot of potential.

Apr
18

The Problem of CSFs

If you are unable or unwilling to appoint a Problem Manager, you are not ready for Problem Management.

That’s what I said. Or at least I think that’s what I said.

The venerable and ubiquitous Chris Dancy quoted me this January 2011 on episode 1 of the re-formed Pink Elephant Practitioner Radio podcast. He quoted me as saying “you can’t do Problem Management without a Problem Manager”. I finally listened to it last Friday.

I want to apologize to Chris. First, I apologize that I didn’t listen to his podcast earlier. I am a couple months behind on my podcast queue. Second, I apologize that I didn’t thank him personally at #PINK11 in February for the mention. I love Chris in almost every conceivable way.

I don’t fully agree with the paraphrase. I think a company can successfully implement a Problem Management process without a Problem Manager. What I really wanted to say was this: If you are unable or unwilling to appoint a Problem Manager, you probably haven’t achieved all the critical success factors you need to successfully carry out Problem Management. Unfortunately, this sentence doesn’t tweet well, so I abbreviated.

ITIL v3 Service Operations lists the critical success factors for Service Operations processes:

  1. Management Support
  2. Business Support
  3. Champions
  4. Staffing and retention
  5. Service Management training
  6. Suitable tools
  7. Validity of testing
  8. Measurement and reporting

All of these are necessary to successfully implement Problem Management. Organizations that lack any of these factors won’t appoint a Problem Manager. My advice to organizations, then, is very simple: appoint a Problem Manager. If they cannot do this, they are not ready for Problem Management.

In fairness, a few organizations do meet all the above CSF’s and choose to implement Problem Management without a centralized point of contact. It is the responsibility of managers to perform Problem Management activities inside their own group. Organizations with the right culture can get away with this. Most organizations cannot.

For that matter, most organizations cannot muster the courage or resources to appoint a Problem Manager.

Dec
30

Rethinking the CMS

I first started this post in response to the IT Skeptic’s CMDB is crazy talk post about 2 weeks ago. My own position derives from several observations in the real world:

  1. Few organizations are willing to perform a full spectrum CMDB implementation, due to cost constraints. (In my opinion few organizations actually require this.)
  2. Observation #1 even includes those organizations that have purchased a commercial CMDB software package. They purchased the software to achieve a more specific objective.
  3. And yet most organizations perform some level of configuration management, even if that is as simple as tracking software licenses on a spreadsheet.
  4. Most organizations would benefit from doing a little more than they are currently doing. The “what” depends on the organization.

The ITSM community needs to stop thinking about the CMS / CMDB as a process (which has defined inputs and outputs) or a thing or a database. Instead we can think about it as a broad collection of activities that help maintain information and documentation on the configuration of assets and software inside an organization. This isn’t a black or white implementation where you do it all or you don’t do any–most organizations span the spectrum of gray.

The trouble with ITIL (as if there were only one) is the concept of a CMS is so abstract that most people cannot understand  it. This is by design–it saves the authors the trouble of actually doing anything. I still have trouble describing ITIL’s take on the CMS, and I have done practical implementations in a dozen organizations.

Let’s help practitioners by enumerating and describing the various CM activities that take may take place that are common in the real world. We will explain the benefits and costs associated with each.

For example:

  • Automated discovery of hardware assets
  • Automated discovery of installed software assets
  • Automated discovery of network assets
  • Automated linking of software and hardware assets
  • Automated linking of hardware and network assets
  • Automatic reporting on software compliance and unused licenses
  • Linking Incidents to CI’s
  • Linking Changes to CI’s
  • Linking Problems to CI’s
  • Linking CI’s to end-users
  • Linking CI’s to end-user organizations

This list is VERY incomplete, and there is no out of the box solution for any of the above. There is a wide variety of expression of CI names, CI types, attributes, and statuses of the above items. Each can be automated to different levels.

By making a checklist we can help practitioners and organizations understand what they can do, what other organizations do, and what they should consider in the future. It would be a list of available options, rather than a document of the One True Way dictated high from above. We can expand on Skep’s checklist concept.

A checklist of practical activities could also feed into a maturity assessment.

We can call it the Management of the Configuration of the Configuration Management Database Database. Or we can call it WikiCMDB for short. Stay tuned here for more details.

I am thinking out loud, so everything in this post may be wrong. I welcome your feedback.

Nov
23

Killing IT Projects (Dead or Alive)

About 10 years ago I was the infrastructure manager for the Tokyo branch of global financial firm. I was involved with 2 projects that had gone wrong.

Project A was an initiative to pull some additional analysis and data from a well-known market data provider. The vendor was unresponsive, even though the project was as much in their interest as ours. The requirements were growing more complex by the day. Overnight the vendor rolled out some new code unannounced that broke our test system. The next day we pulled the plug.

Project B was an ERP system that was to be rolled out globally, to a bunch of independently-managed and funded IT departments. It contained no features or functionality that our users wanted. The global project “manager”, himself a last-minute transplant, announced a minor milestone the day it was due. I asked for a project plan and received an amorphous blob of unintelligible requirements. We tried to comply with their requests for a while, but none of our local users were helping us. I heard tales of the project well after I left.

Project B had too many issues to discuss. There are two I would like to mention here, in the context of both projects A and B. Both concepts are strait from the PRINCE2 method. Let’s start with RACI, an acronym for:

R = Responsible: one or more parties who carry out the work

A = Accountable: one party who is accountable for all activities

C = Consulted: zero or more parties (other than R or A) who may also be consulted on the task, or alternatively on the planning of the task in a process

I = Informed: zero or more parties who may be informed of the results of the task, or alternatively may be informed via reporting of the outputs of the process that performs that task

PRINCE2 is very clear on the accountable party, called the Project Sponsor. The Sponsor is one person (not group, not committee) who owns the Business Case, and who can allocate resources as necessary to achieve the Business Case.

The second concept is the Business Case. It is qualitative and quantitative descriptions of the benefits to be achieved by the project. It is a living, breathing document that is updated throughout the project, more specifically between each phase. Every phase contains a go/no-go decision based on the business case.

In my examples above, Project A had a clear sponsor who understood the business case (as far as I know the business case was never documented, but it may have been). When requirements escalated, and the relationship with the vendor’s project team soured, the sponsor pulled the plug. It was an easy decision, and none of the project participants were tainted. It wasn’t a particularly eventful day.

Project B had no individual sponsor. The sponsor was a committee with a broadly defined goal to improve transparency and accountability. There was no business case, for the organization as a whole or for the individual offices (the latter is a governance issue). The project died a long, slow death, but I am absolutely sure it died. Lacking a sponsor or business case, it should never have started in the first place.

Dying projects should be killed. No remorse. No finger-pointing. No false gestures of “accountability” only meant to take down political enemies (or cover up incompetence). Project requirements change, especially in IT projects. The external environment changes. These affect the business case. If the business case no longer warrants further expenditures, the project should be killed. There is no shame.

In fact I would reward the project sponsors who kill the most projects for lack of business case. If they save $200,000 in bungled projects, they deserve a $20,000 vacation package. On the company. Most IT departments would agree they deserve it.

Nov
10

Gaming the Addiction of Social Media

During World War II the British routinely intercepted German Morse Code transmissions. Eventually Bletchley Park was able to decode many in real time, but even the encrypted transmissions provided valuable information. The radio operators developed intimate familiarity with signature characteristics of the transmitters. They were assigned names and given personalities. The locations of their transmissions provided valuable intelligence about the deployment of Germany troops.

Even the limited bandwidth of encrypted Morse Code transmissions provides the radio operators a rewarding sense of intimacy. Those of us who are incapable of “getting” their experience should note that many non-users of social media also don’t get it. An increasing number of people worldwide understand the feeling of connectedness and intimacy they can feel with complete “strangers”. Nobody need remain a stranger for long.

TEDTalks never ceases to amaze me for the breadth, depth, and originality of the presentations. On November 2, 2010 TEDTalks released a presentation by Tom Chatfield called 7 Ways Games Reward the Brain. It is worth watching the video, but in a nutshell the 7 ways are:

1. Experience bars measuring progress: LinkedIn uses this when filling out your profile completeness. Facebook users measure their importance by their number of friends. Similarly Twitter users measure their numbers of followers and tweets.

2. Multiple long and short-term aims: Users seek to engage each other in a variety of ways that evolve over time. However, the lack of clear objectives is at least one reason for abandonment by novice users.

3. Reward effort: in video games this means every activity is associated with experience points or gold. In social networking it means getting retweets or Likes or replies to updates.

4. Rapid, frequent, clear feedback: In video games and social networks the availability of feedback is a reward of use. However, the lack of clear aims with clear feedback can cause abandonment.

5. An element of uncertainty. (“This is the neurological goldmine.”): Gamblers know this factor well, as do gamers and social networkers. Your most clever post can go without response, while the most mundane of comments can elicit pages of replies. The uncertainty encourages participants to keep trying.

6. Windows of enhanced attention, when learning is taking place at an enhanced memory. Improves memory and confidence. Video game designers spend a lot of time tuning the game to enhance attention. To some extent social networkers can tune their own experiences by how often they check their data feeds, subscriptions, and discussions. However, social network participants and designers are behind video games in studying ways of enhancing attention to improve retention and learning.

7. Other people: This is a factor in video games, and even more so in social networks. The ability to form networks of interest or reconnect with old friends are some of the most rewarding aspects of social networks. Somehow, following the travels and travails of complete strangers is entirely rewarding.

Why does this matter? The video game industry is $50 billion, and gamers spend $8 billion in real-world cash on video game experiences that have no real-world equivalent. We haven’t even begun to unlock the (monetary and otherwise) potential of social networks. As a participant, a corporate marketer, or social network designer, this matters. Constructing the right experiences can result in significant cash rewards. But for many, I reckon that isn’t the point.

Nov
09

Ditching the Resume

I want to be the ITSM guru who never needs to write another resume. Ever.

I am not there yet, I admit, but it is my professional goal. Not to be rich. Not to pass the Service Strategy exam. Not even to understand what really makes up that nebulous ITIL V3 CMS.

You may wonder if it is because I hate HR types. Maybe, but I think I don’t really hate HR types. Actually I think HR is the most undervalued job in corporate America. HR has the largest impact on organizational performance, yet it is often an administrative job that collects time sheets and writes and distributes the formal HR manual that nobody reads.

I have a friend who I would trust implicitly for any ITSM engagement. He has it all. The certification. The theory. The practical experience. The communication skills. Practical tool knowledge. He plays a musical instrument. I know he is looking and I hope I can be the one to find him something.

I want to be known the way I know him. I won’t need a resume.

The resume is an anachronism. It is a two-page summary of a person’s professional life that warrants 10 seconds of a hiring manager’s life, in order to ascertain whether the applicant can spell correctly or pay for a professional resume preparation service.

This is the pinnacle of our knowledge-worker economy? If so we are all doomed.

I heard somewhere that eighty percent of Americans lie on their resume. Maybe it was sixty percent. It doesn’t matter.

Knowledge workers need to move beyond this. The resume is a standard tool to describe commoditized products.

If your professional career has to be confined to a static resume, then you are competing with 100,000 other commodities around the world. You are a commodity, like pork bellies or light-sweet crude that costs less than bottled water.

I started this the other day. It isn’t finished yet, but I am calling it my Visual Resume. Publicly I am posting only a low-res portion of it. Email me and I will send you the fuller version of it.

http://about.me/gregorytucker

Older posts «