Structure in Threes: Organizational Design

Business Structure verses Organizational Structure

One of the interesting issues that came across my desk today as I was discussing a colleague’s new venture was the taxonomy and ontology of our conversation.  She wanted to cover multiple concepts in the same conversation which is a notable goal regarding economy of one’s time.  However, it became apparent that the terms being used were being overloaded during the conversation.  Example: Discussing the Business Structure and Organizational Structure both terms were used interchangeably.  However, when I hear the words Business Structure I think of the legal form in which the business is established (Corporation, LLC, Partnership, etc.).  When I hear the term Organizational Structure I consider whether it is centralized or distributed; a partitioning along functional, product, customer or geographic lines.  As I continue to develop the Business Design Tool (see below) the question becomes how-to ensure that the dimensions are orthogonal to each other while retaining the interconnectedness of these dimensions.

Organizational Development Tools

Many of the recent texts define various dimensions such as complexity, market, size, etc.  However, the interconnection is only a Infographic.  Perhaps these interconnections are only a probabilistic connection leading one to only heuristics.  I will make a interesting systems dynamic study at the Center for Understanding Change when I have some spare time.  In the meantime I continue to develop the Org Design and Modern IT Portfolio Management tools which are looking more and more like an enhancement to the Business Analysis System and Environment (B.A.S.E.) application built in 1994 on MS Access V1.

B.A.S.E. at that time performed a variety of management consulting analysis:

• Porter Competitive Analysis which has been advanced by Slywotzky’s Value Nets and then further by Osterwalder’s Business Model Canvas which the Org Design tool is working to further advance into a Computer Aided Design (CAD) tool for Organizational Development and Management Consultants
• BEAM which was created by Parker and Benson is being advanced through the R&D to a Modern IT Portfolio Management methodology
• MBA Product Planning which has been superseded by Design Insight’s (Peter Marks) Customer $APPEALS

This application will eventually become the basis for the semi-automated workflow for several of Intellectual Arbitrage Group’s practices and services

 

Forces that influence increasing IT Economics maturity

The maturity of resource allocation of most IT organizations are typically less than the resource allocation maturity of the enterprises that host these.  This is not a surprising finding given people and groups usually adopt the norms and behaviors of the context they are surrounded by.

For an IT organization to increase it’s Economics Maturity it needs to address the concerns of its host.  This suggests stakeholder analysis and managing expectations is of significant importance, possibly more importance than the level of precision of the actual economic justification.  Texts on decision analysis  indirectly discuss this phenomena.

One strategy to mitigate this issue is to choice the appropriate level of methods for both decision and organizational decision maturity.

Many organizations often in an effort to expedite decisions either choice methods that are too simplistic.  This can result in decisions that don’t address the nuances of the problem or are not repeatable as inputs and influences to the decision are not explicitly, hidden in pockets of subject matter experts or decision makers.  The other alternative are decision processes that are overly complex.  Initially the rational of these complex processes is to provide a comprehensive system for making decisions.  Where this often goes wrong is that the process becomes the standard and dogma for all decisions.  Thus creating a bureaucracy for decisions.

A possible remedy for this unintended consequence is to develop a  series of decision processes at different levels of complexity and guidance as to when to use which.   While it can be argued with the information technology one all encompassing process can be created and automated thereby reducing the overhead in these processes making them easier to execute.  The problem with such a strategy is that it neglects that the decision maker still needs to understand the attributes and variables to make an effective decision.  For a complex decision there are not only multiple variables but typically require time to digest the interaction of variables.  Using a similar process for simple decisions places undue delay.

Another strategy is to create a decision team composed of the stakeholders, guide them through the development of the economics case themselves.  This has several benefits.  First it helps raise the knowledge level of the group.  Second it help build confidence in the methodologies used  as they develop experience.  Third, an open discourse explicitly raises concerns of stakeholders to be addressed.

Discipline Maturity Lifecycle: Enterprise Architecture example

Spent this morning thinking about operating models in IT organizations and ITIL initiatives.   After a few minutes of pondering , hearing a group next to me at a conference extol the virtues of the 4hr days a few thoughts came back to me; the IT discipline is still in a low state of maturity.  If I was to use a human scale, the IT discipline is like a 5 year old copying its older brothers thinking it is all grown up.  Sure the IT Discipline has many elements that other more mature design and development disciplines have, however, the behavior, standards, ethics and other aspects around the profession have yet to develop.

This revelation is not new to me, years ago I had started quantifying how other design disciplines evolved and matured.  I had presented a corkscrew diagram at some conference back then and left it as an interesting phenomena.  As I was in a keynote session the image popped back in my mind and the book I had started but never finished.

What triggered that thought process was a discussion of the Enterprise Architecture discipline/practice.  This had triggered another memory of drafting a paper and proposal to create “The Architect’s Office” within an IT Organization I was working in.  Some of the issues are still the same which were taken from my studies in residential architecture and later field experience:  Architectural Practice is not like Howard Roark in Anne Rand’s The Fountainhead the majority of the time.  It is a social and community effort.

There are two aspects to successful architectural firms:

• The Practice BOK –the body of knowledge and activities used to perform and deliver value to the client.  This is where most practitioners focus when discussing the discipline.  The mechanics of deliverable creation.   While this is the      foundation of any discipline and it grows as it matures, it is only part of the practice.  Many EA firms have yet to take that jump into operating the discipline as a business as opposed to only a methodology of delivery.

• The Business –the selection of market, the value defined to be delivered, and the means on how value controlled and delivered (aka the Business Model).   Without knowing your business model Enterprise Architectures are prone to produce limited value to customers though providing what was requested.       Eventually, the practice could end up in a different business or on the corner with a sign “will architect for food” as the activities performed do not deliver an acceptable cost benefit ratio to  clients. This suggests that architects need to understand their market and alternatives to their delivery of value.       Many residential architects left the calling in the 70s & 80s as customers failed to see the value they provided over general contractors that had draftsman on staff.