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:
- 3 ideas to kill your next requirements review session
- The day I used the CMMI model
- The best way to become a good Business Analyst
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?
Did you read other interesting business analysis content recently? Share it with us in the comments below!
credit: hbrinkman @ freeimages.com
