A few years back, EMC's own IT organization embarked on a journey of fundamental transformation.
No longer content with incremental improvements, the decision was made to refashion themselves into an internal IT service provider, and leave behind the traditional enterprise IT construct.
The story of their transformation -- motivations, challenges, successes and lessons learned -- has provided extremely useful insight for many hundreds of EMC's customers and partners. Yes, every IT situation is different, but time and time again we've seen that there's plenty that can be learned from their efforts.
Recently, they published a very insightful whitepaper: "An IT-As-A-Service Handbook: Ten Key Steps On The Journey To ITaaS". I think it does a superlative job of outlining the crucial steps needed to get organized and start to make progress.
While no recipe is perfect, once again there's plenty to take away from their experience and perspectives. Once again, my thanks to the EMC IT team for investing the time in creating these documents.
Are You Ready?
But if you do fit the profile, at some point you're looking to get more formally organized around the transformation. You know how you're organized today. You probably have some ideas on how you'll be organized down the road somewhere.
But the key question remains: how do you organize to facilitate a transition between the two?
Maybe you've experimented with a few on-demand IT services. Maybe you even have two distinct styles of IT within your organization: old school and new school. But, at some point, you'll need to rally the troops, and make the substantial investments required to formalize the transition to an ITaaS model.
And that's what this discussion is about.
Define Vision, Goals and Objectives
Yes, so many strategic initiatives start with the "vision thing", it almost seems trite. Yet, based on experience, it's a very crucial step.
I meet with many, many customers around this topic. Within the first 3 minutes, I can tell whether they've done this first step -- or not.
If they have, their vision and focus is sharp and clear, almost tangible and certainly actionable. If they haven't yet put their thoughts together, the result is usually a fuzzy smorgasbord of nice-sounding phrases that don't really hang together.
It's easy for me to tell -- simply by listening -- that their collective thinking hasn't really jelled yet. Others can probably discern the same.
The end result should be what I call a "talking deck" -- a handful of slides, passionately delivered, that makes the case for change, and announces to all that a journey has begun.
Having seen many of these in the wild, they tend to follow a prescribed format. The "front matter" is basically the same: the world is changing, our business is changing, therefore we in IT have to change, followed by a set of call-outs contrasting how things are done today, and how they'll eventually be done tomorrow.
That core is then embellished with context unique to the particular industry, company situation, etc. Following that are typically three or more add-on modules directed at specific internal audiences: the IT staff, key business stakeholders -- and usually a few slides specifically aimed at the finance crew. Not everybody gets to see all the slides; it's somewhat audience-specific.
Since coming up with an effective "talking deck" isn't something that IT leaders routinely do, EMC Consulting has worked with IT leadership teams to help them come up with something that's both effective and personalized.
Using other people's slides to deliver your own message can only get you so far ...
Win Hearts And Minds
You've got your pitch, now you've got to take it on the speaking circuit. In many of the ITaaS stories I'm familiar with, there was a distinct phase where the IT leadership team was on the road: out in front of various audiences -- large and small -- delivering their pitch.
Feedback and responses often drive adjustments to the core talking deck as described above, so it tends to be an iterative process. You typically start with friendly, smaller audiences, and eventually move on to more challenging forums. The more you deliver the message, the better you get at it.
But there's more going on here than simply communication -- you're quietly on the lookout for early adopters, wherever they might be.
You're looking to create a tribe of people who understand what you're trying to do, and inherently want to support you as best they can. The cadre of internal and external supporters you develop along the way might not exactly map to the formal org chart at the outset, but that's to be expected.
We here at EMC do get involved with this activity frequently on behalf of our customers. We come in, share our stories, and drive an active level of discussion and engagement. Since the whole idea of ITaaS transformation can be quite controversial at the outset, we often act as a lightning rod to draw out all the different perspectives on the behalf of IT leadership.
After all, we don't work there.
Define Plan And Scope
Actually, I think this statement is inverted: define scope and then plan would be a better way of expressing things. The fundamental challenge here appears to be getting the scope right: not too much, and not too little.
Too much scope and all of the sudden you're trying to cure cancer, eliminate global warming and pay off the national deficit in one fell swoop. The sheer complexity becomes too daunting for most mere humans to grasp, and you stall out.
On the other end of spectrum, I've seen initiatives branded as "transformative" where it was pretty much a re-arranging of existing deck chairs. There were a few more meetings for people to go to, and perhaps some named initiatives with no dedicated resources, and that was about it. Predictably, these fail to initiate substantive change.
In between those two extremes is what I call the "alpha team" approach. Break off a small team of people who can play using a different set of rules. Give them some resources to go do something. Point them at one or two use cases that are interesting, but hardly mission critical. Make it their job to achieve results; don't simply add this task to the heap of other things they've been asked to do. Give them some time to gain experience and mature their processes. Allow them to make mistakes, and celebrate their successes.
Over time, their operational model becomes the blueprint for other efforts. New IT projects can either use the new model, or the existing one, depending on circumstances. Over time, more IT is done the new way, and less is done the old way. And the transformation progresses as a result.
Coming up with the right initial scope can be very difficult for some, especially if there are many loud voices at the table. EMC Consulting has on occasion done this work on behalf of some of our customers, using a lightweight methodology and bringing an external perspective.
It's there if you need it.
Acquire Resources
If everything in IT is fully allocated (people, infrastructure, etc.) there won't be any pool of resources to start doing things differently. Indeed, this seems to be one of the most formidable intellectual stumbling blocks when I speak with IT teams on this topic.
From their perspective, everything and everyone is already 110% consumed -- so how the heck are you going to start doing things differently?
The precise mechanisms of how this comes about varies considerably. Sometimes it's a formal, named (and funded!) project, e.g. Project Athena or similar. Sometimes IT groups shave a bit here and there to get the party going on their own and fly below the radar. Sometimes a big project comes along that looks like a candidate for ITaaS (e.g. VDI) and the work is piggybacked.
There's no standard or repeatable recipe that I've seen -- the precise mechanism falls to the leadership team to figure out.
What is repeatable is the notion of critical mass around the effort. I'm looking for at least 3-5 people at the outset where standing up the first services is their full-time job (not a hobby), and enough management protection that they don't get sucked back into the swamp of legacy processes and mindsets. If you can do more on the people side, so much the better.
This team is also going to need some infrastructure, but -- unless they've got a ready-to-go-cloud, they'll unfortunately be off the reservation for many months designing and assembling their own. If you can afford something like a Vblock or perhaps a VSPEX for the new team to get busy with, that's a win.
And I've got plenty of examples where the first new services were actually delivered using an external IT service provider in sort of a white-label arrangement.
At EMC, we can provide more than a few options on the infrastructure side, including a long list of enterprise-class IT service providers that can help. Additionally, we've occasionally augmented internal resource teams with a few outside resources during the outset through EMC Consulting.
Establish The Go-To-Market Team
Now you've got a modest factory that can provide a variable service. How do people find out about it? How do you morph the service into something people want to consume, as opposed to simply something that IT wants to build? That's where go-to-market comes in.
This important step is perhaps one of the most difficult in the journey for many. Traditional enterprise IT DNA isn't typically wired for marketing, sales and business development. Your challenge? You've got to build a small team of people that see themselves as essentially standing up a new "business" inside the company.
Marketing matters. User experiences matter. Having focus groups tell you what they need, and having them react to your prototypes matter. Figuring out what makes people consume one service and ignore another matters.
Communicating consistently across multiple channels matters as well.
The good part? These skills really aren't all that scarce -- that is, outside of a traditional enterprise IT setting. Chances are, you've got people in your broader organization who understand how this stuff works. Or you'll find no shortage of people outside your company who have the right mindset.
Regardless of where they come from, you're looking for one key thing: they're entirely focused on what people want to consume vs. what IT wants (or doesn't want) to produce.
Define Service Lifecycle And Governance
One common trap is that the service catalog is often thought of a static entity, chiseled in stone, with few changes over time. Unfortunately, it's precisely the opposite.
Think of the service catalog as the catalog to your retail store. Ideally, new stuff is going in, and unpopular stuff is coming out.
That implies a process that ascertains what new services might be wanted, establishing the business case for each, deciding how they're approved and funded, figuring out how they're introduced, then determining how they're measured -- and eventually retired.
Successful businesses are perpetually creating new stuff for their customers. That's one of the things that makes them a successful business. No surprise, successful ITaaS organizations have learned to do the same thing as well. And, of course, the process by which you do these activities itself has to be re-engineered and evolved over time.
Once again, we've got people in EMC Consulting who've done this sort of work, and -- at the very least -- can provide a variety of templates and examples to consider.
Define Service Taxonomy And Framework
Names can be important things, especially when creating new stuff. They're an important intellectual shorthand that code for powerful ideas and concepts. For example, what do you *really* mean when you say "infrastructure as a service"? Or "service portal"? Fail to pay attention to taxonomies and precise definitions, and it's highly likely everyone involved will end up thoroughly confused at the outset.
Behind those service names, though, there's real work to be done: provisioning and delivering the new service, as well as evolving it over time. Expectations have to be defined and communicated to all involved: proof of concept, alpha, beta, production, v1.1 and so on.
And, of course, over time neither the taxonomy nor the underlying framework are static concepts: they too evolve rapidly, so there needs to be a process to keep things updated.
Determine Financial Model
A more precise statement might be "determine the sequence of financial models as you move from your present state to your envisioned end state".
There's plenty of evidence that the IT funding model directly impacts what kind of IT organization you'll have. Unfortunately, this is turning out to be one of the hardest things to change, especially in larger environments.
Today, your IT function is most likely funded as a combination of flat tax and per-project allocation of ingredients: servers, licenses, headcount, etc.
That's a far cry from a service provider model where everything is exposed as a variable service charge; one where consumers don't see the long list of the specific ingredients.
Not all of that financial model change can be done in one fell swoop -- or, at least, it's certainly not practical in larger settings. Instead, you'll want to think about a sequence of models that you progress through as more IT services are produced and consumed using the new model.
For example, one familiar early step is "showback" -- giving business consumers of IT a sense of what they're consuming, expressed as a user-friendly service vs. a long list of traditional IT components and allocated costs. The first "invoices" are done manually and usually without a great degree of precision.
But, for the first time, there's transparency at play -- costs are understood, and decisions can be made.
Very often, I'm asked "what's the right model for pricing services back to IT consumers?". The answer is turning out to be "it depends on what works for the people who are consuming the service".
For example, here at EMC our IT team provides a standard bundle of end-user productivity services with a fixed amount per head. There are few different bundles depending on what part of the organization you work in, but it's essentially a flat-rate plan. That pricing model seems to work -- for that specific service type.
By comparison, we've found more than a few power users of our new BI-as-a-service capability, and they can consume an awful lot of resources when they get going. For them, we're heading towards a variable pricing model with a hard cap if things get out of hand. Other services in the portfolio are more one-time, e.g. a migration from a business-owned application to one that's owned by IT.
In the real world, the pricing model is an integral part of the service offer -- consider wireless family data plans as just one example. Costs are recovered, but it's priced and packaged in such a way that it's easy and convenient to consume. Pricing models are thus continually revised to be more attractive and convenient.
The same sort of thing can be observed in proficient ITaaS organizations as well.
Define The To-Be Organizational Structure
In some sense, all the activities up to this point have mostly been warm-ups for the main act: a fundamental restructuring of the IT function around service production and consumption.
The previous activities basically give you a flavor and familiarity of what's required, but they don't go to the very heart of the matter, which is how IT does its business.
At some point into this journey, you will need to gather your leadership team, and start drawing big-picture end-state org charts, process flows, feedback loops, measurements and accountability, and so on.
It tends to work better once the IT leadership team has seen some aspects of ITaaS at work in their own world and are starting to realize that it's a workable model for all of IT, and not just a small portion of it. Often, the end-state model is then walked backwards through a series of progressive re-organizations that move people in the right direction, but not all at once.
Smaller IT organizations seem have a decided advantage here; they can move faster than larger ones when it comes to an organizational restructure.
Underneath the covers, you'll see new roles pop up that probably don't exist today in your organization, or -- at the very least -- are substantial re-definitions: service managers, product managers, account managers, process architects, etc.
This can be a challenging discussion, but it's absolutely critical. A new mission for IT always means new processes, new roles and new skills -- there's just no avoiding it.
Design Your Change Management Plan
Now that you know where you're going (organizationally speaking, that is) -- how do you get people there? Most of them will need to embrace new roles and measurements, learn new skills, and basically re-learn how they do their jobs. They'll need to learn to look at metrics a different way (e.g. cost-to-serve, end-to-end service delivery) and they'll need some tools to help them figure out how well they're doing.
But -- in reality -- although change management may start within IT, it certainly doesn't end there. In larger organizations, there's the unenviable but important task of teaching many thousands of IT consumers how to consume IT intelligently using the new model vs. how they used to do it.
Vendors and contractors will also need a special flavore of "re-education", especially when it comes to such important subjects as software licensing.
Any good plan has milestones and metrics that measure progress, and formulating these can iself be a challenging part of the planning exercise.
Are You Up For The Journey?
To end where we begun, IT transformation to an ITaaS model is not for the faint of heart. Not everyone is up for a few years of heavy lifting as the basic construct of enterprise IT gets re-envisioned from the ground up.
But it can be done -- and there are plenty of examples to learn from.
Whether or not it needs to be done is more subjective -- the change is slowly percolating through the vast enterprise IT segment, and -- in some senses -- it's still early days.
The hard part is when IT leadership senses that change might be in the air, but it's not exactly here yet. You know a harsh winter is coming, but right now it's a pleasant summer day. There's no obvious crisis or mandate that's making the change rapid and inevitable. I've seen IT leaders who "get it", but struggle to get the right sense of urgency to get ahead of the inevitable.
And, no, I don't have an answer for that one.
Grear post Chuck, some very interesting but effective points are covered by you to optimize development. I really liked the one describing about winning hearts and minds. Collectively, if you are a IT leader then must be aware of these. :)
Posted by: Mark | July 24, 2012 at 05:15 AM
well say it's use full thinking
Posted by: naveen | July 25, 2012 at 04:00 AM