Inhalt
Startseite: Leinen los!
PM Früher bis Heute (Geschichtliches)
PM Heute (die Gegenwart)
Die Herausforderung "PM" (PM verbessern)
Zen-PM (oder "Meditatives PM")
FlePA (Flexibles Planen und Arbeiten)
Leistungsangebot (IT / Projekt-Wissen und -Können)
Werdegang (Stationen des Laufens im Leben)
Downloads (Was Sie gleich mitnehmen können)
Externe Links / Externe Informationen
Rechtliche Informationen (Impressum, Datenschutz, etc)
Kontakt: Nicht verzagen, gleich fragen!
Ich "distanziere" mich nicht
(Unsinnige Rechtslage in der BRD).
|
"Zen" Projekt Management
oder
Meditatives Projekt Management
Warum schreibe ich von einem "meditativen" Projekt Management?
Wie ein chinesisches Sprichwort besagt: "Achte auf Deine Gedanken -
sie sind der Anfang Deiner Taten".
Es ist nicht schwer einzusehen, dass besonders für Projekte, wo Neues
geschaffen wird, eine Denkleistung unabdingbar ist.
Nennen Sie es wie Sie wollen; "Denken", "Meditieren", "Überlegen". Der
Punkt ist, ein Projekt ohne Denkarbeit ist gar kein Projekt (ist eine
"Arbeit", "Tätigkeit" oder "Aufgabe").
Klassisch
"Klassische" Projekte (nicht wirklich "Wasserfall", denn "Wasserfall"
als solches hat nie existiert - siehe Buch "Untersuchung...", Seite 17
-), die sich nach dem PMBOK richten oder halt nach anderen ähnlichen
klassischen Vorgehensweisen, trauen dem Projekt Manager
auch nicht wirklich viel, auf jeden Fall keine Denkarbeit, nur das
Produzieren von maximalen Dokumentation (vielleicht um ihn die Chance
zu gewähren, wenn das Projekt wieder mal aus den Fugen läuft,
belegen zu können, dass er alles nach dem PMBOK gemacht hat).
Die "klassischen" definieren die Entwicklung eines Projektes als durch
Dokumentation getrieben. Die Dokumentation ist die treibende Kraft.
Agil
Bei den "agilen" Projekten wird eine relativ große Anzahl an
sogenannten "agilen" Praktiken angeboten, diese Praktiken
können (und müssen) so kombiniert werden, dass (mehr oder weniger)
erwartete Ergebnisse aus den durchgeführten Arbeiten resultieren. Aus
diese Vorgehensweise ist ersichtlich, warum die "Agilen" nie genau
voraussagen wollen (oder können) was sie am Ende liefern werden.
Dieses Fummeln an "agilen" Praktiken kann funktionieren und Ergebnisse
liefern, muss aber nicht.
Die treibende Kraft ist der Vertrauen, der "Glaube" an die Methode.
Daher nimmt nicht Wunder wenn man erlebt mit welchem Dogmatismus die
"Agilen" eingesetzt werden bzw mit welcher Verbissenheit bei der Verteidigung der
(zweifelhaften) Methoden argumentiert wird.
Beide Methoden (oder Vorgehensweise) haben eine Gemeinsamkeit:
Denkarbeit ist nicht ein Teil der Methode: Es wird keinerlei
Denkleistung von dem Projekt Manager verlangt um die Methode an das Projekt
anzupassen.
Es sieht fast so aus, als würden die Methoden sich für
so vollkommen halten, dass man sie gar nicht mehr zu ändern braucht.
Eine brauchbare Entwicklungsmethode
Eine Entwicklungsmethode muss anpassungsfähig sein, flexibel, agil
halt. Mit anderen Wörter es muss möglich sein, durchs Überlegen
herauszufinden wo man ansetzen muss, um durch eine Arbeit, mit einem
Team, für ein Produkt, mit einer Organisation, für ein Projekt die Ergebnisse
zu produzieren, die man erhalten möchte.
"Scrum" zum Beispiel kann mit "Störgrößen" nicht
umgehen. Im Gegenteil, Änderungen werden auch im fortgeschrittenen
Projekt "willkommen" sein (agile Prinzipien).
Es gibt "Rituale" die man machen kann oder auch nicht, wenn sie nicht
funktionieren; doch eine "Anpassung" ist nicht vorgesehen.
Natürlich behaupten daraufhin die "Agilisten" dass, wenn ein Daily pro Tag zu
viel ist, so kann man halt ein Daily jeden 2. Tag abhalten.
Wieso und Warum? Gibt es eine Erklärung? Mitnichten.
Das ist ein Rumstochern im Dunkeln.
Das liegt auch darin begründet, dass für einen Daily auch keine
wirkliche Begründung gibt.
Wenn die Begründung "Kommunikation" wäre, müsste eine vernünftige, brauchbare
Methode auch andere Kanäle in Betracht ziehen: Chat, Email oder
vielleicht mal zusammen essen gehen.
Das ist bei "Agilen" halt nicht der Fall.
"Zen" Projekt Management
Also dann: Warum "meditatives" Projekt Management?
Und noch eine Frage: Warum scheitern Projekte?
(Siehe SW-Untersuchungs-Buch, Seite 55)
Projekte scheitern nicht an zu wenig geleisteter Arbeit,
sondern wird oft ein Vielfach an Arbeit geleistet, bevor das Projekt
beendet ist.
Projekte scheitern nicht an schlechte, dumme, gleichgültige Projektarbeiter,
sondern daran, dass die Kontrolle über die Arbeiten und das Ergebnis
flöten geht.
Projekte scheitern nicht an dem Unwillen der Mitarbeiter Mehrarbeit zu leisten,
sondern an Risiken, die man nicht richtig berücksichtigt hat.
Daraus folgt, dass nicht mehr Arbeit oder bessere Mitarbeiter
vonnöten sind, sondern mehr Planung, mehr Denkarbeit.
Kein Projekt scheitert an einer Entwicklungsmethode (klassisch oder agil),
sondern an der unrichtigen Anwendung einer Methode.
In Acht muss man sich dann nehmen, wenn eine Entwicklungsmethode keine
Maßnahmen vorsieht, die helfen sollen, einem Projekt, das aus den
Fugen zu gleiten droht, wieder aufzufangen.
Die Arbeiten an einem Projekt müssen ruhig und konzentriert erfolgen.
Nur so kann man die vielen Variablen und Risiken richtig einschätzen
und angemessen reagieren.
Und das nenne ich "Zen" Projekt Management.
Zitate
"Der Aufwand, ein Problem zu korrigieren, wird umso
größer, je später man es im Entwicklungsprozess
findet." Deswegen möchte man die Anforderungen (und das Design)
so schnell wie möglich fertig vorliegen haben und
Korrekturaufwände in späteren Phasen vermeiden (Buch
"Adrenalin Junkies und Formular Zombies", Tom Demarco, Kap. 66).
Die meisten Maßnahmen zur Erhöhung von Druck bewirken nicht die
geringste sinnvolle Verhaltensänderung. "Menschen unter Zeitdruck
denken nicht schneller." (Buch "Spielraume - Projektmanagement
jenseits von Burn-out, Stress und Effizienzwahn", Tom Demarco).
|