Ziele vs. Anforderungen: Wo liegt der Unterschied?

Ziele und Anforderungen – zwei vermeintlich ganz verschiedene Begriffe. Aber der Schein trügt. Es gibt klare Zusammenhänge. Nur leider wird die Brücke zwischen den Zielen und den Anforderungen in vielen Projekten zuwenig oft geschlagen. Mit einer systematischen Herangehensweise in der Projektinitialisierung und in der Konzeptphase lassen sich viele in späteren Phase möglicherweise auftretende Missverständnisse vermeiden. Bewusste Design-Entscheide in den frühen Projektphasen helfen dabei.

Die Wirkungsziele eines Projekts geben uns einen Soll-Zustand vor. Wo wollen wir am Ende stehen? Was soll mit dem Projekt erreicht werden? Die Abwicklungsziele geben die Rahmenbedingungen vor. Was für Ressourcen stehen uns im Projekt zur Verfügung? Welchen Weg gehen wir zum Ziel? Die Projektziele, also Wirkungs- und -Abwicklungsziele, werden bei Projektstart festgelegt – normalerweise. Aber wofür stehen denn die Anforderungen? Und wann kommen die ins Spiel?

Anforderungen sind konkretisierte Ziele

In einem Projekt gibt es nur wenige Ziele, zumindest im Vergleich zu den Anforderungen. Anforderungen gibt es meistens listenweise. Oft wird der Bezug zwischen Anforderungen und Zielen aber nicht wirklich hergestellt. Denn was sind denn eigentlich Anforderungen anderes als heruntergebrochene Ziele? Detailziele des Projekts. Konkretisierungen der Projektziele. In den frühen Projektphase, z.B. in der Design- oder Konzeptphase, werden die Anforderungen erarbeitet. Dies ist Teil der Projektdisziplin "Requirements Engineering". Und die Ausgangslage dafür bilden eben die Projektziele. Dies zumindest die Theorie.

Und Ziele sind abstrahierte Anforderungen

Schauen wir uns dies noch etwas genauer an. Drehen wir die Zeitachse um und gehen zurück von den Anforderungsliste zu den Zielen. Die Ziele sind im Prinzip die Zusammenfassung der Anforderungen und bilden eine höhere Abstrahierungsebene. Eigentlich sind Ziele und Anforderungen dasselbe. Einfach auf unterschiedlichen Flughöhen oder Betrachtungsebenen. Ein Beispiel verdeutlicht dies. Nehmen wir an, wir möchten ein Softwaresystem bauen, welches uns ermöglicht, unsere Personalressourcen besser zu planen (ein Projektwirkungsziel). Und es soll zudem nicht mehr als CHF 200'000 kosten und bis in einem Jahr eingeführt sein (zwei Projektabwicklungsziele). Dies sind wohl eher Projektziele aus Sicht des Managements (hohe Flughöhe).

Der Projektleiter und sein Projektteam werden wohl mit diesen Managementzielen noch nicht ganz glücklich sein: Was heisst denn konkret "Personalressourcen besser planen können"? Und was heisst "bis in einem Jahr eingeführt"? Das Projektteam muss das genauer wissen und diese Ziele auf die eigene Flughöhe herunterbrechen. Dieses Konkretisieren geschieht in den ersten Projektphasen. Besser könnte z.B. heissen, dass man schneller einen Überblick über bestehende Ressourcenauslastungen erhält. Oder dass man den Ressourcenbedarf im System anmelden kann. Noch konkreter: Das System soll einem Abteilungsleiter per Knopfdruck die Auslastungskurven seiner Mitarbeiter über die nächsten 3 Monate grafisch darstellen. Das entspricht in der Welt der Software-Entwicklung in etwas einer User Story oder einem Use Case. (Für diese grobe Betrachtungsweise soll diese Analogie hier genügen.)

Ziele sind das WAS, Anforderungen das WIE

Beim Herunterbrechen der Projektziele auf Anforderungen im Rahmen des Requirements Engineering wird einem schnell klar, dass es für viele Ziele mehrer Konkretisierungen geben kann. Das Ziel "besser" kann als "schneller", "übersichtlicher" oder auch "kostengünstiger" verstanden werden. Das sind unterschiedliche Lösungsansätze (Designs) für die Erreichung eines Ziels. Somit muss in dieser Projektphase ganz viel entschieden werden: Jedes Ziel (WAS) kann mit verschiedenen Lösungen (WIE) erreicht werden. Und jemand muss in dieser Phase konkret festlegen, welchen dieser Lösungsansätze man weiterverfolgt. Dies sind Design-Entscheide, die oftmals auch schleichend und nicht wirklich bewusst im Projekt gefällt werden.

An image

Vom Ziel über den Design-Entscheid zur Anforderung, ad infinitum

Wenn die Projektziele (WAS) einmal mittels Design-Entscheiden in die Form von Anforderungen (WIE) umgewandelt sind, dann kann man das Ganze natürlich wiederholen. Diese Anforderungen können nun ihrerseits wiederum als Detailziele angeschaut werden. Denn was sind Anforderungen anderes als konkretisierte Ziele? Also lassen sich diese noch weiter konkretisieren. Zurück in unserem Beispiel heisst das: Die obige User Story kann weiter konkretisiert werden. In der Software-Entwicklung würde man hier wohl ein Screen Design zeichnen, das darstellt, wo der User welchen Button drücken kann, um dann ein Balkendiagramm etc. so erhalten.

So genau wollen wir dieses Beispiel hier aber nicht weiterführen. Es geht vielmehr darum, dass wir hier feststellen, dass das Herunterbrechen von Zielen auf Anforderungen im Prinzip mehrmals wiederholt werden kann. Jede Anforderung (WIE) kann auf einer tieferliegenden Ebene wieder als als Ziel (WAS) betrachtet werden, welche somit seinerseits noch weiter in Einzelheiten aufgeschlüsselt werden kann. Das könnte man beliebig wiederholen. Bei der Software-Entwicklung könnte man die Ziele mit Design-Entscheiden soweit herunterbrechen, dass am Ende Pseudo-Code oder gar lauffähiger Code herausschaut und die Anforderungen somit so konkret sind, dass man die fertige Lösung fast schon vor sich hat. Auf dieser Detailebene spricht man dann häufig von technischer Spezifikation. Aber im Grunde genommen sind das einfach sehr, sehr detaillierte Ziele.

Bewerten und kommentieren Sie diesen Artikel


Über den Autor

Ich helfe unseren B2B-Kunden, den Übergang in die neue, agile Welt der modernen Unternehmensführung zu meistern. Agilität, Projektorientierung und digitale Transformation sind Schlüsselbegriffe dabei.

Ein effizientes «Run the Business» reicht heute nicht mehr – ein effektives «Change the Business» und das ständige sich Anpassen an neue Marktbedingungen sind heute wichtiger denn je. Dafür braucht es den richtigen Mindset - etwas, das mir besonders am Herzen liegt.

Meine Erfahrung aus unzähligen Kontakten und Erlebnissen mit Führungspersönlichkeiten aus der Wirtschaft hilft mir enorm, unsere Kunden auf dieser Reise zu begleiten: Weg von starren, auf die eigene Organisation ausgerichteten Prozessen – hin zu einer dynamischen, projekt- und kundenorientierten Unternehmenskultur. Adäquate Informationssysteme und der Fokus auf neuartige digitale Zusammenarbeitsmöglichkeiten bilden dabei stets eine Basis für langfristigen Erfolg.

Daniel Hösli ist Managing Director bei der INTRASOFT AG.

Neueste Artikel

Blog Tags

Zum ersten Mal hier? Bleiben Sie auf Kurs.

Anmeldung zum PQFORCE Newsletter

Datenschutz ist uns wichtig: Hier finden Sie unsere Datenschutzerklärung.

Durch die Nutzung dieser Website stimmen Sie der Verwendung von Cookies zur Verbesserung des Angebots sowie zum Zweck der Nutzungsanalyse zu.Datenschutzerklärung