Each month Adriana Beal answers questions submitted to her via email or through LinkedIn.
1) I’ve been working informally as a business analyst for the past 2 years, and now due to lack of opportunity for growth have started to search for a new job. My problem is that twice I’ve been asked for a work sample, and both times the deliverables I submitted were not considered good enough. I know I could produce more formal documentation in the company’s standard format if given a chance. How do I convince employers to give me a chance?
There may be many reasons why a BA’s past deliverables aren’t optimal for sharing with potential employers as a work sample, including, but not limited to, insufficient time to prepare better documentation and lack of previous knowledge of what good requirements look like. That doesn’t mean you’re “stuck” with submitting these original artifacts as your samples–it would make perfect sense to rework them so that your submission reflects the level of quality you are capable of delivering now.
Also (and this also applies to someone who doesn’t have a work sample because they never worked in a BA role before), remember that it’s perfectly fine to create samples from fictitious projects to showcase your expertise. You can use applications you’re familiar with as reference to create requirements samples to share with your interviewers. For example, create a Use Case to describe the interactions a user has with an online store during the checkout process, or a set of user stories and acceptance criteria for a content management system used to publish content to the Web based on your experience with Amazon or WordPress. The hiring manager is interested in learning what you can do in terms of quality requirements documentation, and for that he or she doesn’t need access to real-life projects, only to work you’ve done yourself that illustrates your level of expertise writing high-quality requirements.
2) Can you give a generalized synopsis of a project you have worked on as an IT Business Analyst?
I was originally asked to answer this question on Quora. My answer is reproduced below:
Here’s a project from my past that reflects much of the work I’ve done as an IT business analyst (and is also very similar to the work being performed by several IT BAs I’m currently coaching):
I was hired by a financial institution to help define the scope of the next releases of an internal system used to process loan syndication contracts with borrowing customers. They needed someone who could go through a list of more than 500 change requests, many conflicting each other, and figure out how to prioritize what needed to be built next to better support the various user groups (financial researchers, people in charge of structuring the loan terms, etc.).
My approach involved understanding and mapping the end-to-end process, talking to the various user groups and observing them perform their tasks with the system to better understand their needs, coming up with candidate solutions for each problem they faced, and prioritizing the work to ensure the most valuable changes were introduced first.
Then I had to gain consensus among the various groups about what would and would not be included in the next release, and write the requirements used by the development team to understand what they needed to build and by the QA team to define the test cases that would ensure the solution was fit for purpose.
You can get a sense of the techniques I used in this and other projects to quickly get up to speed with a complex process I wasn’t familiar with it, analyze the problem, and define a solution that user groups who were previously in conflict happily approved by visiting this page: Get the help you need to succeed in business analysis.
3) When determining relevant testing scenarios for a software project, should SMEs (subject matter experts) or users be involved, or is it sufficient to develop the scenarios based on the documented requirements?
Well-designed functional tests can play a critical role not only in the process of verifying that a solution is fit for purpose after it has been implemented, but also to crystalize the vision of how the application will work under different conditions and validate that the requirements are clear, complete and don’t conflict with each other before the first line of code is written. In an ideal world, the business analyst will write the user and functional requirements and a tester will identify and write the test cases, scenarios, procedures, and scripts. This combination of efforts increases the odds of detecting and fixing any inconsistencies, mistakes, or omissions in requirements before coding starts. But in many cases the BA will also be in charge of writing test scenarios.
In this case, should the analyst attempt to involve SMEs or end-users in identifying test scenarios? I have recommended this in the past when the team didn’t have confidence that the requirements discovery process was conducted by someone with the skills and knowledge required to produce high-quality requirements. If that’s not the case, then involving stakeholders in test scenario identification may be unnecessary, because the right scenarios to test should have already been identified during the analysis of use case and usage scenarios.
To illustrate this viewpoint, let’s look at an example. Imagine that you’re writing the requirements for a content management system used by a company to publish blog posts. One of the key tasks users have to perform with the system is schedule blog posts for future publishing. As you interview stakeholders and lead requirements sessions, you might discover that a typical scenario is a sequence of scheduled blog posts being postponed. Rather than requiring the user to edit each individual post to change its publishing date (which would increase the risk of human error), the desired behavior is that the system allows the user to select multiple scheduled blog posts and shift them X days or weeks to the future in one single action (e.g., move the whole batch one week to the future relative to the original scheduled date). This usage scenario would then be captured in the requirements documentation that serves as the reference for creating the corresponding testing scenario.
But suppose the requirements for the content management system had been written by an untrained BA who didn’t do a thorough job identifying user objectives and usage scenarios like the one mentioned. The requirements might specify the ability to reschedule individual blog posts, but omit the need to support postponing multiple blog posts at once. In this case, involving end-users in the definition of test scenarios before coding would increase the likelihood that the missing requirement was identified at a time when fixing the omission is much cheaper and easier than if the issue is only identified only during QA testing.
The key takeaway here is that subject matter experts and end-users need to be heavily involved in the requirements discovery process to provide input regarding the tasks they need to be able to perform with the application being developed, how they envision interacting with the system to perform these tasks, and so forth. This is how you achieve a common vision of the essential tasks and steps in the actor-system interaction to feed both the requirements and test planning tasks. When this involvement is not properly obtained during the requirements process (or the requirements work is conducted by an unprepared BA who is unable to extract the right information from SMEs and users), then it becomes highly advisable to make an effort to involve SMEs and end-users in identifying anticipated usage scenarios that need to be considered as part of the tests to determine the software’s acceptability.
You may also like
More on Ask Me Anything
Solutions to the most common BA issues