Analysts: who is who?
Often, the analysis role in an IT project differs from company to company. Sometimes the position name may not even contain the word "analyst". For example, Product owner. Or the person responsible for working with clients. And this is despite the fact that outside the IT industry, there are many other analysts: budget, finance, investment, marketing ... So what is the difference between all these analysts? The answer to this question depends strongly on the context in which it is viewed.
In sectors not related to software development, the difference between a business analyst and, for example, a requirements analyst is fairly obvious. A Business Analyst needs a fairly deep knowledge in the field of management and finance. But he does not have such a deep understanding of the issues of business process automation and integration of computer systems. Such a high-level analyst decides the tasks for which, in some cases, automation is not always necessary. For example issues related to business goals or business process optimization.
In documents created as a result of their work, talking about computers in general is not an option. But if a business analyst’s recommendations include the need for the development or revision of software other analysts come into play. And it is here where the confusion regarding the various titles of analysts come into play. But this confusion – is only apparent. In IT projects, all people whose work is somehow connected to analysis, have more similarities than differences.
After all, what is the job of the analyst in an IT project? First of all he needs to understand how the part of the client’s business which will be automated works. To understand the true business needs and the needs of individual employees, whose interests are affected by the project. Then explain this as a well-structured set of requirements in order to develop or fine-tune a piece of software. This is important for developers who may not have a deep knowledge of the area in which the customer operates.
You may say that such analysts should be called requirements analysts, it's obvious! But only at first glance ... After describing the requirements, the analyst must be clear about the whole system: its structure, function and interaction with other systems. So he might be a systems analyst! But there are projects in which an emphasis is placed on the functionality of the system. For example, when finalizing an already deployed system whose architecture is well established and will not change in the course of the project. In such projects we may call him a functional analyst.
It turns out that all the differences are just nuances and all analyst are about the same. For some projects (especially those where there is just one analyst) all of the above could apply. A business analyst in an IT project is a kind of "customer representative", always there to clarify any issues related to automating the business.
Often times a business analyst may be an employee of the customer. Because of this, he is not only knowledgeable in the subject area but he is also well versed in the specifics of a particular company, for which the project is carried out. It is for such external business intelligence projects that we use the agile concept of Product owner.
Thus, all of the different names of an analyst position are correct. They reflect the specifics of the project (or the company), but each different name has a very similar set of responsibilities, skills and knowledge. Any such role requires literacy, systematic thinking and good communication skills.
If you are interested in improving your Business Analysis expertise why not check out our courses: