Elements of an IT Operating Model

This is the second part of my series on IT Operating Models for Enterprise 2.0 (for the introduction, please see here.)  In Part 1, I explored the question, “Why Does Enterprise 2.0 Demand a New IT Operating Model?”  I posited three key answers:

1. The types of IT products and services the IT organization must deliver in an Enterprise 2.0 world are quite different from those in a 1.0 world.  Enablement of enterprise collaboration, for example.
2. The ways that IT products and services can be delivered in an Enterprise 2.0 world are also quite different.  Through “the cloud”, for example.
3. The ways of designing and executing an IT Operating Model in a Web 2.0 context are also quite different.  Collaboratively, and through “the cloud”, for example.

I mentioned my current interest and excitement about the 3rd point as something I’ve been exploring, both through multi-company research and through actual consulting engagements, and that is where I want to focus this post.

What Are the Primary Elements of an IT Operating Model

My last post described an IT Operating Model as “the basic framework your IT organization follows to get your products and services into the hands of its consumers and customers.”  Let’s consider what might be the primary elements of such a framework:

• Processes – how we perform activities that deliver predictable and repeatable business results through competent people using the right tools.  For example, how to we shape demand?  How do we surface and clarify demand?  How do we turn demand into solutions that deliver the intended (or better) business results?  How do we continuously improve the way we do IT work?
• Governance – how we make and sustain important decisions about IT.  For example, how do business needs and initiatives get prioritized?  How do we manage the tensions between local and global optimization?  How are “standards” chosen and what are the consequences for deviations?  How do we govern major business programs?
• Sourcing – how we select and manage the sourcing of our IT products and services.  For example, how do we leverage our scale?  What do we offshore, near shore, onshore, in house, in source, contract?  How do we manage key vendors?
• Services – our portfolio of IT products and services.  For example, what is in our service catalog?  How do we define and manage service levels?  Do we offer differentiated services by customer segment (e.g., concierge service for executives or key customers?)
• Measurement – how  we measure and monitor our performance.  For example, what are the shared goals of the IT organization?  How does the business determine value realized and delivered through IT investments?  How are we improving over time?  What are our leading indicators of performance and trends, what are they telling us and how do we know what to do about it? What customer experience are we creating for users of our products and services?
• Organization – how  we structure and organize our IT capabilities.  For example, what capabilities should be located within the IT organization and what can be within the business?  How do we organize around major projects and programs?  How do we organize around major products and platforms?

Note, I deliberately put Organization Structure last in the list.  For years, when I’ve been consulting on IT operating model design, clients invariably want to start with the organization design.  I call that “moving the deckchairs on the Titanic.”  It rarely solves anything.  On the other hand, if you work around the other elements – services, processes, governance, etc., the organizational decisions fall out relatively easily, and far more coherently.

For the last 50 years or so, IT Operating Model Design was mostly an oxymoron – they weren’t designed as much as evolved.  When deliberate design was attempted it was typically though workshops, using flip charts, post-its, PowerPoint slides, Visio, and so on.  At the end of the day, you had an organization chart to follow, organizational charters, templates, process descriptions and such, usually as MS Word and PowerPoint documents that got emailed to and fro, edited, re-edited and eventually “filed,” never to be seen again until the next CIO and the next attempt to “better align IT to the business!”

So, How Can Web 2.0 Change the Way to Design an IT Operating Model?

Given collaborative tools, wiki’s, social networks, prediction markets, et al, how can IT Operating Model design be performed in a more collaborative, impactful way?  How can it be done so that the traditional artifacts of the design – the PowerPoints, flip charts and Visio diagrams become “the way work gets done”?

I will pick up this question in the next post in this series.