What are the best business analysis blogs

Business analysis versus project management

Are you also familiar with the current discussion about business analysis versus project management? In many companies there seems to be uncertainty as to which tasks a business analyst and which a project manager will take on. Who is responsible for what? Where does a separation between roles and tasks make sense and where does collaboration make sense?

Business analysis and project management - a look into the past

Business analysis and the role of the business analyst have changed significantly in recent years. In the nineties, business analysts liked to have a degree in economics, but at least had a business background, and were often employed in banks. Their job was to determine when a deal - that is, a business - would make sense. Which factors played a role for the success, how could this success be ensured and measured? And today?

Even today, the business analyst must have some kind of radar for business. He advises corporate management, looks beyond the present day, discovers markets and opportunities. But he also interacts with stakeholders, discusses requirements and forms the interface to the customer. There is increasing direct overlap with the role of the project manager (and the system analyst, the requirements engineer or the requirements analyst).

The project manager is also largely responsible for the company's success, especially since working on projects has proven to be the preferred form of collaboration for a large number of companies. Line organizations do define a structural affiliation, but the necessary interdisciplinary cooperation between experts from a wide variety of areas with a wide variety of skills regularly results in projects.

A project manager is therefore no longer just a "master of his own kind", but a captain, navigator, motivator and also a "communicator between the worlds". And these worlds not only exist within the company, but of course also externally in interaction with clients, suppliers and stakeholders. Thus, both roles are very important for the success of the company and the question of the respective tasks is in the room.

Different tasks, or not?

The tasks of a business analyst and a project manager cannot be clearly and universally defined for all projects, project types, companies and industries. For example, a project manager could be responsible for the success of a project and the business analyst could be responsible for the requirements analysis or the coordination of the requirements in certain project phases. Or the business analyst defines the framework conditions of the business and the implementation is aimed at with a project under the leadership of the project manager.

So what could a meaningful division of tasks look like? The key could be the business analyst's concentration on the product, the solution or, in short, the “what”, while the project manager takes care of the creation process and thus the “how”. The “what” determines the “how”, so that the business analyst covers a slightly wider spectrum than the project manager.

This in itself is not surprising, because the project manager can usually only act when there is a project. The business analyst, on the other hand, can become active within the framework of a project, but also outside of a project. In this way, he could prepare or make strategic decisions that then lead to new projects. It would then be the responsibility of the project manager to implement these, taking into account the given boundary conditions such as time, budget and resources.

With such an understanding, there is the following division between business analyst and project manager:


Business analysis and project management in practice

And how does the cooperation work in practice? Theoretically, the demarcation between business analysis and project management is defined down to the smallest detail, but in practice the handling differs from company to company, from project to project. Often there is neither pure business analysis nor pure project management, but a kind of hybrid of both parts. This hybrid can be seen as an opportunity when the different perspectives of business analysis and project management are combined. Or as a risk, namely when both roles are assumed by one person and the natural conflict of interests between strategic and operational orientation is not taken into account. This can save money in the short term, but in return, the workload of the specific employee increases.

In addition, competition between the roles or representatives of the respective direction is developing. Sentences like “I am a business analyst and do not need a project manager” or “I am a project manager and do not need a business analyst to tell me how to work” are heard more often. It can also be clearly seen at conferences that business analysts see themselves increasingly in requirements engineering and testing. One can easily get the impression that the corporate world can hardly exist without business analysts.

This is certainly also the case when it comes to the strategic direction of a company, when advising management, when recognizing markets and opportunities. In the concrete implementation in project work, in the development of products or software, there are, however, various roles that deal with the elicitation, management and coordination of requirements, so that companies should ask themselves whether an adaptation of the roles actually lived is desirable.


It makes perfect sense to think about the distribution of tasks and responsibilities within organizations. The results will vary depending on the company. This is due to the different processes and existing roles. You may be developing software with the V-Modell XT and therefore know a requirements analyst whose area of ​​responsibility could clearly overlap with that of a business analyst. Or you can use the PRINCE2 project management methodology - and the project manager is responsible for creating the business case. Perhaps you have also established a project application system and have to provide commercial key figures before the actual project can even start. The creation of a business case would therefore not be a task for the project manager; this would “only” have to take care of the operational achievement of goals.

Another reason is due to the fact that people are different. No two business analysts and no two project managers are actually alike. Ideally, employees also have a common understanding of tasks across all roles.

But employees also have different experiences and skills. So you can easily define that a business analyst does a, b and c and a project manager d, e and f, but that only helps to a limited extent if, for example, the business analyst is not able to do c at all. A definition should therefore be understood as a starting point, but would then have to be discussed in detail in the course of the upcoming plan, business or project. Of course, this creates more effort, but also avoids misunderstandings, duplicate work and missing results. So the focus would no longer be on the individual titles, but on mutual cooperation, teamwork and the actual result.

Business analysis AND project management is the bottom line.



Further information on the subject can be found in the PMI “Practitioners Guide for Business Analysis” under “Collaboration Points”.

The following books are also worth reading:

Business Analysis and Requirements Engineering, Sustainable Improvement of Products and Processes, Peter Hruschka, Carl Hanser Verlag Munich

Business analysis, simple and effective, Inge Hanschke, Gunnar Giesinger, Daniel Goetze, Carl Hanser Verlag Munich

Basic knowledge of business analysis, solving problems, seizing opportunities, Ingrid Gerstbach, Peter Gerstbach, Redline Verlag



Michael Schenkel believes in useful tools, that support users in their work and that provide a common working environment for all types of roles in a project. He became a member of the microTOOL family more than fifteen years ago and took over the position of head of marketing for about half a decade. In October 2017, he moved on to a new adventure and we wish him all the best on this new path.

Tags:Methods and processes