Roland Dürre
Donnerstag, der 21. Juli 2011

Vortrag – Projekt Management

Eine Auswahl von Schülern der Kolleg-Stufe will im Rahmen eines Förderungsprogramms für Eliten ein ehrgeiziges Projekt realisieren. Der im Bayerischen Kultusministerium dafür Verantwortliche ist ein guter Freund und hat mich gebeten, zu diesen aus ganz Bayern stammenden jungen Menschen über „Projekt Management“ zu sprechen.

Dazu habe ich folgenden Vortrag entwickelt und versucht, ihn ganz einfach zu halten. Vor allem wollte ich meinen jungen Zuhörerinnen und Zuhörern klar machen, was zu einem Projekt so alles dazu gehört.

Hier das Manuskript. Viel Spaß beim Lesen!

Guten Morgen!

In meinem Vortrag geht es um Menschen, Planung, Teams, Unternehmen, Vorhaben, Ziele und – Projekte! Denn Ihr wollt gemeinsam eine anspruchsvolle Veranstaltung vorbereiten und durchführen. Diese Veranstaltung soll werbewirksam, künstlerisch wertvoll und kaufmännisch erfolgreich sein. Ihr wollt viele Zuschauer erreichen und für Euch selbst einen bleibenden Wert schaffen.

Als Team müsst ihr so in dem gut halben Jahr bis zur Aufführung viele Leistungen in verschiedenen Dimensionen erfolgreich erbringen und integrieren. Das heißt, Ihr habt ein anspruchsvolles Projekt vor Euch.

Was ist denn überhaupt ein Projekt?

Es ist nicht gut, über Begriffe zu reden, von denen man gar nicht weiß, was sie bedeuten. Ich versuche mal den Begriff „Projekt“ zu definieren:

Ein Projekt ist eine zeitlich begrenzte Zusammenarbeit eines Teams, das ein konkretes Vorhaben in einer bestimmten Zeit schaffen will. Ein Projekt soll also in endlicher Zeit ein beschreibbares Ergebnis liefern. So hat jedes Projekt einen Anfang. Und es muss ein Ende haben. Am Ende soll das Projekt fertig sein und erfolgreich funktionieren. Es gibt also eine konkrete Aufgabe, die in einer definierten Zeit erledigt werden soll/muss.

Was gehört denn alles zu einem Projekt?

Es gibt immer ein Ziel! Ein Vorhaben soll erfolgreich durchgeführt werden. Wir müssen also ein Projektziel finden und beschreiben.

Wenn wir dieses Ziel zum geplanten Zeitpunkt des Projektendes erreichen, dann sind wir erfolgreich. Aber wie beschreibe ich das Ziel? Wie definiere ich Erfolg? Wann ist ein Projekt erfolgreich?

Die Definition von Erfolgskriterien hilft. Wir können Kriterien für den Erfolg des Projektes festlegen. Wenn wir die zum vorgesehenen Zeitpunkt erreichen, ist das Projekt erfolgreich. Aber Vorsicht, Erfolg ist mehrdimensional! Die erwartete Funktion muss geliefert werden, die Qualität muss stimmen, der gewünschte Mehrwert muss eintreten, der Aufwand soll im vorgesehenen Bereich bleiben, der Termin muss gehalten werden und alle im Team sollen möglichst viel dazu gelernt haben. Vorher festgelegte Erfolgskriterien ermöglichen zu bewerten, ob das Projekt erfolgreich war oder nicht.

Bevor wir die Erfolgskriterien aber willkürlich festlegen, sollten wir uns nochmal daran erinnern, dass jedes Projekt einen Anfang und ein Ende hat. Beides, Anfang und Ende, müssen klar festgelegt sein. Wir beginnen mit dem Anfang.

Wie startet man ein Projekt?

Wichtig ist, dass man Menschen findet, die sich an unserem Projekt verpflichtend beteiligen. So wird man in der Regel für ein Projekt ein Team benötigen. Das Team kann ein Kernteam sein, das im Laufe des Projektes bei Bedarf oder geplant vergrößert wird, oder auch ein Team, das in möglichst unveränderter Besetzung das ganze Projekt stemmt.

Warum betrachten wir erst mal das Team? Ganz einfach, das Team wird viele Herausforderungen schaffen müssen. Die Team-Mitglieder werden viel Zeit und Kraft, Verstand und Kreativität investieren müssen. Und natürlich müssen Team und Ziel zusammen passen. Das klingt so einfach.

Ist es aber nicht. Denn es gibt immer eine ganz wichtige Frage:

Ist das Ziel realistisch?

Das können wir erst feststellen, wenn wir die verfügbaren Ressourcen kennen. Und dann ist es immer noch schwer genug. Denn die Zukunft ist eben nicht vorhersehbar.  Und wichtige Projektentscheidungen werden immer unter Unsicherheit gefällt werden müssen.

Es gibt ein englisches Sprichwort:

Birds of a feather flock together.

Warum erwähne ich dieses Sprichwort? Die Menschen, die beim Projekt mitmachen, müssen ein Team zu bilden. Mit dem „gleich und gleich gesellt sich gerne“ ist aber keinesfalls gemeint, dass die Mitglieder des Projektteams alle die selben fachlichen „Skills“ haben sollen. Vielmehr ist Pluralismus und interdisziplinäres Können gefragt (dies natürlich auch abhängig von der Art des Projektes). Aber die Werte und sozialen Kompetenzen der Menschen, die gemeinsam den „Geist“ des Teams bestimmen, müssen passen. So suchen wir ein Team, das über Werte verbunden und trotzdem pluralistisch und interdisziplinär ist.

Team-Aufbau

Wenn wir das Team zusammen stellen, sind zwei Fragen hilfreich:

Welche Voraussetzungen müssen erfüllt sein, damit das Vorhaben gelingen kann?

Und:

Was darf nicht passieren, wenn es gelingen soll?

Wir müssen also ein Team aufbauen, das solchen Unabwägbarkeiten gewachsen ist. Wir müssen Menschen gewinnen, die mitdenken und mitmachen.

Für den Erfolg ist wichtig, dass wir ein „echtes Team“ und keine „Gruppe“ aufbauen. Gruppe in dem Sinn, dass es einen Gruppenführer gibt, der die Dinge vorgibt, die von den anderen abgearbeitet werden. Ein Team unterscheidet sich von einer solchen Gruppe. Alle Mitglieder im Team wollen eigen motiviert (intrinsisch) den Erfolg des Projektes. Sie sind sich bewusst, dass sie in einer möglichst passenden Rolle dafür wesentliches zu leisten haben.

Alle Mitglieder sollten vom Typ „Partner (P)“ sein. Einfach erklärt bedeutet das, dass alle im Team vor allem die Probleme auf dem Weg zum Projekterfolg und nicht andere Team-Mitglieder als Gegner und Feinde betrachten. S-Typen (Sieger) sind unerwünscht (und gefährden schnell das Projekt) wenn ihr Hauptziel ist, sich im Team in den Vordergrund zu spielen, wie z.B. in Besprechungen zu zeigen, wie toll sie sind.

Beim Aufbau des Teams und der weiteren Integration neuer Mitglieder müssen wir darauf achten, dass hierzu Einigkeit besteht. Für den Aufbau eines Teams ist es hilfreich, dem Projekt einen Namen zu geben.

Wenn man soweit ist, also weiß, was man will und welche Menschen mit machen, dann wäre es an der Zeit, vorsichtig einen Plan zu entwickeln. Ein Projekt ohne Plan kann leicht (wird) daneben gehen.

Planung

Für das Planen braucht man Erfahrung. Wenn man die noch nicht hat, dann hilft nur eins: ein paar Sachen vor ab mal auszuprobieren. Wichtig ist, dass man bei der Zeitplanung immer vorwärts rechnet – nie rückwärts vom gewünschten Ende des Projektes her!

Auch ein guter Plan sollte davon ausgehen, dass nicht alles klappt? Das ist die Realität. Man braucht also Reserven. Ganz banal – aber oft vergessen. Nur Reserve allein genügt nicht. Ein guter Plan muss die Qualität haben, dass man ihn iterativ verändern kann.

Denn in jedem Projekt gibt es Unwägbarkeiten und Überraschungen. Aufwände werden falsch eingeschätzt. Neue Erkenntnisse werfen Teile der Planung (oder alles!) komplett um. Eine iterative Planung lässt zu, Dinge rechtzeitig um zu planen.

Neben der Planung sollte man sich auch überlegen, wie man das Projekt methodisch organisieren kann. Es hilft immer, wenn man sich eine Projektmethodik sucht.

Methodik und Rollen

Gerade wenn Teams sich auf Neuland wagen müssen – und das ist ja bei jungen Menschen ganz natürlich der Fall – empfehle ich SCRUM als eine iterative Methode. Iterativ ist wichtig, weil man nur so wichtige Erkenntnisse aus dem Projektfortschritt in die Projektarbeit geplant einbringen kann.

SCRUM bietet eine Reihe von Vorteilen: Man nimmt sich als „Meilensteine“ nur kleine Schritte vor (SPRINTs). Wie beim Laufen sind kleine Schritte besser als größere. Jeder Sprint bringt etwas Konkretes und Nutzbares. Das Ergebnis eines Sprints muss immer eine verlässliche Produktqualität besitzen. Die für das  Projekt so wichtige Motivation wird durch den Erfolg, d.h. den gefühlten und sichtbaren Fortschritts des Projekts erreicht. Also – kleine „Sprints“!

SCRUM als Methode konsequent angewandt stellt sicher, dass es einen Menschen gibt, der weiß, was das Ziel ist (den Product Owner). Und es gibt eine Rolle – den Scrum Master. Der sorgt dafür , dass im Projekt und für alle Teammitglieder eine „geschütze Ordnung“ gegeben ist. Und – ganz wichtig für Projekte immer aber besonders mit vielen jungen Menschen: Es gibt ein zwingend schriftliches backlog.

Dann kann es losgehen und die Rollen können verteilt werden. Jede Methode lebt davon, dass die Rollen optimal besetzt und dann gut gelebt werden.

Werkzeuge

Aber halt, man sollte nochmal nachdenken, welche Werkzeuge man verwendet. Was könnte man in einem Projekt brauchen? Vielleicht ein Wiki. Ein gutes Tracking macht immer Sinn, also braucht man einen „Tracker“, sprich ein Werkzeug, mit dem man den Projektfortschritt überwacht.

Also ab ins Projekt!

Vernünftig planen: Die Phasen und Dimensionen des Projektes festlegen! Wo muss parallel gearbeitet werden, wo gehen die Projektschritte nur seriell wegen vorhandener Abhängigkeiten. Welche Meilensteine sind wünschenswert. Welche Regeln können die Kommunikation und Zusammenarbeit verbessern. Machen Rituale Sinn, die das Team stärken und die Menschen motivieren. Wie wird der Fortschritt kontrolliert, die Qualität auch vorbeugend gesichert?

Dabei aber nie vergessen, dass der gesunde Menschenverstand unverzichtbar ist. Der „Kopf nie in den Sand gesteckt werden darf“. Unangenehmes darf nicht ignoriert werden, alle im Team sollten auch die Zivilcourage und die Bereitschaft haben, ihre Bedenken angemessen zu artikulieren. Und immer gesunden Optimismus und den Glauben an den Erfolg bewahren.

Und wenn man das alles mit guter Motivation geschafft hat, dann kommt man in der Regel auch gut ins Ziel. Nie ganz ohne Schmerzen und Mühen. Rückschläge und kleine Krisen hat man auch erlebt. Vielleicht sind auch ein paar der gewünschten aber doch nicht ganz so notwendigen Features gestrichen worden, aber man schließt das Projekt erfolgreich und stolz ab, so dass sich die Arbeit sehen lassen kann.

Und was macht man, wenn ein Projekt vorbei ist? Dumme Frage – natürlich Feiern!

Aber damit ist die Arbeit noch nicht vorbei! Es gibt noch etwas ganz wichtiges zu tun. Neben einer ordentlichen Feier sollte man noch eine gründliche Abschluss-Arbeitssitzung durchführen! Und Lessons learned machen. Eine solche Übung hilft, die schon erreichte Lernkurve der Team-Mitglieder noch zu verbessern.

Das Projekt wird in einem gemeinsamen Rückblick besprochen. Was war gut, was war schlecht? Welche Probleme wären vermeidbar gewesen? Wo und wann ist die Kommunikation entgleist? Wann war das Projekt in der Krise? Was war die Ursache? Was würde man jetzt anders machen? …

Ganz wichtig bei der „Lessons learned“-Sitzung ist, dass man sich sehr fair aber durchaus konsequent ehrlich gegenseitiges Feedback gibt. Es muss gelingen, dass alle Mitwirkenden bereit und fähig sind, die Leistung der anderen Mitglieder des Teams  mit möglichst wenig Verzerrung zu spiegeln. Ein nicht ganz triviales Vorhaben, hier kann eine Begleitung durch einen erfahrenen Moderator viel beitragen.

So wird das Projekt zweifach erfolgreich: Es funktioniert und alle Beteiligten haben viel dazu gelernt.

Euch allen viel Erfolg bei Eurem anspruchsvollen Vorhaben!

Der Vortrag selbst hat mir dann viel Spaß gemacht. Vor allem wurde er von den Kolleg-Stufen-SchülerInnen sehr gut aufgenommen. Ich hoffe, dass ich damit einen kleinen Beitrag zum Gelingen des Projekts leisten konnte.

🙂 Und finde schade, dass er nicht auf Video aufgenommen wurde. Um selbst vom Video als mein Spiegel zu lernen. Aber vielleicht muss ich ihn ja irgend wann einmal wiederholen.

RMD

Be Sociable, Share!

3 Kommentare zu “Vortrag – Projekt Management”

  1. Bernhard Findeiss (Freitag, der 22. Juli 2011)

    Ich finde es eine sehr anspruchsvolle Aufgabe, Projektmanagement in solch kurzer Zusammenfassung zu beschreiben. Von daher finde ich deine Zusammenfassung wirklich gut gelungen.

    Anmerkungen hätte ich spontan lediglich zu ein paar Details:

    – Du schreibst an einer Stelle „Iterativ ist wichtig, weil man nur so wichtige Erkenntnisse aus dem Projektfortschritt in die Projektarbeit geplant einbringen kann.“ Ich denke, das sollte man noch ein wenig präzisieren. Scrum hat nämlich 2 verschiedene Feedback-Schleifen für verschiedene Zwecke eingebaut: Eine für die Verbesserung des Produkts (-> Sprint Review), und eine für die Verbesserung des Prozesses (-> Sprint Retrospective). Beide werden am Ende jeder einzelnen Iteration durchlaufen, um möglichst viel für das aktuelle Projekt zu lernen. Bei dir sieht es jedoch fast so aus, als würde das „Lessons learned“ nur zu Projektende durchgeführt werden. Das ist natürlich ebenfalls richtig, aber für mich sind die beiden Feedbackschleifen in jedem Sprint mit die zentralen Erfolgsfaktoren für Scrum (->Kaizen).

    – Du sprichst im Kapitel „Werkzeuge“ von einem Tracker und nennst als Beispiel dafür ein Wiki. Das würde ich durchaus unterschreiben, jedoch evtl. noch ergänzen, dass man das auch mit einfachen Klebezetteln an einer Wand machen kann. Für unerfahrene Zuhörer (von denen auch nicht klar ist, wie gut sie sich mit Technik auskennen) könnte sich das ansonsten nach einer Einstiegshürde aussehen, die sie erst überwinden müssen (-> Kostet das Geld? Wer kann so etwas aufsetzen? etc.). Ein einfaches Scrum Board mit ein paar Klebezetteln reicht aber in den allermeisten Fällen völlig aus – v.a. wenn man sich eh jeden Tag persönlich trifft (wovon ich bei Schülern derselben Schule einfach mal ausgehe :).

    Ich überlege mir übrigens seit einiger Zeit, ob ich etwas ähnliches nicht auch zum Thema Kanban machen soll. Kanban ist momentan gerade stark im Kommen, da es sich auch für Projektumfelder eignet, in denen Scrum nicht funktioniert, z.B. bei Support-Teams, wenn verschiedene Servicelevel im Spiel sind, oder ganz allgemein für Organisationen, in denen abrupte Veränderung ein Problem ist (Kanban ist hier wesentlich sanfter als Scrum).

  2. rd (Freitag, der 22. Juli 2011)

    Danke Bernhard!

    Werde Deine Anregungen im Falle einer Wiederholung des Vortrages einbauen. Im Vortrag habe ich übrigens gleich zwei Werkzeuge empfohlen: Ein Wiki und einen Tracker! Aber Du hast völlig recht, auch hier gilt KISS („Keep it simple and stupid“ oder ironisch: „Keep it simple, stupid“), siehe auch meine Abhandlung dazu, von der ich immer noch begeistert bin! 🙂

    Eine kleine Korrektur: Die Schüler waren nicht von einer Schule, sondern kamen ihm Rahmen eines Eliteprogrammes aus ganz Bayern und mussten so auch verteilt zusammen arbeiten. Sie hatten sich übrigens schon vor meinem Vortrag auf facebook als Kommunikationsplattform geeinigt. Ist auch interessant – FB als Projekt Management Werkzeug! 🙂

    Zu Deiner Idee, einen einfachen KANBAN-Vortrag vorzubereiten, kann ich Dich nur ermuntern.

  3. bf (Dienstag, der 26. Juli 2011)

    Hier übrigens noch ein ganz spannendes Tool aus dem Kanban-Bereich: http://flowkaizen.com/

    Damit kann man eine aus Klebezetteln bestehende Kanban- bzw. Scrum-Tafel per Bilderkennung vollautomatisch in ein elektronisches System überführen.

    Technisch basiert es auf einer Kombination aus festem (und daher bekanntem) Board-Layout, und QR-Codes, die auf die Klebezettel aufgebracht werden.

    Gibt aktuell nur 2 Probleme:
    – Es ist erst in der Beta-Phase (
    – Es wird auch in Zukunft ein reines „Cloud-Tool“ bleiben, d.h. es gibt keine Version zum runterladen o.ä.

    Für unser professionelles Umfeld daher wohl nur unter gewissen Umständen geeignet, für weniger kritische Projekte aber absolut top und eine tolle Verbindung von analoger und digitaler Welt!

Kommentar verfassen

*