Tag Archives: IT governance

Does Cloud+Consumerization Doom the Federated IT Operating Model?


The Federated IT Operating Model is Under Threat!

Today, most organizations employ some sort of Federated IT Operating Model.  Wikipedia defines a federation as:

…characterized by a union of partially self-governing states or regions united by a central (federal) government. In a federation, the self-governing status of the component states, as well as the division of power between them and the central government, are typically constitutionally entrenched and may not be altered by a unilateral decision of the latter.”

Typically, enterprise-wide or common applications, initiatives and infrastructure are a centralized (federal) responsibility, while local applications and activities are under the control of business units or functions.  This “federal rights/states rights” model has infinite variations.  Definitions of “common,” “enterprise-wide” or “infrastructure” are subject to interpretation, and these tend to change over time, with changing business conditions, leadership, technology and other forces.  There’s also inevitably a “shadow IT” phenomenon – sometimes quite large – where much IT activity happens outside the realm of IT governance.

Just as in countries with a federal governance model, the competing forces between state and federal rights pull and push over time, leading to an ebb and flow of centralization and decentralization.  This can be healthy – like an accordion, making sweet music as the parts are squeezed together or pulled apart.  It’s never static, but constantly responding to the forces of change – just as all living systems “breathe” in some way or another, and have their seasonal variations.

But every now and again, new forces surface and combine together to disrupt the gentle ebb and flow – the so-called Arab Spring comes to mind.

The New Forces of Change

IT governance is undergoing such a confluence of new forces.  These include:

  • Cloud computing – it is easier, faster and cheaper (on the face of it) to leverage the cloud to host applications and provide IT services (e.g., storage, transaction processing, data analytics) rather than have your federal IT group provide these services.  Much of this activity takes place in the “Shadow IT” realm.
  • Mobile computing – more of us are doing more via smart phones and tablets.  This exposes us to mobile applications and the many “app stores” including Apple’s and Google.  Getting an app is as simple as clicking a button – and many apps are free, or cheap enough to add to your mobile phone bill without feeling any pain.
  • The shift in the personal computing operating system – from Windows, et al, which can be controlled by the central (federal) IT department, to technologies such as Apple’s iOS and Google’s Android which are much harder (perhaps impossible?) to control centrally.  The genie is already out of the bottle, and it’s not going back any time soon!
  • Economic climate – the economic climate facing most businesses, whether in the US or just about anywhere else is in the doldrums.  This keeps people scrutinizing costs, prepared to make short term economic moves, even if at the expense of the longer term, and trying just about anything to get “unstuck”!  Such a climate tends not to favor centralization and federal power (just ask President Obama’s campaign advisers!) but empowers local forces and factions.

Beware the Unintended Consequences

So, what to do about it?  Here’s three options:

  1. Take a laissez-faire approach – a path of least resistance.
  2. Push back, hunker down and reinforce the federal model with more controls and stronger sanctions for “shadow” behavior.
  3. Adopt a “mutual adjustment” approach that navigates the stormy waters to constantly find the optimal balance.

From my perspective and experience, Option 1 has potential (likely?) unintended consequences.  We saw this when many central IT groups were slow to respond to the emergence of the Personal Computer.  When they did respond, it was generally via Option 2 – they tried to constrain them.  That drove a lot of rogue and shadow behavior and set many companies IT efforts back several years.

For most of us, Option 3 is the practical and pragmatic solution.  Let’s face it, there are all sorts of unknowns in terms of how these forces will play out over time.  We need some form of centralized coordination of infrastructure. However, the terms “coordination” and “infrastructure” must be defined clearly and re-defined from time to time as we gain experience with cloud computing and consumerization of IT.  There is not a right and wrong here – but a critical need for organizational clarity so that you are setting the bounds of infrastructure clearly and in a way that is appropriate to the times and to your business context.

Seven Steps to a Mutually Adjusting IT Operating Model

I believe IT leaders must approach this in the same way they would approach any needed change:

  1. Create and “market” a compelling end state vision.
  2. Surface and “sell” the cost of status quo or of going down the wrong path.
  3. Define a credible and palatable path to the future.
  4. Enroll key stakeholders in joining together on that path.
  5. Engage selected key stakeholders in the governance model.
  6. Surface and celebrate successes along the way.
  7. Take action to discourage deviations from the path.

Image courtesy of Charles Ayoub

Related articles
Enhanced by Zemanta
About these ads

To Whom Should Business Relationship Managers Report?


I recently received this question from a reader:

We are evaluating a strategy to centralize IT and implement Business Relationship Management (BRM) roles as part of the centralization. Where do you typically see the BRM’s reporting into in a centralized IT organization? Should they report directly in to the CIO, or can they be effective a level or two below the CIO?”

Rule #1 – Reporting Lines Are Weak Determinants of Success for the BRM Role

I have found reporting relationships to be a very weak determinant of success for the Business Relationship Manager (BRM) role. Far more important are the competencies (especially business knowledge and relationship skills) of the BRM and the maturity of the business executives they partner with.

Rule #2 – Heft Matters!

Notwithstanding Rule #1, the “heft” of the BRM role – the weight and implied authority it carries does matter.  There’s a couple of reasons for this:

  1. BRM’s are often on a CIO succession path (either explicitly or implicitly) – i.e., have the skills and wherewithal to be a CIO down the road, and the BRM role may be seen as a developmental step.  This has implications for who you chose to fill BRM roles, and for their career paths.
  2. The story a CIO tells the business executives when establishing the BRM role is along the lines of, “I am giving you one of my senior staff members to help surface, shape and manage IT demand so that you get the highest possible value from IT investments and assets. In return for this ‘gift’ I expect you to treat this BRM as a member of your management team.”

As a result, the most common reporting relationship for successful BRM’s is directly to the CIO.  In some cases, the BRM has a dotted line relationship to the senior business executive for the unit they represent.  In other cases, the BRM role is solid line to the senior business executive and dotted line to the CIO.

Rule #3 – Context Matters!

There are many other contextual factors to consider here, including:

  • What is the scope of the BRM role – is it primarily demand management (shaping, surfacing and managing business demand for IT)?  Or does the role include supply management, service management or other responsibilities?
  • Do the BRM’s act as Project or Program Managers for major initiatives?
  • Do the BRM’s sit on any governance bodies, such as Portfolio Management or Service Management?
  • How do BRM’s engage with the supply side?  How do they engage with Enterprise Architects?
  • How mature is IT supply?
  • Howe mature is business demand?

BRM’s Can Be ‘Game Changers’!

The BRM role is a tough one to get right, but from my experience, well worth the effort!  An effective BRM can:

  1. Elevate business maturity
  2. Ensure that IT resources are being focused on the highest potential value activities and initiatives
  3. Ensure that those initiatives capture the highest possible value

 

Graphic courtesy of Linda Galindo

Related articles
Enhanced by Zemanta

Changing the Culture of an IT Organization – One Wiki Page at a Time!


I’ve been a student of IT organizational culture since I began my management consulting career some 30+ years ago.  It’s wrong, of course, to generalize too broadly, but I’ve worked with literally hundreds of large enterprise IT organizations (i.e., IT organizations of 250+ members) and have seen more commonalities than differences.  Of course, within any IT organization, there are sub-cultures – architects are not the same as operations people or as solution developers – but again, there are more common threads than sharp differences.

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

Enhanced by Zemanta

Why It’s Time to Re-Think IT Funding Models! – Part 1 of 3


The Live 3rd Rail!

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.

Enhanced by Zemanta

The Decline and Fall of the IT Organization?


With apologies to Ed Yourdon for my plagiarism of his original the book title, published back in 1993, “The Decline and Fall of the American Programmer“.  (Though I don’t recall if Ed gave apologies to Gibbon for first using this line!)

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

Enhanced by Zemanta

When Words Just Don’t Cause Change


I was in a heated ‘discussion’ with a client recently.  We had completed an IT strategy refresh and one of the outstanding items was to review their IT Principles.  The IT leadership team had come up with some candidate new Principles, and I was being asked if I thought they were appropriate.

“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
Enhanced by Zemanta

Do You Have IT Organizational Clarity – Part 3


This picks up on Part 1 and Part 2 in this series on IT Organizational Clarity.

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.

Enhanced by Zemanta

From Business-IT Alignment to Business-IT Convergence


I’ve posted before on the emergent confluence between business and IT.  I’ve also discussed the shift from Business-IT Alignment to Business-IT Convergence as an aspect of increasing business and IT maturity.  I’ve noted (Goodbye, Shadow IT – Hello, Shadow IT) that ‘Shadow IT’, often viewed as a problem to be solved might be more appropriately recognized as embodying the clues to the new reality of business-IT convergence.

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.

Enhanced by Zemanta

Four Common Mistakes in IT Portfolio Management


Among my most popular topics, week after week, is Portfolio Management.  It’s a key discipline, especially crucial in driving Business-IT Maturity past the tricky mid-point where many IT organizations tend to get stuck.

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!

Enhanced by Zemanta

IT Organizational Implications of Cloud Computing


First off, let me make myself clear.  I firmly believe that Cloud Computing, in its various forms, is real, absolutely inevitable and will completely revolutionize the form and role of the IT Organization.  Some readers will look at that sentence and laugh – it’s like saying “day will pass into night.”  Obvious, beyond dispute, devoid of insight.  Others will also laugh at my opening proclamation – only in their case, because my assertion is completely ridiculous to them – beyond belief.  Of course, to many businesses, especially smaller and medium sized, Cloud Computing is already real, and has been for some time.  So, feel free to debate me (comments and opposing views highly welcome!) but I will stick with my beliefs on this.

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?

Enhanced by Zemanta