ITIL® and Me

In the trenches with ITIL and ITSM.

It’s been a while since I’ve posted on my own blog, and while I’ve been busy writing drafts of several ideas, things have been busy and I never seem to be able to finish my posts.  But with SysAdmin Day right around the corner, I couldn’t resist throwing a new post on my blog that is, yes, the variety of shameless vendor specific promotion that I try to avoid.  Of course, since my paycheck is paying for my new Ferrari (I only drive the ’95 Toyota Matrix so people don’t target me for theft or kidnapping), I’m happy to oblige.  I still stand by my philosophy of being vendor transparent – and the sysadmins out there will love this one…

I have a pretty cool job, no doubt about it.  And my employer is equally as cool (if not cooler), so as part of celebrating sysadmins out there, and for the rest of the year, they’re working on a contest for finding the craziest video that describes the life of a sysadmin.  Maybe you’ve heard of it – it’s The IT Log (if you haven’t heard of it, I suggest heading right over to SysAid’s blog and reading about the contest).  There’s been one catch to this content – sysadmins are very camera shy.  In fact, they’re so camera shy, that none of them want to win the first-place prize of $1500.  I’m honestly not sure why – I have two kids and $1500 would go great for a new gaming PC (since my current computer can’t play Planetside 2).  Needless to say, if you’re a sysadmin and are looking for a few bucks, pounds, shekels, yen or rubles to add to your pocket, it’s a nice way to express yourself and win money at the same time.

Since tomorrow is SysAdmin Day, I’d like to include a mini-contest (which I’m sure I’m not authorized to do, but I don’t care).  For all the videos submitted tomorrow, I’m going to choose the three best of the bunch and send out $25 Amazon gift cards to their submitters.  Ok, so maybe that won’t get you a Ferrari, but at least it’s $75 that won’t end up going to my kids overpriced college education.

And now…a few wise words on vendor neutrality…

[youtube_sc url=”″ title=”Waynes%20World%20Not%20Selling%20Out”]

I can’t even recall how many times I’ve been in this situation:  A new release goes out and several new features aren’t working properly.  Worse yet, existing functionality is now compromised.  This was a common occurrence during my incident management days, and I hear about it throughout the IT Service Management world.  The absolute worst reaction a person, or even a team, can have is to suddenly start placing blame.    Doing so really is just futile and a waste of time because in reality, these problems don’t start during build or development.  They don’t even start during design.  The source can usually be traced to a time before any new project is even started.  In fact, it goes all the way to how a team operates to deliver value.

Maybe I’m thinking about this topic because of my recent read of The Phoenix Project.  Maybe it’s in my head since I’m wondering how IT will evolve during the supposed impending IT & business singularity event.  Either way, the quality of a product can’t be tested right before production.  In fact, it can’t be tested in a single event, but things like quality assurance and governance have to be considered during the entire lifecycle, not just as checkboxes on a project management document.  This is where focus on execution needs to occur.  If a team is working efficiently and diligently, calling out flaws during each and every phase, be it an agile or waterfall build, then by the time the product reaches production, everyone can be comfortable in the end result.  With this in mind, here’s some advice on how to get away from focusing on a final product, and instead focus on the actions and execution:

1.  Focus on one thing at a time

I still don’t understand how my wife can multitask, but one thing is for sure, I don’t do it very well.  Since I consider myself to be fairly average (more on that later), I’m willing to bet most people in IT are single taskers.  There’s already been research on the topic so if you want to know more, feel free to do a search on Google.  The fact that focusing on a specific task can decrease defects is why kanban is gaining in popularity.  If you haven’t tried it yet, I strongly encourage you to do so.

2.  Minimize distractions of key resources

Do you know the name of that guy in IT that seems to know everything?  Not only is he skilled to work on 20 projects at once, but he’s also the “go to” person for fixing things.  Keep in mind, every distraction, a.k.a. incident, that your key resources have to fix is more time away from value-adding projects.  If that person’s knowledge is so valuable, then why isn’t it being captured to share with others?

3.  Knowledge is power (also – sharing is caring)

I’ll admit it.  I love being in a position of the “know it all.”  Not only does my ego get stroked, but it feels great to be valued.  Unfortunately, hoarding of knowledge only hurts the entire organization.  The only way #2 can be achieved is by getting the common knowledge scribed into a knowledgebase for all to enjoy.

4.  Go agile

Look, I understand there are circumstances in which the traditional waterfall approach to development is the best way to go.  Unfortunately, those circumstances usually involve consultants and a lot of departmental overhaul, to be revealed as a “big bang.”  If you have a product and want to release new features, and still want to meet #1 above, then you have to focus on a single feature at a time, and to do it quickly.  This also doesn’t mean just developing a new feature and waiting for more to be completed for testing.  It means development, test, deploy….and to keep doing it again.  If you’re running regular releases and are deploying multiple features in a release, at least deploy to a staging environment so all features can be tested as they’re added.

5.  Go forth and fail

I'll be back

I’ll be back

Nobody likes to fail at anything.  I’ve done it countless of times and I still haven’t gotten used to it.  Of course, all the brilliantly successful people will tell you to not be afraid to fail because without taking risks, you won’t even have a chance to succeed.  With that in mind, I’m going to say go out and fail.  Don’t specifically try to achieve failure, but if something doesn’t work you should just look failure right in the eye and say “I’ll be back.”

Please keep in mind, none of these ideas are inherently new to the world.  You can read The Goal or The Phoenix Project to know more, but with today’s technology, it blows my mind with our potential in the IT world.  Sure, “the business” will eventually take over, or maybe it’ll be the other way around, but if you have the right execution and vision for a service, then the opportunities are limitless.

********** END POSITIVE RANT ************

****** Non-Spoiler Alert ******

If you’re reading The Phoenix Project and are sitting on the edge of your seat, just waiting to know the outcome, then…feel free to keep reading this post.  This is a novel about IT, and there’s certainly no reason to think it doesn’t have a bit (or a lot) of fantasy to it.

With that in mind, on to my review of The Phoenix Project


Whenever I read a book review, especially if it’s from someone that provides recommendations I trust, I really just want to know one thing; should I spend the time and money and invest in the book?  With The Phoenix Project, I give a hearty “yes.”  I will warn you though; if you’re looking for a book to help guide you through the current trending buzz of DevOps, then this isn’t the book.  I’ll admit, I was disappointed that the novel only hit on DevOps for the last few pages, and even then it referenced it more as a possibility in IT.  It was courteous of the authors to put in a segue way to another book, The DevOps Cookbookbut if you follow anything from Gene Kim, then you probably already have a good idea about DevOps anyway.  I’m sure the letdown came more from a recent local DevOps MeetUp in which I asked where I could learn more about DevOps, and The Phoenix Project was the #1 recommended book.

If you want a novel on how to apply methods in The Visible Ops Handbook, another book by Gene Kim, George Spafford and Kevin Behr, then you’ve hit on the right novel.  As I read The Phoenix Project, it was obvious Kim, Spafford and Behr were taking the reader through a Visible Ops transformation from start to finish.  In the first few pages of the novel the authors took every dysfunctional IT department cliche, and put it into a single corporation.  This is where I started to feel like I was reading Fifty Shades of Grey.  Sorry, there’s no weird kinky scenes in the book, but as someone that has heard about the writing in FSOG (honestly, I have not read the book), E L James took every woman’s fantasy and put it into a single male character; smart, very wealthy, never working, and with lots of time to devote to a single love interest.  FSOG contains a lot of unrealistic scenarios (and some realistic, but I’m not going there) that just places the reader into a fantasy land.  The Phoenix Project pretty much does the same thing with how a corporation goes from being the most dysfunctional IT entity to have ever existed, and in the course of three months, becomes a leader in innovation and is in a position to upset competition.  Unlike FSOG, The Phoenix Project doesn’t have any reference to whips and chains, even though those are commonplace tools in IT.  Of course, at the end the main character is put into a position to be groomed to enter the C-level world within the corporation.  While I know the general message is to promote the trend that IT is to meld with the business and it’ll probably happen as more IT leaders move into the business world, there’s definitely an appeal to my personal ego that someone would one day recognize my genius and give me an opportunity, a mentor, and political clout to go and cause a revolution within an organization.  It’s an awesome fantasy and one that I’ve had well before this book.

The one final comparison of The Phoenix Project with Fifty Shades is the writing.  The authors are really smart guys, and they certainly did not have a writing method reminiscent of the 7th grade style I’ve heard is commonplace in FSOG, but at times, it did feel like some dialogue and explanations were created for a less experienced audience.  Between the highly descriptive technical explanations from one character, to thoughts from the narrator, this book does a great job in explaining IT and processes, but if you’re reading it before bed I’ll warn you that it’s possible to fall asleep.  I understand though, terminology and concepts need to be explained in case the reader simply doesn’t know.

The characters themselves are quite interesting.  Once again, I have a comparison to make, and this time it comes from the Haggadah, which I get to read every Passover (which is, incidentally, within  a week – חג שמח).  In the Haggadah there are four sons.  One is wise.  One is wicked.  Another is simple.  The final son simply doesn’t know what to ask.  In The Phoenix Project, There are four main characters that fit these personalities perfectly.  Believe it or not, the main character, Bill, is more of the simple one, with needing his mentor to take him through finding the faults in the department.  Bill’s closest co workers, Patty and Wes, definitely fit in as the wise and “don’t know what to ask” sons, respectively.  Patty is always the person that immediately picks up on the concepts and just seems to “know what to do,” while Wes really seems to be there more for a bit of realistic comic relief (we all know those kind of people).  The final “son” is that of the primary antagonist, Sarah.  Sarah is symbolic of “the business” that doesn’t understand how to efficiently run IT, always pulls resources in for “shadow IT” projects, and ultimately represents the aging business perspective that IT is subservient to the rest of the organization.  I’m  sure everyone in IT can identify at least one Sarah type of person, maybe even several.  Unfortunately, often these people are the ones that stay on top, preventing IT from becoming that strategic partner as outlined in The Phoenix Project.

When I started this review, I gave an absolute “yes” to the purchase, and here’s why:  As The IT Skeptic outlined in his own review, the book is a great selling tool.  Could a company follow the exact same timeline as that shown in The Phoenix Project?  Probably not.  But everyone can identify with the dysfunctions shown in the book, and there are several current methods that are explained to have positive results in helping with transformation.  Many of these are brilliantly illustrated in The Phoenix Project, and there are even examples on how an efficient and effective IT department can run.  Not only that, but if a director or VP reads the book, identifies with the dysfunction, there’s hope that there can be some political push for improvements.  It’s not likely, but it could happen, and I’m assuming that’s why The DevOps Cookbook is published by a company with “revolution” in its name.

While I’m a little late to giving a review, I’m still happy for the purchase and am excited to continue on with my DevOps journey.  There’s now inspiration to read The Goal, and eventually move on to The DevOps Cookbook.  Who knows, maybe I can reference Hunger Games and Christmas in the next post?

Dearest Microsoft Outlook,


We’ve been together since, wow…it’s been so long I almost can’t remember…at least since the year 2000, when I began my first IT job at Chemical Abstracts.  Ok, so we did frolic together a little before that time, but those were personal POP email addresses and it didn’t really count.  No, we became an official “item” when I first connected to a corporate Exchange account.

Through the years of Outlook 97, 2000, 2003, and 2010 we did it all.  From basic settings such as my signature (which I constantly had to recreate since it was always stored locally), all the way through compacting PST files to free space on the server and stop those annoying “Your mailbox is getting full” messages.  Let’s not forget the many times I had to rebuild an end-user’s profile…wow, what long hours that took, especially when the person wanted every little setting exactly how it was before.  But with each reply, forward, and missent email (I still don’t understand why you have a ‘Recall’ feature, which never really worked), our relationship grew beyond anyone’s comprehension; even mine.  I’ll admit I spent a few years with Groupwise, but during that time it was you I longed for, yearning for the days of a familiar Microsoft product to manage my email.

Honestly though, the signs were there that we were drifting apart, and it has nothing to do with the “Kill Email” movement that passed by me without a second glance.  The end started when I purchased a Mac and I was relegated to using Outlook Web Access.  Sure, you updated it so it would work well on Chrome, preventing me from having to switch to Parallels and using IE, but that was only a temporary period of elation.  And yes, I did go with Outlook 2011 for Mac OS, and it generally worked well…for about  day, but after periods of annoying freezing, which could only be fixed by rebuilding my ‘profile,’ I simply gave up on trying to run a local client.  And let’s not even bringing up the Mail and Calendar updates for Mac OS 10.9 Mavericks – that pretty much sealed the deal with running Outlook as a local client.

Outlook, I wish I could say it’s not you, it’s me, but that simply wouldn’t be the truth.  It’s you.  I’ve moved on to a different employer, one that embraces the cloud; something you just were not designed for, despite Microsoft’s best efforts with Office 365.  I do understand my new mistress, Google, isn’t perfect, but who is?  My Calendar and Mail apps connect with it, mobile device configuration is a breeze, and I get the added benefit of integration with Google Hangouts, Google Apps, Google+, Google Drive, and well….everything Google.  In short, it’s simply that you weren’t able to keep up with my new way of life.  And while you could say I’m the one that changed, it’s really been the entire industry and you’ve had a tough time keeping up.

I won’t say you’re a bad product, Outlook.  In some cases, you work out well for many different organizations.  Look, even SysAid has a great blog post on you vs. Google,, and it mentions many great features with Office 365 that your father, Microsoft, has been building and pushing to keep up with competition.  In fact, I won’t even say this is a final goodbye for us.  One day you may change and we’ll reunite back in productivity bliss.  Until that time comes though….it really is you.