Einleitung

Abwicklung der Projekte

Das Phasenmodell bildet das Rückgrat des Projekts. Es gliedert den Lebenszyklus des Projekts und schafft die Voraussetzung für das gemeinsame Verständnis der Projektbeteiligten zum Projektablauf. Das in der Abbildung 11 abgebildete HERMES-Phasenmodell besteht aus vier Phasen:

1. Initialisierung
2. Konzept
3. Realisierung
4. Einführung

Das Projekt beginnt mit der Phase Initialisierung beim Meilenstein Projektinitialisierungsauftrag und endet am Schluss der Phase Einführung beim Meilenstein Projektabschluss.

Jedes Phasenende ist durch einen Meilenstein bestimmt, der den Entscheid zum weiteren Vorgehen hervorhebt. Diese Meilensteine entsprechen Quality Gates, an denen der Stand des Projekts und die Qualität der Projektplanung und -durchführung überprüft werden. Dabei erfolgt auch die Abstimmung mit den übergeordneten Strategien und Zielen der Stammorganisation. Die Überprüfung der Erreichung der Meilensteine erfolgt mit Checklisten, die mit projektspezifischen Kriterien ergänzt werden. Ergänzend zu den Meilensteinen an den Phasenenden gibt es szenariospezifische Meilensteine als weitere Quality Gates, z.B. Entscheid Typenwahl.

Entlang den Phasen und Meilensteinen erfolgt das Reporting gemäss den Vorgaben der Stammorganisation bezüglich Inhalt und Frequenz.

Das Phasenmodell bildet auch eine Grundlage für die finanzielle Steuerung des Projekts. Bei Phasenfreigabe werden die Mittel (finanziell, personell, Infrastruktur) für die nächste Phase durch den Projektauftraggeber freigegeben.

Projekte in einem Programm

Das Phasenmodell erleichtert die Koordination und Steuerung der Projekte in einem Programm (vgl. Abbildung 12). Es ist eine Voraussetzung für die Integration der Projekte in das Projektportfoliomanagement der Stammorganisation. Dadurch werden die Projekte übergeordnet durch die Stammorganisation steuerbar.

Anwendung des Phasenmodells

Grundsätzlich durchlaufen Projekte die Phasen sequentiell. Abhängig vom Projektgegenstand müssen einzelne Komponenten eines Gesamtsystems aber bereits realisiert sein, damit ein Truppenversuch durchgeführt werden kann. Die Darstellung zeigt, dass beispielsweise ein Teilprojekt 'IT-System' bereits die Phasen Konzept und Realisierung durchlaufen hat, damit das IT-System für die Durchführung des Truppenversuchs zur Verfügung steht. Das Gesamtprojekt befindet sich noch in der Phase Konzept.

Beschreibung der Phasen

Die folgende Aufstellung beschreibt die Phasen mit ihrem jeweiligen Schwerpunkt:

1. Initialisierung
2. Konzept
3. Realisierung
4. Einführung

Phasenmodell und Anforderungen

Die Anforderungsdefinition und die Systementwicklung erfolgen entlang den Projektphasen.

Die Anforderungen werden erstmals hinsichtlich dem Projektinitialisierungsauftrag grob erarbeitet (Ergebnis Grobanforderungen - siehe Lebenswegphase Militärische Gesamtplanung). Sie werden nach dem Prinzip 'vom Groben ins Detail' in den weiteren Projektphasen konkretisiert.

Die Abbildung 14 zeigt schematisch die Ergebnisse der Anforderungsdefinition und Systementwicklung von System / Material und IT:

1. In der Phase Initialisierung werden in der Projektstudie die Ziele festgelegt und die Anforderungen so weit konkretisiert, dass Varianten gebildet und bewertet werden können. Auf der Grundlage der Variantenwahl wird der Projektauftrag erstellt.
2. In der Phase Konzept werden die technischen Anforderungen auf der Basis der Anforderungen detailliert und vervollständigt. Sie dienen als verbindliche Basis für die Offertanfragen.
3. Bei IT-Systemen wird auf der Grundlage des Angebots des Lieferanten und den Systemanforderungen die Detailspezifikation erstellt sowie das System entwickelt. Dazu gehört auch das Testen als Voraussetzung für den Entscheid zur Abnahme.
4. Bei System / Material wird auf der Grundlage der Spezifikation das System / Material hergestellt. Es wird dann entlang den Spezifikation abgenommen.
5. In der Phase Einführung wird das IT-System aktiviert und dem Betreiber übergeben.

Bei Anforderungen wird zwischen funktionalen Anforderungen, Qualitätsanforderungen (nicht funktionale Anforderungen) und Randbedingungen unterschieden. Anforderungen sollten nie die Lösung beschreiben und somit die Typenwahl präjudizieren, sondern das Bedürfnis respektive die Eigenschaft eines Systems beschreiben. Der Lösungsraum kann allenfalls durch Randbedingungen eingeschränkt werden. Dies wäre zum Beispiel der Fall, wenn es Government Furnished Equipment (GFE) oder bereits spezifizierte Schnittstellen zu Umsystemen bzw. bestehenden Services gibt. Anforderungen werden auch auf Grund ihrer rechtlichen Verbindlichkeit unterschieden. Dabei wird zwischen vertragsrechtlich bindenden (MUSS), dringend empfohlenen (SOLLTE) und zukünftigen (WIRD) Anforderungen differenziert. Wünschenswerte Anforderungen werden aus wirtschaftlichen Gründen nicht berücksichtigt. MUSS-Anforderungen müssen durch die Anbieter erfüllt werden (Killer-Anforderungen). Bei SOLLTE-Anforderungen sind die Anbieter frei, die eine oder andere Anforderung nicht zu erfüllen. Aus diesem Grund ist immer darauf zu achten, dass alle Angebote einen Mindestnutzwert erreichen. Es ist auch empfohlen, die SOLLTE-Anforderungen zu priorisieren und entsprechend zu gewichten. WIRD-Anforderungen sind zukunftsorientiert und werden den Anbietern nicht mitgeteilt. Sie werden dokumentiert, damit sie zu einem späteren Zeitpunkt verfügbar sind. Bei diesen Anforderungen ist zu beachten, dass sie unter Umständen bereits von Beginn weg in den nicht funktionalen Anforderungen berücksichtigt werden müssen. Sie können z.B. die Systemdesign-Auslegung beeinflussen.

Um Anforderungen systematisch und diszipliniert zu spezifizieren sowie zu verwalten, wird als Methode Requirements Engineering (RE) eingesetzt. Empfohlen wird der IREB-Standard (IREB ist das International Requirements Engineering Board) für Requirements Engineering. Entsprechend wird auch eine Aus- und Weiterbildung mit Zertifizierung empfohlen (Certified Professional for Requirements Engineering SAQ/IREB).

Requirements Engineering dient zur Qualitätssteigerung der Anforderungen und Anforderungsdokumente. An Hand von zahlreichen Kriterien soll nach Ermittlung und Dokumentation der Anforderungen diese Qualität geprüft und abgestimmt werden. Unter anderen wichtiges Kriterium ist die Vollständigkeit: diese soll sicherstellen, dass auch implizite Anforderungen - die risikoreichste Art von Anforderungen - identifiziert und dokumentiert werden. Im komplexen Umfeld der zahlreichen Rollen und über die Projektphasen wechselnden Verantwortungen spielt die Verfolgbarkeit von Anforderungen eine weitere zentrale Rolle. Essenziell ist für die Anwender zu verstehen, dass Requirements Engineering nicht einfach eine zusätzliche Methode, sondern der Weg zu besseren Anforderungen und somit zu einem besseren System ist. Requirements Engineering anzuwenden braucht neben der erwähnten Ausbildung viel praktische Erfahrung und die notwendige Geduld. Die Nutzung von Tools unterstützt das Requirements Engineering, ist aber keine Garantie für Qualität. Entscheidend bleibt die disziplinierte und inhaltliche nach Requirements Engineering komplette Formulierung der Anforderungen.

Die Abbildung 15 zeigt schematisch den Weg von Grobanforderungen zu Spezifikationen im Rahmen der Projektphasen entlang der Verbindlichkeit.

Die Darstellung ist allgemein gültig, kleine Anpassungen können in Ausnahmefällen vorkommen. Folgendes ist jedoch unbedingt zu beachten:

1. Die Verbindlichkeit und Gewichtung der Anforderungen sowie die Anforderungen selbst können im Rahmen eines Änderungsmanagement-Prozesses bis zum Zeitpunkt der Offertanfrage geändert werden. Dies erfolgt in HERMES mit der Aufgabe 'Änderungsmanagement führen'. Der Zweck ist, das oben erwähnte Vorgehensprinzip 'vom Groben ins Detail' formell zu unterstützen.
2. Die technischen Anforderungen sind die Anforderungen, die durch die Anbieter umgesetzt werden müssen oder sollten. Mit dem erteilten Zuschlag ist auf Grund des Pflichtenhefts bzw. Angebots des gewählten Lieferanten klar vereinbart, welche SOLLTE-Anforderungen letztendlich umgesetzt werden. Somit kann die Spezifikation definitiv erstellt werden. Diese ist dann integraler Bestandteil des Vertrages. In Entwicklungsprojekten sind die technischen Anforderungen und das Pflichtenheft des Angebotes vertraglicher Bestandteil.
3. Mit dem Auftrag bzw. mit der Realisierung werden die Anforderungen dem Ersteller übergeben. Er übernimmt in der Phase Realisierung die Arbeiten, die durch die Methode RE-V vorgegeben werden. Diese werden in seiner eigenen Umgebung bzw. mit Hilfe seiner eigenen Tools durchgeführt. Spätestens bei Abnahme des Systems werden die Daten des Requirements Engineering dem Beschaffer in der vereinbarten Form wieder übergeben (Lösungsraum).

Entscheidungsprozess

Entscheidungsprozess generell

In der Projektdurchführung müssen Entscheide getroffen werden. Die Entscheide sind in den Modulen als Aufgaben definiert. Aufgaben, die zu einem Entscheid führen, enden mit einem Meilenstein.

HERMES unterscheidet zwischen Entscheiden, welche durch die Steuerung und / oder die Stammorganisation getroffen und Entscheiden, welche durch die Projektführung und Fachspezialisten getroffen werden. So erfolgt beispielsweise die Phasenfreigabe durch den Projektauftraggeber und die Stammorganisation (Steuerung).

Die Steuerung und die Stammorganisation prüfen am Ende einer Phase, ob die nötigen Fachentscheide vorliegen. Fehlen diese, wird die nächste Phase nicht frei gegeben. Die Steuerung fällt dadurch keine Entscheide ohne über die nötige Fachkompetenz zu verfügen.

Die Entscheidungsaufgaben in HERMES, bzw. die Entscheidungsprozesse werden mit der Checkliste unterstützt.

Die Abbildung 16 zeigt als Beispiel die Entscheide der Steuerung sowie der Führung und Ausführung im Szenario Beschaffung Verteidigung.

Abbildung 16: Entscheide im Szenario Beschaffung Verteidigung

Entscheide der Steuerung und der Stammorganisation

Auf der Steuerungsebene entscheidet der Projektauftraggeber und / oder die Stammorganisation. Sie entscheiden über die Projektfreigabe, Phasenfreigaben und den Projektabschluss sowie weiteren Meilensteinen. Bei Bedarf wird der Projektauftraggeber durch weitere Rollen wie den Projektausschuss unterstützt, die ihn beraten.

Die nachfolgende Tabelle zeigt die Meilensteine, bei denen der Projektauftraggeber und / oder die Stammorganisation Entscheide treffen sowie die für den Entscheid benötigten Ergebnisse Zustände, Unterlagen.

Entscheid zur Projektfreigabe

Die Projektfreigabe erfolgt am Ende der Initialisierung. Der Entscheid wird gemeinsam durch den Projektauftraggeber und die Stammorganisation im Rahmen des Projektportfoliomanagements getroffen.

Es wird entschieden, ob

1. die Phase Initialisierung abgeschlossen wird oder ob weitere Ergebnisse zu erarbeiten sind
2. das Projekt freigegeben wird
3. das Projekt zurzeit nicht freigegeben wird und es später nochmals beantragt werden soll
4. das Projekt nicht freigegeben und das Vorhaben beendet wird

Entscheid zur Phasenfreigabe

Bei jeder Phasenfreigabe werden die Ziele des Projekts mit den Strategien der Organisation und den Vorgaben abgestimmt und die Zielorientierung des Projekts sowie seine Wirtschaftlichkeit überprüft.

Es wird entschieden, ob

1. die Phase abgeschlossen wird oder ob vor dem Phasenabschluss weitere Ergebnisse zu erarbeiten sind
2. die nächste Phase freigegeben wird
3. das Projekt beendet wird

Der Projektauftraggeber prüft bei Phasenende, ob die notwendigen Abnahmen der Ergebnisse durch die Controlling- und Vorgabestellen sowie die Fachspezialisten erfolgt sind und die Ergebnisse der Phase seinen Erwartungen entsprechen.

Die Abbildung 17 zeigt einen typischen Entscheidungsprozess am Beispiel der Freigabe der Phase Konzept.

Die Abbildung 17 zeigt, dass auf der Steuerungsebene der Phasenbericht abgenommen und die Phase Konzept abgeschlossen werden. Vorgängig werden auf den Ebenen der Führung und der Ausführung die Projektergebnisse mit den Stakeholdern sowie Controlling- und Vorgabestellen abgestimmt bzw. durch diese geprüft. Wenn die Voraussetzungen erfüllt sind, gibt der Projektauftraggeber die Phase Konzept frei.

Entscheid zum Projektabschluss

Am Ende der Phase Einführung treffen der Projektauftraggeber und die Stammorganisation den Entscheid zum Projektabschluss.

Es wird entschieden, ob

1. das Projekt abgeschlossen wird oder ob vor dem Projektabschluss weitere Ergebnisse zu erarbeiten sind
2. die Projektorganisation aufgelöst wird

Entscheide der Führung und Ausführung

Entscheide zu Projektergebnissen

Prüfung und Abnahme von technischen Ergebnissen erfolgen durch die Führung und Ausführung, d.h. durch die jeweiligen Spezialisten für das entsprechende Thema.

Der Projektleiter plant die Entscheidungsaufgaben. Er berücksichtigt die Vorgaben der Controlling- und Vorgabestellen der Stammorganisation.