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 Three: Governance

This week’s research agenda continues on governance and the interfaces of controls with decisions processes for portfolio management.  The further I dive into COBIT 5 the more I like the taxonomy and structure.  While there are gaps, these are explicitly called out in the management guide where research is needed.  Which is interesting as those are the areas I’ve been focused upon, so at some point convergence is likely.  I’ve started to White-Board an assessment tool (MS Access DBMS) which would include COBIT-like concepts yesterday.  As I reverse engineer and rebuild my Access V1 Consultant Workbench (B.A.S.E.) I’ll be adding TIPA & COBIT to the modules I previous built for the platform.  I like using ACCESS more as an intelligence platform that EXCEL due to its ability to build relational models, however, as of late I’m looking at build highbred applications using SharePoint, ACCESS Services and EXCEL.

With more than a few years under my belt in management consulting, methodology and support tools development I have come away with insights on how to make consulting practices more efficient and effective.  B.A.S.E. was developed with that insight in mind years ago.  However at that time management consulting was operated around time & materials billing rather than outcomes, so efficiency and effectiveness in operation was counter to the revenue model.  If it took less time to deliver results to the client you were taking money out of your pocket.  Despite calls for outcome based billing by such notables such as Allan Weiss, Peter Block, and Gerald Weinberg the industry and oddly enough clients still used T&E as the primary billing method.  Which I suppose makes both parties more comfortable and believe easier to contain risk, as time consumption is easier to measure than progress to an outcome.  Just an interesting side-note.

As I continue governance research, the next major area to develop is adoption.  While COBIT 5 describes the change management within implementation, like most other implementation activity very little is defined in this arena.  The majority of efforts listed are on planning the technical rollout and communicating the schedule of such.  From my experience with reengineering processes, such approaches limit effectiveness of change programs.  If left to the end of the lifecycle, stakeholders are suddenly thrust into dealing not only with technological and process aspects but also social and emotional aspects as well.  And as experience has shown experts in the field we continue to ignore, people take longer to change attitudes and behaviors than it takes to implement the technology and define the processes.  The work that John Kotter has accomplished on change management  looks to provide a good base, the next level of development is to move from his strategic framework to create a catalog of tactics and methods to support each stage similar to the business development framework I’ve been recommending to small and medium business colleagues by C.J. Hayden .  End of week I hope to post draft of tactics and methods for adoption stages or find and post a reference by someone else that has already done the research.

Structure in Threes: Capabilitiy Models

Most of yesterday was dedicated to continuing to fix my wife’s IPhone contacts and syncing with desktop.  By 10pm I had finally reloaded a restored copy of her contacts to both laptop and phone.  Later today its back to AppleCare to restore her apps.  Apple is still suggesting using ICloud to sync multiple devices, but at this juncture its unlikely she will trust any cloud provider.  This has taught her a lesson businesses are either about to learn the hard way or have Enterprise Architects, like myself, developing disaster contingency and continuity plans prior to jumping to the cloud:  Technology changes that you run your business on require serious change management.  And even then the a poor implementation can require many hours to recover.  Another lesson or side benefit, she’s starting to see what my career really is about: enabling others,  preventing crises, and recovering from crises.  The unfortunate thing about the Enterprise Architecture profession is that goals one and two are what enables goal three, but goal three is the only one that gets other’s attention.

This morning before jumping back on IPhone recovery, I’m reading through the COBIT 5 management guide.  It’s rather odd how most standards, processes and models now take the form of the CMMI maturity model.  While I’m a supporter of the maturity model construct it has it’s deficiencies or rather I should say poor adaptation of the concept leaves deficiencies in the applied domain.  Often I’ve seen various organizations adapt the maturity model construct for their domain of expertise but as a marketing tool to infer gaps which their product or service naturally fulfills.  However, these capabilities are often not completely filled by the product or service as the capabilities have to be built with these tools, knowledge, processes and behaviors.

The COBIT 5 generic capabilities model points to level characteristics, level generic enablers, and generic level enabler capabilities.  However, it appears the rating of conformance is a subjective exercise.  May be that is acceptable at present as this field become more defined.  However, linking performance to organizational design then become more subjective also.  It may be the design methodology I’m working on will have to include the concept of tolerance and performance ranges (similar to physical product engineering) for the results of selecting the various design attributes.  I’ll have a better handle on that when I encode the governance model into a spreadsheet and link it to the organizational design spreadsheet.  The results should give me a more robust assessment criteria as well as a diagnostic tool for clients that will guide them to a more specific areas to address rather than a shotgun approach.


Structure in Threes: Change Management and Adoption

Wednesday I went back to Microsoft main campus to meet with friends, colleagues and management for a potential new role.  Had several interesting discussions with each.  The curious take away I came up with was a feeling of Déjà vu.  Like other enterprises I’ve designed and installed processes in, the real challenge is not design and development.  Though considering the aspects that improve adoption early in the design process is necessary but not sufficient, the hard part is adoption management.  That set of planning and execution activities that help organizations move from current state to transition state to new status quo.  There are many models and books on the market about change management.  Some of my favorites are those by Harvard Professor Kotter.  Other authors such as Hiatt (ADKAR), Association of National Advertisers (DAGMAR), Cialdini (Influence: Science and Practice) ,and Bosworth & Eades (Solution Selling) are divided into the marketing or behavior sciences realm.  The unfortunate aspect of most of these books is the practical application of these theories is left to the reader.

I can understand why this is; people are not machines that work in a repeatable and predictable manner.  While they may have tendencies to act a specific way there are no guarantees, if there were a magic formula Crossing the Chasm or finding the Tipping Point would be easier to do.  Given that people and organizations are a complex interaction of entities with conditions and events finding the right formula of activities to allocate funds to oft times becomes a quest for the holy grail resulting in analysis paralysis.

Those organizations that try the shotgun approach (throw everything at it and see what sticks) are on the other side of the spectrum.  Both approaches are less successful, typically achieving success due to chance rather than design.  Examples being those enterprises that spent so much time analyzing the Internet, they missed the bubble then later claim brilliance and insight for not investing rather than painfully slow processes. Or those ventures that charged ahead and as luck would have it had some measure of success then collapsed as the items that stuck did not constitute a sustainable business.

Change and adoption is similar in that either end of the spectrum may have some success by chance during a specific set of conditions and events.  However, when the conditions change or a new event occurs, snapback to the old way of doing things happens and one finds out that the organization really did not change how it was operating it just put a new veneer on over what it really was doing.  I call this the Jell-O Pyramid model.  Often leaders and change agents think they are being successful as they view the change from the top where they are applying pressure.  This bends the point of the pyramid in the direction they would like to go.  However, once the pressure is removed unless sufficient pressure was exerted long enough to move the base, the  pyramid snaps back to its original shape and position.  This suggests the need for a measurement and monitoring system similar to those pointed out in Stafford Beer’s research.  However, I’ll leave that for another blog post.

For the pragmatics of adoption I found a model in the small business arena of business development.  A book by C.J. Hayden, Get Clients Now!.  The book does not claim to be a master’s thesis in change management or sales.  What is does do that other books do not with its system, is move one from formula and theory or strategy to tactics.  In other words she’s created a system of strategic execution if I throw a Harvard label on it.  The book does not profess to tell you do A, then B, the C and get result D.  What it does do is show you tactics that have some strong correlation to success for various aspects of moving from one stage of business development to another.  She does not tell you specifically do A, but provides a list of potential “A”s, “B”s, and “C”s  that have had success for others.  These are tactics you can look at and quickly execute and measure results.  She continues with here system by having you measure both executing these tactics and the results.  This becomes the feedback system so important to ensuring you are actually doing something planned verses just doing everything.

I bring up this book as an example as I see this as the model to be used for change and adoption management, then after considering this I saw a similar pattern of execution management –without the list of tactics– in using Hoshin Planning.  I expect that the change and adoption planning section of the book with merge these two concepts.

Managing the change and adoption process suggests one measures current state, activities and reactions and sentiment