Viele IT-Projekte starten ohne einen klar umrissenen Projektauftrag. Der Projektleiter steht in diesem Fall vor der Aufgabe, den Auftrag parallel zur Abwicklung zu definieren. Ein sehr hilfreiches Werkzeug dafür ist eine "Projektskizze". Sie dient dazu - ausgehend von den zu Beginn lückenhaften Informationen - systematisch immer mehr Details über das Projekt und seine Rahmenbedingungen zusammenzutragen. Schritt für Schritt entstehen so in einem dokumentierten Prozess der eigentliche Projektauftrag, die Spezifikation des Projektergebnisses und die Abnahmekriterien. Im Folgenden erläutere ich zunächst die Problematik der unklaren Auftragsstellung. Anschließend erkläre ich, welche Informationen eine Projektskizze enthält und wie sie in der Praxis angewendet werden kann.

Klare Aufträge sind in IT-Projekten selten

Projektbegleitende Auftragsklärung - ist das nicht ein Widerspruch in sich? Jeder angehende Projektleiter lernt, dass ein Projekt gekennzeichnet ist durch ein definiertes Ziel, ein Anfangs- und Endedatum, ein festes Budget und weitere Randbedingungen. Zu Letzteren gehören zum Beispiel Mitarbeiter, die für bestimmte Rollen vorgesehen sind, die Einbettung der Projektorganisation in die Gesamtorganisation oder die Hard- und Software-Umgebung.

Eine solche geordnete Ausgangssituation ist allerdings nur in Unternehmen mit einem sehr hohen Projektmanagement-Reifegrad anzutreffen. Auch projektorientierte Unternehmen, die ihren Umsatz nahezu vollständig mit Projektarbeit erwirtschaften, betreiben viel Aufwand, um die Projektaufträge von Anfang an so exakt wie möglich zu klären. Dies ist beispielsweise im Anlagenbau der Fall.

In anderen Branchen und besonders bei internen Software-Entwicklungen dürfte jedoch kaum je ein Projektleiter bei der Auftragsvergabe diese Idealbedingungen in der Praxis vorgefunden haben. Und wenn ja - wie lange hatten sie Bestand? Meiner Erfahrung nach laufen IT-Projekte selten so ab, wie es nach Vorgabe allgemein anerkannter Projektmanagementsysteme und -standards ablaufen sollte. Je größer das Projekt ist, desto weniger halten sich die Entscheider an formale Vorgaben. Ist die Vorstellung, ein IT-Projekt sei eine fixe Größe in einer sich ständig ändernden Umwelt, also in Wahrheit lediglich eine Idealisierung?

Unvermeidbar: Anpassungen und Korrekturen

In jeder Projektphase werden Unzulänglichkeiten der vorherigen Phasen erkannt und behoben. Nehmen wir zum Beispiel ein Projekt für eine Anwendungsentwicklung: Ist das neue Verfahren in Produktion, werden Änderungen über einen definierten Änderungsprozess des Anforderungsmanagements eingebracht. In der Abnahmephase werden Abweichungen des Software-Systems von seinem Entwurf und seiner fachlichen Spezifikation festgestellt und behoben. Im Integrationstest werden Fehler erkannt - insbesondere an den Teilen der Schnittstellen, die bisher nicht getestet wurden.

Änderungen sind Alltag - trotz einer intensiven Abnahmeperiode, eines ausgefeilten Fachkonzepts und eines mehrfach qualitätsgesicherten Datenbankentwurfs. Zum einen ändert sich die Umgebung des Fachverfahrens, sodass zwangsläufig technische, fachliche und organisatorische Anpassungen notwendig werden. Zum anderen ist es für Fach-, Organisations- und IT-Abteilungen unmöglich, sämtliche Aspekte eines Systems lückenlos zu planen, zu entwerfen und zu realisieren.

Projektmanagement-Systeme wie z.B. das V-Modell oder PRINCE2 enthalten komplette Änderungssysteme oder berücksichtigen Änderungen zumindest in ihrem Prozessmodell. Letzteres gilt zum Beispiel für den PMBOK Guide. Diese Prozesse tragen der Tatsache Rechnung, dass aufgrund der Komplexität des Systems und der Veränderungen in der Systemumgebung ein Projekt keine so fixe Größe ist wie es die allgemeinen Definitionen suggerieren. Allerdings gehen all diese Managementsysteme davon aus, dass zumindest ein klar umrissener Projektauftrag mit den wesentlichen Projektzielen, dem Projektgegenstand sowie Zeit und Budget existiert. In der Praxis ist dies aber leider häufig nicht der Fall.

Oft dasselbe: Idee und Projektauftrag

Wie entsteht ein Projektauftrag? Meist ist es doch so, dass jemand aus der Unternehmensführung oder der Leiter eines Fachbereichs eine Idee hat. Diese Idee hat keinen detaillierten Business Case, oft ist sie nicht mehr als ein Schlagwort oder ein Einzeiler. In vielen Fällen wird der Projektauftrag erteilt, bevor die Idee ausreichend präzisiert wurde. Ein Gespräch, das ich mit meinem Geschäftsführer geführt habe, veranschaulicht dieses Phänomen: