Category Archives: Key Frameworks

A collecation of frameworks that I’ve come across that help cast light on the journey to IT 2017.

ITIL and the Business Relationship Manager: Avoiding the Performance Trap!


order-taker

I have good news, and I have bad news!

The Good News…

The IT Infrastructure Library (ITIL) 2011 edition and the ISO/IEC 20000 standard for IT Service Management formalized the existence of the Business Relationship Manager (BRM) role and corresponding Business Relationship Management process as a new best practice and international IT Service Management standard requirement.  This is good – for professional BRMs around the world, for the IT profession in general, and for improving the business return on IT investments, as technology becomes ever more deeply embedded in business processes.

The Bad News…

(And I know I will get hate mail and lose readership for saying this, but…) As defined by ITIL, the BRM role comes off as somewhat tactical – not something to get business leaders salivating over their new partnership with IT, nor hungry to innovate business products and services!  Let me be clear – the ITIL vision of BRM is necessary – but from my experience, it is insufficient to drive real business value beyond a certain point.  It will help an IT organization with poor service quality get better.  But it will not help an IT organization with good service quality to excite and delight their customers with the new business capabilities that are enabled by information and information technology!

Business Relationship Manager Role

I’ve posted extensively on this role in the past – the BRM is a bridge between the IT organization and its business clients (just as a good CIO is a bridge between the IT organization and corporate leadership).  As such, it both represents the business clients to IT, and IT to the business clients.  This role has surfaced over the last 10 years or so and Gartner predicts that the fraction of IT personnel dedicated to Relationship Management and Change Leadership functions will reach as much as 15% by the end of 2013 and grow up to 20% by 2016.  LinkedIn hosts two groups dedicated to the BRM role.  One group – IT Business Relationship Management - currently boasts over 1,800 members.  The other group, Professional Business Relationship Managers currently has over 2,600 members!  (In the interests of full disclosure, I co-manage the latter group.)

I’ve conducted a significant amount of consulting, assessment and training in the BRM space, including designing and leading BRM training and development programs for global companies with over 100 BRMs (as well as for those with fewer than 5 BRMs).  From that experience, and from my ongoing activity on the LinkedIn groups, I’ve seen two distinct ‘flavors’ of BRM – “Tactical” and “Strategic.”

BRM and Business-IT Maturity

To help understand “tactical” and “strategic” BRMs and how they’ve come to be, I’ll use my Business-IT Maturity Model (BITMM).  I’ve posted at length about the BITMM.  In its simplest form (see graphic below) the model represents both business demand maturity (highlighted in red to the left of the learning curve) and IT supply maturity (highlighted in blue to the right of the curve. These never move completely in tandem – sometimes demand is slightly ahead of supply, other times it is slightly behind.  If demand and supply get too far out of whack, there’s usually a change of CIO (or a turnover of the IT organization to an outsourcer!)

Slide1

The number of maturity levels is arbritary, but for simplicity let’s use three – business efficiency, business effectiveness and business transformation.  Where a company is at any point in time is a function of factors such as:

  • the industry it’s in
  • current business leadership
  • competitive and regulatory forces
  • quality of IT leadership
  • quality of service delivery

For example, the financial services industry tends to be highly information-intense, so is generally demonstrated higher business demand and IT supply maturity than say, manufacturing companies, which have traditionally been less dependent on information.  All that is changing, of course, as businesses and governments everywhere become increasingly digitized.

The ITIL Connection

Improving service delivery quality is where ITIL focuses.  According to its current owners (The APM Group Limited) ITIL is “the most widely accepted approach to IT service management in the world.”  Originally developed under the auspices of the UK Office of Government Commerce (OGC), ITIL is becoming a popular approach to service management.  Often loosely, and occasionally rigorously followed, ITIL documents processes and practices for service management.  This focus on service management is crucially important in moving IT supply maturity up from low Level 1 to mid-Level 2.

The Tactical BRM

The graphic below crudely cuts the BITMM in half.  The lower half is what I refer to as the “tactical” BRM space – focused on business efficiency and effectiveness.  The conceptual dividing line between these spaces is important.  Around the mid-point of Level 2 maturity, the learning curve changes direction.  This is also a common “sticking point” (see my earlier posts on “sticking points”) where IT organizations often become trapped and their efforts at performance improvement taper off.  In some cases, they actually fall back in performance.

Slide2

So, in the pursuit of service management quality, the BRM has an important role, establishing a strong business relationship with the customer by understanding their business and customer outcomes.   But the focus is service management, as opposed to the strategic possibilities for IT capability to enable new or improved business products and services.  Service management applies most to ‘steady state’ IT services – not to transformational projects and programs on behalf of business units.

The Strategic BRM

The upper half of the BITMM is the “strategic” BRM space – focused on business effectiveness and transformation.  While an IT organization must be careful not to slip back on IT service quality and customer satisfaction, simply delivering ever-improving services will not transform IT into a respected, value-producing business partner. Sooner or later, IT service management efforts reach a point of diminishing returns. Something quite different is then needed to further improve the business return on IT assets and investments.  While the “Tactial BRM” tends to focus on IT supply management processes and activities, the “Strategic BRM” focuses on business demand management – stimulating, surfacing and shaping demand for services, activities and initiatives with the highest potential business value.  The “Strategic BRM” works closely with her business partner to ensure that IT investments and capabilities yield real business value.

Leverage the Standard Frameworks – But Don’t Get Stuck

The message here is that it’s ok to leverage standards and frameworks such as ITIL, COBIT and TOGAF – but essential to do so with intelligence!  They have their place – and a context for which they were intended – that often being UK government entities.  Nothing wrong with that, but it tends to be a context of control – not innovation.  Control can help you get from low Level 1 to mid-Level 2 – but not to Level 3.  What kind of IT capability does your business need – controlling or innovating?

Thoughts on a postcard, please!

Graphic courtesy of giffconstable.com

Related articles
Enhanced by Zemanta
About these ads

The Keys to IT Demand Management


Once again, I’m posting in response to a reader’s emailed question.  The reader wrote:

While trying to understand the difference between Demand management, Portfolio Management and Project management from an IT Infrastructure Service delivery perspective, I stumbled upon your blog and found some interesting reads.  Could you please share your thoughts on how to define Demand Management for a service delivery company – what is in-scope and out of scope?”

IT Leaders Tend to Focus on Supply Management

Delivering IT products and services has been challenging since businesses first became IT-dependent.  There’s lots of complexity, layers of specialization, an unnatural separation of IT producer and consumer, and significant capital investments.  Exacerbating this is the typically high ongoing maintenance and life cycle costs, rapidly changing generations of technology, with resulting technological obsolescence.  As a result, IT leaders have focused far more on supply management – figuring out their supply chains, providing security, integrity and stable services, squeezing out costs,and so on.

Meanwhile, the demand side has typically received short shrift.  Demand chains are unclear at best, and complexities such as the IT infrastructure implications of supply activities and changing technologies are opaque.  IT planners have a hard time answering fundamental questions such as, “What’s in the pipeline for the next 6 months?” or, “What is our projected resource utilization for the next 6 months?”

There are also common problems where demand meets supply – IT delivers products and services that business users don’t understand, did not really want, or did want but do not know how to extract the business value.  It is generally seen that IT’s job is to “deliver” the solution, but not to ensure it is working to full effect.

So, What is IT Demand Management?

According to Wikipedia:

Demand management is a planning methodology used to manage and forecast the demand of products and services. In business, the term is used to describe the proactive management of work initiatives (demand) with business constraints (supply).” (Bold font added for emphasis)

I like to think of IT demand management as:

A set of disciplines, tools, and governance mechanisms designed to surface, stimulate and shape business demand for IT products and services in balance with supply constraints.”

In other words, given that IT supply is always limited, how do we surface and shape demand to get optimum business value from limited IT supply?

Key Elements of IT Demand Management

Getting demand management working effectively requires an orchestration of several techniques and processes – and ultimately, a moderate to high level of Business-IT Maturity (earned through the focus on supply management mentioned above).

The key elements include:

  • Portfolio Management is an important demand management technique and tool (and, if implemented properly, a governance mechanism).  Portfolio Management can help balance IT demand across time horizons (short versus long term), across risk/reward profiles (high risk/high potential return, low risk/low potential return), across business units or business processes, and across IT investment categories, such as IT projects and programs versus IT infrastructure.  Portfolio Management can make these balancing acts explicit so that they become strategic choices (Portfolio Planning) rather than the result of natural “drift.”
  • Product and Service Life Cycle Management.  In the world of IT, creating a solution is a fraction of the cost – maintaining and evolving it, keeping up with changing business needs and shifting technologies is costly.  Traditional accounting practices add to the load as depreciation of capital expenditures creates an ongoing drag on funding sources.  So, ensuring that life cycle costs are taken into account with the initial investment, and managing product life cycles to ensure that necessary investments are made, and unnecessary products and services are retired in a timely fashion is a key Product and Service Management function.  Also, maximizing ‘reuse’ of products and services – “why bring in yet another Customer Relationship Management system when we already have three” is a common refrain that often goes unanswered.  Finally, understanding cost drivers, and influencing business behavior towards ‘responsible’ consumption of IT products and services is an important part of the demand management equation.
  • The role of the Business Relationship Manager (BRM) – the key interface between business and IT.  The BRM is an important demand management channel.
  • My reader’s question asked about what Project Management has to do with IT Demand Management.  Project Management is mostly a supply management technique.  However, poor project management can negatively impact demand.  For example, I’ve seen business behavior that essentially says, “I will ask for more than I need because I know IT will screw it up!”  Or, “I will ask for as much as I can get because I know nobody is keeping count on the results!”)
  • Though not mentioned in my reader’s question, Program Management embodies an important set of both Demand and Supply Management disciplines, tools and governance mechanisms.  Program Management is a critical linkage between Portfolio Management and Project Management.
  • Effective demand management also requires agile supply capabilities.  This is one of the best reasons for techniques such as selective outsourcing and cloud computing – being able to flex up as demand increases and scale back when it wanes.

The COBIT and ITIL Trap

I’m generally supportive of frameworks such as COBIT and ITIL – there’s no really good reason to reinvent these wheels – they embody ‘good practice’ for IT governance and service management respectively.  However, they have to be customized to fit your environment, and many companies short-change this activity and end up with processes-in-theory, but not in practice.  In other words, the processes, control objectives, and so on that they think they have are not what people actually do!

Another problem these frameworks can induce is deluding their proponents into thinking that tools and processes solve the problems of demand management.  Yes – you need clear, transparent demand (and supply) management processes, and these can certainly benefit from good frameworks and tools.

However, effective demand management hinges on strong business understanding and buy-in, highly skilled Business Relationship Mangers (or whatever you call people in that role) and robust business-IT governance.  In particular, governance must address how demand is justified, funded, and how benefits are tracked and accountability held for them.

 

Graphic courtesy of Vendeka

Related articles
Enhanced by Zemanta

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


This is the 3rd in a series on assessing IT Capabilities.  (See Part 1 and Part 2)

A Quick Recap

Part 1 introduced some assessment principles I’ve found to be important.  Part 2 defined the term IT Capability, presented a potential landscape, or normative model, if you will, for IT Capabilities, and discussed ways to determine what IT Capabilities are needed.

In this part we will examine assessment dimensions, options and ratings.

Assessment Dimensions

Figure 1 – Capability Assessment Dimensions

Figure 1 shows a capability assessment approach that uses 4 top-level dimensions – Purpose, Commitment, Ability and Accountability. Each dimension is decomposed into lower (leaf) level dimensions.  Purpose, for example, is a function of how clearly and effectively the service(s) produced by a capability are defined, and how clearly the goals for that capability and principles by which the capability operates are defined.

Note, there is a hierarchy implied among the top-level dimensions.  It is unreasonable to expect management commitment to a given capability if the purpose and goals for that capability are unclear or inappropriate.  It is unlikely that appropriate ability is in place without the necessary management commitment.  It is unreasonable to expect clarity of accountability for a given capability if ability is lacking.   In practice, I don’t usually disclose this hierarchical relationship until the assessment is underway, when I do use it as a validation mechanism.  For example, if the assessment team is scoring Accountability as fully in place, when they’ve scored Purpose or Commitment or Ability as not in place or only partially in place, then I know I need to challenge the team, and probe for the inconsistency.

Assessment Options

The multi-level assessment dimensions provide several options for the assessment method:

  1. Assess a capability at the top-level, but use the leaf levels to clarify what is meant by the top-level.  For example, I can assess the degree to which the Purpose of a given capability is in place by thinking about the effectiveness and clarity of the Service Definition for that capability, and the quality of the Goals and Guiding Principles for that capability.
  2. Assess a capability at the leaf level dimensions.
  3. Mix and match between top-level and leaf level dimension based upon the needs (purpose and goals of the assessment) and feasibility (available time, available knowledge) of the assessment situation.

Assessment Ratings

For any capability, for each dimension, a rating can be assessed as follows – the capability dimension is:

  • Fully in place – this is our universal practice and will be found to be used consistently, with few, if any, exceptions.
  • Mostly in place – this is common practice, though is not universal or not consistent, or there are frequent exceptions.  We know how to do this well – but we need to get better in practice.
  • Partially in place – this is not common practice, though we have many of the necessary characteristics, but not all of them.  We have some work to do to strengthen the capability as it exists as common practice.
  • Not in place – we have few, if any, of the necessary characteristics.  We have a great deal of work to do to develop this capability.

Note, there is clearly room for interpretation in these ratings.  This is more art than science, and for most IT capabilities, we are not dealing with highly mature processes and statistical process control!  From my experience, that is ok, and is why in Part 1 of this series that I said that my preference is to use a facilitated self-assessment approach – pull together a team of practitioners, customers and subject matter experts and facilitate them through the assessment.  It is usually the dialog this generates that has the most value, and leads to the insight and commitment from the team to initiate and sustain improvement efforts.  More on this in Part 4.

Assessment Dimension Descriptions

Below are brief descriptions for each top-level and leaf level assessment dimension.

Purpose

Are purposes and goals for the capability clearly defined and well understood?

  • Service/Product Definition
    • Is there a clear definition of the business purpose served by the capability and how this service/product integrates or links with other services and products?
    • Is there a clear definition of business outcomes for the service?
    • Have the service providers been identified? (e.g., dedicated internal service providers, external service providers, project team responsibility)
  • Goals and Guiding Principles
    • Are the appropriate opportunities to use the capability defined?
    • Are the goals established for use of the capability and/or its service providers?

Commitment

Has organizational commitment been demonstrated in terms of senior sponsorship and management responsibilities?

  • Sponsorship
    • Is there adequate understanding, support and management commitment to sustain the use of the capabilities and/or services?
    • Is there commitment by example?
  • Delivery Management
    • Is qualified management in place to provide oversight and direction for delivering the capability or service?
    • Are mechanisms in place to ensure that service delivery will improve over time?
  • Change Management
    • Is a change management strategy and plan in place to overcome issues of organizational resistance?

Ability

Have the baseline processes, role requirements, enabling technologies and deployment capabilities been established?

  • Process Definition
    • Has a documented process been implemented to guide work activities?
  • Roles and Competencies
    • Are required competencies and specific areas of specialization defined?
    • Are appropriate service providers identified and trained?
    • Are training/skill development processes defined and provided?
  • Tools and Technologies
    • Are tools and technologies in place to enable effective execution of the work processes?
  • Deployment
    • Are the service providers organized, ready, and able to provide service?
    • Are charging and cost allocation mechanisms in place?

Accountability

Have criteria for success and related consequences been defined?

  • Performance Management
    • Have measurable criteria for individual and group performance been defined?
    • Have measurable criteria for evaluating business results been defined?
    • Have necessary measurement/assessment approaches been instituted?
  • Consequence Management
    • Has a program to ensure usage been established?
    • Are the rewards for success and penalties for failure defined, communicated and implemented?
    • Have individual roles been defined including their inter-dependencies and how performance contributes to overall success?

 

Please join me for the 4th and final part in this series!  And please do weigh in with your own experiences, observations or questions!

 

Graphic courtesy of Tarun Trikha.com

Related articles
Enhanced by Zemanta

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

COBIT – Good News… Bad News!


COBIT is described by its creators, ISACA, as a “Framework for IT Governance and Control.”  Celebrating it’s 15-year anniversary, COBIT provides an excellent framework for helping bring IT under control.  In ISACA’s own words:

COBIT is an IT governance framework and supporting toolset that allows managers to bridge the gap between control requirements, technical issues and business risks. COBIT enables clear policy development and good practice for IT control throughout organizations. COBIT emphasizes regulatory compliance, helps organizations to increase the value attained from IT, enables alignment and simplifies implementation of the COBIT framework.”

With Version 5 being released this year, COBIT 5 will consolidate and integrate IT value delivery and IT risk management into the COBIT 4.1 framework.

So, You Want to Increase IT Maturity?

For IT shops of relatively low maturity, COBIT provides an effective framework and body of intellectual capital for implementing or improving IT processes and controls.  It can help avoid a great deal of ‘reinventing the wheel’ that so many IT shops get into, developing IT processes from scratch, or living with processes that do not integrate properly and propagate IT organizational silos.  The danger here, though, is that simply licensing a set of process descriptions is by no means equivalent to adopting them.  If people don’t really understand the processes they are supposed to be following, or if they aren’t completely bought into the need for and value of those processes, then having scads of process descriptions and related documents is not going to ensure a controlled IT environment.

Oh, You Want to Reach High IT Maturity?

I have blogged at length about Business-IT Maturity and have described a simple 3-stage model of both Business Demand Maturity – the business ‘appetite’ for IT, if you will, and IT Supply Maturity – the necessary IT capabilities to satisfy business demand (at lower maturity) and to shape and stimulate business demand (to reach higher maturity).  I’ve also written several posts on what I refer to as ‘sticking points‘ or traps that IT organizations fall into when they are in the middle levels of business-IT maturity. (I’m reminded of the proverbial ‘gumption traps‘ that Robert Pirsig so eloquently describes in his exploration of the metaphysics of quality, Zen and the Art of Motorcycle Maintenance.)

Unfortunately, I’ve found that COBIT can easily create one such trap.  While it can be an effective way to get from Level 1 to Level 2 maturity (on the 3-stage model), it will not take you from Level 2 to Level 3, and can, in fact, inhibit movement towards high business-IT maturity.

Let me try an analogy.  Imagine a car driver who is taught how to drive around a city and diligently follow all the rules and regulations of the road, including speed limits.  Then put that driver into a racing car and expect them to keep up with other racing car drivers on a race track.  Not only will they be unable to keep up, they will likely wreck the car and hurt themselves, unaccustomed as they are to the finer points of fast driving, and unskilled in high speed steering techniques.  Note, the racing car driver is still perfectly able to drive in the city and be compliant with the rules of the road, she has learned additional skills to win races and avoid high speed crashes.  Our novice, city-trained driver has not learned these skills.

This is the COBIT trap – it will take you so far, but, absent further skills and enhanced processes, will not take you further.

I’m expecting this post to be controversial, and the COBIT bigots to attack my heresy, so please, bring it on!

Enhanced by Zemanta

The Major Drivers of IT Performance


This is a guest post by my valued and esteemed colleague, Roy Youngman.  This appeared this morning on his blog, and I loved it, so invited him to re-post it here.  Enjoy!

—————————————————————————————–

Half-Full Stadiums and IT Effectiveness?

I heard something on the radio the other week that I thought was clever and interesting. I was driving around casually listening to a sports talk show host (Colin Cowherd) lament over the dangers of large stadiums that are only half-full.  To make his point, Colin said he always believed in the following equation:

He then proceeded to make his point that people generally equate a good time at a sporting event to a loud, sold-out stadium more than a larger stadium with many empty seats, even if there are more people in attendance.  I do agree with his point, but more importantly, I like the way he made his case.  The use of a simple equation that depicts the relationships between a few major drivers of something we can relate to is really quite appealing and thought-provoking.

As luck would have it, a few days later my colleague, Vaughan Merlyn, and I were discussing the major drivers of IT Performance and how best to depict them.  Not just the performance of any one individual, but the combined performance of everyone involved in realizing the greatest potential from information technology across the entire enterprise.  I think we came up with a pretty good equation.  If you want, jump to the end of this post to see it, but  here is our thought process that leads to it.

Talent as a Driver of IT Performance

The first and most obvious driver of IT Performance is Talent – the total quantity and depth of competency of all your people.  The more people you have with useful skills, the better your IT Performance.  This one is so obvious, it hardly seems worth exploring.  What is not as obvious is that most companies seem to stop here – in other words, they equate Performance to Talent and nothing else.  These are the companies who answer every increase in IT demand with a plea for additional IT resources.  To them, there is no way to increase IT Performance without increasing the numbers of IT resources.

Coordination as a Driver of IT Performance

But there is more to IT Performance than just Talent!  The second driver of IT Performance is Coordination – how well do your people coordinate their activities.  This is a bit more subtle, but obvious with just a little reflection.  In his book Structures in Fives: Designing Effective Organizations, Henry Mintzberg states:

Every organized human activity – from making pots to the placing of a man on the moon – gives rise to two fundamental and opposing requirements: the division of labor into various tasks to be performed, and the coordination of these tasks to accomplish the activity.”

Coordination Costs are almost always understated because they are seen as a failing of management and no manager wants to admit they are part of the problem.  So instead, coordination failures are often conveyed as Talent shortfalls and blame is placed on some poor individual who silently learns how to behave as a victim of poor process.  Experts in process improvement should understand Coordination Costs, because it is a major source of Waste, something every good 6 Sigma Black Belt is trained to reduce.

Okay – so IT Performance is driven by the level of Talent and the Coordination of that Talent, right?  Well, yes, but we can’t stop there. There is another driver, one with incredible positive power, and one that process improvement black belts don’t understand and can’t deal with.  Think about this question: Is it possible for one team of people to substantially outperform another team of people when both teams have the exact same number of people with the exact same skills and the exact same coordinating mechanisms?  I bet you answered, “yes”. But why would you? Logic would suggest that performance should be essentially the same, so what could make a substantial difference?

Synergy as a Driver of IT Performance

The answer to this is a difficult concept, because it delves into human relationships and human motivators.  The best English word for it is probably Synergy, but sometimes even that word seems inadequate.  People who have an effective relationship with one another can anticipate one another’s needs, back each other up, build upon one another’s thoughts and even conceive things neither of them could have ever dreamed up individually.  Equally important, synergistic relationships are pleasurable and rewarding to people.  They are fun to be a part of and usually cultivate rapid growth to each individual involved.  As the network of such relationships expands throughout the team and beyond, the sum total of Performance moves well beyond that of a team with the same skills and same method of coordination.  Synergy, as hard as it is to measure and explain, is a very real positive driver of IT Performance.

Confusion as an Obstacle to IT Performance

Is there a negative driver, something that works to degrade IT Performance?  Unfortunately, yes.  As a consultant, it is something I witness almost daily at almost every client: Confusion – the breakdown in Organizational Clarity.  Patrick Lencioni describes the second discipline in The Four Obsessions of an Extraordinary Executive as “Create Organizational Clarity”:

An organization that has achieved clarity has a sense of unity around everything it does.”

I’ve seen it – skilled people who coordinate their activity and have great relationships with one another, and yet they struggle.  They struggle because they aren’t sure of their purpose.  What little direction they get seems almost intentionally ambiguous.  They feel un-empowered to make decisions because the values and principles needed to guide those decisions are non-existent or equally ambiguous.  They are confused but don’t want to admit it because being confused is viewed as a weakness by management instead of a weakness of management.

So there you have it, our IT Performance Equation:

Want to increase your IT Performance? Find ways to increase your Talent (the total quantity and strength of useful competencies), improve the Coordination of your Talent, increase the overall Synergy through better collaborative networks of effective human relationships, and decrease Confusion across the enterprise.

Which of these will you work on next year?

Enhanced by Zemanta

Do You Have IT Organizational Clarity – Part 4


This picks up on Part 1, Part 2 and Part 3 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 Part 3, I described the three different types of IT Capability – Value Chain, Aligning/Governing, and Enabling, and why the distinctions among these types is important.

In this final post in the IT Organizational Clarity series, I will discuss an IT Capability Assessment Framework.

An IT Capability Assessment Framework

There are four dimensions of IT Capability that contribute to IT performance and organizational clarity:

  1. Purpose – the degree to which the goals, values, desired business outcomes and guiding principles are defined and understood by those contributing to or benefiting from the Capability.
  2. Commitment – the degree to which organizational relationships and commitment are demonstrated in terms of sponsorship and clearly defined accountabilities.
  3. Ability – the degree to which baseline processes, structure and competency requirements, enabling technologies and measurement approaches have been established.
  4. Accountability – the degree to which criteria for success and related performance requirements have been defined and communicated.

Note, that each of these dimensions comprise lower level assessment attributes.

Hierarchical Nature of Assessment Dimensions

Also note, there is a hierarchical nature to the four dimensions.  Clarity of purpose for a given capability is needed to gain management commitment to that capability and to establish the organizational relationships – for example, between the capability, its providers and its customers.  Management commitment, in turn, is needed to ensure the abilities are in place for the capability to perform.  With clarity of purpose, management commitment, and the components of ability in place (i.e., defined processes; clear roles with clear competency requirements; appropriate tools and technologies; service providers organized, ready, and able to provide service; charging and cost allocation mechanisms) then accountability (performance management and consequence management) can be meaningfully defined and assessed.

The Mechanics of Capability Assessment

I have always found the assessment process to be as important, or even more important, than the results.  Towards this end, I’ve adopted a couple of principles when helping clients with IT Capability Assessment:

  1. Follow a facilitated self-assessment approach i.e., get the right people in the room and facilitate them through the assessment process, so that the results are their results, and the insights as to what should be compared with what is are theirs to understand and ultimately, to act upon.
  2. Assess against an anticipated future state – “What is our capability to deliver against the IT vision and anticipated demand?” rather than “How are we doing today?”  Ultimately, it is the future ability to deliver that matters, and people tend to be less defensive when they are assessing their ability to handle tomorrow’s needs as opposed to how they are doing today.

The other ‘mechanical’ question is the level of granularity at which to assess.  There are two degrees of freedom, here.  One is, the scope of capability.  You can imagine, for example, assessing an entire IT capability as a single unit (not very helpful!) More realistically, assessing the 8-10 top level capabilities that comprise the entire IT capability.  Or assessing the 8-10 sub-capabilities comprising any one of the 8-10 top level capabilities.

You can also adjust the level of assessment – for example, assessing against the four dimensions (Purpose, Commitment, Ability, Accountability), or assessing against the lower level attributes, such as Service Definition, Goals and Guiding Principles.

Figuring out the scope and level of assessment is part art, part science.  In general, start at the highest reasonable level, then drill down as assessment findings indicate a need to drill deeper.  I typically start with one assessment for the IT Value Chain capabilities (discover, deliver, sustain), and one for each of the Align/Govern and Enabling Capabilities – this usually means 7 or 8 assessment sessions.  I typically allow 2 hours per assessment, and try to conduct the assessments with teams of 8 to 10 people, representing individuals from the capability being assessed and from related enabling or aligning capabilities.

Similarly, I usually start with the top level dimensions, but make sure that the assessment teams have access to descriptions and definitions of the lower level attributes.  If we are unable to come quickly to consensus at the top dimension level, we will drill down to the underlying attributes.  Experience with a relatively small number of assessments will give you a feel for appropriate scope and depth.

It’s Not About the Assessment – It’s About Identifying the Gaps to Close!

While the assessment process itself can be extremely enlightening, assessment itself is not the end – it is a means to the end.  The key to an assessment is to gain clarity on where the biggest gaps are, in order to move from assessment to improvement.

 

Enhanced by ZemantaGraphic courtesy of Asia Society

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

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