Reverse-Tailoring – Ein Verfahren zur Projektplanung und ...

Christian Roth: Reverse-Tailoring- Ein Verfahren zur Projektplanung und Aufwandschätzung Seite 3
Erschienen im Objektspektrum 02/2012 www.sv-gutachten.de
Der gesamte Projektaufwand lässt sich also erst ermitteln, wenn man neben den über die
Features bestimmten Release-Aufwänden auch alle weiteren Aufwandspositionen in den
Release-Rahmen und dem Gesamtprojekt-Rahmen kennt.
Die genannten „Rahmen“, das „Drumherum“, werden über die nachfolgend erläuterten
Projektvorgehensweisen bestimmt. Entscheidend ist zunächst, dass eine tragfähige Aufwandschätzung
ohne Berücksichtigung der Projektvorgehensweisen nicht zu Stande
kommt bzw. dass die Betrachtung allein der fachlichen Release-Aufwände zu kurz greift.
Auch, wenn die über die Fachfunktionen hinausgehenden Anforderungen vereinzelt im
Vertrag oder im Anforderungsdokument vorkommen, eine Gewähr für die notwendig vollständige
Erfassung aller Projektanforderungen bietet das ebenso wenig, wie sich eigene,
unternehmensinterne Vorgehenspraktiken dabei einbeziehen lassen. Hierzu bedarf es einer
systematischen Herangehensweise.
Diese gewinnt zusätzlichen Wert über die Aufwandschätzung hinaus auch dadurch, als
dass ein der Aufwandschätzung zu Grunde gelegtes, definiertes und adäquates Projektvorgehen
natürlich auch die Grundlage für die spätere Projektsteuerung bildet, der insbesondere
in agilen Projekten ein hoher Stellenwert zukommt. Vor diesem Hintergrund wäre
es geradezu sträflich, mit pauschalen Zuschlägen beim Aufwand zu arbeiten oder notwendige
Projektschritte einfach auszublenden.
Projektplanung – wie man es nicht machen sollte
Trotz aller berechtigter Begeisterung über Scrum [4] und ähnlicher Agiler Vorgehensweisen
ersetzt Agilität als primär Zusammenarbeits-Paradigma kein Vorgehensmodell – die
Hoffnung, über Agilität allein zu einer Systematik des Projektvorgehens zu finden, ist deswegen
unberechtigt. Geeigneter erscheinen da schon die gängigen Vorgehensmodelle.
Diesen ist i.d.R. auch gemein, dass sie sich über das sog. „Tailoring“ an konkrete Projekterfordernisse
anpassen lassen – ist das nicht genau die Systematik, nach der wir suchen?
Fast, wenn da nicht der berühmte „Teufel im Detail“ stecken würde. Betrachten wir zur
Erläuterung beispielhaft das V-Modell XT [3]. Es berücksichtigt moderne Projektkonzepte
wie Komponentenorientierung, Standardsoftware-Integration und sogar Agilität, es differenziert
verschiedene Projektszenarien für das Tailoring und es bietet sogar eine Werkzeugunterstützung
dafür an.
Haben Sie das schon einmal für ein konkretes Projekt ausprobiert? Sie nehmen sich die
gut 800 Seiten V-Modell, müssen sich, jedenfalls dann, wenn Sie nicht gerade jede Woche
damit arbeiten, zuerst einarbeiten, „tailoren“ danach auf Ihre Anforderungen und sind das
erste Mal erstaunt: Aus den 800 ursprünglichen Seiten sind um die 500 geworden. Das
macht die Sache besser, aber nicht gut, denn zum zweiten Mal sind sie erstaunt festzustellen,
dass viele Spezifika Ihrer Projektsituation trotz Tailorings leider noch nicht in Ihrem
Modell enthalten sind. Und so kommt „das dicke Ende“ zum Schluss: Der Versuch, in 500
Seiten getailortem Modell eigene Projektspezifika unter zu bringen, endet spätestens nach
zwei bis drei Tagen mehr oder weniger ergebnislos – dann nämlich werden Sie gefragt,
warum das alles so lange dauert und so kompliziert ist.
Trösten Sie sich, Sie nicht allein und eine Antwort auf das „so lange“ und „so kompliziert“
können Sie jetzt auch geben: Das V-Modell Tailoring ist für die Praxis in dieser Form
schlicht nicht geeignet! Dabei bezieht sich die Kritik nicht allein auf den Tailoring-