Projektkoordination "ruynk"

Herausforderungen des Projekt Managements

Ich mag nicht wirklich zu kritisieren. Leider aber sind Projekte bekanntermaßen Unterfangen, die regelmäßig Schwierigkeiten haben.

Nur 16% aller Softwareprojekte werden erfolgreich (hinsichtlich Zeit-, Budget und Funktionsvorgaben) abgeschlossen.
Rund 53% der Softwareprojekte werden mit erheblichen Defiziten zu Ende gebracht
und 31% der Projekte scheitern gänzlich, d.h. es sind glatte Fehlschläge
(Ergebnisse einer Studie der "Standish Group" aus dem Jahre 1994)

Allerdings muss ich hier der Vollständigkeit wegen anmerken, dass die "Standish Reports" auch scharf kritisiert werden. Es wird behauptet, das sie eine Verbreitung fanden die ganz und gar nicht verdient ist (siehe "Reconstructing Project Management": Peter W.G. Morris, Seite 242).


Trotz der Kritik von Herrn Morris an der oben genannten Untersuchung kann ich doch, aus meiner Erfahrung berichten, dass das Projekt Management als solches nicht wirklich so funktioniert wie es sollte.

Salvatorische Anmerkung:

Ist klar und es ist mir bekannt (und viele Projektmanager sind sich bewusst), dass das Projektgeschäft nun mal so ist wie es ist:

1. Wenn schon am Anfang die Wahrheit über die Länge und Kosten des Projektes bekannt wäre, befürchtet man (zu recht) dass das Projekt nicht durchgeführt wird.


2. Projekte werden mit einem (fahrlässigen) Optimismus gestartet: es wird der beste, sonnendurchflutete, risikofreie, technisch problemlose Gutsfall zu Grunde gelegt.
   Uns alle ist es klar, dass so einen Fall nicht vorkommt: Doch man spielt gerne der Überraschte, wenn die ersten Schwierigkeiten auftreten, um den ganzen Verlauf des Projektes nicht zu gefährden.
   Zu dieser Lage trägt dazu bei, unterstützend, die Erwartungshaltung des 'Managements', das nur positive Meldungen aufzunehmen bereit ist; alle Bedenken werden erbarmungslos im Keim erstickt.


3. Ein Projekt entsteht sehr oft durch eine politische Entscheidung und muss "politisch korrekt" bis zum bitteren Ende durchgeführt werden

Die Rolle des Projekt Managers

Hier eine Liste:

1. Initialisieren des Projektes
   
   • Auswahl der Projekt-Methode
   • Projektakte anlegen
   • Erstellung einer ersten Spezifikation
   • Schätzung des Umfanges
   • Expertenrat einholen
   • Risiken einschätzen und bewerten
   • Bestätigungen einholen




2. Planen
   
   • Projektplan erstellen
   • Umfang definieren
   • Untersuchung des Ergebnisses
   • Kosten/Leistungsanalyse durchführen
   • Alternativen untersuchen
   • Netzwerkanalyse
   • Simulationen berücksichtigen
   • Tools und Software festlegen
   • Planumfang definieren
   • Arbeitspakete definieren
   • Aktivitäten definieren
   • Risiken minimieren
   • Schätzen der Dauer der Aktivitäten
   • Schätzen der benötigten Ressourcen
   • Kosten schätzen
   • Budgetieren
   • Qualitätssicherung planen
   • Teams planen
   • Kommunikation planen
   • Stakeholder identifizieren
   • Qualitative Risiken bewerten
   • Quantitative Risiken bewerten
   • Risikoplan erstellen
   • Einkäufe und Beschaffungen planen
   • Vertragswesen planen
   • Bestätigungen einholen




3. Laufende Aufgaben
   
   • Projektablauf leiten und koordinieren
   • Planung nachplanen
   • Qualitätssicherung leiten
   • Risikomanagement leiten
   • Projektteam leiten
   • Projektteam entwickeln
   • Information verteilen
   • Beschaffungen organisieren
   • Lieferanten auswählen
   • Bestätigungen einholen




4. Steuerung und Kontrolle
   
   • Projekt durchleuchten und steuern
   • Change Management durchführen
   • Konfigurationsmanagement durchführen
   • Trend-Analyse
   • Varianz-Analyse
   • Budget-Analyse
   • Umfang verifizieren
   • Termine kontrollieren
   • Kosten kontrollieren
   • Leistung messen
   • Qualitätssicherung kontrollieren
   • Projektteam steuern
   • Berichtwesen durchführen
   • Stakeholder steuern
   • Risiken überprüfen
   • Zu ausgewählten Stakeholder berichten
   • Verträge kontrollieren ggf steuern
   • Bestätigungen einholen




5. Abschließende Arbeiten
   
   • Verträge abschließen
   • Review durchführen
   • Durchführen der abschließenden Arbeiten
   • Bestätigungen einholen

Ein Teamleiter soll nicht übermäßig viel Arbeit erledigen/machen (Buch "Adrenalin Junkies und Formular Zombies", Tom Demarco, Kap. 39).

Das neuzeitliche Durcheinander: "Agil"

Diese Haltung ergibt sich aus vielen Jahren Erfahrung sowohl mit "herkömmlichen" (klassischen) Projekten als auch in "agilen" Umgebungen.

Natürlich bin ich als Qualitätssicherer wohl nicht unvoreingenommen: Als solcher bin der Auffassung, dass alles getestet werden muss (meine Einstellung: "Vertrauen ist gut, Kontrolle ist besser"). Und ja, zugegeben; ich bin ein Kontrollfreak.

Ich habe mich mit den "agilen Methoden" schon bald 10 Jahren auseinandergesetzt (im Jahre 2008 hatte ich schon damit angefangen, sie zu verstehen - bis heute habe ich es nicht fertig gebracht! -.

Am Anfang war ich sehr interessiert und habe viel über sie gelesen...
denn die Probleme mit der herkömmlichen Projektarbeit waren mir durchaus bekannt und geläufig
- ein Dorn im Auge, gewissermaßen -.

Nach mehreren Jahren Auseinandersetzung mit den "Agilen", plus 5 Jahren agiler Arbeitserfahrung, waren mir die Unzulänglichkeiten der "Agilen" ebenfalls bewusst und wohlbekannt.

Aus diesen Untersuchungen, viel Erfahrung und mein Wissen als Systemanalytiker entstand eine neue (nicht agile!) Methode: FlePA.

FlePA steht für "Flexibles Planen und Arbeiten" und stellt eigentlich einen Rahmen für die Projektdurchführung und nicht eine Methode dar.

Sollten Sie bzw Ihre Firma im Strudel der "Agilen" geraten sein, berate ich Sie gerne um einen "Ausweg aus der agilen Falle" zu finden.



Eine der "agilen" Ideen ist, dass die Teams sich selbst organisieren sollen (wie schon weiter oben erwähnt, eine idee der Management-Chaostheorie).
Einerseits is das gut, denn das Projekt Management dadurch entlastet wird und, wie weiter oben beschrieben (die Rolle des Projekt Managers), sind die Aufgaben des Projekt Managers so vielfältig, dass diese Idee nicht unangebracht zu sein scheint.

Andererseits aber ist das Interagieren der Mitglieder des Teams dermaßen wichtig, dass man es eigentlich nicht dem (agilen) Zufall überlassen sollte.

Denn es gibt sie, auch wenn man sie nicht haben möchte und das 'Management' es nicht hören will: die Konflikte.

Ich will nicht sagen, dass es eine Aufgabe des Projekt Managers ist, das Interagieren der Teammitglieder zu steuern, doch es ist eine Aufgabe, die durchgeführt (und kontrolliert) werden soll.

Zitate, die zu "Agile" passen:

Es gibt viele Projektmitarbeiter, die zu Fundamentalisten werden, Diese sind Gift für Projekte (Buch "Adrenalin Junkies und Formular Zombies", Tom Demarco, Kap. 10).


Ein Modell oder Methode soll angepasst werden (Buch "Adrenalin Junkies und Formular Zombies", Tom Demarco, Kap. 12).


Verantwortlichkeiten sollen ganz genau definiert und verteilt werden. Selbstorganisierte Teams wo alle alles und jeder mitmachen darf, kann und soll ist natürlich Nonsens (Buch "Adrenalin Junkies und Formular Zombies", Tom Demarco, Kap. 20).


Am Ende eines Marathons einen Spurt hinzulegen, ist sinnvoll; 42 Kilometer lang zu spurten, ist verruckt. Wenn Sie ein paar hundert Meter gespurtet sind, rollen Sie danach am Boden, halten sich den Bauch und ringen ein paar Minuten lang nach Luft, bevor Sie an einen weiteren Sprint auch nur denken konnen.
Einen Spurt-Keuch-Spurt-Keuch-Marathon zu laufen, wurde vermutlich zwei-mal so lang dauern, wie 42 Kilometer normal zu laufen.
(Buch "Spielraume - Projektmanagement jenseits von Burn-out, Stress und Effizienzwahn", Tom Demarco, Kap. 9).

[Mein Kommentar: Das zeigt, wie realitätsfern das Sprint-Konzept der "agilen" ist, welches bei "Scrum" Standard ist...]