Analyst’s Perspective
3 Questions for the Expert: Szymon Moskała
Imagine a large-scale project within a massive organization. The requirements are clear and transparent, and the solutions are consistent. However, statistics have long shown that a large portion of IT projects are delivered late, and only about one-third of organizations complete their initiatives on time. Worse still, the problem rarely, truly rarely, can be “blamed” on technology. Most often, the root of the problem lies in what happens before anyone writes the first line of code.
Why? Szymon Moskała, an experienced business and systems analyst who has witnessed many such situations, shows us some reasons.
What do client workshops reveal?
Analytical workshops often reveal a gap between the client’s belief that they perfectly know and understand their needs and the actual state of knowledge about the processes to replicate in the system. At times, clients present a list of requirements that initially seems both consistent and carefully thought through. However, during the workshops, when we begin to ask detailed questions and simulate specific scenarios, this concept is put to a tough test.
That’s when gaps in logic, certain contradictions, undefined business rules, and sometimes even a lack of shared understanding of terms among people from the same organization come to light. Workshops often also expose inconsistencies between how different departments imagine the functioning of the existing or planned system.
Additionally, workshops allow all participants to structure and organize information about real events that occur in daily work. They help extract knowledge that no one has previously written down, because “everyone knows it.” Only during joint analysis does it become clear how many operational decisions were made based on intuition, not clearly defined rules, and that, in reality, not everyone knows as much as they think, and certainly not everything is as well understood as assumed.
In short, workshops enable us to verify assumptions, expose gaps in requirements, and cooperate with the client to develop an implementable solution.
What was the most difficult process you’ve faced?
One of the most challenging processes I had to deal with was initially prepared by another team, as a large, centralized mechanism encompassing many different operational scenarios. On the documentation level, it seemed like a single coherent process. The problem was that, in reality, it was a synthesis of several independent business processes and their variants. All of them have been merged into one structure to make management and maintenance easier, at least on paper.
At first, this didn’t raise serious doubts. The description was consistent, and the implementation simplified. Yet as the project advanced, it required expansions of the process to include new paths, decision branches, conditions, and exceptions. Over time, it became clear that the whole thing was starting to resemble a spider’s web: changing one rule in one place caused unforeseen effects elsewhere. Maintaining such a structure became increasingly laborious, as did testing or further developing functionality.
The biggest challenge was convincing stakeholders that the original assumption – treating everything as one big process – began to work against the project. We proposed refactoring the entire process by decomposing it – splitting it into smaller, independent modules, which made separate development and maintenance possible for each of them.
This experience taught me that sometimes the attempt to standardize and centralize processes is illusory – and that the courage to challenge an existing concept, even if it seems well-established, is often key to the quality of the solution and the future scalability of the system.
What are the 3 most common mistakes clients could avoid, but make anyway?
Moving to a solution too quickly
Often, a client arrives with a ready vision of functionality, skipping the stage of analyzing actual needs. Instead of focusing on what they want to achieve and why, they immediately state how it should work. That leads to designing a system based on existing habits rather than real goals. A better approach is to model needs and processes first, and only then choose tools and solutions.
Skipping prioritization
Clients often expect the implementation of all functionality at once, without prioritizing or dividing into phases. This limits flexibility, makes testing more difficult, and makes it harder to respond to changes or new needs that arise during the project.
Blind faith in the completeness of initial documentation
Many clients assume that once they’ve prepared a requirements documentation, the topic is closed. The problem is that such documentation often contains gaps, simplifications, or even omits the business context. Only conversations, workshops, and joint analysis allow hidden assumptions, exceptions, and dependencies between departments to surface. Without this, you end up with a solution that is compliant with the documentation but not necessarily working in reality.
