3 Political Pitfalls to Avoid When Moving to an IT Services Model

Moving to an IT services model may be the most complicated thing an IT organization ever does. Why is the transition so challenging? Maybe not for the reasons you’d expect.

Becoming a services provider has less to do with your mix of technologies or your customers than it does with change management in your own organization. That’s because developing an IT services mentality requires a cultural shift and a change in the way IT does business. This new way of thinking not only impacts the way technology is packaged, but the way the IT team is structured to deliver it.

Neglect important steps needed to coax teams along and you could get blindsided by negativity and resistance. Why? Your real challenge isn’t strategic justification of the new model—it’s politics, inertia, and bias against any kind of transformation. Change is hard. And the changes required to successfully structure IT services can feel risky to key players in your organization. In many cases, you can expect a strong immune response to this perceived threat.

Using my own prior experience as an IT leader in this exact situation, I’d like to offer some advice for avoiding three political pitfalls that can derail your IT services transition.

Pitfall #1: Communication

Let’s say you’ve decided an IT services model is key to delivering value and managing costs, and you’re certain this direction is right for the organization. You do your research, put together your plan, and present it confidently to your executive team. And it blows up right in front of you. This is what happened to me. Why?

I’d missed a step. In the absence of communication, people will assume the worst. They will infer that “IT-as-a-service” is code for downsizing. And, let’s face it, it can be. Transitioning to an IT services model requires changes to the way your organization is structured, which means changes to people’s jobs, responsibilities, and areas of impact. Think about how political this might be in certain environments.

In my case, I’d spent my time comparing the way other organizations had accomplished an IT services transition and deriving a plan to do the same at my company. By the time I presented this plan, I was very confident about what we needed to do and assumed that everyone would jump to the same logical conclusion. The blowback was significant. What became clear was that I hadn’t done my due diligence to solicit input from our executive team or pull together best practices I could use to influence thought leaders, who might have offset some of the reactionary fear my IT services plan generated.

Lesson learned:

Ask before you tell. Bring best practices to the table to generate discussion, which will help you get key decision makers, thought leaders, and influencers on board early in the process.

Pitfall #2: Taxonomy

A taxonomy’s purpose is to help package products so that you can automate delivery of them. Sounds reasonable, but defining a service taxonomy is a potentially treacherous process.

The reason this is political, believe it or not, is because the taxonomy can imply the relative importance of a particular department. For example: at my company, app development was almost 50% of the IT spend. The app folks considered themselves the most important and sophisticated part of the organization (and in some ways, they may have been right).

When I developed my IT-as-a-service recommendation, applications and everything related to them required only 10-20% of the ink in the taxonomy. That’s because we couldn’t get very far with automation of the development process. When business units were thinking about engaging app dev, the “service” quickly became a person-to-person conversation. For this reason, infrastructure projects got the disproportionate amount of real estate in the taxonomy.

Well, our app folks didn’t like that very much. Given their significance in the organization, they assumed everything related to app dev would go to the top, with everything else trailing beneath it. The reality was that app dev was one of six IT areas (Apptio calls them “towers”), so they got 1/6 of the area. This made them look trivial on a surface level. And, believe it or not, this led to endless pain, hundreds of hours of wasted executive time, and far too many meetings.

Lesson learned:

Don’t get blindsided by political posturing. Apptio can be a HUGE help as you set up a service taxonomy. If I’d recognized this was going to be a hurdle, I could have taken Apptio’s industry standard, TBM Council-endorsed ATUM™ taxonomy into the presentation. We may have needed to make a few modifications to tailor it to our business, but this model would have saved a great deal of frustration.

Starting with a best practice taxonomy will make the adoption process much easier. Plus, once up and running, it will take much less effort to achieve a deep understanding of costs and you’ll find you’re much more compatible with benchmarks that correspond to industry standards.

Pitfall #3: The service owner role

Creating the service owner role can be even more political than the taxonomy. From managers to directors to SVPs, leaders in your organization who have traditionally had a lot of control over an area or tower are going to resent this encroachment on their work. That’s because this role represents the most threatening aspect of service transformation: organizational change.

Service owner roles shift control from others

To manage services effectively, you need tower owners (titles vary: service owner, product manager, etc.) who function largely like product managers. These people see the whole life cycle of IT products and services, from inception to development to retirement, and they shoulder a broad range of responsibilities—responsibilities often aggregated from other groups. See the potential landmine?

Let’s use the SVP of Applications as an example. He’s not at all excited about a new group of service owners (who won’t report up to him) making decisions about  how apps will be positioned, marketed, and sold to internal IT customers. Ultimately, he benefits from a smoother running IT shop, where shedding some of these responsibilities allows him to also shed a lot of the headaches. But he and his directors may not immediately see the forest for the trees. They’re used to having a fair amount of customer contact, and this shift can represent a significant loss of control.

The inflection point is that creative leaders will use this opportunity to expand and change their roles and responsibilities, and those that want to hunker down and do networks (or etc.) will still have an important job to do. Just beware the natural immune response to circle the wagons, which can lead to a lot of noncompliance and passive resistance at first.

The good news is that, under the new model, everyone—from SVP to individual contributor—is more likely to be held more accountable than they have been, because there will be more clarity around what needs to be delivered and the cost of what’s being delivered.

Service owners can be hard to find

Depending on your organizational structure, there might be 3-20 people working in this full-time capacity, reporting up to one person who reports to the CIO. Finding these people can be challenging. A good service owner will need requisite technology credentials, but there are other, perhaps more important, success factors for the role . Service owners also need to understand financial management and have strong negotiation and sales skills, and this can be an unusual skill set for an IT organization.

Service owners require a unique career path

Another challenge is that the service owner role is typically an individual contributor role. By accepting this position, folks who are used to managing small teams may feel they are taking a step backward. Many organizations fumble with this, not doing enough to clearly define and publicly support a career path for this position.
The way to elevate the service owner role is to enlist the CIO to make a clear statement. This position naturally provides a broad range of experience that will be invaluable to someone wherever they go, but it should also be defined as a leadership track opportunity.

Lesson learned:

Look for hungry, motivated people who are already breaking stereotypes and getting noticed. Typically, you’re looking at someone with ~5 years experience (in IT) who is accustomed to managing people, perhaps someone on your team who demonstrates high potential or someone from the outside.

Communication is key to get the benefits of this position across. Make sure you outline a clear career path for this role and emphasize its weight and potential in the organization.

Summary: from supplier to trusted advisor

While moving to an IT services model may be the most challenging and political shift you ever undertake, the rewards are substantial. Among the many benefits we realized, here are a few that stand out:

• better alignment between staff effort and the services our business colleagues valued
• enhanced customer satisfaction and loyalty
• improved relationship between IT leadership and the business

We successfully transformed from supplier to trusted advisor, and ultimately, we learned valuable lessons about communication and partnership that can be applied to other IT initiatives.

Phil Gormley is regional VP of Strategic Services at Apptio and formerly a senior strategy consultant at EMC, where he spearheaded a service transformation and learned a few lessons along the way. Follow him on LinkedIn here.

For more on this topic, read Phil’s article “Seeing the Elephant: 10 Steps to Unifying a Business View of IT Services.”