Projekte leiten, nicht organisieren

Projektmanagement ist eigentlich ganz einfach. Und dennoch verlieren viele Projekt"manager" das Managen aus dem Auge und enden im Organisieren kleiner Aufgaben. Projektorganisierer haben kein große Idee und keine Übersicht.

 

Was macht also der Projektmanager während der Projekt-Phasen Initiierung, Planung, Ausführung, Überwachung, Abschluss & Review? In Punkten von A - O.

Mood: Ausschnitt Notizbuch
Bild: morgueFile

Initiierung

A. Für die Begründung des Projektvorhabens sorgen

Bereits unternehmenskulturell und auch im Kleineren sollte die schwierigste aller Fragen vorab geklärt sein: warum macht Ihr das Projekt eigentlich? Den Treiber für Euch und für den Kunden zu kennen, liefert Bewertungsgrundlage für alle anderen Fragestellungen. Das "Warum?" beantworten zu können, ist wirkungsvoll und hochmotivierend. Denn die Antwort wird bereits einfordern, dass Ihr Euch Bedingungen schafft, in dem das "Warum" leben kann.

B. Projektziele definieren

Während der Initiierungsphase ist das Ziel für das Projekt zu definieren. Die Zieldefinition erfolgt unter Beteiligung aller Projektpartner. Dafür ist es wichtig, genau diese zu kennen.

 

Es ist also ein Zielbild zu formulieren, dass von allen Projektbeteiligten mitgetragen wird.

 

Besondere Vorsicht ist hier bei internen Projekten geboten: hier erhöht sich die Anzahl der Projektpartner oft während des Projektverlaufs. Eine Herausforderung stellen auch Unternehmen dar, in der die Unternehmensziele nicht klar definiert sind. Hier gilt es, mit den Projektbeteiligten tragfähige Hypothesen abzustimmen.

C. Bewusst Projektkultur ausprägen

Während der Projektinitiierung wird die Projektkultur entscheidend geprägt. Wer in dieser Phase, offen und transparent über Ziele und TradeOffs spricht, wer auch zukünftig Probleme offen diskutieren können. Gleichzeitig machen alle Beteiligten klar, mit welchen Ansprüchen und welcher Haltung sie ins Projekt gehen.

 

Als Projektleiter solltest Du Dir in dieser Phase genau ansehen, wie sich Kommunikation, Ansprüche und Haltung der einzelnen Projektteilnehmer in Ansätzen zeigen - dies ist Euer Ausgangspunkt für die Teamentwicklung.

Planung

D: Regeln, Zusammensetzung & Rollen klären (moderieren)

Aus der Zielsetzung leiten sich fachliche und technische Ziele ab, die während des Projekts eingelöst werden sollen. In der Planungsphase sind mehrere wesentliche Punkte zu klären:

  1. Wie genau arbeiten wir zusammen?
  2. Wer sind wir? Wer gehört genau zum Team? Welche Aufgabe hat jeder?
  3. Wie schneiden wir die Arbeitspakete?
  4. Wie verläuft unser Change Management?
  5. Wie messen wir Projekterfolg?

Die ersten beiden Fragen sind Fragen, die uns aus Teamentwicklungsprozessen bekannt sind. Transparenz in der Teamzusammenstellung herzustellen ist sehr wichtig - genauso wie es wichtig ist, für ein festes, beständiges Team zu sorgen. Der Verlust an Motivation durch ständiges Einstellen auf neue Team-Mitglieder ist nicht zu unterschätzen. Das Aufstellen von Team-Regeln beginnt in der Planungsphase und setzt sich in die Ausführungsphase fort. Die Team-Regeln schließen alle Projektpartner, also auch Auftraggeber und Steuerungspersonen des eigenen Unternehmens, ein.

 

Ein Teil der Kommunikationsplanung sollte immer die Frage sein, ob und wie die Zielgruppe für das Endergebnis in den Entstehungsprozess einbezogen werden kann. Bei öffentlichen Websites sind UsabilityTests ein probates Mittel, bei internen Prozessen sind eine offenes Erwartungsmanagenent bzw. die Beteiligung der Zielgruppe zu diskutieren.

E: Teilprojektziele vereinbaren

Fachliche und technische Anforderungen laufen beim Schneiden der Arbeitspakete oft diagonal zueinander.

 

Zum Beispiel in einem E-Commerce-Projekt ist der UserFlow von einer Produktdetailseite bis zur Bestellbestätigung im Check-Out ganzheitlich und als Gesamterlebnis zu betrachten. Die fachliche (Marketingsicht, also konzeptuelle & Design-) Sicht schaut auf einen Prozess. Technisch gesehen stellen Produktdetailseite, die Anbindung des Payment Servcice Providers und das Anlegen von Kunden-Accounts unterschiedliche Software-Komponenten dar.

 

Hier gilt es im interdisziplinären Gespräch Anforderungen zu erkennen und einen gemeinsamen Schnitt der Arbeitspakete festzulegen. Dies ist wichtig, um eine gemeinsame Erwartung an das (Teil-)Projektergebnis zu erzeugen. Gleichzeitig wird dies helfen, eine sinnvolle Struktur in dem Zeiterfassungsystem für das Projekt anzulegen.

F. Kommunikator sein

Interdisziplinär heißt in diesem Falle: neben den Beteiligten auf Auftraggeberseite (Chef-Ebenen, Marketing, IT, ...) gilt es auch alle anderen Projektbeteiligten auf Eurer Seite zu identifizieren: Chef-Ebene, Projektteam. Falls diese nicht Teil des konkreten Projektteams sind, bedenkt auch spätere Nutznießer Eures Projekt wie die Qualitätsicherung oder den Betrieb.

G. Change Request Management explizieren

Durch eine klare Zieldefinition fällt es dem Projektteam und dem Auftraggeber leichter, Change Requests als solche zu identifizieren. Während der Planungsphase sollte vereinbart, wie im konkreten Fall der erkannte Change Request im Team und gegenüber dem Auftraggeber kommuniziert wird.

 

Dabei sind zwei Dinge zu klären:

  1. Wie erkennt das Team Change Requests?
  2. In welcher Form werden Change Request-Verhandlungen und -Ergebnisse dem Umsetzungsteam durch den Projektleiter offengelegt?

H. Qualitätskriterien ableiten

Zielsetzungen sind konkret zu formulieren. SMART (spezifisch, messbar, annehmbar, realistisch und terminiert) sollten sie sein. Das gilt sowohl für fachliche als auch technische Zielsetzungen (siehe z.B. ATAM).

 

Aus den Zielsetzungen sind möglichst konkrete Qualitätskritierien abzuleiten. Diese lassen sich, weil sie konkret sind, in Abnahmelisten in Form von UseCases übertragen. Ist die Konzeption des eigentlichen Gewerkes, sind diese Abnahmelisten im Laufe der Ausführungsphase zu definieren - natürlich im Einklang mit der übergreifenden Zielsetzung.

Ausführung

Gerade in der Ausführungsphase verlieren Projektleiter gerne die Übersicht und mutieren vom Leiter zum Organisierer. Projektmanagement lebt nicht von Tools, sondern von Kommunikation.

I. Für Takt, Transparenz, Beständigkeit sorgen

Um nicht aus dem Tritt zu geraten, ist es wichtig eine eine getaktete Vorgehensweise (gleichmäßiges, regelmäßiges Zu- und Abliefern) zu etablieren. Das Projektcontrolling für die einzelnen Schritte ist für das Team und den Auftraggeber nachvollziehbar.


Schwierige, risikoreiche Situationen sind offen zu thematisieren: auch das in alle Richtungen. Auftraggeber, die das Gefühl haben, dass etwas schief laufen könnten, haben großes Störpotenzial. Die gleiche Situation kann auch von allen gemeinsam gemeistert werden - mit dem Auftraggeber zusammen.

 

Das Projektteam sollte in einer festen Konstellation - räumlich nahe - miteinander arbeiten. Diese Beständigkeit sorgt für Effizienz in der Ausführung. Gleichzeitig ist ein Auge darauf zu halten, dass die vereinbarten Team-Regeln funktionieren und eingehalten werden.

 

Der Projektleiter gibt Orientierung in Aufgabenstellung, räumt Hindernisse aus dem Weg und sorgt für ein gutes Projektcontrolling.

Überwachung

J. Kurs halten: Steuermann /-frau ;-) sein

Das regelmäßige Projektcontrolling - also die Frage: bin ich auf Kurs? Wie lange braucht es noch? Was muss ich tun, damit wir Kurs halten? - ist eine Aufgabe, die

  1. durch Analyse von Zeit-Buchungseinträgen und  Blick auf Ticketsystemen beantwortet und
  2. durch Überprüfung der (Teil-)Projektziele und der daraus abgeleiteten UseCases überprüft wird.


Das ist eine zeitraubende Angelegenheit, die gerne als Erstes während eines stressigen Projektverlaufs "vergessen" wird. Damit wird einer sachlichen Bewertung der Situation die Basis entzogen. Gleichzeitig ist es vielen Projektteams eigen, dass sie die fachliche / technische Zieleinlösung nicht vollständig überprüfen.

 

Die Fragestellung "bin ich auf Kurs" wird mit Hinweis auf die gebuchten Stunden nicht weiter erörtert. Damit bleibt ein eingeschlagener Fehlkurs unentdeckt.

 

Eine weitere Form des Projektcontrollings ist die Einbindung des Kunden durch regelmäßige Teilabnahmen. Dieser Prozess führt zu einer Taktung des Projekts und führt zu Transparenz im Projektverlauf.

K. Sicherheit (durch Transparenz) geben

Das Projektteam und der Auftraggeber sollten daher Rituale vereinbaren, wie die Kursüberprüfung von allen Beteiligten vorgenommen werden kann. Empfehlenswert sind nach innen gemeinsame Status-Sitzungen des Teams, bei denen der Projektstand mit den zukünftigen Abnahmetests verglichen wird, nach außen regelmäßige Deployments mit lauffähigen Zwischenständen.

Abschluss

L. Livestellung planen

Ein Projekt endet nicht mit der Übergabe! Es ist Eure Erfahrung und Euer Gespür, mit der Ihr den Einsatz und das Ausphasen aller Projektteam-Mitglieder plant.

 

Im Team ist für eine gute Livestellung, Übergabe in den Betrieb und die Planung der Abnahme- (und die anschließende BugFixing- bzw. Abschluss-Phase) vorzunehmen. Es gibt zwei große Punkte zu klären:

  1. Der Auftraggeber und der -nehmer stimmen überein, dass das Projekt beendet ist. Formal läuft das über die Abnahme.
  2. Mit dem Abschluss beginnt oft etwas Neues: eine Maintenance-Phase oder ein neuer Release-Zyklus. Die Begleitung des Auftraggebers und des Teams in die neue Phase ist ebenfalls zu managen.

M. Übergabe begleiten

Während der Abnahmephase kommen die in UseCases formulierten Abnahmedokumente zum Einstatz. Gleichzeitig solltet Ihr die möglichen Fehlerklassen sauber und lebensnah definiert haben (möglichst schon im Vertrag). Wenn das fehlt, wird jeder vom Auftraggeber erkannte Fehler ein Blocker sein. Das wird dazu führen, dass Ihr bei jedem Fehler diskutiert, ob das stimmt und dieser Fehler wirklich abnahmeverhindernd ist. Das defokussiert Euch und das gesamte Team.

 

Viele Auftraggeber unterschätzen Ihren Anteil an dieser Projektphase. Das Managen von Erwartungshaltung und ein klares Aufzeigen der Auftraggeber-Aufgaben wird Euch helfen, dass Ihr auch diese Phase gut durchlaufen könnt. Plant die Abnahmephase gut durch.

 

Gleichzeitig kommen - je nach Projekt - Contentthemen, Produktionsfragen, Kampagnenplanung, Außenkommunikation, Beratung und Sorgentelefon für neue Intranets (!) für den Auftraggeber hinzu. Das hat Störpotenzial für Euch. Gibt es hier Unklarheiten auf Auftraggeber-Seite, droht die daraus entstehende Unruhe ins Projektteam überzuschwappen. "Wir machen uns die Probleme des Auftraggebers nicht zu eigen." Der Auftraggeber sieht selbst diese Fragestellungen viel wichtiger als die Abnahme.

 

Hier erfordert es Übersicht und Abstand des Projektmanagers, zu sehen, welche Aufgabenstellung auf welcher Seite liegt. Gleichzeitig könnt Ihr Euren Auftraggeber an Eurem Erfahrungsschatz teilhaben lassen, wie in Vor-Projekten vorgegangen worden ist. An dieser Stelle könnt Ihr - mit der notwendigen Distanz - ein wichtiger Ratgeber für Euren Auftraggeber sein.

Review

N. Erkenntnisgewinn forcieren

Das Projekt-Review schließt wieder alle Projektbeteiligten ein. Wichtig ist, dass Reviews und Review-Phasen ritualisiert erfolgen.

 

Wenn ein Projekt erfolgreich verlaufen ist, haben selten Projektteams Lust darauf, das Review durchzuführen: "Es besteht ja kein Anlass". Sofern es nicht gut gelaufen ist, hält eine eigentümliche Mischung aus Schuldgefühlen und Vorwürfen uns leicht davon ab, ins Review zu gehen.

 

Besser ist es, wenn Reviews nach jeder Abgabe eines Teilprojekts und auch nach Abgabe des Gesamtprojekts zum Standard gehören.

 

Während des Reviews sind folgende Punkte zu identifizieren:

  1. Welche Rituale / Regeln / Inhalte / Methoden liefen sehr gut - was sollte also beibehalten werden?
    Hierfür sollte man nicht nur das Offensichtliche benennen. Manchmal entwickelt man "still" neue, gute Methoden. Explizieren hilft für die nächste Runde.
  2. Was lief nicht gut? Welche Handlungsoptionen hätten bestanden?
  3. Was machen wir beim nächsten Mal anders?

Der Projekt-Review schließt alle Projektbeteiligten - also auch den Auftraggeber - mit ein.

A - O: Leiten, nicht organisieren

Wie gesagt: Projektmanagement ist eigentlich ganz einfach. Der Projektalltag bringt es mit sich, dass man vor lauter wichtigen Details den Blick fürs Große und den Rhythmus verliert.

O: Regelmäßig innehalten und das eigene Handeln überprüfen

Um das zu verhindern, um Projektmanager zu sein und nicht Organisierer zu werden, ist es wichtig, dass man das eigene Handeln, Verhalten und Rolle regelmäßig reflektiert.

 

Macht dafür einen Termin mit Euch selbst. Oder besser: vereinbart mit einem Kollegen eine regelmäßige kollegiale Beratung. Das wird Euch helfen, Euer eigenes Handeln zu beurteilen und - falls Ihr mal davon abgekommen seid - wieder auf den rechten Pfad zu kommen.

 

Dieser Blog-Post ist ein privater Beitrag von Judith Andresen.


Kommentar schreiben

Kommentare: 0