Process complexity
Often we believe that if we just instituted good processes, we could hire inexperienced people to follow them, train them well to follow the processes well, and then our projects would go smoothly.
The problem is, most of our projects are not in the realms of "Simple" or "Known" (these terms come from 2 different versions of the Cynefin framework), that which is the proper realm for process reengineering and best practices, where bins can be identified and once you find the bin your situation is in, you just enact the preprogrammed response.
Rather, most of our projects are at least in the "Complicated" or "Knowable" realm, if not the "Complex" realm. In both of these, we have difficulty just following process. Complicated situations embody cause and effect separated in distance or time, so we need to analyze to figure out what the right thing to do is. In complex situations "cause and effect are only coherent in retrospect and do not repeat"...an excellent regime for Monday-morning quarterbacking but not an easy place to predict in advance what to do.
My theory here is that when we find ourselves in a complex or complicated situation and we are told to follow processes that assume a Simple or Known situation, here is where we deviate from the processes. We intentionally apply more knowledge than the processes think is necessary...we use our brains, also called our "internal neural networks".
One advantage that neural networks are known to have that is superior to sequential computing is pattern recognition and associativity...meaning, this is *like* something I have seen before. Our brains do this, much better than processes encoded in text and stored digitally. We look for processes that might handle the current situation, and if we don't see one that avoids the problem we saw in the past, we move on and invent one that we think might be better.
Of course, inventing processes for documenting game software is a bit different in effect than inventing processes for testing a nuclear power plant...the latter could blow you up and possibly destroy a large part of the planet.
In general, we need to become more aware of what complexity is, how it affects our products and our development programs, and what we should do about it.
I am in the process of making new modules related to this for my Complex Systems Engineering course.
The problem is, most of our projects are not in the realms of "Simple" or "Known" (these terms come from 2 different versions of the Cynefin framework), that which is the proper realm for process reengineering and best practices, where bins can be identified and once you find the bin your situation is in, you just enact the preprogrammed response.
Rather, most of our projects are at least in the "Complicated" or "Knowable" realm, if not the "Complex" realm. In both of these, we have difficulty just following process. Complicated situations embody cause and effect separated in distance or time, so we need to analyze to figure out what the right thing to do is. In complex situations "cause and effect are only coherent in retrospect and do not repeat"...an excellent regime for Monday-morning quarterbacking but not an easy place to predict in advance what to do.
My theory here is that when we find ourselves in a complex or complicated situation and we are told to follow processes that assume a Simple or Known situation, here is where we deviate from the processes. We intentionally apply more knowledge than the processes think is necessary...we use our brains, also called our "internal neural networks".
One advantage that neural networks are known to have that is superior to sequential computing is pattern recognition and associativity...meaning, this is *like* something I have seen before. Our brains do this, much better than processes encoded in text and stored digitally. We look for processes that might handle the current situation, and if we don't see one that avoids the problem we saw in the past, we move on and invent one that we think might be better.
Of course, inventing processes for documenting game software is a bit different in effect than inventing processes for testing a nuclear power plant...the latter could blow you up and possibly destroy a large part of the planet.
In general, we need to become more aware of what complexity is, how it affects our products and our development programs, and what we should do about it.
I am in the process of making new modules related to this for my Complex Systems Engineering course.
posted by SarahSheard at
8:36 AM
1 Comments:
Hi, Sarah,
While reading up for my blogging this last week, I came across "the Dreyfus model of skills acquisition", which relates a practitioner's increasing skill levels with varying needs and abilities to follow standard rules.
Wikipedia has a brief but pretty good intro to this concept.
By
Dan Breslau, at 3:15 PM
Post a Comment
<< Home