Von: Clemens

Clemens — Fri, 13 Feb 2009 09:22:55 +0000

Eigentlich ist das garnicht so weit von dem entfernt wie die Projekte bisher laufen, lediglich die Sichtweise ist eine andere. Während die herkömmliche Projektvorgehensweise Änderungen als change requests erachtet (ein für alle Beteiligten negativ behafteter Terminus), macht agiles Vorgehen die sich ständig verändernde Projektumwelt zum zentralen Bestandteil. Es ist entwicklungsorientierter, da wir es bei Individualsoftware nie mit im voraus vollständig abgrenzbaren Anforderungen zu tun haben. Und menschlicher, da wir mit den immer auftretenden Unsicherheiten natürlicher umgehen können. @Markus: sauber, wie Du das mit einem vom Kunden durch Budgetzwänge oft gewünschten Festpreis vereinbarst und dabei den Kunden noch mehr involvierst.

Von: Markus

Markus — Thu, 12 Feb 2009 14:53:46 +0000

Wir haben im vergangenen Jahr ein Projekt mit einem unserer großen Kunden durchgeführt und uns dabei komplett auf agiles Vorgehen eingelassen, weil die Anforderungen von vorherein unklar waren und die Kompetenz auf Seiten des Auftraggebers nicht so weit ging, dass man sich hätte über die präzise Funktionalität im Vorfeld einigen können. Es ging um die digitale Abbildung eines Prozesses mit einer größtmöglichen Fehlerfreiheit. Wir haben ein paar Dinge gelernt in diesem Projekt:
1. Der Kunden muss sich auf den Dienstleister verlassen können. Uns hat es geholfen, dass wir eine langjährige Kundenbeziehung haben und in Zufriedenheitsbefragungen immer nahe 100 liegen. Das schafft Vertrauen, und das ist unbedingt notwendig.
2. Wir haben einen Festpreis vereinbart. In der Regel strebt man bei agilen Projekten ja eine Vergütung nach Aufwand an. Ich glaube, ein Festpreis ist auch möglich, wenn man die Prozesse im Projekt transparent hält und dem Kunden Einblick gibt in die Tätigkeiten und Aufwände. Interessanter Weise interessierte sich der Kunde viel mehr für den Verlauf des Projekts als in vergleichbaren Projekten, wo auf Basis starren Plans nach festen Anforderungen gearbeitet wird und allenfalls Meilensteine interessant sind.
Auch hier ist der grundlegende Faktor das Vertrauen. Wenn wir dem Kunden sagen: “Wenn Du dieses Feature willst, dann wird das 30% des Budgets kosten”, dann überlegen wir gemeinsam nach Alternativen oder bewerten Funktionalitäten im Blick auf Nutzen, Aufwand etc.
3. Der Kunde lernt unser Geschäft als Dienstleister verstehen und entwickelt eine Kompetenz im Blick auf budgetangemessene Realisierungsmöglichkeiten. Damit steigt auf Kundenseite die Akzeptanz unsere Empfehlungen und Entscheidungen.
Am Ende des Tages haben wir vielleicht nicht alles realisiert, was möglich gewesen oder spezifiziert geworden wäre. Aber wir haben ein besseres System realisiert, weil wir es exakt auf die Bedürfnisse zugeschnitten haben. Die gewünschte Fehlerfreiheit lässt sich m.E. in einem agilen Projekt per se viel besser erreichen.
Und jetzt bin ich gespannt auf das im April anstehende Audit zur ReZertifizierung unserer Qualitätsstandards. Da werde ich das Projekt nämlich einbringen – und hoffentlich feststellen, das unsere Firma an manchen Stellen ebenso weit ist wie unser Kunde.

Kommentare zu: Agiles Projektmanagement: Viele Stolpersteine in der Praxis

Von: Clemens

Von: Markus