Too busy to crawl the web for interesting Business Analysis content? Not interested by social networks noise? The Busy BA Reading List brings you the best Business Analysis articles and websites I came across while surfing the Internet.
Christmas is coming soon (in 17 days to be precise). Since you probably have a lot to do before spending some time with your family, let’s get straight to the point! This edition contains interesting articles about user involvment with the Business Analyst, BA under-empowerment and a small quiz on business processes definitions. Enjoy your reading!
From Eric the Business Analyst
These blog posts were published since the last edition of the Busy BA Reading List:
- Don’t blame the spreadsheets: 3 tips to avoid losing control of your data
- You are not the user : 4 tips to elicit better requirements
Being user-oriented when eliciting requirements
As I explained in my latest blog post, user collaboration is essential when it’s time to elicit requirements and understand how a system will be used. Corey Stern from UX Magazine published a few weeks ago an interesting model to get a better understanding of why some projects were successful in providing an interesting user experience, and others not. In a nutshell, his model focuses on 4 areas: the Content (ie why are users using the system); the Users goals; the Business goals; and the Interactions.
The CUBI model is used to support the whole interaction process with the system: business goals are the trigger to content creation, which should fulfill users goals in order for them to interact with the system and fulfill initial business goals. The focus of the model in mainly on designing systems, but it can provide valuable input for BAs as to what dimensions should be considered for requirement elicitation from a user perspective.
Empowering Business Analysts
BAs are more than admin assistants, writing requirements documents based on a specific request and then handling the result to a development team for conception. However, in too many organizations, this is the understanding of what should be Business Analysis. In a recent post, Ajay Badri summarizes the problem very well:
The analyst is treated as a semi-skilled resource to flesh out the details of a product concept initially (dreamed up by someone “higher up the food chain”), and react to the development teams needs for scope control later in the process. However, they are not permitted to perform vital tasks around product definition and scope control proactively. Analysts are not permitted (or, at the very least, strongly discouraged) to ask basic questions around the need for requested features, suitability of requested features to solve the business problem at hand, quantification of the business problems that the solution will address. In short, they are almost totally forbidden from really understanding the problems being addressed by a solution and its suitability for the same.
Ajay then clearly explains what the organization is missing by acting like this: real business objectives are misunderstood, features are not proactively prioritized, which leads to unuseful & unused features. By empowering BAs, and giving them the opportunity to take the leadership on the solution (which is different from managing the project!), organizations should get the best from their BAs.
Should BAs develop training material?
We already know that BAs should be involved until the delivery of a project to ensure its success. BA support during development and testing phases is essential since the BA is the only one who has the big picture of the solution; he can therefore keep everyone focused on the business needs that the project needs to address. It’s only natural for BAs to also be involved in developing training material, or supporting the team members in charge of it.
What does this brings to the process? Teresa Bennett highlights 3 key benefits of this involvment: the BA knows the company objectives regarding the project; he’s able to see the differences with the current processes and procedures, which helps him in highlighting obstacles that could be met by trainees; he also knows how to create training material using real-life cases, since he’s involved with the users since the beginning of the project.
Procedures or Business processes?
This is a recurring question I get from my students, and until now, I haven’t found something as clear as the explanation provided by Stephanie Famuyide in her latest post. With a simple example, she goes through the differences between business processes and procedures. The key difference between both lies in their respective objectives; a procedure focuses on task completion, while a business process is oriented toward business goal achievement.
Do you like what you’re reading?
Did you come across other interesting business analysis content recently? Share it with us in the comments below, or in the social medias (Facebook, Twitter, or Google+)!
Image credits: hbrinkman @ freeimages.com
