<?xml version="1.0" encoding="utf-8"?>
<rss version="2.0" 
    xmlns:dc="http://purl.org/dc/elements/1.1/"
    xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
    xmlns:admin="http://webns.net/mvcb/"
    xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
    xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:itunes="http://www.itunes.com/dtds/podcast-1.0.dtd">
	<channel>
<title>The Razor&#x27;s Edge</title><link>http://www.interlogic-inc.com/index.html</link><description>Critical thought on the nuclear future&#x21;</description><dc:language>en</dc:language><dc:creator>bradwmson@interlogic-inc.com</dc:creator><dc:rights>Copyright 2008 Brad Williamson</dc:rights><dc:date>2008-06-04T09:16:19-04:00</dc:date><admin:generatorAgent rdf:resource="http://www.realmacsoftware.com/" />
<admin:errorReportsTo rdf:resource="mailto:bradwmson@interlogic-inc.com" /><sy:updatePeriod>hourly</sy:updatePeriod>
<sy:updateFrequency>1</sy:updateFrequency>
<sy:updateBase>2000-01-01T12:00+00:00</sy:updateBase>
<lastBuildDate>Wed, 04 Jun 2008 20:58:51 -0400</lastBuildDate><item><title>Iterative Solutions&#x2c; or why planning 10&#x2c;000 years ahead is a bad idea.</title><dc:creator>bradwmson@interlogic-inc.com</dc:creator><category>Philosophy</category><dc:date>2008-06-04T09:16:19-04:00</dc:date><link>http://www.interlogic-inc.com/3/files/2c54217972044b119aded9a18936d388-11.php#unique-entry-id-11</link><guid isPermaLink="true">http://www.interlogic-inc.com/3/files/2c54217972044b119aded9a18936d388-11.php#unique-entry-id-11</guid><content:encoded><![CDATA[I was musing about the failure of the U.S. government to come to terms with its responsibility and obligation to fulfill on the promise of long term high level radioactive waste storage with my friends and mentors the other day. I was struck by the concern that seems to be rampant among the public, the responsible government officials, and the scientific and technical effort associated with the Yucca Mountain project that we somehow provide a long term high level radwaste storage solution that will be viable for 10,000 years. <br /><br />Now maybe it's just me, but doesn't that strike you as ludicrous? We've barely been around that long as a species, at least as far as I've heard, and we have the arrogance to try to project a solution ten thousand years into to the future. How absurd, I trust you are saying about now. To declare that your assumptions regarding long term radwaste storage will be valid ten thousand years into the future is not only foolish, self-serving, and irresponsible, it does nothing short of guarantee the failure of the Yucca mountain effort.<br /><br />But this is not meant to be a railing diatribe against inane government policy, even if it may in fact be inane. (Currently the EPA is proposing a regulation  which will extend exposure limits to one million, that's right, 1x10E6, years. Guffaw!) Rather, I started speculating about the probability that a logical argument could be built against trying to finalize a solution that was expected to endure even more than 250 years. What follows here is not that argument, but some building blocks for the argument, to provoke a little conversation and some exploration of possibilities that might be effective in resolving the 'solution' enigma.<br /><br />Point A: History. At the time of the Roman empire, no one could have conceived that trans-global transportation, moving a person from say, Rome, to say, the yet unbuilt Chicago, could take less than 15 hours, as it does now, 1800 years later. You wanted to go somewhere, you marched. You wanted to go somewhere fast, you rode a horse or chariot. Humans could not see as far as the Boeing 777 burning refined petroleum landing on concrete runways three feet thick. In the 1600s, no one could have conceived that you could move tens of thousands of tons of product hundreds of miles for a few dollars a ton. They could not see as far as the GE Electromotive Division locomotive and rail infrastructure that connects freight with consumers nation wide on every continent. In 1900, the possibility that a man might walk on the Moon was science-fiction at best. But 69 years later, the Eagle landed, and what was inconceivable in the year 200, unimaginable in 1600, and nothing more than fantasy in 1900 became so commonplace as to be ignored in the prime time news hour. Even 40 years ago, no one would have predicted that we could cultivate and harvest grapes in Chile, pick and pack them, fly them to the US on a 747, unload, ship, store, and distribute them to your local grocery store in time measured in hours, and still sell them for seventy-nine cents a pound. <br /><br />Each of these advances required an iterative approach - we had to  try and sometimes fail at several intermediate points in order to accomplish the goal that we now appreciate as commonplace. <br /><br />Lesson learned: Interim situations are necessary, even required, for expanding our capacity to act in the future. We should approach something as critically serious as radwaste storage in a series of solutions.<br /><br />Point B: More history lessons.  History demonstrates that the cycle time for improving the effectiveness of solutions decreases with each iteration, that is, each time we effect a solution to a problem, the solution itself (Law of Unintended Consequences?) reveals breakdowns that the solution did not address. I don't know what the equivalent of Moore's law is for solution improvement, but I'll speculate that it is measured in years or tens of years, four or five orders of magnitude less than the Yucca mountain solution.<br /><br />Lesson learned: Identifying breakdowns fast and often moves you quickly through the learning curve of unanticipated issues to a successful implementation.<br /><br />Point C: As Will Rogers so gracefully said, "It's not what we don't know that causes us trouble, it's what we know that ain't so!" Human beings do not have much capacity for seeing the future. Meteorologists are proven wrong routinely within 24 hours, investors leap from windows to punctuate their skill in predicting the market, and the only people who consistently make money on horses are the bookies. And these are situations that are a full five orders of magnitude closer to the present in time than the Yucca Mountain solution. When we assume, or make an assumption about how things are going to be in the future, we necessarily must act as if that assumption is true. So as a consequence, we plan as if something is true, when for all intents and purposes, we can be almost certain that it is not.<br /><br />Lesson learned: Our assumptions about the future that provide foundation for our design are only as valid as our ability to predict the conditions under which the assumptions must remain valid, which we have seen historically is not very accurate. Shortening the range that our assumptions must survive makes our design more robust.<br /><br />Point D: Proponents for the one million year requirement make the assumption that the site will not be occupied, monitored, and improved during that one million years. As far as I can tell, no one has suggested such a thing as part of the design, construction, operation, and maintenance of Yucca Mountain. Historically, we identify failures in our design by usage and observation, not by guessing at how long we can stay away without anything going wrong.<br /><br />Lesson learned:  Continuous observation allows us to anticipate when and where breakdowns will occur, and modify the design to accommodate the new learning.<br /><br />Point E:  Technology is evolving at an ever increasing rate. One only need look at the last hundred years to realize that what we believe are the limits of technology today will be meaningless 10 years from now. When I was a boy, traveling from Chicago to Michigan for summer vacation meant 2 hours driving through the black hole of northern Indiana steel country. The sun was a vaguely orange disk through the cloud of black metallic tasting smoke from the steel mills that hung for 50 miles along the lake shore. People were so gripped by the story of steel that they couldn't conceive of life without the black cloud, and gritty fall-out that coated everything. That was the 60's. Twenty years later, the clouds were gone, because we had invented technology to eliminate them. Today, the steel mills are essentially gone, because their technology is no longer viable.<br /><br />History has shown that we are so unable to predict the technological future that we can't begin to imagine how nuclear radwaste storage will evolve over the next ten to twenty years. Prognosticator that I am, I'll go out on a limb and suggest that 250 years from now, radwaste won't be an issue, because there won't be any, meaning we will have invented technology that eliminates the production of radioactive waste. There, I've said it. Remember you heard it here first.<br /><br />Lesson learned: Time doesn't stand still - evolution in technology continues at a breakneck pace. If this is a technical issue now, expect that it will be resolved in 250 years.<br /><br />Point F: When we seek the perfect solution, nothing happens. No progress is made as we argue about the perfect and final solution. We are arguing about assumptions that we can no more prove than we can ignore the laws of physics. And nothing gets done.<br /><br />Lesson learned: Do something, even if it is not complete. As Patton said, "A good plan violently executed now is better than a perfect plan executed next week!"<br /><br />There are probably more points to be made, but this is enough to get started.<br /><br />Where do we go from here? <br /><br />First, abandon the existing plan, and shoot anybody who suggests that more than 250 years is necessary. Well, don't actually shoot them. Banish them from the halls of rational thought, because they don't belong there. <br /><br />Two, develop the 250 year solution. Two hundred and fifty years is enough time to evolve a better solution, and put it in place. <br /><br />Three, take all that money you saved by not developing the perfect solution, and create an investment account that pays for the execution of the 250 year solution, and for developing the next solution. I'm confident that we won't need more than one or two "250 year" radwaste storage solutions. If we do, send your complaints to this address. See what I mean?<br /><br />Four, tell your Senators and Representatives what you think. You can quote me if you like, but your words will probably come from the heart, and they need to hear from you, because they aren't thinking clearly.<br /><br /> I'm guessing that there is a paper that needs writing in all this. Any volunteers?<br /><br />I would be interested in hearing your comments and feedback.<br /><br /><br />]]></content:encoded></item><item><title>The Origins of the Razor&#x27;s Edge</title><dc:creator>bradwmson@interlogic-inc.com</dc:creator><category>Admin</category><dc:date>1995-02-14T13:06:02-05:00</dc:date><link>http://www.interlogic-inc.com/3/files/3f74f8b08e0ee91d463bdf8b45e4ec01-10.php#unique-entry-id-10</link><guid isPermaLink="true">http://www.interlogic-inc.com/3/files/3f74f8b08e0ee91d463bdf8b45e4ec01-10.php#unique-entry-id-10</guid><content:encoded><![CDATA[The "razor's edge" is a term used by Maturana and Varela in "The Tree of Knowledge" to describe the balance required to think and act in a world that cannot be completely objective and yet at the same time is not thoroughly without substance or order. To exist on the "razor's edge" is to live in an understanding that both extremes are nothing more than interpretations that we make, and to be effective in the world you must be a master at managing the middle ground.<br /><br />This interpretation has led us to explore new thinking that we have published here in a variety of articles on various topics, to provoke others to recognize different possibilities in diverse areas of business, life, and the world, where we observe that the traditional interpretations are breaking down and causing people to suffer. ]]></content:encoded></item><item><title>Robust Barriers and Good Design </title><dc:creator>bradwmson@interlogic-inc.com</dc:creator><category>Philosophy</category><dc:date>2006-02-24T22:15:55-05:00</dc:date><link>http://www.interlogic-inc.com/3/files/6a275f319684b335e5152784b2b96839-8.php#unique-entry-id-8</link><guid isPermaLink="true">http://www.interlogic-inc.com/3/files/6a275f319684b335e5152784b2b96839-8.php#unique-entry-id-8</guid><content:encoded><![CDATA[Lurking about my favorite root cause analysis forum,  reading the conversations about poka-yoke and robust barriers triggered a few thoughts, which are captured here. These are meant to encourage and challenge our collective thinking, not criticize, though sometimes it is difficult to sound that way.<br /><br />The issue of sound design, which is at the heart of poka-yoke and is central to the concept of robust barriers, seems to be worth discussing. Good design is the practice of anticipating the problems, breakdowns, and errors that can occur when equipment, systems, or processes are operated or executed, and incorporating features that PRECLUDE the possibility of errors occurring as a matter of design. It is a design issue - it takes place before the installation and operation of equipment or the execution of processes. Note the emphasis on preclude - this is important, and is echoed in the material available on poka-yoke, that the possibility of that error is eliminated - made impossible.<br /><br />Errors have occurred in hospitals where oxygen and nitrous oxide connectors allowed patients to be administered the wrong gas, resulting in several deaths. It was argued that the connectors were painted different colors to differentiate the two gases and avoid a mixup. Clearly this was not effective.<br /><br />Painting O2 and nitrous oxide connections different colors is interior decorating - it can help alert people to differences, but it is not good design. Creating connectors that are different shapes that precludes connecting to the wrong source is better design. Creating different shaped connectors that do not rely on a fragile alignment pin or tab that can break off is even better design, because it anticipates two failures - one of operator error (plugging into wrong system) and equipment breakage (no tab to fail, the square plug won't fit in the round hole). Creating different shaped connectors with no fragile tab that also automatically isolate when disconnected addresses a third failure, that of uncontrolled gas release. The design gets better all the time.<br /><br />Same thing with electrical appliance plugs. The error of connecting an ungrounded equipment case to the hot wire in the wall socket, which could kill someone, is prevented by, among other things, a polarized plug, or in other cases, the three prong plug. These designs anticipates errors in usage - user tries to plug into wall the wrong way, but does not prevent installation errors - the electrician could have wired the outlet incorrectly.<br /><br />In a certain nuclear power plant control room, control switches for different pieces of equipment are similar in shape and co-located, resulting in several significant errors where the operator turned off the wrong component. To minimize the possiblity of this happening, covers were installed over the one type of switches, to alert the operator that this was one type of component, not the other. This has prevented the error so far, and has been touted as an example of poka-yoke, or a robust barrier, though I would argue that it is not.<br /><br />A cover over a switch is not a robust barrier for mis-operation. It works when it works because it is a second action required on the part of the switch operator that is unusual, thereby causing him to examine his work process by triggering the question, "Do I have the right switch?" I would consider it a workaround, however effective, and not good design, in the application where it was used to prevent deliberate operation of the wrong switch. My speculation is that if you covered all switches with the same covers, the error rate would go back up, because there would be nothing unique to remind operators to second check themselves. That doesn't make it bad or ineffective necessarily, but I wouldn't consider it robust. It is easily defeated by deliberate or inadvertent mis-operation.<br /><br />By contrast, the switch cover would be considered good design if the switch were in a location that resulted in it being bumped accidently. (See the multiple NTSB reports on train crashes where a contributing factor was the engineer's knee bumping the switch that turned off dynamic braking in the other engines on multi-engine trains.)<br /><br />Interestingly enough, robust barriers and good design tend to work well to prevent errors of 'how' and 'where', but not so well on errors of 'when' or 'what'. That is, the gas connector and the polarized plug force correct connections (issues of 'how'). They don't control when - you can plug in gas or electric whenever you want. The switch cover protects against accidental bumps (an inadvertent 'when' error), but not against intentional errors, errors of 'what' (I wanted pump A but I operated pump B) or 'when' (it is OK to switch off pumps when shutdown, but not when operating).<br /><br />Maybe it would be better said that 'when' and 'what' errors require more complex solutions, from a design perspective. The Rod Worth Minimizer (RWM), and Rod Block Monitor (RBM) at a nuclear BWR are good examples. If you only want control rods moved under certain conditions (when) and in certain configurations (what) then the RWM and RBM represent a very complex system that enforces those constraints, usually right up to the moment that they are overridden!<br /><br />The struggle to develop good design that prevents 'when' and 'what' errors is well-documented, and has been a challenge. The Airbus crash at the Paris air show is an example of a failure in this battle. The design of a complex system, designed to eliminate many common pilot errors in flight, did not anticipate a unique but not unusual flight condition, where the airframe was in a landing configuration, but the pilot wanted to 'go-around' and applied full power. The design of the fly-by-wire control system prevented the pilot from manipulating the aircraft as desired, resulting in the deaths of all on board.<br /><br />An example of how 'what' errors are being effectively addressed includes the maintenance lock-out system on electrical breakers, where you cannot close a breaker until the lock is removed, and you can't remove it until the technician is done with maintenance, because he has the only key. An example of 'when' errors being addressed effectively is the two key system for submarine ballistic missile launches, which requires both keys to be turned at separate locations within a fraction of a second. You can't launch a missile unless two separate individuals agree on when (and multiple other criteria!).<br /><br />In conclusion - components of good design include anticipating problems in advance (or recognizing them in failure and recovering through organizational learning), and modifying the design to preclude those failures or errors.<br /><br />-----------<br />This article and incorporated images are &copy;2006 Brad Williamson All Rights Reserved. Permission is granted for reproduction not for profit in its entirety including this copyright notice.<br />-----------<br />]]></content:encoded></item><item><title>Narrative Translation as a Function of Management</title><dc:creator>bradwmson@interlogic-inc.com</dc:creator><category>Coordination of Action</category><dc:date>2005-02-21T22:08:33-05:00</dc:date><link>http://www.interlogic-inc.com/3/files/c98dcd7dac34da7d25fc2499c78d3015-7.php#unique-entry-id-7</link><guid isPermaLink="true">http://www.interlogic-inc.com/3/files/c98dcd7dac34da7d25fc2499c78d3015-7.php#unique-entry-id-7</guid><content:encoded><![CDATA[A critical role played by management in an effective organization is that of narrative translator. At one end of the employee spectrum you have the individual contributors, those employees that actually fulfill the promises of the organization to deliver goods and services. At the other end, you find the executives, the President, the CEO, or within a division or location, the Vice President. These are the individuals that create and define the promises that the organization makes, and wrap them up in a story that defines the organization.<br /><br />In between, you find supervisors, superintendents, managers, and directors, which for the sake of discussion we will call 'middle managers'. These middle managers have jobs which look like scheduling, planning, allocating resources, attending meetings, and so forth. But apart from the job description, there are several roles the middle managers must fill.<br /><br />One of these roles is that of narrative translator. The leaders of the organizations, the executives, are responsible for the story of the company. They craft the narrative that ties the organization together, that tells the customer and the share-holder what the company is about, and focuses the employees on fulfilling the promises inherent in that particular story. But the story of the company is too broad, too imprecise, and necessarily too global to be of much help to the individual contributor, who has to decide what he must do each day to fulfill the promises of the organization.<br /><br />The middle manager then must assume the role of translator, converting the story of the organization as told by the level of management above them into a more specific narrative and accompanying course of action for their direct reports. This is a continuous responsibility at all levels of middle management.<br /><br />For example, the CEO says we have to produce a certain return on our investments to satisfy or 'create value' for the shareholders. The Vice-President then translates that into a story that makes sense to the Director of Maintenance that sounds like "we are going to spend less than X dollars on maintenance this quarter and we will do that by reducing our outage downtime." This may make sense to the Director, but will more than likely escape the individual contributor, so the Director translates for his Manager, "We need to reduce scope so we can shorten the outage, I need you to identify work that can be done before the plant is shut down, so we can get it out of the outage." The Manager goes to the supervisor and translates, "give me a list of electrical maintenance items previously conducted during the outage that could be done with the plant at power." The supervisor gathers his direct reports and says something like, "Brainstorming session, what items are you working in the outage that could be done pre-outage?"<br /><br />For an organization to function effectively, it must be competent at translation. The story of the CEO has to be translated into something that is "actionable", that can be acted on by the individual contributor.<br /><br />A common observation is that management fails to translate, and merely 'parrots' or repeats the story of the executive leadership. "The boss said we have to produce value for the shareholder, so you guys get out there and start producing some value."<br />It should be obvious that the average individual contributor cannot produce action based on that kind of input. The resulting disfunctional organization flounders, and the individual employees are blamed for not producing value for the shareholder.<br /><br />There appears to be a loose correlation between the degree to which translation does not occur and the overall dysfunction or non-performance of the organization. Poor narrative translation results in less actionable work direction and therefore, poor performance. On the other hand, effective translation is revealed by effective action at all levels in the organization.<br /><br />A middle manager who ignores the role of narrative translation puts his people and his organization at risk.<br /><br />-----------<br />This article and incorporated images are &copy;2005 Brad Williamson All Rights Reserved. Permission is granted for reproduction not for profit in its entirety including this copyright notice.<br />-----------<br /><br />]]></content:encoded></item><item><title>The Distinctions of Role and Job in the Narrative of Work</title><dc:creator>bradwmson@interlogic-inc.com</dc:creator><category>Coordination of Action</category><dc:date>2005-02-17T22:06:28-05:00</dc:date><link>http://www.interlogic-inc.com/3/files/60c56976eb7019e9a7f8312765560426-6.php#unique-entry-id-6</link><guid isPermaLink="true">http://www.interlogic-inc.com/3/files/60c56976eb7019e9a7f8312765560426-6.php#unique-entry-id-6</guid><content:encoded><![CDATA[There are situations we have observed where employees cannot embrace the narrative of the business because they confuse the distinctions of role and job.<br /><br />We recently encountered a situation that involved an Instrumentation and Control (Ix) shop at a large power plant where work wasn't getting done. The backlog of broken, out of service, inaccurate and otherwise unavailable Ix equipment was large and continuously increasing. Both the manager and the technicians were at a loss of how to move forward and address this accumulation of what was essentially undone work. Nothing the manager could say or do seemed to make a difference in what was being accomplished, or more accurately, what was not being accomplished.<br /><br />We talked with the technicians about the nature of the backlog, and what they had to accomplish to repair broken equipment. They spoke of the administrative overhead associated with documenting work performed, of complex coordination necessary to take instruments off-line, and of long periods of inactivity waiting for support personnel, parts, or permission. When we talked about addressing these breakdowns, we would commonly hear things like, "That's not my job, I'm an Ix technician", or "All I want to do is fix the electronics, and they (meaning everybody else that wasn't a fellow Ix technican) won't let me do it."<br /><br />It became apparent that technicians were confusing their role as Ix technicians with their jobs as people who accomplished the repair of Ix equipment in a certain environment. The role of Ix technician was that of a trade or craft, where an individual has skills, knowledge, and abilities to work on Instrumentation and Control equipment.<br /><br />The job on the other hand, was a broader distinction. Dependent on the environment, it called for someone with the disciplines of an Ix technician to maintain, calibrate, and when necessary, repair Ix equipment in the context of a large power plant. This context required all employees to be masters at documentation, coordinating work, and anticipating and preventing breakdowns that occur with personnel, parts, and permissions.<br /><br />The technicians' role was to be Ix technicians, to demonstrate the skill and competence in working on Ix equipment. Their job was to take care of Ix equipment within the constraints and limitations of the greater context of the plant and to do so in a way that maximized the operational availability of their equipment, and accounted for documentation, coordination, and anticipation and prevention of breakdowns.<br /><br />These two distinctions were significantly different in scope, and easily confused. It was complicated by the fact that plant management refered to the job and the role by the same name of Ix technician. The very language used to manage the situation contributed to its complexity.<br /><br />In the end, the solution was surprisingly simple. A narrative about the job of being an Ix technician was crafted and presented in a manner designed to connect with technicians, and connect them to accomplishing the necessary backlog elimination. This new narrative revealed to the technicians, many for the first time, what it meant to be an Ix technician (role) in a Instrumation and Control shop (job).<br /><br />For them, and the backlog elimination project, success hinged on understanding the distinction between role and job.<br /><br />-----------<br />This article and incorporated images are &copy;2005 Brad Williamson All Rights Reserved. Permission is granted for reproduction not for profit in its entirety including this copyright notice.<br />-----------<br /><br />]]></content:encoded></item><item><title>The Role of Language and Abstraction in the Safe Operation of Complex Systems</title><dc:creator>bradwmson@interlogic-inc.com</dc:creator><category>Language and Linguistics</category><dc:date>2004-02-09T22:02:45-05:00</dc:date><link>http://www.interlogic-inc.com/3/files/b1889dbcb631b0688cf1f6583b074a68-5.php#unique-entry-id-5</link><guid isPermaLink="true">http://www.interlogic-inc.com/3/files/b1889dbcb631b0688cf1f6583b074a68-5.php#unique-entry-id-5</guid><content:encoded><![CDATA[This is the abstract to our paper, "The Role of Language and Abstraction in the Safe Operation of Complex Systems." For a copy of the paper, please contact Brad Williamson at blog@interlogic-inc.com.<br /><br />Operations of complex systems such as nuclear plants generate information regarding the health of the systems and comparisons to how the systems conform to the intent of the designers. Our interpretations about safe operation are therefore derived from valid problem indications as well as the potential distraction of irrelevant or insignificant data. Separation of legitimate problem reporting, the &ldquo;signal&rdquo;, from distracting and irrelevant issues, the &ldquo;noise&rdquo;, is only the first part of intelligent signal processing. Organizing those signals in a manner that enables you to form an effective assessment is the paramount operational challenge.<br /><br />Some signals are unambiguous; a worker gets hurt, equipment is damaged during a plant transient, or a relief valve lifts. For these instances, a series of actions is triggered to assess why the instance occurred and what can be done to prevent future occurrences. But what about those instances in which the problem report is not about a failure or the instance is not distinguished as a failure but rather as some sort of occurrence that falls short of our failure threshold? Notice now that the very use of the terms &ldquo;instance&rdquo;, &ldquo;failure&rdquo;, and &ldquo;problem&rdquo; each to attempt to distinguish a set of events, and perhaps more importantly, characterize our response.<br /><br />These distinctions are all in language, the words we speak and write, and the means by which we as human beings produce operational actions within our organizations. As such, the words we choose, their variation in meaning and intent, and the abstractions we make are critically important in producing the assessments that influence our actions, and ultimately, the performance of our plant, operation, or organization.<br /><br />The authors of this paper will, using examples from failures in complex systems including nuclear power and aerospace, examine how the words we choose, the way problems are labeled, reflects the organizational culture and pre-determines the organizational response. We will look at potential methods to improve the &ldquo;signal to noise ratio&rdquo; and thereby identify valid signals as the basis for forming effective assessments.<br /><br />-----------<br />This article and incorporated images are &copy;2005 Brad Williamson All Rights Reserved. Permission is granted for reproduction not for profit in its entirety including this copyright notice.<br />-----------<br />]]></content:encoded></item><item><title>Random Observations on the Ontology of Coordination Enablers</title><dc:creator>bradwmson@interlogic-inc.com</dc:creator><category>Coordination of Action</category><dc:date>1996-03-07T21:57:26-05:00</dc:date><link>http://www.interlogic-inc.com/3/files/b90a2df59dcddd90c0eec43abdf06221-4.php#unique-entry-id-4</link><guid isPermaLink="true">http://www.interlogic-inc.com/3/files/b90a2df59dcddd90c0eec43abdf06221-4.php#unique-entry-id-4</guid><content:encoded><![CDATA[We have written regarding the effectiveness of coordination enablers.<br /><br />"Our assessment methodology evaluates your organization against a set of Coordination Enablers that reflect the shared concerns that must exist to allow the coordination of action within organizations.<br /><br />"These coordination enablers include such concerns as:<br /><br />&bull; Relevant, mission oriented goals<br />&bull; Adequate performance standards<br />&bull; Adequate performance measurement methodologies<br />&bull; Effective communication of goals, standards, and performance measurements<br />&bull; Mechanisms to adequately reinforce superior performance<br /><br />In reflecting on why these enablers are effective I thought of the Navy and why organizational action was effective in the military. We observed that despite primitive inter&ndash; and intra&ndash;organizational communications systems (no emergent technology for the coordination of action) the organization was still very effective at accomplishing a variety of tasks or missions. We postulated that the existence of coordination enablers was critical to that success, but that didn&rsquo;t explain why.<br /><br />Since we wrote on that issue, I have been observing the impact that interpretation has on effective action. Interpretation, whether based on grounded assessments or speculation, is very powerful in defining the space of possibilities for action. For example, an individual examines a glass of water and declares it to be half empty. That interpretation of a fact (100 ml of water in a 200 ml glass) immediately restricts the space of opportunities to those that involve a half empty glass of water. It can no longer be treated as full or almost full. Additionally, the interpretation pre&ndash;disposes the alignment of new interpretations. Others will be less inclined to challenge the interpretation as not being effective. Further, interpretations will be made of the individual that further restrict opportunities for action. If the individual continues to make interpretations that are assessed as limiting, he will be &ldquo;labeled&rdquo; as a pessimist. This label is not a definition or a description, but a declaration of the space of opportunities that the individual represents.<br /><br />Back to the military example &ndash; a CO that is assessed as effective at getting underway on time makes interpretations of the environment in which he exists. His interpretation of the Squadron Commander&rsquo;s directive to &ldquo;never be late getting underway&rdquo; creates within him a space of opportunity that does not accommodate sailing late. His interpretation creates both the standard of always getting underway on time, and and interpretation of him by his crew as someone who gets underway when scheduled, even if &ldquo;they have to row it away from the pier.&rdquo; So being assessed as effective becomes primarily dependent on the interpretations one makes about the situation that ultimately define what is acceptable and what is not.<br /><br />On to nuclear power plant operation &ndash; the existence of coordination enablers is both a reflection and a reinforcement of the interpretations that exist with the organization. Absence of the enablers is a declaration that the interpretations that are being made preclude the possibility of success, as surely as the &ldquo;pessimist&rdquo; restricts his possibilities by his interpretation of the &ldquo;half&ndash;empty&rdquo; glass.<br /><br />So why do the enablers work? The work because they produce an interpretation within the employees that defines the space of possibilities, and when effective, the space of possibilities that is generated precludes the possibility of poor production.<br /><br />-----------<br />This article and incorporated images are &copy;1996 Brad Williamson All Rights Reserved. Permission is granted for reproduction not for profit in its entirety including this copyright notice.<br />-----------<br />]]></content:encoded></item><item><title>Annunciators Make Ineffective Performance Indicators</title><dc:creator>bradwmson@interlogic-inc.com</dc:creator><category>Performance Indicators</category><dc:date>1996-03-06T21:54:19-05:00</dc:date><link>http://www.interlogic-inc.com/3/files/72f254c15b3f80e6662e7ac481dc41ce-3.php#unique-entry-id-3</link><guid isPermaLink="true">http://www.interlogic-inc.com/3/files/72f254c15b3f80e6662e7ac481dc41ce-3.php#unique-entry-id-3</guid><content:encoded><![CDATA[Annunciators make poor performance indicators because they are driven by events rather than being used to drive performance. From a human factors perspective, annunciators exist to compensate for our inability to monitor large amounts of changing data effectively all the time. Thus, an annunciator is provided to warn the operator when a parameter exceeds some boundary. Note that the annunciator has limited value once in the alarm state because it cannot tell you anything else about the situation other than its still in the alarm state.<br /><br />Annunciators thus do not offer the feedback mechanisms typical of numeric type indicators such as information on rate or future state. In general the annunciators lack a linkage to analog interpretations that human beings use. Annunciators lack scale , trend or rate information. They have no ability to display current progress versus the goal.<br /><br />Annunciators are not anticipatory devices. They exist in one state or another. The use of three state annunciator windows (OK, Caution, Alarm) further confuses the purpose of annunciators regarding state change. The change in state is not necessarily proportional to the deviation from plan. Thus you can be in an alarm state for a minor deviation as well as a major deviation. It is the old teaspoon of sewage in the barrel of wine problem, its still sewage.<br /><br />Annunciators change state and then provoke action when what is desired is continuous action to achieve the goals. Continuous action is monitored with indicators that continuously display the value and if possible trend.<br /><br />Annunciators lack predictive power. There is no inference based upon current state to future states<br /><br />The coloration of annunciator windows changes with the state of the window. Unfortunately, there is no causal linkage generated from color change to what action might be required to reverse the state change. Thus the use of color coding for state change lacks a feedback mechanism to point towards action required or desired.<br /><br />The key to distinguishing effective indicating devices is the concept of DRIVING versus DRIVEN. Indicators associated with changing the current state of the process or business would be characterized as DRIVING indicators in a sense analogous to the speedometer on a car in which the operator varies the pressure on the gas pedal to adjust speed as indicated by the speedometer. Indicators that reflect what has just been accomplished e.g. historical items would be characterized as DRIVEN indicators. In the car analogy the odometer is a DRIVEN indicator because it reflects what has just happen as well as what happened before. Useful as the odometer may be to selling a used car, it does not have much relevance to the act of driving the car. In essence the odometer is a bean count of the miles a car has traveled.<br /><br /><br />Reference cited: McCormick, Ernest J., Human Factors in Engineering and Design,(New York: McGraw-Hill, 1982<br /><br />-----------<br />This article and incorporated images are &copy;1996 J. M. O'Connell  All Rights Reserved. Permission is granted for reproduction not for profit in its entirety including this copyright notice.<br />-----------<br /><br /><br />]]></content:encoded></item><item><title>On Annunciator Inadequacy</title><dc:creator>bradwmson@interlogic-inc.com</dc:creator><category>Performance Indicators</category><dc:date>1996-01-11T21:49:28-05:00</dc:date><link>http://www.interlogic-inc.com/3/files/4e087ba22d80211d177be38f62c8bd8b-2.php#unique-entry-id-2</link><guid isPermaLink="true">http://www.interlogic-inc.com/3/files/4e087ba22d80211d177be38f62c8bd8b-2.php#unique-entry-id-2</guid><content:encoded><![CDATA[Imagine a control room where the sum of all the indicators was reduced to eight or ten key indicators which, through competent design, provided the operator adequate information for control of the plant. Annunciators would not be needed unless it was intended or expected that the operator would not focus his attention on the indications.<br /><br />This, of course, raises the question of what mechanism could be used to display information in a manner that would obviate the need for annunciators. The current background listening in the domain of engineering does not allow for the existence of analytical indicators. By analytical I mean instrumentation that presents an interpretation of the situation or event, rather than reporting some engineering fact.<br /><br />We are starting to see trends in that direction in combat aircraft flight information displays. Velocity vectors and waterline indicators are HUD related information that make interpretations about the future of the aircraft based on current status. This relieves the pilot from having to make engineering assessments of flight parameters in order to maneuver the aircraft. They make a declaration that if the pilot continues as things are, the plane will be in this position in the future.<br /><br />At this point, we make another distinction between predictive and interpretive. Predictive is merely an engineering, mathematical, or mechanical projection of the current situation into the future. Interpretive is the incorporation of judgment or multi&ndash;parameter reasoning or evaluation into the indication. In this sense, the tactical display information in the F/A&ndash;18 HUD is predominately predictive. Designs are being proposed, however, that would assimilate all sensed and calculated information and present the pilot with best possible choice displays. For example, based on current flight parameters, detected threats on the ground and in the air, and the declared ground target from the navigation computer, a single color monitor could present the pilot with a pseudo three&ndash;dimensional map that presents the &ldquo;least threat&rdquo; path to the target. This is clearly in the interpretive realm, and also not ready for control room indication.<br /><br />What then does interpretive indication mean in the context of the control room? What kind of judgment or interpretation do we use to drive these displays? Can information be reduced to meaningful operational indicators that adequately address the full range of concerns that exist? These are questions that must be answered before we can competently present alternatives to the clearly less than adequate annunciator methodology. Without alternatives, there is no compelling argument for change. Without change, we will continue to exist in an environment where annuciators are seen as adequate and effective.<br /><br />-----------<br />This article and incorporated images are &copy;1996 Brad Williamson All Rights Reserved. Permission is granted for reproduction not for profit in its entirety including this copyright notice.<br />-----------<br />]]></content:encoded></item><item><title>On Performance Indicators</title><dc:creator>bradwmson@interlogic-inc.com</dc:creator><category>Performance Indicators</category><dc:date>1995-11-30T21:42:38-05:00</dc:date><link>http://www.interlogic-inc.com/3/files/651080c8884f79d543ca3a422e789529-1.php#unique-entry-id-1</link><guid isPermaLink="true">http://www.interlogic-inc.com/3/files/651080c8884f79d543ca3a422e789529-1.php#unique-entry-id-1</guid><content:encoded><![CDATA["Task based measurements are finite Cartesian interpretations that restrict you to incremental change. You can only make the process more efficient. Outcome based measurements ask "Why" instead of "How" and open up the possibility for quantum changes in performance because they are not preconditioned to accept that the process has to exist at all."<br />-----------<br />This article and incorporated images are &copy;1995 Brad Williamson All Rights Reserved. Permission is granted for reproduction not for profit in its entirety including this copyright notice.<br />-----------<br />]]></content:encoded></item><item><title>Welcome to the Razor&#x27;s Edge&#x21;</title><dc:creator>bradwmson@interlogic-inc.com</dc:creator><category>Philosophy</category><dc:date>1995-01-01T12:00:00-05:00</dc:date><link>http://www.interlogic-inc.com/3/files/f9b27d8dfc2bb53ce3b4e6330a291691-0.php#unique-entry-id-0</link><guid isPermaLink="true">http://www.interlogic-inc.com/3/files/f9b27d8dfc2bb53ce3b4e6330a291691-0.php#unique-entry-id-0</guid><content:encoded><![CDATA[Razor's edge thinking on issues of management of change, configuration, assets and margins, safety conscious work environment, safe operation of complex systems, causal analysis, management assessments and investigations, performance measurement systems and tools, linguistics, neuro-biology, producing action, requests and promises, and other extremely "outside the box" perspectives on life, the universe, and everything.<br />]]></content:encoded></item></channel>
</rss>