COBIT

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!

What is IT Renewal?

In the first post in this series, I discussed how information and technology are becoming ever more central to what an organization does and how it does it and how consumer technology is beginning to have a dramatic impact on enterprise IT. I referred to the actions an IT organization takes in response to these changes as “IT Renewal.”

In Part 2, I described three major opportunities for Cloud Computing to accelerate IT renewal:

1. Finding and validating new business opportunities.
2. Improving existing business capabilities.
3. Transforming how IT capabilities are managed and deployed.

I wrapped up the second post focusing on opportunity #3 from the list, arguing that IT Management is becoming a distributed activity that exhibits many of the characteristics of complex systems, where:

• Organization is a natural, spontaneous act;
• Emergent structure trumps imposed hierarchy and control;
• Creativity arises from variety and randomness;
• Relationships, porous boundaries, free flows of information and self-reference are essential to survival and growth.

These complex system characteristics lend themselves to the use of collaborative approaches to managing IT work – what I referred to as the “Five C’s” of Information Management.

The “Five C’s” of Information Management

As the management of information and technology becomes increasingly distributed and complex, five types of management activity emerge as important to the way work is done:

1. Collaborating
2. Coordinating
3. Connecting
4. Co-creating
5. Coalescing

Enabling the “Five C’s” in the Cloud

Because each of these activities is increasingly being conducted across time and space and across organizational boundaries, enabling them through flexible, scalable cloud solutions becomes an attractive proposition.

As an example, I’m currently working with a client who is refining their IT Operating Model so as to enable a new, growth-oriented business-IT strategy. They had determined that they wanted to support their IT work and forge stronger business relationships using Microsoft SharePoint. However, they are currently on SharePoint 2007 and recognized that they needed to move to SharePoint 2010 as their preferred collaboration and knowledge management platform. However, the upgrades to servers, licenses and related IT infrastructure was going to take 3-4 months, and a significant capital outlay. But, they did not want to lose the momentum they had already established in developing the new business-IT strategy.

As an alternative, we were able to set them up with a cloud-hosted SharePoint 2010 instance over one weekend, with zero capital outlay, and a very modest monthly cost that scales with the number of users, and therefore with the value delivered. Now, they are creating new levels of organizational clarity, establishing a continuously improving IT Operating Model, and experiencing new ways of working – collaborating, coordinating, connecting, co-creating and coalescing, against a set of Cloud-based software services.

Let’s take each of these in turn and see how they can help you “manage IT in the cloud.”

Collaborating on IT Work

Much IT work is performed through teams – increasingly distributed across geographies, organizations and time zones. This change forces a shift in work management from a document-centric (write-attach-email-review-attach-email, repeat ad infinitum) to a more collaborative Wiki-based approach, which has significant advantages:

• Wiki’s are inherently non-linear and encourage a ‘constructive informality’ that improves quality over time, drives organizational clarity and reduces or eliminates redundancy and contradictions. Wiki’s (well-managed!) let you stop wondering, “Is this the latest version? What was changed since the last version?”
• Wiki’s encourage multi-author collaboration. Whereas the typical document-centric approach has one or two main authors with everyone else in a review role, Wiki’s encourage a more collaborative approach to authoring – with higher engagement and understanding in the content.
• A Wiki approach dramatically simplifies search and discovery. The ability to hyperlink, tag, and use a well-factored semantic Wiki leads to content that is far more accessible, intelligible and searchable for all stakeholders.
• There are many good Wiki products available as SaaS, including SharePoint, Confluence, and MediaWiki.

Coordinating Activities in Time and Space

As IT work becomes more distributed, the need to coordinate activities in time and space becomes both increasingly important and challenging. And again, SaaS offerings are ideally suited to helping distributed teams coordinate their activities, including:

• Real-time communication and collaboration – e.g., IM, Google Wave
• Collaborative Project Management – e.g., Bamboo, BaseCamp
• Desktop videoconferencing – e.g., Go To Meeting, WebEx

Connecting People and Ideas

The need to identify and connect people and ideas is important to innovation and learning. As IT work becomes more distributed, cloud-based SaaS solutions become effective ways of connecting people and ideas, through tools such as:

• Social Networking – e.g., FaceBook, LinkedIn, Plaxo
• Mind Mapping – e.g., MindMeister, WebBrain, Bubbl.us
• Virtual Electronic Whiteboards – e.g., FlockDraw, Colabopad
• Social Network Analysis – e.g., Netminer, InFlow
• Innovation James – roll your own using a combination of cloud-based services

Co-Creating Experiences

As business and IT converge, opportunities emerge to co-create experiences with customers, consumers, suppliers, business partners, etc. New types of SaaS solutions for co-creation include:

• Modeling and Simulation – e.g., Creately, FlexSim, Second Life
• Prototyping – e.g., iRise, Dreamweaver
• Virtual Worlds – e.g., Second Life, There.com (currently closed)

Coalescing Around Ideas and Reaching Consensus on Decisions

With the increasing distribution of IT work comes the need to poll stakeholders, tap into sentiment, coalesce around ideas and reach consensus around decisions. And new approaches and supporting tools emerging into this space, including:

• Polling – e.g., Survey Monkey, Kluster, IdeaScale
• Group Decision Making – e.g., Resolve
• Prediction Markets – e.g., NewsFutures

Summary

One the one hand, the increasing complexity of the world of IT management, and the convergence between the work of professional IT organizations and their customers and consumers can seem like a daunting challenge for IT leaders – a threat to the order, security and stability they have worked so hard to achieve over the last 50 years of enterprise computing. On the other hand, the shift to the “information prosumer” and the distribution of IT work is forcing a new way of managing IT activities – across organizational boundaries, across geographies and across cultures.

Just as these shifts are taking place, the Internet as a computing platform and the rise of Web 2.0 and 3.0 capabilities promise a new set of rapidly evolving tools – available as Web services – accessible from mobile devices – and affordable by even the smallest business or even the individual consumer.

I believe these Cloud-based IT management capabilities offer a way for IT leaders to step ahead – to take the lead in learning how to deploy and take advantage of these services – and help to drive business-IT convergence for their organizations.

Illustration courtesy of Suzanne Lebeda at Adirondack Artists’ Guild

Related articles

• Leveraging the Cloud to Accelerate IT Renewal – Part 2 (vaughanmerlyn.com)

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

So, Who Screwed Up the IT Organization?

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

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

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

An Historical Perspective

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

So, What’s Happening to the IT Organization?

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

From Business-IT Alignment to Convergence

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

From Owning to Sourcing IT Capabilities

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

Information is Becoming both Strategic and Implicit

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

So, Where Do IT Capabilities Belong?

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

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

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

• Enterprise Architecture
• IT Strategy
• Portfolio and Program Management

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

• Common and shared IT Infrastructure
• Enterprise Applications

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

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

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

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

What Does ‘Agility’ Mean to an IT Organization?

Wikipedia defines agility as:

The ability to change the body’s position efficiently, and requires the integration of isolated movement skills using a combination of balance, coordination, speed, reflexes, strength, endurance and stamina.  In business, agility means the capability of rapidly and efficiently adapting to changes.”

From the perspective of the research project, we defined IT agility as:

The ability to rapidly and easily incorporate new technologies and methods into the way the IT organization operates, thereby having the capability to effectively sense and respond to changing business conditions in a timely manner.”

Why Does Agility Matter to an IT Organization

Simply stated, most business executives I speak to feel that their IT organizations lack agility! To paraphrase the typical response:

Things take too long to get to the point where they are delivering business results, and the IT organization typically seems to be behind the curve on emerging technologies!”

You may disagree with this statement, but I think most of you will agree that it is the common perception of your business executives.  In a world that seeks instant gratification, that is a value that is not typically embraced by IT organizations – and perhaps it should not be?  In a world where the business and competitive context can change almost overnight, increasing IT organizational agility should become an active goal.

So, What Have We Found?

The data is still coming in, and the numbers being crunched, but a couple of early observations:

1. Your perspectives on Enablers and Barriers to agility depend upon where you sit.  In a federated IT Operating Model (some centralized, some decentralized), those that sit in the central camp tend to see shared IT capabilities as enablers of agility, whereas those in the decentralized units tend to see shared capabilities as inhibitors to agility, and seek more freedom from the ‘mothership’ in order to increase agility.
2. Even with the definition of IT organizational agility provided as part of the research, its meaning is very squidgy and Rorschach-like – you read into “IT organizational agility” what you want to see.
3. Fans of Agile Development equate IT organizational agility to Agile Development – they are essentially one and the same to them.  On the other hand, when you drill into what teams are doing with Agile Development, what you find is all over the map.  To some teams, it is a license to take short cuts, no matter what the consequences!
4. Governance is desperately misunderstood!  This will be a subject of a separate post (or two!), but what I am seeing as I pour over the research findings indicates some governance perceptions that are way off base.  Again, it depends where you sit, but while some see governance as an agility enabler, others (in the same organization!) see it as a major barrier!
5. The very different perspectives on what is meant by IT organizational agility and why it is important is quite troubling – if you can’t agree on what it means and why you want it, you are unlikely to increase your IT organizational agility!

Three Ways To Increase IT Organizational Agility

So, given those findings, here are three relatively ‘quick wins’ that will at least get your leadership talking in the same direction (excuse the mixed metaphor!)

1. Get clarity on what IT organizational agility means to you.

Don’t get wrapped up in academic definitions – focus on what it means to your organization.

• What are your business drivers for IT organizational agility?  If you were more agile, what good things would you be capable of that you aren’t today?
• Complete the tool in our research survey and use the 6 Domains of IT Agility to drive discussion internally on your enablers and barriers to agility.
• Get to a consensus on the factors that need to be worked on for increased agility.
• What do you see as the connections between agility and collaboration?
• What do you see as the connections between agility and knowledge management?
• What do you see as the connections between agility and Enterprise Architecture?

2. Identify where Agile Development fits in and how you will exploit that without increasing project risk.

Get clarity on Agile Development – what it is, and what it is not!

• How do you define Agile Development for your organization?
• When, where and how should you use Agile Development?
• How will you define and monitor success?
• What ‘unintended consequences’ will you look for and how will you mitigate against them?
• What else is needed to increase IT organizational agility above and beyond Agile Development as you’ve define it?

3. Get to a shared understanding of IT Governance.

Get clarity on how you define IT Governance.  Again, don’t get wrapped up in academic definitions – define what it means to your organization.

• What are the various aspects of organizational governance in your organization? (Don’t be limited by “formal” structures – consider aspects such as empowerment, decision rights, accountabilities, processes, culture of compliance, consequences for compliance or lack thereof.)
• What is it about your IT governance that enables agility?
• What is it about your IT governance that inhibits agility?

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.

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

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

This client has shown trust in us and has engaged us to help them.  Complaining about them behind their backs is not helpful and can be potentially disruptive.  Any time you say “The client just doesn’t get it!” you are pointing to your own inadequacy in helping the client to ‘get it.’  So stop bitching and figure out how to help the client!”

A Caricature of Frustrating Client Behavior

This is a caricature of the kinds of discussion and debate we sometimes witness in our less mature clients.  The specifics are fictional – the general tone is real!

Consultant: “This is the role interaction model we are suggesting for the points of engagement between business demand and IT supply – where your Relationship Managers, Business Architects, and Solution Managers interact with their business executives to surface or explore new opportunities.”

Client Executive #1:  “I think the arrowheads should be larger!”

Client Executive #2:  “I’m not so sure about that – I was thinking they should be smaller!”

The meeting continues and becomes increasingly heated, often veering way off track.  The meeting (which started late) never produces any clarity around this important issue.  The 40 minutes of actual time we can wring out of a scheduled 1-hour meeting surfaces no light – just heat, as trivial and largely irrelevant issues get debated, while the important questions are dodged or swept under the table.  The meeting wraps up with an acknowledgment of the need to schedule more time to get into this important topic.  Unfortunately, the ‘important topic’ in question is the size of the arrow heads!

Of course, this is a caricature, and in some respects an exaggeration of the specifics.  And you could fault the consultant in this case for allowing the dialog to go so far off track.  But in many ways, it is real.  We have found time and time again, that clients who are unsure of themselves around a given topic will sometimes be quick to debate trivial points, sometimes ad nauseum, rather than wrestle with the real issue.  Over the weeks we are working with this type of client, significant chunks of otherwise productive time are wasted on trivial debates as a means of deflection and obfuscation.

Are You Debating the Trivial?

What proportion of your management discussions are around issues of significance rather than the trivial?  How does this tendency impact overall IT performance?  What can you do to change the behaviors underlying this dysfunctionality?

Image courtesy of Amrit Williams Blog

I recently posted on my time in Portland, Oregon, and my love for the city.  I also mentioned the anomalous ‘street people’ scene.  Portland is so squeaky clean and seemingly well-run, and yet it seems to tolerate a thriving street person scene – some bordering on aggressive pan handling.  I personally never felt threatened by this, but it was strange that these misfits are so tolerated.

From Portand’s Streets…

A recent Portland Tribune front page article asked, “Would Rudy Giuliani Put Up With This?” under a picture of a lavishly tattooed street person sitting in front of a rather blunt epithet I won’t quote on this blog.  The article recounted the history behind the remarkable street and crime clean-up that took place under Rudy’s watch.  The article said:

Then, in 1994, Police Chief William Bratton and Mayor Rudy Giuliani, within a matter of months instituted Draconian measures that changed the (New York) street culture in ways that remain in place today.”

The article goes on to recount:

Bratton, who initially led the transit police, first cracked down on subway turnstile jumpers and panhandlers – arresting them.  In the process, they found that many of those arrested had outstanding warrants for more serious crimes.  Making quality-of-life arrests on the subway reversed the momentum of declining ridership… and created a momentum that allowed law-abiding New Yorkers to reclaim public transportation.”

…to IT Meetings

So, what’s the connection to well-managed IT organizations?  I’ve noticed over years of consulting that well-run IT organizations pay attention to the apparently small things – such as the discipline around scheduling and running meetings.  Meetings start and end on time, have pre-published agendas, published results, with action items and assignments.  They make sure meetings are necessary and productive, and that the right people (and only, the right people) are there.

Yes, I know we all tend to complain about “too many meetings.”  But the reality is, for knowledge workers (yes, that’s us) meetings are an important part of our work.

IT Leaders Model the Culture They Want

IT cultures are set from the top.  When the CIO and the IT leadership team pay attention to meeting discipline – modeling excellent behaviors, and calling out sloppy meeting behaviors – just like turnstile jumping, people pay attention, discipline increases, and everyone benefits.  On the other hand, when turnstile jumpers are tolerated – i.e., sloppy meetings are taken as ok, then discipline around all sorts of behaviors degrades, and IT performance drops.  I guess there’s an analogy with ‘quality of life crime.’  Being late for a meeting is not a ‘crime’.  But in terms of its impact on organizational cohesion and performance, it’s a ‘quality of organizational life crime.’  So is a lack of clear roles and accountabilities.  So is an ‘entitlement culture’ where poor performers are tolerated.

Like a well-run ship (sorry, too many analogies here!) a well run IT organization is disciplined at the most fundamental level.  It’s a manifestation of mutual respect and collective accountability.  When I turn up late for a meeting at which I’m needed and expected, I am disrespecting my colleagues.  The ones that show up at the appointed time sit there twiddling their thumbs.  It’s as if the message I want to send is, “My time is so valuable I couldn’t be here on time – and all your time is so worthless, it’s no problem if y’all sit there waiting for me.”

And, of course, late meetings beget late meetings – these things escalate.  I’m always bemused and angered when a plane is late “Due to a late arrival of the inbound flight” like that’s a valid excuse.  As an Atlantan, most of my flying over the years has been on Delta.  Each time they announce this excuse, it’s as if they are denying any culpability in the late flight.  “It wasn’t our fault – it was the damn inbound flight you should blame!”  Or, “The ground crew is not all here yet!”  So, I wonder, who was responsible for the late inbound flight?  Yep – Delta!

Enough ranting.  You get the point.  If you want to do a ‘quick and dirty’ IT Capability Maturity assessment, look no further than at how well you run IT meetings – including starting and ending on time.  As goes the meeting discipline, so goes the IT capability performance – and the credibility you have with and value perceived by your business partners!

Process Culture is REALLY Important!

There are some fundamental disciplines that are at the heart and soul of the IT profession – project management, program management, portfolio management, service management, product management, and Enterprise Architecture.  All these disciplines depend upon the “meta-discipline” of process management.  It is easy in an age of Web 2.0, Enterprise 2.0 and Cloud Computing to take these fundamental disciplines for granted.  This is a massive mistake!  From my experiences, few IT organizations have mastered these disciplines, and in those companies where process culture is mature, I often find that the IT organization is the exception!

Do yourselves a favor – check out the Simple Processes blog!

Graphic courtesy of BizManualz