Analyst’s Perspective
3 Questions for the Expert: Szymon Moskała
Wyobraźcie sobie duży projekt w ogromnej organizacji. Organizacja jasno określa wymagania, a rozwiązania wydają się spójne. Mimo to wiele projektów IT kończy się opóźnieniem. Co więcej, tylko około jedna trzecia organizacji realizuje swoje przedsięwzięcia zgodnie z harmonogramem. I co gorsza – problem rzadko, naprawdę rzadko można „zrzucić” na technologię. Najczęściej tkwi w tym, co dzieje się jeszcze przed napisaniem pierwszej linii kodu.
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?
Warsztaty analityczne często ujawniają rozbieżność między przekonaniem klienta a rzeczywistą wiedzą o jego potrzebach. Klient jest przekonany, że dobrze rozumie swoje procesy, ale w praktyce okazuje się, że nie są one jeszcze jasno opisane. Zdarza się, że klient przychodzi z gotowym zestawem wymagań, które na pierwszy rzut oka wyglądają na spójne i przemyślane. Jednak w trakcie warsztatów – gdy zaczynamy zadawać szczegółowe pytania i symulować konkretne scenariusze – koncepcja ta zostaje wystawiona na ciężką próbę.
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?
Jednym z najtrudniejszych przypadków, z jakimi się spotkałem, był proces zaprojektowany wcześniej przez inny zespół. Zbudowano go jako duży, scentralizowany mechanizm obsługujący wiele różnych scenariuszy. Na poziomie dokumentacji wyglądało to jak jeden spójny proces. Problem w tym że w rzeczywistości była to synteza kilku niezależnych procesów biznesowych oraz ich wariantów. Wszystko to zostało połączone w jedną strukturę, co miało ułatwić zarządzanie i utrzymanie. Przynajmniej na papierze.
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 most common mistakes clients make and could easily avoid?
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
Wielu klientów zakłada, że przygotowanie dokumentu z wymaganiami zamyka temat. Problem polega na tym, że taka dokumentacja bardzo często zawiera luki, uproszczenia albo wręcz nie uwzględnia kontekstu biznesowego. Dopiero rozmowy, warsztaty i wspólna analiza pozwalają wydobyć ukryte założenia, wyjątki, zależności między działami. Bez tego powstaje rozwiązanie „zgodne z dokumentem”, ale niekoniecznie działające zgodnie z rzeczywistością.