Gescheiterte Software-Projekte

Vor kurzem ist wieder einmal der CHAOS Report 2009 der Marktforschungsfirma Standish erschienen. Darin wird erfasst, wie viele IT-Projekte im vergangenen Jahr (USA) erfolgreich abgeschlossen wurden, problembehaftet waren (Zeit, Budget, Nutzen) oder gar gescheitert sind. Nun mag man angesichts der Methodik und der damit verbundenen Aussagekraft den Nutzen dieser Studie gerne anzweifeln. Aber rein gefühlsmäßig spiegeln sie die Wirklichkeit durchaus wieder:

Lediglich 32 Prozent aller Projekte wurden erfolgreich abgeschlossen. 44 Prozent waren problembehaftet und damit stark gefährdet und immerhin 24 Prozent scheiterten, beziehungsweise wurden eingestellt.

Es wäre schön zu wissen, warum genau die vielen Projekte gescheitert oder in Probleme gelaufen sind. Liegt es etwa an den Projektmanagern? Oder doch an den Umständen? Die Wirtschaftskrise jedenfalls kommt nur begrenzt als Sündenbock in Frage. In den Vorjahren waren die Zahlen ähnlich, 2006 beispielsweise sind beispielsweise sogar 46 Prozent der Projekte gescheitert.

Allerhand agiles und ein paar Links

Es wird wieder einmal Zeit zum Kollegen Andreas Heilwagen zu schauen. Auf seinem Blog beschäftigt er sich ausführlich im Rahmen einer Serie mit dem agilen PMBOK4 Guide. Wie der Name schon vermuten lässt, geht es wieder einmal um das Zusammenwachsen des guten alten Wasserfall-Modells mit agilen Techniken. Lesenswert!

Und weil wir schon beim Agilen sind, habe ich die folgende Lese-Empfehlung: 32 Zeichen an denen Sie erkennen, dass Ihr agiles Projekt kein Erfolg werden kann. Sehr unterhaltsam und wahr. Schon der erste Punkt rang mir ein breites Grinsen ab: „You think agile is iterative waterfall.“ Oder wie wäre es damit: „You think Product Backlog = project plan, iteration = milestone, scrum-master = project manager, sprint retrospective = project status meeting and agile discipline = micromanagement.

Und zum Schluss noch ein Hinweis auf Altmeister Bas de Baar. Er fordert, man solle sein Projekt in ein Piratenschiff verwandeln: „But it will also clearly differentiate your project team from the larger organization. If the entire company is a conservative, slow moving, bureaucratic monster turtle, and you need a team that moves fast and doesn’t comply to the dominant culture, you should raise the Pirate Flag.“ Eine anregende Idee um in verkrusteten, sich nicht bewegenden Unternehmen zu überleben.

Projekt-Praktikum: Aufwand schätzen oder nicht?

Bärbel de BouvierSeit meinem Aufwandsschätzungs-Faux-pax vor ein paar Tagen beschäftigt mich das Schätzungs-Thema. Dabei bin ich auf verschiedene Postings von – vorwiegend amerikanischen – Bloggern gestossen, die darüber diskutieren, ob man eine Aufwandsschätzung überhaupt braucht. Ein Gedanke, der mit bislang noch gar nicht in den Sinn kam. Die Argumente sind aber nur zu schön:

  • Aufwandsschätzung sind nie wirklich genau und schaffen daher keinen Mehrwert.
  • Selbst wenn sie hinreichend genau sind, die Arbeit muss trotzdem erledigt werden. Warum also Zeit mit Schätzungen vergeuden?
  • Das Schätzen des Aufwands sorgt für schlechte Stimmung, da jeder gezwungen ist mitzumachen und einem Konsens zuzustimmen, auch wenn er tief im Inneren anderer Meinung ist.
  • Die Aufwandschätzungen beeinflussen das Verhalten der Teammitglieder in negativer Weise. Entweder, indem sie sie unter Druck setzen den Termin einzuhalten und damit schlechtere Qualität zu liefern oder, wenn sie dem Termin voraus sind, in ihren Anstrengungen nachzulassen und damit Zeit zu verschwenden.

Dem stehen natürlich die bekannten „Vorteile“ entgegen:

  • Der Wert eines Projektes lässt sich nicht ohne Aufwandsschätzung ermitteln.
  • Ein Sprint lässt sich nicht planen, ohne den Aufwand zu kennen.
  • Ohne Aufwandsschätzung geht die Disziplin im Team flöten und es wird Zeit verschwendet.

Die Frage ist jetzt natürlich, was uns die Autoren damit sagen wollen. Wird da ein endlich etabliertes, in unzähligen Projekten bewährtes Verfahren schon wieder in Frage gestellt? Ein bischen schon. Meine Erkenntnis: Nicht beirren lassen und weiter machen! Trotzdem bleibe ich an dem Thema dran. Mehr dazu im nächsten Posting.

Projekt-Praktikum: Aufwandsschätzung

Bärbel de BouvierOh je! In meinem letzten Blog-Post zum Thema Aufwandsschätzung habe ich ein wenig daneben gehauen. Aber es gibt ja nichts, was man nicht auf Youtube finden und daraus seine Lehren ziehen kann. Beispielsweise eine zweiteilige Session von Mike Cohn, einem der Gründer der Scrum-Alliance, zum Thema Agile Estimation. Der Vortrag dauert insgesamt gute eineinhalb Stunden. Zeit, die sich auf jeden Fall lohnt.

Weiterlesen