What is IT Strategy?

I do realize there are probably thousands of blogs out there that try to answer this, but it is such a fun question I thought I’d give it a try. Business partner Jim and I were off last week on a little writing retreat and this was one of our hiking talks… we talked about how IT strategies need to give organizations/ companies focus related to IT, to help make the best decisions about how to invest in technology.

So I was doing yoga tonight in my living room and apparently not effectively concentrating while in pigeon pose, because a book on the shelf underneath my coffee table caught my eye: The Boston Consulting Group On Strategy. Ah, that ended the yoga practice. I don’t know when BCG gifted this to me, but I haven’t yet read it and after a quick flip through I decided it looked pretty good (especially compared to most strategy books). Anyway, I opened it up wondering if it had a perspective on this “what is strategy?” question. Sure enough, BCG’s founder, Bruce Henderson, starts the book working to answer this question. Here’s what he says: “All competitors who persist over time must maintain a unique advantage by differentiation over all others. Managing that differentiation is the essence of long-term business strategy.”

I like this. But it that mean for IT strategy? Many think of IT strategy as the strategy for the IT organization. And many think of the IT organization as a little mini business within a business. If you follow this logic, that organization has historically been the sole provider, but these days, with outsourcing and cloud computing on the rise, that organization does have competitors. So IT strategy for an organization could be how they differentiate against their “competitors”.

But hold on… I like that if I’m a CIO trying to keep my job, but I’m not sure I like it if I’m a CEO trying to do the best thing for my company. From a CEO’s perspective, an IT strategy should more directly state how IT is applied to maintain that unique advantage referenced above over competitors. And part of that unique advantage may be strategically sourcing some or all of the IT organization and moving more of the technology to the cloud, either for cost savings or some other kind of differentiation. And if I’m a good CIO, I’m probably thinking about IT from the CEO’s perspective…

OK, that’s it for now, but this discussion isn’t over… just getting started … feel free to chime in.

What’s first? Org Strat or Tech Strat?

I’ve been talking recently with a couple of colleagues about the logical flow of strategy within large organizations. Our clients often have multiple strategic challenges to address, particularly when they have just brought on a new leader, merged or divested their organizations, or gone through other broader company changes that require a transformation of the technology group. Two big strategic needs tend to emerge: one around designing the right organization and the other around developing the right technology architecture. People who believe, as we do, that strategy projects must be limited to a few months, may be faced with a dilemma on which challenge to tackle first.

(By the way, this dilemma is really only relevant to large technology organizations, those with hundreds or thousands of employees. Small organizations can and should cover all these topics in an integrated strategy over a couple of months.)

So where should you start? With the organizational strategy or the technology strategy? Both strategies begin with the same step, assessing the business’s needs for technology. But then, the organizational strategy dives deep to understand the current organizational design, its capabilities, and its performance model while the technology strategy dives deep into identifying and assessing the different layers of technology architecture. When defining the future state and implementation plan, though, both lead back to the other. A technology strategy, both its design of its future state and its implementation plan for transitioning to that future state, is heavily limited or enabled by the organization driving it. A technology strategy that ignores the organization supporting it is likely to be impractical and end up on the shelf. An organizational strategy is often defined by the current state and planned direction of its technology architecture. Plans for existing or new technologies may affect which groups can be outsourced or how development groups should be aligned.

Even within our company, we have a variety of opinions on the right ordering of strategy and honestly, I could pretty easily debate technology or organization strategy as the best starting point. But overall, without considering specific nuances of a given situation, I believe in starting with organization. Here’s why:

1. You get payback sooner. You can design, plan and rollout a new organization in a few months, whereas designing, planning and rolling out a new architecture takes years.
2. The technology strategy cannot be executed without strong structures and capabilities. It is likely to end on the shelf.
3. Getting the right people into right roles builds towards a high performing organization that will make better technology decisions on an ongoing basis versus on a follow-the-architecture basis.

Of course, neither the technology strategy nor the organizational strategy will define a perfect end state. Nirvana will never be reached; both strategies will need to evolve interactively over the years. The organization will likely need to be reassessed once the technology architecture has shifted. Both will need to shift with broader business changes. Everything is linked. So we must pick a starting point, focus and make progress, and then pick the next highest impact area, focus and make progress and so on, always keeping in mind the significant interdependencies of the broader system.

Gartner’s influence on technology decision making

This is a great little piece: "Magic Quadrant Lawsuit: Would You Jump Off a Bridge If Gartner Says So?" putting Gartner, the analyst firm, in perspective. Thomas Wallgum compares following Gartner with following the in crowd in high school. His overall point is valid, if Gartner continues to be successful, they must be doing something right. Companies continue to follow their advice over the years so it at least must be directionally correct.

I’ve incorporated lots of Gartner (and Forrester, and CIO Exec Board, etc, etc) research over the years, into both organizational and technology strategies, sometimes at the request of our clients and sometimes at our suggestion. This research has never fundamentally changed our direction or brought forth a killer idea that changed our way of thinking about and solving a problem. That said, it has helped educate us and our clients on concepts, validate approaches, identify technologies to further investigate, etc. It has helped us fill out and back up our analysis but rarely drive to different recommendations.

And that’s how I’d recommend companies use Gartner. Not to decide their strategy but as one of many inputs.

Are we expecting too much out of CIOs?

I read this article on “The Three Types of CIOs: Are You and Your Company a Match?” earlier this week and while it isn’t really anything all that new within IT or even with business execs, it has spawned some interesting discussion with colleagues and clients that I thought I would share …

(If you don't want to read the article, the one sentence overview is that companies need to think about what type of CIO they need and can pick between Strategic, Transformational or Operational.)

First, are CIOs any different than other executives in their needs for different types of leadership? It seems to me that the three camps Curran describes could apply to CEOs as well as many other executive positions. I suppose you could attempt to make a case that IT organizational strategies change more often than their business strategies, requiring a new type of leader with each major shift, but I think I’d argue the opposite if forced to debate it …

Second, is this need for different types of CIOs at different times the reason that the average tenure of a CIO is only 18 months? If the answer to #1 is no and CIOs deal with more of a roller coaster than their businesses, then this could be a logical conclusion. But with my answer to #1, I’d say the reasons for their short tenure go back to other factors, including the average CIO’s capability gaps and the ongoing misunderstandings between IT organizations and their business partners.

Finally, is it unfair to expect a CIO to have all these capabilities? No! Leadership theory says that there is a natural preference for leadership, but if someone has reached the CIO level, and I’m not talking about an IT director of a small little organization here where you might have to make the tradeoff to afford someone or even find someone who would stay happy in the position, if they are working at a large company and responsible for both strategy and execution, they have to have all these qualities! Of course they can and should supplement themselves with strong lieutenants and/or consultants to help them, but a strong leader can seemingly effortlessly switch between these different modes and should be able to last more than 18 months. I think that’s core to the definition of a good leader, IT or otherwise.

One more note, one of the comments on the article referenced this State of the CIO study from the CIO Executive Council. If you are interested in this topic, it is definitely worth a skim. I found it particularly interesting that most Operational CIOs (what they call Function Heads) and Strategic CIOs were male but twice as many Transformational CIOs were women versus men.

IT strategic objectives that mean something

One of my business partner Jim’s favorite soapboxes is that most strategies don’t really say anything. And he’s right. I could go on about business strategies in their own right, but I’ll start with the problems with most IT strategic objectives since that’s where we tend to get involved. They go something like this: “we want to be more responsive to our clients, optimizing our costs, improving quality of solutions, and developing and engaging the best people around”. You can’t really argue with any of it, but it sure doesn’t give your employees much focus. And it doesn’t have any specific tie to what the business does as a whole. It’s just that it could be the IT strategy at any company, in any industry, with any variety of business objectives that might require very different focuses from their technology organization.

Thanks to one of my clients for sending me this article from Global CIO the other day, which gave me hope that some organizations out there are really getting it. Chevron’s IT objectives go something like this, as described by their CIO, Louie Ehrlich:

"First: connecting people, partners, and businesses. We're a global company, with lots of different types of relationships around the world with governments or joint ventures or business units, and whatever those relationships are or wherever they may extend, we need to be able to allow our people to connect easily and securely.

"Second, accelerating insights: for a company like ours, it's finding ways to improve how we view things like the subsurface more effectively, or how we look across the business and gain insights. And doing that implies improved data, and a single source of truth, which is difficult if we've haven't set things up properly," he said.

The third objective is keyed to automating, integrating, and optimizing business assets around the globe, infusing IT more deeply and strategically into the global Chevron central nervous system.

Now that’s what I’m talking about. Good stuff. It actually defines how IT contributes to business value and helps employees engage with their ultimate business objectives.

Scrummerfall: Pitfalls of Mixing Agile and Waterfall

One of my colleagues just sent me this article : Scrummerfall: The World's Worst Software Development Methodology - it is worth a quick read if you are interested in development processes. Most agree that there are pros and cons to Agile versus Waterfall depending on the organization. Pretty much everyone agrees that half-assing Agile is worse than not doing it at all. Hence the definition:

Scrummerfall. n. The practice of combining Scrum and Waterfall so as to ensure failure at a much faster rate than you had with Waterfall alone.

For those who are well aware of these pros and cons, this won't offer any deep insights. But it is a pretty funny take on it all, with spot on analysis of many organizations' cultural resistance to Agile.

THOUGHTful meetings

Back in the day (okay, a few months ago), Jim and I would constantly call each other to talk through ideas, ideas for client recommendations, ideas for advice to friends, ideas for industry changing frameworks or thoughts. These days, we are juggling clients across multiple geographies and starting to grow our team. It would be very easy to fall back on the ways most of us have worked in previous consultancies, focused on delivering to our clients and coming together primarily to manage the company, maybe with some more strategic thinking happening in sporadic pockets or centrally from a knowledge management group.

I thought I’d share a bit about what we’ve been doing to build a culture of thinking, since it seems to be working well so far. Now that we have added John and Claudia to the team, we have two weekly meetings, an Ensemble meeting to focus on management of the company and a Thought meeting to discuss ideas. In the Thought meetings, one of us shares an article or presentation with the group for feedback or we just pose open-ended topics. Last week, I was talking a lot with one of our clients about the differences between a software organization and an internal IT department. In past lives, I probably would have done a little thinking myself, maybe with a little research and possibly some conversation with someone from my company. This time, I “hijacked” another less urgent topic in the Thought meeting and we spent the entire hour brainstorming up the different pressures and probable recommendations for an organization trying to make the shift from “internal IT” to “software company” mentality. We came at it from very different perspectives, which I suppose you’d expect from a group of four that includes a couple technology backgrounds, a couple MBAs, a PhD in organizational psychology and many years of varied experiences.

To be honest, we were all grumpy at the start of the meeting. We met at 7 AM (6 AM for Claudia) so as to be done in time to kick off client meetings at 8 AM. Everyone was busy, logistics were challenging that morning, but after five minutes in we were having a healthy debate that started the day off just right. Not only was it fun, it gave me some great additional ideas to take back to my client. I think the weekly meetings also remind us to stay engaged with each other in a “thoughtful” way throughout the week via email, phone and impromptu meetings.

Too often, I think organizations try to relegate innovation or strategic thinking to a small group of people or force it into rare windows of time throughout the year. Meetings are all tactical, without enough room for real thinking. Organizations may have the capability to think strategically, but not the structure and practice. I’m not going to say it is easy, and check with us in a few years on how we are working this with 75 people, but I think these Thought meetings could be onto something ….