[ Pobierz całość w formacie PDF ]
.I get back to my desk around 12:30.I update the two use cases we reviewed this morning.I browse through my meeting notes, issues list, and use cases and then upload the updated files to the company intranet.I send an e-mail with links to all of the relevant materials to this morning’s meeting invitees.I check my calendar and see that I need to get moving on a new use case for Thursday’s meeting.I spend an hour or so drafting the use case, incorporating the questions I have, and drafting a rough mock-up.Tomorrow I will give this all another review and send it out to the invitee list.As I am working, a fellow business analyst comes back to her desk after a meeting.She is new to the team, and she is visibly frustrated.I ask her what is wrong.It turns out that the new issue on my project could impact hers as well.One of the developers brought it up in her meeting, even though the architect was not there, and it derailed her agenda.I let her know that I am scheduling some time to go over the issue later today and promise to inform her about the resolution.I also give her a few tips that I use to keep concerns like this from hindering my meetings, such as reviewing the agenda and the importance of each item at the opening of the meeting and keeping an issues list for when unexpected issues come up.Then, I realize that I never stopped by my manager’s desk, and it is already 2:30.I walk to her desk, and luckily she is there.We talk for a few minutes about the projects, and I agree to get her rough estimates and assumptions after my 3:00 p.m.meeting.She asks about the issue.I give her a brief synopsis of how it came up and how I stepped in to save everyone from a miserable e-mail chain.I tell her that I will let her know if the project is impacted substantially.She gives me an approving nod, and I go back to my desk.I have just a few minutes to get to the 3:00 meeting.As I sit in the conference room, I review the e-mail chain one final time.I write down a few notes and decide how I am going to open the meeting.The crew wanders in and chats about the issue.I ask them to hold off on conversation until everyone is here.After all, we are here to gain consensus.We have everyone we need, and I summarize the issue as I understand it.I ask if anyone would like to clarify what I have said, and we are off and running.Forty-five minutes and several white board drawings later, we have resolved the issue.I will need to log a small change request with the project manager.I am tired but energized.We all leave in upbeat spirits.After a short break, I spend the remainder of my day working on the estimates for my manager.At 5:20 p.m., I finally hit send on the e-mail.Getting meeting notes out from the problem-solving session and writing up the resulting change request will have to wait until tomorrow.No Typical DayWhile the story above walks you through a probable day for a business analyst, no typical day exists.Rather, business analysts experience different kinds of days, some of which tend to repeat themselves throughout project lifecycles and some of which are unique among themselves.Business analysis is not the type of career where you need to necessarily be prepared for anything, but expect the occasional surprise or unexpected situation.In most business analyst jobs, you will experience a fair amount of variety in your day-to-day work.And while this is not a role like technical support that requires near-constant interaction with others and real-time prioritization, priorities do shift for business analysts, and a certain amount of flexibility and responsiveness is important.Of course, if your company experiences a catastrophe or uncovers a meaningful unexpected opportunity, you may be called in to help on short notice, but that is the exception not the rule.Most commonly your days will not hit you, instead you will hit them.The best business analysts drive the requirements process.This means scheduling meetings, managing input, influencing stakeholders, and checking that decisions are made.Excellent business analysts are proactive and seek out answers.If this is not a comfortable role 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 for planning out your own work to meet deadlines (possibly set by yourself, possibly imposed) and facilitating input and occasionally following up with a number of people to achieve your end goals.While no typical day exists, a business analyst can expect to experience several kinds of days.During Project InitiationProject initiation mainly involves eliciting requirements to understand the scope of a potential solution to a problem.Elicitation days are fun, and many business analysts enjoy elicitation days the most.These days occur early in the project or possibly even before the project commences and involve meeting with stakeholders to understand what they want to achieve in a project.You will spend elicitation days drinking from a fire hose because you will be learning so much and handling so many different perspectives about the project [ Pobierz całość w formacie PDF ]