Es ist schwierig, auf einer unterschiedlichen Erfahrungsbasis zu argumentieren. Es ist sicher so, dass die Skalierbarkeit von Scrum und der Aufwand zum managen von Abhängigkeiten im Scrum-Werkzeugkasten unterrepräsentiert ist. Dies ergibt sich alleine aus der Teamgröße und aus konkreten Praxiserfahrungen.

Beispielsweise tut man sich in der Praxis schwer, technische Abhängigkeiten durch den Product Owner managen zu lassen. Insbesondere, wenn es sich um ein Projekt >10000PT Aufwand handelt. Hier wiederum hat das “klassische” Critical Chain PM das notwendige Handwerkszeug.

Es geht nicht darum, dass eine Methode besser als die andere ist, sondern zu erkennen, wann man welche Methode einsetzt. Und diese Wissen scheint mir vom Autor dieser Kritik nicht schlüssig dargestellt.

ehrlich gesagt ist das eine “Ente”, es gibt derzeit keinen Beschluss, diese Zertifizierung nach der Pilotierung (der Inhalte und des Verfahrens)in Polen auch wirklich umzusetzen. Dies muss bei der IPMA erst durch das Council of Delegates genehmigt werden, dieser Beschluss kann ggf. im September in Baku kommen, dies ist aber noch ungewiss…

http://de.wikiquote.org/wiki/Statistik

Die Einrichtung eines “CR-Wasserkopfs” sägt für Mitglieder agiler Teams an den Grundlagen des Selbstverständnisses und bemüht sich Symptome zu bereinigen und nicht ein mögliches Grundproblem anzugehen. Ich vermute als Grundproblem in dem Artikel die Sicht, dass ein Product Owner den Aufgaben nicht gewachsen ist bzw. viele Dinge nicht Teil seiner Rolle sind. Der Product Owner trägt große Verantwortung bei Scrum und die transparente Kommunikation mit dem Auftraggeber ist nur ein Teil seiner Rolle.

Ein paar Zitate aus dem Scrum Guide 2011 zur Illustration:

• “Der Product Owner ist für die Maximierung des Wertes des Produkts und der Arbeit, die das Entwicklungs-Team verrichtet, verantwortlich.”
• “Die Sicherstellung der Wertschöpfung des Entwicklungs-Teams.”
• “Die Sicherstellung, dass das Product Backlog für alle Beteiligten einsehbar, transparent sowie klar ist.”

Der Job der Verantwortung des Product Owners endet nicht damit Features ins Backlog bringen sowie zu priorisieren und die Transparenz nicht damit, dass man sich in einem Tool einloggen kann. Die Einbindung der Stakeholder und das Aufzeigen von Auswirkungen von Entscheidungen ist ebenfalls Job des Product Owners.

Wenn der technische Projektleiter analoge Fehler macht wie die als Schwächen agiler Methoden aufgeführten Punkte im Artikel, geht auch ein klassisches Projekt ebenso baden. An dieser Stelle scheue ich mich weiter in die Detaildiskussion zu gehen da ich dann anfangen würde eine Scrumkurs niederzuschreiben.

Anstatt Scrum invasiv verbessern zu wollen anstatt Scrum im Sinne von Scrum einzusetzen gilt es wirklich fehlende Teile von Scrum zu ergänzen. Hierzu zähle ich ensprechend des PMBOK® Guides z.B. Beschaffungsmanagement. In einer länglichen Postingserie im Blog habe ich vor Jahren einmal die Wissensgebiete des PMBOK® Guides vor diesem Hintergrund auseinandergenommen. Heute stehe ich auf dem Standpunkt Projektmanagement wie einen großen Borgwürfel zu betrachten aus dem Scrum einen guten Teil herausbeisst. Scrum verbessern zu wollen führt nicht zum Erfolg, von Scrum nicht besetzte Gebiete einer Landkarte mit Projektmanagement zu managen passt wiederum.

“Woher kommt also nur diese – teils emotionale – Ablehnung der für mich so trivialen Aussage, dass ein Projekt nur dann ein Projekt ist, wenn es einen Buiness Case hat?”

Das ist gar nicht trivial. Und auch nicht emotional. Nur realistisch.

Der Business Case ist zum Popanz geworden, der vielen den Blick auf die einfache Projektrealität verbaut: Manche Projekte sind Business-Case-getrieben, manche nicht.

“Überleben ist nicht freiwillig.” (W. Edwards Deming)

Dein Beispiel: “Warum nur produzieren Textilunternehmen in Indien? Eben deswegen, weil das Projekt: “Verlagerung der Produktion in Länder ohne gesetzliche Vorschriften für den Schutz von Arbeitnehmern und Umwelt” einen besseren Business Case hat als “Erfüllen aller gesetzlichen Vorgaben am Produktionsstandort Deutschland.”” beschreibt ja ein Business-Case-getriebenes Outsourcing-Projekt, das Management hat Wahlmöglichkeiten.

Nun stelle Dir doch mal vor, Edeka würde beschließen, deutsche Kunden mit Supermärkten in Indien zu bedienen, weil die Bedingungen am Standort Deutschland so schlecht geworden sind. “Die Deutschen können ja zum Einkaufen nach Indien fliegen.”

Diesen Business-Case gibt es nicht, das Management hat keine Wahlmöglichkeiten.

Edeka muss also hiesige gesetzliche Vorgaben einhalten, und wenn dafür ein Projekt aufgesetzt werden muss, dann wird das auch gemacht.

Das ist auch nicht Ergebnis einer Abwägung, sowenig wie Du im Auto, wenn vor Dir ein Kind auf die Straße läuft, abwägst, was ökonomischer ist, abzubremsen oder das Kind zu überfahren.

Es ist natürlich viel einfacher, Menschen auf den Status eines Homo Oeconomicus zu reduzieren. Ist aber dennoch falsch.

Vielleicht liegt das Problem ja auch darin begründet, dass die Prozesse und Mechanismen der Projektauswahl, um die es hier eigentlich gaht, den meisten, die mit Projektmanagement befasst sind, völlig fremd sind.

Aus meinen Seminaren weiß ich, dass kaum ein Projektmanager Stratigic Scoring, NPV, IRR, Payback Period etc. berechnen und bewerten kann, und kaum einer hat sich je mit Dingen wie Marktfenstertheorie, NIMBY-Effekt etc. beschäftigt, die alle zu einen Business Case gehören können.

Ist ja auch verständlich: Die allermeisten Projektmanager werden erst dazu geholt, wenn die Projektauswahl bereits gelaufen ist.

Vielleicht wäre die Diskussion fruchtbarer, wenn wir vorher die Basics klären würden.

“Was mir in seiner Definition fehlt, ist der Hinweis auf eine zeitliche Begrenzung. Ohne zeitliche Begrenzung lässt sich Projektmanagement nicht von Unternehmensmanagement unterscheiden. Einmal ist jedes Projekt beendet (und wenn es auch abgebrochen wurde).”

Irgendwann ist jeder unternehmerische Prozess beendet. Angesichts der Unmöglichkeit, etwas für die Ewigkeit zu erzeugen (vielleicht von ein paar traditionell christlichen Ansätzen zum ewigen Leben abgesehen), sehe ich darin kein echtes Unterscheidungskriterium.

VW baut den 6er Golf nicht als Projekt, sondern als betriebliche Produktionstätigkeit seit 2009.

Geplant ist aber auch, ihn um 2015 durch den 7er abzulösen, der bereits in der Entwicklung (Projekt) ist.

Außerdem steckt im Wort “neu” immer auch das Wort “temporär” mit drin. Die Freude am Neuen, aber auch die Angst davor, und die damit verbundene erhöhte Aufmerksamkeit werden irgendwann nachlassen.

“Punkt 4) kann ich nicht immer nachvollziehen. Gerade Integrations- und Migrationsprojekte haben keine Staged Deliverables.”

Staged Deliverables sind natürlich keine Merkmale eines Projekts.

Ihr ex- oder impliziter Ausschluss ist für mich aber ein Merkmal einer unzureichenden Beschreibung dessen, was ein Projekt ist.

“Eigentlich weiss der Kunde erst am Schluss, was er eigentlich genau will, weil er während des ganzen Projekts lernt.”

Das würde ich gerne verallgemeinern. Das gilt nämlich zu einem gewissen Grad für alle Projektbeteiligten und -betroffenen, den Stakeholders. Ich habe noch eine andere Definition, nämlich die eines gemanagten Lernprozesses.

Was Ihre Aussage zu unserem Wahrnehmungsapparat angeht, sind wir auf jeden Fall zusammen.

Übrigens – manchmal zum Glück. Hätte Columbus nicht eine falsche Vorstellung vom Durchmesser der Erdkugel gehabt, und dann noch das unglaubliche Glück, dass zwischen Spanien und dem damals unerreichbar weiten Asien ein ganzer Kontinent mit vorgelagerten Inseln lag, und dass er auch noch genau auf einer dieser Inseln gestoßen ist, Amerika wäre vielleicht heute noch nicht entdeckt.