single.php
< Beitrag von Bernhard Reuß

Borniertheit und Pedanterie – Helfer für Projektziele und Projektanforderungen? (Teil 2)

Ich bin nicht nur borniert – wie Sie evtl. in Teil 1 schon gelesen haben –, sondern auch ein Pedant, ein bekennender Pedant. Meine lieben ORBIT-Kollegen haben es längst aufgegeben, mich damit aufziehen zu wollen, weil sie wissen, dass ich jeden derartigen Vorwurf nur kokettierend und stolz wie einen Orden an der Brust trage.

Und da stellen Sie sich als geneigter Leser die Frage, was dieser erneute Seelenexhibitionismus nun wiederum mit Projektanforderungen zu tun hat.

Die Frage nach dem „Warum?“

Diese Verbindung ist tatsächlich sehr eng. So frage ich in Projekten oft: „Warum machen wir das, gibt es dafür eine Anforderung?“ Wenn ich frisch in einem Projekt bin, ist das eine offene, interessierte Frage. Kenne ich den Laden hingegen schon besser, weiß ich dann natürlich, dass es dazu keine Anforderung gibt und stelle damit eine heimtückische Falle … Perfide bin ich also auch noch …

Aber zurück zum Thema: Ja, wir wissen aus Lehrgängen, jeder zweiten PowerPoint-Arie und jedem anderen Blog, dass Anforderungen totaaaal(!) wichtig sind und so … Aber fast kein Mensch weiß, was Anforderungen genau sind.

Fragen Sie in Ihrem Projekt mal 5 Leute, wie sie den Begriff „Anforderung“ definieren. Ich bin sicher, dass Sie mindestens 7 völlig unterschiedliche Antworten bekommen, die dazu meist noch mit vielen quälenden „Ähs“ und „Ahs“ durchzogen sein werden. Das liegt schlicht daran, dass der Begriff „Anforderung“

  1. ein sehr komplexer ist, dessen Theoriebücher noch einmal deutlich dicker sind, als die der Zieltheorie
  2. im Projektleben für ‚alles‘ und ‚nichts‘ gebraucht wird. Für die einen ist es eine Passage im Konzept, für die anderen die E-Mail vom Müller-Lüdenscheid, für die anderen die Kundenbindung – also ein Ziel – und für die nächst anderen …

Kurzum, es ist ein Graus. Vermutlich ist irdisch betrachtet durch diesen Begriff im alttestamentarischen Turmbauprojekt die Babylonische Sprachverwirrung entstanden!

Was bedeutet „Anforderungen“?

Ich arbeite seit Jahren – ja, sehr erfolgreich! – wieder mit meiner eigenen ganz einfachen Einfachdefinition: „Anforderungen sind Soll-Eigenschaften der Liefergegenstände.“ Um den Wert dieser Definition zu verstehen, muss man zugegebenermaßen erst den Begriff „Liefergegenstände“ verstehen.

Also ganz kurz: Liefergegenstände sind alle irgendwie sicht- oder greifbaren Ergebnisse, die der Kunde im Projektverlauf – vertraglich zugesichert – erhält. Also nicht jede E-Mail ist ein Liefergegenstand, an einer solchen kann aber durchaus einer dranhängen, ein Konzept, ein Klumpen Software oder auch nur ein Lieferschein.

Projektanforderungen erfolgreich verfolgen

Und mit dieser sehr konkreten Vorstellung, von dem, was der Kunde wirklich bekommen will und soll, kann man sich überlegen, welche Eigenschaften diese vorher benannten Ergebnisse später haben sollen. Das kann dann ganz verschiedene Ausprägungen haben: Es soll „grün“ sein, „zwei Meter breit“, „die ISO 4711 erfüllen“, den „Use-Case x“ oder, für unsere agilen Freunde, die „User-Story y“.

Und all das sammelt man, schreibt es auf und – ganz wichtig – man beschließt es. Danach macht man im Projekt nur noch das, was dazu passt, es sei denn natürlich, es gäbe einen genehmigten Change-Request. Und spätestens dann kann ich wieder meiner Lust an der Heimtücke und Pedanterie frönen und im ein oder anderen Moment schnippisch fragen – na, Sie wissen schon – „Warum machen wir das, gibt es dafür eine Anforderung?“

Folgen
X

Folgen

E-mail : *
Kategorie: ITSM | Schlagwörter: | Kommentare: 0

Beitrag kommentieren

CAPTCHA * Time limit is exhausted. Please reload CAPTCHA.