Warum Projekte gegen die Wand fahren oder 10 Regeln für den Projekterfolg

von Tom am 3. Juni 2008

Manche Projekte laufen reibungslos, andere fahren bei der ersten Gelegenheit oder manchmal auch erst auf der Zielgeraden gegen die Wand. Warum sind manche Projekte von Erfolg gekrönt, andere nicht? Einiges hat mit der Erfahrung des Projektmanagers zu tun, aber auch sein Umfeld ist  mitverantwortlich für den Projekterfolg oder -misserfolg. Im Rückblick auf meine eigenen Projekte aber auch durch die Beobachtung anderer Projekte habe ich 10 Regeln formuliert, die die Erfolgschancen eines Projektes um einiges steigern. Die Reihenfolge der Punkte stellt in keiner Weise eine Wertung dar, dass ein Punkt wichtiger wäre als ein anderer.

  1. Wer ist der Sponsor des Projektes? Wie entstehen eigentlich Projekte? In manchen Firmen kann dies eine ganz politische Frage sein, denn manche Projekte entstehen zum Beispiel allein dadurch, dass ein Standort dem anderen nicht vertraut und daher eine eigene Lösung baut (klingt irrsinnig, hab ich aber schon mehrmals gesehen), obwohl die eigentliche Lösung global genutzt werden sollte. Der Sponsor des Projekts ist dann ein lokaler Manager, der seinem Manager wahrscheinlich erst sehr spät „beichten“ wird, dass ganz zufällig morgens eine eigene Lösung vor der Tür lag. Dies ist eine wichtige Information für die Projektmitarbeiter, damit sie nicht aus Versehen auf eine Ebene eskalieren, die von dem Projekt gar nichts wissen sollte. Bei einem Bauprojekt ist der Bauherr der Sponsor, aber auch hier wird ein Bauarbeiter nicht den Bauherrn bei jeder Frage anhauen, sondern seinen Chef, der vielleicht wiederum eigene Interessen verfolgt (zum Beispiel möglichst wenig Arbeitszeit bei diesem Bau verbringen). Letztendlich bestimmt aber derjenige, der das Projekt finanziert, und dieser muss identifiziert sein. Nur in Einzelfällen, zum Beispiel wenn Mitarbeiter in ihrer Freizeit eine Innovation entwickeln, können Projekte ohne einen Sponsor leben (wobei dann die Mitarbeiter ihre eigenen Sponsoren sind).
  2. Kenne Deine Stakeholder: Nicht nur der Sponsor ist ein Stakeholder, sondern jeder, der entweder am Projekt mitarbeitet oder auch lediglich nur ein Interesse am Projektverlauf oder Ausgang des Projektes hat, sei es positiv oder negativ. Bei dem Bau eines Hauses sind nicht nur der Bauherr, der Architekt und die Baufirma beteiligt, sondern auch Ämter, Nachbarn, Banken. Der Nachbar, dessen Terrasse nachmittags nicht mehr von der Sonne bestrahlt wird, weil der Neubau sie verdeckt, ist ebenso ein Stakeholder wie der Auszubildende des Handwerksbetriebs, der ihn leider nicht nach der Ausbildung übernehmen kann, was dieser gleich in fehlender Motivation beim Verlegen wichtiger Leitungen zeigt. Deutlich wird an diesem Beispiel, dass  man als Projektleiter nicht dafür verantwortlich ist, es allen recht zu machen. Es ist zum Teil auch gar nicht erst möglich zu erfassen, was die einzelnen Stakeholder wirklich denken. So kann der Projektleiter vielleicht schon vor Baubeginn die unmittelbaren Nachbarn besuchen und sie über die geplanten Baumassnahmen informieren; potentiell entstehende Nachteile für einen Nachbarn können diskutiert und eventuell auch Lösungen gefunden werden, sofern der Nachbar seine Kritik auch direkt äussert und sie nicht erst beim Stammtisch los wird. Dem Azubi allerdings kann der Projektmanager sehr wahrscheinlich nicht helfen, auch wird er von dessen Sorgen kaum erfahren. Dennoch ist das Ziel für den Projektmanager, so viele Stakeholder wie nur möglich vor Beginn des Projektes zu identifizieren und sie in die Planung einzubeziehen.
  3. Kickoff: In der Projektmanagement beinhaltet die Definition eines Projektes, dass dieses einen Anfang und ein Ende hat. „Sag mir wie Dein Projekt anfängt, und ich sage Dir, wie es endet,“ so lautet ein Spruch der Projektmanager, und tatsächlich entscheidet sich schon zu Beginn, ob ein Projekt am Ende Erfolg haben wird oder nicht, denn am Anfang werden die Weichen gestellt. Dazu gehört, dass das Projekt offiziell gestartet wird. In dem Kickoff-Meeting sitzen die wichtigsten Stakeholder sowie das Projektteam, und idealerweise werden die Projektziele, -risiken und -annahmen detailliert in dem Kickoff-Meeting vorgestellt. Dabei sind natürlich vorher schon wichtige Vorbereitungen getroffen worden: So existiert in der Regel bereits eine frühe Version des Plans, und natürlich gibt es eine offizielle Entscheidung, dass dieses Projekt gestartet wird und auch die notwendige Unterstützung des Top Managements erhält.
  4. Kommunikation ist alles: Als Projektleiter kann man nicht genug kommunizieren, Projektmanager müssen geradezu Kommunikations-Experten sein. Was nervig klingt, wird dann in seiner Wichtigkeit deutlich, wenn man daran denkt, wie oft man innerhalb eines Projektes schon gehört hat: „Das wusste ich gar nicht. Doof. Jetzt habe ich das nämlich anders gemacht.“ Dabei müssen verschiedene Kommunikationsformen gewählt werden, damit alle Projektteilnehmer auch erreicht werden können. Ein Softwareentwickler mag das persönliche Gespräch bevorzugen, ein anderer ein Spezifikationsdokument, ein dritter das Team-Meeting.
  5. Schreib es auf! In der Projektmanagement-Welt heisst es, dass nur das gesagt worden ist, was auch auf Papier existiert (womit auch elektronisches Papier gemeint ist). Anknüpfend an den vorherigen Punkt kann auch fast nichts sorgfältig genug schriftlich dokumentiert werden. Dabei geht es nicht darum, jemanden belangen zu können, wenn etwas schief geht, sondern vielmehr die Vielzahl von losen Enden an einem Ort zu sammeln, damit sie miteinander verbunden werden können. Dies bietet auch dem Projektteam die Möglichkeit, Informationen nachträglich einzuholen, wenn sie nicht verstanden oder auch nicht mitbekommen wurden, zum Beispiel weil ein Projektmitglied nicht da war. Zuguterletzt hilft eine Projektdokumentation auch bei den Lessons Learned, die dem Projektteam wie auch dem Projektmanager ermöglichen, aus den Erfahrungen zu lernen.
  6. Kalkuliertes Risiko: Jedes Projekt ist mit einem, meist eher mehreren Risiken behaftet. Nur in den seltensten Fällen führt das Ignorieren von Risiken zum Erfolg. Vielmehr ist es notwendig, sich gleich zu Beginn Gedanken zu machen über die möglichen Risiken und sie anhand der Wahrscheinlichkeit ihres Eintreffens und ihrer möglichen Auswirkungen auf das Projekt zu priorisieren. In manchen Unternehmen gilt man als Schwarzseher, wenn man auf mögliche Risiken hinweist, dabei ist gerade dies absolut notwendig, um für den Ernstfall gewappnet zu sein. Denn aus der priorisierten Risikoliste wird eine Aktionsliste erstellt, was getan werden kann, um die Wahrscheinlichkeit und/oder die Auswirkungen eines eintretenden Risikos zu verringern beziehungsweise was zu tun ist, wenn ein Risiko eintritt.
  7. Das hat Methode: Nach einem Projektmanagement-Seminar oder der Lektüre eines  Projektmanagement-Buches fühlt sich jeder Projektleiter bestärkt, die gerade erlernte Methoden anzuwenden und Prozesse einzuführen. Oft genug ist die Realität nicht so geduldig wie das Papier, auf dem die Seminarnotizen gesammelt wurden oder die Projektmanagement-Literatur gedruckt wird. Tatsächlich gibt es nicht DIE EINE Projektmanagement-Methode, vielmehr muss aus dem Werkzeugkasten der Projektmanagement-Welt das Werkzeug gewählt werden, das zu dem Projekt passt. Niemand wird eine Motorsäge benutzen wollen, wenn man lediglich ein kleines Stück Holz zurechtschneiden möchte. Für ein kleines Projekt ist die Nutzung des vollen Projektmanagement-Instrumentariums abschreckend für alle Projektteilnehmer, für den Bau eines Flugzeugs hingegen wird das Minimal-Instrumentarium nicht ausreichen. Die Kunst eines Projektmanagers besteht darin, die Methoden und Werkzeuge zu nutzen, die für das jeweilige Projekt angemessen sind.
  8. Achte auf den Kritischen Pfad: Der kritische Pfad ist der kürzest-mögliche Weg durch ein Netzwerk-Diagramm, in dem die Abhängigkeiten der einzelnen Projektbestandteile visualisiert werden. Verzögert sich ein Projektbestandteil auf dem kritischen Pfad, so  verzögert sich das ganze Projekt. Wenn zum Beispiel das Holz für den Dachstuhl nicht geliefert wird, dann kann der Dachstuhl nicht gebaut werden, und das Holz kann nicht geliefert werden, wenn es nicht bestellt wurde, und es kann nicht bestellt worden sein, wenn  vorher keine Entscheidung gefällt worden ist, wie das Dach eigentlich gebaut werden soll. Wenn alle diese Komponenten ohne Puffer verplant wurden, dann kann sich ein tag Verzögerung auf das ganze Projekt auswirken. Dabei ist es wichtig zu wissen, dass ein Projekt mehr als einen kritischen Pfad haben kann. Wenn man nicht weiss, was der kritische Pfad oder die kritischen Pfade in einem Projekt sind, dann hat man schon verloren.
  9. Man kann nur verbessern, was gemessen werden kann: Vertrauen ist gut, Kontrolle ist besser, um noch ein weiteres Sprichwort anzubringen. Doch um den Projekterfolg zu sichern, ist es notwendig, die Eignung der abzuliefernden Komponenten für das Projekt zu überprüfen, sobald eine Komponente vorhanden ist. Gerade bei Software-Projekten empfiehlt es sich, nach dem 1 oder 0-Verfahren zu handeln, denn wenn ein Entwickler sagt, dass er zu 90% fertig sei, so kann das oft bedeuten, dass er für die restlichen 10% genau so lange brauchen wird wie für die ersten 90%. In einem solchen Fall käme jede Korrekturmassnahme zu spät, denn der Projektleiter ginge davon aus, dass die Komponente ja bald fertig sein könnte. Gleichzeitig bedeutet dies, dass Komponenten so klein wie möglich aufgesplittet werden sollten, denn die Verzögerung einer in sechs Monaten zu entwickelnden Komponente ist schwerer zu erfassen als die von sechs kleineren und jeweils einen Monat dauernden Komponenten, die zusammen die grosse Komponente ergeben.
  10. Alles bleibt anders: Nur selten läuft ein Projekt genau so ab wie geplant, eigentlich ist mir fast kein Projekt bekannt, bei dem alles lief wie geschmiert. Entweder hat der Kunde einen Änderungswunsch, die Konkurrenz hat ein neues Feature auf den Markt gebracht, auf das im nächsten Release noch reagiert werden muss, oder eine Voraussetzung, die eine dritte Partei erfüllen sollte, fällt überraschend aus. Aus diesem Grund sollte man sich gleich zu Beginn des Projektes überlegen, was man im Falle von Veränderungen tun will. Soll der Umfang verringert werden, damit der Termin noch eingehalten werden kann? Kann man mit zusätzlichen Entwicklern und damit verbundenen höheren Kosten noch die Deadline erreichen? Und die wichtigste Frage: Wer darf das eigentlich entscheiden?  Zumindest die letzte Frage sollte zu Beginn geklärt werden: Bis zu welchem Grad darf der Projektleiter selbst entscheiden? Wann muss der Sponsor um eine Entscheidung gebeten werden? Aber auch bei der Planung selbst sollte man sich eine gewisse Flexibilität gönnen, denn es kommt erstens anders und zweitens als man denkt.

Natürlich kann ich keine Garantie geben, dass Sie allein durch das Befolgen dieser Punkte erfolgreich sein werden. Aber wenn Sie in Ihrem Projekt scheitern, obwohl Sie alle diese Punkte befolgt haben, würde ich gerne verstehen, was dazu geführt hat – Bitte melden Sie sich bei mir 🙂

{ 2 Trackbacks }

10 PM Erfolgsfaktoren « PROJEKTMANAGEMENT BLOG
10. Juni 2008 um 11:23 Uhr
Eigentlich ist Projektmanagement doch sooo leicht… « PROJEKTMANAGEMENT BLOG
10. Juni 2008 um 11:25 Uhr

{ 4 Kommentare… unten lesen oder hinzufügen }

Jean-Pierre 11. Juni 2008 um 16:01 Uhr

Hallo, mich würde interessieren, was Sie für die Abwicklung eines Projektes im Rahmen von Softwareentwicklung als Vorgehens-„Modell“ vorschlagen.

Gruss, jp

tom 12. Juni 2008 um 23:00 Uhr

Da gibt es keine allgemeine Antwort, das hängt von der Komplexität und der Größe des Projektes ab.

Danny Quick 13. Juni 2008 um 17:32 Uhr

Die Punkte, die entscheidend sind, ein Projekt erfolgreich zu beenden, sind den Beteiligten oft hinreichend bekannt. Häufig scheitern Projekte aber, da sie politisch überladen sind und niemand das „Gesicht verlieren“ will.

Gruß DQ

dg 19. August 2008 um 17:49 Uhr

Oft scheitern Projekte aber auch, weil der Anfang nicht genau spezifiziert wurde bzw. die Anforderungen nicht genau spezifiziert wurden. Oder wegen Missverständnissen, der Kunde versteht unter einem Begriff was anderes als der Dienstleister.

Vorheriger Post:

Nächster Post: