"Meine Projektleiter setzen manchmal Sachen um, ohne verstanden zu haben, was der Kunde damit tun möchte.", sagt Peter, Geschäftsführer eines mittelständischen Software-Dienstleisters. Sein Projektleiter Hans versteht die Welt nicht mehr: "Der Kunde wollte einen Button, mit dem alle Aktionen zur Bestellbearbeitung auf einmal rückgängig gemacht werden sollen. Das habe ich ihm programmieren lassen und jetzt beschwert er sich, diese Funktion sei kompletter Unsinn.", berichtet Hans in der internen Projektleiter-Runde seinem Chef. "Ist ja klar, dass wir so mit den geplanten Aufwänden niemals hinkommen. Ich kann mich auf die Aussagen beim Kunden offenbar überhaupt nicht verlassen."   

Der Geschäftsführer rauft sich die Haare. Dieses Projekt sollte längst fertig sein und Hans schon das nächste begonnen haben. Das geht aber nicht, weil ein "normaler" Kunde auf einmal zum verärgerten Kunden zu werden droht. Und anscheinend nur aus dem Grund, weil er etwas verlangt hat, was er anschließend nicht mehr haben wollte. Kennen Sie eine derartige Szene? 

Warum formal richtiges Vorgehen kein Erfolgsgarant ist

"Hast Du gefragt, was der Kunde mit der Funktion beabsichtigt hat", möchte Peter von seinem Projektleiter wissen. "Nein, er hatte ja alles ausführlich beschrieben, dann habe ich es umsetzen lassen. Die Anforderungs-Dokumentation war komplett ausgefüllt. Außerdem war die Zeit knapp. Das nächste Projekt steht ja schon an." Hans findet, er hat alles richtig gemacht. 

Das hat er auch, aber nur auf den ersten Blick – und das reicht eben nicht. Solange der Projektleiter Hans nicht genau verstanden hat, welchen Sinn und Nutzen sich der Kunde von der bestellten Software erhofft, werden solche Szenen sich wiederholen. Peter möchte das verständlicherweise abstellen.

Sein erster Impuls ist, für seine Projektleiter eine neue Regel aufzustellen: "Hinterfrage jede Anforderung immer genau nach Sinn und Nutzen für den Kunden." Dann stellt er fest, dass im Formular für die oben erwähnte Anforderungsdokumentation bereits ein entsprechendes Feld dafür vorhanden ist. Füllen es die Projektleiter aus? Ja, mit der typischen Standard-Antwort: "Kunde sagt, er braucht das."  Ok, Regeln scheinen nicht weiter zu helfen. Was dann? 

Nutzenstiftende Produkte entwickelt man nur im Dialog

In der Projektleiter-Runde kommt ein anderer Lösungsansatz zur Sprache, und zwar ganz intuitiv. Einer der neuen Projektleiter, Micha, fängt an, Hans` Situation zu hinterfragen, weil er als Neuer die Zusammenhänge und Arbeitsweisen noch genauer kennenlernen möchte. Und je genauer Micha nachfragt und Hans über Hintergrund und Zusammenhänge des Projekts erzählt, umso mehr wird die Lösung für Hans klar: so ein Gespräch hätte er vor der Programmierung der Software mit dem Kunden führen sollen.

Michas Fragen haben ihn darauf gebracht, den Nutzen der Funktion nochmal genauer zu durchdenken. Und es fällt ihm auf, dass er tatsächlich eine andere Annahme darüber hatte als der Kunde. Peter und seine Projektleiter beschließen, dass der regelmäßige Bericht an den Kunden über den Projektfortschritt eine andere Qualität bekommen muss: Es soll nicht nur ein Bericht über den Stand des Projekts sein, sondern auch einen Dialog mit dem Kunden einleiten, um den Kontext und die Absichten "hinter der Software" besser zu verstehen.

Den Kontext zu einem Projekt liefern oft Stories, die den Hintergrund, Nutzen und die Absichten des Projekts anschaulicher erklären, als es im Projektmanagement-Alltag in der Regel vorkommt. Die Geschichten rund um ein Projekt sind nicht nur unterhaltsam, sie liefern meistens auch die erhellenden Informationen, – die gerne vergessen werden, wenn man nur mit strukturierten und analytischen Methoden arbeitet – die man dringend braucht, wenn man eine neue Anforderung richtig "einschätzen" möchte.