Projektmanagement

Analytics: Projekte besser managen.

BI-Vorhaben laufen oft aus dem Budgetrahmen. Liegt es an der schlechten Aufwandsschätzung oder der unvollständigen Anforderungsbeschreibung? Derlei Erklärungsversuche greifen zu kurz. Ein Praxisbericht.  

* Von Kai Rordorf 

  

Die Budgetierung von BI-Projekten gibt oft Anlass zu Diskussionen. Kaum ein größeres Vorhaben bleibt innerhalb des abgesteckten Rahmens. Nachbudgetierungsrunden sind die Konsequenz. Ein Beispiel aus dem Alltag:
Betrachten wir die fiktive Situation des Vertriebsmitarbeiters Max Schuther beim BI-Lösungsanbieter planFuX. Er hat einen Neukunden, die Firma Silbermond, akquiriert und den Kunden bereits von der Servicemannschaft und der Softwarelösung von planFuX überzeugt.

Die Projektanforderungen sind ambitioniert: Es geht um eine stark verteilte Planung für zahlreiche unterschiedliche Abteilungen, die im Laufe des Projekts ausgebaut werden soll – von der Umsatzplanung bis hin zur integrierten Finanzplanung. Obwohl es noch einige Unsicherheiten gibt (zum Beispiel die Qualität der Daten aus den diversen Schnittstellen), drängt der Projektverantwortliche, Hans Hurtig, auf ein verbindliches Angebot mit einer Kalkulation für das gesamte Vorhaben und verweist auf einen Mitbewerber, der bereits ein Angebot eingereicht habe.
Schuther ist in Zugzwang. Seine Kollegen im Service haben wunschgemäß bereits sehr kurzfristig eine Kalkulation aufgestellt. Da es noch einige unbekannte Faktoren gab, berücksichtigen sie bei den entsprechenden Arbeitspaketen etwas mehr Puffer. PlanFuX erhält den Zuschlag.



Das Pflichtenheft ist keine Lösung.
Aber schon nach wenigen Wochen ist für alle Beteiligten absehbar, dass die Komplexität der Anforderungen für das Projekt den festgelegten Rahmen erheblich überschreiten wird. Schuther ist also gezwungen, kurzfristig mit Hurtig über die Abrechnung der nun gestiegenen Arbeitsleistungen zu sprechen.
In einer Besprechung diskutieren die beiden lange darüber, welche der nun zusätzlich nötigen Tätigkeiten als Change Request laufen sollen oder bereits im ursprünglichen Angebot enthalten waren. Schlussendlich einigen sie sich auf einen  50-50-Kompromiss für die Abrechnung der Mehraufwände. Für Schuther verringert sich der Projektumsatz. Und auch Hurtig muss die Mehrkosten erst einmal vor dem Management rechtfertigen. Natürlich sind beide Seiten wenig begeistert über die Situation.

Angesichts dieses Beispiels liegt der Schluss nahe, ein klassisches Pflichtenheft zu schreiben und alle erforderlichen Maßnahmen bis ins kleinste Detail vorab festzulegen und im Projekt eins zu eins abzuleisten. Wie viele Projekte zeigen, ist dies keine ratsame Lösung:

Erstens ist der Entwicklungs- und Abstimmungsprozess sehr aufwendig und diskursanfällig. Zweitens, was noch viel schwerer wiegt, gibt es wohl kaum ein Projekt, bei dem sich Anforderungen gleich zu Anfang hundertprozentig beschreiben lassen. Um das zu tun, müssten die Beteiligten in alle Untiefen des Projekts abtauchen und damit auch jede einzelne Schnittstelle ausprobieren oder Ausreißer in den Geschäftsdaten finden – ein immenser Aufwand, mit dem das Unternehmen fast schon ein vollständiges Projekt abschließen könnte.

Zudem entstehen und ändern sich viele Anforderungen erst im laufenden Projektgeschäft, zum Beispiel aufgrund aktueller Geschäftsereignisse (etwa interner Umstrukturierungen oder eines Managementwechsels).  
Derlei Situationen kennt fast jeder BI-Entscheider. Trotzdem verlangt das Management vor dem Projektstart meist eine Gesamtprojektkalkulation. Um indes ein solches Dilemma wirklich zu lösen, sollte dieser Ansatz ganz aufgegeben werden: zugunsten eines Scrum-Verfahrens.



Effektive Projektarbeit mit Scrum.
Scrum ist ein Modell zur Verschlankung und Dynamisierung von Prozessen. Es wird bislang vor allem in der Softwareentwicklung eingesetzt. Auf der Basis der kontinuierlichen Abstimmung des gesamten Entwicklungsteams, inklusive der Entscheider und Anwender, nähert sich das Projektteam in überschaubaren Intervallen dem optimalen Endergebnis.

Dafür bedarf es einer Zusammenarbeit auf der Grundlage maximalen Vertrauens. Dies darf aber kein Lippenbekenntnis bleiben. Vielmehr müssen sich alle Parteien auf ein «Time-and-Material»-Modell auf der Basis eines Scrum-Service-Agreements einlassen.

Könnte dieses Vorgehen dazu führen, dass die Projektleitung die Zügel zu locker lässt? Das Gegenteil ist der Fall: Die Verantwortlichen sitzen wegen der klaren Regeln sogar noch fester im Sattel. Das Herzstück eines Scrum-Projekts besteht aus den sogenannten Sprints. Darunter verstehen Experten kurze zeitliche Entwicklungsabschnitte, die nicht länger als einen Monat dauern dürfen.

Zu Anfang eines jeden Sprints steht die Planung. Dabei definiert das Team, bestehend aus «Product Owner» (der Projektverantwortliche des Auftraggebers) und Entwicklern (im Projekt die Servicekräfte des Dienstleisters), welche Aufgaben aus dem sogenannten «Projekt-Backlog» (einer Sammlung der kurz- bis mittelfristigen Anforderungen) abgearbeitet werden.

Der «Product Owner» hat dabei das letzte Wort und zeichnet auch verantwortlich für die Generierung des «Projekt-Backlog». Natürlich stimmt er sich mit allen Verantwortlichen («Stakeholdern») der unterschiedlichen Fachabteilungen ab.
Am Ende jedes Sprints steht ein «Review Meeting», bei dem allen Beteiligten die Ergebnisse präsentiert und direkte Feedbacks eingeholt werden. Dieser Zyklus setzt sich bis zur Fertigstellung der Planungslösung fort.


Umfassende Transparenz.
Der Projektmanager beim Kunden erhält durch Scrum folglich viel mehr Kontrolle und kann jederzeit gegensteuern, wenn er das Gefühl hat, dass die Aufwände aus dem Ruder laufen. Zusätzlich schafft dieser Ansatz Möglichkeiten für neue Anforderungen, die erst während des Projekts zum Beispiel in Form von neuen Schnittstellen hinzukommen.
Die dadurch entstehenden Mehraufwände erfährt der Kunde unmittelbar und kann ad hoc entscheiden, ob die Investition gerechtfertigt ist. Zudem beinhaltet der Aufwand nicht nur Kosten, sondern auch Zeit. Deshalb kann der Projektmanager auch die Auswirkungen auf die Zeitplanung aktiver mitsteuern.  

Zusätzlich entfallen durch die umfassende Transparenz in einem Scrum-Projekt die oft langwierigen Diskussionen zwischen Kunden und Dienstleistern über Nachbudgetierungen oder verpasste Termine. Das Gesamtprojekt bleibt auf diese Art gefeit vor bösen Überraschungen am Ende des Prozesses – und der Kunde kann kontinuierlich prüfen, ob die Software seinen Erwartungen entspricht. Neben dem Kontrollgewinn erzielen Unternehmen zudem einen extrem relevanten Mehrwert: eine gute Stimmung im Projekt.


Ausblick auf die Praxis.
Bis sich Scrum-Service-Agreements indes als akzeptiertes Projektmodell in der Praxis wirklich durchsetzen, wird sicher  noch einige Zeit vergehen. Um aus den eingefahrenen Pfaden der Projektabwicklung auszubrechen, braucht es neben einem gewissen Pioniergeist vor allem Vertrauen in den Vertragspartner, der das nächste BI-Projekt zum Erfolg führen soll. Wer diesen Mut mitbringt, wird mit mehr Kontrolle, mehr Projektfrieden und einem schnelleren Weg zur BI-Lösung belohnt.

 

* Kai Rordorf ist Leiter Consulting bei Thinking Networks in Aachen.

 

Quelle: BUSINESS INTELLIGENCE MAGAZINE, www.bi-magazine.net 
© ProfilePublishing Germany GmbH 2014_2015. Alle Rechte vorbehalten. 
Vervielfältigung nur mit Genehmigung der ProfilePublishing Germany GmbH

Business Intelligence Magazine: Springe zum Start der Seite