The Business Analyst role in IT

If you search the internet for a clear description for the Business Analyst role you will most likely get a ton of answers, some may be confusing, and you might mix it up with some other roles, as I have found people tend to do. For many, the role seems to be unclear and I was often asked during the time I was a BA, “So what is it you do exactly as a BA?”. No, it’s not a person that comes through the door, looks at the CEO and says — Sir after careful consideration of your establishment I‘ve concluded that this indeed is a business.

Jeff Dunham Peanut said it best in this funny sketch (min 2:22):

No, that’s not what a business analyst does. Let’s put it this way — You want to build a bridge. Do you just start buying materials, and start building and hope that the materials you bought are enough so you get to the other side? Do you even get to the other side in the right place? Or maybe you start the bridge from both sides and you think they will meet up in the middle. But chances are that if you didn’t think things through, you will end up with two bridges instead of one, and one may collapse. But do we even need a bridge? Would that make your clients happy?

Business analysis according to the International Institute of Business Analysis is the practice of enabling change in an enterprise by defining needs and recommending solutions that deliver value to stakeholders. Business analysis enables an enterprise to articulate needs and the rationale for change, and to design and describe solutions that deliver value.

Let’s translate that into the responsibilities of a BA:

• He gathers the requirements of a project. They are crucial because without them the development teams would look around at each other counting their toes
• He organizes requirements in a clear, easy to understand way for everyone (especially the business people), and make it visible for anyone at any time. People need to know at all times what the requirements are
• He anticipates and reacts. Now this is something that comes with experience, and separates the great BAs from the average ones. Anticipating what might change, and what needs to be done accordingly is no easy task
• Eliminates implementations that are not worth doing, bottlenecks and always finds the best solution
• He is the keeper of the requirements in the sense that he is constantly maintaining them. Don’t think that after you right some initial requirements, they won’t change. Even after the project is done, he then switches to correcting defects, making enhancements and delivering reports

You need a thorough analysis of everything you do, before you actually start to build things. Forget about work, you need to do that even in your personal life. It’s just common sense. Don’t just go out and take a loan and buy a Porsche, and be surprised at the end of the month your flat broke from the upkeep.

Analyze, think it through, anticipate what might happen and study what’s happening around you. In the IT case I mean study what’s happening in the market, what others are doing, what solutions they are using, and of course most importantly keep in mind what the stakeholders need, and then put into, and this is very important, requirements. Good requirements are crucial before you do anything at all, and I will explain it a little better further in the article.

But before you have requirements, you need information and that means communication. Talk to the people that need your project. Talk to them and make it clear what they want, cause trust me, most of the time they don’t even know whats behind their needs. Or maybe they do, but they need someone to ask the right questions so they get what they actually want.

To cook up a definition of the BA role, the BA is the person who fills the gap between stakeholders and development. He is above all else a good negotiator, and makes sure requirements are in line with what the stakeholders want and need. It might sound easy to do, but it’s not as most of the time business analysts have to deal with reluctant stakeholders, who don’t always share all the information you need, or don’t understand why you’re going a certain way on a project, or why this and that is needed.

The best way to evaluate if a BA is doing a good job is if the requirements are in line with what the stakeholders want. If they are happy, if the project is doing well and was built as planned, if there is transparency in sharing information, then the BA has done his job.

Keeping that idea in mind I wanted just to underline some ideas on how to improve relations with stakeholders:

• Establish clear roles and communication with people. You need to have a clear, concise and standard channel of communication. There’s no clear recipe here, you do it as if fits your company, and it changes based on the people you work with. Information can get lost along the way of there is no clear plan of communication. And it also makes life easier for a BA. For instance when I was a BA I created a clear procedure document that underlines the roles of each member of the project and also made it clear in meetings how the communication would flow. And I just stuck to the plan and it worked.
• Add a little extra to your project and get the stakeholders on your side by doing so. What do I mean? Let’s say you order a car, and it arrives with some extra features you didn’t think could be done. Wouldn’t that be great? Apply that idea to a project. Bring something to the project that improves the final product and gets your stakeholders worked up. But do it with real feasible ideas, not crazy ideas that have no chance of ending up in the final product, because there is a really thin line between excitement and disappointment
• Make project documentation available to all at all times, and make sure it’s centralized in one place. Also make sure it’s clear and easy to understand. No one likes to read long word documents, and the worst thing about communicating information through documents in an email is that information can get lost, or you don’t know what the last version is and nightmares can appear just from that. A good example of a tool to use for documentation is Confluence.
• Keep requirements up to date to gain the stakeholders trust, and make them understand they can rely on you to keep the project on track
• Create a good relationship between the stakeholders and the developers. Why? Do I even have to answer that?

I kept going on about requirements. So what are these requirements. There are two types of requirements:

• Business requirements
• Functional requirements

The two make up a project.

• Business requirements are usually drawn higher up in the company. They define why the business needs to achieve a certain goal for the company. For instance you may want to improve customer satisfaction through faster delivery times by adding extra warehouses
• Now the functional requirements keep in line the business requirements and break them down in steps and what actually needs to be done to achieve that goal. How do we add extra warehouses, how do they appear in our system, what happens in our delivery system and so on. Business set’s the goal, functional draws the how-to plan. The developers need the functional requirements to do their job

How do the two requirements actually look? Any way you want as long as they make sense, are clear for everyone and get the job done.

There is a lot that can be said about the BA role in a company, especially an IT company, but I think it’s safe to say the BA is crucial in a project and if your projects are suffering that’s one of the pieces of the puzzle that needs to be in place.

And if I can offer a piece of advice: If you’re passionate about IT, and would love to start a career in IT, the BA role is a good start. You’d be surprised to know how many doors this role opens up and how much you can learn. For instance I started as a web business analyst, learned a lot about website projects and creating a website from scratch, then I became a business analyst in eMAG for a monitoring application and now I am a Product Owner and my path will continue to go up and up learning more than I could have ever hoped. With each project new challenges arise, and you are pushed to learn new things and you have no choice but to grow. With each project you tackle new things and that’s really cool.

In eMAG we are always looking for a good BA, and more and more business analysts are assigned to projects. If you are interested in such an endeavor check out eMAG’s career page and maybe there is an opening you might take advantage of, and start to write some well needed requirements to help us along our journey of making people happy with their online shopping.