Forums for the Business Analyst

 
  Modern Analyst Forums  Business and Sy...  Requirements  Great BA fallacies
Previous Previous
 
Next Next
New Post 11/21/2008 6:03 PM
User is offline David Wright
141 posts
www.iag.biz
7th Level Poster




Re: Great BA fallacies #2 proof by verbosity 

A 5 minute discussion rule, agreed to by participants up front, along with other good session rules like no sidebar conversations, no interrupting, etc.... if something can't be described or resolved in 5 minutes, it is tabled for another time and we move on. This way, it can' t(or shouldn't) be seen by anyone has having been cut off when others are not, the rule applies to everyone, junior to senior.


David Wright
 
New Post 11/21/2008 6:31 PM
User is offline David Wright
141 posts
www.iag.biz
7th Level Poster




Re: Great BA fallacies 

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 Wright
 
New Post 11/22/2008 2:17 AM
User is offline Guy Beauchamp
257 posts
www.smart-ba.com
5th Level Poster




Re: Great BA fallacies #2 proof by verbosity 

 dwwright99 wrote

A 5 minute discussion rule, agreed to by participants up front, along with other good session rules like no sidebar conversations, no interrupting, etc.... if something can't be described or resolved in 5 minutes, it is tabled for another time and we move on. This way, it can' t(or shouldn't) be seen by anyone has having been cut off when others are not, the rule applies to everyone, junior to senior.

David,

This brings back memories of SUMO cards we had one place I worked: SUMO - Shut Up Move On. You had 3 cards and you could play them in any meeting at any time with the effect that the conversation had to immediately move on, no questions. It was funny and got some laughs, team bonding, all that wishy-washy touchy-feely stuff. Useful? I don't think so and I prefer your structure - your way a debate gets surfaced and rescheduled if needed.

Guy

 
New Post 11/22/2008 2:29 AM
User is offline Guy Beauchamp
257 posts
www.smart-ba.com
5th Level Poster




Re: Great BA fallacies 

 dwwright99 wrote

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

 
New Post 11/25/2008 7:59 AM
User is offline David Wright
141 posts
www.iag.biz
7th Level Poster




Re: Great BA fallacies 

"How does that work for you?

Thanks again for raising this.

Guy"

I am not sure yet. What would be an example of a Requirement you would validate 'behind the scenes'?


David Wright
 
Previous Previous
 
Next Next
  Modern Analyst Forums  Business and Sy...  Requirements  Great BA fallacies

Community Blog - Latest Posts

Anthony Horner
Anthony Horner
BPMN 2.0 is a modelling standard that has been around for 10 years now and although it has its foibles it has been recognised as the best for capturing the business logic behind real-life scenarios.  What most people don’t realise is that the standard itself is supported by an XML definition of its objects. What does this mean? Essent...
0 Responses
akshitavarma143
akshitavarma143
Different procedures are utilized for legitimate administration of IT administrations, yet ITIL is viewed as the best arrangement of practices for even administration of IT administrations. ITIL is the contraction for Information Technology Infrastructure Library.  In easier words, ITIL is many rules and arrangements for the effective admin...
0 Responses
Rajesh-N
Rajesh-N
What Everyone Must Know about AI in Testing Artificial Intelligence is the buzzword that we frequently keep hearing. Its widespread popularity and influence can be understood from the way industries adopting AI in their organization. Whether it’s Healthcare, Automobile, Banking & Financial Services, or Airlines, many industries have st...
0 Responses






Latest Articles

Product Owner vs. Business Analyst - Demystifying the Ambiguities
Feb 21, 2021
0 Comments
Agile projects, due to the short cycles of delivery, require a collaborative team, substantial leadership support, and a robust, agile culture to be i...
Copyright 2006-2021 by Modern Analyst Media LLC