Ein neuer Beitrag für unsere kleine VisualPM-Serie: Kelly Waters zeigt wie agile Teams Kalender zur Visualisierung nutzen können. Das Beispiel – ein Flipchart-Kalender mit vielen bunten Post-its – veranschaulicht deutlich, dass es nicht auf das Medium ankommt, dass Hemdsärmlichkeit durchaus erlaubt ist, aber die Visualisierung der wesentlichen Inhalte ist das Entscheidende

Andreas Heilwagen setzt sich mit mit dem neu erschienen Risikomanagement-Standard des PMI auseinander. Der Standard erweitert die Ausführungen des PMBOK. Die 116 Seiten scheinen noch jede Menge Luft zu enthalten und es handelt sich um die Dokumentation eines Standards, d.h. Fachliteratur zum Risikomanagment geht mitunter deutlich weiter.

Alec Satin gibt 72 Project Management Tipps. Eigentlich sind es keine Tipps, sondern es handelt sich eher um eine Checkliste. Die einzelnen Punkte sind als Fragen formuliert.

Wenn wir schon beim Thema Scheitern und Desaster sind, kann Toll Collect nicht lange auf sich warten lassen.
Zur Best Practice in solchen Projekten scheinen Geheimverträge zu gehören.
Na prima!

Projekterfolg ist sicherlich eines der „Lieblingsthemen“ auf schlossBlog. Die Computerwoche schreibt nun wie Herkules, das IT-Großprojekt der Bundeswehr, immer mehr zum Desaster gerät.

Je größer ein Projekt, desto höher die Wahrscheinlichkeit des Scheiterns. Und dennoch: Gibt es ernsthafte Alternativen zu solchen Großprojektmonstern bei insbesondere Infrasturkturthemen? Bestimmte Veränderungen erfordern mitunter einen schmerzhaften Kraftakt, den niemand lostreten würde, wenn im Vorfeld die Kosten und Konsequenzen ehrlich diskutiert würden und doch ist der Druck zur Veränderung unüberwindlich. Insofern keine Häme über gescheiterte oder schlecht laufende Projekte!

Das soll aber kein Freibrief für Managementfehler in Projekten sein. Hierzu eine Anekdote zu Herkules: Im vergangenen Jahr waren IT-Dienstleister auf der Suche nach Rolloutmanagern für Herkules. Die Preisvorstellungen waren allerdings weniger für Management-Aufgaben geeignet. Wenn das Projekt am Ende so gestafft worden sein sollte, dann wundert mich jetzt gar nichts mehr…

Für Glen B. Alleman liegt der Startpunkt für Projekterfolg in der Project Governance. Project Governance muss für die Verbindung mit der Geschäftsstrategie sorgen, d.h. dafür sorgen dass auch die „richtigen“ Projekte gemacht werden, denn nur diese führen auch zu einem „gefühlten“ Projekterfolg. Selbst erfolgreich abgeschlossene Projekte verpuffen in ihrer Wirkung, wenn Ihnen die Ausrichtung auf das, was wirklich gebraucht wird, fehlt.

 Balanced Scorecard oder Portfoliobetrachtungen sind hier bewährte Methoden. Ich beobachte aber bei aller Berechtigung dieser Ansätze einen gewissen Overkill in Project Governance und Portfoliomanagement:

Die meisten Unternehmen haben gelernt sich in Projekten zu organisieren. Über die Governance hinaus wird aber vergessen, was es braucht um Projekte erfolgreich zu gestalten. Projektleiter kämpfen in den Governance-Prozessen um ihr Budget, bedienen die Bürokratie, reporten und administrieren, aber haben längst vergessen (oder nie gelernt) was Projektmanagement ist, wie man im Projektteam arbeitet, Probleme löst, kommuniziert, etc..

Im Projektportfolio liegen zwar mehr oder weniger die richtigen Projekte, aber wie man diese „richtig“ umsetzt ist auf der Strecke geblieben. Danach fragt die Governance i.d.R auch nur sehr formal.

Project Governance kann das i-Tüpfelchen auf einer vielversprechenden Projektkultur sein, aber Project Governance kann diese nicht ersetzen. Insofern würde ich Glen B. Alleman widersprechen: Der Startpunkt für Projekterfolg liegt in der Projektkultur. Project Governance ohne Projektkultur ist eine leere, sinnlose Hülle.

Pat Weaver setzt sich in einem lesenswerten Thread auf Mosaicproject´s Blog mit dem Planungshorizont, genauer: mit der „Planungsdichte“ – Schedule Density auseinander. Bei weitem nicht alle Vorgänge brauchen die gleiche Planungstiefe. Anfangs reichen gröbere Abschätzungen, aber für die heißen Phasen kommt man um eine Detaillierung nicht herum. In vielen IT-Projekten kann man dies bestätigt finden. Werden Konzeption, Realisierung und Test mitunter noch auf Tages- oder Wochenebene geplant, kann es für GoLive oder Migration schon in den Minutenbereich gehen. Häufig entstehen dann eigene Planungen neben der Gesamtprojektplanung (nämlich Migrationsplan oder GoLive.Plan).

Christian Henner-Fehr hat im Mission Paradox-Blog einen Beitrag zum Thema Planung ausgegraben und fasst noch besser als im Original zusammen:

„…es geht um das Nachdenken an sich und gar nicht so sehr um das Ergebnis des Nachdenkprozesses.“

Wir wissen alle, dass fast jeder Plan sich zumindest in Detailausprägungen als falsch erweisen wird, aber darauf kommt es gar nicht an. Digitales Denken (richtig/falsch) sind hier die falschen Kategorien. Viel mehr ist es wichtig sich mit dem Gegenstand und der Komplexität des Gegenstandes auseinanderzusetzen. Die Planung ist also weit wichtiger als der Plan. Der Plan ist zwar Output der Planung, aber eben nicht das einzige Ergebnis! Auf dem Weg dahin liegen viele Erkenntnisse über Gegenstand, Umfeld und Vorgehen verborgen, die mitunter noch weit wertvoller sein können, als der Plan an sich.

Neuerdings häufen sich untern den Anhängern von agilen Methoden Posts über Kanban. So widmen sich z.B. Pawel Brodzinski und Henrik Kniberg dem Thema.

Kanban kommt eigentlich aus der Produktionssteuerung und beruht im Wesentlichen auf dem Pull-Prinzip. Statt einer zentralen Steuerung (also übertragen einer zentralen Planvorgabe), wird dezentral ja nach aktuellem Bedarf (also situationspezifisch je Sprint) Material (also Input/Requirements/Zulieferungen) abgerufen.

Auch über Lean Management findet man gelegentlich ähnliche Übertragungen auf das Projektmanagement.

Die guten alten Management-Methoden finden also im Projektmanagement und der Softwareentwicklung ein erfolgreiches Recycling.

Sowohl über David Allens  GTD (Getting things done) als auch über Mindmaps wurde hier schon berichtet. Im MindjetBlog zeigt Michael Deutch wie man Mindmaps bei der Umsetzung von GTD nutzen kann.

Ich selber führe z.B. das, was David Allen seine Project List nennen würde, als Portfolio in einem Mindmap. Die Hauptäste spiegeln Phasen wieder: Ideen, In Vorbereitung, In Arbeit, Nachbereitung, Erledigt. Darunter kommen die einzelnen Projekte, manchmal sogar noch mit weiteren Ästen untergliedert. Mit Farben werden die Projekte kategorisiert und Fahnen visualisieren den aktuellen Status eines Themas. Während ihres „Lifecylces“ wandern die Projekte dann per Drag-and-Drop durch die Phasen.