Project Management Central

Please login or join to subscribe to this thread

Topics: Business Analysis/Requirements Management
BA role in Project OBS?

Where does the business analyst role fit into a typical project based organization structure?

In engineering, requirements management is central to the systems engineering role, and whether there is one SE or a team, they fall under the PM as an Engineering Integration job function. Sometimes the PM and SE roles are combined as a Project Engineer, or other terms but the PM is the role responsible for overall project management, and SE manages and integrates the technical plan including requirements management.

Some comments in recent threads involving the BA role have made me question how that fits in compared to a SEBoK framework.
Sort By:

I cannot talk about engineering specifically but I do not see why the BA role would, or should be different in a project-based organization compared to a functional or matrix structure. The core function of the BA I believe remains the same as do their position in the structure. The BA works with the project team as a project team member to deliver solutions (product requirements) with the PM remaining responsible for project requirements.

@Keith, first of all, BA is not related to requirements engineering only. I have discussed this with inside the CMU SEI and with IREB (which have change some thing related to that). BA role scope of work is whole solution, not requirements only. I have participated from "the genesis" of the role and in the very begining that was real including it was a role defined to brid the gap between business and IT so the other misconception is BA is an IT related role. That was changed time after in the defintions but still remains. In fact, because of that, BRM role has emerged trying to modify in the market all that misconception. PM focus on requirements are project requirements BUT not other requirements. SE (if SE mean Sytem Engineering) is about to define components and relations of the whole solution while SWE (software engineer) is to define the same but about software component only. BA is on top of the solution where the solution, as you know, could be composed by components belonging to all enterprise architecture layers.

Addional comment: I am in charge of defining this type of things in my actual work place because I have previous experience on that and I have the opportunity to be part of the groups of authors of some *BOKs. What worked for me is thinking from the point of view of architecture. Obviously, the key success factor is to understand the role definition and responsabilities. For example, some people said that BA and PM overlaps and it is totally wrong. The same some people said from BA and Architect (business, system, software architects) which is totally wrong too. When you analyze the focus each role must keep the dference is there. With that said, is good to say that all are roles and the same person can perform more than one role at the time as much of us do (while is not recommendable becuase the skills are totally diferent too).

When it comes to the OBS, there are lots of issues out there. generally, I support Sergio's idea.

It sounds like you're follow the enterprise architecture TOGAF standards in which the SEBOK would apply and it doesn't define a BA. It defines mission analysis focused on the solution but also focuses on stakeholders needs and requirements. Other standards and orgs SDLC for software development would define role/need for BA.

Thank you all for the inputs. I think Sergio spoke to the root of my question very well. Requirements management is done at multiple levels and by different job roles. Those job roles may or may not be done by different people and role clarity can be challenging for those who are in project-aligned job functions in a large matrix organization. It's something that can be easy to draw on an organization chart, while the day-to-day responsibilities can be more complicated when considering how the theoretical roles fit with an organization's business processes.

I'll have to read more on the details of the BA role. Working in a very requirements focused field, how they are managed is both an important and fascinating topic to me.

Please login or join to reply

Content ID:

"In youth we learn; in age we understand."

- Marie von Ebner-Eschenbach