Tag Archives: reaching level 3

Does Your IT Shop Embody a “We Can Do That!” or a “We Can’t Do That!” Culture?


I was reminiscing with a consulting colleague recently about the two kinds of IT shops we’d worked with.  (Reminds me of an old joke that I first heard from Professor John Henderson at Boston University – “There are two kinds of people in this world – those who believe there’s two kinds of people and those who don’t!”)

The “Can Do’s”

Some IT shops fall clearly into this camp.  Suggest something innovative or new to them, and they are quick to explore the idea, see if it makes sense, and then figure out how they’d make it happen.  These clients are a delight to work with – energizing, engaging, sometimes challenging, but in a positive, constructive way.

The “Can’t Do’s”

Other IT shops fall into this unfortunate camp.  Suggest anything – innovative or not – and the immediate reaction is some variation on, “We can’t do that!” or, “That won’t work here!” or, a common variation, “That’s just not the way things work around here!”

Ask someone in a “Can’t Do” shop to help with something, and they will spend 30 minutes or more telling you why they don’t have the time to help – even if the help you are asking for would take only 15 minutes!  In other words, they will spend more time telling you why they can’t help than the time it would have taken to help.  It’s a knee jerk reaction.  The thought bubble I see in my head, floating above these naysayers is, “If I sign up for this, I might have to do something that would change the status quo.  That might be dangerous.  That might lead me to the unknown.  It’s safer to say, ‘no.’”

Prevent “Bad Change”

The “can’t do” environments spend all their energy trying to prevent change that might be harmful or counter to the established order.  Of course, there’s typically no way of knowing if it’s going to be a “bad change” or a “good change”, so by definition, any change is to be resisted at all costs!

Create “Good Change”

These are the innovators – the change agents.   Always looking to challenge the status quo and explore new possibilities.  I imagine that companies like Woolworths and Circuit City had a critical mass of “change resistors” (or at least, had enough of them in positions of power to preserve the status quo), while companies like Best Buy and Target had a critical mass of “change agents”.

I can understand why IT shops tend towards the “prevent bad change” camp.  IT operations depend upon stability and predictability, so you don’t want to mess with that.  But, unfortunately, the operational needs and culture tends to permeate everything the IT shop does!  Just when the business needs their IT specialists to be bringing them new ideas and new ways to compete, the IT specialists are beating down anything new.

From “Can’t Do” to “Disengaged”

Unfortunately, it’s an easy slide from “can’t do” to “disengaged”.  People in the organization get so beaten down whenever they try to introduce something new, that they give up.  It becomes such a painful endeavor, banging your head against a wall, that you stop trying.  It’s easier to slip into the background and go with the flow.  I have to admit that even as a consultant, there have been times where it was too painful trying to change things, and I’ve “gone native”.  Just make sure the deliverables per the Statement of Work are produced, get paid, and get out!  After a while, the extra energy it takes to break through the culture is spent.  At times like that, I empathize with the client’s employees – beaten down, disengaged, and at peace with simply going with the flow.  All that potential creative energy left at home, rather than being brought to the office as a source of new ideas.

So, What To Do About It?

I’m sorry, there’s no magic formula I’m aware of.  The first step, like the substance abuser, is to admit to the shortcoming.  Recognize that “can’t do” has permeated everything – way beyond those operational process where preventing bad change makes sense.  Then follow the familiar but tricky steps of organizational change management – establish the cost of the status quo, create a vision of the new, brighter future, build a guiding coalition, create early wins, etc.   Sometimes, it pays to stick you neck out – ask forgiveness, not permission!  If you get shot for doing so, that’s OK – you probably didn’t want to work there anyway!

Enhanced by Zemanta
About these ads

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 Realpolitik of Business-IT Convergence


For some reason, I get much more commentary about my posts via personal emails than by direct commentary.  There’s something I quite like about that – it feels more personal when someone takes the time to send an email about a post.  On the other hand, the emailed comments are often illuminating and deserve a response (which I always provide) that hopefully leads to a discussion, so I wish they were made directly on my blog!

Anyway, I just got such an email – in fact in response to a post that was re-purposed by Formicio, a company with whom I am proud to be affiliated.  The email was about the deadly “IT versus the business” trap!

It’s Not “IT” versus “The Business”!

I sometimes fall into this trap of referring to “IT” and “the Business” as distinct entities.  I consequently (and deservedly!) take some heat for doing so!  The objections are perfectly valid.  I am as big a believer in the goal of business-IT convergence as anyone, and I am sensitive to the use of language, often coaching my clients to avoid anything that connotes separation of IT from the business.

But… the Business-IT Realpolitik!

As much as I believe in the goal of business-IT convergence, and as much as I respect the intent behind those who talk and act as though these things are converged, for most enterprises, the reality is that they are not converged – and sometimes, seem not to be even living on the same planet!  I think there are several causes to the tensions that seem to be inherent in the relationship between the business units and the primary organization charged with coordinating IT activities and managing or overseeing IT operations:

  • Uncommon goals and incentives.  For all the talk of shared goals and incentives, the leadership of the IT organization usually has different goals and incentives from the leadership of the business units they serve.
  • Partnership only in name.  For all the aspirations and happy talk about business-IT partnerships, I find these are rarely the case.  The exceptions are wonderful to behold, and typically lead to good things happening, both for the business and for IT.  But they are not the norm!
  • Healthy tension, is…  well, it’s still tension!  The pull and push between profit centers and shared service providers can create and sustain a healthy tension.  This is good – as the term implies – healthy!  But, as the term also implies, it’s still a tension.  And tension sometimes don’t feel healthy, even if it is good for you!

How to Achieve Convergence?

I believe in positive techniques such as Appreciative Inquiry and Role Modeling, so talking and behaving as if business-IT convergence is real and is already happening is a healthy practice.  But pretending that there are no tensions, and living with misaligned goals, rewards and recognition is to ignore important and ultimately destructive realities.  Be positive – yes!  Be optimistic – absolutely!  But don’t ignore the realpolitik.

 

Graphic courtesy of Trainingwreck

Enhanced by Zemanta

Do You Have IT Organizational Clarity – Part 3


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

In Part 1, I discussed the importance of IT Organizational Clarity, the symptoms when clarity is compromised, and the challenges of trying to address those symptoms rather than the root causes that lead to compromised clarity.  Part 1 closed with a discussion of the two key dimensions along which IT Organizational Clarity can be tackled – scope (units of IT Capability) and meaningful and assessable characteristics for evaluating and improving IT Capabilities.

In Part 2, I discussed ways to define IT Capabilities and provided guidelines on the manageable number of IT Capabilities and appropriate depth of decomposition.  In this post, I will describe three different types of IT Capability.

Not All IT Capabilities Are Born Equal

It is helpful to classify IT Capabilities into one of three different types, as illustrated in the graphic above.

Value Chain Capabilities

At the core are those capabilities that take inputs, add value, and deliver outputs to a customer or end consumer (in the world of IT, these tend to be services and products).  Think of these Value Chain Capabilities as those that the end customer appreciates (hopefully!) and is willing to pay money for.

For example, as a business user, I may have a business problem I’d like IT help to solve.  That problem (or opportunity) is the input to a Value Chain.  The first Capability that will approach that problem adds value by analyzing the problem, identifying and proposing a solution.  As the business user, I appreciate that value has been added – drilling into my stated problem and offering (and perhaps demonstrating via a prototype) one or more proposed solutions.  The next Capability in the Value Chain might take the chosen solution and develop and deploy that solution.  Again, as the business user, value has been clearly added – taking a proposed solution and delivering it.  The final Capability where value can be added is supporting and maintaining that solution – again, a recognizable way of adding value for me, the customer.

Ultimately, as the business user or consumer, these are the only Capabilities I care about and am willing to pay for (directly or indirectly) because of the value they add for me.  Unfortunately, while these Value Chain Capabilities are necessary, they are not sufficient.

Enabling Capabilities

Value Chain Capabilities typically draw upon other Capabilities that enable them.  Think of these as Shared Services that are common to other Capabilities, or to other instances of problems/solutions working their way through the Value Chain.  Examples of IT Services that might enable the Value Chain Capabilities include Project Management, IT Operations, and IT Supply.

Alignment and Governance Capabilities

Value Chain Capabilities also typically depend upon other Capabilities that ensure that the work they are doing is aligned and governed to ensure they are operating effectively and in the interests of the enterprise.  For example, determining which business problems will be addressed, which solutions will be selected, how staff and resources will be allocated are all important control that Value Chain Capabilities will be subject to.

Why These Distinctions Matter to IT Organizational Clarity

The distinctions between Value Chain, Enabling and Alignment/Governance Capabilities are significant:

  1. Different types of IT Capability tend to be optimized towards different value propositions, with implications for how they are organized.  For example, Enabling Capabilities tend to be optimized for Operational Excellence (as shared services, they need to deliver predictable, consistent, quality services at the lowest possible cost).  Value Chain Capabilities tend to be organized for Customer Intimacy, delivering what specific customers want; anticipating customer needs.  Alignment and Governance Capabilities tend to be more about decision-making – rather than delivering services, they make decisions or provide decision-making frameworks – think Enterprise Architecture and the mechanisms and structures that support it as Alignment and Governance Capabilities.  As such, these tend to be networked, linking stakeholders and decision makers, and optimized to maximize the business value delivered or enabled by IT Investments..
  2. Some types of IT Capability lend themselves to alternate sourcing more than others.  For example, Aligning and Governance Capabilities lend themselves the least to straight outsourcing approaches (do you want to pass decision rights to an external vendor?)
  3. Different types of IT Capability lend themselves to different funding models.  For example, Value Chain Capabilities lend themselves to direct business funding, whereas Enabling Capabilities lend themselves better to indirect funding models (e.g., overhead charge).

IT Capability Model Example

As an illustration, below is a ‘normative’ IT Capability Model.

The Fractal Nature of IT Capabilities

Note, that as you decompose any IT Capability, you will generally find that the decompositions will have a similar structure – a primary Value Chain, drawing upon underlying Enabling Capabilities and influenced by Alignment and Governance Capabilities.

For example, Manage Business-IT Portfolio & Programs might decompose into the following sub-Capabilities:

In the following post, we will look at the assessable characteristics of any IT Capability as a means of determining Capability Maturity and determining how to increase maturity and thereby improve performance.

Enhanced by Zemanta

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

Account Teams and Business-IT Relationship Management


I’ve posted quite frequently on this blog about the role of the Business-IT Relationship Manager. It’s a key role – crucial, in fact, at mid-levels of Business-IT maturity.  It’s a role that typically does not work well at lower maturity, yet is essential to reaching higher maturity. It’s also a role that is hard to get right!  But went you get it right, it can contribute significantly to business value realization from IT assets and investments.

An Account Teaming Approach to Relationship Management

I’ve found myself re-immersed in the Relationship Management (RM) domain lately.  I’m working on a significant RM development program with one current client, and helping another client fine tune their IT Operating Model.

With the first client, I got involved in a benchmarking exercise, going back to two former clients where I had led extensive RM training a few years back.  The purpose of the benchmarking was to find out how their RM approach had evolved, what was working well, and where they still had challenges.  In both cases, the clients had converged on an Account Management Teaming approach – essentially, a set of business unit-facing account teams comprising a very senior Relationship Manager (rarely called that, by the way), a Solutions Manager and an Enterprise Architect.

In the client where we are fine tuning the IT Operating Model, one such account team had formed fairly naturally.  Nobody told them to organize that way.  One of the RM’s met with a business architect and a solution manager and decided they needed to set time aside to meet and talk and strategize in order to present a cleaner, simpler face to the business client.  They wanted to be more deliberate and proactive in shaping business demand rather than simply respond to it.  They saw the formation of the account team as a sort of experiment.  They did not ask permission – just went ahead and tried it.  (I’d describe this as a fairly sophisticated client in an information intensive industry, with an exceptional quality of IT leadership and management.)

This Seems to be Working – Let’s Generalize It!

I met recently with the account team and other architects, RM’s and solution managers to talk about how to generalize the model and duplicate it for the other business units and their RM’s.  We analyzed what had changed as a result of the account team approach – both from the perspective of the individual IT roles, and from the business client’s perspective.  It was an impressive story with impressive results.

So, how to ‘codify’ the approach and generalize it?  The responses from the account team members were surprising and distressing on the one hand, yet obvious and comforting on the other.  Their counsel was, “Don’t try to codify this too much.  It won’t work!”  and, “Remember, we formed into a team because we wanted to, not because we were told to!”

Not So Fast, Tonto!

The business-IT interface is an extremely complex space.  The Account Teaming approach works because it is organic, and was emergent.  It works because the team members have mutual trust and respect.  It is the role of the team that is important and brings the magic, not the roles of the team members.  They talk about “having each others backs covered.”  About the fact that the client executives know that they can talk to any of the team and reach the whole team at the same time.  About the fact that any business-IT conversation quickly and automatically gains the perspectives of enterprise architecture, solution delivery and relationship management.  The business executives don’t need to be concerned about who to call for what.  Nor do they have to sit down with five IT folk to get anything done!

The Power of Self-Organization

Ralph D. Stacey, in his great book, “The Chaos Frontier” defines Self-Organization as:

A process in which the components of a system in effect spontaneously communicate with each other and abruptly cooperate in coordinated and concerted common behavior.”

I believe that viewing organizational spaces such as the business-IT interface as a complex system, operating at the ‘edge of chaos’ (scientifically speaking) reveals the insights that:

  1. Variety, randomness, paradox, information, and interconnection are sources of creativity.
  2. Organization is a natural, spontaneous act – to force otherwise is not sustainable or effective.
  3. Systems have a capacity to self-organize to great effect – given the opportunity to do so.

The danger feared by the Account Team was that as an organizational consultant, I would take the model and create organizational charters, role descriptions, competency models, and so on, and in so doing squeeze the life out of the account team concept.  And I use the word “life” deliberately.  Everything we know about complex emergent behavior tells us that for life forms such as this type of account team to really work, they have to behave like living organisms – with porous boundaries, guided by a common sense of mission and purpose, a ‘genetic code’ if you will, not sealed off from their world by hard boundaries and deterministic rules.

Image courtesy of The Savvy CIO

Enhanced by Zemanta

From Business-IT Alignment to Business-IT Convergence


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

The always-impressive Dion Hinchcliffe sums it all up perfectly in his post, “CoIT: How an accidental future is becoming reality“.  Hinchcliffe repurposes Computerworld’s Scott Finnie’s use of ‘CoIT’ as referring to the ‘consumerization of IT’ to a new term, ‘Cooperative IT.”  I’d like to humbly suggest yet another interpretation of CoIT as a shorthand for “Converged IT” – referring to a world where much of the work of the IT organization has converged with the business as a deeply embedded capability.

A Vision for CoIT

Hinchcliffe suggests some aspects for the vision of CoIT as embodying:

  • Decentralized (or at least distributed) governance
  • IT support that scales up to the new app/device proliferation
  • Business led IT solutions with an enabling infrastructure

I think these are appropriate, though many details and realities to be yet worked through.  And, I believe, while the IT leaders who are most proactive in leading this shift will make some mistakes, they will also be the first to figure out the new realities and will ultimately make less mistakes and learn more quickly than their ‘ostrich’ counterparts who either believe this will all blow over, or that they can figure it out down the road.

What do you think?  Do you agree with Hinchcliffe’s vision?  What are you doing to exploit the emerging ‘converged’ reality of CoIT?

Digital Art: ‘Convergance’ by Wilby  courtesy of Iasos.

Enhanced by Zemanta

Matrix Management and the IT Organization


Many years ago, when I was a partner with Ernst & Young, John Cross, the CIO of BP (a very highly regarded company at that time) approached me wanting to benchmark the way E&Y managed its engagements.  My first reaction was incredulity.  I knew we were good at engagement management – after all, it was what we did for a living!  But it was not immediately clear why this would be of interest to BP.  John explained,

You respond to RFP’s and prospect requests virtually overnight.  You assemble a consulting team with the right mix of competencies in a day or so, and you get them on the ground at the client site, with their own consulting workbenches and tools, ready to be productive in about 48 hours.  You do all this while developing new people, managing engagement economics, running a robust quality assurance process, and keeping up with emerging technologies.  If my IT organization could do those things half as well as E&Y does them, we’d be in great shape!”

What You Can Learn From Consulting Businesses

Now I got it, and realized why John had been so successful at BP, leading the transformation of IT first at BP Exploration, and then globally across BP’s business units.  What we found through the benchmarking exercise (BP was part of a 3-year longitudinal study of global IT transformations that I was leading at the time) was that one of the trickier and more subtle aspects of the E&Y ‘magic’ was the deeply ingrained Matrix Management approach.  Individual contributors reported to both their discipline leader, and the leader of the project to which they were assigned.  Both bosses were part of regular performance reviews, with the project leader’s input carrying significant weight.  Over the course of a year, you might work on a half-dozen or more project, and work in a couple of disciplines, so you were getting performance feedback from 8 or more people.

Other Factors for Matrix Management Success

If you need the flexibility and agility that Matrix Management can bring, and the characteristics of a good consulting organization that I described above, there are several ‘conditions for success’ I’d like to point out:

  1. Clarity of Roles and Responsibilities, and “Organizational Clarity” as Patrick Lencioni refers to it in his great book, Four Obsessions of an Extraordinary Executive.
  2. A clear distinction between ‘role’ and ‘job’ – people may have one job, but fill many roles depending upon their competencies and the need at hand.
  3. A robust Performance Management System – where performance feedback is taken very seriously, performed consistently, and has a direct impact on rewards, recognition, career path and promotions.  Both the individual performer and managers must take Performance Management seriously.
  4. An organizational environment where ‘power and success’ are not denoted by one’s number of direct reports, but by one’s contributions to the success of the organization.
  5. Strong Project Managers.  A ‘project’ is the ultimate temporal unit of management – if the project management process is broken, or project managers not fully competent, Matrix Management will suffer and confusion will rein.

I am indebted (as ever!) to my colleague Roy Youngman for his contributions to this post.

Image courtesy of Global Integration

Enhanced by Zemanta

Are Your Processes Setting You Free? Or Holding You Back?


Early in this blog’s life, I posted quite a bit on ‘sticking points‘ that IT organizations find about mid-way through the journey to high Business-IT Maturity.  Process discipline can be one of the quintessential such sticking points.  Process management can get you out of the mess of Low business-IT maturity to a mid-level, but simply cranking up the degree of rigor and discipline will prevent you from getting to high maturity.

Three Ways to Abuse Process Discipline

  1. Forgetting that the heart and soul of process thinking is Process Improvement.
  2. Process becomes a substitute for thinking, rather than an aid to it.
  3. Not everything lends itself to detailed work processes.

Let’s examine these.

Come Back Deming – All Is Forgiven!

When the likes of Deming and Juran began spreading the gospel of Process Thinking, they weren’t talking about creating a process and freezing it in concrete!  The ‘Deming Cycle‘ – Plan, Do, Check, Out – was all about continuous (and sometimes, discontinuous, as in process re-engineering) process improvement.  And yet many IT organizations somehow leave this aspect behind as they institutionalize worksteps, activities, deliverables and milestones.  People are encouraged (forced”) to follow the project management methodology or systems development life cycle, and punished for violations.  For a while, things improve – some process is generally better than no process!

But then people begin to realize that the process seems to get in the way – inhibits agility.  Intelligent choices are held victim to the process, and bureaucracy reigns.  To get past this sticking point, people need to understand, believe in and be passionate about process improvement.  Be it incremental, stepwise improvement or breakthrough re-engineering, the missing ingredient of continuous improvement is essential to getting the intelligence back into the work and non-value-adding activities out of the work – especially if these inhibit speed, agility or quality.  The trick is to throw out the ‘bathwater’ of blind rigor without throwing out the ‘baby’ of process management discipline.

Three Ways to ‘Standardize’ for Repeatability and Predictability

Many years ago, my esteemed colleague Roy Youngman was co-authoring a book with me (Development Effectiveness: Strategies for IS Organizational Transition) and pointed me to this great work by Henry Mintzberg.  If a goal is to make work consistent, repeatable, predictable and of high quality, there are three ‘degrees of freedom‘ that can be tackled – the tasks, the deliverables, or the people.  The degree to which you ‘standardize’ within this mix is a function of the nature and complexity of the work you are trying to achieve.

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 tries to capture 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, think training and performance support.

Some Process Management Questions To Ponder

  • Are your IT processes holding you back – or setting you free?
  • Are they an aid to thinking, or a substitute for it?
  • Is it time to move past the blind discipline of mindless processes to a more context-sensitive and effective approach?
  • How often to your processes improve, and where is the impetus and insight for those improvements coming from?
  • How are process improvements recognized and rewarded?
  • Is it clear who owns ‘improvement’ for any given process?
  • Is it clear who owns the ‘services’ that are delivered by given processes?

Answers on a postcard, please!

Enhanced by Zemanta