April 6, 2009

Constraint Abstraction

Posted in Business, Technology tagged , , , , , , , , , , , , at 4:04 pm by lindaslongview

cc_descamaradoWhen I first started working professionally in chemical engineering, I only worked on technical problems.  As such, I only saw, knew, and understood technical issues – my level of abstraction was limited.  As my career matured, I realized that logistical issues often trumped technical issues for achieving the goals of the organization. So I gained mastery in solving logistical problems.  Then, as I understood even larger levels of abstraction, I realized that organizational issues often trump both technical and logistical issues and so I gained mastery in solving organizational challenges.

I have found that in order to be effective in the development and commercialization of emerging technology over the long view, one must recognize the domain of the system constraint and be attentive to changes (as the organization progresses and the marketplace matures). Mastery of all three domains is required to successfully develop and grow an emerging technology business.

Domain differences are assessed by level of concreteness (or the level of insight that can be achieved through measurement, modeling, and computation):

  • Technical challenges are addressed through physical/chemical/mathematical models and measurements of physical quantities. Direct quantitative comparison of competing phenomena creates optimized technical processes that meet stated goals.
  • Logistical solutions rely on intuitive understanding of outcomes. Discrete event simulation can build intuition and help to create optimized processes, but there is no direct analytical optimization.
  • Strategies for resolving organization issues are least concrete. Detailed logical analysis (if-then scenario analysis) provides direction for solution but requires experience and excellence in future projection.

Why is it hard?!  Because the situations are all too common.  For example:

The organization must improve conversion at step X (upstream) to stay within market costs, so a technical team is deployed to address it.  It is also recognized that the separation at step Y (downstream) must be improved to achieve scalability, so a separate technical team is deployed to address it.  Then the business team makes the case that they need more products to sell (to potential clients, to show investors breadth, ….) so yet another technical team is deployed to develop processes using key technology at step Z (finishing) in new applications or markets.  However, technical resources are limited (the technical organization is small) and many of the same people are working on X, Y, and Z simultaneously.

By trying to do too much, organizational constraints emerge from technical constraints. Because these types of problems emerge slowly, they are often unrecognized and unaddressed until damage is done (insufficient progress is achieved for X, Y or Z to satisfy stakeholders).  Although some tolerance for multitasking is inevitable, not all technical specialists are equipped to recognize and manage progressions from technical → logistical → organizational constraints effectively for success.

Does your business have a technical challenge now, but an organizational challenge waiting to happen?

March 14, 2009


Posted in Uncategorized tagged , , , , , , , , , , at 12:49 am by lindaslongview

As a veteran of understanding complex systems, it is not terribly surprising that sometimes the unexpected occurs. It is not so much that humans have poor intuition, it is more that we 1) oversimplify (we focus on a specific element and not the whole), 2) we underestimate the affect of randomness, 3) we do not account for a changes in underlying assumptions of our mental models, and 4) we overvalue the expected outcomes because we become emotionally attached to the outcome.

As a trivial example of the unexpected, I am whining about my sore hands after having returned to running and climbing after a month of ankle injury hiatus (the climbing calluses on my hands receded and my hands became soft). So even though I expected to be most challenged by my ankle, it is actually my hands that are unexpectedly sore — I did not anticipate the whole picture.

As a really BIG example of the unexpected, the core of the financial mess that the world is currently experiencing can be traced to an oversimplified quantitative model that failed to account for changes in market assumptions – see Wired (March 2009): “A Formula for Disaster.” (Very interesting yet short article).

My experience in managing complex systems coincides with all of the wisdom and experience of others before me — take the long view: pay attention to the capacity constraint of the system, be wary of process steps with similar capacity to the constraint either upstream or downstream (they could easily become the constraint), and stay aware of external factors that can impact the system. The most important advice is to assume that Murphy exists and plan for managing it. To that end, if you do not have good intuition under different scenarios and want to build it to plan for it (for example, recovery from disruption), I recommend discrete event simulation with Simul8.

I am sure that there are other reasons than the four (4) I listed for the unexpected to occur. I invite you to add reasons 5, 6, 7….