What’s the difference between an Analyst and a Scribe (Notetaker)?
In this video, I talk about how people who become a business analyst get stuck as a glorified note taker and I talk about some of the characteristics and opportunities a person can take on to become that analyst.
LEARN.BA. The skills you need to perform at your peak B.A. capacity.
What’s the difference between an Analyst and a Scribe (note taker)?
I ask that question because there are some business analysts out there that get stuck in the position of becoming a scribe or a note taker as opposed to actually being an analyst.
That’s what I want to talk about in this video. This is kind of in line with the same theme of whether you’re a senior analyst or more of a junior analyst because when you first start off your career, you’re basically a bit of a note taker until you learn how to do the analysis work and you learn a lot of the key skills that you need to actually become an analyst.
So if you’re just first starting out and you feel like you’re a bit of a note taker that’s OK – the opportunity here is for you is to the step into an endless role by taking on certain characteristics right. And so that’s what we’ll talk about in this video.
Become an Analyst by Taking On These Characteristics:
- So number one I want to talk about what it means to take ownership of the solution because if you want to switch from becoming a glorified note taker into an analyst you have to learn how to take ownership of the design of the solution or the product that’s being built.
- Number two I want to talk about some of the basic skills that it’s going to take for you to be able to do that. Namely, it’s going to be your ability to do a very quick cost-benefit analysis on certain things that the business will request.
- Number three you have to master the art of what I like to call Disagree and Commit.
I’ve written a whole article on this idea of disagreeing and commit but this is an art form in a lot of ways that enables you to give constructive resistance, is what I like to call it.
1 | Ownership
So as an analyst you’re in a very tough position because you don’t really have any authority. You’re not a decision maker right.
There is the management of the company are the people in the company that decide how to allocate the company’s resources and they’re the ones that decide what happens what they’re going to put money towards and what doesn’t happen right. Your job as an analyst is not to do any of that. Your job as an analyst is to help management facilitate those decisions by providing them with the information that they need.
So for example, if they’re trying to decide what kind of a product they’re going to build and they want to allocate some funds towards a project, it’s your job to help them figure out how to implement that project, what a solution might possibly look like, what kind of options they have if they want to try to solve a certain problem right.
But what you don’t have is you don’t have any authority on major decisions.
It puts you in a bit of a tight spot because if you want to try to achieve the first thing I want to talk about which is product ownership or owning the solution if you want to try to achieve that to try to step into a more senior role you’re gonna be in a very tough spot because you don’t have any authority but you’re trying to take ownership of the direction of a certain product right. And so the way that you do that is number one is that you have to be very good or you have to get very good inside your own environment at making very quick cost-benefit judgments.
So for example, if your stakeholder says hey we want you to build this piece of functionality into the solution.
There are two things you need to know you have to very quickly be able to calculate how much is that feature going to roughly how much work is going to take for the project to implement that. And number two what is the business benefit of us.
If we want to implement something like that you have to end this a lot of times is more but more of a gut feel then. I mean you don’t go through a long drawn out process to try to generate numbers to figure out what the cost benefit of something like that is because in a project you have so many of those things popping up that you have to really kind of make that judgment call based on your gut feel and then try to figure out the rationale for the position you want to take.
So just to give you a perfect example if a client says to me we need a feature in our product that is let’s say going to take a week to do the analysis on it’s going to take us three weeks to build it and then another two weeks to do Q A on this on this functionality as soon as the person asked that question.
I have to be experienced enough and I have to know enough about our development environment and about the company in general about how we function to be able to size that up very quickly. So I say to myself, Well, roughly speaking compared to everything else that we’re building this is either medium size or a large size piece of work or a feature that you’re asking for. And so we really have to make sure that the thing that you’re asking for is actually going to have the business benefit that you’re expecting because if it’s a feature that’s unlikely to get used very often it’s one of those features that just gets built in and nobody ever uses it.
You have to make sure that you make it clear that you will recommend not to build that feature in and for the project to actually start to build a workaround to figure out how the business can solve that problem without building in the feature.
Right. So no one is taking ownership and that’s part of what it means to take ownership. That’s when you start to take ownership of the product. You start to give a lot more constructive feedback into the process of what gets built and what does not get built right.
And so you’re not taking full product ownership, you’re not taking on the role of a full product owner, but whoever the product owner is inside your company – you’re giving them a lot more – a lot of constructive input that they need to be able to make the right decision. And so to be able to provide that constructive input.
So you do the cost-benefit very quickly and you establish your own position on that issue.
2 | Cost-Benefit Analysis
So you say either we feel like we should build it and because of the benefit that it provides to the business and the fact that the tradeoff of building it putting in the time and effort to build it and it’s worth it you take that position or you take a position where you say you know what. I understand that you really strongly want this thing but I have to challenge you on whether this is actually worth for the project to build in. Right.
And again as an analyst, it is a very you’re in a tight spot when you’re taking on that obligation. Right. Because you don’t have any decision making authority and you don’t have the ability to control any of the resources that the project might have or that any of the management might have. But you’re still taking on the risk of-of taking a stance on a subject that you feel strongly about.
So you take ownership and you do it by doing a very quick cost-benefit analysis and then kind of establishing enough of a backbone to be able to back your position on the on those types of questions that pop up.
3 | Disagree and Commit Policy
The last piece of the puzzle here is really for you to be able to do this effectively – This is a bit of a policy – that I have but you have to master the art of what I like to call disagree and commit.
I want to spend the last couple of minutes explaining to you what that means. So because of the fact that you don’t have any decision making authority and you have a strong opinion on whether something is in or out the policy of disagreeing commit helps you to do that in a very effective way. OK.
In a constructive and effective way that doesn’t create any kind of conflict in your organization and it makes it so that the ideas that you’re putting forth have some credibility to them.
And so the policy of disagreement and commit is as follows. There’s a certain point at which your opinion matters and then a point at which you have the professional obligation to implement, regardless of whether your suggestion was taken into account or not. Right.
So this is a green commit. Works like follows. There’s a certain period of time under which you have to work hard to lobby for your position. So you say you know what I really disagree with us moving forward on dates for reasons X Y and Z and I feel obligated to express my opinion for this because I don’t think it’s the best decision for us to make.
And you’re lobbying this against people who might be holding the counter position so the person who’s asked for the feature, for example, might say no you really have to build it in and you have to really kind of hold strong in your position if you really believe that that’s the right thing to do.
But there’s a point at which you are not professionally obligated to implement whatever decision has been made.
So even if let’s say the project manager or the project leadership group or the steering committee of your project has decided that they’re going to go against your recommendation, Right at that point you switch from being a person who has a strong opinion to a person who now implements one with 100 percent of their effort based on the decision that was made by management. Right.
And so I have a full article on this on the website LEARN.BA. I’ll link it below. I would suggest that you go ahead and read that.
Think about ways that you can start to get yourself into a more senior role by doing things like this – taking a bit of ownership or giving constructive feedback and then finding effective ways of how you can do that without creating a lot of conflict in your organization.