4 Teil 5: V-Modell-Referenz Produkte
4.3 Produkte
4.3.1 Planung und Steuerung
4.3.1.3 Projekthandbuch
|
Vorgehensbaustein |
Sinn und Zweck
Das V-Modell ist ein generischer Vorgehensstandard, der für ein konkretes Projekt angepasst und konkretisiert werden muss. Das Projekthandbuch legt die für Management und Entwicklung notwendigen Anpassungen und Ausgestaltungen fest. Somit dokumentiert es Art und Umfang der Anwendung des V-Modells im Projekt und ist Informationsquelle und Richtlinie für alle Projektbeteiligten.
Das Projekthandbuch beinhaltet eine Kurzbeschreibung des Projekts, die Beschreibung des Tailoring-Ergebnisses, den grundlegenden Projektdurchführungsplan, die notwendige und vereinbarte Unterstützung des Auftraggebers sowie Organisation und Vorgaben für die Planung und Durchführung des Projekts und die anstehenden Entwicklungsaufgaben. Der Projektleiter muss dieses zentrale Produkt in Abstimmung mit den Schlüsselpersonen des Projekts erarbeiten.
Dabei werden im Projekthandbuch auch insbesondere Häufigkeit und Notwendigkeit der Erzeugung weiterführender Produkte, die für die Planung und Durchführung des Projekts, für das Ausschreibungs- und Vertragswesen sowie für die Prozessverbesserung notwendig sind, festgelegt, zum Beispiel Projektstatusberichte, Risikolisten, Verträge und Bewertungen von Vorgehensmodellen.
Wann ist das Produkt entscheidungsrelevant?
|
Entscheidungspunkt |
Wer ist beteiligt?
Womit kann das Produkt erstellt werden?
|
Werkzeuge |
|
|
Methoden |
Keine |
Welche Vorlagen sind verfügbar?
|
Vorlagen |
Produktvorlage wird generiert. Projektorganigramm (Teil der SOS-Methode): Vorlagen/SOS-GrossPM/GrossPM_6.1-1_Projektorganigramm_detailliert_v1.0.ppt Kommunikationsplanung (Teil der SOS-Methode): Vorlagen/SOS-GrossPM/GrossPM_6.3-2_Kommunikationsplan_v1.0.ppt Projekthandbuch (Teil der SOS-Methode): Vorlagen/SOS-GrossPM/GrossPM_6.3-6_Projekthandbuch_v1.0.doc Beistellungsliste (Teil der SOS-Methode): Vorlagen/SOS-GrossPM/GrossPM_7.1-2_Beistellungsliste_v1.0.xls Änderungsverfahren (Teil der SOS-Methode): Vorlagen/SOS-GrossPM/GrossPM_7.2-1_Aenderungsverfahren.ppt |
|
Beispielprodukte |
Wie erstellt man das Produkt?
|
Aktivität |
Projekthandbuch erstellen |
Mit dem Projekthandbuch werden die organisatorischen Rahmenbedingungen für alle Projektbeteiligten festgelegt. Insbesondere neuen Teammitgliedern dient das Projekthandbuch als Einstiegspunkt und Informationsquelle. Wichtiger Bestandteil des Projekthandbuchs ist die Festlegung der Art und Weise, in der das V-Modell im Projekt zur Anwendung kommt.
Die Erstellung des Projekthandbuches ist Teil der Projektinitialisierung. Ändern sich jedoch im Projektverlauf die Rahmenbedingungen des Projektes, dann muss das Projekthandbuch fortgeschrieben werden.
Bei der Erstellung ist zunächst das Anwendungsprofil festzulegen und auszuwerten. Projektspezifische Anpassungen sind vorzunehmen, um auf diese Weise eine geeignete Projektdurchführungsstrategie zu ermitteln. Daraufhin ist die Projektdurchführung zu planen und mit allen Projektbeteiligten abzustimmen. Dieses Vorgehen kann solange wiederholt werden, bis die Abstimmung erfolgt ist. Erst dann erfolgt der Kick-Off des Projekts.
Folgende Teilschritte sind dabei enthalten:
- Anwendungsprofil erstellen und auswerten
- Projekthandbuch mit allen Projektbeteiligten abstimmen
- Projektdurchführung planen
- Projekt-Kick-Off vorbereiten und durchführen
- Projektspezifische Anpassung durchführen
- Projektspezifische Anpassung zur Projektlaufzeit durchführen
Welche Abhängigkeiten hat das Produkt?
4.3.1.3.1 Projektüberblick, Projektziele und Erfolgsfaktoren
Das Projekthandbuch ist eine unverzichtbare Informationsquelle und Richtlinie für alle Projektbeteiligten. In diesem Thema wird kurz, prägnant und möglichst plastisch das gemeinsame Projektleitbild dargestellt.
4.3.1.3.2 Teilprojekte
Auf der Basis einer Skizze des Lebenszyklus und der Gesamtsystemarchitektur, den Funktionale Anforderungen und den Nicht-Funktionale Anforderungen des Gesamtprojektes werden die Teilprojekte festgelegt. Die Festlegung der Teilprojekte enthält die Anzahl der Teilprojekte, eine Kurzbeschreibung der Teilprojekte, die wichtigsten Teilprojekt-Entscheidungspunkte, die Zuordnung der funktionalen und nicht-funktionalen Anforderungen zu den Teilprojekten und die Abdeckung der Elemente der Gesamtsystemarchitektur durch die Teilprojekte.
Dabei wird auch ein Teilprojekt Integration festgelegt, das die Ergebnisse aller anderen Teilprojekte zum Gesamtprojekt integriert.
Das Teilprojekt Integration beschreibt die Reihenfolge der zu integrierenden Teilprojekte, die besonderen Verfahren oder Methoden zur Integration der Teilprojektergebnisse, die Termine, Aufwände, Verantwortliche und Ressourcen.
4.3.1.3.3 Projektspezifisches V-Modell
Das V-Modell ist ein generisches Vorgehensmodell. Die projektspezifische Anpassung - das so genannte Tailoring - wird in diesem Thema dokumentiert. Das dabei zu erstellende Anwendungsprofil, der resultierende Projekttyp, die zu verwendenden und zusätzlich ausgewählten Vorgehensbausteine sowie die ausgewählten Projektdurchführungsstrategien sind dabei festzuhalten. Im Rahmen dieses Themas können auch die Umstände und Konsequenzen von bereits vorhersehbarem, dynamischem Tailoring festgehalten werden. Alle diese Festlegungen sind entsprechend den Vorgaben des V-Modells zu begründen (siehe dazu auch Abschnitt Projektspezifische Anpassung - Tailoring im Teil 1: Grundlagen des V-Modells).
4.3.1.3.4 Abweichungen vom V-Modell
Sämtliche Abweichungen von den Vorgaben des V-Modells, wie Streichungen einzelner Produkte, Aktivitäten und Abweichung vom Tailoring-Verfahren, müssen unter Angabe von Gründen dokumentiert werden. Die Änderungen sind in diesem Thema aufzuführen.
4.3.1.3.5 Projektdurchführungsplan
Das V-Modell macht durch die Festlegung von Entscheidungspunkten Vorgaben zur groben Strukturierung des Projekts. Dieses Thema enthält die planerische Ausgestaltung dieser Entscheidungspunkte in Form eines Projektdurchführungsplans. Hierbei sind zumindest der Projektanfang, das Projektende und alle wichtigen Entscheidungspunkte während des Projekts einzuplanen.
Darüber hinaus können noch weitere projektspezifische Meilensteine festgelegt werden, soweit diese für alle Projektbeteiligten relevant sind. Meilensteine, die nur projektintern relevant sind, werden im Projektplan dokumentiert.
4.3.1.3.6 Organisation und Vorgaben zum Projektmanagement
In diesem Thema werden die Vorgaben des V-Modells zum Projektmanagement angepasst und konkretisiert. Es werden alle internen und externen Projektbeteiligten aufgeführt. Die verantwortlichen Ansprechpartner sind dabei namentlich zu benennen. Darüber hinaus werden die Schlüsselrollen des V-Modells, wie Projektleiter, QS-Verantwortlicher und Systemarchitekt, mit Personen besetzt und deren Aufgaben und Verantwortlichkeiten entsprechend den V-Modell-Vorgaben ausgestaltet.
Die grundlegende Organisation und Durchführung der Zusammenarbeit zwischen allen Projektbeteiligten wird definiert. Dabei werden beispielsweise Besprechungen, das Vorgehen für Abstimmungsrunden, das Konfliktmanagement, die Eskalationsstrategie, die Bedingungen für die Durchführung eines formalen Entscheidungsprozesses festgelegt und dokumentiert. Zusätzlich werden Schwellenwerte definiert, deren Überschreitung zur Einleitung von Steuerungsmaßnahmen führt. Ein Beispiel dafür ist die Überschreitung von Sollwerten für die Planung um mehr als 15%. Organisationsweite Vorgaben müssen dabei berücksichtigt werden.
Für die im Rahmen des Projektmanagements zu erstellenden V-Modell-Produkte, wie Projektplan, Aufgabenliste und Projekttagebuch, wird festgelegt, ob und wann diese zu erstellen sind, nach welchen Methoden, Richtlinien und Standards diese Produkte auszuarbeiten sind und mit welchen Werkzeugen beziehungsweise Bestandteilen der Projektmanagement-Infrastruktur sie bearbeitet werden (siehe dazu auch Abschnitt Erzeugende Produktabhängigkeiten).
Das Projektorganigramm verbildlicht die aufbauorganisatorische Projektstruktur, beispielsweise die Untergliederung eines Projekts in Teilprojekte bzw. die Zusammensetzung des Projekts aus einzelnen Teams. Dabei sollte auch die Auftraggeber/Auftragnehmer-Konstellation beachtet werden. Außerdem sollte das Projektorganigramm die Beziehungen der Führungs- und Managementrollen (beispielsweise Lenkungsausschuss, Projekteigner, Projektleiter, Projektmanagementbüro) aufzeigen.
In großen Projekten enthält es die Aufteilung des Gesamtprojekts in Verantwortungsbereiche und Teilprojekte (einschließlich Aufgabenabgrenzung zwischen den Teilprojekten) und dokumentiert, wer für welche Teile verantwortlich ist. Ggf. kann für einzelne Rollen auch deren konkrete Besetzung im Projektorganigramm dargestellt werden.
Die im Projektorganigramm dokumentierte Struktur ist unabhängig von den Aufbauorganisationen der beteiligten Behörden oder Unternehmen. Die Aufteilung auf Verantwortungsbereiche und Teilprojekte orientiert sich an Projektinhalten, die in der Definition des Projektumfangs und letztendlich im Projektstrukturplan beschrieben sind und ist Basis für den Ressourcen- und Organisationsplan . Das Projektorganigramm bleibt im Projektverlauf meist relativ stabil, kann aber jederzeit an aktuelle Entwicklungen angepasst werden.
Die Rollenbeschreibungen machen deutlich, welche Projektrolle welche Aufgaben wahrnimmt, welche Kompetenzen ihr zugeordnet sind und welche Verantwortung sie im Projektkontext hat. Die Rollenbeschreibungen stellen sicher, dass alle benötigten Aufgaben wahrgenommen werden und keine Aufgaben doppelt oder mit unklarer Verantwortung vergeben werden. Entspricht das Rollenmodell des Projekts dem Rollenmodell im V-Modell, so reichen hier meist Verweise auf die V-Modell-Dokumentation. Weicht das Rollenmodell im Projekt vom V-Modell-Rollenmodell ab, so sollte zumindest versucht werden, eine entsprechende Zuordnung zu finden.
Projektmitarbeiter und Rollenbesetzung
Im Projekthandbuch werden alle Projektmitarbeiter nebst ihrer Kontaktdaten aufgelistet. Außerdem wird für jeden Mitarbeiter festgelegt, welche Rollen er im Projekt einnimmt oder einnehmen kann und in welchen Teilprojekten oder Teams er eingesetzt wird.
4.3.1.3.7 Organisation und Vorgaben zum Risikomanagement
Damit die Einschätzungen der Risiken innerhalb des Projekts nach denselben Maßstäben erfolgen, wird das im V-Modell bereits vorgesehene Risikomanagement in diesem Thema ausgestaltet und konkretisiert. Dabei ist die generelle Entscheidung zu treffen, ob neben Risiken auch Chancen betrachtet werden sollen. Für Chancen wird das gleiche Verfahren wie für Risiken angewendet, deshalb wird im Folgenden nicht mehr zwischen den Begriffen Chance und Risiko unterschieden.
Hier erfolgt die Festlegung, wann und nach welchen Kriterien Risiken in einer Risikoliste dokumentiert werden. Zusätzlich muss definiert werden, mit welchen Methoden, Richtlinien und Standards und mit welchen Werkzeugen beziehungsweise Bestandteilen der Projektmanagement-Infrastruktur das Risikomanagement durchzuführen ist.
Dabei sind im Einzelnen die folgenden Punkte festzulegen:
- Risikoklassen zur Einstufung von Risiken
- Kriterien zur Risikoakzeptanz
- Eskalationsstufen basierend auf den definierten Risikoklassen, entsprechend den Vorgaben des Themas Organisation und Vorgaben zum Projektmanagement
- Verfahren für die Dokumentation der identifizierten Risiken und der geplanten Maßnahmen
- Zeitpunkte und Vorgehen bei der Risikoidentifizierung
- Zeitpunkte für die Neubewertung von Risiken
- Zeitpunkte und Verfahren für die Planung und Durchführung von Gegenmaßnahmen
4.3.1.3.8 Organisation und Vorgaben zum Problem- und Änderungsmanagement
In diesem Thema wird das im V-Modell bereits vorgesehene Problem- und Änderungsmanagement ausgestaltet und konkretisiert. Es erfolgt die Festlegung, ob, wann und welche Problemmeldungen und Änderungsanträge erstellt werden müssen, nach welchen Methoden, Richtlinien und Standards diese zu bearbeiten sind und mit welchen Werkzeugen beziehungsweise Bestandteilen der Projektmanagement-Infrastruktur sie weiterverarbeitet werden.
Dies beinhaltet beispielsweise die Definition der vorgesehenen Status von Problemmeldungen und Änderungsanträgen (erstellt, genehmigt und abgelehnt) die Besetzung der Änderungssteuerungsgruppe (Change Control Board) sowie das Konfliktmanagement und die Eskalationsstrategie. Dabei kann es erforderlich sein, mehrere Änderungsverantwortliche und Änderungssteuerungsgruppen (Change Control Boards) mit unterschiedlicher Entscheidungskompetenz und Zusammensetzung einzurichten.
Bei unterschiedlichen Auffassungen in einer Änderungssteuerungsgruppe (Change Control Board) werden Eskalationsstufen definiert. Beispielsweise kann eine mit größerer Entscheidungskompetenz ausgestattete Änderungssteuerungsgruppe (Change Control Board) oder ein Lenkungsausschuss als Eskalationsinstanz festgelegt werden.
4.3.1.3.9 Organisation und Vorgaben zum Konfigurationsmanagement
In diesem Thema wird das im V-Modell bereits vorgesehene Konfigurationsmanagement ausgestaltet und konkretisiert. Es erfolgt die Festlegung, welche Produktexemplare wann nach welchen Methoden, Richtlinien und Standards vom Konfigurationsmanagement zu verwalten sind, sowie wann und in welchen Abständen Produktkonfigurationen und Releases zu erstellen sind. Zu Anzahl und Umfang der Produktkonfigurationen sind mindestens die Vorgaben zum Konfigurationsmanagement einzuhalten.
Alle Produkte, die im Rahmen eines V-Modell Projektes erstellt werden, werden entsprechend den Vorgaben im Projekthandbuch in die Produktbibliothek eingestellt und verwaltet. Hierzu muss festgelegt werden, welche Dateiablagestruktur und Namenskonventionen in der Produktbibliothek einzuhalten sind, wie die Produkte im Konfigurationsmanagement eindeutig zu bezeichnen sind, wie die Fortschreibung von Versionen und Releases erfolgt und welche Produktzustände ein Produktexemplar aus Sicht des Konfigurationsmanagements durchläuft. Die Produktzustände müssen mindestens die im Kapitel Qualitätssicherung und Produktzustandsmodell definierten Zustände umfassen.
Neben der Verwaltung der Produktbibliothek ist im Rahmen dieses Themas ein Konzept zur Datensicherung und Archivierung der Exemplare in der Produktbibliothek zu erstellen. Es werden die Verantwortlichkeiten, Termine und Verfahren zur Datensicherung festgelegt, sowie Konzepte zur Archivierung und Aufbewahrung der Daten über längere Zeiträume erstellt.
Das Konfigurationsmanagement liefert zudem einen Beitrag zum Projektstatusbericht, welcher zur Fortschrittskontrolle der Produktexemplare und Produktkonfigurationen dient. Es ist festzulegen, wann, in welcher Form und an welche Personen eine KM-Auswertung zu übergeben ist.
Ferner wird in diesem Kapitel beschrieben, wie Eintragungen in das Änderungs- und Prüfverzeichnis von Produkten vorzunehmen sind, d.h. z.B. Häufigkeit von Einträgen und welche Einträge bei der Bearbeitung vorgenommen werden und unter welchen Bedingungen.
4.3.1.3.10 Organisation und Vorgaben zum Projektcontrolling
In diesem Thema wird das im V-Modell bereits vorgesehene Vorgehen zum Projektcontrolling ausgestaltet und konkretisiert. Hierfür werden die Projektziele, die durch Projektkennzahlen verfolgt werden sollen, die Kennzahlen selbst und die dazugehörigen Messdatentypen zusammengestellt. Die Projektkennzahlen werden dabei den Projektzielen zugeordnet. Damit ist eine quantitative oder qualitative Verfolgung dieser Ziele möglich.
Abschließend erfolgt die Festlegung, ob, wann, welche und durch wen Messdaten zu erfassen und Kennzahlenauswertungen zu erstellen sind. Zusätzlich muss definiert werden, mit welchen Methoden, Richtlinien und Standards und mit welchen Werkzeugen beziehungsweise Bestandteilen der Projektmanagement-Infrastruktur dabei vorgegangen werden soll. Dabei ist insbesondere die projektspezifische Ablagestruktur der Messdaten festzulegen.
4.3.1.3.11 Organisation und Vorgaben zum Anforderungsmanagement
Dieses Thema beschreibt die im Rahmen des Anforderungsmanagements anzuwendenden Verfahren. Dies beinhaltet Festlegungen zu folgenden Bereichen zu treffen:
- Ermittlung von Anforderungen
- Dokumentation von Anforderungen
- Identifikation von Anforderungen
- Stakeholder
Insbesondere sind auch die Verantwortlichen für die Produkte (insb. das Produkt Anforderungen (Lastenheft)) der Anforderungserhebung zu benennen, sowohl für die Durchführung im Projekt als auch für die Betriebsphase. Zu berücksichtigen sind bei den Festlegungen auch, ob und welche Werkzeuge für die Anforderungserhebung zu verwenden sind, wie die Statuskontrolle der Anforderungen erfolgen soll und welche Metriken dafür zu verwenden sind. Eine angemessene Regelung dafür ist insbesondere für die Erstellung des Produkts Anforderungsbewertung erforderlich, dessen Erstellung ebenfalls hier zu regeln ist. Abschließend ist hier zu dokumentieren, wie die Anforderungserhebung in das Berichtswesen eingebunden werden soll.
Es lassen sich drei Arten von Anforderungen unterscheiden:
- Funktionale Anforderungen definieren die jeweilige Funktion, die von einem System zur Verfügung gestellt werden muss und vom Benutzer erwartet wird.
- Nicht-Funktionale Anforderungen definieren die Qualitätsmerkmale für ein System und seine Funktionalität, zu denen in der Regel auch Anforderungen aus dem Bereich des IT-Betriebs zählen.
- Randbedingungen leiten sich aus Rahmenbedingungen (z.B. organisatorische und technische Vorgaben) ab. Sie sind in der Regel projektextern und schränken die Art und Weise der Systemrealisierung ein bzw. geben konkrete Vorgaben für diese.
Für jede dieser Anforderungsarten sind hier Festlegungen zu den oben aufgeführten Punkten zu treffen. Darüber hinaus ist auch die frühzeitige Einbindung des Betriebs zu regeln, um die spätere Inbetriebnahme des Systems zu erleichtern.
Eine Anforderung im Allgemeinen stellt eine Bedingung oder Fähigkeit dar, die von einem Benutzer zur Problemlösung oder Zielerreichung benötigt wird und die ein (Teil-)System erfüllen oder besitzen muss, um bestimmte Vorgaben (z.B. Normen, Spezifikationen) zu erfüllen. Außerdem ist die Anforderung die Dokumentation dieser Bedingung bzw. Fähigkeit.
Zur Ermittlung von Anforderungen können verschiedene Techniken zum Einsatz kommen, wie z.B.:
- Kreativitätstechniken (z.B. Brainstorming, Mind-Mapping etc.) für die Sammlung erster Ideen
- Beobachtungstechniken (z.B. Feldbeobachtung) zur Ableitung von Details für die Anforderungen abzuleiten und für das Erkennen impliziter Anforderungen
- Befragungstechniken (z.B. Fragebogen, Interview) zur Erfragung von Anforderungen in beliebigem Detaillierungsgrad
- Vergangenheitsorientierte Techniken (z.B. Analyse bestehender Lösungen) zur Wiederverwendung der bei früheren Systementwicklungen bereits gemachten Erfahrungen und zur Überprüfung, ob tatsächlich alle Anforderungen ermittelt wurden
Der Einsatz der Techniken, die für die Anforderungsfestlegung verwendet werden ist hier zu dokumentieren.
Dokumentation von Anforderungen
Funktionale Anforderungen können sowohl natürlichsprachlich als auch modellbasiert erfasst werden. Nicht-Funktionale Anforderungen werden dabei ausschließlich in Textform dokumentiert. Anforderungen sollen stets so beschrieben sein, dass ihre Erfüllung prüfbar und entscheidbar ist. Bei einer textuellen Beschreibung ist daher auf hinreichende Präzision zu achten. Bei der modellbasierten Dokumentation von Anforderungen sind insbesondere die Perspektiven zu berücksichtigen, die zur Dokumentation verwendet werden, da sie einen Einfluss auf die Art der Interpretation der Anforderungen haben. Folgende Perspektiven sind dabei üblich:
- Strukturperspektive: Mit ihr lassen sich z.B. Abhängigkeitsbeziehungen im Systemkontext abbilden. Hierfür können z.B. UML-Klassendiagramme oder Entity-Relationship-Diagramme verwendet werden.
- Funktionsperspektive: Sie ist die Darstellungsform zur Erläuterung der Informations- / Datenflüsse. D.h., welche Informationen / Daten bekommt das System als Input, wie verarbeitet das System diese und welche Informationen / Daten liefert das System als Output. Hierfür können z.B. UML-Aktivitätsdiagramme oder Datenflussdiagramme verwendet werden.
- Verhaltensperspektive: Mit ihr lässt sich beschreiben, wie ein System auf Ereignisse reagiert und was die Bedingungen für einen Zustandswechsel des Systems sind. Hierfür können z.B. UML-Zustandsdiagramme oder Statecharts verwendet werden.
Die Festlegungen, wie in einem Projekt Anforderung erfasst werden, welche technischen und methodischen Hilfsmittel für die Dokumentation Verwendung finden ist hier zu dokumentieren.
Identifikation von Anforderungen
Anforderungen müssen eindeutig identifizierbar sein, um eine verlässliche Anforderungsverfolgung zu ermöglichen. In diesem Thema sind daher die Festlegungen zu dokumentieren, wie die Identifikation, z.B. durch Nummerierung, im Projekt erfolgen soll.
In diesem Thema sind alle an der Anforderungserhebung beteiligten Personen (Stakeholder) zu benennen. Dies umfasst nicht nur den Anforderungsanalytiker (AG) sondern auch weitere Personen, wie z.B. Anwendervertreter, die ein Interesse am IT-System haben. Insbesondere die Ansprechpartner des IT-Betriebs (z.B. die Rolle IT-Service-Design-Verantwortlicher) ist hier einzubinden.
4.3.1.3.12 Organisation und Vorgaben zur Systemerstellung
In diesem Thema wird das im V-Modell bereits vorgesehene Vorgehen zur Systemerstellung ausgestaltet und konkretisiert. Es erfolgt die Festlegung, wann und welche Produkte für die Systemerstellung zu verwenden sind, nach welchen Methoden, Richtlinien und Standards diese zu erstellen sind und mit welchen Werkzeugen beziehungsweise Bestandteilen der Projektmanagement-Infrastruktur sie zu bearbeiten sind.
Dies beinhaltet zumindest die Festlegung der anzuwendenden Entwicklungsmethoden, Entwicklungsumgebung, Technologien sowie Konfliktmanagement und Eskalationsstrategie.
4.3.1.3.13 Abstimmung mit IT-Organisation und Betrieb
Soll ein beauftragtes/erstelltes System nach dem Projektende in den Betrieb überführt werden, ist der IT-Betrieb frühzeitig in das Projekt einzubeziehen. Ist eine Übergabe in den Betrieb geplant, müssen hier die für das Projekt relevanten Regelungen zur Erstellung des Produkts Betriebliche Freigabeerklärung getroffen werden. Das Thema beschreibt ebenfalls, wie die IT-Organisation und der IT-Betrieb, insbesondere die Rollen IT-Service-Design-Verantwortlicher, IT-Service-Transition-Verantwortlicher und IT-Service-Operation-Verantwortlicher ins Projekt eingebunden werden.
Darüber hinaus beschriebt das Thema die grundlegende Konstellation nach Projektende und insbesondere zwischen welchen Parteien eine Leistungsvereinbarung (SLA/OLA/UC) zu schließen ist. Die konkreten Inhalte finden sich dann in den einzelnen Leistungsvereinbarungen.
Sind weiterhin die Vorgehensbausteine IT-Sicherheit und Datenschutz für das Projekt relevant, so enthält das Thema außerdem die projektinternen Regelungen zur IT-Sicherheit und zum Datenschutz, sowie die Abstimmung mit der umgebenden IT-Organisation. Dies umfasst im Detail die Regelungen, wer, wann wie den Beitrag zum IT-Sicherheitskonzept und den Beitrag zum Datenschutzkonzept erstellt und wie die Abstimmung mit den Rollen Informationssicherheitsverantwortlicher und Datenschutzverantwortlicher erfolgt.
4.3.1.3.14 Vorgaben für das Projekthandbuch der Auftragnehmer
In diesem Thema kann der Auftraggeber die unterschiedlichsten Vorgaben für die Planung und Durchführung des Projektes beim Auftragnehmer festlegen. Sie werden hier dokumentiert und dann in alle Ausschreibungen übernommen und gegebenenfalls angepasst. Die Vorgaben können beispielsweise den zu verwendenden Entwicklungsprozess, das Tailoring, die zu verwendende Infrastruktur und das Vorgehen bzgl. der Sicherheit umfassen.
4.3.1.3.15 Berichtswesen und Kommunikationswege
In den vorhergehenden Themen wurden die Organisation und Vorgaben für die unterschiedlichen Aufgaben der Planung und Durchführung von Projekten festgelegt. In diesem Thema wird ein Überblick über das dabei festgelegte Berichtswesen und die Kommunikationswege dargestellt. Dies beinhaltet beispielsweise die getroffenen Festlegungen, wer wann welche Informationen in welcher Form an wen zu liefern hat.
Das Thema beschreibt sowohl die projektinterne als auch die projektexterne Kommunikation. Die Ziele des Kommunikationsmanagements werden dabei in der Zielgruppenübersicht definiert, die Umsetzung wird im Kommunikationsplan beschrieben.
Die Zielgruppenübersicht beschreibt, welche Personen und Personenkreise welche Informationen über das Projekt erhalten müssen, sollen oder möchten. Kommunikationszielgruppen sind oft deckungsgleich mit Projektstakeholdern, und umfassen beispielsweise die Projektmitarbeiter, Lenkungsausschuss, Leitung, Anwender, aber auch Öffentlichkeit oder Medien. Ziel des Kommunikationsmanagements ist es, das Informationsbedürfnis der einzelnen Zielgruppen durch geeignete Maßnahmen zu bedienen.
Der Kommunikationsplan beschreibt, wie die in der Zielgruppenübersicht definierten Informationsbedürfnisse der Kommunikationszielgruppen befriedigt werden sollen. Er legt fest, welche Information (z.B. Projektfortschritt), wann (z.B. jeweils zum Monatsende) in welcher Form und über welches Medium (z.B. schriftlicher Projektstatusbericht via E-Mail) an welche Kommunikationszielgruppe (z.B. Lenkungsausschuss und Leitung) kommuniziert wird und wer dafür verantwortlich ist (z.B. Projektleiter). Auch die projektinterne Kommunikation wird hier geplant und organisiert, beispielsweise dass alle Besprechungen protokolliert werden und an wen das Protokoll im Anschluss verteilt wird.