BA vs PM

BA vs. PM: Where Do We Draw the Line?

Mark Mullaly

So many acronyms, so little time…

We abbreviate to expedite talking about something that is long, complicated or that we talk about frequently. So project managers become PMs. Steering committees become SCs. Project Management Offices become PMOs. Information Technology becomes IT (and begets hundreds of other mind-numbing acronyms in the process). And Business Analysts have become BAs.

In the last few years, we’ve seen a rise in awareness, visibility and formality associated with business analysis. At the same time, there’s been an increasing intersection between business analysis and project management. The two concepts show up in the same conversations. They get talked about in the same meetings. The two roles are sometimes performed by the same people. And members of each community crash each other’s events.

All of this can leave people scratching their heads and wondering what it all means? Where are the overlaps? Where are the boundaries? What are the divisions? What does it mean to be a business analyst relative to what it means to being a project manager? When would I want one over the other ? And is there any value to being both?

The alignment between business analysis and project management is relatively unsurprising, given the emphasis that both play on understanding and managing stakeholder expectations and requirements. In fact, there is a great deal of overlap between the two disciplines at the outset. And that overlap has been progressively becoming more blurred as each discipline evolves the interpretation of what it actually does.

In the world of project management, the management (and satisfaction!) of stakeholder expectations has become a progressively important thing. Theoretically, it’s always been there, of course, but now it has become more formalized. In the last update of A Guide to the Project Management Body of Knowledge (PMBOK® Guide), for example, stakeholder management became the first new knowledge area in—well—forever. This accompanied a growing expectation on understanding stakeholders, evaluating their interests and influence, and assessing their requirements of the project. Successful delivery to requirements—and successful management of stakeholder engagement and satisfaction—is now a critical emphasis.

Business analysis, on the other hand, has always emphasized requirements definition and management. A core area of emphasis for the business analyst is also effectively engaging with stakeholders to understand their needs and interests, assess their current capabilities and gaps, and articulate the requirements that are to be addressed in delivering an effective solution. In fact, requirements in all their forms—of the business, of stakeholders, of solutions and of transition and outcomes—is central to how business analysis is formally defined.

All well and good, and theoretically all very overlapping. And yet, while both business analysis and project management start with an understanding of stakeholders and requirements—and really, so should any effective solution—they take things in very different directions. This is arguably where the lines get blurred and the interpretations get fuzzy. While the up-front language is very similar, the subsequent steps and stages are not.

Project managers focus on requirements in order to establish the nature of the project they need to deliver. In the overall project continuum, stakeholder requirements lead to objectives, which leads to scope, which leads to project results. What stakeholder interests, influence and requirements ultimately shape is the definition of the outcomes and impacts that projects must support.

Business analysts also emphasize requirements, as we’ve identified. The purpose of requirements in this context, however, is in supporting the design of the end result. Traditionally, business analysis focusses primarily on information technology solutions and—to a lesser extent—the business processes on which technology products are based. The business analysis continuum is that stakeholder requirements lead to process understanding, which leads to solution design, which leads to operational changes.

If these definitions sound suspiciously like they overlap some, then you’ll be understanding the genesis of this article. Both disciplines do have a lot in common. They both lead with stakeholders and requirements. They both endeavour to deliver value—and satisfaction—to those self-same stakeholders. They both seek solutions that respond to stakeholder requirements. And they both seek to do so in a project context.

So are there differences? There are, yes…at least to the extent that each discipline is currently defined within its respective body of knowledge. Project management carries on with all of the coordination, management and leadership necessary to bring those outcomes to reality. The work of the business analysis is to design the solution, and to evaluate how well the solution worked, but building and implementation belongs to someone else. The open question is—as each discipline evolves—whether this continues based on where each chooses to go. Currently, the most significant difference is based upon the focus and emphasis of each role.

Project managers lead with projects. In seeking requirements, there is a recognition that both product and project requirements will emerge, and there is appreciation that both of these are important. But the focus of a project manager is essentially on getting the project done well. This means technical delivery to schedule, budget and scope first and foremost, although it also means delivery in the context of outcomes and business value. Managing attainment of both of these largely appears under the umbrella of “execution”—the actual work of getting the project done.

Business analysts, by contrast, lead with the product. Or, in their words, the solution. The emphasis is on what needs to be put in place to deliver concrete business value, and how to design a solution that best delivers on this. Business analysis seeks to understand the process, conduct a gap analysis , assess the required operational outcomes and ultimately evaluate the degree to which these were attained. A project happens around this, yes, but the emphasis for the business analyst is on designing the solution that the project will go and deliver.

It’s still possible to look at these definitions and feel like the distinctions depend upon subtle nuance. To a certain extent both sides are staking the same territory, each with a slightly different emphasis.

This is in large part because there is a biased and blinkered view of how each role is defined within its own discipline. In the world of project managers, for example, “execution” encompasses the full work of getting the project delivered. But how this is done isn’t defined; the presumption is, quite accurately, that there are a number of approaches and “methodologies”—both formal and informal—that define how the work actually gets done.

What project management defines as “execution” is the work that is being conducted.

Business analysts also have a mystical “and then the magic happens” placeholder in the definition of their role. They are extraordinarily active in requirements definition and solution design, and then leap to evaluation of how the solution worked out. While this might stage from prototype to pilot to operational transition, it largely ignores the work that goes into building said solution, as well as coordinating how that work happens.

Neither of these definitions is wrong, per se. It would be woefully presumptuous if project managers or business analysts were to prescribe how the actual work should be done. Not that they don’t have a say from project to project, but to attempt to codify this as part of their respective bodies of knowledge would be foolhardy in the extreme. Comparing the bodies of knowledge side by side also highlights the degree to which each definition is largely ego-centric: they describe what the role does , and the work they are involved with, largely from their own perspective and worldview.

This certainly has some implications in how the roles are defined today, but more so in how the roles evolve going forward. Each of the disciplines—and in particular, the dominant associations that back up each discipline—are seeing and discussing similar challenges. These particularly revolve around direction, definition, governance and oversight in terms of how problems are defined and addressed and the resulting solutions are implemented. The result is that each discipline is expanding its focus to encompass a broader perspective. They are, if you will, moving up the food chain. Both project management and business analysis are placing greater emphasis on strategic alignment, on the definition and quantification of business problems and on the demonstration and realization of strategic value.

Why this evolution is occurring is entirely logical. Nature abhors a vacuum. When details are vague, imprecise, ambiguous or entirely not forthcoming, we naturally seek to impose structure for ourselves. And so project management and business analysis are staking out the domains of strategic management, operations management and benefits realization as ripe for further evolution. The problem is that these domains already exist. There is exceptional—and exemplary—research and practical guidance into how each area can, and should, work to help address real organizational issues. We know what the problems are, we know what doesn’t work and—sadly—we already know what most of the solutions involve. It’s just that the solutions often don’t get put into practice.

The reason that many organizations don’t solve these problems is that they aren’t essentially rational in nature. The problems are often rooted in organizational politics. By incorporating the upfront strategic conversations and downstream operationalization into their bodies of knowledge, associations are trying to define codified means of dealing with the messy, complex, awkward and altogether human challenges associated with introducing change. This ignores the fact that these challenges are the very real and frequently unavoidable result of trying to get things done in a context of power, influence and personal agendas.

Project management and business analysis are both useful practices. They attempt to provide meaningful and relevant guidance to how their respective roles are performed. They also run the risk of myopically seeing the world from their own perspective, and prescribing solutions that conform only to that worldview. This can feel a little bit like, “If the only tool you have is a hammer, then everything starts to look like a nail.” While recognizing the underlying causes of current problems is useful and relevant, it is foolhardy for either discipline to believe that it can solve those problems in isolation. But if we look at the trends in terms of how various bodies of knowledge are evolving, that is just what they are trying to do.

Project management and business analysis would both do well to step back and be clear about the roles they play, the problems that they are trying to solve within those roles and where boundaries on each role exists. As we've already noted, each discipline has an existential gap around how the work of the project actually gets done, and that this is a reasonable thing; we’re agnostic on what the process is, we just know there needs to be a process.

Arguably the same flexibility needs to also exist around how strategic choices to do projects get made, and how resulting value of projects is realized and assessed. There are very different options, approaches and degrees of formality that define how this is done. Attempting to prescribe, codify or impose a solution on what is inherently a political and fluid process runs the risk of courting irrelevance. Or at least continuing to unnecessarily blur the boundaries.

Source: PMI


PMI®, PMP®,CAPM®, PMBOK® Guide, PgMP are marks of the Project Management Institute, Inc

copyright©. ProjectPro®. All rights reserved.
Designed by
For technical difficulties e-mail:
Home | e-Zine | Editorial | Project Parade | About Us | Training | News Flash | Library | Links | Calendar | Consulting | PM Services | Training Schedules | Training Registration | Subscribers | Recommend Website | Advertise | Contact Us