Boiling a business analyst’s primary functions down, you get the following:
- conceptualize, visualize
- troubleshoot, problem solve
- research, mine data and reports
- identify trends and patterns, predict
- identify similarities and differences
- interact with people, communicate
- innovate and discover solutions to problems
- create proof of concepts, write business cases
- document procedures and implement solutions
Here is a day in the life of a business analyst using some of these primary functions:
Visualization, conceptualization, and problem solving approaches over a time have matured and are quite structured and repetitive (if done well). However, no matter how structured and repetitive your documents and processes are, the people you work with and report to will always be there to throw obstacles in your way – so expect it. The business analysts role is to confront these challenges everyday at work and constantly innovative to come up with a workable solution.
A typical business analyst’s day usually contains complexity and challenges, which require an individual to conceptualize, design, research, and report on a variety of products and/or procedures. You may be presented with a question but no data, or data without a clearly defined question. An analysis cannot really start until both the question and the data set is clearly defined. I call this QDAR, which stands for:
- Question
- Data set
- Analysis
- Report / Revision
This is similar to STAIR, which is:
- State the problem
- Define the Tools
- Algorithm (procedure)
- Implement
- Revise
Business analysts have to interact with people who have the data but are not ready to part with it for some reason. Maybe they are afraid of what you are going to do with it (such as use it against them) or maybe they feel like you are replacing them (“Hey, I’m the one who owns that data!”), so some social skills definitely come in handy.
A lot of the time the work you are doing is up in your head. This means you may often look like you don’t have work to do. This is unavoidable, but some things you can do is to make active use of a white board and/or sheets of scrap paper on your desk as a way to look busy, but truly to make sure your ideas get down on paper.
Some times you’ll lead projects even if you are not a project manager. This means you’ll have to collaboratively strategize, generate acceptability, and ownership. Getting all these people on the same platform and presenting the idea through their perspective while keeping everybody’s attention is one of the hardest parts and primarily what your function will be along with organization of the project.
Before beginning any big endeavor you’ll want to create a sort of proof of concept (PoC) document. Don’t get too caught up in formalities here. This report is for you as much as your boss to help guide you through the project or task. You’re more than likely going to be working on more than one thing at a time and you’ll likely get pulled away long enough to forget your ideas about the initiative so get th plan down on paper while you can. Use the STAIR acronym if it helps. If there are Business Requirement Specifications (BRS), include those in the document too.
Once the plan is in place, revised, and approved, it’s time to start implementing. Execution may be the easiest part, but sometimes is the hardest to do because its not analyzing, it’s work. If you’re making a system change, be sure and use change control processes, and when you are done, test, and review. Finally, report on the initiative, get feedback, and move on to your next assignment. You’ve just had a productive day!