Transforming IT

The 4 1/2 Things You Must Do To Affect Change

I recently posted a column at ITSM Portal entitled, "The 4 1/2 Things You Must Do To Affect Change."  Here is an excerpt:

Why is it so hard to make changes stick in your organization? You go through the process of identifying inefficiencies or areas that will create a significant improvement in the delivery of services, you figure out a better way of getting things done - and then splat. People go to the training, they nod knowingly and they start trying to implement your better mousetrap. But inevitably, they slowly revert back to the old ways of doing things. Particularly in large IT organizations, making change stick may be one of the toughest challenges you must deal with if you truly want to have an impact and create lasting change.

WHY YOU NEED AN ADOPTION STRATEGY
The problem is that it is human nature to resist change. Most of us prefer the pain of what we know to the fear of what we don't. The barriers to change are extensive and well rooted. So if you want to affect change in your organization you need more than a better way of doing things - you need an adoption strategy that will make that change stick.  Read More

Running IT as a Business Doesn't Mean It's a Separate Business

There always seems to be a lot of controversy over the concept of running IT as a business.  There has been a recent backlash over whether or not it's a smart strategy and there has been a long running industry discussion over what it really means to run IT as a business.  I think that the biggest problem is that most IT folks aren't actually business folks, so they say the words, but don't really know what it means or how to make it real.

But the recent dust-up has really been about the idea that running IT as a business is the wrong strategy in that it creates separation between IT and the business.  This was all brought to mind as I read a recent article from Information Week entitled, "Global CIO: What's IT Worth?" 

The article and Northwestern Mutual Life's story of IT transformation really had two key messages:

• Words Matter - How you describe your IT organization and the services you provide/activities you perform are the tip of the spear as you try to transform your organization.  Where your words lead, your organization will follow if you make them real.
• IT Assets Have Business Value - and should be measured as such

The article has a lot of good ideas and information on measuring IT value, but the thing that struck me the most was Tim Schaefer's (the CIO of Northwestern Mutual Life) focus on changing the language to remove the perceived barriers between IT and the business.  A lot of the targeted terms will be very familiar to those of us who are proponents of "running IT as a business" - internal customers, IT leaders, alignment, etc.

I understand why this is - words used improperly can create divides between people.  His focus on the words was a statement that he was demanding intimacy and partnership between the IT organization and the business - to integrate IT into the business itself.  And I can see where on the surface this seems like a repudiation of the whole "running IT as a business" mantra.  But I don't think it is.

The issue is that "running IT as a business" was never meant to be a literal construct.  It is meant to create a "service attitude" within the IT organization to combat the greatest ill that most IT organizations have - that they focus on the technology rather than on the business value that the technology provides.  The intent - at least to me - was never to create this little stand alone business within a business with all of the separation that seems to imply.  Instead, the model should be the one that the greatest businesses in the world follow - the creation of such intimacy, that they become an integral part of their customer's business.  I believe that this gets to the same place that Northwestern Mutual Life is going. 

In the end, maybe "running IT as a business" has a limit to its useful life.  I think that it's a critical metaphor and place to start as you begin the process of transforming your IT organization to think in terms of services and consumers of services and the derived value of those services.  But perhaps the metaphor begins to break down as the service context matures and leaves a residual of separation from the business as people take it too literally.  Then maybe, the next evolution is to one of true intimacy with the business to finally make IT and the business one.  Could be.

If Capabilities are So Important, Why Don't You Build Them?

A new survey by McKinsey (you'll need to register for a free account to view it) reports that 60% of companies state that building organizational capabilities is one of their top 3 priorities.  Yet only a third of them have a specific and deliberate effort in place to actually build them.  Huh?

While this report is speaking to overall organizational capabilities, the same surely applies to the IT organizations of these same companies.  We see it all too often - there is always a lot of smoke, but little fire.

I get that building organizational capabilities is a lot harder to do in practice than it sounds.  But it should be clear that the first step to getting something done is to put forth a deliberate plan to do it.  Yet, we routinely run into IT organizations that have the speech down pat, but are not doing anything real to develop capabilities in a meaningful way - with the possible exception of technology capabilities.

We believe that there are largely six major capabilities that an IT organization should be concerned with (in line with ITIL v3):

• Management
• Organization
• People
• Process
• Knowledge
• Technology

Of these six, five of them are fundamentally about people - how you measure them, organize them, train them, enable collaboration between them, etc..  Yet most organizations invest very little in developing these capabilities.  The question is why?  I'm not sure that I know the answer (except maybe that it's a lot easier to buy a tool than it is to tackle some of these), but I know that if IT leaders are serious about building organizational capabilities, then they will need to make sure that there's some fire beneath all of that smoke.

The Folly of Organizing Around ITIL

The IT Skeptic posted over the weekend about his review of the book Building an ITIL-based Service Management Department and it reminded me of what a pet peeve of mine this is.

I haven't read the book, but I completely agree with both the Skeptic and Hank Marquis in terms of the purpose of service management processes.  They are supposed to transcend the organizational structure - not become them.  It annoys me to no end when I see organizations try to turn Service Management process areas into just another functional area.

My biggest problem with this approach is that it destroys the foundation of Service Management - namely, that it's everyone's problem (or opportunity, if you prefer).  Once you begin structuring the organization around process areas, well then clearly the only people that need to worry about Incident Management is the Incident Management team and so forth.

Why would anyone think this makes sense?  Maybe it's just that the concept of a process that actually transcends organizational and political boundaries is too off-the-wall to be real for some people.  I don't know, but I wish they'd stop wasting their time trying to make ITSM processes something that they're not and simply build them to do the job they're intended for.  Just my humble opinion.

How Will the New Normal Affect IT?

In an article today by Thomas Wailgum on CIO.com entitled, "Why the New Normal Could Kill IT," he posits that the recent financial crisis has fundamentally altered the business's view of IT and is leading to significant changes within the way IT operates.  Sounds a lot like our view of IT Transformation.

Here is a link to the article: http://www.cio.com/article/575563/Why_the_New_Normal_Could_Kill_IT

I posted a comment and thought that I'd repost it here:

First off, I thought this was a great, thought-provoking article. The core concepts - the changes that are required - may be nothing that new. But I believe the understanding that there is a fundamental shift taking place that is leading to the transformation of IT - whether by choice or by force - is the real point of the story.

While I agree that any successful IT organization must operate as a partnership with the business, I found some of the virulent response to this article both comical and part of the foundational problem.

"the huge ERP systems, the inability to react precisely and quickly, are due to the business LETTING them happen."

Really? The business should have somehow just taken over IT and stopped them from hurting themselves? Then why have an IT team at all?

The truth of the matter is that IT has lived behind this opaque wall of whiz bangs and mysterious blinking lights for decades. For a lot of folks, that's just the way they like it. And even in situations where the CIO or the leadership team gets it and truly engages in business-based dialogue, their minions don't and continue to undermine the relationship by hiding in their comfort zones of technical architectures and SDLCs.

I think that the issue is less about CIOs needing to change - I think that most CIOs actually get this now - but that CIOs need to start putting in the serious effort required to reshape their IT organizations from the ground up. They need to create customer-focused, service-centric organizations that are able to engage the business in partnership and dialogue at all levels of the organization. Once that happens, I believe that IT will find that it can operate very effectively in the "new normal."