The Busy BA Reading List, December 8th 2014 edition

T

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:

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?

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 come across other interesting business analysis content recently? Share it with us in the comments below, or in the social medias (FacebookTwitter, or Google+)!

Image credits: hbrinkman @ freeimages.com

Add comment

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

By Eric Provost

Your host

Eric Provost

Making sense out of chaos as a BA & UX specialist

Recent Posts

Recent Comments

Archives

Categories

Meta