Monthly Archives: October 2010

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
About these ads

Do You Have IT Organizational Clarity – Part 2


My previous post introduced the topic of IT Organizational Clarity, discussed common symptoms arising from a lack of Organizational Clarity, and suggested two dimensions through which clarity can be assessed and improved:

  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

Enhanced by Zemanta

Do You Have IT Organizational Clarity?


This is the first in a series of posts on the subject of IT Organizational Clarity.  The general concept of  Organizational Clarity is clearly laid out in Patrick Lencioni‘s wonderful leadership fable, The Four Obsessions of an Extraordinary Executive.

I believe that Organizational Clarity is particularly important for IT leaders today as IT management and operational roles are increasingly dispersing throughout the business rather than being performed within a homogeneous IT organization.

There are a zillion analogies for illuminating what is meant by, and the importance of Organizational Clarity.  One that resonates for me is rowing boat racing. I attribute that to growing up in the UK and getting excited about the annual Oxford and Cambridge Boat Race (I lived on Oxford Gardens in London, so it was always clear which team I was supporting!)  The sight of a rowing boat, with 8 rowers and a coxswain sitting at the rear, steering and uttering commands to help the crew keep the cadence and stroke rating, is a compelling image.  When all the rowers are in perfect harmony and staying on course, there is enormous power in the boat.  If the coxswain screws up, or any of the rowers don’t follow the instructions, havoc reins and the boat slows way down or goes way off course.  I think of IT organizations that lack organizational clarity as the slow boat, or even worse, the fast boat heading in the wrong direction!

Common Symptoms Reveal Lack of Organizational Clarity

From my consulting and research work, I will assert that the symptoms of the lack of Organizational Clarity are common and prevalent.  How often do you or your colleagues say or hear:

We Don’t Communicate Well!”

Not only has virtually every client I’ve worked with raised this complaint, but I don’t think I’ve ever seen an IT organization that claims, “We communicate really well!”

This is a non-trivial symptom.  It leads to redundant work, leakage of business value (i.e., value that should have been captured, could have been captured, but is not captured) and a general sense of confusion and disorientation.  For the beneficiaries of IT work, it contributes to a poor customer experience – “The left hand doesn’t know what the right hand is doing!”

We don’t have clear accountability!”

This is another common symptom – failure to be clear on who is accountable for what, and, more to the point, what happens when something goes wrong.  This is often (and unfortunately) referred to as, “Not knowing who’s throat to choke!” but is probably more constructively thought of as, “Not knowing what actions to take to ensure that this error is never repeated!”

This symptom also means that managers and individual performers often do not understand how their work contributes to the overall mission and vision for the IT organization, and, more importantly, how it contributes to the success of their internal and external customers.

We exist to support the business!”

This common misunderstanding leads to the ‘order taker’ mentality, and an IT organization that is always extremely busy (to the point of rampant overwork!) and yet is seen by the business as adding little to no value.

Don’t Attempt to Address the Symptoms Directly!

It is essential to recognize that these are symptoms and not root causes in of themselves.  You cannot solve the communications issue by mandating or even organizing for better communications.  I’ve lost count of the number of IT leadership teams I’ve worked with who talk about putting a marketing/communications specialist on their staff “to address the communications problems.”  I’m not saying this is necessarily a bad idea – I’ve posted before about the importance of bringing marketing skills and disciplines to IT management.  But adding such a role with the purpose of ‘fixing communications’ rarely, if ever, works.  Communications problems are symptomatic of a lack of Organizational Clarity – not just for the IT organization as a whole, but for its ‘moving parts’ such as IT Infrastructure, Enterprise Architecture, Solutions Delivery, and so on.

Similarly, you cannot address the accountability issue by simply trying to mandate accountability.  Unless a given IT Capability has clear goals, service definition and guiding principles, and the appropriate processes, roles, competencies, tools and technologies are in place, it’s little use trying to tie accountability to anything!

Two Dimensions of Organizational Clarity

Improving organizational clarity – and in turn increasing focus and effectiveness – must be tackled along two dimensions:

  1. Bounding scope appropriately, or defining the ‘unit of analysis.’  An appropriate unit of analysis is commonly referred to as “an IT Capability.”  Typical IT organizations can be described through 7-9 Capabilities, such as IT Infrastructure, Enterprise Architecture, Opportunity Discovery, Solution Delivery, Portfolio Management and so on.
  2. Defining Capability Characteristics, including Purpose, Commitment, Ability and Accountability.

In the next couple of posts, I will drill into these two dimensions as a means of describing IT Organizational Clarity and how to measure and achieve it.

Image courtesy of What’s Running You

Enhanced by Zemanta