htt

Business Intelligence,Markttrends

Agiles und klassisches Projektmanagement im Einklang

von
Projektmanagement

Die Bedürfnisse der Kunden, die Unternehmensdaten für sich sprechen zu lassen, gibt es schon seit den frühen 80ern, als man noch von Management Informationssystemen gesprochen hat (Kemper, 2010), aber durch die sich immer schneller verändernden Umwelt sowie der zunehmenden Datenmasse, nimmt das Thema BI ganz neue Dimensionen an. In der Vergangenheit reichte es aus, sich auf einfache Listen, Tabellenkalkulationen, etc. zu konzentrieren; die Herangehensweise hatte konfirmatorische Züge. Heute arbeiten Business Intelligence Analysten explorativer als vorher, um neue Erkenntnisse aus den Daten zu gewinnen. Aufgrund der extremen Datenzunahme, braucht es immer schnellere, intuitivere, und leistungsfähigere Tools zur Realisierung von Business Intelligence Projekten. Flexibilität im Projekt hat hierbei einen hohen Stellenwert errungen und stellt einen wesentlichen Faktor auch für die BI-Technologie dar. BI-Berater müssen sich deshalb Gedanken machen, wie derartige „Riesenprojekte“ erfolgreich realisiert werden – nicht nur technisch, sondern auch auf Projektmanagement-Ebene.

In weitesten Sinne hat jedes Projekt ein definiertes Ziel, welches  in einem gegebenen Zeitrahmen in einer vorher definierten Qualität und im Rahmen eines bestimmten Budgets erreicht werden soll. Klassischerweise wird hierbei ein Projekt in unterschiedlichen Phasen untergliedert, wie man es aus dem typischen Vorgehensmodellen kennt. Aufgrund der zunehmenden Dynamik des Marktes, müssen sich Unternehmen immer wieder an neue Gegebenheiten anpassen, sodass sich die in BI-Projekten zu Beginn aufgestellten Anforderungen verändern oder sich sogar erst im Laufe eines Projektes entwickeln können. Um auf diese Bedürfnisse eingehen zu können, greifen Projektmanager  auf agile Vorgehensmodelle zurück. Diese legen, anders als iterative-sequentielle Modelle, ihren Fokus auf die folgenden Werte (TDWI, 2014):

  • Unternehmensnutzen ist wichtiger als das Festhalten an Methoden und Architekturkonzepten.
  • Kontinuierliche Zusammenarbeit und Interaktion zwischen Anforderern und Umsetzern sind wichtiger als Prozesse und Werkzeuge.
  • Eingehen auf Veränderungen ist wichtiger als Festhalten an einem Plan.
  • Funktionierende BI-Lösungen sind wichtiger als detaillierte Spezifikation.

Diese Werte lassen sich in den klassischen Vorgehensmodellen, wie z.B. dem Wasserfallmodell oder V-Modell (Sommerville, 2008), kaum wiederfinden. Dennoch, haben die klassischen Modelle immer noch Ihre Daseinsberechtigung – gerade wenn es um große und sehr komplexe Projekte geht. Viele Unternehmen haben deshalb erkannt, dass es oft sinnvoll sein kann agile und klassische zu kombinieren. Folgendes Szenario beschreibt eine Situation, in der eine solche Kombination als sehr sinnvoll erscheint:

Oberstes Ziel ist es, ein Business-Intelligence-System mit einem Data-Warehouse und dem entsprechenden Reporting aufzusetzen. Da jeder Fachbereich eigene Bedürfnisse und Reporting-Vorstellungen hat, ist es unmöglich im Rahmen des initialen Business Cases alle Anforderungen auf einmal aufzunehmen. Um flexibel auf die Bedürfnisse des Kunden eingehen zu können, wendet man die Scrum-Methodik an. Damit wird es möglich, gemeinsam mit dem Kunden Daten, Reports, etc. zu erarbeiten. In diesem Beispiel wird das Prince2-Prozessmodell (P2PM) als Management Framework genutzt und SCRUM als agiles Vorgehensmodell, um mit den Auslieferungen umzugehen. Das Prince2-Prozessmodell konzentriert sich auf das Projekt, welches vom Unternehmens-/Programmmanagement durch ein Projektmandat eingeleitet wird. Im weiteren Verlauf gliedert sich das P2PM in 3 Hierarchiestufen (Imm & Weber, 2014):

  1. Lenken: Auf dieser Ebene agiert der Lenkungsausschuss, der die Gesamtverantwortung und –vollmacht des Projektes besitzt. Auf dieser Ebene wird das Projekt gelenkt, z.B. Projektinitiierung freigeben oder Ad-Hoc Anweisungen geben.
  2. Managen: Diese Ebene steuert das Projekt, dabei nimmt der Projektmanager die führende Rolle ein. Dieser ist für die laufende Durchführung des Projekts verantwortlich. Neben den Tätigkeiten der Initiierung des Projekts, Managen der Phasenübergänge, werden in der Steuerungsphase die Teilprojekte und/oder Arbeitspakete an die Teammanager weitergegeben. Nach dem alle Arbeitspakete erfolgreich abgeschlossen worden sind und das Ziel des Projektes erreicht wurde, wird das Projekt abgeschlossen.
  3. Liefern: Diese Ebene wird durch Teammanager geprägt, welche für die Fertigstellung der verschiedenen Arbeitspaketen zuständig sind.

Die Scrumethodik (Kriegisch, 2014) greift hierbei auf der Lieferebene, das bedeutet, dass Teammanager Anforderungen aufnehmen, diese werden in Zusammenarbeit mit dem Entwicklungsteam und dem Kunden umgesetzt. Dabei dauert jeder Sprint ca. 30 Tage mit dem Ziel am Ende fertige Produktinkremente abzuliefern, im Laufe eines Sprints können aber flexibel neue Anforderungen aufgenommen, evaluiert, priorisiert und entsprechend geplant werden. Ziel ist es immer den Nutzen im Fokus zu behalten, so dass auch durch Änderungen nicht die Qualität des Projekts leidet.

Der Vorteil einer solchen Kombination ist,  dass die Kontrolle von Budget, Plänen, Ressourcen und der notwendigen Kommunikation durch die klassische Methode sichergestellt werden und so die Struktur des Projektes permanent gleich bleibt. Die Scrum-Methodk gibt dem Team und dem Kunden/Unternehmen eine entsprechende Flexibilität, so dass nicht am Anfang komplett alles definiert werden muss, sondern sich das Projekt entwickeln kann.

Auf der folgenden Grafik wird das Hybridmodell bildhaft dargestellt:

Prince2  Scrum

Literatur

Imm, O., & Weber, M. (2014). PRINCE2® – Alles was man wissen muss. SERVIEW GmbH.

Kemper, H.-G. B. (2010). Business Intelligence – Grundlagen und praktische Anwendungen. Wiesbaden.

Kriegisch, A. (10 2014). Scrum-Master.de Agiles projektmanagement. Von http://scrum-master.de/Was_ist_Scrum/Scrum_auf_einer_Seite_erklaert abgerufen

Pütter, C. (17. 01 2014). CIO-Magazin. Von http://www.cio.de/strategien/2941213/ abgerufen

Sommerville, I. (2008). Software-Engineering. Boston: Pearson Studium.

TDWI. (10 2014). TDWI Europe. Von Memorandum für Agile Business Intelligence: http://www.tdwi.eu/wissen/agile-bi/memorandum/ abgerufen

Bhagat Ransi

Über den Autor 

Nach dem Studium der Wirtschaftswissenschaften an der Universität Hohenheim als Consultant im Business Intelligence Umfeld in verschiedenen Branchen tätig. Seit Juli 2014 BI Consultant und Business Analyst bei der Insight Dimensions GmbH.

Agiles und klassisches Projektmanagement im Einklang Reviewed by on .

Business Intelligence ist in aller Munde und es scheint, als ob der der Trend bestehen bleibt, was auch die aktuelle BARC- & Gartner Studie (Pütter, 2014) zeigt. Das Thema Business Intelligence (BI) ist jedoch keineswegs etwas „Neues“.

Hinterlasse einen Kommentar

Your email address will not be published. Required fields are marked ( required )