The main difference lies in analysis experience: those who are just aiming to become analysts; those who have already gained their first experiences; and those who, in theory, could already teach trainings themselves. Interestingly, each of them finds something new in the training – although that “something” is always a little different.

Career changer – moving into the IT field without coding

In every group, there is at least one person who joins the training with the goal of starting work as an analyst or product owner. Usually, they have previously worked as either a project manager or a tester – they have already collaborated with IT teams, but inside there is a doubt: “am I suited to be an analyst?”

On the other hand, there are also those who want to move from a specialist position in some business domain into the IT field, but actual programming seems too intimidating. Becoming an analyst or project manager appears to them as a more reasonable alternative.

For career changers, it is usually very interesting when, at the beginning of the training, we talk about the different roles that perform analysis in various types of organizations and what their responsibilities are. Discussions about how to interpret job postings to identify the right role sometimes even continue at the lunch table and during breaks.

During the training, they usually discover that the role of an analyst is not some kind of mysterious secret art. When discussing what an analyst actually does and what lies behind those different job titles, a career changer often realizes that they have already done many of those activities. It has simply been called by a different name.

When those puzzle pieces fall into place and some gaps in knowledge are filled, it becomes easier to highlight relevant experience in a CV using terms that a future employer will understand. For me, the most moving moments have been when a career changer later sends me a message saying they have actually been hired as an analyst!

Beginner analyst – I do know, but I don’t really know how

The challenges of a beginner analyst are different. They usually have a university diploma in hand or a couple of years of experience, but still dozens of questions circle in their head: “How do I make time estimates for analysis? How do I find the time to create all the documents we learned about at university? I did everything the way I was supposed to – why did this project run over schedule?” They do have knowledge, but lack experience – they don’t know how to make the right choices among all those dozens of possibilities.

In the training, they do know how to create documents correctly, but the aha! moment is understanding in what order and in which situations to use a particular tool at all. They begin to better understand other roles and processes around them; they learn to make choices and to ask the right questions. Already during the training, I have often received feedback such as: “At work we just found out that the project scope needs to be reduced. I pulled out our slides and we found a solution! “

In summary, a beginner analyst gains clarity from the training: all those pieces – processes, people, documents, tools – form a single system. They start using the right tools at the right time, which makes projects run more smoothly and clients happier.

Experienced analyst – different techniques and experiences

And then there are the veterans. They have been working as analysts for years, have developed their own routines, and drawing a process diagram or a data model is like a second native language to them. They are in the minority in my trainings, and they mainly attend because there is training money available in some budget and there are few trainings specifically for experienced IT analysts.

At first, analysts with long experience may even doubt whether they can get anything out of the training at all, but soon I receive intriguing questions from them such as: “Does anyone actually use this method?” or “Why should it be done this way, we’ve always done it differently?” They often discover that they have been stuck with one type of project and that there are many more useful techniques in the world – new ones are being created all the time! For me as a trainer, the detailed questions about specific situations are also fascinating, as they provide engaging context for the other participants as well.

In their feedback, experienced analysts usually say that they especially enjoyed learning how work is done in different types of projects, and they are satisfied that they had the chance to try out different techniques. Some even admit that they discovered a gap in their knowledge or picked up a useful tip on how to do their daily work better. Not a bad outcome, considering they came with “just” training money and still found something practical!

What can be taken away from these stories?

When looking at these three typical participants, a pattern emerges quite clearly:

• The career changer gains the confidence that “analyst” is not such a complicated job, but rather the application of common skills in a new way.
• The beginner analyst finds structure – how different tools help and when to use them.
• The experienced analyst gains fresh perspectives and a few new tools for their toolbox.

In summary, this means that regardless of their background, everyone goes home with some important realization: “Aha, now I understand why this all really matters!”

And maybe that is the most important lesson – the work of an analyst does not only mean producing documents or drawing processes. It means understanding how people, technology, and business fit together. And when that understanding emerges, daily work also becomes much smoother.

Come and try yourself!

If you are reading this and recognize yourself in one of these types, then you are exactly the person this course was created for.

The next public training will take place from September 29 to October 3 in Tartu (with an online option available).
See detailed information and register here (training is in Estonian):

Previously, I wrote about which character traits are needed for a good analyst. Just having the correct character however is not enough – you also need some skills. In this article, I will not be able to list absolutely all skills that a good analyst needs. Instead, I will list here three most important groups of skills.

Office worker basic skills

These are basic skills that are needed by all office workers and are useful also elsewhere. Unfortunately, these skills are not mostly taught in schools. However, missing these skills has a painful outcome – it will be more complicated to collaborate and keep a pleasant relationship with the customer.

Office worker basic skills are:

• Politeness – polite behavior, suitable dressing, using appropriate level of formality for the environment, proper document formatting.
• Relationship-building – small-talk, keeping appropriate parties informed, expectations management, keeping promises.
• Self-management – time management, prioritization, own tasks management.
• Using office software – using programs for e-mails, documents, spreadsheets, online meetings.
• Leading meetings – be it interviews, workshops, negotiations, or presentations. Analyst needs to be able to lead meetings face-to-face, by video bridge or even in written form.

These skills may seem very basic and obvious. Unfortunately, I have often seen that these skills are lacking either for myself or my colleagues. In real life, some of these may be forgotten during activity if you don’t put knowing focus on them. These are skills that always need additional practice.

Communication skills

Analyst may be described as mediator between different roles in the project:

• different customer representatives to discuss business requirements with;
• developers and architects, who need technical description;
• project manager, account manager etc, who need updates on project progress.

Analyst must be able to translate between these different roles. They must choose appropriate terms, point of view, level of detail and subjects for the audience.

In addition to roles, analyst must also consider personality types. They must manage also the more extreme forms of communication, for example:

• shy people, who don’t stand up for their requirements;
• chatty people, who tend to take the discussion off-topic;
• visual, written and auditory communication types, etc.

Analyst may encounter some complicated situations in their work, for example:

• Contract or change negotiations;
• Scope reduction negotiations;
• Communication with participants that are uninterested or object to project implementation;
• Resolving conflicting requirements;
• Finding solutions under big scope, stress, and nearing deadlines
• Etc.

Although analyst is not the main responsible in all these situations, they must support their project manager and escalate as needed. They must have the ability to manage tensions in all situations and keep the discussion on planned topic. They must be ready to lead the conversation, explain different facets of the project, etc. Here, the most useful skills are active listening, assertiveness, negotiation skills, presentation skills, etc.

Many analysts don’t acknowledge that communication skills can be learned or that they should be studied. Unfortunately, professional and effective communication is not natural – it needs conscious practice.

Analyst’s technical skills

Analyst’s technical skills are specific to analysts and they are obtained by studying the profession.

I consider main analyst’s technical skills to be primarily different documentation skills:

• Taking meeting notes;
• Visualization options, including diagram markup languages – ex UML, BPMN etc;
• Knowing documentation types – ex use cases, user stories, form or integration specifications etc.

In addition, I consider here knowledge about the following:

• The way IT-systems work (IT analyst needs more in-depth knowledge here than business analyst);
• Common analysis frameworks and using their patterns;
• Ability to read and use standards;
• Development methodologies and analysis techniques;
• And many more.

With experience, analyst gains ability to choose appropriate framework, standard or methodology for each situation.

Analyst’s technical skills are most easily learned and they are the biggest focus when hiring analysts. Still, many analysts’ skills are one-sided and need additional study.

Analyst training options

There is no systematic training regimen for analysts after university completion. You can find online courses from internet, but you need to know what to search for.

There are many books and courses about office worker basic skills. The quality is uneven, but it is possible to find truly beneficial courses both locally and online. It is essential to participate in these as practical trainings to practice the required skills as role play.

Analyst technical skills can be studied at TalTech Business ICT (in Estonian)  on both bachelor and master level and in Computer and Systems Engineering (in English) master level. In universities’ general IT programs, these skills are only taught in high level. On the other hand, there are countless books on these topics. Still, learning from a book might not be applicable on local market.

In addition, I have found in discussions that HR has lack of systematic mapping of analysts training needs. I hope this article gave a summary of the skills that are needed for an analyst in my opinion. Add your own opinion here, in our Facebook or LinkedIn group!

My past and current customers often give me the compliment of asking if I could take on another project. Or maybe I can suggest someone, who would be just as good. But how to evaluate an analyst?

I consider analysis work to be easily learned. When I told my Granny what I do for work, she was surprised that somebody is willing to pay for this! They are, and more than average salary. You just need certain personality traits and learnable skills.

Active listening

Analyst’s primary task is to find out customer’s wishes and needs, priorities and opportunities. Some people can do it naturally, while others lack information even after talking to customer.

Passive listening is not enough – part of knowledge is not heard and less specific topics remain unclear. Same with intense interviewing, where customer will not talk about things that weren’t specifically asked for (and nobody can ask all details!).

I have met analysts who talk more than listen. The result of this is always unsatisfied customer. Formally, the solution may meet all requirements, but customer’s actual needs are not met.

The best communication technique here is active listening. The analyst follows customer’s talking and asks questions to clarify. When talking strays away from the focus of specific meeting, it shows the analyst customer’s pain points. In this case, analyst writes those down, agrees a time to discuss these, and directs the discussion back to correct track.

Curious

Analyst’s main motivation is unlimited curiosity. They always want to know how things work, and why:

• How do they make train schedules so that trains won’t run into each other?
• How the electricity grid is managed to make sure production and consumption are in balance?
• How can insurance company be sure that there are enough reserves to pay for claims?
• How can Estonian state institutions exchange information securely?
• etc etc etc

Like a small child, the analyst wants to know everything. Analyst’s curiosity is independent of specific field and gives energy to find out everything necessary for offered solution. No detail is too small or unimportant!

In addition to details, analysts are also interested in the way those pieces fit together. When discussing a topic, analyst creates an abstract multidimensional picture in their head, how different details influence each other. Knowledge from previous meetings affect ongoing discussion and initiate new questions. New details may come to light that contradict the existing picture – then it is important to highlight this right away and determine, how they could be made to work together. The system must work as a whole.

Systematic

Analyst likes to have everything clear and systematized. There is a lot of information, but how do you know that you found the whole truth?

• Systematize and catalog the information,
• Create drawings that show relationships between different pieces of knowledge.
• Define the terms to be sure everything is unambiguous.
• Put actions in logical order to be sure no step is missing.

Being systematic applies to behavior as well. A good analyst always goes to a meeting with a plan about what they want to find out there. On a meeting, they make sure that all those questions get answered, as well as any questions that arise during the discussion. No question can be left undiscussed, no detail undescribed! If the time runs out, you just systematically agree next meeting to continue the discussion.

Thinks outside the box

Good analysts always think whether it would be possible to do something better in the field they are analyzing. They know that the way something has always been done, might not be the best way; even customer’s vision may not be best possible solution. Technology is developing fast and customer may not know all the possibilities.

• Maybe instead of creating a form to insert data, it would be possible to import this information from another system automatically?
• Maybe instead of showing information as table, you can visualize it using a graph or highlight important data points with colors?
• Maybe it is possible to redesign the process so that some action can be skipped completely?

Field specialists together with analysts can create truly innovative solutions that make work more effective.

On the other hand, one of my biggest lessons has been that sometimes you need to simplify the solution to fit into necessary time and budget limits. If an out-of-box thinker can figure out ways to automate activities and solve problems in innovative ways, then sometimes it makes sense to actually create a simple insertion form or not automate something, because the development is not worth the effort. Some examples are:

• support for old services that need to be maintained in new system;
• if automated solution cannot always give correct result, so user needs to review it anyway;
• MVP (Minimum Viable Product), pilot or PoC (Proof of Concept) solution, where it is important to deliver quickly even without full functionality.

Flexible

Analyst is always ready to adjust when their previous assumptions turn out to be incorrect. It is not always possible to be ready for all options – especially as we are going there to learn information that we don’t know yet.

We might have built a solution in our head, but it may not be suitable because of piece of information we haven’t got yet. Customer may also come to a different understanding that completely changes the approach to the solution. In any case, customer is the one to decide what to do; and analyst is the one to make sure that the solution is logically whole.

Analyst must be able to drop already completed works and readjust according to new knowledge.

Result oriented

All actions by analyst bring project closer to its goals.

If something has not been done or it is done differently than needed, then it is not useful to play the blame game, but to find a solution. If something comes to light during project that is contradicting project’s goal, then it must be brought in front of other participants as soon as possible. Everybody makes mistakes – even the best analyst is sometimes wrong! -, and in this case the only valid action is to tell about it and find a way forward from it. Even if the issue is with a customer representative, who doesn’t share needed information, or does it too slowly considering project timeline, then analyst finds a way to resolve this as well.

Analyst uses the previously described characteristics to find a solution to every situation, without escalating it on emotional level.

Responsible

Analyst knows the importance of their work. The plans and descriptions compiled by them are the basis for the whole solution. The earlier in development process that a mistake is made, the bigger impact it has on the system. A requirement that has not been uncovered correctly may:

• mean penalties to customer or project team,
• need to scrap and redo big part of the solution,
• or stopping the project because of accumulating problems.

Analyst has big responsibility to avoid mistakes and check the solution’s feasibility from every conceivable angle. That’s why they listen to customer actively, curiously finds out all their needs, systematizes this information, finds suitable solution by thinking outside the box or flexibly simplifies it and does everything needed to get to project result.

When I look back, then I didn’t have all the above characteristics when I started as analyst, and even now I am not perfect. Even so, I have developed far as an analyst and I am certain that the above characteristics have helped me most in this work.

If you are an analyst – do you agree with the characteristics I listed? Is there something important missing or is something I named not important in your opinion? Write your comment below this article, or in ITBAC Facebook or LinkedIn group.

If you are not an analyst, but you recognized yourself in this article, and you are interested in starting in this field – make sure to join ITBAC Facebook or LinkedIn group or our e-mail list! We can help you get started in this field and we offer mentoring to learn needed skills. There is a big shortage of good analysts!

This article was first published at https://liriel.org/.