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.
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.
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.
|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.|
|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.
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.
|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.
- 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.
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.
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.
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.
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:
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.
- 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.
You: I want to go on a BA certification course.
You: Because I want to become a BA.
You: Because I like projects.
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.
About this post
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.