"A consultant is a bridge between technology and reality," an IT consultant on software deployment, field work, and solving invisible problems

Many people don’t have a clear idea of what an IT consultant actually does. How would you describe this job to someone outside the IT world?

I like to explain it this way — an IT consultant is someone who’s involved in all phases of software development and its implementation in practice. I communicate with the customer, understand their needs, take part in designing the solution, and oversee its realization. I test the software, optimize its performance, and finally help deploy it into production. A consultant therefore sees the product throughout its entire life cycle and bridges the gap between the technical side and real user needs.

Which parts of the project are under your responsibility as a consultant?

I divide a project into three main phases: development, deployment into production, and production support. I’m not very involved in the very first, pre-development phase. That’s when the analytical part takes place — determining exactly what the system should do, what the client’s requirements and processes are, what technical constraints exist, and so on. This phase is mainly handled by the analyst, together with the project manager and the client.

I get involved once the specification is approved — when we already know what needs to be developed and development can begin. In this phase, I prepare test scenarios, meaning specific situations we’ll later test to ensure the software does what it’s supposed to. I also start communicating with the client to fine-tune details that couldn’t be resolved earlier — for example, what the data connections should look like, what devices will connect to the system, or what the user interface should look like.

At the same time, I plan how the system will be deployed into real operation — what steps need to be taken to make everything go smoothly. Who will be trained and when, what needs to be prepared in the infrastructure, what kind of testing will happen at the client’s site, and how we’ll make sure everything works flawlessly from day one of live operation. This preparation is crucial to prevent problems later on that could cause downtime or delays.

How does the actual deployment of the system into production work?

We first deploy the system into a so-called pre-production environment — basically a simulation of the client’s real environment, but without live data and without the risk of disrupting company operations. There, we thoroughly test the system again, verify all developed functionalities, and fine-tune it according to the customer’s specific needs. It’s a very intense phase because we’re already bringing a finished solution into a real environment.

At this stage, we work with the client directly in their warehouse or production area — we’re physically present there. We test the system on their actual devices, whether it’s stacker cranes, conveyors, or other technologies that need to be integrated with the system. We try to simulate all possible situations that might occur in real operation, so we can identify and fix them before the system goes live.

Only when everything is fine-tuned, when we’re sure all integrations work, processes are correctly configured, and the client’s people know how to use the system, do we move on to deployment in production — into live operation.

At that point, my role in production support begins. During the first few days after deployment, I stay in close contact with the client, monitor how the system behaves in live operation, help resolve any minor issues, answer user questions, and make adjustments if needed. This is the period when we have to stay alert to support the client and ensure a smooth transition to their new reality.

Which phase is the most intense for you?

Definitely pre-production. That’s when we already have the completed system — the software is programmed according to the requirements — but that doesn’t yet mean everything works perfectly. Quite the opposite: in this phase, everything comes together like a puzzle. We fine-tune details, verify whether the designed processes actually work in practice, and test them directly in the client’s environment.

The big challenge is that we’re no longer working only with code or theory — real technologies come into play: machines, conveyors, stacker cranes, scanners, terminals… Every device has its specifics and must communicate properly with the system. We also interact with different people — from technicians and warehouse workers to management. Everyone expresses themselves differently and has different expectations, so communication is just as important as technical knowledge in this phase.

If we handle the pre-production phase well — fine-tune everything, train the users, and make sure the client understands what they’re getting — then the production phase is much calmer. The system just “switches” to live operation, and we’re only needed for minor issues that might arise in practice. Ideally, it’s about being available — not putting out fires.

Who do you communicate with most during the different project phases?

During development, mostly with developers — I help identify issues, whether in the code or potential problems that could appear in real operation. In pre-production, communication intensifies with analysts and the customer. In production, we primarily handle feedback or new requests from the customer.

What does software testing include? Is it the tester’s job, or does the consultant test as well?

Testing is also part of the consultant’s job. When a developer finishes a software feature, the consultant receives it for testing. We first test it internally, simulating real-world processes. We look for bugs, check whether the system behaves as expected, and request fixes if necessary. Then we test it directly at the customer’s site to see how it performs in real conditions.

How different is testing in the office compared to real operation?

Very different. In the office, we test interactions within the software — buttons, data displays, processes. But in real operation, physical factors come into play. Sometimes we find that the software works perfectly, but in practice it runs into issues. That’s why field testing is so important.

Can you describe how software deployment into production happens?

After testing is completed both internally and at the customer’s site, we move to the live deployment phase — meaning the system starts being used in real operation. During this time, we’re often physically present with the customer, observing how the system behaves and helping to resolve initial issues. Afterward, we provide remote support, but for major updates or significant changes, we return on-site to ensure a smooth transition.

How do you identify problems during development or testing?

I go through the test scenarios that represent real-world processes. If I find an issue, I describe it and report it to the developer. It’s important to correctly identify whether it’s a bug or a new requested feature — that’s a crucial part of my job.

 

How does communication differ with different types of people on a project?

Every day I deal with something different. In the morning it might be a warehouse worker, later a data analyst — the language and form of communication must be adapted to the situation. A consultant has to be able to communicate with both worlds, the technical and the non-technical.

What is your role after the system is deployed?

I usually remain part of the project, either as the lead consultant or as someone who can step in. If new requirements appear, we handle them. I also communicate with the hotline; if a problem is more serious, it gets discussed to me.

What happens if the customer needs to expand the system or add new features?

Such requests often come when the customer is growing or adjusting their processes. First, we analyze exactly what they need, then we consult with the analyst and the development team on how to implement it technically into the existing system. After development, testing and deployment follow again. The challenge is that our customers operate continuously, so we have to carry out updates with minimal impact on their operations.

Despite thorough testing, unexpected situations appear in production. What has surprised you already?

Many times it turns out the problem isn’t in the software but in the environment itself or the human factor. For example, we had an access control system using chip cards where employees logged in via scanners. We kept getting reports that the system wasn’t working properly, but in internal tests everything was fine. Only during an on-site visit did we find out that someone on the floor had installed a metal cabinet that was blocking the signal. This type of issue can’t be caught in simulations — on site we have to be a bit like detectives.

So is the consultant often also a detective?

When we receive a report that something isn’t working, we have to analyze the entire process second by second to find the source of the problem. Sometimes the solution is immediate — we see an obvious error. Other times it’s a complex interplay of factors, where, for example, several operations occurred at the same second and the software reacted unpredictably. That can only be discovered through detailed analysis and experience.

How does working on projects with fully automated technologies differ from those with many manual processes?

With manual systems, there’s a lot of interaction with workers — we focus on how they’ll use the system, train them, and adjust processes to suit their needs. With fully automated systems, the focus shifts to integrations. Many issues in such solutions arise from communication between different systems.

For example, our software might be programmed correctly, but if an external system doesn’t respond properly or experiences downtime, we need to look for solutions beyond our own application. It often happens that an external system undergoes a scheduled update without informing us, and suddenly we start receiving reports that nothing is working. These are situations we have to be able to predict and resolve.

What’s the most extreme situation you’ve had to deal with?

The most unpredictable ones are physical interventions in infrastructure. For instance, there was a case where cables providing communication between the system and the servers were accidentally cut in a hall. The entire operation stopped, and no one knew why. It took us hours to identify the issue, and we had to secure temporary fixes overnight to keep the company running. You can’t really prepare for situations like that in advance — only experience and having a clear contingency plan for unexpected outages help.

Have you experienced nighttime incidents?

Yes, in the past — especially during critical deployments. Some operations run 24/7, so it doesn’t matter if it’s day or night — if a problem occurs, we have to respond. But if a project is well-prepared and the pre-production phase is handled properly, most incidents can be minimized.

Every company uses different processes and technologies. Do you notice interesting differences?

Absolutely. Two companies with the same type of production can have completely different technologies. One might use semi-automated solutions with a lot of human involvement, while another runs fully robotized lines. That’s what makes this job fascinating — we see how different approaches translate into productivity and results. Every project teaches us something new.

Which industry do you find the most interesting in your work?

I enjoy warehouses and logistics the most — especially those with large volumes of goods. There, we deal not only with software but also with spatial optimization: how to arrange goods efficiently, how to design the warehouse layout, and how to make movement as fast as possible. The more complex the warehouse, the bigger the challenge, because we have to consider not just IT processes but also physical factors such as temperature zones, material handling, and safety regulations.

Do you see everyday things differently compared to most people?

Definitely. For example, when I shop and see self-checkout systems or scanners, I immediately notice how the system is designed — whether it’s intuitive, what potential issues there are. I often find myself thinking about how I could “break” it — which is basically the same mindset we use when testing software.

What is the most important skill for an IT consultant?

Analytical thinking and problem-solving. A consultant needs to quickly identify where the problem lies — even if they can’t necessarily fix it themselves. The key is to pinpoint exactly where the issue is and who should handle it. Often, our role is diagnostic — we investigate what went wrong and help developers or clients find the best solution. That requires not only experience but also the ability to keep learning.

What new challenges does the role of a consultant bring?

Every new project brings something different. Even if the technologies are similar, every client has their own specifics. That means that even when you think you know something inside out, something new can always surprise you — and that’s exactly what makes this job so interesting.

When optimizing processes, you have to focus on details. What factors determine efficiency?

It’s often the small things that have a huge impact on efficiency. For example, if someone works ten hours a day with a scanner and constantly presses a button on one side of the device, simply moving the button to the other side can significantly improve their performance. We have to identify such details during testing, put ourselves in the employee’s shoes, and see how the system affects their daily work.

That must require a lot of communication with the customer. How do you handle differences between IT and non-IT users?

Yes, quite often someone calls with a problem described secondhand — the person doesn’t fully understand what’s happening. So we have to ask the right questions quickly and precisely. When someone says “it doesn’t work,” that can mean anything — from a forgotten password to a real technical failure. We need to filter information, stay calm, and focus on quick diagnosis.

Are there any stereotypes about consultants that you think are wrong?

Probably the most common one is that consultants just sit behind a computer and test things. In reality, it’s a very diverse job — besides IT work, we deal with customers, train employees, travel to client sites, and analyze real-world situations. We meet people who aren’t from IT and have to adapt communication so they understand the solution.

Since you’re often in touch with customers, do you ever feel like you’re on the same wavelength with them?

Definitely, especially on long-term projects. Every client has someone responsible for implementation, and when you work with them for a year or two, you naturally get to know each other better. That makes communication more efficient — we can clarify requirements faster and better understand each other’s expectations.

An IT consultant must have some technical knowledge, but how essential is programming?

You don’t have to be a programmer, but you do need to be able to read technical specifications and understand databases. Basic knowledge of code and logical thinking is enough. What’s important is the ability to connect analytical thinking with how the software actually works. If you can’t read a specification, you can’t identify a problem — and if you don’t understand the data behind it, you can’t properly communicate it to the developers.

What soft skills are key for a consultant?

Definitely communication. And also the ability to analyze quickly — to know what’s a priority, what needs to be fixed immediately, and what can wait. A consultant has to be able to identify a problem even when it’s not immediately obvious.

What do you need to keep improving as a consultant?

Mostly working with different technical devices. Every client has something different — new versions, new configurations. I have to learn quickly how each one works and how to connect it properly. I also need to understand the specifics of individual processes, which are often custom-made.

IT consultants work with data, but do you sometimes have to solve physical problems too?

Absolutely. Sometimes we have to intervene physically — move equipment, connect scanners, help set up hardware. It also happens that we uncover attempts to bypass the system — for example, when someone tries to modify data or “simplify” their work in a way that goes against established processes. The system is designed to detect that, and we help customers handle such situations.

When does your work have the greatest impact?

I have the biggest influence during the development phase — while testing and detecting bugs — and then during deployment, when everything has to work perfectly so the customer is satisfied.

What do you enjoy most about your job?

The connection between software and the real world. We get to see how IT solutions affect physical processes. The work is varied, full of new challenges, and when I see that the system I worked on really helps, it’s a great feeling. I also enjoy communicating with customers — being that bridge between technology and real operations.

And the diversity as well. One day I’m dealing with warehouse logistics, another with a production line — testing software, training people, solving unexpected problems. There’s never a day when I’m bored. And the best part is seeing that our solution truly helps the customer — that things work better, more efficiently, and people enjoy using it.

What’s your idea of perfect relaxation after work?

Since the job is mainly mentally demanding, the best way to relax for me is through physical activity. I go to the gym, I run — it helps me clear my mind and recharge for the next day.

If someone wanted to start as an IT consultant, what advice would you give them?

Being a consultant is a great entry point into the IT world because it exposes you to various areas of both IT and business. You learn how developers, analysts, project managers, and customers work. And most importantly, you’ll always be solving new challenges — so if you like a dynamic environment, it’s an excellent career choice.