Classic Mistakes Systems Analysts Make on IT Projects

Let's go through the typical missteps systems analysts make on large enterprise projects — I'm talking banking and fintech specifically, because I've been stewing in this world for a long time. What exactly goes sideways when you're surrounded by legacy systems, hard regulation and a dozen stakeholders with conflicting interests — and how to shave off the risk early.

1. Vague, under-detailed requirements

The classic — high-level phrasing with no acceptance criteria. Example: "We need convenient money-transfer functionality for corporate clients." Without scenarios, metrics and clarifications about transaction types and limits, development drowns in guesswork and the business doesn't get what it was waiting for.

Recommendation, or "here's your band-aid ))"

Define a KPI for every requirement, write out the use cases together with their edge cases, and sign them off with business and engineering before you start. And squeeze the most out of your BA resource, if you have one.

2. Ignoring the architectural environment and integrations

Analysis in a bank doesn't live in a vacuum: a new feature has to fit into a landscape that's already running. And this is exactly where analysts routinely underestimate integration — with legacy systems, with payment-provider gateways — or they simply never draw a model of how the old and the new interact. The outcome is predictable: effort blows up, deadlines drift, and sometimes the whole thing has to be rewritten from scratch, and in a different language on top of that.

Recommendation, or "here's your band-aid ))"

At the start, study the architecture artifacts, dig out the constraints — throughput, latency, regulation, data formats — and agree on the integration strategy with the architects and your fellow analysts.

3. Weak grasp of the domain and its regulation

An analyst who buries themselves in the technology and ignores the specifics of the banking industry — from PCI DSS to mandatory regulatory reporting — is planting a mine under compliance. Fail to reflect the KYC (Know Your Customer) requirements in the spec, and the product ships with holes that will surface at the worst possible moment. And the requirements inside each domain can be extremely specific.

Recommendation, or "here's your band-aid ))"

Study the domain regulations and bake in the supervisory bodies' requirements at the early stages. If you have to, pull in domain experts and legal to gather every nuance before the final formalization. Formally this is the business-requirements stage, but you and I both know: the BA and the SA are often the same person!

4. Under-worked negative scenarios

A fintech system isn't a set of scripts — it's a complex process where fault tolerance, error handling and boundary checks aren't a bonus but a mandatory part of the product. Overlook the negative scenarios — a dropped connection, a malformed payment-details format, exceeded limits, an unavailable API — and enjoy the surprises straight in production.

Recommendation, or "here's your band-aid ))"

Put test scenarios with erroneous and atypical data right into the specs. Stay in touch with QA — together you'll find and describe the failure points. And don't forget your beloved support and infosec teams: those two will happily throw in cases.

5. No early validation of concepts

Writing documentation for the drawer, with no feedback from developers or end users, is another classic. The later the ambiguities and contradictions surface, the more expensive they are to fix afterward. As a lead, I know that price from my own skin.

Recommendation, or "here's your band-aid ))"

Work in short iterations with intermediate checkpoints. Prototype the key scenarios and run them past engineering, architects, security folks and the business. That way, even before implementation kicks off, it becomes clear what needs tightening and where.

---

Systems analysis in large banks and fintech isn't translating business requirements into technical specs word for word. It's work at the intersection of regulation, architecture, security, user experience and economics. The more precisely you hold that balance, the smaller the chance the project slams into an unaccounted-for constraint or collapses under the weight of forgotten scenarios. Attentive, meticulous, well-thought-out analyst work is not just a successful release, but the product's reputation in the market.

P.S. just a bit of thinking out loud — or, well, my own analysts keep forcing me to think about this constantly....

---

Originally published on my Telegram channel @it_underside.

Yours, DPUPP