Reifegradmodelle im Projektmanagement

Mich erreichte die Nachfrage, was ich denn mit Reifegradmodellen im Projektmanagement meinen würde. In einem Post hatte ich den Begriff kurz fallengelassen als Hinweis auf einen möglichen Projektverlauf im Rahmen eines Performance Tunings.

Oft beschreiben Reifegradmodelle themenbezogen die möglichen Entwicklungsschritte einer ganzen Organisation. Es gibt dabei Modelle für ganz unterschiedliche Herausforderungen: IT-Infrastruktur & Security, Business Intelligence, Projektmanagement usw. Dabei wird in der Regel als Orientierung festgelegt, wo die Organisation im Referenzmodell gerade steht, was die nächste Stufe ist und durch welche Merkmale diese zu erreichen wäre. Das Reifegradmodell fasst dabei durch sein “Modell” die einzelnen “Reifegrade” der notwendigen Prozesse innerhalb der Organisation zusammen.

Es geht mir nun darum, wie große, unhandliche und komplexere Projekte “eingefangen” werden können und damit das Risiko eines Scheiterns bereits während der Planung minimiert werden kann.

Im Rahmen von Projekten werden häufig eine ganze Reihe von Prozessen bzw. Funktionalitäten implementiert oder auch erweitert. Während der Planung von Projekten gilt es für diese Implementierungen bzw. Änderungen einen Entwurf zu erstellen, welcher beschreibt wann was wie umgesetzt wird. Die Praxis zeigt, dass dieser Vorgang häufig damit endet, dass der Planer vom Hundertsten ins Tausendste kommt. Dieser Umstand kommt häufig daher, dass nicht immer klar ist, wie weit eine Implementierung in dem jeweiligen Teilprojekt gehen soll bzw. muss! So entstehen oft große undhandliche Projekte, welche dann leider auch meist zum Scheitern verurteilt sind.

Schauen wir uns mal ein plakatives Beispiel an. Es soll ein komplettes Data Warehouse erstellt werden. Dieses Vorhaben als ein einziges großes Projekt abzubilden ist nicht unüblich. Das Scheitern solcher Projekte leider auch nicht.

Erfolgsversprechender ist es die für den Betrieb eines Data Warehouse notwendigen Prozesse in einem so genannten Implementierungsprojekt ans Laufen zu bringen. Das Projekt ist erfolgreich, wenn die Prozesse “leben” und funktionieren. Änderungen und Erweiterungen am DWH sind dann meist keine Projekte mehr, sondern fallen in die Kategorie Change Request. Damit befinden wir uns dann mitten im Change Management des Life-Cycle-Managements eines DWHs.

Trotz alledem wird es bei größeren Erweiterungen oder gar neuen Funktionen wieder die Notwendigkeit von Projekten geben. Was für Erweiterungen können das sein? Dafür ist das Thema Daten Qualität ein schönes Beispiel. Wie weit wollen oder müssen wir im Implementierungsprojekt beim Thema Daten Qualität im Data Warehouse gehen? Wäre es nicht sinnvoll für den Prozess DQ eine Reihe von Reifegraden zu definieren, mit denen wir die Entwicklungsstände dieses Teilprozesses dokumentieren und planen können?

Wenn wir bei dem Data Warehouse bleiben, dann gibt es zum Beispiel auch das Thema nachhaltige Protokollierung des Zugriffs auf Daten (kurz Audit). Ist in vielen Umgebungen ein sehr wichtiges Thema, nur wie weit soll bereits im Implementierungsprojekt dieser Prozess vollständig abgebildet werden? Wieder kann hier eine Reihe von Reifegraden die Planung vereinfachen, da diese die künftige Entwicklungsschritte der Funktionalität vorbereiten und klar voneinander abgrenzen.

Fassen wir nun die vorgesehenen Reifegrade der geplanten Prozesse und Funktionalitäten zusammen, so erhalten wir ein Referenzmodell für die angestrebte “komplette” Lösung, welche wir schrittweise erreichen können. Die Reifegrade sind damit auch die Grundlage für die Planung der Teilprojekte, welche wieder ganz klassisch im Projektmanagement stattfinden kann. Hier kommen sich unser Reifegradmodell und er Begriff Strategie sehr nahe.

Unterstützt kann diese Vorgehensweise dadurch werden, dass wir für unsere diversen technischen Objekte in unserer Lösung ein Repository nutzen und in diesem u. a. den jeweiligen Entwicklungsstand festhalten und auch gleich die weitere Planung daran binden. Wichtig ist mir hier die Abgrenzung zur klassischen separaten Dokumentation. Diese hat zwar ihre Daseinsberechtigung, aber hat in der Regel keine direkte Bindung mit den Objekten in der Lösung. Objekte in einem solchen Repository können zum Beispiel SSIS Pakete, DQ Regeln, Inhalte von Reports (RDL), Dimensionen und Fakten eines Cubes und / oder eines Data Warehouses sein.

Die Kombination aus einem Reifegradmodell für die angestrebte Lösung und Repository ist eine wertvolle Unterstützung für das Projektmanagement, da es sowohl die Planung als auch die Kommunikation im Teilprojekt vereinfacht. Dieses Vorgehensmodell lässt sich leicht auf andere komplexere IT-Projekte ausdehnen. SharePoint Projekte sind zum Beispiel ebenso prädestiniert für diese Vorgehensweise.