Analyst’s Perspective
3 Questions for the Expert. Katarzyna Stramol
IT projects are not only about technology. They are, above all, about people, relationships, and everyday organizational challenges. What truly determines the success (or failure) of implementations, how to recognize the first warning signs of problems, and why empathy is just as important as technical competence – these are the themes discussed by Katarzyna Stramol, an experienced business systems analyst. Learn how to build projects not just “in line with scope” but, more importantly, effectively and with people in mind.
What is the worst project situation you remember?
I wouldn’t point to one specific case, but rather to a recurring pattern that appears in different projects. It’s the moment when a project stops being a technological challenge and turns into a human and organizational one.
In such cases, the team faces multiple overlapping difficulties, including overload, unclear division of roles, strained communication, the unavailability of key personnel, or insufficient decision-making support. Combined with time pressure and high expectations, even the most committed individuals may feel overwhelmed.
From my perspective, as an analyst, the hardest situations are those where there is no room for genuine dialogue. If we fail to discuss goals, constraints, and context, and focus on “delivering scope,” the risk of misunderstanding, frustration, and loss of quality increases.
Triggers worth identifying early:
Every organization and project is different, but some warning signs appear regularly:
- Vaguely defined roles and responsibilities, leading to blurred decisions or competence conflicts.
- An underestimated budget compared to the scope of expectations, which results in growing time pressure and dissatisfaction (“we’re paying for a Fiat but expecting a Ferrari”).
- Lack of open, partnership-based communication – especially when strong emotions or difficult personalities appear in key roles.
- A team where responsibility effectively falls on a single person, which can cause burnout and, as a consequence, weaken the entire project.
What helps to better understand client needs in your view?
Attention to people. Understanding the client doesn’t come only from analyzing provided requirements – it emerges in relationships, in listening, empathy, and trust. Great collaboration is not just about tasks, but about goals, worries, and the context in which the organization operates.I believe that by creating a safe and open atmosphere during the first workshops, we can ensure that the quality, efficiency, and benefits of the project results will be unimaginably greater than in a situation where we neglect this, and the client doesn’t have it embedded in their organizational culture. Unfortunately, that is often the case ☹
During work with the client, I think it’s essential to ask questions:
About goals and context:
- What does the client really want to achieve – beyond the implementation itself?
- How does this project fit into the broader company strategy?
- What happens if the project succeeds? And what if it doesn’t?
About constraints and challenges:
- What constraints (time, budgetary, organizational) do stakeholders see?
- How have previous IT project experiences shaped their expectations?
- Where, according to the client, “might it hurt” – what are their greatest fears?
About collaboration and communication:
- Who on the client’s side really knows the subject? Who makes the decisions?
- Does the team feel comfortable expressing opinions and asking questions?
- Does the client treat the project as a joint venture, or more like “we pay – you deliver”?
And, of course, about end users:
- Who will be using the solution?
- What does their daily work look like? What are their needs, frustrations, and habits?
- What changes will implementation bring to their work, and how do they feel about them?
Are project bottlenecks common, and do clients notice them?
Definitely yes – and they often appear earlier than we manage to name them. In practice, these are not always spectacular blockades, but rather obstacles invisible at first glance, which slow down progress and accumulate risk.
The most common causes of bottlenecks I observe in projects are:
- Limited availability of decision-makers – key decisions are delayed or made without context, affecting the quality and pace of work.
- Integration bottlenecks – e.g., lack of test environments, overburdened client-side integration teams, or lack of knowledge about source systems.
- Insufficient involvement of subject matter experts – even the best-described business process loses value if we can’t confront it with operational practice.
Understanding these limitations requires empathy and a broader perspective – clients often operate in dynamic environments where the IT project is just one of many activities. In such a context, it’s easy to overlook growing dependencies or overestimate the team’s availability.
