There is a thin line difference in the objectives between the two roles. Project management is more about the project and business analysis is more about the product. The project manager’s role is to meet the project objectives. The BA’s role is to help organizations reach their goals by recommending value-added solutions that solve business problems. This is a subtle but important difference. In other words, the project objectives help the organization meet its business goals and objectives. The PM focuses on the former; the BA on the latter.
I mentioned that the PM typically focuses on the project, including resolving issues about the project, managing project risks, and getting the resources working on activities and tasks. And that the BA typically focuses on the end product, like managing risks related to the product, eliciting questions about a new product, and specifying the details of the product so that it can be developed and delivered.
Although the Project Manager may do some work related to the product and the BA may do work related to the project, there is still a need, I think, for both roles on most projects. There is a different focus and different objectives, there is often a pull in opposite directions, especially when both roles report to different organizational functions. Project managers want, among many other things, to deliver the product on time and within budget. Business analysts want to ensure that customers can actually use the product once it has been implemented.
Suggested read: Roles and responsibilities of the project manager
But wait—what about Agile?
With Agile there may or may not be a BA and PM on the team. Our question, then, is can the same person focus on both the product and the delivery of that product at the same time? For the product we mean not just the product backlog, but the details of the features that comprise the backlog. By delivery focus we mean someone to protect the Agile processes and remove roadblocks so the team can move forward. Someone who can develop burn down and burnup charts to know what’s been completed and what’s left to do.
The answer of course is yes, it’s possible to have one person focus on both. While not ideal, it may be necessary when there are not enough resources to have a dedicated product owner and scrum master.
It would take someone with the skills to specify the features in enough details so they can be estimated and built, like a product owner—if, and this is a critical constraint—they are authorized to make business decisions. But someone who also focuses on the delivery of the features. This can work in small organizations and on small projects. It can even work in larger organizations when the organization needs to “make do” with less than an ideal number and types of resources. And although there are inherent risks with this approach, it can work.
Let’s look at a real example. A small organization used an outside IT resource to develop a product and a member of the management team to be the product owner. This manager not only was able to make business decisions, but also had both a BA and a development background. The features were developed “agily” and were scheduled to be delivered every few weeks. The acting product owner and developer worked through complex design issues and the features were implemented almost flawlessly. So far so good.
The difficulty was that although the PO and developer worked together superbly on the product features, there was no one looking after the delivery of those features. There was no one, in other words, to support or protect an Agile process. There were occasional Scrum meetings, but no daily meetings to review status and issues. The progress was not routinely monitored, and weeks would go by with no results delivered and no clear idea of when the next feature would be released. There were no retrospectives and not many reviews of the features with other key stakeholders. Because this was a small company and everyone was doing a million other tasks, this process more or less worked. But the lack of focus on the project proved frustrating for almost everyone involved.
Finally, I want to emphasize again that we’re talking about focus, not job titles. We’re talking about someone who not only has the skills to focus on both the project and product, but the time. So even on Agile projects, can the same person be both a BA and a PM, that is, be able to focus on both the product features and the delivery of those features? Sure, but when the main focus is the product, the delivery might suffer and vice versa. On projects of any size, there is less risk when these job functions are separated.