IT Organization Circa 2017

I want to continue on this ‘secrets of consulting’ thread, and deal with one particular tool – principles.  Over the years, in many different situations, I’ve found this to be a remarkably powerful tool for resolving problems, clarifying positions, and, in many cases, driving significant change in behaviors.

As a tool, Principles are both easy to understand, and yet deceptively hard to apply effectively.  I see a lot of work done in the name of ‘principles’ that is weak and undoubtedly ineffective. 

The way I’ve had the greatest success with Principles is to use it as a way to force a choice between strategic alternatives.  I usually do this around some recurring pain point – the kind of ‘groundhog day’ moment where you find yourself saying, “Oh, here we go again – back to this perennial issue!”  Let me jump right in with one of my favorite examples. 

• We will optimize our IT investments for the enterprise rather than for individual business units.

This makes a clear, explicit choice between alternatives.  It is what I call a strong  Principle.  This is a principle that exists in many companies, needs to exist in many others, and does not belong at all in some enterprises.  For example, a holding company may want to minimize cross-business unit dependencies in favor of the freedom to buy and sell units, without having the overhead of integrating and dis-integrating lots of IT capability and infrastructure.

Let me stick with this example and discuss how it can break down in practice – the difference between this Principle becoming a powerful tool to drive change, versus a waste of time and energy.  The first error I see in a lot of Principles is the addition of ‘weasel words.’  For example, a Principle such as my example above often gets softened to:

• We will optimize our IT investments for the enterprise rather than for individual business units where appropriate.

This is a weak Principle.  It has been watered down and is now impotent.  The second big mistake people make with Principles is that after going through the hard debate to air both sides of the choice, and eventually reach consensus (or however the decision is reached) they stop – declare success and move on.  Often, even worse, they don’t actually stop.  Instead, they wordsmith the Principle to death, laminate it in Lucite, or blow it up to poster size, and believe that if everyone has this on their desk or whatever, it will somehow magically become reality.  Strong Principles become strong tools of change when, once the Principle is agreed, you figure out, “What will need to change in order for behaviors to become compliant with the new Principle?  How will we effect those changes?”  As an example, Principles such as my example will at least need changes to IT governance, funding, portfolio management, and possible to the IT organization structure (i.e., what gets shared versus what is business unit specific).

So, I think the lessons to be learned to get the most out of this tool are:

1. Use principles ONLY to clarify strategic alternatives around points of pain.  (The exception to this is in developing Architecture Principles, where you typically drill down into multiple levels and domains to arrive at policies and standards).  A good test of this rule is, “Could a reasonably sane person argue the opposite?”  For example, with my example I did argue the opposite for the holding company case.  If you can’t argue the other side of the Principle, then its probably ‘motherhood and apple pie’ to use an American colloquialism.  i.e., you don’t need it – it’s a given.
2. Keep Principles strong – don’t allow wiggle room!  Forbid the use of words such as ‘where possible’, and ’where appropriate’.
3. Don’t stop with the principle.  Document your rationale.  Then figure out what things will need to change to make the Principle real.  Remember, if the things implied by the Principle are already happening, then you don’t need a Principle.  So, by definition, you arrived at the Principle in order to effect change.  What needs to change and how will you make those changes happen.
4. Principles set direction – there may be occasions where you will make an exception.  But do so formally and deliberately – acknowledge that it is an exception, and the rationale for the exception.

Filed under: Business-IT Governance, IT Management, Key Frameworks | Tagged: architecture principles, IT governance, Principles, strategic choice