Building the business case for configuration management

Carlos Casanova
Carlos Casanova

This article has been contributed by Carlos Casanova from K2 Solutions Group

At last year’s itSMF USA conference in Nashville I had the pleasure of meeting Dagfinn Krog from itSMF Norway. We had a great conversation regarding configuration management and The Phoenix Project by Gene Kim, and during the conversation, there were some references to attending the conference in Norway, but nothing I took all that seriously. Much to my surprise, a few weeks later I received a formal invitation to not only attend the conference in Norway but to participate in three different sessions.

Having never traveled to the region before, I jumped at the opportunity to participate in what many describe as “one of the best service management conferences in the industry”. Shortly after accepting to participate, I received an invitation from Tobias Nyberg from the itSMF Sweden to meet the itSMF Sweden team in Stockholm after the conference in Norway. To say I was thrilled to be invited to the region and meet with their member and discuss configuration management would be an understatement.

This conference was, in some ways, very different to the many ones that I have attended in the US. The primary differentiator being that this one was much more personal. It could have been the size, which was at record number this year, but personally I think it was more than that. There seemed to be a more “family” feel to it which, for a foreign traveler was very welcoming. From first arrival in Norway to final departure from Stockholm, I could not have asked for a more personal and warm reception from everyone. It’s as if we had known each other for years.  A huge thank you to all involved for making a long trip away from home that much easier.  Ok… now on to why you actually read “ITSM Review”

Configuration management workshop

As I mentioned, I participated in three sessions, of which this was the first. This pre conference workshop focused on developing the business case for your configuration management efforts. We had a great group of individuals participating that were slammed with far more materials than they could ever have possibly absorbed in such a short time, but they all did a great job working through the five activities we had scheduled to start formulating the basis of the business case.

  1. Why is configuration management Important to my organization?
  2. What does “value” look like to my organization?
  3. How will each process area reap “value” from the configuration management initiative?
  4. What should I expect to encounter within my organization that will hinder value from being achieved?
  5. What will I do in the first 30 days once I get back to start generating value?

In a three hour session with a total of approximately one hour to work on the activities, it wasn’t expected that they would form cohesive thoughts and statements but, at a minimum, they would start formulating the foundations of their argument. In much the same manner, we can’t cover all the material from the workshop in this article but, below are some highlights for you to think about.

  • Without configuration management, your level of operational maturity will always be limited due to lack of insight into how devices and services mesh together to deliver business outcomes.
  • If you can’t define/demonstrate what “value” looks like in your organization and to the various domains that must participate, everyone will define it themselves. Leaving it up to each area to define without guidance will most assuredly result in a variety of expectations which you will likely never be able to meet.
  • Identify your biggest challenges immediately and address them or set a path around them. If it’s people, find out what their biggest desire is and see if you can satisfy it. If you can, they will be your biggest advocate and asset to success. If you can’t avoid, if possible, impacting their area for as long as possible until you have established some traction and a broader support base to take them on.
  • Get started. You can’t keep putting it off. The challenge of not knowing has always existed and has only gotten worse.  Waiting for a better time to do Configuration Management is silly. Do something, anything…. and do it now.

What Configuration Management, CMDB and CMS is and isn’t

This session was predominantly based upon materials from my book (The CMDB Imperative)  and framed the core concepts around executing a configuration management initiative. Unfortunately, whether it is clients in the US or individuals in Scandinavia, there are some common areas that everyone seems to struggle with implementing and/or understanding.

  1. CMDB versus CMS – They aren’t the same thing.  Understand the difference and which approach is most likely to work for you. Very briefly, they can be thought of as…
    • CMDB – A conceptual structure that provides perspective to the relationship between two objects controlled in a single data store.
    • CMS –  A conceptual structure that provides perspective to the relationship between two objects across more than one controlled data stores
  2. Relationships – Without them, you really don’t have configuration management, you have watered down asset or inventory management. You’re basically a manifest manager. Sorry!
  3. Transforming Data into Information – There is no shortage of data in every organization. We’re drowning in it.  Problem is, there is no context to it. Configuration Management adds context.
  4. Complexity – Yes, it can be complex if you let it be. Cut through it and look at it through a small network/neural network perspective. Focus on singular connections between items. Then repeat for the next and the next. Eventually you’ll identify them all.
  5. Perspective and Layers – You need to, if you haven’t already, adopt the perspective of the consumer rather than producer.  It is all about producer-consumer relationships and the view from the other side is not always attractive and you need to know that.
  6. Transitioning and Awareness – Your organization didn’t get to where it is overnight and it won’t sort itself out overnight. Set realistic expectations. Expect potholes and speed bumps. Plan for them and factor them in. Be aware of your surroundings at all times because they will sneak up on you.

Establishing a common vision of what “it is” and what “it is not” is instrumental to the likelihood of success. Set a sound strategy and vision and then start small and work at a tactical level to deliver value at regular intervals. You need the small “wins” early to stand a chance at bigger accomplishments later.

Anything about Configuration Management

The last configuration management related session I conducted for itSMF Sweden members, where we held an unstructured question and answer session whereby the individuals simply asked anything related to configuration management. We then had an open conversation about the question and/or statement.  From questions about specific challenges to advice for how to go about doing something, this session solidified my early sense that their challenges, questions and concerns were not very far from their peers in the US or UK.

They were challenged by essentially the same things:

  • Lack of and/or constantly changing “leadership”
  • Poor, nonexistent constantly changing directives
  • Cultural resistance to changing how it’s currently done (a topic discussed extensively in the round table session I also participated in about the Future of ITSM at the Norway conference)
  • Misunderstanding/confusion of the difference between ITAM and SACM

The first three of these challenges are interrelated and based on poor or frequently changing leadership.  Think of leadership as a compass.  It sets direction and vision for where you need to go. If the compass is broken or the owner of the compass continually picks a different location to sail towards, you will never reach your a destination. When this occurs, the masses lose general confidence in leadership and will no longer feel that they should exert energy towards moving in any direction set by them.

An individual I met a long time ago, who was at the time working for a global enterprise well known for their musical chair approach to “leadership” had been subjected to this type of environment for years. He told me without shame or hesitation, (paraphrased) “I just need to get my work done today.  I have outlasted the last three CEOs & CIOs. I will outlast the next three if I just ignore the latest leadership whim and just do the work as I know it needs to get done. I’d like to believe that the next guy will be different, but I have lost faith in that potential so I just focus on doing my job today.”  The bottom line; without strong, reliable and consistent leadership, even the best ideas are likely to fail and breed a bad working culture.

The last item listed has been a more recent awareness as I have worked with more mid-sized clients typically less mature in their operational processes. As these companies try to improve their operational maturity and IT cost accounting, they recognize the need to first capture and maintain lists of devices in their environment and what they cost; i.e. asset and inventory management. However, with all the talk of how configuration management enables you to see all the devices, they tend to make the connection, incorrectly as it may be, that configuration management is the mechanism by which this is done. So, these companies venture down the road labeled “configuration management” unknowingly in search of “asset and inventory management”.

In summary

All in all, the events in both Norway and Sweden were excellent and I strongly recommend that if you have the opportunity to attend next year, you do. The organization of them is top notch, the venues are as you would expect and most importantly, you will be welcomed as though you have been part of their family since birth. Go and enjoy, you won’t regret it professional or personally.

This article has been contributed by Carlos Casanova from K2 Solutions Group

What I learned about IT and DevOps from Gene Kim

Gene Kim presents at itSMF Norway
Gene Kim presents at itSMF Norway

Following on from my trip to itSMF Norway last week, I wanted to share with ITSM Review readers my thoughts on Gene Kim’s presentation “The Phoenix Project: Lessons Learned in Helping Our Businesses Win”, along with some of the key pieces of advice that he presented.

Gene kicked off the first full day of the conference with his keynote presentation about IT and DevOps. If you’re not familiar with his book then I’ll start by highly recommending that you head over to Amazon to purchase a copy. If my recommendation alone isn’t enough to entice you to part with your hard earned cash, then read this article by Gene first.

Gene’s article provides a good summary of his session (along with some great tips), but the bottom line of the presentation was that (and to quote Gene) “IT is in a downward spiral, it’s trapped in a horror movie that keeps playing over and over again” and DevOps is a way to help try fix this.

Advice from Gene

Some of the advice that was provided during his session included:

  • Never forget that the best will always get better. Back in 1979 who’d have thought that anything could surpass the amazing Sony Walkman?
  • In order to win in business we need to out experiment our competitors.
  • Be fearless in breaking things. Mistakes and errors are a key source of learning
  • When it comes to DevOps and metrics, measuring lead time (i.e. the time it takes to go from the “raw materials” to “finished goods” is a much more effective metric than measuring deploys per day
  • When creating a DevOps process it’s important to ensure that you include a “handback” stage. This way, if necessary, fragile services can be returned back to development if operations don’t think that they are up to scratch
  • Develop smaller changes frequently to avoid painful large scale deployments in the future

Bonus learning

Other things we learnt in this session that you might not know:

  • 95% of all capital projects have an IT component
  • 50% of all capital spending is technology-related
  • The value of DevOps is even greater than anyone can imagine. Some of the companies doing DevOps include: Spotify, Google, Amazon, Bank of America, H&M, US Department of Homeland Security, Twitter, Gap (and a long list of others).
  • A survey of the room showed that it took most months, and even quarters, to deploy a change request. Did you know that an effective DevOps team can deploy a change request in days, and even hours?

Overall a thought-provoking presentation, and one that I very much enjoyed. Not being a total ‘techie’ I confess to never really, fully understanding the concept of DevOps before. Now thanks to Gene, I think I might even be able to confidently explain the benefits to others.

To learn more about the entire itSMF Norway conference please read: The itSMF Norway Conference: it’s the one that I want!

The itSMF Norway conference – it’s the one that I want!

DSC_0022
itSMF Norway Conference

Last week I had a last minute opportunity to attend the itSMF Norway conference in Oslo, and I have to say the stress of booking a flight, packing a bag and leaving my house within the space of an hour was completely 100% worth it. This was easily one of the best ITSM events that I’ve ever attended, both in terms of quality of content and overall experience, and one that I would highly recommend to others.

It’s also worth noting that I say this without really experiencing the entire event, as there was many sessions in Norwegian that I couldn’t attend (my Norwegian is a little rusty you see) all of which received great praise from the more local attendees. I was particularly sad that I couldn’t attend the session by Henrik Aase as it was literally all anybody was talking about throughout day one. However, the good news is that we are going to work with itSMF Norway to get some of the Norwegian sessions written in English as ITSM Review articles.

I couldn’t pass up on the opportunity to share some of the key takeaways, advice and tips coming out from the event, and so I hereby present to you my summary of some of the sessions that I attended along with general thoughts about the conference.

The conference key messages

Bearing in mind that I didn’t attend all of the sessions (my takeaways may differ to other attendees. However, from the sessions that I attended and my conversations with other delegates I found three key reoccurring messages:

  • We can’t keep ignoring DevOps. The benefits are too great to miss out on
  • Be honest in everything that we do, both with ourselves and with our customers
  • We must work on continual service improvement to maintain success

Interestingly, ITIL barely came up in any of the presentations that I attended, nor was I party to any conversations (bar a quick catch up with AXELOS) discussing ITIL. I know it was discussed during the “future of IT service management” panel at the end of day two, but by that time I’d left for the airport and so I only picked it up on Twitter. I found this particularly refreshing, I can’t remember the last time I didn’t get stuck in a conversation going round and round in circles on the topic of ITIL. In fact, I heard ‘COBIT’ mentioned more often than ‘ITIL’. Perhaps this says something about Norway’s adoption of the best practice framework (but I guess not given that the conference tagline was “ITIL – tell me more, tell me more”), or perhaps I just don’t understand ITIL in Norwegian (although I still question that I understand it in English).

However, a topic that did come up on a number of occasions was one that I’d not personally heard being discussed in a long time. Project and portfolio management (PPM) seemed to be a key focus for many of the delegates that I spoke with, with their primary reason being that it helps them make faster and better business decisions.  Again, this could speak more about the country than a new trend, but when I spoke with some of the international delegates they seemed to be in agreement of its new found importance.

Other messages

To avoid this particular article becoming incredibly long, over the course of this week I will publish supplementary articles of the key takeaways and advice from the following sessions:

We have also invited speakers to write articles based on their presentations, which we hope to publish over the coming weeks.

The conference itself

I could easily write paragraph after paragraph about just how good the itSMF Norway conference was, but for everyone’s sake I will try and summarize my thoughts in bullet points:

  • The content overall (granted I can’t really speak for the Norwegian sessions, but talk amongst the delegates leads me to believe that my assessment is fair) was far superior to anything that I have seen at any other ITSM event
  • The atmosphere was much nicer than at any other event I have ever attended. It was relaxed, laid back and fun – there were no stressed out organizers either, they enjoyed every second of the conference just as much as any other delegate
  • The theme was brilliant (although I don’t know how many more days I can take of continuously having “Summer Nights” stuck in my head) and was consistent throughout the event, from the sessions to the entertainment to the roaming hotdog vendors dressed in full 50s attire.
  • The organizers were wonderful, in control and most importantly ­– happy! P.S. Thanks for extending the services of your 50s hair and make up artist to me!
  • The food was yummy (this is huge praise from me, I never touch the food at conferences) – many will tell me this is irrelevant, but it’s all part of the event experience as far as I am concerned
  • The entertainment was fantastic (although there were a few groans from some who could understand the Norwegian “dinner entertainer” – i.e. not me – that he wasn’t on par with the standard of previous years).  Who knew that dancing to Grease tunes with Tobias Nyberg, Kaimar Karu, Dagfinn Krog, Andrea Kis, Rae Ann Bruno and a bunch of Norwegian people that I don’t know could be so much fun?

My only criticism of the event, which I (and others) have already shared with the organizers, and I am already 100% confident will be fixed for next year, was that for those of us who couldn’t understand Norwegian there were often long periods of time when we were left with no English content (two hours and 15 minutes each day to be exact). Whilst, I wouldn’t expect a Norwegian conference to be delivered 100% in English, as itSMF Norway has become a victim of it’s own success with more international attendees each year (I met with delegates from Finland, UK, USA, Italy, and Germany just to name a few), it would be nice to find a way to ensure that we could still benefit from the Norwegian sessions.

This conference easily has the scope to become one of the biggest itSMF events in Europe. It’s inexpensive to attend compared to other ITSM events (even with flights from long haul destinations) and the quality is of an exceptional standard. To be honest, even with the gaps for non-native speakers I will still be recommending this conference to everyone that I speak to.

If you want to learn, pick up practical advice, meet amazing people, and all whilst having a huge amount of fun then make sure you get your tickets booked to next year’s itSMF Norway conference. I know for a fact there is no way that I intend to miss it.

Trust me: The DevOps Movement fits perfectly with ITSM

Gene Kim
Gene Kim

This article has been contributed by Gene Kim, Author of the book “The Phoenix Project: A Novel About IT, DevOps, and Helping Your Business Win”.

In my thirteen year journey of studying high performing IT organizations, I’ve started to see a new and unsettling trend.  Whenever I mention ITIL and IT Service Management in presentations and briefings, people in the audience snicker. When I ask why, they roll their eyes, and talk about the shrill, hysterical bureaucrats that suck life out of everyone they touch, doing everything they can to slow the business down, preventing everyone from getting work done.

This is simply not true. In fact, every time I’ll argue that ITSM skill sets are ever more important in a world where there is an ever quickening business tempo.

However, an even more troubling trend is that ITSM practitioners will dismiss emerging movements such as “DevOps,” suggesting that it’s a passing fad.

It is my genuine belief that that patterns and processes that emerge from DevOps are the inevitable outcome of applying Lean principles to the IT value stream.  It is an inexorable force that will likely change IT in a manner we haven’t seen since the birth of client-server computing in the 1980s.

More importantly though, ITSM practitioners are uniquely equipped to help in DevOps initiatives, and create value for the business.

The DevOps Movement fits perfectly with ITSM. My goal is to help you become conversant with DevOps and aid you in recognizing the practices when you see them. I hope this article will illustrate how information practitioners can contribute to this exciting organizational journey.

What Is DevOps?

The term “DevOps” typically refers to the emerging professional movement that advocates a collaborative working relationship between Development and IT Operations, resulting in the fast flow of planned work (i.e. high deploy rates), while simultaneously increasing the reliability, stability, resilience and security of the production environment.

Why is it that Development and IT Operations are singled out?  Because that is typically the value stream that is between the business (where requirements are defined) and the customer (where value is delivered).

The origins of the DevOps movement is commonly placed around 2009, as the convergence of numerous adjacent and mutually reinforcing movements, most notably the  “10 Deploys A Day” presentation given by John Allspaw and Paul Hammond and the Agile system administration movement (Patrick DeBois).

Currently, DevOps is more like a philosophical movement, and does not yet have a precise collection of practices, descriptive or prescriptive (e.g. CMM-I, ITIL, etc.).  On the other hand, it is an incredibly vibrant community of practitioners who are interested in replicating the performance outcomes and culture described so vividly by organizations such as Etsy, Amazon, Netflix, Joyent and so forth.

DevOps aims to address a core, chronic conflict that exists in almost every IT organization.  It is so powerful that it practically pre-ordains horrible outcomes, if not abject failure. The problem? The VP of Development is typically measured by feature time to market, which motivates as many changes, as quickly as possible.  On the other hand, the VP of IT Operations is typically measured by uptime and availability.

Until very recently, it was impossible to get both desired outcomes of fast time to market and sufficient reliability and stability.  Because of these diametrically opposed outcomes (“make changes quickly” vs. “make changes very carefully”), Development and IT Operations were in a state of constant inter-tribal warfare, with ITSM practitioners put right in the middle.

Although many people view DevOps as backlash to ITIL (IT Infrastructure Library) or ITSM, I take a different view.  ITIL and ITSM still are best codifications of the business processes that underpin IT Operations, and actually describe many of the capabilities needed into order for IT Operations to support a DevOps-style work stream.

I am part of a team who wrote “The Phoenix Project: A Novel About IT, DevOps, and Helping Your Business Win”, which codifies the “good to great” transformation we’ve observed these organizations making.  Our goal is to create a prescriptive guide that shows how Development, IT Operations and ITSM practitioners can work together to create phenomenal organizational outcomes that none of them could achieve alone.

What are the unpinning principles of DevOps?

In “The Phoenix Project: A Novel About IT, DevOps, and Helping Your Business Win” we describe the underpinning principles in which all the DevOps patterns can be derived from as “The Three Ways.”  They describe the values and philosophies that frame the processes, procedures, practices, as well as the prescriptive steps.

image 1

The First Way emphasizes the performance of the entire system, as opposed to the performance of a specific silo of work or department — this as can be as large a division (e.g., Development or IT Operations) or as small as an individual contributor (e.g., a developer, system administrator).

The focus is on all business value streams that are enabled by IT.  In other words, it begins when requirements are identified (e.g., by the business or IT), are built in Development, and then transitioned into IT Operations, where the value is then delivered to the customer as a form of a service.

The outcomes of putting the First Way into practice include never passing a known defect to downstream work centers, never allowing local optimization to create global degradation, always seeking to increase flow, and always seeking to achieve profound understanding of the system (as per Deming).

image2

The Second Way is about creating the right to left feedback loops.  The goal of almost any process improvement initiative is to shorten and amplify feedback loops so necessary corrections can be continually made.

The outcomes of the Second Way include understanding and responding to all customers, internal and external, shortening and amplifying all feedback loops, and embedding knowledge where we need it.

image3

The Third Way is about creating a culture that fosters at two things:  continual experimentation, which requires taking risks and learning from success and failure; and understanding that repetition and practice is the prerequisite to mastery.

We need both of these equally.  Experimentation and risk taking are what ensure that we keep pushing to improve, even if it means going deeper into the danger zone than we’ve ever gone.  And we need mastery of the skills that can help us retreat out of the danger zone when we’ve gone too far.

The outcomes of the Third Way include allocating time for the improvement of daily work, creating rituals that reward the team for taking risks, and introducing faults into the system to increase resilience.

What Are The Areas Of DevOps?

We divide up the DevOps patterns into four areas:

area1

Area 1: Extend Development into IT Operations:

In this area, we create or extend the continuous integration and release processes from Development into IT Operations, integrating QA and infosec into the work stream, ensuring production readiness of the code and environment, and so forth.  The steps include:

  • Create the single “repository of truth” containing both the code and environments
  • Create the one-step Dev, Test and Production environment build process
  • Extend the deployment pipeline processes into production
  • Define roles and integrate QA, Infosec, Ops/CAB into Dev workstream

First,  we put everything needed to rebuild the service into a common repository from scratch, including both the application and the environment (i.e., operating system, databases, virtualization, and all associated configuration settings).

Next, we will make a one-step environment creation process available at the earliest stages of the Development project.  By using a common build process and requiring that Development be responsible for ensuring that the code and the environment work together, we’ll have an unprecedented level of production ready, even at the earliest stages of the development project.

This impacts the ITSM process areas of release, change, and configuration management.  The ways that ITSM practitioners can actively integrate into the DevOps value stream includes the following:

  • Find the automated infrastructure project (e.g., puppet, chef) that provisions servers for deployment.  We can help that team with our release management readiness checklists, security hardening checklists and so forth, integrating them into the automated build process.
  • Define pre-authorized changes and deployments, and ensure that production promotions are captured in a trusted system of record that can be reviewed and audited.
  • Define changes and deployments that require authorization, such as security functionality that is relied upon to secure systems and data (e.g., user authentication modules).  The goal is to ensure that changes that could jeopardize the organization (e.g., the infamous 2011 Dropbox failure where customers discovered that authentication was disabled for four hours) never occur.

Area 2: Create IT Operations feedback into Development

The steps in this area ensure that information from IT Operations is radiated to Development and the rest of the organization.  IT Operations is where value is created, and this feedback is required in order to make good decisions.

The specific steps in this area include:

  • Make all infrastructure data visible
  • Make all application data visible
  • Modify the incident resolution process and blameless post-mortems
  • Monitor the health of the deployment pipelines

The first step overlaps with the ITSM process areas of event management, while the second step requires creating the monitoring infrastructure so that there’s no excuse for developers not to add telemetry to their application (e.g., “since it only requires one line of code, even the laziest developer will instrument their code”).

The third step then enables IT Operations and Development to resolve incidents quickly, by ensuring that all relevant information from the entire application stack is at hand to determine what might have caused the incident, and then to restore service.

ITSM practitioners can help by ensuring that the process areas of event management, as well as incident, problem and knowledge management are modified to incorporate Development.

Area 3: Embed Development into IT Operations

According to the Second Way, the goal of steps in this area is to create knowledge and capabilities where we it is needed, and shorten and amplify feedback loops.  A delightful quote that frames this comes from Patrick Lightbody, CEO, BrowserMob.  He said, “We found that when we woke up developers at 2am, defects got fixed faster than ever.”

To facilitate creating tribal knowledge within IT Operations and shared accountability for uptime and availability with Development, the steps in this area include:

  • Make Dev initially responsible for their own services
  • Return problematic services back to Dev
  • Integrate Dev into the incident management processes
  • Have Dev cross-train Ops

Area 4: Embed IT Operations into Development

This area is the reciprocal of Area 3, and the goal is to create the service design and delivery equivalent of designing for manufacturing (DFM).  In plant engineering, DFM recognizes that the primary customer of engineering is the manufacturing personnel, and therefore one of the engineering goals is to parts are designed for easy assembly, minimizing the likelihood of putting on parts on backwards, over-tightening, being damaged during transit or assembly, and so forth.

Similarly, in addition to ensuring that IT Operations needs are integrated into the daily Development processes of design, requirements specification, development and testing, the product and processes are designed with resiliency in mind.

The steps in this area include:

  • Embed Ops knowledge and capabilities into Dev
  • Design for IT Operations
  • Institutionalize IT Operations knowledge
  • Break things early and often

This includes embedding or liaising IT Operations resources into Development, creating reusable user stories for the IT Operations staff (including deployment, management of the code in production, etc.), and defining the non-functional requirements that can be used across all projects.

Conclusion

It is my firm belief that ITSM and the DevOps movement are not at odds. Quite to the contrary, they’re a perfect cultural match. As DevOps gains momentum I’m excited by what we can achieve using a winning combination of the two. It is my sincere hope that by reading this article, you’ll better understand what DevOps is, see why it is important and be energized by the possibilities it creates, and generate some ideas of how to put some of these practices into place in the IT organizations you help support.

You can hear more from Gene on this topic at the itSMF Norway conference taking place in Oslo, 12-13 March.

 

Pink14 Preview: The Phoenix Project

3
IT needs to embrace the “3 Ways”

Ahead of his presentation at the 18th Pink Elephant Conference and Exhibition (PINK14)Jack Probst, Principal Consultant at Pink Elephant talks about The Phoenix Project: a novel about IT, DevOps and helping your business win

In May 2003, Nicholas Carr wrote a Harvard Business Review article entitled “IT Doesn’t Matter”. In it Mr. Carr proposed that IT was, and remember this was just after the dot.com bust, being marginalized and could be thought of as a commodity.

Seems that thinking hasn’t changed much in the past 10 or so years. IT is challenged daily to just keep the lights on, at best, and, if all goes well, maybe try to keep up with the needs of the business much less get ahead of the game.

For those of us who are immersed in IT Service Management, that thought, at times, is a bitter pill to swallow. It is true to that the table stakes for IT is to maintain and manage operational stability but there is more to a day, week or month in the life of IT than KTLO. If we truly embrace the notion of a service – “delivering value by facilitating customer outcomes” – then staying abreast of or anticipating and preparing for the future of the business is or should be the IT mantra. The question is can IT do both? 

Gene Kim, Kevin Behr and George Spafford recently published The Phoenix Project. Their book develops a landscape of principles and practices that attempt to answer that question. The book, written as an allegory, focuses on the trials and tribulations of Bill Palmer, recently named VP of IT Operations at Parts Unlimited Inc.. From day one on the job Bill is challenged to first stabilize operations AND deliver on a mission critical project – a project that could spell disaster if it fails. As the story unfolds the authors highlight ideas that should be on every IT managers improvement opportunities list. I would think everyone would like to get a peek at practical advice for how to deal with:

  • Demanding business leadership
  • Major incidents
  • Uncontrolled changes
  • Failed deployments
  • Security/audit issues
  • Overwhelming project list

At PINK14

At the upcoming Pink Elephant IT Service Management Conference, I will be presenting Sunday afternoon and again Wednesday morning some of my insights from the book.

There are many great discussion topics interlaced throughout the story. My focus during the session will be laser in on the results of when Bill reluctantly falls under the guidance and tutelage of Eric Reid, a candidate for the Board of Directors. Eric leads Bill through a set of hands on exercises to learn some key principles instrumental to elevating IT’s overall performance. Of the many insights, Eric continues to hammer home the need to focus on Bill finding ways for IT embrace the “3 Ways”.

  • First Way – Create a fast flow of works as it moves from Development into Operations”
  • Second Way – Shorten and amplify feedback loops to fix quality at the source and avoid rework
  • Third Way – Create a culture that simultaneously fosters experimentation, learning from failure and understanding that repetition and practice are prerequisites to mastery.

So why read The Phoenix Project

I have been recommending to my Pink Elephant clients to pick up a copy of the book and add it to their nightstand reading. Several reasons for this:

  • I’m sure you will find yourself at some point seeing your own situation through Bill’s eyes. I found the experience of reflection on the challenges Bill was having and some “ah-ha” solutions the authors brought forward would highly instructive, especially as conversation starters for ITSM teams at various stages of their program.
  • Many of the ideas that are being kicked around today in the blog-o-sphere and water cooler talk are fleshed out in a practical setting. Granted the circumstances don’t exactly match what my clients are dealing with but it isn’t a huge leap to find resonance with how the practices can be incorporated in their own ITSM program.
  • Lastly, it is a story after-all. One that we have all lived through to some extent. An entertaining read and, as one side note, there is some visceral pleasure in seeing the antagonist getting her comeuppance.

Why attend my session?

My focus for this session was to distill the many points and concepts that Bill and his team use to solve their challenges into a pragmatic approach for your ITSM program.

During my sessions I will dig deeper in to each of the three ways. For instance the in the First Way we will learn how IT must understand the 4 types of IT work and how that work is managed through what I call “the Funnel and the Pipe” or the IT Value Stream. In the Second Way we will talk about the “Tyranny of Technical Debt”, its sources and potential ways to avoid it. And finally my discussion of the Third Way will encompass Improvement Katas and DevOps.

I hope that you will add one of my sessions to your Conference Optimizer. If we don’t get a chance to connect during my workshops, then look for during the networking events each night.

This will be the best Pink Elephant Conference yet! I look forward to meeting you in Vegas – see you there.


Jack Probst
Jack Probst

To learn more find Jack at PINK14:

Image Credit