Hilfe in meinem Projekt stimmt die Qualität nicht mehr

Diese Situation ist nicht neu: Ein grösseres Softwareentwicklungsprojekt wurde mit einer 10 köpfigen Mannschaft begonnen. Man hat gute Fortschritte gemacht, der Auftraggeber ist mit den ersten Resultaten zufrieden. Alle Entwicklungstasks sowie die internen Test sind nahezu abgeschlossen, das Projekt neigt sich dem Ende zu. Längst können nicht mehr alle 10 Team Mitglieder beschäftigt werden sondern diese sind teilweise bereits wieder in anderen Projekten tätig. Plötzlich merkt der Projektleiter, dass die Qualität im Projekt nicht mehr stimmt. Wann die Fehler aufgetreten sind, ist an dieser Stelle gar nicht mehr wichtig, sondern viel mehr, was der Projektleiter in einer solchen Situation tun kann, respektive wie er solche Situationen vermeiden kann:

1. Das Team bleibt bis zum Schluss ein Team
Obwohl das Projektteam nicht mehr ausschliesslich für dieses Projekt arbeitet, bleibt es bis zur Projektabnahme ein Team. Es kann durchaus sein, dass einige Leute auf anderen Projekten arbeiten und nahezu nicht mehr für das eigene Projekt tätig sind, dennoch muss der Projektleiter sicherstellen, dass die Informationen an alle Team Mitglieder verteillt werden. Statusmeeting, oder persönliche Updates an Leute, die keine konkrete Tasks mehr haben sind unerlässlich. Und warum?

• Der Entwickler soll bis zum Schluss für seine Komponenten verantwortlich sein und wenn möglich auch darin gefundene Fehler beheben. Wenn er sich jedesmal für eine Fehlerkorrektur komplett neu orientieren muss, so dauert das unter Umständen viel zu lange. Ist er aber informiert, was im Projekt gelaufen ist, so kann er geziehlt mit der Fehleranalyse beginnen. 
• Wird die Verantwortung plötzlich abgegeben, so müssen andere Personen die Fehler glatt ziehen. Das ist nicht im Sinne eines Teams, in dem jeder seine Verantwortung übernommen hat.
• Wird das Team Mitglied nicht mehr informiert, verliert es sehr schnell die Motivation. Selbst wenn dann Fehler behoben werden müssen, wird dies allfällig lieblos und ohne ausführliches Testing / Review erledigt.  

Wenn ein Team Mitglied gar keine Zeit für das Projekt mehr hat, so muss der Projektleiter eine saubere Übergabe an einen anderen Entwickler sicher stellen, damit dieser die Verantwortung über die entsprechende Komponente übernimmt.

2. Nach den ersten Erfolgen darf die Qualitätssicherung nicht vernachlässigt werden
Ist der Auftraggeber mit den bisherigen Leistungen zufrieden, besteht sehr schnell die Gefahr, keine ausführliche Qualitätssicherung mehr zu machen wie bis anhin. Das Vertrauen des Auftraggebers hat man ja durch die ersten Erfolge für sich gewonnen. Sehr schnell kommt jetzt die Denkweise "die können ja auch mal testen" auf. Das ist kontraproduktiv und nicht sinnvoll. Code Reviews, Überprüfung der Code Qualität ist auch in einer späteren Phase des Projektes unerlässlich. Durch eine schnelle Fehlerkorrektur können sich auch schnell Folgefehler einschleichen. Darunter leidet die (Code) Qualität zwangsläufig. Ein sorgfältiges Retesting der Fehlerkorrektur durch Entwickler und Tester ist in dieser Phase besonders wichtig.

Das hier Beschriebene klingt sehr stark nach dem "Idealfall". Mir ist bewusst, dass oftmals weder Zeit noch Budget für eine ausführliche Qualitätssicherung resp. für regelmässige Updates im gesamten Projektteam vorhanden ist. Dennoch soll sich der Projektleiter der Thematik bewusst sein und früh gegen dieses Problem steuern.

Teil 6: Stakeholder Kommunikation

Über Stakeholder und Stakeholderkommunikation gibt es gute theoretische Grundlagen, wie beispielsweise die Stakeholderanalyse oder die Kommunikationsmatrix. Ich möchte in diesem Post nicht diese theoretischen Grundlagen erläutern oder nochmals wiedergeben, sondern viel mehr beschreiben, was man nebst diesen Methoden als PL für die Kommunikation mit den Stakeholdern verwenden kann. 

Für die gezielte Kommunikation mit den Stakeholdern ist eine ausführliche Stakeholderanalyse unerlässlich. Auch wird der Projektleiter vermutlich zu Beginn des Projektes sich überlegt haben, welche Stakeholdergruppen wann wie und worüber informiert werden (Kommunikationsmatrix). Aber hat man mit einer sauberen Analyse und den entsprechenden Reports die Stakeholder wirklich im Boot?

Persönliche Kommunikation als wichtigste Ausgangslage für die Stakeholderkommunikation:

Ich glaube, dass bei der Kommunikation mit den Stakeholdern genau wie beim Projektteam die persönliche Kommunikation eine ebenso wichtige Rolle spielt. Je nach Stakeholder vielleicht nicht in der Intensität wie innerhalb des Teams, aber von Zeit zu Zeit ein Anruf oder bei einen gemeinsamen Kaffee zu plaudern schadet nichts. Dies aus folgenden Gründen:

• Stakeholder, die nicht so nah am Projekt sind, haben oft gar keine Zeit, alle Reports zu lesen und zu verstehen, die ihnen einmal im Monat zugeschickt werden. Da hier keine tägliche Kommunikation stattfindet, vergisst man oft den Zusammenhang. Hilfreicher sind hier Projektpräsentationen, bei denen in der Pause auch mal das persönliche Gespräch gesucht werden kann.
• Im persönlichen Gespräch kann der Projektleiter mit gezielten Fragen eher herausfinden, wo allenfalls der Schuh drückt, als in einer Einwegkommunikation.
• Im persönlichen Gespräch hat der Stakeholder die Möglichkeit Fragen zu stellen und das ist für den Projektleiter die ideale Möglichkeit falsche Annahmen aus dem Weg räumen.
• Es ist besser möglich, im persönlichen Gespräch das Vertrauen eines Stakeholeders zu gewinnen. Der Stakeholder kennt danach das „Gesicht“ hinter demjenigen, der regelmässig Reports schickt. Und wer weiss, vielleicht werden diese Reports dann doch angeschaut ;o)

Es ist klar, dass in einem grossen Projekt nicht jeder einzelne Stakeholder persönlich durch den Projektleiter betreut werden kann. Aber der Projektleiter könnte im Projekt jemanden bestimmen, der für die Stakeholderkommunikation verantwortlich ist. Diese Person entscheidet dann auch, wann der Projektleiter dabei sein soll/muss.

Ohne Zuhören läuft im Projekt gar nichts

Zuhören ist eine der wesentlichen Eigenschaften, die ein Projektleiter mich sich bringen muss. Es ist natürlich noch besser, wenn auch alle Team-Mitglieder zuhören können, aber diese Voraussetzung ist nicht immer gegeben. Umso wichtiger, dass der Projektleiter mit gutem Beispiel voran geht.

Warum Zuhören für das Projekt und für das Team wichtig ist:
Der Projektleiter ist weit mehr als nur der Terminkoordinator, Kosten- und Leistungsüberwacher. Der Projektleiter soll auch auf die Bedürfnisse im Team eingehen. Auch wenn der Projektleiter nicht immer für alles eine Lösung griffbereit hat, soll er als zentraler Ansprechpartner für alle fungieren. Das kann er durch Zuhören erreichen und damit, indem er jeden einzelnen eingeht. Der Projektleiter muss erreichen, dass er eine Vertrauensperson wird. Es reicht, bei einem Kaffee einfach mal zuzuhören und sich voll und ganz dem Team-Mitglied zuwidmen.
Darüber hinaus sollte der Projektleiter erreichen, dass nicht nur er selbst zuhört, sondern auch das Team einander zuhört. Vielfach gehen nämlich Dinge vergessen oder werden falsch interpretiert, weil das Team nicht richtig zugehört hat.
Wenn der Projektleiter und auch das Team einander nicht zuhören, grenzt das für mich persönlich an Respektlosigkeit. Und das ist vermutlich eine der schlimmsten Gegebeneheiten, wenn man in einem Team ein Ziel erreichen will.

Wie der Projektleiter das Zuhören bei sich selbst und auch im Team fördern kann:

• Regelmässige Feedbackrunden machen. Raum für Kritik (auch an den Projektleiter selbst) schaffen
• Als gutes Beispiel vorangehen, selbst immer aktiv zuhören. 
• Meetings moderieren und Regeln einführen: Handy, Notebooks etc. sind ein absolutes NoGo während einem Meeting. Darauf hinweisen und um Aufmerksamkeit bitten, auch wenn jemand anders spricht.
• Persönliche Gespräche mit den einzelnen Team Mitglieder führen, sich Zeit nehmen für deren Bedürfnisse. Dabei sich nicht von anderen Tasks ablenken lassen
• Den Austausch zwischen den Team Mitglieder fördern und aktiv einfordern, z.B. gegenseitiger Review von entwickelten oder konzipierten Komponenten, fachlicher Austausch nach dem Statusmeeting. Dabei achten, dass die "Kommunikationsregeln" eingehalten werden.

Mehr zum Thema "aktives Zuhören"
- Aktives Zuhören
- Begriffsdefinition