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.

In many IT teams, documentation is random, fragmented, and outdated. However, systematic and up-to-date documentation helps maintain consistency in IT development, solve problems efficiently, and enable new team members to onboard faster. I’ve often heard that in agile projects, it’s impossible to keep documentation up to date, and therefore, it’s not worth creating it at all (I also wrote about this earlier in the article Debunking 6 Myths About Documentation).

I say it is possible!

In almost every team I’ve joined, documentation has been fragmented, outdated, or entirely missing. I’ve seen systems where the same functionality was developed multiple times in different ways. I’ve had to reconstruct the intended system state based on team folklore. And, of course, I’ve had to plan development work based on incomplete documentation. It’s a recurring frustration!

To change this, I have experimented with various approaches. I have found principles that help create, manage, and update documentation as a natural part of the process, even in agile teams.

Why is IT Documentation so often outdated?

Documentation is often imagined as following the traditional waterfall model: first comes analysis, then system design, development, and testing. Once the system is deployed, the documentation is considered complete. However, in reality, modern IT development is not linear. It is flexible, parallel, and consists of small iterations. Even existing systems are constantly being modified. Documentation needs to be adapted for the agile process.

In agile teams, documentation usually exists only as task descriptions or when specifically requested. It often lacks updates reflecting changes made during development and is not structured into a systematic documentation set. In the maze of various Confluence pages, readers can easily lose track of what has actually been implemented, what is still planned, or what was merely a discarded idea.

This leads to a situation where systematic and reliable documentation simply doesn’t exist. When team members leave, all knowledge about how and why a solution was built in a certain way disappears with them. No wonder there is so much reluctance toward documentation!

How to achieve up-to-date documentation?

You can develop a suitable solution for any team by considering the following questions:

1. How do you distinguish AS-IS from TO-BE?

Anyone reading the documentation should clearly understand whether it describes an existing solution or one that is still being developed. To achieve this, a team needs to establish its own convention. I have seen various approaches to solving this issue, such as:

• AS-IS and TO-BE are separate documents, where you can clearly see, which situation it describes;
• TO-BE description is colored in AS-IS documentation;
• With each change, a new version of the document is created. Instead of tracking the latest document version, the focus is on which document corresponds to the solution currently deployed in the production environment.

All of these approaches can provide clarity, but none of them fit every situation. The worst scenario is when different practices are used within the same team—this easily leads to confusion!

2. Which situation does AS-IS documentation describe?

People often talk about out of date documentation, but the moment when it gets outdated may be different in each team. Documentation is most often used to describe TO-BE vision, but at what moment the vision becomes reality (AS-IS)? Is it when the developer has finished programming, when it has been tested, or not before it has been deployed to production environment?

The answer may not be the same for every team. Only by establishing a clear agreement on this can you ensure that the entire team interprets the documentation in the same way.

3. How do you update documentation?

From the previous point, you determined when updates should occur. You can only ensure that documentation stays up to date if it is integrated into the regular workflow.

• The task must have a clear owner. In different teams, this responsibility can fall on various roles, from the product owner to the developer.
• The responsible person must receive a reminder to ensure updates are made. My recommendation is to set up a clear notification—whether as a separate task or a calendar reminder—so that updates are done on time and the work doesn’t pile up.

Once the previous steps are in place, updating documentation becomes a quick and simple task. For me, it also provides a sense of completion and satisfaction, knowing that a task has been properly finalized.

With a conscious approach, always up-to-date documentation is possible

Although the principles are universal, there is no single right answer that works for every team in every situation — each option has its pros and cons. I cover these in more detail in my book Optimal documentation: useful, up to date, and convenient and on the first day of my Business and Systems Analysis Course, which I run several times a year. There, I also provide more specific recommendations for how to find the solution that best fits your team.

I can confidently say that when these principles are consciously considered and implemented within a team, documentation becomes a valuable tool that you can always trust. In my projects, this is exactly the case!

“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).

In today’s business landscape, IT projects have become a crucial part of innovation. However, these projects may not always deliver the expected results and can even go very wrong. Kaja Trees, a business and systems analyst with decades of experience in diverse projects, has put together a course titled “Navigating the IT Landscape: A Business Professional’s Guide to IT Procurement and Successful Collaboration.” Here, she reveals common obstacles in IT projects and offers practical strategies to overcome them.

1. Exceeding Budget and Deadline

Problem: IT projects often tend to exceed budgets and timelines. Given that IT projects are not cheap and business outcomes depend on deadlines, this poses a significant problem for businesses.

Solution: Clear communication is the key to successful budget and deadline management. Pay special attention to ensuring a shared understanding in the following areas:

• Define clear project goals and ensure everyone understands them uniformly. It’s crucial to highlight priorities – which goal is more important than others.
• Ensure that the project scope is clear, and any changes are based solely on the project goals. If necessary, abandon less critical project outcomes to achieve more important ones.
• When selecting technologies, ensure that all options, along with sufficient explanations and pros/cons, are presented. The client must understand how to make the best choice based on project goals.
• Use an appropriate project management technique for the project and ensure that decisions are made by the client.
• Regularly evaluate what is working well or not and adjust accordingly.

Exceeding budget and deadline can be acceptable if the result is a product that is worth it. However, these decisions must be made consciously. Ignoring the above can result in no outcome at all – all the work and money have gone to waste.

2. Unusable Results

Problem: Even impeccably executed projects can fail if end users find the system unsuitable, forcing them back to traditional, less efficient methods.

Solution: The system can conflict with end user demands in several ways. Solutions include:

• Functionality must meet users’ needs and qualifications – involve business and systems analysts to ensure the system aligns with user needs.
• System usage should be simple; information and buttons where needed – involve user experience (UX) specialists to ensure an intuitive user interface.
• The system must be fast enough – involve system architects to ensure technological choices meet expected usage intensity.
• The system must deliver what is expected – involve quality assurance engineers (testers) in your team.
• Go straight to the source – involving actual users in the team through user interviews or user testing provides the best insights into what real users need.

Every IT project is teamwork, with each member playing a role. While some individuals may need to fulfill multiple roles, if any aspect is left uncovered, the project may be completed, the system built, but it won’t bring the desired benefits.

The IT world has evolved differently from the traditional business world. It has its project management concepts, specific roles, innovative practices, not to mention technical terms. To successfully carry out IT projects, it’s worthwhile to be aware of the peculiarities of the IT world and consciously consider them.

By enrolling in the “Navigating the IT Landscape” course, you not only acquire essential skills but also gain confidence in successfully managing complex IT projects. In the course, Kaja shares real-world experiences and explains in detail everything a non-IT person needs to know for successful IT collaboration and avoiding the problems that plague many IT projects.

First appeared in Estonian in Geenius DigiPro here: https://digipro.geenius.ee/sisuturundus/mis-saab-it-projektides-valesti-minna-ja-kuidas-seda-valtida/

Get ready, because we are about to debunk the myths surrounding documentation in IT projects! While documentation is essential when building a house, it often gets neglected in the world of technology.

We have invited Kaja Trees to help us explain why documentation is not a burden but a valuable tool on our journey in the IT world. She is an experienced Business and Systems Analyst and has a training called “Optimal Documentation: Enough, Connected, and Up-to-Date” (read more about the course HERE).

1. No one reads documentation anyway

Kaja suggests forgetting about detailed documentation where every nuance is precisely written. Instead think about who needs this information and include only what is necessary.

In your documentation, you should definitely include agreements with clients, tasks, and responsibilities. They help the project manager keep the project moving forward and let the developer know what their area of responsibility is.

When a new team member joins, it’s also beneficial if they can get the necessary information from documentation rather than through oral communication. For example, when a technical team member joins, understanding frameworks, tools, and project workflow is critical.

2. Code is documentation

Kaja states that code is documentation as much as the world is a map!

Yes, code contains a lot of information, but for large systems, understanding it can be as challenging as finding your way from downtown Tallinn to Rome. Code is very detailed, and getting an overview from it can be difficult.

Moreover, code is not understandable to the client and does not describe agreements – if code is documentation, there can’t be any “bugs”! Every change would have to be paid for by the client because, according to this logic, everything in the code is always correct, even if the developer has misunderstood something.

Good documentation helps everyone understand what the software does and navigate the code.

3. Documentation takes too much time

Kaja advises not to spend excessive time on detailed documentation. Think about what information is actually needed and document only that. The time spent creating such documentation is an investment that pays off later, with interest, when it can be used for planning updates and changes.

4. Documentation is always outdated

Kaja explains that documentation doesn’t have to become outdated! In her projects, she has learned to keep it up to date.

The key here is to include updating documentation as part of the natural process at an appropriate point. Software should not be updated without updating the documentation!

5. No One Likes to Write Documentation

Kaja points out that she genuinely enjoys documenting, and in fact, there are many people who enjoy writing documentation.

Choose diverse people for your team and let each person focus on what they enjoy. This is also one of the reasons why it’s good to include an analyst or even multiple analysts in a slightly larger project. Everyone can deal with the part of the work they enjoy.

6. Agile approaches don’t include documentation

Kaja asserts that the Agile Software Development Manifesto created in 2001 stated, “We value … working software over comprehensive documentation!” Over the more than 20 years that followed, this has often been interpreted as “we don’t value documentation.”

It’s forgotten that in the same manifesto, it says: “While there is value in the items on the right, we value the items on the left more.” Of course, the most important thing is that the software works, but good documentation can be a valuable tool in achieving that.

Documentation is not an enemy but a companion that helps the team navigate the complexities of the IT world. Finding the right balance that fits your project and team is crucial.

At Kaja Trees’s training session “Optimal Documentation: Enough, Connected, and Up-to-Date,” you can learn how to naturally write and update documentation to maximize its benefits with minimal effort. This is an opportunity you shouldn’t miss! You can purchase tickets for the training session in English, taking place on November 6 and November 8, 2023, HERE.

First appeared in Geenius 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!

In my own opinion, my biggest weakness is asking questions. Often I didn’t know what to ask even when it was clear that I don’t understand anything. Still, you need to start somewhere…

In the world of autistic people, I found the book The Essential 5. This book says that autistic children have it easier, if you always answer 5 questions: “why?”, “who?”, “where?”, “when?” and “how?”. I have started to use those same questions to find out everything necessary in IT-projects.

Why?

If you don’t know answer to “why?”, there is no point in going to next questions.

Why is this project started? What goals does this project need to reach? What KPIs need to be improved with this? Why are these KPIs important?

Simon Sinek has written a book “Start with why”. I agree with the title without reading the book itself. This is the most important question, the easiest to ask – and most underutilized. From “why?” you can set priorities and lead to more suitable functionality. IT system is waste of everyone’s time and money, if it doesn’t correspond to that question.

“Why?” gives the goal to the whole project and puts it in the context of the surrounding world. This is the clear basis for making decisions by all parties. The opposite question of “why not?” is also important. As an example, it is not necessary to implement already existing functionality or currently less important requirement. It limits the scope and helps make sure it is ready in time.

Answer to “Why?” often doesn’t is not documented. I have not found any good techniques to make sure it is always added there. “Why?” should be part of vision, RFQ or project contract. As this is compiled by customer, it doesn’t have a standard structure. During business analysis, different techniques are used to examine the background (SWOT, MOST, PESTLE, business plan etc), but the goal is only a small part of it. “5 Whys” technique helps discover the deeper reasons, but in my experience, it is used rarely and only in the beginning.

If “Why?” is missing then:

• Work is mechanical and error prone for all roles – developers, testers, implementers;
• Later, when system is repaired or improved, they may contradict the objectives;
• Nobody knows whether described functionality is actually needed or an analyst’s nice-to-have idea.

Agile software development methodology solves the problem by bringing customer and developer behind the same table. Still, in this case “Why?” is only in their memory. After a few iterations, it is difficult to remember why the solution was created the way it was. Something important for the customer may be lost in further developments, and will need to be restored.

“Why?” also needs to be asked as sub-question of all of the following questions:

• “Why they are interested in the project?”
• „Why exactly this way?“
• „Why at that time or with that regularity?“
• „Why there?“

Who?

Who orders the project? Who will be using the system? Who is interested in this system for some other reason?

“Who?” is often the starting point of project because, as they say – the one who pays, orders the music. Customer’s “why” is the most important for the project and it is customer, whose goals are primary from project’s standpoint. Analyst still needs to view solution from viewpoint of all parties. Stakeholder analysis is used to find all parties, and you can use different techniques to do that.

“Who?” says to the analyst, whom they need to talk to, or whose interests they need to find from other channels.

There are also common answers to this question. First, the customer and different roles who will be using the system. Analyst will be spending most of the time with them or considering from their point of view. Additionally, there are roles that tend to get overlooked:

• Legal requirements (if customer cannot bring these up);
• Competitor’s interest (that we want to contradict);
• Accountant/management reporting needs;
• and needs of technical system administrators.

The discovered needs are usually contradictory, but analyst needs to find suitable solution for the customer.

Where?

Where does future user currently do needed activities? What is customer’s and users’ vision about where they could do these in the future? Where is information needed by stakeholders?

“Where?” tells you first about the architecture of future solution. For example, what views are needed, how the data is stored, which systems are involved – and which are not.

On the other hand, “where?” talks about devices used by future users. Maybe the user is a technician, who uses a mobile phone with small screen while on the site? Maybe they didn’t have some devices before and it is needed to procure them within the project? Maybe it is required for all future users to use specific operation system? Maybe it is reasonable to continue using existing solutions – partially, for transition or as replacement of some development.

Different aspects of “where?” are described in (nonfunctional) requirements, architecture and deployment views. It is also mentioned on process diagrams, user stories and use cases.

When?

When does a process start? What is the order of different processes, what is the frequency? When does user need to see any information? When do the process results need to be ready?

“When?” helps to decide whether to automate a process or make it manually accessible. Often used processes and information may need to be made more easily accessible or highlighted. It may be necessary to optimize time-critical processes.

“When?” gives mostly information about what the solution can be like. This information is described in requirements, processes and use cases.

How?

How do future users currently do those activities? What is the customer’s and users’ vision for how to do that in the future? How would it be most convenient/efficient/correct way to reach to the result? How can we provide best solution to customer within given time and budget constraints?

“How?” question is dealt with during most project meetings and hours spent alone by analyst. It helps you understand all details that you can’t find with previous more generic questions. It is also used to understand how processes work in system to be built or around it.

When focusing on “How?” there is risk to forget “Why?”. For example, you create system exactly the same way as current process that is based on paper or Excel use. There is no added value from process optimization in such system.

“How?” is mostly described in process diagrams, use cases or user stories. In my experience, the best way is process diagrams with descriptive remarks, because these don’t need specialized IT knowledge to read. Depending on the project, it still might be better to create user stories or use cases instead.

Conclusion

Maybe you wonder, why there is no “what?” question in this list? It wasn’t there in given framework – and whether through luck or some other reason, it is not needed. Analyst is answering this question with their work. Some customers do give quite detailed vision about what the future should be. Still, even in this case, it must be analyzed whether it really is the best possible solution. Using the analyst’s experience and analysis process, usually the final solution will be somewhat different. Too detailed vision given by customer may even draw out analysis process and make it more complicated; especially if analyst forgets to ask “Why?” because of it.

Those questions are clearly not exhaustive. You can go into more details in everything, and based on project, you may need to ask some very specific questions. Still, this framework helps cover biggest areas during IT project analysis. They help me start the discussion, if it is difficult for some reason, and keep the most important thing in focus.

Why would you use this framework – or not? Do you have some simple frameworks that help in analysis process? Add them below as comments or 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/.

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.