Disclaimer: The writer is not an expert so take the things written here with a grain of salt. Also, images you will find in this post were all found in Google, the business analyst and system development jokes are from Dilbert and ModernAnalyst.

You’re probably not a Business Analyst yet here you are trying to read as much as you can about Business Analysis because your boss told you this morning that you will be taking the mantle a week later.

Or maybe, you are one of those who typed “a lucrative job, working in front of the computer 8 hours a day” and the search engine included Business Analysis in the results. Sounds too good to be true? You are probably thinking that these job listing sites are lying to you and they are not transparent with the stress the job entails.

Was I spot on?

Naturally.

Otherwise, you wouldn’t see this post among the ones already available in Google. Yet, here you are because, certainly, you’re thinking, “I can’t be the only non-techie who’s supposed to work as a BA next week!” 

I can’t promise that this post will be your redemption but that’s not stopping us from entertaining ourselves even just a little bit, right? So what do you, a non-techie, have to do as a Business Analyst?

Prepare yourself for immense documentation.

You can’t shy away from documentation. It’s your greatest ally. When it is down to the letter, it can be your friend. When it is vague, it may be your worst nightmare.

I have said it before—I don’t trust my memory—I don’t have an Eidetic one like Sheldon from the Big Bang Theory.

My brain like any others categorizes information and puts them in different vaults to be retrieved later and it also discards those it thinks aren’t necessary to ponder. With that said—I can’t trust it nor can I trust someone else’s particularly when things they remember change all the time. Do you see where I’m going with this? I hope so. Start with the following tools:

• Meeting Minutes (follow the template that makes sense to you)
• Use Cases
• Workflows
• User Story
• Requirements Matrix

Train yourself to negotiate.

Sounds easy?

Unless charm is one of your assets, negotiating deadlines and requirements is not easy.

With your clients

It will help if you have documents showing the prioritization of requirements and their dependencies. Here’s the thing: your stakeholders might have different requirements that they think they need but actually don’t and requirements they think they don’t need but actually do. This is the BA’s playground. As the person who takes these requirements and delivers them to the developers, you need to distinguish which is which.

With your Project Manager

I’m saying this not only with clients in mind. As a BA, you need to negotiate with your Project Manager and Developers regarding timelines and releases while still making your clients, the Stakeholders, happy.

Having a stable relationship with your Project Manager could also do wonders. Note: stable. Find equilibrium by discussing how the both of you can attack or manage a project.

What has worked for me and still does is discussing with my Project Manager how we will handle projects, communication plan, documentation and meetings. You will find particularly in the beginning how thin the line is between a PM and a BA and knowing what your scope is helps you stick to it better. For example, in meetings, both of my PM and I take notes and collaborate in creating meeting minutes and project status reports depending on our availability. Informing her that I need someone who is into details more than I am also helps. This way, she tells me when things are awry because of confusing details in my user story and I can reassess them.

Notice that I didn’t require a project manager who’d easily agree with me. PMs are not supposed to readily accept project requirements, workflows, and changes. Neither are they supposed to reject all of your proposals on how things must be done. They are there to provide check and balance. Remember that it is not always rainbows and butterflies. Most often than not you’ll bounce ideas off each other but clarification must always be your goal.

When you have a stable relationship with your Project Manager, it will be easier to create different combinations of “to be delivered” and “to be deferred.” One thing I learned: thou shall not go straight to the developers when the PM is around.  

Recognize that as the system improves, so should you.

As in any job, you can only use the excuse “this is not my major” for so long. There are several free open sources for BA and online courses now have free or paid certification. Surely, if you’re seriously thinking of doing a good job, devoting an hour per week to online BA courses won’t take a big chunk of your Netflix time, right? Apart from taking courses you can also:

1. Learn the language of your PM and Developers. It helps that you understand no matter how shallow what a system architecture is and how it is created. Trust is built when people speak the same language and you will save yourself from confusion during future discussions with your project team. It’s not different from watching foreign dramas with subtitles. You aren’t sure if the translations are accurate but you don’t mind that as long as you can get the gist of what is happening on screen.
2. Use more techniques in harvesting requirements before the project development. An interview is not the be-all and end-all of things. Review policies, create workflows, and come up good questionnaires. From the stakeholders’ responses, build your documentation framework. Thank me–and yourself–later.
3. Read how other software systems have been created. It’s not cheating. Think of it as data gathering—a reference for projects that may come your way. This goes back to item A. When developers and PM realize that you are as heavily invested in the project as they are and willing to learn, they will be easier to work with. Hopefully. When you begin to understand how a system is created, planning your next one will be a breeze – I’m pulling your leg but I’m serious in telling you it pays to think in advance even when people tell you not to.

As a non-techie, you’ve got your work cut out for you. There’s something that you can do about and it is not whining. Get yourself a copy of the BABOK Guide and get cracking.