In your career as a Business Analyst, you will have the wonderful opportunity to work in many different environments with each new project. It can be intimidating at first because part of your ramp up time can be spent trying to figure out your exact role on the project. As our role is not always cut and dry, I have found that our working environments influence our roles as BA’s on a project. I started my career as a software developer in 2000 for a number of smaller companies, and then slowly evolved into a full-time Business Analyst with some larger companies. I now work as an IT Business Analyst Consultant.
With each new project, I find myself continuously referencing experiences from the following environments:
- Organization with no BA Role defined
- BA on a project outside of the IT Organization
- BA working within a dedicated BA Group
Organization with no BA Role defined
I have worked within smaller IT Departments where the role of a true IT Business Analyst was not defined. Looking back, the biggest observation is that there was always someone performing the role of Business Analyst. When I was a software developer early in my career, it was the Project Manager who would interact with the client and bring back the specs for us to implement. Sometimes, I would find myself asking clarifying questions to get to the root of the problem that we were trying to solve. I was trying to determine the true requirement. Once I had the answers to my questions, the specs would be adjusted accordingly. In this situation, you will almost always find yourself wearing many different hats as Developer, Tester, Business Analyst, or Project Manager. This is always true for a full-time Business Analyst, regardless of the size of the organization they are working in. In addition to gathering requirements, I have written test cases, managed a project, and even written a little code when necessary for numerous projects. In this situation, extra emphasis needs to be placed on keeping track of your deliverables and ensuring that they are complete.
BA on a project outside of the IT Organization
Another working environment is a project that is handled outside of the IT Organization. This happens when the Business has an urgent need which the IT group is unable to resource at the time. The first time I was a Business Analyst on a project without IT governance, it did feel a bit stressful because I did not feel like we were planning for a good long-term solution. My initial instinct was to hold back and to try to instill some order or process around what we were trying to achieve. After all, this is counter-intuitive to the traditional roles and responsibilities of a Business Analyst, but the business’s goal is a quick short-term solution. It is important to keep in mind that there will be many iterations. Ideas may be implemented and scratched, but it is important to keep the momentum going. In these types of projects, it is always key to keep comparing the solution to the project charter to prevent scope creep. A Business Analyst’s role is critical here. If you do come into such a project as a consultant or a contractor, it is important for yourself and the Project Manager to constantly gauge progress and adjust
accordingly. I have found that a lot of short-term solutions will become long-term solutions in the end, so it is best to try and document good solid requirements as you get closer to the end of the project. This way, when the IT group does inherit this project, they have a reference document to start with.
BA working within a dedicated BA Group
The last environment that I will discuss is a Role within an independent BA Group. If you are a member of such a group as an employee, then this is ideal because there are good structures and standards for the deliverables. This structure ensures that good, solid requirements are produced and documented because this is the main deliverable for the organization. If the project is deprioritized, then the organization will have a document to refer back to if the project is ever reinitiated. As a consultant, this is also a great environment to work in. I have had the opportunity to mentor different groups, but it is also a great opportunity for me to learn from the client processes as well. The only challenge that I see in this environment is that there is an extra effort involved in keeping engaged with both the IT Organization and the Business Organization. Neglecting the Business relationship results in requirements that do not meet business need, while removing IT from the relationship results in requirements that are not implementable. As a consultant, it is important to always remember the standards of the BA Group as they may have a defined list of deliverables that you will be responsible for (e.g. Requirements in a particular format, requirements entered into a particular software system, Non-Functional Requirements, etc.) It is always important to respect the standards of this group. Just remember that your method for eliciting requirements will always have your own personal touch.
Conclusion - Be Ready for Anything and then Be Clear About Your Roles and Responsibilities
As Business Analysts, we struggle determining our exact role as we move from one project to the next. In my 15 years in the IT Industry, I have found that the working environment you are in has a huge influence on your role. You may sometimes be asked to elicit requirements only, or you may also be asked to Test, Analyze Data, or even debug some code yourself! As a consultant, I would advise that you determine and communicate exactly what your roles and responsibilities may be depending on the project description and environment. If there is no dedicated testing team, then plan on testing. If your technical team will not be on site with you at project initiation, then plan on helping out with some of the technical discovery work to help get them started. I hope that some of my experiences listed here can help you on your next project. Good Luck BA’s!