Was macht eigentlich ein gutes Projekt aus? Was muss ich tun / wissen / wie muss ich handeln, damit ein Projekt im Prinzip gut verläuft?
Ich glaube daran, dass Projekte durch Rhythmus ("release early, release often"), Transparenz ("klare Regeln") und Beständigkeit (festes Team mit genauer Zieldefinition) zum Erfolg zu führen sind.
Ein Projekt wird dann als nicht erfolgreich eingestuft, wenn es die Erwartungshaltung eines oder mehrerer Projektbeteiligten unterläuft. Welche Erwartungen an das Projekt sind also im Vorwege zu klären?

Um Projekte erfolgreich durchzuführen, müssen drei Fragen grundlegend geklärt werden: Warum, wie und was sind die Grundfragen?
Warum?
Warum baut Deine Firma eigentlich Software? Warum macht Deine Firma Marketing? Was treibt Euch? Das sind existenzielle Fragen. Die Antwort darauf erklärt,
- was Euch wirklich wichtig ist,
- warum Ihr bestimmte Features / Eigenschaften / Formen der Zusammenarbeit für unabdingbar haltet.
Wenn Ihr diese Frage für Euch beantworten könnt, kennt Ihr Euren Maßstab zur Beurteilung eines erfolgreichen Projekts. Genauso lohnt es sich, darauf zu schauen, warum Euer Auftraggeber dieses Projekt in Auftrag gibt. Was treibt den Auftraggeber? Wenn Ihr das versteht, kennt Ihr ein wichtiges Qualitätsmerkmal für Euer Projekt.
Für den Auftraggeber ist ein Projekt oft dann erfolgreich, wenn bestimmte (fachliche) Features in das Projekt integriert werden. Das Maß für den Projektmanager ist oft "in time, quality and budget". Für Techniker ist Qualität oft nur dann gegeben, wenn das entstehende System dauerhaft gut zu betreiben und einfach zu erweitern ist.
Dies ist der Fall, weil Eure "Treiber" unterschiedlich sind. Um so wichtiger ist es, diese zu explizieren und darüber Einvernehmen herzustellen. Dabei können TradeOffs entstehen. Besser ist es, diese während der Projektinitiierung offenzulegen - damit diese nicht während des Projektreviews zur Begründung dienen, warum ein Projekt nicht gut verlaufen ist.
Wie?
Ein Projektteam soll im Laufe des Projekts zusammenwachsen. Ein Projektteam, das die Storming-Phase hinter sich gelassen hat und für sich Werte und Rituale während der Norming-Phase aufgestellt hat, wird gut performieren.
Reden, reden, reden! Die während der Anfangsphase im Projekt in die Frage investierten Stunden, wie das mit der Zusammenarbeit genau geht, werden sich im Laufe des Projekte rentieren. Das gilt für jedwede Projektmethode: sei es agil oder doch eher klassisch im Wasserfall.
- Alle Projektbeteiligten verständigen sich Projektrituale und -regeln, die verbindlich eingehalten werden.
- Es gibt klare Projektwerte, an denen Handlungen Einzelner gemessen werden können.
Auch wenn dieses Ansinnen erstmal sehr großspurig klingt - und irgendwie überflüssig: "wir wissen ja, wie's bei uns läuft" - hilft das Aufstellen expliziter Regeln ungemein. Während man sich ungeklärt über den ständig unpünktlichen Kollegen ärgert, findet man durch explizites Vereinbaren eine verlässliche Projekt-Kernarbeitszeit. Und verliert keine Kraft mehr mit Ärger, sondern nutzt konzentriert die gemeinsame Zeit.
Persönlich wichtig ist mir die Projektregel: "Das Projektteam sitzt zusammen." Das Projektrisiko, das sich aus einem Treppenhaus zwischen Projektteam-Mitgliedern ergibt, ist viel größer, als man annnehmen möchte.
Wichtig ist auch, dass auch mit dem Auftraggeber des Projekts - das gilt für interne als auch für externe - Projektspielregeln vereinbart werden. Es ist zu klären, wie Interventionen laufen oder wann wer über was informiert.
Das ist nicht immer leicht bei der ersten Diskussion und erfordert eine selbstbewusste Haltung als Auftragnehmer. Das Resultat ist ein ruhiger Projektverlauf, in der der Auftraggeber nicht eine Störung, sondern eine Bereicherung darstellt.
Was?

Wenn man in Projekt-Reviews darauf schaut, warum ein Projekt nicht gut gelaufen ist, findet man neben dem Klassiker der Fehlkommunikation (also einem ungeklärten "Wie") auch oft heraus, dass erst sehr spät klar wurde, was eigentlich gebaut werden sollte. Das Ziel war nicht klar.
Es lohnt sich darauf zu sehen, ob Ziele SMART definiert sind. Sind sie dies nicht, ist Ärger vorprogrammiert. Denn eine nicht-SMARTe Formulierung lässt Interpretationsspielraum für unterschiedliche Qualitätskriterien zur Beurteilung des Projekts zu. In diesem Sinne bietet SMART sich als Schablone zur Ermittlung von Qualitätskriterien an. Gerade diese sind mit Auftraggeber offen zu verhandeln. Im besten Falle sind diese Qualitätskriterien diejenigen, die vertraglich für die Abnahme vereinbart werden.
Auch auch hier gilt: über Zielkonflikte sprechen, TradeOffs offen legen, für Klarheit sorgen.
Wichtig ist hierbei u.a. auch der Umgang mit Fehlern. Fehlerfreie Software existiert nicht. Gerade mit externen Auftraggebern sollte man daher klären, wie der Zustand des Bugtrackers beim Launchtermin auszusehen hat. Es ist ein SMARTes Ziel, wenn man einfordert, dass beim Launch nicht mehr als 30 Schönheitsfehler eingestellt sind (sofern der Begriff "Schönheitsfehler" definiert ist).
Definierte Erwartungshaltung = klare Projektbeurteilung
Zusammengefasst: Allen Projektbeteiligten (welche von Beginn an alle bekannt sind) kennen das Projektziel, den Treiber für das Anliegen und die Art der Zusammenarbeit. Während der Zieldefinition entstandene TradeOffs sind allen bewusst. Wenn diese Klarheit im Projekt herrscht, dann wird die Bearbeitung und die Beurteilung des Projekts gut laufen.
Denn: bemerkt ein Projektbeteiligter während des Projekts, dass sich das Projekt aus diesen Parametern herausbewegt, kann entweder die Zielsetzung oder das Projekt selbst re-justiert werden.
Viel Erfolg!
Dieser Blog-Post ist ein privater Beitrag von Judith Andresen.
- Nächster Artikel: Interne Projekte - Projekte der ganz besonderen Art
- Vorheriger Artikel: Webfonts in jimdo-Site einbauen
- Kategorie: Projekte, Leitung, Kultur
Kommentar schreiben