Flow Chart Decision Symbol Arrows - Which flowchart is correct?

[JaneB]

The reason for using a structured logical approach is that people don't necessarily think that way, but should. If there's too much detail it's because the flowchart is poorly drawn, not because the method is at fault.

Agree with you Jim. It doesn't have to be (and shouldn't be!) the kind of 'every single little fine detail' type flowchart of the IT systems designer, and a well-drawn flowchart can be - should be! - logical and clear to follow. Which is, as you point out, to push people into thinking and acting in a logical, consistent way.

Once a process is designed and proven, competent people have to operate the process as designed. In fact, that's a definition of competence. The problem with logical flowcharting is that people don't know how to do it.

Again, very true.

I am not a big fan of this type of flowcharting mainly because: most users don't think in this way

Users?? Do you mean 'readers'? 'people who use the system'? Or are you meaning 'end users of an IT system'?? Whichever, I disagree with you. I often use flowcharts, making them as simple and logical as I can, and I haven't often found clients who a/can't 'think' that way or b/don't like them. Au contraire: many of them become raving fans of the flowchart!

and also because they tend to be produced in far too much detail and therefore distract from managing the real risks in the process.

Then they're badly done, as Jim says. But just because some are badly done doesn't mean the whole approach is bad or wrong. Far from it.

However, if you are arguing against having too many decision boxes and arrows going all over the place, then yes, I agree. I prefer to minimse the use of decision boxes and restrict their use to the important decision or control points. But no, I don't want to lose these! In my opinion, it's usually important to emphase where such checks/decisions/control points are and get people to focus on the 'if Yes, go on... if not, go back to/repeat until...' Too often, people in the procedures do just go on without making the decision/being conscious of the decision being made. And in some places, those are important.

 

[Yarik]

Dear all,
From the attached word file, would you mind telling me which flowchart is correct, A or B, in terms of the decision symbol arrows?
Many thanks

One could argue that technicaly both variants are corect, but... variant B is conventional and clear, whereas variant A is exactly oposite.

IMHO, the serious problem with variant A is that it makes two separate elements overlap so much that they look like a single element which is ilegal (only unidirectional arows are alowed in "clasic" flowchart notation). Yes, a reader of variant A eventualy wil decipher the meaning of what looks like a bidirectional arow, but... it is going to take a litle extra mental efort and cause some discomfort.

Just like omission of double-consonants in my writing up to this point: I am sure everybody was understanding the meaning of what I was writing, but I think most of the readers probably were quite annoyed while reading it.

 

[Jim Wynne]

One could argue that technicaly both variants are corect, but... variant B is conventional and clear, whereas variant A is exactly oposite.

IMHO, the serious problem with variant A is that it makes two separate elements overlap so much that they look like a single element which is ilegal (only unidirectional arows are alowed in "clasic" flowchart notation). Yes, a reader of variant A eventualy wil decipher the meaning of what looks like a bidirectional arow, but... it is going to take a litle extra mental efort and cause some discomfort.

Just like omission of double-consonants in my writing up to this point: I am sure everybody was understanding the meaning of what I was writing, but I think most of the readers probably were quite annoyed while reading it.

You've hit on one of the problems with flowcharts, which is lack of a standard method. I don't mean an international standard (although iirc there's an ANSI standard for symbols), but a set of rules in a company that dictates the method to use, with the appropriate training.

 

[Cornwap]

Hi Jim and Jane,
Thanks for your comments on my “heresy”. I respect your opinions and I believe that it is always healthy to review my points of view. I have therefore given some careful thought to your comments and which I have responded to below.
I’d like to pick up one of Jim’s comments first “people don't necessarily think that way, but should”. Who says that humans must think in a logical structured way? Things such as lateral thinking and rules of thumb allow humans to make very quick decisions and to be highly creative. My experience is that understanding human behaviour is critical in creating sustainable processes. I certainly can’t imagine telling my clients that they are wrong because they don’t think in the correct way.
Having given some thought to your comments about the tool, I agree that there is inherently nothing wrong with any tool. I would also argue that competency to use a tool is not the main problem area. Having read through your responses I have realised that my issue with this type of flowcharting is the intentions behind it.
Reading through the phrases that you both use such as “competent people have to operate the process as designed” and “push people into thinking and acting in a logical, consistent way”, I am very aware that it is the language of top-down command and control.
I do not intend this to be a criticism as this may be a valid approach with your clients or within your companies. A format that is built around telling people each activity, decision and permissible outcomes from each decision will be a good fit with a command and control approach. Unfortunately this is also the way in which I have typically seen it used which would explain my dislike of it and I suspect the underlying reason for many people not liking it.
In my own experience attempting to push solutions onto clients doesn’t work. I believe that it is important to approach my clients with humility, understand their needs and develop solutions using whatever tools or formats work for them.
I do not believe that there is a single right approach, at the end of the day it is sustainable results and improvements that count. As I have said, maybe the people that you deal with like to be told what to do and how to think and that produces the desired results, so it is the right approach. My personal experience has been that this doesn’t produce the desired results so I use different approaches, which are also right. The important fact is that nobody is wrong therefore I see no basis for line by line criticism of anybody’s approach.
All the best
Phil

 

[Jim Wynne]

Reading through the phrases that you both use such as “competent people have to operate the process as designed” and “push people into thinking and acting in a logical, consistent way”, I am very aware that it is the language of top-down command and control.
I do not intend this to be a criticism as this may be a valid approach with your clients or within your companies. A format that is built around telling people each activity, decision and permissible outcomes from each decision will be a good fit with a command and control approach. Unfortunately this is also the way in which I have typically seen it used which would explain my dislike of it and I suspect the underlying reason for many people not liking it.

You're making a judgment on the product--a logically constructed process--based on false assumptions about the construction method, I think. The fact that a process has logical structure and decision points doesn't mean that the design for it was thrown out of a silo. If the people who operate and are affected by the process are included in the design effort, and understand the need for process control, there is no stifling of creativity and no odor of command-and-control.

On the other hand, if you think that process control isn't necessary, or that some decisions don't need to be made before something bad happens, you're inviting chaos.

 

[JaneB]

Who says that humans must think in a logical structured way? Things such as lateral thinking and rules of thumb allow humans to make very quick decisions and to be highly creative.

as Jim said, I think you're confusing a product - in this case a way of representing a process - with the process itself, including the one of agreeing on that process.
Anyone in the profession of quality who doesn't value logical thought and structure in representing processes is probably in the wrong field, in my opinion. And to value those doesn't mean ruling out lateral thinking and rules of thumb, quick decisions or being highly creative.

I certainly can’t imagine telling my clients that they are wrong because they don’t think in the correct way.

I don't understand how you can draw the possible inference that I or perhaps Jim do this, nor any of the conclusions that follow, merely on the basis of a discussion on flowcharts!

I am very aware that it is the language of top-down command and control.... In my own experience attempting to push solutions onto clients doesn’t work.

No, really?

I believe that it is important to approach my clients with humility, understand their needs and develop solutions using whatever tools or formats work for them.

Well, by golly, gee, yes. Consulting 101 surely?

Phil, you're drawing a bow so long that it's stretched out of existence! How you could leap from a discussion of the method of flowcharting to making erroneous and utterly wrong assumptions about 'attempting to push solutions onto clients' is quite beyond me. It could even be considered discourteous or insulting if it wasn't so ludicrous.

Consulting methods etc is and was not the subject of this thread. To leap to that, given the discussion to date, to me is a complete failure of logic and reason, not to mention a failure to stay on topic.

You want to discuss consulting methods? As a very new member, you may have missed this Consulting forum, which is the place to raise such a topic if you wish. This is not.

 

[Pazuzu - 2009]

As for double-headed arrows... Mean what exactly? Lots of stuff going backwards and forwards??? Who decides what and when???

Agreed...an arrow that doubles back on itself can no longer be deciphered accurately. That is, how many times is it running back and forth? For pure sake of clarity, B is the best choice.

 

[Eloy Gomez]

"B" is the way to go

 

[Yarik]

Hello Phil,

B is correct in the traditional approach. However you could use A if you used a single ended arrow and treated it as a gateway. If there is a question or instruction in the gateway why do you have to tell a competent person to go back if they can't pass it? Less arrows, less complexity.

I don't think that your idea really reduces complexity of this sample diagram. It just makes its complexity less explicit (which is not necessarily a good thing).

Yes, you would remove one semantically simple element (one of the diamond's outgoing arrows) from the diagram, but the meaning of the diamond element itself would become more complex: now a reader would have to know the meaning of a special situation when a diamond has only one outgoing arrow.

The worst thing about homegrown "enhancements" like this one is that any uninitiated reader would be totally lost. 99,9(9)% of people who beleive that they do understand flowcharts would be confused first and then most likely would jump to a conclusion that the "enhanced" diagram is plain erroneous. :mg:





Having said all that, I must note that desire to "enhance" traditional flowcharting notation (see http://en.wikipedia.org/wiki/Flowcharts for the lack of any official standard) is perfectly understandable to me: semantically the elements of this ancient notation are too poor to stand up to more complex real workflows - ones that involve non-binary decisions, parallel execution of activities, parameterized activities, so-called "exceptions", etc. etc.... But why reinvent the wheels again and again? For example, why not to use UML or BPMN which are (a) well-defined and standardized and (b) mature enough to take good care of both simple and complex workflows?

I know those modern modeling notations may look overcomplicated at the first glance, but the truth is: they are almost pure supersets of traditional flowcharting, so a simple workflow would look almost equally simple in both traditional flowcharting notation and in UML...

 

[Jim Wynne]

Having said all that, I must note that desire to "enhance" traditional flowcharting notation (see http://en.wikipedia.org/wiki/Flowcharts for the lack of any official standard) is perfectly understandable to me: semantically the elements of this ancient notation are too poor to stand up to more complex real workflows - ones that involve non-binary decisions, parallel execution of activities, parameterized activities, so-called "exceptions", etc. etc....

Although I have lived a reasonably happy and productive life without having any idea what a "parameterized activity" might be (and I now wish I could unremember that phrase), the "ancient notation" you refer to is called "logic flow," and so far as I know, logic hasn't changed in a long time. Nor are complex processes anything new; the general principles of flowcharting exist because of complex processes. The primary reason that we have the ineffable ugliness of such things as turtle diagrams is that people were never taught how to do flowcharting to begin with. Most "flowcharts" we see today remind me of the old joke about a camel being a horse that was designed by a committee.