IT Organization Design: Part 2


Picking up on my previous post on Organization Design and the Value Disciplines, my colleague Roy Youngman reminded me of the theoretical work by Henry Mintzberg that we drew from many years back.  At that time, Roy was helping me to write a book, Development Effectiveness: Strategies for IS Organizational Transition.  (Note:  I’m not plugging the book – it was written in 1994, and while I think much of it is still relevant, there are more current and relevant books on the topic today.  I include the link here in the interests of completeness.  Of course, if you want to buy a copy, that’s OK too!)

Anyway, Roy has been using the Mintzberg insights with a current client to great effect, and as I was on the subject of organization design, I thought it was worth revisiting these ideas.  Mintzberg’s Theory on Organizational Forms discusses four “standardization” strategies that can be applied in organizational design:

  • Standardization of work processes, which achieves coordination by specifying the work processes of people carrying out interrelated tasks.  This is the common model for things that are routine and sequential (e.g., IT operations, data center, telecommunications, IT infrastructure, etc.)
  • Standardization of outputs, which achieves coordination by specifying the results of different work.  This is the best model for things that are collaborative and perhaps visual.  This is perhaps the dominant model for systems development and programming.
  • Standardization of skills (as well as knowledge), in which different work is coordinated by virtue of the related training the workers have received.  This is the model for things that are complex and exploratory.  There is an element of this in all IT roles, but tends to apply mostly in the more technical and operational roles (think Microsoft Certification programs, Project Management Institute, etc.)
  • Standardization of norms, in which it is the norms infusing the work that are controlled, usually for the entire organization, so that everyone functions according to the same set of beliefs.  I’ve found over the years that IT groups with the most cohesive culture (i.e., they have a shared sense of their destiny, and a passion for fulfilling it) are the most effective in driving performance and leading transformations.  For example, at their best, movements such as Total Quality Management and 6 Sigma instill norms of quality management.  I’ve also found (though this is unfortunately not the norm) values initiatives such as Johnson & Johnson’s Credo Values, and Google’s Mission to be effective ways to motivate and focus people around important values and norms.

Like most models, Mintzberg’s theory is valuable because it simplifies reality.  While the reality of IT organizations can be quite complex (e.g., Mintzberg’s standardization strategies all apply to IT roles to various degrees) it can help to think about the dominant strategy for a given IT capability.

We often find the standardization strategies and the interventions to achieve them get confused.  For example:

  • We see people trying to standardize work processes for things that are not routine and sequential – think of waterfall life cycle methodologies applied to rapid, iterative development!
  • I once worked with a health sciences company who was trying to standardize software development processes in order to comply with Federal regulations, when what was really called for (and far more easily implemented across about 10 business divisions with their own IT shops at very different levels of maturity) was standardization of deliverables (outputs.)
  • We see simple training programs as futile attempts to induce norms such as self-accountability.  Or, as an industry, we have suffered for years without standardization of many crucial IT skills.  Even today, PMI Certification (and legitimate and worthy credentials) are not taken seriously by a majority of IT leaders.
  • I believe that most IT shops pay too little attention to standardization of norms.  For example, many lower maturity groups believe their mission is to do what their business partners ask for, as opposed to do what they actually need.  This reflects norms such as, ‘the customer is always right’ and ‘to be successful I must behave as an order-taker’ rather than ‘my role is to help create business value from IT investments’ and ‘the customer is not always right – they expect us to push back and guide them.’

So, think about standardization in your organization – have you applied the appropriate standardization strategies to your important IT capabilities?  To drive business-IT maturity, what would you like to change with regard to these standardization strategies?

About these ads

Business-IT Maturity and the Portfolio Lens


I was with a client recently as their CIO was leading one of their regular “town hall” meetings (live meeting for those in HQ, videoconference for those elsewhere).  He was talking (eloquently!) about Next Generation Enterprises, Web 2.0 technologies and the implications for their company and for their IT / shared services organization.

A question from the floor asked if ITIL (Information Technology Infrastructure Library)was incompatible with the move towards becoming a Next Generation Enterprise (NGE).  It’s an interesting question.  It is easy to perceive NGE’s as chaotic, emergent, free-for-alls - characteristics that seem to be at odds with the rigor and process discipline inherent in approaches such as ITIL, CMMI, 6 Sigma, and so on.  There can seem to be all sorts of inconsistencies and ambiguities in the idea that, on the one hand, we are implementing all this process discipline, while on the other, we are moving to a world of rapid experiments, open networking, emergent teams, and all sorts of loose collaborations, both within the enterprise, and with customers, suppliers and the outside world.

As is often the case, I find the Business-IT Maturity lens helpful in sorting out this apparent dichotomy.  In this case, I want to add another model that I find helpful in thinking through these issues, and then combine the models.  First, as a reminder, below is a version of the basic Business-IT Maturity Model that has been central to many posts on this blog.

bus-it-small.jpg

Business-IT Maturity Model

Next, I want to consider an IT portfolio model.  The model below comes from Professor Peter Weill at the MIT Sloan School.  It is a very useful portfolio view that classifies IT spend (or investment) into infrastructure (common and shared IT capability), transactional, informational and strategic.

2075304175_6bb851c15f1.jpg

IT Portfolio Model

This model divides IT spend (or investment, depending upon how it is being used) into 4 classifications.  To a degree, Level 1 Business-IT Maturity is all about getting the right IT infrastructure capability.  Level 2 is about getting the right transaction processing capabilities in place.  And Level 3 is about the strategic and informational IT capabilities.  Again, I realize this is a crude approximation, but it helps us to realize what types of IT investments we should expect to focus on as we move through business-IT maturity, and how the shape of the IT portfolio might change with that maturity journey.  Putting the portfolio model on top of the maturity model creates the following picture.

mat-plus-pfm-small.jpg

IT Portfolio Mapped Against Business-IT Maturity

So, the IT portfolio can be something of a proxy for business-IT maturity.  Compared against ‘average’ infrastructure spend, a Level 1 organization will be higher than average.  Compared against ‘average’ transactional spend, a Level 2 organization will be higher.  And compared against ‘average’ informational and strategic spend, a Level 3 organization will be higher.  Now there are many issues that can distort this simple view.  If your transaction processing systems are a mess of dozens of different instances of disparate systems, you are probably at Level 1, but will have inordinately high transactional spend because of all the complexity in your transactional systems.  So, higher than average transaction spend may be more a symptom of lack of Level 2 attention, than a byproduct of Level 2 investment.

Finally, back to the opening question – are ITIL and NGE approaches incompatible?  No, not all all – they are focused on very different capabilities.  ITIL will help improve Level 1 and Level 2 IT capabilities, but do little to nothing for Level 3.  If you are moving into Level 3, you need strong Level 1 and Level 2 capabilities, which leverages techniques such as ITIL and CMMI.  But these same techniques will not get you to Level 3.