ITIL® and Me

In the trenches with ITIL and ITSM.

****** 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.




It’s been a while since I’ve written a post, and honestly, it’s because life as a consultant in the ITSM world keeps me damn busy.  Alas, it’s that time again where I’m switching employers.  Fortunately, and now unfortunately, I had the chance to work with my original “ITSM Crew” from several years ago.

Since my former coworkers have retained their awesomeness, there really isn’t much to add to the tribute*.  I do want to thank them for putting up with me, again, for several months.  I know it wasn’t always easy (especially during my grumpiness of Passover), but it truly was a highlight to spend several hours with each of them, be it during work, laughter, or even the occasional intoxicating beverage.  If you’re looking to network with some really smart people in the IT world, then please look no further than this group of extraordinary individuals:

Jacob Dunmoyer:

Emily Long:

Brett Anderson:


In the immortal words of Douglas Adams – so long and thanks for all the fish!


(* see

I’ve been hearing and reading so many “ITSM is dead” and “IT is dead” statements that I couldn’t simply ignore the propaganda and sit here without some kind of generic response, akin to something The IT Skeptic might state as these being “Attention-seeking declarations of death.”  I can’t exactly explain the reason for wanting to respond.  Since I work in IT, it may be I want to look for some rationalization for staying in the industry, or maybe I’m currently in a “down the revolution” type of mood…or it simply can be I have a level-head and fully subscribe to The Hitchhiker’s Guide mentality of “Don’t Panic.”  For whatever reason, I just want to put out my two cents (or .07 shekels, based on today’s exchange rate) and reiterate that IT isn’t dead; it’s simply evolving.  In fact, it’s been evolving for the past several decades and (unfortunately for the revolutionaries out there) it’s not going to go away anytime soon.  Change?  Yes.  Disappear?  Hell no.

First, we need to examine the credibility of this statements.  I did a wonderful search (thanks to Google) regarding statements of “IT is dead” and came across an excerpt that an author argued “the IT department is dead.”  While I’m sure the statement brought a lot of attention to the book, it’s 2014 and I am still happy to know for a fact that at least one organization has an IT department (ok, several still do).  Sure, the author makes a valid argument that cloud computing will essentially destroy the reason for maintaining an on-premise data center, but through the wonderful teaching method called experience, few organizations have been able to go “all cloud.”  Through the need to maintain secure data, be it government regulations or CEO paranoia, many companies still keep computing on some kind of infrastructure, being worked on by the technical skills required to provide the backbone that allows businesses to function at the speed of technology.

Second, some of us in IT like revolution.  A few weeks ago, a colleague of mine stated “ITSM is dead.  It’s the status quo.”  While I agree the popularity of ITSM has changed in the past few years, thanks to an economic downturn that forced organizations to improve internal processes, ITSM is far from dead.  In fact, it’s far from the status quo.  But I don’t want to ignore that ITSM is changing.  ITIL has now been privatized, ITSM tools are branching out more to the enterprise (at least ServiceNow is), and users are becoming better able to help themselves, bringing about “Shadow IT.”  In short, ITSM is in the middle of an identity transition (or an identity crisis), but futile revolutionary movements such as the SM Congress won’t help to speed things along.  I love revolution just as much as the next person, but trying to force IT through a transition when people aren’t ready will only slow down the evolution.

Third, and probably the most important reason to consider that IT isn’t dead, is the fact that many companies out there are huge.  In fact, massive, and with global infrastructures.  While a small start-up can go all cloud and have the ITSM singularity of IT existing with “the business,” not everyone can change that quickly.  Banks, pharmaceuticals, healthcare; all these industries take a while to change and it’s not going to happen overnight.  In fact, some of the companies in the more “traditional” industries are conservative, and they tend not to change unless there’s a published best practice.  Unfortunately, “best practice” doesn’t come around until it’s already been done, and proven, for a few years.

I’m happy to admit that I’d like to see the death of the IT department.  As people grow in familiarity with the technology, and as technology becomes easier to manage, it’s eventual that every person will have a basic set of IT knowledge to be their own support.  Does that mean IT will really die?  No.  Similar to the H. G. Wells novel The Time Machine, in which the infrastructure of a utopian world is hidden, the majority of IT will go “underground,” to create and provide the services used by the aboveboard business.  At the same time, let’s just hope the Morlocks don’t start eating the Elois.

Switch to our mobile site