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: 2

Beitrag kommentieren

CAPTCHA * Time limit is exhausted. Please reload CAPTCHA.

Kommentare

  • 29.06.2017 von Martin Wißkirchen

    Danke für diese eigentlich triviale und doch wertvolle Betrachtung der Frage "Warum tun wir das?" Nach einigen Jahren in Kundenprojekten habe ich die Erfahrung gemacht, dass sich ein Projekt solchen Formalitäten in erster Linie sicherer und einfacher durchführen lässt.
    Dennoch mag ich die Kundenbeziehung nicht ganz außer Acht lassen. Es mag "Gefälligkeiten" für Kunden geben, die man erbringt ohne, dass es hier eine dedizierte Anforderung gibt - das Risiko trägt jedoch dann der Projekt-Verantwortliche und darüber sollte dieser sich auch bewusst sein.

    • 11.07.2017 von Bernhard Reuß

      Ich kann das gut verstehen, diese "Gefälligkeiten" sind durchaus an vielen Stellen üblich, und auch ich bin der Versuchung in der Vergangenheit immer mal wieder erlegen.
      Sie bergen aber die Gefahr, einen „ungesunden Appetit“ beim Kunden zu nähren, den man dann vielleicht nicht wieder loswird. Zudem entwerten sie in der Tendenz ein wenig die — bezahlten — Kernleistungen. Deshalb setze ich in den letzten Jahren vermehrt auf konsequentes Erwartungsmanagement beim Kunden: Jenseits der vertraglichen Regelungen mache ich auch in meiner mündlichen Kommunikation ständig deutlich, was „drin“ ist und was nicht. Zudem mache ich die Vorzüge der „drin“-Leistungen auch präsent und sichtbar. Das klingt trivial, ist es nach meiner Erfahrung aber nicht. Den echten Wert, auch ggf. kleiner Zwischenlösungen, verkennen viele Berater oder Dienstleister und können diesen dann auch nicht selbstbewusst beim Kunden betonen. Ich stelle das hingegen immer klar heraus. Damit erreiche ich meist dieselbe verbindende Kraft, aber mit dem „drin“…
      Aber natürlich gibt es auch bei mir nach wie vor die ein oder andere dieser Gefälligkeiten, sie sind dann aber so klein, dass eine gesonderte Abrechnung auch lächerlich wäre. Das ist dann schon näher an einem menschlichen „Gefallen“ als an einer geschäftlichen „Gefälligkeit“. Und einen solchen Gefallen tue ich den meisten Kunden gern. Die meisten sind nämlich tatsächlich sehr angenehme Menschen. ;-)