Over the past few months, several Business Analysts interviewing with firms have shared with me mini-requirements development assignments, in which a hiring firm asks for candidates to produce sample requirements for a specific project.

This points to a new (or possibly resurgent) trend in specialist hiring: qualitative testing of the candidates’ abilities by getting them to provide an illustration of their work. And it’s brilliantly effective. The manager gets a good idea of what the candidate can actually produce on day one of the job…

But only if it’s done effectively. Bad assignments are a waste of time (for all parties), and good ones are a fantastic opportunity (again, for all parties).

In this blog post, I’ll cover a lot of ground, and it’s important for both BA candidates and BA Recruiters/Managers to review it entirely.

So… What is this Assignment Really?

Most succinctly, the assignment is asking the candidate to analyze, model, and document a pre-existing (and publicly available) system. The assignment assesses the hard skills (analysis, modeling) of the BA, and also assesses the communication skills (documentation) of the BA to a limited extent.

A couple recent examples I’ve seen have been a bank asking the candidate BA to develop requirements for the ATM locator applet on its public website. Another has been developing requirements for the inbox and folder management features of Gmail.

But here is what it isn’t. It is not asking behavioral questions of the BA; it’s more than that, and there will be plenty of opportunity for this in interviews.

It’s also not a BA bringing in a binder full of requirement documents; the value of the binder of requirements has always been hard to gauge. Instead, the recruiter/manager is asking the candidate to independently devise a set of requirements geared to a particular problem or system. understood by all parties.

The assignment, however, is not going to provide a complete portrayal of the BA’s capabilities. Like any tool, you have to appreciate its limitations. Written communications ability will be easily gauged, but not the key elicitation, stakeholder management, and many other skills that are crucial to Business Analyst competency.

So, let’s dive into the advice aspect of the post.

Advice to Business Analysts

Understand what the recruiter and manager want to see

As Steven Covey suggested, begin with the end in mind. Seek to understand not only what is expected of you, but what will make you stand out as a candidate.

Recruiters will want to gauge your intelligence. They will need to assess the clarity of your thought process. And they will pay a good amount of attention to your communication ability – how clearly, succinctly, and professionally you write.

The hiring manager will pay attention to the same aspects and additional ones. The manager wants to see how well you analyze and model the system. They’ll pay attention not only to what you write, but also how you write, such as your choice of requirement artifacts and how you structure everything. They will also gauge the completeness of your work, looking for gaps in the requirements you provide.

Specific analysis direction

Keeping this tall order in mind, here are seven tips that will help you to stand out from the pack.

Ask questions. At the time the exercise is given to you, take the opportunity to ask questions to understand two big areas. First, try to get an idea of what a successful set of requirements looks like. Try to find out from the Recruiter what other candidates are providing and how they have been received/perceived so far. This can guide your analysis approach with the exercise. Second, try to get an analysis-oriented question passed to the hiring manager. Ask a question that will help you to put some parameters around the requirements you create. This will help the hiring manager to remember your name at review time. Just don’t ask what requirement artifacts/formats are needed – you should already know this as an experienced and capable Business Analyst.

Do just enough research. This is pretty simple, but often overlooked. It’s too easy to take the assignment at face value… Just write it up, and be done with it, right? But doing a bit of research in areas relevant to the exercise can add an extra level of solidity to your work product, and it shows the manager that you know that research is a key part of the requirements development process.

Start with the high level, and progressively elaborate. We Business Analysts know that jumping right into the details of a requirement set is a non-starter. Any requirements stakeholder will need to be oriented to the problem and see how all the requirements fit together to produce a solid framework. So, start with the high level, and progressively build the details…

… And be sure to get into the details. Business Analysts tend to be detail-oriented types, but some BAs will naturally make the mistake of skipping the details in these exercises. Don’t do that. Managers need to see that you can work at all levels of the requirements hierarchy, and lack of details can be perceived as a lack of substance.

Produce a variety of (applicable) requirements artifacts. Managers don’t want to hire someone who doesn’t know what use cases are. So, provide a few different types of relevant requirement artifacts. If your exercise relates to a user using a system, provide use cases. If you want to model a decision process, a decision tree or simple flowchart could be options. Just don’t go overboard – 3 to 5 analysis/modeling methods is plenty.

Document your thought process. It’s good to show some of the thought process you’ve put into the exercise. Just like “showing your work” when you did math problem sets in school, you may get “partial credit” if the manager understands the approach you took to solving a problem. BA Managers want to understand how their prospective team members think. This is your chance to show off your brain.

Do a walk-through with a trusted colleague or friend. This could be another BA, a developer, a tester, a Project Manager – really anyone that you would normally do a requirements walk-through with. The key is trust – this person will know that you’re looking for a new role.

Make the presentation a high priority

In addition to these tips, keep your audience in mind, and make things easier for them.

Your textual requirements must be clear. Use short sentences and common words. Do not rely on any assumption of technical understanding.

Graphic illustrations are more than recommended; they’re necessary. Keep them clear and small – you probably won’t have the luxury of being able to explain them and walk through them with your audience until the interview.

Advice to BA Managers and Recruiters

Hiring managers and recruiters, I didn’t forget about you.

Here is my advice on using this tool.

Remember that candidates are in a difficult position to provide requirements

First, understand their limitations.

Your candidates, no matter how good they are, will have little to no knowledge of your internal operations. The systems you use will be materially different from the ones they’ve worked with. The lingo (and acronyms) your organization uses will be different from others.

More importantly, they will not be able to interview stakeholders, and they will probably lack any understanding of their attributes. It is unreasonable to expect any truly valuable insight to come from the candidate’s work. Instead pay attention to their thought process, analysis expertise, and how they communicate.

Be as demanding as the candidate role deserves

But don’t let these limitations temper the real-world demand that will be placed on them when they join your organization.

Give a good think to what your real requirements are for the hire, not just what your job requisition might state. If your stakeholders are grammarians, pay attention to the candidate’s grammar. If your stakeholders are process people, pay attention to the flows the candidate develops.

Business Analysts have a wide range of experience, and you should keep this in mind when judging among them. Be much more demanding of senior BAs than juniors. But don’t have too-low expectations of junior BAs. They are indeed our future, and “taking it easy” on them now will set them up for poor results as their careers develop.

Choice of assignment is key to getting valuable results

To wrap up with very tactical advice, let’s talk about your choice of assignment.

Your aim should be to get sample requirements from your candidates that are relatively similar to each other in level of detail and scope. This will make it easier for you to draw meaningful comparisons across your candidates. Here are three tips to doing this.

First, the assignment should be in the Goldilocks zone – not too big, not too little. “Write requirements for a CRM system” is a bad assignment, and you’ll get results that are interesting but of little use. Instead, aim for analysis topics that are around the “big feature” level.

Additionally, make your assignment as close to reality as possible. Use real systems with real features and real users as your topics. This will help to constrain the responses you get.

Finally, help yourself out by providing at least some level of guidance about your actual organization. If you are an Agile shop, say so, or else you’ll end up with a detailed requirement hierarchy that doesn’t make sense for your organization. If your business stakeholders are relatively tech-savvy, say so, and you won’t have your candidates explaining what “buttons” are.

* * *

Good luck with your sample requirements exercises – all of you. I hope this post has clarified some good practices, but I want to hear about what you’re doing – and seeing – in the field. Sound off below.

Subscribe