Forums for the Business Analyst

 
  Modern Analyst Forums  Business and Sy...  Requirements  Great BA fallacies
Previous Previous
 
Next Next
New Post 11/21/2008 5: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 5: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 1: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 1: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 6: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

Fabricio Laguna talks Business Analysis and AI
I recently connected with Fabricio Laguna, aka The Brazilian BA. Fabricio is a passionate and pioneering business analyst from Brazil. During our conversation, we had a thought-provoking discussion on how artificial intelligence stands to shape the field of business analysis in the years ahead. While AI promises to transform many aspects of busines...
Business Architecture, Ontology and More with Terry Roach
It's been a privilege meeting Terry Roach, a visionary in the field of enterprise architecture and business architecture. Terry's insights into the evolution of business models, the importance of ontology in architecture, and the potential of AI to shape our future were not only thought-provoking but also a reflection of his extensive exper...
Today I had the pleasure of chatting to Jignesh Jamnadas, Chief Operations Officer at Mosaic, about his Blueprints for Success. As a Senior Finance and Operations Executive, Jigs (as he is known to many) has a holistic understanding of all facets of business and a flair for managing both people and processes. Having worked with Jigs, I was struc...

 



Upcoming Live Webinars




 

Copyright 2006-2024 by Modern Analyst Media LLC