Monthly Archives: January 2009

Business-IT Alignment As Simple Rules


Back in 2001, Kathleen M. Eisenhardt and Donald N. Sull published a Harvard Business Review paper called “Strategy as Simple Rules.“   This was a great paper that spoke to the need for a few straightforward, hard-and-fast rules that
define direction without confining it.  It resonated strongly with my colleagues and I as the term “simple rule” as used in the paper correlated very closely with a consulting tool we used regularly and to great effect – that tool being “principles”.

principles-pic1

Principles to Clarify Strategy

Principles surface and can ultimately clarify key questions of business strategy, operating model design and Enterprise Architecture.   Principles represent a small set of simple, direct, clear articulations of “the way we work here” – rules of the road.  An effective principle has “edge.”   Rather than simply stating a mealy-mouthed cliché, a good principle is one where rational individuals can argue for the principle or its inverse.

We will optimize our IT investments for the enterprise, rather than for individual business units or functions.

The principle above is powerful, especially if optimization for the whole was not previously the case.  You can see here that a rational person (perhaps the head of one of those business units who has historically had the freedom to optimize his or her IT spend for their unit) could argue the opposite (in fact, the opposite was the status quo, presumably a result of rational decisions by sound minds!)  However, many organizations reach a point where they need to rationalize IT investments, share common capabilities wherever possible, and move to a more integrated operating model.  In those cases, the principle above can be an effective way of surfacing the issue, driving the dialog and reaching consensus.

Often general, always actionable, effective principles help translate strategy into an action.  Effective principles:

principles-of-principles1

From Simple Rule to Changed Behavior

While the power of a good principle (i.e., simple rule) to surface issues, drive dialog and reach consensus is important, that is typically insufficient to drive action and ensure behavior consistent with the principle.   Once the principle has been agreed, it is important to work through the key implications of each principle.  What will need to be different for the principle to become “the way things work around here”?   How will we need to act after the principles are in place?  What changes must be made to ensure that we act in accordance with the principle?

Some principles require new policies.  Some demand changes to governance models or decision rights.  Some demand attention to rewards, recognition and consequence management.  All effective principles should be accompanied by an underlying rationale explaining why the principle was adopted and why it is important.

Where do you see the need for a few “simple rules” that might better leverage IT capabilities and investments in your enterprise?  Tyically, these are found in “points of pain” – recurring issues that feel insane, and yet keep popping up like Groundhog Day.  How can you pull together the right set of stakeholders, and facilitate them through the development of principles to help fix the insanity?

About these ads

How Does Your Company View IT?


pollI’m experimenting with WordPress’s (my blog platform) ever increasing range of bells and whistles – today trying a simple poll.

Take a look.  Give us your answer – please don’t be shy!  All responses are anonymous, but please submit a comment if you have suggestions for other polls.  This could become an interesting regular feature!

Increasing Business Value Through Demand Shaping


walk-past-no-coffeeA key role for IT leaders, especially during recessionary times, is Demand Shaping.   A perennial reality in the business-IT world is that demand seems to exceed supply.

Of Backlogs and Early Cloud Computing

When I entered the field of IT back in the 1960′s, the term “backlog” was pervasive – that huge list of requests we could not get to until supply resources freed up.  Around the same time, and partially as a result of these huge backlogs (often measured in months or even years!) time-sharing and service bureau’s were the rage.  Often they would install terminals for you for free, provide access to so-called Fourth Generation Languages, data analytics, simulation and modeling tools, and let you “pay by the drink.”

Long term, this may not have been the most cost effective approach, but it let “end users” (as we called them back then) get access to the tools and computing power they may not have otherwise had access too.   I remember doing some work for a large enterprise that ran movie theaters.  I needed to model the economics of dividing up cinemas from single screen (which was the only model in the UK back then) into mutli-screen theaters – an approach called ‘multiplexing’ today.  I used a financial modeling tool called PROSPER through a service bureau.  I was learning the tool while I was building the model, so it took me a while to get it all working.  I remember getting to my 30th iteration of the model before I saw the first service bureau invoice, and on seeing all the zeroes following the pound sign, realizing that, “I had some splainin’ to do” as Ricky Ricardo would have said at the time!

But the results were important to the company, and they were happy to pay the invoice without complaint as it validated a major strategic shift for them, and they became one of the pioneers of the new movie theater model in the UK, capturing significant market share from competitors, and driving great profits for many years.  Had I responded to their request for the analysis with, “IT does not have the capacity just now, we’ll get to it in 18 months,” at best, I’d have had an unhappy customer.  At worst, we’d have watched a competitor beat them to the punch!  On-demand, cloud computing (in its earliest form) provided me the flexibility to satisfy demand without capital investment or undue delays.

Shaping Demand Rather Than Accepting It

Perhaps the more interesting story behind the cinema multiplexing modeling story above is how it came about.  I was at the time a Systems Engineer for ICL – then the leading British computer company.  I was working with a Sales Engineer.  The movie theater enterprise (actually, this was just one business in a broad range of consumer businesses) was his key account, and he was working hard to convince them to buy a larger computer.  He came up with the strategy of multiplexing (I think he’d been to the US and had first seen it there) and took the idea to his customer with the offer to find a free resource (yours truly!) and do the necessary modeling to analyze the financial implications.  (Note the irony here that we both worked for Britain’s largest computer company and that I had to go to a service bureau to get access to the computer cycles!)

The point is, that sales executive was shaping demand for his customer – bringing ideas to create demand.

Two Ways to Drive Business Value Through Demand Shaping

In the example above, demand shaping was through the relationship manager bringing ideas to his customer.  This is a technique familiar to all of us (at least, in the US) used by pharmaceutical companies to let us know about medical conditions we may not even be aware of and for which they have a potential remedy – even if we can’t go out any by those remedies.  We have to ask our doctors whether the treatment is appropriate for us.

The second method those in relationship management roles use demand shaping is when the customer tells us their ‘demand’ and we deflect it by suggesting a solution that might be of higher value, or, at least, pointing out that the requested ‘demand’ may not deliver value sufficient to justify the need.  This is the more common opportunity for demand shaping, and typically the trickier role to successfully pull off.  If we are not careful, it can be seen as being unresponsive or uncooperative.  It might mean elevating a one-off and/or siloed need to a more enterprise-wide solution.

Anne, that’s an interesting request, but perhaps we can kill several birds with one stone if we provide a solution that addresses more than the needs of your department?”

To the customer, that might mean delays as we work through enterprise-wide governance processes, or work the politics to enroll other departments in the solution.  In these cases, pushing back by the relationship manager requires intestinal fortitude, skills in the art of persuasion, and political savvy.  But such is the lot of relationship manager – shifting from ‘order taker’ to ‘valued business partner’, from ‘account executive’ to ‘agent of enterprise solutions and business value.’

How often are you simply in the role of order taker?  What could you do differently to position IT capability for value realization?

Do You REALLY Have Effective IT Processes?


chickenprocessFrom time to time, we conduct IT capability assessments for our clients.  These typically examine two different kinds of capabilities – those IT capabilities that are largely owned and executed by the IT organization, for example:

  • Manage the IT Infrastructure
  • Deliver Business Solutions
  • Manage the IT Organization

They also (and sometimes, of great significance) assess those IT capabilities that are jointly owned by business and IT, such as:

  • Manage the Business-IT Portfolio
  • Manage Business-IT Relationships
  • Manage Enterprise Architecture

Capability vs. Process

An important element of capability is the concept of process.  Processes tell you how work should be done, where inputs come from and outputs go to, what results should look like and how they should be measured and evaluated, how efficient and effective the process is, and how it should be evaluated and improved.  Capabilities bring in the dimensions of people and technology that use processes to get work done.

Some capabilities (typically those whose primary value proposition is Operational Excellence) require rigorous and robust process definitions.  For example, this is the primary domain for frameworks such as ITIL and COBIT.  Other capabilities, where the value proposition is Customer Intimacy or Innovation have a far higher “human content” requiring special competencies and judgment.  In these cases, processes may be less rigorously defined, but they are still important, even if only in the form of a checklist for the major steps, entry and exit criteria, and examples of the deliverables they create or outcomes to which they are intended to lead.

The distinction between capability and process is important for many reasons.  I sometimes find myself in debates with clients along the following lines:

We have assessed that your (fill in the blank) capability is low – not in place or only partially in place.

Which garners the client response:

That’s wrong – we have processes and artifacts to do (fill in the blank) – it’s fully in place, or at least mostly in place!

To which we respond:

You might think you have a process, but the people who’s role it is to deliver the capability associated with that process either don’t know about it, or are ignoring it – the net result is, you don’t have the capability maturity you need for (fill in the blank)!

The Characteristics of Real Process

So, how do you know you really have processes that are driving (or at least, shaping) behavior?

  1. Do you have a process definition that is known by and used by impacted stakeholders?
  2. Is it defined at a level appropriate to its purpose?
  3. Does it provide “best practice’ examples of input criteria, exit criteria and deliverables for each major step?
  4. Does it clearly spell out all roles associated with each given step?
  5. Do those roles call out or point to descriptions of the competencies (knowledge, skills and behaviors) needed to satisfy a given role?
  6. Are there outcome and in-process metrics and are these used to drive continuous improvement?
  7. If a new person, once familiarized with the formal process, stepped into the work mid-flight, would they know what to expect (and would find) what work has been done so far, and what steps need to be performed next?
  8. Do you have approaches to assure that key process steps have been followed (risk management)?

Some Questions to Reflect Upon…

So, think about your major IT capabilities:

  • For which ones do you really have good processes?
  • Where are your biggest gaps?
  • What would you gain if you closed those gaps?
  • Would it help with communications – internal to the organization and with your business partners?
  • Would it help clarify roles, responsibilities and accountabilities?
  • Would it help clarify the ‘rules of engagement’?
  • Would it make work more predictable and more easily repeatable?
  • Would it help identify non-value adding steps and activities, or missing roles?
  • Would it enable process improvement and innovation initiatives?
  • Would it help bring new employees or partners up to speed more quickly – accelerate ‘time to value’?
  • What would that all be worth?
  • What’s standing in the way of doing it?

Why a Good Business Case or ROI Analysis Doesn’t Ensure Value Realization


business-case-mouseI find that most companies I work with nowadays are pretty good at insisting that business requests for IT solutions are accompanied by a robust business case that surfaces all the costs (including total life cycle costs), expected return on investment (ROI), risks, mitigation strategies, and so on.  They have good business case templates, and often associated tools to facilitate the development of effective business cases with a consistent ‘look and feel.’

Beyond the Business Case

These things are all necessary, but are woefully insufficient to drive value realization.  In fact, they can be a trap, creating a false sense of security.  “We’ve done a solid analysis of the business case, so now we can just blaze ahead with the system and the results will naturally and inevitably follow!”   Wrong!!! It’s quite likely that the results that do follow bear little, if any, relationship to the business case.

Seven Steps to Value Realization

There’s a level of analysis, engagement, measurement, control and accountability here that is essential to driving business value and that does not automatically come along with business case development.  So, here are some techniques I recommend to help ensure value realization, not just project approval.

  1. Be deliberate and explicit on the language of ‘business case’ versus ‘value realization.’  Whether you use those terms, or other terms, differentiate between things you do/artifacts you use to analyze a project’s or program’s merits and risks, versus those things you do to drive value realization.  They are both critical to success, and many more people do the business case well than do value realization effectively, which is a shame – leaves lots of money on the table!
  2. Get really clear on costs and value and accountabilities for each.  Each accountable party should be a party to the value realization plan, and sign up explicitly for their part.  See my earlier post, Lack of Accountability – Who’s Dirty Little Secret?
  3. Don’t limit value realization to financial return.  Get explicit about the “value system” at play in your organization.  ‘Time’ may be an important value (e.g., this will reduce new product time-to-market from 6 months to 4 months through…). Quality may be an important value (e.g., this will reduce defect rates from 1% to 0.25% within 12 months enabled by…)  Employee engagement may be an important value (e.g., this will increase overall employee engagement scores as tracked in our annual engagement survey from 85% to 95% within 12 months due to…)  As long as it is an important value, and can be quantified in terms of degree and time frame, and can be measured, it is meaningful to value realization.   Even if you can’t predict with accuracy or precision what a 10% increase in quality is worth, you can measure it and learn the relationships between intermediate outcomes and financial implications over time.
  4. Figuring out the value system and the outcomes and intermediate metrics and goals is not easy.  Therefore, it is a great opportunity to engage a broad audience of stakeholders in figuring the metrics out.  This not only ‘spreads the load’ but engages stakeholders in the value realization conversations.  Sometimes, it surfaces problems and opportunities early on, while there’s time to do something about them.  For more on this, see my earlier post on Measuring the Business Value of IT – Where You Can Win by Simply Trying.
  5. Once you’ve figured out the outcomes and intermediate metrics, create the measurement plan and document it as part of the program.  I don’t favor post-implementation audits as the primary vehicle for value realization assessment.  Audits are good for lessons learned, but value realization is so important, it is better if you can build the instrumentation into the implemented solution.  The difference is like designing cars where you have to get out every now and again and dip a stick into the fuel tank to figure out how much gas you have (bad), versus designing a fuel gauge into the car (better) versus designing a widget that tells you how many more miles you can travel and that sounds an alarm when you are 50 miles from empty (best).
  6. Implement the measurement plan, and take measurement seriously!  Get a senior executive sponsor who’s going to pay attention to this.
  7. Ideally, find ways to ‘close the loop’ between measured realized value and individual and/or group rewards and recognition.  This need not be money in someones back pocket – there’s tremendous power in an internal newsletter or collaboration hub celebrating the success of value realized through a system, and congratulating those associated with the program.

If all this sounds simplistic, it is – deliberately so.  I find people obsess over false precision and accuracy, rather than see this whole exercise as on of learning and growth – of driving the right conversations to increase understanding of and commitment to value realization.  Keep it as simple as you can, especially to get started.  Once you’ve got some momentum going, you can get more sophisticated if you feel the need (and the value!)

Getting Control Over Business Demand – How to “Just Say No!”


just-say-noDid you ever feel that some of the things you are asked to do by your business partners just don’t make sense?  That they won’t deliver value that truly justifies their cost?  I find this to be a common issue.  And it’s not just the questionable value associated with some of these requests.

Low value demand:

  • Carries with it an opportunity cost – resources working on clarifying and satisfying low value demand are not available to stimulate and satisfy higher value activities.
  • Fosters a ‘master-servant’ and ‘order-taker’ relationship between business and IT which in turn limits that relationship’s ability to grow into a more strategic and value-creating partnership.
  • Order-taking behavior misses out on important opportunities to raise business-IT savvy – to raise business awareness of information and IT possibilities for value creation, or to raise IT awareness of where and how the business can leverage information and technology in important or significant ways.
  • Typically backfires on IT by creating an undercurrent sense that ‘IT costs too much and delivers too little’.
  • Creates the feeling that the person taking the order adds only cost, not value, to the business-IT relationship, often leading to a vicious cycle of weak relationship managers not receiving the training and development they need to be more effective.

I think there are all sorts of historical reasons why we get into this bind, mostly associated with low business-IT maturity on which I’ve commented substantially over the last 15 months or so.  But I believe the economic downturn presents a wonderful opportunity for the IT professional to get back in front of, and in control of business demand.

Saying ‘No’ by Saying ‘Yes’

As nonsensical as this sounds, there are ways of saying ‘no’ that don’t sound like ‘no’ and can lead to a far more constructive conversation and a more productive outcome.  I’ve worked with The Second City improvisation group in client workshops, where they taught us the simple skill of re-framing a  ‘No” into a “Yes, and…”  With a little practice and the right mindset, you can take a low value request (e.g., please produce a report that shows sales trends by sales person by region over the last 6 months) and turn it into something with a lower cost-to-serve, higher business value, and an improved customer experience.  “That sounds like a useful report, and my guess is that in the current economic climate, you’re going to be needing all sorts of analyses to help drive sales performance improvement.  Given that, perhaps it would be more useful to you if we created a data warehouse with all the current and historical sales data, and showed you how to use the report-writing tools to create just about any report you are going to need.  Let me show you an example of how easy that is, and how empowering it can be – you’ll be a company hero for your understanding of the sales data, and your insight into what it means!”

Now, my example is, of course, trivial, but hopefully provides a sense of what can be done.  Saying ‘no’ is typically seen as non-constructive, lacking service orientation, obstructionist and generally annoying.  Rejecting a bad idea by smoothly and collaboratively turning it into a good idea is seen as constructive, service oriented, and satisfying.

Think back over times when you’ve had to say ‘no.”  Think about those times when you finessed the situation, using your best zen instincts that led to a positive outcome?  Compare those examples to the times where you were less elegant in how you handled the situation.  Could you have offered a better alternative?  Could you have better explained your rationale?  Could you have made the requester feel better about the outcome?  Finally, look for opportunities to practice and use this skill.  To quote Standford Professor Paul Romer, “A crisis is a terrible thing to waste!”

A Thought for all the Frequent Flyers and the Folk Who Serve Them


New York Plane in RiverI know that we’ve all been entranced by the wonderful news of the US Airways plane that “landed” in the Hudson River this week.  It was a remarkable and uplifting piece of good news at a time when we’re mostly inundated by bad or terrible news.

As a very frequent flier, I was particularly moved by the ever-eloquent Scott Simon’s piece on National Public Radio’s Weekend Edition Saturday.   He closed this short piece about the heroic acts of the Captain, Co-Pilot and three flight attendants  piece by saying,

So the next time you might get exasperated over some air travel problem, and be inclined to say something sharp to a flight attendant, you might want to remember that their first and last responsibility is safety. And as we saw this week, they will risk their lives to save yours.  Isn’t that worth a lot more than a small bag of peanuts?

It made me think, and hopefully, personally demonstrate a little more patience when the stresses and trials of air travel test my temper and good humor.

Zen, Motorcycles, and the Art of Organizational Change Management


zen01My post the other day on Chaos and Complexity led me into a client conversation about organizational change.  This in turn reminded me of an article I had published back in 1996 in Hewlett-Packard’s Perspectives magazine.  I’ve also said before that occasionally I will dig into one or more of my passions and hobby’s (music, scuba, motorcycling) and relate this back to the work and transformation of IT organizations.  Anyway, I dug out a copy of the original article, have done a minor update, and include it here as today’s post.

In his book “Zen and the Art of Motorcycle Maintenance,” (a book that has had enormous influence on my approach to work and life), Robert Pirsig used a motorcycle as a metaphor to explore philosophy, quality, and the meaning of life.  I’d like to extend the metaphor to examine the nature of organizational change, and discuss why conventional change-management wisdom (which mostly surfaced in the last century) when applied to today’s complex organizational context may lead you dangerously off course.

The motorcycle is, of course, a machine.  It’s constructed from components, assemblies and sub-assemblies. Power is generated in an internal combustion engine (typically, although there are electric-powered motorcycles, and even one powered by a helicopter jet engine – famously owned and ridden by Jay Leno), transferred through gears, cogs and chains.  We can understand this classic machine by describing its parts and how they fit together.  The motorcycle behaves according to simple laws of Newtonian mechanics.  If you want to turn left, you steer to the left. That is, until you reach a certain speed.  Above about 10 mph, (depending upon the size and geometry of the motorcycle) something strange happens.  If you want to turn left, you steer right!  Above a certain speed, what looks like a simple machine operating according to predictable laws becomes a complex set of interacting systems that behave neither linearly nor intuitively.

And this is the problem with conventional change management wisdom.  In the early and mid-industrial revolution, organizations were relatively simple and stable systems.  They did behave somewhat linearly.  Like machines, they were divided into functions and sub-functions.  Strategy was formulated at the top, work performed at the bottom, with middle management interpreting between the executives and workers,  smoothly transferring power and information up and down the organization, like cogs and chains.  Line folk did the work and staff handled control and support functions.  You can see this view reflected in the mechanistic methods for organizational change that were popularized by researchers such as Kurt Lewin.

If you want small changes, the conventional wisdom held, then do incremental things at the lower parts of the organization. Large change required radical interventions at higher levels.  Even the traditional language of change speaks of ‘unfreezing’, ‘refreezing’, and of ‘resistance’, as if describing a rusty or gummed up machine.

As information and knowledge replace minerals and machinery as industry’s fuel, however, organizations are becoming increasingly complex and dynamic.  As with the motorcycle, the intuitive way you steered the organization in simpler times no longer works.  Small interventions, such as 6 Sigma or Lean Manufacturing, can lead to massive change.  Large interventions, such as business process re-engineering and restructuring often fail completely, as the organization springs back to its original form like a motorcycle fork spring rebounding from a pothole.

Back to the motorcycle and the phenomenon called countersteering.  Most motorcyclists don’t even know this is happening unless they have been trained to use counter-steering to avoid becoming road kill.  So why aren’t they constantly careening off the road?  Under normal conditions, this counter-steering effect is very subtle.  Ask a biker how he steers and he will say, “I lean.”  The reality is, the only way to lean at anything above parking-lot speeds (unless you are racing and prepared to hang off the side of the motorcycle – not recommended for street riding) is by applying subtle pressure to the handlebars in the direction opposite the intended turn.  The biker can get by for years doing this unconsciously – until there is an emergency, and the hapless biker who doesn’t understand countersteering, is unable to turn sufficiently quickly to avoid the hazard.  And so it is with managing change.  Doing what seems intuitive gets you by until organizational complexity, or ambiguity of the change reach a certain pitch.  The “nuke the process, take no prisoners” re-engineering approach fails miserably and expensively because it assumes machine-like organizational qualities.  Those managing change in today’s dynamic organizations must discard the conventional wisdom.  They must forget mechanistic images of the organization, recognize the inherent complexities, and draw instead from the sciences of chaos, complexity and ecology.  For example, chaos with its ‘strange attractors‘ explains why major interventions may lead to little or no change, while small changes can produce radical results – the so-called ‘butterfly effect.’

By approaching organizations as complex, living organisms, rather than as machines, managers recognize that they can’t predict the outcome to any given intervention.  As such, informed managers approach their change tasks in a more incremental, holistic and organic fashion, and realize that they aren’t really managing change in the conventional sense of the word.  They are more sensitive to the complex interactions between systems, and use whole systems approaches that get as many stakeholders involved in the change as possible.  Shared Vision and values become the ‘genetic code’ that shapes behavior throughout the organization, rather than detailed change designs engineered from above.  Information becomes a source or both order and creativity.

While the mechanistic approach treats work structures as permanent, and transition structures as temporary (pilot projects, change teams, and so on) the organic approach has fluid work structures (teams, self-organizing networks) and permanent transition-support structures (social networks, communities of interest).

Chaos sensitizes us to look for patterns rather than rules. If motorcycle steering reverses at a certain speed, we should expect to find other examples of non-linearity in control systems.  We find it in supersonic flight where initial attempts resulted in mysterious crashes – until someone figured out the different control dynamics as you break the sound barrier.  In Pirsig’s words, “Traditional scientific method has always been at the very best, 20-20 hindsight.”  It’s good for seeing where you’ve been.  It’s good for testing the truth of what you think you know, but it can’t tell you where you ought to go.

There are other change-management lessons to draw from motorcycles.  The safest way to corner on a motorcycle is to counter-steer into the turn and then gradually open the throttle through the turn.  Constant throttle, or even worse, reducing the throttle in a turn (the intuitive thing to do) leads to wobbling, and an unfortunate tendency to leave the road.  This is explained by paraphrasing Newton’s first law – changing direction requires energy.  If the energy is not replaced by opening the throttle, the speed of the bike drops, the lean angle changes, and the bike becomes unstable.  Similarly, organizational change requires additional energy.  Rarely, however, do managers budget the extra time and resources needed for the change.  People are expected to do their normal workload, plus assimilate change – a recipe for frustration and failure.

Managers can learn a lot from motorcycles – particularly if they recognize the trap of treating organizations mechanistically and look instead to chaos, complexity theory and ecology as a source of change-management wisdom.

Chaos, Complexity and the Future of the IT Organization


fractalDid you ever think about the relationship between the magnificent fractal patterns like that in the graphic to the right and IT organization design?  One of my early posts alluded to the climb from Level 1 to Level 2 Business-IT Maturity as “bringing order to the chaos” while the Level 2 to Level 3 journey is about living with complexity, decentralizing control and empowering the community of IT stakeholders.

This is a difficult concept for many of us to get our heads around, especially IT professionals whose lives depend upon driving out ambiguity, bringing order to chaos, and bringing processes “into control.”  Back in 1992 I read Margaret Wheatley’s remarkable book, Leadership and the New Science.  It was intriguing to me at the time, though hard to translate into action.  I was leading research into both IT effectiveness and organizational change and transformation, and I knew that much of the conventional wisdom about organizations and transformation did not seem to apply, or was, at best, of limited value.

I followed up my reading of her book by participating in a multi-day workshop led by Meg Wheatley in Toronto.  The experience was personally transformational.  It gave me a new lens through which to see the world of organizational change, and a new set of tools and approaches for working with my clients.  At the time I was working with a large State agency, and persuaded the visionary CIO to let me try some of the techniques I had learned in an IT leadership workshop.  Although scary, the results were spectacular, and my fear of taking a client through an unpredictable process so that a new, natural order can emerge was replaced by a trust in people’s ability to find a new order in chaos, and to simplify and clarify by letting people drown in an apparently overwhelming sea of data.

In the ensuing 15 years or so, I have seen complexity increase for IT leaders, and experienced time and time again the need to step back and rethink the natures of chaos and order, and what it means to “be in control.”  I’ve mostly used this as a workshop technique and consulting intervention.  But, especially with the advent of Web 2.0 and social networking, I’m increasingly using the principles of Complex Adaptive Systems to inform my IT organization design work.

For me, some of the key insights that come out of the chaos/complexity disciplines include:

  • Complex systems display non-linearity – output is not proportional to input.
  • Variety, randomness, paradox, information, and interconnection inherent in complex systems are sources of creativity.
  • Complex systems display emergent order – organization is a natural, spontaneous act;  systems have a capacity to self-organize.

Ralph D. Stacey, in The Chaos Frontier captured this last insight beautifully when he defined 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.”

So what does all this mean to an IT leader and the journey towards 2017?  We will explore that in subsequent posts, taking each of the insights above and looking at the implications for IT.