Business Analysts solve organizational problems. Although overall activities, responsibilities and qualifications vary greatly by position,  Business Analysts are always responsible for leading change, creating clarity and fostering alignment.

According to the Business Analysis Body of Knowledge (BABOK) Guide® version 3: Business analysis ultimately helps organizations understand business needs and why they want to create change, design possible solutions, and describe how those solutions can deliver value.

Business Analysts work on all types of projects and change efforts. Some of the most prevalent applications of business analytics activities include software modifications, business process improvement, and ensuring compliance with regulations.

When thinking about what business analysts do, it can be helpful to consider the concept of change in the broadest possible sense. Business analysis techniques can be applied to any scale of change, from large to small. A significant change can take a year or more to design, implement and deploy. An example would be developing an onboarding strategy for a newly recruited sales team. Another type of significant change would be the deployment of a new software solution, impacting many areas of business processes. In contrast, a small change can be made in as little as a day or a week. Examples of relatively minor changes would be updating a field on a user interface screen or producing a new report from existing data.

Regardless of the scale of the change, the business analyst works with stakeholders across the organization to understand the Business Objectives driving the change, define the scope of the change, change, analyze and specify detailed requirements related to the change and finally, support the implementation of the change.

While business analysts have always been seen as the bridge between business departments and IT departments, the reality has become much more complex. Business analysts today bridge gaps in knowledge, perspectives and understanding between stakeholders from different functional departments, at all levels of the organization.

A stakeholder is anyone who has an interest in the change or who has an influence on the change. Stakeholders can be the beneficiaries of the change or participate in its implementation.

It is not uncommon for a business analyst to obtain approval from a Director-level sponsor, learn about how the process works from business users across multiple functional departments, negotiate technical possibilities with a technology architect , communicates requirements to a developer and QA.

A business analyst bridges multiple gaps in understanding between all stakeholders to align with the future plan and ensure that the implemented change generates as much value as possible. The main outputs of business analysis activities are requirements, which are grouped into documents called specifications. A requirement is a condition or capability necessary for a stakeholder to solve a problem or achieve an objective. A requirements specification includes the requirements specific to a change, project, or project component.

Business analysts verify that the requirements are clear, complete and represent the needs of the stakeholders. Business analysts employ a range of techniques to carry out their work.

Ultimately, the business analyst is responsible for reaching a common understanding of what needs to be achieved and helping stakeholders discover the best solution to deliver the most value to their organizations. Decisions become easier if we can see and feel what the end result will look like.

The rest of this article is intended to help you put yourself in the shoes of a business analyst. I invite you to absorb what is written here and see yourself in different aspects of this role. First, let’s take a look at a hypothetical real-life workday that a Business Analyst might experience.

A typical day for a Business Analyst (Business Analysts, Business Analysts or Business Architects)

It’s Monday: meeting day. I arrive at work at 8:15. I really wanted to arrive at 7:45, but there was an accident on the road that delayed me. Before I left last Friday, my Director asked for my feedback on some of our new projects. She wanted me to provide her with estimates and assumptions for planning purposes. His secretary therefore welcomes me with a document. I open the document, and I see that this document includes three projects. I read the details. I see right away that nothing is detailed. The first project is actually an idea that came up during a project workshop. The other two are new to me and I have a lot of questions. She needs the estimates by the end of the day. I go to her office and she’s not there. I decide to send him an email.

I open my email. A flood of messages arrives. At least ten contain the same subject line, and the chain was started by the architect of my main project. I choose to read the latest in the chain in hopes of following the thread so I can respond before my 10:00 a.m. appointment. I see the team is confused about the requirements but also about a new technical issue that hasn’t been discussed. So I reluctantly hit reply all and let everyone know that I would schedule a meeting later today or early tomorrow to discuss the problem.

The project manager of one of my minor projects comes to my office to ask what is driving a specific requirement. The developer team is having difficulty meeting the deadline and the project manager would like to propose that this particular requirement be postponed. I’m able to clarify why this is important, but I think there might be other ways to reduce delays and meet deadlines. He agrees to schedule a meeting on Wednesday or Thursday so we can review the outstanding requirements and project timeline and develop a proposal to present to the company.

It’s now 9:30 a.m. and time to prepare for my 10:00 a.m. appointment. I print out the documents we are going to review and give them one last look. I write down a few questions, grab my notebook and laptop, and head to the meeting room. Fortunately, the participants of the previous meeting vacated the room a few minutes early. I turn on my laptop and connect to the projector. I display the documents I need, as well as the most recent set of mockups.

I’m still finishing the installation when the architect arrives. He seems unhappy, and I think about ways to keep this meeting on track, even though I know a burning technical issue could distract us.

I decide to face the problem head on. I ask him about the problem and if it’s urgent. He seems pleased with my question and says he wishes he had thought of this potential problem sooner. It’s urgent, he said, but a meeting this afternoon is good. He also needs the final documents that we will review in this meeting to begin planning the design for the next iteration. This is the best result I could have hoped for.

The product manager and two subject matter experts arrive right on time. We discuss the new project proposals under study, those that my Director sent me via his secretary this morning. I get some information about the second proposition that will be useful in my estimation. Five minutes past the hour, the other developers arrive. We can launch.

Some people have printouts of the documents, but for those who don’t, I display the most recent documents on the projector. We walk through the four-page use case, which describes step by step how the user will interact with the solution to achieve a specific goal, section by section.

Collectively, we’re asking a few questions and making some minor updates. We agree that the use case is ready to be designed. One more use case remains on today’s agenda, and we wrap up our review with fifteen minutes remaining in the meeting.

I ask if everyone would like to discuss the issue raised by the architect, but we have no critical development. We decide to stick to the original plan and meet up this afternoon. For the remaining ten minutes, I ask a few high-level questions about the next use case on the list. I learn what drives the feature from the product manager and a technical constraint that the developer is concerned about. We adjourn a few minutes early.

I take a bathroom break and return to my desk. First of all, I see that everyone who needs to be involved in solving the new problem is available at 3:00 p.m. I create a brief agenda and schedule a meeting. I note that we may only need a half hour, but I’ll allow a full hour just in case.

I open my tablet, and capture my handwritten notes in electronic form. I list three new actions to take or next steps to take. I’m adding two new issues to the list of issues as I keep questions and concerns open for the project. I also close an issue on the list and document the answer to the question as the resolution of the issue. It’s almost noon, so I’m getting ready to go out for my break. I usually eat lunch at my desk, but I’ve learned that escaping for even just half an hour helps me have a more productive afternoon. Today is a beautiful day.

I get my sandwich from the cafeteria queue. I was planning to read some articles from a recent business analyst newsletter, but I see Cyriaque of Accounting sitting alone. Accounting has a few process-oriented people on its team, and Cyriaque is one of them. My ambition is to ultimately establish a community of practice where all members of our company performing business analysis tasks can share their best practices, and Cyriaque would be an influential ally. I ask him if he is busy. It doesn’t, so I sit down.

Cyriaque and I discuss our children’s latest school project. We also talk for a few minutes about our latest projects. I realize that my current major project could impact the accounting process. Cyriaque agrees to evaluate the requirements and determine if he can foresee any problems.

We finished the break. Cyriaque bids me goodbye and I wander outside, listening to part of a podcast on divine audacity by Mohammed Sanogo. Most of the time I read and listen to literature, but I recently invested in a podcast series about self-awareness and am discovering a multitude of new ways to improve my interpersonal relationships.

I return to my office around 1:00 p.m. I’m updating the two use cases we looked at this morning. I go through my meeting notes, issue list, and use cases, then upload the updated files to the company intranet. I am sending an email with links to all relevant documents to the guests at this morning’s meeting for review.

I check my calendar and see that I need to tackle a new use case for Thursday’s meeting. I spend about an hour drawing the use case, integrating the questions I have, and designing a rough model. Tomorrow I’ll give this another review and send it to the guest list.

While I work, a fellow Business Analyst returns to her office after a meeting. She is new to the team and she is visibly frustrated. I ask him what’s wrong. It turns out that my project’s new problem might also impact his. One of the developers brought it up at his meeting, even though the architect wasn’t there, and it derailed his agenda. I let him know that I could schedule some time to look into the issue later today and promise to let him know of the resolution. I also give him some tips that I use to prevent such concerns from getting in the way of my meetings, such as reviewing the agenda and the importance of each item at the opening of the meeting and keeping a list of issues when Unexpected problems arise.

Then, I realize that I haven’t been to my Director’s office again, and it’s already 2:30 p.m. I walk over to her office and luckily she’s there. We discuss the projects for a few minutes, and I agree to have his rough estimates and assumptions after my 3:00 p.m. meeting. She asks about the problem. I give him a brief summary of how this happened and how I stepped in to save everyone from a miserable email chain. I tell him I will let him know if the project is significantly impacted. She gives me an approving nod and I return to my desk.

I only have a few minutes left to get to the 3 p.m. meeting. As I sit in the conference room, I review the email chain one last time. I take some notes and decide how I’m going to open the meeting. The crew comes in and discusses the problem. I ask them to pause the conversation until everyone is there. After all, we are here to reach consensus.

We have everyone we need and I’m summarizing the problem as I understand it. I ask if anyone would like to clarify what I said, and off we go. Forty-five minutes and several whiteboard drawings later, we solved the problem. I will need to register a small change request with the project manager. I am tired but full of energy. We all leave optimistic.

After a short break, I spend the rest of my day working on my manager’s estimates. At 5:20 p.m., I finally hit send on the email. Retrieving the meeting notes from the problem-solving session and writing the resulting change request will have to wait until tomorrow.

No typical day

While the story above walks you through a likely day for a business analyst, there is no such thing as a typical day. Rather, business analysts experience different types of days, some of which tend to repeat throughout the project life cycle and others that are unique from each other.

Business analysis is not the type of career in which you necessarily have to prepare for everything, but expect occasional surprises or unexpected situations. In most business analyst jobs, you will experience a lot of variety in your daily work. And while it’s not a role like technical support that requires near-constant interaction with others and real-time prioritization, priorities change for business analysts, and a certain amount of flexibility and responsiveness is important . Of course, if your business suffers a disaster or discovers an unexpected and significant opportunity, you may be called to its aid at short notice, but this is not the rule.

More often than not, your days won’t hit you, but you will hit them.

The best business analysts drive the requirements processes. This means scheduling meetings, managing input, influencing stakeholders, and verifying that decisions are made. Excellent business analysts are proactive and seek answers. If this role isn’t right for you, it might be possible to find positions where you can partner with a strong project manager. In general, however, you should be prepared to plan your own work to meet deadlines (possibly self-set, possibly imposed) and to facilitate contribution and occasional follow-up with a number of people to achieve your end goals. Although there is no typical day, a business analyst can expect to experience several types of days.