Projekte oder das Management von Vorhaben

Projekte oder das Management von Vorhaben

Posts 11-12 of 12
  • Henning Zeumer
    Henning Zeumer    Premium Member   Group moderator
    The company name is only visible to registered members.
    Re^8: Schlechte Erfahrungen mit agilen Methoden?
    Kein WIderspruch von meiner Seite! Aber ohne jetzt Scrum im Detail der Vorgehensweise hier erörtern zu wollen:
    beim klassischen Auftrag erhalte ich als Auftraggeber, was und wie ich spezifiziert habe und kann Änderungen über Change Requests für zusätzliches Geld "kaufen". Bei Scrum lege ich pro Sprint fest, was ich danach haben möchte.

    Das macht mich flexibler gegenüber Änderungen, und ich kann dann aufhören, wenn es mir genügt. Wie lange bzw. wieviele Sprints das dauert (und wieviel es damit kostet), kann ich aber nicht von vornherein wissen. Ich kann nur irgendwann einmal stop sagen, wenn's zuviel Zeit oder Geld wird, was aber noch nicht heißt, dass ich dann auch all das in Gänze habe, was ich ursprünglich mal an Scope haben wollte. Das ist halt bei Festpreis-Projekten nach klassischer Kalkulation meist anders, zumindest wenn sie sauber geplant und kalkuliert werden...

    Wie gesagt, beides hat seine Vorzüge und Nachteile. Es kommt auf eine intelligente Kombination beider Ansätze an!

    Viele Grüße
    Henning Zeumer
  • Hans-Peter Korn
    Hans-Peter Korn    Premium Member   Group moderator
    The company name is only visible to registered members.
    Re^9: Schlechte Erfahrungen mit agilen Methoden?
    Henning Zeumer schrieb:
    Wie lange bzw. wieviele Sprints das dauert (und wieviel es damit kostet), kann ich aber nicht von vornherein wissen. Doch, ich nutze ja zu Beginn des Projekts den dann vorliegenden "Backlog" als Basis für eine Gesamtschätzung. Ich verbreite aber nicht die "Hoffnung" dass das ein gesicherter Wert ist. Es ist eine Schätzung.

    Ich kann nur irgendwann einmal stop sagen, wenn's zuviel Zeit oder Geld wird, ... oder bereits früher und billiger als erwartet eine Lösung vorliegt, die bereits gut genug ist.
    was aber noch nicht heißt, dass ich dann auch all das in Gänze habe, was ich ursprünglich mal an Scope haben wollte. Mit SICHERHEIT wird beim Agilen Vorgehen am Ende eines Projekts etwas ANDERES vorliegen, als das, was zu Projektbeginn im Product Backlog formulieret wurde. Es wird nämlich etwas vorliegen, was NOCH BESSER dem Kundenbedürfnis entspricht, als es der Kunde zu Projektbeginn formulieren konnte.
    Wenn jedoch trotz Agiiltät genau das vorliegt, was zu Beginn bereits im Scope war, dann wäre kritisch zu hinterfragen, ob denn dann das agile Vorgehen tatsächlich korrekt genutzt wurde oder ob es sich um eine von Anfang an in aller Breite und Tiefe spezifizierbare Sache handelte - und das agile Vorgehen daher eine unangemessene Erhöhung der PM-Komplexität mit sich brachte. Und dann durchaus zu einer schlechten Erfahrung mit agilen Methoden führen kann.

    Das ist halt bei Festpreis-Projekten nach klassischer Kalkulation meist anders, zumindest wenn sie sauber geplant und kalkuliert werden... ... sofern sie bereits zu Beginn in aller Breite und Tiefe planbar sind, es sich also um keine komplexen sondern um simple oder komplizierte Aufgaben handelt.

    Bezüglich "Vetragsmodelle" bei Agilität ist das lesenswert:
    http://www.coldewey.com/publikationen/kolumne/leanDevelopmen...
    auf Seite 85, rechte Spalte und der "Agile Festpreis" in: Bernd Oestereich / Christian Weiss / Oliver F. Lehmann
    "APM – Agiles Projektmanagement"