Skip to main content

Birds of a Feather – Project Managers and Business Analysts

I sit down to write this article knowing that my initial proposition is going to cause some debate – even anger – among readers.  Yet, I believe that the point still needs to be discussed, so I am going to take a risk and put these thoughts into writing.

The proposition that I would like to make is that the roles of project manager and business analyst are not very different from each other.  In fact, I’ll even go further than that:  I believe that these roles eventually merge together the higher one rises in either profession.

Now, before you start writing a strongly-worded rebuttal, please take the time to consider these facts:

  • Good project managers and business analysts need to be able to bridge both the business and technology worlds.  In other words, they need to be able to discuss requirements and project approach with the sponsoring stakeholders, while also being able to discuss technical issues with the delivery team.  It doesn’t matter whether the technology is software development, setting up computers, mechanical engineering, graphic design, the mechanics of getting planning approval from a municipality, or the rules and processes around conducting clinical trials for a new drug – these are all technical work of delivery teams working within specific industries.  Both project managers and business analysts need to be able to discuss the project in terms of meeting business requirements to the business stakeholders and in terms of technical processes and functionality to the project delivery team.
  • Both roles spend most of their time communicating requirements, issues, and project status to the internal team and external stakeholders.  Many PMs and BAs that I speak with say that they spend most of their project management time explaining requirements, specifications, and project approach over and over again, sometimes to the same people, in order to ensure that everyone is on the same page.
  • Both roles (especially the more senior practitioners) spend time planning and playing a big role in forming the project delivery strategy.
  • Both roles are concerned with customer (and stakeholder) satisfaction.
  • Both roles are very concerned with understanding and supporting the sponsor’s business case.  That means that both of them care about funding, timelines, key business dates, and other constraints that affect the project.

The above points are more applicable the more senior the practitioner being considered.  For example, a junior project manager, functioning as part of a large project management team, may only be assisting with some aspects of the project management responsibilities on the project or may only be managing a small part of the overall project.  Someone in this role may not be working directly with external project stakeholders or may not have a role in overall project strategy and business case achievement.  However, the more senior a project manager, the more likely it is they will be focusing on these elements, leaving more of the mundane PM tasks to the more junior PMs.  The same rule applies to business analysts, where the more senior BAs have a more strategic role and can work with executive sponsors on optimizing the project delivery strategy to achieve the best business case return.

One thing that I do not want to be misinterpreted, however:  I strongly believe that we still need both professions.  I am NOT advocating that the two roles be merged.  While the work performed by PMs and BAs starts to merge as you move up the career path of the two professions, each brings a different focus to that work.  At the lower levels (the ones doing the bulk of the traditional PM or BA tasks on a project) the difference is most notable and desired; however, one theoretically could have a very senior BA also manage a project, or a senior PM with BA skills lead requirements gathering workshops.  But overall, I think these two different roles should remain separate.

It is interesting to note that there are joint conferences and educational offerings targeted at both professions.  One North American example is the “Business Analyst World” conference that is often combined with “Project World” or “Project Summit” that runs many times a year in cities across Canada and the U.S.A.  The continuing education departments of universities and community colleges offer courses such as “Project Management for Business Analysts” and “Introduction to Requirements Management for Project Managers” that target those who need to blend skill sets at higher career levels.

Even the very popular Lessons from History series of books bridges both of these worlds.  This series of books and DVDs analyzes historical projects and extracts lessons learned that can be applied to modern projects.  Many of the cases studied are analyzed using both PMI’s PMBoK Guide and the IIBA’s BABoK as frameworks.  Even the latest book in the series, The History of Project Management, says almost as much about the history of requirements elicitation, analysis, and management as it does about scheduling, budgeting, or resource management.  As many projects need both skill sets, I don’t think that they are easily separable, and the prevalence of joint PM/BA books and conferences seems to support this notion.

So, while both professions have clearly different foci, I think that we need to consider them as close siblings that are rarely apart.  And, as in a family, we should get to know our siblings’ strengths and weaknesses well, so that we can best support each other as we struggle through our everyday lives.  PMs:  go see some basic BA training – you’ll not regret it.

Don’t forget to leave your comments below

Comments (11)