"Projects are not made by spreadsheets, but by people," says a project manager in an interview about team coordination, emotional resilience, and finding solutions between two worlds.

How long have you been working as a project manager?
Since 2012. At first, I worked for three to four years as a project coordinator, then I moved to the position of project manager. I’ve stayed in this field ever since.

And what did you study?
Law. I even completed the state exams. But I entered IT right after finishing school.

How did that happen?
An IT company was looking for someone from outside to take on management tasks, because in IT teams it often happens that the best programmer becomes the team lead, even though they might not have managerial skills. My future boss realized that and called me. Exactly one day after my final exams. He had hinted earlier that he might have something interesting, but nothing specific.

And you accepted the offer?
Yes, I told myself I’d give it a chance. The situation in the legal field in Slovakia wasn’t ideal at the time.

So IT seemed like a more attractive path?
Definitely yes — not only in terms of salary but also in terms of how it felt. Even in high school, I enjoyed exploring things related to computers; I figured everything out on my own and later started helping others as well. Technology has always been close to me.

How did the beginning of your career go?
At first, I was supposed to handle management-related tasks for the head of the division, but that quickly changed. On one large project for a South Korean client, the project manager dropped out, and I was offered to help with management. At that time, I had only recently joined the project management team, but I took the opportunity. It was my first major international project, and since then, I’ve stayed in project management.

How did you end up at ANASOFT?
In a completely ordinary way. I saw a job posting, sent my CV, went through the interview process, and here I am.

How did you decide where you wanted to work?
Over time, I realized that I prefer Slovak private companies. In corporations, responsibilities are narrowly defined, and a person doesn’t have the opportunity to get involved in other areas. In private companies, the boundaries are more flexible. A project manager often understands the technical side of things better there. And that’s closer to me.

What types of projects do you work on?
I work on projects that are more product-oriented, as well as those focused on custom development. The solutions are delivered not only to private companies but also to the public sector. That was a challenge for me. The approach in the public sector is completely different: approvals, budgeting, bureaucracy… compared to private companies, it’s much more formal and slower.

Are you involved in every project from the very beginning?

It depends on the specific case. Sometimes I’m part of the project from the very beginning — I participate in preparing the proposal together with the salesperson, analyst, technical architect, or tester. In that case, we create the schedule together, define milestones, describe how the project will proceed, what phases it will have, what types of testing will be done, how the project will be managed, and more. A proposal can have just a few pages, or tens or even hundreds, depending on the size of the project and the client’s requirements.

Other times, I join the project later — for example, when it’s an extension of an existing solution or a separate project that originated from previous cooperation. Every project starts differently: sometimes we begin from scratch, other times we build upon an already established relationship. That’s why there isn’t one universal model.

What happens once the client approves the proposal?

We begin with the initiation phase. We set up the project plan, agree on milestones, management methods, and the schedule — unless some of that was already agreed upon in the proposal or the contract. In the past, many projects were carried out using the so-called waterfall method — first a complete analysis, then development, testing, and finally deployment. Today, more agile approaches are used: the project is divided into smaller parts or modules that are analyzed, developed, and tested separately. The advantage is that the client receives functional deliverables during the project and gets something they can already work with.

Are you present throughout the entire project?

Yes, I’m involved from the very beginning until the project’s completion. Sometimes even longer — if the project transitions into a service phase, it is handed over to a so-called service manager who ensures support and further maintenance.

How do you perceive the relationship between the supplier and the client during a project?

A project is a joint effort. It’s not about one side delivering something and the other just receiving it — we function as one team. People from the client’s side are crucial for the project because they know their business, processes, and needs best. We can propose a solution, but without their input, it wouldn’t work.

Do you actively involve them during implementation as well?

Yes, depending on the project phase. At the beginning, it’s mainly cooperation between analysts, consultants, and business architects on both sides. The client needs to be able to explain what they need and how they envision it. We then align it with the technical possibilities.

As a project manager, do you also coordinate developers and other team members during development?

Yes, absolutely. I’m the link between the business and development sides. I make sure everyone knows what to do, that developers have the necessary inputs, know the priorities, and at the same time, I keep the client informed about the project’s progress. From the very start, we have a project plan that becomes more detailed as the project progresses. Everyone has their tasks, and I monitor whether they are being completed on time, within budget, in the agreed scope, and with the required quality. I communicate with the team daily, address risks and issues, and report them to project leadership so we can act in time.

Isn’t the job of a project manager quite unpredictable? Do you enjoy that uncertainty?

I don’t see it as uncertainty but as a natural part of a project’s lifecycle. Things never go exactly according to plan — unexpected situations can arise on our side or the client’s side during implementation. That’s why we talk about risks in advance — what might happen, how likely it is, and what we can do to prevent it.

So risks aren’t just of a technical nature?

Exactly. For example, if there’s a key person on the client’s side on whom many things depend, and that person is overloaded or unavailable, it represents a risk. Clients often work on several projects at once, handling them alongside their usual duties, which can slow the project down.

That sounds quite stressful. How do you handle it?

Stress comes when a risk turns into a real problem. As long as it’s just a potential threat, it can be managed — through communication, prevention, and finding compromises and solutions. But when, for example, the client doesn’t have time to approve documentation or test deliverables, it can jeopardize the whole schedule or cause other issues that endanger one of the project’s key pillars. That’s when you can really feel the pressure.

What do you do when the client simply doesn’t have the capacity to focus on the project?

The key is open communication. If I see a problem might arise, I always point it out in advance, and together we look for a solution — either the client allocates more people, or we adjust the schedule. The important thing is not to deal with such issues at the last minute. My job as a project manager is to lead these discussions and keep the project moving.

Do you always work on just one project, or can you handle several at once?

It depends on the scope. With a large project for a major client, I focus fully on that one — there are many people, lots of communication, and coordination involved. With smaller projects, I usually manage several in parallel. Sometimes I’ve had one big one and a smaller one alongside it, other times several small ones at the same time.

What do you prefer — working on one large project or several smaller ones?

Each type has its advantages. Large projects are managed more systematically, following “textbook” project management, because the situation requires it. Smaller projects involve less bureaucracy, faster agreements, and more flexible functioning. The ideal is a mix — having experience with both types. Because if I only worked on small projects and then a big one came along, it would completely overwhelm me. And focusing only on large projects would be a pity — you lose flexibility.

Once development starts, what happens next?

After development, internal testing takes place on our side — developers always produce something, and naturally, there may be bugs. At the same time, test scenarios are prepared — ideally by the customer, because they know best how they’ll use the system. But if they don’t have the capacity, our testers prepare them. Then the system goes into customer testing.

Do you show the client design drafts or functional previews during the process?

Yes, depending on the project phase. When we work on design, we show drafts such as wireframes or screen visuals. It’s important for the client to see how it will look — so they don’t say after development that it’s not what they wanted. And once we have something functional, we present it continuously — depending on whether it’s our first project with that client or an ongoing collaboration.

Who has the final say during testing?

Most often, it’s the lead tester. They have the necessary distance, can look at things from the client’s perspective, and have the experience to spot what might cause issues. The analyst’s view is also important — they verify whether the solution matches the requirements and design. The tester, on the other hand, tries different scenarios that a developer might not even think of.

So the type of testing depends on the type of project?

Exactly. For example, with web systems accessible from the internet, we also perform penetration tests to verify security. If the project works with sensitive data, security testing is essential. The types of tests are proposed by the quality assurance manager, always according to the specific project.

Are you still part of the project even when the client is already deploying it themselves?

Yes, even when the client controls the deployment, we stay in touch. We hold regular status meetings, monitor feedback from testing, address bugs, and track the schedule. The project is “alive” until the system is stably running in production. And then comes the phase of increased care.

What does increased care mean?

It’s the period after going live, when the whole team remains on standby — some call it “hypercare” or “babysitting.” It lasts a week or two, sometimes even several months, depending on the project size. It’s expected that issues may appear in live operation that didn’t surface during testing, and they need to be resolved quickly.

And after this phase?

Then the project officially transitions into standard service mode. All requests and incidents are handled through the service channel — for example, a helpdesk — and according to the service agreement, specific response times apply depending on the priority of the requests.

When do you feel a real sense of satisfaction from a project?

The first sigh of relief usually comes when the system goes live — but not always. It depends on whether it’s the final phase or just one of many. A project manager is constantly on the move, always solving something, and sometimes there’s barely time to stop and reflect on what’s been achieved.

Do you take work home with you?

I used to, but now only when it’s really necessary — for example, during deployment or when we’re dealing with something urgent in production. It also depends on the SLA — whether we have 24/7 support or only during business hours. Everything is based on the agreement with the client.

So you’re always “on call”?

Yes, but it’s not dramatic. Most communication happens via email or Teams — depending on what we use with the client.

And how do you clear your head afterward?

By closing the office door. I have a dog, so I go for walks — that’s my way of maintaining mental balance. And sports. That helps me the most.

So sports are your outlet?

Definitely. And also having a community and hobbies outside of work — simply keeping a healthy work-life balance.

What do you do in your free time?

Mostly sports. That’s a bit of a professional deformation — even there I end up coordinating something (laughs). I’m part of a Spartan training group.

Spartan Race?

Yes, I participate in all levels. It’s a challenge for me, a completely different world. At work, you use your mind; here, it’s all about the body. You find yourself in situations you couldn’t have imagined before, and you realize you can handle them. That pushes you forward. And then there’s triathlon — that was really extreme for me because I couldn’t swim at all before. I had to learn to swim first, and right after that, I did my first triathlon: swimming, cycling, running.

How do you decide to do a triathlon?

One day you just say to yourself, “Why not?” — and there’s no turning back.

What led you to it?

My partner does triathlons, and I once promised him I’d try it too — that I’d learn to swim and complete at least one triathlon.

So you’re a bit of an extremist — both at work and in your private life?

Maybe a little. But when you do it with your partner or with a community of people who motivate you, it’s different. Some people go for a beer with friends — we go for a run.

How often do you train?

Every day. It depends on the type of training — swimming in the pool or lake, running (I prefer outdoors), cycling indoors on a trainer in winter, outdoors in summer. Strength training either at the gym or outside, depending on my mood.

And does work influence you outside of it — do you have any “professional habits”?

Definitely. For example, at a friend’s wedding — she wanted to organize everything herself but couldn’t manage. So I spontaneously stepped in, started assigning tasks, calming people down... Her mother-in-law eventually asked me if I do this professionally. It just happens naturally.

What do you consider the essential traits of a good project manager?

Pragmatism and emotional resilience. We often deal with issues that aren’t just about the project itself — sometimes it’s interpersonal disagreements, other times pressure from management or the client. And you can’t take it personally. Some decisions might not align with your own opinion, but your job is to implement them and see the project through to completion.

Anything else?

Definitely communication skills — without them, a project can’t move forward. You have to be able to talk to the team, the client, management — but also listen. And you have to be perceptive toward people; projects aren’t done by spreadsheets, but by people. They need to know what to do, be motivated, and feel that their work matters. Diplomacy is also important — that’s something I had to learn. I’m naturally straightforward, but not everyone likes to hear things “as they are.” Sometimes it’s not what you say, but how you say it. And even though I’ve been doing this for years, I’m still learning. Every project is different, every client has different needs.

What’s the last thing you learned?

There’s always something new — especially when it comes to working with people. For example, recently I had to deal with a situation where two colleagues couldn’t understand each other: one was factual and pragmatic, the other expected a more friendly approach. Both had their point of view — they just weren’t listening to each other. So I “translated” it for them, from each one’s perspective. It was a bit of a mediation moment.

That’s the beauty of this job — you’re a project manager, but sometimes also a translator, kindergarten teacher, and mediator. And even though I often deal with problems, I enjoy the process. I like understanding what the client needs, what the analysts, developers, and testers do, and how we all work together. When we explain to the client that something isn’t technically possible, I can put it in understandable terms and find a compromise. And with developers, when things seem complicated, we can find simpler solutions together. But that’s only possible if you understand at least the basics — the high-level view of what we’re doing. And that’s what keeps me in this job — that in every project, I learn something new. Whether it’s about technology, processes, or deployment methods — there’s always something that helps me grow.