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.

Das Projektmagazin (Abodienst) fasst in seiner neuen Ausgabe die Neuerungen von Microsoft Project 2010 zusammen:

• Ribbons (bekann aus Office 2007) erhalten jetzt auch Einzug in Project
• Planungmodus: Haben wir nicht alle schon einmal mit der automatischen Terminaktualisierung von Project gekämpft. Mit unabsehbaren Kettenreaktionen… Im Planungsmodus kann man jetzt auf manuell umschalten…
• Tasks kann man nun auch deaktivieren (statt sie gleich hart zu löschen)
• Weiter tut sich noch was in der Ressourcenplanung, z.B. um kurzfristige Spitzen zuzulassen
• Aus den Vorgangstreibern wird der Vorgangsinspektor
• Weitere Verbesserungen gibt es im Reporting, im Projektvergleich und in der Bedienung

Conventional project management practices, which originated in the 1950s using mathematical models and structured planning approaches, assume a stable and predictable environment. Conventional project management works well and should be used for predictable, repeatable projects; however, this approach has proven to be no match for chaotic 21st century projects.

aus:

Kathleen B. Hass (Amazon)
Managing Complex Projects: A New Model
Management Concepts, Vienna (USA) 2009
ISBN-10: 1567262333
IBSN-13: 978-1567262339

S. 32

Auch Kathleen Hass folgt einer systemorientierten Sichtweise von Projekten. Sie spricht von „complex adaptive systems“ und entwickelt in ihrem Buch ein eigenes Project Complexity Modell.

Mit der systemorientierten Sichtweise und dem Fokus auf die Komplexität trifft sie bei mir einen Nerv, dem ich nur zu gerne folge.

In ihrem Project Complexity Modell unterscheidet sie dann independet, moderately complex und highly complex projects. Mit ihrem Versuch diese Kategorien messbar zu machen und zu quantifizieren macht sie sich natürlich beliebig angreifbar. Der Versuch ist ehrbar, vermessen und muss natürlich scheitern. Nimmt man aber die Quantifizierung und konkrete Ausprägung nicht ganz so wichtig, sondern würdigt mehr die dahinterstehende Idee, so bleibt das Buch absolut lesenswert. Es handelt sich ja auch nicht um ein Lehrbuch, sonder um einen fundierten Diskussionsbeitrag, der zur weiteren Reflexion anregt.

In der zweiten Hälfte des Buches setzt sie sich dann dezidiert mit den möglichen Komplexitätsquellen in Projekten auseinander. Als solche werden genannt und ausführlich behandelt:

• large, long duration projects
• large, disperse, culturally diverse project teams
• highly innovative, urgent projects wth agressive scopes and schedules
• complexities caused by ambigious business problems, oppotunities, and solutions
• poorly understood, volatile requirements
• highly visible strategic projects, which are often politically sensitive
• large scale change initiatives
• projects with significant dependencies and external constraints
• IT complexity

Kathleen B. Hass
Managing Complex Projects: A New Model,
Management Concepts, Vienna (USA) 2009
ISBN-10: 1567262333
IBSN-13: 978-1567262339

(Amazon Affiliate Link)

Die einfachste Form eines Projekttagebuchs oder Logbuchs lässt sich mit Windows-Bordmitteln erstellen. Erstellen Sie mit dem Notepad einfach eine neue txt-Datei. Dann tragen Sie in die allererste Zeile folgendes ein:

.LOG

Speichern und schließen sie die Datei (z.B. auf ihrem Desktop, damit sie sie immer schnell zur Hand haben). Beim nächsten Öffnen der Datei ergänzt der Notepad automatisch die akutelle Uhrzeit und das Datum:

.LOG
20:03 09.11.2009

Und nicht nur beim nächsten Mal, sondern immer wenn Sie die Datei neu öffnen:

.LOG
20:03 09.11.2009
Eintrag 1: Lorem ipsum dolor sit amet, consectetur adipiscing elit. Phasellus mollis ornare est sodales tempor. Nam quis iaculis nisi. Donec gravida, nunc tristique vestibulum porttitor, risus urna cursus mauris, non laoreet est urna vitae eros. Lorem ipsum dolor sit amet, consectetur adipiscing elit.

20:06 10.11.2009
Eintrag 2: …

Zugegebenermaßen nicht gerade komfortabel, aber als schnelle quick&dirty-Lösung durchaus ok.

Im frei zugänglichen Forum des Projektmagazins (ansonsten ein Abo-Dienst) hat die Moderatorin und Blogger-Kollegin Sigrid Hauer einen lesenswerten Thread gestartet: Gibt es das Projekt-Tagebuch wirklich?

Eine Reihe von Kollegen haben sich gemeldet, ja das gibt´s wirklich…

Da gibt es dann u.a. den Hinweis auf Wikis und Foren, aber die Erwähnung des Tools in diversen Standards und ganz persönliche Erfahrungen.

Ein Projekttagebuch ist zu allererst ein Werkzeug. Kein Heilbringer. Sinvoll eingesetzt kann es gute Dienste leisten. Aber um ehrlich zu sein, ich habe es noch nie im größeren Stil eingesetzt gesehen. Ich nutze es gerne z.B. im Rahmen einer Urlaubsvertretung, um den Rückkehrer schnellst möglich einen Überblick zugeben, bevor er sich durch einen eMail-Dschungel kämpfen muss oder in Projektphasen, die von Unklarheit geprägt sind, wenn die Aufgaben noch nicht strukturiert sind oder im Krisenmanagement, wenn die Ereignisse einen überrollen, um selbst wieder eine Übersicht zu gewinnen.