By now, the story should be starting to be more familiar.
The business needs more from the IT function, but IT can't easily deliver. Inevitably, business leaders start searching outside of IT to get the flexible and easy-to-consume services they need.
I T leadership suddenly realizes that they're now being forced to compete for internal business , and IT isn't a monopoly any more.
Fail to compete successfully for your internal IT customers, and the future is not bright.
And so begins the uncomfortable process of IT groups transforming to look more like modern IT service providers, and less like the inwardly focused, siloed IT departments of yesteryear.
What started a few years ago as just a modest handful of customer examples quickly expanded to dozens, then hundreds and now many thousands.
Personally, I think this has created a great opportunity for IT leaders to learn from each other as they each embark on their own transformational initiatives.
But -- as with most things -- you tend to see patterns: where things work, and -- sometimes more importantly -- where things tend to bog down.
So, allow me to share my personal list of sand traps where IT leaders occasionally get stuck.
Why? Because knowing where the problems might lie is often half the battle ...
#1 -- Not Realizing The Game Has Fundamentally Changed
Nobody likes disruptive change. Indeed, we as human beings have a strong ability to see things as we would like them to be vs. how they might really be.
Myself included :)
We rationalize. We position. We justify. Sometimes, we just make excuses.
All of that normal human behavior tends to delay the stark reality: there's a massive task at hand, so let's get started.
For example, some IT leaders will tell me that they've implemented new processes over the existing environment and organization to improve a few key indicators (such as time-to-provision, or perhaps utilization) in an attempt to move the needle by what they believe to be a big number -- say, 10 or 15% over some historical baseline.
Alternatively, someone might say that they've established new procurement enforcement procedures to keep those pesky users from sourcing around the enterprise IT group -- and now the problem is under control.
Or, occasionally, they'll attempt to gift-wrap the legacy IT function with a set of internal communications that paint glowing pictures of just how good the internal IT group is.
To my way of thinking, these are all symptoms of a clear underlying root cause: the relationship between the business and IT is fundamentally changing, and no incremental measures are likely close the widening gap.
For me, it's pretty clear. It's gut check time: the IT game is fundamentally changing.
And as an IT leader, you've got a tough decision to make -- are you in, or are you out?
#2 -- Making It About Technology
This one is very understandable -- many of us are technologists, so we tend to frame most problems and solutions in technological terms.
I am less-than-popular within various product groups at EMC because I steadfastly refuse to frame IT transformation and learning to compete as a "technology challenge".
IT transformation is an organizational challenge -- nothing more, and nothing less.
Sure, you'll need modern tools to get the job done. And I believe there are unwise technology choices that can make the task at hand much harder than it needs to be. And, of course, I believe that EMC makes great stuff to support these environments.
But the conversations doesn't start (or end) there. We must exit the familiar world of product feature/function, and enter the squishy and uncomfortable world of people and politics.
IT professionals -- in general -- are hired for their technology and process skills, and not necessarily their people or political skills. The natural tendency (for some) is thus to steer the conversation back to familiar territory, e.g. what are the "right" technologies?
Trust me: without organizational context, an isolated technology debate is an unproductive diversion.
I've shared this slide before, but it illustrates the point well.
At one of our IT Leadership Forums last year, we asked the senior audience where they saw the challenges going forward.
Not one of them picked "technology". Zero, zilch, nada.
Think about that when you see the cloud pundits passionately arguing about various technologies back and forth on the interwebs.
Sheesh.
#3 -- Overwhelmed By The Legacy
This one is also very understandable. About 30 minutes into the ITaaS discussion, many IT leaders look around their shop and see the end result 20 years of IT decisions that now look somewhat questionable in the light of the new day.
Legacy applications. Legacy infrastructure. Legacy IT processes. Legacy business processes. Legacy funding models. Legacy skill sets, roles and organizational models.
Where to start? Can we ever get there? And how will be bring all this stuff forward?
Taken in aggregate, it all can be intellectually and emotionally overwhelming.
The most productive answer -- as it turns out -- is to create a small pocket where you do things the new way vs. the old way.
Give the new team a few interesting (and non-critical) use cases to cut their teeth on, like development and test, or perhaps self-service analytics. Prove that the model can work -- for both IT and the people who consume it.
As the new way of doing things quickly matures and gains traction, more new projects will find their way to the new environment vs. the old one. Over the course of time, there ends up
being a lot less legacy to deal with.
And then you can make informed decisions around what stuff needs to be brought forward vs. simply retired in place.
#4 -- New Mission, New Leadership Style Required
When organizational situations are familiar and stable, you need a familiar flavor of manager -- one who's comfortable process, measurement and predictable results. A very useful and important mangerial style when it's business-as-usual.
However, when you're trying to drive accelerated change in a decent-sized IT organization, a very different leadership profile is needed.
You need leaders who inspire and motivate people to do things differently and take a few risks. You need someone who can figure stuff out as they go along while believing in the bigger mission.
There aren't many people out there who are adept at both styles. To make matters even more sticky, you're sill going to need those critical operational skills to keep the lights on at the same time you're working on building out your new model.
The farther you are along in your career, the more difficult it can be to adapt and evolve your leadership style.
But that's exactly what needs to be done -- and not everyone is up to this challenge.
#5 -- Trying To Implement Entirely New Functions With Existing People
When you look at the business model of any IT service provider (or any IT organization that is competing like one), you'll find newer functions where there usually isn't anyone inside of the current IT organization who has any relevant background.
One classic example is the go-to-market function. Ask yourself: how many people with good marketing and sales DNA end up in an enterprise IT organization?
Answer: usually none.
So the tough part is to acknowledge that (a) you're going to need the function, (b) you don't have any internal candidates, and (c) better figure out where you're going to get a few of these critical skills.
Another classic example is IT finance: the ability to model and price variable IT services takes a whole lot more firepower than simply negotiating with vendors and allocating traditional IT costs.
And yet another classic example is "product management": the function that manages the portfolio of IT services -- what do people want, how is it justified, how is it introduced, how is it measured, etc. Anyone who's worked for a product or services company is familiar with the function, but -- once again -- you don't find it in many IT shops.
If you're a successful IT service provider, you have all of the above functions, and more. If you're an enterprise IT organization who wants to compete with IT service providers, you're going to need the exact same functions.
The bad news? Very often IT leaders attempt to use existing internal IT candidates, often with poor results all around.
The good news? These skills aren't really that hard to find -- that is, if you look outside of traditional IT settings.
#6 -- Backing Away From The Finance Challenge
It's a simple truism: how IT is paid for will dictate how IT is built.
If your funding model is per-project, IT will end up being an interesting collection of projects.
If your funding model is IT as a corporate cost center, you'll be the perpetual organ donor for every round of budget cutting that comes along.
But if you make IT "pay its way" by delivering attractive IT services that internal customers prefer to consume, you get the privilege to grow and invest in your business much the same as any other business owner.
If you think transitioning an IT organization is hard work, wait until you sit down with a bunch of finance guys and start to argue that the IT funding model needs to change.
Fortunately, we cracked that code internally here with EMC IT, and we've seen several of our customers do the same.
The natural inclination, though, is to avoid the discussion for as long as humanly possible :)
#7 -- Not Thinking Like An Entrepreneur
If you were starting up a new IT services business, you'd probably pick out a few big clients, and try to build something they'd like.
You wouldn't make the fatal mistake that people would want to automatically consume exactly what you had built. And you wouldn't try and please everyone from the outset.
Well, if you think of IT transformation as an "intrepreneurial startup", you'd probably want to do the same thing -- find a few internal stakeholders who are willing to work with you,
and build something they'd like to consume -- but do it as the starting point for a broader set of capabilities, and not an end unto itself.
Everyone else can continue to use the legacy environment and processes -- for a while, until you expand and grow your capabilities.
The trap I see people falling into is thinking that somehow the CFO is your "internal customer".
A better way to think of it is that the CFO is your VC firm :)
#8 -- Not Investing Over-Communicating
Any senior exec that's been through any major organizational or strategic transformation -- of any sort -- will say the same thing: you spend most of your time communicating and overcommunicating.
Since most IT professionals weren't exactly hired for their communication skills, IT leaders involved in transformation often have to suck it up and get on the internal speaking circuit -- and do so for quite a while, both internal to IT and especially externally.
Sure, there's a role for written communications: memos, newsletters, powerpoint decks and the like.
But a wise man once told me that meaningful communication can only happen when two people are face-to-face.
Yes, it's a big investment in time. But there doesn't seem to be any shortcut.
#9 -- Not Planning For Inevitable Mistakes
Yes, when dealing with critical IT systems, there's a strong incentive to plan, schedule and double-check everything to plan for each and every eventuality. That doesn't become any less important.
But when starting on an ITaaS initiative, you're essentially investing in learning a new way of doing things. That means that you'll never get it 100% right from the outset, nor should you attempt to.
The implication?
Work your strategy, schedules and plans so that people have the slack to make a few mistakes. Make sure the new team knows it's OK to get a few things wrong as the learning progresses.
I've seen more than a few nascent ITaaS transformation initiatives completely sstrangled by this "we're running this like a military operation" mindset. That's hard on everyone involved, and -- besides -- you're encouraging people to take a few risks.
Give your teams the room to learn, adapt, grow and mature.
#10 -- Not Celebrating Progress
If you've ever climbed a modest mountain, it's very rewarding to stop every so often, and look back at just how far you've come. Doing so can give you that extra boost of motivation to tackle the next ascent.
I can't tell you how many IT groups I've met that have been able to achieve meaningful progress in relatively short time frames, but don't easily acknowledge just how much progress they've made under challenging circumstances.
Maybe I met them a year ago, and they were just getting started. And I see them a year later, and I'm duly impressed with their substantial progress.
But for some reason, they're usually not that impressed with their results.
I find that puzzling.
Yes, there's always more to do. I get that.
But at the same time, everyone deserves a hard-earned victory lap once in a while.
Even IT people :)
Why Bother?
I know it. You're reading this and thinking "why should I bother?".
It all sounds so -- well -- uncomfortable.
I'll tell you why: because there's a big pot of gold at the end of this rainbow. And I've seen more than a few IT groups get to it.
IT is now seen as a value generator by the business, as opposed to just another cost to be minimized.
IT professionals elevate their careers by getting closer to the business rather than deeper into technical minuteia.
The IT group is now perceived as a business within a business, with all of the benefits that brings.
The work doesn't stop there: progressive IT organizations are now building on their ITaaS capabilities to move into cool, really-move-the-needle IT topics: enabling big data analytics, mobilizing their user and customer experiences, building new app factories, -- ultimately helping to create "digital business models" that can power their businesses through the next few decades.
It isn't quick, and it isn't easy.
But for those that decide to undertake the journey, the rewards are clearly visible ...
This is a very interesting, well written and on-the-mark post. I can say this from direct & personal experience, one in which we produced considerable success by identifying & addressing the items you've highlighted here. Most of our IT groups didn't recognize how much things had really changed and were not producing critical results during the 2008 market turmoil. Only by fundamentally changing the model of cooperation between business & IT, taking risks with new processes and technologies, focusing on some related critical areas rather than boiling the ocean, working through organizational boundaries, building the right team with the right people including some new, financing it appropriately and over-communicating, did we clear the FUD and have what turned into foundational & transformative success. You have identified all the major hurdles in your article and I have also seen where these were not done leading to failures.
Posted by: Ken Carroll | February 28, 2012 at 03:08 PM