A little while ago, during our weekly Tampa IIBA certification study group meeting (you should join us!), someone asked me whether the business analyst or the project manager makes certain decisions. The specific question had to do with potential guidance on how projects should be implemented, but here I will try to answer the question more generally. (If you’re interested, the question is asked at 38:25 of the video file BABOKStudyGroup20230209.mp4 stored here. Our normal facilitator was out so I guided that week’s session.)
I offered a few answers at the time, but let’s try to analyze it even more completely.
In theory, the project manager and business analyst have different duties. The PM manages the environment in which the work is done and arranges for, tracks, and protects the resources (especially including money and people), while the BA manages the actual analysis and solution process. I touch on this idea here.
The foregoing is true if you’re talking about two practitioners of similar seniority in an organization where those roles are defined clearly. In smaller organizations (for example, where the PM and the most senior BA are the same person), situations where things aren’t well delineated, or where you have people of unequal seniority, the decisions will be made by the most senior member or the one otherwise nominated by senior management or organizational working style. It’s possible that the PM is the most senior and guides most aspects of running engagements. I probably thought this was true through most of my career, and the idea of having people called business analysts is still comparatively new (and given the way things always change, who knows what may be in fashion or what anything may be called in twenty years?). In other cases, a team lead, primary investigator, senior engineer or scientist, or someone else in an analytical role will guide most of the engagement while the project manager stays in the background “counting the beans.” I’ve been that guy, too. The point is that the actual conditions on the ground dictate how things will be done.
Another assumption smuggled into the question is that there is only one BA (“the” PM or “the” BA). In reality, especially depending on the scope and scale of the project, a given effort may involve multiple BAs, and they may specialize in different phases of a project. Junior BAs, in particular, may chiefly be involved in the requirements phase(s), or at least may not be aware of everything that’s going on in the entire scope and life cycle of an engagement. (This is why BAs always seem to be doing such a seemingly wide variety of different things in different contexts if you talk to them. They’re applying a consistent set of skills, but they really are in a wide variety of different situations in different contexts. That’s why the BABOK is written in such a general, non-prescriptive way, and why I emphasize that my framework is extremely flexible.) This is certainly often true of implementation SMEs and testers. There may be multiple PMs, too, but that is more rare, and usually only happens if one is in training or a generalized PMO (Project Management Office) is in place.
External customers may drive the majority of the process based on their own methods, experience, and needs, and only include your BAs and PMs in advisory roles. I once did a discovery and analysis project where a VP from a large customer organization worked hand-in-hand with my consulting company’s senior BA/PM to run the engagement. I’m sure they had at least some discussions about how things should be done before I ever got involved, and I was learning how to be a mid-level analyst and project coordinator at that time. If the customer is internal or if the team is working for itself, decision-making defaults back to the other considerations discussed here.
Sponsors may also have a lot to say about how things are done, and may be involved to varying degrees. This is especially true if they explicitly want to do something a bit different than the organization’s typical m.o..
Every combination and permutation of roles, titles, and methods is possible. Within all that, human nature is always a factor, and humans have wonderful qualities and all manner of foibles. The best thing to shoot for is to operate in the most friendly, cooperative, supportive, customer-helping way possible, aided always by continuous, open communication.