ITIL® and Me

In the trenches with ITIL and ITSM.

Browsing Posts published by Michael

Ahhh…yes, another conference is over, so do you know what that means? If you said “a large population of the ITSM population is hungover,” you’re only partly right. It also means that it’s time to write-up a post conference blog article. Compared to my previous conference related posts, you’ll find this one to be a little different. Why, you ask? It’s because this conference was different. In fact, it was very different. In fact, it was so different, it redefines different. I would say this conference was “difspectacularferent.” Without making you wait any longer, here’s my (most likely incomplete) summary of lessons learned from Knowledge 12.

1. As usual, thank you vendors! Your tireless work, enthusiasm, energy and devotion only went unnoticed during the after-hours events, even though you helped to make those moments possible (and unconscious).

2. This was the first conference I’ve ever been to in which a vendor actually paid for “booth babes.” As usual, I won’t name names, but I will say they were “logical” in their reasoning for the expense.

3. Session Depression: A mental state in which there are so many exciting topics being all presented concurrently, that missing them causes depression. This is also another reason why the human cloning process needs to be legalized (I know it’s already available, despite what the government says). Knowledge 12 was the first conference I’ve ever attended in which I found this to be a realistic condition.

4. Chanukah Came Early! If Fred Luddy only showed a single new feature in the Berlin or Calgary releases, I would have said “Christmas,” but let’s be realistic. So many new features all at once? That’s definitely enough to fill the eight days of Chanukah.

5. I predict the next Hangover movie will be filmed in New Orleans. Those that attended Knowledge 12 would probably agree. Those that didn’t; take my word for it and don’t risk the possible consequences of visiting (unless you hire a body guard or simply give up on coming out unscathed).

6. Social IT is moving into a new frontier. Whitepapers and ideas are great, but when vendors start building their platforms around social, you know it’s really happening.

7. As I mentioned in other conference blog posts, networking is the most important activity, but this time, the content was fantastic. In fact, often the best networking opportunties came just after a topic or lab was presented. After the session, presenters were more than willing to talk about new ideas or hear feedback.

8. This conference would not have been the same without social media support. In fact, during a panel I tweeted out that I forgot to grab lunch. Seven minutes later, someone stopped on by and dropped off a sandwich (thank you Andy Ho – https://mobile.twitter.com/#!/techtrainingtip).

9. My dream of never needing to touch a computer is coming closer to reality. Yes, one could argue my iPhone or iPad is essentially a computer, but they are still in different categories compared to my (very big and ugly) laptop. The S***-**w iPad app looks great. Now, if they only would come out with something specifically for admin/coding work….

10. Get a Mac, and save the embarrassment of trying to figure out how to use it right before a presentation.

11. I finally went to a conference where I showed a QR code with my contact information, and people actually knew what to do. Sure, the business card still lives, but your days are numbered!

12. Put my Twitter handle on my name badge. It was far more recognizable as my identity than my actual name (which is understandable since my last name is of Ukrainian origin and not the easiest to pronounce).

 

There you have it, my lessons learned summary. I can safely say that it’s probably not as extensive as other conference posts, but that’s because there was so much content, excitement and energy, that the best lesson I could say to anyone is “Go to Knowledge 13,” and not just because it’ll be in Vegas.

A while ago I was having a conversation with a friend and former colleague in which we were discussing a certain problem related to Change Management (I apologize I’m not ITIL 2011 compliant; I meant change management). See, my friend works as the change manager and she was trying to figure out how to speed along the change review process, especially after her workplace recently started including RFC’s related to a major business system that previously had it’s own change process. One idea that immediately came to my mind was the use of risk calculation. Depending on the type of change, CI undergoing the change, potential impact, testing plans, etc., etc., she and the CAB could sort out the changes and scrutinize (and deny) them accordingly. While we were talking about how best to calculate the risk, something came into my head that I had yet to see: Why not calculate risk based on the person submitting or implementing the change? I hate to be redundant, but this also fits in perfectly with concepts in gamification in which people accrue “experience” points based on certain actions. It’s this experience that’s supposed to help along the calculation.

If you’re still reading, then you’re probably currently thinking one of three things. First, it’s already being done somewhere and I’m late to the party. Second, it’s crazy and will only cause backlash, upheaval, and the eventual apocalypse in which cats and dogs live together. The third option, and one I’m betting on the majority of ITSM’ers out there to be thinking, is “damn good idea, and we’ll start doing that tomorrow.” In case I’m wrong and most people fall into the second class (not to imply you’re a second class citizen), please allow me to defend my idea just a little.

To begin with, I’d like to go back to my history of working as an incident manager and being (somewhat) involved with change management. I remember, after reviewing the change calendar, that when certain people submitted changes, I knew we had to get ready for something crazy to happen. Either users weren’t notified in time, the service desk wasn’t trained, documentation wasn’t complete, or testing wasn’t thorough…either way, there were certain people that I simply did not trust to ensure a smooth change implementation. Conversely, there were a few fantastic colleagues that had their changes and tasks down to a science; they communicated with all parties involved, they had their documentation up-to-date, and on the rare case in which problems did occur, I knew about it before our users did and we could put in a work-around, or at the very least, send out communication to prevent the flood of calls that would eventually hit the service desk. In a way, I was already calculating risk from my own personal experience.

Now that I admitted the existence of my own personal risk calculations, I’m going to step out on a limb and bet other people in the trenches do the same thing. If that’s true, and there are others out there that calculate risk based on people, then let’s just cut to the chase and put that into the actual risk calculation. “How” will be different for every organization, but I highly recommend the gamification concept of using experience. Everyone starts out at a level of zero, and as they successfully submit and implement changes, which meet all criteria in the change management process, they earn points to eventually level up. If certain parts of the process aren’t followed, their score goes down. Once a certain level is achieved, the risk calculation can eventually reduce the level of risk. Of course, there will always be exceptions; certain CI’s may be of such importance that change requests will always need to be highly examined, but overall, I’ll bet (one more time) that any increase in efficiency for change management will be warmly welcomed. Plus, look at the added benefit that now people will want to learn about the change management process, and most importantly, will want to follow it.

As usual, any system in which people are rated is most definitely going to meet resistance. So, is there a way to sneak the practice into an organization without their ever knowing? Here’s my answer; simply start with the gamification and see how it takes. Some people will not care to play (according to David Smoley, it’s likely to occur with digital immigrants), some will think it’s fun, and still others may not even care. But once people are used it it, tying it into the risk calculation can make it seem like an added reward to following common practice and policy, instead of being seen in a negative context (by the way, I don’t intend to push gamification on anybody; it just seems to fit well with the concept I’m describing).

So, is this a crazy idea? Probably so. Do I care? Of course, I do; I suffer from POLLI and am ever paranoid of the repercussions of looking like an idiot in front of my peers. In truth though we, as people, already rate ourselves. Certifications, educational history and years of work experience are all used to try and demonstrate how much “experience” we’ve already accrued. By gamifying change management and risk calculation, it’s only putting that same behaviour into a granular, and functionally beneficial, form. Maybe it’s not so crazy after all…

 

A few days ago I finished my second Snappcast with Matt Beran (two in a row!), and after a (very) awkward moment where Matt brought up that he was going to impersonate Chuck Norris in my S***-**w instance, and I gave a failed attempt at mocking the “Senator, you’re no Jack Kennedy” line by stating I had met Chuck Norris and Matt was no Chuck Norris (sorry Matt – but there’s only one Chuck), I had started to wonder…what if Chuck Norris had written ITIL?  After some lucid moments of speculation, here are just a few differences on how ITIL version C.Norris would have come out if it had been written by someone that truly knows how to provide value in the form of services….

1.  Problem Management would be gone.  With Chuck, there are no problems…

2.  The requirements for the ITIL Master qualification would already be established, and if you’re not Chuck Norris, you don’t qualify…

3.  ITIL would no longer need to be published in five separate books.  All the knowledge would be instantaneously delivered directly into your head by a Chuck Norris roundhouse kick…

4.  There would be no need for Continual Service Improvement.  With Chuck Norris driving ITSM, services will want to improve themselves…

5.  The section in ITIL detailing other frameworks and methodologies would immediately be removed.  If it’s written by Chuck Norris, it’s already the best…

6.  All 26 processes would be combined into a single process – Chuck Norris Roundhouse Management…

7.  Some organizations may want to implement a nonessential, secondary process of Unconscious Management.  This is for those that think ITIL can’t be done with a single process.  This is just a warning – you’re dealing with Chuck Norris after all…

8.  Each ITIL certification test would require the candidate to break a cinder block with a randomly chosen body part.  Chuck Norris doesn’t waste time with multiple choice questions…

9.  ITIL version C.Norris would never have any updates.  Chuck would have gotten it right the first time…

10.  Jokes such as “IT’IL end in tears” will not apply, unless you piss of Chuck.  But even then, the joke would be “IT’IL end so quickly, you’ll be unconscious before you hit the floor…”

11.  With Chuck Norris at the ITIL helm, 95% of companies would have successfully implemented a CMDB (it would actually be at 100%, but Chuck would want to be nice and let the authors of other frameworks think they have a niche in the market)…

12.  There would only be two functions:  Chuck Norris Followers, and those that are trying to remember their names after Chuck finishes with them…

13.  Business Relationship Management will not need to exist.  Chuck already knows what the business wants.  In fact, the business may want to invest in ITCNM (Information Technology Chuck Norris Management)…

14.  The Deming cycle of “plan, do, check, act” would be rewritten as the Chuck Norris cycle of “roundhouse kick, done.”  “Checking” is only useful if it’s for a pulse, and Chuck doesn’t “plan”….ever…

15.  No vendor would ever dare align their software with ITIL.  A company that advertises “We use Chuck Norris” would not survive for long…

16.  ITIL Experts would wear black belts and break wooden boards to prove their expertise.  Do you really think Chuck Norris would allow papers tacked up on a wall to act as certifications?

17.  ITIL training providers would be renamed as “dojo’s”…

 

There you have it…a few changes in ITIL if it had been written by Chuck Norris.  One day, maybe we’ll see his name on the author list.  Of course, in that case there wouldn’t be a list since no one would dare put their name next to Chuck.

You’ll have to pardon me if this blog article is a bit of a rant, but it will be one so I’ll warn you in case you’d rather spend a few minutes watching the next famous furry animal make some dumb face on Youtube (I still crack up at the dramatic look video).

During the past few weeks at the peanut dispensary (a.k.a. work), we’ve been talking, thinking, strategizing, worrying, yelling, stressing, and generally trying to figure out how to build out our CMDB in the hopes of gaining as much value with as little work as possible.  It’s been an interesting few weeks because 1) I hate doing work and I get out of it under the guise of “research,” and 2) I feel like I’m starting the journey of Frodo to destroy the Ring of Doom, but without any cool weapons, a fellowship, or Viggo Mortensen coming along to save me.  Needless to say, since I’m making a Lord of the Rings analogy, which was filmed in New Zealand anyway, I researched the topic and came along what the Kiwi’s, or at least one Kiwi, mentioned about companies and the results of CMDB implementation.  In particular, I took to heart what the IT Skeptic has publicized about only 5% of organizations having successfully justified and implemented a CMDB.  That’s only five percent, which is the same as taking 100 companies and only expecting five, funf, cinco, חמש (you get the idea) such companies succeed in creating a CMDB.  My point is that’s not a lot, so what does that mean to me as a practitioner?

There are two possible answers.  The first one is to give up and don’t even worry about a CMDB (which definitely gets me out of work).  A second option, and probably more realistic, is for us to look at our CI’s (or assets, depending on the reason you’re looking at said IT related object), and record the information that’s most important, and then figure out a way to manage the data.  But if that’s the case, and we’re simply looking to limit our “view” of the IT world and forgo the uninhibited joy of putting together a CMDB, why are we still calling it a “CMDB?”  Is it because we simply don’t have another name, such as “CMDB Lite?”  Or a cool acronym such as WIWWAC (What I Wish Was A CMDB)?  I understand that given the maturity of my current organization, we don’t need a full CMDB.  In fact, if my boss were to ask me to put together a plan on building a fully ITIL-aligned CMDB, the first section would describe the most effective anti-hallucinatory medication available on the market.  So I get it, stick with what brings value.

But now I have another question out there, and this one pertains to the point of my blog post.  If roughly 5% of organizations have successfully implemented, and justified, a full 100% ITIL CMDB, who were/are the people that know what they’re doing?  I understand there are books on the subject (I still have The CMDB Imperative on my reading list), but if the knowledge is readily available, why are we not pushing towards CMDB Nirvana as ITSM practitioners?  In theory, there’s a lot of benefit and reason to do it.  Is it because there’s a financial cost to such a project?  Or maybe a change in culture that needs to occur?  I suspect the answers go beyond just a couple of simple explanations.

Then again, maybe the answer is simple.  It’s unfortunate, but maybe we, as an ITSM community, really just don’t know what we’re doing when it comes to CMDB, at least in a sense that there’s no one single “answer” for everyone.  Sure, it all sounds cool when we talk about it, publish the diagrams in books and white-papers, and generally bring everything up regarding the theory, but it seems to me the concept of a “CMDB” is more closely related to an evolutionary necessity that needs to grow as an organization matures, and not just as a one (or two) phase project.  In essence, only 5% of companies have justified and built a fully implemented CMDB because that’s the limited number of IT organizations that have really matured their processes and require a true CMDB to continue providing value.

So where does that leave the other 95% of us?  Does it mean we don’t know a single thing about CMDB?  I certainly hope not, or else those ITIL v3 certificates in my desk drawer just means I have a back-up alternative to toilet paper when the zombie apocalypse comes around.  An alternative answer, and one that I believe given my faith in the ITSM community, is that we, as practitioners, are really pushing the CMDB as much as the opportunity for return on value presents itself, no more, no less.  And since several of us are gainfully employed, it also means our places of ITSM practice are still maturing and growing.  Maybe not as fast as we’d like, but let’s be realistic, it’s all about the Continual Service Improvement anyway.

So maybe we do know about the CMDB and it would be better to describe the scenario as a long, drawn out drama in which character development is slowly revealed.  Something more like Gone with the Wind, except without anyone falling asleep.