Prevent Bad Change…

For all the change that IT organizations bring about for their customers and clients, IT people are generally resistant to change.  I think this resistance is deeply rooted in a couple of factors:

1. IT environments are full of technical complexity – layers upon layers of technology containing multitudes of interfaces and dependencies.  Change something over here and something over their is impacted – sometimes in subtle ways that may not be evident for some time, or until some other seemingly unrelated change is made.
2. IT professionals thrive by taking complex situations and reducing them down – ultimately, to zeroes and ones.  There’s no room for ambiguity in a digital system – as such IT specialists are conditioned to abhor ambiguity.  And yet change is full of ambiguity – what ‘has been’ is no longer, and what ‘will be’ is not yet stabilized.  The natural inclination, then, is to drive out the ambiguity, and typically, the fastest, safest path to achieve that is to revert to the status quo – ending the change before damage is done (or the changed state it reached!)

Meet the Culture Where it is – Or Where You Want it to Go?

This inherent tendency to ‘prevent bad change’ creates some tough dilemma’s when introducing social networking and collaboration capabilities such as Wikis.  Wikis thrive best where a culture is open and emergent – “enabling good change,” if you will.  As you design the governance mechanisms for a Wiki, you have some interesting choices.  For example:

• Do you allow people to create their own pages?  Or do you put controls on who creates and who edits pages?
• Do you allow all spaces to be open to anyone in the organization?  Or do you allow for “private” spaces, where a select few (such as an IT leadership team) collaborate?
• Do you allow people to display avatars that are humorous or ironic?  Or do you insist on “corporate photographs” from people’s security badges?
• Do you allow people to write in their unique voices – even if a little rough around the edges?  Or do you have a Wiki Gardener monitor pages and clean up the rough edges?

To be clear, I’m not talking about allowing people to violate corporate codes of integrity – potentially offensive or inflammatory graphics or text is clearly out of bounds and violations of such codes of conduct should swiftly be managed as performance management issues.  I’m talking about an open and emergent Wiki environment – complete with the bumps and hiccups it may contain, versus a more closed and structured Wiki, protected from potential ‘voices of dissent’ or the raising of challenging or tough issues.

Governance Designed to Meet the Culture Where it is

You can take the position that Wiki governance should be designed for the current state:  “We are locked down, deeply concerned about security and privacy.  We have to have special ‘standards of conduct’ and controls to keep things structured and secure.”

Governance Designed to Help Shift the Culture

Or, do you take the position that the governance should be designed with an eye to the desired future state: “We encourage open dialog and a thriving ‘community of adults’ – keep within our corporate code of integrity and help make the Wiki a safe, valuable and fun place to grow and share our enterprise knowledge about IT.”

Given the people responsible for approving Wiki governance will probably not have significant experience with the more open model, their inclination will be to ‘play it safe’ and design for the current state.  Unfortunately, that is likely to perpetuate the current culture and probably prevent the Wiki from becoming what they want it to become.  It make take one or two strong, visionary leaders to take the leap of faith, and allow a governance model that reflects their aspirations for the culture.

Graphic courtesy of Positive Change

Recently, a colleague said to me about a client, “It’s time to raise the subject of their IT funding model.  The current model is causing all sorts of dysfunctional behaviors!”  My response was, “You are right – but I really don’t want to go there just yet.  I don’t think they’re ready to hear that message, or, more importantly to tackle the ‘live third rail’ and do anything about it!”

I’m not particularly proud of my response – in some respects, it was ‘wimping out’ on an important client conversation.  On the other hand, I’ve had mixed results over the years in getting clients to tackle this issue.  Let me be clear – getting agreement that the funding model is broken and is driving dysfunctional behaviors is always an easy sell.  In just about every client I’ve ever worked with, the funding model is clearly broken!  In some cases, it’s slightly broken.  In most cases, it’s badly broken, with all sorts of bad behaviors as a result, including inefficient consumption, underspending on IT infrastructure, lack of value realization, an overly conservative IT portfolio, and so on.  But few CIO’s have the courage to tackle funding models – with so many battles to wage in the name of realizing business value from IT, the funding battle just seems too big, hairy, complicated and politically charged to take on.

Where I have had success, it has usually been thanks to one of a couple of conditions for success:

1. There was a strong partnership in place between the CIO and the CFO, or…
2. The CEO (or Chairman, or Board) recognized that the IT funding model was broken and wanted to change it to drive the right behaviors

What’s Wrong With IT Funding Models Today?

Actually, most of today’s IT funding models are riddled with problems, but the biggest issue is that they DON’T DRIVE RESPONSIBLE CONSUMPTION BEHAVIORS!

• Many IT services are essentially “free” (recovered as overhead costs and corporate ‘taxes’) leading to irresponsible behaviors.
• Other services that could increase the business value of IT (e.g., consulting services to identify and leverage high value opportunities for IT activities and investments) are dis-incented  (i.e., too scarce, too expensive, or, in many cases, not even available).
• Most pricing models lack transparency.  The ways that services are packaged and priced hide the cost drivers from the business consumer.  As a result, the consumer has no idea how to manage these costs, and wonders why IT bills fluctuate so widely.
• Most pricing models don’t reflect business value – often the bulk of the IT bill is for services seen as low value (e.g., basic desktop support).
• Some pricing models are just too complex!  If the clients don’t understand what they are paying for, why, and what they can do to control costs, the model is broken.  If clerical effort is being expended around the company to check on, decipher and challenge every IT bill, then the model is broken!

Decomposing the Funding Model

So, before we talk about how to change funding models, let’s take apart the underlying components and issues.

Pricing vs. Recovery

The first and most obvious distinction is between pricing – how we price IT services – and recovery – how we recover IT costs.  These are completely separate and distinct – and yet, sometimes get commingled unnecessarily.  Just because a services costs you $x per unit to deliver does not mean you have to charge some function of $x, or charge by the same units as the costs are incurred.  You may chose to ‘give away’ some services, or to charge different clients at different levels, or charge based upon units different from those you pay by.  Recognizing this separation between pricing and recovery gives you tremendous pricing flexibility – and the ability to think about consumption behaviors you’d like to drive, and price accordingly.  Then you can tackle the recovery side of the equation separately – and adjust pricing levels and recovery strategies to balance the budget, as it were.

IT Savvy vs. IT Literacy

The “IT Savvyness” of business managers and executives is a crucial factor in any and all IT value discussions.  This term was first coined by Professor Peter Weill at the MIT CISR.  It is quite distinct from the more common concept of IT literacy.  I can say that Fred is IT literate – he knows his way around Windows and the main Microsoft Office products and successfully installed his own WiFi local area network in his home.  This does not necessarily mean that Fred is an astute steward of IT resources – understanding how IT can really differentiate his business area.  Nor does it meant that Fred can appreciate the distinction between one-time and full life cycle costs.  Bill, on the other hand, struggles with his PC.  But he does appreciate the need for ongoing investment in IT infrastructure.  He does realize that the business owns the accountability for extracting value from IT investments.  Bill might not be very IT literate, but he’s quite IT savvy!

Business-IT Funding Principles

I’ve mentioned Principles in many other posts – they can be a great tool for surfacing some of the tough strategic choices, and then making those choices explicit.  Business-IT Funding Principles do this for the strategic choices around IT funding.  For example, one of my favorite IT Funding Principles is;

We optimize IT investments for the enterprise – not for individual business units.

Or, if you prefer:

We optimize IT investments for the individual business units rather than for the enterprise.

I don’t care in the abstract case which one of these you pick, but pick one and stick to it!  Hopefully, the one you pick will be consistent with your agreed business model, and the degree to which that model calls for common processes and/or shared information.

A less contentious example of an IT Funding Principle is:

Business units directly fund both business-specific IT projects and the steady-state IT expenses associated with the outputs of these projects, rather than funding common activities via corporate contribution or standard allocations.

The rationale for this Principle (all Principles should state the rationales behind them!) would be that IT capital and expenses should be funded by the party best able to manage the demand for the IT services and thereby the cost.  An implication of this Principle (all Principles should articulate their implications!) would be that services that are specific to a business unit, such as third-party maintenance fees, other maintenance support, desktop costs, and IT labor for service requests, should be borne by those business areas that consume the services and are best able to justify the cost relative to business value.

We will pick up on the underlying IT Funding components and issues in the next post.

For a blog entitled “IT Organization 2017″ and for a management consultant who has had a very satisfying professional career consulting to IT organizations, the title of this post may seem both extreme and inappropriate.  However, I use the title not just as a controversial ‘hook’ to attract readership, but as a sincere expression of what I think is happening today – and will continue to do so.  The traditional role of the IT organization is on the decline and will never return to the importance and business value impact it had over the last 50 years.  The good news is, there is a crucial new role emerging – and for IT leaders that can envision and lead the new possibilities, I believe there’s a bright new future – perhaps brighter than the traditional IT leadership role.

So, Who Screwed Up the IT Organization?

I’m not sure this is anyone’s ‘fault’ per se, or could have been avoided.  Rather it is a natural by product of technological evolution.  Back in the late 1800′s, many corporations employed Chief Electrical Officers.  Nick Carr gets into this nicely in his aptly named book, “The Big Switch.”

A hundred years ago, companies stopped generating their own power with steam engines and dynamos and plugged into the newly built electric grid. The cheap power pumped out by electric utilities didn’t just change how businesses operate. It set off a chain reaction of economic and social transformations that brought the modern world into existence. Today, a similar revolution is under way. Hooked up to the Internet’s global computing grid, massive information-processing plants have begun pumping data and software code into our homes and businesses. This time, it’s computing that’s turning into a utility.”

The shift from electricity as a highly specialized resource to commodity took about a decade as standards such as voltage, alternating current, plug and socket configurations, and so on were settled.  Once the standards existed, businesses could simply plug into a grid – electricity became a commodity, and the Chief Electrical Officers become extinct as the Dodo.

An Historical Perspective

The first commercial mainframe computers, the LEO were created in 1951 by J. Lyons and Company, a British catering and food manufacturing firm.  The idea of a food and catering company today designing and building it’s own computer is unthinkable!  I remember in the late 1960′s, businesses such as Massachusetts General Hospital were creating their own programming languages, data base software and teleprocessing monitors – activities that would be considered wholly irresponsible today.  I wonder if 15 years from now we will look back at the turn of this century and be bemused by the fact that typical companies of any size at all maintained IT organizations – in some cases, thousands of IT professionals – writing programs, tending help desks, and so forth.

So, What’s Happening to the IT Organization?

For many years the annual surveys of top CIO issues list business-IT alignment. It’s a noble and challenging goal – and it’s no longer the right goal! A combination of technology advances, advances in standards and architectures (mostly prompted by the Internet revolution) and the increasing IT literacy across the business means that the challenge has moved beyond Business-IT Alignment to Business-IT Convergence.

From Business-IT Alignment to Convergence

Let’s drill further into this convergence phenomenon. Today, many IT activities, including project management, information analysis, application configuration are devolving into Business Units while others are consolidating with support functions such as HR, Finance, etc.  Helping to drive this is the rapid consumerization of IT devices and services, with iPhone’s, iPads, Android devices and the like becoming an important window into business systems and information.  Further driving this is the increasing ‘IT Savvy’ and confidence with IT that business executives, line managers and workers (especially, knowledge workers) increasingly feel.  This is in part generational – people entering the workforce with high IT literacy, and in part a byproduct of people’s engagement through social media, e-commerce and so on.

From Owning to Sourcing IT Capabilities

The last decade or so has seen a shift from owning all needed IT capabilities (data centers, server farms, software teams, application development groups, desktop support, etc.) to sourcing these capabilities externally.  Today, traditional functional outsourcing is being continuously expanded, and now often includes Business Process outsourcing as well as the outsourcing of compute power, data storage, IT infrastructure, applications and platforms through the rapid rise of Cloud Computing.

Information is Becoming both Strategic and Implicit

Information is becoming an increasingly strategic asset.  There is compelling research data showing how companies are successfully embracing and competing on business analytics.  At the same time, data is also becoming implicit to business management and operations – increasingly representing what the business manages and how it manages. In many respects, the context for IT today is becoming less about IT and more about information – the ability to capture, integrate, interpret, predict, and act is increasingly the holy grail of competitive advantage – and that belongs in the business – not in a separate specialist group.

So, Where Do IT Capabilities Belong?

Now, I’m on dangerous ground, because the answer depends – on the nature of the business, IT savvyness of business managers and knowledge workers, and their vision for how they want to deploy and manage information and IT.  But, I’d argue that many IT capabilities belong in business operations.  For example:

• Business Process Management
• Business Analytics
• Project Management
• Satisfying Business Unit application needs

Other IT capabilities belong in the governance of the business.  This might include, for example:

• Enterprise Architecture
• IT Strategy
• Portfolio and Program Management

And finally, some IT capabilities should be centrally coordinated and shared. Examples here include:

• Common and shared IT Infrastructure
• Enterprise Applications

So, What Are the Implications for IT Leadership and the IT Professional?

I will save that for a follow-up post, but suffice it to say that most companies and their IT organizations are not quite ready for the shift I’m espousing (and, indeed, predicting).  And, I think it is the clear responsibility of IT leadership to help lead this revolution – ensuring that it is orderly and safe – ensuring that the business and IT professionals are fully prepared and able to take advantage of business-IT convergence.

Please join me in the next post on this topic – and in the meantime, please weigh in with your perspectives and observations.

Painting by Joseph-Noël Sylvestre: The Sack of Rome by the Barbarians in 410

“What Will You Do With The IT Principles?”

I asked, “What will you do with these IT Principles?”  The silence I was met with was palpable.  My client was too polite to say it, but I knew that in the silence he was thinking,  “Vaughan – you complete idiot!  A Principle is a Principle!  Having a Principle is the whole kahuna!  It has nothing to do with ‘what you do with them!”

The Pleasant Reassurance of New Words

This weekend, I saw a post by Seth Godin with the title above.  I knew I was going to like it – I like all Seth’s posts, and I LOVED this title!  This is what I found:

It’s a lot easier for an organization to adopt new words than it is to actually change anything.  Real change is uncomfortable. If it’s not feeling that way, you’ve probably just adopted new words.”

Short, and very sweet!

Giving IT Principles “Teeth”

I’ve posted before on the power of Principles, and in particular on Principles as a Problem Solving Tool.   To recap, there are three keys to making IT Principles valuable:

1. Pick a few (say between 3 and 9) ‘points of pain’ that you want to try to address.  By ‘points of pain’ I mean something that is a significant performance inhibitor – often, this will mean it keeps surfacing as a root cause of some important dysfunctionality.
2. Come up with a simple, direct and unambiguous statement that FORCES A CHOICE that would resolve the pain point.
3. (And this is THE MOST IMPORTANT KEY!) Identify what will have to change in order that behaviors will change to come into line with the Principle.

Let me provide an example.  You have constant tension and debate around how much of the IT budget gets sucked into maintenance.  You’ve had good success getting prioritization of major new initiatives based on business value, but it is ongoing maintenance of existing solutions that is nickel and diming you to death!  You drill into root causes, ask a lot of “why’s” and come up with the recognition that the planning for new initiatives never takes the full life cycle costs into account.

This meets key #1 above – it’s a real point of pain!  You come up with a new IT Principle as follows:

We manage all business solutions and technology investments based upon total value of ownership – including total life cycle costs.”

This meets key #2 above.  But this is where I feared that my client was going to stop.  And this is where Seth’s words of wisdom about words were so salient.  It was going to feel good to the client’s IT leadership team to draft the words in the Principles – to debate over the language.  I imagine that once they’d been agreed upon, they’d be printed on posters or perhaps handy wallet inserts.  And that somehow these words would change things.  They won’t.  We need to address key #3 – what will have to change for us to act in accordance with this principle?

What Has to Change?

As an example:

• The total cost of ownership of an IT asset and its value-contribution must be periodically calculated and tracked over time.
• Requires closer alignment between program planning, project estimating,  budgeting and benefits tracking processes.
• The cost of a new system should include the cost to retire the system it replaces.
• Application retirement must be an active process.
• The total cost of ownership must include both the business and technology costs of developing, deploying, and operating business solutions.
• Costs such as hardware, software, maintenance, security, monitoring, training and on-going support must be included in the total cost of ownership.

These changes will have implications for business-IT governance processes, structures and reporting.  There may need to be new Policies.  There may need to be changes to rewards and recognition.  There may need to be changes to IT audit procedures.  And so on.

Remember, as powerful as words can be, they usually need the strength of structural, process, governance, rewards and recognition change to bring them to reality.  What say you about this?

Image courtesy of Drop Ship Access

Related articles

• Some Consulting Principles to Live By… (vaughanmerlyn.com)

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.

The always-impressive Dion Hinchcliffe sums it all up perfectly in his post, “CoIT: How an accidental future is becoming reality“.  Hinchcliffe repurposes Computerworld’s Scott Finnie’s use of ‘CoIT’ as referring to the ‘consumerization of IT’ to a new term, ‘Cooperative IT.”  I’d like to humbly suggest yet another interpretation of CoIT as a shorthand for “Converged IT” – referring to a world where much of the work of the IT organization has converged with the business as a deeply embedded capability.

A Vision for CoIT

Hinchcliffe suggests some aspects for the vision of CoIT as embodying:

• Decentralized (or at least distributed) governance
• IT support that scales up to the new app/device proliferation
• Business led IT solutions with an enabling infrastructure

I think these are appropriate, though many details and realities to be yet worked through.  And, I believe, while the IT leaders who are most proactive in leading this shift will make some mistakes, they will also be the first to figure out the new realities and will ultimately make less mistakes and learn more quickly than their ‘ostrich’ counterparts who either believe this will all blow over, or that they can figure it out down the road.

What do you think?  Do you agree with Hinchcliffe’s vision?  What are you doing to exploit the emerging ‘converged’ reality of CoIT?

Digital Art: ‘Convergance’ by Wilby  courtesy of Iasos.

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!

For IT Leaders, the Cloud Changes Everything!

For me, the big question is, what does the migration to Cloud Computing mean for today’s IT organization?  What structural changes are necessary to successfully leverage Cloud Computing capabilities?  How quickly should you be moving IT services to the Cloud?  How does the Cloud impact the IT Service Portfolio and the capabilities needed to deliver those services?  What are the implications for IT competencies?  How does business-IT governance change in a Cloud Computing world?

I think these are important questions whose answers are not yet totally clear.  As I reflect back on the shift from mainframe to client-server computing, many IT organizations were less than stellar at anticipating needed changes.  As a result, they experienced more bumps and potholes in that journey than was necessary.  For example, for all that had been learned about back-up and recovery in a mainframe world, the onset of client-server computing created gaping holes in the IT organization’s ability to cope with data protection and loss at the Personal Computer level.  The same was true for the evolution from client-server to the web – many of the controls put in place for client-server computing were ineffective (and some even counter-productive) as more work moved to the Internet.

Which Aspects of Cloud Computing Could Bite Your IT Organization?

In the next few posts I will explore some of IT organizational implications of Cloud Computing.  Aspects we will examine will include:

• Mobility implications – both for the business user and the IT professional charged with enabling that user.
• The distinctions between Infrastructure as a Service, Applications as a Service, Platform as a Service, Development as a Service and Business Process Services and how these impact IT organizations.
• The distinctions between Public, Private and Community Clouds and their implications for IT.
• Accounting implications, including funding and budgeting.
• Implications for Business-IT Governance.
• Security and Privacy.
• Implications for the work teams and flow of work involved in requirements analysis to solutioning.
• Impact on Enterprise Architecture.
• Implications for IT Services and Service Management.

Please weigh in – let us know your experiences, issues and concerns about the shift to the Cloud.  Do you agree with my assessment that this shift is inevitable?  How fast do you see it happening?  What does it mean for you personally, and for your career?

• 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

Peter and his colleague and co-author Jeanne Ross recently published their latest book called IT Savvy: What Top Executives Must Know to Go from Pain to Gain.

This is an excellent and important book.  It is notably the first book by this duo written for the top executive community, rather than for IT professionals – the target readership for prior Weill/Ross books.  I’m well known for repeating the mantra, “Organizations get the IT they deserve!” This book really reinforces the leadership roles and practices that help converge business and IT.  The ideas are beautifully organized, clearly presented and convincingly illustrated by interesting case studies.

I don’t want to pretend that one book can, by itself, move you along the road to “premium return on IT.”  But it sure is a great resource and, most importantly, a way to educate your key stakeholders what it takes to get on the right road!

Practices that Earn a Premium Return on IT

The authors, building on 15 years of research, describe what they refer to as the “Three Obsessions of the IT-Savvy Firm.”  These are:

1. Fixing What’s Broken About IT.
2. Building a Digitized Platform.
3. Exploiting the Platform for Profitable Growth

Citing several case studies to illustrate their points and help make the practices real, they work through issues of business operating model and the IT implications of operating model choices: IT funding model, digitized platforms, governance, driving value, and leadership.

Read, Share and Discuss!

Read this book with the idea of sharing it with your business partners and stakeholders.  Set up or take advantage of current opportunities to drive dialog around the implications of IT Savvy to your organization.

I believe you will recognize in the IT Savvy book many of the practices, recommendations, and “vignette’s” that surface in this blog from time.  In fact, Peter and Jeanne’s work over the years, and my research experiences with Peter, has greatly influenced my belief system, and with it, my approach to IT management consulting, at least over the last 15 years!

Book Cover Image Courtesy of Harvard Business Press