Guy, I have been thinking about this Fallacy #1 for a few days now, because I understood it ,but something about it made me feel uneasy and I wasn't sure how to respond to it.

I think it comes down to what is "true". Its because I see that BAs are responsible for getting the requirements elicited, analysed, documented and reviewed, but BAs don't own the requirements. They belong to the business that needed them in order to get defined what they need such that the best solution can be delivered.

Within this, the key word above is 'need'. I agree that what anyone sponsor or SME 'wants' is not automatically a requirement, in fact it probably never is. We as BAs have to get to what the business actually needs to meet its objectives and support its operations. So, I think its the wrong fight to take what the business says it wants and render a judgement as to its merit or 'truth'. That is the proverbial slippery slope to assuming we know more than the business about their business.

How do I (and my BA compatriots) avoid this fight? Instead of asking the business what it wants, we ask what they do and what they need to accomplish. For example, if the business process is servicing customers and they need to know if who they are dealing with is a new or existing customer, then the requirement is 'the system must have the ability to determine if a customer is new or existing". No truth or merit has to be determined.

I expect I may be over-stating my case somewhat, because what you describe does happen, business people demanding something they want, and it has to be dealt with... I dunno, I don't know what else to say. I am thinking your description of how you deal with this may read/sound more antagonistic then you actually would be...

David,

Thanks for this thoughtful repsonse. The question you raise is for me one the most fudamental questions to the whole of Business Analysis - what is 'true' in Business Analysis? In science, reality is true and all scientists have to do is analyse reality. They have it easy! We have to define reality first and then analyse it!!!

How? See my post "100% Proof BA" which I will copy below for convenience as well - but before that I just want to comment on your point about ABC maybe being "antagonistic " - the ABC thing is not something I do in the clients face, I am doing it behind the scenes because I need the 'truth' to do the analysis and because it is (by definition - see below) in the clients best interest. So I would not challenge the client - I am on a jopint voyage of discovery with them to define exactly what it is they want changed and why. And a good technique to do that is ABC and no-one else on the project is doing this detailed, rigourous analysis.

Now that post on what 'true' is:

100% Proof BA

How can Business Analysts prove anything when ultimately all their information comes from other people's opinions? Science can prove stuff - why not us?

Let's contrast how science and Business Analysis proceed:

Science has an objective to uncover more new knowledge. Science proceeds from observations on reality - these are then explained using 'hypotheses' and tested experimentally: if the hypothesis is true/false and we do such-and-such then this should happen. Those hypotheses that survive testing become theories. Theories are what pass for 'facts' in science on the basis that even though you have proved experimentally 10,000,000 every time you drop the hammer it falls, the 10,000,001st time it may not invalidating the theory of gravity that explained the falling hammer.

Business Analysis has an objective to uncover more new change requirements: Our 'facts'. But Business Analysis does not have reality as a starting point like science does.

Luckily (maybe) there is a form of reality that can be defined for Business Analysis but it can change - it is not as fixed as the reality that science has the luxury of: our BA reality is the decisions made by a group of people who have the recognised authority (formally or not) to sanction our project to proceed or kill it. Crucially, they must agree a joint definition of what needs to change and by how much in order for the project to be considered successful (smart Objectives).

These 'killer stakeholders' are not always who you would expect: sure, the budget holder is there. But what about the guys in charge of the IT standards and procedures? Try implementing without their agreement and you will rapidly experience the effect of killer stakeholders. Their objective: this project must maintain compliance with IT standards and procedures.

Once we have these smart objectives we can proceed to define what has to change in order for these objectives to be met (change requirements). Once we have that we can define how the changes will be made (design a solution) that will deliver these objectives. Then we can build, test and roll out.

Almost all change projects will have killer stakeholders we may not have expected: who is accountable for compliance with the Data Protection Act? Who is responsible for validating the business case? What about John Smith the main user because if he won't use it no-one will? And so on.

BA reality is built from people (mostly) who can leave their jobs, get promoted, and just change their minds! All our analysis is built using logic that rests on the premise that the smart objectives are right - and that premise depends on the agreement of all the killer stakeholders.

And scientists thinks they have it tough?!?!?!?

End of post.

How does that work for you?

Thanks again for raising this.

Guy