First, my apologies – this is old news!  But I was talking to a CIO last week and he made a statement I’ve heard many times over the years:  “The company views IT as ‘the piggy bank’ – it’s a place they can reliably come to when they need to cut costs!”  This reminded me that while I’ve had the good fortune over the last 5 to 10 years to work mostly with more mature IT organizations and their ‘clued in’ CIO’s, there’s a lot of CIO’s out there who should not be running enterprise IT functions – they are doing a terrible disservice to their employers!  Hence this post, intended to prompt less capable CIO’s (and maybe some CEO’s) into action!

Back to my anecdote.  I asked the CIO (knowing pretty much what his response would be), “How does the company feel about it’s IT capabilities?”  He said, “Well, no so great, actually!  They tell us we are delivering ok from a tactical perspective, but are not creating strategic value!”  I asked, (again, anticipating a predictable response) “How engaged are the members of the IT organization?”  His response, “Well, we do have an engagement problem – IT scored quite low on our latest engagement survey.”

The ‘Piggy Bank’ Trap

This CIO is caught in a familiar vicious cycle:

1. While they’ve done a decent job ‘keeping the lights on and the trains running,’ IT has not delivered strategic value.
2. As a result, when the company is looking to take out costs, IT is the first place they go.
3. Feeling vulnerable and wanting to be a ‘team player’ the CIO makes some cuts and ‘ponies up’
4. With budgets reduced, and with IT’s position as a tactical capability reinforced, the business units don’t look for strategic IT enablement, and the IT organization doesn’t have the bandwidth or capabilities to stimulate strategic demand.
5. Inevitably, more cuts are requested of IT (as a dependable source of budget money) and the cycle continues!

IT Must Be highly Cost Effective!

Make no mistake – IT has to run its operational side in the most cost effective manner – provable through benchmarks.  (And, as it turns out, IT operations and support is one of the most easily and accurately benchmarkable aspects of IT.)  Often, getting to an acceptable benchmark in operational costs means working with business units to consolidate disparate systems, retire ancient and non-viable platforms, and exploit newer technologies such as virtualization and cloud computing.  There’s good news and bad news in this:

• The bad news is, it can’t be done without business cooperation.
• The good news – it forces business cooperation!  In other words, IT is not simply acting as a piggy bank – it is working with its users to increase efficiency and effectiveness.

The good news side of this equation helps position IT beyond a ‘back office’ mystery zone of geeks and propeller-heads, and towards a valued business partner.

IT Must be Strategic

But cost effective operations is just table stakes for the real mission – enabling business growth and innovation.  Not simply helping the bottom line, but growing the top line – and even creating new top lines enabled by information and technology.  You cannot cost cut your way into this role.  If, as CIO, you find you are repeatedly getting relegated to the company piggy bank, you need to look in the mirror.  As I’ve noted before, businesses get the IT they deserve!  And the corollary to that – CIO’s get the respect they deserve.

In Part 1, I discussed the importance of IT Organizational Clarity, the symptoms when clarity is compromised, and the challenges of trying to address those symptoms rather than the root causes that lead to compromised clarity.  Part 1 closed with a discussion of the two key dimensions along which IT Organizational Clarity can be tackled – scope (units of IT Capability) and meaningful and assessable characteristics for evaluating and improving IT Capabilities.

In Part 2, I discussed ways to define IT Capabilities and provided guidelines on the manageable number of IT Capabilities and appropriate depth of decomposition.  In this post, I will describe three different types of IT Capability.

Not All IT Capabilities Are Born Equal

It is helpful to classify IT Capabilities into one of three different types, as illustrated in the graphic above.

Value Chain Capabilities

At the core are those capabilities that take inputs, add value, and deliver outputs to a customer or end consumer (in the world of IT, these tend to be services and products).  Think of these Value Chain Capabilities as those that the end customer appreciates (hopefully!) and is willing to pay money for.

For example, as a business user, I may have a business problem I’d like IT help to solve.  That problem (or opportunity) is the input to a Value Chain.  The first Capability that will approach that problem adds value by analyzing the problem, identifying and proposing a solution.  As the business user, I appreciate that value has been added – drilling into my stated problem and offering (and perhaps demonstrating via a prototype) one or more proposed solutions.  The next Capability in the Value Chain might take the chosen solution and develop and deploy that solution.  Again, as the business user, value has been clearly added – taking a proposed solution and delivering it.  The final Capability where value can be added is supporting and maintaining that solution – again, a recognizable way of adding value for me, the customer.

Ultimately, as the business user or consumer, these are the only Capabilities I care about and am willing to pay for (directly or indirectly) because of the value they add for me.  Unfortunately, while these Value Chain Capabilities are necessary, they are not sufficient.

Enabling Capabilities

Value Chain Capabilities typically draw upon other Capabilities that enable them.  Think of these as Shared Services that are common to other Capabilities, or to other instances of problems/solutions working their way through the Value Chain.  Examples of IT Services that might enable the Value Chain Capabilities include Project Management, IT Operations, and IT Supply.

Alignment and Governance Capabilities

Value Chain Capabilities also typically depend upon other Capabilities that ensure that the work they are doing is aligned and governed to ensure they are operating effectively and in the interests of the enterprise.  For example, determining which business problems will be addressed, which solutions will be selected, how staff and resources will be allocated are all important control that Value Chain Capabilities will be subject to.

Why These Distinctions Matter to IT Organizational Clarity

The distinctions between Value Chain, Enabling and Alignment/Governance Capabilities are significant:

1. Different types of IT Capability tend to be optimized towards different value propositions, with implications for how they are organized.  For example, Enabling Capabilities tend to be optimized for Operational Excellence (as shared services, they need to deliver predictable, consistent, quality services at the lowest possible cost).  Value Chain Capabilities tend to be organized for Customer Intimacy, delivering what specific customers want; anticipating customer needs.  Alignment and Governance Capabilities tend to be more about decision-making – rather than delivering services, they make decisions or provide decision-making frameworks – think Enterprise Architecture and the mechanisms and structures that support it as Alignment and Governance Capabilities.  As such, these tend to be networked, linking stakeholders and decision makers, and optimized to maximize the business value delivered or enabled by IT Investments..
2. Some types of IT Capability lend themselves to alternate sourcing more than others.  For example, Aligning and Governance Capabilities lend themselves the least to straight outsourcing approaches (do you want to pass decision rights to an external vendor?)
3. Different types of IT Capability lend themselves to different funding models.  For example, Value Chain Capabilities lend themselves to direct business funding, whereas Enabling Capabilities lend themselves better to indirect funding models (e.g., overhead charge).

IT Capability Model Example

As an illustration, below is a ‘normative’ IT Capability Model.

The Fractal Nature of IT Capabilities

Note, that as you decompose any IT Capability, you will generally find that the decompositions will have a similar structure – a primary Value Chain, drawing upon underlying Enabling Capabilities and influenced by Alignment and Governance Capabilities.

For example, Manage Business-IT Portfolio & Programs might decompose into the following sub-Capabilities:

In the following post, we will look at the assessable characteristics of any IT Capability as a means of determining Capability Maturity and determining how to increase maturity and thereby improve performance.

1. Bounding scope by defining “IT Capabilities” at an appropriate level of granularity. (Units of analysis).
2. Defining meaningful and assessable characteristics for IT Capabilities. (Means of assessing and improving).

Note – the ultimate gauge of IT Organizational Clarity is in the ‘health’ of the IT Organization and the business results to which it contributes.  However, there are all sorts of demand-side complexities in assessing these things, so for now I will focus on the notion of capability maturity as a worthy proxy for and predictor of end results and the ability to continuously improve.

In this and the next couple of posts I will discuss the notion of IT Capabilities and how best to define them.  I will then address the assessable characteristics of IT Capabilities.

What Is an IT Capability?

In order to adequately define an IT Capability, we need to clarify a couple of common terms – Service and Process:

Service

A Service in the context of IT Capabilities is best described as the interface point between a provider and a consumer where value is exchanged.  Services should be defined from the perspective of the consumer.  They need to be ‘discoverable’ and the service interface understood by the consumer.  They need to have clarity on what they do, what they cost, how they are invoked, and how problems are reported and resolved.  The service provider should have a good understanding of the value received by the consumer, as well as the overall quality of the customer experience.  This may comprise both tangible and intangible elements, most of which are ultimately subjective.

Process

A Process is a sequence of interdependent and linked procedures which, at every stage, consume one or more resources (employee time, energy, money) to convert inputs (data, material, etc.) into outputs.  These outputs often serve as inputs for the next stage until a known goal or outcome is reached.

Capability

A Capability can be thought of as everything it takes behind the scenes that makes a service possible.  This will include:

• One or more Processes.
• Descriptions of the Roles needed to perform one or more of the procedures within a process (e.g., Project Manager, Business Analyst, Relationship Manager).
• Descriptions of the Competencies needed to perform a given role (what the person performing the role needs to know, e.g., business knowledge, what skills they need, e.g., facilitation, and what behaviors they should exhibit, e.g., results orientation).
• An adequate supply of competent human resources filling the given roles.
• Tools and technologies needed to automate or execute necessary processes or procedures.
• Management systems necessary to ensure the health and performance of the Capability, including funding, organizational will, personal incentives, and so on.

How Many IT Capabilities Should You Have?

This is a tricky question to answer.  First, of course it depends on the mission to be served by a given capability.  But more importantly, this is a question of granularity.  In the heady days of business process re-engineering, I learned that picking the right granularity for an end-to-end process is crucial, and perhaps as much art as science.

I think this question has more to do with the characteristics of and limitations to the workings of the human mind than anything else.  If you end up with, say, 3 IT capabilities, chances are that you are at too high a level of granularity to be really useful in terms of analytical and management discipline.  On the other hand, if you have 12 or more IT capabilities, you are at too low a level.  From my experience, between 7 and 9 is the right number of IT Capabilities to have in a ‘top-level’ IT Capability model.

How Many Levels of Decomposition Should You Go To?

Yes – you guessed it – it depends!  On the basis that you really don’t understand a Capability unless you can see a level of decomposition below it, I think the answer is at least two levels of decomposition are necessary.  Beyond that, it depends on the Capability you are trying to understand or improve.  Consider, for example, the Process aspect of an IT Capability.  Capabilities that are highly procedural, such as those found in IT Infrastructure and Operations, will typically need more levels of decomposition (i.e., more detailed process definitions).  Coincidentally, this is the domain of ITILv3, so you can effectively ‘buy’ process definitions and a process architecture off-the-shelf.

On the other hand, a Capability such as Opportunity Discovery may be more about analytical skills and the magical space between problem understanding and solution definition.  This space is much more about specially-skilled people and specific business domain knowledge rather than sequential, detailed and rigorously controlled processes (as in Statistical Process Control.)

We will pick this up in the next post and look at three different types of IT Capability  – Value Chain Capabilities, Aligning/Governing Capabilities and Enabling Capabilities – and examine the distinctions between these and why the distinctions are important.

Graphic courtesy of MassBay Organization Development Learning Blog

IT Business Edge has just published a short slideshow on “Four Common Mistakes in IT Portfolio Management“, re-purposing a post of mine from January 2008.  I think they did a great job simplifying and bringing to life some of the key points in the original post.  Enjoy!

Alignment can also refer to Structure – IT capabilities are structured to align with business structures and needs.  But there’s a crucial ‘third leg’ to the business-IT alignment stool, and that is the alignment of relationships that sit between business units and IT capabilities.

The Crucial Relationship Manager Role

Many IT organizations have created a role that bridges the business and IT.  Rarely actually called “Relationship Managers”, this role represents IT to the business and the business to IT. I’ve posted on this role before – see, for example The IT Relationship Manager’s Role in Expanding Business-IT Capability,  and From Supply-Constrained to Value-Constrained IT Business Model, and IT Maturity and the Role of the Relationship Management.  Sometimes called an IT Account Manager, or Business-IT Director, or some-such, the role is primarily responsible for ‘demand shaping‘ – stimulating an appetite for high value demand, and suppressing appetites for low value demand.  Sometimes, people in this Relationship Manager Role are effectively mini-CIO’s or Business Unit CIO’s – leveraging shared IT infrastructure (and often leveraging common applications and enterprise systems) but taking care of business unit-specific IT needs.

Relationship Alignment

There are at least three dimensions along which Relationship Managers can align with their business partners.  The first two dimensions are pretty obvious and generally handled well, but the third dimension is trickier and often not well addressed.  The dimensions are:

1. Domain Expertise – the Relationship Manager (or whatever title this role operates under) needs to really understand the business domain for which they are responsible.  Be it marketing, supply chain, human resources, and so on, they need to have deep domain knowledge in order to bring real value to their business partners and have the credibility to have impact.
2. Geography – as the real estate cliché goes, ‘location, location, location!’ so goes Relationship Management.  At its best, the Relationship Manager should be co-located with the senior managers of the business unit with which they are aligned.  At the very least, they need easy access.  The occasional ‘fly in’ to meet with their business partners typically doesn’t do it in terms of creating a productive business-IT partnership.
3. Maturity – this is the tricky dimension, and one that is typically not well addressed.  Skilled Relationship Managers are a rare resource.  You want your most effective and creative Relationship Managers aligned with those business units and executives with the highest demand maturity – i.e., with the best  capacity to recognize and leverage high value IT-enabled opportunities.  Innovative, ‘change agent’ types of Relationship Managers will quickly become frustrated facing off against executives who are technologically in the dark ages, or who cherish the status quo.  Similarly, progressive, innovative business leaders will become quickly frustrated working with a Relationship Manager who lacks drive, a sense of urgency, the creativity to generate valuable ideas about IT possibilities, and the wherewithal to bring them to fruition.

How Healthy Are Your Business-IT Relationships?

Clearly, the CIO is in many ways the ‘über-Relationship Manager’, setting the tone for demand shaping and the strategic context for IT, and typically ‘owning’ the business-IT relationships with the most senior executive team.  But no CIO has the bandwidth or domain expertise to handle all the relationships at all the management levels needed to surface and steer the best opportunities to create business value from IT.  So, how healthy and productive are your key relationships between business and IT? Do you even know what would be considered ‘key relationships’?  How would you know the degree to which they are fully delivering value against their potential?

Let me know your thoughts and experiences around Relationship Management effectiveness.

I introduced my ideas about leveraging Web 2.0 (broadly defined) to significantly drive up the value of business innovation – specifically by following the principles and processes of Design Thinking.  I’ve been getting to this point in my last series of posts (Part 1, Part 2 and Part 3.)  In fact, those posts were largely written as I was developing my session materials.

Does ‘Design Thinking’ Have Legs?

Part of my thesis built upon the success of the Design Thinking movement that has gelled over the last 5 years.  I have found the success stories compelling, and the underlying principles resonate with my own experiences and values over the last 30 years in trying to leverage IT for increased innovation.  However, I was troubled by the recognition and acceptability of the term ‘Design Thinking’ – especially in the US.  The text of a 2007 speech by BusinessWeek‘s Bruce Nussbaum given in London tipped me off that there might be a problem here.

Nussbaum’s Banana…

In his 2007 speech to the Royal College of Art, Nussbaum noted:

In the US, CEOs and top managers hate the word “design.” Just believe me. No matter what they tell you, they believe that “design” only has something to do with curtains, wallpaper and maybe their suits. These guys, and they’re still mostly guys, prefer the term “innovation” because it has a masculine, military, engineering, tone to it. Think Six Sigma and you want to salute, right? I’ve tried and tried to explain that design goes way beyond aesthetics. It can have process, metrics all the good hard stuff managers love. But no, I can’t budge this bunch. So I have given up. Innovation, design, technology—I just call it all a banana. Peel that banana back and you find great design. Yummy design. . The kind of design that can change business culture and all of our civil society as well.”

One of the first to make the Web 2.0 connection, Nussbaum went on to say:

Innovation is no longer just about new technology per se. It is about new models of organization. Design is no longer just about form anymore but is a method of thinking that can let you to see around corners. And the high tech breakthroughs that do count today are not about speed and performance but about collaboration, conversation and co-creation. That’s what Web 2.0 is all about.”

I tested the waters of my Summit attendees, first by asking how many in the room had some familiarity with the term ‘Design Thinking’?   Three hands shot up, and a couple sort of hovered around shoulder level (presumably meaning, “I’ve heard of it, but please don’t call on me to talk about it!”).  Of the three hands, two were from companies for whom I had Design Thinking case studies about and who were listed in my very first slide (I had not at this point turned on the projector.)  The third hand was from a senior executive at a major Industrial Supply company that I had not expected to be particularly Design Thinking literate.  So, test 1 indicated that the term is not widely known.  Of course, this does not necessarily mean that Design Thinking is not widely practiced – perhaps all 60 companies in the room do in fact excel at Design Thinking, but refer to what they do as some variation of Nussbaum’s ‘banana’?  However, I truly doubt this.  In fact, the many one-on-one conversations that I had with the executives at this summit during the reception and dinner following my presentation supported my sense that explicit efforts to drive up the value of business innovation are relatively few and far between.

Are Design Thinkers Web 2.0 Enabled?

To the larger part of my thesis, there was little evidence at this Summit that any form of Web 2.0 was being explicitly leverage to support Design Thinking (or innovation, or the banana!)  There were a few ‘accidental experiments’ and emergent social networks – both internal and external – but nothing claimed as part of a deliberate, holistic effort to increase innovation through Web 2.0 technologies.  This for me was the big surprise.  The Senior Vice President of Strategy from one of the Design Thinking literate companies told me at the reception, “When you first connected Design Thinking and Web 2.0 in your presentation, I thought you’d completely lost it!  But as you gave examples, the light bulbs began to turn on – I think you are onto something!”  This was gratifying indeed – well worth the price of admission!

Graphic courtesy of RI Nexus

Related articles by Zemanta

• Reading Bruce Nussbaum’s The Future of Design Stanford Conference @BusinessWeek (fredzimny.wordpress.com)
• Design Thinking 2.0: Enabling Innovation with Web 2.0 – Part 2 (vaughanmerlyn.com)
• Design Thinking 2.0: Enabling Innovation with Web 2.0 – Part 3 (vaughanmerlyn.com)
• Just Read: Thinking About Open Design @BusinessWeek (fredzimny.wordpress.com)
• Design thinking:Everywhere and Nowhere, Reflections on The Big Re-think (core77.com)
• Nussbaum on Design, Disruption and Innovation (myventurepad.com)
• Design Thinking is Killing Creativity (designsojourn.com)
• What is Design Thinking, Really? ” emergent by design (fredzimny.wordpress.com)

• Processes – how we perform activities that deliver predictable and repeatable business results through competent people using the right tools.
• Governance – how we make and sustain important decisions about IT.
• Sourcing – how we select and manage the sourcing of our IT products and services.
• Services – our portfolio of IT products and services.
• Measurement – how we measure and monitor our performance.
• Organization – how we structure and organize our IT capabilities.

In Part 3 we looked at how Web 2.0 approaches could transform the way IT processes are defined and managed.  I now want to look at IT governance, and the implications of Web 2.0 for this ever important aspect of IT operating models.  Due to the depth of this topic, I will discuss the facets and domains of IT governance in this post, then deal with the Web 2.0 implications in a subsequent post.

Facets of IT Governance

There are many definitions and descriptions of IT Governance, and frameworks such as COBIT that attempt to bring ‘best practices and processes’ to the domain.   The two definitions I have landed on in my years of research and consulting in this space, are:

1. A framework of decision rights and accountabilities to encourage desired behavior to realize maximum value from information technology.
2. Aligning IT decision-making with enterprise governance and business unit objectives through an interrelated set of processes, policies and decision-making structures with clear goals, roles and functions, sponsored by the CEO, with clear consequences for compliance or lack thereof.

I like the first definition for its simplicity, getting to the heart of both ‘decision rights’ and ‘accountabilities’ through the lens of ‘behaviors’ all focused on maximizing the value realized through IT.  This is pragmatic – you can define the types of behaviors you would like to see (e.g., business takes ownership for the business outcomes to be enabled by IT initiatives), or behaviors you are seeing but would like to eliminate (e.g., people see IT as a ‘free’ resource, and therefore use it with little or no regard as to its cost or value.)

I like the second definition in contrast for its recognition that IT governance is an extension of enterprise governance, and for its reference to ‘processes’, ‘policies’, and ‘decision-making structures.’  I also like the emphasis on CEO sponsorship and consequence management – i.e., governance with ‘teeth’.

I’ve come to view IT governance as a means to achieve balance between the competing forces of innovation versus standardization and business unit autonomy versus collaboration.  I also see IT governance as a way to manage IT investments and assets as a  resource that is shared by the enterprise.  Finally, good IT governance provides a “transmission chain” for the highest level enterprise strategy, from senior executives on down through the organization. As such, IT governance is a critical alignment mechanism.

IT Governance Domains

Peter Weill and Jeanne W. Ross, in their excellent book, IT Governance: How Top Performers Manage IT Decision Rights for Superior Results, call out five decision domains of IT governance:

• IT Principles (strategic choices between competing perspectives.  For example, ‘We will optimize IT investments for the enterprise rather than for individual business units.’)
• IT Architecture (“the organizing logic for data, applications, and infrastructure captured in a set of policies, relationships and technical choices.”)
• IT Infrastructure (“Centrally coordinated, shared IT services that provide the foundation for the enterprise’s IT capability.”)
• IT Investments and Prioritization (“How much and where to invest in IT, including project approvals and justification techniques.”)
• Business Application Needs (“Specifying the business need for purchased or internally developed IT applications.”)

While these domains may each be handled by different processes, policies and decision-making structures, all of these domains must be covered in ways that support a coherent strategy and set of beliefs about IT.

IT Governance, In Other Words…

IT governance deals with how the business makes decisions about the deployment and delivery of IT.  When sound IT Governance is in place, senior executives not only know their organization’s IT plans and policies, they also know how they are made.  IT governance is about the specification of decision rights and responsibilities required to ensure effective and efficient use of IT.  As such, it deals with organizational power and influence, and therefore  must be approached with care!

IT Governance 2.0

The implications of Web 2.0 on IT Governance are dramatic and far reaching!  On the one hand, with ‘transparency’ a watchword of good governance, 2.0 capabilities offer several important mechanisms to bring transparency both to the design of effective IT governance processes and structures, and to their ongoing execution and management.  On the other hand, dealing with decision rights and accountabilities in the types of highly diverse, distributed and fluid information environment enabled by social networking tools can become quite complex.  We will dig deeper into the implications of Web 2.0 for IT governance in a subsequent post.

Image courtesy of The ERM Current

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.

I’ve Looked At Clouds From Both Sides Now

Back in August 2008, not being able to resist the title to the wonderful Joni Mitchell and her reference to “cloud illusions I recall”, I posted on the denial I was witnessing among my client base.   I likened it to the denial that was common among CIO’s back in the early 1980′s.  To quote from that post:

(CIO’s) were mostly in denial, even as executive offices just down the corridor from the CIO’s office were beginning to become home to a variety of rogue PC’s – machines such as Apple II’s and Radio Shack TRS 80’s.

Fast forward 25 years or so. Now the press is full of predictions and prognostications about Cloud Computing, several key players are investing heavily in this space (pun intended) but many CIO’s and CTO’s either just don’t believe it, see it as warmed over service bureau computing from the 60’s and 70’s, or believe it’s the greatest threat to enterprise computing sanity since computer viruses first appeared.

Now, nearly 1 year later, I’m still seeing the same denial – Cloud Computing, for the most part, is on the back burner – a technology to watch!  Clearly, there are significant risks with the untried, standards are still evolving, and there’s something intimidating about such a simple concept being able to replace so much enterprise technology and expertise – the “heart and soul” of the typical IT organization.  In fact, for many IT shops, this “heart and soul” is where they’ve invested many of their improvement efforts over the last few years, implementing ITIL and process improvement approaches.  That’s been a hard-won fight, and CIO’s are loathe to admit that there might now be an easier and better way!

In another post earlier this year on The Dangers of Cloudy Thinking, I wrote:

I’m fascinated and bemused by this Cloud Computing phenomenon. Never before have I had such a strong feeling that something really, really important is happening – a fundamental discontinuity, if you will, in the way we leverage IT – and yet most of my clients and those I am interacting with in a couple of multi-company research projects are essentially standing on the sidelines.

Hincliffe’s “8 Ways That Cloud Computing Will Change Business”

Dion hits the nail on the head once more with his excellent June 5 post in which He says:

(Cloud computing offers) benefits that can potentially change the game for many firms that are willing to be very proactive in managing potential downside. These include access to completely different levels of scale and economics… Easier change management of infrastructure including maintenance and upgrades (cloud vendors extensively virtualize and commoditize the underlying components to make them non-disruptive to replace and improve) … Cloud computing also offers an onramp to new computing advances such as non-relational databases, new languages, and frameworks that are designed to encourage scalability and take advantage of new innovations such as modern Web identity, open supply chains, and other advances.

He goes on to show the major pros and cons, and then to cite 8 compelling ways that cloud computing can change business.

Cloud Computing – Ideal for the “Edgy” Opportunities?

Dion refers to the use of cloud computing beyond “edge” computing (which he describes as minor applications and non-critical business systems).  This is the only place where I take issue – I think “edge” computing is where the exciting action is, where the high value and innovative opportunities lie.

Back in July 2008, I posted on “Edginess and Innovation.”  In that post, I differentiated between “core” and “edge”:

Many IT leaders when talking about the “core” are referring to the “legacy” systems…  built over the years and have to maintain.  But in reality, the core goes much deeper than the systems and technologies. Business processes – especially when you include the unautomated practices and workflows that interact with the automated ones, are hard to change. The mindsets that dominate “core” thinking and “edge” thinking are radically different. I’ve noted before that quality guru Joseph Juran distinguished between “preventing bad change” (keeping processes under statistical control” and “creating good change” (innovating processes and products, or creating “breakthrough” performance as Juran put it) and the different management approaches and structures each requires. Most IT leaders have focused for years on management approaches more consistent with preventing bad change than creating good change. This has created a mindset that abhors risk taking.

I believe most of the “core” opportunities have been addressed in the typical global enterprise.  Sure, there’s always more to do (and the trap of saying “yes” to all the business requests to continually tweak and bolt onto core systems) but I believe you can move the business value needle significantly to the right by tackling more of the “edge” opportunities, and that is where, to Dion’s point, the Cloud (and its related technologies) offers real promise – now!

Dion Hinchcliffe had a superb post on Determining the ROI of Enterprise 2.0.  The post cites several authoritative and useful sources on the subject.  It also hypothesizes several reasons for the mostly “wait and see” attitude currently taken by most IT leaders and business managers.

But I mainly want to focus on the business case for Enterprise 2.0 – specifically, the pursuit of Return on Investment – ROI.

The Problem with ROI

Much has been said in the past about the limitations and challenges with ROI as a tool to evaluate many types of IT investments.  Dion’s post links back to an old post, The Case Against the Business Case by the father of the term Enterprise 2.0, Andrew McAfee.  McAfee in turn references the work of Kaplan and Norton and their Strategy Mapping book which points out that the value of intangible assets (human, organizational, and information capital such as databases, information systems, networks, and technology infrastructure):

…derives from their ability to help the organization implement its strategy… Intangible assets such as knowledge and technology seldom have a direct impact on financial outcomes such as increased revenues, lowered costs, and higher profits. Improvements in intangible assets affect financial outcomes through chains of cause-and-effect relationships.”

This is a really important point, but it sets up a very slippery slope. “We can’t attribute any direct financial impact to our Enterprise 2.0 investments…  so we won’t try.”  It’s the “not trying” here that drives me nuts!  It leads to:

1. Lazy thinking… which leads to…
2. Lack of clarity about what outcomes we are trying to drive to with our Enterprise 2.0 initiative… which leads to…
3. Lack of rigor in thinking through what behaviors we are hoping will change in order to realize the targeted outcomes…  which leads to…
4. A “if we build it, they will come” approach to Enterprise 2.0…  which leads to…
5. Failure of the Enterprise 2.0 initiative, “proving” there is no business case!

Value from Enterprise 2.0 can be a Self-Fulfilling Prophecy

Last August I wrote a post titled Measuring the Business Value of IT – Where You Can Win By Simply Trying! My point here was that the discipline of thinking through what we’d like to achieve, and how we might achieve it, dramatically increases our probability of achieving it.  As a trivial case, imagine the following conversation:

Let’s invest $1 Million to increase collaboration across our company.”

“Why?”

“Because we’ll be more innovative and productive.”

“How?”

“Hmmm – good question!  Well, we’ll tap into people’s ideas about how to improve our products and services.  And even how to improve our processes.  We could even tap our customers’ ideas!”

“How will we do that?  What will we need to enable that?  What will we need to shift to those kinds of behaviors?  Are there any aspects of our culture that might inhibit those things happening?”

“Hmmm!  More good questions.  Perhaps we need a bit more definition around what we are trying to do?  Perhaps we need to drive to some clarity on the outcomes we hope to achieve?  Perhaps we need to assess our ability to achieve those outcomes and clarify what will need to change for them to materialize?”

And so on.  Note, we aren’t building a business case in the financial sense.  This is not an ROI exercise – its a business value and outcomes exercise.  And this is the type of analysis that needs to be done to shift from the laissez faire “if we build it” to a more thoughtful, targeted approach.

(Image courtesy of SponsorMap)