I want to tackle the thorny and often controversial topic of transforming IT capabilities – probably through several posts over the next few weeks.  I first started looking at how large companies went about transforming IT about 20 years ago.  I got very focused on it in a formal way about 16 years ago when I was leading a multi-year longitudinal study of 25 global corporations under the auspices of the Ernst & Young Center for Business Innovation.  This research led to the infamous Business-IT Maturity Model that I refer to from time to time on this blog (it has evolved substantially in the last 10 years), to a normative IT Process Landscape (which has also evolved somewhat over the years) and to a great deal of insight about IT transformations – things that seem to work well, and others that seem to fail consistently.  Finally, it led to a book, which was very satisfying to write, well regarded at the time, but is now somewhat too dated to try to hawk on this blog!

First, a couple of observations.  Defining transformational change can be somewhat tricky as it is inherently subjective.  We might believe, for example, that a change in a business analyst’s role to shift from a focus on a business area to a focus on an end-to-end business process (order-to-cash, say) is an incremental change, but to the analyst it might feel transformational.  Notwithstanding this subjectivity, I think of transformation as change that is:

  • Broad in scope (for example, encompassing change in processes, tools, organization structure, vision, mission, rewards and recognition)
  • Deep in nature (i.e., intended to lead to a significant change in organizational outcomes)
  • Far-reaching in impact (i.e., affecting a broad base of stakeholders)
  • Recognized to be risky in that the absolute details of the end state may be unclear or ambiguous at the outset

Further complicating the definition of transformation is that not all transformational change is labeled as such.  Sometimes the infamous “butterfly effect” leads to transformational change as a result of an intervention that looked on the surface to be purely incremental.  For similar reasons (the unpredictability of the behaviors of complex systems), not all programs labeled transformational actually result in transformation – in fact, the vast majority do not!  How many programs do you recall titled something like “Quality First,” or “One Company,” or “Journey to Innovation,” and so on that are now distant memories with little more to show for them than the printed tee shirts and embossed paper weights?

Why do IT organizations feel from time to time they need to transform?  Reasons, of course, vary but the typical rationales include:

  • A shift in business operating model – often from a holding company model with independent business units to a more integrated model, with common and shared capabilities.
  • A shift in underlying technology paradigm – for example, from mainframe to client-server (historically) or from client-server to Web 2.0 (currently).
  • A shift in sourcing model – for example, outsourcing major pieces of IT, and then transforming the “retained IT” organization for an increased focus on business value, growth and innovation.
  • A change in CIO where the new boss wants to shake things up and make her mark by driving IT performance to new heights.

Why do I feel that I need to post on this subject?  Because I’m tired of seeing the same transformational issues time and time again!  It seems to me we ought to be better at reinventing the role of the IT organization, delivering more value from costly IT investments, getting significantly closer to the businesses we serve, and being more sympathetic to the IT professionals who have heard it all before, want to keep their heads down until the latest transformation wave passes, or who just want to know, “What’s in this for me?”

I’m also tired of seeing so-called transformational change programs so badly bungled that the organization learns to ignore strategic change initiatives (the “this too shall pass” syndrome).  I’m tired of seeing so many IT leaders tackle transformational change as if they were the first ever to try it, and that there is nothing to be learned from all those who have gone before – especially learning from the failures, as well as from the success stories.  I often (with prior permission) put CIO’s in touch with clients I’ve worked with who have successfully transformed their IT capabilities – I do this in response to a request, but 8 out of 10 times discover that they don’t follow through!  The client who has been through the pain is more than willing to take their time to share their experiences, but the CIO who’s asking the questions does not even take the time to make to the call.

Also, I have to say that I come across many IT organizations that are frankly so out of touch with today’s business and technological realities that they need a major dose of transformation.  Week after week I talk to IT managers and leaders who have no idea what RSS, Wikis, and Cloud Computing are, and what their implications might be for the business they support.  The don’t know what an RSS reader is, or why they should want one.  They have never participated in a social network, and so have no opinions or ideas about how Web 2.0 capabilities might be turned to  business advantage.

So, let me suggest the first couple of transformation principles:

Principle #1. Communicate from the outset with absolute integrity and the unvarnished truth.

Your IT people are smart and will not be easily fooled.  In fact, trying to fool them will undoubtedly backfire.  So engage them in the dialog; be honest about what is going to be needed; don’t take anything “off the table” as sacred cows not to be discussed.  In most transformations, some people will not make it through – that’s a fact than cannot be hidden or avoided.  Make it clear to people that those that get engaged in the journey are more likely to come out as winners, but there’s no guarantees.  On the other hand, those that stand in the background lobbing stones will absolutely come out as losers!

Principle #2. Take the time and effort to collaboratively build a compelling but plausible vision for the future.

The temptation is to short-change this step – IT leaders already have the vision in their heads and assume everyone else in the organization “gets it.”  They don’t!   The next temptation is to develop the vision with a subset of the IT leadership team, and then emboss it in a paper weight or memorialize it on wall-sized posters.  After all the wordsmithing and polishing, the “vision statement” (which is not what I mean by “vision”) means nothing to anybody except the select few who created it.  Visions need to be rich and multi-faceted.  They need to be in peoples heads, hearts and stomachs.  They need to be compelling and to serve a higher purpose that gets people up in the morning and that merits putting themselves through the pain and anxiety of change.

Have you been through an organizational transformation?  Did it work?  Why?  If not, why not?  And please watch for more to come on this topic in subsequent posts.