fbpx

PM VS. BA PART 1: SUBTLE DIFFERENCES BETWEEN THE TWO

Is there a difference between the roles of project managers and business analysts and what is it? We are considering the roles in the context of the “classical” structure of software development teams. Also, pay attention to the word “roles”—in your team, they can be called “pink elephants”—the essence of the tasks and areas of responsibility will not change. More so, in “skillful” hands, the microscope can be used as a hammer. However, there are no guarantees that the nail completely enters the surface and the microscope remains intact. The reasons to read this are the “fun” candidates who come to interviews to apply for a position of “PM or BA, I don’t care at all” and equally “fun” resource managers, plugging vacant team positions with “universal PM/BA,” preferably part-time.

 

Let’s define the terms first. Take, for example, a car maintenance service. “Firm X” has a team of professionals, and there is a clear separation of the roles within, not the “multi-tool” Mike from the garage. In addition to maintenance specialists (read: developers) and other professionals involved at certain stages of the process, a consultant may also be present. They range from a “pretty face who can fix issues on paper” to “an expert in a specific car model.” The person in this role will listen to clients, understand their pain, suggest a solution, carefully write down instructions, and go to the repairmen to explain to them what to fix. This is a business analyst. Often there is also a person who holds the whip and ensures that maintenance specialists have the necessary equipment and motivation and that they fit the timeline, etc. This person probably influenced the fact that the consultant called you back and called on time. This is the project manager.

What the Standards Say (PMBOK and BABOK)

A Business Analyst is a specialist who uses business methods to analyze the needs of organizations to identify business problems and suggest solutions. Translation: a person who understands what is wrong with your project and what you want. Additionally, he or she can also explain to the team what you need, how to do it, and how to do it well.

A Project Manager is a specialist who uses project management techniques to ensure that project activities meet design requirements. Translation: a person who performs magic so that the clients’ great design is carried out within the agreed time, price, and level of quality.

 

Areas of Responsibility and Focus (aka knowledge areas) According to PMBOK and BABOK

Business Analyst:

  • Business Analysis Planning and Monitoring – plans your future work within the project and constantly monitor the fact that it is being done
  • Enterprise Analysis – examines you, understands your problems and their potential solutions.
  • Requirements Elicitation – understands in detail what you would like to receive within the chosen solution
  • Requirements Analysis – comprehends at your leisure information received from you.
  • Requirements Management and Communication – writes down the formulated essence of the decision, conveys to you and the performers and prevents you from cramming “just one more small thing” into the agreed money/timeframe.
  • Solution Assessment and Validation – chooses the best solution at the stage of their comparison, estimates whether it is suitable in your situation, and subsequently examines and evaluates how much it helps you.

Project Manager:

  • Project Integration Management – overall planning and project management.
  • Project Scope Management – ensures that according to your decision, only the proper and necessary work is being done.
  • Project Time Management – ensures that everything fits in time.
  • Project Cost Management – keeps track of the allocated budget.
  • Project Quality Management – monitors the quality of work and ensures an appropriate level of quality solutions.
  • Project Human Resource Management – recruits people into a team, train, closely monitors each—in general, everything related to a key project resource – people.
  • Project Communications Management – determines who and with whom communicates on the project, whether they communicate correctly, whether the necessary information and whether it is disseminated on time—everything related to the exchange of project information.
  • Project Risk Management – thinks hard about what could “suddenly” go wrong and how to deal with it.
  • Project Procurement Management – provides the team with everything needed from the outside—tables, chairs, cookies, computers, etc.
  • Project Stakeholders Management – understands who has any relation to the project from any side, how they can “spoil” and carefully manage them so that the project goes as conceived.

 

Here are the points where the divide may not look as clear as we would like:

  • Scope management. This terrible word “scope” appears in a detailed description of the duties of both roles. The trick is that the BA is in for the solution scope (“why are you imparting this function to the system’s scopes—this will most likely require a revision of the design parameters—I’ll check with the PM”), and the PM is in for the project scope (boundaries of the project, how the price/terms will change, what risks will arise, etc.).
  • Communication plan. Both, one way or another, are related to thinking through a communication plan with stakeholders. The stakeholders and clients are in the areas of responsibility of both roles, so they should be engaged in this task together.

 

Key Soft Skills Needed by Both These Roles

I do not specifically focus on professional knowledge and skills (for example, for a BA, it could be technical writing, visual modeling, prototyping of user interfaces, knowledge of techniques and processes of working with requirements, etc.), because they, as follows from the areas of knowledge above, are radically different. However, general requirements for both are:

  • Communication skills
  • Learning ability
  • Effective management skills
  • Resistance to stress

Sometimes this leads to disputes over whether it is worth separating these two roles altogether. Everything else in the duties of a PM and BA is as far apart as, for example, writing a specification and writing source code. So, why are people still trying to equate, interchange, and combine these roles? I can only assume the following:

  1. If we conditionally divide the entire team into those who are able/willing to communicate and those who do not, then the PM and BA will occupy the entire first category.
  2. The BA as a key carrier of knowledge about the solution: he/she is actively involved in the formulation of problems and can do it independently, even though in essence solving these issues is the work of the PM.
  3. The PM and BA are both “far away” from “building” the product and a little closer to the customer than other roles.

 

Why is it Important to Define and Divide These Roles?

Project productivity is probably the most important reason why it is critical to define the project roles clearly. When you are working on a small project with the short timeframe, it is easy to mix up the responsibilities of business analysts and project managers and still achieve a good result.

 

However, when you start looking at larger projects, you soon realize that without clearly-defined roles and responsibilities in the team, you will never deliver a successful outcome. If you don’t have clear project roles and responsibilities in a larger-scale environment, you end up having people not knowing where to start or what they are responsible for delivering the results.

 

Professionalism is the other main reason why it is important to define the role of the Business Analyst and Project Managers clearly. Once we look at the responsibilities listed below you will see that each role has a very distinct and clear set of competencies and responsibilities and to mix this up will dilute both these professional roles into something undefined. Business analysts and project managers should primarily be focused on performing their respective roles.

No Comments

Sorry, the comment form is closed at this time.