Hal Macomber von Reforming Project Management philosophiert über Lean Projects und Lean Project Management. Über Lean Project Management war an dieser Stelle auch schon zu lesen. Hal attestiert am Beispiel Toyota eine interessante Entwicklung, die von einer Toolorientierung hin zu einer Orientierung am Menschen geht (erinnert schon fast ein bisschen an agile Philosophien):

Now they speak about the two pillars of continuous improvement and respect for people. It’s a shift from tools to tool users.

Und weiter:

Lean is a mindset. It’s not a set of practices.

Seine Schlußfolgerungen für das Projektmanagement fallen dann aber etwas dürftig in Eigenwerbung für das Last Planner® System aus. Nach der lesenswerten Einleitung hätte man sich etwas anderes als ein Planungssystem erwartet…

Wie im vorangehenden Beitrag angekündigt, hier eine kurze Beschreibung zum Projektplan-Template:

• Die Datei hat drei Reiter, zwei davon mit Planungstemplates, einer mit Hilfsdaten. Auf den Einsatz von Makros wurde bewusst verzichtet.
• Aus den Angaben Projektbeginn (B2) und Projekteende (B3) in den Template-Reitern wird die Beschriftung der Datumsachse abgeleitet.
• Der Zellbereich A5:G1005 ist in den beiden Templates als Tabelle definiert. und dient der Erfassung der Planungsdaten.
• Im Reiter berechnete Dauer wird davon ausgegangenen, dass in der Tabelle Anfangs- und Enddatum zu jedem Vorgang erfasst werden. Die Berechnung der Dauer in Arbeitstagen (und nicht in Kalendertagen) erfolgt dann automatisch per Excel-Formel.
• Im Reiter berechnetes Ende wird wiederum aus der Eingabe von Vorgangsdauer und Anfangstermin, das Endedatum ermittelt.
• Für die Zuordnung der Verantwortlichen für einen Vorgang kommt die Namensliste aus dem Hilfsblatt (ebenfalls als Tabelle definiert) zum Einsatz. Mittels Gültigkeitsüberprüfung wird in den entsprechenden Eingabefeldern der Planungsreiter eine Dropdwonliste mit den Namen aus dem Hilfsblatt angezeigt.
• Die Vorgangsbalken, sowie die graue Hinterlegung der Wochenenden (zur besseren Orientierung) erfolgt über bedingte Formatierungen. Excel 2007 ist im Gegensatz zu den Vorgängerversionen hier nicht auf drei Regeln beschränkt.

Die Frage ist müßig: Warum sollte man ein GANTT-Chart (Balkendiagramm) in Excel erstellen? MS Project macht das doch automatisch.

Und trotzdem: Im Projektalltag verfolgen uns diese Excelplanungen dann doch. Nicht jeder, der den Plan lesen muss, hat auch einen Project Client, Excel ist sowieso zur Hand, diverse Listen und Planungen liegen bereits im Exel-Format vor,…

Ich glaube, ich habe schon mehr Excle-Templates für Planungen gesehen, als es PM-Tools gibt. Ignatz Schels ist ein Meister solcher Excel-Tools, aber auch im Internet wird man fündig: Stefan Hagen hat jüngst eine Variante mit GoogleDocs eingestellt, die sich nach Excel exportieren lässt. Bei Microsoft findet sich eine Variante, die die Diagramm-Funktionen von Excel nutzt. Hier ein ähnlicher Vorschlag auf Online-Excel.de. Auch im Abo-Dienst des Projekt-Magazins sind schon einige Beiträge zum Einsatz von Excel erschienen. Auch mein Testmanagement-Toolset im Projekt-Magazin, enthielt eine Variante. Als kleine Spielerei habe ich die darin enthaltene Lösung noch etwas aufgebohrt. Den Download für dieses Templates für Excel 2007(!) finden Sie hier. Die Datei ist bewusst im XLSX-Format, da einige Funktionen genutzt werden, die in älteren Excel-Versionen nicht zur Verfügung stehen. Eine Beschreibung zum Template finden Sie im nächsten Beitrag.

In einem Interview in Air&Space spricht Chesley Sullenberger über seine spektakuläre Airbus-Landung im Hudson River. Bemerkenswert vor allem gegen Ende der Passus über die Verwendung von Notfall-Checklisten (soviel zum Thema Grenzen der Planung):

Air & Space: Does the Airbus operator’s manual have a procedure for ditching?

Sullenberger: Yes.

Air & Space: So your first officer would have found that procedure and had a checklist to go through for the ditching procedure?

Sullenberger: Not in this case. Time would not allow it. The higher priority procedure to follow was for the loss of both engines. The ditching would have been far secondary to that. Not only did we not have time to go through a ditching checklist, we didn’t have time to even finish the checklist for loss of thrust in both engines. That was a three-page checklist, and we didn’t even have time to finish the first page. That’s how time-compressed this was.

Im Editorial der aktuellen Ausgabe von Projektmanagement aktuell, nimmt Heinz Schelle in bemerkenswerterweise Stellung zur projektbezogenen Einsatzmittelplanung:

„… Wie auf dem Gebiet der projektbezogenen Einsatzmittelplanung, wo man sich leider wieder auf  ‚dumme‘ Algorithmen besinnt, statt einzusehen, dass die auf Vorgängen und Arbeitspaketen basierende Planung ein Irrweg war, feiert Operations Research, meiner Meinung nach im Projektmanagement längst glorreich gescheitert, fröhliche Auferstehung. Geboten wird nicht, was das Projektmanagement braucht (Nachfrageorientierung), sondern was die Mathematik hergibt (Angebotsorientierung).“

Andreas Heilwagen greift die Diskussion von Meilensteinen und Stage Gates von Glen Alleman auf, der stattdessen für die Verwendung von klar definierten Metriken für die Fertigstellung plädiert. Unter Hinweis auf den häufig vertraglichen Charakter von Meilensteinen und Stage Gates plädiert Andreas Heilwagen für die Nutzung solcher Metriken im Rahmen von Meilenstein- und Stage Gate-Konzepten.

Theoretisch kann ich dem voll und ganz zustimmen. Praktisch sieht es aber leider etwas anders aus, denn eigentlich erfordert das Reissen eines Meilensteins oder das Verpassen eines Stage Gates klare Konsequenzen, die im Projektalltag so häufig gar nicht gewünscht sind – von allen Beteiligten!! Wenn eine Testphase nur zu 80% abgeschlossen ist, der gewünschte GoLive-Termin aber verschoben werden müsste, werden sich i.d.R. Auftraggeber und Projektteam tief in die Augen schauen und eine Risikoabwägung vornehmen, die so in keinem Projektplan vorgesehen war. Es ist illusorisch anzunehmen, dass alle Unabwägbarkeiten eines Projekts in den vertraglichen Beziehungen eindeutig vorab geklärt werden können. Voraussetzung, dass solche AdHoc-Anpassungen nicht ein reines Hasardeurspiel werden, ist ein höchstes Mass an Transparenz und Vertrauen zwischen den Beteiligten. Vertragliche Regelungen und theoretische Konzepte können wieder einmal keine Projektkultur ersetzen, sondern setzen diese voraus.

Passend zum Thema Denkschulen ist auch meine aktuelle Lektüre:

Henry Mintzberg, Bruce Ahlstrand, Joseph Lampel, Strategy Safari – Eine Reise durch die Wildnis des strategischen Managements, Wien 1999. (Amazon)

Hier geht es zwar nicht um Projektmanagement, sondern um Denkschulen im strategischen Management, nämlich:

1. Designschule: Strategieentwicklung als konzeptioneller Prozess
2. Planungsschule: Strategieentwicklung als formaler Prozess
3. Positionierungsschule: Strategieentwicklung als analytischer Prozess
4. Unternehmerschule: Strategieentwicklung als visionärer Prozess
5. Kognitive Schule: Strategieentwicklung als mentaler Prozess
6. Lernschule: Strategieentwicklung als sich herausbildender Prozess
7. Machtschule: Strategieentwicklugn als Verhandlungsprozess
8. Kulturschule: Strategieentwicklung als kollektiver Prozess
9. Umweltschule: Strategieentwicklung als reaktiver Prozess
10. Konfigurationsschule: Strategieentwicklung als Transformationsprozess

Travis Anderson hat einen lesenswerten Beitrag über den Einsatz von Activity Based Costing im Projektmanagement (Englisch) verfasst. Die Kostenzuordnung auf Aktivitäten orientiert sich dabei an der Work Breakdown Structure (WBS).

So wohl überlegt die Ausführungen sein mögen, habe ich dennoch meine Bauchschmerzen mit dem Einsatz solcher high sophisticated Methoden im Projektmanagement: Natürlich braucht PM Kostenüberwachung und Kostenschätzungen, je deaillierter die Modelle hierfür sind, desto größer wird allerdings auch der bürokratisch/administrative Aufwand. Je größer dieser Aufwand, umso mehr entfernt sich die Sicht von der Projektrealität. Die Administration will mit Zahlen gefüttert werden, also bekommt sie Zahlen. Nach meiner persönlichen Erfahrung finden sich die vermeintlich ausgefeiltesten PM-Methoden meist dort im Einsatz, wo von Projekten im engeren Sinn gar nicht mehr gesprochen werden kann, wo es eher um regelmäßige Tasks oder Aufgaben geht. Ein dynamisches Projektumfeld braucht hingegen eine gewisse „Hemdsärmligkeit“.

Danny Quick erinnert daran, dass auch für Projekte die Grenzen der Machbarkeit gelten. Was selbstverständlich sein sollte, wird doch immer wieder vergessen. Oder verdrängt?

In einem XING-Thread hat  Ronald Derler eine Umfrage unter Projekt-Professionals über den Einsatz von PM-Software gestartet.

Auffällig ist, dass MS Excel alle anderen Applikationen in der Häufigkeit der Nennung schlägt.

Interessant hierzu auch ein Forums-Beitrag von Georg Angermeier im Forum des Projektmagazins:

„Marktführer“ im Bereich der für Projekte eingesetzten Software ist zweifelsohne Microsoft Excel! Über das Thema „Microsoft Project“ lässt sich sehr lange und kontrovers diskutieren. Eines gilt aber sicherlich: Es ist weder das funktionsreichste noch das leistungsfähigste Programm. Dies sind aber auch nicht die Kriterien für die Software-Auswahl. Je nach Branche und Markt ist Microsoft Project auch nicht Marktführer. Beispielsweise ist Asta Powerproject im Bauwesen dominant, Primavera im Großanlagenbau.