Archiv der Kategorie ‘Projektmanagement‘

 
 

#293 Planungshorizont und „Planungsdichte“

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).

#292 Der Plan ist tot. Es lebe die Planung!

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.

#291 KANBAN

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.

#290 GTD & Mindmaps

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.

#289 Microsoft Project 2010

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

#287 Quote: Conventional Project Management

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

#286 Gelesen: Managing Complex Projects

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)

#283 Projekttagebuch selbstgemacht

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.

#282 Projekttagebuch

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.

#281 Status Reports und die Realität

In einem Gastbeitrag auf PMStudent setzt sichSusan de Sousa damit auseinander ob Statusberichte tatsächlich den Projetkfortschritt wiedergeben und hat natürlich auch gleich ein entsprechendes Negativbeispiel an der Hand.

Das Grunddilemma liegt wohl darin, dass die Berichterstattung gleichzeitig für die unterschiedlichsten Berichtszwecke eingesetzt wird. Ja, klar soll ein Statusbericht Transparenz in das Projekt bringen. Ja, aber er dient auch der Rechtfertigung (manchmal auch der Schuldzuweisung). Mitunter der Außendarstellung. Von hidden agendas einzelner Beteiligter noch ganz abgesehen…

Manchmal dient er auch dazu das Gesicht zu wahren und einen Neuanfang zu ermöglichen. Hierzu ein echtes Beispiel:
In einem Projekt durfte ich ein Review aller Teilprojekte durchführen und betreuen. Alle Beteiligten gingen sehr förmlich und höflich miteinander um, schließlich diente das Review der Einphasung eines neuen Projektleiters. Es wurde gelogen, dass sich die Bretter nur so bogen: alles bestens – ein paar Schwierigkeiten hier und da, aber im eigenen Teilprojekt kein wirkliches Problem. Ich unterstelle allen Beteiligten genügend Intelligenz, dieses Lügenspiel durchschaut zu haben, aber dennoch hat niemand widersprochen, denn das Review erlaubte einen „sauberen“ Schlußstrich unter die Vergangenheit, der in einem entsprechenden Lügenreport verewigt wurde und es gelang in der Tat ein gesunder Neuanfang.

Bitte nicht missverstehen, das war jetzt keine Aufforderung zur Lüge, sondern eher zum richtigen Umgang mit Berichten. Fünfe gerade sein lassen, kann mitunter sinnvoll sein, aber im genannten Beispiel ist dies auch nicht aus Ahnunglosigkeit geschehen, sondern aus politischem Geschick, das letztendlich zur Teambildung beitrug.



bernhardschloss.de