My head is full of business analysis topics and thoughts. However, Chris Gurney‘s post ‘How to Be Awesome at Being a BA‘ assisted in inspiring me for my first business analysis related writing. In his post he does a great job of hitting on key skills BAs need to have, and is also on the money when it comes to saying, “Chances are, if your career has landed you in the role of a business analyst, it was probably by accident.”
- I too am someone that accidentally ended up in the role of Business Analyst
- I too have had very little formal training on being a Business Analyst
- I am relatively new to being a team lead
- I have no training on how to interview people
Last fall the BA team I worked on had 5 people on it. Today we have 15 with another staring next week, 3 current positions open, and one more position slated to open in the next month. Over the past 3 months I have reviewed 60+ resumes, interviewed at least 25 people and selected 6 for placement on my team. That’s almost a full time job in and of itself.
Through this, I consistently wondered, where do I find awesome BAs? Granted, I am hiring all contract positing and considering I operate within a mammoth sized IT organization there are lots of processes and restrictions related recruiting. I am essentially limited to considering only resumes submitted by our strategic sourcing providers. Given that, perhaps the more appropriate question is… How do I identify an awesome BA?
Clearly BAs need to be analytical and detail oriented individuals that communicate well, but what I have found is that being detail oriented conflicts with communicating well. First off, if I am not an aggressive interviewer its tough to get a word in edgewise after the candidates start talking. I find myself wondering, do I ramble like this when I talk? Gosh, I certainly hope not. To me a good BA will get down there in the weeds and have the ability to tell you every single nitty-gritty detail about something, but a great BA can give you the elevator speech about requirements and effectively communicate whats important to the audience at hand. As a result, I’ve landed on one question that makes it or breaks it during an interview: Can you take a moment to describe for me your ideal process for gathering and documenting requirements?
What I don’t mean is…Tell me about the process you used to gather requirements on your last project. But 9 times out of 10 that’s the answer I get and I have to painfully ask leading questions in order to try and uncover what I am really looking to understand. There are lots of technical answers someone could give me, and in a moment I will outline for you a BABOK inspired response, but first – my answer.
I would say my preferred process for gathering requirements involves a handful of key steps:
- Review the scope of the project I am working on
- Gain a foundational understanding of current state (if it exists) and the organization so I know my sandbox
- Gather requirements using techniques best suited for the project
- Distill content from those meetings into clear and testable requirements
- Validate the accuracy of the requirements with stakeholders
- Verify that requirements are truly feasible and in the scope of the project with my PM and technical counterparts
- Prioritize requirements with stakeholders
- Present a comprehensive package of requirements to all stakeholders
- Obtain approval/sign-off on the requirements
It’s not that hard. The answer should take about a minute, and if you are less wordy than I am you can probably capture it in a distinct list of verbs. The BABOK Table of Contents is a great place to pick up on the keywords a BA needs to effectively answer this question.
- 2.1 Plan Business Analysis Approach
- 2.2 Conduct Stakeholder Analysis
- 3.1 Prepare for Elicitation
- 3.2 Conduct Elicitation Activity
- 3.3 Document Elicitation Results
- 3.4 Confirm Elicitation Results
- 4.1 Manage Solution Scope & Requirements
- 4.4 Prepare Requirements Package
- 4.5 Communicate Requirements
- 6.1 Prioritize Requirements
- 6.2 Organize Requirements
- 6.5 Verify Requirements
- 6.6 Validate Requirements
There are a wealth of techniques one can use to achieve these steps, but it all comes down to four must-haves in my mind:
- Assess the Environment
- Elicit Requirements
- Organize Requirements
- Validate/Verify Requirements
Interviewing has certainly given me appreciation for what it takes to find talent and when it comes time for me to interview for a position again I will certainly do a better job presenting my own skills. So please, do me and any other hiring manager a favor. Know how to answer this question, and if the person interviewing you doesn’t ask it and you have an open ended opportunity to summarize yourself – include this topic. You should look stellar.