The Illusion of Role Overlap – Project Managers & Business Analysts

Recently I taught a class on project management, using PMI-endorsed material provided by a well-known leadership training brand. Last fall, I co-led a presentation with a project manager on the topic of managing the PM/BA relationship. Perhaps we should have titled it, “why can’t project managers and business analysts get along?” because the subtext was all about the friction that occurs when one thinks the other is infringing on their job. I had first-hand experience with the subject already, but teaching the class on project management fundamentals brought it all together for me.

Think of a project like a truck convoy traveling along the highway. The project manager is in a Cessna flying overhead, looking for road hazards (risks), figuring out the path from the air, and calculating whether the convoy will get to the destination on time. The project manager has to stay at the bird’s-eye level because they have to be the one to identify the hazard and figure out how to clear it before the convoy plows into it. Down at ground level, the business analyst is in one of the trucks. Only by working together to identify and mitigate the road hazards will the project manager and business analyst bring the convoy to the destination safely.

Since I’m apparently in a Convoy mood, let me riff on that a moment. Both the business analyst and the project manager are keeping their eyes peeled for risks to the project.  The project manager does it from the bird’s-eye, or strategic view while the BA is deep in the proverbial weeds at ground level. A pilot might be too high in the air to notice a crate of tire-busting nails scattered all over the road, but the truck driver at ground level has an up-close view of clear and present danger. On the other hand, the truck driver’s view of the horizon can only go a short way, whereas the pilot can see that the bridge is out ahead, and the whole caravan could fall in the river if they take the bridge at full speed. Both driver and pilot see dangers, but they see different dangers, based on their relative perspective. Either danger jeopardizes the caravan, and it’s going to take coordination between the driver at ground level and the pilot to keep everyone safe. Likewise, the business analyst sees risks in the details while the PM sees them at the macro level. They must work together to identify the risks and mitigate them, but the project manager is the one calling the shots, so the PM gets the final say on how to address the risks, while the BA makes recommendations.

Business analysts and project managers can clash in requirements elicitation too. Again, it’s a matter of perspective. At the beginning of the project, in the phase PMI refers to as the “Initiate” phase, the project manager identifies the team and wraps his head around the parameters of the project. To do that, the PM gathers high level requirements from key stakeholders. Specifically, they need to understand the business need and what success looks like to the key stakeholders. Business analysts refer to these as business requirements, or statements of the goals, objectives and outcomes that will drive the project, and stakeholder requirements, that define how the key stakeholders define success in achieving the desired outcome.

Note that I said key stakeholder requirements. The project manager is talking to influencers in management who call the shots on the budget. If the project manager is collecting business requirements and key stakeholder requirements, the business analyst has a great basis to build on, but the job’s not done. The project manager may have what they need to write a project charter, but the business analyst has several more detailed layers of requirements to understand.

If the project manager is adept at framing the stakeholder requirements well, the business analyst can document them and move on. The PM had to make a start in gathering requirements at a high level to understand the parameters of the project, but that’s where a handoff should occur and the business analyst builds out additional levels of detail traceable all the way back to the stakeholder and business requirements the project manager identified in their initiation phase.

With examples like these in mind, it’s easier to see how a business analyst or project manager might perceive that her territory is being threatened.  However, instead of a “my job/ your job” mentality, it should be an “our” job attitude, with the business analyst clearly providing the assist and granular level of detail while the project manager is managing the work of the overall team. By working together, rather than at odds, the business analyst and project manager can both shepherd the project effectively, each from their own perspective.

Tamara Copple