Die Meldungen, dass zwischen (80-90)% aller IT-Projekte Ihre Ziele nicht erreichen oder gar komplett scheitern, sind seit langem bekannt. Die hier immer wieder genannten Top-Ten Fehler, z.B. fehlende Sponsoren des oberen Managements, mangelnde Verbindung zwischen IT-Entwicklung und Geschäftsprozessen oder auch fehlender kontinuierlicher Einbezug der Key-User, sollen an dieser Stelle nicht wiederholt werden. Aus unserer Erfahrung werden Großprojekte, die über mehrere Jahre angelegt sind, von Unternehmen und Dienstleistern sehr professionell geplant und auch durchgeführt.
Der überwiegende Teil eines IT-Projektportfolios bewegt sich aber im Bereich 50-300 Personentage. Hier wird in Summe über alle Projekte der überwiegende Teil des IT-Projektbudgets ausgegeben und hier besteht aus unserer Sicht der größte Handlungsbedarf zur Optimierung und Steigerung der Effizienz.
Dazu aus der Praxis hier eine Liste von Verbesserungsvorschlägen zu folgenden Punkten:
- Vorstudie statt Design to Cost – Ansatz
- Monetäre Bewertung der gewählten IT-Architekturen über den gesamten Lebenszyklus
- Belastbare Fortschrittskontrolle der Entwicklungsstände
- Interaktive OP-Listen für das gesamte Projektteam
- „One Stop Shop“ für Projektdokumentationen
- Usability-Tests von der Konzeptphase an
- Projekt endet nicht mit dem Go-Live
- Keine Angst vor roten Ampeln
Vorstudie statt Design to Cost – Ansatz
In der Regel wird vor Beginn der Projekte eine grobe (Daumen-)Schätzung der Kosten an Hand eines mehr oder weniger detaillierten Fachkonzeptes vorgenommen. Es folgt eine Budgetfreigabe durch den Entscheiderkreis mit der Vorgabe, die Kosten keinesfalls zu überschreiten. Im Projekt stellt sich dann die schwierige Aufgabe, das Lösungsdesign den Kosten permanent anzupassen und Fachanforderungen, die in jeder Iterationsstufe verfeinert werden, zu reduzieren. Die Folgen sind: Unzufriedene Anwender (da Anforderungen nicht erfüllt), unzufriedene Entwickler (da Lösungsdesign sich ständig ändert), unzufriedener Projektleiter (da man zwischen beider Parteien permanent Konflikte lösen muss) und unzufriedene Auftraggeber (da zwar die Kostenplanung, aber selten der Zeitplan eingehalten wird). Eine Lösung für diese Dilemmata: Die aus Großprojekten gängige Praxis der Vorstudie für kleine Vorhaben pragmatisch adaptieren und z.B. (5-10)% des geplanten Projektbudgets im Vorfeld der Gesamtentscheidung für eine Detailschätzung und Evaluierung des Lösungsdesigns investieren. Dies schützt vor technischen Fehleinschätzungen, sichert das Gesamtinvestment und sorgt in der Regel für eine schnellere Projektabwicklung.
Monetäre Bewertung der gewählten IT-Architekturen über den gesamten Lebenszyklus
IT-Architekturen von Projekten zwischen 50 und 300 Manntagen werden oft ‚pragmatisch‘ aufgesetzt. Entweder man verwendet einen vorhandenen Lösungsbaukasten oder weicht auf scheinbar weniger ‚abstimmungsintensive‘ Fremdplattformen aus. Ich wundere mich immer wieder, dass durchaus geschäftsrelevante Applikationen sich aus Microsoft Access – Übergangslösungen entwickelt haben, oder sensible Applikationen komplett über IT-Frameworks bei einem externen Provider betrieben werden. Dies kann über die Lebenszeit der Applikation gerechnet zu sehr kostenintensiven Schnittstellenentwicklungen, hohen Migrationskosten und oft auch schlicht und ergreifend zu Datenverlusten führen. Das Lösungsdesign sollte daher nicht nur technisch für die aktuelle Projektphase, sondern monetär über den gesamten Lebenszyklus betrachtet werden. Fragen, die es für einen Zeitraum von 3-5 Jahren zu beantworten gilt, sind z.B.: Welche Anwendergruppen (interne und externe) werden die Applikation nutzen? Welche Drittsysteme (und Releasestände davon) werden potentiell angebunden werden müssen? Werden unternehmensinterne IT-Standards zu einer späteren Migration führen? Wie wird die inhaltliche und technische Wartung und Weiterentwicklung organisiert? Eine kritische Prognose bei der Beantwortung dieser Fragen hilft, die wahren Kosten scheinbar kleiner und pragmatischer Lösungen zu identifizieren und die IT-Architektur passend zu wählen.
Belastbare Fortschrittskontrolle der Entwicklungsstände
Der Klassiker in Statusbesprechungen ist die Frage an das Entwicklungsteam: „Könnt Ihr den Meilenstein einhalten und wie weit seit Ihr mit der Entwicklung gekommen?“ Die Antwort ist oft eine Schätzung nach bestem Wissen und Gewissen – aber eben oft aus dem Bauch heraus…
Der Projektleiter steht dann vor der Herausforderung die Fortschrittskontrolle und Risikoabschätzung auf dem Bauchgefühl der Entwickler aufzubauen und diese in Prozentzahlen zu verbrämen.
Viel besser und zugegeben auch etwas aufwändiger ist es, die Entwicklungsaufgaben in klare Pakete einzuteilen und diese dann über eine kombinierte Versions- und Aufwandsverwaltung zu kontrollieren. Dadurch kann zu jeder Zeit überprüft werden, ob das Entwicklungsteam die geplanten Aufwände pro Baustein einhält und welcher Trend der Fertigstellung sich ergibt. Das Projektcontrolling ist transparenter, Risiken können früher erkannt und Abweichungen in der Zeitplanung früher kommuniziert werden.
Interaktive OP-Listen für das gesamte Projektteam
Die ‚pragmatische‘ Abwicklung von IT-Projekten mittlerer Größe führt oft dazu, dass Anforderungen oder auch offene Punkte über eine Vielzahl von Medien verteilt abgelegt werden: Fachabteilungen führen Word-Dokumente, der Projektleiter arbeitet mit MS Project, das Entwicklungsteam organisiert sich mit Excel-Dateien, neue Anforderungen werden per e-Mail verteilt oder sind in Statusprotokollen versteckt. Es darf hier keinen wundern, dass wichtige Informationen nicht beachtet werden oder Ihren Adressaten gar nicht finden.
Die große Herausforderung ist daher, alle Projektbeteiligten auf eine gemeinsame „offene Punkte – Liste“ einzuschwören, die von allen eingesehen, gepflegt und kommentiert werden kann. Alle Fehler, neuen Anforderungen und offenen Punkte werden genau dort (und nur dort) eingetragen, mit Priorität, Fertigstellungstermin, Umsetzungsverantwortung und Status versehen und auch mit Aufwandsschätzungen zur Umsetzung hinterlegt. Diese Liste kann dann in jedem Statusmeeting gemeinsam ausgewertet und nachjustiert werden.
„One Stop Shop“ für Projektdokumentationen
Die obere Ausführung zu der OP-Liste gilt analog für Projektdokumentationen. Hier tummeln sich oft Word-Dokumente, Screen-Shots, Powerpoint-Präsentationen und „inline code“ – Dokumentationen, die jeweils in einer bestimmten Projektphase die Ergebnisse festhalten, aber beim Übergang in die nächste Phase oder das nächste Team nicht mehr weiterverwendet und weitergepflegt werden. Zum Projektende fehlt eine genaue Historie der Anforderungen und ein konsistenter Dokumentationsstand. Die Erfahrungen aus dem Projekt sind für Außenstehende kaum nachzuvollziehen.
Genau hier können die vielbesprochenen Enterprise 2.0 – Lösungen Abhilfe schaffen. Der Projektleiter führt ein Blog z.B. mit den Tags ‚Lessons learnt‘, ‚Beschluss‘ oder ‚Ideenspeicher‘ (alle offenen Punkte und Anforderungen sind ja in der OP-Liste 🙂 – siehe oben). Das gesamte Team nutzt ein einziges Wiki für die Fachkonzeption, Entwicklungsdokumentation und Schulungsinhalte. Auf Dokumente wird weitgehend verzichtet. Falls diese dennoch aufkommen, werden sie im Wiki oder einer verbundenen Dokumentenbibliothek abgelegt und mit Tags für die jeweilige Zielgruppe versehen.
Wichtig aus unserer Erfahrung ist: Nutzen Sie möglichst einen einzigen Ort (sei es ein Dokument oder ein Wiki), das fortlaufend überarbeitet und strukturiert wird. Dadurch werden Übergabeverluste, Einarbeitungsaufwände und Suchzeiten im Laufe des Projektes drastisch minimiert.
Usability-Tests von der Konzeptphase an
Usability-Tests werden (wenn überhaupt) mit fertigen Entwicklungsständen oder erst kurz vor GoLive mit dem Betastand der gesamten Anwendung durchgeführt. Dabei können Tests schon in der Konzeptphase mit interaktiven Mock-Ups (Klick-Dummy) oder auch nur mit Skizzen von Navigations- und Ablaufstrukturen durchgeführt werden. Nach unseren Analysen können Fehler oder missverstandene Anforderungen in dieser frühen Phase mit einem Bruchteil des Aufwandes und der Kosten behoben werden. Die Daumenregel für die Bearbeitung ein und derselben Änderung, betrachet jeweils in den verschiedenen Stadien, besagt: 1 Stunde Aufwand für die Änderung des Screens, 10 Stunden Aufwand für die Anpassung des Entwicklungsstandes, 30 Stunden Aufwand für die Anpassung der fertig ausgerollten Anwendung.
Projekt endet nicht mit dem Go-Live
„So, die Anwendung geht ja zum 31.07. online, so dass wir die Ressorcen ab 01.08. dann wieder für andere Projekte verplanen können“. Was stimmt hier nicht? Richtig: Das Projekt endet gar nicht mit dem Go-Live. Vielfach fängt dann eine sehr intensive Post-Go-Live-Phase an, in der eine Vielzahl von Punkten bearbeitet werden muss: Anwender (die die Applikation ja zum ersten Mal sehen und verwenden) melden trotz vorheriger Key-User-Tests Fehler, fehlende Funktionalitäten und neue Anforderungen. Die Dokumentaion muss erstellt werden 🙂 Die Projekterfarhungen müssen im Team aufgearbeitet werden (Wissensmanagement!). Aus den in der Regel noch offenen Punkten und den neuen Anforderungen muss eine Releaseplanung erstellt werden (keine Applikation wird so bestehen bleiben, wie sie am ersten Tag des Go-Live sichtbar ist!). Plant man die Projekte des Portfolios daher zu eng angrenzend an die Go-Live-Termine, kämpft man mit fehlenden Ressourcen und Überlastungen der Teams. Die Post-Go-Live-Phase sollte daher immer mit (10-15)% des Aufwandes, der bis Go-Live anfällt, geplant werden und ca. 50% der Ressourcen einbeziehen.
Keine Angst vor roten Ampeln
Mein absoluter Lieblingssatz des Projektleiters der Fachabteilung: „Herr Hirsch, Sie haben hier rote Ampeln im Status gesetzt. So können wir das dem Lenkungsausschuss aber nicht darstellen. Ich möchte das Projekt nicht durch kritische Diskussionen gefährden. Herr Dr. xy wird das sofort nutzen, um das Gesamtprojekt in Frage zu stellen!“
Und nun?? Ampeln sind dazu da, auch einmal auf „Rot“ zu stehen. Es muss ein gemeinsames Verständnis geben, dass damit Risiken ausgedrückt werden und Entscheidungen herbeigeführt werden müssen. Eine rote Ampel ist keine persönliche Kritik.
Ich hoffe, Ihnen mit diesen Erfahrungen für Ihre Projektabwicklung einige Ideen gegeben zu haben und wünsche viel Erfolg bei Ihren Vorhaben!
