Bei agilem ProjektmanagementProjektmanagement stehen viele Unternehmen noch immer auf der Bremse. Vor allem IT-ProjekteIT-Projekte in der Finanzbranche sind betroffen. Der Grund: Viele Projektverantwortliche müssen zusätzlich zu den Projektanforderungen weiterhin Aufgaben im Tagesgeschäft übernehmen. Ein Interessenkonflikt ist programmiert. Das kostet Firmen bereits in einzelnen Projektphasen sechsstellige Beträge. Alles zu Projekte auf CIO.de Alles zu Projektmanagement auf CIO.de

Kennzeichnend für agile Methoden wie ScrumScrum sind kurze Projektphasen, sogenannte Sprints. Üblicherweise ist ein Sprint mit 20 Tagen kalkuliert. Das erfordert vom Ergebnisverantwortlichen als "Product Owner" für das neue IT-System hohe Flexibilität und schnelle Entscheidungen, damit das Team während der Sprints ausgelastet bleibt und keine kostenintensiven Leerzeiten entstehen. Alles zu Scrum auf CIO.de

Zudem muss der Product Owner alle an das Team herangetragenen Anforderungen managen. Das gilt sowohl vonseiten der Auftraggeber als auch der beteiligten Fach- und IT-Abteilungen sowie der Revision. Viele Unternehmen machen dabei den Fehler, Product Owner nicht ausreichend vom Tagesgeschäft freizuhalten. Stattdessen setzen die Entscheider auf schnelle Schulungen und einen Sprung ins kalte Wasser.

Schlüsselposition: Product Owner

Ohne die erforderliche Priorisierung der Anforderungen des IT-Projekts drohen jedoch hohe Folgekosten in einzelnen Sprintphasen. In einem Team aus typischerweise sechs bis acht Mitarbeitern laufen alle Fäden beim Product Owner zusammen. Erfüllt dieser wegen zu starker Einbindung im Tagesgeschäft seine Steuerungsfunktion nur unzureichend, gerät der Projektverlauf aufgrund nicht geeignet definierter Anforderungen ins Stocken.

Zunächst lässt sich dies noch durch ohnehin erforderliche Routinearbeiten wie der Spezifikation technischer Anforderungen kompensieren. Später droht dagegen der Totalverlust ganzer Sprints, da die Projektmitarbeiter direkt von Informationen des Product Owners abhängig sind. In der Praxis zeigt sich, dass Ausfälle von 150.000 Euro und mehr durch verschenkte Projektzeiten keine Seltenheit sind - und das pro ausgefallenen Sprint.

Neben dem Totalausfall eines Sprints gehören Verzögerungen zur Tagesordnung. Diese entstehen etwa bei unklar definierten Anforderungen, die eventuell im falschen Detaillierungsgrad vorliegen oder durch Überlastung des Product Owners verspätet priorisiert werden. Das macht Nachbesserungen erforderlich, die sich auf den nächsten Sprint verschieben.

Dabei wirkt sich die "Exportquote" notwendiger Nacharbeiten auf die Ergebnisqualität im Folgesprint aus. Das führt dann unter Umständen sogar zu einem Aufschub von Meilensteinen auf den übernächsten Sprint. Auf diese Weise schiebt das Projektteam eine Bugwelle verzögerter Aufgaben vor sich her, die schlimmstenfalls einen Totalausfall künftiger Sprints provoziert.

Verteilte Steuerung der Anforderungen

Abhilfe schafft ein Product-Owner-Team (PO-Team) mit einem Verantwortlichen, der vor allem koordinative Aufgaben wahrnimmt und bei kritischen Anforderungen immer als Entscheider zur Verfügung steht. Auf diese Weise lassen sich Effekte wie ein nicht eingehaltenes On-Site-Customer-Prinzip sowie Verzögerungen im Stakeholder-Management oder im Projektmarketing abmildern. Mit einem PO-Team lassen sich auch offene Fragen schneller klären, die anderenfalls zu Mehrarbeit in Folgesprints führen würden.

Eine wesentliche Gefahr besteht darin, zur Vermeidung von Mehrkosten oder einer dauerhaft zu hohen Auslastung der Mitarbeiter Qualitätseinbußen in einzelnen Sprints zu akzeptieren. Das gefährdet das Gesamtergebnis vor allem, wenn Überbelastungen nicht abgebaut werden, sondern kontinuierlich bestehen bleiben. Nach Projektabschluss ergeben sich zusätzlich regelmäßig neue Herausforderungen, wie etwa Erweiterbarkeit, Wartbarkeit oder Portabilität.

Ein PO-Team sorgt für die nötige Priorisierung und sollte deshalb aus Mitgliedern der Fachabteilungen und der IT bestehen. Gemeinsam stellt es dann Akzeptanzkriterien auf, um eine Vernachlässigung von wesentlichen Anforderungen oder Rahmenbedingungen hinsichtlich des gesamten Zielbilds für das Projekt zu vermeiden. Dies gilt vor allem für Vorschriften wie Bildschirmarbeitsplatzrichtlinien, Architekturvorgaben, IT-Sicherheitsanforderungen oder gesetzlichen Regelungen.

Beispielsweise führen im Bankenumfeld eine Verletzung von MaRisk-Richtlinien oder eine fehlende SSL-Verschlüsselung bei Anwendungen, die über das Internet kommunizieren, zum K.O. des Projekts. Dann dürfen selbst zufriedenstellende Projektergebnisse nicht verwendet werden und das eingesetzt Budget ist verloren.

Erfolgskriterien gemeinsam definieren

Ein gemischtes PO-Team eignet sich besonders, um wesentliche Erfolgskriterien rechtzeitig in die Projektphasen einzuführen. Eine Triage entscheidet zu Beginn der Anforderungserhebung über die jeweils erforderliche Detaillierungsstufe. Wichtige Kriterien dabei: Business Impact, Komplexität und Beobachtbarkeit des Systemverhaltens. Einzelne Anforderungen lassen sich zudem während des Projektvorgehens verfeinern (Lazy Refinement).

Entscheidend sind in diesem Zusammenhang Methoden, um nicht-funktionale Anforderungen wie etwa Benutzerfreundlichkeit zu ermitteln und zu dokumentieren. Einfache Anwendungsberichte von Nutzern reichen dafür kaum aus. Besser eignen sich Akzeptanzkriterien, die alle relevanten Kriterien durch Tests messbar abfragen.

Weiterhin sind agileagile Projektteams nicht von der Dokumentationspflicht entbunden. Allerdings lässt sich das harte Kriterium der Vollständigkeit durchaus etwas aufweichen, wenn es um die Dokumentationstiefe geht. Fehlende Anforderungsdokumente führen dagegen durch "Unterdokumentiertheit" zu ernsten Nachvollziehbarkeits- und Wartungsproblemen. Den richtigen Gradmesser bei der Dokumentation zu finden gehört ebenfalls zum Aufgabenbereich des Product Owners. Alles zu Agile auf CIO.de

Fazit

In agilen Projekten verwandelt sich der Product Owner zunehmend in einen Anforderungsmanager für das Gesamtprojekt. Vor allem in Finanzunternehmen, die fachlich häufig noch nach Geschäftsbereichen organisiert sind, macht daher eine Verteilung der klassischen Aufgaben von Product Ownern auf mehrere Schultern Sinn.

Das stellt die erforderliche Kommunikation über fachliche und organisatorische Grenzen hinweg sicher. Erfahrungsgemäß muss das Projektteam dadurch weniger Hürden auf dem Weg zum Ziel nehmen und erreicht so in kürzerer Zeit einen gemeinsamen Arbeitsmodus.