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 Affiliate Link)

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.

Planungspoker ist ein „Spiel“, das mir erstmalig in der Auseinandersetzung mit agiler Softwareentwicklung über den Weg gelaufen ist. Um zu möglichst unvoreingeommenen Aufwandsschätzungen zu gelangen wird ein Spiel unter Experten initiiert. Jeder muss spontan mittels Pokerkarten den mir einem Funktionsbaustein/einer Use story verbundenen Aufwand schätzen. Alle Experten legen ihre Schätzung gleichzeitig auf den Tisch, damit sie sich nicht gegenseitig beeinflussen können.

Wie Aufwandsschätzungen mit und ohne Planungspoker ablaufen können beschreibt der agile Software-Blog

Erfolgreiche Projekte unterscheiden sich von weniger erfolgreichen Projekten häufig darin, dass sie sich auf das Wesentliche beschränken. Weniger ist eben häufig mehr. Apple´s Steve Jobs gibt uns in diesem Sinn mit auf den Weg: „(…) it´s only by saying no that you can concentrate on the things that are really important“ (aus: The Seed of Apple´s Innovation).
Nicholas Negroponte, Technologie-Guru des MIT, überspitzt für die Softwareentwicklung diesen Gedanken, indem er deutlich darauf hinweist, das viel wichtiger als die Zahl der Lines of Code mitunter die Zahl der eliminierten Code-Zeilen ist: „If programmers got paid to remove code from software instead of writing new code, software would be a whole better (aus: And the Rest of the Story).

(Beide Zitate nach: http://www.37signals.com/)

Was ist der schönste Plan wert? – Nichts.

Was zählt ist einzig und allein das Ergebnis der Umsetzung.

Wir werden uns nicht an unseren Plänen messen lassen müssen, sondern an ihrer Umsetzung!

„Everyone can read a book. Everyone cancome up with an idea. Everyone has a cousin that´s a web designer. Eversyone can write a blog. Everyone can hire someone to hack together some code.

The difference between you and everyone else will be how well you execute. Success is all about great execution.“

http://www.37signals.com/