Why Good Requirements Determine the Success of IT Projects

Most IT projects don't fail because of technology. They fail because of unclear, contradictory, or simply missing requirements. If you've ever watched a project veer off course after months of development, you know the truth: the problem didn't start with the development team. It started at the very beginning -- where nobody looked closely enough.

In my consulting work, I see this pattern constantly. Companies invest six-figure sums in new software, cloud migrations, or digitisation projects -- and start without proper requirements documentation. Not out of carelessness, but because the value of this step is underestimated. This article explains why good requirements make the difference between project success and expensive failure -- and how SMEs can approach the topic pragmatically.

The core problem: Everyone talks, but nobody writes it down

In many SMEs, an IT project begins with a meeting. Someone from the executive team says: "We need a new CRM" or "Our processes need to be digitalised." There's a discussion, heads nod, and then a brief goes to the IT department or an external service provider. The problem: what exactly is needed was never precisely defined.

What follows is a pattern that repeats itself constantly in practice. The service provider interprets the vague statements to the best of their knowledge. Different departments have different expectations that were never reconciled. And when a first prototype appears after three months, someone inevitably says: "That's not what we meant."

That moment is expensive. Not just financially, but also in terms of trust, motivation, and project momentum. And in most cases, it could have been avoided -- with a structured requirements gathering process at the beginning.

Requirements specification vs. technical specification: What SMEs actually need

In traditional project methodology, there's a distinction between the business requirements document and the technical specification. The business requirements document describes what the client needs -- from their perspective, in their language. The technical specification describes how the provider intends to implement it -- technically, conceptually, architecturally.

For SMEs, the business requirements document is the decisive step. It forces you to clearly articulate your own needs before speaking with vendors. That sounds trivial, but it isn't. Because it requires different departments to bring their requirements together, uncover contradictions, and set priorities.

A good business requirements document doesn't need to be an 80-page document. For many SME projects, 10 to 20 pages suffice -- as long as they answer the right questions: What should the system do? Who will use it? Which processes should it support? What are the absolute must-have criteria, and what's nice-to-have? What interfaces to existing systems are needed?

The most common mistakes in requirements gathering

Requirements are formulated too technically

A classic mistake: the IT department writes the requirements, and everything sounds like databases, APIs, and interfaces. The business departments don't understand any of it, nod along anyway -- and only realise during acceptance testing that their actual needs weren't addressed. Good requirements describe the what and why from a business perspective. The technical implementation comes afterwards.

Stakeholders aren't involved

Often, the executive team decides on a system that will primarily be used by operations staff. Their perspective is then missing from the requirements document. The result: the new system looks great on paper but isn't adopted in daily work because it doesn't match actual workflows.

Everything is equally important

When a requirements document contains 150 requirements and all are marked as "must-have," the document is worthless. Prioritisation is the hardest but most important part of requirements work. An honest conversation about what's truly business-critical and what can wait saves enormous amounts of money and time later on.

Requirements are written once and never revisited

The world changes. Markets, processes, priorities -- everything is in motion. A requirements document written twelve months ago that has been sitting in a drawer since helps nobody. Requirements need to live and be reviewed regularly. That doesn't mean constantly overhauling everything -- but a quarterly review to check whether the defined requirements still align with business objectives is essential.

Requirements in agile projects: A contradiction?

Some people think that requirements management is only for traditional waterfall projects. In agile projects, you work iteratively after all -- so you don't need a requirements document. That's a dangerous misconception.

Even in agile projects, you need a clear understanding of what should be achieved. The difference is that you don't define everything in granular detail upfront, but think in larger blocks and refine them iteratively. A product vision, clearly formulated epics, and well-written user stories are nothing other than requirements -- just packaged differently.

What's often missing in agile projects, however, is the overall framework. User stories describe individual pieces. But who defines how those pieces fit together? Who ensures that a coherent system emerges at the end, rather than a collection of individual features? This is exactly where an overarching requirements document is needed -- call it a requirements specification, product brief, or project framework. The name doesn't matter. The content does.

What makes good requirements

Good requirements share certain characteristics, regardless of whether you work in a traditional or agile way. They are understandable -- every stakeholder, from the CEO to the developer, can read and understand them. They are verifiable -- at the end, you can clearly determine whether a requirement has been met or not. "The system should be fast" is not a requirement. "Search results should be displayed within two seconds" is.

Good requirements are also prioritised. Not everything can be implemented simultaneously with the same urgency. And they are traceable -- it's documented why a requirement exists and who raised it. This helps enormously when discussions about project scope arise later.

The connection between requirements and costs

There's a rule of thumb in software development that has held true for decades: the later a requirements error is discovered, the more expensive it is to fix. A misunderstanding that's cleared up during the requirements phase costs a conversation. The same misunderstanding discovered only at go-live can trigger a complete redevelopment.

For SMEs working with limited budgets, this is particularly relevant. The investment in a clean requirements phase -- typically five to ten percent of the total project budget -- almost always pays off. Not as an abstract quality metric, but in concrete money that doesn't need to be spent on rework, change requests, and frustration.

Getting started pragmatically: Requirements management for SMEs

Requirements management doesn't have to be complex. For most SME projects, a pragmatic approach consisting of three steps is sufficient.

First: Identify and involve stakeholders. Who uses the system? Who decides on budget and priorities? Who has domain expertise about the affected processes? These people belong at the table -- not at the acceptance stage, but from the very beginning.

Second: Workshops instead of individual interviews. In joint workshops, contradictions and differing expectations surface immediately. That's uncomfortable but extremely valuable. When sales says "We need maximum flexibility" and accounting says "We need standardised processes," that's a conflict that needs resolving -- before the project starts, not during it.

Third: Document and prioritise. Everything discussed gets recorded. Not at novel length, but structured and clear. Every requirement gets a priority. And the result is signed off by all participants -- in writing, not just verbally.

Conclusion: The best investment at the start of a project

Good requirements are not bureaucratic overhead. They are the foundation for IT projects delivering what the business actually needs. They reduce costs, prevent frustration, and create a shared basis between business and IT.

Skipping this step means saving in the wrong place. The few days or weeks that a proper requirements gathering process costs represent the best investment you can make in your next IT project.