"Die Basis erfolgreicher Projekte ist eine gute persönliche Beziehung zu Auftraggeber und Stakeholdern." Das war das Ergebnis eines intensiven Erfahrungsaustausches zwischen Geschäftsführern der IT-Branche in Augsburg, den wir kürzlich moderiert haben. Dabei kam ein ganz typischer Fall eines Projektes zur Sprache, in dem der Projektleiter formal alles richtig gemacht hat, und das Projekt trotzdem in Schieflage zu geraten droht. „Meine Projektleiter setzen manchmal Sachen um, ohne Verstanden zu haben, was der Kunde damit tun möchte.“ Peter, Geschäftsführer eines mittelständischen Software-Dienstleisters, 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, dass diese Funktion kompletter Unsinn ist.“, berichtet Projektleiter 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.“
Peter, der Geschäftsführer, rauft sich die Haare. Das Projekt sollte schon längst fertig sein und Hans sollte das nächste Projekt begonnen haben. Das geht aber nicht, weil ein „normaler“ Kunde auf einmal zum verärgerten Kunden zu werden droht. Und offenbar weil er etwas verlangt hat, was er anschließend nicht mehr haben wollte.
Ist Ihnen eine derartige Szene auch schon vorgekommen?
„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 zu knapp. Das nächste Projekt steht ja schon an.“ Hans findet, er hat alles richtig gemacht.
Das hat er auch, nur reicht das nicht. Solange der Projektleiter Hans nicht genau verstanden hat, was für den Kunden der Sinn und Nutzen der Software ist, die er beauftragt hat, werden solche Szenen immer wiederkehren. 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, typische Standard-Antwort: „Kunde hat gesagt, er braucht das.“
Ok, Regeln scheinen nicht weiter zu helfen. Was dann?
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, umso mehr wird die Lösung für Hans klar: dieses Gespräch hätte er vor der Programmierung der Bestellbearbeitung 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 Projektes sein, sondern auch ein Dialog mit dem Kunden, um ihn und die Absichten „hinter der Software“ besser zu verstehen. Projektkommunikation eben.
