home
Home » Methodology

Why humans don't like to analyse?

Submitted by GuyBeauchamp on Wed, 2008-10-22 03:45.

 .
Humans have evolved because they survived. They survived by exploiting their key advantage over competitors: the ability to use rationality to solve problems (such as how do I get away from the sabre tooth tiger?).

This rationality is expensive in terms of time and effort. It takes time and mental effort to reason: "I have observed and have also been told that sabre tooth tigers eat people so really I should ensure that I am not at risk of being attacked by one".

Far more efficient to just react with fear at the sight of the tiger and run away, making rational choices about which way to run perhaps.

So that fear came from somewhere. Sure: it came from the abstraction of the rational knowledge about sabre tooth tigers. The abstraction (i.e. the emotion of fear) is far less expensive to process than rationality. It is quicker and easier.

The problem is this: the abstraction does not admit new knowledge. If the sabre tooth tiger said "Hi, did you know I am now a vegetarian?" we would already be too far away to hear it and we would have no evidence that our fear reaction strategy had not worked yet again.

So people trust their emotions (abstracted rationality) as as they think they are quick, easy and reliable.

Now the nasty bit for us business analysts: we come along and try to get people to formalise their rationality in to analysis of their requirements. Perversely, they have already abstracted the knowledge that this analysis business is expensive and hard in to the emotion "dislike". What they do like are emotional reactions (quick and easy). So they don't like doing analysis and they worked out why rationally and that reasoning has been dropped as now they only need to know they don't like it.

Rationally they will agree (if they hang around long enough to discuss it with us) that analysis is necessary but that doesn't mean they have to like it and (usually) they don't.

More thoughts like this...

» GuyBeauchamp's blog | printer friendly version | 1042 reads

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

I'm wondering why we would wa

Submitted by Anonymous (not verified) on Thu, 2008-10-30 11:17. *

I'm wondering why we would want the customer, user or stakeholder to analyze anything. As business analysts, we have the title "analyst" in our name and are responsible for the analysis. It is a given that the users don't necessarily like to analyze and moreover, that they are not qualified to do so. Their job is to give us the information. Our job is to do the analysis.
=steve

» reply

I'd suggest further analysis....

Submitted by ScottWAmbler on Mon, 2008-11-10 18:29. *

Is analysis really the problem, or is it the approach to analysis that the BA is following?  I haven't run into stakeholders pushing back on analysis efforts on agile projects, but then again agilists focus on value, quality, collaboration, and evolutionary approaches, all of which seem to be attractive to stakeholders.

- Scott

» reply

re "I'd suggest further analysis..."

Submitted by GuyBeauchamp on Tue, 2008-11-11 03:41. *

Thanks for the comment, Scott. 

As I understand Agile, the whole point is to limit activities in order to make projects more responsive to change. Analysis is done, just not of the whole.

Other Business Analysis approaches on the other hand fully decompose a complex in order to understand the inter-relationships between the components. It starts from the premise that the whole cannot be analysed in independant parts.

That's probably why there is no Agile scientific method - although Darwinian evolution is the ultimate Agile implementation in the real world!

So - bottom line is that I suspect stakeholders like Agile precisely because people don't like to do a full blown analysis of a project, which is the feature that got me thinking about this area in the first place.

Guy

www.smart-ba.com

» reply

Analysis is so important, agilists do it throughout the project

Submitted by ScottWAmbler on Tue, 2008-11-11 16:32. *

Yes, we try to get the value out of modeling with is to communicate and think things through while avoiding the pain of unnecessary documentation and the damage caused by making decisions too early.   In general we work smarter, not harder, focusing on quality and high-collaboration strategies.  So we follow "agile analysis practices" such as initial requirements envisioning, iteration modeling, model storming, and executable specifications -- in short, it's not your father's business analysis method.

- Scott

» reply

Before or during?

Submitted by martin on Tue, 2008-11-11 17:08. *

When it comes to thinking up front, I have experienced many clients have a preference to avoid it like the plague, it's not easy, it means making tough decisions and pondering many alternatives, much easier to go with what everyone else does. 

The reality is that whether we like it or not, analysis will happen during a project, the question is whether we have the discipline to do it upfront or are lazy and wait until we have no choice in the matter and then make a series of smaller decisions as needed to get to the end point.

The latter approach produces a result but not necessarily a good one.  Doing analysis upfront, is harder but gives you a better result.
» reply

re: "before of during"

Submitted by GuyBeauchamp on Wed, 2008-11-12 03:40. *

Martin,

Many thanks for your comment - I agree with everything you have said and share your experiences.

It all goes back to what my dad used to say: more speed less haste....

Iterative release approaches minimise individual release risk but cost more in overall time, money and effort and increase risk for the overall project (realising the project is wrong in the last release is just plain embarressing!). Waterfall release approaches minimises overall project risk and uses less (arguably) resources. 

Iterative release approaches do something quickly and are seen to do something quickly. That is their main strength and people like it. Hence my ponderings on why...

Thanks again for taking the time to comment.

Guy

 

www.smart-ba.com

» reply

re: "Analysis is so important, agilists do it throughout the pro

Submitted by GuyBeauchamp on Wed, 2008-11-12 03:31. *

Hi Scott,

Thanks for your comments - thought provoking indeed! I'd like to make two points in response:

1. My dad's analysis is iterative and is done throughout a project too so is no different to Agile in that respect

2. It's just that my dad's analysis recognises that cost of fixing analysis errors rises almost exponentially throughout the project - the longer you leave it the more expensive to fix because of rework costs. Given that fact, then the rational thing to do is get the analysis right up front. Of course this will never be achieved for reasons Agile majors on. But a BA can and should minimise changes in requirements by getting it right first time to minimise costs, duration and effort. How do they get it (more) right first time? By proving the analysis and documenting that proof using the fundamental components of business analysis that every method and approach has (even Agile!) whether the method or approach recognises it or not (hardly surprising when all analysis methods and approaches are covering the same subject matter: namely the analysis of change requirements).

So there are rational reasons to do analysis up front and many (many!!!) ways of doing it - why don't we? I suspect because humans don't like to analyse....

Thanks for commenting again on this post - I am finding the debate very stimulating!

Guy 

 

www.smart-ba.com

» reply

The evidence doesn't actually support up-front detailed analysis

Submitted by ScottWAmbler on Sat, 2008-11-15 01:31. *

A few comments:

1. Examining BRUF summarizes some of the evidence for why up-front detailed analysis doesn't work out so well in practice.

2. The cost of change curve is definitely something to be aware of.  I've mapped several common agile and traditional techniques to compare the paradigms.

- Scott

» reply

Re: "The evidence doesn't actually support up-front detailed ana

Submitted by GuyBeauchamp on Sat, 2008-11-15 04:17. *

Hi Scott,

Thanks again fro your reply.

A few comments in reply.

1. I don't know why you think I advocate big up front analysis - I don't. I advocate analysis.

2. You are correct that SOME evidence claims not to support up front analysis - but even that evidence is challenged on the subjective nature and self selection aspects of it - e.g http://www.infoq.com/articles/chaos-1998-failure-stats

3. In the absence of undisputable evidence, logical reasoning seems to be the only way to progress this issue and I have yet to discover a fault in the logic that analysing requirements for a whole project is the best way to decrease the risk of delivering the wrong solution because of incorrect requirements. 

4. The cost of fixing analysis errors rises almost exponentially the longer they are left due to re-work costs.

5. Agile and every other method and approach that defines change requirements does analysis - the scope varies (especially for agile and ragile), but not the analysis. 

6. As a side issue - having been in analysis even longer than my dad, I have seen so many methods and approaches come and go. They all do the same thing, just use different terminology. They all have  to do the same thing because they are all defining change requirements. My guestimate based on the cyclical nature of these methods and approaches is that Agile has no more than 5 year's active promotion left before the next Big Thing comes along - ragile maybe? Who knows? What I do know is it will advocate analysis using different terminology that will do the same job of defining change requirements just as my dad used to do!

7. (and finally!) ...our debate seems to be on the merits of agile - I think agile is fine, no real problems with it: it has strengths (fast repsonse) and weaknesses (I've covered these already) but my question about why humans don't like to do full detailed in depth analysis (which is what rationally we should do) remains and is what my post is really about - not agile...

www.smart-ba.com

» reply

Post new comment

*
*
The content of this field is kept private and will not be shown publicly.

*

  Sponsored Announcements & Special Offers


Independent Evaluation of Requirements Management Solutions - Compliments of MKS
Forrester Research has released its evaluation of the requirements management market and gives MKS the highest score for its current offering. Get your complimentary copy of: The Forrester Wave: Requirements Management, Q2 2008.

Get Powerful: Visualize With iRise
Imagine being able to quickly assemble fully-interactive visualizations that mimic the exact look, feel, and behavior of applications – without any coding! No more confusing communication with stakeholders. No long hours handling rework. Now business analysts have a powerful ally in the fight to get it right – the first time. Isn’t it time you joined the thousands of business analysts iRise has already empowered? Download your FREE trial now!

Business Analyst Workbench Demo
Learn how Blueprint’s business analyst workbench enables you to elicit and validate requirements with stakeholders through visual simulation. Learn how to generate 100% ready-to-run test cases automatically. Free online demonstration.
© 2007 Requirements Networking Group All rights reserved. contact | advertise | privacy
Requirements Networking Group