Warum gute Anforderungen über den Erfolg von IT-Projekten entscheiden

Die meisten IT-Projekte scheitern nicht an der Technologie. Sie scheitern an unklaren, widersprüchlichen oder schlicht fehlenden Anforderungen. Wer schon einmal erlebt hat, wie ein Projekt nach Monaten der Entwicklung in eine völlig falsche Richtung gelaufen ist, weiss: Das Problem begann nicht beim Entwicklerteam. Es begann am Anfang – dort, wo niemand genau genug hingeschaut hat.

In der Beratung sehe ich das immer wieder. Unternehmen investieren sechsstellige Beträge in neue Software, Cloud-Migrationen oder Digitalisierungsprojekte – und starten ohne saubere Anforderungsdokumentation. Nicht aus Nachlässigkeit, sondern weil der Wert dieses Schrittes unterschätzt wird. Dieser Beitrag zeigt, warum gute Anforderungen den Unterschied zwischen Projekterfolg und teurem Fehlschlag machen – und wie KMU das Thema pragmatisch angehen können.

Das Grundproblem: Alle reden, aber niemand schreibt es auf

In vielen KMU beginnt ein IT-Projekt mit einem Meeting. Jemand aus der Geschäftsleitung sagt: «Wir brauchen ein neues CRM» oder «Unsere Prozesse müssen digitalisiert werden». Es wird diskutiert, Köpfe nicken, und dann geht ein Auftrag an die IT-Abteilung oder einen externen Dienstleister. Das Problem: Was genau gebraucht wird, wurde nie präzise festgehalten.

Was folgt, ist ein Muster, das sich in der Praxis ständig wiederholt. Der Dienstleister interpretiert die vagen Aussagen nach bestem Wissen. Die Fachabteilungen haben unterschiedliche Vorstellungen, die nie abgeglichen wurden. Und wenn nach drei Monaten ein erster Prototyp steht, kommt der Satz: «Das ist nicht das, was wir gemeint haben.»

Dieser Moment ist teuer. Nicht nur finanziell, sondern auch in Bezug auf Vertrauen, Motivation und Projektdynamik. Und er wäre in den meisten Fällen vermeidbar gewesen – mit einer strukturierten Anforderungsaufnahme am Anfang.

Lastenheft vs. Pflichtenheft: Was KMU wirklich brauchen

In der klassischen Projektmethodik unterscheidet man zwischen Lastenheft und Pflichtenheft. Das Lastenheft beschreibt, was der Auftraggeber braucht – aus seiner Perspektive, in seiner Sprache. Das Pflichtenheft beschreibt, wie der Auftragnehmer das umsetzen will – technisch, konzeptionell, architektonisch.

Für KMU ist das Lastenheft der entscheidende Schritt. Es zwingt dazu, die eigenen Bedürfnisse klar zu formulieren, bevor man mit Anbietern spricht. Das klingt trivial, ist es aber nicht. Denn es erfordert, dass verschiedene Abteilungen ihre Anforderungen zusammentragen, Widersprüche aufdecken und Prioritäten setzen.

Ein gutes Lastenheft muss kein 80-seitiges Dokument sein. Für viele KMU-Projekte reichen 10 bis 20 Seiten – wenn sie die richtigen Fragen beantworten: Was soll das System können? Wer arbeitet damit? Welche Prozesse soll es abbilden? Was sind die absoluten Muss-Kriterien, und was ist Nice-to-have? Welche Schnittstellen zu bestehenden Systemen gibt es?

Die häufigsten Fehler bei der Anforderungsaufnahme

Anforderungen werden zu technisch formuliert

Ein klassischer Fehler: Die IT-Abteilung schreibt die Anforderungen, und alles klingt nach Datenbanken, APIs und Schnittstellen. Die Fachabteilungen verstehen nichts, nicken trotzdem ab – und merken erst bei der Abnahme, dass ihre tatsächlichen Bedürfnisse nicht berücksichtigt wurden. Gute Anforderungen beschreiben das Was und Warum aus Geschäftssicht. Die technische Umsetzung kommt danach.

Stakeholder werden nicht einbezogen

Oft entscheidet die Geschäftsleitung über ein System, das primär von Sachbearbeitern genutzt wird. Deren Perspektive fehlt dann im Anforderungsdokument. Die Folge: Das neue System sieht auf dem Papier gut aus, wird aber im Alltag nicht akzeptiert, weil es an den tatsächlichen Arbeitsabläufen vorbeigeht.

Alles ist gleich wichtig

Wenn ein Lastenheft 150 Anforderungen enthält und alle als «Muss» markiert sind, ist das Dokument wertlos. Priorisierung ist der schwierigste, aber wichtigste Teil der Anforderungsarbeit. Ein ehrliches Gespräch darüber, was wirklich geschäftskritisch ist und was warten kann, spart später enorm viel Geld und Zeit.

Anforderungen werden einmal geschrieben und nie wieder angepasst

Die Welt verändert sich. Märkte, Prozesse, Prioritäten – alles ist in Bewegung. Ein Anforderungsdokument, das vor zwölf Monaten geschrieben wurde und seither in einer Schublade liegt, hilft niemandem. Anforderungen müssen leben und regelmässig überprüft werden. Das heisst nicht, dass man ständig alles umwirft – aber eine quartalsweise Überprüfung, ob die definierten Anforderungen noch zu den Unternehmenszielen passen, ist essenziell.

Anforderungen in agilen Projekten: Ein Widerspruch?

Manche denken, dass Anforderungsmanagement nur etwas für klassische Wasserfallprojekte ist. In agilen Projekten arbeite man schliesslich iterativ – da brauche man kein Lastenheft. Das ist ein gefährliches Missverständnis.

Auch in agilen Projekten braucht man ein klares Verständnis davon, was erreicht werden soll. Der Unterschied liegt darin, dass man nicht alles bis ins letzte Detail vorab definiert, sondern in grösseren Blöcken denkt und diese iterativ verfeinert. Eine Product Vision, klar formulierte Epics und gut geschriebene User Stories sind nichts anderes als Anforderungen – nur anders verpackt.

Was in agilen Projekten trotzdem oft fehlt, ist der Gesamtrahmen. User Stories beschreiben Einzelteile. Aber wer definiert, wie diese Einzelteile zusammenpassen? Wer stellt sicher, dass am Ende ein kohärentes System entsteht und nicht eine Sammlung von Einzelfunktionen? Genau hier braucht es ein übergeordnetes Anforderungsdokument – nennen Sie es Lastenheft, Product Brief oder Projektrahmen. Der Name ist egal. Der Inhalt zählt.

Was gute Anforderungen ausmacht

Gute Anforderungen haben einige gemeinsame Merkmale, unabhängig davon, ob Sie klassisch oder agil arbeiten. Sie sind verständlich – jeder Beteiligte, vom Geschäftsführer bis zum Entwickler, kann sie lesen und verstehen. Sie sind überprüfbar – man kann am Ende eindeutig feststellen, ob eine Anforderung erfüllt ist oder nicht. «Das System soll schnell sein» ist keine Anforderung. «Die Suchergebnisse sollen innerhalb von zwei Sekunden angezeigt werden» ist eine.

Gute Anforderungen sind ausserdem priorisiert. Nicht alles kann gleichzeitig und mit der gleichen Dringlichkeit umgesetzt werden. Und sie sind nachvollziehbar – es ist dokumentiert, warum eine Anforderung existiert und wer sie eingebracht hat. Das hilft enorm, wenn später Diskussionen über den Projektumfang aufkommen.

Der Zusammenhang zwischen Anforderungen und Kosten

Es gibt eine Faustregel in der Softwareentwicklung, die seit Jahrzehnten Bestand hat: Je später ein Fehler in der Anforderungsdefinition entdeckt wird, desto teurer ist seine Behebung. Ein Missverständnis, das in der Anforderungsphase aufgeklärt wird, kostet ein Gespräch. Dasselbe Missverständnis, das erst beim Go-live auffällt, kann eine komplette Neuentwicklung nach sich ziehen.

Für KMU, die oft mit begrenzten Budgets arbeiten, ist das besonders relevant. Die Investition in eine saubere Anforderungsphase – typischerweise fünf bis zehn Prozent des Gesamtprojektbudgets – zahlt sich fast immer aus. Nicht als abstraktes Qualitätsmerkmal, sondern in konkreten Franken und Rappen, die nicht für Nachbesserungen, Change Requests und Frustration ausgegeben werden müssen.

Pragmatisch starten: So geht Anforderungsmanagement für KMU

Anforderungsmanagement muss nicht komplex sein. Für die meisten KMU-Projekte reicht ein pragmatischer Ansatz, der aus drei Schritten besteht.

Erstens: Stakeholder identifizieren und einbeziehen. Wer nutzt das System? Wer entscheidet über Budget und Prioritäten? Wer hat Fachwissen über die betroffenen Prozesse? Diese Personen gehören an den Tisch – nicht erst bei der Abnahme, sondern von Anfang an.

Zweitens: Workshops statt Einzelinterviews. In gemeinsamen Workshops kommen Widersprüche und unterschiedliche Erwartungen sofort auf den Tisch. Das ist unbequem, aber extrem wertvoll. Wenn der Vertrieb sagt «Wir brauchen maximale Flexibilität» und die Buchhaltung sagt «Wir brauchen standardisierte Prozesse», ist das ein Konflikt, der gelöst werden muss – und zwar vor dem Projektstart, nicht währenddessen.

Drittens: Dokumentieren und priorisieren. Alles, was besprochen wurde, wird festgehalten. Nicht in Roman-Länge, sondern strukturiert und klar. Jede Anforderung bekommt eine Priorität. Und das Ergebnis wird von allen Beteiligten freigegeben – schriftlich, nicht nur mündlich.

Fazit: Die beste Investition am Anfang eines Projekts

Gute Anforderungen sind kein bürokratischer Overhead. Sie sind die Grundlage dafür, dass IT-Projekte das liefern, was das Unternehmen tatsächlich braucht. Sie reduzieren Kosten, vermeiden Frustration und schaffen eine gemeinsame Basis zwischen Business und IT.

Wer diesen Schritt überspringt, spart am falschen Ende. Die paar Tage oder Wochen, die eine saubere Anforderungsaufnahme kostet, sind die beste Investition, die Sie in Ihr nächstes IT-Projekt machen können.