Wenn ein klarer Auftrag fehlt … Projektbegleitende Auftragsklärung mit der Projektskizze

Viele IT-Projekte starten ohne klaren Projektauftrag. Der Projektleiter steht dann vor der Aufgabe, den Auftrag parallel zur Abwicklung zu definieren. Ein hilfreiches Werkzeug dafür ist die "Projektskizze". Sie dient dazu, systematisch immer mehr Details über das Projekt und seine Rahmenbedingungen zusammenzutragen, um schließlich den Projektauftrag, die Spezifikation des Projektergebnisses und die Abnahmekriterien festlegen zu können. Rüdiger Flockert erklärt in seinem Beitrag, welche Informationen eine solche Projektskizze enthält und wie sie in der Praxis angewendet wird.

 

Wenn ein klarer Auftrag fehlt … Projektbegleitende Auftragsklärung mit der Projektskizze

Viele IT-Projekte starten ohne klaren Projektauftrag. Der Projektleiter steht dann vor der Aufgabe, den Auftrag parallel zur Abwicklung zu definieren. Ein hilfreiches Werkzeug dafür ist die "Projektskizze". Sie dient dazu, systematisch immer mehr Details über das Projekt und seine Rahmenbedingungen zusammenzutragen, um schließlich den Projektauftrag, die Spezifikation des Projektergebnisses und die Abnahmekriterien festlegen zu können. Rüdiger Flockert erklärt in seinem Beitrag, welche Informationen eine solche Projektskizze enthält und wie sie in der Praxis angewendet wird.

 

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:

Geschäftsführer: Wir sollen für unseren Kunden, einen großen Automobilhersteller, eine vollständig neue Software für seine Niederlassungen, Händler und Werkstätten entwickeln und einführen. Eine geeignete Standardsoftware und der Lieferant, der den Softwarestandard anpasst, sind bereits gefunden. Wir sollen die landesspezifischen Anpassungen durchführen, den Roll-out in die fast 1.000 Standorte machen, Schulungen halten usw. Möchten Sie dafür die Projektleitung machen?
Ich: Mit den Standorten sind deutsche Standorte gemeint?
Geschäftsführer: Ja. Aber wenn wir erfolgreich sind, will ich das Modell auf Europa ausweiten. Da sprechen wir dann über mehrere tausend Standorte.
Ich: Was umfasst die Software funktional?
Geschäftsführer: Alles, was ein Autohaus benötigt. Also von der Zeiterfassung der Mitarbeiter über das Bestellwesen, die Showroom-Anwendung, die Werkstattunterstützung bis hin zum Marketing.
Ich: Und die ausgewählte Standardsoftware unterstützt all diese Bereiche?
Geschäftsführer: Manche teilweise; der Rest muss entwickelt oder zugekauft werden. Das ist Teil des Auftrags.
Ich: Wer ist der Auftraggeber und wer stellt das…

Bewertungen und Kommentare

Diese Funktion steht nur eingeloggten Nutzern zur Verfügung. Jetzt einloggen
0 Kommentare anzeigen & selbst mitreden!
Gesamt
Bewertungen 18
Kommentare 0