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:

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


Structure in Threes: One Enterprise’s Capability is another’s Function

Spent a portion of yesterday going through my project archive (two four drawer lateral file cabinets).  Mostly to clear out duplicated or outdated materials, but some was information mining for the book.  Typically on engagements I spend a fair amount of time to understand clients mental models, language and corporate culture with the objective to operate and communicate in the organizational structure with as little disruption as possible.  While this assists my clients, as I go to the effort of translating concepts into their language so they don’t have to spend the cycles.  This allows them to focus on exploiting the solutions, recommendations I propose and get value from these faster.  Which gets to the point of this post.

The mysterious language of strategy-speak.  Pick up any book on strategy the past decade or two and you’ll see a discussion on the importance of Corporate Capabilities.  The problem being though is the definitions are rather fuzzy.  Is CRM a function or a Capability or both or Software Product or now a Service?  Clearly if we are discussing the “ability” for an organization to manage customer relationships effectively we’re talking capability.  If we discuss the organizational unit tasked with preforming tasks associated with managing customer relationships it would be labeled a business function; which become even more confusing when we add the software products meant to enable performance of those tasks which could be either a product or a service.  And you thought your teenager’s language was confusing.  Those that enter the discussion without context need to spend extra effort to decipher if they can from the dialog.

Why I bring up this semantic problem?  This becomes a critical matter when designing an optimum organizational design.  I stress designing the “optimum” design; like product engineering there are many possible configurations possible.  However, there are a fewer configurations that fit the specific enterprise’s working environment, corporate culture and resources.  These are the high level design inputs parameters which affect the design decisions.  Unfortunately, there hasn’t been a metrics driven approach toward organizational design –something I’m in the process of remedying now through this book– that would include usage of concepts such as Taguchi’s Design of Experiments for design optimization.  However, to use such an approach one needs to standardize on terms such as these, the attributes and metrics associated with these.  Which again brings me back to my achieve and the broad spectrum of models and definitions I’m wading through to create a consistent ontology for Enterprise Design.

I had hoped to avoid the Yet Another Framework (YAF) trap, but I’m still seeing wide variance between associations and societies languages, as broad as what I experienced working on the ISO 103030 (STEP) standard.  My goal is not to create still one more framework, but rather the transformations similar to those John Zachman mentions as key with he discusses his framework. These would not be between cells but between other framework constructs.  The point behind such activity is to make the specific representation system any enterprise uses transparent to the design effort.


These materials though will likely be in the appendix or associated supporting website for the book, as it will likely be a long term effort and would delay development of the core design methodology.

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.

Translating Business to Enterprise Architecture: Methodology Activity #4

Portfolio Decision Making Methods

The process by which alignment occurs in organizations is never a simple activity.  While it would be great to have a mathematical formula that generates enterprise architecture from business strategy, the fact of the matter is that there is no one right answer that fit for all.  Having business strategy x does not always translate to enterprise architecture y.    

The alignment of Business Strategy and Enterprise Architecture resembles algebra or calculus more than simple addition.  The areas that have yielded promise:  multi-variant analysis, Real Options (a derivative of options theory); Bayesian models, and quality function deployment.  If this appears to be a short course in decision science it is. 

In the 80s Marylyn Parker et al, at the IBM Los Angeles Scientific Center developed a methodology, BEAM, which guided MIS directors on the prioritization of I.T. investments.  If it was created today it would likely be called Balance Scorecard for I.T.  Unfortunately the timing was not right for acceptance of this approach, nor was access to corporate strategy or decision authority granted at the senior MIS levels.  But that doesn’t make it less useful today.  The heart of BEAM is using multiple weighted criteria to establish a prioritized list of I.T. investments in line with Business priorities.

BEAM worked well in determining priorities; however, in today’s economy long horizon projects such as infrastructure decisions create a problem.  Many organizations are unwilling to have projects that have 18 month horizons.  Today the name of the game is short cycle and agile.  This strategy is useful in limited technical risk, but there is a tradeoff it also restricts the potential upside.

What is needed a means to merge the benefits of large projects with the flexibility or short cycle and agile.  This is where options theory shines as a method.   The feature behind Real Options (options theory) is the dividing a project or investment into a sequence of investment decisions that are made after over the course of a project.  These decisions are whether to invest another segment of the total investment.  So at each investment point or option of the project, if partitioned correctly, the decision marker is faced with determining whether the next investment is of value and alignment with current conditions.  The previous point is evaluated as to whether it reached its immediate goal, nothing more.  Likewise the next investment decision or option is only evaluated in context to what it provides.  This decision is made as to whether to invest for what value the option brings or not.  A large project becomes a series of continuation decisions over time rather than the big bang investment approach.

Bayesian decision models allow one to yield a decision based upon decision criteria factors weighted as each has different relative importance in a decision.  Applying this method –similar to BEAM—enables a more effective decision.

Quality Function Deployment aids in defining the features needed to fulfill needs.  This technique can be adapted in the design chain I’ve previously discussed in this blog.         

Translating Business to Enterprise Architecture: Methodology Activity #2

Capabilities from this context are the “what do we need to be able to do” to enable the strategy.  This requires more thought than just saying we need the capability to collaborate.  Collaborate by itself is just an activty with no context. If we add a software application associated with collaboration we’re still not talking about a real strategic capability.  There is a lot still missing from such a short capability definition.  To be effective a capabilities definition should contain what activitiy, who is envolved, what is to be accomplished and how. 

 Using capability to collaborate as an example, it would be neccicsary to define the what and who of collaboration.  This could be “we need to have our marketing staff around the country collaborate on collecting and analyzing market intelligence to determine new opportunities”.  This moves the definition from a broad and vague initiative to a supportive activity that could be associated to a strategy such as “the enterprise being more market agile and adaptive than competitors”.   When associated with this strategy those in the organinzation can see why collaboration capability is important and how it should be implemented. 

This definition also brings to the surface that developing a capability is more than just providing technology, it infers that there are people to be envolved with skills and knowledge, information that needs to be supplied and further sub-activties to be accomplished other than just sharing the base information.  This underlying information with the objective of usage or what is to be accomplished provides the context on how the capability is to be used to provide the what of the satrategy.  With this context established the further refinement of creating the capability by selecting the technology, configuring its, and informing staff on its usage is kept in alignment with the strategy.  Too many technology driven projects often are successful in deployment of software, but fail in implmentation for te business.  Further research had shown that while the technology was functional, its usage was never thought of or publized in context to the enterprise strategy.  In some exterme cases the implementation and thereby adoption was actually counter to the enterprise’s goal.  As such while capability discussions seem simple these are crictially important and is where most of the loss of value occurs.  It is my believe this is where most initatives start going off track and further deviate from the path as the activities move from the abstract to the concrete.

Information Management/Taxonomy reading list

Going back through my posts this evening.  Found that I didn’t post the Information Management/Taxonomy reading list I had stated I would.  Here it is in no particular order:

  • Quality Information and Knowledge, Huang, et al
  • Data Smog, Shenk
  • The Accidental Taxonomist, Hedden
  •  Organizing Knowledge, Lambe
  •  Finding the Concept, Not just the Word, King
  • Business Metadata, Inmon
  • Principles of Semantic Networks, Sowa
  • Semantics in Business, McComb
  • Information Space, Boist

Enterprise Taxonomy: Wicked Problems

One of the interesting this about taxonomy work is that it exposes value systems and mental models of the participants.  Take for instance a simple organizational design and development project.  Various terms are thrown around in a casual manner and have different meanings depending upon your background.  The term Business Function has been used to mean the activity or action taken within an company –this could be a synonym for process—or the association of people with a common purpose and management, commonly called groups, divisions, or departments (e.g, HR Department).  While the term or label used often infers a result that both definitions produces, when working to define taxonomy this ambiguity and automatic context shifting people do unconsciously results in serious nightmares for information systems.


Above is a simple data model of an enterprise I’m working on today.  The goal is to define a model of how an organization functions.  There are many models out there; Value Chain (Porter), Value Net (Slywotzky), Division (Sloan) and Generic Enterprise (McKinsey) to name a few.  These models all create taxonomies in which to classify and place instances of a working company’s structure into a framework for thinking.  However, the ontology beneath these taxonomies is often hidden.  Thus without the context of the authors the terms definitions diffuse into ambiguity eventually becoming overloaded and creating chaos.  Did you mean the activity or the group of people when I say function?  Information Systems are not smart enough yet to ask programmers or end users what you mean by that term.

 While this sounds like a fairly esoteric and academic issue, I assure you it’s not.  The project is real.  The various companies and stakeholders are trying to decide how to restructure to gain competitive advantage or at the least gain efficiencies to capitalize of new opportunities on the horizon.   Without a common framework to organize around companies become misaligned and operate very poorly.  In not the worst case scenarios, departments work at cross purposes or even counter to each other.  In the 80s I watched two divisions literally undo each other’s work RIGHT IN FRONT OF THE CUSTOMER.  It was painful to watch from a professional organization.   When I debrief both organization heads both were positive they were following the company’s direction. 

 The next step in this activity would be to associate processes, capabilities, and other resources to these functions.  However, the context switch between activities vs. management structure (org-charts) models that the prior are based upon results in many misalignments and wicked programs.  If a Business Function is a people association structures at which decomposition layer into smaller units to you assign roles which is the linkage between key processes, the value stream and competencies needed to perform these activities within the “function”.   Add to this mixture that multiple functions and multiple competencies participate all participate in multiple value streams and processes, it become a web of complexity quickly.    

 Again while it sounds fairly esoteric I had to be brought in to straighten out this issue when one corporation decided to implement another’s process.  They wanted to keep how the company was structured but they also wanted to use the process.  It took several months to be able to rationalize the differences in terms and frameworks for the corporation to successfully deploy the process.   The alternative was to turn the corporation inside out to match the model the processes and software had. The choice to rationalize vs. change organizational structures was one of find the least objectionable alternative.                           

 –all this is neded to resolved before you could place the taxonomy into SharePoint’s Term Store for publication to various farms