This fallacy creeps in just when you don't expect it - and I should know: I've been right about every other fallacy so I'm right about this one!

And there is the fallacy: I assume that because I've been right every time before (please remember that this is a made up example before reminding me of all my mistakes!) that I will be right in the future.

It's like saying that because I have flipped a coin 3 times and it has come up heads each time that the next time must be tails. No - each time I flip it there is a 50:50 chance of it being heads regardless of what happened on the last 3 or 5 or 100 flips.

Past performance is no indicator of future performance. Such reasoning that assumes an outcome in order to justify the outcome is begging the question.

Here's a classic BA example of it: "we tried that before and it didn't work". The inference is that because we tried it before and it didn't work if we try it again it won't work. The truth of the outcome will be determined by why it didn't work before and whether those factors still apply.

This fallacy ties in nicely with fallacy #1 - argument from authority - just because some 'authority' says something does not make it true: don't just believe someone because they have a reputation for being right or knowing a lot about something, that would beg the question of whether they are right in this case as well. You may want to use the person's track record as evidence that their opinion is worth considering - but it is NOT evidence that they are right.

Sometimes I get asked about how to Project Manage a project I am doing the analysis on: "you're doing a good job on the analysis so how should we restructure the project plan". I don't know! Project Management is a separate skill set I don't possess - asking me on the basis I am doing well with the analysis maybe flattering but would still result in (very probbaly) the wrong answer, so it is in both our interests for me to declare that.

Begging the question - assuming that we know the answer before asking the question and basing our answer on that false assumption - it gets everywhere and it always has caused trouble so it always will!

Whoops...

Great BA Fallacies #5 - Accidents

Anyone who breaks in to another person's house is a criminal. Fireman break in to people's houses therefore firemen are criminals. Well obviously that is wrong and any idiot can see that. Is it always so obvious?

Functional requirement: Only a customer can withdraw money from their accounts. Is this ok? What about if they die? Alright, change it then: Only the customer or the executor of a their will can withdraw money from a customer's account. But suppose the customer is a criminal using the account to launder money?

The fallacy of accident is the fallacy of making a generalisation that disregards exceptions - applying general rules that allow no exceptions to circumstances that need to cater for exceptions.

Given these exceptions, a Business Analyst might be tempted then to restate the functional requirement as "Anyone can withdraw money from any customer's account". What the BA has done is commit the reverse of the accident fallacy by making a general rule based on exceptions - in effect by reasoning that since anyone MIGHT need to withdraw money from a customer's account then everyone CAN withdraw money from a customer's account.

So how to avoid these fallacies? Specify what the requirements actually are as definitively as possible:

1. A customer must be able to withdraw money from their account.

2. The executor of a customer's will must be able to withdraw money from that customer's account.

3. Anyone who provides evidence of their legal right to withdraw money from a customer's account can withdraw money from that customer's account.

Hopefully you can start to see how the three process models that would implement these three functional requirements might start to look and how they would involve different validation procedures. Perhaps these requirements need further refinements (for example combining requirements 2 & 3?) - doing these requirements is detailed, tricky work where fallacies are always waiting to trip us up...accidents happen...

K,

Thanks - I agree that state diagrams will help avoid this fallacy as far as entity modelling goes. Of course, this is not the only area that accidents can happen in and other techniques will be applicable in other areas (e.g. event driven process modelling such as BPMN for process accidents). The key to avoiding accidents (and the other fallacies) is to be on the look out for them in the first place!

Thanks again,

Guy