10 (scheinbare) Selbstverständlichkeiten im operativen Projektmanagement

In meinem letzten Blogpost „Deine Stakeholder sollen sich gefälligst entscheiden!“ ging es um einen Aspekt des Stakeholder-Managements – und ich hatte bereits angekündigt, demnächst mehr über meine Arbeit in Projekten und meine Übernahme zu berichten.

Heute ist es soweit: Ich nehme euch wieder mit in eine fiktive Situation, die ich im Projektalltag immer wieder erlebe – mit überraschenden Erkenntnissen, viel Kommunikationsbedarf und der Frage: Was darf man als Projektleitung eigentlich voraussetzen?

Es geht um unausgesprochene Standards, Routinen, die dann aber nicht wirklich existieren, und vermeintliche Selbstverständlichkeiten, die sich als alles andere als selbstverständlich entpuppen.

Ausgangssituation: Unzufriedenheit beim Kunden

Es war Herbst, als sich unser fiktiver Kunde bei meinem Arbeitgeber meldete, weil er unzufrieden über den Verlauf eines  Projektes war. Das Team bestand zu dieser Zeit aus einer Projektleitung und drei Entwicklern.

Der Kunde sah eine Lösung im Wechsel der Projektleitung und ich wurde gebeten, diese Rolle zu übernehmen. Eine Situation, die ich nicht zum ersten Mal erlebe. Aber in diesem Fall zeigte sich – auch das erlebe ich immer wieder – schon bei der Übergabe: Es gab einiges, das ich als selbstverständlich angesehen hatte, was in der Realität schlicht nicht gegeben war.

Erste Erkenntnis: Der Scope – oder eher: der große Nebel

Meine erste Frage an den bisherigen Projektleiter war simpel: „Was genau muss bis zum Projektende noch umgesetzt werden?“

Meine Erwartung:

Als PL habe ich einen Überblick über das, was noch zu tun ist – insbesondere, wenn das Projekt nur noch rund drei Monate läuft.

Die Realität:

Kein klarer Scope. Ein völlig überladener, unstrukturierter Backlog. Unpriorisierte Tickets, veraltete Einträge, Duplikate – eine wahre JIRA-Geisterbahn.

Meine (zugegeben direkte) Frage: „Warum hast du das denn nicht längst bereinigt?“
Die Antwort: „Ja, wollte ich ja, aber mit mir redet ja keiner.“
Das ließ mich erstmal sprachlos zurück.

Kein Kollegen-Bashing – sondern ein Appell

Ich möchte hier nicht den moralischen Zeigefinger heben oder jemanden bloßstellen. Vielmehr ist dies ein Aufruf an alle, die Projekte leiten:

Ihr seid das Kommunikationsdrehkreuz.

Ihr haltet die Fäden zusammen, vernetzt Stakeholder und treibt Entscheidungen voran.

Communication is King. Oder wie ich manchmal sage: „Projektleitung ohne Kommunikation? Das ist wie Schach spielen, ohne dem Gegner zu sagen, dass er dran ist.“

Was ich daraus gelernt habe

Im Zuge der Projektübernahme und beim Blick in Dailys, Backlog und Teamrunden habe ich mir einige grundlegende Leitlinien zusammengestellt. Dinge, die für mich in der Projektleitung selbstverständlich sind – und die ich heute gern mit euch teile:

10 (scheinbare) Selbstverständlichkeiten in der Projektleitung

1. Entscheidungen und relevante Infos werden schriftlich dokumentiert
   Egal ob in Confluence, per Mail oder im JIRA-Ticket.
2. Tickets, die begonnen wurden, werden zügig abgeschlossen
   a) Idealerweise fertiggestellt und ausgeliefert
   b) Alternativ sinnvoll gesplittet – Teil 1 fertig, Teil 2 ins Backlog
   c) Hauptsache: eindeutiger Status
3. Tickets werden kommentiert
   Mindestens dann, wenn sie im Board von Spalte zu Spalte wandern.
4. Jedes Ticket wird geschätzt
   Story Points ? Stunden ? Personentage.
5. Das JIRA-Board ist zentrales Arbeitsmittel
   Im Daily, im Jour fixe, in Reviews.
   So wissen alle, was läuft – oder eben nicht.
6. Wir kommunizieren aktiv – mit allen Beteiligten
   a) Entwicklerteam
   b) Fachbereich
   c) Kunden-IT
   d) Projektleitungskolleg:innen
   Ein „Mit mir redet ja keiner“ zählt nicht.
7. Restlicher Scope wird regelmäßig gegen Zeit und Kapazität geprüft
   a) Wenn’s klemmt: kommunizieren, priorisieren, nachjustieren
   b) Wenn’s am Anfang schon nicht passt: frühzeitig ansprechen!
8. Ausgelieferte Releases werden dokumentiert
   z.B. mit Confluence-Seite, JIRA-Release oder einfachen Release-Notes.
9. Dokumentation wird nicht vergessen
   Ab und zu prüfen, aktualisieren, aufräumen.
10. JIRA wird strukturiert genutzt
    Mit Sprints, Epics, Komponenten, Releases. Struktur ist kein Selbstzweck, sondern Grundlage für Klarheit.

Diskussionsanstoß an die Community

Ich bin mir sicher: Viele von euch nicken jetzt – andere vielleicht auch nicht. Und genau das interessiert mich.

• Welche dieser Punkte sind für euch selbstverständlich?
• Wo habt ihr ähnliche Erfahrungen gemacht?
• Oder ganz andere?

Ich freue mich auf eure Gedanken, Kommentare und Beispiele. Let’s talk PL!