8D Problem Solving for Transhumanists

Posted in transhumanism on January 13th, 2011 by Samuel Kenyon

Transhumanists are into improvements, and many talk about specific problems, for instance Nick Bostrom. However, Bostrom’s problem statements have been criticized for not necessarily being problems, and I think largely this is why one must consider the problem definition (see step #2 below).

Sometimes people talk about their “solutions” for problems, for instance here in H+ Magazine. But in many cases they are actually talking about their ideas of how to solve a problem, or making science-fictional predictions. So if you surf the web, you will find a lot of good ideas about possibly important problems—but a lot of what you find will be undefined (or not very well defined) problem ideas and solutions.

These proposed solutions often do not attempt to find root causes or assume the wrong root cause. And finding a realistic complete plan for solving a problem is rare.

8D (Eight Disciplines) is a process used in various industries for problem solving and process improvement. The 8D steps described below could be very useful for transhumanists, not just for talking about problems but for actually implementing solutions in real life.

Transhuman concerns are complex not just technologically, but also socioculturally. Some problems are more than just “a” problem—they are a dynamic system of problems and the process for problem solving itself is not enough. There has to be management, goals, etc., most of which is outside the scope of this article. But first one should know how deal with a single problem before scaling up, and 8D is a process that can be used on a huge variety of complex problems.

Here are the eight steps of 8D:

  1. Assemble the team
  2. Define the problem
  3. Contain the problem
  4. Root cause analysis
  5. Choose the permanent solution
  6. Implement the solution and verify it
  7. Prevent recurrence
  8. Congratulate the team

More detailed descriptions:

1. Assemble the Team

Assemble the team

Are we prepared for this?

With an initial, rough concept of the problem, a team should be assembled to continue the 8D steps. The team will make an initial problem statement without presupposing a solution. They should attempt to define the “gap” (or error)—the big difference between the current problematic situation and the potential fixed situation. The team members should all be interested in closing this gap.

The team must have a leader; this leader makes agendas, synchronizes actions and communications, resolves conflicts, etc. In a company, the team should also have a “sponsor”, who is like a coach from upper management. The rest of the team is assembled as appropriate; this will vary depending on the problem, but some general rules for a candidate can be:

  • Has a unique point of view.
  • Logistically able to coordinate with the rest of the team.
  • Is not committedd to preconceived notions of “the answer.”
  • Can actually accomplish change that they might be responsible for.

The size of an 8D team (at least in companies) is typically 5 to 7 people.

The team should be justified. This matters most within an organization that is paying for the team, however even a group of transhumanists out in the wilds of cyberspace will have to defend themselves when people ask, “Why should we care?”

2. Define the Problem

What is the problem here?

Let’s say somebody throws my robot out of an airplane, and it immediately falls to the ground and breaks into several pieces. This customer then informs me that this robot has a major problem when flying after being dropped from a plane and that I should improve the flying software to fix it.

Here is the mistake: The problem has not been properly defined. The robot is a ground robot and was not intended to fly or be dropped out of a plane. The real problem is that a customer has been misinformed as to the purpose and use of the product.

When thinking about how to improve humanity, or even how to merely improve a gadget, you should consider: Have you made an assumption about the issue that might be obscuring the true problem? Did the problem emerge from a process that was working fine before? What processes will be impacted? If this is an improvement, can it be measured, and what is the expected goal?

The team should attempt to grok the issues and their magnitude. Ideally, they will be informed with data, not just opinions.

Just as with medical diagnosis, the symptoms alone are probably not enough input. There are various ways to collect more data, and which methods you use depends on the nature of the problem. For example, one method is the 5 W’s and 2 H’s:

  • Who is affected?
  • What is happening?
  • When does it occur?
  • Where does it happen?
  • Why is it happening (initial understanding)?
  • How is it happening?
  • How many are affected?

For humanity-affecting problems, I think it’s very important to define what the context of the problem is.

3. Contain the Problem


Some problems are urgent, and a stopgap must be put in place while the problem is being analyzed. This is particularly relevant for problems such as product defects which affect customers.

Some brainstorming questions are:

  • Can anything be done to mitigate the negative impact (if any) that is happening?
  • Who would have to be involved with that mitigation?
  • How will the team know that the containment action worked?

Before deploying an interim expedient, the team should have asked and answered these questions (they essentially define the containment action):

  • Who will do it?
  • What is the task?
  • When will it be accomplished?

A canonical example: You have a leaky roof (the problem). The containment action is to put a pail underneath the hole to capture the leaking water. This is a temporary fix until the roof is properly repaired, and mitigates damage to the floor.

Don’t let the bucket of water example fool you—containment can be massive, e.g. corporate bailouts. Of course, the team must choose carefully: Is the cost of containment worth it?

4. Root Cause Analysis

Root cause analysis

There can be many layers of causation

Whenever you think you have an answer to a problem, as yourself: Have you gone deep enough? Or is there another layer below? If you implementt a fix, will the problem grow back?

Generally in the real world events are causal. The point of root cause analysis is to trace the causes all the way back for your problem. If you don’t find the origin of the causes, then the problem will probably rear its ugly head again.

Root cause analysis is one of the most overlooked, yet important, steps of problem solving. Even engineers often lose their way when solving a problem and jump right into a fix which later on turned out to be a red herring.

Typically, driving to root cause follows one of these two routes:

  1. Start with data; develop theories from that data.
  2. Start with a theory; search for data to support or refute it.

Either way, team members must always remember keep in mind that correlation is not necessarily causation.

One tool to use is the 5 Why’s, in which you move down the “ladder of abstraction” by continually asking: “why?” Start with a cause and ask why this cause is responsible for the gap (or error). Then ask again until you’ve bottomed out with something that may be a true root cause.

There are many other general purpose methods and tools to assist in this stage; I will list some of them here, but please look them up for detailed explanations:

  • Brainstorming: Generate as many ideas as possible, and elaborate on the best ideas.
  • Process flow analysis: Flowchart a process; attempt to narrow down what element in the flow chart is causing the problem.
  • Fishikawa: Use a Fishikawa (aka Cause and Effect) diagram to try narrowing down the cause(s).
  • Pareto analysis: Generate a Pareto chart, which may indicate which cause (of many) should be fixed first.
  • Data analysis: Use trend charts, scatter plots, etc. to assist in finding correlations and trends.

And that is just the beginning—a problem may need a specific new experiment or data collection method devised.

Ideally you would have a single root cause, but that is not always the case.

The team should also come up with various correction actions that solve the root cause, to be selected and refined in the next step.

5. Choose the Permanent Solution

The solution must be one or more corrective actions that solve the cause(s) of the problem. Corrective action selection is additionally guided by criteria such as time constraints, money constraints, efficiency, etc.

This is a great time to simulate/test the solution, if possible. There might be unaccounted for side effects either in the system you fixed or in related systems. This is especially true for some of the major issues that transhumanists wish to tackle.

You must verify that the corrective action(s) will in fact fix the root cause and not cause bad side effects.

6. Implement the Solution and Verify It

This is the stage when the team actually sets into motion the correction action(s). But doing it isn’t enough—the team also has to check to see if the solution is really working.

For some issues the verification is clean-cut. Some corrective actions have to be evaluated with effectiveness, for instance some benchmark. Depending on the time scale of the corrective action, the team might need to add various monitors and/or controls to continually make sure the root cause is squashed.

7. Prevent Recurrence

It’s possible that a process will revert back to its old ways after the problem has been solved, resulting in the same type of problem happening again. So the team should provide the organization or environment with improvements to processes, procedures, practices, etc. so that this type of problem does not resurface.

8. Congratulate the Team

Party time! The team should share and publicize the knowledge gained from the process as it will help future efforts and teams.

Image credits:
1. Inception (2010), Warner Bros.
2. Peter Galvin
3. Tom Parnell
4. shalawesome

Also published in H+ Magazine.

Tags: ,

Culture Alt Delete

Posted in culture, transhumanism on November 4th, 2010 by Samuel Kenyon

Now published on h+ magazine: my article “Culture Alt Delete: Steampunk and Transhumanism.”

The expanding threads of steampunk are statements of what could have been, nostalgia for a retro-future, and false memories of an alternate history.

Read more…

Image credit: Don Pezzano (modified by Sam Kenyon)

Tags: , , , ,

Multitask! The Bruce Campbell Way

Posted in culture, interaction design, posthuman factors, transhumanism on September 7th, 2010 by Samuel Kenyon

Some have pointed out the supposed increase in multitasking during recent decades [1]. An overlapping issue is the increase in raw information that humans have access to. It is certainly a fascinating sociocultural change. However, humans are not capable of true multitasking. First I will describe what humans do have presently, and then I will discuss what future humans might be capable of.

photo of Bruce Campbell talking on a cell phone

Bruce Campbell

“Multitasking” in humans is primarily switchtasking combined with scripting:

  1. Switchtasking [2] is to switch between tasks. This can be done quite rapidly, so fast in fact that you might feel as though you are truly multitasking.In the past I have suggested that attentional consciousness is like a single-threaded manager [3]. However, I want to be clear that I’m not saying there’s a Cartesian Theatre [4]. I’m saying that the brain, although highly parallel at certain levels of detail, has a functionally singular attention and working memory system. Whether the model of a top-down manager is valid in all circumstances is undetermined. Neuroscientists have found a model with top-down influences on visuospatial working memory [5], but that is not necessarily the case for all mechanisms involved with attention.

    How can you have two centers of conscious activity at the same time?

    How can you have two centers of conscious activity at the same time?

  2. Scripting is the auto-piloting in your mind. A script is the sequence of steps that you can do without conscious attention.These scripts are often activities you had to learn at first, for instance bicycling and driving. The reason driving while multitasking is notorious is that the script works until something happens that breaks the script, such as a person wandering out in front of your car suddenly. When the script breaks, your attentional consciousness is interrupted to attend to the situation, but by the time you have decided what to do it might be too late.
Image credit: Paul Oka, CC Attribution-NonCommercial-NoDerivs 2.0 Generic

Image credit: Paul Oka, CC Attribution-NonCommercial-NoDerivs 2.0 Generic

You can drive your car with your scripts, meanwhile entertaining yourself with detailed telemetry (e.g. MPG, engine temperatures, etc.), MP3 players and satellite radio, video players, GPS navigation, your cell phone handling multiple calls and running multiple applications, etc. I think many people would love to be able to handle all those interactions at the same time. Some people try and end up crashing. And there’s always the few who abuse technology in special ways [6].

I consider background tasks like listening to music to also be just that—in the background. If you actually pay attention to music, you will find that you are not doing it at the same time as your other task (e.g. writing)—you are switching between them.

Cyborg Multitasking

In the future, humans may be able to truly increase their multitasking capacity.

An obvious question is, why bother?

My speculative answer: Society has increased the expectation for simultaeous activities; at the same time social interactions through always-on mediums are massively popular. Humans desperately want omnipresent interaction multiplicity—be it for work, social interaction, entertainment, or all of the above. The enabling technologies are already here—the real limiting factor is the human brain.

Even when people know they are less efficient due to switchtasking, it is still quite difficult to use that premise to revert to a more efficient way of working, and to be focused for longer periods of times on single tasks [7].

Personally, I switch between periods of single-tasking and switchtasking. However, being able to focus for a long period of time on one thing depends on you and your situation. Which brings us to enhancement.

One of the potentially popular mind enhancements will be multitasking. This could start off with working memory enhancements. Then we would be able to switch between more tasks (or more complex tasks) while having the necessary information still loaded for all of them. But true multitasking will require enhancements to our attention system.

This essay is not about how it can be done technically—maybe it will involve drugs, cyborg technology such as electronic implants and nervous interfaces, other types of invasive objects like nanobots, substrate changes (e.g. to digital computers) that enable programmatic enhancements, or none of those. Whatever the case, we can acknowledge some of the problems multitasking cyborgs or posthumans will face.

Problems with Multitasking

in ancient rome there was a poem
about a dog who had two bones
he picked at one he licked the other
he went in circles till he dropped dead
—Devo, “Freedom of Choice”

The main problem is that multitasking will change the architecture of attentional consciousness and working memory. The changes for the new architecture have to take into account control of the body—attempting to answer the phone with the same hand that is ironing could be disastrous. Likewise with trying to run in two directions at the same time. Choices that affect or require the use of limited body resources must reduce to a single decision.

Also, multiple tasks that require visual perception will have to wait for each other (basically resulting in switchtasking again) unless we also are enhanced with extra visual perception inputs. In general, the limits of the sensory modalities will limit the types of tasks being done at the same time, a problem we already have with our primitive switchtasking.

The other architectural problem is that the multiple attention sub-systems need a way to stay in sync. It’s feasible that a part of the mind would have to become a meta-manager, although that could just be the default attentional consciousness controlling the others.

The Man with the Screaming Brain

The Man with the Screaming Brain

From the outside, broken multitasking behavior would look like dissociative identity disorder [8], or even worse, like Bruce Campbell in the movie The Man With the Screaming Brain [9]:


[1] http://singularityhub.com/2010/08/26/are-we-too-plugged-in-distracted-vs-enhanced-minds/

[2] http://blog.crankingwidgets.com/2008/08/19/switchtasking/

[3] http://www.science20.com/eye_brainstorm/multitasking_consciousness_and_george_lucas

[4] http://en.wikipedia.org/wiki/Cartesian_theater

[5] http://www.klingberglab.se/pub/Edin2009.pdf

[6] http://www.thesmokinggun.com/documents/bizarre/woman-nabbed-auto-erotic-crime

[7] http://lifehacker.com/5041144/debunking-the-myths-of-multitasking

[8] http://en.wikipedia.org/wiki/Dissociative_identity_disorder

[9] http://www.imdb.com/title/tt0365478/

Tags: , , , , , , , ,

H+ Summit @ Harvard

Posted in transhumanism on June 13th, 2010 by Samuel Kenyon

This weekend I attended the H+ (transhumanist) Summit at Harvard University (live streamed videos here).

We were invited to blog about it on Scientific Blogging which added a special tab for H+ and a category for the theme of the conference, which was Rise of the Citizen Scientist.

So I made a new blog there, In the Eye of the Brainstorm, so far with two three posts related to transhumanism and/or the conference itself:

Kurzweil’s Phenomenological Consciousness

Cat Usability Testing (Wolfram’s Predictions)

Pirate Evolution

Note that SynapticNulship (this site) is still my main blog for artificial intelligence and interaction design writings. (The posts mentioned above are on this blog as well.)

Note for those interested in presentation skills: The most lively talk was by Seth Lloyd.  Interestingly, he did not use a computer.

Tags: , , , , ,