Posts Tagged ‘system’

System Science And Fat Heads

April 26, 2009 Leave a comment

I recently finished reading John Warfield’s An Introduction To System Science . John asserts that whenever you try to design a system that will involve human beings during its operation (and what non-trivial system doesn’t? ), you must take into account these two universal human characteristics:

If your technical system design doesn’t pay homage to these human frailties, it will most likely fail – big time. The money will be gone, the time will be gone, and the damn thing won’t work. Warfield claims that his generic system design process effectively deals with these issues. In his book, John describes his process and cites several examples of it’s success in the public, private, and educational domains.

Warfield also says that the biggest hurdle to overcome, which he doesn’t have a solution for, is the propensity of high level executives  for refusing to accept/acknowledge great ideas founded on firm principles from subordinates. I believe what John says, but in my layman’s mind, I equate this strange and unproductive behavior with  egomania. The higher up you go and the more titles that you acquire, the bigger and fatter your head gets. Of course, there are always exceptions to every rule :^)

Government Business

March 26, 2009 Leave a comment

The figure below is a UML (Unified Modeling Language) class diagram that models a fictional government contracting system. So you don’t know UML? Don’t leave, because UML is easy to understand if one doesn’t over-specify in an attempt to show the world how “smart” he/she is.

The diagram shows the players (“classes” in UML lingo) in the game and some of the relationships (“associations” in UML lingo) between them. The diagram can be understood as follows:

The taxpayer funds congress, which funds groups of government bureaucrats, who hire a contractor to develop and deliver a product to be used by government workers to do their job of serving the public. Money, which everyone worships of course, ties all these main power players together. The contractor develops a product, which is then (delivered to the government and is) used by the government workers. All is well and the world becomes a better place. Whoopeee!


Yawn, meh. Boring and uninteresting, no? But wait, there’s more. Some hidden relationships between the “classes” in the system are not displayed by this proper and politically correct diagram. The diagram below shows just one of these hidden relationships – mistrust – between everyone 🙂 . How did this mistrust emerge and infiltrate the system? From the players getting burned in the past, that’s how. Especially the ultimate source of all money in the system – the taxpayer.


The last figure in this post shows the dynamic behaviors exhibited by each of the active players in this goverment business dance.  In the UML, the middle compartment in a “class” (which is nothing more than a type of object – a classification) is intended to hold the attributes that characterize the class. I purposefully left them out because they’re not important to the message I’m trying to communicate.


I’ll leave it to your imagination to create specific scenarios of system operation (called “use cases” in the UML).  Scenarios are specific subsets of behaviors that are sequentially strung together in time (scenarios can be modeled with UML “sequence diagrams”). At the end of a given scenario execution, the system has achieved a specific goal, like “make everyone in the system miserable”, or “damage the environment”, or “reward those who deserve it the least and punish those who are innocent of wrongdoing”.

Are there any significant players missing in this system? Are there any relationships missing? Are there any behaviors missing? Got a different model of how this government system works or how it should work? Remember this:

The purpose of a system is what it does, not what its advocates say it does.

Thanks for listening!

A Rigged System

March 25, 2009 Leave a comment

Based on observation and personal experience, here’s my assessment of how the system nominally executes:

  1. A customer issues a Request For Proposal (RFP) or a Request For Quote (RFQ) for a product that meets a perceived need.
  2. The competitors respond with a proposal that contains a solution, a price, and a schedule.
  3. An organization wins (kudos and high-fives all around)!
  4. A program team is formed in the winning organization.
  5. The program team inherits the proposal schedule.
  6. The proposal is communicated to the product development group (PDG).
  7. The PDG forms a product development process (PDP) team.
  8. The PDP team analyzes the proposal and constructs a PDP schedule.
  9. The PDP team executes the PDP.
  10. The PDP team performance doesn’t *match* its own schedule OR the original proposal schedule – sometimes by a large amount.
  11. The customer, the organization, the program team, and the PDP team suffer the consequences.
  12. Go to step one for the next effort.

The figure below illustrates the nominal system operation, where M = Milestone.


Sometimes, but not always, the developer organization “forgets” the original proposal schedule and, via the magic of cognitive dissonance, praises the PDP team at the end of the effort for being on schedule and under budget. Sometimes, even the customer conveniently “forgets” original proposal schedule, but the customer’s financial sponsor usually doesn’t.


Do you agree with the assessment of the system’s nominal operation? If you agree with it, then consider these follow on questions:

For each of the participants in the system, where do you think the suffering starts?

Do all participants suffer equally? If not, which participant do you think suffers the most?

Is anyone at fault, or are the unintended consequences a byproduct of the system’s behavior?

What management techniques can be employed to drive “the measure of underperformance” to zero, or ideally, to a negative value?

Are there some management techniques that, if applied, will cause greater underperformance?

If you don’t agree with the assessment, then please tell me why, and what your experience has been.

Do you think the cognitive dissonance scenario exists?

If so, have you experienced the cognitive dissonance scenario?

In the cognitive dissonance scenario, even though the outcome is falsely deemed a rousing success, do you think there is any suffering by one or more participant groups during execution?

System Architecture Notation

March 14, 2009 Leave a comment

For years and years, I’ve used the simple circle and square notation shown in the top half of the figure below in order to communicate (mostly to myself) multi-technology system designs. I did it because UML hadn’t been invented yet, and circles/squares were trivial to draw with any software drawing tool.

Now that UML has been out for quite a while, I’m gonna (try) and switch to the UML notation shown in the bottom half of the diagram. Even though packages and nodes are slightly harder to draw than circles and squares with most mainstream drawing tools, every UML tool makes it as easy as pie. Even Visio (my favorite engineering graphics tool) has templates for easily generating UML notation.


Categories: miscellaneous Tags: , , , ,

Contained And Container

March 14, 2009 Leave a comment

In Russell Ackoff‘s excellent book titled Idealized Design , he talks about container and contained systems. He essentially states that optimizing the contained system without changing the container system is a failure in waiting. The figure below depicts what often happens  when a change agent succeeds in improving the contained system without consideration of the container system.


At time 1, the change agent realizes that there is an efficiency problem within the contained system. After an epic battle against the forces conspiring to keep the status quo intact, he/she succeeds in smoothing out the operation of the contained system at time 2. However, since the container system was neglected, it still operates according to the old rules and interfaces of time 1. Thus, an impedance mismatch between the container and contained system interface has appeared. This impedance mismatch can cause organizational performance to be worse than before the change (the cure is worse than the disease) to the contained system!

In an ideal system change effort, both the container and contained systems are improved. Done correctly, a smooth and high performing system-of-systems, like the above model at time 3, can be achieved. Compare the smooth circular integrated interface at time 3 with the previous inefficient and cloudy interfaces of the previous 2 times.

%d bloggers like this: