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):

That’s why I wrote the book Optimal documentation: useful, up to date and convenient

Early in my career, I was just as frustrated. I saw teams skip documentation entirely, or worse, create piles of outdated files no one trusted. As a business and IT systems analyst, I couldn’t ignore how much time and money was wasted because the right information wasn’t available when needed. On the other hand, I felt those struggles first-hand — it is not intuitive to make documentation relevant and up to date, and nobody was able to teach me how.

Over the years, I discovered through trial and error documentation best practices that helped me keep on top of it. I found ways how to make documentation useful and easy to maintain, and genuinely supports the team — and that’s the approach I share in this book.

Here are a few ideas from the book.

1. There are too many bad arguments and myths that take away our motivation to document

The article Debunking 6 Myths About Documentation is fully incorporated into the book, but I also expand upon just bad arguments for writing documentation:

× “You have to,” “the boss said so.”
× That’s how it’s always been done.
× That’s the analyst’s output.
× To fulfill contractual obligations.
I hear these arguments often. If you encounter such justifications in your work – just because it’s required or someone said so – it’s no wonder you might lack motivation to write documentation. In such cases, it’s worth asking “why?” and truly unpacking the reasoning for yourself. Otherwise, it might indeed feel justified to leave the documentation undone.

Chapter 1: Why people don’t want to document?

To write truly useful documentation, it is important to understand why we write it, to whom and what kind of documentation is actually helpful.

2. Documentation should help you yourself

Often, I attend a meeting with a client where they explain their ideas and needs and answer all my questions. It seems like everything is clear… But then, as I start writing things down into a coherent whole, I realize there are still missing details or gaps that need to be addressed.
The structured nature of documentation naturally helps to think through the entire solution and highlight what’s still missing

Chapter 2: Documentation is useful to you personally

Good documentation isn’t just for handovers or audits — it’s a thinking tool. It helps you spot missing information early, reduces repeated explanations, and makes it easier to make solid decisions.

3. Integrate updates into your workflow

One of the most common frustrations I hear is: “Documentation is always outdated.”

But it doesn’t have to be this way – and of course, up-to-date documentation is far more valuable. And yes, keeping documentation up to date is entirely possible! This simply requires updating it as needed. Naturally, this means assigning responsibility to someone who has both the persistence and the skills to maintain it.
I explain how I’ve addressed this in the part titled “Up to date,” where I describe how the updating process can be integrated into your regular work routine as a natural part of documentation.

Chapter 1: Why people don’t want to document?

I also share practical ways to do this in my article Always Up-to-Date Documentation is Possible — and the book goes into detail about this framework of documentation best practices.

4. You don’t need to document everything

Busy teams don’t have the luxury of writing novels. That’s why my documentation best practices focus on right-sizing it to the project’s needs — enough to give clarity, not so much that it becomes unmanageable.

One must make smart choices between these models. For example, even a map can have many different views – traffic schemes, electrical installation layouts, cadastral boundaries, mineral resource maps, etc. You don’t need to create all of them – unless you’re building a centralized geoinformation service – just a base map and views tailored to show the information needed by your target audience. /…/

On the other hand, continuing with the map analogy, we can also choose the appropriate level of detail – at what zoom level do we need to view the map in a given situation? /…/

When documenting IT systems, documentation is often created as views with varying levels of detail, where a higher-level view includes components that are expanded in more detailed lower-level views. This creates a hierarchy in which the lower levels contain significantly more views/documents than the higher levels – and that raises the idea of not documenting every solution in such depth to reduce maintenance overhead.

Chapter 6: Sufficient documentation

Considering the types of documentation and the abstraction level necessary helps you make smart choices about your documentation, which helps us manage our workload – do only what is actually necessary. In the book, I explain how to identify the right models and the correct level of detail.

Ready to make your documentation useful and easy to maintain for you?

If you’re a business analyst, systems analyst, project manager, product manager, product owner — or simply part of a busy IT team — you can stop treating documentation as a chore and start using it as a productivity tool.

In the book, I walk step-by-step through understanding the frustration, value of documentation, to practical principles on how to make it truly helpful, understandable and convenient. Although I mention standards and frameworks where appropriate, this book focuses on documentation best practices that can be applied anywhere. In addition to the theory, there are exercises under most chapters. These help you deepen the understanding and apply it to your own specific documentation and processes.

Learn the full approach in the book: Optimal documentation: useful, up to date and convenient,
available as both e-book and paperback, or if you want to walk it through with your whole team, a training-workshop is available on the topic.

“There are no analysts in our projects!” and “I don’t want to see another analyst in my projects!” are increasingly common phrases in IT projects. Yet, before the triumph of agile development, analysts played a critical role in preparing for IT development. So, how is it done now?

The topic is elaborated by Kaja Trees, a systems and business analyst with over 20 years of experience, who also shares her knowledge through training sessions. She has provided consultancy services in various companies.

The Analyst’s Place in IT Teams

According to Kaja, the structure of IT teams and the analyst’s place in them can be roughly divided into four groups:

1. Teams without analysts

Here, every developer does the analysis for their development task. This can lead to unevenly thought-out solutions, or a ‘hunchback’ system. Such systems may contain duplications, technological debt, and scaling issues. Users are often dissatisfied with the UX, and IT architects with the technical structure.

The challenge is maintaining the big picture, often done by a collective ‘hivemind’ rather than a central role. There are software developers who can collectively maintain the big picture and engage in necessary discussions with the client, though many prefer focusing on the technical side. Agile methodologies offer many practices to mitigate this risk. However, Kaja’s experience shows the need to be aware of the analysis role to avoid problems.

2. Teams with an analyst under a different title

The Product Owner, IT Architect, or even Scrum Master might fulfill this role if they have the relevant skills. This is like doing “secret” analysis to bypass strict restrictions.

The risk here is that their other activities may not receive enough attention, though they are also important. If there is a good balance between developers and other roles, such a team can function very well.

3. Teams Where the Client Conducts the Analysis

This means the client has a strong business analyst who maintains scope and logical coherence of the solution, preparing development tasks (like user stories) and ensuring that the solution is optimal from the client and user perspectives. Ideally, they have an IT background to utilize IT capabilities without overcomplicating things. The development team receives a task that is understandable to developers, allowing them to focus on the technical side.

The biggest risk is when the analyst does not fully understand how IT systems work. Here, an open dialogue with IT architects or developers, who think along and suggest alternatives to proposed solutions, is helpful.

On the other hand, such a team must have either an IT architect or excellent developer collaboration to ensure that all parts of the solution work as a unified whole from a technical perspective. Without a grand vision, for example, development might start on a platform with insufficient scalability for the final solution.

4. Teams with an analyst as part of the development team

The analyst’s task is to prepare tickets just as a developer’s task is to develop them and a tester’s is to test them.

If the client lacks a strong, technologically savvy business analyst, then the project team must fulfill this role. Kaja has been in this position in many projects and found it can work very well. However, purists of agile development see this as sacrilege, believing that the development ticket should be solely in one person’s hands from start to finish.

Analysis is of critical importance

It’s vital to understand that analysis is a critically important part of any project, no matter who does it. To avoid disputes, Kaja often approaches the responsibility of analysis by looking beyond job titles and defined roles – finding the person who takes on this responsibility. An analyst, in her view, is someone who does the analysis, regardless of their job title or where they “sit” in the team structure. The notion that only people with the official title of “analyst” can do this work is limiting and creates conflicts.

Similarly, Kaja’s taught “Business and Systems Analysis Course” is intended for all roles involved in business or systems analysis – including developers, product owners, Scrum Masters, testers, and project managers. It teaches analysis skills through thoughtful theory and feedback-based practice and is an investment in personal and company development.

The article was first published in DigiPRO (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!

Best way to understand the analysis roles is to go through the process of project.

Simplified project process

A project starts when the Client has created a vision for a business model or change in the organization. They define the model for change with the help from Business Consultant. Their goal is to verify that the change is worth pursuing. The main results from this process are definition of vision, budget and deadline.

If the project is worth pursuing, they find a Project Manager to control its execution. He/she will include other roles to the project, as necessary – Business and IT Analysts among others.

Next, Business Analyst defines the business organization and processes based on the vision. They might need workshops with people involved to find all needs. Business Analyst might also discover ways to improve the model of the vision, which they will relay to Client. Often they discover changes needed in existing IT-systems or need for new ones. In this case, they will involve IT Analyst.

IT Analyst defines the details of IT-systems and their interactions. They use business processes and workshops with people involved to understand the needs. They might discover ways to streamline the business processes using the IT-systems. In this case they will work with Business Analyst to improve them.

IT Analyst includes IT Architect to define the structure of the IT systems. This includes components of the systems as well as interactions between systems. They consider non-functional specifics like performance and security to find the solution. IT Analyst then defines how the processes use this structure.

The designed solution is then:

• realized by the Developer
• tested by Quality Assurance engineer (or Tester)
• approved by all the above roles for implementation
• and implemented through both technical and other activities;
• results interpreted by Client, who may start next project for any improvements.

Differences

Above description looks like the dreaded waterfall model, but this doesn’t need to be the case. One person can be in all these roles, as is often the case in smaller projects or with agile methodologies. Yet, in bigger projects the roles may be even more specific:

• User Interface Analyst
• Database Analyst
• Integrations Analyst
• etc.

It is easier to understand the roles and responsibilities when broken down like this. We will be using the roles on this page as defined in this simplified process. The IT and Business Analysis Club focuses on the roles of Business Analyst and IT Analyst.