Inhalt : High-Speed Projektmanagement

Unsachliche Kommentare entfernt. Bitte konstruktive Beiträge.

Das beschriebene Ziel ist unumstritten. Schon viele haben versucht es zu erreichen, indem sie mit dem angeblich heiligen Gral vorangeschritten sind. Ob er nun Klassisch, Agil, CCPM oder sonst wie heißt. Alle hatten eins gemeinsam, sie waren alle zu dogmatisch. Ich bin überzeugt, dass der Schlüssel in der richtigen Kombination von einzelnen Elementen dieser Methoden liegt. Der Schlüssel passt dann, wenn die Organisation, die Menschen und das Umfeld genau analysiert sind und man verstanden hat, was wie am besten funktionieren kann. Das ist schwieriger und aufwändiger, als etwas allgemeines  über zu stülpen.

Ich persönlich glaube nicht, dass der Lösungsansatz funktioniert. So wie ich es verstehe, setzt auch dieser wieder auf dem Versuch auf, singulär erfolgreiche Methoden zu generalisieren. Das kann aus meiner Sicht allein deswegen nicht funktionieren, weil jedes Projekt andere Menschen zusammenbringt und diese sich im Team immer anders / immer neu organisieren. Wenn wir uns soweit auf den Abstraktionsebenen nach oben bewegen, dass solche Effekte egal werden, helfen die Erkenntnisse im konkreten Projekt auch nicht mehr weiter.

Zudem habe ich schon meine Zweifel an der Eingangsthese (auch wenn sie provozieren soll): Ich bin fest überzeugt, dass es unter den Beteiligten immer jemanden gibt, der meint, es ginge noch schneller oder man könne noch mehr parallel machen. Das hängt einfach damit zusammen, dass unser Empfinden, was "noch geht" einfach zu unterschiedlich ist und mit der jeweiligen persönlichen Leistungskurve zusammenhängt. Ich behaupte also, das Ziel ist faktisch nicht zu erreichen.

Aber mal abgesehen davon: Ist es wirklich sinnvoll, alle Projekte immer noch schneller zu machen? Für mich haben Projekte (im weitesten Sinn) die Aufgabe, ein System von einem Zustand in einen anderen zu bewegen. Die maximal mögliche Änderungsgeschwindigkeit hängt aus meinem Gefühl aber vom Ausgangssystem ab und nicht vom Projekt. Was nützt es also, das Projekt zu beschleunigen, wenn das Ausgangssystem dafür zu träge ist?

Die eigentliche Frage ist, was ein Projekt wirklich "schneller" macht . Da wir es in erster Linie mit Menschen zu tun haben, würde ich mal sagen, wir sollten uns mehr auf diesen Faktor konzentrieren, dann kommt der Rest von selbst. Das ist ein entscheidender Aspekt, warum die agilen Vorgehensweisen tatsächlich mal einen Fortschritt zu allem, was davor versucht wurde, zeigen. Erst wenn ich die beteiligten Personen und ihre Beziehungen zueinander in Einklang gebracht habe, kann ich von "optimal" sprechen. Darin liegt natürlich die größte Herausforderung.

Wäre mal interessant mit Psychologen zu diskutieren, ob es sinnvoll wäre für Projekt Manager psychologisch geschult zu werden. Tukman, etc. sind zwar interessante Modelle, aber das was tatsächlich dahinter steht wäre eigentlich wichtig, um zu verstehen wie man ein Projekt aufstellen sollte, damit es optimal laufen kann.

Ich werde den obigen Artikel gleich ergänzen. In den letzten Monaten sind interessante Sachen passiert. Was mir aber wichtig ist, dass wir in unseren Kommentaren von "Meinungen" wegkommen. Ich würde mir mehr wünschen, dass wir unseren Aussagen sauber begründen. Ungeachtet dessen bin ich bei Rainer - bis auf die Frage der Reihenfolge.

In der Systemtheorie (u.a. die von E.Goldratt beschrieben Theory-of-Constraints) geht man davon aus, dass die es besser ist eine Intervention nach der anderen zu machen (mehr Fokus, besser überprüfbarkeit der Ursache-Wirkungs-Kette) und vor allem dass die Reihenfolge wichtig ist.

Hier das passende Gedankenspiel - zwei Fälle/Reihenfolgen:

Fall1: zuerst wird in die Menschen investiert, man klärt die Bezeihung u.s.w. --> Ergebnis sie sind motiviert --> dieses Team trifft nun auf eine Organisation, die ggf. noch gar nicht damit umgehen kann --> secundäres Ergebnis: das Team ist frustriert und verläßt das Unternehmen

Fall2: man räumt zuerst die Prozesse/Glaubenssätze im Unternehmen auf --> Ergebnis es kommt zu einer deutlichen Verbesserung des Fluss und das Team erhält mehr Kapazität, die genutzt werden kann --> zweiter Schritt man entwickelt das Team und die Mitarbeiter weiter --> sekundäres Ergebnis zusammen mit der zusätzlichen Kapazität kann das Team seine neu gewonnenen Fähigkeiten um so besser nutzern --> noch mehr Erfolg

Ich hab leider den Fall 1 schon mehrfach gesehen. Es gibt nichts frustierendes für Denkarbeiter, wenn sie hochmotiviert auf eine schlechte Organisation treffen. Umgekehrt habe ich es aber auch schon oft erlebt Fall 2 - ein frustriertes Team, dem man endlich gute Prozesse gibt blüht unverzüglich auf. Wenn man von Wasserfall herkommt (ganz schlechte idee das mit dem Wasserfall) und dann auf was etwas besser (aber nicht ansatzweise optimal) wie Scrum/Kanban umstellt wird sofort deutliche Verbesserungen spüren - die haben aber oft weniger was mit der Gruppendynamik sondern mehr mit der WIP-Begrenzung zu tun. Es ist allso alles andere als eindeutig, dass Teamentwicklung in Scrum der Erfolgsfaktor ist - sorry. J. Sutherland ist seit langem auf der Suche nach "hyper produktivität" hat es mit Scrum schon ein paar mal geschafft - aber nicht reproduzierbar. Die agilen Verfechter haben sehr oft ein blinden Fleck in der Wahrnehmung.

Wenn man die ganzen Ideen aber zusammen packt kommt man auf eine (vielleicht) sinnvolle Reihenfolge:

#1 Prozesse im Unternehmen aufräumen --> die Ideen hierzu finden sich u.a. im Critical Chain Projektmanagement ... das ist interessanterweise hauptsächlich WIP Begrenzung (wie bei Scrum) und operative Steuerung der Prioritäten ... damit erzeugt man typischerweise Fluss (noch ein bisschen besser als bei Lean)

es ist aber nicht CCPM alleine. Auch Scrum kann von diesen Ideen profitieren s. Reliable Scrum.

#2 das Team von allem nicht wertschöpfendem entlasten --> systematisch analysieren wie man den Overhear oder administrativer Unsinn vermeidet --> maßnahmen ergreifen --> was sofort zu einer weiteren Steigerung der Produktivität führt. Das hat uns im aktuellen Team zu einer neuen Steuerung "Drum-Buffer-Rope" geführt --> statt ca. 35% Overhead wie bei 2-Wochen-Sprint-Scrum sind wir jetzt bei unter 10% ... die Beschreibung dazu findet sich aktuell auf der reliable-scrum.info ... die Arbeitsorganisation ist so leichtgewichtig und so wenig Bestand, dass wir davon ausgehen, dass wir am theoretischen Optimum arbeiten ...

#3 und jetzt sind wir endlich soweit - jetzt müssen wir nicht mehr über Prozesse reden und nicht mehr über Overhead reduktion. Die Organisation unterstützt das Team optimal. Jetzt ist das Team dabei sich zu überlegen, wie sie jeden einzelnen individuell persönlich weiter entwickeln können. Wir überlegen uns wie wir das Können verbessern. Wir reden also nur noch über die Menschen! Und da bin ich genau bei dir Rainer - aber in der richtigen Reihenfolge.

Die Vorgehensweise in der Reihenfolge stellt sicher, dass an keiner Stelle die Möglichkeit für Frustration besteht, sondern das Team sich von Erfolg zu Erfolg steigert.Der Transformationsprozess verlief erstaunlich schnell und ist sehr nachhaltig.

cu Wolfram

p.s.: auch da bin ich bei dir Rainer - es wäre wichtig, dass die Projektmanager (oder Manager allgemein) verstehen, was sie machen. Aus meiner bescheidenen Sicht kommt man hier um Systemtheorie und systemische Interventionen nicht herum. Hier gibt es viele Autoren, die aber noch nicht in den Streamline eingeflossen sind u.a. Goldratt (Theory of Constraints), Luhmann (Systemtheorie in der Soziologie), Milton Erickson (NLP) oder Gunter Schmidt (hypnosystemeische Interventionen) ... es sind noch viele mehr - aktuell gibt es leider keine konsolidierte Sekundärliteratur

Wäre schön, wenn man vor allem dem mittleren Management zuerst mit einer Optimierung der Organisation kommen könnte, damit Dein Ansatz umsetzbar wäre. Allerdings beobachte ich so etwas nicht. Da sehe ich eher erst dann ein Reagieren, wenn es gar nicht mehr anders geht. In welchen Situationen schaffst Du es, die vorgeschlagene Reihenfolge einzuhalten? 

Hab gerade mal einen Blick auf den Drum-Buffer-Rope-Ansatz von Dir geworfen. Du schreibst, daß die regelmäßigen Meetings in Scrum sowie die Sprint-Taktung auf der einen Seite zu einem unnötigen Overhead führen, auf der anderen Seite bei Ultimate Scrum die Fähigkeiten der Entwickler das einzige Problem seinen.

Grundsätzlich ist nachvollziehbar, daß eine Durchlaufoptimierung ein wichtiges Ziel ist. Ich habe auch schon mal darüber nachgedacht, auf eine Sprint-Taktung zu verzichten. Allerdings sind die Meetings in Scrum Kommunikations-Hot-Spots, die ja gerade dafür sorgen, daß die Entwickler optimal informiert sind bzw. das Ergebnis erreicht wird. Die Sprint-Taktung bringt Laufruhe in das ganze und gibt somit Orientierung für die Entwickler.

Kannst Du Deine Thesen vielleicht noch mal etwas erläutern?

das was du beschreibst ist nach unserem Wissensstand (viele weltweit tätigen CCPM/TOC-Berater) das Kernproblem. Wir sind uns bewusst, dass wir nur wirkliche durchbruchsartige Erfolge erziehlen können, wenn das "mittlere Management" (wir sprechen oft von der Ebenen direkt unter der Geschäftsführung) vollständig den Ansatz verstanden haben. Sprich wir nehmen keine Beratungsaufträge an, bei denen das Management nicht bereit ist diesen Schritt zu tun. Daher konzentrieren wir unsere Bemühungen gerade darauf Wege zu finden, diesen Schritt zu optimieren - aktuell verlieren wir noch zu viele Aufträge genau an der Stelle . Aber es wird seit ein paar Monaten deutlich besser. Wir beobachten, dass immer mehr Firmen auf uns zukommen und auch gewillt sind den Schritt zu gehen

Konkret verlangen wir von den Firmen, die mit uns zusammenarbeiten wollen, dass das mittlere Management (inkl. zumindest zeitweise Geschäftsführung) sich Zeit für 2-3 Workshops mit 2-3 Tagen sich Zeit nimmt (das Ganze dann auch noch innerhalb von max. 8 Wochen). Die Besten Firmen brauchen nur 2 Workshops mit 3 Tage (darunter hat es noch keiner geschafft) - manchen brauchen (und wollen) dann aber noch mehr. In diesen Workshops machen wir Spiele, Diskustieren und bauen das Verständnis auf - so lange bis das mittlere Management geschlossen dahinter steht. Das ist ganz schön anstrengend - aber gigantisch wenn man es erreicht hat Dann kann man nämlich endlich aus der klein-klein-lokalen-Optimierungswelt in die ganzheitliche-holistische-Optimierung gehen - und das ist das Ziel 

p.s.: ich hab das ganze gerade in einer mittelständischen AG durchgezogen - jetzt geht es an die Umsetzung - genau nach dem obigen Schema und eben nicht nur in kleine Teams sondern - komplette Umstellung aller Business-Units, angefangen vom Portfolio Management (strategische Priorität, Work-In-Progress Control) über zur Projektsteuerung (Crticial Chain) bis hinunter zu den Teilprojekt-/Teamsteuerungen mit Agile (Reliable/Ultimate Scrum) ..... ich werde berichten

es "verschwindet" ja nicht alles ...

... auf die Stand-Ups und die Retrospektiven haben wir nicht verzichtet. Die Retrospektiven haben wir sogar noch etwas intensiviert (14tägig). Allerdings hat sich deren Charakter und Dauer deutlich verändert:

a) Stand-Ups sind jetzt viel kürzer. Wir haben ja nur noch sehr wenige offen Tasks - die Stand-Ups sind mehr ein "Hallo guten morgen, schön das du da bist ...!". Ultimate Scrum fokussiert in den ersten Woche darauf Impediments deutlich zu machen und diese aufzulösen. Wir haben in den Stand-Ups daher fast nichts mehr was zu diskutieren gibt. Was noch vorkommt sind Sätze wie "Ich bin da gerade über was gestolpert - wer kann mir dabei helfen?". Allerdings ist das auch selten - wir haben parallel ein Chat laufen und diese Fragen werden bevorzugt online in echtzeit ohne Wartelatenzzeiten einfach sofort gelöst. Es geht im Stand-Up fast nur noch drum zu sehen, wer heute da ist und eben auch Wertschätzung zu zeigen - ich sage glaube ich 5-10 mal Danke pro Stand-Up - es wird ja auch laufend was fertig

b) die Retrospektiven verändern sich auch (und werden kürzer). Früher hat man viel über Arbeitsorganisation gesprochen - über den Prozesse - das ist komplett weg. Wir sind ja am Optimum. Danach kam die Phase an dem wir systematisch die "Overheads" eleminiert haben. Wir stimmen auch heute noch die Refactorings hier ab - also was können wir am Code verbessern, so dass das Entwickeln hinterher leichter wird. Und jetzt seit ein/zwei Retrospektiven wechselt der Fokus massiv auf was kann jeder einzelne an sich arbeiten und wie tauschen wir uns aus, so dass wir unser Können verbessern. Parallel arbeite ich jetzt immer mehr auch Führungsthemen ein - also ich bauen den Faszinationslead auf (Vision, Disziplin und Leidenschaft). Aber alles Schritt-für-Schritt.

c) Planning II ist ja in den kontinuierlichen Modus aufgegangen. Hier ist der Vorteil, dass es nicht mehr durch das ganze Team gemacht werden muss sondern eben durch Senior Entwickler. Das spaart Aufwand. Natürlich erklärt dieser dann auch immer wieder was er da gemacht hat - aber nicht zwangsweise in der Gruppe sonder dort wo es am besten passt.

d) Planning I bleibt auch - aber auch hier nicht mehr in der ganzen Gruppe sondern es wird durch den Product Owner und den Architekten vorbereitet. Dann erklären wir es dem Team. Dann wird gegroomed (auf eine ganz schnelle art und weise ohne diese elend langen Poker-Diskussionen). Noch ein bisschen im Team geschätzt, was ggf. dazu kommt. Damit ist das Team abgeholt. Den Rest der Diskussion können wieder vom Product Owner und/oder Architekt oder Seniors durchgeführt werden.

e) die Reviews werden adhoc gemacht wenn eine Story fertig wird.

... der Gewinn liegt darin a) dass nicht mehr jeder bei jedem Meeting dabei sein muss b) die Sachen genau sofort dann gemacht werden, wenn es gerade sein muss - weniger Verzögerungen, weniger Waste und c) noch viel stärkeren Fokus auf unverzügliche Verbesserung (Kaizen) so dass Hindernisse sofort und ein für alle mal verschwinden. Je früher ein Hindernis verschwindet desto frühe hat man den Gewinn. Der Ganze Optimierungsprozess läuft viel fokussierter und schneller ab.

... wenn man Reliable Scrum macht - kommt das Release in den Fokus. Die Laufruhe stellt sich also über das Release ein und damit braucht man die Schutzfunktion des Sprints nicht mehr. Die Schutzfunktion der Sprints ist IMHO eben ein Anzeichen, dass das Management noch Nachholbedarf im Verständnis von Systemem braucht (s. Antowort auf dein voriges Posting). Das sind die gläsernen Wände und decken, die entstehen, wenn man von unten in kleinen Teams versucht das große Ganze System zu verändern.

cu Wolfram

p.s.: vor ein paar Tagen hat mich Steve Tendon darauf hingewiesen, dass Scrum ja auch eine Historie hat. Z.B. hat Jeff Sutherland 11 Jahre bei der US Air-Forch gedient. Wenn man sich Scrum anschaut sieht man das Flight-Briefing (Stand-Up) und das Debriefing (Review). Kadenzen bestimmen die Arbeit von militärischen Organisationen erheblich - fängt beim Morgenapell an. Auch das Thema Commitment ist im Militär sehr sehr sehr wichtig (die müssen am Anfang einen Eid schwören). Das ist jetzt etwas überspitzt formuliert - aber ich habe den Eindruck, dass Scrum noch gar nicht so "frei" denken kann wie es für heutige Wissensarbeiter besser wäre.

Es gibt eigentlich nur ein einziges Problem beim Projektmanagement:

das Akzeptieren, genauer das Nichtakzeptieren, der Gegebenheiten bei Projekten

Ständig taucht jemand auf, der es besser wissen will, und der es dann garantiert falsch macht, aber sicher weiß wer schuldig wenn es fehlschlägt, außer ihm selbst natürlich. Es ist als würde man ständig versuchen die 100m in 5 Sekunden zu schaffen (gemäß dem Witz, der Schnellste braucht derzeit 9.8 sec, aber ich kenne eine Abkürzung).

Dass Endkunden, die Gegebenheiten nicht kennen, ist nicht verwunderlich, dass aber die "Führungskräfte" von Firmen, die Projekte anbieten, es oft nicht akzeptieren, ist schon peinlich. Es ist leider üblich etwas zu versprechen was sowieso nicht einzuhalten ist.

Leider gehört diese vorgestellte These gleichermaßen in die trotzig kindliche Kategorie "Es darf nicht sein, es darf nicht sein, ..."

Echte Projekte haben immer etwas neues und damit was riskantes. Und damit geht es immer darum zuerst überhaupt einen Lösungsweg zu finden. Also um

EFFEKTIVITÄT

trotzdem versuchen ständig irgendwelche Leute sofort

EFFIZIENT

zu sein. Das ist aber Quatsch. In anderen Zusammenhängen fällt dieser Ansatz unter "PREMATURE OPTIMIZATION". Zunächst muss überhaupt mal EIN Weg bekannt sein um einen ZWEITEN bewerten zu können, ob der nun besser, effizienter, kostengünstiger, wartbarer, schneller, hübscher ... ist.

Der Erfolg von Scrum beruht zu großen Teilen darauf, dass er die Gegebenheiten akzeptiert, die Entscheidungen dort läßt wo die meiste Kompetenz ist, Rollen akzeptiert. Und weil Scrum nicht versucht, die Kosten und Termine eines komplexen Projektes festzulegen.

Nichts ist effizienter als etwas richtig zu machen,
nichts ist unsinniger als Effizienz zu erzwingen.

Ins Extreme getrieben hat es die NASA mit der Verweigerung der Fakten und Gegebenheiten, und das hat schlussendlich die Challengerkatastrophe heraufbeschworen, die 7 Menschen das Leben gekostet hat.

Richard Feynman hat es so ausgedrückt:

"For a successful technology, reality must take precedence over public relations, for nature cannot be fooled."

http://de.wikipedia.org/wiki/Richard_Feynman

Das gilt analog für Projekte

Und nun etwas konkreter zu

Meine These ist: Es muss ein Projektmanagement geben, von dem jeder Beteiligte behaupten kann, dass

• die Projekte mit max. möglicher Geschwindigkeit laufen,

Zunächst müsste man überhaupt festlegen was "max Geschwindigkeit" heißt?

??? an schnellsten fertig (Wall-Time)?

Das erfordert hellseherische Fähigkeiten. Wer sieht sich ernsthaft in der Lage vorauszusehen, welcher Projektmitarbeiter zuerst die zündende Idee haben wird um das Projekthindernis zu überwinden?

??? am wenigsten Aufwand ?

Auch das erfordert hellseherische Fähigkeiten. Wer sieht sich ernsthaft in der Lage vorauszusehen, welcher Projektmitarbeiter den effizientesten Ansatz hat um das Projekt abzuschließen? Wer weiß dass zwei Tage später ein, vielleicht sogar etwas schüchterne Kollege noch einen viel besseren Ansatz einbringen wird, wenn man ihn weitersuchen läßt?

Projektmanagement sollte einfach akzeptieren wie Projekte ablaufen und sich darauf einstellen.

es wurden zwei Fragen gestellt ...

a) Def. max. Geschwindigkeit? das wurde bewusst genau so formuliert - "jeder Beteiligt behauptet, dass es die max. mögliche Geschwindigkeit WAR" ... es gibt keine objektive Geschwindigkeitsmessung in Projekten. Wenn man die Beteiligten frägt, kann aber interessanterweise jeder retrospektiv beurteilen, ob er er sich vorstellen kann, dass man noch schneller hätte sein können ... die meisten werden dann mit ja antworten und ideen entwickeln, was man besser machen kann ...... max Geschwindigkeit ist dann erreicht, wenn hier nichts mehr zu holen ist

b) am wenigsten Aufwand ... genau gleich definiert

... bzgl. akzeptieren von Gegebenheiten - ich erkläre das immer so: "Es gibt zwei möglichkeiten Projekte langsamer zu machen #1 ich plane einen Termin, der später liegt als das Optimum und #2 ich planen (akzeptiere) einen Termin der früher ist als das Optimum". Ich werde es nie verstehen, wie man Gegebenheiten ignorieren kann! Da sind wir uns also absolut einig

Das macht es aber um so wichtiger sich mit dem Optimum auseinander zu setzen - und umd das geht es hier. Je besser wir die "Mechanik" oder "Zusammenhänge" verstehen, desto besser kommen wir an das Optimum heran. Und es gibt IMHO nichts motivierenderes für ein Team als richtig Leistungsfähig zu sein.

cu Wolfram

p.s.: nur so nebenbei - der Erfolg von Scrum basiert objektiv eher auf dem Mißerfolg des klassichen Projektmanagements. Wenn man Scrum-Projekte mit Critical-Chain oder Kanban vergleicht sieht Scrum gar nicht mehr so gut aus. Der Erfolg von Scrum kommt eher auch daher, dass man es gegen die Organisation in einem abgeschlossenen Team implementieren kann. Das ist oft leichter als holistische Ansätze wie Critical Chain - ist aber letzt endlich eine lokale Optimierung (sehr wirksam) aber nur ein Teilerfolg. Der systemisch ist der Hauptmechanismus von Scrum die rigide Work-In-Progress Reduziererung. Scrum ist sehr emfindlich, wenn etwas daran geändert wird und und und ...

... noch was zum nachdenken:

http://boeffi.net/scrum/warum-scheitern-immer-mehr-scrum-projekte/

ich würde allerdings die Frage und Antwort erweitern. Warum wird Scrum immer seltner richtig angewendet? Kann es sein, dass Scrum auch ein paar Probleme hat? Wenn ja - dann sollte man sich auf die Suche machen und überlegen, was man besser machen kann - und genau darum geht es. Anregungen was besser zu machen ist - jederzeit und gerne

Ich hab mal gelernt: Min./Max Prinzip geht nicht. D.h. maximale Geschwindigkeit bei minimalen Kosten = no go

Maximale Geschwindigkeit bei gegebenen Kosten und minimale Kosten bei gegebener Geschwindigkeit sind erreichbar. Letzeres ist in der Regel das Ziel aller Projekte und schon schwierig genug zu erreichen. 

Lässt man aus obigen Text mal alle Werbeaussagen und falschen Pauschalisierungen raus (ich finde das sollten wir tun), dann ergibt sich die Frage, wie man das PM besser machen kann indem man Methoden (auch klassische und agile) kombiniert. Das ist ein interessanter Ansatz, an dem man festhalten sollte. Oder sehe ich das falsch?

__

Ich habe Elemente aus Scrum mit klassischen PM Methoden kombiniert und damit sehr gute Erfahrungen gemacht.

Bei Scrum habe ich folgende Probleme: Sprints machen in meinem Umfeld keinen Sinn und sind meiner Meinung nach nur eine Sache der Softwareentwicklung, Scrum bietet zudem relativ wenig Gesamtüberblick. Den zusätzlichen Overhead kann ich auf keinen Fall bestätigen. Ich finde SCRUM sehr agil und unbürokratisch. 

Klassisches PM ist die pure Überschätzung des Projektleiters und ein reines hinterherrennen hinter einem Projektplan der vom ersten Öffnen von MS Project an nie wirklich gestimmt hat. Aber es bietet Übersicht, Meilensteine und Kennzahlen, die in Scrum oft nicht herstellbar sind. 

Was kann das eine vom anderen lernen? Das interessiert mich..

Anti-These:

"Das klassische Projektmanagement braucht keine Weiterentwicklung, es braucht richtige Anwendung. Klassisches PM in "chaotischen" Organisationen richtig angewendet, kann sich nicht entfalten. Klassisches PM verhindert keine Managementfehler und biegt auch keine "krummen" Organisationen gerade, kann aber dazu beitragen das "Geradebiegen" kontrolliert ablaufen zu lassen (Vorausgesetzt man hat ein Ziel für ein solche  Organsiationsprojekt).

Es gibt Organisationen in welchen

• die Projekte mit "max. möglicher" Geschwindigkeit (=Schneckentempo) laufen, da die Organsisation keine andere Geschwindigkeit zuläßt

• nur ein min. Bestand von Projekten im System sich gerade befindet, aber die Priorisierung der einzelnen Projekte immer wieder geändert wird so, dass für die Organisation insgesamt keine vernünftige Planung möglich ist

• das Ganze bei min. Kosten/Aufwand, denn mehr Geld steht einfach nicht zur Verfügung.

• trotzdem ohne Druck - nur Pull = Flow, gearbeitet wird

• und trotzdem ist das alles menschenwürdig, aber es hat einfach keiner Bock in einer chaotischen Firma zu arbeiten."

Was will ich damit sagen:

Wenn man "Klassich" synonym verwendet als z. B.

• der Projektleiter plant und gibt vor was gemacht wird
• Das Management redet rein wie was gemacht wird
• zuerst Konzepte, dann Entwicklen, dann testen usw.
  dann ist das für mich zunächst Fehler in der Kommunikation, Teambildung etc und letztlich in der Führung des Projektes gepaart mit handwerklichen Fehlern.

SCRUM & Co. sind für mich Methoden um Spezialistenprodukte (Begriff nach PRINCE2 zur Abgrenzung der Produkte im PM) zu erstellen. Deswegen ist für mich die Kombination PM(auch klassisch) + Agile kein Widerspruch.

Bei allen anderen, derzeit in der Presse kommentierten Projekten, reden wir nicht von PM, das ist Politik...

a) Def. max. Geschwindigkeit? das wurde bewusst genau so formuliert - "jeder Beteiligt behauptet, dass es die max. mögliche Geschwindigkeit WAR" ... es gibt keine objektive Geschwindigkeitsmessung in Projekten. Wenn man die Beteiligten frägt, kann aber interessanterweise jeder retrospektiv beurteilen, ob er er sich vorstellen kann, dass man noch schneller hätte sein können ... die meisten werden dann mit ja antworten und ideen entwickeln, was man besser machen kann ...... max Geschwindigkeit ist dann erreicht, wenn hier nichts mehr zu holen ist

Als jemand der wirklich in Projekten arbeitet und gearbeitet hat, habe ich Null Probleme diesen scheinbaren Widerspruch aufzulösen.

(Den unwahrscheinlichen Fall, dass jemand ein Projekt bewußt torpertiert, lasse ich aussen vor.)

Im Laufe eines Projektes kommen immer wieder neue Ideen und Ansätze hoch. Wären diese früher erkannt wurden, wäre das Projekt schneller, effizienter gewesen. Hilft nur nichts, die Umwege sind notwendig gewesen um diese Idee und Ansätze zu erhalten.

Druck ist ein Kreativitätskiller. Wer sein Projektteam unter Druck hält, verhindert bessere Lösungen, verhindert Lerneffekte und damit Produktivitätsgewinne.

Der Versuch mehr aus einem Team heraus zu pressen, scheitert. Das einzige was wirklich Vorteile bringen wird, ist dem Team möglichst optimale Bedingungen zu verschaffen und ihm die Lust zu geben, diese auch auszunutzen.

Mal abgesehen, dass das naturgemäß auch eine vage Aussage ist, diese Möglichkeit wird regelmäßig durch dominanz-getriebenes Management (selten ist das Management Teil des Teams) und Neid der Restorganisation blockiert.

b) am wenigsten Aufwand ... genau gleich definiert

... bzgl. akzeptieren von Gegebenheiten - ich erkläre das immer so: "Es gibt zwei möglichkeiten Projekte langsamer zu machen #1 ich plane einen Termin, der später liegt als das Optimum und #2 ich planen (akzeptiere) einen Termin der früher ist als das Optimum". Ich werde es nie verstehen, wie man Gegebenheiten ignorieren kann! Da sind wir uns also absolut einig

Du hast, glaube ich, noch nie ernsthaft an einem Softwareprojekt mitgewirkt, mag sein das Projekte in anderen Bereichen anders laufen. Im Buch Bärentango wird implizit dargelegt, dass die Schätzungen für eine Sache die Formel

  Bedarf = tBase * (1..3)

gilt. Es ist eine Illusion immer die 1 (= Optimum) zu treffen, und das liegt überhaupt nicht an der Planung sondern das ist die Realität.

Wenn irgendjemand einen Termin, eigentlich Zeitkontingent, für eine Sache geplant hat, dann können folgende Fälle auftreten.

• das Kontingent ist völlig ausreichend. Dann wird ein gut behandelter Entwickler auch früher fertig melden. In einer Druck & Peitsche-Organisation wird er die verbleibende Zeit nutzen um anderes zu tun.
• das Kontingent ist knapp bzw. nicht ausreichend, dann wird der Entwickler abwägen zwischen Funktion, Tiefe des Problemverständnisses, Test, Qualität, Dokumentation, Lesbarkeit usw.
• jederzeit können Probleme auftreten, erkannt werden, die die bisherige Plannung scheitern lassen. Daher wird ein erfahrener Entwickler schon bei ausreichendem Kontingent anfangen Kompromisse zu machen, außer die Organisation oder Methode kann diesen Fall kompensieren.
• Tatsächlich kann ein größeres veranschlagtes Zeitkontingent paradoxerweise dafür sorgen, dass das Projekt früher fertig wird.

Das klassische Management sähe es oft gerne, diese Abwägungen selbst zu steuern. Das funktioniert aber nicht, da keine einfachen Regeln formulierbar sind. Was hilft, ist dem Entwickler mehr als ein Guckloch von dem Problembereich zu vermitteln und ihm die Entscheidungen zu überlassen. Damit hat klassisches Management aber Probleme

• keine Macht mehr durch Informationsvorsprung
• billige Mitarbeiter sind ungeeignet
• Mitarbeiter möchten gehört und verstanden werden
• Management muss sich um die Teammitarbeiter bemühen
• keine Macht und Politikspiele, reine Ehrlichkeit zählt
• es müsste im besten Sinne führen, nicht kommandieren
• die dämliche Methode einfach alles 10% kürzen funktioniert überhaupt nicht

Das macht es aber um so wichtiger sich mit dem Optimum auseinander zu setzen - und umd das geht es hier. Je besser wir die "Mechanik" oder "Zusammenhänge" verstehen, desto besser kommen wir an das Optimum heran. 

Aber sicher nicht mit Vorgaben/Planung sondern nur mit dem Bereitstellen optimaler Bedingungen und echter Führung.

Und es gibt IMHO nichts motivierenderes für ein Team als richtig Leistungsfähig zu sein.

Das ist richtig, nur wenn sich ein Team ausgebeutet, nicht gehört/ernst genommen (Personaler: schön dass wir darüber geredet haben) oder manipuliert (verarscht) fühlt, kehrt sich das schnell ins Gegenteil um.

Druck ist eben mittlerweile bekanntermaßen eine schlechte Idee. Die Motivationsforschung zeigt deutlich, dass die Selbstbestimmtheit ein großer Erfolgsfaktor ist ... s. z.B.

zu deinem Kommentar "Du hast, glaube ich, noch nie ernsthaft an einem Softwareprojekt mitgewirkt" - sowas würde ich immer vermeiden - denn man weiß nie wirklich was der andere gemacht hat oder nicht. Ich hab ca. 530 Projekt (meist aber nicht nur Software) verantwortet - viele selbst gemanaged - viele davon von meinen Leuten. Nur so nebenbei - ich schätze den Bärentago (sehr gutes Buch) und ich kenne Tom De Marco sogar persönlich 

aber jetzt zum Inhalt:

Die Mechanismen die du beschreibst sind unzweifelhaft richtig. Man spricht oft von den fünf Gesetzten der Schätzungen

• Schätzungen sind immer falsch
• je genauer ich gezwungen bin zu schätzen desto unwahrscheinlicher dass es richtig ist
• Parkinsons Law: Zeit/Arbeit nimmt immer den Raum ein, den man ihr gibt
• Studentensyndrom: Wenn man weiß man hat Zeit dann macht man zuersts noch andere Sachen
• Murphy: es geht immer was schief

Verfrühungen gibt es daher (sehr sehr sehr selten) - was wir immer sehen sind Verspätungen.

Je größer der Druck in einer Organisation und umso schlechter die Führung desto größer ist der Selbstschutzmechanismus und damit die Puffer in den Arbeitspaketen. Alos wir sind und hoffentlich einig, dass Druck keine Lösung ist, das Optimum zu erreichen.

Damit aber auch das klassische Management seine Bedürfnisse erfüllt bekommt. Sind aus der der Systemtechnik vor ca. 20 Jahren Ideen entstanden, wie diesen Konflikt auflösen kann (s. Critical Chain von E.Goldratt). Er war nicht der Einzige, die Ideen gibt es unter ein paar Namen.

Kurz gesagt wird hier strategisch der Work-In-Progress am Engpass so eingestellt, dass (retrospektiv) die Termine der Projekte mit hoher Wahrscheinlichkeit eingehalten werden. Das ist die größte Herausforderung für die Top- und Mittelmanager. Das ist aber eine wichtige Vorraussetzung.

Im zweiten Teil werden die Zeit-Puffer aus den Arbeitspaketen an das Projektende (oder vor den Integrationspunkt) verschoben. Der kritische Pfad wird dadurch kürzer - die Störungen/Streuungen werden aber hinten abgepuffert. Das Projekt und die Ressourcen werden über die Projektampel gesteuert. Das roteste Projekte bekommt alle Aufmerksamkeit und so viele Ressourcen wie sinnvoll möglich. Die Farbe richtet sich nach Fortschritt zu Pufferverbrauch. Wenn Fortschritt größer Pufferverbrauch dann grün - sonst rot.

Mit diesen zwei Mechanismen können die ganzen negativen Effekte, die wir immer wieder sehen vermieden werden.

Die Konzentration richtet sich dann auf das Umfeld, die Entwicklung der Mitarbeiter und Führung u.a. ... aber erst dann wenn die Arbeitsorganisation geklärt und "optimal" ist.

a) man kann die Geschwindigkeit tatsächlich bei minimalen Kosten erreichen - warum nicht? Das geht aber nur bei einer "strukturellen Verbesserung". Aus der Systemtheorie kennt man z.B. den Satz, dass jedes produzierende System einen Engpass aufweisen muss, der die Leistungsfähigkeit bestimmt.

Wenn man am Nichtengpass optimiert passiert im besten fall nichts. Dann kann man Geschwindigkeit/Leistungsfähigkeit nur mit zusätzlichen Kosten erreichen.

Wenn man ausschließlich am Engpass Optimierungen durchführt kommt es zu deutlichen Verbesserungen des Durchsatz/Geschwindigkeit bei Reduzierung der Kosten. Man nutzt hier den Hebeleffekt, dass eine Verbesserung im Engpass in den Nichtengpassteams zu Verbesserungen der Auslastung führt - globale Optimierung.

b) Kombination von klassisch und Scrum ... das ist auch meiner Erfahrung nach pefekt! Ich kann aus dem Stehgreif 5 Projekte benennen in denen das super funktioniert hat. Ich mache gerne Teilprojekte in Scrum/Kabnan. Aber das Gesamtprojekt in Critical Chain

zwei Stoßrichtungen --> reliable-scrum.de macht Scrum kompatibel zu Projekten und Critical Chain agilisiert das Projektmanagement ... zusammen macht es richtig Spass

zur Antithese: "Das klassische Projektmanagement braucht keine Weiterentwicklung"

was ich oft sehe ist "Wir müssen jetzt alles anderst machen - wir brauchen agile Unternehmen und kein Projektmanagment mehr!". Das ist natürlich nonsens - das "klassische" (wie auch immer definierte) Projektmanagement hat unheimlich viel wichtige Ideen gebracht. Ich setzte mich auch massiv für die Integration von Agil (Produktionssteuerungen) und Projektmanagement ein

ABER offensichtlich scheitern immer noch viele Projekte (aus welchem Grund auch immer). Daher sehe ich folgende Nachholbedarfe im "klasssichen" Projektmanagement:

• ein Projekt ist nie alleine - es ist immer in ein Portfolio oder Unternehmen eingebunden --> ales fängt bei der eindeutigen/stabilen Priorität an, geht über die Work-In-Progress-Kontrolle ... Projektmanagement kann sich nicht vor der Unternehmensführung verstecken - sondern ist integraler Bestandteil der Organisation
• Schätzungen sind immer falsch und fehlerbehaftet. Das wird in vielen Projekten noch falsch gemacht - es gibt hier Ansätze - der am weitest gehende ist Critical Chain (ruhig mal anschauen und p.s. Critical Chain bezieht die ganze Organisation ein)
• die Rückkopplungsschleifen werden vernachlässigt und sind nicht richtig geschlossen. Woran erkennt die Geschäftsführung, dass es zu viel WIP ist. Woran erkennt der Projektleiter/Teamleiter dass das Projekt wirklich in Schieflage ist. Woran erkennen alle beteiligte, worauf sie sich konzentrieren fokussieren müssen um alle Projekte pünktlich und in guter Qualität und zu den versprochenen Gesamtkosten des Portfolio zu liefern

Ich sehe schon Bedarf an der Weiterentwicklung des Projektmanagment - wobei ich/wir klar die Gesamtorganisation im Blick haben

Wolfram Müller

p.s.: ich schreib hier nicht weil ich Werbung machen will ... ja ich berate Unternehmen - sogar sehr erfolgreich. Dabei sehe ich immer wieder wie die Menschen das Leuchten in die Augen zurück bekommen, wenn die Organisation sich verbessert ... dabei werden die Projekte so nebenbei immer schneller - daher High Speed Projektmanagement

Ja, alles richtig, sehe ich genauso, da sind wir gar nicht auseinader.

Ich würde nur gerne trennen wollen zw. "Werkzeug/Methode" und "Anwendung" der solchen. Was kann ein Hammer dafür, dass man damit Versucht eine Mutter auf eine Schraube zu drehen, oder was kann der 5kilo Vorschlaghammer dafür, das man damit ein Stiftnagel ins Parket schlagen möchte? Deswegen die "Anti-These".

Meine Erfahrung ist, dass meistens die "PM-Methode xy" für "schuldig" erklärt wird, selten das Management.

Projektorientierte Unternehmen müssen sich Gedanken machen, wie sie Projektmanagement anwenden und ihre Organisation danach ausrichten (und nicht umgekehrt).

Was Schätzungen angeht haben wir aktuell auch so einen Fall: eine DIN A4 Seite groben Text für ein komplexes System......"schätzen Sie mal".....ein Klassiker.

Klar kann und muss man Werkzeuge/Methoden verbessern, das ist auch gut so. Wir müssen nur aufpassen, dass wir unter "High-Speed-PM" nicht als "Plätzchenbacken bei 400 Grad" verstehen, weils "dann ja schneller geht, als bei 200 Grad". sondern "Gute Vorbereitung, Ofen vorheizen, dann backen).

In diesem (weihnachtlichen) Sinne....

zu deinem Kommentar "Du hast, glaube ich, noch nie ernsthaft an einem Softwareprojekt mitgewirkt" - sowas würde ich immer vermeiden - denn man weiß nie wirklich was der andere gemacht hat oder nicht. Ich hab ca. 530 Projekt (meist aber nicht nur Software) verantwortet - viele selbst gemanaged - viele davon von meinen Leuten.

Deswegen sagte ich "ich glaube", Ich werde auch weiterhin zu unvollständigen Daten eine Meinung haben, die ich bei verbesserter Datenlage anpasse. Ich unterlasse es Teammitglieder auf diese oder andere Weise zum Schweigen zu bringen. Kontroversen bringen, richtig kanalisiert, ein Projekt voran. In Projekten sollte die Energie eingebracht werden um die Aufgabe zu lösen, nicht um Hierarchiekämpfe auszufechten.

Wer allerdings 530 Projekte "gemacht" hat, hat sie anders "gemacht" als ich

Nur mal ein kleines Spiel mit den Daten:

Laut Xing bist Du 23 Jahre berufstätig, Bei 10 Monaten pro Jahr, komme ich auf 2.4 Projekte im Monat, also ca 8.5 Tage pro Projekt.

Das deutet darauf hin, dass Du vorwiegend mit den Auftraggebern eines Projektes zu tun hattest (Management, Kunden). Solche Leute träumen davon, ein Projekt wie einen Produkt, sagen wir wie ein Auto, einzukaufen. Anschauen, Probefahren, Herumfeilschen, Zahlen, Mitnehmen,

Echte Projekte können naturgemäß keine definierten=korrekte Kosten und Zeitpläne haben. Das einzige was machbar ist, ist die Energie voll auf die echten Projektziele zu legen.(Zeit und Kosten können keine Projektziele sein). In dieser Hinsicht war Scrum ein deutlicher Schritt nach vorne, der aber bei den meisten Endkunden noch nicht angekommen ist.

aber jetzt zum Inhalt:

Die Mechanismen die du beschreibst sind unzweifelhaft richtig. Man spricht oft von den fünf Gesetzten der Schätzungen

• Schätzungen sind immer falsch
• je genauer ich gezwungen bin zu schätzen desto unwahrscheinlicher dass es richtig ist
• Parkinsons Law: Zeit/Arbeit nimmt immer den Raum ein, den man ihr gibt
• Studentensyndrom: Wenn man weiß man hat Zeit dann macht man zuersts noch andere Sachen
• Murphy: es geht immer was schief

Diesen Thesen stimme ich grundsätzlich zu. Nur würde ich vieles als Symptome schlechter Führung und Umgebung sehen.

Verfrühungen gibt es daher (sehr sehr sehr selten) - was wir immer sehen sind Verspätungen.

Siehe erste Punkte meiner Liste . Das ist ein Symptom, dass was nicht in Ordnung ist. Wenn nicht regelmäßig 30% aller Projekte/Arbeitspaketen früher fertig meldet werden, dann waren die Schätzungen zu aggressiv. Dann werden die Teamkollegen die Planung auch nicht mehr ernst nehmen weil sie sie regelmäßig als reines Wunschdenken der Projektleitung/Kunden wahrnehmen.

Je größer der Druck in einer Organisation und umso schlechter die Führung desto größer ist der Selbstschutzmechanismus und damit die Puffer in den Arbeitspaketen. Alos wir sind und hoffentlich einig, dass Druck keine Lösung ist, das Optimum zu erreichen.

Ich gebe Dir hier recht, nur ist "Puffer" ein Versuch mit dem Unsinn Terminplanung umzugehen. Der Unsinn hört ja nicht auf indem man versucht Puffer zu verhindern.

  Termine sind bestenfalls Zeitpunkte wo sich alle über den Stand des Projektes klar werden. ggf kann der Auftraggeber dann sagen, das zugrundeliegende Problem sei ausreichend gelöst oder Punkte seien noch zu verbessern (klingt ja schon wieder wie Scrum)

Im Übrigen sind Fertigstellungstermine an sich schon Druck

Damit aber auch das klassische Management seine Bedürfnisse erfüllt bekommt. Sind aus der der Systemtechnik vor ca. 20 Jahren Ideen entstanden, wie diesen Konflikt auflösen kann (s. Critical Chain von E.Goldratt). Er war nicht der Einzige, die Ideen gibt es unter ein paar Namen.

Kurz gesagt wird hier strategisch der Work-In-Progress am Engpass so eingestellt, dass (retrospektiv) die Termine der Projekte mit hoher Wahrscheinlichkeit eingehalten werden. Das ist die größte Herausforderung für die Top- und Mittelmanager. Das ist aber eine wichtige Vorraussetzung.

Im zweiten Teil werden die Zeit-Puffer aus den Arbeitspaketen an das Projektende (oder vor den Integrationspunkt) verschoben. Der kritische Pfad wird dadurch kürzer - die Störungen/Streuungen werden aber hinten abgepuffert. Das Projekt und die Ressourcen werden über die Projektampel gesteuert. Das roteste Projekte bekommt alle Aufmerksamkeit und so viele Ressourcen wie sinnvoll möglich. Die Farbe richtet sich nach Fortschritt zu Pufferverbrauch. Wenn Fortschritt größer Pufferverbrauch dann grün - sonst rot.

Mit diesen zwei Mechanismen können die ganzen negativen Effekte, die wir immer wieder sehen vermieden werden.

Die Konzentration richtet sich dann auf das Umfeld, die Entwicklung der Mitarbeiter und Führung u.a. ... aber erst dann wenn die Arbeitsorganisation geklärt und "optimal" ist.

Es ist ja irgendwie lustig, dass Critical Chain letztlich für das gesamte Projekt das macht was der einzelne Entwickler für seine Arbeitspakete machen würde.

Meine 4 Punkte passen sehr gut zu Critical Chain.

Critical Chain entschärft ein bisschen (siehe auch meine Anmeldung dritter Punkt, letzter Satz) und die Erfolge zeigen, dass richtige Elemente vorhanden sind, spricht aber nicht wirklich die Ursache aus. Und die eigentliche Ursache sind Fertigstellungstermine, ohne sie könnte der Puffer entfallen und man könnte das Ganze auch Scrum nennen.

------

Ein Projekt ist eigentlich nichts anderes als wenn man mit einem Symptom zum Arzt geht.

Diagnose, Behandlung, Überprüfung des Ergebnisse, ggf Iteration.

Wer hat jemals einem Arzt gezwungen zu einem bestimmten Termin Erfolg zu haben?Wer hält das für eine gute Idee?

Wieso versuchen seit Jahrzehnten Kunden und Manager dieses nachweislich gescheiterte Modell beizubehalten?

Das ist doch eher ein Symptom mangelnder Lernfähigkeit!

Es schlägt aber nicht nur auf die Motivation.

Druck verhindert kreative Lösungen und  ist auch ein unbestimmtes Signal Kompromisse einzugehen. Die Qualität des Ergebnisse leidet darunter.

Selbstverständlich können manche Qualitätsaspekte den Businesswert übersteigen und sind damit unwirtschaftlich

In einem komplexen Umfeld wie Softwareentwicklung ist es nahezu unmöglich mit einfachen Worten die sinnvollen Qualitätsstufen vorzugeben.

Da hilft nur ein möglichst breites Verständnis für den Einsatz der Software zu vermitteln.Und wenn die damit erhöhte Selbstbestimmtheit die Motivation steigert, um so besser

a) man kann die Geschwindigkeit tatsächlich bei minimalen Kosten erreichen - warum nicht? Das geht aber nur bei einer "strukturellen Verbesserung". Aus der Systemtheorie kennt man z.B. den Satz, dass jedes produzierende System einen Engpass aufweisen muss, der die Leistungsfähigkeit bestimmt.

Die Leistungsfähigkeit eines Softwareteams ist ganz einfach die der Summe seiner Mitglieder (Ich nenne dies Energie) . Die wirklich zu stellende Frage ist, wie erreicht man dass die Energie weitestgehend ins Projekt fließt. Und da gilt es primär "Fremdabflüße" zu verhindern.

• soziale und wirtschaftliche Stabilität fördern
• Fokussierung
• Entbürokratisierung
• Fairneß (nicht nur fordern sondern auch geben)
• Zielkonfikte vermeiden
• angemessene Doku
  

Davon zu unterscheiden ist, dass der Endkunde eines Projektes umgesetzte Aspekte, auch gleich aufwändige, unterschiedlich bewertet (Thema Businessvalue). Da hilft nur intensive Iteration und Kommunikation, aber auch das ist schon wieder ein Abwägen, denn für die Energie des Hinterfragens hätte man auch auch schon einen Aspekt umsetzen können.

Wenn Du eigentlich das meinst, dann streiten wir nur über die Wortwahl. Dann geht es darum den Businesswert eines Aspektes/des Projektes zu verstehen, und zwar wie üblich besser als der Kunde selbst. Dann geht es nicht darum etwas schneller zu machen, sondern nur das zu machen was zwingend notwendig ist und was honoriert wird, mit dem Risiko minderwertige Qualität abzuliefern (weil der Kunde einen Aspekt nicht oder noch nicht einsieht).

Erstmal ja - ich habe tatsächlich eher mit Auftraggebern, Kunden und Managern zu tun. Ungeachtet dessen habe ich viele Projekte (vor allem große und zeitkritische) selbst gemanaged. Und ich mache seit 10 Jahren agile Softwareentwicklung und agiles Projektmanagement.

Ich kann auch den massiven Widerstand ihrerseits gegen Termine verstehen. Ich kenne auch Situationen, in den der Fokus auf Flow/Ergebnisse/Business Value liegt und der Termin zweitrangig ist. Das sind schöne Situationen - freuen sie sich wenn sie in einer solchen sind.

Die Umkehrung, dass Termingetriebene Projekte gescheitert wären oder ein Auslaufmodell sind kann ich nicht teilen. Hierzu kenne ich und verstehe ich die Beweggründe der Auftraggeber zu gut.

Wenn sie z.B. in einem kompetitiven Markt unterwegs sind und es saisonale Verkaufsfenster gibt (z.B. Weihnachtsgeschäft in der Elektronik) dann macht es ein riesen Unterschied ob sie das Projekt im Oktober/November am Start haben oder im Januar. Ganz klar ein Terminprojekt. Wenn sie dann z.B. noch in USA/CA auf den Markt wollen dann müssen sie 6-8 Wochen Vorlaufzeit vor der Kampagne einpalnen - so lange braucht es hier um die ganze Werbung in Zeitschriften zu drucken und zu verteilen. Wenn sie TV-Werbung bei Superbowl machen wollen müssen sogar ein Jahr zuvor schon buchen. Vermarktung von neuen Produkten ist oft sehr termingetrieben. Bitte nicht Apple als Beispiel nehmen - für den Marktführer gelten manchmal andere Gesetze - wenn aber alle wie Apple wären wäre es wieder termingetrieben.

Oder ich hab lange für die Medizintechnik gearbeitet. Hier ist der Projektplan durch die klinischen Studien geprägt. Hier werden z.T. 100erte Menschen einbezogen. Das wird vorbereitet - wenn dann das Device nicht rechtzeitig vorliegt muss man die Studie abblasen/verschieben - mit einem Vorlauf von z.T. einem Jahr. Das gleiche gilt für Beantragungen für Zulassungen - hier gibt es harte Zeitfenster.

Ich kenne auch jemand aus dem Event-Business. Glauben sie mir wenn Mike Jagger ein Konzert gibt dann ist das ein termingeriebenese Projekt. Wenn die 100.000 Fans am Eingang stehen und die Soundanlage funktioniert nicht ist der Spasfaktor begrenzt. Man nennt das auch gerne One-Shot oder Drop-Dead-Projekte. Ich mag diese Projekte übrigends sehr - die sind sehr motivierend und man muss alle Register des Projektmanagments ziehen (nichts für Anfänger  :-)

Je größer ein Projekt wird (z.B. A380, Flughaven, Fertigungsanlagen, Olympiaden, ...) desto mehr unterschiedliche Teams sind beteiligt und desto mehr Abhängigkeiten und Timings gibt es. Viele davon lassen sich flexibilisieren (mit Puffern an den richtigen Stellen) - aber nicht alle.

Die Argumentation - alle Schätzungen sind falsch - also bitte nicht mehr schätzen. Oder Termine sind Druck also bitte keine Termine mehr sind wohl bekannt. Dort wo sie anwendbar sind - bitte gerne. Ich möchte hier nur die Augen öffnen, dass das bei weitem seltener der Fall sein könnte als man gerne wahrhaben würde. Als gescheitert würde ich daher die "alten" Ansätze kaum bezeichnen. Sie sind herausfordernder und spannender als man landläufig denkt.

Ich bin einfach gesagt "Integrationist" - dort wo es möglich ist ohne Termin zu arbeiten - gerne. Dort wo man agile methoden einsetzen kann (die interessanterweise im Kern Produktionssteuerungen sind) gerne. Dort wo man aber Projekte, Abhängigkeiten und Termine hat muss man auch Projektmanagement machen - und das kann (abseits vom Wasserfall und anderen Blödsinnigkeiten) super genial spannend und motivierend sein . Die Manager, Auftraggeber und Kunden zurfieden zu stellen ist IMHO auch eine recht gute Idee.

Am Schluss geht es draum die optimale Werkzeuge einzusetzen. Wenn das nicht passiert ist es immer die Verantwortung des Management und der Führung (das ist die Definition von Management). Daher muss auch immer hier angesetzt werden. Ich bin ja auch Berater - bevor wir anfangen eine Methode (egal ob agil oder critical chain oder immer häufiger beides) dann gehen wir mit dem Top-Management ca. 6-10 Tage auf Klausur - einfach um sicher zu stellen, dass sie wissen was sie tun.

Mir geht es am Schluss immer um die Menschen - wenn die Organisation stimmt - dann stimmen auch die Ergebnisse und es gibt nichts motivierenderes für die Menschen. Da kommt das Leuchten in die Augen zurück . Fast wie bei Weihnachten - in dem Sinne - frohes Fest

Ein hoch-interessanter Thread: viele Aspekte, denen ich insbesondere aus der Praxis-Sicht zustimmen kann, aber ebenso viele Aspekte, denen ich nur bedingt oder gar nicht zustimmen kann; 

auch wenn ich eigentlich "Ski-Ferien-Computer-Verbot" habe, werde ich mir diesen Beitrag für nächstes Jahr bookmarken;

euch allen wünsche ich ein schönes Weihnachtsfest und einen guten Rutsch in's neue Jahr 2013

CU Boeffi

(der Satzpunkt funktioniert auf meinem iPad sowohl mit der virtuellen Bildschirm- als auch mit der Logitech-Bluetooth-Tastatur nicht - mit mehreren Browsern ausprobiert; liegt dies an Confluence? Deshalb habe ich im obigen Abschnitt das Semikolon verwendet; misteriös)

"Plätzchenbacken bei 400 Grad": eine sehr schöne Metapher - werde ich mir als Ergänzung zu diesem Spruch merken:

“Nine women can’t make a baby in one month” 

http://boeffi.net/blog/brookss-law/

Das heute zu erlebende Scrum-Scheitern liegt ergänzend auch in der Beliebigkeit, in der Scrum heute (miss-) verstanden und gelebt wird, s.a.:

"Wert-los - Scrum wird immer häufiger bis zur Unkenntlichkeit verbogen" http://boeffi.net/blog/wert-los-scrum-wird-immer-haeufiger-bis-zur-unkenntlichkeit-verbogen/  

Dieses Jahr werde ich mein Scrum-Projekt #50 [1] begleiten dürfen. Bisher habe ich nur zwei Projekte erlebt, in denen erstens Scrum sinnvoll war und zweitens richtig - ohne Wenn und Aber - korrekt umgesetzt wurde; beide sehr erfolgreich.

Sicher kann und wird man an Scrum kontext-bezogen Verbesserungsmöglichkeiten finden. Aber ich bin der Meinung, dass die meisten hier viel über Scrum schreiben, einiges mit Scrum erlebt (mit welcher tatsächlichen Scrum-Reife?) und ihr ganz eigenes, sehr subjektives Scrum-Bild haben - aber kaum einer hat hier Scrum ehrlicherweise vollumfänglich im Originalen, geschweige denn in den einzelen Shu Ha Ri-Phasen erlebt und verinnerlicht.

Die meisten Gesprächspartner, mit denen ich mich unterhalten darf, machen bereits in der Shu-Phase sehr schnell die ersten Rückzieher und ersetzen oder verbiegen einzelne Scrum-Bestandteile, da "diese bei uns nicht funktionieren".

Scrum funktioniert nach meiner Erfahrung jedoch nur als Ganzes - Einzelteile höchstens sub-optimal (dann ist es aber nicht mehr Scrum, auch wenn es so entartet leider meistens noch Scrum genannt wird). Das i.d.R. halb-herzige Pseudo-Scrum ("Scrum, but...") wird jedoch in solchen Beiträgen gern als Maßstab für Folge-Argumentation herangezogen.

Auch ich bin der Überzeugung, dass man die einzelnen Scrum-Aspekte in den einzelnen Wirkungsweisen und Ketten erst einmal genauestens unter die Lupe nehmen und verstehen sollte. Aber bitte nicht isoliert, sondern systemisch im Zusammenhang und Spiel mit den jeweiligen anderen. Erst dann kommt man weg von dem "Cargo Cult"-artigen "Do Scrum" und man hat die Chance die Shu Ha Ri-Phasen auch wirklich zu erleben. Für die Wenigen unter uns, die tatsächlich die Ri-Phase ("Be Scrum") erreicht haben, bekommen solche Diskussionen einen wirklichen Wert. Die anderen bleiben beim cherry-picking...

High Speed oder High Performance Scrum darf ich im aktuellen Projekt mit sieben Teams erleben... Davon takten zwei im Tages-Sprint, eines zwei-, der Rest ein-wöchentlich - released wird insgesamt täglich. Und, ganz wichtig, der Speed wird nicht auf Kosten der Teams, sondern systemisch erzielt. Auf einer Zufriedenheits-Skala (min..max=0..10) wird seit diesem Sommer im Durchschnitt immer eine "9+" erreicht - unmittelbar von dem Scrum-Start im Sept. 2011 lag diese Wertung bei "3,27")

Ein frohes Fest (der Berg und das schöne Ski-Wetter ruft)

CU Boeffi

[1] alles Projekte (von inzwischen 200+), die überwiegend direkt als "Software"-Projekte beschrieben werden können; der Rest hatte zumindest größere Software-Sub-Projekt-Teile;

Scrum selbst habe ich in allen möglichen (klass. und agilen) Rollen begleiten dürfen (Fachbereichler, RE, BA, klass. Architekt und Tester, Entwickler, XPler, Cont.Integr., etc, heute als Product Owner, Scrum Master und Agile Coach)

Sorry, kämpfe mit meinem iPad-Handling  (@Admins: Kommentar kann bitte gelöscht werden - bei mir auf dem iPad erscheint der Beitrag, je nach Browser, bis zu vier mal)

MotionComputing -> J3500 nehmen  

> MotionComputing ,,, nehmen

Was meinst Du mit Deiner Empfehlung? Meine iPad-/Confluence-Probleme, oder wurde dieses Tablet via "Original Scrum" entwickelt?

CU Boeffi

Siehe mein Selbstmanagement Setup;

Hallo miteinander,

sehr interessante Diskussion. Für mich ist Projektmanagement ein Werkzeug (eben der schon beschriebene Hammer). Die Frage ist, zu welchem Zweck ich ein Werkzeug einsetze.

Bei Software-Projekte liegt m.E. nach die Hauptproblematik im "Requirement Engineering". Also herauszubekommen, was notwendig ist, um ein bestimmtes Problem zu lösen und von der Lösung ein Modell zu entwickeln. Beim Bauen von Häusern fragt der Architekt auch zunächst nach den Anforderungen und erstellt anschließend eine Reihe von Plänen. Gegenüber dem Hausbau hat Softwareentwicklung den Nachteil, dass das Ergebnis nicht "greifbar" ist und zu einem bestimmten Zweck eingesetzt werden soll. Ein großes Badezimmer mit Eckbadewanne kann man irgendwann sehen und der Zweck ist relativ einfach ... gefällt mir oder gefällt mir nicht. Eine internationale Frachtabrechnung ist da schon wesentlich komplexer und es ist für einen einzelnen Menschen fast nicht mehr möglich, diese zu beurteilen und zu sagen, ob sie "gut" oder "schlecht" ist.

Beim Badezimmer genügen ein paar Skizzen, Materialmuster und ggf. Fotos von Musterbädern, um eine gemeinsame Vorstellung von dem zu errichtenden Raum zwischen zukünftigem Bewohner, Architekt und Bauarbeiter zu erlangen. Bei der internationalen Frachtabrechnung ist es extrem schwer, die Erwartungen aller Stakeholder unter einem Hut zu bekommen. Genau deshalb haben agile Ansätze in solchen Szenarien m.E. auch Erfolg. "Man" hat eingesehen, dass es fast unmöglich ist, ein gemeinsames Verständnis der zu entwickelnden Software im Vorfeld zu erstellen ... sprich ein Modell zu bilden. Also liefert man anstelle eines Modells in kurzen Zeitabständen das "fertige" Produkt und lässt die Stakeholder Korrekturen einreichen.

Ich stelle die Frage einmal so rum: Wenn es möglich wäre, in einem heterogenen Umfeld ein Modell des zu programmierenden Systems in überschaubarer Zeit zu erstellen, sodass alle Stakeholder ein Verständnis davon haben, was das System für sie leisten wird und dieses Modell würde den Entwicklern eine realistische Aufwandsschätzung ermöglichen, würde dann klassisches Projektmanagement als Methode das Ergebnis in einem definierten Zeit-, Kosten- und Aufwandsrahmen zu erhalten?

Ich meine "ja". Deshalb ist die Frage m.E. falsch gestellt. Wenn ich die Voraussetzungen für klassischen Projektmanagement nicht schaffen kann, dann muss ich mich zwangsläufig nach anderen (agilen) Methoden umsehen.

Unabhängig davon, ich hätte keine Lust einen Operationsroboter oder ein Kernkraftwerk mit einer agilen Methode zu entwickeln.

Schöne Zeit Euch allen.

CU

Andreas

Andreas Epping: "Man" hat eingesehen, dass es fast unmöglich ist, ein gemeinsames Verständnis der zu entwickelnden Software im Vorfeld zu erstellen ... sprich ein Modell zu bilden. Also liefert man anstelle eines Modells in kurzen Zeitabständen das "fertige" Produkt und lässt die Stakeholder Korrekturen einreichen."

Die andere Alternative ist, bereits in der Anforderungsanalyse einen ablauffähigen Prototypen zu bauen.In unserem Umfeld "Financial Services" hat sich das bewährt. Der Kunde sieht bereits "etwas" bevor mit der eigentlichen Implementierung begonnen wird, und die Entwickler verstehen was gewollt ist. Mit ablauffähigem Prototyp meine ich jetzt nicht nicht einfach Bilder oder Mokups, sondern die Verbindung von UI-Flows und die Abbildung von Geschäftsprozessen. Das geht sogar recht leichtgewichtig....(wir haben das was...).

Außerdem hat es den Vorteil, dass somit auch der Scope festgelegt wird...

Andreas Epping: "Unabhängig davon, ich hätte keine Lust einen Operationsroboter oder ein Kernkraftwerk mit einer agilen Methode zu entwickeln."

Warum eigentlich nicht ? Voraussetzung ist, dass alle Beteiligten verstehen wie vorgegangen wird und welche Regeln bestehen. Bei solchen Projekten scheitert es ja (leider) schon am Verständis "Customer collaboration over contract negotiation"....siehe Berliner Flughafen....da macht jeder nur das, für das er beauftragt wurde....ohne Rücksicht auf das Ganze....Bei der Entwicklung von Autos funktioniert das sehr wohl....und vor allem beim Bau von Auto-Prototypen.

Aber wie gesagt: Bei Beginn eines Projektes "ist das geeignete Vorgehen zu bestimmen".

Andreas Epping:

"...ich hätte keine Lust einen Operationsroboter oder ein Kernkraftwerk mit einer agilen Methode zu entwickeln."

Wenn zuvor alle Beteiligten sich auf die selbe Vorgehensweise verständigt und wirklich das selbe Verständnis davon haben - und sich hierzu "commiten"! - , dann können insbesondere solch hoch komplexen Projekte sehr erfolgreich "agil" entwickelt werden. Hoch-Komplexe "Agile" Projekte gibt es zum Beispiel aus dem Automotive-Bereich inzwischen vielfältige - z.B. Wikispeed ( http://www.wikispeed.com/the-process , Johnson Control (Scrum of Scrum), ...

(Vision: 

Gern würde ich die Gelegenheit bekommen zu demonstrieren, dass solche Groß-Projekte wie Stuttgart21, Berliner Flughafen, Hamburger Elbphilharmonie, das damalige "Fiscus"-Projekt, die "elektronische Lohnsteuerkarte", etc. ... mit "agilen" Werten und Methodiken erheblich wirtschaftlicher realisiert werden können, gegenüber den bisherigen - gescheiterten - Vorgehensweisen. 

Hierzu bin ich sehr gespannt, welche Ergebnisse das aktuelle Nürnberger Großprojekt bei der Arbeitsagentur oder das Großprojekt bei der DB Energy erzielen wird - beide sollen vom Anspruch her "Agile" umgesetzt werden.)

CU Boeffi

Keine Frage,

es gibt Branchen, die homogener sind als andere und eine längere "Projektmanagementkultur" aufweisen. Dazu gehören m.E. die Finanzbranche und der Automotive Bereich. Es gibt mit Sicherheit Fragestellungen, bei denen "agile Methoden" ein für den Auftraggeber zufriedenstellenderes Ergebnis liefern, als "klassisches Projektmanagement". Und sicher können wir haufenweise Beispiele liefern, bei denen Scrum gut funktioniert hat. Genauso können wir auch haufenweise Beispiele liefern, bei denen klassisches Projektmanagement tadellos funktioniert hat. Vergleicht mal die Flops des klassischen Projektmanagements mit den Tops der "agilen Methoden", wird immer ein positives Bild für die agilen Methoden entstehen. Ob das die "Wahrheit" ist, wage ich zu bezweifeln.

Ich wage nicht zu beurteilen, ob Stuttgart 21, die Elbphilarmonie oder der Großflughafen Berlin mit agilen Methoden zu einem besseren Ergebnis geführt hätte. Meine subjektive, unvollständige und möglicherweise fehlerhafte Interpretation ist bei diesen drei Großprojekten folgende: (1) bei Stuttgart 21 hat "man" definitiv eine umfassende Stakeholderanalyse vergessen. Sonst hätte man erkennen können, dass es Widerstandsgruppen gibt, die es mit einzubeziehen gilt. (2) Bei der Elbphilarmonie und beim Großflughafen Berlin hätte "man" aus vergangenen Projekten lernen können (Oper in Sydney und Denver International Airport).

Die Frage ist m.E.: Warum hat "man" nicht?

Umgekehrt wage ich auch zu bezweifeln, dass z.B. Facebook ein solcher "Erfolg" geworden wäre, wenn es den weg des klassischen Projektmanagement gegangen wäre. Hätte man Marc Zuckerberg vor etlichen Jahren gesagt: "Mach mal einen detaillierten Plan für die nächsten 2-3 Jahre und zwar so, dass wir die Entwicklungskosten abschätzen können", dann hätte er wahrscheinlich recht sparsam aus der Wäsche geguckt.

Für mich bleibt die Frage "Was sind Kriterien, die mich veranlassen würden klassischen Projektmanagement als Werkzeug zu wählen und was sind Kriterien, die mich veranlassen würden agile Methoden als Werkzeug zu wählen?". Oder anders ausgedrückt: Wann nehme ich Hammer und wann Hobel?

Warum ich ein Kernkraftwerk nicht mit agilen Methoden bauen würde ist für mich eine Frage des Risikos. Ich wage zu bezweifeln, dass es einen Menschen gibt, der in einigen wenigen Sprints beurteilen kann, ob die Gesamtkonsequenzen eines Kernkraftwerkbaus a) technisch durchführbar (inkl. Widerstandsgruppen der verschiedenen Interessengruppen) b) wirtschaftlich durchführbar c) langfristig durchführbar und d) ... e) ... f) ... wie auch immer ist. Die Risiken eines solchen Projekts sind immens und im Augenblick in DE nicht durchführbar. Ich will damit keine Stellungnahme abgeben, ob ich für oder gegen Kernkraft bin, möchte dieses Beispiel nur als extreme Polarität in der Diskussion einführen. 

M.E. adressiert Scrum oder eXtreme Programming sehr gut die Projektmanagement Risiken, aber kaum die Produkt Risiken. Ich will diese Ansätze damit nicht schlecht machen. Ich selbst habe zwei Projekte mit eXtreme Programming durchgeführt und a) Erfolg sowie b) Spaß bei der Sache gehabt. Doch glaube ich, dass diese Ansätze nicht genügen sondern einen klassischen Projektmanagementansatz als "Überbau" benötigen. Was sind die Ziele und was ist der Nutzen eines Projektes, welches sind die Risiken, wer muss oder darf mitarbeiten und was sind die "gewünschten Termine" sind m.E. niemals falsch. Und sei es nur, um zu erkennen, dass ein Projekt "aus dem Ruder läuft".

CU

Andreas

Politik:(eigentlich müsste das ein eigener Thread werden):

In einem Kommentar von mir weiter oben, hatte ich angemerkt, dass es sich bei Stuttgart21, Elbphilharmionie und Berliner-Flughafen um Projekte mit starkem politischem Einfluss handelt. Ergo sind solche Projekte nicht mit herkömmlichen Maßsstäben zu messen. Allen drei Projekten ist offensichtlich eins gemeinsam: Salamitaktik was die Kosten angeht: Zuerst niedrig, damit der Beschluss durchgewinkt wird (und das ohne vorher wirklich komplette Pläne zu haben, oder alle Baugenehmigungen usw.), dann erhöhen sich die Kosten im weiteren Verlauf. Geht das Projekt gut, klopfen sich die Politiker auf die Schulter, geht's schief war es der Projektleiter oder einer aus der Verwaltung....Schon komisch, den Ausbau der A8 Augsburg - München wurde komplett von privater Hand a) finanziert und b) in Rekordzeit fetiggestellt. Warum? Ganz einfach: Hier waren die Auftragnehmer in vollem Kosten-Risiko. Ergo wurde von Anfang an mit allen Kosten plus Puffer gerechnet damit der Busniess-Case mit den Einnahmen aus der Kfz-Steuer aufgeht. Oder in Kürze: Warum vergibt "man" als Öffentliche Hand Großprojekte nicht zum Festpreis an einen GU? Ganz einfach: Mit den so voll kalkulierten Kosten käme man nie durch die politischen Entscheidungsgremien.Wären die Kosten für Stuttgart21 bereits bei Baubeginn genannt worden, hätte sich mit Sicherheit ein Bürgerbegehren etabliert und das Projekt gestoppt. So setzt man Salamitaktik und darauf das sich der Widerstand verflüchtigt. Von den Gegnern haben, seien wir ehrlich, keiner die Kraft 10 Jahre oder mehr durchzustehen (von wenigen Ausnahmen abgesehen). Deswegen: Aus Sicht der Auftraggeber mag es sehr wohl eine Stakeholderanalyse gegeben haben, nur hat man den Widerstand evtl. falsch eingeschätzt. Was auch immer....Politik halt.

Deswegen aus meiner Erfahrung der Softwareentwicklung: Eine Stakeholderanalyse kann noch so gut sein, vielleicht deckt Sie die "Politiker" die mitmischen auf, sobald jedoch Politik im Spiel ist, geht das Projekt den Bach hinunter. (Also das was "man" als vernunftbegabter Mensch "Mißerfolg" nennt ungeachtet dass das Projekt am Ende als "politischer" Erfolg deklariert wird.)

Andererseits, läuft in Augsburg ein riesen Projekt "Mobilitätsdrehscheibe". Hier wurde jahrelang diskutiert, zig Pläne verworfen, Bürgerbegehren initiiert usw. Letztendlich hat man die Bürger aber so abgeholt und klargemacht was machbar ist und was nicht. Die Verkehrsplanung mit Ersatzbussen und Umleitung der Straßenbahnen inkl. der Werbung dafür ist so mit das Beste was ich je in Punkto Projektmarketing erlebt habe.

Auf der anderen Seite ist der Umbau der Eissporthalle ein Desaster. Warum? Sind doch bis auf die Auftragnehmer die gleichen Leute in Poltik, in den Ausschüssen, Veraltung usw.? Das eine Projekt geht, das andere nicht. Bei beiden Projekte müsste man am Ende wirklich lessons learned machen und vergleichen.

Jaaaaaaaaa ..... das finde ich interessant. Warum das eine Projekt in fast identischer Konstellation super läuft und das andere scheitert. Abseits von Dogmen sondern einfach neugierig. Daraus würde ich sehr gerne lernen.

ich versuche mich jetzt mal an einer Antwort auf die die Postings von Reiner und Andreas - was ist der Unterschied zwischen den unterschiedlichen Projekten. Ich würde auch im Baubereich bleiben, hier hab ich ein paar interessante Info's und Kontakte

a) wenn einmal ein paar Projekte funktionieren und manchmal nicht dann darf man übrigends nicht die guten als Erfolg freiern - es könnte auch einfach nur Zufall gewesen sein - das ist ein gern genommener Denkfehler

b) erst wenn man erklären kann warum etwas funktioniert und warum etwas nicht funktioniert hat man Verständnis (mindestens so lange bis eine neue Erkenntnis das Gedankengebäude in Frage stellt). In den letzten ca. 25 Jahren sind die Systemtheorien entstanden. Systeme sind sehr allgemein und abstrakt und die Systemtheorien beschreiben die Wirkungszusammenhänge. Aus meinem Verständnis ist es eigentlich ein muss für alle die über Projektmanagement reden, hier fitt zu sein. Ich verwende als Basis zum einen E. Goldratt ("Theory of Constraints") und die deutsche Übersetzung von Uwe Techt. Viel basiert aber auch auf dem "Trichtermodell" Nyhuis/Wiendahl oder die ganze Warteschlangentheorie (Informatik). Wenn es um Sozialsysteme geht ist natürlich Luhmann pflicht - wenn es um Verhaltensänderungen geht das ganze Themengebiet (NLP Neuro Linguistik Programming), Milton Erickson und jetzt aktuell Gunther Schmidt um nur ein paar zu nennen und auch das sind immer nur Modelle, die aber helfen zu erklären (hoffentlich dogmenfrei)

c) wenn man die Projekt aus der Systembrille anschaut sieht man "immer" folgende drei Hauptfehler:

#1 zu viel (oder ganz selten zu wenig) geplante Arbeit - das ist das mit dem Optimum s. Thread weiter oben ... wenn ich zu viel Arbeit einplane dann kommt es aufgrund von Little's Law (Zusammenhang zwischen Bestand und Durchluafzeit) zu Verzögerungen und in Folge zu Managementoverhead und und und ... wir haben uns mal die Mühe gemacht alle Folgen aufzuschreiben (das ist ein Diagramm mit ca. 350 negativen Folgen) - die sich interessanterweise verstärken

#2 Schätzungen werden oft als "eine" Zahl betrachtet - in Wirklichkeit sind Schätzungen aber Wahrscheinlichkeitfsunktionen (s. Tom De Marco "Bärentango"). Wenn man Schätzungen als eine Zahl betrachtet bekommt man folgende Problem: a) wenn man größer schätzt als notwendig (tatsächlich) wird die Zeit/Aufwand trotz dem verbraucht (Parkinsons Law). Weil in unseren Organisation viel Druck ist - und Verspätungen geächtet sind - wird man Puffer einplanen (typischerweise *1,3 - 2 ich hab aber auch schon *10 gesehen). b) Wenn man Puffer hat und Druck dann macht man zuerst noch andere Sachen (Stundentensyndrom) und dann kommt c) Murphy und es kommt zu verschiebungen (sehr selten zu Verfrühungen - das Wort gibt es gar nicht).

#3 in großen Organisationen herrscht die lokale Optimierung vor - es gibt praktisch keine operativ wirksame Mechanismen die Kooperation fördern. Es fehlt ein zentrales Signal, das den Beteiligten zeigt ob ihre Handlungen sich auf die Leistungsfähigkeit des Gesamtsystems positiv auswirkt oder nicht. Damit sind alle gezwungen lokal zu optimieren. Das kennt man z.B. als Gefangenen-Dilemma aus der Spieletheorie

Es gibt sicher noch mehr Problem (s. Politik oben oder schlechte Führung oder fehlende Produktvisionen u.a.) - die drei hier genannten sind aber grundlegend und man sollte diese als erstes lösen.

d) jetzt sollte man die Fehler einfach lösen - ganz undogmatisch

ich kenne zwei Ansätze die im Projektgeschäft die obigen drei Probleme lösen #1 die Software Cando - hier werden alle Schätzungen als Wahrscheinlichkeiten gerechnet und es wird die Erfolgswahrscheinlichkeit des Gesamtprojektes ausgerechnet. Man plant ganz normal, gibt die Schätzwerte ein (z.B. 10-15 Tage im Oktober - kann man genau so eingeben ... die Software berechnet dann z.B. 55% Wahrscheinlichkeit, dass das Projekt klappt. Die Aufgabe der Planer ist dann die Arbeitspakete so zu schieben/verändern, dass alle Projekte über 80% kommen. Das ist ein Erfahrungswert der Funktioniert "fast" immer. Damit sind die Problem #1 und #2 zu lösen. Aber auch #3 weil sich die Organisation immer drum kümmert, dass das Projekt mit der geringsten Wahrscheinlichkeit Unterstützung bekommt.

der andere viel einfachere Ansatz ist Critical Chain. Hier bedient man sich einer Erkenntnis aus der Systemtheorie "es gibt immer einen Engpass und wenn man an dem alles ausrichtet erreicht man optimalen Durchsatz und kürzeste Durchlaufzeit". Das Problem #1 wird gelöst in dem ein Engpass festgelegt wird (kann auch ein viruteller sein) und anhand dieser Phase werden die Projekte so gestaffelt, dass Termine ermittelt werden die zu 95% sicher eingehalten werden können. Um die Schätzungen in den Griff zu bekommen werden für die Projektsteuerungen die optimisitischen Schätzunge verwendet und um Störungen abzupuffern werden Projektpuffer und Zulieferpuffer integeriert. Das dritte Problem wird dadurch gelöst, dass für jedes Projekt täglich der Fortschritt (auf der kritischen Kette) gegenüber dem Pufferverbrauch ermittelt wird. Das Projekt mit dem schlechtesten Fortschritt gegenüber Pufferverbrauch bekommt alle notwendigen (sinnvollen) Ressourcen und Aufmerksamkeit. Dadurch dass auch der Engpass bekannt ist kann jeder in der Oganisation einfach erkennen ob sein Handlungen positive Ergebnisse haben.

die gleichen Ideen kann man auch im agilen Einsetzen z.B. ein Puffer (ein-zwei-Sprints) am Releasenede und Fortschritt über Pufferverbrauch. Wenn man vorher noch checkt ob der Work-In-Progress zur Zeit und Ressourcen passen - fein - das ist dann das oben genannte Reliable Scrum. Wenn man sich dann noch den Engpass im agilen anschaut - oft die Entwickler, und dann Ideen aus der Lean-Production und Theory-of-Constraints anschaut dann kann man hier den Bestand offener Task/Stories minimieren und kommt auch zum Optimum an Durchsatz und Durchlaufzeit (wie bei Critical Chain im Projekt) - das nennt man dann Ultimate Scrum.

wenn man sich dann noch Multiprojektorganisationen anschaut dann sieht das ungefähr so aus. Auf Multiprojektebenen ähnelt es einer Produktionssteuerung - Staffelung am Engpass (ist eine Produktionssteuerung der 3. Generation - genannt Drum-Buffer-Rope, gerne kombiniert mit einer Just-In-Time oder Dynamic Buffer Management Steuerung). Die Ebene darunter sind die Projekte - hier kann man keine einfache Produktionssteuerung nehmen (wegen der Streuungen und Abhängigkeiten) - da wäre Critical Chain eine gute Idee - bitte kombiniert mit den ganze guten Ideen aus dem guten alten Projektmanagement (z.B. Stakeholderanalyse, Requirement Engineering, ...). Teilprojekte in den Projekten (unterste Ebene) können aber wieder Produktionscharakter aufweisen (ein große Backlog mit vielen kleine recht unabhängigen Teile) - dafür sind die agilen Methoden prädesteniert - weil einfacher und schneller.

ich nenne das dann agile Enterprise oder High-Speed-Projektmanagement ... die ganze guten Sachen, die wir kennen zielgerichtet genau so eingesetzt wie sie systemisch optimal wirken können.

e) viel bla bla bla ... jetzt muss sich das ganze aber auch in der Praxis bewähren. Dazu ein paar Beispiele aus der Bauindustrie - das ist auch Multiprojektmanagement- Singel und Produktion ... alles drei gemsicht. Ich kenne bei den Beispielen jeweils jemand aus dem Team oder der sehr eng damit zusammen gearbeitet hat.

#1 der A8 Umbau zwischen Karlsruhe und Stuttgart ... (s. http://www.vdi-nachrichten.com/artikel/Kostensparende-A-8-Verbreiterung-dank-prozessorientierter-Produktion/14568/2)

1.1 Ob das jetzt privat finanziert wurde oder nicht steht nicht im Artikel. Es ist aber erklärt, was da gemacht wurde: man hat den Engpass identfiert (Teermaschine) und hat alles dan dem Ausgerichtet - 40% schneller und billiger. Das wurd interessanterweise von Porsche Consulting gemanaged und von denen wissen wir, dass sie auf Theory-of-Constraints und Lean Gedankengut zurückgreifen (s.o.)

1.2 Terminal 5 Heathrow (s. http://www.airport-technology.com/projects/heathrow5/) ... ok abgesehen von dem Ding mit den Koffern das war interessanterweise nicht Teil der Projektorganisation und ging prompt schief

"Terminal 5 was a large infrastructure project, involving more than 60 contractors, 16 major projects and 147 sub-projects on a 260ha site. With such a project, BAA realised that if the projects were to be built on time and within budget that a unique approach would be required." ... das war ein Milliarden Pfund Projekt.

Und es war in Time in Budget (kein Stuttgart 21 und so). Eines der faszinierenden Randerscheidnungen - normalerweise rechnet man bei so einem Projekt mit 30-50 Toten. In diesem Fall waren es "nur" sieben - es wurde sehr sehr viel Wert auf Arbeitssicherheit gelegt.

Auch hier kamen Ideen aus der Theory-of-Constraints und Critical Chain zum Einsatz - leider nicht ganz reinrassig. Gesunder Menschenverstand und Projektmanagmenet waren auch dabei. Der Hauptmechanismus war aber die globale Optimierung. Nicht mehr jeder Zulieferer wurde gedrückt und optimiert sondern das Gnaze Projekt. Es wurde ein großer Puffer angelegt (Geldfond) mit dem Ziel - je dem Vertrag. Alles was hier übrig bleibt wird anteilig am Auftragsvolumen auf die Beteiligten ausgeschüttet - und es wurde deutlich ausgeschüttet also globale Optimierung - jeder hilft jedem

1.3 die Bauindustrie in Japan. Japan hat das Problem, dass die Erde oft bebt, Vulkane ausbrechen, Tsunamis und jedes Jahr Hurricans. Das Problem - schlecht Bauprojekte die oft nicht rechtzeitig vor der Hurricansaison fertig wurden und in Folge viele Tote (100erte). Vor ca. 10 Jahr hat sich Yuji Kishira dem Thema angenommen (ich bin mit ihm in Kontakt und mit demjenigen der ihn Berät: David Updegrove) angenommen und Critical Chain als Management Pradigma in Japan verbreitet (s. Testimonial 2007-11 Public Works Revolution - D. Updegrove and Y. Kishira.PDF)

Das Ergebnis ist dass seit 4 Jahren die Projekte alle fertig sind. In Japan wird man als Bauunternehmen bevorzugt, wenn man Critical Chain nutzt. Man spricht von einer Produktivitätssteigerung von 400% (s. Folie 14) - das halte ich für übertrieben. Was ich gut finde ist die Folie 26 mit "Trust" in der Mitte.

f) Also alles drei Beispiele aus der Bauindustrie - es gibt aber auch Beispiele aus allen anderen Industrien.

Das Prinzip ist immer das gleiche - die drei Grundprobleme lösen und mit gesundem Menschenverstand sowie den guten alten Projektmanagment Werkzeugen arbeiten. Nicht mehr lokal optimieren sonder global.

Wie gesagt ich gehe dann noch ein Stück weiter und integriere seamless die agilen Methoden. Und wenn man dann noch mit Vertrauen arbeitet kann man noch mal Balast abwerden und noch schneller werden (s. auch http://speed4projects.net/fileadmin/downloads/High-Speed-Pyramide.pdf).

Alles immer mit dem Blick auf dem Menschen - denn wenn es den Mensche gut geht und sie selbstbestimmt etwas (hindernisfrei im flow) produzieren dürfen dann kommt das Leuchten in die Augen

g) ich würde den Versuch wagen die guten und die schlechten Bauprojekte/Projekte nach den oben drei genannten Hauptproblemen und wie diese gelöst wurden klassifizieren. Mein Verdacht wäre, dass hier ein Muster zu erkennen ist .....

@Wolfram

Danke für Deinen wert-vollen Artikel - eine wirklich spannende Zusammenfassung

zu "a) wenn einmal ein paar Projekte funktionieren und manchmal nicht dann darf man übrigends nicht die guten als Erfolg freiern - es könnte auch einfach nur Zufall gewesen sein - das ist ein gern genommener Denkfehler",

diese These könnte man aber auch umdrehen:

"..wenn einmal ein paar Projekte nicht funktionieren und manchmal doch dann darf man übrigends nicht die schlechten als Miss-Erfolg freiern - es könnte auch einfach nur Zufall gewesen sein - das ist ein gern genommener Denkfehler"

Beide haben aber nach meiner Meinung keine Aussagekraft.

Ein Ursachen-Analyse - im positiven wie im negativen - , z.B. im Rahmen einer "Lessons Learned"-Initiative (klassisch) bzw. einer "Retrospektive" (Agile/Scrum) gibt Auskunft darüber warum etwas funktioniert hat oder eben nicht - und hilft künftig das Gute zu erhalten, und das Schlechte zu vermeiden.

Und damit sind wir bei Deinen oben beschriebenen Punkten b) ff

Hallo zusammen,

interessantes Thema... Interessante Frage... Vereinfacht könnte man die Frage stellen, warum Projektmanagement immer öfter "versagt", oder? Denn die obige Frage beinhaltet doch die Kernanforderungen an ProjektMANAGEMENT perse. Dreieck, abwiegen widerstreitender Interessen, ... Na, ihr kennt das alle denke ich.

Was bedeutet "Versagen" im PM? da sehe ich zwei Ansätze: "Versagen" bedeutet

1. Realität # Planung und/oder
2. Realität # Erwartung

In idealen PM-Systemen ist Erwartung = Planung = Realität. Das Planungssystem wird so lange optimiert bis die Erwartung getroffen wird. Das alles geschieht im Rahmen der durch die Realität vorgegebenen Rahmenparameter.

Nun ist das aber leider (selbst im Idealfall) nur zu Beginn eines Projektes so und die meisten PM-Systeme sind auch nicht ideal. Die Gründe sind vielfältig liegen aber oft in der Unstetigkeit und Komplexität der Realität - und nicht zuletzt in einer oft schwer vorhersagbaren Kreativitätskomponente und natürlich in einer Flut oft unbeherrschbarer Wechselwirkungen zwischen den Beteiligten und deren Zielen die sich im Projektverlauf auch ändern (können). Der sich ergebenden Abweichung zwischen Planung und Realität begegnet man mit Prozessen und Pseudogenauigkeit - an sich um damit die Erwartungshaltung einzufangen (Reporting). Das gelingt oft leider (wenn überhaupt) nur mäßig womit sich Erwartungshaltung und Realität immer weiter von einander entfernen. Damit steuert das Projekt schon recht früh direkt auf sein "Versagen" zu und dabei ist es gleichgültig, ob a) die Planung nachgehalten und damit Planung = Realität erzeugt wird (mit entsprechenden Kompensationsmassnahmen etc pp was ich als gutes PM bezeichne)  was natürlich bedeuten kann Erwartung # Planung = Realität und damit oft für erhebliche Unruhe, Aufmerksamkeit und Mehraufwand sorgt oder b) man Erwartung = Planung # Realität erzeugt/hält mit den entsprechenden Folgen wie Schattenterminplänen, -kalkulationen etc und dem grossen Knall am Ende... An sich bedeutet beides aber "Versagen" des PM (siehe obige Definition).

Wir können uns jetzt Gedanken machen wie wir die Prozesse verbessern, welche KPIs wir messen um rechtzeitig Abweichungen aufzudecken und gegensteuern zu können. Das alles ist sicher notwendig hilft nach meiner Erfahrung oft nicht viel bezogen auf die Bewertung Erfolg/Misserfolg da die Zielerwartung nicht nachgeführt wird oder dies zumindest erst passiert, wenn ein Versagen auch rein rechnerisch und unter den optimalsten Bedingungen nicht mehr erreichbar ist. Getrieben wird dies oft durch eine (ggf. sogar vorsätzlich) von vornherein unrealistische Erwartungshaltung die nicht zu treffen aber trotzdem völlig außer Diskussion steht.

Meine These: PM wird nicht weniger Versagen wenn wir noch mehr Prozesse, noch mehr Kennzahlen und noch mehr Pseudogenauigkeit einführen - wie auch immer die aussehen. Stattdessen sollten wir an realistischen Erwartungshaltungen arbeiten dann wird PM auch weniger versagen.

Wie sollte das jetzt meiner Meinung nach funktionieren? Ich denke, PM-Systeme sind hochkomplex, in den meisten Fällen nicht heterogen und auch nicht stabil und schon gar nicht einfach übertragbar. Das Ganze ist aus meiner Sicht oft vergleichbar mit einer Wettervorhersage (ok, vielleicht nicht ganz da steuernde Eingriffe nur sehr begrenzt möglich sind, aber ähnlich). Ich will jetzt gar nicht erst mit der Chaostheorie und den Schmetterlingen anfangen. Ich denke ihr wisst was ich meine. Es führt uns nur sehr begrenzt weiter das Vorhersagesystem zu verbessern. Bei solchen Problemen denke ich immer an Fuzzy und das Problem des ausbalancierten Besenstiels (ich meine das war mal in der KnowHow-Show - muss schon bald Jahrzehnte her sein). Man hat versucht das System mit einem "Großrechner" auszubalancieren. Das hat ohne große Störungen auch einigermaßen funktioniert. Größere Störungen haben das ganze aber reproduzierbar aus dem Gleichgewicht gebracht. Mit einer unscharfen "Fuzzy"-Steuerung ging's dann auch einige Male schief lief dann aber aufgrund des selbstlernenden Systems anschließen erstaunlich stabile - auch bei größeren Störungen. Das Fuzzy-System war dabei erstaunlich simpel und hat bei Weitem nicht versucht die Gesamtkomplexität des Systems zu formulieren.

Ich denke in einer ähnlichen Situation befinden wir uns beim PM. Vielleicht wäre es ein hilfreicher Ansatz hier ähnlich "unscharf" zu agieren. Hier denke ich in erster Linie an das konsequente Abschätzen und durchrechnen von 3-Punkt-Schätungen (worst case, most likely, best case) und zwar bis hin auf die obersten Berichtsebenen. Den Lerneffekt steuert man dann über die Verbesserung dieser Abschätzungen aufgrund der über die Zeit gewonnenen Erfahrungen ein. Wir ersetzen so Pseudogenauigkeit durch realitätsnahere Aussagen mit definierter Wahrscheinlichkeit und fangen so falsche Erwartungshaltungen frühzeitig ein - eben wie beim Wetterbericht.

Dann muss man nur noch daran arbeiten, wie die gelieferte Mehrinformation zu interpretieren ist. 50% Regenwahrscheinlichkeit bedeutet eben, dass man keine Ahnung hat ob es regnen wird oder nicht. Aber das ist dann eben die Realität  Gemeinsam mit dem Kunden und / oder dem Management kann man sich dann auf eine Arbeitsannahme einigen. Der Unterschied ist, dass sich alle dessen Bewusst sein müssen und die Entscheidung und das Risiko gemeinsam tragen. Wir hätten damit die Erwartungshaltung nachgehalten und damit einen meiner Meinung nach wesentlichen Schritt in Richtung Projekterfolg getan.

Die "Mechanik" selbst ist dabei wohl das kleinere Problem, das richtige Verständnis zu erzeugen sicher das wesentlich größere denn die Frage wird nach wie vor immer lauten: "Erreichen Sie die Ziele oder nicht?" Die Antwort könnte dann lauten: "Ja, mit einer Wahrscheinlichkeit von 85%." Und dann gibt es mehrere Möglichkeiten: 1. Verstanden wird "Ja" und alles hinter dem Komma wird ignoriert oder 2. Diese Antwort wird gar nicht akzeptiert oder 3. Die Bedeutung und der Mehrwert der zusätzlichen Information wird von allen verstanden, entsprechend bewertet und bei Vorhandensein einer Notwendigkeit werden entsprechende Maßnahmen gemeinsam beschlossen und getragen.

Naja, über fehlende Herausforderungen kann man sich in diesem Job ohnehin nicht beschweren!

Hallo, in deinem Posting sind eine ganze Reihe interessanter Aspekte - und immer noch auf der Suche nach Verbesserungen hier auch ein paar Ideen zurück ...

a) in der obigen Definition von High-Speed-Projektmanagement fehlt tatsächlich der Qualitätsaspekt. Einfach daher, weil ich seit längerem davon ausgehen, dass alles unter Q=1 inakzeptabel ist. Für mich ist es inherent, dass die Erwartungen kontinuierlich betrachtet und gemanged werden. Auf keinen Fall Wasserfall - sondern gerne iterativ - in engem Kontakt.

Das Versagen hat sich nie auf die Qualität bezogen sondern immer auf die Geschwindigkeit und den Durchsatz der Projekte. Wobei auch bei der Qualität deutliche Verluste zu beklagen sind.

Das führt interessanterweise zu der Idee, dass es nicht ein magisches Dreieck* ist sondern ganze "DREI" sind - #1 das was der Kunde erwartet, #2 das was pyhsikalisch möglich ist und #3 das was nach der Anwendung von Projektmanagementmethoden noch übrig bleibt. Je mehr Methodeneinsatz desto kleiner ist das was am Schluss rauskommt gegenüber dem was physikalisch möglich ist. Und es ist Aufgabe so nahe wie möglich an das physikalisch möglich zu kommen und dann auch mit dem Auftraggeber klar zu kommen was geht — PM-Forum 2008 - Wolfram Müller 1&1 Internet AG - High-Speed Projektmanagement - 2008-10-22.pdf ... auf Folie 6. Diese Präsentation beruht übrigends auf der Auswertung von mehreren 100 Projekten in denen die Auftraggeber die Erfüllung ihrer Erwatungen auf einer Schulnotenskala angegeben haben. Das verblüffende war eben, dass je mehr Projektmanagementmethode letzt endlich die Zufriedenheit runter ging - weil der Auftraggeber weniger bekam als gedacht.

b) mein Vorschlag bzgl. Reliable Scrum geht genau in die Richtung den Work-In-Progress so zu begrenzen, dass die Erwartungen erfüllt werden können. Dazu muss man sich aber ein paar Gedanken machen und die Schätzungen tranansparent. Dabei wird mit dem Kunden genau ausgehandelt was geht oder auch wie viel Variablilität noch möglich ist. Und weil Kunden mit %-Zahlen nichts anfangen können - gibt es nur ganz oder gar nicht. Das hat mit genau nicht viel zu tun - das ist alles "fuzzy"

(s. Video - gerade erst vor ein paar Tagen veröffentlicht)

c) Die ganze Illusion bzgl. Ein-Punkt-Schätzungen und Planungen sind nichtig - und müssen endlich komplett über den Haufen geworfen werden. Ich habe früher viel mit 3-Punkt-Schätzungen gearbeitet (s. http://speed4projects.net/know-how/basics/) und das ist alles o.k. - am Schluss nimmt man einfach die 80%-absolut-Wahrscheinlichkeit-Werte und gut (s. auch b  und im Video sieht man auch wo die 80% herkommen). Wir müssen unscharf werden - einfach weil die Realität unschaf ist!

Nur ein Hinweis - Critical Chain macht es nochmal viel einfacher (noch gröber noch fuzzier). Hier nehmen wir die normalen 1-Punkt Schätzungen und für die Projektsteuerung nehmen wir einfach die Hälfte davon und packen wiederum die Hälfte als Puffer hinten dran. Bei wenigen Unternehmen muss man hier nachdenken/nachjustieren - das funktioniert immer. Ich mache seit ca. 4 Jahren in meinen Vorlesungen Versuche mit Studenten bzgl. Schätzungen. Es ist irgendwe eine Naturkonstante (empirisch ermittelt) - das wir Menschen unter Druck ungefähr doppelt so lange schätzen wie notwendig wäre - als 50% Puffer. Aber auch hier setzt Critical Chain auf Lerneffekte - je nach Situation werden die Verhältnisse einfach angepasst.

cu Wolfram

* p.s.: die Idee das man nicht aus dem magischen Dreieck ausbrechen kann ist übrigends überholt. Aus der Systemtheorie kennt man ja den Satz mit dem Engpass - damit kann man das Dreieck sprengen. Wenn man den Engpass nicht kennt dann stimmt das Dreieck. Wenn ich z.B. 3 Teams A,B,C habe die an einem Projekt arbeiten müssen und ein Projekt braucht die gleichen Teile von A,B und C und B hat nur 50% der Kapazität von A und c - dann kann man folgendes überlegen:

Wenn man ohne Engpassfokussierung die Leistung erhöhen will dann muss man proportional in allen drei Teams die Kapazität erhöhen. Also mehr Leistung (Qualität = verdoppelt) nur auf Kosten von mehr Kosten (verdoppelt) - Dreieck stimmt.

Wenn man aber nur den Engpass fokussiert und die Kapazität in B verdoppelt. Dann verdoppelt man die Leistung (Q wird verdoppelt) aber die Kosten steigen nur um 17%. Also das Dreieck ist jetzt verbogen - gesprengt oder was auch immer.

Die Idee hinter High-Speed-Projektmanagement ist unsere Grenzen im Kopf (die Dreiecke) zu sprengen und in neuen Gefilde der Erwartungserfüllung bei gleichen/weniger Kosten/Zeit zu kommen

Ich will dennoch darauf bestehen, dass der Ansatz termingetriebener Projekte gescheitert ist. Denn:

• sie bedeuten massive Produktivitätsverluste
• sie bedeuten massive Risiken
• sie verheizen Mitarbeiter
• sie verursachen Fehler
• sie zerstören das Verhältnis Auftraggeber-nehmer. Es kommt fast zwangsläufig zu einem meist kaltem Krieg.

Für das was Zieltermine kaputt machen, also Zeit und Geld kosten, sollte es leicht sein entweder früher anzufangen, oder abzuwarten, bis gesichert ist, dass der Folgeschritt gangbar ist.

Die Geschichte der Menschen ist voll von Beispielen wo scheinbare Abkürzungen in die Katastrophe geführt haben. Auf die Dauer hilft nur richtig machen. Vor langer Zeit war ich bei HP, da hieß es "Do it right the first time"

Die Argumentation - alle Schätzungen sind falsch - also bitte nicht mehr schätzen

So ist mir das doch zu verkürzt. Besser so: Schätzungen sind unpräzise. Also sie nicht für bare Münze nehmen, sondern zu diesem Zeitpunkt den tatsächlichen Stand prüfen und dann den nächsten Schritt entscheiden/freigeben. Vordergründig ergeben sich da zwar zeitliche Lücken, aber unterm Strich wird produktiver gearbeitet. Also "eines nach dem anderen" machen (natürlich nur wenn die Schritte aufeinander aufbauen).

Es ist mit Zielterminen wie in der Bankenkrise, irgendjemand geht diese Risiken ein und lässt sich feiern und gut bezahlen wenn es gut geht. Aber wenn es schief läuft, dann werden andere zur Kasse gebeten.

Es gibt sehr selten Abkürzungen um etwas richtig/besser zu machen, aber man kann sehr viel überflüssiges, unproduktives verhindern. Zieltermine verursachen regelmäßig Konflikte, Hektik, Chaos, Fehler, Schuldzuweisungen und dann Krieg.

Ich bin mir sicher, dass Leuchten in den Augen kommt davon, dass das Projekt funktioniert, aber nicht davon dass man die Hektik und das Chaos überstanden hat.

Also Beharrlichkeit finde ich per se erst mal gut - nur so kann man was bewegen. Wer immer gleich umfällt hat zu wenig Standing.

Ich würde aber gene zum weiterdenken anregen. Aus dem Systemdenken gibt es noch einen zweiten hilfreichen Satz: "Wenn man es schafft ein gemeinsames Ziel zu finden, dann kann es zwischen zwei Personen keinen dauerhaften Konflikt geben - höchsten fehlerhafte Annahmen, die wenn man eine auflöst zu einer Win-Win-Situation führt" (s. Methode der Evaporation Cloud / Konfliktwolke).

In diem Fall haben wir glaube ich das gemeinsame Ziel: wir wollen beide höchste Produktivität und dabei die Integrität des Menschen erhalten. Es darf nicht sein, dass Menschen in einer Überflußgesellschaft auch noch leiden oder beschädigt werden.

Sie sind nun der Meinung, dass terminfixierte Projekte projekte abgeschafft werden sollte. Ich bin der Meinung, dass man beides unter einen Hut bekommen kann - termin und menschlichkeit und produktivität.

Leider kann ich jetzt nicht wirklich mit Ihnen diskutieren, daher kann ich ihre Annahmen nur spekulativ betrachten. Ich versuche es mal:

#1 termingetrieben Projetkte verursachen Produktivitätsverluste, weil meist die Termine zu früh gesetzt werden und damit eine Spirale der negativen Effekte in Gang gesetzt wird - z.B. Verantwortlichkeitsverlust der Mitarbeiter, überbordende Planung und Reportings, Rechtfertigungsorgien, Demotivation, schlechte Qualität, Nacharbeiten ..... wie gesagt ich kenne 350 davon

#2 termingetrieben Projekte bedeudet massive Risieken - durch die unter #1 genannten Effekte wird das Risikomanagment vernachlässigt und keine Reserver für die Risikobehandlung vorhanden ist ... also eine Folge von #1 und fehlende Puffer

#3 verheizen Mitarbeiter ... klar eine Folge von #1 - ich würde noch weiter gehen, wenn Termine zu früh gesetzt werden dann geht auch noch die Selbstbestimmtheit der Mitarbeiter verloren die Folge ist keine Innovationsfähigkeit und keine Qualität

#4 s. #3 ... zu früh gesetzt Termin sind klar ein Qualitätsrisiko

#5 zerstören das Verhältnis Arbeitgeber-Arbeitnehmer... ja klar - wenn ich ein Termin aufgdrückt bekomme, der nicht realisitisch ist dann verliere ich die Beziehung zu dem Menschen ... in schlimmsten Fall, wenn er nicht gehen kann dann beschädige ich den Menschen - no go!

Hinter den 5 Argumenten sehe ich zwei Annahmen a) die Termine werden normalerweise zu früh gesetzt und b) Risiken sind nicht abgepuffert.

Beide Argumente (und noch ein paar mehr) werden durch Critical Chain adressiert. Haben sie sich das Konzept schon angeschaut?

Im Kern ist Critical Chain ein Mechanismus um Termine genau so zu wählen, dass sie mit einer Wahrscheinlichkeit von ca. 95% eingehalten werden. Das ist eine rückgekoppelte Steuerung - so lange die 95% nicht gehalten werden - wird der Work-In-Progress reduziert. Wichtig ist, dass die Führung das versteht - daher machen wir vor einer Einführung 6-10 Tage Workshop mit dem oberen Management. Das zweite Element von Critical Chain ist die konsequente uns sachrichtige Abpufferung der Risiken am Projektende oder Integrationspunkten. Bei geeigneter Dimensionierung (nicht zu groß, nicht zu klein) kann man die Risken sauber in den Griff bekommen. Critical Chain ist noch ein bischen mehr. Die gleichen Mechanismen kann man auch auf agile anwenden dann heißt es Reliable Scrum.

Wenn man unter google "Critical Chain Erfolgsgeschichten" eingibt wird man einiges finden. Es funktioniert - einfach weil die falschen Annahmen eines schlechten Management aufgelöst werden (müssen).

Bei den Abkürzungen gebe ich Ihnen voll recht - ich sage da immer "man kann die Projektphysik nicht austricksen". Das eines nach dem anderen ist übrigends extrem wichtig und richtig. Auch hier hilft der Puffer am Projektende. Durch den Puffer hat man nicht den Druck ein einzelnes Arbeitspaket auf biegen und brechen fertig zu machen. Wenn etwas richtig gemacht werden muss - muss es sein! Wenn man dafür etwas Puffer verbraucht - auch gut. Wenn man aber dauerhaft weniger Fortschritt (auf der kritischen Kette) als Pufferverbrauch, dann mus man reagieren - in letzter Konsequenz muss dann entweder der Termin angepast oder die Resourcenlage verbessert werden. Das eines nach dem anderen ist auch Bestandteil von Critical Chain - das hilft Geschwindigkeit zu gewinnen und Fehler zu vermeiden - was dann wiederum den Aufwand verringert und weitere Geschwindigkeit bringt ....

mfg Wolfram Müller

p.s. für die Verkürzung der Aussage bzgl. Schätzungen entschuldig ich mich - war definititv zu stark verkürzt ... ich kenne aber tatsächlich auch Situationen in Projekten in den Schätzungen gar kein Sinn machen (z.B. bei E2E-Test oder in Integrationsphasen - man weiss eh nicht was passiert) ... aber auch hier gibt es Lösungen

Hinter den 5 Argumenten sehe ich zwei Annahmen a) die Termine werden normalerweise zu früh gesetzt und b) Risiken sind nicht abgepuffert.

Das trifft es ein Stück weit. Wobei b) automatisch entfällt wenn man a) nicht macht. Wenn man fertig meldet wenn man wirklich fertig ist, braucht es auch keinen Puffer.

Es geht mir nicht darum Termine abzuschaffen, sondern dessen Bedeutung richtig zu setzen. An einem Termin kann der Zustand des Projekts/Arbeitspaketes geprüft werden, und dann, und bitte wirklich erst dann, können Folgeschritte beschlossen oder gestartet werden.

Wer möchte denn in einem Bus oder Zug mitfahren, wo man automatisch zur planmäßigen Ankunftzeit zwangsweise ausgesetzt wird?

Oder wer übernimmt die Angaben des Navigationsgerätes so sklavisch als Vorgabe, dass man im Hafen landet (obwohl das schon passiert sein soll).

Beide Argumente (und noch ein paar mehr) werden durch Critical Chain adressiert. Haben sie sich das Konzept schon angeschaut?

Ich habe mir zwei Bücher von Goldratt bestellt. Die sind noch im Zulauf. Solange muß ich Deine Aussagen und Wikipedia als Grundlage nehmen. Dabei fallen mir folgende Dinge auf 

Der Puffer über den früher die Entwickler selbst verfügten, wird nun dem gesamten Projekt zur Verfügung gestellt. Die Argumentation "Student, Gasgesetz, Murphy" & Co wird dadurch nicht entkräftet, sondern nur auf das Management verschoben. Tatsächlich halte ich die Argumentation zwar für richtig, interpretiere sie jedoch als Symptom, nicht als Ursache. 

Das heißt, dass der Puffer tatsächliche Konflikte und Probleme verdeckt und sie somit einer Lösung entzieht. 

Der zweite Punkt ist, dass dieses Konzept aus der Produktionsteuerung kommt. Produktionsabläufe betrachten den Menschen biomechanischen Manipulator, nicht als kreativen, findigen, intelligentes Wesen mit einem großen Potential. Das mag für Produktionssteuerungen pragmatisch sein und meist richtig, für echte Softwareentwicklung ist es schlicht falsch.

Jedes noch so gutes Konzept leidet daran, dass die "Entscheider" dessen Grenzen nicht beachten.

Ich will dazu eine sehr alte Geschichte bei meinem ersten Arbeitgeber erzählen. Es geht um die Kostenbewertungen einer Neuentwicklung. Bauteile und Arbeitsschritte wurden mit "Overheadfaktoren" belegt um die Kosten aus anderen Bereichen umzulegen (z.B. Marketing, Vertrieb, Controlling usw).

Irgendwann waren die Faktoren Werte um die Zahl 10. Das heißt, auf einen Euro Produktionskosten kamen 9 Euro andere Kosten.

Das hatte zunächst zur Folge, dass man die Produktion drängte die Kosten zu senken, sagen wir auf 0.5€. Scheinbar kamen nun nur noch 4.5€ Kosten auf das Produkt zu. Aber die anderen Kosten blieben natürlich unverändert, nun stieg der Faktor halt auf 19. So konnte es nicht funktionieren, der Nutzen der Kostensenkung hielt nur bis zur nächsten Ermittlung der Overheadfaktoren.

Was ist denn nun das Kernproblem? Die Methode operierte mit den beiden Begriffen Overheadfaktoren und Produktionskosten. Andere Kosten wurde nicht explizit genannt. Daher war es für den durchschnittlichen Manager nur möglich in diesen beiden Begriffen zu denken. Overheadfaktor wurde im Controlling ermittelt, die Produktionskosten waren letztlich der einzige greifbar, aber leider auch falscher Ansatzpunkt.

Und unter dem selben Problem leidet Critical Chain (modulo in den Büchern steht mehr). Der Puffer verdeckt und versteckt Probleme. So verständlich ich nachvollziehen kann, dann man zuverlässige Termine haben will, der Preis ist ziemlich hoch. 

... so langsam kommen wir näher zusammen

a) Termine auf Arbeitspaketebene zu fixieren ist komplett sinnfrei - hier teile ich ihre Aussagen vollständig. Hier gilt der Fokus darauf zu legen möglichst ungestört gute Arbeitsergebniss zu erziehlen. Wenn diese erreicht sind dann macht es Sinn das nächste zu starten. Teillieferungen sind natürlich möglich - aber mit der gleichen Prämisse.

Critical Chain kennt hier folgende Mechanismen auf Arbeitspaketeben:

• die Ursprüngliche Schätzung zur Planung wird für die operative Steuerung nicht mehr verwendet
• man schätzt alle ein bis zwei Tage die aktuell noch geglaubte Restlaufzeit (wie bei den Agilen)
• ein Arbeitspaket das begonnen wurde wird mit so viel Ressourcen wie sinnvoll möglich ausgestattet und wird wenn es begonnen wurde auch fertig gemacht
• wenn es von einem Tag zum anderen zu einer deutlichen Verlängerung der Restlaufzeit kommt wird dies als Indikator genommen um zu suchen wo hier das Problem war 

Auf Projektendtermin und Portfolioebene

• das Portfolio wird so gemanaged dass eben 95% der Termine (urspüngliche Planung) gehalten werden 
• wenn zu viel grüne Projekte sind werden die Pufferzeiten reduziert um Stundentensyndrom, Parkinson zu vermeiden und das System anzureizen sich zu verbessern
• die Dauern der Arbeitspakete werden künstlich verkürzt um einen Faktor und die so gewonnen Reserver als Puffer vor den Integrationspunkt zuammengefasst, so dass sich auch größere Störungen oder auch Verfrühungen ausgleichen können
• durch die täglichen Rückmeldungen bekomt man eine Auswertung in welchem Team überdurchschnittlich viel Puffer verbraucht wird. Normalerweise ist das Team dann zwar nicht das Problem - die Probleme entstehen "immer" Upstream als in vorgelagerten Arbeitspaketen - aber man weiss wo man fragen und hinschauen muss

Wenn man die obigen Punkte zusammen nimmt kommt durch Critical Chain genau ein sehr starker Mechanismus in Gange, der dafür sorgt dass Probleme sichtbar werden und ganz fokussiert aufgelöst werden  Hinter der Critical Chain steht ja auch noch die Theory-of-Constraints und die bringt mit der Konfliktwolke ein Format mit, das dann hilf die Konflikte zu lösen und in Win-Win umzubauen. <Werbeeinblendung> Einer unsere Kunden (von Ardenne Anlagentechnik) hat es geschafft die Projektlaufzeit von 21 Monate auf jetzt 6 Monate (Ziel 5 Monate) zu reduzieren - das ist natürlich unser Vorzeigekunde. Bei den anderen Kunden ist es auf dauer auch immer eine Halbierung </Werbeeinblendung>

b) Ja klar die Entscheider müssen voll dahinter stehen. Ich hab es im Thread auch glaube ich schon mehrfach erwähnt. Wenn wir (Speed4Project/VISTEM) ein Beratungsprojekt annehmen dann gehen wir mit dem Top-Management und der Ebene darunter 6-10 Tage in Klausur. In dieser Zeit werden viele "hinderliche" alte Denkmuster entlernt und eben die ganzen neuen gelernt. Das passiert viel mit Spielen und Reflektion - und dauert meist länger als man will. Wird aber nach den ersten Tage auch bereitwillig gemacht. Im Laufe des Changes haben die Führungskräfte dann auch immer wieder Aufgaben, deren Sinn es hauptsächlich ist, den Mitarbeitern zu zeigen, dass sie es verstanden haben (die Mitarbeiter wissen eh schon lange was gut ist)

e) Produktionssteuerung sind per se nicht böse! Sie beziehen den Menschen oftmals mehr ein als schlechte Projektsteuerungen. Produktionssteuerung sind nicht mit Taylorismus zu verwechseln! Wenn man sich die Mitarbietermotivation in guten gemanagten Lean Organisationen anschaut dann würde ich behaupten wollen, dass diese sehr gut auf Wissenarbeit fokussieren (denn Produktion ist nichts anderes mehr).

Interessanterweise sind die agilen Methoden reinrassige Produktionssteuerung. Scrum entspricht einer, nur wirklich sehr alten Produktionssteuerung - nämlich der von Henry Ford - mit einer Verschlimmbersserung nämlich großen Batchsizes. Bei Kanban macht man gar keine Hehl daraus - die ist direkt von T. Ohno Toyota Production Sytem abgeleitet. In beiden Fällen sind die Steuerungen sehr leichtgewichtig - was Ressourcen für die Wertschöpfung und Denkarbeit freisetzt. Sie begrenzen beide sehr hart den Work-In-Progress, was den Fluss in Gang bringt. Und setzen sehr stark auf die Selbstorganisation, Transparenz und systematische Fortentwicklung (Kaizen, Deming). Das sind alles Elemente aus der Produktionssteuerung

f) zum Theme Preisfindung bei Produkten und Produktvollkostenrechnung ... es ist unglaublich wie "falsch" die BWLer hier unterwegs sind. Viele der Ansätze hier stammen aus der Zeit vor den Computern. Kostenstellen z.B. wurden nur eingeführt, weil es die damals einzige Möglichkeit war die Kosten überhaupt buchhalterisch zu erfassen - sie haben für die Preisfindung oder für die Unternehmensführung keinen sinnvollen Mehrwert. Das gleich gilt für Budgets - machen heute in der Form keinen Sinn mehr, weil sie die Flexibilität stören. Weiter geht es bei den Bilanzierungen die Inventar höher bewerten als Fluss. u.s.w.  Aber das ist ein ganz anderes "dunkles" Kapitel.

Wenn wir Critical Chain einführen schaffen wir typischerweise auch gleich noch die Projekt-Voll-Kostenrechnung ab. Die fakturierung von Stunden auf ein Projekt ist bis auf ganz wenige Fälle schlicht falsch. Wenn sie ein Engpassteam haben (und das haben sie!) dann ist ein Projekt das wenige Stunden im Engpass braucht wesentlich lukrativer als eines das viele im Engpass braucht. Wenn man das mal aktzeptiert hat dann sind Stunden im Engpass sehr teuer und im nichtengpass super billig. Aber wie will man das rechnen - es geht schlicht mathematisch nicht. Daher läßt man es am besten und schwenkt über zur Deckungsbeitrag/Engpass-Rechnung um die Qualität des Portfolios zu optimieren.

Wenn man das gemacht hat muss man aber auch gleich die Nummer mit dem Mitarbeiterindividuelle Zielvereinbarungen über den Jordan jagen. Das macht auch keinen Sinn - einfach weil es unmöglich ist, die Ziele (die sich ja tatsächlich oft und kontinuierlich ändern) fehlerfrei auf 100erte Mitarbeiter runterzubrechen ohne dass Konflikte induziert werden. Die Lösung hier ist einfach - X% von der Gewinnsteigerung werden Anteilig nach Gehalt ausgeschüttet - fertig. Wenn jeder Mitarbeiter weiss, wo der Engpass ist, dann weiß er auch ob seine Handlungen dem Gewinn dienlich sind oder nicht. Damit fokussiert das Unternehmen auf ein steuerndes Element und alles Arbeiten daran den Durchsatz zu verbessern. Und ja es gibt Unternehmen die das machen!

No zwei Buchtipps:

• "Goldratt und die Theory of Constraints" Uwe Techt - wer die Romane nicht mag. Hier ist alles auf wenigen Seiten kurz und prägnant zusammen gefasst.
• "Management Dynamics: Merging Constraints Accounting to Drive Improvement" Caspari - meines erachtens die umfassendste Einführung in die ganze Thematik. Achtung hier geht weit über das Projektmanagement hinaus - hier wird gleich noch die Prodution, Distribution, Kostenrechnung aufgeräumt. Das ganze läuft auch oft unter dem Begriff "Throughput Accounting" oder "Theory of Constraints (TOC)". Wir wollen uns bei OpenPM ja auch bewusst vom Mainstream abheben und neues Schaffen - mit TOC kann man auch so ganz neben bei des "magische" Dreieck im Projektmanagment aushebeln/sprengen. Das Dreieck hab ich immer schon als störend und einengend empfunden
• oder mir einfach ne Mail schicken - ich hab ein USB-Stick zusammen gestellt mit vielen Informationen dazu - kommt dann per Post

Also High-Speed-Projektmanagement ist ab Schluss doch mehr als nur Critical Chain und Reliable/Ultimate Scrum Als erstes ist es ein Top-Down-Ansatz (wenn man global optimieren will muss man die obersterste Führung im Boot haben) und es krempelt nach und nach das ganze Unternehmen um. Das schöne ist, dass dabei die guten Ideen (z.B. agil) erhalten bleiben und im Sinne eine Win-Win (Unternehmen + Mitarbeiter) verstärkt werden.

Wenn man im Internet unter google TOC/CCPM zusammen mit Testimonial, Erfolge oder ähnliches eingibt wird man erstaunlicherweise mehr Unternehmen finden, die es einsetzen als man glaubt. Wir sind gerade an einer mittelständischen AG dran - und es macht sehr viel Spass

Dieses Jahr findet die TOC-ICO das ist der Weltkongress der TOC/CCPM-Anwender in Deutschland statt - 02.-04.Juni ... eine super Gelegenheit mal in das Ganze Themengebiet einzusteigen.

"Je mehr Methodeneinsatz desto kleiner ist das was am Schluss rauskommt gegenüber dem was physikalisch möglich ist"

So sehe ich das auch. Außer die Methode ist "Kommunikation". 12 Listen und Tools ersetzen nicht ein kurzes Gespräch. Das ist das positive an den SCRUM Daylies. Man spricht jeden Tag kurz über die Dinge.

"Fehlender Qualitätsaspekt"

Die Qualitätsdimension ist hier auf keinen Fall zu vernachlässigen. Ich kriege meine Arbeit auch in 4 Stunden erledigt. Die Frage ist nur wie. Die Qualität ist also zu definieren und wie du schon sagst iterativ zu managen. Auch hier hat sich meiner Erfahrung nach ein agiles Abstimmen und ein entsprechndes "Log" als sehr positiv erwiesen. Sind die Qualitätsanforderungen hinreichend definiert, dann kann ich auch einen Engpass bestimmen. Diese Qualitätsbestimmung (oder Erwartungsmanagement) ist für mich einer der zentralen Punkte, wie Projekte besser laufen können. Dieses Erwartungsmanagement geht bei mir in Richtung Projektmitarbeiter genauso wie in Richtung Kunden. Hier würden mich Tools und Best Practices interessieren....

"Engpass # Engpass"

Wirklich spannend wird es, wenn man seinen Engpass am Beginn des Projektes nicht kennt und sich dieser erst nach und nach offenbart. Hier liegt dann, so verstehe ich deine Ausführungen, eine Kernkompentenz des PM diese Engpässe zu erkennen und versuchen alles von der Ressource wegzudelegieren, was nicht Niet und Nagelfest ist, oder die Kapazität zu erhöhen. Letzteres funktioniert nur sehr grenzwertig. Hier hat sich bei SRUM Projekten gezeigt, dass die Selbstverantwortung der Mitarbeiter + tägliche Kommunikation die besten Lösungen ergab. I.d.R. wurden innerhalb des Teams Lösungen gefunden und ich als PM musste nur moderieren. Wie geht man damit am besten um?

Schätzung

Meine Erfahrungen mir 1-Punkt oder 3-Punkt Schätzung decken sich nicht so ganz mit dem Naturgesetz 50 % Aufschlag. Tatsächlich liegt bei mir der Puffer bei 25-30 %, aber da wird jeder seinen branchenabhängigen Erfahrungswert haben. Ich habe leider keine Erfahrung mit Critical Chain.Grundsätzlich plane ich also immer mir 30 %  + einem Tag Puffer (Lieferung am Folgetag) beim Task. Den Puffer in Summe nach hinten nehmen kann ich mir nicht vorstellen, da bei mir die Deliverables intensiv während des Projektes mit dem Kunden abgestimmt werden müssen. Dazu brauche ich konkrete Meilensteine, sprich Termin XY (nach Puffer + Folgetag)... Wie geht man damit um?

nur kurz weil einfach nur ergänzende info's

a) Kommunikations ist das absolute beste was passieren kann - bitte aber eben auf persönlicher Ebene (nur hier kommen dann echte Vertäge zustande) und eben kein unnötige methodenzentrierte Ballastkommunikation ... so wenige wie gerade notwendig aber dafür gute echte persönliche Kommunikation macht eh viel mehr Spass

b) den Qualitätsaspekt hab ich ergänzt s.o. "ohne die Qualität zu korumpieren" ... ich gehe heutzutage eben davon aus, dass über Qualität nicht mehr diskutiert wird - Qualität ist einfach ein muß!

c) deine Frage - wie geht man damit um, wenn der Engpass nicht bekannt ist?

Ich gehe mittlerweile davon aus, dass man den Engpass gar nicht findet sondern bewusst irgendwohin legt! Es sind mehr Überlegungen als eine Suche. Das ist allerdings etwas komplexer - daher hier nur ganz ganz kurz

#1 im Scrum-Umfeld kann man davon ausgehen, dass die Entwickler (das Team) der Engpass sind. Wenn der Engpass außerhalb wäre müssten die Entwickler (das Team) ja zeitweise nichts zu arbeiten haben oder es müsste sich ein Berg an fertiger Arbeit irgendwo bilden. Daher getrost davon ausgehen, dass die Entwickler der Engpass sind.

#2 manchmal ist es aber tatsächlich nicht das Team sondern der Integrationspunkt eines Projektes oder eines Unternehmens. Wenn in einem Unternehmen z.B. mehrere Teilprojekte (jeweils mit Scrum organisiert) in ein Hauptprojekt liefern - gibt es hoffentlich zwar continuous integration - aber um sicher zu sein, dass wirklich alles funktioniert werden dann doch E2E-Test von einem gesonderten Team geamacht. Dann kann es sein, dass die Kapazität dieses Teams, in Bezug auf das gesammte Portfolio, den Engpass bildet. Das gleich kann z.B. in einem großen Unternehmen passieren, wenn der Übergang von Entwicklung und Produktion so aufwändig ist, dass es eben ein Engpass bildet. Oder in Unternehmen in denen die Software in eine Hardware eingebaut wird und diese Hardware produziert wird ist oft die 0-Serie der Engpass. Diese Engpässe bei der Integration tauchen auf, weil in diesen Phasen nicht wirklich bekannt ist was passiert - es passieren Bugs (hoffentlich wenige). Wenn Bugs auftreten, dann braucht man aber die besten Experten (sonst wird es lange dauern und teuer) man weiss aber nun beim besten Willen nicht welche und Experten sind per se genau so definiert, dass sie selten sind - daher oft der Engpass.

#3 aber eigentlich sollte der Engpass gar nicht im eigenen Unternehmen sein! Wenn der Engpass im Unternehmen ist und nicht im Markt/Marketing/Sales ... dann heist das nichts anderes, dass mehr Kundenbedarf da ist als das Unternehmen befriedigen kann. Der Schluss hieruas ist, dass entweder Marktanteil verloren wird (ganz dumm) oder mindestens Umsatz/Gewinn (auch dumm). Also der Engpass muss raus aus dem Unternehmen!

Meiner Beoabachtung nach sind Scrum-Teams selten wirklich großzügig gestafft - hat auch was mit der optimalen Gruppengröße zu tun. Denn mehr als 9 sind nicht richtig gruppendynamisch und dananch kommt das Scrum Skalierungsproblem. Bei Scrum-of-Scrum wird nämlich das wertvollste (s. a) die Kommunikation zum Engpass

Also weil #3 oft ignoriert wird und #2 eher selten ist - ist #1 ein akzeptabler Ansatz

e) Die 50%-Verkürzung kommt aus einem eher klassischen Projektumfeld mit zu viel Work-In-Progress (immer noch ca. 95% aller Unternehmen). Im Scrum-Umfeld, wenn das Team schon erfahren ist oder wenn Reliable Scrum oder Ultimate Scrum schon am laufen sind - stimmen die 50% definitiv nicht mehr! Wenn nur Scrum am laufen ist gehen ich gerade mal von 10-20% Reserver aus. Bei Reliable oder Ultimate Scrum ist in den Schätzungen nur noch max. 5% drin und die kommen aus dem Quantisierungsfehler der Fibanoci-Reiche (wer zum Kuckuk ist auf die Idee gekommen, dass Fibanoci hier Sinn macht - wir haben das fast wieder abgeschafft).

Wenn ich die ganze Zeit mit meinem Kunden die Deliverables abstimme dann bin ich normalerweise nicht in der Critical Chain Welt - das ist die domaine der Produktionssteuerungen also der agilen Methoden. Da bin ich ganz ehrlich - das macht CCPM wenig Sinn.

Critical Chain ist in echten Projekten definiert - also Multiprojektumgebungen ohne Scrum/Kanban-Steuerung. Hier ist es so, dass man wie gesagt die Dauern, nur für die operative Steuerung, einfach mathematisch verkürzt und den so gewonnen Zeitpuffer vor den Integrationspunkt (s.o.) legt. Weil mit dieser Maßnahme Studentensyndrom und Parkinsons ausgehebelt wurde kann man normalerweise den Puffer hinten wieder halbieren. Man betrachtet dann immer Fortschritt auf der kritischen Kette genüber Pufferverbraucht. Fortschritt wie bei agilen Methoden über Estimated-Remaining-Time abgefragt.

Es geht aber tatsächlich auch mit Critical Chain. In Critical Chain wird jedes Ergebnis auf der kritschen Kette zu einem Meilenstein. Aber nicht im klassischen Sinne sondern im agilen. Durch dir Verkürzung ist es ja unwahrscheinlich, dass der Termin eines einzelnen Arbeitspaketes (Meilenstein) gehalten wird. Dafür ist ja der Puffer am Ende / Integrationspunkt vorgesehen. Wenn man sich also mit dem Kunde abstimmt, wann das Ergebnis als o.k. gilt dann verschiebt sich ggf. der Meilenstein.

Es geht - aber das hochitterative super kreative ist eher die Domaine von Scrum.

Für größere komplexe verknüpfte Vorhaben ist Critical Chain das Mittel der Wahl.

Aktuell führe ich aber nur noch Kombinationen von beidem ein. Warum sollte man nicht das jeweils beste nutzen. Interessanterweise kann man das sogar innerhalb eines Projektes tun.

Ooooops jetzt ist es doch länger geworden - aber die Fragen waren einfach zu interessant - Danke

Servus,

schöne kurze  Antwort. Tatsächlich bewege ich mich im kreativen Umfeld, wo einzelnde Deliverables kreative Arbeiten sind, die auch mit dem Kunden abgestimmt werden müssen. Hier treffen alle "Anforderungen" an agile Methoden zu. Das Gesamtprojekt wiederum ist schon ein klassisches Projekt mit Budgets, Phasen, Meilensteinen, Ressourcenteams und und und.... Also das komplete Paket. Daher mein Interesse an der Kombination der beiden Welten klassisch & agil. Hier ist viel Selbstversuch unterwegs und es mangelt meiner Ansicht nach an getesteten Konzepten.

Grüße und Danke für die umfangreichen Antworten

Pascal

pascalswelt "Hier ist viel Selbstversuch unterwegs und es mangelt meiner Ansicht nach an getesteten Konzepten."

Also ich für meinen Teil finden PRINCE2 + Scrum als durchaus machbar. Insofern ist das für mich "getestet" und für "gut" befunden. Aktuell machen wir für einen Kunden was ähnliches: PM nach Kundenvorgabe plus projektspez. Anpassungen plus Entwicklung nach SCRUM. D.h. das/der Team(s) wird komplett von der Politik abgeschottet. Da wird's einen PL geben für das ganze "Management-Gedöns", plus Produktowner in Kombi mit Req.engineer an seiner Seite plus Scrum-Master.

Mittlerweile ist das Buch zu ToC von Uwe Techt eingetroffen und ich habe es durchgelesen.

Der Wert von ToC sehe ich in folgenden Punkten

• es ist leicht einsehbar, dass aus vielen lokalen Optimierungen keineswegs eine globale wird. Eine globale Optimierung heißt mehr Geschäftserfolg. Die übliche Kostenrechnung kann bedenkenlos in den Orkus geben werden, da sie zu massiven Fehlentscheidungen führt.
• es wird leicht nachvollziehbar, unter welchen Bedingungen eine lokale Optimierung eine globale werden kann.
• Es räumt mit Illusionen des klassischen Controllings auf. Weg vom Kostendenken, hin zum Nutzendenken
• Konflikte und Widerstände werden dokumentiert und als Chancen begriffen

Schwächen sehe ich dennoch

• Ressourcen werden sehr statisch betrachtet. Insbesondere werden Menschen als statische Ressourcen betrachtet.
  Wenn man Menschen als Ressource betrachten will, dann muss man sie als sehr dynamisch verstehen. (Ich sehe diese möglichen Ansichten: ein Mensch ist keine Ressource oder er ist AUCH eine Ressource im Sinne von Mensch EXTENDS Ressource oder er hat Ressourcen)
  Eine Teermaschine wird in zwei Jahren praktisch gleich leistungsfähig sein wie heute. Ein Mensch kann in zwei Jahren viel dazugelernt haben, viel vergessen und eine andere Einstellung gewonnen haben, auf jeden Fall wird sich seine Leistungsfähigkeit verändern.
  
  Damit brechen die Voraussetzungen der ToC zusammen. "Leerzeiten" können von Menschen genutzt werden um zu lernen, um neue Fähigkeiten anzueignen. Die Teermaschine kann kaum anderweitig z.B. als Lastwagen eingesetzt werden, bei Menschen sind zumindest die intelligenteren Exemplare in der Lage andere Fähigkeiten zu entwickeln. Ob das im Einzelfall Sinn macht (=Durchsatz erhöht) oder nicht kann man nicht generell beantworten.
  
  Es stellt sich eher die Frage, wo und in welchem Grad macht ToC Sinn
• Im Projektumfeld beeinflussen Tool/Sprachen/Bibliotheks-Wissen, Erfahrungen, Auffassungsgabe, Intelligenz, Bereichswissen, Begabung usw. die Produktivität. Welcher Teamkollege für ein Arbeitspaket der Produktivste ist, ist kaum auszumachen und damit ist kaum eine Person als Engpass erkennbar. Und selbst wenn könnte ein anderer mit Leerzeiten sich diesen Themenbereich aneignen.
• Problematisch könnte es werden, dass Personen das Spiel durchschauen und sich bewusst zum Engpass machen, weil dann vielleicht besser bezahlt werden.
• Unklar bleibt wie Verschiebungen des Engpasses erkannt werden. Wer oder was schlägt Alarm wenn die gefundene Lösung aus ihrem Wirkungsbereich herausfällt? Wie soll das in die Organisation eingebunden werden?

Methodisch wäre die Nachbildung des Geschäftsmodell sinnvoll um es systematisch an die Wirklichkeit zu binden. So simpel wie in Buch dürften sich reale Geschäftsmodelle nicht verhalten. Ein Ansatz wäre per Simulation die Stellen größter Hebelkraft zu finden.

----

Ich meine  Tools und Methoden kratzen nur an der Oberfläche. Das Grundproblem sind die Herrschaftsverhältnisse = Hierarchie in den Firmen (Macht kann nur verhindern, nicht schaffen). Sie sorgen dafür dass Konflikte, eben auch konstruktive, produktive Konflikte, nicht ausgetragen werden, zumindest nicht solange der Herrscher das nicht explizit einfordert. Die intelligentesten, kompetentesten Mitarbeiter sind selten im Dominanz/Macht-orientiertem Management anzutreffen

Mit entsprechender Kultur, Ethik und eher rollen- und situationsbedingter Herrschaft können Konflikte schnell konstruktiv zur Weiterentwicklung genutzt werden. Gerade Ethik halte ich für den Schlüssel für die Kunden-Lieferantenbeziehung. Wenn gewünschte Ergebnisse nicht eindeutig niedergeschrieben werden können (=Vertrag), muss was anderes her. Das kann bei 1:1 Beziehungen ein persönliches Verhältnis sein oder eine wirklich starke, gelebte Ethik, die den bestmöglichen Einsatz für den Kunden verspricht. Ein Versprechen analog des Eid des Hippokrates. Auch rechtlich sehe ich Parallelen zum Arzt, ein Arzt verwaltet das Vermögen des Patienten zu dessen Wohle (Vermögensbetreuungspflicht), so sollten auch Projekte sein!

------

Interessanterweise habe ich Scrum nie als Produktionssteuerung wahrgenommen, sondern Kulturänderung:

• Rollen statt direkter störender Durchgriff des Managements (Beim Fussballspiel sind ja auch nur die Spieler=Projektteam auf dem Feld, alle anderen haben während des Spiels den Mund zu halten)
• Die gesamte Story wird zugelassen, keine Möglichkeit des Managements durch Informationszurückhaltung Macht zu gewinnen.
• Teilhabe an Erfahrung Dritter durch täglichen Austausch.
• Störungsarme Zeiten während des Sprints (bitte kein daily Sprint)
• Iteratives Vorgehen, keine Spec, die versucht hinter den Horizont zu sehen.

Scrum entspricht einer, nur wirklich sehr alten Produktionssteuerung - nämlich der von Henry Ford - mit einer Verschlimmbersserung nämlich großen Batchsizes

Das verstehe ich nicht. Im einem Projekt wird die (eine) Herstellanleitung eines Produkts erarbeitet, was soll da die Batchsize erhöhen?

----

..Mitarbeiterindividuelle Zielvereinbarungen über den Jordan jagen.

Das macht Sinn, aber alle gleich bezahlen ist ungerecht und auch falsch. Wie kann der direkte und indirekte Beitrag (= hilft dem Team Beiträge zu leisten) angemessen bewertet werden? Personalabteilungen schwurbeln seit je her von leistungsgerechter Bezahlung. Ich habe noch keine Firma gesehen, die die Leistung der Mitarbeiter bewerten und messen konnte. 

Ja, kann ich nur bestätigen:  PRINCE2 und Scrum ergänzen sich wunderbar. PRINCE2 dient hierbei als Klammer über ein oder mehrere Scrum-Teams, die in ihren Sprints die mit dem PRINCE2-Projektmanager bzw. Benutzervertreter abgestimmten Arbeitspakete bzw. Produkte entwickeln. Die PRINCE2 Klammer hat zudem den Vorteil, dass selbst in einem etwas unerfahreneren Scrum-Team immer noch eine schützende Hand (Projektmanager) den Prozess begleitet und wie von Reiner schon beschrieben das Team vor der "Politik" beschützt.

Bernhard

Hi Wolfram,

Gratulation, da hast du ja richtig eine Welle losgeschlagen hier!

In einem Punkt muss ich dir auf jeden Fall schon mal Recht geben:  wenn es um die Verkürzung von Projektlaufzeiten geht, dann führt definitiv kein Weg an Goldratt vorbei – seine Ideen sind in diesem Punkt Gold wert!

Was mich jedoch ein bisschen stört – und das wurde ja im Verlauf der Diskussion schon mehrfach angedeutet:  Projekt-Speed ist nicht alles.

Als oberstes Ziel sehe ich nicht die Projektlaufzeit und deren Verkürzung sondern die Steigerung des erwirtschafteten Nutzens durch unsere getätigten Projektinvestitionen – kurze Durchlaufzeiten sind dabei ein lobenswertes Nebenprodukt aber eben nicht der Hauptfokus. Mindestens genauso wichtig sehe ich dabei die Einbeziehung der zukünftigen Anwender in unsere Projekte. Oder anders formuliert: ein Projekt, welches on Time on Budget und genau die definierte Qualität geliefert hat, garantiert mir noch lange nicht, dass wir damit langfristig einen Erfolg haben. Wenn das Zeugs was wir basteln nachher von niemandem gewinnbringend angewendet wird, haben wir in kürzester Zeit einen riesen Haufen Mist produziert. Dann bin ich eher dafür einen Moment inne zu halten und das ganze etwas langsamer anzugehen… Es gibt sicherlich einen Zusammenhang zwischen Projektlaufzeiten und nachhaltigen Unternehmensgewinnen doch zweifel ich an der Richtung  und der Stärke des Zusammenhangs. In meinen Augen ist die Schnittstelle zwischen Projektmanagement und Unternehmensmanagement der entscheidende Punkt: welchen Nutzen bringt dieses Projekt/diese  Veränderung dem Unternehmen? Wie viele Unternehmen wissen das jeweils? Viele Unternehmen scheitern ja schon dabei einen Projektnutzen nach Projektende beziffern zu können – in so einem Umfeld ist ein Forecast dann natürlich eine Luftnummer.

Vor diesem Hintergrund sehe ich die Methodenwelt nach meinen Erfahrungen als Trainer, Berater und Projektleiter ein bisschen anders als dies hier in dieser Diskussion bisher der Fall war. In jedem Projekt und jedem Unternehmen muss doch neu modelliert werden wie die passende Vorgehensweise ist. Klar kann man gewisse Unternehmensstandards schaffen und sollte das Rad nicht immer komplett neu erfinden und sich aus existierenden Standards das nehmen was man für nötig hält. Im Kern geht es jedoch darum, dass man als Projektleiter authentisch bleibt und einen eigenen Weg gefunden hat zu dem man 100%ig steht. Für mich sieht mein Methodenwerkzeugkoffer wie folgt aus:

Für das Teammanagement entnehme ich Ansätze aus dem agilen Umfeld.

Für die Punkte Anforderungsmanagement, Planung, Nutzenfokussierung, Organisation, Risikomanagement, Reporting etc.  kommt das Ganze in einen schlanken PRINCE2-Koffer.

Sobald die inhaltliche Planung abgeschlossen ist und die Termin- und Kostenplanung zum Zuge kommt, darf Goldratt mit Critical Chain die Bühne betreten – und findet dann natürlich im Reporting wieder seinen Platz.

Sobald Veränderungs-Aspekte (Change, Wandel) eine größere Rolle spielen, kommen Ansätze der Programmmanagementmethode MSP hinzu.

That's it.

Als Projektleiter kann man es sich leider nicht immer aussuchen, wenn ich jedoch dürfte, würde ich mir wünschen, dass meine Projekte nach mehrmaliger Prüfung als hochgradig rentabel und sinnvoll eingestuft wurden. Hierzu braucht es ein explizit eingeführtes Portfoliomanagement z.B. nach der Methode MoP. Und wenn ich dann noch unterstützt werde durch ein P3O (Portfolio, Programme und Project Office), dann könnte ich Luftsprünge machen.

Die Realität sieht nur leider meistens etwas anders aus. Als Projektleiter müssen wir nun mal unseren eigenen Weg finden und uns eine Schneise bahnen durch das unvollkommene Umfeld - wer das nicht mag, sollte sich einen anderen Job suchen...

Gruß Bernhard

auch ich kann nur Bestätigen, dass Prince 2 unter den aktuell gängigen Standard ein gutes Fundament bildet. Ich bin PMI zertifizert (hat nicht viel gebracht) und arbeite viel mit GPM (sehr klassisch) - Prince 2 hat IMHO den Fokus auf den richtigen Punkten - empfehlenswert.

ungeachtet dessen ist Prince 2 eben auch nur eine Standard - und Standards haben halt das Problem, dass sie "Standard" sind - wenn man sich also aus der Masser herausheben will und einen Wettbewerbsvorteil realisieren muss weiter über den Tellerrand scahuen - das ist ja auch ein Argument für OpenPM hier sollen Sache diskutiert werden die erst in der Zukunft liegen.

daher auch mein Bestreben Critical Chain bekannt zu machen und auch neue Ansätze wie Reliable Scrum, Ultimate Scrum u.s.w.

das sind übrigends alle mehrfach getestete Konzepte

Hi,

> In einem Punkt muss ich dir auf jeden Fall schon mal Recht geben:  wenn es um die Verkürzung von Projektlaufzeiten geht, dann führt definitiv kein Weg an Goldratt vorbei – seine Ideen sind in diesem Punkt Gold wert!

nur so nebenbei - ein Freund von mir hat in seinem Unternehmen die Ideen (so ein bisschen) umgesetzt. Umsatz +50% und Gewinn verdreifacht. Ein Kunde von uns hat die Projekte jetzt so beschleunigt, dass er innerhalb kürzester Zeit (knapp 6 Monate) sein ganze Projektbacklog abgearbeitet hat - er hat jetzt so viel mehr Kapazität, dass sie jetzt auf die Suche nach neuen Märkten gehen (bei den gleichen Kosten versteht sich) u.s.w. ... also am Schluss echtes Gold (Geld)

> Als oberstes Ziel sehe ich nicht die Projektlaufzeit und deren Verkürzung sondern die Steigerung des erwirtschafteten Nutzens durch unsere getätigten Projektinvestitionen

volle Einigkeit - bei Goldratt heißt dass dann Durchsatz. Das ist das oberste Ziel. Nur drei Gedanken, warum ich hier auf High-Speed rumreite:

• einfach weil ich mich auf einen kleinen Teilaspekt fokussieren wollt - es ist nur ein kleiner Teil <5%
• wenn man nicht alles gleichzeitig Ändern will muss man sich fokussieren - wenn man sich fokussiert muss man auswählen ... ich hab viele Teams/Unternehmen gesehen, die haben zuerst mit Protfoliomanagement angefangen (das ist die richtigen Projekte machen - effizienz und so). Wenn die Projekte zu langsam sind und zu schwer laufen und unpünktlich sind hilft das aber nicht viel - weil ein anderer die Lorbeeren einheimst --> Frust ... wenn man zuerst auf den Menschen und die Führung setzt, dann hat man ein hoch motiviertes Team, das am operativen verzweifelt und wieder --> Frust .... nur so als Gedankenexperiment - immer mit den Reihenfolgen spielen. Wenn man zuerst das High-Speed-Projektmanagement macht und operativ excellent ist ... dann wirken die anderen Maßnahmen um so heftiger (ohne Frust)  nur Lust
• Standards sind nicht so wichtig wie einge extrem schnell operativ wirksame Steuerung - und die wollte ich hier zeigen 
• auf der Speed4Projcts.Net im Labor findet sich alles was man wissen muss zu Business Value Optimierung (http://speed4projects.net/know-how/forschung/toc-portfolio-optimierung/). Das Verrückte ist, auch hier ist die Theory-of-Constraints mit Critical Chain der Schlüssel (sorry ich bin hier ein bisschen nerdig). Aber ich kann auch hier aus der Praxis sagen - dass das extrem mächtig ist. Ich habe das Porftolio über Jahre der 1&1/web.de/GMX/u.a. gemanaged - genau nach dem Verfahren wenn man sich die Unternehmensentwicklung anschaut spricht das schon Bände (auch wenn wir wie alle anderen Unternehmen unsere Herausforderungen haben).

> Für mich sieht mein Methodenwerkzeugkoffer wie folgt aus:

a) der Werkzeugkoffer den du beschreibst ist absolut o.k.

b) wir TOCler haben unser Wissen in mehreren Strategie und Taktik-Bäumen zusammengefasst (http://www.goldrattresearchlabs.com/documents/What%20is%20Strategy%20&%20Tactic%20Trees_by%20Dr%20Alan%20Barnard.pdf). Achtung das ist ganz schön viel Stoff. Aus tausenden! Change Projekten ist hier das Wissen eingeflossen, in welcher Reihenfolge welche Schritte unternommen werden "können" um möglichst schnell ans Ziel zu kommen.

ABER und da sind wir/ich bei dir - man muss wirklich sehr sehr genau schauen, wo steht das Unternehmen gerade, dem man hilft. Wir machen daher 6-10 Tage mit dem Top-Management offsite Workshops/Klausuren, in dem wir diesen S&T-Tree durchgehen und auf das Unternehmen anpassen. Das ist dann der Change-Plan, der abgefahren wird.

Das Ziel ist letzt endlich das zu erreichen, was dich zu Luftsprüngen verleiten würde --> richtige Auswahl der Projekte (strategisches Portfolio), operatives durchsteuern (Critical Chain) ergänzt um alles andere was notwendig ist - Führung, Führung, Führung, Teamentwicklung, Konfliktlösungen u.s.w u.s.w.

Let's go!

cu Wolfram

p.s.: wir nehmen keine Aufträge an, bei denen wir nicht 99%ig sicher sind, dass wir die oberste Führung dahinter haben um genau dieses Optimum zu erreichen - und unsere Pipeline ist voll wir (VISTEM/S4P) suchen aktuell Berater, die hier mitmachen wollen - so viel zum Thema Job suchen