The role of an analyst can best be described as someone who is responsible for analyzing business requirements and translating them into software requirements. By that, I mean understanding the needs and goals of the business stakeholders and then translating them into understandable pieces of functionality in the development of a software system. In other words, ensuring that a developer can work with them.
But what sets a good analyst apart from their colleagues? When is it a blessing to have an analyst on the team? For me, it comes down to these 5 personality traits!
An analyst adds absolute value in complex environments where processes and terminology require in-depth knowledge and insights to understand the interconnections. Examples of sectors where these complex environments typically occur are healthcare and the energy sector.
Furthermore, when operating on a larger scale, both nationally and internationally, more stakeholders come into play. The number of interactions increases, making communication more challenging and decisions potentially harder to make.
Another aspect of a complex environment can also be a company operating in a highly volatile market. What is developed today may no longer be relevant in a few months. This impact is reflected in the development process but can also manifest in the complexity of processes and products.
As an analyst, it is important to understand and reason with the complexity alongside the experts in the business. One way to achieve this is by breaking down the complexity into smaller, more understandable blocks.
Equally important and closely related to the previous point is the critical judgment of an analyst.
As mentioned earlier, an analyst is primarily responsible for analyzing business requirements and translating them into software requirements.
The challenge is twofold.
On the one hand, we live in a world where it is increasingly difficult to imagine bringing value to customers without software development. This often leads business experts to think in terms of software solutions and skip the step of asking "what problem are we trying to solve?" too quickly. The analyst's challenge is to counter this and to clearly understand why the expert insists on a particular solution. Undoubtedly, there is a reason behind it, and it is not an arbitrary choice. However, there may be alternative solutions that are cheaper, easier to implement, and still meet the requirements. Therefore, it is crucial to explore the underlying need behind the proposed solution and weigh the alternatives together.
On the other hand, as an analyst, you are confronted with numerous requirements. It is exciting to work with experts who have many great ideas, but time is never your best friend. It is therefore extremely important to distinguish between "important" and "less important." Together with the expert, you set priorities. Which requirements will bring us the most value if we address them now?
It is not surprising that an analyst possesses an analytical mindset. But what does that exactly mean?
It means that an analyst approaches problems and situations in a logical and systematic manner. Think of what was mentioned earlier about dealing with complexity; they can break down complexity into smaller, more understandable blocks. For example, processes that may have different levels of abstraction or an information model that can be conceptually simple but reveal more complex structures logically. By systematically approaching complexity, existing or newly developed processes and systems may reveal potential problems. Conducting analyses involves searching for alternatives since there are often multiple ways to provide a certain functionality. Can a business requirement be met with a quick, short-term solution that has long-term drawbacks? What is a maintainable long-term solution? How far do we go in anticipating future expansions? A simple list of pros and cons can assist business experts and/or the software team in making the right choices.
If possible, an analyst also seeks data to support decisions. Often as analysts, we make assumptions, and there's nothing wrong with that. However, it is incorrect to accept those assumptions as truth. A good analyst takes actions to validate assumptions made. For example, if you start from the assumption that a certain functionality is used in a specific way by end users, it is important to verify if this is indeed the case. This can be done by analyzing existing data, testing a hypothesis, or even developing a certain functionality based on an assumption and later measuring its usage. The latter may not always be possible and requires an environment that is fairly mature in agile development. An important software requirement in that case would be the ability to measure the assumption.
While an analyst must handle complexity and volatility critically and work analytically, it is even more crucial to be able to present and communicate that complexity in a simplified yet accurate manner. This applies to both conveying the understanding to business experts, showing them that you follow their story, and communicating with the software team who ultimately need to translate that complexity into maintainable software. As an analyst, you play the crucial bridge in that communication!
There are two apparent paradoxes: complex thinking versus simple communication and collaboration with business experts versus collaboration with the software team. These apparent (I repeat it once again) paradoxes are what make the role of an analyst very challenging.
When it comes to complex thinking, the skill of the analyst lies in grasping the essential complexity of the problem without adding unwanted complexity to the solution. Think of over-engineering, where systems offer too many functionalities, making maintenance difficult. Or unnecessary optimization, where two different functionalities are developed as one, resulting in a cumbersome user experience.
To communicate simply, an analyst needs to excel in stakeholder management. Having the right answer is not the same as getting others to agree. Your analysis is only valuable when it is shared and embraced by all stakeholders. The analyst tailors their communication to the specific needs of different stakeholders. By using appropriate visuals, the business story can be highlighted to get to the core of the problem with business experts, where technical details matter less. A different approach is needed when discussing the solution with the software team.
Having the right answer is not the same as getting others to agree. Your analysis is only valuable when it is shared and embraced by all stakeholders.
If you possess the aforementioned behavioral patterns as an analyst, you will already go a long way in my opinion. One last, underestimated pattern is the flexibility in how you approach the role of an analyst. I have completed a wide range of assignments in the past 10 years, and in none of them did I fulfill the role exactly the same way. This is partly because the context was different, but also because you are surrounded by different people who may have a slightly different approach or varying levels of maturity.
A colleague of mine once said, "If all the roles surrounding the analyst perform their job to the utmost, then the analyst is essentially redundant." I think there is a lot of truth in that, except for the fact that you still work with people (Phew!). However beautifully you can describe each role on paper, it doesn't always mean that you can directly replace them with others. I truly believe that the mind of a good developer functions completely differently from that of a good business expert. Place an analyst in between with a certain perspective, and magical things can happen. That's just a simple context; the analyst also interacts with project managers, product owners, architects, testers, test automators, team leads, and so on.
Over the past 10 years, I have learned a lot. Not exclusively, but encompassing many aspects, I describe it as flexibility. What I mean by flexibility mainly includes the following:
So, how does a good analyst differentiate themselves from their colleagues? A good analyst can deal with complexity and volatility. A good analyst has a critical attitude and a healthy amount of judgment. They have an analytical mindset, are strong communicators, and are flexible in their approach to the job!