The Busy BA Reading List, June 12th 2014 edition

Too busy to crawl the web for interesting Business Analysis content? Not interested by social networks noise? Twice a month, the Busy BA Reading List brings you the best Business Analysis articles and websites I came across while surfing the Internet.

Hey there! This first edition is full of amazing content, from requirements discovery to groupthinking. I now you are a busy BA, so let’s not waste more time; here we go!

From Eric the Business Analyst

If you missed them, here are the 3 last posts published on my blog:

Golden Questions for Elicitation and Discovery

When starting a new project, it is often difficult to find a good starting point to discover initial requirements. Jonathan Babcock shares his list of 5 key discovery questions to kick-start a discovery session, helping you to identify the problems to solve and their probable causes, the stakeholders that should be involved in understanding the problem and defining the solution, the objectives we try to reach with the new solution, and any other concerns and risks that you might encounter on your way to implementation.

Fear the Groupthink!

As a Business Analyst, I often see me as The Solution Keeper, ensuring that every action taken by the delivery team is aligned with the business requirements. However, being so involved in a solution can lead to some irrational decisions, especially when the team is under pressure. Duncan Watts at RedVespa describes how groupthink can influence our decisions (link unavailable anymore), and what we can do as Business Analysts to identify groupthink symptoms and prevent its effects.

Documenting before or after the fact?

I worked with many teams during my career, and requirements & system documentation is one of the most non-standard artifact I have seen. The moment when this documentation is created is also variable from one team to another; some prefer doing it before the system is developped, while others will do it once the system is in place (sometimes during the quality assurance phase, other times once in production). Tim Bryce does a nice job explaining pros & cons of both documentation approaches, and summarize very well why it doesn’t matter in the end:

No amount of elegant programming or technology will solve a problem if it is improperly specified or understood to begin with.

Do you like what you’re reading?

Let’s keep in touch! Subscribe to my newsletter and be notified when I publish something new (about once a month). You can unsubscribe at anytime!
By submitting this form, your information will be shared with MailChimp, which I use to manage my newsletter.

Did you read other interesting business analysis content recently? Share it with us in the comments below!

credit: hbrinkman @

Add comment

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Your host

Eric Provost

Making sense out of chaos as a BA & UX specialist

Recent Posts

Recent Comments