You’re a Business Analyst and didn’t even know it

How To's
I’ve got a good friend that works in back office operations at a bank who performs activities that a typical business analyst does, but because of his title, does not receive the respect and money of a standard BA.
Dude, you’re a business analyst without even knowing it. This post is dedicated to you. Hopefully by the end of it, I can point out the symmetries between your role in operations and the role of a BA.

Note: My good friend has been in operations for x number of years now and throughout that time, he has been the go-to process champion within operations. Whenever there’s a project that needs a subject matter expert (SME) in the domain, they extract the knowledge from him. Whenever there’s an ad-hoc request to do some type of analysis because of production issue, then the work lands on his desk. So by and large, he has had project exposure and knows the system and processes inside-out. He exercises a lot of similar skills that a typical BA performs without even knowing it.

This may help other folks who are in a similar position that would like to make a leap into the BA world.

When Day-to-Day and Projects world collide

Why projects engage day-to-day operations

When projects engage business units, it’s usually because they are trying to either validate a business case or are in the process of painting the process As Is. Either way, its a win-win for you in your area particularly if you want exposure to projects.

Take note of the questions they ask and do ask them yourself for the output of your meeting. This would usually come in the form of written emails, process flows or requirements document to name a few artefacts. The more formal the document, e.g. a requirements document, the better it is for you as it will help frame the output typically required from the project team.

Study these.

Learn the formal structure, tone and language of the document.

A conversation that would have gone like this:

BA: So how do you guys construct the shape of the yield curve for that structured product?

You: Well we construct that shape by taking the latest Bond Curve Yields every morning from Reuters. This includes the present day price and yields which underpin the product as well as forecast values for the shape of the yield curve.

Might be transformed to the following requirement in Waterfall:

The system must source the price, yields and forecast values from Reuters each morning in order to construct the shape of the yield curve for the structured product.

Or like this in Agile:

As the product system, I want to receive the price, yields and forecast values from Reuters every morning daily, so that I can construct the shape of the yield curve.

In reality, good requirements in the Waterfall world should look something like this:

REQ1: The system must source the price, yields and forecast values from Reuters each morning in order to construct the shape of the yield curve for the structured product.
Importance: Essential
Owner: Product
Driver: The shape of the yield curve is one of the major components for recalculating the structured productMeasurement: The price, yields and forecast values from Reuters have been captured by the product system.

So note the qualities of a good requirement:

REQ1: Atomic, traceable and independent by providing a reference (REQ1). The requirement itself specifies what is needed, by whom and when.
Importance: Importance must always be stated and is also inferred by word ‘must’ for absolutely necessary, ‘should’ for high importance, ‘could’ or ‘may’ for a wishlist item.  Owner: Traceable to an owner.
Driver: States the business driver / asks the question ‘Why?’Measurement:Verifiable and testable.

You can go ballistic and knock yourself out by reading ‘qualities of good requirements’ — but in your case, the above is a good enough start.

What do projects do?

I’ve already alluded to these above but quite simply, they introduce change. Changes can either be driven by a change in regulation or either by a growth or cost-saving initiative.

To reiterate, projects:

  • document the As Is process
  • document the Future state
  • present the Gaps in the above and have a steps to close action plan.

After the last point, there’s usually a walkthrough with all business stakeholders and subject matter experts in order to formally accept what is documented. Do try to get yourself into one of these meetings and observed how your expertise magically made its way into this formal setting.

What happens after the requirements have been signed off?

There’s usually some detailed functional and non-functional specs written, then there’s some technical specs and actual development that goes around, and then there’s a whole round of testing from unit, to system and a whole bunch of other tests before it culminates in UAT.

And this is when you come in.

Put your hands up for UAT and Business PIV

The business will usually engage you once again when it comes to UAT and Business PIR (Post Implementation Review). Seize the opportunity and raise your hand for this. This is great for your career as you can pocket these in your CV and count it as experience.

And don’t ever forget the power of a smile and a can-do attitude. This will take you far in the game.

1000 different ways of documenting

There are so many ways to write any of the above and there are so many standards that a project can chose to follow. The most important thing based on my experience has always been this: “will the readers of the document understand what I am documenting?

You can create the most elaborate map in the world or impress a few with your wordsmithing prowess, but if people cannot digest your document in one read, then you probably failed to perform a core function of translating the problem.

You have nothing if you don’t have buy in. So here’s a helpful trick: Find out how people like receiving information and use their own language.

For example if you’re dealing with traders, then perhaps they like consuming artefacts based on spreadsheets. Let’s not make it hard for them then and let’s swing into buy-in mode by doing something like this:

An example of one group of stakeholders might like to see

An example of one group of stakeholders might like to see

Traders use spreadsheets all day so it’s probably a good idea to give them something they can play around with.

If need be, you can attach this to your requirements document.

And when you do walk this through or meet up with them, use their language but be sure to define these somewhere in your document e.g. zero coupon and duration etc.

But the point here is that it’s far simpler to speak the same language as your stakeholders and provide them with the same material they’re used to, as opposed to sending them something to review that’s completely foreign.

You are The Master

Using the framework above, you should now practice this entire process yourself using your own knowledge of how things work as basis to write requirements, business rules and process flows.

Theory is nice and it looks simple enough, but there’s no replacing repetitive practice.

Here are a couple of other items that might help you:

  • The System Development Life Cycle Wiki read.
  • Always remember the basics: ‘What is the problem, What is the solution and What are the steps to close that gap’.
  • Think of a process in terms of Inputs > Process > Outputs.
  • Inputs / Outputs are pieces of information (data) either pushed or pulled by the system.
  • The System in this context could be a set of processes by some software,or could also be a set of processes between business units i.e. people. It may even be a combination of both.
  • A Process, outside having inputs and outputs, is composed of one or many functions, may contain one or many pieces of data and may have one or many rules applied on the data.
  • Empathize and cater for how your stakeholders like receiving information. Some might want to read details, some might diagrams and flows in Keynote / Powerpoint / Visio etc. and some might even like a mix of the all the above.

And another key thing that good BA’s do is they always ask WHY until you get down to the very reason why they want something. This reason can change how the solution is put together, for example:

You: I want to go on a BA certification course.

Manager: Why?

You: Because I want to become a BA.

Manager: Why?

You: Because I like projects.

Manager: Why?

You: Because I am quite interested in how projects are delivered end-to-end.

Manager: Fine. What about I’ll put you up for that certificate and include you in more projects when they start so that you can ride the end-to-end cycle.


At the time of writing, my friend still owes me some real life examples of his work in operations that are project-related. I wanted to take those dot points and immediately map them to what Business Analysts do.

There might be a followup piece to this, depending on what he comes back with.

Yoda to Luke — I am waiting to lift your X-wing fighter off the ground. Where are you young Jedi?

About this post

PC halved

This post first appeared in Medium and has been published here for completeness.

I have now been given a dot point list of activities by my friend on what he does in Operations. My next challenge is to convert these activities into the project world to help him make the transition (from Operations to Projects). There might be a follow up soon.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s