Inhalt : Finger weg von Scrum!

Moin

Seit 20 Jahren arbeite ich nun in Rollen wie Projekt Leiter und seit 10 Jahren als Project-/Program Manager. "...wenn sich Mitglieder im Team befinden, die sich mit dem Command-und-Control-Ansatz engagiert haben." hat aber nichts mit Projekt Management zu tun. In meinen Augen auch nicht mit Menschenführung des 21. Jahrhunderts.

Wenn dieser Ansatz gewählt ist, handelt es IMHO um ein ernstes Problem der Organisation. Ich lebe sehr gut mit dem Wahlspruch "Ein guter PM vertraut seinem Team!", den mir 1993 mein Mentor mit auf den Weg gab. Dieses Vertrauen war bisher immer gerechtfertigt.

Ich denke (was ich sehr oft mache ) das Führung im Projekt Management vor allem auf gegenseitigem Vertrauen beruht. Ist es möglich, dass sich ein wirkliches Team gebildet hat, wird es niemals zu einem "Command-und-Control-Ansatz" kommen. Schade, dass es sich dabei scheinbar um ein  unausrottbares Vorurteil handelt, sobald eine Art von Organisation (wie ein Projekt oder Linie) existiert, dass es gleich Command-und-Control wäre.Seit 50 Jahren sollte das überwunden sein. Na gut: In Deutschland erst seit 30 Jahren

Control nur in dem Sinne, dass das Projekt wie ein Schiff auch gesteuert werden muss. Kontrolle im Sinne von Überwachung und Misstrauen zeichnet schwache PMs aus. Moderne PM greifen aus Situative, Kooperative und Transaktionale Stile in der Menschenführung zurück.

Mir persönlich ist kein PM bekannt, der diese Technik, die hier genannte wurde, noch verwendet... oder verwendet hat!

Glückwunsch, daß diese Erfahrungen nicht gemacht werden mußten. Trotzdem ist Command-und-Control in Projekten real existent. Manchmal wird es als Reflex auf eine Projektschieflage eingeführt, in der zuvor das Projekt "zu lax" angegangen wurde, manchmal traut man dem Team nicht, und führt es gleich bei Projektbeginn ein.

Und für mich ist erst mal der PM dafür verantwortlich. Ob er die Vorgabe oder Unterstützung der Unternehmensorganisation hat, ist für mich da erst mal zweitrangig.

Hallo Rainer,

Scrum hat sich u.a. auch deshalb so stark verbreitet, weil Teams Mitten in aussichtslosen Projekten angefangen haben zu scrummen und dabei gute Ergebnisse erzielten. Folglich kann ich den meisten deiner Punkte nicht folgen.

Zum einen löst die Vorgehensweise nach dem Scrumframework keine Probleme, sondern macht diese schneller offensichtlich. Für das Lösen sind weiterhin die Menschen gefragt.

Zum anderen: Wenn man alle deine oberen Argumente umdreht, dann hätte man die passende Situation um Scrum einzuführen. Richtig? Gleichzeitig hätte man auch ein gut laufendes Projekt. In dieser Situation wird fast jeder Stakeholder erst mal fragen, wozu Scrum überhaupt eingeführt werden soll. Es läuft doch schon gut!

Die oben genannten Punkte stellen definitiv Schwierigkeiten bei der Einführung dar. Schwierigkeiten sind jedoch dazu da, angegangen und gelöst zu werden.

VG, Viktor

P.S.

>> ...wenn der Kunde nicht zur Verfügung steht.

In einem meiner Projekte hatten wir genau diese Situation. Wir haben trotzdem Scrum eingeführt und PO zunächst intern kompensiert. Nach einigen Sprints erkannte der Kunden die Vorteile dieser Rolle und füllte diese Rolle aus. Wäre wir damals deiner These "Finger weg von Scrum" gefolgt, würde das Team heute weiterhin Unmengen an Blindleistung produzieren und alle wären unzufrieden.

Moin Viktor,

Wenn es sich bei dem von Dir angegebenen "Projekt" um das handelt, was ich meine und kenne, war es mehr Produkt Weiterentwicklung und Pflege. Da ist Scrum ideal. Ich habe es selber erst vor kurzem einen Kunden empfohlen, dort effektiver mit Scrum zu arbeiten als mit PM Methoden.

Allerdings ist es korrekt im Rahmen eines Projektes (also definierter Scope, Time und Budget) nicht immer auf Scrum zurück zu greifen. Je weniger fest der Scope ist, desto wichtiger ist ein Vorgehensmodel, welches die Definition des Scopes unterstützt und voran treibt, alsdo das was man heute agil nennt aber eher flexibel meint. Dies ist aber gottseidank nicht immer so.

In der Wartung und Pflege (also Weiterentwicklung) sind viele Rahmenbedingungen so, dass man Scrum verwenden kann. Müsste aber parallel zur Wartung & Pflege das System neu entwickelt werden, wäre schon alleine aus Ressourcen-Gründen Scrum mit den von Roman Pichler definierten Bedingungen schwer umzusetzen.

Aber fehlender Management Support, rote Projekte, mangelndes Interesse der Fachseite und einer der Punkte: Ressourcenmangel aus Zeit- oder Kompetenzkonflikten gehören in vielen Organisationen und in ihnen aufgesetzten Projekten leider zum Alltag. Über die gesamte Laufzeit interdisziplinäre Teams mit Vollzeiteinsatz zu haben nenne ich in Deutschland einen Luxus. Meist sind die Mitarbeiter anteilig dem Projekt zur Verfügung gestellt, stehen nicht für die gesamte Projektlaufzeit zur Verfügung und sind Diener mehrerer Herren. In den Bedingungen dann zu Scrummen ist schlicht unmöglich. Nach Pichler und und Reiner Eschen . Und auch nach meiner Meinung.

Daher: Vorgehen muss zur Organisation und auch zur Kultur (auch der der Mitarbeiter) passen. Und auch wenn ich mit Reiner nicht oft einer Meinung bin, denke ich schon, dass er hier, vielleicht ungewollt , doch recht hat.

Aber man kann auch einen Artikel schreiben: Finger weg von Projekt Management! Auch da gibt es viele Punkte zum waren...

Btw: Wenn diese von Pichler gesetzten Bedingungen erfüllt sind, muss man schon ein Idiot sein, ein Projekt vor die Wand zu fahren.

"Meist sind die Mitarbeiter anteilig dem Projekt zur Verfügung gestellt, stehen nicht für die gesamte Projektlaufzeit zur Verfügung und sind Diener mehrerer Herren."

Diese Erfahrung habe ich auch schon oft gemacht. Ich überlege immer wieder, ob es Sinn macht in solchen Situationen die Anstrengung zu unternehmen dem Umstand entgegenwirken. Ich finde, in solchen Umgebungen zu arbeiten ist sehr schwierig, durch das ausführen von Aufgaben aus mehreren Projekten sind die Mitarbeiter ab einem gewissen Umfang sowieso überfordert und die Rüstzeiten nehmen enorm zu. Wäre nicht der "richtige(re)" Weg, lieber Prioritäten zu setzen und die Aufgaben sequentieller abzuarbeiten Sprich, wir machen jetzt Projekt 1 und 2 fertig, danach Projekt 3, dann Projekt 4 und 5. Anstatt in allen 5 Projekten gleichzeitig zu arbeiten? Meine Erfahrung ist, dass bei zu vielen Aufgaben parallel der Output sowieso runtergeht, analog dazu die Mitarbeitermotivation. 

Man könnte natürlich auch argumentieren, dass ein "gutes" Team umgekehrt sowieso dafür sorgen wird, das anders gearbeitet wird. Selbstorganisierte Teams mit Backlogs und klaren Prioritäten kommen vielleicht gar nicht in eine solche Situation?

Vielen Dank für Deinen Kommentar. Leider gehst Du davon aus, daß man Scrum nur zur Optimierung von Projekten in Schieflage einsetzen kann. Scrum hat aber eigentlich das Ziel "High-Performance-Teams" zu schaffen. Damit sind Projekte in Schieflage, die es nicht schaffen, die im Artikel von mir erwähnten Umgebungsparameter zu setzen (also das Scrum-Framework komplett abzubilden) keine Scrum-Projekte.

Sicher wird man Verbesserungen erreichen, aber der Begriff "Scrum" kann hier nicht verwendet werden. Da immer etwas vom Scrum-Framework fehlt, können wir alternativ von Ken Schwaber's "ScrumBut" sprechen. Frei nach dem Motto: "We do Scrum, but we do not...".  

Wichtig bei Scrum ist, daß das Framework nur das beschreibt, was absolut notwendig ist, um das Ziel zu erreichen. Wenn man etwas wegläßt, wird das Ziel verfehlt.

Das ist natürlich schwer zu verstehen, wenn man bisher keine Vorstellung davon entwickeln konnte, was tatsächlich ginge. Da ist jede Verbesserung schon ein Plus. Jeff Sutherland beschreibt es ungefähr so: ausgehend von einem klassisch gemanagten Projekt bei einer Leistungssteigerung von mindestens 30% entspricht einem ScrumBut. Alles ab 200% bis 800% entspräche dann Scrum. Da Boris Gloger von 200%-300% Steigerung innerhalb der ersten Sprints spricht, sehe ich das derzeit als den realistisch anzupeilenden Korridor an.

Der letzte Satz bringt es auf den Punkt. Wenn man Scrum richtig implementiert (also alle Vollzeit in einem Projekt), dann verbrenne ich auch meine Teams nicht und bin auch nicht suboptimal unterwegs.

Es stellt sich natürlich die Frage, wie das Management die Sache sieht. Kurzfristig ist eine Doppelrolle der Teammitglieder oder eine prozentuale Verteilung ihrer Kapazität auf verschiedene Projekte ein Gewinn. Ich erwirtschafte einen höheren Gewinn.

Aber es reibt die Teams mittelfristig auf und dann zahle ich dafür. Erwartungsgemäß mehr, als das was ich vorher an Gewinn erwirtschaftet habe. Alleine einen wichtigen Know-How-Träger wegen Demotivation zu verlieren ist schon sehr teuer: Einarbeitung, Neu-Aufbau des verloren gegangenen Know-Hows, neues Team-Building, ...

Dann kommt in der IT z.B. noch hinzu, daß entsprechende Leute kaum noch zu finden sind, oder sehr teuer eingekauft werden müssen .

"Finger weg von Projektmanagement": Wäre klasse, wenn Du dazu mal was schreiben würdest. Der Umkehrschluß wäre das Projekt nicht anzufangen, richtig?

Moin,

Das Problem liegt in der Organisationskultur in Deutschland, vielleicht auch in Mitteleuropa. Linienmananger wollen nicht die vermeintliche Disziplinargewalt abgeben... oder können es nicht.

Gemäß dem Matrixmodel PMI bin ich der festen Überzeugung, dass Projekte (egal welches Vorgehensmodel) erst ab balanced matrix, besser ab strong matrix funktionieren können. Derart in die Organisation eingebundene Projekte haben dann auch eine Mindestgröße, die eine Vollzeit Verfügung zu einem Projekt zulassen.

Allerdings bin ich nicht immer der Meinung, dass ich über die gesamte Laufzeit interdisziplinär besetzte Team brauche. Es kann zwar sein, dass ein Mitarbeiter konsequent dem Projekt zur Verfügung steht, aber in verschiedenen Rollen, z.B. Vom Requirement Engeneer über Busines Analyst bis zum Tester und Change Manager.

Aber zu verstehen ist es nicht, dass ein Einsatz über mehrere Projekte nicht nur die Mitarbeiter übermäßig belastet, sondern auch die Effizienz stark herunter setzt und die Fehlerhäufigkeit erhöht.

Selbstorganisierte Teams mit Backlogs und klaren Prioritäten kommen vielleicht gar nicht in eine solche Situation?

Nein... sie werden erst gar nicht selbstorganisiert Und selbst wenn: Die Teammitglieder sind immer noch in der Linie integriert und damit ihrem Vorgesetzen untergeordnet. Über sticht unter. Es braucht dort einen (sorry Rainer) starken PM, der seinen Leuten den Rücken frei hält und für die Zuordnung sorgen kann ...

Moin Rainer,

Ich schaue mal nach. Ich denke, ich habe dazu schon was geschrieben

Aber Ja: Ein Projekt (egal welcher Art) ist nicht immer das geeignete Vehikel, um ein Vorhaben um zu setzen.

Wie ich Viktor geschrieben habe, ist Scrum z.B. ideal um Systeme weiter zu entwickeln. Grade wenn es stark dynamische Systeme sind, wie Web-Systeme, die einmal in der Produktion sind. Hier hat Scrum mit den kurzen Sprints und dem schnellen time2market extreme Stärken (wenn die Rahmenbedingungen stimmen).

Andere Vorhaben sind viel zu klein um sie als Projekt zu managen, andere Vorhaben sind eher der Regelbetrieb und werden versucht als Projekt zu managen.

Hallo Rainer,

>> Vielen Dank für Deinen Kommentar. Leider gehst Du davon aus, daß man Scrum nur zur Optimierung von Projekten in Schieflage einsetzen kann. Scrum hat aber eigentlich das Ziel "High-Performance-Teams" zu schaffen. Damit sind Projekte in Schieflage, die es nicht schaffen, die im Artikel von mir erwähnten Umgebungsparameter zu setzen (also das Scrum-Framework komplett abzubilden) keine Scrum-Projekte.

Wieso gehe ich davon aus, dass Scrum nur zur Optimierung von Projekten in Schieflage eingesetzt wird? Das habe ich weder behauptet noch angenommen.

Außerdem ist es kein Ziel von Scrum High-Performance-Teams zu schaffen. Ich kenne auch keine Kunden, die für eine Veränderung (und Einsatz von Scrum ist definitiv eine) Geld ausgeben, um High-Performance-Teams zu schaffen. Was Kunden wollen ist eine Verbesserung der Projektergebnisse, sei es Time-to-market, Qualität, Effizienz, Zufriedenere Stakeholder, etc. Scrum kann dabei helfen, diese Ziele zu erreichen. Ein High-Performance-Team ist ein sehr wichtiger Faktor um Verbesserungen zu erreichen, es ist jedoch ein Mittel (wobei ich "Mittel" an dieser Stelle wertneutral verwende) und nicht das Ziel.

Wenn man Scrum als Framework begreift, um Verbesserungen zu erzielen (mal abgesehen von der Prozentzahl), dann ist es grundsätzlich sinnvoll in jeder Projektsituation, den Einsatz des Framework oder Teile davon, zu prüfen. Auch dann, wenn die Verbesserung "nur" 15% beträgt. Vielleicht heißt es dann ScrumBut, aber so what? Geht es im Projektmanagement um korrekte Begriffe oder geht es um das Projektergebnis?

>> Alles ab 200% bis 800% entspräche dann Scrum. Da Boris Gloger von 200%-300% Steigerung innerhalb der ersten Sprints spricht

Ich kenne diese Zahlen und finde es mittlerweile ganz lustig. 800% im Vergleich zu was? Zu einem planungsgetriebenen Projektmanagement? D.h. das ein 100PT-Projekt mit gleichen Personen, mit gleichem Scope, etc. dann mit 12,5 PT realisiert wird? Oder mit 25PT? Dieser Beweis - Top klassischer PM vs. Top Scrummaster - muss noch erbracht werden. Oder heißt es dann "Steigerung, but"?

VG

Viktor

Natürlich ist es das Ziel High-Performance-Teams zu schaffen, da Scrum darauf ausgelegt ist, die Leute, die wirklich den Mehrwert für das Projekt erbringen, optimal zu unterstützen. Aber wenn 15% reichen, will ich das nicht weiter vertiefen .

Hallo Rainer,

>> Aber wenn 15% reichen, will ich das nicht weiter vertiefen.

Naja, was ist denn die Alternative? Gemäß dem Beitragstitel wäre die Alternative nichts zu verbessern, d.h. kein Fortschritt. Anders formuliert: Stillstand!

Eine konsequente Verbesserung um 15% in allen fünf Dimensionen - Zeit, Budget, Scope, Qualität, (Kunden-)Zufriedenheit - ist ein großer Schritt nach vorne. Oder nicht?

>> Natürlich ist es das Ziel High-Performance-Teams zu schaffen, da Scrum darauf ausgelegt ist, die Leute, die wirklich den Mehrwert für das Projekt erbringen, optimal zu unterstützen.

Nee, sorry, definitiv nicht. Um High-Performance-Teams zu bilden gehört deutlich mehr dazu als "nur" Scrum richtig und vollständig zu implementieren.

Schaffung von High-Performance-Teams beginnt bei einer konsequenten Personalauswahl, Schaffung einer guten Teamstruktur, Rollenklärung, Professionalisierung der Feedbackkultur hinsichtlich Angemessenheit und Wirkungsbewusstsein (und mit Feedbackkultur meine ich deutlich mehr als nur "blaming stops learning") und und und. Zu allen diesen Punkten liefert Scrum kaum bis keine Anhaltspunkte.

Ein hervorragendes Buch zum Thema "High-Performance-Teams", welches viele Punkte enthält, die unabhängig einer konkreten Vorgehensweise Gültigkeit haben: http://www.amazon.de/High-Performance-Teams-f%C3%BCnf-Erfolgsprinzipien-F%C3%BChrung-Zusammenarbeit/dp/3791022938/ref=sr_1_1?ie=UTF8&qid=1336596069&sr=8-1

VG

Viktor

P.S.

Ich würde mich freuen, wenn es zu meiner folgenden Anmerkungen, Antwort/Beispiel/Feedback gibt. Mich interessierst wirklich, was mit 800% Verbesserung nun gemeint ist.

>>800% im Vergleich zu was? Zu einem planungsgetriebenen Projektmanagement? D.h. das ein 100PT-Projekt mit gleichen Personen, mit gleichem Scope, etc. dann mit 12,5 PT realisiert wird? Oder mit 25PT? Dieser Beweis - Top klassischer PM vs. Top Scrummaster - muss noch erbracht werden.

Warum soll ich das noch weiter diskutieren, wenn Deine Kommentare mir zwischen den Zeilen sagen, daß Dich eine andere Sichtweise nicht interessiert.

Hallo zusammen,
hallo von einem openPM-Newbie!

Nachdem ich in letzter Zeit immer öfter über diese Seite - im Positiven - "gestolpert" bin, habe ich mich nun mal angemeldet ... und bin direkt über eine "knackige" Headline gestolpert:

"Finger weg von Scrum!"

und dann auch noch "...wenn das Projekt bereits in Schieflage ist."

Als ein langjährig bekennender und überzeugter Agile Coach und Scrum Master kann ich genau dem nicht zustimmen. Gerade die extreme Transparenz (wenn gewollt), die (durchaus intensiv) kurzen Feedback-Schleifen (z.B. bei "1-Tages-Sprints") und ein Scrum-"Risk Management" ermöglichen gerade im Firefighting das für ein Projekt Machbare auch "zu machen".

Genau dies durfte ich vor kurzem als "firefightender" Scrum Master in einem zwei-stelligen Mil. Projekt mal wieder zeigen - erfolgreich.

Vielleicht steht dies oder ähnliches bereits in den vorhergehenden Kommentaren ... die ich mir auf jeden Fall in den nächsten Tagen intensiver durchlesen werde ...

"...wenn das Projekt bereits in Schieflage ist, bietet auch oder gerade Scrum (bzw. agiles Vorgehen) mit die besten Möglichkeiten das Machbare zu schaffen ..."

Soweit mein erster Beitrag (möglicherweise nicht der letzte - keine Drohung ;-)

Viel Erfolg wünsche ich openPM und allen Beteiligten.

CU
Boeffi - boeffi.net

Willkommen bei openPM, Boeffi! 

Übrigens müssen wir nicht alles in Kommentaren diskutieren: es ist durchaus erwünscht einfach den Artikel selbst anzupassen.

Moin Marcus,

das Anpassen des Artikels, vielleicht noch durch mehrere User, würde gerade bei diesem diskussionswürdigen Beitrag von Rainer dessen Intention verfälschen.

Das wäre sehr schade, denn Rainer schreibt etliches Interessantes, was es aber auch wert ist zu kommentieren und diskutieren.

Moin

ich teile die Meinung, die Rainer in diesem Punkt vertritt. Und das bedeutet schon sehr viel. Bei Projekten in Schieflage auf neue Methoden zu setzen, statt die bestehenden funktionsfähig zu machen, bedeutet einen zum Startpunkt des Projekts nicht eingeplanten Mehraufwand und trägt zu Verunsicherung der Teammitglieder bei.

Die von Dir angesprochenen Themen wie kurze Feedbackschleifen (für mich also controlling und lesson learned) als auch Transparenz (sollte immer gewollt sein) sind auch im Rahmen von anderen Methoden und Vorgehensmodelen  möglich. Dies umzusetzen ist in meinen Augen ein Führungsfaktor und kein Methodenproblem.

Jens _{(Project firefighter )}

Moin Rainer,

ich verstehe aber Deine Prozente auch nicht!!?? :-0

Wenn Du von 800% redest, würde das in einem Scrum-Projekt ja einen CPI und SPI von 2 - 8 bedeuten.

Also, wenn ich aus einem 8 Mio Projekt mit einem CPI von 1,12 rauskomme, habe ich fast 850.000,- eingespart. Damit ist das Projekt eine Heldentruppe. Erkläre mir das mit einem CPI von 8!!!!????

Danke Jens von Gersdorff für's Aufpassen! Du hast vollkommen recht: Der Artikel ist eine Meinungsäußerung, die unverändert stehen bleiben soll. Ich war heute früh wohl noch nicht ganz wach. Wichtig wäre mir, dass am Ende der Diskussion auch irgendein Mehrwert, eine gemeinsame Empfehlung, etc. entsteht. Deswegen habe ich zur Zusammenarbeit aufgerufen. Diese Seite ist aber in der Tat nicht der richtige Ort. Da brauchen wir eine neue Seite.

Servus Jens,

>> Bei Projekten in Schieflage auf neue Methoden zu setzen, statt die bestehenden funktionsfähig zu machen, bedeutet einen zum Startpunkt des Projekts nicht eingeplanten Mehraufwand und trägt zu Verunsicherung der Teammitglieder bei.

Das würde ja bedeuten, dass die am Anfang gewählten Methoden die richtigen waren und lediglich nicht konsequent oder falsch eingesetzt wurden. So eine allgemeine Aussage ist schwierig, es wird sicherlich solche und solche Projekte geben (richtige Methodik gewählt, falsch eingesetzt und falsche Methodik gewählt).

Und wenn das Projekt in Schieflage ist, dann ist es bereits in Schieflage und wird voraussichtlich das was am Anfang geplant war (Budget, Scope, Time, Quality) so nicht mehr erfüllen. Andernfalls wäre es nicht in Schieflage, sondern im Rahmen der normalen Projektabwicklung.

Bei solchen Projekten ernsthaft in Erwägung zu ziehen, sinnvolle Elemente aus Scrum einzusetzen (z.B. Transparenz, z.B. Klare Priorisierung, z.B. klare Verantwortung, etc.) bietet in meinen Augen immer einen Mehrwert. Ein "per se" Ausschluss greift nun mal zu kurz.

VG, Viktor

Moin Viktor

Das würde ja bedeuten, dass die am Anfang gewählten Methoden die richtigen waren und lediglich nicht konsequent oder falsch eingesetzt wurden. So eine allgemeine Aussage ist schwierig, es wird sicherlich solche und solche Projekte geben (richtige Methodik gewählt, falsch eingesetzt und falsche Methodik gewählt).

Leider ist es meine Erfahrung, dass oft Metoden nicht richtig eingesetzt werden, wenn Projekte Schieflagen haben. Das ist leider so. Ansonsten gäbe es auch keinen wirklichen Grund für einen Methodenwechsel Es müssen also Gründe sein in der Methodik oder seiner Umsetzung. Und meist, wenn ich rote Projekte übernommen hatte, war es entweder Keine Methode (PM by reaction) oder keine Umsetzung (PM without skills)

...Scrum einzusetzen (z.B. Transparenz, z.B. Klare Priorisierung, z.B. klare Verantwortung, etc.) bietet in meinen Augen immer einen Mehrwert....

Stimmt, weil Priorisierung, Verantwortung und Transparenz auch Teile des Ausser-Scrum Projekt Managements sind. Wenn diese Punkte nicht eingehalten werden, ist es kein Methodenfehler sondern ein Umsetzungsfehler.

Es geht auch nicht darum, was am Anfang geplant war, sondern um die momentane Baseline (inkl. Changes, etc.)

SCRUM für Projekte in Schieflage.....

Nun, ich sehe das schon so, dass man Projekte in Schieflage mit SCRUM retten kann, aber einige Faktoren müssen schon auch passen. 2010 hatte ich ein Projekt in Schieflage auditiert. Neben klassichen handwerklichen Fehlern kam folgendes zu Tage:

a) Die vier Projektmitglieder litten unter Command-and-Control

b) die drei Russen in der Ukraine waren nicht eingebunden

c) Das Management beim Kunden (IT und Fachbereich waren sich ihrer Verantwortung nicht bewusst

Unsere Empfehlung (Kurzform) damals war:

1. ) Das Projekt wird in den Räumen des beauftragten IT-Dienstleisters durchgeführt.
2. ) Das Projekt bekommt die benötigte Infrastruktur zur Kommunikation (Web-Cam, Web-Whiteboard, JIRA etc. etc.)
3. ) einmal die Woche Lenkungsausschuss Task-Force
4. ) IT und Fachbereich priorisieren und treffen Entscheidungen

Das war die Nagelprobe. Ergebnis: Die Vorstellung der Ergebnisse des Projektaudits wurde vom Auftraggeber von drei Stunden auf eine Stunde reduziert. Der Kunde hat das Projekt dann eingestellt.

Meiner Erfahrung nach sind die Mitarbeiter auf Kundenseite immer noch in der Linie tätig. Die Zeiten für die eigentliche Projektarbeit ist hier sinnvoll zu planen. Das sind Rahmenbedingungen die entsprechend gewürdigt werden müssen. Ich wehre mich da immer, bei pauschal-Aussagen "der Termin muss aber gehalten werden"......

Moin Reiner,

Das Problem ist dabei aber auch, dass die Mitarbeiter von zwei Seiten Anweisungen bekommen... und dies ist immer ein Dilemma. Wie sehr man es auch würdigt 

Du wirst in etablierten Organisationen (Kunden) keine Verädnerung herbeiführen können, du wirst es nur "würdigen" können: als Risiko ausweisen und bei Risikoeintritt sagen "hatte ich schon immer gewusst/gesagt", Maßnahmen aufzeigen, usw.. Das Management/LA wird darüber hinweggehen und weitermachen (in 90% aller Fälle). Der PL hat siene Hausaufgaben gemacht und die Verantwortung zurückgegeben. Taht's it. Das meinte ich mit "würdigen".

Hierauf gibt Eliyahu Goldratt mit seinem Critical-Chain-Ansatz die Antwort: vereinfacht ausgedrückt verlangsamt vermeintlich parallele Projektbearbeitung die Durchlaufzeit eines Projekts. Dieses als schädlich bezeichnete Multitasking führt dazu, dass der Nutzen aus den Projekten später zur Verfügung steht. Der Durchsatz steigt sobald ein Projekt nach dem anderen bearbeitet wird - erst Nr. 1, dann Nr. 2, dann Nr. 3. Gleichzeitig macht das die Mitarbeiter zufriedener - so meine Erfahrung. 

Ich finde es gut beschrieben in "Die kritische Kette" (siehe hier bei amazon.de).