Enjoy the episode!
Want to make a huge career change?
Sick of applying to jobs and hearing nothing back?
If that's you, then check out our Career Change Crash Course. We'll teach you how to identify the skills you need to get the work you want, how to craft a story around your past experience, and how to sell your skills to your future employer!
Join the Degree Free! Receive our weekly newsletter and get exclusive tips and tricks to get hired and make money without a degree!
Not sure where are the best places to find jobs online? Check out our previous episode!
Ryan: Aloha guys, and welcome back to the degree free. We are your hosts, Ryan, and Hannah Maruyama. On this podcast, we share fundamentals we've discovered and the mistakes we've made while self-educating, getting work, building businesses and making money. We'll tell you how to make it happen. No degree needed.
Hannah: Welcome back.
Welcome back everybody. Thank you so much for joining us again. Please do like, and subscribe because you don't want to miss this, and then if you listen to a previous episode or after you're done listening to this one, you're curious as to go about learning and then getting a job similar to this without a college degree, check out our guide.
It's on our website. It's degreefreenetwork.com. That's degreefreenetwork.com. And you can grab the guide on there.
Ryan: Yeah. And let's get into today's episode. So today we're going to do something a little bit different. And we're just basically in our answer, one of the questions that we get about your job and it's basically like, what does an IT business analyst do?
Hannah: That's a great question.
Ryan: And honestly, it's a good question because I don't even know what you do. I mean, for the most part, I know that you work.
I know that you sit at a computer and you wear a headset from time to time.
Hannah: I do.
Ryan: That's like, that's like the extent to which what I know that you do is so today's going to be just as educational for everybody else, listening to this.
Who's possibly thinking about going into an IT business analyst role, and then also some other things along the way, too. I think that you've you've accumulated some certifications along the way. Salesforce, scrum master, I dunno, we'll get into that. And what those mean too.
First off, I'll say, let me just take a stab at what I think that you do. So when I hear business analyst, so I don't know about, I don't know what the IT part, but when I hear business analysts, what I think of is somebody that combs through financial statements of a company, looks at the top line. And I guess.
We have to remember that I come from a little bit more of a financial background. So when I,
Hannah: Economics, don't get carried away.
Hannah: I'm sorry I had to be done, but it
Ryan: Gonna burst my bubble.
Hannah: Economics is the communication math.
I'm sorry. No, he wasn't accounting guys.
How you doing?
Ryan: I'm doing great. Fantastic. So what I think a business analyst does is I think that they, once again, they look through a financial statements and they go through, they looked at the top line and they're saying, how can we improve revenue? How can we how can we reduce cost of goods sold?
And then you look at the bottom line and you're looking at how to eliminate expenses, those types of things. That's what I think about what a business analyst does. Correct me.
Hannah: If so, so ask me.
Ryan: What does an it business analyst do?
Hannah: Please. It had to be done. It had to be done. The, how I met your mother and references have to be done.
Okay. So what I do. Basically, what I do is I am a translator. And the reason that my job exists is you're not wrong about the fact that there is some mathematical analysis, but for me, in my role at the company that I'm with now, my role is to work with a software development team. And essentially what I'm supposed to do is work with the project manager.
I worked pretty closely with the project manager. And then what I do is I talk to, to the developers. But most importantly, I talk to the clients, the customers, and the technical term is a stakeholder. So that would be somebody who has a vested interest in the success of the project. So usually those are people that either are going to use it.
Like let's say this project is for a call center, should, would be people that actually work on the floor of the call center. They would have picked a couple people who care about it, who are going to be, or directly affected by it that are on this team basically. And then they're also going to have people who are paying for it.
People usually who have some like budgetary stake in the project and then people who are managing. So people who manage the people who work, who are going to use the product that we're, that we're making. So this is also a little bit different because it delves into different project methodologies.
This is going to get very technical term heavy just because those are the only terms that you can use. Really. So I'm going to try to break the terms down. So when I say methodology. There are different types of ways that projects work. There are three general ones and it's going to be waterfall, which means at the beginning of a project, everyone agrees on something.
And then. Six months later, a thing is given to them that supposedly matches these requirements. There is a high failure rate to those projects, which is why a different method have evolved. And it's called agile and agile, primarily used for software it's used for software development. Whereas waterfall is typically used for like large bulky things like manufacturing or DOD projects.
And aviation is another good example of that because it's like you're working with expensive things that you know, that they've got to get done at a certain time. Whereas agile is used for things that change as user feedback is given. And as people interact with whatever you're building, because you can change it much easier than you could change, like the way a plane is being built.
And then there's a hybrid. Which is a combination of both. So to some extent, some things are predetermined and then some things are more flexible and can be changed. Now I think that with projects in general, big projects, It can be really rocky. Anyway, you look at it because it's just difficult to get from here's this thing that we want and they just come up with it.
Whoever wants this thing done just comes up with best case scenario, but there's limitations, right? There's limitations based on what they want done, how soon they want it done, how much money they have to do it with, how many people are going to be using it. There's just a lot of things that go into this.
And so things change really quickly. And there's a disconnect between the clients, and the people who need the thing and the people who are building the thing, because if you've ever talked to somebody who is a software developer or a coder, they have oftentimes a difficult time breaking down simply what they're doing and why they're doing it.
And also they have better things to do than explain that to somebody. So that's why, that's why my job exists.
Ryan: Got it. So to break it down for myself, You're basically, as you said, you're a translator, you're a go-between, between the technical and the non-technical.
Hannah: Ideally the business analyst is involved at the beginning of a project where you're trying to figure out what the requirements of the project are.
So those initial listing of things that they want done. So usually a business analyst helps the stakeholders come up with the requirements. Sometimes it's not the same business analyst that works with their team. Sometimes it's a separate entity.
Ryan: So this could be like in the sales process, even like before, for some companies, this could be even before they've got the project, the business out of this comes in and figures out, extracts the stakeholders wants and needs and then translates it to the developers. And then the developer. Say yes or no, they can do that. Here's a timeline, whatever.
Hannah: Well, before it even gets to them, it's going to go to the project management and then the higher stakeholders, because they have to agree on a timeline and a budget.
So the business analyst is usually involved in that. And then, and then after that, yes, I see. I see. Usually you would have your lead developer, your head developer who is involved in that process a little bit as well.
Ryan: Got it. So why is it called the business analyst?
Hannah: Because you are looking at now there's a lot of, there's a lot of types of business, business analysts.
There's a lot of types of business analysis and there's a lot of different ways. You can be one in different capacities for different projects. So I have a limited scope of experience on this because, business analyst joke scope, but I have a limited I have a limited view on this because I've only worked as a business analyst on my project.
Ryan: I'm just trying to understand this. Business analyst. There's many different shades of business analyst.
Hannah: And you got a more for whatever project you're working on too. Because it could be a really small one or it could be a really huge one. So you could be, you could be gathering requirements and helping formulate a plan for a project that's going to take 10 years, or you could be developing a plan for something that's going to take three months. So wide, there's a wide range there. And. It's going to differ really, really widely, depending on what you're doing too. If you're doing a construction project, it's going to be a different type of analysis than you're going to do for somebody who needs it like small piece of software.
That's not really going to be too hard. Or if you're building a website for somebody not depending on the size of the website, not very major, you know what I mean? A two page website. Okay. That's not going to be hard. A 400 page website. Okay. That's were, this is a whole other ball game now.
And usually to o, how complicated that is, is going to change based on how many people are involved.
Ryan: A lot of times, you're just asking questions.
Hannah: That's mostly what I do. Mostly I ask why.
Ryan: Just the question why?
Hannah: Why they say, oh, well, well, before we do this, we do this. Oh, well, we can't do that without this.
Why? That's my job. It's very simple. So then what I do is I do keep pretty detailed notes. I keep a record of things that are said, and the reason for that is to protect both sides, right? So it's to make sure that the client tries to get what they want and to make sure the development team can actually give the client what they want while still doing their work not being distracted or getting pulled into discussions with, with the clients.
Ryan: But I guess, no, but what I meant by that was like, what do you do?
So like, you're asking why all this time, what are you trying to get at?
Hannah: Oh, oh, what am I trying to get at? I'm trying to get at the motivations for doing something so that I can find a simpler, cleaner, or more efficient way to do it.
Ryan: Got it. And so,
Hannah: As a business saving money.
Ryan: I see. Okay. So as a business who got it, you can, it is also a part of the process.
I see. Okay. So I have a problem and this problem is five steps. Currently in my company, I'm gonna hire your company to do these, to make these five steps into three steps into one step or whatever I want these five manual tasks. We do it all the time and I needed automated or I needed a lot more efficient to happen.
And so you're asking why we do this? Why we do this? Why we do this, why we do this? And it gets me back all the way to the beginning and then from the end, and so now you and your team of developers, you guys work on how to get me what I want and then how to possibly show me that instead of doing it in five steps, actually I only needed three steps or whatever.
Hannah: And it's an ever-changing it's it is a really ever-changing process because there's multiple different reasons why things can, and can't be done a certain way. So you try to make it as efficient, as possible, as cheap as possible, make as much money as possible, right.
For the company. That's your goal. Save time. There you go. So, let's say somebody wants to, let's say you have a business and there's 10 employees and there's 10 employees because everything that they do has been done on paper for a very long time. And now they want to digitize all their files.
They work in an industry that's heavily regulated. So now, without knowing anything about this company, like, let's say they have nothing written down, they have no rules written down about why they do what they do. And then you just had people that have been working there for 10, 15 years and they just do what they do and they don't even know why.
And then you get somebody, you get a bunch of people busting in going, we're going to put this all in the cloud. And these people are like what's the cloud, and then these people who are going to say, we're going to put it in the cloud. They have to figure out how to get these people, to tell them. Well, they need to do in order to put it in the cloud to like follow laws, to make sure none of the data is lost to make sure everything is where it should be to make sure it makes sense to the people that are going to try to find it. So it's a really ridiculous complicated thing because every situation is. So you're always looking for like, all right, like which person in this group is going to be the decision maker.
So in a group of stakeholders, you're always looking for like, all right, who's the one, who's the one who's going to like advocate for this to be done. Who's going to fight against you. It's your job to win those people over to your side and try to help them understand things. It's my job to figure out what they actually need.
Like what's going to make it easier for them. Like, oh, they think it would be easier to do it like this, but actually it would be easier if they just do this and then to explain to them why they have to do it like that. So they don't resist when that's done. Because it's cheaper. Saves the company money. Because while they're resisting it while they're resisting it, the company's losing money or it's taking them longer to do their job.
And it's making them less likely to say that the project was a success, even if it meets all of the management expectations. Yeah. So it's like, there's a lot, there's a lot. Is it you're smoother. Pretty much. You're just like, all all right, well, let's do like this or, Hey, let's try this or, oh, this is why.
Ryan: It seems your role is very multifaceted than, I mean, it's, to me as a layman understanding, this seems pretty general.
Hannah: Yeah. Yeah, it is. It's like this, it's like a Swiss army knife type job, because like today, for example what I did was I took notes. I took notes on a meeting. I helped a project manager to make sure we were rewriting some requirements for our project to make sure that they're correct.
That they're phrased in the way they're supposed to be phrased. Cause that's gotta get submitted to somebody above us. I got on a one-on-one call with a stakeholder for a project to say, okay, like we got this feedback from you on, I want to make sure I understand why you feel this way and then explain some things to this person so that they better understood what we were doing and why we were doing it, and both left happier than we originally called.
And then I did some work on it, like a really manual process where I was downloading data and then fixing the data. And then I had to upload the data and it's my job to do this process and figure out what steps can be eliminated from that. So like, that was my that's what I did today.
Ryan: Got it.
Ryan: So talk to me about workflows.
Hannah: Yeah. So workflows are a pretty big part of the projects that I work on now. And that's for a few reasons. One is because we do want to keep documentation on when we say, okay, so let's take a business process. Somebody FedExes in a document that this business needs to have. And then it goes from the FedEx envelope to a secretary and then the secretary takes it out of the envelope and they stamp it, but they only stamp it if it's a blue paper.
So they get it out and it's a red. Now it's a red paper, so it has to go to the next person. And so when it goes to the next person, they say, okay, this is red. So now I have to put it in this box. And then I have to send an email to this person to let them know that there is a red piece of paper in this box that they have to sign.
Okay. So that's how their process is now. And then after this person at the top signs it, then it gets manually filed into somebody's file cabinet. And that's the end of the process. So my job is to go from start. So FedEx envelope, and then I'm supposed to go, okay, now we're going to the secretary. Now we're going to the decision the secretary makes, which is it's rhetoric.
And then it's a red paper. So it goes to the next person and then it goes from that person to the box and then it goes from the box to the chief and then it goes back to the file box. And that's the end of the process. And so my job is to go from, start to finish and explain how they do it now, so that I can go back and say, all right.
So if we're going to digitize this whole process, now this thing, instead of being a FedEx, it's an email. And instead of going to this initial person, we've said, we're going to set up an automated process where the email already knows that it's red. So it goes straight to the second person and it not only does it go to the second person, it CCS, the person who has to sign it, they sign it on the internet and then it's automatically filed.
And that's the end of the process.
Ryan: I see. So. I knew what a workflow was, but I thought that it was only used for like documentation in the current. I see how you guys are using it.
Hannah: As in to be.
Ryan: Right. I had, that's interesting for me as somebody like I've done plenty of workflows, but I've always done them as is, and then I've always done them to be, but I never did the comparison of the two, because I never had to explain to anybody.
Hannah: Well, because my job is to meet with somebody and say, so this is what you do. And that's really important because when things are moving like this, and everybody's talking about stuff and there's constant feedback app say, this is it right.
This is what you said, this is what you do. Because if they don't agree later, they might say, oh no, no. And then they'll tell us about another five steps.
Ryan: That make sense. You mean this I've done plenty of workflows, but the workflows are for our business. The workflows are for us. And I don't have to explain to other,
Yeah, to other people.
Where did you get that idea from?
Ryan: Exactly. Yeah. Interesting, interesting. That is interesting.
Hannah: It does make sense because you're getting people to opt in on change. Because they're supposed to work with me to, to get, to get me to understanding of, okay, what are you, what are you. And write, and I've asked why up until this point.
And then I'm like, all right, now, what do you, what do you do? And then we go in and say, okay, why, why do you do these things? And then they have to explain to me, you don't have to justify to me why they do this and if it's necessary, because then it's my job to go, okay. This step is not, it doesn't need to be here.
Like it doesn't legally need to be here. Not, I'm not a lawyer, but like, there's no statute that requires you to do this. You'd like, there's no law or regulation that requires you to do this. So this is just an unnecessary step. It doesn't need to go to this person too. It just needs to go right to this person.
And then it needs to be automatically sent wherever afterwards.
Ryan: So one of the things that I wanted to ask about is like the different certifications that you have and like, which certifications, cause I know that you have a few, I forget which exactly you have. Wondering, which ones do you actually need to do your job?
Or which ones should did you get first? Or which ones should you get? First, if you're thinking about doing this type of work.
Hannah: That's a good question. I think, I don't know, man. The certs have helped me so much because they've got my foot in the door, but in truth, I think I could have just, I don't necessarily think I needed the certification.
I just need to study. A lot of what I needed to know was I needed to know the lingo so that I could understand what my managers were telling me to do, because they're telling me to do things that makes sense, but they have names that I'm not familiar with. So it's like, we want you to do a SWOT analysis.
I'll have to know what that is. We want you to do a fishbone diagram. Okay. Well, I have to know what that is, I can't just like, I can't just draw a fish on a piece of paper and then go, here you go. I should've done that.
Ryan: Through the rundown.
Hannah: If my project manager now ever asked me to do that, I'm 100% just going to draw a fish on a piece of paper and scan it, then it'll be worth the effort for sure.
Give me the rundown. How hard did you work on this?
Ryan: Not any harder than I needed to.
Hannah: Oh, I want you to work any harder than you.
Oh, so good. But yeah so, it's mostly just knowing what the things are. There was a lot of studying. I do have a BA my business analyst certification took me the most studying, I think I think that I was better at studying, but I will say it had the most material to go through.
Ryan: So I think for listeners just to make it easier let's lay out which ones you have.
Hannah: Okay. So I have a Salesforce administrator certification. I have a data analytics certification. I have a scrum master certification, and then I have a PMI PBA business analyst certification.
So I have four.
Ryan: Okay. And I guess quickly, can you say what each of those things are.
Hannah: Oh sure.
Ryan: A few sentences.
Hannah: Yeah. So a Salesforce administrator is somebody who basically just tends to a Salesforce instance. It's basically a website that stores a company's information. All of their data about their customers or whatever they, whatever in incoming data they have.
And your job is to reset passwords, make new fields, which are basically lines that have information. Yeah, resetting passwords sending different permissions for different users and making reports from the information that's in there, which is really not very complicated. And then a scrum master is somebody who is certified to facilitate meetings and work with a project manager because their goal is to work with a development team, to help them work faster and work better and work more efficiently together. And so basically what you do is you make sure that meetings are within a certain timeframe. It's your job to take care of Jira or whatever project management agile thing you're using to run the project. It's your job to ask questions of the development team when they do things, it's your job to talk to the development team. And then you also are important because you work with the business analyst to work with the stakeholders, to have a project. Data analytics is just understanding data sets when knowing a little bit about Tableau and R, which are data analytics software, and then business analyst work or business analysis work is just analyzing how business works how a, project's going to work, how something's going to be delivered of how how a contract is going to be done and delivered to somebody involving the stakeholders involving there's a little bit of money, but not so much, not so much in my experience. And then just understanding how the flow of project works.
Ryan: Okay. Perfect. And so I guess, for your current role as an it business analyst, do you need all of those things or like, what is the minimum amount that you think you needed for this job?
Hannah: The minimum amount? I think I definitely would have needed to study the PBA handbook I would have had to read through that and understand it. I think for me too, I need a reason to learn something.
I would say that it was really helpful because. When you have a goal, when you have a reason to study something, I had a reason to learn the information quickly and absorb it. And then I immediately afterwards had an application for it. Cause I started doing that work. And so for me, I think that that was probably the most impactful cert that I got.
Obviously Salesforce was what got me into the role that I have now. But I will say that the business analyst certification really, I think that that was the one that I think was the most important one, because it gave me a well rounded understanding of why the project was working the way it was.
But also because of our businesses, I was like, oh, I understand the function of a lot of this.
Ryan: Okay, that makes sense.
Hannah: I have to say though, I did like the scrum master certification because I have worked really closely with the scrum master for my teams that I'm on and I've learned a lot from him.
And because of that, I think that that was my major motivation. That certification and seeing how he having a scrum master on your team really does help the team work better. It really does. A lot of people you'll get the tech people that are like, oh, so all you do is like sing kumbaya and blah, blah, blah.
But I will say it smooth a lot of stuff. And the scrum masters job is to get things out of the way of the development team. So they work better and, the person, the person that I work with does, does it very well. And also does business analysis very well using the agile methodology, which is what scrum is.
Well, it's not, it's not exactly, but it's, it's based in. It's similar. Their cousins basically.
Ryan: So we touched on it earlier, but I'm wondering if I can just ask directly what kind of trait do you have to have to be a good business analyst? Like it seems exactly what you said. It seems like this is a pretty general multifaceted role.
It's not super, at least in the role that you're in. It's not super specific. Like what are some of the traits that make a good business analyst?
Hannah: I think probably the most important one actually is. I think the most important one is probably humility because a lot of the time I'm asking people who know a lot about something when I know nothing about it, why? I'm saying, okay, well, what is that?
And I come into most situations with no knowledge of what's going on, and then I have to figure out what's going on. And then I have to make an assessment from a position of authority that I don't have yet very quickly. And so that involves me asking a lot of people questions that sound very dumb, or sound very sound very simple. And because of that, they can be perceived as dumb. Like if somebody says, oh, well we have to get it done by Tuesday. So I'm like, well, why do you have to get it done by Tuesdays? Or they say, oh, well this is on the, the CSRSSIS. And I'm like, well, what is the CSRSSIS?
Even if it's something that supposedly I should know, but sometimes they'll just, they'll just say, okay, well, you got to jump on this meeting with these people. And I know I have no context. I know nothing about what's going on, but I have to figure out what's going on. And the only way to do that is ask questions that other people don't want to ask, because it makes you look like you don't know what's going on.
Ryan: I guess that's the whole job though, right? I mean, I guess that's like a good, well, that's what we're talking about it, but I mean, a good trait to have is you have to think about it from a beginner. You have to have a beginner's mindset because you are the go-between between the technical and the non-technical.
Hannah: Great. And I have no idea what's going on. So I spend most of my time asking developers to explain to me what they're talking about. And then on the other side of it, I spend a lot of time asking clients to explain to me what they're talking about. But it's good though, because what it's also taught me is that people who talk a lot and say a lot of big words sometimes, and this is another aspect of it too, is just like being able to listen and knowing when to ask who, what because there is a lot of people who work in higher up positions that use a lot of acronyms and they say a lot of big words. And when you say, oh, what is that?
They can't tell you. You have to be careful with that too though, because if I ask that, if somebody and it's because I need to know it but they don't know the answer sometimes that can then create some dissent within the group of stakeholders, and I'm working with them, make them not want to cooperate.
Because if you ask that question of the wrong person and they don't know the answer, now you've messed with their position of authority within their organization, their business, whatever. So it's an interesting line to walk in the same. Thing's true with the developers actually, too, but usually the developers have an answer and it's the people in the business that don't always have an answer for the questions that I'm asking, because they're so simple.
Ryan: So the last thing I wanted to ask you is just really quickly, what does a day look like? I know you touched on earlier, but like what does from the morning to when you finished with work.
What does a typical day look like? Is there a typical day? And if there is a typical day, what is that?
Hannah: Hmm, I think so within agile there are set meetings. That's a cornerstone of the agile methodology is that you have a daily stand-up meeting, right? So what that means is that every day a normal world, when you're all in the same place, you would be physically standing up.
The reason for this is that people don't talk too long in the meetings, right? You don't sit down. You're not allowed to have a chair because they need you to say. Say your crap and then leave right. And go back to your work. So in the mornings I have two stand-ups for two projects that I'm working on.
I attend each standup and then. And then usually I have a couple meetings with clients, or I have a couple of meetings with development team. I have a couple meetings where I will attend a meeting of the business or organization I'm working with so that I can get a better understanding of what they're doing so if they have reoccurring meetings, I attend those meetings too. So I have some background about what's going on. And then usually after that, I have a meeting with one of the senior team members. So the. I can tell them, all right, this is what's going on with this, with this, with this. And then usually I'll have a meeting with somebody from another projects, like later in the afternoon.
But other than that in between those meetings, I'll do work that comes up during those meetings. I'll also look at JIRA, which is our project management software and I will make comments on things that I've done or I'll send messages to people to say, oh, Hey, I'm just, this came up in this meeting.
I'm following up about this. I'm curious about this. If I have a question about something specific, I'll sometimes get on the phone with one of the senior developers for a minute and ask them a question and then if they need something from me. So I've been working with a developer on one of the projects and it also depends on the schedule of the people you work with.
Sometimes I'll have like just solid booked meetings up until like one o'clock in the afternoon. Like from from eight o'clock in the morning to one o'clock in the afternoon, and then it's just random work from then on. And I usually do my work later in the afternoon because I don't have meetings.
And then if I'm working with a developer that works later in the day, sometimes they'll call me and be like, oh, Hey, Hey, I need you to look at, I'm doing this based on this thing that you did how does this look. And I'll say, okay, it looks like this, blah, blah, blah. Here's my feedback.
And they say, okay, great. And then they go back and do whatever and then same thing the next day. Yeah, that's pretty much how it looks.
Ryan: Right on. So I think that that's pretty much it for today. Just a glimpse into what an IT business analyst does. I mean, that was just as much for me to know what you do as much as anybody else really
Hannah: Well, thanks for, thanks for listening to me.
Thanks for being curious. Keep being curious, keep asking questions. Yeah. So if you are curious folks about how this works, how I did this, how you can do this and how you can get a job without a degree by doing this. Please check out our guide. It's on our website, worked really hard to make this thing so that you can do exactly what I did.
Figure out how to study for certifications, how to find jobs, how to apply just so much stuff in that guide. That's really, really useful if you're trying to make a similar transition to what I did. And that's on the website it's degreefreenetwork.com. And then also make sure to like, and subscribe because you do not want to miss any of this action.
Ryan: Yeah, definitely. Yeah, I guys, if you guys have any questions, comments drop us an email [email protected]. If you guys want to support the show, one of the best things that you could do is you guys could consider leaving us a review anywhere you get your podcasts, apple podcasts, or wherever.
Liking us on YouTube just really helps get the message out there really helps to gain exposure. I think that's it until next time guys, Aloha.
Our free weekly newsletter gives you everything you need to know to find work and get paid!