How Good are your IT Capabilities and How Good do they Need to Be? – Part 2


This is the 2nd in a multi-part post on assessing IT Capabilities.  (See Part 1)

A Quick Recap

Part 1 introduced some assessment principles I’ve found to be important.

  1. The Process is more important than the results.  I’ve found facilitated self-assessments to be the most effective.
  2. The results must be actionable. An assessment must give you insight into what needs to be improved, with what urgency and in what sequence.
  3. The results must be multi-dimensional. For example, address performance, value delivered and health of a given capability.
  4. Process-based assessments only go so far – and may in fact be misleading! Not all IT Capabilities are process-based.  Some depend more on standardization of deliverables or the outputs produced by a capability, and some depend more on special skills and training. Concluding that a given Capability might be highly mature or highly immature might have nothing to do with its ability to deliver excellent results!

Capability Defined

There are several aspects to defining Capabilities:

  1. What is meant by “IT Capability”?
  2. What is the potential landscape of IT Capabilities?
  3. How do you know what IT Capabilities you need?

Let’s examine these in turn.

What is Meant by “Capability”?

Wikipedia defines Capability as:

The ability to perform actions. As it applies to human capital, capability is the sum of expertise and capacity.”

A couple of things to note about IT Capabilities:

  1. While Capability Maturity Models such as CMMI put processes as the central construct of a capability (and the key to capability maturity assessment), in practice not all IT Capabilities are inherently process-centric.  Some depend more on people’s skills and competencies (think Business Relationship Manager, for example) while others depend more on deliverables than they do on specific processes.  (For a more detailed treatment of this distinction, see Part 1 in this series or my earlier posts on Henry Mintzberg‘s seminal work on organizational constructs.)
  2. You don’t need to “own” any given IT Capability – you can “rent” it as in outsourcing or contracting, for example.
  3. Not all IT Capabilities exist in an IT (or IS) organization.  Some are embedded in business units or other organizations.  For example, the capability to chose, procure and maintain personal computing devices may belong to the business – think “Bring Your Own Device” or “BYOD” as this rapidly growing movement is often referred to.

What is the Potential Landscape of IT Capabilities?

I’ve covered this topic in some depth previously in my posts on IT Organizational Clarity, but as a quick recap, below is a normative, high-level IT Capability Model.

Normative IT Capability Model

One can debate the specific labels for each of these capabilities, but essentially, any enterprise that depends upon Information Technology to any degree needs each of these IT Capabilities.  Of course, the devil, as they say, is in the detail, and the detail exists in the drill-down decompositions for each of these high-level IT Capabilities.  We will get more into this in Part 3 of this series.

How do You Know What IT Capabilities You Need?

There must be a clear and explicit linkage from Business Strategy to needed IT Capabilities.  There are many methods for achieving and expressing this linkage, and this is the realm of strategy formulation.  At its simplest, a given Business Strategy will require a set of Business Capabilities.  In turn, most, if not all Business Capabilities will depend upon one or more IT Capabilities.  Common techniques for achieving this linkage include:

But, IT Must Not Only Satisfy Business Demand – It Must Stimulate and Shape Demand!

The big danger with most strategic alignment methods are that they are inherently reactive.  i.e., To enable “x” business capability or strategy, we need “y” IT capability.  But how do you know that the business strategy is properly informed by IT possibilities?  This is where the first in the Value Chain Capabilities (see graphic above) comes into play – Discovering Business-IT Potential – and where the role of the Business Relationship Manager is so key.  So, you don’t just need the IT Capabilities the business thinks it needs – you also need IT Capabilities that create IT “savvy” and equip the business to understand and fully exploit IT potential.

Coming Up Next…

In Part 3 of this series we will examine assessment dimensions and methods.

Graphic courtesy of LipheLongLurnERrdok

Enhanced by Zemanta
About these ads

How Good are your IT Capabilities and How Good do they Need to Be?


This will be the first in a series of posts about assessing the “goodness” of IT capabilities, both in terms of your current state (how good your IT capabilities are) and ‘desired’ state (how good they need to be).  We will get into the dimensions of ‘goodness’ as well as assessment methods.

I’ve been designing and facilitating IT capability assessments for over 20 years, and have conducted hundreds of them – both as part of multi-company research projects that generated a substantial base of assessment data, and through individual assessments as part of consulting engagements. Over that time, I’ve developed a number of assessment principles I’ve found to be important.

The Process Is More Important Than The Results

There are several aspects to this.

  1. People don’t like being assessed, but they love being part of an assessment process!  By and large, people like to know how they are doing, especially from an organizational perspective.  But they are mistrustful (rightly so!) of consultants or other ‘agencies’ that come in and assess them or their organizations.  So, I’ve always taken an approach where I am a facilitator of a self-assessment process.  I bring the process (which the client and I may agree to modify to accommodate specific contingencies), experience to help them through the process, and act as an impartial ‘judge‘ to resolve differences of perspective, opinion or interpretation.
  2. The process must be transparent.  If people don’t understand or buy into the process, they will never buy into the results!
  3. The process should be repeatable.  Like a meaningful scientific experiment, the process should lend itself to repetition with consistent results.  In fact, repetition over time may well be important to sustained investment in capability improvement activities.  Too many assessments are conducted, discussed and then swept under the table.  This is a travesty!  Not only is the assessment wasted effort, but it may also be that much harder, or even impossible, to get people to participate in future assessments.  “Why should I bother – the last time we did this it went nowhere!” is a fairly common refrain.

The Results Must Be Actionable

The results should let you know:

  1. What needs to be done to improve capability performance.
  2. Where the greatest urgency lies for capability improvement.
  3. What it will take for a given IT capability to be improved, and to what benefit.

The Results Must Be Multi-Dimensional

This actually gets to the question of “goodness.”  I believe there are three important aspects of “goodness” as it relates to IT capability:

  1. Performance – this gets to efficiency – what resources it takes to achieve a given result.
  2. Value – this gets to the effectiveness of an IT capability – what benefits are being derived from the capability.
  3. Health – the ability to perform and deliver value over time.  We’ve all seen heroics, where, for example, a project team moves mountains in the final weeks of a project by working 20 hour days, 7 days a week.  It’s a wonderful thing to behold, and sometimes is necessary and may even promote ‘good health’ for the organization as people pull together and participate in a ‘miracle’.  But it’s not sustainable.  Expecting people to perform at a sprint when the course is a marathon is both dangerous and demotivating.

Process-based Assessments Only Go So Far!

We are all familiar with the SEI CMMI type maturity assessment.  These typically assess a capability’s maturity as somewhere along 5 levels:

  1. Initial
  2. Managed
  3. Defined
  4. Quantitatively Managed
  5. Optimizing

I believe maturity assessments such as this are appropriate for capabilities that are heavily process-dependent.  These include IT operational processes – highly predictable, repeatable processes.  But, drawing from Henry Mintzberg‘s discussion of standardization many years back, (see Mintzberg’s “Structure in Fives: Designing Effective Organizations”) not everything demands standardization of work processes.  If the goal is to make work consistent, repeatable, predictable and of high quality, there are three approaches:

  1. Standardize the work processes
  2. Standardize the outputs – i.e., the deliverables from the process
  3. Standardize the skills – i.e., focus on the people and their training

Typically, all three types of standardization apply to varying degrees – the mix being a function of the nature and complexity of the work you are doing.  For highly complex work (think brain surgery) the emphasis is on the people, which is why surgeons go through years of training, board certification, residencies, and so forth.  It’s no use handing them a detailed process to follow and expecting an untrained person to achieve a quality result.  For work such as bridge building, the emphasis will be on the deliverables – various types of blueprint, work breakdown structures and so on.  For routine, sequential work, the emphasis will be on defining the tasks to be followed and the sequence in which to follow them.  Ideally, the work can be so ‘routinized’ that it can be automated.  (Think data center operations and the shift over the years to ‘lights out’ data centers.)

The graphic below illustrates this concept.  Detailed processes are great at helping manage work that is routine and sequential in nature (which is one of the reasons why ITIL has gained so much traction in the last few years.)  For work that is inherently collaborative, and may require more visual enablement, standardizing on deliverables may be more apparent (think discovery and solution delivery).  For work that is more complex and exploratory, training and performance support systems are more appropriate.

For more on the different approaches to standardization, see my post, “Are Your Processes Setting You Free?  Or Holding You Back?

Please join me for the next post in this series where we will drill further into assessment dimensions and processes.

 

Graphic courtesy of Take On Torah

Enhanced by Zemanta

Do You Need an IT Operating Model?


This post was inspired by some recent discussion on the IT Operating Models Group on LinkedIn.  Pär Nilsson, the Group’s moderator, posted the question:

What do you see as the cornerstone of an IT operating model?”

This question created some interesting discussion, from the insightful to the disdainful (but accurate!) observation that:

Operating Model is one of those buzz phrases that can mean different things to different people.”

Every IT Organization Has an Operating Model!

One of the noteworthy aspects of the discussion was that several participants seemed to view an IT Operating Model as something you may or may not choose to have.  I think that’s wrong – all IT organizations have an IT Operating Model.  The only questions, for me, are the degree to which the IT Operating Model is:

  1. Effective? (i.e., delivers what the business needs in the most effective ways)
  2. Efficient? (i.e., makes the best possible use of assets and resources)
  3. Clear to all those that depend upon it? (i.e., stakeholders in and members of the IT organization)
  4. Healthy (i.e., continuously improving and sustainable)

Way Beyond the Organization Chart!

In many IT organizations, the only explicit manifestation of the Operating Model is an organization chart!  This is an incredibly limited (and limiting!) way of expressing an Operating Model.  It says who reports to whom, but not what gets done or how it gets done.  It tells you nothing about decision rights, key metrics or the portfolio of services.  It tells you nothing about needed competencies or rules of engagement between functions and groups, or between the IT organization and its clients/customers/partners.

So, wherever you are, you do have an IT Operating Model.  You might not understand it.  It might be implicit rather than explicit. It might be badly broken.  But you still have one or you would not be able to ‘operate’.

The Cornerstone is Context-Dependent!

My response to the initial question was:

I think that all depends on the business context and business demand maturity against IT supply maturity. For example, for some environments, IT processes are the cornerstone; for others, it is business-IT governance; for others it is figuring out the proper balance between IT services that should be shared across business units, versus those that should be embedded in business units.  Ultimately, all these aspects (and many more!) are key – but you can’t address them all in one go, so figuring out where to start is the first trick!”

The Keys Are Organizational Clarity and Health

So, I believe that the keys to IT organizational performance are:

  1. Defining what a healthy IT Operating Model would deliver – we might call this the IT Strategy
  2. Defining how a healthy IT Operating Model would deliver that IT Strategy
  3. Ensuring that the IT Operating Model is clear and transparent to its primary stakeholders

And I further believe that very best way to achieve these is to engage those primary stakeholders in:

  1. Clarifying the IT Strategy
  2. Clarifying the IT Operating Model
  3. Continuously improving the IT Strategy and Operating Model

Web 2.0, Anybody?

And it won’t surprise any of my clients, colleagues or regular readers that I believe that the tools, technologies and sensibilities sometimes referred to as Web 2.0 can be an excellent enabler of IT Strategy and Operating Model clarification and continuous refinement.

Graphic courtesy of Kinsale

Enhanced by Zemanta