Have you ever wondered whether a particular experience “counts” as a business analyst experience? Or have you gone through a process to identify your transferable business analyst skills, but still feel yourself coming up short (even though you know you could do the job)? Would you be interested in reading several examples of how professionals without the business analyst job title accumulated relevant business analyst skills?
In what follows, I’ll walk you through 5 examples of how professionals without the business analyst job title have done business analysis work and explain how they can use the BA jargon to talk about their experience. You’ll learn from their discovery process so you can feel reassured about your experience, confident in your skills, and get on a faster path to finding your next BA role.
#1 – A Developer Demos Software
A software developer finishes the first iteration of a solution. The developer demos the software to the business community, walking through how a user might use the system and answering questions about how the software works. A business user notices that a particular feature is missing. The software developer asks a few questions to understand what’s needed. The developer follows up with a summary of the new requests via email and an estimate.
The software developer just completed the following business analyst tasks:
- In demoing the software, the developer uses a version of the protoype technique – which essentially means using a draft version of the solution to identify new needs and requirements. (This draft could be wireframes or actual working software, the process is the same.)
- In asking questions, the developer conducts an interview, the most commonly used elicitation technique.
- In writing up the requested enhancements, the developer conducts requirements analysis and the email is a form of a requirements specification.
#2 – A Technical Writer Creates Help Files
A technical writer is tasked with creating help files for a new software system. She meets with the project sponsor to understand the scope and depth of the desired help files and proposes an approach for creating the requested documentation. As functionality is released to a test environment, the technical writer reviews it and creates skeleton documentation. Finding gaps in her understanding, she engages the business community to understand how they intend to use the tool. The final output is a standard help file, along with several diagrams and work-flows mapping the business process to the new software functionality.
The technical writer just completed the following business analysis tasks:
- In meeting with the sponsor to understand their desires for the help files, she completed a business needs analysis and scoping exercise.
- In reviewing functionality in the test environment, she completed interface analysis – the process of eliciting information by reviewing the interface of a system.
- In engaging the business community to understand how they intend to use the tool, she completed business process analysis. The workflow diagrams she created as part of the help files are business process models.
(By the way, if you think you might have some transferable business analysis skills, you might want to check out our Business Analyst Template Toolkit. The work samples will give you a quick view of what types of deliverables a business analyst creates and the templates will help you get started doing more business analysis.)
#3 – A Subject Matter Expert Gets Involved on a Project
A Customer Service Representative (CSR) is assigned to represent their team on a new project to enhance existing customer-facing functionality. The CSR brings a list of customer complaints to the kick-off meeting and collaborates with the business analyst to figure out the root cause of the complaints. They agree some of the complaints aren’t very clear or actionable, so the CSR schedules time with the customer to more fully understand the issues they reported, gets concrete examples, and also discovers why these problems cause so much frustration. Before the changes are released, the CSR schedules a demo with the entire CSR team and trains them on the new functionality so they can answer any customer questions.
The CSR just completed the following business analysis tasks:
- In compiling a list of customer complaints, the CSR conducted a business needs analysis, which is part of the enterprise analysis knowledge area of business analysis. The list of complaints they provide would also be an example of a draft requirements specification.
- In collaborating with the BA to find the root cause of the complaints, the CSR conducted analysis and problem solving activities.
- In following up on unclear issues, the CSR conducted interviews, a very common elicitation technique.
- In demoing the new solution to CSRs, the CSR used the prototype technique and also was involved in change management – essentially helping the employees who are impacted by the project understand what changes are coming and how it impacts their work.
#4 – A Subject Matter Expert Prepares for Her Transition
As her work is being outsourced to a third-party provider within six months, an editorial coordinator is asked to document her processes and train her replacements. She writes up several procedures that become the standard operating procedures for her entire group. She works with others on her team to understand how and why they handle scenarios differently than she does and updates her process documents so they can be consistently applied by their third-party replacements. She creates several work-flow diagrams showing how the process works. She meets 1-1 with individuals from the outsourcing firm and trains them on how to use the system.
The editorial coordinator just completed the following business analysis tasks:
- In documenting the current process, she applied business process analysis techniques.
- In creating workflow diagrams, she used visual communication skills.
- In reconciling various different versions of the same general process, she completed business process streamlining and improvement.
- In training her replacements, she was involved in change management.
#5 – A Quality Assurance Engineer Discovers Software Issues
A Quality Assurance Engineer works in an environment where the software developers design and code without clear requirements. During testing, a lot of issues tend to come up. Some of these issues are discovered by the QA Engineer – they understand the business and the workflow and so they see gaps. Once initial testing is complete, the QA engineer coordinates a review by the business community. The business community reports the issues to the QA engineer, who will often stop by the user’s desk to walk through the problem, and then logs them in the defect tracking tool.
The QA engineer has just completed the following BA tasks:
- In reporting issues in the defect tracking tool, the QA engineer is analyzing and specifying new requirements or requirements changes.
- In coordinating a review of the application by the business, the QA engineer is facilitating User Acceptance Testing.
- In stopping by a business user’s desk to understand an unclear issue, the QA engineer is using a combination of interviewing and observation to elicit information about expected software functionality.
These 5 examples are 5 of hundreds of potential scenarios I could have drawn from, showing how the BA jargon can be used to talk about your experience even if you’ve never had the job title of “Business Analyst.” If you feel like you are coming up short in your skills discovery process, even though you know you could do the job, take another look at your career background for relevant business analysis skills and experiences. Because your career background could just help you get hired faster.
>>Build Even More Business Analyst Experience
Would you like a starting point for approaching common business analyst work scenarios? Check out the Business Analyst Template Toolkit – all of the requirements templates are fully annotated and editable by you, giving you a great starting point for starting your next business analyst project or formalizing your work samples.