I mentioned last week that I had come across Ed Yourdon’s wiki for “Just Enough Structured Analysis,” and pointed out that it’s a great resource for business analysts. Again, if you haven’t checked it out, I recommend that you do.
So, why do I make mention of the wiki again this week?
Well, as I continued my study of those materials, I found a story I really liked that describes the principles of complexity escalation and infinite regression; fancy words for pretty common ways simple projects can quickly morph into gargantuan ones. First I’ll share the story, originally authored by J.P Eberhard* and cited by Yourdon and others, then I’ll provide a little commentary of my own.
The Story of the Doorknob
One anxiety inherent in design methods is the hierarchical nature of complexity. This anxiety moves in two directions, escalation and infinite regression. I will use a story, “The Warning of the Doorknob,” to illustrate the principle of escalation.
This has been my experience in Washington when I had money to give away. If I gave a contract to a designer and said, “The doorknob to my office doesn’t have much imagination, much design content. Will you design me a new doorknob?” He would say “Yes,” and after we establish a price he goes away. A week later he comes back and says, “Mr. Eberhard, I’ve been thinking about that doorknob. First, we ought to ask ourselves whether a doorknob is the best way of opening and closing a door.” I say, “Fine, I believe in imagination, go to it.” He comes back later and says, “You know, I’ve been thinking about your problem, and the only reason you want a doorknob is you presume you want a door to your office. Are you sure that a door is the best way of controlling egress, exit, and privacy?”
“No, I’m not sure at all.” “Well I want to worry about that problem.” He comes back a week later and says, “The only reason we have to worry about the aperture problem is that you insist on having four walls around your office. Are you sure that is the best way of organizing this space for the kind of work you do as a bureaucrat?” I say, “No, I’m not sure at all.” Well, this escalates until (and this has literally happened in two contracts, although not through this exact process) our physical designer comes back with a very serious face. “Mr. Eberhard, we have to decide whether capitalistic democracy is the best way to organize our country before I can possibly attack your problem.”
On the other hand is the problem of infinite regression. If this man faced with the design of the doorknob had said, “Wait. Before I worry about the doorknob, I want to study the shape of man’s hand and what man is capable of doing with it,” I would say, “Fine.” He would come back and say, “The more I thought about it, there’s a fit problem. What I want to study first is how metal is formed, what the technologies are for making things with metal in order that I can know what the real parameters are for fitting the hand.” “Fine.” But then he says, “You know I’ve been looking at metalforming and it all depends on metallurgical properties. I really want to spend three or four months looking at metallurgy so that I can understand the problem better.” “Fine.” After three months, he’ll come back and say, “Mr. Eberhard, the more I look at metallurgy, the more I realize that it is atomic structure that’s really at the heart of this problem.” And so, our physical designer is in atomic physics from the doorknob. That is one of our anxieties, the hierarchical nature of complexity.
Any of that sound familiar?
Now, Eberhard included “The Story of the Doorknob” in a 1970 publication*, so clearly these are not new phenonema. An Internet search or two will show that the example is relatively well-known and referenced in architecture and design circles.
I really wanted to share that excerpt, because I think it will resonate with a lot of BA’s the way it did with me. In fact, my main reasons for posting it are:
- The example clearly articulates problems we as analysts (and other project professionals) deal with on a regular basis. By understanding the underlying principles, we can more easily identify and mitigate problems stemming from them as they arise.
- It further goes to show that getting scope/requirements right is tough work, and can be easily thrown-off by our perceptions and those of the people we work with to define and deliver solutions.
Stalling tactics and good intentions misplaced
Richard Veryard provides another interesting observation on problems associated with escalation on his fallacy page:
Some people adopt the tactic of escalation to deliberately kill a change. By making it large and complex, they hope to make it impossible. Others adopt the same tactic in innocent enthusiasm, so excited by the potential of an idea, that they do not realise that they are overloading it.
I’ve always taken the position that we, as analysts, have an important responsibility to push back and reemphasize the business problems and objectives when it becomes clear that a solution is being escalated out of proportion – whether it’s being done purposely to stall a change, or in innocence/ignorance by those who want to do right, but are just overdoing it a bit.
Obviously, the key there is to approach the situation tactfully. Sometimes there will be technical interdependencies that an analyst won’t see or be aware of that make a seemingly simply change a bigger deal than originally anticipated. Of course such scenarios may have more to do with interest coming due on technical debt than on escalation or regression.
What are some ways to defend against problems associated with escalation and regression?
Looking back at the statement by the designer,“Mr. Eberhard, we have to decide whether capitalistic democracy is the best way to organize our country before I can possibly attack your problem,” let’s ask ourselves – what was the original problem? Why did Mr. Eberhard engage the designer in the first place?
If we go back to the top, Mr. Eberhard’s original problem appears to be that he just didn’t like his doorknob and wanted a more fancy one. He wasn’t concerned with capitalism or whether four walls were the best way to organize his space.
As analysts – who often represent the stakeholders’ interests in discussions with design – it is critical that we keep a laser focus on the specific point(s) of pain that the business needs addressed.
We defend against the anxieties of escalation and infinite regression through the work we do as analysts – much of it at project outset. Below are just a few examples:
- Identify and define the business problem (or point of pain) to be addressed. If done properly, this will include some degree of root cause analysis to make sure we’re addressing a true business problem, and not just a symptom of another problem.
- Identify and clearly articulate the objectives the product, to ensure that those objectives are constrained to those things that will solve the business problem.
- Later in the project, ensure that work done downstream maps (or traces) cleanly and clearly back to those original objectives, or at least back to business requirements that trace back to the objectives.
- Ask the following question, just as a litmus test: Does the path were taking lead closer to or further from “the simplest thing that could possibly work“? The further we get from the simplest working solution, the more likely that we are treading into the territory of escalation or infinite regression.
- Raise concerns with delivery personnel when it looks like they might be stepping out into deeper waters than necessary with solution design and development. This is just a precautionary measure, and shouldn’t be done in the spirit of “calling someone out”. Typically, the project manager will be right at your side if a proposed solution is going to cause a project to go over time or budget.
To close, an understanding the principles of escalation and infinite regression is yet another useful tool in the analyst’s toolbox to help us understand how easily unnecessary complexity can arise, how to explain it and how to defend against it.
What are your thoughts on these the story of the doorknob? On the underlying principles? How do you defend against escalation and infinite regression?
*I wasn’t able to locate a copy of the original work, but FYI, here is the reference provided by Yourdon on his wiki: John P. Eberhard, “We Ought to Know the Difference,” Engineering Methods in Environmental Design and Planning, Gary T. Moore, ed. Cambridge, Mass.: MIT Press, 1970, pp. 364-365.
I can always count on you to get my synapses firing in the morning with new articles. I really liked this one. The one thing that kept coming back to me as I read it, is that the acquisition of thorough business knowledge is something that can help make the difference against these tendencies. It is often the one thing that helps control an analyst from going off on tangents, because the foundation of how the business operates and its governing processes are in place. Perhaps this is why some organization mandate industry or business knowledge as a requirement to get hired.
In any case, the cases that you highlighted were great and certainly rang true to my own world. I bring up business knowledge as a controlling mechanism because I’ve found that while some will escalate or regress due to other motivating factors, the biggest one seems to be that they aren’t grounded in what SHOULD guide them. I’ve done this myself when I wasn’t as prepared as I should have been. The tendency to start pondering gravitational pull as a constraining mechanism to requirement 14 is much higher when I don’t know what I’m talking about, which includes overarching knowledge of the business.
I also need to read a bit more on Ed Yourdon’s findings. I really also wonder if some of what you are getting at here and what he has written about is basic psychology. Maybe persons that aren’t grasping the original problem, or cannot resolve it, inflate the importance of it (via escalation or regression examinations) to mask this inability.
I hate it when you make me think this early in the day…but love it just the same.
Ok, so I’d like to hear your thoughts on this response.
Interesting. Where you were drawn to consider the need for business knowledge, I kept finding myself thinking that it’s very useful for the BA to have a fundamental knowledge of systems/technical architecture and how technology is used to solve business problems. Not because I think the BA needs to be an architect, too, or that business knowledge is any less important. That’s just the direction my mind took as I read the examples.
When I read Veryard’s quote about using escalation to deliberately kill a change, I think back to an instance or two where I’ve been able to draw on the more technical knowledge to distinguish between the type of complexity that is inherent in dealing with systems and their inter-dependencies (basically, complexity that can’t be avoided),and complexity that is fabricated or forced because no one else knows better.
Now, you could reasonably question whether or not it is the business analyst’s job to make that kind of a distinction and call “bull” when the delivery team is making things more complicated than they have to be. I’m just saying I’ve been there before, and I think it’s another way that I have been able to provide value in the BA role.
And I have no doubt there is a psychological component to all this. I bet there are books and articles to be read on the psychology of hierarchical complexity. Of course I’m just dense enough that it takes a nice little story like the one I cited to make sense of those types of concepts.. 🙂
So many years trying to find out where I had read this brilliant story, and now the search is over!!!!!
Thank you for sharing it..I had digged into Yourdon books, but couldn’t find this quote..and I was sure that it was not a fruit of my imagination! Thanks a lot!