Projektkoordination "ruynk"

R. C. N.-Kuhlmann (IAPM Certified Project Manager) - Entwickler von FlePA

FlePA: Flexibles Planen und Arbeiten




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

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



Design und Realisierung: ruynk 2017

Copyright: ruynk.

Zuletzt Bearbeitet: R. C. N.- Kuhlmann, September 2017