PRINCE 2: Das Projektmanagement-Framework GERMAN

Xpert.press Die Reihe Xpert.press vermittelt Professionals in den Bereichen Softwareentwicklung, Internettechnologie u...

Author: Peter T. Köhler

69 downloads 2137 Views 18MB Size Report

This content was uploaded by our users and we assume good faith they have the permission to share this book. If you own the copyright to this book and it is wrongfully on our website, we offer a simple DMCA procedure to remove your content from our site. Start by pressing the button below!
Report copyright / DMCA form

DOWNLOAD PDF

Xpert.press

Die Reihe Xpert.press vermittelt Professionals in den Bereichen Softwareentwicklung, Internettechnologie und IT-Management aktuell und kompetent relevantes Fachwissen über Technologien und Produkte zur Entwicklung und Anwendung moderner Informationstechnologien.

Peter T. Köhler

PRINCE 2 Das Projektmanagement-Framework

Mit 223 Abbildungen und 26 Tabellen

123

Peter T. Köhler Flachsgraben 4 53343 Wachtberg [email protected]

Bibliografische Information der Deutschen Bibliothek Die Deutsche Bibliothek verzeichnet diese Publikation in der Deutschen Nationalbibliografie; detaillierte bibliografische Daten sind im Internet über http://dnb.ddb.de abrufbar.

ISSN 1439-5428 ISBN-10 3-540-29181-4 Springer Berlin Heidelberg New York ISBN-13 978-3-540-29181-7 Springer Berlin Heidelberg New York Dieses Werk ist urheberrechtlich geschützt. Die dadurch begründeten Rechte, insbesondere die der Übersetzung, des Nachdrucks, des Vortrags, der Entnahme von Abbildungen und Tabellen, der Funksendung, der Mikroverfilmung oder der Vervielfältigung auf anderen Ween und der Speicherung in Datenverarbeitungsanlagen, bleiben, auch bei nur auszugsweiser Verwertung, vorbehalten. Eine Vervielfältigung dieses Werkes oder von Teilen dieses Werkes ist auch im Einzelfall nur in den Grenzen der gesetzlichen Bestimmungen des Urheberrechtsgesetzes der Bundesrepublik Deutschland vom 9. September 1965 in der jeweils geltenden Fassung zulässig. Sie ist grundsätzlich vergütungspflichtig. Zuwiderhandlungen unterliegen den Strafbestimmungen des Urheberrechtsgesetzes. Springer ist ein Unternehmen von Springer Science+Business Media springer.de © Springer-Verlag Berlin Heidelberg 2005, 2006 Printed in Germany Die Wiedergabe von Gebrauchsnamen, Handelsnamen, Warenbezeichnungen usw. in diesem Werk berechtigt auch ohne besondere Kennzeichnung nicht zu der Annahme, dass solche Namen im Sinne der Warenzeichen- und Markenschutz-Gesetzgebung als frei zu betrachten wären und daher von jedermann benutzt werden dürften. Text und Abbildungen wurden mitgrößter Sorgfalt erarbeitet. Verlag und Autor können jedoch für eventuellverbliebene fehlerhafte Angaben und deren Folgen weder eine juristische Verantwortung noch irgendeine Haftung übernehmen. Satz und Herstellung: LE-TEX, Jelonek, Schmidt & Vöckler GbR, Leipzig Umschlaggestaltung: KünkelLopka Werbeagentur, Heidelberg Gedruckt auf säurefreiem Papier

33/3100 YL - 5 4 3 2 1 0

Vorwort

Fast alle Geschäftsprozesse basieren heute auf IT-Systemen. Die Globalisierung zwingt die Firmen in einen fast nicht mehr durchführbaren Rationalisierungsdruck, damit man gegenüber den Anbietern im asiatischen Raum konkurrenzfähig bleibt bzw. treu dem Shareholder Value-Prinzip einen möglichst hohen Profit erwirtschaftet. Für viele Firmen ergibt sich eine Zwangssituation: möchte man seine Geschäftsprozesse nicht nach Indien oder China verlagern, müssen die Chancen genutzt werden, die die heutige Informationstechnologie bietet. Dafür bedarf es Spezialisten die die Geschäftsprozesse mittels eines Projektes in ein DV- oder IT-System transformieren. Jeder, der mit Projekten sein Geld verdient, weiß, wie unberechenbar die möglichen Risiken eines Projektes sein können. Die meisten neuen ITSysteme sind Einzelentwicklungen, die auf Technologie aufbauen, die meist innerhalb von zwei bis drei Jahren veralten. Das bedeutet, dass sich entwickelte Software fast ausschließlich kein zweites Mal nutzen lässt, um die Kosten einer Entwicklung zu reduzieren. Oft werden Projekte innerhalb einer Ausschreibung vergeben, indem meist derjenige den Auftrag bekommt, der der preisgünstigste ist. Dass dies keine günstigen Vorraussetzungen für ein Projekt sind, liegt auf der Hand. Man wundert sich dann in der CIO- und höheren Management-Ebene, warum so viele Projekte scheitern. Oft wird man Außenstehenden schlecht klarmachen können, warum Idealvorstellungen einer Projektdurchführung selten erreicht werden. Besonders Softwareprojekte implizieren durch Erfahrung eine hohe Quote des Scheiterns. Die Anzahl von Publikationen auf dem Gebiet des Projektmanagements lässt erahnen, wie viele Projekte scheitern. Jedes gescheiterte Projekt ist gleichzusetzen mit mangelndem Erfolg entsprechender Firmenorganisationen und menschlicher Einzelschicksale, die damit verbunden sind. Die Rationalität des Menschen versucht dann, durch möglichst viele Regulierungen die bestehenden Risiken eines Projektes zu bändigen. Diese Regulierungen sollen helfen, ein „ideales Projekt“ abzubilden, das alle erfolgreichen Zutaten eines Projektes umfasst.

Vorwort

■ ■ ■

V

Dies führte zur Entwicklung von Projektmanagement-Frameworks und -Vorgehensmodellen wie HERMES, V-MODELL-XT oder PRINCE 2. Die Wirkung eines Projektmanagenent-Frameworks steht und fällt mit der Prämisse: „so viel wie nötig, aber so wenig wie möglich“. Dies ist Sinn und Zweck eines Tailorings, wie es bei umfangreichen Vorgehensmodellen angewandt wird. Das folgende Buch handelt vom Projektmanagement-Framework PRINCE 2 und seinen einzelnen Subprozessen. PRINCE 2 beschränkt sich auf positive Weise ausschließlich mit dem Management von Projekten und weniger damit, wie Hard- oder Softwareentwicklung im speziellen durchgeführt wird. Hierfür gibt es wieder andere spezielle Ansätze, wie z. B. RUB oder DSDM. PRINCE 2 orientiert sich an Prozessen und Verfahren aus der Praxis für die Praxis, was nichts anderes bedeutet, als dass sich diese Prozesse an anderer Stelle schon bewährt haben, also praxisorientiert sind. Es lässt den Firmen Spielraum, PRINCE 2 auf ihre Art und Weise umzusetzen, weil nur beschrieben wird, was gemacht werden muss, und nicht, wie es umgesetzt werden soll. Dies ist meiner Meinung nach auch einer der Hauptvorteile von PRINCE 2. Das Buch soll helfen, bestehende und neue Projekte in Industrie sowie im Dienstleistungs- und öffentlichen Sektor erfolgreicher und kostengünstiger durchzuführen, indem es praktische Leitfäden an die Hand gibt.

Ziele des Buches Thema des Buches ist das prozessorientierte IT-ProjektmanagementFramework PRINCE 2. Es zeigt dem Leser, dass alle wesentlichen Kernaufgaben eines Projektmanagements durch PRINCE 2 erfüllt werden. Das Buch soll einen Einblick geben in die einzelnen PRINCE 2-Prozesse: SU (Vorbereiten eines Projektes), IP (Initiieren des Projekts), CS (Steuern einer Projektphase), MP (Managen der Produktlieferung), SB (Managen von Projektphasenübergängen), CP (Abschließen eines Projekts), DP (Lenken eines Projektes, sowie PL (Planen). Das Buch beschreibt die PRINCE 2-spezifischen Rollen, Projektmanagementprodukte sowie wesentliche Fachbegriffe der entsprechenden PRINCE 2-Projektmanagementprozesse. Das Buch erklärt, wie der Reifegrad der von Firmen eingesetzten Projektmanagent-Frameworks und -Vorgehensmodelle mittels PMMM beurteilt werden kann und wie durch P2MM die firmenspezifischen PRINCE 2-Prozesse daraufhin überprüft werden können, ob sie dem PRINCE 2-Standard genügen. Das Buch nennt

VI

■ ■ ■

Vorwort

PRINCE 2-zertifizierte Ausbildungsstätten, falls man sich dazu entschließt, weitere Informationsquellen über PRINCE 2 zu erschließen. Ein weiterer Schwerpunkt liegt im Benennen von möglichen Projektrisiken, wie sie auf die eine oder andere Art und Weise in der Praxis aufgetreten sind oder auftreten können. Dies ermöglicht es dem Leser, sich mit alltäglichen Projektrisiken auseinanderzusetzen und eigene Lösungsansätze zu suchen, bevor er sein nächstes Projekt durchführt. Es gibt praxisorientierte Beispiele und Hilfen, um ein wirkungsvolles Projektmanagement innerhalb eines Unternehmens durchzuführen und zeigt anhand erlebter Praxisbeispiele, wie subtil sich Projektrisiken einschleichen. Das Buch gibt einen Überblick über die ProjektmanagementFrameworks oder Vorgehensmodelle V-Modell-XT und HERMES, damit man sich einen Überblick über die wichtigsten Projektmanagement-Vorgehensmodelle dieser Zeit verschaffen kann und welche speziellen Eigenschaften diese besitzen. Dies dürfte insbesondere für Leser, die sich in der Ausbildung oder im Studium befinden, nützlich sein. Das Buch zeigt, wie die Vergabe von Aufträgen im öffentlichen Bereich durchgeführt wird und wie die allgemeinen Geschäftsbedingungen der öffentlichen Hand aussehen. Es gibt einen Überblick über die VOL/A, VOL/B und zeigt, wie die allgemeinen Geschäftsbedingungen (AGB) der öffentlichen Hand in der VOL/B zusammengefasst werden. Weiterhin erklärt es die verschiedenen ergänzenden Vertragsbedingungen (BVB, EVB) der öffentlichen Hand und wie eine Wirtschaftlichkeitsbetrachtung für Projekte in der Informationstechnik (IT-WiBe) durchgeführt wird. Nutzerakzeptanz und Erfolg eines neuen IT- oder DV-Verfahrens sind davon abhängig, wie genau die verschiedenen Anforderungen (geschäftsspezifisch, technisch, organisatorisch) bei der Anforderungsanalyse in der Architektur des neu zu entwickelnden DV-Verfahrens abgebildet wurden. Das Buch zeigt auf, welche verschiedenen Sichten oder Sichtweisen eines neuen IT- oder DV-Verfahrens bei der Entwicklung mit berücksichtigt werden müssen. Es gibt einen Überblick darüber, wie sich die Qualität der Softwareentwicklung durch Assessments und „walk throughs“ steigern lässt und welche Software-Entwicklungs-Assessment-Standards (CMM, SPICE) es gibt. Agile Softwareentwicklung ist sicherlich eines der aktuellen Themen, das in aller Munde ist. Das Buch zeigt, was agile Softwareentwicklung ist und welche praktischen Verfahren sich mittlerweile etabliert haben. Es vermittelt weiterhin einen Überblick über DSDM und RUB sowie über die Vorzüge von RAD-Werkzeugen.

Vorwort

■ ■ ■

VII

Weiterhin gibt es einen Überblick über das IT-Servicemanagement-Framework ITIL, um neue, innerhalb eines Projekts entwickelte DV-Verfahren in einer Firma zu betreiben. Das Buch erklärt, wie ein neues IT- oder DV-Verfahren mittels Betriebskonzept in das Servicemanagement eines Unternehmens überführt werden kann. Es erklärt allgemeine Begriffe des Projektmanagements, z. B. was ein Pflichten- und ein Lastenheft ist sowie projektspezifische Definitionen und Begriffe (Prototyping, Tailoring, IT-Wirtschaftlichkeitsberechnung), die tagtäglich im Projektgeschäft anzutreffen sind. Es zeigt, wie wichtig ein Lenkungsausschuss ist, wer im Lenkungsausschuss vertreten sein sollte und welche Aufgaben dieser hat. Ein Kapitel enthält spezifische Statistiken, um eine Argumentationskette dafür aufzubauen, welche wichtigen Erfolgsfaktoren und Probleme ein Projekt in der Praxis beinhaltet. Innerhalb des Buches werden die Gründe untersucht, warum Projekte scheitern können bzw. womit man rechnen muss, wenn die Projekte aus dem Ruder laufen. Die enthaltenen Statistiken konfrontieren den Leser mit praxisorientiertem Erfahrungswissen. Es legt dar, warum ein Projektmanagement-Framework den Erfolg eines Projektes positiv beeinflussen kann. Das Buch spricht die heute relevanten Themen des Projektmanagements und der Softwareentwicklung an und ist somit für das Firmenprogramm-Management, Projektleiter, Entwicklungsingenieure, IT-Consultants einer Firma sowie für Auszubildende und Studenten im IT-Bereich von allgemeinem Interesse.

Wer dieses Buch lesen sollte Das Buch wendet sich an alle Mitarbeiter von Entwicklungsabteilungen, um ihnen eine detaillierte Einführung in PRINCE 2 und praktisch umsetzbare Beispiele an die Hand zu geben, Projekte positiv zu beeinflussen. Es richtet sich an IT-Consultants, die entsprechende PRINCE 2-konforme Projektmanagementprozesse innerhalb eines Unternehmens einführen wollen. Projektleiter bekommen einen detaillierten Eindruck davon, wie die einzelnen PRINCE 2-Prozesse helfen, mit den Projekttücken des Alltags fertig zu werden. Studenten im Informatikstudium oder Neulinge im IT Projektgeschäft erhalten einen umfassenden Einblick in die aktuellen (PRINCE 2, V-Modell-XT, HERMES), wichtigen Projektmanagement-Frameworks oder Vorgehensmodelle unserer Zeit. Durch die Praxisbeispiele ist es möglich, sich in konkrete Projekt-Situationen hineinzuversetzen und sich zu überlegen, wie man in dieser Situation selbst handeln würde. Begriffe des Projektmanagements wie

VIII

■ ■ ■

Vorwort

z. B. Tailoring, Prototyping, IT-WiBe, AQAP, CMMI, SPICE usw. werden erörtert. Mitarbeiter mit Leitungsaufgaben bzw. das Programm-Management einer Firma erhalten einen Eindruck davon, wie das Projektmanagement-Framework PRINCE 2 bestehende Risiken beim Durchführen von Projekten durch spezifische Projektmethodik erfasst und neutralisieren hilft. Auch wird gezeigt, wie das Programm-Management einer Firma trotz vieler Einzelprojekte innerhalb eines Unternehmens mittels PRINCE 2 immer dann rechtzeitig informiert wird, wenn es zu unvorhergesehenen Situationen innerhalb eines Teilprojektes kommt. Durch die Einsetzung oder Stärkung der Möglichkeiten eines Lenkungsausschusses beim Starten eines Projektes wird die Firmenleitung bzw. das Programm-Management einer Firma aktiv in die Durchführung eines Projektes beim ProjektmanagementFramework PRINCE 2 mit eingebunden. Projektleiter, die sich im harten tagtäglichen Projektgeschäft bewähren müssen, erfahren mit dem vorliegenden Buch, wie PRINCE 2 ihnen helfen kann, in Zukunft besser mit widrigen Projektumständen fertig zu werden und wie man mittels des „MoSCoW“-Ansatzes den Aufwand eines Projektes reduzieren und die Kosten im Griff behalten kann. Anhand im Buch enthaltener Statistiken werden Erfolgsfaktoren bei der Durchführung eines Projektes analysiert. Neben reinem Projektmanagement-Handwerkszeug erfährt der Leser etwas über die Dinge im Berufs- und ManagementAlltag eines Projektleiters, die einem sonst niemand erzählt, da sie in der „Grauzone“ des menschlichen Verhaltens liegen. Durch den Überblick über die Softwareentwicklungsprozesse oder Vorgehensmodelle in der Softwareentwicklung RUB und DSDM ist es für alle interessant, die sich mit der Erstellung von Software befassen. Die im Buch enthaltenen Statistiken sollen helfen, Argumentationsketten aufzubauen, um entsprechende neue Strategien der Softwareentwicklung und des Projektmanagements innerhalb einer Firma etablieren zu können. Durch das Kapitel Vergabe und Allgemeine Geschäftsbedingungen der öffentlichen Hand ist es sowohl für Mitarbeiter im öffentlichen Sektor als auch für Projekt-Dienstleister informativ.

Aufbau des Buches Das Buch ist umfassend und gibt detaillierte Beispiele und Argumentationshilfen. Es holt Leser mit unterschiedlichem Wissensstand von dort ab, wo sie sich befinden. Jeder Leser kann in dem Kapitel

Vorwort

■ ■ ■

IX

des Buches anfangen zu lesen, das seinem Wissensstand oder seinen Neigungen entspricht. Leser, die sich detailliert mit PRINCE 2 beschäftigen wollen, können direkt mit dem Kapitel 6 anfangen. Leser, die weder Kenntnisse von Projektmanagement-Frameworks oder Vorgehensmodellen im Allgemeinen besitzen, sollten mit Kapitel 5 anfangen. Leser, die sich generell über Projektmanagement, qualitätssichernde Verfahren bei Projekten oder über typische Probleme bei der Durchführung von Projekten informieren wollen, sollten mit Kapitel 1 bzw. 4 anfangen. Leser, die auch wissen möchten, was nach der Entwicklung und Abnahme eines neuen IT- oder DV-Verfahrens notwendig ist, um es innerhalb einer Firma stabil zu betreiben und effektiv zu nutzen, bzw. wie das neue IT- oder DV-Verfahren optimal in eine bestehende Firmenorganisation überführt werden kann, sind innerhalb des Kapitels 7 gut aufgehoben. Leser, die sich darüber hinaus über die ausschreibungsrelevanten Formalien und Bedingungen der Vergabe von Aufträgen der öffentlichen Hand interessieren, können innerhalb des Kapitels 2 entsprechende Informationen erhalten. Das Buch eignet sich durch das detaillierte Stichwortverzeichnis auch als Nachschlagewerk über die aktuellen Themen des Projektmanagements. Durch seine interdisziplinäre Art verschafft es einen ganzheitlichen Eindruck über alle Belange der Projektdurchführung.

Inhalte des Buches Kapitel 1 vermittelt Basiswissen des Projektmanagements. Es zeigt, welche Eigenschaften ein Projekt hat und was ein erfolgreiches Projekt auszeichnet. Es gibt einen Überblick darüber, aus welchen Gründen in der Praxis Projekte scheitern können und welche Probleme daraus entstehen. Dies ist unterlegt mit entsprechenden Statistiken. Innerhalb des Kapitels 1 wird anhand von Praxisbeispielen erklärt, welche Art von Problemen innerhalb von Projekten entstehen können und welche Auswirkungen sie haben. Es zeigt, wie ein Projektkrisenmanagement aussieht und welche Kosten ein Projektmanagement verursacht. Kapitel 2 gibt eine Einführung in die Vergabepraxis und die Geschäftsbedingungen der öffentlichen Hand. Dabei werden z. B. die Begriffe VOL/A, VOL/B, freihändige Vergabe, öffentliche Ausschreibung, EU-weite Vergabeverfahren mit Leben gefüllt. Auch das neue Vergaberecht sowie die e-Vergabe werden behandelt. Die verschiedenen ergänzenden Vertragsbedingungen für die Beschaf-

X

■ ■ ■

Vorwort

fung von IT-Leistungen im öffentlichen Sektor, wie EVB und BVB, werden im Kapitel 2 behandelt. Projektmanagementbegriffe wie Pflichten- und Lastenheft werden erörtert. Das Kapitel 3 geht darauf ein, wie ein erfolgreiches AnforderungsManagement durchgeführt werden kann, indem die verschiedenen Sichtweisen auf ein neues DV- oder IT-Verfahren und deren zugrunde liegende Geschäftsprozesse berücksichtigt werden. Innerhalb des Kapitels 4 werden qualitätssichernde Prozesse in der Softwareentwicklung und im Projektmanagement behandelt. Es geht auf qualitätssichernde Verfahren wie AQAP sowie Prozessreifegrad-Ermittlung mit CMMI und SPICE ein. Kapitel 4 behandelt die agile Softwareentwicklung mittels RAD-Werkzeugen sowie RUP- und DSDM-Frameworks. Es untersucht den Einfluss von Inspektions-Assessments sowie „walk throughs“ bei Projekten. Kapitel 5 erklärt, was ein Projektmanagement-Framework oder Vorgehensmodell generell ist und stellt die bekannten Projektmanagement-Frameworks oder Vorgehensmodelle HERMES und V-Modell-XT vor. Mit Kapitel 6 wird das Projektmanagement-Framework PRINCE 2 mit seinen einzelnen Haupt- und Subprozessen detailliert erörtert. PRINCE 2-spezifische Rollen sowie Projektmanagementprodukte werden einzeln vorgestellt und erklärt. Die Hauptprozesse SU (Vorbereiten eines Projektes, Starting up a project), IP (Initiieren eines Projektes, Initiating a Project), DP (Lenken eines Projektes, Directing a project), CS (Steuern einer Projektphase, Controlling a stage), MP (Managen der Produktlieferung, Managing Product Delivery), SB (Managen von Projektphasenübergängen, Managing Stage Boundaries), CP (Abschließen eines Projektes, Closing a Project) sowie Pl (Planen, planning) werden detailliert erläutert. Im Kapitel 6 wird gezeigt, wie sich PRINCE 2 und DSDM gemeinsam einsetzen lässt, um Softwareprojekte durchzuführen und welchen Einfluss SSADM und UML auf PRINCE 2 haben. Weiterhin wird P2MM vorgestellt, mit dem sich der Reifegrad von PRINCE 2Prozessen innerhalb einer Firma ermitteln lässt. Zu guter Letzt wird gezeigt, welche PRINCE 2-Schulungen und Zertifizierungen allgemein angeboten werden. Mit Kapitel 7 erfährt man, wie sich nach der Abnahme eines Projektes ein erstelltes DV- oder IT-System in eine bestehende Serviceorganisation mittels Betriebskonzept überführen lässt. Es vermittelt einen guten Überblick über das IT-ServicemanagementFramework ITIL mit seinen einzelnen Modulen und Servicemanagementprozessen.

Vorwort

■ ■ ■

XI

Im Anhang findet sich eine Übersicht über Schulungseinrichtungen, die Wissen über PRINCE 2 vermitteln und entsprechende Zertifizierungen durchführen.

Danksagung Dieses Buch ist Ulrike, Jasmin, Stephan und meinen Eltern, die mir tatkräftig geholfen haben und mit ihrer Gegenwart das Leben lebenswert machen, gewidmet. Besonderer Dank gebührt Gisela, die sich tapfer viele Tage lang mit der Sichtung von Texten beschäftigt hat.

XII

■ ■ ■

Vorwort

Inhaltsverzeichnis

1

Projektmanagement – Basics............................................................................ 1 1.1 Was ist ein Projekt? ................................................................................... 1 1.2 Wodurch zeichnet sich ein erfolgreiches Projekt aus? ............................. 2 1.3 Woran scheitern Projekte bzw. womit muss man rechnen, wenn Projekte aus dem Ruder laufen? Einige interessante Statistiken .............. 3 1.4 Probleme bei Projekten.............................................................................. 9 1.4.1 Politische oder firmenpolitisch motivierte Probleme................. 10 1.4.2 Organisatorische und planerische Probleme .............................. 12 1.4.3 Fachliche und anforderungsbedingte Probleme ......................... 17 1.4.4 Probleme bei der Zusammenarbeit............................................. 21 1.4.5 Methoden zur Risikoidentifikation innerhalb eines Projektes... 22 1.4.6 Projektkrisenmanagement .......................................................... 24 1.4.7 Kosten des Projektmanagements................................................ 25

2

Vergabe und Allgemeine Geschäftsbedingungen der Öffentlichen Hand..................................................................................... 2.1 Arten der Vergabe nach VOL/A ............................................................. 2.2 Neues Vergaberecht sowie e-Vergabe .................................................... 2.3 Was ist EVB-IT und BVB? ..................................................................... 2.4 Was versteht man unter einem Los?........................................................ 2.5 Was versteht man unter einem Lasten- und Pflichtenheft? ....................

3

Die verschiedenen Sichtweisen auf ein neues DV-Verfahren ..................... 37

4

Qualitätssichernde Prozesse ........................................................................... 4.1 Qualitätssichernde Prozesse in Softwareentwicklung, Projektmanagement und IT-Servicemanagement sowie die Standards zu ihrer Überprüfung ........................................................ 4.2 Was sind AQAP13, AQAP 110 und AQAP 150? .................................. 4.3 Capability-Maturity-Modell (CMM)....................................................... 4.4 Software Process Improvement and Capability dEterminaton (SPICE) ....................................................................................................

Inhaltsverzeichnis

■ ■ ■

XIII

27 27 31 32 35 35

43 45 46 47 50

4.5 4.6 4.7

Agile Entwicklung (RAD) und DSDM-Framework............................... RUP .......................................................................................................... 4.6.1 Die Arbeitsweise von RUP ......................................................... Der Einfluss von Inspektionen, Assessments und „Walk Throughs“ bei Projekten............................................................................................. 4.7.1 „Walk Through“..........................................................................

56 61 62 65 66

5

Entwicklung eines neuen DV-Verfahrens mit den Vorgehensmodellen HERMES, V-Modell-XT oder PRINCE 2 .................................................... 69 5.1 HERMES.................................................................................................. 71 5.1.1 Basiswissen von HERMES......................................................... 74 5.1.2 Spezielle Begriffe unter HERMES............................................. 83 5.2 V-Modell-XT ........................................................................................... 90 5.2.1 Einsatzbereiche des V-Modells................................................... 93 5.2.2 Spezifische Eigenarten des V-Modells....................................... 94 5.3 Die einzelnen V-Modell-XT- Vorgehensbausteine im Überblick........ 100 5.3.1 Projektmanagement................................................................... 101 5.3.2 Qualitätssicherung ..................................................................... 101 5.3.3 Konfigurationsmanagement...................................................... 104 5.3.4 Problem- und Änderungsmanagement ..................................... 105 5.3.5 Kaufmännisches Projektmanagement....................................... 105 5.3.6 Messung und Analyse ............................................................... 105 5.3.7 Anforderungsfestlegung............................................................ 106 5.3.8 Systemerstellung ....................................................................... 106 5.3.9 Auftragsvergabe, Projektbegleitung und Abnahme durch den Auftraggeber............................................................. 107 5.3.10 HW-Entwicklung ...................................................................... 107 5.3.11 SW-Entwicklung ....................................................................... 108 5.3.12 Logistikkonzeption.................................................................... 110 5.3.13 Evaluierung von Fertigprodukten ............................................. 110 5.3.14 Benutzbarkeit und Ergonomie .................................................. 111 5.3.15 Systemsicherheit........................................................................ 111 5.3.16 Weiterentwicklung und Migration von Altsystemen ............... 111 5.3.17 Einführung und Pflege eines organisationsspezifischen Vorgehensmodells..................................................................... 112

6

PRINCE 2........................................................................................................ 113 6.1 Rollen unter PRINCE 2.......................................................................... 116 6.2 Erzeugnisse unter PRINCE.................................................................... 121 6.3 Die Prozesse von PRINCE im Überblick.............................................. 127 6.3.1 SU (Vorbereiten eines Projektes).............................................. 127 6.3.2 DP (Lenken eines Projektes)..................................................... 129 6.3.3 CS (Steuern einer Projektphase) ............................................... 130 6.3.4 MP (Managen der Produktlieferung)........................................ 131 6.3.5 PL (Planen)................................................................................ 132

XIV

■ ■ ■

Inhaltsverzeichnis

6.4

6.5 6.6 6.7 6.8 7

6.3.6 IP (Initiieren des Projektes) ...................................................... 6.3.7 SB (Managen von Projektphasenübergängen)......................... 6.3.8 CP (Abschließen eines Projektes) ............................................ PRINCE und seine Prozesse im Detail ................................................. 6.4.1 SU (Vorbereiten eines Projektes) ............................................. 6.4.2 IP (Initiieren eines Projektes) ................................................... 6.4.3 DP (Lenken eines Projektes) .................................................... 6.4.4 CS (Steuern einer Projektphase)............................................... 6.4.5 MP (Managen der Produktlieferung) ....................................... 6.4.6 SB (Managen von Projektphasenübergängen)......................... 6.4.7 CP (Abschließen eines Projektes) ............................................ 6.4.8 PL (Planen)................................................................................ PRINCE 2 und DSDM .......................................................................... PRINCE 2 und SSADM bzw. UML ..................................................... PMMM (Project Management Maturity Modell) und P2MM (PRINCE 2 Maturity Modell)................................................................ PRINCE 2-Zertifizierung und Schulungen ...........................................

Nach der Abnahme (Servicemanagement eines neuen DV-Verfahrens).............................................................................................. 7.1 Die ITIL-Struktur (Die sieben Hauptbereiche von ITIL) ..................... 7.1.1 Business Perspective................................................................. 7.1.2 Planning to Implement Service Management .......................... 7.1.3 Application Management.......................................................... 7.1.4 ICT Infrastructure Management ............................................... 7.1.5 Security Management ............................................................... 7.1.6 ITIL Service Management (Service Delivery, Support) im Überblick ............................................................................. 7.2 Betriebskonzept...................................................................................... 7.2.1 Inhaltliche Ziele des Betriebskonzepts..................................... 7.2.2 Mengengerüst............................................................................ 7.2.3 Zuständigkeitsmatrix ................................................................ 7.2.4 Erreichbarkeit, Wartungsfenster sowie Eskalationsvorgang bei Störungen ............................................................................ 7.2.5 Havarie- und Backupkonzept ................................................... 7.2.6 Wartungsverträge...................................................................... 7.2.7 Kennparameter bzw. Schwachstellenanalyse eines neuen DV-Verfahrens..........................................................................

133 134 135 137 137 147 160 173 193 199 211 218 236 238 239 239 241 241 242 243 243 244 244 245 253 255 258 259 260 263 265 266

Anhang ............................................................................................................ 269 Adressen von Unternehmen, die Schulungen im Bereich PRINCE 2 durchführen .............................................................. 269 Literatur.................................................................................................. 271 Index ................................................................................................................ 275

Inhaltsverzeichnis

■ ■ ■

XV

1 Projektmanagement – Basics

1.1 Was ist ein Projekt? Seit Anbeginn der Menschheit galt es, Aufgaben und Produkte innerhalb eines Projektes zu realisieren. Der Bedarf an einem Standard oder einer Methode, mit der man alle Gefahren und Umstände eines Projektes elegant umschiffen kann ohne zu kentern, ist vorhanden. eineindeutiges deutiges Ziel Ziel zeitlich zeitlich befristet befristet

Komplexität

Abb. 1.1: Was sind die wesentlichen Attribute eines Projektes?

Projekt bereichsbereichsüberübergreifend greifend

neuartig neuartig begrenzte begrenzte Ressour Ressourcen cen

Unendlich viele Bücher geben Tipps, Ratschläge und Orientierungshilfen und trotzdem wird immer ein Teil der Projekte scheitern. Auch mit PRINCE 2. Dies soll uns aber nicht daran hindern, am Wissen und den „Best Practice“-Ansätzen erfolgreich beendeter Projekte zu partizipieren. Da dieses Buch um den Begriff Projekt kreist, wollen wir uns zunächst einmal ansehen, was denn ein Projekt ist und was seine Merkmale sind. Nach der DIN 69901 ist ein Projekt (lat. „proicere“ = entwerfen) ein Vorhaben, bei dem innerhalb einer festgelegten Zeitspanne und bestimmter Ressourcen ein definiertes Ziel erreicht werden soll, das

1.1 Was ist ein Projekt?

■ ■ ■

11

Abb. 1.2: PRINCE 2-typische Definition eines Projektes

„a management environment that is created for the purpose of delivering one or more business products according to a specified business case” PRINCE2 (What is a project?) sich dadurch auszeichnet, dass es im Wesentlichen ein einmaliges Vorhaben ist. Somit hat ein Projekt die folgenden Charakteristika: x Es ist zeitlich befristet x Es hat endliche Ressourcen zur Verfügung x Es besteht aus Aktivitäten, die zu geschäftlichen Zielen oder zum Erhalt von Endprodukten führen. x Es bedarf einer Organisationsstruktur mit definierten Verantwortlichkeiten und Regeln, um das Projekt zu steuern.

1.2 Wodurch zeichnet sich ein erfolgreiches Projekt aus? Nach dem HERMES-Vorgehensmodell zeichnet sich ein erfolgreiches Projekt dadurch aus, dass es am Ende die vier Erfolgsdimensionen Lösungsumfang, Qualität, Kosten und Termine eingehalten hat. Abb. 1.3: Die vier Erfolgsdimensionen eines Projektes nach HERMES [7]

Kostenlimit eingehalten

Qualitätsziele erreicht

Projekterfolg

Lösungsumfang umgesetzt

2

■ ■ ■


Termine eingehalten

Folgende Schlüsselfaktoren wirken sich meiner Meinung nach günstig aus: x Hohe Eigenmotivation aller Projektmitglieder x Erstellung eines Prototypen x Unterstützung durch die Firmenleitung x Präzise Anforderungen und gewichtete Funktionalitätsanforderungen x Kunden frühzeitig mit einbeziehen, z. B. durch „Walk Through“ x Projektrisiken möglichst früh erkennen (einfache Kontrollinstrumente) x Projektlaufzeiten unter 2 Jahren x Risikomanagement x Einsatz eines Projektmanagementframeworks Dennoch soll hier bemerkt werden, dass es zwar viele Gründe gibt Projektmanagement-Frameworks einzusetzen, dass es aber der „Faktor Mensch“ ist, der ein Projekt erfolgreich beendet. Hartnäckigkeit, Spaß an der Sache, Kommunikations- und Frustrationsstärke, organisatorischer Rückhalt, der Wille zum Erfolg sowie ein einfaches und gerade ausreichendes Projektmanagementframework sind meines Erachtens die Zutaten für ein gelungenes Projekt.

1.3 Woran scheitern Projekte bzw. womit muss man rechnen, wenn Projekte aus dem Ruder laufen? Einige interessante Statistiken Diesem Kapitel sollte man viel Aufmerksamkeit schenken, um von Fehlern und Erfahrungen anderer zu profitieren. Die nachfolgenden Statistiken stammen weitestgehend von der Unternehmensberatung Standish Group, die alle zwei Jahre den sog. CHAOS-Report herausgibt. Dieser beurteilt seit 1994 die Erfolgsfaktoren von IT-Projekten primär auf dem US-Markt. Glaubt man den Aussagen dieser Unternehmensberatung, so liegen die Quoten für das Scheitern von Projekten bei 5080%. Diese Zahl sollte man erst einmal verinnerlichen, bevor man weiterliest.

1.3 Woran scheitern Projekte bzw. womit muss man rechnen, wenn Projekte aus dem Ruder laufen? Einige interessante Statistiken

■ ■ ■

3

Abb. 1.4: Wie enden Projekte?

Die damit verbundenen Kosten lagen in den USA 1995 nach einer Schätzung bei 59 Mrd. $ für Kostenüberschreitungen und bei 81 Mrd. $ für abgebrochene SW-Projekte. In Deutschland sind die Kosten, wie in Abb. 1.5 dargestellt, auch nicht günstiger. Die Fülle von Projektmanagement-Literatur und die Anzahl von Vorgehensmodellen lässt erahnen, dass es bei der Durchführung von Projekten ziemliche Schwierigkeiten gibt und dass trotz allem immer eine gewisse Anzahl von Projekten scheitern wird. Abb. 1.5: Verteilung der Kosten bei ITProjekten [13]

Somit ähnelt ein Projektleiter einem Unternehmer, der das Risiko wegen des Gewinns eingeht und der eventuell damit rechnen muss, die entsprechenden Konsequenzen zu tragen. Fragt man jetzt danach, warum denn Projekte scheitern, so gibt einem die Studie in Abb. 1.6 einen Überblick. Da die meisten Projekte einen hohen Anteil an Software beinhalten, ist es interessant sich anzusehen, aus welchen Gründen solche SW-Projekte scheitern. Eine gute Übersicht ergibt sich aus [17]: x Hohe Erwartungen der Auftraggeber/Anwender x Instabile Anforderungen und Ziele

4

■ ■ ■


Abb. 1.6: Ursachen für das Scheitern von Projekten [18]

x Dynamischer Markt x Funktionalitäten nicht eindeutig definiert x Neue Technologien, z. B. neue Versionen (Betriebssystem, Tools u. ä.), während der Projektlaufzeit x Viele Schnittstellen zu bereits vorhandenen Systemen * Programmierer als Projektmanager ohne Erfahrungen und Kenntnisse * Softwareentwicklung ist sehr abstrakt; dem Auftraggeber sind Einzelheiten schwer vermittelbar * Software ist sehr komplex und schwer testbar auf Fehlerfreiheit * Software verhält sich in anderen Umgebungen anders * Akzeptanz kann sich im Projektverlauf verändern * Die Anforderungen sind dem Anwender zu Beginn noch nicht ausreichend klar * Schnelllebigkeit der Umgebung Interessant ist in diesem Zusammenhang auch, welche Art von Softwarefehlern auftritt und wie hoch der Prozentsatz an der Gesamtfehlermenge von Software ist. Abbildung 1.7 gibt darüber Auskunft:


■ ■ ■

5

Abb. 1.7: Arten von Softwarefehlern und ihre Häufigkeit in % [19]

Konfiguration/Versionen

2

Korrekturprobleme

2

Datendefinition

2 6

Dokumentationsfehler Datenbankinhalt

8

Berechnung

8 14

Datenbehandlung Ein/Ausgabe

15

Schnittstellen

15 21

Logik

0

5

10

15

20

25

Nun kann man sicherlich einwenden, dass ein intensives Testen der einzelnen Funktionalitäten in der Entwicklungsphase sowie ein gut vorbereiteter Abnahmetest helfen müssten, vorhandene Fehler innerhalb des Projektendproduktes aufzuspüren. Die folgende Graphik gibt einen ungefähren Eindruck davon, wie viele Fehler sich im Durchschnitt durch die verschiedenen Testverfahren ermitteln lassen. Abb. 1.8: Durchschnittlich gefundene Fehler in % nach [11]

40 36 35 30 25

25

24

23

24

19

20 15 10 5 0

EinheitenTest

SystemTest

Subroutinen- Automatische Neuer IntegrationsTest Regressions- Funktionen- Test Tests Test

Der Anteil der Fehlerbehebung am Gesamtaufwand eines Projektes geht aus Abb. 1.9 hervor:

6

■ ■ ■


19 16 12

12 12 10

Fehlerbehebung

8

Abb. 1.9: Anteil der Fehlerbehebung am Gesamtaufwand in % nach [16]

6 4

Entwicklung

Integration & System Test

Code & Unit Test

Detailed Design

Preliminary Design

1 Requirements

20 18 16 14 12 10 8 6 4 2 0

Die nächste interessante Statistik, die ich gern darstellen möchte, zeigt, wie viel Prozent der Funktionalitäten eines entwickelten DVoder IT-Systems später im Betrieb wirklich genutzt werden. Abbildung 1.10 gibt darüber Auskunft. Wie man erkennt, werden 20% des gesamten Funktionsumfangs immer oder oft verwendet, dagegen 64% des gesamten Funktionsumfanges selten oder nie. Wenn man sich überlegt, wie lange es dauert, die Funktionalitäten zu definieren, zu entwickeln und zu testen, so kann man sich schon die Frage stellen, ob es nicht besser wäre, die gewünschten Funktionalitäten mit einem Faktor zu gewichten und nach diesem die Funktionalitäten der Reihe nach zu entwickeln und zu implementieren, bis die Ressourcen des Projektes aufgebraucht sind. 50 45 40 35 30 25 20 15 10 5 0

Abb. 1.10: Wie viele Funktionalitäten des gesamten Funktionsumfangs eines neuen DVSystems werden genutzt? [20]

45

16

19 13

er Im m

O ft

Se lt e n

M an ch m al

N

ie

7

Dies entspricht dem aus dem DSDM (Dynamic Systems Development Method) abgeleiteten MoSCoW-Prinzip (Must have, Should have, Could have, Would like to have). Ansätze wie Extreme Programming (XP) oder DSDM gehen alle in dieselbe Richtung.


■ ■ ■

7

60

25 7

Projektendarbeiten und Gewährleistungen

Entwicklung, Test und Integration

5 Anforderungsanalyse unter Einbeziehung des Kunden

3

Anfängliche Projektdefinitionsphase

70 60 50 40 30 20 10 0

Projektstart

Abb. 1.11: Ungefähre Kostenverteilung eines Projektes

Des Öfteren wird man gefragt, wie denn die ungefähre Kostenverteilung eines Projektes aussieht und welches die Erfolgsfaktoren eines Projektes sind. Die Abbildungen 1.11 und 1.12 geben darüber Auskunft. Abb. 1.12: Was sind die wichtigsten Erfolgsfaktoren? Nach [20]

Ungewöhnlich ist meiner Meinung nach, dass in Abb. 1.12 der Einfluss von gezielten Schulungen auf das mit dem Projekt betraute Personal nicht genannt wird, was uns natürlich zu der Frage führt, wie viele Unternehmen ihre Mitarbeiter vor einem Projekt gezielt schulen lassen.

8

■ ■ ■


Abb. 1.13: Erhalten Mitarbeiter ein Training vor einem Projekt? [18]

1.4 Probleme bei Projekten Die Erstellung eines neuen DV- oder IT-Systems innerhalb eines Projektes ist immer eine individuelle Angelegenheit. Kein Projekt ist wie das andere. Jedes hat seine eigenen Probleme, Anforderungen, Projektmitglieder und Kunden. Grobe Warnzeichen, dass etwas schief läuft, sind meist viele Krankmeldungen oder häufiger Personalwechsel innerhalb eines Projektes oder einer Firma. Abb. 1.14: Einflüsse auf die Organisation und den Alltag eines Projektes

Die eventuell auftretenden Probleme sind vielschichtig und unzählig. Sie treten in vielen verschiedenen Variationen und Nuancen immer wieder auf. Was sind mögliche Gründe für ein schlechtes Projekt bzw. Projektmanagement und welche Auswirkungen haben sie? Nachfolgend einige Projektprobleme aus der Praxis, die in die Bereiche x Politische oder firmenpolitisch motivierte Probleme x Organisatorische- und planerische Probleme

1.4 Probleme bei Projekten

■ ■ ■

9

x Fachliche und Anforderungs-Probleme x Probleme bei der Zusammenarbeit aufgeteilt wurden.

1.4.1 Politische oder firmenpolitisch motivierte Probleme Der Ansatz, der sich dahinter verbirgt, ist, dass Projekte scheitern, weil sie scheitern sollen (Firmenpolitik) bzw. zum Scheitern gebracht werden (politische Randbedingungen ändern sich). Was sind die Gründe und Auswirkungen? Typisches Beispiel für politische Risiken ist, dass die Gesetzeslage sich ändert oder dass nach Jahren die Grundlage eines Projektes durch politische Konstellationen hinfällig wird. Gerade Großprojekte, die über viele Jahre andauern, sind davon betroffen. Politische bzw. firmenpolitische Vorgaben zwingen Verantwortliche zur Realisierung notwendiger DV-Verfahren, deren Durchführung in einem unrealistischen Terminrahmen erfolgen soll. Hierfür werden des Öfteren externe Dienstleister oder neues externes Personal eingesetzt, das dafür zur Verantwortung gezogen werden kann. Zuweisung von nicht qualifiziertem Personal, Vorenthalten von Informationen und Infrastrukturen; Setzen von unrealistischen Terminen und Budgets; Ausdehnen des Projektes bis hin zum nicht mehr Machbaren – alles aus verkappter Gegnerschaft. Auch mangelnder

Abb. 1.15: Projektleiter müssen starke Nerven haben

Projektanfangsfehler und Projektrisiken

10

■ ■ ■


Support der Firmenleitung oder des oberen Projektmanagements lassen einen Projektleiter mit seinem zugeordneten Projekt scheitern. Eine oft festzustellende Problematik sind Animositäten unterschiedlicher Abteilungen zueinander bzw. das Agieren unterschiedlicher Seilschaften, was sehr häufig dazu führt, dass Projekte scheitern oder an externe Dienstleiter vergeben werden, obwohl sie intern hätten billiger durchgeführt werden können. Ein Projektleiter, der hier nicht den Rückhalt der Geschäftsleitung hat, wird zwischen den unterschiedlichen Abteilungen aufgerieben und wird selten seine Projekte in der geplanten Zeit bzw. innerhalb des Budgets abschließen können. Abb. 1.16: Der ideale Projektleiter

Ein weiteres Beispiel zeigt, wie subtil sich Projektrisiken einschleichen können, obwohl alle das Beste wollen: Eine Entwicklungsabteilung beantragt den Kauf von teuren, genau spezifizierten Schlüsselkomponenten eines Projektes. Die Einkaufsabteilung nimmt eine Marktsichtung vor und erkennt, dass ein anderer Hersteller diese Schlüsselkomponenten preiswerter anbietet, und kauft sie. Die Entwicklungsabteilung stellt nach Lieferung fest, dass sie nicht die spezifizierten Komponenten erhalten hat und die gelieferten nicht verwenden kann. Die Einkaufsabteilung kann die Komponenten aber nicht mehr zurückgeben. Resultat: Durch eine erneute Beschaffung entsteht ein erheblicher Zeitverlust. Durch den Fehlkauf der teuren Komponenten gerät das Projekt in Schieflage und dies nur, weil jeder seine Sache gut machen wollte. Auch scheitern Projekte daran, dass sie durch eine Unternehmensberatung über die maßgeblichen Köpfe einer entsprechenden Firma oder öffentlichen Institution hinweg initiiert wurden und die interne Akzeptanz nicht gegeben ist.


■ ■ ■

11

1.4.2 Organisatorische und planerische Probleme Eines der häufigsten organisatorischen Probleme liegt in der unklaren Abgrenzung von verantwortlichen Personen beim Auftragnehmer und Auftraggeber sowie deren Befugnissen und Pflichten. Dies führt dazu, dass zu viele Personen im Entscheidungsprozess eine Rolle spielen. Auswirkungen sind massive Wartezeiten, die sich durch nachträgliche Abstimmung bzw. Änderungen von Vertragstexten ergeben. Unklare Befugnisse und Verantwortungen einzelner Projektrollen führen dazu, dass sich im besten Fall viele den gleichen Problemen und Aufgaben widmen und im schlechtesten Fall keiner für etwas verantwortlich fühlt. Abb. 1.17: Verschiebung der Einflussfaktoren mit Fortschreiten eines Projektes

Folgendes typisches Beispiel zeigt, wie subtil und natürlich sich Projektrisiken einschleichen, ohne dass man mit entsprechender Personalverantwortlichkeit etwas dagegen unternehmen kann. Der Projektleiter einer Firma bekommt das Recht, Entscheidungen bezüglich eines Projektes zu fällen. Der Abteilungsleiter wiederum hat das disziplinarische Recht, seine Mitarbeiter so einzusetzen, dass der Auslastungsgrad für seine Abteilung optimal ist. Und schon hat man in derselben Firma unterschiedliche Interessen, die sehr wohl Einfluss auf die Projektziele haben können. In diesem Zusammenhang folgendes schöne Beispiel: Ein Projektleiter in einer Dienstleistungsfirma hat zwei Mitarbeiter angefordert, die innerhalb der Entwicklungsabteilung arbeiten. Nun werden ihm beide zugeordnet, obwohl er einen erst später produktiv einsetzen kann. Er ist aber froh, diese Mitarbeiter überhaupt zu bekommen, weil er damit rechnet, dass neue Projekte ihm die benötigten Entwickler abziehen. Am Ende des Projektes wird der Projektleiter in jedem Fall die Quittung für das Überschreiten der Kosten bekommen, weil er den zweiten Mitarbeiter länger einsetzen muss als geplant. Verzichtet er aber zunächst auf den zweiten Mitarbeiter, kann

12

■ ■ ■


es sein, dass dieser Mitarbeiter einem anderen Projekt zugeteilt wird und dadurch sein Projekt als Ganzes scheitert. Exemplarisch ist auch im täglichen Projektgeschäft, dass Mitarbeiter mit notwendigem „Know how“ innerhalb mehrerer Projekte eingebunden sind und immer wieder aus dem eigenen Projekt herausgezogen werden, weil die interne Firmenpolitik dies so entscheidet. Resultat ist, wie in allen vorher beschriebenen Beispielen, eine Kosten- und Endterminüberschreitung des Projektes. Oft ist es auch so, dass einzelne Projektmitglieder mit zu vielen Aufgaben betraut werden, die sie nicht mehr bewältigen können, bzw. dass sie in unterschiedliche Projekte zur gleichen Zeit involviert sind. Dass dies über längere Zeit Auswirkungen auf die Projekte haben wird, liegt auf der Hand, besonders wenn diese Projektmitglieder Kernfunktionen eines Projektes programmieren. Organisatorische Probleme ergeben sich auch aus der Größe eines Projektes, die sich sehr oft auf die Durchführungszeitdauer auswirkt. Dies kann passieren, wenn es die Komplexität des Projektes erforderlich macht, zunächst ein langwieriges Konzept mit Anforderungsanalyse durchzuführen, und sich in dieser Zeit die technischen Möglichkeiten und Ressourcenanforderungen verändern. So ist es klar ersichtlich, dass ein Server- oder Arbeitsplatzsystem von heute in 3 Jahren völlig veraltet ist. Werden dann in der langen Projektlaufzeit Teilkomponenten wie die Arbeitsplatzsysteme gekauft, die darauf lauffähige Software aber erst in ein bis zwei Jahren implementiert, so ist mit einer mangelnden Performance und einem unzufriedenen Kunden zu rechnen. Der Bundesrechnungshof stellte in diesem Zusammenhang fest, dass spätestens ab 2 Jahren Laufzeit jedes ITProjekt von der Technologieentwicklung überrollt wird. Grundlage dieser Aussage war die Feststellung, dass viele öffentliche IT-Projekte in Deutschland eher scheitern, je länger sie dauern. Oft ist der Projektleiter in die Angebotsspezifikation eines Projektes noch gar nicht mit eingebunden, sondern bekommt das Projekt zur Durchführung von der Vertriebsabteilung nach Vertragsabschluss übergeben. Ein planerisches Problem des Projektleiters ergibt sich automatisch aus der Unklarheit über Leistungsumfang, Abnahmeprozeduren und test- bzw. qualitätssichernde Maßnahmen am Anfang eines Projektes. Auch wird meist von den Vertriebsabteilungen der Aufwand unterschätzt, eine entsprechende Dokumentation für eine zu erstellende Softwareapplikationen anzufertigen. Bei manchen Aufträgen für Projekte werden Anforderungen an Abnahmevorgang und spezifische Testszenarien entweder gar nicht oder schlecht definiert bzw. nicht sorgfältig und nicht im erforderlichen Maße durchgeführt. Auch werden benötigte Zeiten dafür nicht mit eingeplant.


■ ■ ■

13

Abb. 1.18: Ergebnis einer Anforderungsanalyse am Anfang eines Projektes

Schlimm ist es auch, wenn eine unklare Beschreibung des Kunden über den Leistungsumfang eines Projektes vorliegt, denn dann werden Aufwandsrisiken oft unterschätzt. Auch werden oft Begriffe im Hinblick auf die Funktionalität genannt, die nicht unzweifelhaft sind. So können zum Beispiel Begriffe wie „Web-basierend“, „Web Services“ oder aber „SOA (Serviceorientierte Architektur)“ oft unterschiedlich ausgelegt werden. Hier sollte der Kunde aufgefordert werden, seine Vorstellung dieser Begriffe und die Ausführung bezüglich der Funktionalitäten des Projektes zu beschreiben. Ein weiteres schönes Praxisbeispiel betrifft die Schätzung des Arbeitsaufwandes und des Zeitpunkts für den Endtermin eines Projektes. Hier wird ganz einfach der Fehler gemacht, den Urlaub der Mitarbeiter, die dem Projekt zugeordnet werden sollen, nicht zu berücksichtigen. Daraus ergeben sich Wartezeiten im Projekt, die sich als Kosten- und Zeitüberschreitung auswirken. Im folgenden Praxisbeispiel wird gezeigt, wie Projekte in eine Schieflage geraten können: Ein großes Projekt in der Anfangsphase ohne Projektleiter führt dazu, dass die Abteilungsleitung im großen Stil Weiterbildungsmaßnahmen der gesamten Abteilung auf Projektkosten beschließt und der spätere Projektleiter dadurch mit einem kleineren Budget auskommen muss. Da der Projektleiter auf die Zusammenarbeit mit der Abteilungsleitung angewiesen ist, wird er einen tieferen Konflikt vermeiden wollen, obwohl er notwendig wäre. Auch passiert es oft, dass ein Projektleiter weitere Mitarbeiter bekommt, um zeitliche Schieflagen im Projekt zu bereinigen, für deren Einarbeitung aber am Anfang Zeit eingeplant werden muss. Das Fehlen eines definierten, strukturierten Vorgehens oder eines definierten Vorgehensmodells in der Projektumsetzung zwischen Auftraggeber und Auftragnehmer führt automatisch zu Missverständnissen und Abstimmungsproblemen und damit zu häufigen

14

■ ■ ■


Definierte Kommunikationswege durch Projektmanagement-Frameworks Projektrisiken

Auftragnehmer (AN)

Projektmanagement-Framework wie z. B: V-Modell, PRINCE II

Abb.1.19: Kommunikation in Projekten muss klar definiert sein

Auftraggeber (AG)

Veränderungswünsche

Feuerwehr-Aktionen. Risiken, Änderungswünsche und Veränderungen im Projektumfeld leiten dann keine automatischen Regulierungsprozesse (definierte Eskalationsstufen) ein, die für die meisten Projektmanagementframeworks selbstverständlich sind. Oft scheitert ein Projekt auch daran, dass der Auftraggeber einzelne Personen des Auftragnehmers, z. B. den Entwickler, Änderungen am zu entwickelnden Endprodukt eines Projektes „auf Zuruf“ oder „unter der Hand“ durchführen lässt, ohne dass die Projektleitung des Auftragnehmers davon erfährt, und dadurch das Projekt aus dem Kosten- und Zeitrahmen herausfällt. Der Auftragnehmer hat dann keine Dokumentation, anhand derer er dem Auftraggeber beweisen kann, dass Änderungen der Kosten oder des Projektendzeitdatums durch den Auftraggeber selbst verursacht wurden. Hier hilft nur ein Vorgehensmodell, in dem das Problem- und Änderungsmanagement am Anfang eines Projektes vom Auftragnehmer und Auftraggeber gemeinsam abgestimmt werden. Auch kann es passieren, dass durch ein unvernünftig hohes Maß an Controlling und Verwaltungsaufwand das Budget des Projektes übermäßig strapaziert wird. Hier das richtige Maß, besonders bei kleinen bis mittleren Projekten, zu finden, ist nicht unbedingt einfach. Eine schlechte Zeitabschätzung zur Durchführung einzelner Tätigkeiten oder Erstellung von Teilerzeugnissen eines Projektes führt zur Verschiebung des Fertigstellungstermins und zur Überschreitung der kalkulierten Kosten. Das gleiche ist der Fall, wenn notwendige Komponenten nicht rechtzeitig geliefert werden bzw. nicht vollständig spezifiziert sind. Schlechtes oder nicht vorhandenes Projektmanagement führt dazu, dass viele an einem Projekt arbeiten, ohne dem Projektziel näher zu kommen. Risiken werden erst bemerkt, wenn sie eingetroffen sind. Oder aber es geht der Überblick über Kosten und Projektstand verloren.


■ ■ ■

15

Abb. 1.20: Die vier Dimensionen des Projekterfolges

Lösungsumfang

Termine

Erfolgreiches Projekt

Qualität

Kosten

Manchmal bekommt ein Dienstleister den Projektauftrag, obwohl die nötigen Fachkenntnisse nicht vorhanden sind bzw. erst durch lange Fortbildung erworben werden müssen. Zeit- und Kostenüberschreitung sind hier bei Auftragsvergabe direkt eingeplant. Situationen, in denen ein nicht zuzuordnender Fehler innerhalb eines IT-Systems die Mitwirkung der davon betroffenen Firmen erfordert, führen automatisch zunächst einmal dazu, dass beide Firmen behaupten, das von ihnen gelieferte Teilsystem sei für diesen Fehler nicht verantwortlich. Im günstigsten Fall wird nach einer zeitlichen Verzögerung der Fehler in einer gemeinsamen Aktion der betroffenen Firmen gesucht und beseitigt. Ob dies bei der Kalkulierung der Kosten und Ausarbeitung der Zeitpläne schon bedacht worden ist? Wohl kaum. Besonders schlimm ist diese Situation für den Kunden, wenn es keine Generalunternehmerschaft innerhalb des Projektes gibt. Verschiebungen des Zeitpunkts in die produktive Nutzung sind hier sicher. Hier hilft nur ein Vertragspassus, der darauf Bezug nimmt. Projekte, in denen Teilprojekte an unterschiedliche Firmen vergeben werden, ohne Generalunternehmer, sind zwar möglich, sollten aber so weit es geht vermieden werden, um potentielle Kosten- und Zeit-Überschreitungen durch nachträgliche Zuordnung von Verantwortlichkeiten zu vermeiden. Ein weiteres Praxisbeispiel zeigt, wie schnell eine Generalunternehmerschaft für einen Dienstleister unangenehme Folgen haben kann. Die Situation stellt sich wie folgt dar: Ein Generalunternehmer hat verschiedene Subunternehmer. Ein Subunternehmer, der eine Schlüsselkomponente entwickeln soll, gerät in Insolvenz. Nun muss der Generalunternehmer diese kompensieren und die Schlüsselkomponente selbst entwickeln. Für den Auftraggeber ändert sich außer einer Zeitverschiebung des Projektendtermins nichts, da er ja den gesamten Projektauftrag an einen Generalunternehmer vergeben hat. Der Generalunternehmer bleibt aber auf den Kosten sitzen. Der Projekterfolg ist gefährdet.

16

■ ■ ■


1.4.3 Fachliche und anforderungsbedingte Probleme

Te ch

no l

ts äf e ch s es zes G o pr

og i

e

Fachliche Probleme ergeben sich meist durch nicht zeitgemäße Aktualität der verwendeten Technologie, Information sowie Spezifikationsdokumente. Abb. 1.21: Verschiedene Belange wirken auf ein Projekt ein

Ve rf üg ba rk

rt ze ei ut hk en lic B nd eu fr

ei t

Projekt

Beispiel hierfür ist der Einsatz einer technisch nicht ausgereiften Technologie bzw. im anderen Extrem einer veralteten. Auch passiert es manchmal, dass die Anforderungen vom Auftragnehmer nicht verstanden bzw. die Komplexität des Projektes unterschätzt wird. Oft wird bei der Auftragsvergabe nur auf die Kosten gesehen und der Auftrag dabei an einen Projektdienstleister mit mangelnder Kompetenz in den abzubildenden Geschäftsprozessen vergeben. Ein weiteres schönes Beispiel für fachliche Probleme ist, wenn beim Dienstleister Technologiedenken vorherrscht und kein Erfolgsdenken, d. h. Probleme werden auf rein technischer Basis angegangen und weniger als projektübergreifendes Ganzes. Dies kann dazu führen, dass die im Produkt abgebildeten Arbeitsprozesse unvollständig sind oder nicht richtig abgebildet werden. Mitunter passiert es auch, dass sich eine sicherlich notwendige Spezifikation dessen, was gemacht werden muss, in 10.000en von Seiten wiederfindet, für die der Hauptteil der Projektkosten aufgewendet wird. Für den Rest des Projektbudgets bleibt dann kaum noch etwas übrig. Da Papier geduldig ist, wird manche reale Unsicherheit nicht erfasst. Deshalb ist es erforderlich, die Papiermasse


■ ■ ■

17

Abb. 1.22: Bestehende verdeckte Projekt-Anforderungen entwickeln sich oft zu gefährlichen Projektrisiken

auf ein notwendiges Maß zu reduzieren und bei großen Projekten spezifikationsbegleitend einen Prototypen anfertigen zu lassen. Heutige Software beinhaltet eine steigende Anzahl von möglichen Schnittstellen mit den implizierten entsprechenden Problemen. Bei Beschreibungen von Schnittstellen ergibt sich oft das Problem, dass diese nicht aktuell sind und Änderungen zeitintensiv durch Ausprobieren vorgenommen werden müssen. Auch können Schnittstellen erst dann auf ihre Funktionalität überprüft werden, wenn diese zur Verfügung stehen. Hier kann es dann passieren, dass notwendige Nachbesserungen die Inbetriebnahme des Projektendproduktes verzögern. Meist werden auch die Aufwände zur Integration von bestehenden externen Schnittstellen unterschätzt. Ein Fehler, der des Öfteren auftritt, besteht darin, dass sich bei der Integration des zu entwickelnden Systems herausstellt, dass die bestehende Infrastruktur beim Kunden nicht oder erst nach einer gewissen Zeit mit dem entwickelten System funktioniert. Auch bei der Beschreibung des Workflows oder der Gestaltung der Benutzeroberfläche liegen oft unterschiedliche Vorstellungen beim Auftraggeber und beim Auftragnehmer vor. Hier hilft nur, eine genaue Beschreibung des Workflows sowie der einzelnen Bildschirmmasken der graphischen Nutzeroberfläche vom Kunden einzufordern. Oft muss der Kunde aufgefordert werden, weitere Spezifikationen nachzuliefern; er kommt dieser Nachforderung aber erst nach längerer Zeit nach. Dadurch ergeben sich Kosten- und Zeitüberschreitungen beim Auftragnehmer. Besser ist es hier, einen Prototypen zu vereinbaren, der die vom Auftraggeber beschriebenen Workflows abbildet, und ein Management, welches die erforderlichen Änderungen einfließen lässt und die Aufwände fakturieren hilft. Ein häufiger vorkommendes Beispiel ist, dass eine fehlerhafte Feinspezifikation des Kunden zu einem Endprodukt führt, dessen Brauchbarkeit nicht gegeben ist, oder dass das Endprodukt nicht den Vorstellungen des Kunden entspricht. Qualitätskontrollen von

18

■ ■ ■


Ansteigende Kosten durch späteren Zeitpunkt bei Veränderungen

Abb. 1.23: Änderungen im Projekt sollten frühzeitig vorgenommen werden

Projektdurchführung

Steigende Projektkosten Teilerzeugnissen, ein „Walk Through“ zu wesentlichen Projektzeitpunkten oder ein Prototyp hätten dies verhindern können. Ein häufiges Problem ist auch, dass ein Projekt umgesetzt wird, es sich aber herausstellt, dass performance- oder verfügbarkeitssteigernde Maßnahmen nicht eingebracht wurden, um Kosten und Zeit zu sparen. Es kommt auch vor, dass zu Beginn eines Projektes bzw. der Entwicklung keine ausreichenden Anforderungsdokumente zur Spezifikation der geforderten Leistung vorliegen, man aber das Projekt unter allen Umständen haben will. Manchmal ist es auch so, dass der Endanwender oder Nutzer bei der Auftragsvergabe des Kunden nicht mit eingebunden ist oder die Anforderungsanalyse nicht mit unterstützt hat.

Projektziel ?


Abb. 1.24: Kunde und Dienstleister haben des Öfteren unterschiedliche Meinungen darüber, wie das Endprodukt eines Projektes aussehen soll

■ ■ ■

19

Das Endprodukt mutiert in diesem Fall zu verschiedenen Ausprägungen (moving targets), je nachdem, mit welchen Kundenverantwortlichen man redet. Hier ist es notwendig, dem Kunden diesen Sachverhalt vor Augen zu führen und beharrlich eine genaue Spezifizierung des Endproduktes zu verlangen. Bei öffentlichen Ausschreibungen ist es oft so, dass Anforderungen, die innerhalb der Ausschreibung spezifiziert sind, nicht ergänzt werden dürfen, ohne die Ausschreibung zu wiederholen, was einen erheblichen zeitlichen Verzug mit sich bringt sowie eine veränderte Bieter- und Konkurrenzsituation bei einer erneuten Ausschreibung. Dies ist weder für den öffentlichen Auftraggeber noch für die Bieterfirmen ohne Gesichts- oder Auftragsverlust möglich, so dass durch die mangelhafte Anforderungsspezifikation schon am Anfang eines Projektes der Keim für Missverständnisse gelegt ist. Für den Kunden kann es ein Ärgernis darstellen, wenn keine oder nur wenige Informationen über notwendige Wartungsarbeiten am Projektendprodukt vorhanden sind. Dies führt im täglichen Betrieb unweigerlich zu Stillstandszeiten des neuen DV-Systems. Als Fehler stellt sich bei Projekten öfters heraus, dass man DVVerfahren in einer anderen Software-Technologie (CMS, CORBA, SOA, Webservices) abbilden will, aber keinen Überblick darüber besitzt, welche Vor- und Nachteile diese Technologien haben bzw. welche Voraussetzungen dafür bestehen müssen. Hier hilft es, sich in die Lage eines Entwicklers zu versetzen, der die Aufgabe hat, dieses neue DV-Verfahren zu realisieren. In einer Schulung oder einem Workshop, die einfache Beispiele der Realisierung einzelner Funktionalitäten enthalten, lässt sich sehr schnell erkennen, welche Eigenschaften und Kernpunkte eine Realisierung mit sich bringt. Abb. 1.25: Nicht nur für das U-Boot Nautilus ein guter Wahlspruch

Mann kann dies vergleichen mit dem Prototyping-Ansatz des V-Modells. Anhand von realen Szenarien lässt sich eine genauere Vorgehensweise in einem zukünftigen Projekt ableiten.

20

■ ■ ■


1.4.4 Probleme bei der Zusammenarbeit Interpretiert man die Aussage von John Gage von Sun Microsystems „Technology is easy – people are hard“ richtig, so kommt dem menschlichen bzw. zwischenmenschlichen Bereich in Projekten eine große Bedeutung zu. Beispiele für das Scheitern von Projekten wegen menschlicher Probleme gibt es viele. Manchmal ist die Kommunikation innerhalb oder außerhalb der Entwickler-Projektgruppe gestört und macht sich meist erst dann bemerkbar, wenn die einzelnen zu entwickelnden Teilprodukte oder -funktionalitäten der Entwickler miteinander verbunden werden sollen. Dies ist besonders der Fall, wenn einzelne Projekterzeugnisse von unterschiedlichen Abteilungen gefertigt werden. Eine schlechte Kommunikation innerhalb eines Projektes führt dazu, dass Probleme nicht frühzeitig erkannt werden, Informationen nicht an die richtige Stelle gelangen, Teilerzeugnisse nicht den Erfordernissen und Erwartungen des Kunden entsprechen sowie normale Probleme eines Projektes über Gebühr eskalieren. Gute Entwickler sind meist eine Art Künstler und nicht immer unbedingt Kommunikationsgenies. All diese menschlichen Eigenschaften, die in normalen Situationen kaum eine Auswirkung haben, werden dann innerhalb eines Projektes zu einem ernsthaften Problem. Steigt der Erfolgsdruck oder befindet man sich in der Nähe des Auslieferungstermins, so arbeitet oft jeder Entwickler an seinem Teil, ohne das Gesamtbild im Auge zu haben. Hieran kann man eine schlechte Zusammensetzung des Projektteams und des Managementkreises, der zur Projektsteuerung eingesetzt wurde, erkennen. Ein weiterer Grund für das Scheitern eines Projektes kann darin liegen, dass sich keiner der Projektbeteiligten verantwortlich fühlt bzw. dass keine Verantwortlichkeit zugeordnet wurde, wie dies auch Abb. 1.26: Menschliche Einflussgrößen auf den Projekterfolg


■ ■ ■

21

Abb. 1.27: Innerhalb einer Projektgruppe ist dies manchmal ein guter Rat

„Wovon man nicht sprechen kann, darüber muss man schweigen.“ Ludwig Wittgenstein

sehr schön aus dem Ausspruch in Abb. 1.28 hervorgeht. Die Ursache liegt oft darin, dass eine Firma wenig Wert darauf legt, eine Firmenkultur zu entwickeln, in der sich schlagfähige Strukturen bilden können. Ein passendes Beispiel für Probleme bei der Zusammenarbeit ist, dass notwendige Entscheidungen nur halbherzig getroffen werden, weil die Konsequenzen von der Firmenleitung angeblich nicht mitgetragen werden können. Dies ist besonders der Fall, wenn Machtund Interessenskonflikte die Entscheidungsprozesse behindern. Bei Offshoring- oder Outsourcing-Projekten kann die Kommunikation bezüglich Sprach- und Denkbarriere sowie Dokumentationstechniken ein Problem sein. Abb. 1.28: Eine Geschichte aus dem Leben

This is a story about four people named Everybody, Somebody, Anybody, and Nobody. There was an important job to be done, and Everybody was asked to do it. Everybody was sure Somebody would do it. Anybody could have done it, but Nobody did it. Somebody got angry about that, because it was Everybody's job. Everybody thought that Anybody could do it, but Nobody realized that Everybody wouldn't do it. It ended up that Everybody blamed Somebody when Nobody did what Anybody could have done!

1.4.5 Methoden zur Risikoidentifikation innerhalb eines Projektes Es ist klar verständlich, dass man Risiken, die man früh erkennt, auch frühzeitig beseitigen bzw. deren Auswirkungen mildern kann. Dem Risikomanagement wird unter dem Projektmanagementframework PRINCE 2 besondere Bedeutung beigemessen.

22

■ ■ ■


PRINCE 2 ordnet identifizierten Projektrisiken bestimmte Wahrscheinlichkeiten und Risikoschwellwerte zu. Aber aus welchen Richtungen und Gebieten können sich für ein Projekt Risiken ergeben? Die folgende Aufzählung gibt darüber Auskunft: x Rechtliche x Politische x Organisatorische x Technische x Menschliche x Finanztechnische x Vertragstechnische x Infrastrukturelle Abb. 1.29: Grund für das Risikomanagement eines Projektes

Wir wollen uns im Folgenden überlegen, welche Methoden der Risikoidentifikation innerhalb eines Projektes möglich sind. Die folgende Aufzählung gibt einen Überblick: x Brainstorming mit Mitarbeitern der IT x Risikokataloge x Szenario-Analysen x x x x x x

Expertenbefragungen Analyse früherer Schadensfälle Brainstorming mit Anwendern Brainstorming mit Unternehmensführung Projektassessments und Softwareinspektionen Tests an Prototypen


■ ■ ■

23

Sind potentielle Risiken identifiziert und deren potentielle Wirkung klassifiziert, so muss im Vorfeld überlegt werden, auf welche Art und Weise auf diese Risiken reagiert werden kann und wie die Risiken laufend überprüft (monitoring) werden können. Oft kann auch der Projektlösungsansatz so gewählt werden, dass das Eintreffen eines Projektrisikos keine größeren Auswirkungen hat, indem z. B. eine Vier-Prozessor-Hardwareplattform angeschafft wird, obwohl nur mit einer notwendigen Rechnerleistung von zwei Prozessoren gerechnet wird. Abb. 1.30: Riskmanagement ist ein Teil des Projektmanagements

PRINCE 2 ordnet einzelne Risiken oder deren Monitoring einzelnen Projektmitgliedern zu, die dafür verantwortlich sind, diese im Auge zu behalten und frühzeitig darauf hinzuweisen, dass sie eintreffen.

1.4.6 Projektkrisenmanagement Ein Projektkrisenmanagement hat die ehrenwerte Aufgabe, als erstes den Ist-Zustand eines im Scheitern befindlichen oder gescheiterten Projektes aufzunehmen und zu bewerten. Hierunter fällt, welche Arbeitspakete nach Terminplan offen sind und wie der Sachstand in den jeweiligen bekannten und unbekannten

24

■ ■ ■


Abb. 1.31: Ohne ProjektFrühwarninstrumente verliert man wertvolle Zeit zum Handeln

Arbeitspaketen ist. Auch muss man sich zuerst einmal einen Überblick darüber verschaffen, wer einem Projekt zugeordnet ist und welche Aufgaben er hat. Daneben müssen die Ziele des Projektes (Kunde, Dienstleister) neu definiert werden. Nachdem der Ist-Zustand ermittelt wurde, wird meist ein Projektberichtswesen eingeführt und Projektfrühwarninstrumente installiert, die vor bevorstehenden Projektkrisen warnen können. Ist man an einem solchen Punkt angelangt, muss eine situationsbedingte Problemanalyse bestimmen, ob ein Projekt weiterverfolgt werden soll oder ob es beendet wird.

1.4.7 Kosten des Projektmanagements Wir wollen hier der Frage nachgehen, ab wann sich ein Projektmanagement lohnt und mit welchen Kosten einschließlich der daraus resultierenden Mehraufwendungen zu rechnen ist. Schon bei der Kalkulation von Projekten sind die Aufwände abzuschätzen, die durch ausreichende Projektorganisation und Projektmanagement entstehen. Dabei ist die Klassifizierung der Projektgröße von Bedeutung. Projektgröße

Anzahl Mitarbeiter

Mannjahre

Td. Euro

PM Kosten Faktor in %

Sehr kleine

150

> 500

12

> 51 Mio.


Tabelle 1.1: Projektgrößen und Projektmanagementkosten nach [48]

■ ■ ■

25

Abb. 1.32: 5% Mehraufwand durch das PM bringt 20% Kosten-, Zeitersparnis [49]

Kosten

Bei kleineren Projekten wird der Projektleiter fachliche Aufgaben übernehmen und daneben die erforderlichen Projektmanagementtätigkeiten durchführen. Bei großen Projekten wird er sich hauptsächlich den Projektmanagementtätigkeiten widmen müssen. Bei ganz großen Projekten werden meistens kleinere Einzelprojekte definiert, denen je ein Teil der Projektmanagementtätigkeiten zugeordnet wird. Die Koordination wird dabei von einem Gesamtprojektleiter durchgeführt.

Mit Projektmanagement

20 % KostenErsparnis 20 % ZeitErsparnis

Ohne Projektmanagement

Zeit

Ein Problem in der Praxis besteht darin, dass man bei Ausschreibungen in starkem Konkurrenzdruck zu anderen Anbietern steht, und deshalb des Öfteren gerade die Projektmanagementkosten einspart, unter dem Motto „das machen wir nebenbei“. Dies rächt sich oft im Nachhinein.

26

■ ■ ■


2 Vergabe und Allgemeine Geschäftsbedingungen der Öffentlichen Hand

Viele IT-Dienstleister und Unternehmensberatungen beteiligen sich an öffentlichen Ausschreibungen. Wer im Projektgeschäft mit der Öffentlichen Hand zu tun hat, kommt um die VOL (Verdingungsordnung für Leistungen) in den Ausführungen A und B nicht herum. Deswegen wollen wir der Frage nachgehen, was diese im Einzelnen behandeln. Planung

Ausschreibung

Bewertung

Ausfü Ausführung

Abnahme

Die VOL/A regelt die Vergabe von Aufträgen der Öffentlichen Hand. Kommt ein Vertrag zustande, dann sind automatisch die AGB (Allgemeinen Geschäftsbedingungen) der Öffentlichen Hand, nämlich die VOL/B, Vertragsbestandteil.

Abb. 2.1: Schematischer Beschaffungsvorgang der Öffentlichen Hand

2.1 Arten der Vergabe nach VOL/A Da die Europäische Gemeinschaft jährlich öffentliche Aufträge im Umfang von 1500 Milliarden Euro vergibt, ist es wichtig, sich mit den Arten der Vergabe zu beschäftigen. Des Öfteren findet man verschiedene Begriffe, die bei Ausschreibungen öffentlicher Auftraggeber bezüglich des Vergabeverfahrens auftauchen. Das Beschaffungswesen der Öffentlichen Hand ist eine Spezialmaterie. Wie man in Abb. 2.2 erkennt, ist die Beschaffung von Waren ein rechtlich komplexes Konstrukt, das durch die VgV (Verordnung über die Vergabe öffentlicher Aufträge) geregelt ist. Grundsätzlich erfolgt die Vergabe von Aufträgen im Namen des Staates als „öffentliche Ausschreibung“, d. h. nach öffentlicher Aufforderung

2.1 Arten der Vergabe nach VOL/A

■ ■ ■

27

Abb. 2.2: Beschaffungsvorgänge der Öffentlichen Hand und deren rechtliche Einordnung

durch entsprechende Publikationen (Bundesanzeiger oder www. bundesausschreibungsblatt.de) können Unternehmen ihre Angebote einreichen. Es gilt hier der Transparenzgrundsatz, d. h. alle Entscheidungen eines Vergabeverfahrens müssen dokumentiert und nachvollziehbar sein. Der Begriff Teilnehmerwettbewerb, der öfters fällt, bedeutet hierbei nichts anderes als die öffentliche Aufforderung, sich um die Teilnahme an einer Ausschreibung zu bewerben. Die Art der Vergabe von öffentlichen Aufträgen erfolgt meist nach der VOL/A. Bei Ausschreibungsverfahren nach VOL (Verdingungsordnung für Leistungen) unterscheidet man grundsätzlich, ob die Vergabe national oder EU-weit erfolgen muss. National sind innerhalb des §3 der VOL/A die folgenden Vergabearten definiert: x Öffentliche Ausschreibung x Beschränkte Ausschreibung x Freihändige Vergabe x Verhandlungsverfahren Ab einem bestimmten Schwellen- oder Grenzwert muss ein öffentlicher Auftraggeber EU-weit ausschreiben, wobei sich die EUweiten Vergabeverfahren teilweise von den nationalen unterscheiden. EU-weite Vergabeverfahren sind: x Offenes Verfahren x Nichtoffenes Verfahren x Verhandlungsverfahren

28

■ ■ ■


Grenzwerte, ab denen eine EU-weite Vergabe erfolgen muss, sind ab dem 31.1.2006 wie folgt: Gilt für

Dienstleistungsund Lieferaufträge

Zentrale Regierungsbehörden > 162 TEURO (Bundesministerien und Auswärtiges Amt; Bund) Alle anderen öffentlichen Auf- > 249 TEURO traggeber (Länder, Kommunen)

öffentliche Bauaufträge >v6.242.000 EUR

Tabelle 2.1: Schwellenwerte für EU-weite Vergabe

> 6.242.000 EUR

Die einzelnen Varianten der Ausschreibung in Abhängigkeit von den Schwellenwerten werden nachfolgend beschrieben. National unter 249.000 Euro Die öffentliche Ausschreibung ist die Regel. Die Veröffentlichung von Ausschreibungen erfolgt durch entsprechende Publikationskanäle, wie das Bundesausschreibungsblatt oder durch www.evergabeonline.de. Bei der beschränkten Ausschreibung werden eine beschränkte Anzahl von Unternehmen aufgefordert, ein Angebot einzureichen. Gründe für eine beschränkte Ausschreibung können Dringlichkeit oder Geheimhaltung sein oder allgemein, weil eine öffentliche Ausschreibung unzweckmäßig ist. Auch eine außergewöhnliche Fachkunde, Leistungsfähigkeit oder Zuverlässigkeit sind Gründe der öffentlichen Auftraggeber, eine beschränkte Ausschreibung vorzunehmen. Ein Unternehmen kann entsprechend der öffentlichen Aufforderung einen Teilnehmerantrag stellen und dann ein Angebot abgeben. Bei der freihändigen Vergabe wird ohne ein förmliches Vergabeverfahren ein Auftrag platziert. Voraussetzung dafür sind drei vorliegende Angebote. Weiterhin ist dies aber nur zulässig, wenn die Leistung nicht eindeutig und erschöpfend beschreibbar ist, eine Monopolstellung vorliegt, die Geheimhaltung oder eine besondere Dringlichkeit es erfordert oder es sich um geringfügige Vergaben handelt. Mit einem Bieter nach Öffnung des Angebotes in Verhandlung zu treten, ist nach §24 VOL/A nur dann möglich, wenn Zweifel über die Angebote oder die Bieter bestehen. §24 VOL/A erlaubt es, mit dem Bieter, dessen Angebot als das wirtschaftlichste gewertet wurde, beim Nebenangebot und Änderungsvorschlag eines Angebots aufgrund funktionaler Leistungsbeschreibung noch geringe technische Änderungen zu vereinbaren sowie den zugeordneten Preis entsprechend anzupassen.

2.1 Arten der Vergabe nach VOL/A

■ ■ ■

29

Abb. 2.3: Schematische Übersicht der Ausschreibungsverfahren nach VOL

Ausschreibung und Vergabe für Dienstleistungs- und Lieferaufträge

> 249.000 Euro

< 249.000 Euro

EU-weite Ausschreibung

Nationale Ausschreibung

Offenes Verfahren

Öffentliche Ausschreibung

Nichtoffenes Verfahren

Beschränkte Ausschreibung

Verhandlungsverfahren

Freihändige Vergabe

EU-weit über 249.000 Euro Die Ausschreibungsvarianten bei einer EU-weiten Ausschreibung sind für das offene sowie das nichtoffene Verfahren ähnlich den nationalen Ausschreibungsvarianten „Öffentliche Ausschreibung“ und „Beschränkte Ausschreibung“. Publiziert werden Ausschreibungen unter anderem auf den Links http://ted.publications.eu.int und http://publications.eu.int. Bei der EU-weiten Ausschreibung stellt das Verhandlungsverfahren noch eine weitere Variante der möglichen Ausschreibungsverfahren dar. Es ist in zwei Ausprägungen (mit und ohne Vergabebekanntmachung) vorzufinden. Hier ist es grundsätzlich erlaubt, mit dem Bieter in Verhandlung zu treten, falls bei der Vergabebekanntmachung der Bieter ein unzulässiges Angebot abgegeben hat. Dies ist der Fall, wenn z. B. Änderungen an der ausgeschriebenen Leistungsbeschreibung vorgenommen wurden. Bei der Ausschreibung ohne Vergabebekanntmachung darf in ein Verhandlungsverfahren mit den Bietern getreten werden, wenn das offene bzw. nichtoffene Verfahren zu keinem wirtschaftlichen Angebot geführt hat. Da die Vergabe öffentlicher Aufträge nicht immer so klar auf der Hand liegt, hat die Industrie- und Handelskammer in fast jedem Bundesland so genannte Auftragsberatungsstellen eingerichtet, die bei Fragen kompetent Auskunft geben. Unter www.abst.de findet man die nächste Auftragsberatungsstelle oder den jeweiligen Ansprechpartner.

30

■ ■ ■


2.2 Neues Vergaberecht sowie e-Vergabe Das Vergaberecht unterliegt einem ständigen Wandel. Durch die Umsetzung der EG-Richtlinien 2004/17/EG (Sektorenkoordinierungsrichtlinie) und 2004/18/EG (Vergabekoordinierungsrichtlinie) verändert sich das Vergabeverfahren in verschiedener Art und Weise (EU-Legislativpaket) ab dem 31.1.2006. Unter anderem werden die Grenzwerte, ab denen EU-weit ausgeschrieben werden muss, geändert. Der neue Schwellenwert für Dienstleistungs- und Lieferaufträge liegt bei Bundesministerien und beim Auswärtigen Amt (zentrale Regierungsbehörden) bei 162.000 EUR (ohne MwST) und bei allen weiteren öffentlichen Auftraggebern bei 249.000 EUR (ohne MwST). Bei öffentlichen Bauaufträgen ab einem Schwellenwert von 6.242.000 EUR (ohne MwST) muss auch europaweit ausgeschrieben werden. Auch wird eine erhöhte Anforderung an die Dokumentationspflicht des Auftraggebers gestellt, aus der hervorgeht, warum ein Bieter den Zuschlag für eine zu vergebende Leistung erhält. Weiterhin wird der erweiterten Nutzung von Handelsplattformen des Internets (elektronische Auktion sowie dynamische elektronische Verfahren) durch die Öffentliche Hand Rechnung getragen und entsprechende Regelungen vorgegeben. Das neue Vergaberecht fügt den alten Vergabeverfahren die folgenden Begriffe hinzu: x Wettbewerblicher Dialog x Dynamisches Beschaffungssystem x Elektronische Auktion Wir wollen diese Punkte nachfolgend mit Leben füllen. Wettbewerblicher Dialog Der wettbewerbliche Dialog stellt ein neues Verhandlungsverfahren dar, das bei besonders komplexen Aufträgen der Öffentlichen Hand angewendet werden darf. Voraussetzung dabei ist, dass der Auftraggeber objektiv nicht in der Lage ist, die technischen Mittel sowie die rechtlichen oder finanziellen Konditionen des Vorhabens anzugeben. Für diesen Fall kann der öffentliche Auftraggeber im Vorfeld der Ausschreibung Gespräche mit Unternehmen führen, um entsprechende Lösungsvorschläge zu erarbeiten, auf deren Basis diese Unternehmen dann im Anschluss ein verbindliches Angebot abgeben. Der wettbewerbliche Dialog wird auch als „nichtoffenes Verfahren mit vorgeschaltetem technischen Dialog“ bezeichnet.

2.2 Neues Vergaberecht sowie e-Vergabe

■ ■ ■

31

Dynamisches Beschaffungssystem Grundlage des dynamischen Beschaffungssystems ist ein Zirkel von Bietern für bestimmte Waren oder Warengruppen, die innerhalb einer elektronischen Handelsplattform angebunden sind. Die Beschaffung kann ohne erneute Eignungsprüfung und innerhalb verkürzter Fristen an bekannte Bieter vergeben werden. Elektronische Auktion Innerhalb der elektronischen Auktion (inverse Auktion) wird über eine elektronische Handelsplattform eine bestimmte Leistung, wie z. B. die Beschaffung von Serverhardware, ausgeschrieben. Verschiedene bekannte Bieter bekommen die Gelegenheit, im Rahmen der elektronischen Auktion innerhalb eines vorgegebenen Zeitfensters oder einer zuvor bestimmten Anzahl von Auktionsphasen ihre Angebote vorzulegen und nachzubessern. In der Regel erhält der kostengünstigste Bieter den Zuschlag für die Lieferung der Leistungen. Die Handelsplattform wird meist von einem Dienstleister zur Verfügung gestellt, der die Auswertung der Bieterangebote übernimmt. Weiterhin weist der Handelsplattform-Dienstleister den vom öffentlichen Auftraggeber entsprechend vorgeschlagenen Bieterkreis in die Arbeitsweise und Handhabung der elektronischen Auktion ein.

2.3 Was ist EVB-IT und BVB? Die grundsätzlichen AGB (allgemeinen Geschäftsbedingungen) der Öffentlichen Hand sind in der VOL/B zusammengefasst. Die VOL/B sind die allgemeinen Vertragsbedingungen für die Ausführung von Leistungen (ausgen. Bauleistungen). Sie gelten für Kauf-, Werk- und Werklieferungsverträge sowie für Dienstverträge entsprechend. Bei der Vergabe von Aufträgen der Öffentlichen Hand muss VOL/B Vertragsbestandteil sein. Bund, Länder und Kommunen nutzen in allen Bereichen des öffentlichen Lebens DV- und IT-Verfahren, um die dahinter liegenden öffentlichen Geschäftsprozesse zu gestalten. Dafür müssen IT-technische Güter und spezielle Dienstleistungen eingekauft werden. Die VOL/B werden deshalb durch EVB-IT (Ergänzende Vertragsbedingungen für die Beschaffung von IT-Leistungen) oder BVB (Besondere Vertragsbedingungen für die Beschaffung von DVLeistungen) ergänzt. Diese kommen je nach Typ der zu beschaffenden Lieferung oder Leistung zur Anwendung. In der EVB-IT oder BVB werden weitere Rahmenbedingungen vorgegeben, wie „besondere, ergänzende oder zusätzliche Vertragsbedingungen“.

32

■ ■ ■


Die besonderen Vertragsbedingungen beschreiben die Erfordernisse des Einzelfalls. Ergänzende Vertragsbedingungen definieren die Erfordernisse einer Gruppe gleich gelagerter Einzelfälle. Zusätzliche Vertragsbedingungen schildern die Erfordernisse, die ständig beim Auftraggeber vorliegen, unabhängig vom Beschaffungsgegenstand. BVB und EVB-IT sollen dazu führen, dass: x vergleichbare Angebote vorliegen (sollen vernünftige Bewertung ermöglichen) x einheitliche Vertragsbestimmungen gelten (sollen zu Transparenz und Vergleichbarkeit beitragen) x ausgewogene Vertragsbestimmungen vorliegen (sollen zu einer ausgewogenen Risikoverteilung führen) x eine ausgewogene Risikoverteilung entsteht (soll zu Akzeptanz und Wirtschaftlichkeit führen). BVB und EVB-IT regeln in Verträgen der Öffentlichen Hand spezielle IT-spezifische Belange und sollen den öffentlichen vertragsgestaltenden Abteilungen eine Unterstützung geben sowie eine praxisgerechte Vertragsgestaltung sicherstellen. Sie geben den Lieferanten ein Vertragsgegenstand

Von der KBSt empfohlener Vertragstyp

Dienstvertrag Kauf von Hardware (ohne werkvertragliche Leistungsanteile) Kauf von Hardware (mit werkvertraglichen Leistungsanteilen) Miete von Hardware Instandhaltung (früher: Wartung) von Hardware Kauf von Standardsoftware (ohne werkvertragliche Leistungsanteile) Miete von Standardsoftware (ohne werkvertragliche Leistungsanteile) Überlassung von Standardsoftware (mit werkvertraglichen Leistungsanteilen) Pflege von Standardsoftware Pflege von Individualsoftware Planung von DV-gestützten Verfahren, insbesondere Planung von Individualsoftware (Planungsphase, fachliches Konzept) Erstellung von Individualsoftware

EVB-IT Dienstleistung EVB-IT Kauf BVB-Kauf

Tabelle 2.2: Übersicht Vertragsergänzungen EVB-IT, BVB sowie deren Anwendungsbereiche

BVB-Miete EVB-IT Instandhaltung EVB-IT Überlassung Typ A EVB-IT Überlassung Typ B BVB-Überlassung Typ II EVB-IT Pflege S BVB-Pflege BVB-Planung

BVB-Erstellung

2.3 Was ist EVB-IT und BVB?

■ ■ ■

33

klares Bild über die zu erbringenden Leistungen durch die immer gleich gestalteten EVB-IT Vertragsergänzungen. Die ersten VOL/B-ergänzenden Vertragstypen der BVB wurden 1972 vom Kooperationsausschuss Automatisierte Datenverarbeitung Bund/Länder/Kommunaler Bereich (KoopA-ADV) und der Industrie erarbeitet, die durch die vom Bundesministerium des Innern (BMI) erarbeiteten Vertragstypen EVB-IT im Jahre 2000 und 2002 abgelöst wurden. Für die weitere Verbreitung ist heute die KBSt (Koordinierungs- und Beratungsstelle der Bundesregierung für Informationstechnik in der Bundesverwaltung) zuständig. Sie stellen bis heute ein einheitliches Regelwerk für die Beschaffung informationstechnischer Produkte dar. Es ist geplant, die EVB-IT um die Vertragstypen EVB-IT Planung und EVB-IT Systemvertrag zu ergänzen. Der Vertragstyp „EVB-IT Kauf“ wird angewendet, wenn fertige Hardware und Standardsoftware gegen eine so genannte Einmalvergütung zur unbefristeten Nutzung einer öffentlichen Institution überlassen wird. Möchte eine öffentliche Institution Schulungs-, Beratungs- oder sonstige Unterstützungsleistungen von einem externen Dienstleister einkaufen, so bildet der Vertragstyp „EVB-IT Dienstleistung“ die Grundlage. Der Vertragstyp „EVB-IT Überlassung Typ A“ wird von einer öffentlichen Institution verwendet, wenn eine Standardsoftware gegen eine Einmalvergütung zur unbefristeten Nutzung erworben werden soll. „EVB-IT Überlassung Typ B“ wird angewendet, wenn eine Standardsoftware für eine zeitlich befristete Nutzung erworben werden soll. „EVB-IT Instandhaltung“ ersetzt die alte „BVB-Wartung“. „EVB-IT Instandhaltung“ wird verwendet, wenn Wartungs- und Instandhaltungsleistungen für Hardware angefordert werden müssen. Möchte ein öffentlicher Auftragnehmer für seine genutzte Standardsoftware einen Release- oder Upgrade-Vertrag abschließen, so ist der Vertragstyp „EVB-IT Pflege S“ anzuwenden. Er wird auch angewandt, wenn ein Upgrade bzw. die Erstinstallation einer Standardsoftware vorgenommen werden oder ein Auskunfts- und Hotline-Service in Anspruch genommen werden soll. EVB-IT Pflege S ersetzt somit den alten Vertragstyp „BVB-Pflege“. Soll die gekaufte Standardsoftware von einem externen Dienstleister installiert, integriert oder angepasst, also eine werkvertragliche Leistung vom externen Dienstleister erbracht werden, dann ist, bis der “EVB-IT-Systemvertrag“ fertig gestellt ist, weiterhin mit „BVBÜberlassung“ zu arbeiten. Da noch nicht alle Vertragstypen zur Beschaffung innerhalb der EVB-IT abgedeckt werden, gilt hier noch die entsprechende alte BVB. Die entsprechenden Vertragstypen können über www.kbst.bund.de bezogen werden.

34

■ ■ ■


2.4 Was versteht man unter einem Los? Innerhalb einer Ausschreibung findet man des öfteren Teile an einem Gesamtprojekt als Teillose. Dies bedeutet, dass für jedes Teillos ein anderer Bieter berücksichtigt werden kann.

2.5 Was versteht man unter einem Lastenund Pflichtenheft? Ein Lastenheft (requirements definition document) nach VDI-VDE 3694 oder DIN 69905 ist die „Gesamtheit der Forderungen des Auftraggebers an die Lieferungen und Leistungen eines Auftragnehmers. Im Lastenheft sind die Forderungen aus Anwendersicht einschließlich aller Randbedingungen zu beschreiben. Diese sollten quantifizierbar und prüfbar sein. Im Lastenheft wird definiert, welche Aufgabe vorliegt und wofür sie zu lösen ist.“ Es ist somit eine Zusammenstellung aller Anforderungen des Auftraggebers hinsichtlich Liefer- und Leistungsumfang. Sie wird in der Planungsphase eines neuen Projektes erstellt und oft auch Grobkonzept genannt. In ihm sind die fachlichen Basisanforderungen aus Anwendersicht einschließlich aller Randbedingungen beschrieben und es schildert, „was“ gemacht werden soll und „wofür“. Das Lastenheft dient auch zur Aufwandsabschätzung eines Projektes. Es enthält auch noch vage, unvollständige und teilweise widersprüchliche Anforderungen, die in der Definitionsphase genauer spezifiziert werden müssen, damit das Projekt geschrieben werden kann. Abb. 2.4: Von der Planung bis zur Abnahme mit Lasten- und Pflichtenheft

2.4 Was versteht man unter einem Los?

■ ■ ■

35

Ein Pflichtenheft (requirements specification document) beschreibt, welche Leistungen der Auftragnehmer wie zu erbringen hat. Die aus der Planungsphase noch offenen Punkte werden in der Definitionsphase geklärt. Im Gegensatz zum Lastenheft sind die Inhalte präzise, vollständig und überprüfbar. Das Pflichtenheft entspricht dem Feinkonzept. Bei einer Softwareapplikation werden die gewünschten Fähigkeiten, Funktionen des Programms sowie das Aussehen der Benutzerschnittstelle (GUI) beschrieben. Zeitliche Anforderungen wie Antwortzeit- und Lastverhalten werden festgelegt. Daneben wird meist auch beschrieben, in welcher infrastrukturellen Umgebung das ausgeschriebene Projektendprodukt eingesetzt wird und welche Wartungsaspekte sichergestellt werden müssen. Es enthält Testfälle bzw. Testszenarien (Qualitätsanforderungen), unter denen sich das Endprodukt bewähren muss, was in einer Abnahme mündet. Das Pflichtenheft wird in der Definitionsphase eines Projektes geschrieben und ist wesentlicher Teil einer Ausschreibung.

36

■ ■ ■


3 Die verschiedenen Sichtweisen auf ein neues DV-Verfahren

Heutige Geschäftsprozesse basieren mehr und mehr auf DV-Verfahren. So stellt sich also zu einem Zeitpunkt, wenn modernisiert werden soll, die Frage, wie die alten Geschäftsprozesse am besten auf DV-gestützte Geschäftsverfahren umgestellt werden können. Damit verbunden ist die Frage, wie dies am besten umgesetzt werden soll. In Zeiten der Globalisierung wird Geschäftsfähigkeit 24 Stunden pro Tag verlangt, um Geschäftspartner rund um den Globus miteinander zu verbinden, zu kommunizieren, Verträge abzuschließen bzw. Waren abzusetzen. Dadurch werden andere Anforderungen an ein DVVerfahren gestellt als früher einmal. Globalisierung bedeutet, sich messen zu müssen mit irgendeiner anderen Firma auf der Welt. Dies stellt fast unerfüllbare Anforderungen an Effizienz, besonders wenn die Firma in Hochlohnstaaten ansässig ist. Also wird versucht, einen Wettbewerbsvorteil durch ein möglichst optimales Geschäftsverfahren und das zugrunde liegende DV-Verfahren zu erhalten. Die spezifische GeschäftsfeldSicht

InformationsSicht

GeschäftsprozessSicht

DV-Verfahren

ApplikationsSicht

Abb. 3.1: Die verschiedenen Sichtweisen auf ein DV-Verfahren bzw. die IT-Architektur oder wie erhält man das Optimum eines DVVerfahrens

TechnologieSicht


■ ■ ■

37

heutigen Anwender der DV-Verfahren wollen die Geschäftsprozesse und die zugrunde liegenden DV-Verfahren aktiv mitgestalten, wenn diese innerhalb der Firmenorganisation neu implementiert werden sollen. Sie wollen die Art und Weise, wie diese DV-Verfahren genutzt werden, beeinflussen, da sie erkannt haben, dass der effektive Gebrauch der IT-Technologie, gekoppelt mit der Veränderung, wie sie diese DV-Verfahren nutzen, über ihren persönlichen und organisatorischen Erfolg bestimmend sein wird. ITIL zeigt uns, dass es sehr wohl verschiedene Sichtweisen gibt, um ein DV-Verfahren zu betrachten, wobei dies stets aus der Warte eines optimalen IT-Services geschieht, also aus dem Wunsch heraus, ein möglichst optimales Design für ein DV-Verfahren zu erreichen, das alle verschiedenen Sichtweisen einer Firma mit berücksichtigt. Ein Ansatz zur Entwicklung eines DV-Verfahrens, das die größte interne Akzeptanz und die höchste Wahrscheinlichkeit hat, die externen Geschäftsziele zu erreichen, ist der so genannte Ansatz über die fünf Architekturblickrichtungen beim Design des neuen DV-Verfahrens. Jede dieser Architekturblickrichtungen sieht die geschäftliche Perspektive oder den Erfolg eines DV-Systems aus unterschiedlicher Richtung. Heutzutage ist ein Paradigmenwechsel festzustellen: weg von der Einzelbetrachtung hin zu einer ganzheitlichen Betrachtung eines DV-Verfahrens. Dies ist notwendig, weil die Komplexität, Abhängigkeit und Kritikalität der DV-Verfahren und der zugrunde liegenden Geschäftsprozesse zugenommen hat. Geschäftsfeldsicht (Business View): Die Geschäftsfeldsicht modelliert die zukünftige Struktur einer Firma in Form logischer Serviceeinheiten, die mit DV-Verfahren arbeiten, welche die veränderten oder reengineerten Geschäftsprozesse einer Firma repräsentieren. Ein methodischer Ansatz, um den immer neuen Anforderungen der heutigen Geschäftswelt gerecht zu werden, liegt in dem Prinzip, dass Geschäftsprozesse erst reengineert werden sollen, bevor Arbeitsprozesse und deren zugeordnete IT-Applikationen neu entwickelt werden. Das Geschäftsmodell einer Firma ist ein Netz von Servicefunktionen, welche die verschiedenen Bedürfnisse und Anforderungen von Kunden und Mitarbeitern miteinander verknüpfen. Geschäftsprozesssicht (Work View): Die Arbeitsarchitektur oder Geschäftsprozesssicht ist die zweite Sichtweise auf die IT-Architektur eines neuen DV-Verfahrens. Nachdem durch die Geschäftsfeldsicht (Business View) die Servicefunktionen überarbeitet wurden, werden diese modelliert mit Arbeitsaktivitäten, zugeordneten Personen, Arbeitsplätzen und zugeordneten Hilfsmitteln, welche auch die benötigten Informationen, die der Arbeit zugrunde liegen, umschließen. Das Ziel der Modellierung einer IT-Architektur durch die Arbeitsarchitektur (Work View) ist es, den effizientesten Weg zu finden, diese

38

■ ■ ■


geschäftsbedingten Aktivitäten mit der notwendigen IT-Technologie zu unterstützen. Daraus entwickelt sich ein neuer, angepasster Geschäftsprozess dieser Firma. Informationssicht (Information View): Genauso wie die neuen Geschäftsprozesse aus dem reengineerten Geschäftsmodell abgeleitet werden, so wird daraus auch das neue Informationsmodell oder Informationsrepository einer Firma abgeleitet. Dieses Informationsmodell ermöglicht es erst, ein DV-Verfahren zu entwickeln, da in ihm sämtliche spezifischen Daten enthalten sind, um alle Geschäftsprozesse darauf abzubilden. Nutzung, Betrieb und Wartung eines DV-Verfahrens (Life Cycle )

Abb. 3.2: Was ist der Lebenszyklus (Life Cycle) eines IT-Verfahrens?

Systems Engineering

Anforderungsanalyse

Entwurf

Implementierung

Test

Betrieb und Wartung Änderungswunsch

Applikationssicht (Application View): Das Geschäftsprozess- und das Informationsmodell einer Firma sind verbunden über die Applikationssicht, d. h. über die Oberfläche der Applikationssoftware. Über diese Applikationssicht sollen alle Inhalte des Informationsmodells abgerufen, gelöscht, verändert bzw. ergänzt werden können. Die Oberfläche der Applikationssoftware muss die Arbeitsaktivitäten der Geschäftsprozesse flexibel unterstützen. Technologische Sicht (Technology View): Aus technologischer Sicht ist die Wahl einer entsprechenden technologischen Arbeitsplattform notwendig, die alle notwendigen Randparameter und Bedürfnisse der späteren Anwender erfüllt. Dies fängt an bei der Auswahl


■ ■ ■

39

der Rechnersysteme, deren Betriebssystem und Leistungsfähigkeit, der Oberflächensoftware, einer entsprechenden Middleware, Datenbank und Administrationsoberfläche. Auch stellt sich heute die Frage, ob ein Client-Server- oder webgestütztes DV-Verfahren eingesetzt werden soll. Daneben müssen entsprechende Peripherieeinheiten, Arbeitsplatzrechner, Netzwerkkomponenten und Backupmedien vom IT-Architekten ausgewählt werden. Außerdem müssen sich IT-Manager oder Projektleiter vor Einführung bzw. Ausschreibung eines neuen DV-Systems Gedanken machen, wie man möglichst kleine Stillstandszeiten des zukünftig einzusetzenden DV-Systems erhält. Denn spätestens dann, wenn sich diese Systeme im produktiven Einsatz bewähren müssen, fällt die Verantwortung für die Stillstandszeiten und die daraus resultierenden Kosten wieder auf die Entscheidungsverantwortlichen von früher zurück. Verfügbarkeitssteigernde Maßnahmen sind nach Einführung eines neuen DV-Verfahrens schwerer zu implementieren als vorher. Hinzu kommt noch, dass verfügbarkeitssteigernde Maßnahmen während des produktiven Betriebes meist erstmal mit Ausfallzeiten beginnen, um diese zu integrieren. Abb. 3.3: Gewichtung der Ziele eines neuen DVVerfahrens

24 Stunden/Tag Geschäftsfähigkeit Zentrales Backup aller Server

18 Stunden/Tag Geschäftsfähigkeit

Backup auf allen Servern

20.000 Transaktionen/Stunde 10.000 Transaktionen/Stunde

Transaktionskosten von 5 Euro/Transaktion

Transaktionskosten von 10 Euro/Transaktion Entwicklungskosten unter 5 Millionen

Eingeschränkte Sicherheit Große Sicherheit Erreichbarkeit in 5 Landessprachen

Entwicklungskosten unter 3 Millionen

Verfügbarkeit 99,9 Erreichbarkeit in 8 Landessprachen Verfügbarkeit 99,99

Möchte man ein produktives DV-Verfahren ändern, so ist ein ausreichend dimensioniertes Testsystem mit allen wesentlichen Funktionalitäten notwendig, es sei denn, der Nutzer verzichtet im Vorfeld definitiv auf Änderungswünsche, was er wohl nicht kann. Wenn am Ende alle sagen: ja, das könnte es sein, dann beginnt die eigentliche Projektdurchführung. Alle, die im Projektgeschäft tätig sind, wissen, dass dies ein hartes Geschäft ist. Jeden Tag gibt es neue Überraschungen und alle haben sich das fertige Produkt nachher anders vorgestellt.

40

■ ■ ■


Auch wird jeder Projektleiter feststellen, dass das Geld sowieso nicht reicht. Denn wenn der Kunde die tatsächlichen Kosten für eine ausgereifte Einzelanfertigung übernehmen müsste, hätte man den Auftrag nicht bekommen. Nach meiner Erfahrung ist es deswegen notwendig, innerhalb der Definitionsphase einen Prototyp aufzusetzen, der viele Probleme am Anfang eines Projektes sichtbar macht und die Planung in einer realistischen Art und Weise beeinflusst. Weiterhin zwingt es die Anwender, dazu Stellung zu nehmen, und gibt die Möglichkeit, schon zu Beginn eines Projektes durch einen „Walk Through“ dem Anwender seine Veränderungswünsche vorzubringen, bevor es zu spät ist. Der Kunde soll seine Anforderungen mit einer Priorität versehen, mit der diese Funktionalitäten realisiert werden. Ist ein Prototyp vorhanden, wird man sehr schnell merken, dass die Ressourcen endlich sind, und sich auf das Wesentliche beschränken. Wichtig ist es auch, sich bei Projekten, die Einzelanfertigungen sind, auf Kernfunktionalitäten zu beschränken und diese als erstes umzusetzen. In den meisten Fällen reicht das Geld gerade dafür aus. Um die Projektdurchführung so zu beeinflussen, dass sie ein glückliches Ende nimmt, gibt es verschiedene Standards für Softwareentwicklung und Projektmanagement, wie z. B. V-Modell und PRINCE, welche wir uns im nachfolgenden Kapitel ansehen wollen. Sieht man sich den Lebenszyklus (Life Cycle) eines neuen DVVerfahrens in Abb. 3.2 an, so erkennt man, dass am Ende die beiden Punkte Betrieb und Wartung sowie Änderungswünsche existenzielle Bestandteile eines neuen DV-Verfahrens nach Einführung darstellen. ITIL bietet hier einen guten Ansatz, um die Bedürfnisse der Anwender nach Einführung des neuen DV-Verfahrens zu befriedigen, da es aus Sicht des IT-Services versucht, alle wesentlichen Punkte abzudecken.


■ ■ ■

41

4 Qualitätssichernde Prozesse

Der Begriff Qualität ist in aller Munde; er erstreckt sich auf alle Bereiche des menschlichen Wirkens, jedoch versteht jeder Mensch etwas anderes darunter. Dies führt uns dann zu der Frage: Was ist Qualität? Fragt man einmal verschiedene Menschen danach, so sind die folgenden Attribute des Öfteren zu vernehmen: x Zufriedenheit (Kunden, eigene) x Zuverlässigkeit x Fähigkeit x Eignung x Lebensdauer x Verarbeitung x Ausstattung x Ästhetik x Verständlichkeit x Einfache Handhabung x Service, Dienstleistung Qualität nach DIN EN ISO 8402 ist: „(…) die Gesamtheit der Merkmale und Merkmalswerte eines Produktes oder einer Dienstleistung bezüglich ihrer Eignung, festgelegte und vorausgesetzte Erwartungen zu erfüllen.“ Die ersten, die qualitätssichernde Prozesse in die Unternehmen einbrachten, waren Anfang der 60er Jahre die japanischen Unternehmen. Im Japanischen gibt es den Begriff „Kaizen“ (Kai = Veränderung, Wandel; Zen = zum Besseren, im positiven Sinn), der übersetzt kontinuierliche Verbesserung bedeutet. Kaizen bedeutet in einem japanischen Unternehmen eine stetige, nicht endende Folge von kleinen Verbesserungen aller betrieblichen Elemente und der


■ ■ ■

43

damit im Zusammenhang stehenden Prozesse, wie z. B. Produktionsprozesse und die zugeordneten Mitarbeiter, die diese Produktionsprozesse am Leben erhalten. Die mathematischen und betriebswirtschaftlichen Grundlagen, auf die sich die qualitätssichernden Prozesse beziehen, wurden durch die Amerikaner Juran, Feigenbaum, Crosby und Deming sowie die Japaner Ishikawa und Tagushi geschaffen, die sich konsequent mit der Theorie und praktischen Anwendung von qualitätssteigernden Verfahren beschäftigten. Das bekannteste Produkt ist der Qualitätskreis von Professor Deming, der eine kontinuierliche Qualitätsverbesserung durch einen Zyklus beschreibt, den er mit „Plan-Do-Check-Act“ bezeichnet hat. Abb. 4.1: Andauernde Verbesserung durch das Qualitätsrad von Prof. Deming

Qualitätskreis von Professor Deming (Plan, Do, Check, Act)

A P C D

Qualität Dabei beginnt Deming mit einem Planzyklus „plan“, der den gegenwärtigen Sachstand auf Verbesserungspotentiale überprüft und einen Plan zur Qualitätsverbesserung entwickelt. Bei der Analyse von Schwachstellen und Verbesserungspotentialen ergeben sich meist konkrete Änderungsmaßnahmen zur Verbesserung der betrachteten Prozesse. Diese Änderungsmaßnahmen werden dann im Umsetzungszyklus „do“ durchführt. Nachdem eine Veränderung eingetreten ist, muss nun überprüft werden, ob die Veränderungen positiv verlaufen sind in Bezug auf die vorher definierten Ziele und ob Seiteneffekte aufgetreten und wie diese zu bewerten sind. Im letzten Teil werden Maßnahmen zur Korrektur der festgestellten Abweichungen, Planänderungen oder Verbesserung im Qualitätsmanagementsystem durchgeführt, um das vorher definierte Ziel zu erreichen. Wird das „Qualitätsrad“ stetig weitergedreht, so ergibt

44

■ ■ ■


sich mit der Zeit automatisch eine Verbesserung der vorgefundenen Produktions- oder Geschäftsprozesse. Dabei sollte man die Ergebnisse stets kritisch und offen betrachten und auch nicht zögern, durchgeführte Änderungen schnell wieder zurückzunehmen, falls diese nicht die erwünschten Ergebnisse zeigen.

4.1 Qualitätssichernde Prozesse in Softwareentwicklung, Projektmanagement und IT-Servicemanagement sowie die Standards zu ihrer Überprüfung Heute gibt es eine große Anzahl von Vorgehensmodellen für fast alle Bereiche der Entwicklung und des Betriebes von DV-Systemen, die eine Reihe von qualitätssichernden Prozessen enthalten. Angefangen bei reinen Vorgehensmodellen für die Softwareentwicklung wie RUP (Rational Unified Process) bis zu standardisierten Projektmanagementframeworks wie HERMES, VMODELL-XT oder PRINCE 2. Die einzelnen Vorgehensmodelle bestehen aus einer Reihe von notwendigen qualitätssichernden Prozessen, um die bestehenden Aufgaben, für die sie entwickelt wurden, optimal lösen zu können. Der Vorteil von HERMES-, VMODELL-XT- oder PRINCE 2Projektmanagementframeworks ist, dass diese nicht nur auf die Softwareentwicklung bezogen sind, sondern für die verschiedensten Ausprägungen eines Projektes einsetzbar sind. So gibt es neben reinen Softwareentwicklungsprojekten auch Projekte, die nur Hardware entwickeln. Abb. 4.2: Weiterentwicklung der ProzessReifegrad (Maturity)-Modelle

4.1 Qualitätssichernde Prozesse in Softwareentwicklung, Projektmanagement und IT-Servicemanagement sowie die Standards zu ihrer Überprüfung

■ ■ ■

45

Oft zeigt sich die Güte eines Projektmanagementframeworks gerade bei Projekten, bei denen die komplexesten Systeme entwickelt werden müssen, die sowohl Hard- als auch Softwareanteile enthalten und die die komplexesten Schnittstellen von Fremdprodukten mit einbinden. Neben reinen Entwicklungsprojekten gibt es aber auch Projekte, die „einfach“ nur die Aufgabe haben, eine Migration von Altsystemen oder die Einführung und Pflege eines neuen DV-Systems vorzunehmen. Man sieht, die Bandbreite ist groß und ein Projektmanagementframework muss universell einsetzbar sein. Neben den reinen Projektmanagementframeworks haben sich Vorgehensmodelle für den Betrieb von DV-Systemen entwickelt. Das bekannteste ist wohl das IT-Servicemanagementframework ITIL. Abb. 4.3: Was die BS 15000 für die Überprüfung des Reifegrades eines IT-Servicemanagements ist, ist SPICE für die Überprüfung von Softwareentwicklungsprozessen.

BS 15000

PD 0005

ITIL

Hier stellt sich auch die Frage, wie sich die Güte oder Reife (maturity) bestehender Vorgehensmodelle, z. B. bei der Softwareerstellung, messen und überprüfen lässt. Die Antwort auf diese Frage heißt CMM, PMM bzw. SPICE. Nachfolgend wollen wir uns CMM und SPICE kurz ansehen.

4.2 Was sind AQAP13, AQAP 110 und AQAP 150? Der Ursprung der Normenreihe ISO 9000 liegt, wie so viele Dinge, im militärischen Bereich. Die NATO publizierte 1969 die AQAPs (Allied Quality Assurance Procedures), um einen Qualitätsstandard zu setzen, den die Zulieferfirmen für ihre Produkte, die sie für den militärischen Bereich produzierten oder entwickelten, einsetzen mussten. Bekannte Standards, auf die heute noch teilweise verwiesen wird, sind die AQAP 110 (NATO Quality Assurance Requirements

46

■ ■ ■


for Design, Development and Production), die AQAP 150 (NATO Quality Assurance Requirements for Software Development) sowie die AQAP 13 (Qualitätssicherung von Software). Mit der Anwendung des V-Modells-XT sind die entsprechenden Anforderungen der AQAP 13 und AQAP 150 erfüllt.

4.3 Capability-Maturity-Modell (CMM) Das Capability-Maturity-Modell (CMM) wurde von Watts Humphrey und seinen Kollegen bei der Firma IBM um 1980 herum entwickelt. Humphrey bestimmte, dass die Qualität einer Softwareapplikation im direkten Verhältnis zu der Qualität des ApplikationsEntwicklungs-Prozesses stand. Er entwickelte ein Prozess-ReifeFramework. Diese theoretischen Grundlagen wurden von der Carnegie-Mellon-Universität im Jahre 1987 genutzt, um einen Auftrag des Verteidigungsministeriums zu realisieren. Dabei sollte ein Fragebogen entwickelt werden, der es dem Ministerium erlaubte, Softwarelieferanten zu bewerten. Durch die Definition des evolutionären Softwareentwicklungsprozesses durch fünf Reifestadien entsteht eine Möglichkeit, Softwareentwicklungsfirmen in Reifestufen zu gliedern. Ein CMM-Fragebogen besteht aus 18 Hauptkriterien (Key Process Areas), denen Aspekte zugeordnet sind, die beschreiben, was getan werden muss, um eine entsprechende CMM-Stufe zu erreichen, aber nicht, wie die Firma diese umsetzen muss. Dies ist abhängig von dem organisatorisch-technischen Umfeld einer Firma und wird immer anders gestaltet werden müssen. Die einzelnen CMM-Stufen bauen aufeinander auf, so dass die Anforderungen an die Entwicklungsprozesse der höheren Stufen erfüllt sind. Um die CMM-Stufe 1 (Initialer Prozess; initial) zu erreichen, sind keine Voraussetzungen notwendig. Jede Firma, die Software entwickelt, hat somit wenigstens die Stufe 1. Der Reifegrad der Software, die von dieser Firma hergestellt wird, unterstellt, dass diese fehlerbehaftet und die Entwicklung der Software chaotisch ist, d. h. Zeit- und Kostenrahmen werden regelmäßig überschritten. Frühere Erkenntnisse anderer Entwicklungsprojekte werden nicht verwendet. Möchte man die Voraussetzungen für die Stufe 2 (Wiederholbarer Prozess; repeatable) erfüllen, so muss die Firma ihre Softwareentwicklung in unterschiedliche Teilschritte unterteilen. Dieses Zerlegen in Projektteilschritte ist ein wiederholbarer Prozess, der sich auf jeden Softwareentwicklungsprozess übertragen

4.3 Capability-Maturity-Modell (CMM)

■ ■ ■

47

Abb. 4.4: Die fünf Stufen des CMM (Capability-MaturityModell)

lässt. Dies ermöglicht es, notwendige Ressourcen frühzeitig zur Verfügung zu stellen und eine Fortschrittsüberprüfung mittels Projektmeilensteinen vorzunehmen. Ein weiteres Merkmal der CMM-Stufe 2 ist, dass man ein firmeninternes Verfahren hat, das Erfahrungen aus früheren Entwicklungsprojekten in den aktuellen Entwicklungsprozess mit einbezieht. Tabelle 4.1: CMM-Stufen im Überblick

CMM Beschreibung -Stufe

Implementierte Verbesserungen, um zur nächsten CMM-Stufe zu gelangen

1

Initialer Prozess / Initial (keine Vorausetzungen notwendig, um diese Stufe zu erreichen)

2

Wiederholbarer Prozess / Repeatable Der definierte Prozess / Defined

Kosten- und Zeitabschätzung sowie Terminplanung durchführen Fortschrittsüberwachung beim Entwicklungsprozess Änderungs- und Qualitätsmanagement durchführen Entwicklungsvorgänge wiederholbar gestalten Prozessstandards und Methoden entwickeln und einführen Prozesse messen und analysieren sowie Qualitätsverbesserungsinfrastruktur einsetzen Dies ermöglicht eine quantitative Qualitätssicherung Prozessüberwachung Instrumentierte Prozessumgebung erlaubt eine gesteuerte dynamische Softwareentwicklung Kontinuierliche dynamische Anpassung der Softwareentwicklung

3

48

■ ■ ■

4

Gesteuerter Prozess / Managed

5

Optimierender Prozess / Optimizing


Abb. 4.5: CMM-, CMMI-, SPICE-Reifegradstufen

Hat eine Firma die CMM-Stufe 3 (Definierter Prozess; defined), so sind die intern durchzuführenden Projektteilschritte eines Softwareentwicklungsprojektes durch Prozesse oder Prozessaktivitäten definiert, die auch die notwendigen Werkzeuge und das dafür notwendige Personal im Voraus beschreibbar macht. Dies ermöglicht es, eine höhere Qualität der einzelnen Projektteilschritte und deren Erzeugnisse zu erreichen, die ein Nachbessern weniger erforderlich machen. Möchte eine Firma die CMM Stufe 4 (Gesteuerter Prozess; managed) erreichen, so sind die einzelnen Prozesse, die der Softwareentwicklung dienen, steuerbar und werden anhand entsprechender Prozessmetriken bewertbar. Aus diesen Prozessmetriken lässt sich dann ableiten, ob ein Teilprojektschritt weitergeführt werden soll und ob das Projekt als Ganzes überhaupt noch realisierbar ist. Durch diese Prozessmetriken und die damit verbundene Einwirkungsmöglichkeit auf den Entwicklungsprozess ist eine wesentliche Qualitätssteigerung zu erwarten. Wesentlicher Vorteil ist es auch, dass Projekte seltener den Zeit- bzw. Kostenrahmen überschreiten, da diese viel genauer planbar und steuerbar geworden sind. Eine Firma, die die CMM-Stufe 5 (Optimierender Prozess; optimizing) erreicht hat, wird ihre Softwareentwicklung prozessmäßig so ausgerichtet haben, dass der gesamte Softwareentwicklungsprozess optimiert und dynamisch veränderbar gestaltet werden kann. Abhängig von spezifischen Prozesskennwerten wird dynamisch eine Änderung vorgenommen, ohne dass sich dadurch ernsthafte

4.3 Capability-Maturity-Modell (CMM)

■ ■ ■

49

Auswirkungen auf den Zeit- bzw. Kostenrahmen ergeben. Fazit ist, dass man mittels des CMM-Modells in der Lage ist, ein Unternehmen, das Software entwickelt, zu beurteilen. Die meisten Softwareentwicklungsfirmen liegen zwischen CMM Stufe 2 bis 3.

4.4 Software Process Improvement and Capability dEterminaton (SPICE) Um 1980 herum beauftragte das DoD (Department of Defense) das Software Engineering Institute (SEI) der Carnegie Mellon University in Pennsylvania damit, ein Prozess-Assessment-Modell für die Softwareentwicklung zu erstellen. Hintergrund war, dass IT- und DV-Systeme mehr und mehr Einzug nahmen in den militärischen und zivilen Alltag. Die mangelnde Qualität der diesen IT- und DVSystemen zugrunde liegenden Software führte zu Beschwerden und Frustration bei dem mit der Nutzung betrauten Personal. Das Software Engineering Institute (SEI) entwickelte deswegen das Reifegradmodell Capability-Maturity-Modell (Integrated), auch CMM(I) genannt. Im Jahre 1992 wurde ein Programm gestartet mit dem Ziel, eine internationale Norm zur Prozessbeurteilung und -verbesserung zu entwickeln. Diese Norm bekam den Namen SPICE. Im Jahre 1995 gab es die erste Version von SPICE. Im Jahre 1998 wurde SPICE als ISO/IEC TR 15504-Norm veröffentlicht. Der wesentliche Unterschied zwischen SPICE und CMM ist, dass die Reifegrade von einzelnen Prozessen ermittelt werden und nicht, wie bei CMM, der Reifegrad eines ganzen Unternehmens. SPICE (Software Process Improvement and Capability dEterminaton), auch unter ISO/IEC 15504 bekannt, ist ein Standard-Framework zur Bewertung der Qualität von Software-Entwicklungsprozessen. Der Standard soll es ermöglichen, Stärken und Schwächen bestehender Entwicklungsprozesse einer Firma durch Vergleich im Rahmen eines Assessments aufzudecken. Es stellte sich heraus, dass Abb. 4.6: SPICE ist ein CMM für SoftwareEntwicklungsprozesse

50

■ ■ ■

ISO 12207

SW-CMM

ISO 15504 (SPICE) 4 Qualitätssichernde Prozesse

gerade Assessments in diesem Bereich dazu beitrugen, Prozessverbesserungen zu bewirken. SPICE ist ein spezialisiertes CMM für den Bereich der Softwareentwicklung, in der alle (Geschäfts-)Prozesse einer Firma, die Software entwickelt, bewertet werden. Es wird nicht, wie unter CMM, generelle Fähigkeit einer Firma geprüft, Software zu entwickeln. Die Entwicklung von SPICE hatte von Anfang an folgende Ziele: x Durchführen von Assessments über Softwareentwicklungsprozesse x Verbesserung von Softwareentwicklungsprozessen x Bestimmung des Reifegrads von bestehenden Softwareentwicklungsprozessen x Ausbildung von Fachpersonal zum Durchführen von Assessments über Softwareentwicklungsprozesse x Entwickeln von Standards, um Assessments über bestehende Softwareentwicklungsprozesse durchführen zu können x Fördern eines Technologietransfers bezüglich Assessments über bestehende Softwareentwicklungsprozesse von Firmen weltweit. SPICE enthält eine Prozessdimension (process dimension) sowie eine Fähigkeitsdimension (capability dimension). Der Standard bietet eine Skala zur Bewertung der Leistung aller Prozesse der Software-Entwicklung. Durch Vergleich lässt sich der Reifegrad der Firmen-Prozesse zur Softwareentwicklung bestimmen und somit auch das mögliche

SPICE Qualität von SoftwareSoftware-Entwicklungsprozessen

KundeLieferantBeziehung

Engineering

Projekt

Organisation

Abb. 4.7: Die zu überprüfenden Bereiche der Software-Entwicklungsprozesse nach SPICE

Unterstützung

4.4 Software Process Improvement and Capability dEterminaton (SPICE)

■ ■ ■

51

Potential zur Verbesserung der Reife; weiterhin kann bestimmt werden, durch welche grundsätzlichen Verfahren die Reife der einzelnen Entwicklungsprozesse verbessert werden kann. SPICE untergliedert die Softwareentwicklungsprozesse in fünf Prozessgruppen: Tabelle 4.2: Prozessgruppen unter SPICE

SPICE-Prozess-Gruppe

Abkürzung

Kunde-Lieferant-Beziehung CUS (Customer-Supplier ) Engineering ENG

Hauptprozesse Ungefähre Anzahl von Subprozessen CUS1CUS4

46

ENG1ENG2

51

Organisation

ORG

ORG1ORG6

65

Unterstützung (Support)

SUP

SUP1SUP8

53

Management

MAN

MAN1MAN4 35

Der Prozessbereich Kunde-Lieferant-Beziehung (Customer-Supplier, CUS) besteht aus allen Prozessen, die eine Auswirkung auf den Kunden haben. Hierunter fallen Prozesse, die die Vertragsgestaltung, den Kauf von Softwareprodukten, Anforderungen, Abnahme und Monitoring günstig beeinflussen, sowie Prozesse, die den Gebrauch und den Betrieb des ausgelieferten Systems unterstützen. Die Prozessgruppe Engineering (ENG) umfasst all die Prozesse, die die Systemanforderungen und das Softwaredesign unterstützen sowie die Integration und Tests der Software und des Gesamtsystems betreffen. Abb. 4.8: Nach dem Überprüfen der vorgefundenen Softwareentwicklungsprozesse einer Firma ergibt sich der folgende Reifegrad pro Prozess

52

■ ■ ■


Innerhalb der Prozessgruppe Organisation (ORG) findet man alle Subprozesse, die sich mit der Bereitstellung der Entwicklungsumgebung, der Prozessverbesserung sowie mit der Durchführung von Nutzerschulungen befassen.

Die Rolle des Managements ist es, den Prozess zu verändern nicht die Mitarbeiter.

Abb. 4.9: Aussage mit Tiefgang von Prof. Deming

W. Edward Deming

Der Prozessbereich Unterstützung (Support, SUP) besteht aus Einzelprozessen, die sich um die Dokumentation, das Konfigurationsmanagement sowie das Finden von Lösungen für Projektprobleme kümmern.

Input

Prozess: ENG 1.1

Ergebnisse (outcomes)

Zweck (purpose): Spezifizierung der Systemanforderungen

Output

Abb. 4.10: Assessment eines Softwareentwicklungsprozesses mittels SPICE

Steuerungsgrößen

Gute Mitarbeit des Kunden

Innerhalb der Prozessgruppe Management (PRO oder MAN) werden all die Prozesse geführt, die sich mit dem Projektmanagement befassen, wie z. B. Anforderungs-, Risiko- und Qualitätsmanagement, sowie mit der Gestaltung des Projektplans und des Projektteams.


■ ■ ■

53

Bei einem Assessment werden als erstes die einzelnen SPICEReferenzprozesse mit den vorliegenden Firmenprozessen (was wird getan?) verglichen (process mapping). Danach erfolgt die Einordnung der Firmenprozesse mittels Vergleich nach den folgenden Reifegradstufen: Tabelle 4.3: Reifegrad-Stufen und deren Bedeutung

Reifegradstufe

Bezeichnung

Prozessattribute, Bedeutung die überprüft werden

0

Incomplete

1

Performed

Durchführung der Der implementierte Prozess Prozesse erfüllt seinen vorgesehenen Zweck

2

Managed

Management der Prozesse und Management der Produkte

3

Established

Definition der Prozesse und Verteilung der Prozesse

4

Predictable

Messung der Prozesse und Kontrolle der Prozesse

5

Optimizing

Prozess-Innovation und Optimierung der Prozesse

Der durchgeführte Prozess liefert Arbeitsresultate einer definierten Qualität innerhalb eines definierten Zeitbereiches mit den dafür vorgesehenen Ressourcen. Der Prozess ist wiederholbar, aber nicht überprüfbar. Der geführte Prozess arbeitet mittels eines definierten Prozesses, der auf guten Softwareengineering-Prinzipien beruht. Der Prozess ist wiederholbar und überprüfbar. Der etablierte Prozess arbeitet konstant innerhalb definierter kontrollierter Grenzen, um die definierten Ziele zu erreichen. Der Prozess wird in allen Stufen gesteuert und überprüft. Der berechenbare Prozess optimiert seine Leistung um die gegenwärtigen und zukünftigen geschäftlichen Erfordernisse in wiederholbarer Weise, um seine definierten Geschäftsziele zu erreichen.

Die Fähigkeitsstufe (Capability Level) bezieht sich auf einen einzelnen untersuchten Prozess. Die Bewertung (appraisal) erfolgt nach einer Vier-Punkte-Skala.

54

■ ■ ■


Bewertung

Bedeutung

Punkte in %

N

Nicht (not) erreicht

015

P

Teilweise (partially) erreicht

1650

L

Zum Großteil (largely) erreicht

5185

F

Voll (fully) erreicht

86100

Tabelle 4.4: SPICEBewertungsstufen und deren Bedeutung

Alle durch SPICE vorgegebenen Prozesse werden beurteilt. Daraus folgt der Reifegrad. Der Reifegrad (maturity level) bezieht sich auf die Reife aller Softwareentwicklungsprozesse einer Firma, welche durch ein Assessment festgestellt wurde. Durch ein SPICE-Assessment bekommt man eine Idee, in welchen Prozessen eine Änderung vorgenommen werden sollte. SPICE wird zu einem Prozessverbesserungsprogramm, indem ein schrittweiser Aufstieg auf der SPICE-Reifeskala geplant wird. Abb. 4.11: Wirkungen von SPICE

Prozess

Ist Gegenstand von

Identifiziert Änderungen des

Identifiziert Eignung von

Prozess Beurteilung

Führt zu

Führt zu Bestimmung der Fähigkeiten

Prozess Verbesserung Führt eventuell zu

Durch die Änderung ergeben sich z. B. kleine Entwicklungszeiten oder eine kleinere Anzahl von nicht entdeckten Softwarefehlern. Auch das schnellere Finden von Fehlern verringert die Zeiten, die zum Testen und nachfolgenden Modifizieren von Software benötigt werden. Dies führt automatisch zu einer Zeit- und Kostenreduktion bei der Entwicklung. Sieht man sich die Studie der Carnegie Mellon University (Abb. 4.12) an, so erkennt man die Abhängigkeit der durchschnittlichen Fehleranzahl (pro 1000 Zeilen Softwarecode) vom jeweiligen CMM-Level. Die Studie basiert auf einer Auswertung von verschiedenen Dienstleistern im Softwareentwicklungsbereich und deren durchgeführten Projekten.


■ ■ ■

55

Abb. 4.12: Fehler pro KLOC (thousands of line of code) in Abhängigkeit vom jeweiligen CMM-Level [30]

8

7,5

7

6,24

6 4,73 5 4 3

2,28

2 1,05 1 0 Level 1

Level 2

Level 3

Level 4

Level 5

4.5 Agile Entwicklung (RAD) und DSDM-Framework Viele Firmen bekommen bei einer Ausschreibung erst den Auftrag, wenn sie ein ideales Projekt kalkulieren. Der absehbare Druck wird durch den Projektleiter und die Entwicklergruppe dann absorbiert werden müssen, vielleicht in einer Zeit, in der die betroffenen Personen mit zeitlichen und technischen Problemen kämpfen. Als letzte Maßnahme bleiben dann Überstunden, die so lange anhalten, bis die Fehlerrate der zu entwickelnden Software in die Höhe schießt und sich Probleme im persönlichen Umfeld der Projektmitglieder auftun. Deswegen nun ein kurzer Überblick über agile Softwarenentwicklung sowie über Softwareinspektionen, die helfen sollen, die Projektziele in einer nicht idealen Welt zu erreichen. Zu einer Softwareentwicklung gehören neben dem reinen Schreiben von Software verschiedene andere notwendige Tätigkeiten und Prozesse. Da muss getestet werden, Versionsstände müssen verwaltet sowie der Zugriff auf bestehende Bibliotheken oder Softwarefragmente von anderen Gruppenmitgliedern ermöglicht werden. Daneben braucht man Hilfsmittel, um Arbeitsabläufe und Datenstrukturen zu definieren. Unter RAD (Rapid Application Development) versteht man nun Werkzeuge, die die einzelnen Arbeitsschritte, Prozesse und Tools zur Entwicklung von Software zusammenfassen, um damit die eigentliche Entwicklungsarbeit zu beschleunigen.

56

■ ■ ■


Höchstes Ziel des Projektes

Höchste Priorität Funktionalitäten des Endprodukts

Zeit (Zeitplan)

Kosten (Kostenrahmen) KundenAnforderungen

KundenAnforderungen Zeit (Zeitplan)

Kosten (Kostenrahmen)

Funktionalitäten des Endprodukts

Abb. 4.13: Unterschied zwischen traditionellen Projekten der Softwareentwicklung und agiler SoftwareentwicklungsProjekte

Je nach Philosophie oder Vorgehensweise bei der Softwareentwicklung werden unterschiedliche RAD-Werkzeuge zu unterscheiden sein. Mittels RAD können Prototypen in kurzer Zeit entwickelt werden. Das Ziel ist dabei, die gewünschten Funktionalitäten zu erfassen und diese so schnell wie möglich innerhalb der Software umzusetzen. Abb. 4.14: FMI und DBI im Wechsel

Wie man in Kapitel 1.3 anhand entsprechender Statistiken sehen kann, werden die meisten Funktionalitäten im Betrieb eines entwickelten DV-Systems kaum genutzt. Dies führte zu der Überlegung, ob es nicht klüger wäre, Zeit und Kosten als feste, nicht veränderbare Ziele anzusehen und dabei zu versuchen, möglichst die in diesem Rahmen maximal möglichen Funktionalitäten zu realisieren. Weiterhin wurde bei Analysen zum Scheitern von Projekten, herausgefunden, dass die unterschätzte Komplexität von Projekten einer der Hauptgründe für ihr Scheitern ist. Ein menschliches steuerndes Regulativ für komplexe Systeme sind empirische iterative Prozesse. Das heißt, man entwickelt die erste Stufe eines Systems, man kontrolliert und prüft dieses System und entwickelt dann die nächste Stufe, die die Ergebnisse der Kontrolle der ersten Stufe beinhaltet und so weiter. Der Änderungswunsch ist hierbei der Weg zum gewollten Ergebnis. Innerhalb der Softwareentwicklung nennt man dies agile Softwareentwicklung. Vertreter dieser agilen Softwareentwicklung sind folgende Methoden:

4.5 Agile Entwicklung (RAD) und DSDM-Framework

■ ■ ■

57

x Extreme Programming (XP) x Crystal x Scrum x DSDM x RUP Im Weiteren wollen wir uns exemplarisch einem Vertreter der agilen Softwareentwicklung mit dem Namen DSDM (Dynamic Systems Development Method) widmen. DSDM wurde ursprünglich 1994 als eine herstellerneutrale Methode spezifiziert und 1995 in der Version 1.0 publiziert. Im Jahre 2003 wurde die Version 4.2 freigegeben. DSDM ist ein Framework, welches auf Best Practice-Prozessen zur Anforderungsanalyse, Softwareentwicklung und dem notwendigen Management besteht, um agile Softwareentwicklung durchführen zu können. Es ist als Framework gedacht, das den Erfordernissen innerhalb einer Firma angepasst werden kann. Abb. 4.15: Der lange Weg von DSDM

2003 DSDM Version 4.2

2001 DSDM Version 4.0

1997 1996

DSDM Version 3.0

1995 DSDM Version 2.0 DSDM Version 1.0

Eine weitere Maxime von DSDM ist, dass am Anfang nichts perfekt ist, dass aber 80% des angedachten Funktionsumfangs eines neuen DV-Systems sich in 20% der Zeit erreichen lässt, die es dauern würde, den Funktionsumfang von 100% zu realisieren. Das Prinzip lautet: „Liefere, was du liefern kannst, aber es muss funktionieren!“ Das DSDM-Framework beinhaltet innerhalb seiner enthaltenen Prozesse somit die Maxime, den Funktionsumfang eines neuen DV-Systems, den eine Firma braucht, dann zu liefern, wenn sie es braucht.

58

■ ■ ■


Bei diesem Ansatz ist nicht vorgesehen, direkt alle vorstellbaren Funktionalitäten zu definieren und dann zu entwickeln, sondern in Zusammenarbeit mit den inoder externen Kunden im Einzelnen Iterationsschritte zu entwickeln. Somit können wir die drei wichtigsten Kernpunkte von DSDM wie folgt definieren:

Abb. 4.16: Iterativer Ansatz von DSDM

x Prototyping x Iterative Entwicklung x Time boxing Der Begriff des Time boxing unter DSDM beschreibt dabei das Prinzip eines festen Zeitrahmens (2 bis 6 Wochen) zur Lieferung einer neuen unfertigen stabilen Softwareversion, die dem Nutzer übergeben wird. Abb. 4.17: Die Phasen von DSDM

DSDM umfasst den MoSCoW-Ansatz, der die Gewichtung von gewünschten Funktionalitäten eines neuen DV-Systems auf folgende Art und Weise festlegt: x x x x

Muss enthalten sein (Must have) Sollte enthalten sein (Should have) Könnte enthalten sein (Could have) Gewünscht (Would like to have)

4.5 Agile Entwicklung (RAD) und DSDM-Framework

■ ■ ■

59

Die iterative Entwicklung unter DSDM erfolgt immer in sieben Phasen. x Pre-Project x Feasibility Study x Business Study x Functional Model Iteration (FMI) x Design & Build Iteration (DBI) x Implementation x Post-Project Abb. 4.18: Alle Phasen von DSDM von Anfang bis Ende des Projektes

Am Anfang steht die Pre-Project-Phase, in der verschiedene Projektziel-Vorschläge verglichen werden, um einen auszuwählen, mit dem das angestrebte Projektziel erreicht werden soll. In der PreProject-Phase wird entschieden, ob überhaupt ein Projekt durchgeführt werden soll.

In der Phase der Durchführbarkeits-Studie (feasibility study) wird überlegt, wie die aus der Umsetzung des Projektes erwachsenen Probleme gelöst werden sollen und welche Kosten daraus erwachsen. Es wird ermittelt, ob es technisch durchführbar ist, ob das zu realisierende DV-System die erforderlichen Geschäftsprozesse abbilden kann und ob das DSDM ein geeignetes Framework ist, um das zu realisierende Projekt umzusetzen. Anschließend erfolgt die Business-Study-Phase. Hier werden die notwendigen Funktionen festgelegt, die aus den geschäftsprozessspezifischen Eigenarten resultieren. Die Hauptaufgabe der Functional Model Iterations (FMI)-Phase liegt in der verfeinerten IT-spezifischen Anforderungsanalyse, die sich aus der Umsetzung der innerhalb des Projektes umsetzbaren Geschäftsprozesse ergibt. Das FMI nimmt direkten Bezug auf die in der „business study“ niedergeschriebenen Grundanforderungen. Innerhalb der Design & Build Iteration (DBI)-Phase wird das DV-System entwickelt und den Nutzern zum Testen überlassen.

60

■ ■ ■


Nachfolgend kommt die Implementierungsphase, bei der das inzwischen durch hintereinander folgende FMI- und DBI-Iterationen entwickelte Projektendprodukt von der Entwicklungsumgebung in die Produktivumgebung überführt wird. Innerhalb der Post-ProjektPhase wird bestimmt, wie gut sich das implementierte Projektendprodukt in der Produktivumgebung bewährt und ob Veränderungen oder Erweiterungen notwendig sind. Die Prinzipien, auf denen DSDM basiert, sind wie folgt: x Aktives Einbeziehen der Nutzer/Anforderer und des Managements innerhalb des iterativen Entwicklungsprozesses. x Damit schnelle Ergebnisse erarbeitet werden können, ist es notwendig, dass die Entwickler und Nutzer die notwendige Entscheidungsfreiheit haben, notwendige Entscheidungen über Technik, Funktionalitäten und abgebildete Workflows zu treffen. x Produktzentriert liegt der Fokus auf häufigerem Ausliefern von entwickelten funktionsfähigen Produktprototypen innerhalb festgelegter Zeitfenster (time boxing). x Die entwickelten Funktionalitäten sollen streng auf die geschäftlichen Anforderungen der entsprechenden Firma fokussiert werden. x Iteratives und inkrementelles Entwickeln ist notwendig, um die Geschäftsprozesse nach und nach genau abzubilden. x Es soll jederzeit möglich sein, alle Veränderungen an einem Prototypen rückgängig zu machen. x Es werden inkrementelle Tests auf die entwickelten Einzelkomponenten sowie Abnahmetests des Prototypen durchgeführt, damit technische und geschäftsprozess-spezifische Anforderungen genau getroffen werden.

4.6 RUP Das RUP (Rational Unified Process) ist ein standardisiertes Entwicklungsvorgehensmodell in der Softwareerstellung. RUP beinhaltet einen starken UML (Unified Modelling Language)-Bezug. Entstanden ist RUP aus Entwicklungen der Firma Rational (iterative Softwareprozesse) sowie dem von Ivar Jacobsen entwickelten Objectory Process. In den Jahren 19951998 wurde RUP erstmalig unter diesem Namen veröffentlicht. Im Jahre 2003 übernahm die

4.6 RUP

■ ■ ■

61

Firma IBM die Firma Rational und entwickelte RUP als Produkt weiter. Als Grundlage einer qualitativ guten Softwareentwicklung (Best Practices) werden allgemein die folgenden Ansätze angesehen: x Iterative Softwareentwicklung x Anforderungsmanagement x Verwendung komponentenbasierter Architekturen x Visuelle Softwaremodelling x Prüfung der Softwarequalität x Kontrolliertes Änderungsmanagement Alle diese Punkte sind innerhalb des Rational Unified Process (RUP) enthalten. RUP ist leider auf objektorientierte Software fixiert. Abb. 4.19: Softwareentwickler der ersten und fünften Generation

Das Rational Unified Process (RUP)-Vorgehensmodell besteht aus 9 Prozess-Workflows, die iterativ innerhalb von 4 Phasen ablaufen.

4.6.1 Die Arbeitsweise von RUP Die Arbeitsweise von RUP basiert auf einer iterativen und inkrementellen Entwicklung. Eine inkrementelle Entwicklung kann man sich wie in Abb. 4.20 gezeigt vorstellen. Ein iterativer Entwicklungszyklus bedeutet die Entwicklung des Gesamtsystems als Folge ausführbarer Teilsysteme. Man will damit das Problem der immer größer und komplexer werdenden Softwareprojekte lösen, da meist der Umfang der zu entwickelnden Funktionalitäten nicht zu überblicken ist. Das Gesamtsystem wird bei der inkrementellen Entwicklung in kleinen und sich wiederholenden Arbeitsschritten oder Entwicklungsprozessen

62

■ ■ ■


entwickelt, wobei sich die Gewichtung der Arbeitschritte immer weiter vom Design und der Anforderungsanalyse zu Test und Inbetriebnahme verschiebt. In jedem iterativen Arbeitsschritt können weitere Wünsche und Anforderungen des Kunden mit Anforderungsanalyse, Analyse & Design, Implementierung und Test mit einfließen, bestehende Risiken identifiziert und entsprechende Gegenmaßnahmen ergriffen werden. Der Vorteil liegt auf der Hand. Jeder, der schon einmal Ausschreibungen mit den gewünschten Funktionalitäten von Firmenfachbereichen verfassen musste, weiß, in welcher Zwickmühle man steckt. Man muss erstens alle nur vorstellbaren Einsatzszenarien im Voraus bedenken und dann, wenn die Ausschreibung fertig ist und an potentielle Dienstleister versendet wurde, kommt der Fachbereich und reicht noch Anforderungen nach bzw. bis zum Zeitpunkt der Projektdurchführung vergeht eine Zeit, in der zusätzliche Funktionalitäten notwendigerweise gebraucht werden.

Vorstellung des Endproduktes

4 3

2

Abb. 4.20: Darstellung für einen inkrementellen oder iterativen Entwicklungsansatz.

1

Iterativer Entwicklungszyklus

RUP definiert vier Phasen (Inception, Elaboration, Construction und Transition) eines Projektes. Innerhalb der Inception (Konzeptualisierungs)-Phase wird das Projekt vorbereitet. Die Projektgrenzen werden abgesteckt. Es erfolgt eine Definition der Projektziele, das Erfassen der funktionalen Anforderungen aus Benutzersicht und das Ermitteln der Projektrisiken, bevor das Projekt als solches etabliert wird. In der Analyse werden UML-Use-Cases (Anwendungsfälle) verwendet, um die wesentlichen Funktionalitäten eines Systems zu identifizieren und zu gruppieren. Die Elaboration (Entwurf)-Phase beinhaltet das Ausarbeiten eines Architekturentwurfs sowie Projektplans. Anstehende Probleme werden analysiert und Gegenmaßnahmen zu bestehenden Projektrisiken eingeleitet. Es werden die funktionalen und die nichtfunktionalen Anforderungen, wie z. B. Verfügbarkeit oder Performance, bestimmt.

4.6 RUP

■ ■ ■

63

Abb. 4.21: Iterative Sofwareentwicklung [34]

Hauptaktionen der Construction (Konstruktion)-Phase ist die Entwicklung eines Projektendproduktes mittels eines iterativen und inkrementellen Entwicklungsprozesses. Weiterhin muss ein rudimentäres Benutzerhandbuch erstellt werden und, wenn eine Softwareapplikation erstellt wird, diese auf unterschiedlichen Systemen lauffähig sein. Innerhalb der Transition(Übergangs)-Phase wird das Projektendprodukt mittels System- und Abnahmetests überprüft und dann in den normalen Betrieb überführt. Entsprechende Nutzerschulungen runden diese Phase ab. Neben den vier Phasen besteht das Rational Unified Process (RUP)-Vorgehensmodell aus 9 Process-Workflows, die iterativ innerhalb der Phasen ablaufen. Abb. 4.22: Prozessstruktur von RUP [36]

Process Workflows

Konzeption Entwurf

Realisierung

Einführung

Business Modeling Requirements Analysis & Design Implementation Test Deployment

Supporting Workflows Configuration Mgmt Management Environment Preliminary Iteration(s)

Iter. #1

Iter. #2

Iter. #n

Iter. Iter. #n+1 #n+2

Iter. #m

Iter. #m+1

Die Engineering-Workflows Business Modelling, Requirements, Analysis & Design, Implementation, Test und Deployment werden im Laufe der iterativen Systementwicklung mehrere Male durchlaufen, bis daraus ein stabiles Projektendprodukt erwächst.

64

■ ■ ■


Die Supporting-Workflows Project Management, Configuration & Change Management und Environment stellen immer wiederkehrende, unterstützende Projektfunktionalitäten zur Verfügung, ohne die eine Systementwicklung nicht auskommt. Aus Abb. 4.22 erkennt man, dass der Aufwand für bestimmte Entwicklungsprozesse (Business Modeling, Requirements, A & D) hoch ist, aber nach und nach, nach jedem Iterations-Schritt abnimmt und die Prozesse Implementation und Test mehr und mehr den gesamten Arbeitsaufwand darstellen. Die Process-Workflows unter RUP sind aufgeteilt in Engineering- und Supporting-Workflows.

4.7 Der Einfluss von Inspektionen, Assessments und „Walk Throughs“ bei Projekten In den letzten Jahren wurde die Vorteilhaftigkeit von zwischenzeitlichen Assessments oder Inspektionen bei Softwareprojekten diskutiert. Abb. 4.23: Einfluss von SoftwareReviews

20 % 18 % 16 % 14 % 12 % 10 % 8% 6% 4% 2% 0%

Ohne Softwareinspektionen Mit Softwareinspektionen

Anforderungsphase

Designphase

Kodierungsphase

Testphase

Grundlage ist, dass bei Fehlern, die erst am Ende der Entwicklungsphase gefunden wurden, ein höherer Aufwand durch Modifizieren der Software mit erneuten Tests entsteht, als wenn ein gewisser Prozentsatz von Fehlern mittels Inspektion innerhalb der Entwicklungsphase gefunden und korrigiert wird. Den positiven Einfluss von Software-Reviews auf die Reduktion von fehlerbehebenden Maßnahmen bei der Firma Boeing kann man in Abb. 4.23 erkennen.

4.7 Der Einfluss von Inspektionen, Assessments und „Walk Throughs“ bei Projekten

■ ■ ■

65

4.7.1 „Walk Through“ Der „Walk Through“ unterscheidet sich von der Inspektion und wird oft bei größeren Projekten angewendet. Beim „Walk Through“ soll überprüft werden, ob sich die Erwartungen des Kunden an das zu erstellende Projektendprodukt verändert haben, oder ob Kunde und Dienstleister unterschiedliche Vorstellungen vom gesamten Projektendprodukt oder in Teilen haben. Änderungen und unterschiedliche Auffassungen innerhalb eines Projektes sollten nach Möglichkeit so früh wie möglich auftauchen, wenn noch die Chance besteht, diese anzugleichen. Dies ist z. B. möglich mit dem Eingliedern von verschiedenen „Walk Through“-Terminen mit dem Kunden innerhalb der Projektlaufzeit und, wenn möglich, nach Beendigung einer definierten Projektphase. Abb. 4.24: Ein „Walk Through“ erlaubt Kunden und Dienstleistern ein grundsätzliches Urteil

Hier werden bei einem speziellen Termin, bei dem Vertreter des Kunden und des Dienstleisters anwesend sind, mit den bisher im Projekt erstellten Produkten Testfälle durchgespielt, die den Kunden die generellen Funktionsweisen des entwickelten Produktes erkennen lassen. Mittels „Walk Through“ ist es dem Kunden möglich,

66

■ ■ ■


frühzeitige Bedenken und Änderungen einfließen zu lassen, bevor es zu spät ist. Auch ergibt es sich, dass theoretische Überlegungen durch die Demonstration an einem Prototyp im Anfangsstadium konkretisiert werden können, so dass die weitere Entwicklung davon positiv beeinflusst wird. Wichtig dabei ist, dass beim frühzeitigen Stand eines Projektes nicht erwartet werden darf, dass das Projektendprodukt fehlerfrei funktionsfähig ist. Meine Erfahrung mit „Walk Throughs“ sind positiv, da unter anderem für den „Walk Through“ wiederholbare Testprogramme und -szenarien entwickelt werden müssen, die es erlauben, interne Entwicklungsfehler und falsche logische Abläufe zu entdecken. Weiterhin wird der Stand eines Projektendproduktes dadurch stabilisiert, dass vorher definierte, aber noch nicht realisierte Funktionsbausteine nun erstellt werden müssen, die sonst auf das Projektende geschoben werden. Auch ist der Abschluss eines Projektabschnitts mittels „Walk Through“ ein guter Zeitpunkt für Zwischenzahlungstermine, weil der Kunde sieht, dass sein Projekt Fortschritte macht.

4.7 Der Einfluss von Inspektionen, Assessments und „Walk Throughs“ bei Projekten

■ ■ ■

67

5 Entwicklung eines neuen DV-Verfahrens mit den Vorgehensmodellen HERMES, V-Modell-XT oder PRINCE 2

Die Durchführung von Projekten ist notwendig, die Möglichkeiten, zu scheitern, unendlich. Dazwischen steht der Mensch als regulierendes Instrument. Jeder, der mit dem Projektgeschäft sein Geld verdient, weiß über die Unberechenbarkeiten desselben. Dies liegt im Allgemeinen daran, dass alle Projektbeteiligten eine andere Betrachtungsweise der anstehenden Probleme und deren Lösungsmöglichkeiten haben. Abb. 5.1: Welches Projektmanagementframework soll man nun wählen?

Projekt

Kommen dazu noch Organisations- oder Kommunikationsprobleme zwischen Auftraggeber (AG) und Auftragnehmer (AN), so hat das nicht selten zur Folge, dass ein Projekt keinen Gewinn abwirft oder – im schlimmsten Fall – daraus ein finanzielles Fiasko entsteht. In den USA hilft man sich dann des Öfteren mit der harten Methode, indem man die Projektgruppe feuert und eine neue Projektgruppe auf das Projekt ansetzt. Ob dies der Produktivität und dem


■ ■ ■

69

Arbeitsklima nützlich ist, wage ich nicht zu beurteilen. Was ist daher einleuchtender, als Standards für das Projektgeschäft zu schaffen, welche für Auftraggeber und Auftragnehmer bindend sind. Grundlage eines guten Projektes ist ein Vorgangs- oder Prozessmodell, wie das deutsche V-Modell, das Schweizer HERMES-Modell und das britische PRINCE 2. Abb. 5.2: Wie ist ein Vorgehensmodell aufgebaut?

Womit ?

Wie ?

Produktmodell

Was ?

Werkzeuge

Aktivitätenmodell

Wann ?

Wer ?

Prozessmodell

Methoden

Rollenmodell

Vorgehensmodelle können in der Praxis helfen, innerhalb eines Projekts eine genaue Systematik, Wortschatz und Vorgangsbeschreibung zwischen Auftraggeber und Auftragnehmer festzulegen. Vorgehensmodelle sind ein Weg, um systematische Fehler bei der Projektabwicklung zu vermeiden, indem sie dem Projekt eine nachvollziehbare Struktur geben. Sie können den Erfolg eines Projektes aber nicht garantieren. Wer meint, mit einem peniblen Vorgangsmodellablauf den Erfolg seines Projektes sicherzustellen, hat den ersten Schritt zu dessen Misserfolg gelegt. Jedes Projekt stellt einen Kraftakt dar, dessen Ausgang zwar beeinflussbar, aber nicht vorhersehbar ist. Die beste Voraussetzung, Abb. 5.3: Wettbewerb der Vorgehensmodelle

Ein Wettbewerb besteht nicht zwischen Menschen, Produkten oder Firmen, sondern zwischen Prozessen. Arthur R. Tenner

70

■ ■ ■


ein Projekt positiv zu beeinflussen, liegt in der bewussten Auswahl der Projektmitglieder und deren Erfahrungen und Wissen. Letztendlich entscheidet der menschliche Faktor über Sieg und Niederlage, und das ist auch gut so. Im Folgenden wollen wir uns einen Überblick verschaffen über die bekanntesten Projektmanagementframeworks oder Projektvorgehensmodelle.

5.1 HERMES HERMES ist ein offener Standard der schweizerischen Bundesverwaltung zum Führen und Abwickeln von Projekten der Informations- und Kommunikationstechnik (IKT). Er wurde in den 70er Jahren von der Bundesverwaltung und der SBB (Schweizerischen Bundesbahn) sowie der PTT (Post, Telefon und Telegraf) entwickelt, um größere Projekte zum Erfolg zu führen. HERMES wurde dann 1975 eingeführt und in den Jahren 1986, 1995 und 2003 (NEO Hermes) den projektspezifischen Erfordernissen angepasst. HERMES enthält zahlreiche Erfahrungen aus vorangegangenen Projekten aus der Praxis für die Praxis („best practice“). Er besteht aus unterschiedlichen Vorgehensmodellen für die unterschiedlichen Arten von Projekttypen. Wohl am bekanntesten ist das Vorgehensmodell HERMES-Systementwicklung, welches speziell auf die Selbstentwicklung eines neuen IT- oder DV-Systems zugeschnitten Einbindung von HERMES innerhalb der Informatikprozesse der schweizerischen Bundesverwaltung P01: Informatik steuern

P04: Informatik führen P05: Lösungen entwickeln

P06: Infrastruktur betreiben

HERMES

P02: Fähigkeiten entwickeln

Abb. 5.4: Einbettung von HERMES innerhalb der schweizerischen Bundesverwaltung [7]

P07: Benutzer unterstützen P03: Güter und Dienstleistungen beschaffen

P09: Finanzielle Führung unterstützen

P08: Prozesse pflegen

5.1 HERMES

■ ■ ■

71

ist. Im Jahre 2005 wurde die HERMES-Vorgehensfamilie durch HERMES MOB sowie HERMES-Systemadaption vervollständigt. Innerhalb von HERMES MOB findet man die EE-IKT (Evaluierung und Einführung einer IKT-Lösung). In der HERMES-Systemadaption befasst man sich mit der Evaluation und Adaption eines Systems, welches nicht selbst entwickelt, sondern eingekauft und angepasst wird. Mittlerweile ist HERMES 2003 in den Sprachen deutsch, französisch sowie italienisch verfügbar. Es wird auch oft als das Schweizer V-Modell bezeichnet. Das Informatikstrategieorgan Bund (ISB) ist Inhaber der Urheberrechte an HERMES, entwickelt ihn weiter und passt ihn dem aktuellen Kenntnisstand über Projektmanagement an. Die Dokumentation des HERMES-Standards ist immer in zwei Teile gegliedert: x Teil I (Grundwissen) behandelt die HERMES-Grundlagen. Er geht darauf ein, welche Aspekte erfolgreiche Projekte auszeichnen und wie HERMES angewendet werden sollte. Er zeigt, was bei der Projektdurchführung notwendig ist und warum. x Teil II (Projektdurchführung) enthält jeweils für einen Projekttyp (Systementwicklung, Systemadaption, MOB, Migration usw.) ein Vorgehensmodell, bezogen auf die relevanten Aktivitäten und Ergebnisse sowie die notwendigen Projektrollen. Durch den auf einzelne Projekttypen zugeschnittenen Arbeitsstrukturplan erleichtert er die praktische Projektdurchführung. Abb. 5.5: Die drei HERMESSichten eines Projektes [7]

72

■ ■ ■


HERMES stellt grundsätzlich für verschiedene Projekttypen, wie z. B. Systementwicklung, Systemadaption, MOB oder Migration, eine vorgefertigte Vorgehensmethodik zur Verfügung. An neuen Projekttypen, wie z. B. Evaluation und Einführung einer IKT-Lösung, wird momentan gearbeitet. Jedem Projekttyp ist ein entsprechend angepasster Arbeitsstrukturplan (ASP) beigefügt, der bei der Durchführung eines Projektes zur Hand geht. Im zweiten Teil des Handbuchs von HERMES findet man verschiedene Submodelle, die die querschnittlichen Projektführungsaufgaben für einen Projekttyp beschreiben. Diese sind wie folgt: x Projektmanagement x Qualitätssicherung x Konfigurationsmanagement x Risikomanagement x Projektmarketing Je nach Projekttyp, wie z. B. Systementwicklung (SE), Systemadaption (SA), MOB oder Migration, sind die einzelnen oben genannten Submodelle anders aufgebaut und nehmen damit Bezug auf die speziellen Projekttypeigenschaften. Zu jedem Submodell sind entsprechende Rollenbeschreibungen und das Vorgehen in bestimmten Projektphasen anders geregelt. Ein spezifischer Arbeitsstrukturplan ist den entsprechenden Projekttypen angepasst. In dem Arbeitsstrukturplan sind zugeordnete Arbeitsergebnisse, Aktivitäten und Arbeitsschritte sowie Verantwortlichkeiten enthalten. Die Aufteilung des HERMES-Handbuches für den projekttypspezifischen zweiten Teil ist in der folgenden Tabelle dargestellt. Kapitel

Inhalt

1 2 3 4 5 6 7 Anhänge Index

Einleitung Übersicht über den Projekttyp (Ergebnisse, Phasen, Rollen) Die einzelnen Phasen des Projekttyps im Detail Die Submodelle des Projekttyps Die Ergebnisse des Projekttyps Die Rollen des Projekttyps Arbeitstechniken Weitere Informationen zu bestimmten Themen und Hinweise Stichwortverzeichnis

5.1 HERMES

Tabelle 5.1: Übersicht über das HERMESHandbuch

■ ■ ■

73

5.1.1 Basiswissen von HERMES Das Projektmanagementframework HERMES gliedert ein Projekt in unterschiedliche Phasen. Die Projektphasen sind mit bestimmten zu erarbeitenden Ergebnissen verbunden. Die Beurteilung der entsprechenden Phasenergebnisse führt dann zu Phasenentscheidungspunkten. Somit ist ein HERMES-Projekt durch Phasenentscheidungspunkte strukturiert. Die Phasen und zugeordneten Phasenergebnisse unter HERMES lauten: Tabelle 5.2: Phasen beim Projektmanagementframework HERMES

Phase

Phasenergebnis

Initialisierung Voranalyse Konzept Realisierung Einführung Abschluss

Definierte Ausgangsbasis Grundsätzliche Lösungsvariante Umfassend beurteiltes Konzept Erstelltes System Installiertes und genutztes System Dokumentierte Projekterfahrungen

HERMES ist ergebnisorientiert, d. h. je nach Projekttyp werden Ergebnisse (Projekthandbuch, QS-Plan, RM-Plan usw.) eines Projektes definiert, die bei einer professionellen Herangehensweise vorhanden sein sollten. Abb. 5.6: Nutzung von HERMES in der Projektphase [7]

Studie

Projekt

Betrieb

HERMES Initialisierung Initialisierung

Voranalyse Voranalyse

Konzept Konzept

Realisierung

Einführung Einführung

Abschluss

HERMES unterscheidet intern zwischen verschiedenen Projektkategorien (A bis C) in absteigender Reihenfolge, welche abhängig sind von den Einflussgrößen Wichtigkeit, Größe und Risiko.

74

■ ■ ■


Kategorie

Wichtigkeit

Größe

Risiko

A B C

hoch mittel niedrig

groß mittel klein

hoch mittel niedrig

Tabelle 5.3: Projektkategorien bei HERMES [8]

Die Größeneinteilung eines Projektes ist entscheidend für die Ergebnisse des angewandten Tailorings. Tailoring ist der Vorgang, der die projekttypspezifischen Arbeitsergebnisse und Aktivitäten eines Projektes anpasst an die Größenverhältnisse des durchzuführenden Projektes. Größe

Aufwand in Personentagen (PT)

Projektteamgröße in Mitarbeitern

Investition in Mio. CHF

groß mittel

> 1000

>5

>2

d 1000

d5

d2

klein

d 100

d2

d 0,2

Tabelle 5.4: Größeneinteilung eines Projektes beim Projektmanagementframework HERMES [8]

Damit soll eine übermäßige Papierflut mit sinnlosen Dokumenten vermieden werden. So ist es einfach ersichtlich, dass man bei einem kleineren Projekt auch ohne QS- und RM-Plan auskommt. Initialisierungsphase

Voranalysephase

Konzeptphase

Realisierungsphase

Einführungsphase

Abschlussphase

Abb. 5.7: Risikoverlauf nach Projektfortschritt nach HERMES [8]

Die einzelnen Submodelle unter HERMES im Überblick. Innerhalb des Submodells „Projektmanagement (PM)“ sind alle Aktivitäten – geordnet nach Projektphasen – zusammengefasst, die den Erfolg eines Projektes positiv beeinflussen sollen. Anhand von Abb. 5.7 kann man erkennen, dass das Risiko, zu scheitern, in den ersten Phasen eines Projektes relativ hoch ist. Hier ist seitens des Projektmanagements ein erhöhter Kontrollbedarf gegeben.

5.1 HERMES

■ ■ ■

75

Das Projektmanagement unter HERMES soll den Spagat schaffen, Lösungsumfang, Qualität, Aufwand/Kosten sowie Termine miteinander in Einklang zu bringen. Das Submodell Qualitätssicherung (QS) soll erreichen, dass das Projektendprodukt die Eigenschaften besitzt, welche vorher zwischen Auftraggeber und Auftragnehmer vereinbart wurden. Der Qualitätssicherung sind nach dem Projektmanagementframework HERMES verschiedene Aktivitäten je Projektphase zugeordnet, wie z. B. QS-Plan, Prüfspezifikationen, Prüfprotokolle, Testplan und Testbericht erstellen. Bei HERMES wird unterschieden zwischen Prüfungen und Tests. Unter Prüfungen versteht man hier statische Maßnahmen, wie z. B. die inhaltliche Überprüfung von Ergebnissen und Prozessen. Abb. 5.8: Vorgang der Systemzerlegung innerhalb des Projekttyps Systementwicklung unter HERMES [8]

Systemanforderungen

Voranalyse

System Lösungsvorschläge

Systemanforderungen

Konzept

Subsystem

Subsystem Systemarchitektur

Realisierung

Konfigurationseinheit

Systemanforderungen

Konfigurationseinheit Systemdesign

Element

Element

Unter Tests versteht man dynamische Maßnahmen, die die Systemanforderungen am laufenden System überprüfen. Die Abnahmeprüfung basiert auf vorher definierten Tests der Qualitätssicherung, bei der die zugesicherten Eigenschaften des Projektendproduktes überprüft werden. Im Submodell Konfigurationsmanagement (KM) soll die Integrität des innerhalb eines Projektes zu erstellenden Systems sichergestellt werden sowie die Nachvollziehbarkeit seiner Entwicklung. Je nach Projektphase sind typische Aktivitäten, wie z. B. KM-Plan erzeugen, Ergebnisbibliothek aktualisieren, KM-Schlussbericht anfertigen, durchzuführen. Nur durch das Konfigurationsmanagement ist eine Nachvollziehbarkeit der Entwicklung des zu erstellenden Projektendproduktes möglich. Das Konfigurationsmanagement ist über den gesamten Lebenszyklus des zu erstellenden Projektendprodukts durchzuführen.

76

■ ■ ■


Der Auftragnehmer wird diese Tätigkeit mit den entsprechenden Dokumenten dem für den Betrieb des Projektendproduktes zuständigen Personal des Auftragnehmers übergeben, damit dieses auf den dort vorliegenden Daten ein weiteres Konfigurationsmanagement durchführen kann. Weiterhin hat das Konfigurationsmanagement die Aufgabe, das Änderungsmanagement des Projektes durchzuführen, damit trotz vieler Änderungen die Kontrolle über das Projekt erhalten bleibt. Jede Änderung am bestehenden System muss bewertet und nach der erlaubten Durchführung dokumentiert werden. Alle Daten (Sourcecode, Dokumentation, Projektdokumente usw.), die in einem Projekt anfallen, werden in kürzeren Abständen gesichert, damit der erreichte Projektstand jederzeit an einem anderen Ort wieder erhalten werden kann. Projekt Lösungen entwickeln Lösung Änderungsantrag

Abb. 5.9: Lösungen in den Betrieb übernehmen [8]

Information

Lösungen in den Betrieb überführen Änderungen überwachen und Änderungsstatus kommunizieren

Änderungsantrag

Information

Betrieb Lösung

Lösungen betreiben

Infrastruktur betreiben

Benutzer unterstützen

Das Submodell Risikomanagement (RM) ermittelt anhand bestimmter Techniken, wie z. B. Interview oder Brainstorming, mögliche Risiken. Diese können vielfältiger Natur sein. Klassische technische Probleme wie auch Probleme rechtlicher Natur sind Beispiele dafür, auf welchen Gebieten das Problemmanagement eventuell tätig werden muss. Alle erkannten Risiken werden innerhalb des Risikokatalogs erfasst. Die Wahrscheinlichkeit eines eintreffenden Risikos wird geschätzt und eventuell zu ergreifende Gegenmaßnahmen ausgearbeitet. Danach erfolgt die ständige Überwachung, ob das Risiko auch

5.1 HERMES

■ ■ ■

77

wirklich eingetreten ist, mit anschließender Umsetzung vorher ausgearbeiteter Gegenmaßnahmen. Das Risikobewusstsein aller Projektbeteiligten soll durch die Tätigkeiten des Risikomanagements gestärkt werden. Im RM-Plan sind alle Informationskanäle beschrieben, welche Stellen oder Personen über bestimmte eintretende Risiken zu benachrichtigen sind. Das Projektmarketing (PM) ist innerhalb des Projektframeworks HERMES dafür verantwortlich, dass eine umfassende und zielgruppenspezifische Information über Ziele, Stand, Möglichkeiten und Grenzen des Projektes vermittelt werden kann und dass der Aufbau von Kontakten zu den Auftraggebern, internen Kunden und Promotern ermöglicht wird. Kritiker sollen in das Projekt mit eingebunden werden, um ihnen zu ermöglichen, das Projekt in ihrem Sinne zu beeinflussen. Das Projektmarketing soll einen Erfahrungsaustausch über die Belange des Projektes fördern, um das Projektendziel mit Erfolg erreichen zu können. Je nach Projekttyp sind die Submodelle Systementwicklung (SE), Systemadaption (SA), MOB und Migration neben den klassischen fünf Submodellen (Projekt-, Konfigurations- und Risikomanagement, Projektmarketing und Qualitätssicherung) Teil des Arbeitsstrukturplans. Abb. 5.10: Phasenmodell Systementwicklung [7]

Studie

Projekt

Betrieb

HERMES

■ ■ ■


Projektabschluss

Systemabnahme

Abschluss Abschluss

Freigabe Phase Abschluss

Einführung Einführung

Systemintegration

Systemfertigstellung

Freigabe Phase Einführung

Systemspezifikation

Realisierung Realisierung

Freigabe Phase Realisierung

Konzept

Konzept

Freigabe Phase Konzept

Lösungsauswahl

Projektantrag

78

Voranalyse Voranalyse

Zielvereinbarung

Initialisierung

Systementwicklung

Ausgangslage Situationsanalyse Systemziele Marktanalyse

Anforderungen

System/Prototyping

Systemanforderungen Betriebsanforderungen Geschäftsprozessanforderungen Organisationsanforderungen Pflichtenheft

Lösungsvorschlag Wirtschaftlichkeit Detailstudie Systemarchitektur Systemintegrationsplan Systemdesign Prototyp Informatiksystem

Fertigproduktevaluation Fertigprodukte Evaluationsbewertung Sachmittelbedarf Sachmittelevaluation Sachmittel

Ausbildung/ Betriebsdoku

Einführung Einführungskonzept Migrationsdesign Migrationsverfahren Geschäftsprozessbeschreibung Organisationsbeschreibung

Sachmittel/ Fertigprodukte

Abb. 5.11: Ergebnisstruktur Systementwicklung [7]

Berichte Voranalyse Konzept Realisierung Einführung Projektschlussbeurteilung

Ausbildungskonzept Anwendungshandbuch Supporthandbuch Betriebshandbuch Organisationshandbuch

Wir wollen uns nun einen groben Abriss über das bekannteste Submodell Systementwicklung (SE) ansehen. Das Submodell Systementwicklung beinhaltet spezifische Ergebnisse, die bei Systementwicklungs-Projekten anfallen können. Die Abb. 5.11. gibt einen Überblick. Ein spezifisches Phasenmodell beschreibt, welche Ergebnisse, Aktivitäten und Rollen innerhalb eines Systementwicklungsprojektes anfallen. Die wesentlichen Phasenergebnisse der HERMES-Phasen (Initialisierung bis Abschluss) für die Systementwicklung sind in der nachfolgenden Tabelle dargestellt. Phase

Wesentliches Phasenergebnis


Definierte Ausgangsbasis Grundsätzliche Lösungsvariante Umfassend beurteiltes Konzept Erstelltes System Installiertes und genutztes System Dokumentierte Projekterfahrungen

Tabelle 5.5 Phasenergebnisse der Systementwicklung

Innerhalb der Systementwicklungs-Phasen strukturiert HERMES die relevanten Aktivitäten und zu erzeugenden Projektergebnisse anhand eines speziellen Arbeitsstrukturplans (ASP), angepasst an die Systementwicklungserfordernisse.

5.1 HERMES

■ ■ ■

79

Für die einzelnen Dokumenten-Projektergebnisse wird ein vorteilhafter Aufbau vorgeschlagen. An bestimmten Stellen der Systementwicklungsphasen sind Entscheidungspunkte vorgesehen, wie z. B. nach der Konzeptphase (siehe auch Abb. 5.10) der Entscheidungspunkt „Freigabe Phase Realisierung“. Hier müssen den entscheidungsbefugten Rolleninhabern klar definierte Ergebnisse vorgelegt werden, die als Grundlage dienen für die Entscheidung, ob die nächste Phase durchgeführt werden soll. Reichen die Ergebnisse nicht aus, so wird die gegenwärtige Phase erneut durchgeführt, bis die Ergebnisse einen positiven Entscheid erlauben. In der Initialisierungsphase soll der generelle Verlauf für eine erfolgreiche Projektabwicklung definiert werden, indem die organisatorischen und technischen Rahmen festgelegt werden. Abb. 5.12: Übersicht der HERMES-Projektorganisation nach [7]

Phasenspezifische Erzeugnisse sind das Projekthandbuch, der Projektplan, Bedarfsanforderungen, Risikokatalog, Marketing-Konzept, anfänglicher QS-Plan und der Projektantrag. Am Phasenentscheidungspunkt wird darüber entschieden, ob der Projektauftrag erteilt und die nächste Phase, die Voranalyse-Phase, durchgeführt wird. Innerhalb der Voranalyse-Phase wird geklärt, auf welche Art und Weise das System realisiert und welche Ziele durch das System erreicht werden sollen. Stellt sich dabei heraus, dass das geplante Vorhaben unwirtschaftlich ist, so wird es vorzeitig abgebrochen. Innerhalb der Voranalyse-Phase werden verschiedene Lösungsvorschläge

80

■ ■ ■


auf ihre Brauchbarkeit hin untersucht, ob damit die Systemrealisierung durchgeführt werden kann. Die Aspekte der Informationssicherheit und des Datenschutzes werden betrachtet. Erzeugnisse dieser Phase sind die Situationsanalyse, Systemziele, ISDS-Konzept, Marktanalyse Systemanforderungen und Wirtschaftlichkeitsbetrachtung. Weiterhin werden Geschäftsprozess- und Organisationsanforderungen ermittelt. Am Ende steht wieder ein Phasenentscheidungspunkt, der auf Grundlage der ermittelten Daten und Erzeugnisse eine Entscheidung darüber ermöglicht, ob die nächste Systementwicklungs-Phase „Konzept“ durchgeführt wird. Abb. 5.13: Ergebnisse für Prüfungen und Tests mit ihren Abhängigkeiten nach HERMES [7]

QS-Plan Testkonzept

Prüfplan

Testplan

Prüfspezifikation

Testspezifikation

Prüfprozedur

Testprozedur

Prüfprotokoll

Testprotokoll

In der Konzeptphase wird überlegt, wie die in der Vorphase definierten Systemziele erreicht werden können. Systemanforderungen, Systemarchitektur, Systemintegrationsplan, Einführungs- und Ausbildungskonzept sind wesentliche Erzeugnisse der Konzeptphase, aber auch mögliche Schutzmaßnahmen gegen potentielle Bedrohungen der Informations- und Datensicherheit werden durchdacht. Sie werden innerhalb des ISDS-Konzepts niedergeschrieben. Kritische Teilsysteme des Gesamtsystems werden genauer untersucht und Anforderungen an die Geschäfts- und Organisationsprozesse weiter verfeinert. Mögliche Fertig-Fremdprodukte werden evaluiert und auf ihre Brauchbarkeit hin untersucht. Es wird der Sachmittelbedarf festgestellt und daraus die Wirtschaftlichkeit abgeleitet. Am Ende der Konzeptphase steht wieder der Entscheidungspunkt zur Realisierungsphase. Innerhalb der Realisierungsphase werden die Systemanforderungen und das Systemdesign ermittelt und eventuell

5.1 HERMES

■ ■ ■

81

ein Prototyp gefertigt, um Sicherheit bezüglich verschiedener offener Punkte des Systemdesigns zu erhalten. Oft wird dem Kunden oder Anwender der Prototyp vorgeführt, um die Zustimmung zu nicht vollständig definierten Anforderungen und kritischen Funktionen zu erhalten. Das Systemdesign beschreibt den Aufbau und die Funktionsweise des zu erstellenden Systems. Da das Systemdesign wesentlicher Teil der Realisierungsphase ist, wird es auch manchmal in mehreren iterativen Schritten verfeinert. Gleichzeitig wird mit dem Einführungskonzept und Migrationsverfahren die Einführung des realisierten Systems vorbereitet. Die Anforderungen bezüglich Informations- und Datensicherheit fließen in die Realisierung mit ein. Danach erfolgt die Erstellung des Systems anhand des definierten Systemdesigns. Liegt ein Prototyp vor, so wird dieser als Grundlage der Systemerstellung weiterentwickelt. Es erfolgt eine intensive Verifizierung der mittels des entwickelten Systems abgebildeten Geschäftsprozesse und deren Teilfunktionalitäten. Abb. 5.14: HERMES-Vorgehensweise bei externer Auftragsvergabe [7]

Auftraggeber

Auftragnehmer

Ausschreibung vornehmen Pflichtenheft Projekthandbuch Allgemeine Geschäftsbedingungen (AGB)

Angebotsunterlagen erstellen

Angebot auswerten

Wiederholung der Ausschreibung

Abbruch

Angebot ergänztes Projekthandbuch grober Projektplan

Ausgewähltes Angebot

Vertragsabschluss

Am Ende der Realisierungsphase steht der Entscheidungspunkt, ob das realisierte System den fachlichen und qualitativen Anforderungen entspricht. Ist die Entscheidung positiv, erfolgt die Einführungsphase. Innerhalb dieser Phase werden das erstellte System in den Betrieb überführt und die späteren Nutzer geschult. Dann erfolgen die Systemabnahmetests durch den Kunden. Ergebnisse der Systemabnahmetests werden in Prüfprotokollen niedergeschrieben sowie eventuelle Mängel festgehalten und beseitigt.

82

■ ■ ■


Nach einem stabilen Test- und Nutzungszeitraum erfolgt die Systemabnahme durch den Kunden. Sodann wird darüber entschieden, ob in die nächste Systementwicklungsphase „Abschluss“ übergegangen werden soll. Es werden alle noch notwendigen Maßnahmen erfasst und durchgeführt, Schlussberichte erstellt und das entwickelte System der Kundenorganisation zum Betreiben des neuen Systems übergeben. Erfahrungen und eine Projektabschlussbeurteilung werden festgehalten und niedergeschrieben. Alle Projektbeteiligten und technischen Hilfsmittel, die innerhalb der Projektorganisation zeitweilig gebunden waren, werden an die entsprechenden Organisationseinheiten abgetreten.

5.1.2 Spezielle Begriffe unter HERMES 5.1.2.1 Arbeitsstrukturplan (ASP) HERMES definiert je Projekttyp (Systementwicklung, Migration) und Submodell (Projekt-, Risiko-, Konfigurationsmanagement, Qualitätssicherung und Projektmarketing) Tätigkeiten und Aktivitäten, in logischer Reihenfolge sortiert, die innerhalb eines Arbeitsstrukturplans zusammengefasst sind. Dieser Arbeitsstrukturplan soll es unterstützend ermöglichen, das Projekt eines bestimmten Typs zum Erfolg zu führen. Die einzelnen Tätigkeiten und Aktivitäten unterstützen ein Projekt in den Bereichen Planung, Steuerung und Kontrolle. Es ist leicht einsichtig, dass je nach Projekttyp verschiedene Aktivitäten innerhalb der Projekt-, Risiko-, Konfigurations- und Qualitätssicherung durchgeführt werden müssen. In Abb. 5.15 erkennt man die submodellspezifischen Aktivitäten: Systemziele definieren und Lösungen suchen. Die Aktivitäten QS-Aktivitäten festlegen und planen sind dagegen immer dieselben, wenn auch die spezifische Ausprägung von Projekt zu Projekt variiert. 5.1.2.2 Ergebnisbibliothek Der Begriff Ergebnisbibliothek ist HERMES-spezifisch und beinhaltet das Erfassen aller Arbeitsergebnisse eines spezifischen Projektes mit entsprechendem Versionsstand des Konfigurationsmanagements (KM). Es soll sichergestellt werden, dass alle Ergebnisse eines Projektes eindeutig identifizierbar sind.

5.1 HERMES

■ ■ ■

83

Abb. 5.15: Auszug aus einem Projektstrukturplan eines fiktiven Projektes in der Systementwicklung [7]

5.1.2.3 Evaluationsbewertung Die Evaluationsbewertung ist die Entscheidungsgrundlage für die Beschaffung. In ihr befinden sich die Ergebnisse der Evaluation von Fertigprodukten, die einer Kosten/Nutzen-Analyse und Risikobewertung unterzogen wurden. Weiterhin werden in der Evaluationsbewertung die Eigenschaften des Fertigprodukts mit den Anforderungen des Pflichtenhefts verglichen und bewertet. Aufgrund der Ergebnisse wird ein Entscheid über die Beschaffung vorgenommen und weiteren Vertragsverhandlungen zugestimmt. 5.1.2.4 ISDS-Konzept ISDS ist die Abkürzung für Informationssicherheit und Datenschutz, die innerhalb von HERMES als separate Aktionen je nach Projekt durchgeführt werden müssen. Innerhalb des ISDS-Konzeptes soll sichergestellt werden, dass die Vertraulichkeit, Integrität und Verfügbarkeit der Daten und Dienste, die ein neues Projekt beinhalten, sichergestellt wird.

84

■ ■ ■


Innerhalb des Konzeptes muss in einer Analyse ermittelt werden, welche Sicherheitsanforderungen notwendig sind, und es müssen Schutzmaßnahmen erarbeitet werden. Auch muss der Datenschutz beim Umgang mit personenbezogenen Daten innerhalb des zu realisierenden Informationssystems eines Projektes sichergestellt werden. Je nach Einsatzort oder Behörde müssen Datensammlungen in einem Genehmigungsverfahren erlaubt werden. Abb. 5.16: Die Dimensionen der Datensicherheit nach [37]

Für die Erarbeitung von Antworten auf alle damit verbundenen Fragen ist der Informationssicherheits- und Datenschutzverantwortliche zuständig. Er erarbeitet auch für das innerhalb eines Projektes zu erzeugende Informationssystem ein Notfallkonzept, das in Notfallsituationen angewandt werden kann. Die Lösungen aus dem ISDS-Konzept werden dann nach und nach umgesetzt und implementiert. Auch wird die Effizienz dieser Schutzmaßnahmen überprüft und eventuell, wenn notwendig, verbessert. Eventuelle Restrisiken werden erfasst und beschrieben.

5.1.2.5 Marketing (MA)-Konzept Das Projektmanagementframework HERMES enthält als einziges Projektmanagementframework den Aspekt des Projektmarketings für größere Projekte. Jeder, der sich mit dem Projektgeschäft beschäftigt, weiß von Risiken, die aus dem Nichts entstehen können. Als ausgleichendes Element dient das Marketing-Konzept. Im Marketing-Konzept werden am Anfang eines Projektes neben einem einprägsamen Projektnamen und Projektlogo die Interessen und Personengruppen aufgelistet, die einen Bezug zu dem Projekt haben, und innerhalb einer Interessen-Gruppenmatrix zugeordnet. Jetzt können gezielte Informationsaktivitäten geplant und organisiert

5.1 HERMES

■ ■ ■

85

Abb. 5.17: Projektunterstützung und Kundenzufriedenheit erhalten durch Projektmarketing

Informationsaktivitäten planen und organisieren InteressenGruppenmatrix aufstellen Projektname Basisund faktoren Projektlogo

KUNDENZUFRIEDENHEIT

werden, die dem Projekt eine positive Beeinflussung des Projekterfolgs garantieren.

5.1.2.6 Organisationshandbuch Jedes Informations- oder DV-System, das im Rahmen eines Projektes erstellt wird, bedarf der Unterstützung bestehender Organisationsstrukturen, wenn es produktiv eingesetzt werden soll. Daneben verändern, ergänzen oder erweitern solche neuen Informationssysteme nicht selten bestehende Organisationsstrukturen. Innerhalb des Organisationshandbuches werden alle diese Aspekte behandelt. Es beinhaltet bestehende und notwendige Rollen und Verantwortlichkeiten sowie Schnittstellen des neuen Informationssystems zu anderen DV-Systemen, wenn das neue System in den Betrieb übergeben werden soll. 5.1.2.7 Projektplan und Projekthandbuch Der Projektplan und das Projekthandbuch bilden die Handlungsgrundlage für ein durch das HERMES-Projektmanagementframework gesteuertes Projekt. Der Projektplan am Anfang eines Projektes enthält die Grobplanung. Diese wird im Laufe des Projektes weiter verfeinert und den Erfordernissen entsprechend laufend angepasst. Der Einsatz von Personal- und Sachmitteln ist aus dem Projektplan ablesbar. Wichtige Aktivitäten und zugeordnete zu entwickelnde Teilprodukte sind verzeichnet. Grundangaben über Termine des PM, QS, RM, KM, PM, SE sowie der Auslieferungstermin des Gesamtwerkes sind im Projektplan enthalten.

86

■ ■ ■


Für alle entsprechenden Aktivitäten und Teilaktivitäten finden sich die entsprechenden Aufwände vermerkt. Angaben über Liefertermine von notwendigen Fremdprodukten sowie Termine für vordefinierte Projektmeilensteine und Walk-Through mit dem Kunden runden einen Projektplan ab. Aus dem Projektplan geht auch die Projektaufbauorganisation hervor sowie die Zusammensetzung der einzelnen Projektteams. Es ist beschrieben, welche Sachmittel (Räume, Server, Telefon, Netzwerkbandbreiten, Geldmittel) wann und wie lange den Entwicklerteams zur Verfügung stehen müssen. Aus der Beschreibung der Projektaufbauorganisation geht hervor, wer für die einzelnen HERMESSubmodelle (PM, KM, QS usw.) verantwortlich ist. Alle Aufgaben, Rollen und Verantwortlichkeiten können dem Projektplan entnommen werden. Der Projektplan ist das Dokument, welches am meisten verändert wird und das beim Ausdrucken schon veraltet ist. Wenn nötig, gibt es zu einzelnen groben Teilen des Projektplanes eine Feinplanung als separates Dokument. Aus dem Vergleich eines Ist-Projektplans mit einem Soll-Projektplan geht die Abweichung hervor, welche eine Prognose über eventuelle Verschiebungen einzelner Arbeitspakete oder des Lieferendtermins darstellt. Das Projekthandbuch stellt den technischen und organisatorischen Rahmen eines Projektes dar. Es beschreibt die wesentlichen Ziele und Teile eines Projektes, wie z. B. die Ablösung eines alten DV-Verfahrens bzw. die Einteilung in einzelne Projektphasen. Jede entsprechende Projektphase wird mit ihren spezifischen Anforderungen und Regelungen festgelegt. Abb. 5.18: Ausschnitt aus einem fiktiven groben Projektplan

5.1 HERMES

■ ■ ■

87

Nach Abschluss einer Projektphase wird das Projekthandbuch den bestehenden Erfordernissen angepasst. Es werden die HERMESspezifische Klassifikation des Projektes definiert sowie die bestehenden Risiken aufgezählt. Weiterhin wird der Projekttyp festgelegt und in Abhängigkeit von der Projektgröße ein entsprechendes Tailoring durchgeführt, das das projektspezifische Vorgehensmodell mit den wesentlichen durchzuführenden Aktivitäten des Projektes festlegt. Sind bestehende Risiken eines Projektes als hoch anzusehen, kann die Erstellung eines Prototypen vorgesehen werden. Ein wesentlicher Teil des Projekthandbuchs ist auch die Festlegung bestimmter Soft- und Hardware sowie entsprechender Projektmanagement- und Konfigurationsmanagement-Tools. Es wird festgelegt, in welchem Rahmen und in welchen Teilen das Projekt sicherheitsrelevanten Anforderungen unterliegt. Der grobe QS- und RM-Plan liegt bei. Innerhalb von Projektrahmenbedingungen kann auch festgelegt werden, in wieweit der Auftraggeber verpflichtet ist, den Projektverlauf mitzugestalten, und wer als Ansprechpartner fungiert. Manchmal werden auch Koordinations- und Kontrollstellen festgelegt, die die qualitätssichernden Maßnahmen im Namen des Auftraggebers überprüfen. Besonderen Wert legt man im Projekthandbuch darauf, wie bei Projektschwierigkeiten im Eskalationsfall verfahren werden soll. Das Projekthandbuch dient allen Projektbeteiligten als Handlungsgrundlage.

5.1.2.8 Risikokatalog und RM-Plan Jeder, der im Projektgeschäft ist, weiß, dass es viele Risiken geben kann, die das Erreichen der angestrebten Projektziele verhindern können. Man kann die Risiken meist nicht verhindern, wohl aber sofort, wenn sie entstehen, Maßnahmen vorsehen, um sie zu neutralisieren. Es ist klar ersichtlich, dass dies eine sehr anspruchsvolle Aufgabe in einem Projekt ist. Diese Aufgabe beginnt im Vorfeld eines Projektes, bevor man überhaupt ein Projekt initiiert. Risiken kommen in den verschiedensten Schattierungen vor: technische, finanzielle, rechtliche, zeitliche und organisatorisch-personelle. Die schwierigsten von allen sind die organisatorisch-personellen, da sie meist nicht veränderbar sind bzw. oft nicht offen angesprochen werden können. Denn wer kann sich schon seinen Kunden aussuchen. Deswegen ist es erforderlich, die entsprechenden Rahmenbedingungen im Vorfeld eines Projektes positiv zu beeinflussen. Alle bekannten Risiken werden innerhalb eines Dokuments, im Risikokatalog, gesammelt. Auswirkungen der Risiken werden analysiert und entsprechende neutralisierende Maßnahmen erdacht und dem Risikokatalog hinzugefügt. Die Risiken werden innerhalb einer

88

■ ■ ■


vorgegebenen Skala klassifiziert. Der Risikokatalog muss laufend aktualisiert werden und besonders beim Übergang in eine neue Projektphase den Gegebenheiten angepasst werden. Der Risikoverantwortliche eines Projektes ist für den Risikokatalog und die neutralisierenden Maßnahmen verantwortlich. Der RM-Plan definiert Kriterien, Messinstrumente und Hilfsmittel, um Risiken gerecht bewerten zu können. Hier kann z. B. festgelegt werden, in welcher Form (RM-Verfahren) die Risiken ermittelt werden sollen, wie z. B. in einem Interview oder Brainstorming mit den Projektbeteiligten. Innerhalb des RM-Plans wird definiert, wer wann über bestehende Risiken nach innen und außen zu informieren ist (RM-Organisation) und wer bei der Findung und Anwendung der entsprechenden risikominimierenden Maßnahmen zu beteiligen ist. Oft ergeben sich auch im direkten Kontakt zum Qualitätsmanagement Hinweise, die durch Qualitätstests offensichtlich werden. Für jede Risikoart werden im RM-Plan Schwellenwerte definiert, die festlegen, wann das eventuelle Risiko als eingetreten erachtet wird.

5.1.2.9 Situationsanalyse Die Situationsanalyse ist gerade in der Konzeptphase eines neuen DVSystems oder Projektes von immenser Bedeutung. Innerhalb der Lösungssuche, um Teile oder das Projekt als Ganzes zu realisieren, nimmt die Situationsanalyse einen wesentlichen Part zur Umsetzung der Projektziele ein. Jede Projektphase beginnt mit einer Situationsanalyse, in der die Ist-Situation einer Projektphase oder eines Projektes betrachtet wird. Darin enthalten sind die gegenwärtigen Probleme und die in der neuen Projektphase zu erwartenden neuen Probleme. Es werden, je nach zu realisierendem System, alle wesentlichen existierenden Schnittstellen und Rahmenparameter erfasst und in einem Gesamtkontext dargestellt. Darin enthalten sein können die Betriebsanforderungen. Auch vor dem Start eines Projektes wird eine Situationsanalyse durchgeführt, um schon bestehende Teile der Problemlösung dahingehend zu analysieren, in wieweit sie das Projektendziel beeinflussen und genutzt werden können. Auch bei der Evaluierung, ob Fertigprodukte als Ganzes oder in Teilen zur Realisierung von Projektzielen oder -Funktionalitäten verwendet werden können, wird eine Situationsanalyse vorgenommen. Zur Situationsanalyse gehört das Ermitteln von zu erwartenden Betriebs- und Investitionskosten sowie Verfügbarkeit eines neuen Projekt-Endproduktes. Die Sicherheitsanforderungen müssen in einer Situationsanalyse erfasst werden und auf entsprechende rechtliche Fragen, die sich daraus ergeben, Antworten generiert werden. Die weiteren Anforde-

5.1 HERMES

■ ■ ■

89

rungen an die Ausbaufähigkeit und die damit verbundenen Rückwirkungen auf andere Teilelemente sind zu erfassen. Entsprechende Dokumentationen, die Auskunft zu den einzelnen Fragestellungen geben können, werden innerhalb der Situationsanalyse erfasst. Wesentlicher Teil ist auch die Analyse, in welche bestehende Anwendungslandschaft und IT-Infrastruktur das neu zu erstellende System integriert werden soll. Auch organisatorische Rahmenbedingungen wie die Frage, wer ein System später betreut, wer der Anwender ist und ob das neue DV-System 7 u 24 Stunden genutzt werden soll, sind Dinge, die durch eine Situationsanalyse geklärt werden sollen. Das Erfassen existierender und erwarteter zukünftiger Schwachstellen ist ebenfalls von Bedeutung, da sich entsprechende Maßnahmen davon ableiten lassen. Qualitative Anforderungen an das Qualitätssicherungsverfahren werden innerhalb einer Situationsanalyse festgestellt und entsprechende qualitätssichernde Normen festgelegt. Alle diese Daten ergeben im Überblick mit den bestehenden Projektund Systemzielen die funktionalen und System-Anforderungen an das Projektendprodukt.

5.1.2.10 Projekthistorie Innerhalb der Projekthistorie wird beim Projektmanagement-Framework HERMES der Projektverlauf dokumentiert, damit man später nachvollziehen und überprüfen kann, warum Entscheidungen getroffen bzw. nicht getroffen wurden. Auch lässt sich nachvollziehen, wann und warum Änderungen in der Entwicklung stattgefunden haben und wer diese Änderungen bezahlen muss. Weiterhin werden entdeckte Fehler und Risiken festgehalten. Versionsstände der Softund Hardware mit dem entsprechenden Funktionsumfang werden in der Projekthistorie festgehalten. Auch dient die Projekthistorie dazu, nachzuvollziehen, wer was wann getan hat, um eingehende Rechnungen für Fremdpersonal oder -material nachhalten zu können.

5.2 V-Modell-XT Die Geschichte des V-Modells beginnt 1988 mit der Vorstellung der ersten Version des V-Modells. Vorangegangen war eine intensive Diskussion darüber, wie eine Standardisierung der Softwareentwicklung sowie Software-Pflege bzw. -Änderung innerhalb von Bundesbehörden gestaltet sein könnte. Es wurden unterschiedliche Ansätze und Normierungen in anderen Ländern, wie den USA und Frankreich, geprüft, doch stellte sich bald heraus, dass sich die Anforderungen an

90

■ ■ ■


Abb. 5.19: Das neue V-Modell-XT [4]

einen allgemeingültigen Standard damit nicht realisieren ließen. 1986 wurden somit durch das Bundesministerium der Verteidigung zwei Projekte initiiert (Softwareentwicklungsumgebung für Informationssysteme, SEU-IS; und die Softwareentwicklungsumgebung für Waffen- und Waffeneinsatzsysteme, SEU-WS), die sicherstellen sollten, dass eine Vergleichbarkeit von Angeboten der unterschiedlichen Firmen bei einer Ausschreibung möglich wurde und somit auch die Kosten eines Softwareentwicklungsprojektes transparenter auszuwerten und begrenzbar waren. Daneben sollte die Qualität des Endproduktes „die entwickelte Software“ erhöht werden. Seitdem hat sich die Softwareentwicklung, wie die gesamte Informationstechnologie, rasant verändert. Und so wurde auch das V-Modell in den Jahren 1991 und 1997 sowie im Februar des Jahres 2005 dem jeweiligen Wissensstand angepasst. Mit der Version V-Modell 1997 gelangte es quasi in jede Bundesbehörde. Die heute vorliegende Version V-Modell XT in der Release 1.1 stellt das Endprodukt der heutigen Diskussionen innerhalb Deutschlands dar. Nachteil ist die Mächtigkeit und Komplexität des V-Modells. Diese schreckt viele Anwender zunächst ab. Hat man aber erst einmal verschiedene „konventionelle Projekte“ mit negativem Ausgang mitgemacht und die positiven Effekte verinnerlicht, so verliert es seinen komplexen Charakter. Teil 1 (Grundlagen des V-Modells) beschreibt die Grundlagen des V-Modells und gibt einen generellen Überblick. Es werden Anwendungsrichtlinien genannt, welche die Umsetzung des V-Modells in konkrete Projekte regeln sollen. Im Teil 2 (Eine Tour durch das V-Modell) wird anhand eines Beispielprojektes beschrieben, wie das V-Modell in der Praxis angewandt werden kann. Teil 3 (V-ModellReferenz Tailoring) beschreibt, wie ein Tailoring innerhalb des V-Modells durchgeführt wird, um die notwendigen Aktivitäten und Erzeugnisse für ein Projekt ermitteln zu können. Als Entscheidungsbasis werden Projektmerkmale definiert.

5.2 V-Modell-XT

■ ■ ■

91

Abb. 5.20: Aufbau des V-Modells-XT

Im Teil 4 (V-Modell-Referenz Rollen) werden die spezifischen Rollen (wie z. B. HW-Architekt, SW-Entwickler, Ausschreibungsverantwortlicher, Einkäufer usw.) innerhalb des V-Modells beschrieben, die von Projektmitgliedern übernommen werden müssen, um die entsprechenden Aktivitäten und Erzeugnisse des V-Modells durchzuführen und zu erzeugen. Im Teil 5 (V-Modell-Referenz Produkte) sind die spezifischen Produkte für den jeweiligen Vorgehensbaustein beschrieben. Beispiele für Produkte beim Vorgehensbaustein „Projektmanagement“ wären z. B. Projekthandbuch, Projektplan sowie Projekttagebuch. Äquivalent werden im Teil 6 (V-Modell-Referenz Aktivitäten) alle spezifischen Aktivitäten für den jeweiligen Vorgehensbaustein beschrieben. Beispiele für Aktivitäten beim Vorgehensbaustein „HW-/SW-Entwicklung“ wären z. B. Anforderungen festlegen, Systemspezifikation oder Ersatzteilekatalog erstellen. Teil 7 (V-ModellReferenz Konventionsabbildungen) des V-Modells-XT beschäftigt sich mit Konventionsabbildungen (Vergleich von V-Modell-XT zu V-Modell 97), was nichts anderes bedeutet als das Beziffern äquivalenter Aktivitäten und Produkte des V-Modells-XT zu anderen gebräuchlichen Normen und Prozessen, wie z. B. des alten V-Modells 97 oder der AQAP-150, CMMI und ISO 15288. Abb. 5.21: Symbole für Aktivitäten und Produkte beim V-Modell-XT

92

■ ■ ■

Aktivität

Produkt


Teil 8 (V-Modell-Referenz Anhang) enthält neben einem ausführlichen Glossar eine Referenz über Literaturangaben, eine Methodenreferenz sowie ein Abkürzungsverzeichnis. Innerhalb des Teils 9 (V-Modell-Referenz Vorlagen) findet man V-Modell-spezifische Dokumenten-Vorlagen, um das V-Modell im Rahmen eines neuen Projektes direkt einsetzen zu können.

5.2.1 Einsatzbereiche des V-Modells Um sich ein generelles Bild vom V-Modell zu machen, ist es lohnend, sich einen Überblick über die Verwendungsform zu verschaffen. Grundsätzlich deckt das V-Modell die folgenden Einsatzbereiche ab: x Auftragsaufforderung x Vertragsgestaltung x Projektbegleitung von IT-Systemen x Erstellung von IT-Systemen x Pflege von IT-Systemen x Änderung von IT-Systemen (SWPÄ) Es kann somit während des gesamten Lebenszyklus eines ITSystems eingesetzt werden. Abbildung 5.22 zeigt, wie seine Verwendung die Kommunikation zwischen Auftraggeber und Auftragnehmer gestaltet. Auftragnehmer als Generalunternehmer

Öffentlicher Auftraggeber

V-Modell als Vertragsgrundlage Projektnachweis Projektbetreuung

Projektabwicklung

ProjektAbwicklung und -Entwicklung

Abb. 5.22: Die verschiedenen Einsatzmöglichkeiten des V-Modells-XT

Projektbetreuung V-Modell als Arbeitsanleitung

V-Modell als Vertragsgrundlage

V-Modell als Arbeitsanleitung

V-Modell als Vertragsgrundlage

V-Modell

Projektnachweis Projektabwicklung


Projektnachweis


Projektabwicklung

Subunternehmer 1

Subunternehmer n

5.2 V-Modell-XT

■ ■ ■

93

Das V-Modell wird also, wie aus Abb. 5.22 ersichtlich, als Vertragsgrundlage und Projektdurchführungs- bzw. Arbeitsanleitung eingesetzt.

5.2.2 Spezifische Eigenarten des V-Modells 5.2.2.1 Tailoring Ein wesentlicher Begriff des V-Modells ist das Tailoring. Es steht für das Anpassen des V-Modells an die projektspezifischen Gegebenheiten eines Projektes. Ein Beispiel hierfür ist die Größe (Projekt-Personen-Monate oder Projekt-Kosten) eines Projektes, die dazu führt, dass nur bestimmte Teilbereiche oder Vorgehensbausteine des V-Modells bei einem Projekt beachtet werden müssen. Abb. 5.23: Schematische Wirkungsweise des Tailorings

So ist es leicht einsehbar, dass es bei einem kleinen Projekt nicht notwendig ist, die Vorgehensbausteine Logistikkonzeption oder Systemsicherheit zu betrachten oder innerhalb des Vorgehensbausteins HW-/SW-Entwicklung eine System-Integration zu spezifizieren oder innerhalb der Implementierung die Debugging-Möglichkeiten zu beschreiben. Innerhalb des V-Modells wird zwischen statischem und dynamischem Tailoring unterschieden. Statisches Tailoring, auch ausschreibungsrelevantes Tailoring genannt, wird angewandt bei der Projektinitialisierung, bei der die für ein Projekt sinnvollen bzw. erforderlichen Tätigkeiten und Produkte ermittelt werden, welche dann innerhalb des Projekthandbuches niedergeschrieben werden.

94

■ ■ ■


Das dynamische Tailoring wird dagegen im weiteren Projektverlauf während der Feinplanung eingesetzt.

5.2.2.2 Prototyping Eins der wichtigsten Elemente, die im V-Modell enthalten sind, um den Projekterfolg sicherzustellen, ist das „Prototyping“. Jeder, der sich schon längere Zeit mit dem Projektgeschäft beschäftigt, hat schon einmal erlebt, wie über längere Zeit Aktenordner über Aktenordner angelegt wurden, in denen bestimmt wurde, wie das Endprodukt eines Projektes aussehen sollte, bevor überhaupt die ersten Schritte zur tatsächlichen Umsetzung unternommen wurden. Dabei besteht die Gefahr, dass Annahmen und Voraussetzungen definiert wurden, die sich in der Wirklichkeit nicht realisieren lassen. Deswegen führte das V-Modell den Vorgang des Prototypings ein. Es hat die Aufgabe, Einzelanforderungen auf ihre Realisierbarkeit hin zu verifizieren und dem Auftraggeber und Auftragnehmer in der Anfangsphase eines Projektes noch die Möglichkeit einzuräumen, unerfüllbare und sinnlose Forderungen zu identifizieren. Es dient der Minimierung des Entwicklungsrisikos. Auch lässt sich mittels des Prototyping-Ansatzes die Leistungsfähigkeit eines Endproduktes einschätzen. Denkt man hier z. B. an realisierbare Antwortzeitverhalten oder die CPU-Last eines Systems, kann man vermeiden, viel Geld durch Fehlkäufe von teurer Hardware zu verlieren. Oft deckt ein existierender Prototyp eventuelle Integrationsschwierigkeiten externer Schnittstellen auf oder man erkennt, dass Schnittstellen zu anderen Systemen als Ganzes vergessen wurden. Das Prototyping wird auch oft eingesetzt, um die Entwicklung kritischer Teilelemente eines zu entwickelnden Systems vorzuziehen, die eventuell bei Nicht-Realisierbarkeit das Gesamtprojekt in Frage stellen. Es ist des Öfteren das Mittel der Wahl, um eine Anforderungsanalyse genauer durchführen zu können und technische Ansätze zur Realisierung zu erproben. Eine frühzeitige Qualitätssicherung sowie Ausarbeitung von Qualitätstests ist möglich. Es gibt dem Auftraggeber, Auftragnehmer sowie dem Endanwender die Möglichkeit, eine frühzeitige Informationsbeschaffung und Diskussion über wichtige technische und organisatorische Kernpunkte eines Projektes aufzunehmen. Damit kann der Planungsaufwand unter Umständen reduziert werden. Ein weiterer Vorteil des Prototypings ist, dass der Fertigstellungsgrad besser verifizierbar ist. Nachteilig wirkt sich hier aus, dass das Prototyping oft innerhalb kurzer Zeit den Prototyp erzeugt, aber eine Dokumentation wegen der Kürze der Zeit unterbleibt.

5.2 V-Modell-XT

■ ■ ■

95

Typische Arten des Prototypings sind Exploratives Prototyping, Experimentelles Prototyping und Evolutionäres Prototyping. Unter einem Explorativen Prototyping versteht man, dass im direkten Meinungsaustausch mit dem Anwender die Anwenderforderungen verfeinert, ergänzt und geklärt werden. Beim Experimentellen Prototyping werden technische Eigenschaften eines Systems oder Systemteils ermittelt. Das Evolutionäre Prototyping beginnt mit der ersten Version der Anwenderforderungen, die in einem System-Prototypen mündet. Diese erste Version wird ergänzt und geändert nach den davon abgeleiteten weiteren Anwenderforderungen, wobei alle Teile des Prototypen ergänzt und geändert werden können. Der Prototyp wird somit als Grundlage des zukünftigen Systems weiterentwickelt.

Abb. 5.24: Schematischer Zusammenhang Kosten und Nutzbarkeit bei Standard-Software versus Individual-Software

Kosten

5.2.2.3 Systembegriff innerhalb des V-Modells Der Systembegriff innerhalb des V-Modells bezieht sich auf den in der ISO 12207 definierten Begriff „System“. Dort versteht man unter einem System ein einheitliches Ganzes, das aus einem oder mehreren Prozessen, Hardware, Software, Einrichtungen und Personen besteht und die Fähigkeit besitzt, vorgegebene Forderungen oder Ziele zu befriedigen. Beim V-Modell werden dabei nur Systeme betrachtet, deren Aufgabenerfüllung vorwiegend durch den Einsatz von IT realisiert wird. Dazu zählen neben den IT-Systemen auch IT-Anteile in anderen Systemen.

IndividualSoftware Angepasste StandardSoftware

StandardSoftware

Optimale Nutzbarkeit der eingesetzten Geschäftsprozesse

96

■ ■ ■


Unter einem Element (Funktionseinheit, Baustein) versteht man beim V-Modell ein nach Aufgabe oder Wirkung abgrenzbares Gebilde. Ein Element kann somit ein System, ein Segment, eine SW-/ HW-Einheit, eine SW-Komponente, ein SW-Modul oder eine Datenbank sein.

5.2.2.4 Fertigprodukte (COTS, MOTS und GOTS) Im V-Modell versteht man unter einem Fertigprodukt eine im eigenen Umfeld oder im Markt verfügbare passende Funktionseinheit. Weiterhin wird zwischen einem COTS (Commercial off-the-shelf), GOTS (Goverment off-the-shelf) und MOTS (Military off-the-shelf oder Modifiable off-the-shelf) unterschieden. Unter COTS versteht man seriengefertigte Produkte aus dem Elektronik- oder Softwaresektor, die in großer Stückzahl, völlig gleichartig aufgebaut, verkauft werden. Allgemeines Beispiel sind hier MS-Office-Produkte. Entwicklungskosten für diese Fertigprodukte werden dann nicht vom Auftraggeber allein, sondern durch die hohen Verkaufsstückzahlen vom Markt getragen. Eine Sonderform des COTS, die zwar aus Serienfertigung zur Verfügung steht, aber immer noch auf die Bedürfnisse des Endkunden angepasst werden kann oder muss, ist MOTS (modifiable offthe-shelf). Beispiel ist hier z. B. der Einsatz von gewerblich nutzbarer Open Software, wie z. B. Teile des LINUX-Betriebssystems, deren Quellcode noch angepasst werden muss. Oft versteht man unter MOTS (Military off-the-shelf) auch ein Produkt eines externen Herstellers, das speziell nach Spezifikationen der Bundeswehr gebaut wurde. GOTS (Goverment off-the-shelf) entspricht der klassischen Selbstentwicklung einer öffentlichen Institution oder der Bundeswehr, oft auch durch militärische Forschungseinrichtungen entwickelte Produkte. 5.2.2.5 Aktivitäten, Hauptaktivitäten und Produktflusstabellen Eine Aktivität unter dem V-Modell mündet in ein Produkt, wie z. B. in eine Schnittstellenübersicht oder ein SW-Architektur-Dokument. Einzelne Kapitel, die als Teilaktivität separat erstellt wurden, nennt man dann entsprechend Teilprodukt. Einer Aktivität sind spezifische Tätigkeiten zugeordnet, die ein Produkt erzeugen oder verändern. Somit bestehen Aktivitäten aus Teilaktivitäten.

5.2 V-Modell-XT

■ ■ ■

97

Abb. 5.25: Beispielhafter Produktfluss beim V-Modell-XT

Hauptaktivität

SW-Entwicklung „Zentrale Steuereinheit“

Aktivität 1 Teilaktivität1 Teilaktivität2 Teilaktivität3 Aktivität 2 Teilaktivität1 Teilaktivität2 Teilaktivität3

Anwenderforderungen Bedienbarkeit Reaktionszeiten Datendurchsatz Systemarchitektur Hardware Software Netzwerk

Aktivität n Teilaktivität1 Teilaktivität2 Teilaktivität3

Schnittstellenübersicht Echtzeitbus Steuereinheit Externe Wartungsschnittstelle

Die oberste Ebene der Aktivitäten nennt man Hauptaktivität. Welche Aktivitäten durchgeführt bzw. welche Produkte erzeugt werden müssen, hängt davon ab, welche Projektvoraussetzungen vorliegen. Alle notwendigen Aktivitäten und Produkte werden durch das Tailoring entsprechend den Projektvoraussetzungen ermittelt. Der Produktfluss beschreibt, welche Aktivitäten die benötigten Produkte erzeugen und in welchem Zustand (geplant, in Bearbeitung, vorgelegt, akzeptiert) sie dann sind. Weiterhin definiert er, welche Voraussetzungen oder Eingangsprodukte vorliegen müssen, um die nächsten Aktivitäten des Erstellungsprozesses des Endprodukts durchführen zu können.

5.2.2.6 Wirtschaftlichkeitsbetrachtung für Projekte in der Informationstechnik (IT-WiBe) Des Öfteren wurde früher neben dem V-Modell 97 auch eine ITWiBe separat vom V-Modell durchgeführt, die nun in das V-Modell-XT integriert wurde. Unter der IT-WiBe (Wirtschaftlichkeitsbetrachtung für Projekte in der Informationstechnik) versteht man die Bewertung eines neuen IT-Projekts anhand eines Kriterienkatalogs. Folgende Kriterienmodule sind innerhalb der IT-WiBe definiert: x x x x

98

■ ■ ■

WiBe KN (Kosten- und Nutzen-Kriterien) WiBe R (Risiko bei Kostenkriterien) WiBe D (Dringlichkeit des IT-Vorhabens) WiBe Q (Qualitativ-strategische Bedeutung)


Abb. 5.26: Die Wirkungsdimensionen der IT-WiBE [39]

WiBe KN und WiBe R bilden die Wirtschaftlichkeit im engeren Sinne, WiBe D und WiBe Q die erweiterte Wirtschaftlichkeit. Die Bewertung anhand der Kriterienkataloge ermittelt die Wirtschaftlichkeit unter Kosten-/Nutzenaspekten mittels der Kapitalwertmethode. Hier werden die Entwicklungs- und Integrationskosten auf der einen Seite mit dem monetären Nutzen auf der anderen Seite verglichen. Der monetäre Nutzen wird meist durch Einsparungen beim Ablösen von alten IT-Verfahren erzielt bzw. durch Einsparungen bei deren Betriebskosten. Dies ist oft gleichzusetzen mit Personaleinsparungen bzw. Reduktion der Wartungskosten. Regel: Projekt

WiBe KN

WiBe D

WiBe Q

WiBe E

Durchführen

KN > 0

Durchführen, Projektrisiken beachten Durchführen, aber Nutzen-Inkasso sichern! Negativer Kapitalwert, denoch: durchführen Negativer Kapitalwert, kann ggf. durchgeführt werden Negativer Kapitalwert, kann ggf. durchgeführt werden Negativer Kapitalwert, darf nicht durchgeführt werden

KN > 0, KN/R < KN KN > 0, KN h < 0

KN < 0

3.2.1 = 10 P.

KN < 0

4.1.1 = 10 P.

KN < 0

> 50

> 50

> 50

KN < 0

< 50

< 50

< 50

5.2 V-Modell-XT

Tabelle 5.6: Entscheidungsregeln der ITWiBe [38]

■ ■ ■

99

Neben der Kapitalwertmethode wird eine Wirtschaftlichkeitsbetrachtung auch nach der Nutzwertanalyse vorgenommen für die Fälle, in denen sich der Nachweis der Wirtschaftlichkeit monetär nicht ermitteln lässt. Hier werden meist Gründe wie Dringlichkeit bzw. strategische Bedeutung mit in die Wirtschaftlichkeitsberechnung einbezogen. Die IT-WiBe umfasst meist den Zeitraum der voraussichtlichen Nutzungsdauer eines neuen IT- oder DV-Verfahrens. Standardmäßig umfasst dieser Zeitraum fünf Haushaltsjahre.

5.3 Die einzelnen V-Modell-XTVorgehensbausteine im Überblick Eine wichtige Rolle innerhalb des V-Modells-XT bilden die Vorgehensbausteine. Sie enthalten jeweils ein Set von Aktivitäten und spezifischen Erzeugnissen, die dem entsprechenden Vorgehensbaustein zugeordnet sind. Aber nicht alle Aktivitäten oder Erzeugnisse müssen beachtet werden. Je nach Projekt wird mit dem Tailoring festgelegt, welche Aktivitäten und Erzeugnisse innerhalb des Vorgehensbausteins sinnvollerweise durchzuführen bzw. zu erzeugen sind. Die folgenden Vorgehensbausteine sind innerhalb des V-Modells-XT definiert: x Projektmanagement x Qualitätssicherung x Konfigurationsmanagement x Problem- und Änderungsmanagement x Kaufmännisches Projektmanagement x Messung und Analyse x Anforderungsfestlegung x Systemerstellung x Auftragsvergabe, Projektbegleitung und Abnahme durch den Auftraggeber x Angebotserstellung und Vertragserfüllung durch den Auftragnehmer x HW-Entwicklung x SW-Entwicklung

100

■ ■ ■


x Logistikkonzeption x Evaluierung von Fertigprodukten x Benutzbarkeit und Ergonomie x Systemsicherheit x Weiterentwicklung und Migration von Altsystemen x Einführung und Pflege eines organisationsspezifischen Vorgehensmodells

5.3.1 Projektmanagement Das Projektmanagement beinhaltet grundsätzlich alle Dinge, die sicherstellen, dass das Projektziel erreicht wird. In Kurzfassung: „All what needs to be done to get the Job done“. Innerhalb des Vorgehensbausteins Projektmanagement sind also all die Dinge enthalten, die der Planung, Kontrolle und Steuerung von Projekten dienen. Erzeugnisse wie Projekthandbuch, Projektplan, Risikoliste und Dokumente des Berichtswesens sind dem V-Modell-XT-Vorgehensbaustein zugeordnet.

5.3.2 Qualitätssicherung Im Vorgehensbaustein Qualitätssicherung werden die Aktivitäten und Erzeugnisse beschrieben, die sicherstellen, dass das Projektendprodukt die zugesicherten Eigenschaften besitzt. Innerhalb des Erzeugnisses QS-Handbuch wird beschrieben, welche Prüfungen mit welchen Spezifikationen durchgeführt werden müssen und wie dies dokumentiert werden soll. Wichtig dabei ist, dass die Prüfung durch eine andere Person erfolgt als die, die das Produkt innerhalb der Projektlaufzeit entwickelt hat. Da jedes entwickelte Produkt spezifische Eigenschaften besitzt, müssen die Prüfspezifikationen und die Prüfprozedur auch spezifisch festgelegt und die Ergebnisse so festgehalten werden, dass sie dem Auftraggeber als Nachweis vorgelegt werden können. Wichtig dabei ist, die Tests so zu gestalten, dass sie jederzeit wiederholbare Ergebnisse liefern.

5.3 Die einzelnen V-Modell-XT-Vorgehensbausteine im Überblick

■ ■ ■

101

Abb. 5.27: V-Modell-PMProzess

102

■ ■ ■


Abb. 5.28: V-Modell-QSProzess


■ ■ ■

103

5.3.3 Konfigurationsmanagement Abb. 5.29: V-Modell-KMProzess

104

■ ■ ■

Das Konfigurationsmanagement soll sicherstellen, dass alle Teile eines Produktes, das innerhalb eines Projektes erstellt wird, eindeutig bestimmt sind.


Darunter fällt nicht nur das entwickelte Produkt, sondern auch die Entwicklungsumgebung, spezifische Prüfeinrichtungen und eine entsprechende Dokumentation, die erforderlich ist, um das Produkt zu betreiben. Auch Änderungen, die sich aus Änderungswünschen des Auftraggebers ergeben, müssen innerhalb des Vorgehensbausteins Konfigurationsmanagement erfasst werden. Jeder, der das Konfigurationsmanagement eines Projektes schon einmal durchführen musste, weiß, wie komplex dieses Thema sein kann.

5.3.4 Problem- und Änderungsmanagement Da sich nichts so schnell ändert wie die Wünsche an einem zu entwickelnden Produkt, ist es die Aufgabe des Vorgehensbausteins Problem- und Änderungsmanagement im V-Modell-XT, diese zu bewerten und offiziell umzusetzen. Aber auch technische oder organisatorische Änderungen, die sich aus Problemen innerhalb eines Projektes ergeben, sind zu betrachten. Bei jeder Änderung am Endprodukt eines Projektes muss offiziell bewertet werden, in welcher Hinsicht Kosten und Erstellungsendtermin davon betroffen sind. Auch können durch die Änderungen neue Abhängigkeiten entstehen, die das Risiko eines Projektes erhöhen, etwa durch eine vom Auftraggeber nachträglich gewünschte Integration eines Fremdprodukts einer Fremdfirma.

5.3.5 Kaufmännisches Projektmanagement Innerhalb des Vorgehensbausteins Kaufmännisches Projektmanagement werden die spezifischen Aktivitäten und Produkte beschrieben, die sich aus der Planung und Steuerung der Projekt- und Fertigungskosten ergeben. Angefangen bei der Aufwandsabschätzung eines geplanten Projektes bis hin zur aktuellen Kostenermittlung (Soll und Ist) eines gegenwärtigen Projektstandes ermöglicht dies der Projektleitung, zielgerichtete Entscheidungen zu treffen, um das Projektziel zu erreichen.

5.3.6 Messung und Analyse Jeder Prozess – und ein Projekt stellt auch einen sehr komplexen Prozess dar – kann durch Ermittlung von prozessspezifischen Kenn-


■ ■ ■

105

zahlen überprüft und gesteuert werden. Damit lassen sich Fehler und Abweichungen im Projektverlauf besser feststellen und bewerten. Innerhalb des Vorgehensbausteins Messung und Analyse des V-Modells-XT wird dieser Vorgang beschrieben, ohne Aussagen darüber zu treffen, welche Metriken dabei genutzt werden sollen. Dies festzulegen, ist die Aufgabe des Projektmanagements, welches sich dabei entweder auf spezifische Eigenheiten des gegenwärtigen Projektes bezieht oder aber auf Erfahrungswerte, die sich aus anderen, schon erfolgreich beendeten Projekten ableiten lassen.

5.3.7 Anforderungsfestlegung Der Vorgehensbaustein Anforderungsfestlegung soll sicherstellen, dass es eindeutige Entscheidungskriterien und Gründe gibt, ein Projekt auf Basis eines Projektvorschlags durchzuführen. Der Auftraggeber muss Anforderungen erfassen und innerhalb eines Lastenheftes niederschreiben. Der Auftraggeber will mit dem Vorgehensbaustein Anforderungsfestlegung die wirtschaftlichen Rahmenbedingungen günstig beeinflussen, indem er die Anwenderanforderung so detailgerecht beschreibt, dass ein potentieller Auftragnehmer einen Überblick erhält, der ihn in die Lage versetzt, ein optimales Angebot zu erstellen.

5.3.8 Systemerstellung Im Vorgehensbaustein Systemerstellung werden all die Aktivitäten und Produkte behandelt, die sicherstellen, dass ein komplexes technisches System, das sich aus den Systemelementen Hardware, Software und externen Einheiten zusammensetzt, in der entsprechenden Einsatzumgebung funktionstüchtig ist. Die einzelnen Systemelemente müssen erfasst und ihre spezifischen Eigenheiten festgelegt werden. Eine Systemspezifikation definiert innerhalb eines Pflichtenheftes die Einzelanforderungen an die einzelnen Systemelemente. Innerhalb des Systementwurfs werden die Systemarchitektur, die Implementierung und die Prüfung des gesamten Systems erfasst. Bei der Implementierung des Systems ist es wichtig, dass erforderliche Integrationsschritte vorher definiert wurden. Es ist notwendig, anhand von Anforderungen und Analysen festzulegen, ob einzelne Teilelemente des Gesamtsystems gekauft oder entwickelt werden müssen. Hierbei ist auch zu erfassen, welche technische Umgebung bzw. unterstützende Systemarchitektur vorliegen muss, um die Teilelemente bzw. das Gesamtsystem betreiben zu können. Auch

106

■ ■ ■


sind Prüfspezifikationen auf Elementebene bzw. systemelementübergreifend festzulegen.

5.3.9 Auftragsvergabe, Projektbegleitung und Abnahme durch den Auftraggeber Ziel dieses Vorgehensbausteins im V-Modell-XT ist es, die organisatorischen Rahmenbedingungen festzulegen, die es dem Auftraggeber ermöglichen, die Abwicklung eines Projektes positiv zu beeinflussen. Die Auslegung der einzelnen Punkte dieses Vorgehensbausteins ist abhängig von der jeweiligen Firma oder öffentlichen Institution. Anfänglich muss festgelegt werden, wie ein Projekt ausgeschrieben wird (Vergabeverfahren), z. B. ob im öffentlichen Wettbewerb oder in funktional beschränkter Ausschreibung. Auch muss auf Grundlage existierender Anforderungen ein Lastenheft erzeugt werden, auf dessen Grundlage der Auftragnehmer ein Leistungsverzeichnis erstellt. Ein Kriterienkatalog zur Bewertung von Angeboten sowie ein Fragenkatalog für die potentiellen Auftragnehmer runden diesen Vorgehensbaustein ab. Bei den nachfolgenden Vertragsverhandlungen werden je nach Ausschreibungsart eventuelle Fragen und Nachverhandlungen behandelt. Der zwischen Auftraggeber und Auftragnehmer abgeschlossene Vertrag enthält neben den Anforderungen an das zu erstellende Gewerk ein Projekthandbuch, eine Leistungsbeschreibung und ein QS-Handbuch. Es werden bei größeren Projekten so genannte Meilensteine (Project Milestones) definiert, die es dem Auftragnehmer ermöglichen, das entwickelte Endprodukt in seinem vorliegenden Reifegrad zu betrachten und zu bewerten, und somit frühzeitig den Auftragnehmer auf Wünsche oder Abweichungen des Endproduktes zu den existierenden Vorstellungen aufmerksam machen. Oft sind diese Projektphasen auch mit entsprechenden Teilleistungen des Auftraggebers verbunden, so dass der Auftraggeber eine finanzielle Gegenleistung erhält. Die Abnahme des Projektendproduktes oder der Projektteilprodukte erfolgt nach den vorher erstellten Prüfspezifikationen, die, soweit es geht, am Anfang eines Projektes festgelegt werden. In den Vertragswerken der Projektbeauftragung sind Klauseln einzufügen, die Bezug nehmen auf Abnahme und eine eventuelle Mängelbeseitigung.

5.3.10 HW-Entwicklung Bei dem Vorgehensbaustein HW-Entwicklung wird, angefangen beim Systementwurf der Hardware-Architektur über die Hardware-


■ ■ ■

107

Systemspezifikation bis zur Hardwareintegration, beschrieben, wie die einzelnen Hardwareelemente entwickelt und integriert werden sollen. Der Hardwareentwurf beschreibt neben der generellen Spezifikation das Design der Hardwarekomponenten. In der Realisierungsphase werden die vorher definierten Hardware-Systemspezifikationen verfeinert und umgesetzt. Innerhalb des Integrationsteils wird neben der Inbetriebnahme und den Prüftests auch die Integration der spezifischen Hardwarekomponente mit anderen Hardwarekomponenten beschrieben. Wichtig dabei sind die Anforderungen, die sich aus den Schnittstellen der einzelnen zu entwickelnden Hardwarekomponenten ergeben. Die einzelnen Schnittstellen müssen detailliert beschrieben sein, damit vorher definierte Systemtests die gewünschten Funktionalitäten sicherstellen.

5.3.11 SW-Entwicklung Je nach Detaillierungsgrad, welcher beim V-Modell durch das Tailoring festgelegt wird, ist im Vorgehensbaustein SW-Entwicklung geregelt, wie die SW-Entwicklung durchgeführt werden soll. Nachdem eine generelle SW-Architektur das gesamte System in einzelne SW-Einheiten, deren Komponenten und Module sowie deren Schnittstellen untergliedert, wird jeweils für jede als notwendig erachtete SW-Komponente eine genaue SW-Spezifikation definiert. Manchmal ist es erforderlich, die Realisierbarkeit einzelner SWKomponenten zu untersuchen. Für SW-Einheiten, die eine Datenbank nutzen, müssen eine Schemadefinition sowie eine Beschreibung der notwendigen Datenbankprozeduren sowie Indizes in eine DBMS umgesetzt werden. Bei größeren SW-Systemen müssen die System-Integration, die Prüfung einzelner SW-Einheiten sowie, falls nötig, die Tuningmaßnahmen beschrieben werden Je nach Größe des zu erstellenden SWProjektes muss neben einem Anwendungs- und Betriebshandbuch auch ein Diagnosehandbuch geschrieben werden. Bei kleineren Softwareprojekten erfolgt nach Fertigstellung des Grobentwurfs ein Feinentwurf, der die detaillierte Beschreibung des Projektes im softwaretechnischen Sinne fortsetzt und in der Realisierung mündet. Eventuelle Schnittstellen zu anderen Systemkomponenten sowie deren Integration sind dabei dediziert zu beschreiben. Mit der Realisierung zusammen wird dem Kunden ein SW-Prüfkonzept sowie Betriebshandbuch ausgeliefert.

108

■ ■ ■


Abb. 5.30: V-Modell-SEProzess


■ ■ ■

109

5.3.12 Logistikkonzeption Bei größeren IT- oder DV-Verfahren sind logistische Unterstützung wie z. B. Pflegemaßnahmen zum Erhalt der weiteren Betriebsbereitschaft unumgänglich. Damit beschäftigt sich der Vorgehensbaustein Logistikkonzeption innerhalb des V-Modells-XT. Er beschreibt, welche Aktionen notwendig sind, um eine hohe Verfügbarkeit sicherzustellen, und wie die Betriebskosten über die Nutzungsdauer (Inbetriebnahme, Nutzung, Instandhaltung und -setzung sowie Aussonderung) möglichst gering gehalten werden können. Darin enthalten sind Vorschläge für eine Ersatzteilbevorratung und empfohlene Schulungsmaßnahmen für das zur Pflege des DV-Systems vorgesehene Personal. Vorschläge, wie Ausfallzeiten minimiert werden können, Lösungsvorschläge für zu erwartende Fehlerzustände, Empfehlungen von Prüfprogrammen sowie empfohlene Wartungs- und Pflegemaßnahmen runden das Bild ab.

5.3.13 Evaluierung von Fertigprodukten Da die Entwicklungskosten für ein neues DV-System immer sehr hoch sind, ist es legitim, sich vorher Gedanken zu machen, ob Teile des DV-Systems nicht mit Fertigprodukten zu realisieren sind, die nur angepasst werden müssen. So ist es einsichtig, wenn man eine Relationale Datenbank auf dem Markt kauft und nicht selbst entwickelt. Das gleiche gilt für Betriebsystemkomponenten oder Serverhardware. Der Vorgehensbaustein „Evaluierung von Fertigprodukten“ innerhalb des V-Modells-XT beschäftigt sich mit der Frage, inwieweit Fertigprodukte eingesetzt werden können, um die entstehenden Kosten, die sich aus der Erstellung eines neuen DV-Systems ergeben, zu reduzieren. Dabei muss bedacht werden, dass Fertigprodukte spezifisch angepasst werden müssen, um die gewünschten Funktionalitäten zu erhalten. Diese Anpassungskosten sind zu bewerten und in einer „Make-or-Buy-Entscheidung“ den Kosten einer Neuentwicklung gegenüberzustellen. Innerhalb der Systemarchitekturphase eines neuen DV-Systems muss eine Marktsichtung ergeben, welche Fertigprodukte sich zur Teilrealisierung spezieller Funktionen des neuen DV-Systems eignen. Eine Abwägung zwischen Kosten und Nutzen schließt sich daran an, um frühzeitig geeignete Fertigprodukte zu beschaffen. Auch ist zu spezifizieren, welche spezifischen Unterstützungssysteme zum Betrieb dieser Fertigprodukte notwendig sind.

110

■ ■ ■


5.3.14 Benutzbarkeit und Ergonomie Bei der Anforderungsanalyse bzw. beim Systementwurf eines neuen DV-Systems ist die einfache Bedienbarkeit eine Frage der späteren Akzeptanz. Die einfache Bedienbarkeit ist abhängig davon, wie die jeweilige Mensch-Maschine-Schnittstelle ausgeprägt ist. Bei Computerprogrammen ist dies stets ein Graphisches User Interface (GUI), mit dem ein vorher definierter effizienter Arbeitsablauf (Workflow) abgebildet werden kann. Aber auch entwickelte Hardwarekomponenten müssen z. B. im Fehlerfall eine einfache Signalisierung ermöglichen, die das Bedienpersonal in die Lage versetzt, eine schnelle Fehlerbeseitigung vorzunehmen. Das V-Modell-XT nimmt sich innerhalb des Vorgehensbausteins „Benutzbarkeit und Ergonomie“ dieser Frage an.

5.3.15 Systemsicherheit Verschiedene DV-Systeme werden in Bereichen eingesetzt, die bei Ausfall zu Gefährdungen des Bedienpersonals oder zu Schäden (Leben, Gesundheit, Vermögen) im eingesetzten Bereich, wie z. B. in der Medizin, bei Sicherheitsorganen oder Überwachungseinrichtungen (Flugsicherung), führen. Ist das neue DV-System ein sicherheitskritisches System, so sorgt der Vorgehensbaustein „Systemsicherheit“ für eine ganzheitliche Betrachtung von System und Systemumgebung. Neben besonderer Auswahl der Systemkomponenten werden auch erhöhte Ansprüche an die entsprechenden Prüfungen des neuen DV-Systems gestellt. Eine vorangegangene Klassifizierung definiert, welche Maßnahmen zu einer Risikominimierung eingesetzt werden können.

5.3.16 Weiterentwicklung und Migration von Altsystemen Im öffentlichen Bereich sind DV-Systeme meist nach fünf Jahren abgeschrieben und auch durch den technologischen Fortschritt meist nicht mehr leistungsfähig genug und im Hinblick auf die Wartungskosten zu teuer. Des Öfteren versucht man, existierende Applikationsprogramme auf neue Server und Storagesysteme zu portieren bzw. auf Neusysteme zu migrieren.


■ ■ ■

111

Auch wird im Laufe der Nutzungsdauer der Anwender weitere Wünsche oder Anforderungen an das existierende DV-System entwickeln, die dann zu gegebener Zeit eine umfangreiche Weiterentwicklung notwendig machen. Diese neuen Anforderungen münden dann in einem Migrationskonzept, welches die Weiterentwicklung des Altsystems beschreibt. Bei der Entscheidung hin zu einem neuen System wird meist dann auch ein Konzept zur Übernahme der Altdaten enthalten sein. All diese Aspekte werden im Vorgehensbaustein „Weiterentwicklung und Migration von Altsystemen“ des V-Modells-XT behandelt.

5.3.17 Einführung und Pflege eines organisationsspezifischen Vorgehensmodells Innerhalb des V-Modells-XT, Vorgehensbaustein „Einführung und Pflege eines organisationsspezifischen Vorgehensmodells“, wird die Frage behandelt, wie ein Vorgehensmodell in eine bestehende Organisation eingeführt werden kann bzw. eingesetzte Prozesse innerhalb einer Organisation verbessert werden können. Grundlage für den kontinuierlichen Verbesserungsprozess ist das V-Modell mit all seinen Teilprozessen, Produkten und Aktivitäten. Die Bewertung existierender Prozesse kann z. B. auf der Basis von CMMI (Capability Maturity Model Integration) oder des SPICE-Modells (ISO/IEC 15504) vorgenommen werden.

112

■ ■ ■


6 PRINCE 2

Da heute kein Geschäftsprozess ohne eine IT-Unterstützung auskommt, müssen Geschäfts- und IT-Strategien miteinander verbunden werden. Dies ist gerade deswegen so wichtig, weil Wettbewerbs- und Ertragsfähigkeit eines Unternehmens in erhöhtem Maße vom IT-Management abhängen. Die Umsetzung der zukünftigen Unternehmensstrategie führt in allen Aufgabenbereichen einer Firma zu einer Vielzahl von Projekten. Diese müssen neben dem normalen produktiven Tagesgeschehen umgesetzt werden. Das Programm-Management (programme management) einer Firma ist für das erfolgreiche Steuern von vernetzten Projekten innerhalb einer Firma verantwortlich. Dafür ist es erforderlich, eine interne und externe Ressourcenplanung bei der Abwicklung von mehreren Projekten durchzuführen. Hierbei ist es notwendig, Prioritäten zu setzen und durchzusetzen. Neben dem Finanzchef (Chief Financial Officer, CFO) und dem Personalchef (Human Resources Officer, CHRO) hat sich deshalb Abb. 6.1: Das PRINCE Prozessmodell

6 PRINCE 2

■ ■ ■

113

Abb. 6.2: PRINCE 2 als Black-Box

PRINCE2 Prozesse, Rollen, Aktivitäten

der Vertreter des Produktionsfaktors Informationstechnologie (Chief Information Officer, CIO) im Top-Management einer Firma verankert. Das Programm-Management einer Firma ist eng mit der Firmenleitung (corporate management) verbunden. Es liegt auf der Hand, dass komplexe Projekte leicht scheitern können; deswegen ist die Nachfrage von standardisierten Projektmanagement-Methoden von der Praxis für die Praxis relativ hoch. Die Projektmanagementmethode PRINCE, die mittlerweile in der Version 2 vorliegt, wurde 1989 von der CCTA (Central Computer and Telecommunications Agency) eingeführt. Sie basiert auf einer Projektmanagement-Methode mit dem Namen PROMPT der Firma Simpact Systems Ltd. aus dem Jahre 1975. Die CCTA (www.ccta.gov.co.uk) ist eine Dienstleistungsorganisation der britischen Regierung, die die Aufgabe hat, die öffentlichen Dienstleistungen der britischen Regierung durch eine Nutzung der IT-Technologie zu verbessern. PRINCE steht für „PRojects IN Controlled Environments“ und ist eine Projektmanagement-Methode bzw. ein Projektmanagementprozess mit 8 Hauptprozessen, die Bezug nehmen auf die einzelnen Phasen eines durchzuführenden Projektes. Grundsätzlich geht PRINCE davon aus, dass ein erfolgreiches Projektmanagement aus den drei Komponenten Organisation, Planung und Projekt-Controlling besteht. Hinzu kommt, dass es bestimmte Rollen definiert, die je nach Prozess verantwortlich für die Durchführung sind. Projektarbeit basiert darauf, dass die wesentlichen Rahmenparameter, Risiken und Anforderungen bekannt sind. Mittels PRINCE werden Dokumente beschrieben, die je nach Projektprozess diese erforderlichen Daten enthalten sollen. Vorteil dieser Dokumente von PRINCE 2 ist, dass damit eine geschäftliche Rechtfertigung (für die eine oder andere Entscheidung) möglich ist und im Nachhinein festgestellt werden kann, wo es „geklemmt“ hat und wer dafür verantwortlich ist; und dass es einen vorher festgelegten Ablauf gibt, um solche Probleme möglichst schnell zu identifizieren

114

■ ■ ■

6 PRINCE 2

und damit umzugehen, ohne den Problemen als solchen ausgeliefert zu sein. In PRINCE 2 findet man das Prinzip „Management by Exception“; das heißt, dass das Management stets über den Projektstatus informiert wird, aber nur bei wichtigen Entscheidungen bzw. großen Planabweichungen des Projektes oder einer Projektphase eine Sitzung des Lenkungsausschusses stattfindet. Für die Planabweichungen werden obere Toleranzwerte vereinbart. Innerhalb dieser Planabweichungen kann der Projektleiter das Projekt nach seinen Vorstellungen steuern. PRINCE 2 basiert auf einzelnen Prozessen, Rollen und zugrunde liegenden Aktivitäten, um ein erfolgreiches Projektmanagement durchzuführen. Das Projektmanagement-Framework PRINCE 2 hat nach meiner Meinung den Vorteil, dass es allgemein beschreibt, wie ein Projekt organisiert werden sollte. Wie beim erfolgreichen IT-Servicemanagement–Framework ITIL bleibt aber die Ausgestaltung der PRINCE 2-Prozesse der Firma oder öffentlichen Institution, die PRINCE 2 einsetzen möchte, vorbehalten. PRINCE 2 besteht aus 8 Hauptprozessen, die aus einer Anzahl von Unterprozessen bestehen. Jeder der 8 Hauptprozesse ist unterteilt in Subprozesse, die in Tabelle 6.1 aufgelistet sind. Subprozesse Inhalt/Deutsch von PRINCE

Inhalt/Englisch

SU IP DP CS MP SB

Starting up a Project Initiating a Project Directing a Project Controlling a Stage Managing Product Delivery Managing Stage Boundaries

CP PL

Vorbereiten eines Projektes Initiieren eines Projektes Lenken eines Projektes Steuern einer Projektphase Managen der Produktlieferung Managen von Projektphasenübergängen Abschließen eines Projektes Planen

Tabelle 6.1: Überblick über die Hauptprozesse von PRINCE 2

Closing a Project Planning

Ein wesentlicher Vorteil von PRINCE ist meines Erachtens, dass das Programm-Management einer Firma gezwungen ist, projektspezifische Toleranzen vorzugeben, innerhalb derer ein Projektleiter entscheiden darf, welche Maßnahmen er bezüglich des Projekts für angebracht hält (management by exception). Da Toleranzwerte vorgegeben sind, entfällt die Diskussion, warum ein Projektleiter nicht frühzeitig über bestehende Risiken informierte. Sind die Toleranzwerte erreicht, liegen die Fakten frühzeitig auf dem Tisch und das Projekt kann aus einer bestehenden Sackgasse herausgeführt werden, bevor zu viele Ressourcen verbraucht wurden und das Projekt

6.1 Rollen unter PRINCE 2

■ ■ ■

115

Abb. 6.3: Die Drei-Parteien-Partnerschaft [29]

nur noch zwangsweise beendet werden kann, weil keine Handlungsmasse mehr vorhanden ist. Eventuell wird dadurch auch sichergestellt, dass die Kommunikation einen definierten Verlauf nimmt, indem alle Entscheidungsträger frühzeitig benannt wurden. Wie bei allen Vorgehensmodellen wird auch unter PRINCE 2 unterschieden, ob es sich um zu entwickelnde projektspezifische Erzeugnisse (business products) oder um Managementprodukte (management products) handelt. Die Managementprodukte sollen dafür Sorge tragen, dass alle notwendigen Informationen und Aktivitäten erfasst sind, um das zu erzeugende Projektendprodukt mit hoher Wahrscheinlichkeit auch zu erhalten. PRINCE 2 beschreibt die beteiligten Personen bzw. deren Rollen innerhalb eines Projektes genau. Des Weiteren sind bestimmte Ausgangsprodukte, die sich aus dem Projektmanagementprozess ergeben, wichtig. Deshalb wollen wir uns zuerst den definierten Rollen innerhalb der Projektmanagementmethode PRINCE und ihren Ausgangsprodukten widmen, bevor wir auf die einzelnen Prozesse von PRINCE eingehen.

6.1 Rollen unter PRINCE 2 Innerhalb der Projektmanagementmethode PRINCE 2 legt der Kunde (Customer) die Anforderung zur Realisierung eines Produktes fest, welches unter Zuhilfenahme eines Projektes realisiert wird. Der

116

■ ■ ■

6 PRINCE 2

Abb. 6.4: Rollen unter PRINCE

Dienstleister (supplier) hat die Aufgabe, das Projekt nach den Wünschen des Kunden durchzuführen. Innerhalb von PRINCE gibt es bestimmte Rollen, die von wesentlicher Bedeutung für die Umsetzung der einzelnen Subprozesse sind. Deswegen wollen wir uns diesen Rollen und ihrer Position innerhalb einer Firma näher widmen. Da gibt es die Rolle des „Project Executive“ (Vorsitzender des Lenkungsausschusses), der den Kunden repräsentiert. Innerhalb des Lenkungsausschusses (project board) sitzen Repräsentanten des Kunden (senior user und executive) und des Dienstleisters (senior supplier) mit weitreichenden organisatorischen Entscheidungsbefugnissen. Der Vorsitzende des Lenkungsausschusses („Executive“) repräsentiert den Kunden bzw. die Kundenforderung nach einem Produkt innerhalb der Management- oder Geschäftsleitungsebene. Er ist verantwortlich dafür, dass für die eingesetzten finanziellen Mittel das Optimum eines Endproduktes mittels des Transformationsprozesses eines Projektes erhalten wird. Früher wurde oft ein Lenkungsausschuss (project board) erst eingesetzt, wenn ein aktuelles Projekt zur Schieflage neigte und nach den Ursachen gesucht wurde, um anstehende Probleme in konzertiertem Einsatz zu lösen. Innerhalb der Projektmanagementmethode PRINCE wird dieser Lenkungsausschuss im Vorfeld eines Projektes zusammengestellt. Mitglieder des Lenkungsausschusses (project board) differieren je nachdem, ob Kunde und Dienstleister aus einer oder zwei verschiedenen Firmen kommen. Besteht der Lenkungsausschuss


■ ■ ■

117

aus Repräsentanten ein und derselben Firma, so wird es eine Produktionsabteilung geben, für die es gilt, ein Produkt (z. B. ein neues DVVerfahren) zu entwickeln und einzuführen, sowie eine inoder externe Entwicklungsabteilung, die das entsprechende Projekt durchführt. Daneben wird dem Lenkungsausschuss sicherlich der DV-Koordinator, der IT-Sicherheitsbeauftragte, der Kundenvertriebsbeauftragte, ein Repräsentant des zentralen Einkaufs, der Finanzabteilung und der Geschäftsleitung sowie ein fachlicher und organisatorischer Mitarbeiter der IT-Dienstleistungsabteilung, die das DV-Verfahren während des späteren Regelbetriebes betreuen soll, angehören. Der Executive (Projekt-Auftraggeber oder Vorsitzender des Lenkungsausschusses) ist ein von der Geschäftsleitung oder dem Programm-Management einer Firma Berufener, der ein spezifisches Projekt vorantreiben soll. Grundsätzlich ist er derjenige, der dem Projekt generell eine Richtung gibt. Dafür braucht er weitreichende Befugnisse. Er hat die Aufgabe, finanzielle Mittel zur Durchführung des Projektes zu autorisieren, und ist Hauptverantwortlicher dafür, dass die Projektziele in betriebswirtschaftlichem Kontext zum Nutzen der Kundenseite durchgeführt werden. Er gibt innerhalb des Phasenplans (stage plan) die Grenzen (tolerance) vor, in welchen sich das Projekt bewegen darf (z. B. Kosten, Zeit), und welche qualitativen Erwartungen an den inoder externen Kunden in Bezug auf das Projekt gestellt werden. Die generelle Tagesarbeit überlässt der Executive dabei dem Projektleiter (Project Manager). Werden die zuvor definierten Grenzen einer Projektphase überschritten, so ist er zu informieren. Der Executive achtet auf den Stand der aufgelaufenen Kosten und des Projektfortschrittes sowie Veränderungen, die sich im Projektplan ergeben, und analysiert daraus, welche Auswirkungen dies auf den Geschäftsplan bzw. den „business case“ hat. Er überprüft den Projektabschlussbericht (end project report) sowie den Erfahrungsbericht (lessons learned report) nach Beendigung eines Projektes und leitet den Lenkungsausschuss eines Projektes. Er informiert das Programm-Management sowie die Geschäftsleitung über den Stand und eventuelle Probleme eines Projektes. Der Hauptnutzer (senior user) ist verantwortlich für die genaue Spezifizierung des Endproduktes, sowie dessen Qualität und führt die Endabnahme durch. Er ist für diese Rolle vorgesehen, weil er bzw. seine Kollegen nach Umsetzung des Projektes mit dem Endprodukt arbeiten sollen. Er muss somit immer wieder den Blick auf die eigentlichen Grundbedürfnisse des Endproduktes lenken. Weiterhin ist er dafür verantwortlich, dass Forderungen nach Information oder anderweitigen Ressourcen des Dienstleisters nachgekommen wird. Er muss die Anforderungen an das Endprodukt mit einer Priorität versehen, in der diese Anforderungen vom Dienstleister umgesetzt werden

118

■ ■ ■

6 PRINCE 2

Abb. 6.5: Der Projektleiter sorgt für die ordnungsgemäße Durchführung der Projektanforderungen

sollen. Im Falle von außergewöhnlichen Schwierigkeiten muss er mit gezielten Vorschlägen den Dienstleister unterstützen. Er gibt im Rahmen seiner Tätigkeit Informationen über die Handhabbarkeit des Endproduktes an spätere Nutzergruppen sowie an das Management seiner Firma. Oft ist es auch so, dass die Rolle des Hauptnutzers von verschiedenen Personen (z. B. DV-Koordinator, IT-Sicherheitsbeauftragter, Team-, Abteilungsleiter und Wissensträger) ausgefüllt wird, die je nach ihren Erfahrungen und Entscheidungsbefugnissen Kundenpositionen beim Dienstleister vertreten. Den Gegenpart des Hauptnutzers nimmt der Hauptlieferant (senior supplier) wahr. Er ist für die Erstellung des Endproduktes nach den Angaben des Kunden innerhalb vorgegebener finanzieller und zeitlicher Rahmenbedingungen verantwortlich. Weiterhin überprüft er die vom Kunden gestellten Anforderungen an das Endprodukt auf Stimmigkeit, realistischen Bezug und eventuell damit verbundene Risiken für den Kunden und für die Firma des Dienstleisters. Eventuell muss er den Lenkungsausschuss auf Unstimmigkeiten hinweisen und Alternativen aufzeigen. Er ist dafür verantwortlich, das gewünschte Endprodukt zu designen, erforderliche Entwicklungsarbeiten durchzuführen bzw. von seinem Team durchführen zu lassen und es später beim Kunden zu implementieren. Dafür ist es auch erforderlich, dass er die entsprechend notwendigen Spezialisten auswählt und technische Standards vorgibt. Er muss dafür Sorge tragen, dass die benötigten Ressourcen infrastruktureller (Räume, Netzwerkverbindungen, Entwicklungswerkzeuge) oder personeller Natur (Mitarbeiter) zu dem Zeitpunkt zur Verfügung stehen, an dem sie gebraucht werden. Qualitätstests müssen von ihm durchgeführt werden, um zu gewährleisten, dass der Kunde das Endprodukt erhält, das er auch haben wollte. Er informiert das Management seiner Firma über alle wesentlichen Aspekte des Projektes.


■ ■ ■

119

PR

Abb. 6.6: Der Inhalt entscheidet

IN C E2

Der Project Manager (Projektleiter) wird vom Lenkungsausschuss ernannt. Denkbar sind Fälle, in denen der Kunde und der Dienstleister Teil ein und derselben Firma sind oder aber der Kunde und der Dienstleister unterschiedlichen Firmen angehören. Je nachdem wird der Projektleiter entweder vom Kunden oder vom Dienstleister gestellt. Seine Aufgaben umfassen alle Tätigkeiten, die notwendig sind, um den Erfolg des Projektes innerhalb der Grenzen, die der freigegebene Phasenplan des Kunden vorsieht, zu garantieren. Er muss nicht unbedingt einen technischen Background haben. Es ist ausreichend, analytisch organisatorische Fähigkeiten zu besitzen. Der Projektleiter entscheidet über anstehende Alternativen in dem Rahmen, der ihm vom Lenkungsausschuss vorgegeben wird und weist an bzw. motiviert in schwierigen Situationen die mit der Umsetzung des Projektes betrauten Mitarbeiter. Er plant und prüft Risiken des Projektes und steht für die erforderliche Qualität des Endproduktes gerade. Innerhalb der Projektmanagement-Methode PRINCE ist er unter anderem für die Erstellung der folgenden Dokumente verantwortlich: x Project Initialisation Document x Stage Plan x Exception Plan x Risk Log x Projektqualitätslogbuch (Quality Log) x Lessons Learned Report x Follow on Action Recommendations x End Project Report Oft sind mehrere Teams mit der Entwicklung verschiedener Komponenten betraut, deren Leitung von einem Gruppenleiter (TeamManager) übernommen wird. Der Team-Manager informiert dann

120

■ ■ ■

6 PRINCE 2

den Projektleiter über alle wichtigen Dinge des Entwicklungsprozesses und kümmert sich um die Belange der Team-Mitglieder.

6.2 Erzeugnisse unter PRINCE Der englische Begriff „Business Case“ beschreibt ein Dokument, das die Gründe zur Durchführung bzw. Weiterführung eines Projektes beinhaltet. Ein Business Case ist ein Szenario zur betriebswirtschaftlichen Beurteilung einer Investition, z. B. die Durchführung eines Projektes. Innerhalb des Dokumentes werden Annahmen getroffen über die entstehenden Kosten und die mit den Ergebnissen des Projektes zu erzielenden Gewinne. Es wird auch analysiert, welche Auswirkungen es für eine Firma hat, wenn das Projekt nicht durchgeführt wird. Man kann sagen, dass das Business Case die geschäftliche Rechtfertigung für ein Projekt ist. Es wird stets auf dem neusten Stand gehalten. Das „Project Mandat“ (Projektauftrag) umfasst neben der Beschreibung des Projektes den Projekthintergrund und die wesentlichen damit zu erreichenden Ziele. Ferner sind die Gründe zu nennen, warum das Projekt durchgeführt werden soll, und welche Rahmenbedingungen oder andere Anforderungen einzuhalten sind. Es beschreibt, in welchem Umfang und Rahmen das Projekt sich entfalten kann (z. B. Dauer, Kosten) und listet Referenzdokumente auf, die weitere Informationen enthalten. Es enthält Angaben darüber, wer zum Vorsitzenden des Lenkungsausschusses (executive) und wer zum Projektleiter (project manager) bei diesem Projekt ernannt wurde. Weiterhin sind Kunden, Nutzer oder andere wesentliche Schlüsselpersonen, die mit dem Projekt im Zusammenhang stehen, verzeichnet. Beim „Project Brief“ (Projektentwurf, Projektkurzbeschreibung) handelt es sich um ein Dokument, in dem eine Beschreibung des Projektes und der Aufgabenstellung gegeben sowie der geschäftliche Hintergrund und die betriebswirtschaftliche Beurteilung einer Investition, wie z. B. die Durchführung eines Projektes, erläutert wird. Er enthält Angaben über Grenzen, in denen sich das Projekt bewegen darf (Kosten, Zeit) und über qualitative Erwartungen des inoder externen Kunden in Bezug auf das Projekt. Werden die Grenzen überschritten, so ist damit eine Benachrichtigung der übergeordneten Entscheidungsebene verbunden. Der „Project-Brief“ enthält weiterhin eine Auflistung bekannter Risiken und Abnahmekriterien des Projektes. Die Abnahmekriterien beschreiben, welche Anforderungen das Projektendprodukt erfüllen soll.

6.2 Erzeugnisse unter PRINCE

■ ■ ■

121

Abb. 6.7: PRINCE Managementprodukte

122

■ ■ ■

6 PRINCE 2

Das „Risk Log“ (Risikoprotokoll) umfasst eine Liste und Beschreibung von bekannten Risiken mit einer geschätzten Wahrscheinlichkeit ihres Auftretens und dem daraus zu erwartenden Schaden. Weiterhin sollten zu den Risiken entsprechende Gegenmaßnahmen aufgelistet werden, die in einem solchen Fall ergriffen werden sollten. Das „Risk Log“ wird während der Anfangsphase eines Projektes erstellt und während der Projektlaufzeit ständig auf den neuesten Stand gebracht. Innerhalb des Projektlösungsansatzes (project approach) wird der Lösungsansatz beschrieben, mit dem die Ziele des Projektes erreicht werden können. Auch eine entsprechende Lösungsmethode bzw. zugrunde liegende Technologie oder ein Softwarestandard, der genutzt werden soll, um die Ziele zu erreichen, ist Bestandteil des „Projekt Approach“. Daneben werden die Gründe aufgeführt, warum das Projekt gerade auf diesem Weg realisiert wird. Innerhalb des „Acceptance Criteria“-Dokuments werden Abnahmebedingungen für das Endprodukt des durchzuführenden Projektes aufgelistet. Beispiele dafür sind z. B. die Auflistung von Funktionen und die Erscheinungsform des GUI (Graphic User Interface) einer Softwareapplikation. Aber auch Antwortzeitverhalten, Verfügbarkeit, Entwicklungskosten, Einfachheit der Bedienung, Betriebskosten (running cost) des Endproduktes, Fertigungstoleranzen bzw. einzuhaltende Qualitätsnormen oder einfach das Fertigungs- oder Erstellungsenddatum können Abnahmebedingungen sein. Die Abnahmebedingungen fließen ein in das „Project Initiation Document“ (PID). Das „Project Initiation Document“ (PID) umfasst alle wesentlichen Daten eines zu startenden Projektes. Es enthält Angaben zum Hintergrund des Projektes sowie Ziele, die mit dem Projekt verbunden sind (business case), und warum es wichtig ist, diese Ziele (Firmenstrategie) zu erreichen. Weiterhin wird aufgezeigt, welche Person oder Organisationseinheiten dem Projekt zugeordnet sind und welche Aufgaben und Verantwortungsbereiche von ihnen wahrgenommen werden. Es enthält genaue Angaben darüber, wie das Projektziel erreicht werden kann und wann das Projekt als Ganzes abgeschlossen sein soll. Enthalten sind Randparameter, eventuelle Schnittstellen zu anderen Projekten oder technischen Systemen. Auch die Abgrenzung des Projektauftrags, also was bzw. was nicht innerhalb des Projektes bewerkstelligt wird, ist im „Project Initiation Document“ enthalten. Wichtig sind auch Annahmen, auf denen das Projekt basiert, z. B. dass bestimmte Genehmigungen, Förderbeiträge, Räumlichkeiten, Serversysteme zu einer bestimmten Zeit erhalten werden können. Es muss klar daraus hervorgehen, wie das Projekt kontrolliert und überprüft werden kann. Ein Projektorganisationsplan, „Communication Plan“ (Kommunikationsplan), „Risk


■ ■ ■

123

Abb. 6.8: Änderungen der Spezifikationen führen zu Änderungen von Rahmenbedingungen

Kunde

Kosten, Zeit, Risiken

Veränderung

Vorteile, Kostenersparnis

Log“ (Risikoprotokoll), „Project Plan“ (Projektplan) „Contingency Plan“ (Alternativplan) sowie „Project Quality Plan“ (Qualitätsplan) sind wesentliche Bestandteile des „Project Initiation Document“ (PID). Das „Project Initiation Document“ (Projektleitdokument) soll alle Informationen zu den Schlüsselfragen (warum, was, wer und wann) eines Projektes enthalten. Es dient somit als Grundlage für die Genehmigung (project approval) eines Projektes. Der „Quality Plan“ (Qualitätsplan) regelt, welche die qualitätssichernden Maßnahmen und Qualität überprüfenden Verfahren innerhalb einer Projektphase von welcher Organisationseinheit oder welchem Projektmitglied durchgeführt werden sollen, um die angestrebte Qualität sicherzustellen. Im „Quality Log“ (Projektqualitätslogbuch) ist jedes Teilprodukt beschrieben, welches mittels des durchzuführenden Projektes fertig gestellt werden soll. Weiterhin enthält es die entsprechenden qualitätssichernden Verfahren, die die qualitativen Anforderungen an dieses Teilprodukt sicherstellen, sowie die Mitarbeiter, die diese Tests durchführen sollen. Auch ist ein Zeitplan enthalten, in dem die einzelnen qualitätssichernden Verfahren durchgeführt werden. Wurden einzelne Tests durchgeführt, so sind die Ergebnisse innerhalb des „Quality Log“ (Projektqualitätsplan) niederzuschreiben. Sind die Ergebnisse mangelhaft, so sind entsprechende Korrekturmaßnahmen notwendig, bis das entsprechende qualitätssichernde Verfahren erneut durchgeführt werden kann. Der „Communication Plan“ (Kommunikationsplan) beinhaltet alle wesentlichen Details darüber, welche Organisationseinheiten in welcher Form und in welchen Abständen miteinander Informationen über ein Projekt austauschen bzw. informiert werden müssen. Dabei kann

124

■ ■ ■

6 PRINCE 2

Abb. 6.9: Die Einteilung des Projektes unter PRINCE 2 in Projektphasen

der Informationsbedarf (technisch, finanziell) je nach Interessengruppe unterschiedlich sein. Der Kommunikationsplan ist Teil des Projektleitdokuments (Project Initiation Document; PID). Der „Stage Plan“ (Projektphasen-Plan) enthält neben einer generellen Beschreibung der Projektphase genügend Informationen über notwendige Aktivitäten, Ressourcenerfordernisse und geplante Endzeitpunkte einer Projektphase. Er enthält alle äußeren Abhängigkeiten, die in dieser Projektphase existieren können. Der „Stage Plan“ ermöglicht dem Projektleiter eine Steuerung des Projektes auf Tagesbasis und beschreibt auch, wie und mit welchen Mitteln die Projektphase kontrolliert und überwacht wird. Auch, wer über bestimmte Dinge in welcher Art und Weise informiert werden soll, ist dort beschrieben. Bestandteil des „Stage Plans“ ist ein „Quality Plan“ (Qualitätsplan), in dem geregelt ist, welche qualitätssichernde Maßnahmen und Qualität überprüfenden Verfahren innerhalb einer Projektphase von welcher Organisationseinheit oder welchem Projektmitglied durchgeführt werden sollen. Als Anhang ist der vorgesehene Projektplan beigefügt, aus dem hervorgeht, wann, was, von wem zu tun ist. Der Lenkungsausschuss genehmigt jeweils die Ausführung einer weiteren Projektphase.

Projektende stage 6 stage 5 stage 4 stage 3 stage 2 stage 1 stage 0

Abb. 6.10: Unterteilung eines PRINCEProjektes in eine Anzahl von „stages“ (Phasen)

Projektanfang


■ ■ ■

125

Abb. 6.11: Projektphasen und zugeordnete PRINCE 2Prozesse

126

■ ■ ■

6 PRINCE 2

Im „Contingency Plan“ (Alternativplan) sind die zu treffenden Entscheidungen und Maßnahmen enthalten, die unter bestimmten Umständen, die außerhalb des Einflussbereiches des Projektes liegen, ergriffen werden können. Man könnte auch sagen, dass der „Contingency Plan“ eine Sammlung von wesentlichen Plan-B-Vorgängen innerhalb eines Projektes darstellt. Innerhalb einer „Request for Change“ (Änderungsanforderung) wird eine Änderung der gegenwärtigen Produktbeschreibung geschildert. Weiterhin findet man dort eine so genannte „impact“ (Auswirkungen)-Analyse, in der abgeschätzt wird, welche zeitlichen, finanziellen und Ressourcenbedarfs-Änderungen dadurch hervorgerufen werden. Auch werden die Folgen beschrieben, die eintreten, wenn die entsprechende Änderung nicht vorgenommen wird. Der „End Project Report“ (Projektabschlussbericht) wird vom Projektleiter dem Lenkungsausschuss zur Verfügung gestellt. Er bestätigt die Übergabe des aus dem Projekt hervorgehenden Endproduktes an den Kunden. Inhalt des Projektabschlussberichtes ist ein aktualisierter „Business Case“ sowie eine Bewertung des Projektes und der damit zusammenhängenden Randparameter. Der „Lessons Learned Report“ (Erfahrungsbericht) wird nach der Beendigung eines Projektes verfasst und enthält Erfahrungswerte, die sich aus der Durchführung des Projektes ergeben haben. Der Erfahrungsbericht wird vom Lenkungsausschuss genehmigt und dann innerhalb einer Wissensdatenbank anderen bzw. zukünftigen Projekten zur Verfügung gestellt. Das Dokument „Follow on Action Recommendations“ (Empfehlungen für Folgeaktionen) wird vom Projektleiter verfasst, indem er Lösungsvorschläge zu Problemen (issues) beschreibt, die auch für später durchzuführende Projekte nützlich sein könnten. Oft wird solch ein Dokument auch erstellt, um notwendige Aktionen zu beschreiben, die sich aus Problemen eines Projektes oder des daraus entstehenden Endproduktes ergeben. Es umfasst aber nicht nur technische, sondern auch verfahrenstechnische Vorschläge, die die Durchführung eines Projektes betreffen.

6.3 Die Prozesse von PRINCE im Überblick 6.3.1 SU (Vorbereiten eines Projektes) Der PRINCE-Prozess-SU (Vorbereiten eines Projektes) sorgt dafür, dass alle grundlegenden Informationen zu einer grundsätzlichen

6.3 Die Prozesse von PRINCE im Überblick

■ ■ ■

127

Abb. 6.12: Der PRINCE 2SU-Prozess im Überblick SU (Vorbereiten SU (Vorbereiten eines Projektes)

SU 1 (ProjektauftragSU 1 geber und Projekt(Projektauftraggeber leiter ernennen) und Projektleiter

SU 3 (Ernennen SU 3 des Projektleitungsteams )

(Ernennen des Projektleitungsteams )

SU 2 SU 2eines (Entwerfen Projektleitungs(Entwerfen eines Projektleitungsteams) teams)

PRINCE 2

PRINCE 2

eines Projektes)

ernennen)

SU 4 SU 4 (Vorbereiten des Projektentwurfes) (Vorbereiten des Projektentwurfes)

SU 6 SU 6 (Planen der (Planen der InitialisierungsInitialisierungsphase ) phase)

SU 5 SU 5 eines (Definieren Projektlösungs(Definieren eines Projektlösungsansatz) ansatzes)

Sicherstellung aller Sicherstellung aller wesentlichen wesentlichen ProjektvorausProjektvoraussetzungen setzungen

Entscheidungsfindung, ob ein Projekt durchgeführt werden soll, vorhanden sind. Nachdem der SU-Prozess durchlaufen wurde und der Lenkungsausschuss grünes Licht zur Durchführung des Projektes gegeben hat, kann ein Projekt nun auf einer guten Basis starten. Im Einzelnen stellt der SU-Prozess sicher, dass alle wesentlichen Informationen, die zur Erstellung des Projektentwurfs (Project Brief) notwendig sind, verfügbar gemacht werden. Es wird ein auf das Projekt zugeschnittenes ProjektmanagementTeam zusammengestellt und ein einleitender Plan für die erste Projektphase (Initiation Stage Plan) entwickelt. Innerhalb der Interessengruppe, die ein bestimmtes Projekt vorantreiben möchte, wird ein Vorsitzender des Projekt-Lenkungsausschusses (Project Board Executive) sowie im Lenkungsausschuss ein Projektleiter (Project Manager) bestimmt, der ein Projekt vorantreiben soll. Dabei wird der Vorsitzende des Lenkungsausschusses zumeist vom inoder externen Kunden einer Firma und der Projektleiter vom inoder externen Dienstleister einer Firma gestellt. Die Verantwortungsbereiche und die intern notwendigen Kommunikationsstrukturen werden definiert und zugeordnet. Innerhalb des SU-Prozesses werden die Rahmenparameter und bekannten Risiken (Risk Log) des Projektes erfasst und zur weiteren Verwendung niedergeschrieben. Die geschäftsbasierenden Projektdaten sind im Business Case enthalten und fließen in den Projektentwurf (Project Brief) mit ein. Dann wird definiert, wie die gewünschten Projektziele erreicht werden sollen, ob z. B. eine

128

■ ■ ■

6 PRINCE 2

Neuentwicklung als notwendig erachtet wird oder ob ein bestehendes Produkt, das auf dem Markt angeboten wird, so weit angepasst werden kann, dass die festgelegten Ziele des Projektes damit erreicht werden können. Ist dies definiert, wird die einleitende Projektphase mit einem entsprechenden Projektphasenplan, der die durchzuführenden Tätigkeiten näher beschreibt, weiter spezifiziert. Der Lenkungsausschuss prüft den ihm vorgelegten einleitenden Projektphasenplan und genehmigt je nach Prüfungsergebnis die erste Projektphase.

6.3.2 DP (Lenken eines Projektes) Der DP-Prozess innerhalb von PRINCE nimmt den regulierenden, kontrollierenden Teil eines Projektes wahr. Er ist innerhalb des Lenkungsausschusses angesiedelt und genehmigt nach Antragstellung des Projektleiters Start, Ende und Projektphasenübergang. Der Projektleiter steht dem Lenkungsausschuss Rede und Antwort zu wesentlichen Projektfragen und zeigt bei auftretenden Schwierigkeiten alternative Phasenpläne auf, die vom Lenkungsausschuss genehmigt werden müssen. Da die meisten größeren Projekte nach Abschluss einer Phase auch entsprechende finanzielle Transaktionen zum Dienstleister umfassen, muss hier genau feststehen, wie die Kriterien auszusehen haben, die es erlauben, entsprechende Geldmittel freizugeben.

PRINCE 2

PRINCE 2

Abb. 6.13: Der PRINCE 2DP-Prozess im Überblick


■ ■ ■

129

Wenn abzusehen ist, dass bestimmte Toleranzgrenzen überschritten werden könnten, ist es besser, den Lenkungsausschuss vorab zu informieren. Sind Informationen von firmenrelevanter Bedeutung aufgetreten, so muss der Lenkungsausschuss und über diesen die Firmenleitung bzw. das Programm-Management einer Firma informiert werden. Der Lenkungsausschuss muss sicherstellen, dass er bei schwerwiegenden Risiken eines Projektes den Sachstand darüber in möglichst kurzen Zeitabständen erhält, um die Risiken unter Kontrolle zu halten. Dabei kann es notwendig sein, die Anforderungen an das Projekt zu verkleinern, den Projektleiter zu ersetzen oder aber das Projekt als Ganzes zu beenden. Während der Endphase des Projektes muss der Projektleiter darauf achten, dass der Nutzer bzw. Kunde das Endprodukt überprüft und formal abgenommen hat. Dabei kann es notwendig sein, weitere Zugeständnisse oder Änderungen am Endprodukt vorzunehmen. Diese werden dann innerhalb eines Dokumentes (Empfehlung für Folgeaktionen) erfasst und vom Lenkungsausschuss genehmigt. Der Lenkungsausschuss verfasst einen Projektabschlussbericht, den er der Firmenleitung bzw. dem Programm-Management einer Firma übermittelt und in dem er formell seine Auflösung bekannt gibt.

6.3.3 CS (Steuern einer Projektphase) Mit Hilfe des PRINCE-Prozesses CS werden alle kontrollierenden Subprozesse CS1 bis CS9 definiert, die dafür Sorge tragen, dass eine Projektphase erfolgreich bzw. mit den kleinstmöglichen Toleranzüberschreitungen durchgeführt wird. Angefangen bei der Genehmigung eines Projektarbeitspaketes bis zum Erfassen von gegenwärtigen Problemen gibt es Subprozesse, die darauf abzielen, alle wesentlichen Punkte einer Projektphase zu erfassen. Probleme können vielfältiger Natur sein: angefangen bei Fehleinschätzungen über den benötigten Ressourceneinsatz (personeller, finanzieller, technischer oder infrastruktureller Art) bis hin zu äußeren Einflüssen, die einem das Leben schwer machen. Ziel ist es, die Bedrohungen eines Projektes zunächst einmal zu erkennen, diese zu bewältigen und alle Beteiligten davon in Kenntnis zu setzen. Liegen Probleme vor, die eine Projektphase aus der zugebilligten Phasentoleranzgrenze bringt, so muss der Lenkungsausschuss informiert und um Zustimmung zu einem neuen Problembehebungskurs gebeten werden. Subprozesse, die den Projektleiter zwingen, sich über den realen Stand seiner Projektphase in Kenntnis zu setzen und Risikopotentiale im Vorfeld zu erfassen, sind ebenfalls ein Wirkungsfeld des CS-Prozesses. Unterschiedliche Vorgangsweisen

130

■ ■ ■

6 PRINCE 2

Abb. 6.14: Der PRINCE 2CS-Prozess im Überblick

sind abhängig davon, ob man mit entsprechenden Korrekturmaßnahmen noch innerhalb der Projekttoleranzgrenzen bleibt oder ob diese überschritten werden. Auch fällt in den PRINCE-Prozess CS ein Subprozess, der sich damit beschäftigt, wie zu einem bestimmten Zeitpunkt der Status einer Projektphase ermittelt wird. Der letzte Subprozess stellt sicher, dass mit dem Abschluss eines Arbeitspaketes auch wirklich das Enderzeugnis vorliegt, welches der Kunde vorher spezifiziert hat und einsetzen kann.

6.3.4 MP (Managen der Produktlieferung) Innerhalb dieses PRINCE-Prozesses MP werden alle Aspekte der Produktlieferung behandelt. Dies umfasst die Übergabe des Arbeitspaketes an ein Entwicklerteam, das Durchführen von Projektarbeitspaketen sowie die Übergabe eines geprüften Produktes oder Arbeitspaketes an den Projektleiter. Dabei ist es grundsätzlich egal, ob das Arbeitspaket von einer externen Firma (nicht unbedingt Projektmanagement nach PRINCE) oder intern durchgeführt wurde. Wichtig dabei ist es auch, so unbürokratisch wie möglich, aber kontrolliert vorzugehen. Hauptverantwortliche dieses PRINCE-Prozesses sind der Leiter des Entwicklerteams sowie der Projektleiter. Regelmäßige Statusberichte des Teamleiters halten den Projektleiter auf dem Laufenden.


■ ■ ■

131

PRINCE 2

MP (Managen der Produktlieferung )

MP1 (Annehmen eines Arbeitspaketes )

MP2 (Durchführen eines Arbeitspaketes )

PRINCE 2

Abb. 6.15: Der PRINCE 2MP-Prozess im Überblick

MP3 (Liefern eines Arbeitspaketes )

Sicherstellung des Endproduktes

6.3.5 PL (Planen) Das Endprodukt eines Projektes kann nur so gut sein wie seine Planung. Deshalb wird für jede Projektphase ein eigener Planungsprozess durchgeführt. In diesem werden anfänglich die benutzen Methoden und Tools festgelegt, die später zur Anwendung kommen. Danach werden die Anforderungen (technisch, qualitativ, anwenderbezogen) an das Endprodukt sowie die sich daraus ergebenden Teilprodukte vom Blickwinkel des Produktes her definiert. Dabei plant und definiert man im Einzelnen die Punkte Produkterstellung, Produktqualität und Produktverwendung, um am Ende das gewünschte Endprodukt zu erhalten. Ein Produktstrukturplan (product breakdown structure) erfasst alle Einzelprodukte in ihrer logischen Erstellungsreihenfolge, die als Ganzes das Endprodukt bilden. Nachdem das Produkt und die Teilprodukte, aus dem es besteht, definiert wurden, werden die Aktivitäten beschrieben, die notwendig sind, um das Produkt zu erzeugen. Auch daraus entstehende Abhängigkeiten sind zu betrachten. In einer weiteren Subprozessphase werden der Arbeitsaufwand abgeschätzt und die benötigten Ressourcen identifiziert, die erforderlich sind, um die definierten Aktivitäten umzusetzen. Nachdem dieser Schritt beendet wurde, beginnt nun das Planen der Aktivitäten und deren Zuordnung in zeitlicher Hinsicht. Dabei können Abhängigkeiten bestehen, die als risikobehaftet einzustufen sind. Alle Risiken, die in den vorherigen Planungsstufen aufgetreten

132

■ ■ ■

6 PRINCE 2

Abb. 6.16: Der PRINCE 2PL-Prozess im Überblick

sind, gilt es zu analysieren und mögliche Alternativwege und Problemlösungen zu finden. Nachdem dies getan ist, bleibt nur noch, den entsprechend bearbeiteten Projektphasenplan so zu vervollständigen, dass er leicht überschaubar die wichtigsten Daten in kürzester Zeit vermittelt, die den Lenkungsausschuss in die Lage versetzen, sich einen Überblick zu verschaffen, um ihn genehmigen zu können.

6.3.6 IP (Initiieren des Projektes) Der PRINCE-Prozess IP soll dafür Sorge tragen, dass das Fundament eines Projektes solide gelegt ist und alle wesentlichen Informationen vorliegen, damit der Projektstart vom Lenkungsausschuss formal ausgesprochen werden kann. Alle ermittelten Daten fließen innerhalb des Projektleitdokuments (Project Initiation Document; PID) zusammen. Anfänglich wird die Qualität des Endproduktes mit seinen Eigenschaften festgelegt und das Projekt nochmals auf eventuelle Risiken abgeklopft. Mit Hilfe von PL-Subprozessen wird ein Projektplan und das Abschätzen der dafür notwendigen Ressourcen durchgeführt. Ein besonderes Hauptaugenmerk liegt auf den Projektrisiken und Kommunikationsstrukturen sowie den Dokumentenablagestrukturen. Auch wird nochmals überprüft, ob die Projektziele, wie sie im Business Case niedergelegt sind, mit der Durchführung des Projektes erreicht werden können.


■ ■ ■

133

Abb. 6.17: Der PRINCE 2IP-Prozess im Überblick

6.3.7 SB (Managen von Projektphasenübergängen) Das Einteilen eines Projektes in verschiedene Projektphasen erlaubt es, an kontrollierten Zeitpunkten innerhalb eines Projektes festzustellen, ob alles in Ordnung ist oder ob es Bedarf für Korrekturmaßnahmen gibt. Der PRINCE-SB-Prozess behandelt alle Vorgänge, die mittels Einteilung eines Projektes in unterschiedliche Projektphasen verbunden sind. Neben dem formalistischen Planen einer Projektphase, in der die notwendigen Details und möglichen Probleme und Risiken einer Projektphase in einem Projektplan oder dem Risikoprotokoll (Risk Log) niedergelegt werden, ist es manchmal notwendig, den gegenwärtigen Projektplan auf den neuesten Stand zu bringen. Sei es, dass eine Überschreitung der Projektphasen-Toleranzwerte festgestellt wird oder dass sich einfach terminliche und organisatorische Änderungen ergeben. Damit einher geht das Prüfen und Updaten des bestehenden Business Case. Dies erfolgt nicht nur, wenn Probleme aufgetreten sind, sondern auch am Ende einer jeden Projektphase. Dasselbe muss mit dem existierenden Risikoprotokoll passieren, da oft Probleme und Risiken erst auftauchen, wenn man wirklich an der Realisierung von Erzeugnissen innerhalb einer Projektphase arbeitet. Daraus folgt ein auf den neuesten Stand gebrachtes Risikoprotokoll (Risk Log). Befindet man sich am Ende einer Projektetappe, so muss die nächste Projektphase geplant werden. Damit verbunden ist ein Report über die vergangene Projektphase und die daraus resultierenden

134

■ ■ ■

6 PRINCE 2

Abb. 6.18: Der PRINCE 2SB-Prozess im Überblick

Daten, wie aufgelaufene Kosten, erledigte Arbeitspakete und Fertigungsgrad in Bezug auf das Endprodukt sowie entstandene Projektrisiken. Dieser Report ist wesentlich für den inoder externen Kunden, den Lenkungsausschuss, die Firmenleitung und das ProgrammManagement einer Firma. Zum Managen von Projektphasenübergängen gehört auch das Erstellen eines Ausnahmeplans (Exception Plan) für den Fall, dass bei der Abschätzung von benötigtem Zeitbedarf und auflaufenden Kosten innerhalb einer Projektphase bemerkt wird, dass die vom Lenkungsausschuss vorgegebenen Projektphasentoleranzgrenzen überschritten werden. Innerhalb des Ausnahmeplans ist ein neuer Projektplan enthalten, der Auskunft darüber gibt, wie es mit dem Projekt weitergehen könnte.

6.3.8 CP (Abschließen eines Projektes) Dieser PRINCE-Prozess ist unterteilt in drei Subprozesse CP1 bis CP3 und sorgt dafür, dass alle wesentlichen Aktionen, die beim Beenden eines Projektes notwendig sind, auch durchgeführt werden. In diesem Zusammenhang muss geprüft werden, ob alle Produkte, die im Projektleitdokument (Project Initiation Document; PID) spezifiziert wurden, auch an den Kunden geliefert wurden und ob er diese offiziell abgenommen hat. Reservierte Ressourcen, die zur Durchführung des Projektes gebraucht wurden, müssen jetzt mit


■ ■ ■

135

PRINCE 2

CP (Abschließen eines Projektes)

CP1 (Beenden des Projektes )

CP2 (Identifizieren von Folgeaktionen )

PRINCE 2

Abb. 6.19: Der PRINCE 2CP-Prozess im Überblick

CP3 (Bewerten eines Projektes)

Sicherstellung aller Projektziele und Produkteigenschaften

einer bestimmten Vorlaufzeit gekündigt werden. Alle Beteiligten müssen darauf hingewiesen werden, dass das Projekt beendet werden soll. Eine andere Variante, die zum Durchführen dieses Subprozesses führt, ist die vorzeitige Beendigung des Projektes aus inoder externen Gründen. Innerhalb des Subprozesses CP2 werden alle noch zu tätigenden Aktionen ermittelt, die vor Abschluss des Projektes oder darüber hinaus noch durchgeführt werden müssen. Auch offene Punkte innerhalb des Problemlogbuchs (Issue Log), die es noch zu lösen gilt, fallen darunter. Außerdem wird ein Terminvorschlag gemacht, an dem eine Projektrevision (post project review) stattfinden kann. Innerhalb der Projektrevision soll festgestellt werden, ob die Ziele, die innerhalb des Business Case niedergeschrieben sind, auch nach dem Beenden des Projektes erreicht wurden. Weiterhin soll ermittelt werden, ob der inoder externe Kunde mit der qualitativen Ausführung des gelieferten Endproduktes eines Projektes zufrieden ist und ob es beim Implementieren zu Schwierigkeiten gekommen ist. Mittels des Subprozesses CP3 wird beurteilt, ob die Managementsteuerungsmechanismen bei dem Projekt ausreichend waren, um den während des Projektes aufkommenden Problemen und Risiken zu begegnen. Die Kenndaten (z. B. Kosten, Implementierungsdatum) am Ende des Projektes werden verglichen mit den im Projektleitdokument (Project Initiation Document; PID) beschriebenen und vorgegebenen Rahmenwerten. Alles dies fließt im Projektabschlussbericht (End Project Report) zusammen, der dem Lenkungsausschuss übergeben wird. Auch durch das Projekt erworbenes „Know-how“, wie man in Zukunft ein ähnliches Projekt besser gestalten kann (z. B. Qualität

136

■ ■ ■

6 PRINCE 2

sichernde Verfahren, technische Hilfsmittel, Managementprozesse) findet seinen Weg in ein Erfahrungsprotokoll (Lessons Learned Log), damit spätere Projekte davon profitieren können.

6.4 PRINCE und seine Prozesse im Detail 6.4.1 SU (Vorbereiten eines Projektes) Der PRINCE 2-Prozess „Vorbereiten eines Projektes“ (Starting up a Project, SU) beinhaltet alle wesentlichen Aufgaben, um ein Projekt optimal zu starten und Basisinformationen zusammenzutragen, die es erlauben, ein Projekt optimal zu beginnen. Es beginnt mit der Ernennung eines Projektmanagements und endet mit der Erstellung eines anfänglichen Phasen- oder Etappenplans (Initiation Stage Plan). Als Input des Prozesses dient das ProjektMandat, dem wesentliche Elemente entnommen werden können, um die Ausgangsprodukte des Prozesses, wie z. B. den Projektentwurf (Project Brief) zu erzeugen. Wesentlich ist bei dem SU-PRINCE 2Subprozess, dass Verantwortlichkeiten und Projektrollen definiert werden und innerhalb eines Risikoprotokolls (Risk Log) alle wesentlichen Projektrisiken erfasst sind. Abb. 6.20: Der PRINCE 2SU-Prozess im Überblick

6.4 PRINCE und seine Prozesse im Detail

■ ■ ■

137

Abb. 6.21: Schematische Übersicht über den PRINCE 2Prozess SU [1]

138

■ ■ ■

6 PRINCE 2

Subprozesse Inhalt/Deutsch des PRINCE 2SU-Prozesses

Inhalt/Englisch

SU1

Vorsitzenden des Lenkungsausschusses und Projektleiter ernennen Entwerfen eines Projektleitungsteams

Appointing a PB (Project Board) Executive and a PM (Project Manager) Designing a Project Management Team

SU3

Ernennen des Projektleitungsteams

Appointing a Project Management Team

SU4

Vorbereiten des Projektentwurfes Preparing a Project Brief

SU5

Definieren eines Projektlösungsansatzes

SU2

Tabelle 6.2: PRINCE 2-SUProzess mit seinen Subprozessen SU1 bis SU5

Defining Project Approach

6.4.1.1 SU1 (Vorsitzenden des Lenkungsausschusses und Projektleiter ernennen) Bevor ein Projekt initiiert und durchgeführt wird, braucht es jemanden, der es planend, und jemanden, der es entscheidend vorantreibt. Bei größeren Projekten wird zur Kontrolle und Steuerung eines Projektes ein Lenkungsausschuss eingerichtet. Im PRINCE-Subprozess SU1 werden von einer Interessengruppe innerhalb der Geschäftsleitung, Programm-Management oder eines externen Kunden des geplanten Projektes die Verantwortlichen (Vorsitzende des Lenkungsausschusses, Projektleiter) ernannt, die dieses Projekt durchführen sollen. Innerhalb dieser Interessengruppe muss vorher ein Projekt-Mandat autorisiert sowie Tätigkeitsbeschreibungen des Vorsitzenden des Lenkungsausschusses sowie des Projekt-Managers angefertigt werden. Auch muss geprüft werden, ob die dafür vorgesehenen Personen in dem festgelegten Zeitraum, in dem das Projekt durchgeführt werden soll, auch zur Verfügung stehen und nicht schon in anderen Projekten verplant sind. Sind die Projektverantwortlichen (entscheidend und planend) benannt worden, muss auch der Verantwortungsbereich definiert sowie ausstehende Informationen (Ziel, Größe, Komplexitätsgrad, Wichtigkeit) zu dem Projekt zusammengetragen werden, damit das Projekt eine gesunde Basis erhält. Die Projektverantwortlichen (Vorsitzender des Lenkungsausschusses, Projektleiter) sind auch für das Umsetzungs-Design des Projektes verantwortlich. Die Projektentscheider sollten in der Firmenhierarchie die entsprechende Autorität besitzen, um ihrer Aufgabe gerecht zu werden. Auch die entsprechenden fachlichen Qualitäten müssen im Vorfeld


■ ■ ■

139

Abb. 6.22: Schematische Darstellung des SU1-Subprozesses

Prozessbeziehungen und Erzeugnisse von SU 1 Input

Firmenleitung oder Programmanagement einer Firma

Anfängliches Projekt Mandat (project mandate)

Output

SU1 Vorsitzenden des Lenkungsausschusses und Projektleiter ernennen

Ernennung des Vorsitzenden des LenkungsAusschussess (appointing Project Executive)

SU2

Ernennung des Projektleiters (appointing Project Manager)

SU2

(Appointing a Project Bord Executive and a Project Manager) Verantwortlich für diesen Prozess ist die Firmenleitung oder das Programmanagement einer Firma.

mit der Projektaufgabe verglichen werden. Der Vorsitzende des Lenkungsausschusses wird die tägliche Projektsteuerung dem Projektleiter überlassen und nur kontrollierenden und beratenden Einfluss auf das Projekt ausüben. Abb. 6.23: Im SU1-Prozess werden die Rollen der Projektverantwortlichen besetzt

?

Ein rudimentärer Projektplan in einem Vorstadium gibt eine Vorstellung davon, in welchem Zeitraum das Projekt durchgeführt werden soll. Eingangsprodukte sind: x Projektmandat (project mandate) Ausgangsprodukte sind: x Bestimmung des Vorsitzenden des Lenkungsausschusses sowie des Projekt-Managers (Project Board Executive appointment and Project Manager appointment) Verantwortlich für die Durchführung des Subprozesses ist: x die Firmenleitung oder das Programm-Management einer Firma (Corporate or Programme management)

140

■ ■ ■

6 PRINCE 2

6.4.1.2 SU2 (Entwerfen eines Projektleitungsteams) Innerhalb des PRINCE-Subprozesses SU2 wird ein Projektmanagement-Team zusammengestellt, welches sich innerhalb des Projektlenkungsausschusses (project board) trifft. Für dieses Team sollten jeweils Vertreter der späteren Nutzer (user), Auftragnehmer (supplier) und der Geschäftsleitungsebene (business) benannt werden, so dass ein Informationsfluss in alle Bereiche sichergestellt ist und kein wesentliches Detail übersehen wird. Der Lenkungsausschuss beinhaltet alle wesentlichen informellen und administrativen Autoritäten. Innerhalb dieses Projekt-Management-Teams werden die zusammengestellten Informationen bezüglich des neuen Projektes erörtert und auf eine gesunde Basis gestellt. Prozessbeziehungen und Erzeugnisse von SU 2 Input

SU1

Output

Ernennung des Vorsitzenden des LenkungsAusschussess ( appointing Project Executive)

SU2 SU1 Firmenleitung oder Programmanagement einer Firma

Ernennung des Projektleiters ( appointing Project Manager)

Entwerfen eines Projektleitungsteams

Anfängliches Projekt Mandat (project mandate)

(Designing a Project Management Team )

Struktur des Projektmanagement-Teams ( Projectmanagement team structure)

SU3

Abb. 6.24: Schematische Darstellung des SU2-Subprozesses

Verantwortlich für diesen Prozess ist der Vorsitzende des Lenkungsausschuss sowie der Projektleiter.

Wichtig ist bei diesem Subprozess, dass wirklich alle Interessengruppen vertreten sind und dass die fachliche Kompetenz gewährleistet ist, um das Projekt durchzuführen. Eingangsprodukte sind: x Projekt-Mandat (project mandate) x Ernannte Vorsitzende des Lenkungsausschusses und Projektleiter (Project Board Executive und Project Manager) Ausgangsprodukte sind: x Struktur des Projektleitungsteams (project management team structure) Verantwortlich für die Durchführung des Subprozesses ist: x Vorsitzender des Lenkungsausschusses mit Hilfe des Projektleiters


■ ■ ■

141

Abb. 6.25: Drei Dinge braucht PRINCE 2

Projektteam

Projektentwurf

Projektplan

6.4.1.3 SU3 (Ernennen eines Projektleitungsteams) Nachdem das Projektleitungsteam zusammengestellt ist, werden einzelnen Mitgliedern Aufgaben und Verantwortungsbereiche innerhalb des Lenkungsausschussess zugewiesen und festgelegt, wie die Kommunikationsstruktur aussehen soll. Abb. 6.26: Schematische Darstellung des SU3-Subprozesses


SU2

Struktur des Projektmanagement-Teams (Projectmanagement team structure)

Output

SU3

Vereinbarte Aufgabenbeschreibungen, aktualisierte Struktur des Projektmanagement-Teams (job definitions, updated project management structure)

IP6, DP1

Ernennung eines Projektleitungsteams (appointing a project management team) Verantwortlich für diesen Prozess ist der Vorsitzende des Lenkungsausschuss mit der Hilfe des Projektleiters.

Weiterhin werden Personen im Lenkungsausschuss den einzelnen fachlichen, kontrollierenden und organisatorischen Aufgabenbereichen zugewiesen. Dies erfolgt in schriftlicher Form. Abb. 6.27: Ein Team ist nur so gut wie seine Leitung

Eingangsprodukte sind: x Struktur des Projektleitungsteams (project management team structure) Ausgangsprodukte sind: x Vereinbarte Aufgabenbeschreibungen (Agreed job definition) x Überarbeitete Struktur des Projektleitungsteams (updated project management team structure)

142

■ ■ ■

6 PRINCE 2

Verantwortlich für die Durchführung des Subprozesses ist: x Vorsitzender des Lenkungsausschusses mit Hilfe des Projektleiters

6.4.1.4 SU4 (Vorbereiten des Projektentwurfes) Damit diejenigen, die mit der Projektdurchführung beauftragt wurden, sicherstellen können, dass alle wesentlichen Informationen, die zur Projektdurchführung notwendig sind, auch vorliegen, werden sie durch das PRINCE-Subprozess-SU4 angehalten, alle wesentlichen Details innerhalb eines Projektentwurfes (project brief) zusammenzutragen. Auch wird innerhalb von SU4 der Lenkungsausschuss prüfen, ob das beabsichtigte Projekt wert ist, weiter verfolgt zu werden, und ob alle notwendigen Fakten und Informationen für dieses neue Projekt vorliegen. Prozessbeziehungen und Erzeugnisse von SU 4 Input

Firmenleitung oder Programmanagement einer Firma

Projekt Mandat (project mandate)

Output

SU4 Vorbereiten des Projektentwurfs

Projektentwurf ( project brief)

SU5,IP1, IP6,DP1

Projektentwurf, Risikoprotokoll ( project brief, risk log)

SU6, IP2, IP3

Abb. 6.28: Schematische Darstellung des SU4-Subprozess

(preparing a project brief) Verantwortlich für diesen Prozess ist der Vorsitzende des Lenkungsausschuss mit der Hilfe des Projektleiters.

Innerhalb des Projektentwurfs (project brief) sind neben einer genaueren Projektzielbeschreibung, die dem Projektmandat (project mandat) entnommen werden kann, mögliche Projektrisiken sowie bekannte Abnahmekriterien enthalten. Alle zusammengetragenen Informationen werden mit den im Business Case gemachten Annahmen verglichen. Abb. 6.29: Am Anfang eines Projektes müssen alle wesentlichen Teile eines Projektes miteinander verbunden werden


■ ■ ■

143

Wesentlich ist hierbei auch, dass vorher gemachte Annahmen auf ihren Wahrheitsgehalt überprüft werden. In Kurzform: was muss warum, von wem und wann gemacht werden. Die einzelnen Nutzeroder Kundenanforderungen sollten mit einer Priorität versehen werden, mit der sie später umgesetzt werden. Dies ist nützlich, wenn im fortgeschrittenen Projektverlauf die eingeplanten Kosten überschritten werden und es darum geht, die vorhandenen finanziellen Ressourcen effektiv einzusetzen. Eingangsprodukte sind: x Projektmandat (project mandat) Ausgangsprodukte sind: x Projektentwurf (project brief) x Risikoprotokoll (risk log) Verantwortlich für die Durchführung des Subprozesses ist: x Vorsitzender des Lenkungsausschusses mit Hilfe des Projektleiters

6.4.1.5 SU5 (Definieren eines Projektlösungsansatzes) Wesentliche Aufgabe des Subprozesses SU5 ist es herauszufinden, auf welcher Basis mit welchen Hilfsmitteln und Technologien, in Abhängigkeit zu den Projekterfordernissen (Zeit, Kosten, Qualität, Projekt-Anforderungen), das Projekt durchgeführt werden soll. Hierbei ist abzuschätzen, welche Hilfsmittel gekauft, welche Teile innerhalb einer Firma entwickelt und welche nach außen in Auftrag gegeben werden sollen. Abb. 6.30: Schematische Darstellung des SU5-Subprozesses


SU4

Projektentwurf, Risikokatalog ( project brief, risk log)

Output

SU5 Definieren eines Projektlösungsansatzes (defining project approach) Verantwortlich für diesen Prozess ist der Projektleiter mit der Unterstützung des HauptLieferanten wie z.B. der EntWicklungsabteilung und des Auftraggebers sowie des Nutzers.

144

■ ■ ■

6 PRINCE 2

Projektlösungsansatz (project approach)

SU6, IP1, IP2, IP3, IP6, DP1, PL

Dabei kann im Extremfall herauskommen, dass das Projekt als Ganzes durch jemand anderen realisiert werden soll oder dass ein bestehendes Produkt gekauft wird. Auch ist es wichtig herauszufinden, ob ein bestehendes zu erwerbendes Produkt so modifiziert werden kann, dass es die Erfordernisse des gegenwärtigen Projektes erfüllt. Hierbei ist es wichtig, sich mit dem inoder externen Kunden abzustimmen. Auch soll abgeklärt werden, ob es bestehende Firmen-, IndustrieStandards oder „best practice“-Ansätze gibt, die bei der Realisierung des Projektes genutzt werden können. Zeitliche, finanzielle und qualitative Anforderungen sowie zur Durchführung eines Projektes benötigte Hilfsmittel müssen ermittelt werden. Risiken, die durch eine Lösungsstrategie impliziert werden, sind zu erfassen und den möglichen Gegenmaßnahmen gegenüberzustellen. Abb. 6.31: Hier werden die Weichen gestellt

Es sollte auch innerhalb des Subprozesses geprüft werden, ob beim späteren Betreiben des Ausgangsprodukts eines Projekts durch den Projektansatz mit erhöhten Kosten (seien es interne oder externe, wie z. B. Wartungskosten) zu rechnen ist. Weiterhin sollte der ungefähre Schulungsaufwand abgeschätzt werden, der durch die Einführung des Endproduktes zu erwarten ist. Hierbei kann sich z. B. herausstellen, dass es besser ist, den existierenden Workflow bestehender DV-Verfahren zu übernehmen, so dass den Nutzern des Endproduktes die Akzeptanz leichter fällt. Ist ein Projektlösungsansatz gefunden, so wird der zeitliche und fachliche Bedarf zur Realisierung des Projektes abgeschätzt. Eingangsprodukte sind: x Projektentwurf (project brief) x Risikologbuch (risk log) Ausgangsprodukte sind: x Projektlösungsansatz (project approach)


■ ■ ■

145

Verantwortlich für die Durchführung des Subprozesses ist: x Projektleiter (Project Manager) mit der Unterstützung des Kunden, späteren Nutzern und Hauptlieferanten wie z. B. der Entwicklungsabteilung

6.4.1.6 SU6 (Planen der Initialisierungsphase) Innerhalb des Subprozesses SU6 werden verschiedene wesentliche Dokumente erzeugt. Dies sind das Projektleitdokument (project initiation document; PID), der Initiierungsphasenplan (stage plan) sowie das Risikoprotokoll (risk log) in einer ersten Fassung. Diese Dokumente sind eine Verfeinerung der innerhalb des Projektentwurfs (project brief) gemachten Angaben. Da jede Phase (stage) einzeln freigegeben werden muss, enthält die erste Fassung des Projekt-Initiierungsphasenplans (initiation stage plan) wenigstens die nächst notwendige Phase (stage). Die Ausgestaltung der Phase wird durch die PRINCE 2-PLProzesse erreicht. Es muss weiterhin definiert werden, wie innerhalb der ersten Phase (stage) das Vorgehen bezüglich des Berichtswesens (reporting) und des Kontrollverfahrens (control) geregelt werden soll. Abb. 6.32: Schematische Darstellung des SU6-Subprozesses

Auch muss ein Risikoprotokoll (risk log) aufgesetzt werden, das auf die Daten des Projektentwurfs (project brief) des Subprozesses SU4 aufsetzt und verfeinert. Die allgemeinen Planungsprozesse (PL) werden genutzt, um den Initiierungsphasenplan (initation stage plan) zu entwickeln. Der Projektleiter muss vorher abschätzen, wie lange die Planung der nächsten Projektphase dauern wird und entsprechend informieren. Am Ende von SU6 müssen alle Fakten und Informationen vorhanden sein, die es dem Firmen- oder Programm-Management erlauben, eine Entscheidung über die Durchführung des Projektes zu

146

■ ■ ■

6 PRINCE 2

treffen. Verantwortlich für die Planung des Initiierungsphasenplans ist der Projektleiter. Eingangsprodukte sind: x Projektlösungsansatz (project approach) x Projektentwurf (project brief) x Risikoprotokoll (risk log) Ausgangsprodukte sind:

x Entwurf des Initiierungsphasenplans (Initiation Stage Plan) x Überarbeitetes Risikoprotokoll (risk log) Verantwortlich für die Durchführung des Subprozesses ist: x Projektleiter (Project Manager)

6.4.2 IP (Initiieren eines Projektes) Es muss feststehen, welche Produkte innerhalb des Projektes erstellt werden sollen und wie die Grundvoraussetzungen sind, um diese Produkte im angestrebten Zeit- und finanziellen Rahmen zu erstellen. Qualitative Anforderungen müssen spezifiziert sein und entsprechende Prüfmethoden ausgesucht werden. Weiterhin bedingt das erfolgreiche Beenden eines Projektes einen anhaltenden Informationsfluss zwischen vorher festgelegten Stellen. Auch müssen die Risiken eines Projektes betrachtet werden und entsprechende Gegenmaßnahmen festgelegt oder ergriffen werden. Projektsteuerungsmechanismen müssen definiert und die entsprechenden Verantwortlichkeiten zur Kontrolle des Projektes festgelegt werden. Beim Initiieren eines Projektes (Initiating a Project, IP) wird versucht, eine Übereinkunft mit allen Beteiligten zu finden über die Grundlagen des Projektes und über die Dinge, die daraus logischerweise folgen. Der PRINCE-Subprozess IP soll dafür Sorge tragen, dass das Fundament eines Projektes solide ist. Im Wesentlichen sind es nur ein paar Steuerungsmechanismen, die gewährleisten, dass ein Projekt erfolgreich durchgeführt werden kann. Als erstes muss klar sein, aus welchen Gründen ein Projekt durchgeführt wird. Wesentlich ist weiterhin, dass alle involvierten Stellen die gleiche Vorstellung davon haben, wie das Endprodukt eines Projektes aussehen


■ ■ ■

147

soll, welche unabdingbaren Funktionalitäten und Rahmenanforderungen damit verbunden sind und in welchem zeitlichen und finanziellen Rahmen es sich bewegen soll. Damit lässt sich bei aufkommenden Schwierigkeiten genauso schnell reagieren wie auf neue Erkenntnisse darüber, wie das Endprodukt eines Projektes beschaffen sein sollte. Verantwortung muss gezielt übertragen werden, so dass kein Zweifel aufkommt, wer einen Informationsfluss und notwendige Aktionen anschieben muss. Kontrollmechanismen sind aufzubauen bzw. zu vereinbaren, damit in bestimmten Zeitabständen neu Maß genommen wird und auf aufkeimende Probleme massiv eingewirkt werden kann. Ein Dokumentenablageschema ermöglicht allen Beteiligten den zentralen Zugriff zu den notwendigen Informationen, so dass der gegenwärtige Sachstand eines Projektes damit ersichtlich ist. Das wirtschaftliche Fundament eines Projektes ist innerhalb des Business Case niedergelegt und führt über die einzelnen IP-Subprozesse zum Projektleitdokument (Project Initiation Document, PID), welches wiederum dazu führt, dass der Lenkungsausschuss zu einer Entscheidung kommen kann. Dieser stellt dann fest, ob das durchzuführende Projekt eine wirtschaftliche Basis und Erfolgsaussichten hat, und gibt Anweisung, die erforderlichen Ressourcen zur Verfügung zu stellen. Abb. 6.33: Der PRINCE 2IP-Prozess im Überblick

148

■ ■ ■

6 PRINCE 2

Abb. 6.34: Schematische Übersicht des IPSubprozesses


■ ■ ■

149

Tabelle 6.3: Subprozesse innerhalb des PRINCE-IPProzesses

Subprozesse des Inhalt/Deutsch PRINCE 2-IPProzesses

Inhalt/Englisch

IP1 IP2

Planen der Qualität Planen des Projektes

Planing Quality Planning a Project

IP3

Business Case und Risiken verfeinern Projektsteuerungsmittel festlegen Projektablagestruktur einrichten Projektleitdokument (PID) zusammenstellen

Refining the Business Case & Risks Setting up Project Controls

IP4 IP5 IP6

Setting up Project Files Assembling a PID

6.4.2.1 IP1 (Planen der Qualität) In- oder externe Kunden, die die Erstellung eines Endproduktes in Auftrag geben, haben genaue Vorstellungen davon, wie dieses aussehen und welche Funktionen es beinhalten soll. Deswegen ist es für das Projekt von existenzieller Wichtigkeit, dass der Kunde und der Dienstleister (supplier) dieselben Vorstellungen darüber haben, wie das Endprodukt beschaffen sein soll. Daraus ergeben sich die qualitativen Anforderungen an das Endprodukt und das Benennen entsprechender Ansprechpartner. Davon können der voraussichtliche Projektendtermin und entstehende Entwicklungskosten abgeleitet werden. Der Subprozess IP1 (Planen der Qualität) soll beschreiben, wie die qualitativen Anforderungen an das Endprodukt erreicht werden können. Dafür ist es erforderlich, die Qualität überprüfende Regularien und Verfahren festzulegen. Abb. 6.35: Schematische Darstellung des IP1-Subprozesses

150

■ ■ ■

Prozessbeziehungen und Erzeugnisse von IP 1 Output

Input Firmen- und/oder Kunden Qualitätsstandards (QMS)

SU4

Projektentwurf (project brief)

SU5

Projektlösungsansatz (project approch)

6 PRINCE 2

IP1 Planen der Qualität (Planning Quality) Verantwortlich für diesen Prozess ist der Projektleiter sowie Qualitätsverantwortliche innerhalb des Projektteams.

Qualitätsplan (project quality plan)

IP2, IP4, IP5, IP6

Dies kann Schwierigkeiten aufwerfen, wenn der Kunde und der Dienstleister unterschiedliche Qualitätsstandards (QMS) nutzen. Da es kein Projekt ohne Änderungen gibt, muss man sich auch darum kümmern, wie Änderungswünsche offiziell in das bestehende Projekt eingebracht werden können. Das erforderliche Konfigurationsund Changemanagement ist vorzusehen. Eingangsprodukte sind: x Projektentwurf (project brief) x Qualitätsstandards des Kunden und des Dienstleisters x Projektlösungsansatz (project approach) Ausgangsprodukte sind: x Projektqualitätsplan (quality plan) Verantwortlich für die Durchführung des Subprozesses ist: x Projektleiter (Project Manager) unter Zuarbeit der die qualitätssichernden Stellen

6.4.2.2 IP2 (Planen des Projektes) Innerhalb des Subprozesses IP2 müssen die notwendigen Aufwendungen ermittelt werden. Daraus können die Rahmenparameter wie Projektendzeitpunkt, geschätzter Aufwand und benötigte Ressourcen festgelegt werden, bevor man mit dem Projekt voranschreitet. Prozessbeziehungen und Erzeugnisse von IP 2 DP1

Input Genehmigen der Projektinitialisierung (authorisation to proceed)

Output

IP2 SU4

Risikokatalog (risk log)

Planen der Projektes (Planning a Project)

SU4

Projektentwurf (project brief)

SU5

Projektlösungsansatz (project approch)

IP1

Qualitätsplan (project quality plan)

Projektplan (project plan)

IP3, IP4, IP5, IP6, SB1


IP3

Beauftragen des nächsten Phasenplans (trigger for next stage plan)

SB1

Abb. 6.36: Schematische Darstellung des IP2-Subprozesses

Verantwortlich für diesen Prozess ist der Projektleiter.


■ ■ ■

151

Entsprechende Projektmeilensteine und „Walk Throughs“ mit den Kunden sind einzuplanen. Projektkosten werden geschätzt und alle notwendigen und relevanten Informationen des Projektlösungsansatzes ermittelt. Ist das zu planende Projekt Teil eines größeren Vorhabens, so ist sicherzustellen, dass die zeitlichen und technischen Rahmenparameter mit denen des größeren Vorhabens harmonieren. Innerhalb des Subprozesses IP2 müssen bestehende Abhängigkeiten und Rahmenbedingungen überprüft und die dadurch entstehenden potentiellen Projektrisiken ermittelt werden. Es werden Subprozesse des PRINCE-Prozesses PL (Planen) genutzt, um einen Projektplan und Phasenplan zu erhalten. Eingangsprodukte sind: x Genehmigen der Projektinitialisierung (authorisation to proceed) x Projektentwurf (project brief) x Projektlösungsansatz (project approach) x Projektqualitätsplan (quality plan) x Risikokatalog (risk log) Ausgangsprodukte sind: x Überarbeitetes Risikoprotokoll (risk log) x Projektplan (project plan) x Beauftragen des nächsten Phasenplans (trigger for next stage plan) Verantwortlich für die Durchführung des Subprozesses ist: x Projektleiter

6.4.2.3 IP3 (Business Case und -Risiken verfeinern) Dieser Subprozess konzentriert sich auf zwei Schwerpunkte. Zum einen wird während eines Projektes, wenn erst einmal feststeht, was zu tun ist, alle Aufmerksamkeit auf die Überlegung gerichtet, wie es realisiert werden kann, um es dann entsprechend umzusetzen. Dabei vergisst man des Öfteren zu hinterfragen, warum man es realisieren will, denn es kann sehr wohl so sein, dass neuere Informationen zum Projekt dies nicht mehr nötig machen.

152

■ ■ ■

6 PRINCE 2

Abb. 6.37: Schematische Darstellung des IP3-Subprozess

Es wird überprüft, ob die Annahmen und Ziele des Business Case mit externen Einflüssen in Einklang stehen oder ob die Geschäftsziele, die mit dem Durchführen des Projektes verbunden sind, gefährdet werden. Man versucht die mit der Durchführung des Projektes verbundenen Vorteile zu quantifizieren und messbar zu machen, damit ihre Einhaltung (benefit realisation) einfacher zu überwachen ist. So kann es sein, dass die Gründe für die Durchführung bestimmter, im Business Case aufgeführter Dinge gar nicht mehr existieren, z. B. Gesetzesvorhaben und Vorschriften, die sich seit der Erstellung des Business Case, geändert haben. Auch sollte der Nutzen, den sich die Firmenleitung oder das Programm-Management einer Firma vom Durchführen des Projektes verspricht, erneut auf Realitätsbezug untersucht werden. Dabei kann es nicht selten vorkommen, dass sich die Dringlichkeit bzw. der Nutzen, den man sich von der Durchführung des Projektes erhofft, noch vergrößert. Um den Nutzen eines durchzuführenden Projektes zu quantifizieren, muss ein Bewertungsschema den Nutzen beurteilen. Nicht selten ist es auch so, dass sich die mit der Durchführung des Projektes verbundenen Kosten verändern. Dies sollte überprüft werden. Wird hier festgestellt, dass sich Grundvoraussetzungen geändert haben, so ist der Lenkungsausschuss, die Firmenleitung bzw. das Programm-Management einer Firma zu informieren. Auch Gedanken über Zahlungsmodalitäten mit dem Kunden fallen innerhalb IP3. Der zweite Schwerpunkt, auf den sich dieser Subprozess bezieht, ist die Erfassung eventueller Risiken und Bedrohungen des Projektes und die Abschätzung von deren Wahrscheinlichkeit sowie deren Auswirkungen (Kosten, Terminverschiebung, Aktivitäten, Änderungen an Architektur und Design). Zu potentiellen Risiken sind


■ ■ ■

153

Abb. 6.38: Risiken festzustellen und zu vermeiden, ist eine der Aufgaben des Subprozesses IP3

entsprechende Gegenmaßnahmen aufzustellen, um diese Risiken zu neutralisieren oder in ihrer Wirkung zu verkleinern. Falls notwendig, sind sofort entsprechende Aktionen einzuleiten, um diese zu kompensieren. Möglicherweise ist der vorliegende Projektplan mit weiteren Aktivitäten zu ändern, so dass bestehende Risiken minimiert werden. Wesentliche zu bearbeitende Dokumente innerhalb dieses SUSubprozesses sind Business Case, Projektplan und Risikokatalog (Risk Log). Auf Basis der geänderten Dokumente kann der Projektleiter den Lenkungsausschuss auf schwierige Punkte hinweisen und Vorschläge zu Zahlungsmodalitäten, die mit dem Kunden ausgehandelt werden müssen, unterbreiten. Eingangsprodukte sind: x Projektentwurf (project brief) x Projektlösungsansatz (project approach) x Projektplan x Risikokatalog (risk log) Ausgangsprodukte sind: x Überarbeitetes Risikoprotokoll (risk log) x Überarbeiteter Projektplan x Überarbeiteter Business Case Verantwortlich für die Durchführung des Subprozesses ist: x Projektleiter in Absprache mit dem Projektlenkungsausschuss.

154

■ ■ ■

6 PRINCE 2

6.4.2.4 IP4 (Projektsteuerungsmittel festlegen) Projekte und die damit verbundenen Entscheidungen sind angewiesen auf akkurate Sachstandsermittlung. Der Subprozess IP4 soll sicherstellen, dass der notwendige Informationsfluss, die Kontrolle und die Überwachungs- und Steuerungsinstrumente für ein später durchzuführendes Projekt vorhanden sind. Hierbei ist wesentlich, die Zeitabstände festzulegen, in denen die vorgesehenen Kontrollmechanismen wirken sollen und wer in welchen Zeitabständen über welche Projekteckdaten informiert werden soll. Prozessbeziehungen und Erzeugnisse von IP 4 Output

Input

IP1

Projekt Qualitätsplan (project quality plan)

IP2


Überarbeiteter ProjektPlan (project plan)

IP6

Überarbeiteter RisikoKatalog (risk log)

IP6

Kontrollwerkzeuge (project controls)

IP6

Kommunikationsplan (communication plan)

IP6


IP4 Projektsteuerungsmittel festlegen (Setting up Project Controls)

IP3



Hierbei ist die Einteilung eines Projektes und dessen Projektphasen mit verschiedenen „Milestones“ zu logischen Punkten eines Projektes von Vorteil. Alle Personen, die ein berechtigtes Verlangen nachweisen können, sind zu identifizieren und zu ihrem Informationsbedarf zu befragen. Dahinter verbirgt sich das Prinzip, dass die richtigen Entscheidungen von den Entscheidungsbefugten zur richtigen Zeit gegeben werden. Auch zeigt die Erfahrung, dass es besser ist, mehr zu informieren als weniger, weil man nicht immer erfasst, dass manche Sachverhalte für jemand anderen eine große Bedeutung haben. Aber nicht nur die zeitliche Festlegung eines Informationsflusses ist wichtig, sondern auch die fundamentalen Daten, die es zu erfassen gilt, sind entsprechend den Verhältnissen und Risiken eines Projektes festzulegen. Diese können sich von Projekt zu Projekt spezifisch verändern. Hat man sich einmal auf das „Was“ und „Wann“ verständigt, so muss man nur noch festlegen, in welcher Art und Weise (Sachstandsberichte, Erstellungssoftware und Standards) die Informationen übermittelt und die Kontrollwerkzeuge angewendet werden.


■ ■ ■

155

Hierbei ist wesentlich festzulegen, „wer“ (Lenkungsausschuss, Kunde) die Entscheidungsbefugnis hat, notwendige Änderungen zu autorisieren oder regulierend auf den Projektverlauf einzuwirken. Ist der Kunde eine externe Firma, so ist oft der entsprechende Berichtstandard einzuhalten, den dieser Kunde vorgibt. Der Projektleiter muss sich überlegen, in welcher Art und Weise er die notwendigen Daten bekommen kann und ein entsprechendes Monitoring festlegen, wie z. B. wöchentliche Sachstandsberichte der einzelnen mit der Entwicklung betrauten Personen. Das „Monitoring“ eines Projektes sollte aber nicht so eingerichtet werden, dass die mit der Entwicklung betrauten Mitarbeiter einen Großteil ihrer Zeit mit Sachstandsberichten verbringen müssen. Eingangsprodukte sind: x Überarbeiteter Projektplan (project plan) x Überarbeiteter Risikokatalog (risk log) x Projektqualitätsplan (quality plan) Ausgangsprodukte sind: x Kommunikationsplan (communication plan) x Projektsteuerungsmittel (project controls) Verantwortlich für die Durchführung des Subprozesses ist: x Projektleiter

6.4.2.5 IP5 (Projektablagestruktur einrichten) Alle bisher erwähnten projektbezogenen Dokumente unterliegen während der Projektlaufzeit ständigen Änderungen. Diese führen zu neuen Versionsständen, die entsprechend zu kennzeichnen und so abzulegen sind, dass alle Beteiligten darauf zugreifen können. Dies bedingt ein vorher vereinbartes zentrales Ablagesystem (project filing structure) oder eine definierte Datei-Verzeichnisstruktur beim Start eines Projektes. Alle wesentlichen Dokumente sind somit jedem Befugten zumindest mit lesendem Zugriff zugänglich. Innerhalb des Subprozesses IP5 muss auch festgelegt werden, welche Dokumente von allgemeinem Interesse sind und innerhalb der Projektablagestruktur niedergelegt werden sollen. Oft geben die innerhalb einer Firma mit dem Configurations-Management beauftragten Mitarbeiter Tipps und nützliche Hinweise, wie und wo am besten

156

■ ■ ■

6 PRINCE 2

die Verzeichnisstruktur abzulegen ist. Auch wird die Datensicherung der Projektablagestruktur vom Konfigurationsmanagement (Configuration Management) einer Firma übernommen. Eine definierte Projektablagestruktur ist besonders dann, wenn neue Projektmitglieder im Laufe eines Projektes dazustoßen, von Nutzen. Die neuen Projektmitglieder können die dort abgelegten Dokumente am Anfang ihrer Tätigkeit innerhalb des Projektes studieren. Abb. 6.40: Schematische Darstellung des IP5-Subprozesses

Der Zugriff auf diese Dokumente sollte es erlauben, mittels eines Audits den jeweiligen Sachstand klar zu erfassen. Da die wesentlichen Dokumente von Projekt zu Projekt schon wegen der Projektgröße anders geartet sein können, ist auch mit dem inoder externen Kunden zu vereinbaren, was als notwendig erachtet wird, um auf die Belange des Projektes einzugehen. Oft wird auch ein Dokumentenmanagementsystem genutzt, wie man es aus der Softwareentwicklung unter dem Namen CVS (concurrent versions system) kennt. Innerhalb des PRINCE 2-Subprozesses IP5 werden verschiedene Dokumente vorbereitend angefertigt. Darunter fällt der Erfahrungsbericht (lessons learned report), das Problemkatalog (issue log) sowie das Projektqualitätslogbuch (quality log), in der die einzelnen nach dem Projektqualitätsplan (quality plan) beschriebenen Ergebnisse der Qualitätsprüfung einzelner Projekterzeugnisse später niedergeschrieben werden. Eingangsprodukte sind: x Projektplan (project plan) x Projektqualitätsplan (quality plan)


■ ■ ■

157

Ausgangsprodukte sind: x Dokumentenablageschema (project filing structure) x Vorbereitetes Projektqualitätslogbuch (quality log) x Vorbereiteter Erfahrungsbericht (lessons learned report) x Vorbereitetes Problemlogbuch (issue log) Verantwortlich für die Durchführung des Subprozesses ist: x Projektleiter mit Unterstützung des Konfigurationsmanagements (Configuration Management) einer Firma

6.4.2.6 IP6 (Projektleitdokument zusammenstellen) Alle bisher beschriebenen IP-Subprozesse haben den Sinn, alle notwendigen Informationen über das Was, Warum, Wer, Wie und Wann eines Projektes zu erlangen, welche dann innerhalb des zentralen Projektleitdokuments (Project Initiation Document; PID) zusammengefügt werden. Die ermittelten Daten innerhalb des Projektleitdokuments sollen ausreichen, um den Lenkungsausschuss oder


158

■ ■ ■

6 PRINCE 2

in- und externe Kunden in die Lage zu versetzen, den Projektstart innerhalb des Subprozesses DP2 formalistisch zu beschließen. Alle wesentlichen Entscheidungen innerhalb der Projektlaufzeit werden nun getragen von der zusammengefügten Informationsbasis des Projektleitdokuments. Auch am Ende eines durchzuführenden Projektes wird man auf diese Daten zurückgreifen, um zu erkennen, ob das Projekt erfolgreich war und was man eventuell hätte besser machen können. Je nach Größe des Projektes wird das Projektleitdokument aus verschiedenen Teildokumenten bestehen, weil der Umfang für ein Dokument zu groß ist. Ist das zu planende Projekt Teil eines größeren Vorhabens, so ist sicherzustellen, dass die zeitlichen und technischen Rahmenparameter mit denen des größeren Vorhabens harmonieren. Deswegen muss die Firmenleitung bzw. das ProgrammManagement einer Firma davon Kenntnis erhalten. Da im Projektleitdokument auch Angaben über Anforderungen an fachliches „Know-how und Personalressourcen niedergeschrieben sind, müssen die davon betroffenen Abteilungs- oder Gruppenleiter einer Firma hiervon in Kenntnis gesetzt werden. Eingangsprodukte sind: x Projektentwurf (project brief) x Projektmanagementstruktur und dessen Arbeitsbeschreibungen (project management team structure and job definitions) x Projektlösungsansatz (project approach) x Projektqualitätsplan (quality plan) x Projektplan (project plan) x „Business Case“ x Risikoprotokoll (risk log) x Kommunikationsplan (communication plan) x Projektsteuerungsmittel (projekt controls) x Dokumentenablageschema (project filing structure) Ausgangsprodukte sind: x Projektleitdokument (Project Initiation Document; PID) Verantwortlich für die Durchführung des Subprozesses ist: x Projektleiter in enger Zusammenarbeit mit dem Lenkungsausschuss und allen sonstigen Projektverantwortlichen


■ ■ ■

159

6.4.3 DP (Lenken eines Projektes) Der PRINCE 2-DP-Prozess (Dirigieren eines Projektes; directing a project) fängt beim Start eines Projektes an und endet beim Ende eines Projektes. Alle Subprozesse von DP, die das Dirigieren eines Projektes betreffen, finden innerhalb eines Lenkungsausschusses (project board) statt. Hier trifft das „senior management“ Entscheidungen zu Schlüsselpunkten eines Projektes. Dies kann entweder bei einer neuen Projektphase sein oder wenn Schwierigkeiten während eines Projektes auftreten. Ein Teilprozess der Projekt-Fortgangsüberwachung innerhalb des PRINCE 2-DP-Prozesses regelt diese Ausnahmesituationen. Dies kann entweder an den Phasengrenzen (stage boundaries) eines Projektes erfolgen oder aber bei außergewöhnlichen Situationen, die es notwendig machen, den objektiven Stand eines Projektes zu ermitteln. Der Projektleiter berichtet und steht dem Lenkungsausschuss Rede und Antwort über die Durchführung des Projektes. Er erstellt in Ausnahmesituationen (Zeitverschiebung, Kostenüberschreitungen, größere Risiken eingetroffen) einen Ausnahmestatusbericht (exception report) bzw. einen exception plan, der, wenn er vom Lenkungsausschuss genehmigt wird, den gegenwärtigen Phasenplan ersetzt. Innerhalb dieses Projektmanagementprozesses DP werden alle außergewöhnlichen Situationen abgehandelt. Sei es, dass es verschiedene Optionen gibt, ein Projekt weiter zu verfolgen, Abb. 6.42: Der PRINCE 2DP-Prozess im Überblick

160

■ ■ ■

6 PRINCE 2

ein Projekt vorzeitig beendet wird oder aber, dass wichtige Informationen offiziell ausgetauscht werden sollen. Dies alles wird hier abgehandelt. Veränderungen im Lenkungsausschuss oder beim Projektmanagementteam, die offizielle Beendigung des Projektes sowie das Genehmigen von Restarbeiten nach der offiziellen Abnahme des Endproduktes durch den Nutzer bzw. Kunden des Endproduktes werden hier behandelt. Anfordern von weiteren Ressourcen (personell, technisch, finanziell) durch den Projektleiter, weil sonst eine Projektphase nicht innerhalb des ordnungsgemäßen Zeitrahmens abgeschlossen werden kann, ist eine beispielhafte Aktion, die innerhalb des DP-Prozesses erfolgt. Auch kann der Lenkungsausschuss beratend oder entscheidend tätig werden, z. B. wenn die Kosten eines Projektes zu schnell ansteigen oder vermutet wird, dass der Projektendzeitpunkt überschritten wird. Auch die Genehmigung, ein Projekt durchzuführen, es abzuschließen oder in die nächste Projektphase überzugehen, erfolgt jedes Mal nach erneutem Überprüfen der Projektziele unter betriebswirtschaftlichen Gesichtspunkten. Subprozesse Inhalt/Deutsch des PRINCE 2DP-Prozesses

Inhalt/Englisch

DP1

Authorising Initiation

DP2 DP3 DP4 DP5

Genehmigen der Projektinitialisierung Genehmigen eines Projektes Genehmigen eines Phasen- oder Ausnahmeplans Ad-hoc-Anweisungen geben Bestätigen des Projektabschlusses

Tabelle 6.4: PRINCE 2-DPProzess mit seinen Subprozessen DP1 bis DP5

Authorising a Project Authorising a Stage or Exception Plan Giving ad hoc Direction Confirming Project Closure

6.4.3.1 DP1 (Genehmigen der Projektinitialisierung) Hauptaufgabe des Subprozesses DP1 ist festzustellen, ob das Projekt in der richtigen Art und Weise angegangen wurde und ob es sich weiterhin lohnt, das Projekt weiter zu verfolgen oder ob es besser ist, es zu beenden. Innerhalb des PRINCE 2-Subprozesses DP1 wird überprüft, ob die notwendigen Ressourcen vorhanden sind, wie sie im Initiierungsphasenplan (initiation stage plan) beschrieben sind. Ressourcen können dabei zum Beispiel das Bereitstellen entsprechender Räumlichkeiten für das Entwicklerteam oder entsprechende Arbeitsplatzrechner und Kommunikationsmittel wie Fax und Telefon sein. Aber auch das Bereitstellen entsprechender finanzieller Mittel und eventueller externer Hilfe ist Teil der Aufgabe.


■ ■ ■

161

Abb. 6.43: Schematische Übersicht über den PRINCE 2Subprozess DP

162

■ ■ ■

6 PRINCE 2

Prozessbeziehungen und Erzeugnisse von DP1 Output

Input

SU3

SU4

Beschreibung des ProjektmanagementTeams, Arbeitsplatzbeschreibungen (projektmanagement team structure, job definition)

Projektentwurf, Risikoprotokoll (project brief, risk log)

SU5

Projektlösungsansatz (project approach)

IP4

Vorläufiger Projektphasenplan (draft initiation stage plan)

DP1

Genehmigung des Projektstartes, Projektphasenplan, Projektentwurf, Risikoprotokoll (authorisation to proceed, stage plan, project brief, risk log)

Genehmigung der Projektinitialisierung Projektmanagement Teamstruktur,Projekt(authorising initiation)

Verantwortlich für diesenProzess ist der Lenkungsausschuss mit Unterstützung des Projektleiters und anderen Abteilungen des Dienstleisters und Kunden.

lösungsansatz (project management-team structure, project approach)

Benachrichtigung über den Projektstart (project startup notification)

IP2

Abb. 6.44: Schematische Darstellung des DP1-Subprozesses

IP2

Unternehmensoder Programmmanagement

Der Subprozess DP1 wird gespeist durch die Ausgangsprodukte der SU-Subprozesse SU3 bis SU6. Geht alles soweit in Ordnung, wird die Firmenleitung und das Programm-Management einer Firma mittels einer „project start-up notification“ darüber informiert, dass das Projekt gestartet wurde. Auch muss sichergestellt sein, dass alle Mitarbeiter, die innerhalb des Projektes eine Kontrollfunktion ausüben, benannt und allgemein akzeptiert sind. Für den Initiierungsphasenplan (initiation stage plan) werden die Toleranzrahmen (zeitlich, finanziell usw.) vorgegeben, in denen der Projektleiter das Projekt in dieser Phase durchführen soll. Wichtig ist es auch, innerhalb des PRINCE 2-Subprozesses DP1 sicherzustellen, dass in Zukunft alle wichtigen Informationen an die übermittelt werden, die es angeht. Des Weiteren findet eine Genehmigung zum Durchführen des Projektes (authorisation to proceed) mit der Übergabe der überprüften Dokumente – erste Version des Phasenplans (stage plan), Projektentwurf (project brief), Auflistung von Risiken innerhalb des Risikokatalogs (risk log), Projektlösungsansatz (project approach) und Projektmanagementstruktur (project management structure) – an den Subprozess IP (Initiating a project) statt. Für den Fall, dass Kunde und Dienstleister unterschiedlichen Firmen angehören, ist ein weiterer wichtiger Punkt innerhalb des DP1-Subprozesses zu überprüfen; wie nämlich die qualitätssichernden Standards, wie z. B. ISO9000, AQAP 130, SPICE usw., aufeinander abgestimmt werden können oder ob man sich auf einen Standard einigt. Eingangsprodukte sind: x Beschreibung der Aufgaben, die durchgeführt werden müssen (job definitions) x Beschreibung des Projektmanagement-Teams (project management team structure)


■ ■ ■

163

x Projektentwurf (project brief) x Risikoprotokoll (risk log) x Projektlösungsansatz (project approach) x Erste Version des Initiierungsphasenplans (draft initiation stage plan) Ausgangsprodukte sind: x Mitteilung über Projektstart (project start up notification) x Genehmigung zum weiteren Durchführen des Projektes (authorisation to proceed) x Überarbeiteter Projektentwurf (project brief) und Projektlösungsansatz (project approach) x Überarbeitetes Risikoprotokoll (risk log) x Überarbeitete erste Version des Phasenplans (draft initiation stage plan) Verantwortlich für die Durchführung des Subprozesses ist: x Lenkungsausschuss (project board) mit Unterstützung des Projektleiters und wesentlichen Abteilungen des Dienstleisters und Kunden

6.4.3.2 DP2 (Genehmigen eines Projektes) Innerhalb des PRINCE 2-Subprozesses DP2 wird überprüft, ob der vorliegende Business Case mit den Zielen der Firma und seiner zukünftigen Geschäftsprozesse noch zum gegenwärtigen Stand des Projektes übereinstimmt und wie lange es dauern wird, das anvisierte Projekt durchzuführen und welche Kosten und Risiken dabei entstehen werden. Abb. 6.45: Schematische Darstellung des DP2-Subprozesses

Prozessbeziehungen und Erzeugnisse von DP2 Input

IP6

Vorläufiges Projektleitdokument (draft pid)

SB1

Nächster Projektphasenplan (next stage plan)

Output

DP2 Genehmigen eines Projektes (authorising a project) Verantwortlich für diesen Prozess ist der Lenkungsausschuss mit Unterstützung des Projektleiters.

164

■ ■ ■

6 PRINCE 2

Genehmigung zur Projektdurchführung (authorisation to proceed)

Überprüftes Projektleitdokument (approved PID)

CS1


Wichtig dabei ist, dass die geschätzten Projektkosten und die Projektdauer ermittelt wurden. Wesentlich innerhalb des DP2-Subprozesses ist es auch festzustellen, ob das Projekt ausreichend und entsprechend seinen Aufgaben ordnungsgemäß überwacht und kontrolliert wird. Und zu guter Letzt wird innerhalb des PRINCE 2-Subprozesses DP2 die Entscheidung, ob das Projekt weiter fortgeführt werden soll, in Abhängigkeit vom Inhalt und Zustand des Projektleitdokuments (project initiation document, PID) getroffen. Abb. 6.46: Ab jetzt läuft die Zeit

Auch kann es bei diesem Subprozess passieren, dass Teile des Lenkungsausschusses dagegen sind, das Projekt weiterzuführen und andere dafür. Die Entscheidung kann davon abhängig gemacht werden, einzelne Punkte genauer zu überprüfen. Da die meisten größeren Projekte nach Abschluss einer Phase auch entsprechende finanzielle Transaktionen zum Dienstleister umfassen, muss hier genau feststehen, wie die Kriterien auszusehen haben, die es erlauben, entsprechende Geldmittel freizugeben. Eingangsprodukte sind: x Beschreibung der nächsten Projektphase (next stage plan) x Erste Version des Projektleitdokuments (project initiation document, PID) Ausgangsprodukte sind: x Überprüftes Projektleitdokument (project initiation document, PID) x Genehmigung zum weiteren Durchführen des Projektes (authorisation to proceed) Verantwortlich für die Durchführung des Subprozesses ist: x Lenkungsausschuss (project board) mit Unterstützung des Projektleiters (project manager)


■ ■ ■

165

6.4.3.3 DP3 (Genehmigen eines Etappen- oder Ausnahmeplans) Innerhalb des Subprozesses DP3 wird grundsätzlich jede neue Projektphase außer der Initiierungsphase freigegeben oder auch nicht. Um ein Projekt, das einmal gestartet wurde, auch nachträglich an bestimmten Punkten stoppen zu können, wenn es irgendwelche Ungereimtheiten oder schwerwiegenden Probleme gibt, wird mittels der Ausführung des Subprozesses DP3 sichergestellt, dass eine neue Phase eines Projektes erst dann durchgeführt wird, wenn der Lenkungsausschuss dafür grünes Licht gibt. Dies setzt natürlich voraus, dass ein Projekt von Anfang an in einzelne kontrollierbare Phasen (stages) unterteilt wird, die es auch erlauben, anstehende Probleme früh zu erfassen, um entsprechend darauf reagieren zu können. Hier ist es Aufgabe des Projektleiters, den Status des gegenwärtigen Projektes dem Lenkungsausschuss vorzutragen und diesen mit den bis dahin festgelegten Erwartungen zu vergleichen. Für die nächste Projektphase gibt er einen Überblick, den er aus dem nächst folgenden Phasenplan („stage plan“) entnimmt, für den er vom Lenkungsausschuss die Genehmigung zur weiteren Durchführung erhalten will. Unterlegt wird dies meist mit einem auf den aktuellsten Stand gebrachten Projektplan, aus dem die wesentlichen Eckdaten hervorgehen. Verglichen wird dieser Projektplan mit dem am Anfang aufgestellten Projektplan, um zu erkennen, ob das Projekt sich noch in einem gesunden Zustand befindet oder ob sich daraus schon wesentliche Veränderungen finanzieller, zeitlicher, risikobehafteter oder rechtlicher Eckpunkte ergeben. Abb. 6.47: Schematische Darstellung des DP3-Subprozesses

Prozessbeziehungen und Erzeugnisse von DP3

Input

SB5

Output Genehmigung zum weiteren Durchführen des Projektes, Projekttoleranzgrenzen, „Business Case“, Projektplan (authorisation to proceed, tolerances, business case, projekt plan)

Nächster Projektphasenplan, Veränderungen im Projektmanagement-Team, Projektplan (next stage plan, projectmanagement team changes, product checklist, project plan)

DP3 Genehmigen eines Etapenoder Ausnahmeplans

SB5

„Business Case“, Phsenabschlußreport, Risikoprotokoll, Antrag auf Genehmigung der nächsten Projektphase (business case, risk log, end stage report, request for authorisation to proceed)

Ausnahmeplan (exception plan)

IP6


166

■ ■ ■

CS1

Projektphasentoleranzwerte (project tolerances)

6 PRINCE 2

(authorising a stage or execption plan) Verantwortlich für diesen Prozess ist der Lenkungsausschus mit Unterstützung des Projektleiters.

Projektsachstandbericht (progress information)

Unternehmensund ProgrammManagement sowie andere interessierte Stellen

Abb. 6.48: Eintretende Risiken bescheren nicht selten einen Ausnahmeplan

Ist das Projekt Teil eines größeren Gesamtkomplexes, sind die Implikationen und Abhängigkeiten zu anderen Teilprojekten zu ermitteln. Wichtig ist auch die Prüfung, ob die gefundenen Projektrisiken und die dazu gefundenen Gegenmaßnahmen noch greifen. Ergeben sich aus dem jetzigen Zustand des Projektes Änderungen am Business Case, so muss der Lenkungsausschuss die Geschäftsleitung oder das Programm-Management einer Firma benachrichtigen. Dies kann z. B. wichtig sein, weil die Personalabteilung einer Firma Stellen für den Zeitpunkt der Einführung eines neuen DV-Verfahrens oder der damit realisierten Geschäftsprozesse ausschreibt, was besser verschoben werden sollte, weil sich der Termin zur Einführung des DV-Verfahrens auf einen späteren Zeitpunkt verschiebt. Manchmal kann es im Verlauf eines Projektes vorkommen, dass die Firmenleitung ihre finanziellen Ressourcen anderweitig binden muss, so dass für andere Projekte kein Geld mehr da ist und das Projekt erst einmal suspendiert wird. Auch in Fällen, in denen die vorher definierten Toleranzwerte (z. B. finanziell oder zeitlich) einer Etappe überschritten werden, muss der Lenkungsausschuss mittels eines Ausnahmestatusberichts (exception report) darauf hingewiesen werden. Dieser Ausnahmestatusbericht enthält die Gründe für die Toleranzverletzung und deren Auswirkungen. Er gibt dem Lenkungsausschuss Optionen oder Vorschläge innerhalb eines Ausnahmeplans (execption plan), wie weiter im Projekt verfahren werden soll. In diesem Fall muss der Lenkungsausschuss den Ausnahmeplan überprüfen (Projektplan, Risk log und business case) und gegebenenfalls genehmigen, so dass er den gegenwärtigen Phasenplan (stage plan) ersetzt. Der neue Sachstand wird ins Kalkül genommen, um festzustellen, ob das Projekt für eine Firma immer noch erstrebenswert ist. Der Lenkungsausschuss muss in diesem Fall sicherstellen, dass äußere Einflüsse und Abhängigkeiten gewahrt bleiben bzw. entsprechende Informationen über sich im Verlauf des Projekts ergebende Änderungen


■ ■ ■

167

offiziell übermittelt werden. Diese Informationen (wie z. B. Projektendzeitpunkt) sind für den inoder externen Kunden von besonderer Bedeutung, da er seine entsprechenden organisatorischen Planungen entsprechend anpassen muss. Eingangsprodukte sind: x Beschreibung der nächsten Projektphase (next stage plan) aus PRINCE 2-Subprozess SB5 oder Ausnahmeplan (exception plan) vom PRINCE 2-Subprozess SB6 x Produkt Checkliste (product checklist) x Überarbeiteter Projektplan (project plan) x Überarbeiteter Business Case x Projektleitdokument (project initiation document; PID) x Änderungen innerhalb der Struktur des ProjektmanagementTeams (PM team changes) x Überarbeitetes Risikoprotokoll (risk log) x Phasenabschlussreport (end stage report) x Antrag auf Genehmigung der nächsten Projektphase (request for authorisation to proceed) x Projektphasentoleranzwerte (project tolerances) Ausgangsprodukte sind: x offizielle Informationen über den Verlauf des Projektes an in- und externe Interessierte (progress information) x Genehmigung zur weiteren Durchführung des Projektes (authorisation to proceed) x Projektphasentoleranzwerte (project tolerances) x Business Case x Projektplan (project plan) Verantwortlich für die Durchführung des Subprozesses ist: x Lenkungsausschuss (project board) mit Zulieferung von Informationen und Daten durch den Projektleiter (project manager)

168

■ ■ ■

6 PRINCE 2

6.4.3.4 DP4 (Ad-hoc-Anweisungen geben) Auch wenn in einer Projektphase alles nach Plan läuft und die Projekttoleranzgrenzen (Zeit, Aufwand) eingehalten werden, kann es Situationen innerhalb eines Projektes geben, die den Rat des Lenkungsausschusses erfordern. Ergeben sich z. B. während des Projektes verschiedene Optionen, ein bestimmtes Ziel des Projektes zu erreichen, oder, falls Bedarf an weiteren Ressourcen (personell, organisatorisch, technisch, finanziell) besteht, so kann es notwendig sein, den Lenkungsausschuss davon zu unterrichten. Des Öfteren ist es auch so, dass Entscheidungen oder Anweisungen getroffen werden müssen, für die der Projektleiter nicht die ausreichenden Entscheidungsbefugnisse hat. Auch in Situationen, in denen es aus unterschiedlichen Gründen zu Konflikten durch Meinungsunterschiede bezüglich der einen oder anderen Auslegung eines Sachverhaltes kommt, ist die richtungweisende Entscheidung des Lenkungsausschusses von Vorteil. Vorstellbar sind auch Situationen, in denen ein Kunde nicht die erforderlichen Spezifikationen für ein zu entwickelndes Produkt liefert oder eine Kundenentscheidung auf die lange Bank geschoben wird und somit die terminlichen Erfordernisse durcheinander geraten. Es kann auch vorkommen, dass Kunden während eines Projektes den zugeordneten Projektverantwortlichen wechseln, der andere Prioritäten und somit eigentlich ein anderes Projekt im Sinn hat. Dies führt zu Konflikten, die mit Hilfe des Lenkungsausschusses geklärt werden müssen. In Situationen, bei denen abzusehen ist, dass bestimmte Toleranzgrenzen überschritten werden oder mögliche Projektrisiken sich zu manifestieren beginnen, ist es besser, den Lenkungsausschuss vorab zu informieren. Abb. 6.49: Schematische Darstellung des DP4-Subprozesses


■ ■ ■

169

Sind Informationen von firmenrelevanter Bedeutung aufgetreten, so muss der Lenkungsausschuss die Firmenleitung bzw. das Programm-Management einer Firma informieren. Aber auch, wenn der Lenkungsausschuss erweiterte Informationen zu einer Projektphase oder Änderungen in der Zusammensetzung des Lenkungsausschusses dem Projektteam oder dem Projektleiter weiterzugeben hat, ist der Subprozess DP4 (Ad-hoc-Anweisung geben) derjenige, der dies zu jedem Zeitpunkt einer Projektphase ermöglicht. Ist das zu realisierende Projekt Teil eines größeren, so kann es sein, dass das Programm-Management einer Firma Verzögerungen von anderen Teilprojekten bekannt gibt, die Auswirkungen auf das eigene Projekt vermuten lassen. Der Lenkungsausschuss muss sicherstellen, dass er bei schwerwiegenden Risiken eines Projektes den aktuellen Sachstand darüber in möglichst kurzen Zeitabständen erhält, um die Risiken mit seinen Möglichkeiten unter Kontrolle zu halten. Dabei kann es notwendig sein, die Anforderungen an das Projekt zu verkleinern, weitere Mitarbeiter und Ressourcen zuzuordnen, Projektleiter zu ersetzen oder aber das Projekt als Ganzes zu beenden. Notwendig ist es auch, dass alle notwendigen Informationen an die im Kommunikationsplan benannten Ansprechpartner versendet werden, um auf gewisse Sachverhalte hinzuweisen und zu informieren. Eingangsprodukte sind: x Projektstatusbericht (highlight report) x Ausnahmestatusbericht (exception report) x Beratungsantrag (request for advice) x Informationen von oder für in- und externe Stellen (information from and to external sources) x Kommunikationsplan (communication plan) x Informationen mit Projektbezug von inoder externen Quellen bzw. von der Firmenleitung oder dem Programm-Management einer Firma (information from and to external sources or from the corporate or programme management) Ausgangsprodukte sind: x Projektstatusberichte an die Firmenleitung bzw. an das Programm-Management einer Firma x Anweisung zur Erstellung eines Ausnahmeplans (execption plan request)

170

■ ■ ■

6 PRINCE 2

x Neue Toleranzwerte (new tolerances) x Anweisung zur vorzeitigen Beendigung des Projektes (premature close) x Informationen mit Projektbezug von inoder externen Quellen bzw. von der Firmenleitung oder dem Programm-Management einer Firma (information from and to external sources or from the corporate or programme management) Verantwortlich für die Durchführung des Subprozesses ist: x Lenkungsausschuss (project board) mit der Unterstützung von allen Mitarbeitern mit Projektkontrollaufgaben inklusive Projektleiter (project manager)

6.4.3.5 DP5 (Bestätigen des Projektabschlusses) Wahrscheinlich ist der Subprozess DP5 die Belohnung für das Projektgeschäft mit seinen Höhen und Tiefen, indem das Endprodukt mit seinen Rechten und Pflichten formell an den Nutzer bzw. Kunden übergeben wird. Hierbei muss auch sichergestellt sein, dass das zu übergebende Endprodukt beim Nutzer bzw. Kunden die entsprechende Infrastruktur vorfindet, die es benötigt. Der Projektleiter leitet diese Phase des Projektes ein, indem er entsprechende Dokumente erstellt und die Kommunikation mit dem Nutzer bzw. Kunden gesucht hat und der Kunde rein formal die Abnahmeerklärung unterschrieben hat. Der Projektleiter legt dem Lenkungsausschuss nach Durchführung dieser letzten Phase den Antrag zur offiziellen Beendigung des Projektes vor, was nach der Genehmigung durch den Lenkungsausschuss dazu führt, dass sich dieser auflösen kann. Er gibt die

Prozessbeziehungen und Erzeugnisse von DP5 Input

CP1

Funktions- und Wartungsfähigkeits-Bestätigung, Projektabnahme des Kunden, Projektabschlussempfehlung (operational and maintenance acceptance, customer acceptance, project closure recommendation)

Output

DP5

Benachrichtigung über Projektabschluss, Empfehlungen für Folgeaktionen, Projektbeurteilungsplan, Erfahrungsbericht (project closure notification, follow on action recommendations, post implementation review plan, lessons learned report)


Abb. 6.50: Schematische Darstellung des DP5-Subprozesses

Bestätigen des Projektabschlusses (confirming project closure)

CP2

Projektbeurteilungsplan, Empfehlungen für Folgeaktionen (post implementaion review plan, follow on action recommendations)

CP3

Erfahrungsbericht, Projektabschlussbericht (lessons learned report, end project report)

DP2

Kommunikationsplan (project initialisation document; PID)

Verantwortlich für diesen Prozess ist der Lenkungsausschuss mit Unterstützung des Projektleiters.


■ ■ ■

171

Ressourcen (personell, finanziell, technisch), die zur Durchführung des Projektes benötigt wurden, wieder frei. Der Projektleiter gibt innerhalb eines Projektabschlussberichts (end project report) den Sachstand am Ende des Projektes wieder. Auch verfasst der Projektleiter einen Erfahrungsbericht (lessons learned report), in dem er wesentliche Erkenntnisse, die er während des Projektes erworben hat, niederschreibt, damit andere Projekte davon profitieren können. Während dieser Phase muss der Projektleiter darauf achten, dass der Nutzer bzw. Kunde das Endprodukt überprüft und formell abgenommen hat. Abb. 6.51: Am Ende eines Projektes kommt die Bewertung

Dabei kann es notwendig sein, noch kleinere Änderungen am Endprodukt vorzunehmen. Diese werden dann innerhalb eines Dokumentes als Empfehlung für Folgeaktionen (follow on action recommendations) erfasst. Der Lenkungsausschuss vergleicht die im Projektleitdokument (project initiation document, PID) gemachten Annahmen mit dem vorliegenden Projektsachstand. Weiterhin verfasst der Lenkungsausschuss einen Projektabschlussbericht, den er an die Firmenleitung bzw. das Programm-Management einer Firma übermittelt und in dem er rein formal seine Auflösung bekannt gibt. Hat der Dienstleister für einen externen Kunden das Projekt durchgeführt, so kann die Rechnungsabteilung nun vom Kunden den Restbetrag für die Durchführung des Projektes verlangen. Eingangsprodukte sind: x Projektleitdokument (project initiation document; PID) x Genehmigter Erfahrungsbericht (lessons learned report) x Offizielle Kundennabnahmebestätigung des Endproduktes (customer acceptance) x Funktions- und Wartungsfähigkeitsbestätigung (operational and maintenance acceptance)

172

■ ■ ■

6 PRINCE 2

x Projektabschlussempfehlung (project closure recommendation) x Projektabschlussbericht (end project report) x Genehmigtes Dokument „Empfehlungen für Folgeaktionen“ (follow-on action recommendations) x Genehmigtes Dokument „Projektbeurteilungsplan“ (post implementation review plan) x Projektabschlussbericht (end project report) Ausgangsprodukte sind: x Projektbeurteilungsplan (post implementaion review plan) x Empfehlungen für Folgeaktionen (follow-on action recommendations) x Erfahrungsbericht (lessons learned report) x Genehmigung des Antrags zur Beendigung des Produktes (Projektabschlussempfehlung, project closure recommendation) x Projektabschlussmeldung (project closure notification) Verantwortlich für die Durchführung des Subprozesses ist: x Lenkungsausschuss (project board) mit Zulieferung von Fakten durch den Projektleiter (project manager)

6.4.4 CS (Steuern einer Projektphase) Hat man sich dafür entschieden, eine Projektphase durchzuführen, so muss diese auch entsprechend kontrolliert werden, damit am Ende einer Projektphase das Projektphasenziel mit den vereinbarten qualitativen Eigenschaften innerhalb des festgelegten Zeit-, Aufwandund Kostenrahmens erreicht wird. Auch muss unter gewissen internen oder externen Umständen eventuell das Projekt als ganzes neu aufgesetzt oder beendet werden. Die ordnungsgemäße Zuteilung von notwendigen Ressourcen (personell, technisch, finanziell) im benötigten Zeitrahmen sowie die notwendigen Reaktionen auf abweichende Entwicklungen im Zeitund Kostenrahmen sind Tätigkeitsschwerpunkte der CS-Subprozesse. Notwendig ist dabei sicherzustellen, dass der „rote Faden“ zum Ziel des fertigen Endproduktes nicht verloren geht und der Umfang der durchzuführenden Tätigkeiten überschaubar bleibt.


■ ■ ■

173

Abb. 6.52: Der PRINCE 2CS-Prozess im Überblick

Die Subprozesse des PRINCE-CS-Prozesses behandeln die auftauchenden situationsbedingten Probleme und Umstände einer Projektphase und sorgen dafür, dass alle beteiligten in- und externen Interessensgruppen (Kunden, Firmenleitung oder Programm-Management) über den Fortschritt eines Projektes informiert sind. Bei Problemen in Projekten liegt natürlich die Kunst darin, trotz aller negativen Einflüsse doch noch die Projektziele zu erreichen, die im Business Case niedergeschrieben wurden. Da der Subprozess CS oft mit schlechten Nachrichten und einer Verantwortungszuweisung in Verbindung steht, ist dies ein sehr emotionaler Prozess. Ziel des CS-Prozesses ist es, Probleme schnell zu erkennen und kühle rationale Wege einzuschlagen, die es ermöglichen, das Projektziel dennoch zu erreichen. Wichtig dabei ist, dass ein offenes, vertrauensvolles Verhältnis besteht und der Überbringer von schlechten Nachrichten nicht „geköpft“ wird. Abb. 6.53: Verzahnung des CS-Prozesses

CS7

CS8 CS9

CS6 CS5

CS

CS4 CS3

CS1 CS2

174

■ ■ ■

6 PRINCE 2

DP3

Abb. 6.54: Schematische Übersicht über den PRINCE 2 Subprozess CS


■ ■ ■

175

Der Projektleiter muss neben der Bereitschaft, rund um die Uhr zu arbeiten, auch ein Kommunikationsgenie sowie konfliktfähig sein. Nachfolgend eine Übersicht über die einzelnen Subprozesse CS1 bis CS9 des PRINCE-Processes CS. Abb. 6.55: Subprozess CS in den verschiedenen Phasen (1, 2 … n) eines Projektes

176

■ ■ ■

6 PRINCE 2

Subprozesse Inhalt/Deutsch des PRINCE 2CS-Prozesses

Inhalt/Englisch

CS1

Freigeben eines Arbeitspaketes Authorising Work Package

CS2

Überwachen des Fortschrittes

CS3

Erfassen von projektrelevanten Capturing Project Issues Themen und Problemen

CS4 CS5

Überprüfen von projektreleExermining Project Issues vanten Themen und Problemen Prüfen des Phasenstatus Reviewing Stage Status

CS6

Projektstatus übermitteln

Reporting Highlights

CS7

Einleiten von Korrekturmaßnahmen Eskalieren von Projektproblemen Entgegennehmen von abgeschlossenen Arbeitspaketen

Taking Corrective Action

CS8 CS9

Assessing Progress

Tabelle 6.5: Überblick über die Subprozesse von CS (Steuern einer Projektphase)

Escalating Project Issues Receiving Completed Work Package

6.4.4.1 CS1 (Freigeben eines Arbeitpaketes) Der Sinn, der dem Subprozess CS1 zugrunde liegt, ist der, dass ein Arbeitspaket erst dann angefangen werden soll, wenn der Projektleiter der Meinung ist, dass die entsprechenden Voraussetzungen vorliegen. Dies kann z. B. davon abhängig sein, ob entsprechende personelle Ressourcen oder Informationen vorhanden sind, die das Arbeitspaket erfordert. Es soll sichergestellt werden, dass die durchzuführenden Arbeitspakete kontrolliert ablaufen können. Dazu gehört neben der benötigten Arbeitspaketbeschreibung auch die Feststellung, wie über den Verlauf der Tätigkeiten Rechenschaft abgelegt werden soll. Grundsätzlich muss der Projektleiter auch erst einmal sicherstellen, dass entsprechende personelle Ressourcen mit den entsprechenden Fachkenntnissen zum Entwickeln des Teilproduktes im angestrebten Zeitrahmen vorhanden sind. Der Projektleiter muss sicherstellen, dass das Arbeitspaket (work package) genau das Teilprodukt erzeugt, das der inoder externe Kunde auch haben möchte. Dabei kann es auch bestimmte Voraussetzungen für die Herstellung des Arbeitspakets geben. So kann es z. B. sein, dass Testdaten erforderlich sind, um die Wirkungsweise des zu entwickelnden Teilproduktes testen zu können. Oder es kann bestimmtes technisches Equipment notwendig sein, wie z. B. eine Entwicklungsplattform, um das Teilprodukt damit erstellen zu können. Manchmal liegen auch einfach nur weitere Informationen vor,


■ ■ ■

177

Abb. 6.56: Schematische Darstellung des CS1-Subprozesses

die in eine bestehende Arbeitspaketbeschreibung einfließen. Dies können z. B. erweiterte Anforderungen, Dokumentationen, genauere spezifizierte Beschreibungen, Ansprechpartner, Verantwortlichkeiten oder der Zeit-, Kosten- und Aufwandsrahmen, in dem sich das Arbeitspaket bewegen soll, sein. Diese Informationen münden dann in einer veränderten Handlungsanweisung (plan adjustments). Abb. 6.57: Spannungsfeld eines Projektes

Sind größere Entwicklerteams mit der Durchführung von Arbeitspaketen betraut, so übergibt der Projektleiter dem entsprechenden Leiter des Entwicklerteams die Aufgabenbeschreibung (work package) für das Arbeitspaket. Wird das Arbeitspaket extern vergeben, so sind alle diesbezüglichen Vorgänge zu protokollieren und eventuell vorher eine Marktsichtung von verschiedenen bestehenden externen Dienstleistern durchzuführen. Dies betrifft auch die zu vereinbarenden Qualitäts- und Prüfrichtlinien, die einzuhalten sind. Eingangsprodukte sind: x Phasen- oder Ausnahmeplan (stage or exception plan) x Endproduktbeschreibung (product descriptions)

178

■ ■ ■

6 PRINCE 2

x Arbeitspaketbeschreibung (proposed work package) x Genehmigung zur Durchführung des Arbeitspaketes (authorisation to proceed) x Änderungsanweisungen des Arbeitspaketes (work trigger) Ausgangsprodukte sind: x Arbeitspaket (work package)

x Veränderte Handlungsanweisung (plan adjustments) Verantwortlich für die Durchführung des Subprozesses ist: x Projektleiter und Entwicklungsteamleiter

6.4.4.2 CS2 (Überwachen des Fortschritts) Damit die richtigen Entscheidungen zum richtigen Zeitpunkt erfolgen können, ist es notwendig, einen realistischen Sachstand über jedes bearbeitete Arbeitspaket zu erhalten. Hierfür ist eine ausreichende Kontrolle und Informationsfluss in vorher definierten Zeitabständen (checkpoints) erforderlich, damit nicht ein reaktives Management in Form von Feuerwehreinsätzen durchgeführt werden muss, sondern ein proaktives, das auf potentielle Risikosituationen im Vorfeld reagiert. Reaktives Management führt meist dazu, dass man in Details untergeht und dabei die generelle Zielrichtung aus dem Auge verliert. Gespür und analytisches Geschick zum Aufspüren möglicher Fehlentwicklungen im Verlauf einer Projektphase macht einen guten



■ ■ ■

179

Projektleiter aus. Die notwendigen Informationen kommen entweder vom Entwicklungsgruppenleiter oder bei kleineren Projekten von den mit der Aufgabe betrauten Entwicklern. In diesem Zusammenhang ist es auch notwendig, den geschätzten, noch zu leistenden Aufwand und gegenwärtigen Fertigungsgrad zu wissen, damit man erkennen kann, wo eventuelle Schwierigkeiten aufgetreten, um eventuell Hilfe anzubieten. Auch sollte routinemäßig der Verfügbarkeitszeitraum von Ressourcen (personell, technisch, infrastrukturell) ermittelt werden, da in einer schnelllebigen Zeit häufig Änderungen auftreten können. Da kann es schon mal vorkommen, dass ein wichtiger Mitarbeiter vom Abteilungsleiter aus einem Projekt herausgenommen wird, um in einem anderen Projekt kurzfristig auszuhelfen. Oder dass ein Mitarbeiter auf einmal an zwei Projekten gleichzeitig arbeiten muss, was natürlich schlecht für den Zeitplan ist, da er nun die doppelte Zeit dafür benötigt. Der aktuelle Phasenplan ist immer mit den ermittelten Daten abzugleichen, so dass er den gegenwärtigen situationsbedingten Stand des Projektes erfasst. Die Überwachung kann in fest definierten zeitlichen Abständen (Checkpoint) erfolgen oder, wenn es die Lage erfordert, zu jedem vereinbarten Zeitpunkt als Assessment. In der Praxis bekommt der Entwicklungsteamleiter von den einzelnen Entwicklern einen Wochenbericht, in dem diese knapp berichten, woran sie arbeiten, wieviel Zeit sie dafür schon verbraucht

Abb. 6.59: Projektstatus mittels „Earned Value Analysis“

180

■ ■ ■

6 PRINCE 2

Anforderungen an die IT des Unternehmens -

Technologische Innovation

bs er w t e i b et ke W hig ä f

Abb. 6.60: Die IT eines Unternehmens ist vielen Einflüssen unterworfen

Verordnungen und Gesetze

haben, welche Schwierigkeiten es gibt und wieviel Prozent ihrer Arbeit an Teilen des Arbeitspaketes schon durchgeführt wurde (earned value analysis, EVA). Der Teamleiter fasst diese Ergebnisse zusammen und erstellt anhand der Daten einen Wochenbericht (earned value analysis, EVA) über das Arbeitspaket, den er an den Projektleiter übermittelt. Dieser muss dann anhand der Daten und der Informationen, die er außerdem zur Verfügung hat, entscheiden, ob sie akkurat und objektiv sind, und wenn er Zweifel hat, diese in direkten Gesprächen ausräumen. Eine weitere Aufgabe des Projektleiters ist zu verfolgen, welche qualitätssichernden Maßnahmen des Qualitätsplans auf das entstehende Arbeitspaket angewendet wurden. Hat der Projektleiter verschiedene Wochenberichte (earned value analysis, EVA) einzelner Teilprodukte, so fasst er diese zusammen in einen gesamten Wochen- oder Monats-Statusbericht und übermittelt diesen an alle interessierten Stellen. Eingangsprodukte sind: x Teamstatusberichte (checkpoint reports) x Projektqualitätslogbuch (quality log) x Veränderte Handlungsanweisung (plan adjustments) x Phasenplan (stage plan) x Arbeitspaketstatus (work package status)


■ ■ ■

181

Ausgangsprodukte sind:

x Überarbeiteter Phasenplan (updated stage plan) Verantwortlich für die Durchführung des Subprozesses ist: x Projektleiter und Entwicklungsteamleiter

6.4.4.3 CS3 (Erfassen von projektrelevanten Themen und Problemen) Kein Projekt und keine Projektphase wird ohne spezifische Probleme und Änderungswünsche bleiben. Dies liegt daran, dass sich das Endprodukt langsam entwickelt und der Blick somit auf die nicht vorhersehbaren Dinge bzw. auf nicht spezifizierte Punkte fällt. Der Subprozess CS3 soll sich dieser Problematik annehmen, so dass nichts vergessen wird und die Probleme in angemessener Art und Weise behandelt werden. Abb. 6.61: Schematische Darstellung des CS3-Subprozesses

E X T E R N E E I N F L Ü S S E

Prozessbeziehungen und Erzeugnisse von CS 3 Input Problemprotokoll (issue log)

Output

CS3 Erfassen von projektrelevanten Themen und Problemen (Capturing Project Issues)

Neue Projektprobleme (new project issues)

Überarbeitetes Problemprotokoll ( Updated issue log)

CS4


Der Subprozess CS3 erfasst entsprechende Themen, Änderungswünsche und Probleme, die dann im Subprozess CS4 weiter verfolgt werden. Beispiele für relevante Probleme und Änderungen sind z. B. personelle, technische und infrastrukturelle Veränderungen und Probleme. Manche neuen Projektrisiken werden auf diesem Weg erfasst und finden dann, wenn sie als neu klassifiziert wurden, in der späteren Bearbeitung ihren Weg in den Risikokatalog (risk log).

182

■ ■ ■

6 PRINCE 2

Auch wenn für Probleme noch keine Lösungen gefunden wurden, ist es wichtig, diese zu erfassen und mit einem Gewichtungsfaktor zu versehen, in welchem sie behandelt werden sollen. Manche Probleme haben einen direkten Einfluss auf den Phasenplan. Diesen zu quantifizieren ist, sofern im Subprozess CS3 überhaupt möglich, dann Aufgabe vom Subprozess CS4. Eingangsprodukte sind: x Problemprotokoll (issue log) x Neue Projektprobleme (new project issues) Ausgangsprodukte sind: x Überarbeitetes Problemprotokoll (issue log) Verantwortlich für die Durchführung des Subprozesses ist: x Projektleiter (project manager)

6.4.4.4 CS4 (Überprüfen von projektrelevanten Themen und Problemen) Bei der Überprüfung von Projektproblemen, Änderungswünschen und allgemeinen Veränderungen im Projektumfeld muss jeweils geklärt werden, welchen Einfluss diese auf die jetzige Projektsituation oder Projektphase haben (personelle, zeitliche, qualitative, organisatorische, finanzielle, technische, produktbezogene, risikobezogene, Anforderung an das Endprodukt, Anforderungen an Qualitätsstandards Abb. 6.62: Schematische Darstellung des CS4-Subprozesses


■ ■ ■

183

und Verfahren, Veränderungen an anderen Teilkomponenten impliziert). Ebenso ist die Dringlichkeit der auftretenden Probleme einzuschätzen und mit einem Gewichtungsfaktor zu versehen. Es ist die Frage zu stellen, ob durch die Probleme die Ziele des Business Case gefährdet sind und ob sich die Probleme somit zu Projektrisiken entwickeln. Es ist zu überlegen, wer am besten über die Problematik eine Aussage treffen und entsprechende Lösungsvorschläge vorbereiten kann. Auch sollten hier schon Alternativmöglichkeiten angedacht werden, um diesen Problemen zu begegnen, und die entstehenden Kosten sollten abgeschätzt werden. Ziel ist es, allgemeine Vorschläge und Ansätze zu erarbeiten, um Probleme aktiv zu lösen und den angestrebten Zeit- und Kostenrahmen des Projektes beibehalten zu können. Abb. 6.63: Aktivitäten, Verantwortlichkeiten und Termine

Durchzuführende Aktivitäten ProjektCondor Condor Projekt Nr.

Aktivität

1.

Erstelle Produktplan

Verantw. Zeit Hale

2.

Budget kalkulieren

Dixon

3.

Risiken analysieren

Jillson

5.

Entwicklungstool installieren

Bigar

6.

Schulungen

Athenaeum

1 KW 3 KW 5 KW 7 KW

Hierbei sind auch Vorschläge notwendig, wer und was bei den entsprechenden Problemen helfen kann. Alle Probleme einer bestimmten Kategorie werden innerhalb des Subprozesses CS4 ins Risikoprotokoll (risk log) übertragen. Eventuell kann es notwendig sein, offiziell den Projektphasenstatus zu verändern. Dies passiert dann im Subprozess CS5. Eingangsprodukte sind: x Business Case x Projektphasenplan (stage plan) x Problemprotokoll (issue log) x Risikoprotokoll (risk log) x Projektplan (project plan)

184

■ ■ ■

6 PRINCE 2


x Überarbeitetes Problemprotokoll (updated issue log) x Überarbeitetes Risikoprotokoll (updated risk log) Verantwortlich für die Durchführung des Subprozesses ist: x Projektleiter sowie der zugeordnete Gruppen- oder Teamleiter. Die einzelnen Projektmitglieder liefern spezifische Informationen.

6.4.4.5 CS5 (Prüfen des Phasenstatus) Eine periodische Überprüfung (je nach Größe des Projektes etwa alle 23 Wochen) externer Ereignisse, die das Projekt negativ beeinflussen könnten, ist ebenso notwendig wie das tägliche Problemlösen. Eine regelmäßige Überprüfung über Soll und Ist wesentlicher Projektkenndaten sowie des kritischen Pfades (Critical Path) im Projektplan ist Pflicht. Durch das Tagesgeschäft des Projektleiters, das des Öfteren von Problemlösungen für Teile eines Arbeitspaketes geprägt ist, kann es vorkommen, dass das endgültige Ziel aus den Augen verloren wird. Deswegen ist es notwendig, dass eine allgemeine Überprüfung des Zustands eines Projektes in festen Zeitabständen erfolgt. Dies kann in Form eines Assessments durchgeführt werden, innerhalb dessen entschieden wird, weitere kleinere Arbeitspakete durchzuführen und den Projektplan entsprechend anzupassen. Innerhalb dieses Assesments sollten die im Folgenden beschriebenen Abb. 6.64: Schematische Darstellung des CS5-Subprozesses


■ ■ ■

185

Punkte überprüft werden. Da ist zum einen zu überprüfen, wie groß der tatsächliche Fortschritt des Projektes, gegenüber dem innerhalb der Projektphase als Sollwert beschriebenen, eigentlich ist. Des Weiteren muss die Auslastung und zeitliche Verfügbarkeit der erforderlichen Ressourcen (personell, technisch, finanziell, infrastrukturell) für die nächste Zeitperiode überprüft werden. Auch muss abgeschätzt werden, welchen Einfluss die bisher aufgetretenen Probleme und Risiken auf den gegenwärtigen Projektplan haben. Weiterhin muss überprüft werden, ob die Projektziele, die im Business Case niedergeschrieben sind, noch erreicht werden können. Ein Überprüfen des Risikokatalogs mit seinen enthaltenen potentiellen Projektrisiken ermöglicht festzustellen, ob neue Risiken hinzugekommen sind, die festgehalten werden müssen. Wenn die gegenwärtigen Kenndaten der Projektphase innerhalb der vom Lenkungsausschuss vorgegebenen Toleranzen liegt, dann ist es die Aufgabe des Projektleiters, innerhalb des Subprozesses CS6 einen Sachstandsbericht (reporting highlights) anzufertigen und an den vorher definierten Verteiler zu versenden. Sind nicht vorhergesehene Probleme und Risiken aufgetreten und erscheint es dennoch sicher, dass die Toleranzgrenzen für diese Projektphase nicht überschritten werden, dann werden innerhalb des Subprozesses CS7 die notwendigen problemlösenden Maßnahmen eingeleitet. Abb. 6.65: Ohne Subprozess CS5 kann es ganz schön peinlich werden

Stellt sich beim Assessment aber heraus, dass durch nicht vorhersehbare Probleme die definierten Toleranzgrenzen für diese Projektphase überschritten werden, so sollte innerhalb des Subprozesses CS8 der Lenkungsausschuss informiert werden und entsprechender Rat und Entscheidungsrichtlinien für die Problembehebung eingeholt werden.

186

■ ■ ■

6 PRINCE 2

Eingangsprodukte sind: x Phasenplan (stage plan) x Problemprotokoll (issue log) x Risikoprotokoll (risk log) x Projektphasentoleranzwerte (tolerances) x Business Case x Projektplan (project plan) Ausgangsprodukte sind: x Festgestellte Planabweichung (plan deviation) x Phasenplanstatus (stage status information) x Benachrichtigung über das Projektphasenende (stage end notification) x Benachrichtigung über das Projektende (notification of project end) x Korrekturmaßnahmen (work trigger) x Projektphasenplan (stage plan) x Projektprobleme (project issue) Verantwortlich für die Durchführung des Subprozesses ist: x Projektleiter sowie der zugeordnete Gruppen- oder Teamleiter. Die einzelnen Projektmitglieder liefern spezifische Informationen. Der Lenkungsausschuss gibt weitere Informationen und berät.

6.4.4.6 CS6 (Projektstatus übermitteln) Da der Lenkungsausschuss verantwortlich ist für den erfolgreichen Ausgang eines Projektes, die tägliche Arbeit und Verantwortung aber beim Projektleiter liegt, ist er von den regelmäßigen Informationen (Projekt- oder Phasen-Fortschritt bzw. -stand, aufgetretene Probleme und Fragen) über den Sachstand des Projektes abhängig. Der Subprozess CS6 soll sicherstellen, dass der Lenkungsausschuss und alle wesentlichen Stellen, wie z. B. der inoder externe Kunde über alle wesentlichen Dinge informiert wird. Sollte der Lenkungsausschuss eine bestimmte Form des Sachstandsberichts (highlight report) bevorzugen, so ist dies zu berücksichtigen.


■ ■ ■

187


Innerhalb des Subprozesses CS6 sind alle wesentlichen gegenwärtigen oder zukünftigen Probleme zu benennen und auf signifikante Phasenplanänderungen hinzuweisen. Durch Kontrolle des Problemprotokolls (issue log) und des Risikoprotokolls (risk log) wird sichergestellt, dass keine wesentlichen Probleme des Projektes vergessen werden. Der Kommunikationsplan ist daraufhin zu untersuchen, ob alle an dem Projektsachstand interessierten Stellen enthalten sind und ob die definierten Zeitabstände, in denen eine Information erfolgt, noch ausreichend sind. Eingangsprodukte sind: x Problemprotokoll (issue log) x Teamstatusberichte (checkpoint reports) x Toleranzwerte aus dem Risikoprotokoll (risk log tolerances) x Kommunikationsplan (communication plan) x Angepasster Projektphasenplan (stage plan) x Status des Arbeitspaketes (work package status) Ausgangsprodukte sind: x Sachstandsbericht (highlight report) x Benachrichtigungen entsprechend Kommunikationsplan (communications to interested parties) Verantwortlich für die Durchführung des Subprozesses ist: x Projektleiter (project manager)

188

■ ■ ■

6 PRINCE 2

6.4.4.7 CS7 (Einleiten von Korrekturmaßnahmen) Sind während eines Projektes Abweichungen gegenüber dem aufgestellten Projekt- oder Phasenplan aufgetreten, so müssen notwendige Maßnahmen und Anpassungen innerhalb des Projektes durchgeführt werden. Diese sollen erreichen, dass das Projekt- oder Phasenziel doch noch zu erreichen ist. Der Subprozess CS5 aktiviert den Subprozess CS7, um festgestellte Abweichungen oder notwendige Korrekturen einzuleiten. Abb. 6.67: Schematische Darstellung des CS7Subprozesses

Hierfür ist es erforderlich, den gegenwärtigen Sachstand über die Dinge zu erhalten, die für die Abweichungen verantwortlich sind. Danach müssen der aktuelle Phasenplan überarbeitet und die notwendigen Maßnahmen eingeleitet werden. Auch muss geprüft werden, welche Auswirkung sich dadurch auf den Bussiness Case ergeben. Der Lenkungsausschuss kann vom Projektleiter um Entscheidungsfindung oder um Rat innerhalb des Subprozesses DP4 angegangen werden. Abb. 6.68: Sind Korrekturmaßnahmen nötig, so sollten die nächsten Schritte genau definiert sein


■ ■ ■

189

Eingangsprodukte sind: x Planabweichung (plan deviation) x Risikoprotokoll (risk log) x Problemprotokoll (issue log) x Projektphasenplan (stage plan) Ausgangsprodukte sind: x Antrag auf Problemerörterung mit Lenkungsausschuss (request for advice) x Beabsichtigte Korrekturmaßnahmen (work trigger) x Überarbeiteter Projektphasenplan (stage plan) Verantwortlich für die Durchführung des Subprozesses ist: x Projektleiter sowie die zugeordneten Gruppen- oder Teamleiter.

6.4.4.8 CS8 (Eskalieren von Projektproblemen) Fast jedes Projekt kommt irgendwann einmal in die Situation, dass die für eine Projektphase vorgesehene Toleranzbreite überschritten wird. Wichtig beim Projektmanagementframework PRINCE 2 ist dabei, dass dies innerhalb kürzester Zeit, nachdem das Problem erkannt wurde, mit der Zustimmung des Lenkungsausschusses passiert. Oft passiert dies in drei Schritten: Zuerst die Information, dass Probleme aufgetreten sind, dann eine Beschreibung der Probleme

Abb. 6.69: Schematische Darstellung des CS8-Subprozess

190

■ ■ ■

6 PRINCE 2

und dann der Ausnahmeplan (exception plan). Der Projektleiter sollte dem Lenkungsausschuss stets außer der Information über gegenwärtige Schwierigkeiten einen Problemlösungsansatz vorlegen können. Oft geht dem Präsentieren eines Ausnahmeplans (exception plan) eine Information über bestehende Probleme oder eine Verletzung der Projektphasentoleranzgrenzen voraus. Gründe für das Überschreiten von Projektphasentoleranzgrenzen können vielfältiger Natur sein, angefangen bei einer schlechten Schätzung von Zeit- und Ressourcenbedarf bis hin zu der Verfügbarkeit von Ressourcen (personellen, technischen, finanziellen, infrastrukturellen) oder von plötzlich aufgetauchten Problemen, die es zum Beispiel notwendig machen, bestimmte Teile eines Arbeitspaketes zu überarbeiten oder ganz einfach zusätzliche ungeplante Teile von Arbeitspaketen durchführen zu müssen. Abb. 6.70: Frühzeitiger Alarm führt zu frühzeitigen Problemlösungen

Der Subprozess CS8 kommt dann zum Tragen, wenn abzusehen ist, dass trotz Einleiten von Korrekturmaßnahmen die Projektphasentoleranzen überschritten werden. Wichtig ist, dass der volle Umfang der entstehenden Auswirkungen auf das Projekt festgestellt wird. Die Reaktion des Lenkungsausschusses kann unterschiedlicher Natur sein. Er kann den Ausnahmeplan (exception plan) billigen, so dass aus diesem dann der aktuelle Projektphasenplan wird, oder aber die qualitativen Projektphasenanforderungen heruntersetzen. Der Ausnahmeplan (exception plan) enthält Details über Kosten, Endzeitpunkt der Arbeiten, Qualitätsdetails sowie Informationen über den Bereich des Projektes, der davon betroffen wird. Oft ist es notwendig, den Projektplan, Bussiness Case sowie das Risikoprotokoll (risk log) zu modifizieren. Eingangsprodukte sind: x Projektleitdokument (Project Initiation Document; PID) x Projektphasenplan (stage plan) x Business Case


■ ■ ■

191

x Projektplan (project plan) x Problemkatalog (issue log) x Risikokatalog (risk log) Ausgangsprodukte sind: x Entscheidung des Lenkungsausschusses (project board responses) x Problembeschreibung und dessen Auswirkung (exception report with stage plan) Verantwortlich für die Durchführung des Subprozesses ist: x Projektleiter (project manager) sowie der zugeordnete Gruppenoder Teamleiter.

6.4.4.9 CS9 (Entgegennehmen von abgeschlossenen Arbeitspaketen) Immer dann, wenn es um die Fertigstellung eines Arbeitspaketes geht, sollten auch alle der Meinung sein, dass das Arbeitspaket wirklich abgeschlossen wurde. Je nach Informationsstand kann es dabei zu unterschiedlichen Meinungsbildern kommen. Um dies zu erleichtern, wird das Arbeitspaket vorher festgelegten Abnahmekriterien unterworfen und getestet. Dabei sollten die Anforderungen an das Arbeitspaket und die Rahmenbedingungen, die am Anfang definiert wurden, erfüllt sein. Nachdem dann das Arbeitspaket offiziell als fertig eingestuft wurde, kann es nur mittels einer offiziellen Änderungsanforderung modifiziert werden. Abb. 6.71: Sematische Darstellung des CS9-Subprozesses

192

■ ■ ■

6 PRINCE 2

Eingangsprodukte sind: x Überprüftes und abgenommenes Arbeitspaket (approved work package) Ausgangsprodukte sind: x Arbeitspaketstatus (work package status) Verantwortlich für die Durchführung des Subprozesses ist: x Projektleiter sowie Entwicklungsteamleiter und dessen Entwickler

6.4.5 MP (Managen der Produktlieferung) Der PRINCE-Prozess MP erlaubt das kontrollierte Vorgehen für den Fall, dass der Projektleiter Arbeitspakete an die interne Entwicklungsabteilung oder an Dritte vergeben muss, die nicht Teil seiner Firma oder Organisation sind. Ziel der Subprozesse von MP ist es sicherzustellen, dass der inoder externe Dienstleister und der Projektleiter eine Übereinkunft darüber erzielen, was herzustellen ist und dass der inoder externe Dienstleister das Arbeitsprodukt herstellt und es als letzten Schritt dem Projektleiter übergibt. Dabei ist auch zu bedenken, dass der externe Dienstleister dieselben Fertigungs- und Qualitätsstandards unterstützt und das Projektmanagement im Optimalfall auf PRINCE 2-Prozessen basiert. MP (Managen der Produktlieferung )

MP1 (Annehmen eines Arbeitspaketes )

Abb. 6.72: Der PRINCE 2MP-Prozess im Überblick

MP2 (Durchführen eines Arbeitspaketes )

MP3 (Liefern eines Arbeitspaketes )

Sicherstellung des Endproduktes


■ ■ ■

193

Der Projektleiter muss sicherstellen, dass entsprechende Ressourcen (personell, finanziell, zeitlich, infrastrukturell) vorhanden sind und dass die notwendigen Arbeiten effektiv verrichtet werden. Er muss in regelmäßigen Zeitabständen den Fertigungsstand des Arbeitspaketes überprüfen und entsprechende Voraussagen über Endtermine und Ressourceneinsatz machen, die er in Berichtsform denjenigen zur Verfügung stellt, die das Projekt eingeleitet haben. Wichtig dabei ist, das der Verwaltungsprozess nicht übermäßig ausartet und das Projekt mit übermäßiger Bürokratie belastet wird. Abb. 6.73: Schematischer Überblick über den PRINCE 2Prozess MP [1]

Arbeitspaket (work package)

CS1 Freigeben eines Arbeitspaketes

MP1 Risikoprotokoll (risk log)

Liefern eines Arbeitspaketes

SB4 Aktualisieren des Risikoprotokolls

CS2 Überwachen des Fortschrittes

Zugestimmtes Arbeitspaket, Teameinsatzplan (agreed work package, team plan)

Teamstatusberichte, überarbeitetes Qualitätslogbuch

(checkpoint reports, updated quality log)

MP2 Durchführen eines Arbeitspaketes

Vollendetes Arbeitspaket (completed work package)

CS9 Entgegennehmen von abgeschlossenen Arbeitspaketen

Überprüftes Arbeitspaket (approved work package)

MP3 Liefern eines Arbeitspaketes

MP (Managen der Produktlieferung)

Letztendlich muss der Projektleiter das Endprodukt als Vertreter des inoder externen Kunden prüfen und von diesem Zustimmung zum Endprodukt erhalten. Auch muss er Änderungen an Projektarbeitspaketen überprüfen und kontrollieren. Nachfolgend ein Überblick über die Subprozesse des PRINCE 2-MP-Prozesses.

194

■ ■ ■

6 PRINCE 2

Subprozesse des PRINCE 2MP-Prozesses

Inhalt/Deutsch

Inhalt/Englisch

MP1

Annehmen eines Arbeitspaketes Durchführen eines Arbeitspaketes Liefern eines Arbeitspaketes

Accepting a Work Package

MP2 MP3

Tabelle 6.6: Subprozesse innerhalb des PRINCE-MPProzesses

Executing a Work Package Delivering a Work Package

6.4.5.1 MP1 (Annehmen eines Arbeitspaketes) Ziel dieses Subprozesses ist es, mit demjenigen, der das Arbeitspaket durchführen soll, eine Übereinkunft zu erzielen, was denn Inhalt des Projektarbeitspaketes ist. Hierbei ist nicht nur die genaue Beschreibung des Endproduktes mit seinen späteren Eigenschaften zu verstehen, sondern auch, welche Rahmenbedingungen (Qualitätsund Abnahmerichtlinien, Entwicklungsplattformen) bei der Entwicklung zu erwarten sind. Für die wesentlichen Anforderungen (Zeitdauer und Kosten) der Entwicklung des Arbeitspaketes sind Toleranzgrenzen zu vereinbaren. Wichtig ist auch zu erkennen, welche Schnittstellen zu anderen Systemen bestehen, da man sich dann die genauen Schnittstellenbeschreibungen besorgen muss. Aber nicht nur das genaue Spezifizieren des Arbeitspaketes ist von Interesse, sondern auch, unter welchen Bedingungen der Entwicklung dieses Arbeitspaketes vom Ausführenden zugestimmt wird. Das organisatorische Sprachrohr der Ausführenden ist der Leiter eines Entwicklerteams. Dieser verhandelt mit dem Projektleiter über das, was von seinem Team entwickelt werden soll und wie die erforderlichen Eigenschaften des Endproduktes überprüft und abgenommen werden. Er überprüft die Anforderungen des Projektleiters auf Realitätsbezug, bestehende Risiken und stimmt die Arbeitspakettoleranzgrenzen ab, z. B. Zeit, Kosten, die Art und Weise und in welchen Zeitabständen der Projektsachstand dem Projektleiter übermittelt werden soll. Er überprüft auch, ob sein vorgesehenes Team alle Fähigkeiten (skills) und Erfahrungen besitzt, die es braucht, um das Arbeitspaket durchzuführen und ob die benötigte Infrastruktur vorhanden ist. Nachdem alle offenen Punkte vom Teamleiter überprüft wurden, erstellt er einen Arbeitsplan für sein Entwicklerteam, mit dem die Arbeitspakettoleranzen (Zeit, Kosten) eingehalten werden sollen. Er führt des Weiteren eine Risikoanalyse sowie das Blocken von


■ ■ ■

195

Abb. 6.74: Schematische Darstellung des MP1-Subprozesses

Entwicklerressourcen für einen bestimmten Zeitraum durch. Hier ist auch ein großes Risikopotential zu sehen. Des Öfteren stehen dem Teamleiter nicht die Mitarbeiter zu dem Zeitpunkt zur Verfügung, an dem er sie am besten gebrauchen könnte, um die Arbeitsanforderungen umzusetzen. Oder aber er bekommt sie nur für eine bestimmte Zeitperiode, weil diese Leute durch andere Projekte in der Zukunft geblockt sind. Auch muss er bei Softwareprojekten entscheiden, durch welche Standards und Entwicklungstools er das Arbeitspaket umsetzen will und welche qualitätssichernden Maßnahmen und Prozeduren er nutzen möchte. Eingangsprodukte sind: x Arbeitspaket (work package) x Teameinsatzplan (team plan) x Risikoprotokoll (risk log) x Arbeitspaket (work package) Ausgangsprodukte sind: x Genehmigtes Arbeitspaket (authorised work package) x Überarbeitetes Risikoprotokoll (risk log)

x Überarbeiteter Teameinsatzplan (team plan) Verantwortlich für die Durchführung des Subprozesses ist: x Entwicklungsteamleiter (team manager) und Projektleiter (project manager)

196

■ ■ ■

6 PRINCE 2

6.4.5.2 MP2 (Durchführen eines Arbeitspaketes) Bei diesem Subprozesss werden alle Aktionen beschrieben, die die Durchführung eines Arbeitspaketes betreffen. Angefangen bei der Feststellung, welcher Aufwand- und Fertigungsstand bisher bei einem Arbeitspaket anzutreffen ist, bis zum Lösen auftretender Probleme und Versenden verfertigter Arbeitspaketsachstandsberichte fallen sie in das Spektrum von Subprozess MP2. Wichtig ist es auch, eine Übereinkunft zu erzielen, wie der Fortschritt des Arbeitspaketes überwacht und überprüft werden kann und in welcher Art und Weise Verzögerungen oder plötzlich auftretende Schwierigkeiten gemeldet werden sollen. Meist fällt man aus allen Wolken, wenn man separat ermittelt, welchen geschätzten Arbeitsaufwand die Projektmitglieder bis zum Fertigungstermin noch veranschlagen. Deshalb ist es wichtig, in kürzeren Zeitabständen einen Projektsachstand zu erhalten. Abb. 6.75: Schematische Darstellung des MP2-Subprozesses

Auch das Durchführen von vorher festgelegten Qualitätsprüfungen, das Erstellen entsprechender Dokumentation und Handbücher während der Fertigungszeitdauer fallen unter diesen Punkt. Eingangsprodukte sind:

x Genehmigtes Arbeitspaket (authorised work package) x Teameinsatzplan (team plan) x Qualitätslogbuch (Quality Log) Ausgangsprodukte sind: x Teamstatusberichte (checkpoint reports)

x Vollendetes Arbeitspaket (completed work package)


■ ■ ■

197

x Überarbeitetes Qualitätslogbuch (quality log) x Überarbeiteter Teameinsatzplan (team plan) Verantwortlich für die Durchführung des Subprozesses ist: x Entwicklungsgruppenleiter (team manager)

6.4.5.3 MP3 (Liefern eines Arbeitspaketes) Nachdem das Arbeitspaket fertig gestellt wurde, wird es dem Projektleiter übergeben. Die Art und Weise, wie dies zu erfolgen hat, steht innerhalb des Dokuments, das das Arbeitspaket genehmigt hat (authorised work package). Nach Übergabe und offizieller Abnahme können entsprechende Aufwände in Rechnung gestellt werden. Abb. 6.76: Schematische Darstellung des MP3Subprozesses

Der Teamleiter muss sicherstellen, dass das Arbeitspaket die entsprechend zugesicherten Qualitätsmerkmale (Überarbeitetes Qualitätsprotokoll) besitzt und dass alle Teile des Endproduktes übergeben werden. Hierzu sind die Regeln des firmeneigenen Konfigurationsmanagements einzuhalten. Eingangsprodukte sind:

x Vollendetes Arbeitspaket (completed work package) Ausgangsprodukte sind:

x Überprüftes Arbeitspaket (approved work package) Verantwortlich für die Durchführung des Subprozesses ist: x Entwicklungsgruppenleiter (team manager)

198

■ ■ ■

6 PRINCE 2

6.4.6 SB (Managen von Projektphasenübergängen) Ein großes Projekt erfordert in bestimmten Zeitabständen ein Überprüfen der Projektziele, die erreicht werden sollen. Rein organisatorisch bietet sich dies am Ende einer Projektphase an. Aber nicht nur eine Überprüfung der grundsätzlichen Projektziele ist erforderlich, sondern auch eine Anpassung an äußere Gegebenheiten, wie das Wechseln von Projektmitgliedern, das Verändern des Projektlösungsansatzes oder der vorgesehenen qualitätssichernden Tests. Abb. 6.77: Der PRINCE 2SB-Prozess im Überblick

Neue mögliche Projektrisiken können schneller auftauchen als man sich das vorstellen kann. Für sie muss eine adäquate Lösungsstrategie gesucht werden. Manchmal ist es auch notwendig, neu aufgetretene Projektrisiken in kürzeren Zeitabständen erneut zu überprüfen. Nach jeder Projektphase muss der Lenkungsausschuss über die wesentlichen Kennparameter des Projektes verständigt werden, damit dieser in die Lage versetzt wird, entweder die nächste Projektphase zu autorisieren oder aber das Projekt zu beenden. Auch muss am Ende einer Projektphase feststehen, wie denn jetzt weiter vorgegangen wird und welche neuen Phasentoleranzwerte eingehalten werden müssen.


■ ■ ■

199

Abb. 6.78: Schematische Darstellung des PRINCE 2-Subprozesses SB

200

■ ■ ■

6 PRINCE 2

All diese Informationen müssen in einen neuen Projektphasenplan und Projektplan eingearbeitet werden. Um die notwendigen Vorgänge einzuleiten und durchzuführen, sind die Subprozesse SB1 bis SB6 des PRINCE-Prozesses SB (Managing Stage Boundaries, SB) da. Subprozesse Managen von Projekt-Phasendes PRINCE 2- übergängen SB-Prozesses

Managing Stage Boundaries

SB1 SB2 SB3

Planning a Stage Updating a Project Plan Updating a Project Business Case Updating the Risk Log

SB4 SB5 SB6

Planen einer Phase Aktualisieren des Projektplanes Aktualisieren des Projektes Business Case Aktualisieren des Risikoprotokolls (Risk Log) Mitteilen eines Phasenabschlusses Erstellen eines Ausnahmeplans

Tabelle 6.7: Subprozesse innerhalb des PRINCE-SBProzesses

Reporting Stage End Producing a Execption Plan

6.4.6.1 SB1 (Planen einer Phase) Ziel dieses Subprozesses ist das Planen der nächsten Projektphase. Der neue Phasenplan soll alle notwendigen Aktivitäten zum Erreichen der zu dieser Phase definierten Ziele enthalten. Die Projektphase ist so zu planen, dass der tagtägliche Fortschritt anhand des neuen Projektplans kontrolliert werden kann. Am Ende des Subprozesses SB1 liegt ein neuer Phasenplan vor, der vom Lenkungsausschuss genehmigt werden muss. Der Subprozess SB1 nutzt Abb. 6.79: Schematische Darstellung des SB1-Subprozesses


■ ■ ■

201

die PRINCE 2-Planungssubprozesse, um einen möglichst guten Projektphasenplan zu erhalten. In dem neu aufzustellenden Phasenplan sind die zu erstellenden Teilprodukte und erforderlichen Management-Dokumente benannt und die daraus resultierenden qualitätssichernden Verfahren für die nächste Projektphase enthalten. Der Phasenplan sollte mit Unterstützung aller Mitarbeiter mit Projektkontrollaufgaben innerhalb des Projektes erstellt werden, damit sich deren Vorstellungen möglichst frühzeitig im Projekt wiederfinden. Regelmäßige Überprüfungstermine einer Projektphase sollten innerhalb des neuen Phasenplans vermerkt werden, damit bei der täglichen Arbeit nicht das große Ziel der Projektphase verloren geht. Auch sollte bei der Erstellung des neuen Phasenplans überprüft werden, ob sich die Erwartungen des Kunden an die zu erstellenden Teilprodukte verändert haben. Dies ist zum Beispiel möglich mit dem Eingliedern eines „Walk Through“-Termins mit dem Kunden. Hier werden mit dem bisher im Projekt erstellten Produkt Testfälle durchgespielt, die dem Kunden die generellen Funktionsweisen des entwickelten Produktes erkennen lassen. Mittels „Walk Through“ ist es dem Kunden möglich, frühzeitige Bedenken und Änderungen einfließen zu lassen, bevor es zu spät ist. Eingangsprodukte sind: x Problemkatalog (issue log) x Risikokatalog (risk log) x Projektphasenplan (stage plan) x Benachrichtigung über Projektphasenende (stage end notification) x Projektentwurf (project brief) x Projektplan (project plan) x Auftrag zur Definition des nächsten Phasenplans (trigger for next stage plan) x Projektleitdokument (project initiation document; PID) x Projektmanagement-Teamstruktur (project management team structure) Ausgangsprodukte sind: x Überarbeitete Projektmanagement-Teamstruktur (updated project management team structure) x Überarbeiteter Projektplan (updated project plan)

202

■ ■ ■

6 PRINCE 2

x Überarbeitetes Risikologbuch (risk log) x Entwurf des neuen Projektphasenplans (draft next stage plan) x Produktcheckliste (product checklist) Verantwortlich für die Durchführung des Subprozesses ist: x Projektleiter (project manager) mit Unterstützung aller Mitarbeiter mit Projektkontrollaufgaben

6.4.6.2 SB2 (Aktualisieren des Projektplanes) Eins der wichtigsten Teilelemente des Planens der nächsten Projektphase ist der zugrunde liegende Projektplan, in dem die Tätigkeiten eines Projektes einzeln vermerkt sind. Oft ergeben sich durch zugestimmte Änderungswünsche des inoder externen Kunden Veränderungen, die nun berücksichtigt werden müssen. Der Projektplan ist das Instrument, um während eines Projektes festzustellen, ob es voranschreitet oder nicht. Abb. 6.80: Schematische Darstellung des SB2-Subprozesses

Weiterhin wird in dem PRINCE 2-Subprozess SB2 der Projektqualitätsplan (quality plan) und der Projektlösungsansatz (project approach) den momentanen Erfordernissen und dem Verständnis des Projektes angepasst. Aus dem Projektplan lassen sich dann die damit verbundenen Zeitspannen einzelner Arbeitspakete und Kosten abschätzen. Diese werden wiederum verglichen mit den Toleranzgrenzen, die am Anfang eines Projektes für diese Projektphase vorgesehen waren. Durch eine Analyse der letzten und der gegenwärtigen Projektphase lassen sich wesentliche Schlüsse für die nächste Projektphase ziehen. Es kann sehr wohl sein, dass sich durch Veränderungen während des laufenden Projektes Ziele, die im Business Case skizziert


■ ■ ■

203

Abb. 6.81: Ein Rätsel: Was ist kaum geschrieben und schon veraltet? Lösung: Der Projektplan

wurden, nicht mehr einhalten lassen. Der Projektleiter muss abschätzen, ob die genannten Aufwände in zeitlicher und finanzieller Hinsicht realistisch sind, und eventuelle Puffer im Projektplan für unerwartete Ereignisse vorsehen. Eingangsprodukte sind: x Gegenwärtiger und nächster Projektphasenplan (current and next stage plan) x Ausnahmeplan (exception plan) x Projektlösungsansatz (project approach) x Qualitätsplan (quality plan) Ausgangsprodukte sind: x Nächster Projektphasenplan oder Ausnahmeplan (next stage plan or exception plan) x Aktualisierter Projektlösungsansatz (project approach) x Aktualisierter Projektqualitätsplan (quality plan) x Angepasster Projektplan (updated project plan) Verantwortlich für die Durchführung des Subprozesses ist: x Projektleiter mit Unterstützung aller Mitarbeiter mit Projektkontrollaufgaben

6.4.6.3 SB3 (Aktualisieren des Business Case Projekts) Änderungen im Projekt bedingen manchmal Änderungen im Business Case. Der Busines Case soll einen objektiven gegenwärtigen Stand widerspiegeln. Änderungen am Projektendzeitpunkt, die aus

204

■ ■ ■

6 PRINCE 2

dem Planen des gegenwärtigen Projektphasenplans (project plan) oder Ausnahmeplans (exception plan) hervorgehen, müssen im Business Case vermerkt werden. Auch kann sich eine frühere, im Business Case gemachte Kosten/Nutzen-Analyse durch neuere Erkenntnisse verändern. Der Subprozess SB3 wird ausgeführt, wenn eine Projektphase beendet ist und eine neue beginnt. Abb. 6.82: Schematische Darstellung des SB3-Subprozesses

Einflüsse, die sich durch die notwendige Nutzung externer Ressourcen, veränderte Kostenstrukturen, zeitliche Verzögerungen, ein überarbeitetes Risikoprotokoll (risk log) oder innerhalb des Problemprotokolls (issue log) festgehaltene Sachverhalte ergeben, haben Einfluss auf die im Business Case gemachten Grundannahmen über das Kosten/Nutzen-Verhältnis. Auch kommt es vor, dass sich während der Projektlaufzeit die grundsätzlichen Prioritäten der Firmenleitung oder des Programmmanagements einer Firma verändern. Diese Änderungen müssen innerhalb des Business Case betrachtet werden. Sollte sich herausstellen, dass die ursprünglichen Erwartungen und der Mehrwert durch die Durchführung des Projektes laut gegenwärtigem Business Case nicht mehr erfüllt werden, so kann nur der Lenkungsausschuss entscheiden, ob wesentliche Annahmen über den Nutzen der Projektdurchführung verändert werden und der angepasste Business Case die weitere Durchführung des Projektes erlaubt. Eingangsprodukte sind: x Angepasster Projektplan, Ausnahmeplan oder nächster Phasenplan (updated project plan, exception plan or next stage plan) x Problemprotokoll (issue log) x Risikoprotokoll (risk log)


■ ■ ■

205

Ausgangsprodukte sind: x Überarbeiteter Business Case x Überarbeitetes Risikoprotokoll (updated risk log) Verantwortlich für die Durchführung des Subprozesses ist: x Projektleiter mit Unterstützung aller Mitarbeiter mit Projektkontroll-Aufgaben.

6.4.6.4 SB4 (Aktualisieren des Risikoprotokolls „risk log“) Veränderungen im Projektumfeld, Projektplan oder Business Case bedingen veränderte oder neue Projektrisiken bzw. verändern deren Auswirkung auf das Projekt. Dies zu erfassen, ist Aufgabe des Subprozesses SB4. Der am besten geeignete Augenblick, dies zu tun, liegt am Ende einer abgeschlossenen Projektphase. Stellt sich heraus, dass es besonders schwerwiegende Risiken gibt, so muss der Subprozess-SB4 in kürzeren Zeitabständen durchgeführt werden. Jedes neue Risiko muss innerhalb des Risikoprotokolls (risk log) dokumentiert werden und die früher aufgeführten Risiken müssen erneut bezüglich ihrer Auswirkung (finanziell, zeitlich) auf die neue Projektphase untersucht werden. Für jedes identifizierte Projektrisiko sollte es einen Plan geben, es zu eliminieren oder abzumildern. Werden Projektrisiken identifiziert, die einen fundamentalen Einfluss auf den Fortgang eines Projektes oder die jeweilige Projektphase haben, so ist es sinnvoll, jemandem die Verantwortung für die Überwachung dieser Projektrisiken zu übertragen. Abb. 6.83: Schematische Darstellung des SB4-Subprozesses

Prozessbeziehungen und Erzeugnisse von SB4 Input

SB2

CS4

Projektplan, Ausnahmeplan oder nächster Projektphasenplan project plan, execption plan or next stage plan)

Risikoprotokoll, Problemprotokoll (risk log, issue logs)

Output

■ ■ ■

6 PRINCE 2

SB3

Risikoprotokoll (risk log)

MP1

SB4 Aktualisieren des Risikoprotokolls (updating the risk log) Verantwortlich für diesen Prozess ist der Projektleiter mit der Unterstützung von allen Mitarbeitern mit Projektkontroll-Aufgaben.

206

Problemprotokoll, Risikoprotokoll (issue log, risk log)

Eingangsprodukte sind: x Projektplan, Ausnahmeplan oder nächster Phasenplan (project plan, exception plan or next stage plan) x Problemprotokoll (issue log) x Risikoprotokoll (risk log) Ausgangsprodukte sind: x Überarbeitetes Problemprotokoll (issue log) x Überarbeitetes Risikoprotokoll (risk log) Verantwortlich für die Durchführung des Subprozesses ist: x Projektleiter mit Unterstützung aller Mitarbeiter mit Projektkontroll-Aufgaben.

6.4.6.5 SB5 (Mitteilen eines Phasenabschlusses) Nachdem abzusehen ist, dass eine Projektphase abgeschlossen wird oder aber ein Ausnahmeplan (exception plan) erstellt werden muss, werden die Ergebnisse und weitere Informationen innerhalb eines Projektphasen-Abschlussreports (end stage report) zusammengefasst und allen innerhalb des Kommunikationsplans (communication plan) beschriebenen Verantwortlichen zugestellt. Besonders die Firmenleitung oder das Projektmanagement einer Firma bzw. der inoder externe Kunde wird somit offiziell über den Stand des Projektes oder der Projektphase informiert. Wesentliche Daten innerhalb des Projektphasen-Abschlussreports (end stage report) sind aufgelaufene Kosten, erzeugte Teilprodukte und voraussichtlicher Endzeitpunkt des Projektes. Diese werden in Beziehung gesetzt zu den am Anfang des Projektes oder der Projektphase vereinbarten Toleranzgrenzwerten. Innerhalb des Subprozesses SB5 wird überprüft, ob wirklich alle in der Projektphase zu entwickelnden Teilprodukte fertig sind, und ob diese die vorgesehenen Qualitätsprüfungen bestanden haben. Auch die durchgeführten Änderungswünsche des inoder externen Kunden und die dadurch entstandenen Einflüsse auf den Phasenplan sind aufzuführen. Auch ist eine Wertung des Projektleiters der durch die Projektdurchführung zu erhaltenden Vorteile beizufügen sowie eine Schätzung, ob die vom Lenkungsausschuss vorgegebenen maximalen Projekttoleranzen im weiteren Projektverlauf noch einzuhalten sind. Eine Übersicht über die während der Projektphase aufgetretenen


■ ■ ■

207

Abb. 6.84: Schematische Darstellung des SB5-Subprozesses

Probleme (issues), projektbezogene Hinweise, entdeckte Einsparpotentiale und die durchgeführten qualitätssichernden Maßnahmen rundet den Projektphasen-Abschlussreport ab. Meist wird am Ende des Projektphasen-Abschlussreports der offizielle Antrag auf Genehmigung der nächsten Projektphase (stage) gestellt. Oft wird der Projektphasen-Abschlussreport mit dem nächsten Projektphasenplan (stage plan) sowie dem dann gültigen Projektplan (project plan) verschickt. Sind wichtige Erkenntnisse innerhalb der letzten Projektphase angefallen, so werden diese innerhalb des Projektphasen-Abschlussreports (end stage report) und dem Erfahrungsbericht (lessons learned report) für spätere Projektphasen oder Projekte niedergeschrieben. Im Projektphasen-Abschlussreport (end stage report) sind also alle wichtigen Einflüsse (finanziell, zeitlich, Probleme, Risiken, Resultate, realisierte Teilprodukte) der letzten Projektphase auf das Gesamtprojekt enthalten. Ist das Projekt Teil eines größeren Vorhabens, so werden die im Projektphasen-Abschlussreport enthaltenen Informationen von der Firmenleitung oder dem Programm-Management einer Firma genutzt, um verschiedene Teilprojekte miteinander abzugleichen. Eingangsprodukte sind: x Gegenwärtiger Phasenplan, nächster Phasenplan oder Ausnahmeplan (current project plan, exception plan or next stage plan) x Problemprotokoll (issue log) x Risikoprotokoll (risk log)

208

■ ■ ■

6 PRINCE 2

x Projektqualitätslogbuch (quality log) x Business case x Kommunikationsplan (communication plan) Ausgangprodukte sind: x Risikoprotokoll (risk log) x Problemprotokoll (issue log) x Projektqualitätslogbuch (quality Log)

x Genehmigungsanforderung zur Durchführung der neuen Projektphase (request for authorisation to proceed)

x Projektphasen-Abschlussreport (end stage report) x Nächster Phasenplan oder Ausnahmeplan (next stage plan or exception plan) x Angepasster Erfahrungsbericht (lessons learned report) Verantwortlich für die Durchführung des Subprozesses ist: x Projektleiter mit der Unterstützung aller Mitarbeiter mit Projektkontroll-Aufgaben sowie den Gruppenleitern der Entwicklergruppen.

6.4.6.6 SB6 (Erstellen eines Ausnahmeplans) Eine Projektphase befindet sich in einer Ausnahmesituation, wenn die vom Lenkungsausschuss gesetzten Phasentoleranzgrenzen bezüglich Fertigungszeitpunkt und Kosten voraussichtlich überschritten werden. Das Erkennen, ob sich eine Projektphase innerhalb der zugebilligten Phasentoleranzgrenzen befindet, erfolgt innerhalb des PRINCE-CS-Prozesses. Da sie voraussichtlich bald nicht mehr innerhalb der zugesicherten Phasentoleranzgrenzen liegen wird, hat die Phase automatisch nicht mehr die Zustimmung des Lenkungsausschusses. Nur dieser kann die weiteren notwendigen Schritte autorisieren. Dafür ist es notwendig, dass er von der voraussichtlichen oder bestehenden Verletzung der Projektphasentoleranzgrenzen verständigt wird (exception report) und er einen Ausnahmeplan (exception stage plan) vorgelegt bekommt, der den gegenwärtigen Phasenplan (stage plan) ersetzen soll. Dieser sollte alle weiteren und ergänzend notwendigen Schritte und Aktionen umfassen, um eine bestehende Projektphase und somit das ganze Projekt erfolgreich abschließen zu können.


■ ■ ■

209

Abb. 6.85: Schematische Darstellung des SB6-Subprozesses

Prozessbeziehungen und Erzeugnisse von SB6 Input

CS8

CS

Ausnahmebericht, ProjektphasenPlan (exception report, stage plan)

Problemprotokoll, Risikoprotokoll (issue log, risk log

Output

SB6 Erstellen eines Ausnahmeplans (producing an exception plan) Verantwortlich für diesen Prozess ist der Projektleiter mit der Unterstützung von allen Mitarbeitern mit ProjektkontrollAufgaben sowie den Gruppenleitern derEntwicklergruppen.


Überarbeitetes Risikoprotokoll (updated risk log)

SB2

Projektablage

Der Projektleiter muss den Lenkungsausschuss mittels eines Ausnahmeberichtes (exception report) auf die Situation hinweisen. Der wiederum beauftragt den Projektleiter, den notwendigen Ausnahmeplan (exception plan) für die gegenwärtige Projektphase (stage) zu erstellen. Innerhalb des Ausnahmeplans (exception plan) befindet sich dann ein aktueller Projektplan, aus dem die Abweichungen hervorgehen. Den Lenkungsausschuss interessiert auch, ob die im Business Case getroffenen Annahmen über die betriebswirtschaftlichen Gründe zum Durchführen des Projektes trotz bestehender Probleme und Überschreiten der Projektphasen-Toleranzgrenzen noch gültig sind. Wichtig ist, dass es allein schon die potentielle Möglichkeit zum Überschreiten der durch den Lenkungsausschuss vorgegebenen Projekttoleranzen notwendig macht, den Lenkungsausschuss davon in Kenntnis zu setzen. Ist das Projekt Teil eines größeren Vorhabens, so muss der Ausnahmeplan (exception plan) mit den darin enthaltenen Informationen von der Firmenleitung oder dem ProgrammManagement einer Firma genutzt werden, um verschiedene Teilprojekte miteinander abzugleichen. Eingangsprodukte sind: x Gegenwärtiger Projektphasenplan (stage plan) x Problemprotokoll (issue log) x Ausnahmebericht (exception reports) x Risikoprotokoll (risk log) Ausgangsprodukte sind: x Ausnahmeplan (exception plan) x Überarbeitetes Risikoprotokoll (updated risk log)

210

■ ■ ■

6 PRINCE 2

Verantwortlich für die Durchführung des Subprozesses ist: x Projektleiter mit Unterstützung aller Mitarbeiter mit Projektkontroll-Aufgaben sowie den Gruppenleitern der Entwicklergruppen.

6.4.7 CP (Abschließen eines Projektes) Der PRINCE 2-Prozess CP (Closing a project) hat grundsätzlich die Aufgabe sicherzustellen, dass alle Projektendprodukte ausgeliefert und abgenommen sowie keine weiteren wichtigen Aktivitäten vergessen wurden. Beim Abschluss eines Projektes werden des Öfteren Fehler gemacht. Der inoder externe Kunde muss zufrieden gestellt werden. So kommt es vor, dass ein noch nicht ganz fertiges Endprodukt in den operativen Betrieb des inoder externen Kunden übergeben wird oder schleichend die Nutzung dieses Endproduktes einsetzt, obwohl noch diverse Arbeiten durchgeführt werden müssen. Damit dies nicht passieren kann, sieht PRINCE die unterschiedlichen CP-Subprozesse CP1 bis CP3 vor. CP (Abschließen eines Projektes)

CP1 (Beenden des Projektes )

Abb. 6.86: Der PRINCE 2CP-Prozess im Überblick

CP2 (Identifizieren von Folgeaktionen )

CP3 (Bewerten eines Projektes)

Sicherstellung aller Projektziele und Produkteigenschaften

Im CP-Prozess werden innerhalb des Dokuments „Empfehlungen für Folgeaktionen“ (follow on actions) alle notwendigen Aktionen beschrieben, um ein Projekt ordnungsgemäß abzuschließen und eventuell noch notwendige Aktionen offiziell zu benennen, die den inoder externen Kunden zufrieden stellen. Zum Beispiel kann es sein, dass das gegenwärtig abzuschließende Projekt Teil eines größeren ist


■ ■ ■

211

und somit eine Integration stattfinden muss; oder aber, dass das Endprodukt geordnet in die Hände des Servicesupports einer Firma gelegt werden soll. Basiert dieser Service-Support auf ITIL-Prozessen, so müssen die Verantwortlichen dieser Serviceprozesse das neue Endprodukt in ihre Planung mit aufnehmen. Das First-Level-Personal eines Service Desks oder einer Hotline muss geschult werden, um den Nutzern des Endproduktes besser helfen zu können. Grundsätzlich aber soll der PRINCE-CP-Prozess durch eine Überprüfung sicherstellen, dass alle innerhalb des Projektleitdokuments (project initiation document; PID) beschriebenen Projektziele und Produkteigenschaften auch erfüllt und alle zugesicherten Teilprodukte auch ausgeliefert wurden. Dies ist Grundlage dafür, dass der inoder externe Kunde das Endprodukt offiziell abnimmt und er mit der gelieferten Qualität des Endproduktes zufrieden ist. Manchmal ist das Projekt auch die Voraussetzung, um weitere Teile eines Gesamtsystems zu erstellen. Dann muss der PRINCE 2-Prozess CP sicherstellen, dass dies möglichst reibungslos verläuft. Alle durch das Projekt geblockten Ressourcen müssen am Ende eines Projektes schnellstmöglich freigegeben werden, damit weitere Kosten vermieden werden. Abb. 6.87: Schematischer Überblick über den PRINCE 2Prozess CP [1]

DP4 Ad-hocAnweisungen geben

Anweisung zur vorzeitigen Beendigung des Projektes (premature close)

Übermitteln der Projectdokumente ins Archiv (project files)

Dokumentenarchiv CP1

Benachrichtigung vom Projektende (notification of project end)

Beenden eines Projektes

CS5

Funktions- und WartungsfähigkeitsBestätigung (operational and maintenance acceptance)

Prüfen des Phasenstatus

SB5 Mitteilen eines Phasenabschlusses

Projektabschlussmeldung, Abnahmeerklärung des Kunden (project closure notification, customer acceptance)

„Business Case“, Risikiprotokoll, Problemprotokoll, Qualitätslogbuch, Erfahrungsbericht (business case, risk log, issue log, quality log, lessons learned report)

CP2 Identifizieren von Folgeaktionen

Empfehlungen für Folgeaktionen, Termin für Projektrevision (follow on action recommendations, post project review plan)

DP5 Bestätigen des Projektabschlusses

IP6 Projektleitdokument (PID) zusammenstellen

Projektleitdokument (Project Initiation Document; PID)

CP3 Bewerten eines Projektes

Erfahrungsprotokoll, Projektabschlusbericht (lessons learned report, end project report)

CP (Abschließen eines Projektes)

Wird ein Projekt vorzeitig beendet, so hat der CS-Prozess die Aufgabe, die bisher erstellten Teilprodukte zu erfassen und Vorschläge zu unterbreiten, wie weiter verfahren werden soll. Sind für die Durchführung des Projektes Ressourcen angemietet worden, wie z. B. Räumlichkeiten, Testlabore oder Fremdpersonal, sind entsprechende Benachrichtigungen zu versenden, die die weitere Nutzungsdauer beschreiben.

212

■ ■ ■

6 PRINCE 2

Auch muss eventuell in Form eines Audits festgestellt werden, welche notwendigen Aktionen von allen mit der Erstellung des Endproduktes befassten Bereichen noch durchgeführt werden müssen. Neben diesen essentiellen Aufgaben muss am Ende eines Projektes ein Projektabschlussbericht (end project report) verfasst werden, der auch das vervollständigte Erfahrungsprotokoll (lessons learned log) umfasst. Subprozesse Abschließen eines Projektes des PRINCE 2CP-Prozesses

Closing a project

CP1

Beenden des Projektes

Decommissioning a Project

CP2

Identifizieren von Folgeaktionen Bewerten eines Projektes

Identifying Follow-on Actions Project Evaluation Review

CP3

Tabelle 6.8: Subprozesse innerhalb des PRINCE-CPProzesses

6.4.7.1 CP1 (Beenden des Projektes) Das Beenden eines Projektes setzt voraus, dass die inoder externen Kunden mit dem zufrieden sind, was der Dienstleister während des Projektes im Namen des Kunden angefertigt hat. In Sonderfällen wird das Projekt wegen äußerer oder innerer Gründe vorzeitig beendet. Innerhalb des Subprozesses muss geklärt werden, ob alle qualitätssichernden Testverfahren am Endprodukt durchgeführt wurden, der Kunde alle bestellten Endprodukte offiziell erhalten und abgenommen hat und ob Nachbesserungsarbeiten notwendig sind. Prozessbeziehungen und Erzeugnisse von CP1 Output

Input

DP4

CS5

Anweisung zur vorzeitigen Projektbeendigung (premature close direcion)

Ankündigung des Projektabschlusses, Produktstatus des Konfiguration Managements (notification of project end, product status account)

SB5

IP6

„Project Initiation Document“, Kommunikationplan (PID, communications plan)

DP5

Funktions- und WartungsfähigkeitsBestätigung (operational and maintenance acceptance)

DP5

Projektabschlussinformationen versenden (draft communication to interested parties)

DP5

CP1 Beenden des Projektes (Decommissioning a Project)

Problemprotokoll (issue log)

Projektabschlussmeldung, Abnahmeerklärung des Kunden (project closure notification, customer acceptance)

Abb. 6.88: Schematische Darstellung des CP1-Subprozesses

Verantwortlich für diesen Prozess ist der Projektleiter mit der Unterstützung von allen Mitarbeitern mit ProjektkontrollAufgaben

Übermitteln der Projectdokumente ins Archiv (project files)

Dokumentenarchiv


■ ■ ■

213

Sind für die Durchführung des Projektes Ressourcen angemietet worden, wie z. B. Räumlichkeiten, Test-Labore und -Equipment oder Fremdpersonal, sind entsprechende Benachrichtigungen zu versenden, die die weitere Nutzungsdauer beschreiben. Ist der Kunde eine interne Abteilung einer Firma, muss sichergestellt werden, dass die Integration des Projektendproduktes innerhalb der Supportorganisation optimal vonstatten geht. Des Öfteren unterstützt die Entwicklungsabteilung einer Firma die Abteilung, die für den IT-Support zuständig ist, für eine Weile, bis diese die Tätigkeiten voll übernehmen kann. Hier sind meist neben einer einfachen Nutzerschulung der Firstund Second-Level-Mitarbeiter des auf ITIL basierenden Incident Managements zu schulen. Auch ist darauf zu achten, dass Betriebshandbücher die Qualität haben, die man von ihnen erwartet, weil dafür meist während eines Projektes nur wenig Zeit bleibt. Alle noch offenen Probleme und Tätigkeiten müssen innerhalb eines Dokuments „Empfehlungen für Folgeaktionen“ (follow on action recommendation) hinzugefügt werden. Alle Dokumente, die im Laufe eines Projektes angefallen sind, müssen gesichert verwahrt werden zur eventuellen späteren Auswertung mittels Projektrevision. Eingangsprodukte sind: x Projektleitdokument (project initiation document; PID) x Problemprotokoll (issue log) x Zustandsbericht des Endproduktes (product status account) x Anweisung zur vorzeitigen Projektbeendigung (premature close direction) x Ankündigung des Projektabschlusses (notification of project end) x Kommunikationsplan (communication plan) Ausgangsprodukte sind: x Abnahmebescheinigung des Kunden (customer acceptance) x Funktions- und Wartungsfähigkeits-Bestätigung (operational and maintenance acceptance) x Projektabschlussmeldung (project closure notification) x Projektabschlussinformationen versenden (draft communication to interested parties) x Projektdokumente für das Archiv (project files)

214

■ ■ ■

6 PRINCE 2

Verantwortlich für die Durchführung des Subprozesses ist: x Projektleiter mit Unterstützung aller Mitarbeiter mit Projektkontrollaufgaben

6.4.7.2 CP2 (Identifizieren von Folgeaktionen) Jeder, der im Projektgeschäft tätig ist, weiß, dass am offiziellen Ende eines Projektes eigentlich noch viel zu erledigen bleibt, auch wenn der Wunsch verständlich ist, endlich ein Projekt abzuschließen und wenigstens einen kleinen Gewinn zu erzielen beziehungsweise einen Verlust zu vermeiden. Es bewahrheitet sich des Öfteren der Spruch, dass ein Projekt dann zu Ende ist, wenn kein Geld mehr da ist. Prozessbeziehungen und Erzeugnisse von CP 2 Input

CP2 Identifizieren von Folgeaktionen

SB5

„Business Case“, Risikoprotokoll, Problemprotokoll (business case, risk log, issue log)

Output Empfehlungen für Folgeaktionen (follow on action recommendations)

DP5

Termin für Projektrevision (post project review plan)

DP5

Abb. 6.89: Schematische Darstellung des CP2-SubProzesses

(Identifying Follow-on action) Verantwortlich für diesen Prozess ist der Projektleiter.

Dennoch oder gerade deshalb versucht der Subprozess CP2 rational zu klären, welche Folgeaktivitäten (follow-on action recommendation), z. B. Mängelbehebung laut Abnahmeprotokoll, Fehlerbehebung (bug-fixing), Betriebshandbücher erstellen, noch durchgeführt werden müssen, um ein Projekt offiziell abschließen zu können. Auch sollte ein Datum genannt werden, an dem eine weitere Projektrevision (post project review) stattfinden soll, um festzustellen, ob die noch offenen Punkte eines Projektes nun abgeschlossen werden konnten. Es hat sich als vorteilhaft erwiesen, dass das entwickelte Projektendprodukt nach einer bestimmten Einsatzzeit auf seine qualitativen Eigenschaften und auf seinen betriebswirtschaftlichen Nutzen überprüft wird. Daneben ist es wichtig zu erfahren, ob die Nutzer des Projektendproduktes damit zufrieden sind. Dies passiert innerhalb einer Projektrevision. Außerdem soll innerhalb der Projektrevision geklärt werden, ob die Ziele und wirtschaftlichen Vorteile, die innerhalb des Business Case spezifiziert und niedergeschrieben sind, erreicht wurden.


■ ■ ■

215

Abb. 6.90: Endphase eines Projektes

Weiterhin soll dabei festgestellt werden, wie hoch der Zufriedenheitsgrad des inoder externen Kunden mit dem Endprodukt des Projektes ist. Diese Informationen müssen den Entscheidungsträgern (Lenkungsausschuss) zugänglich gemacht werden. Der überwiegende Anteil von Informationen, welche Tätigkeiten noch durchzuführen sind, kommt aus dem Problemprotokoll (issue log). Eingangsprodukte sind: x Problemprotokoll (issue log) x Business Case x Risikoprotokoll (risk log) Ausgangsprodukte sind: x Terminvorschlag für die Projektrevision (post project review) x Empfehlungen für Folgeaktionen (follow-on action recommendation) Verantwortlich für die Durchführung des Subprozesses ist: x Projektleiter (project manager)

6.4.7.3 CP3 (Bewerten eines Projektes) Um eine offizielle Aussage darüber treffen zu können, ob ein Projekt erfolgreich gewesen ist, wird innerhalb des Subprozesses CP3 mittels eines Assessments festgestellt, ob die Ziele (finanziell, organisatorisch, rechtlich, technisch), die man sich mit der Durchführung des Projektes gesetzt hat, auch erreicht wurden.

216

■ ■ ■

6 PRINCE 2

Abb. 6.91: Schematische Darstellung des CP3-Subprozesses

Es wird beurteilt, welche Schwächen das Projekt aufwies und welche Probleme und Risiken im Laufe des Projektes nicht erkannt wurden. Interessant ist auch die Anzahl der offiziell durchgeführten Änderungswünsche und die Frage, welchen Einfluss diese auf das Projektergebnis hatten. Die Ergebnisse werden innerhalb des Projektabschlussberichts (end project report) festgehalten. Auch wird geprüft, ob das Management während des Projektes qualitativ in der Lage war, mit den Schwierigkeiten und Problemen fertig zu werden und ob die angewandten Management- und qualitätssichernden Verfahren sich als funktionstüchtig erwiesen haben und was man in Zukunft besser machen könnte. Unter dem Gesichtspunkt, welche Punkte und Erfahrungen für weitere (später durchzuführende) Projekte nützlich sein könnten, werden die gemachten Erfahrungen innerhalb des Erfahrungsberichtes (lessons learned report) festgehalten. Abb. 6.92: Nach dem Projekt kommt die Revision

Bei späteren Projekten kann man anhand der Erfahrungsberichte schon durchgeführter Projekte eine bessere Schätzung des Aufwandes erreichen. Eingangsprodukte sind: x Projektleitdokument (project initiation document; PID) x Problemlogbuch (issue log)


■ ■ ■

217

x Risikoprotokoll (risk log) x Projektqualitätslogbuch (quality log) Ausgangsprodukte sind: x Projektabschlussbericht (end project report) x Erfahrungsprotokoll (lessons learned log) Verantwortlich für die Durchführung des Subprozesses ist: x Projektleiter mit Unterstützung aller Mitglieder der Projektgruppe.

6.4.8 PL (Planen) Projektmanagement basiert auf ausreichender Planung und Kontrolle der Ergebnisse dieses Planens. Unter PRINCE basiert der Prozess PL auf einem produktorientierten Ansatz. Planen beruht somit auf den Grundsatzfragen: Was wird benötigt? Warum wird es benötigt? Wie kann man das Benötigte erzeugen und wer kann es umsetzen mit welchen Technologien, Standards und Werkzeugen? Abb. 6.93: Der PRINCE 2PL-Prozess im Überblick

218

■ ■ ■

6 PRINCE 2

Des Weiteren ist wichtig, dass im Vorhinein definiert wird, wie man bei äußeren Einflüssen, wie z. B. Problemen, reagiert. Im Detail bedeutet dies abzuschätzen, wie viele Ressourcen (zeitlich, finanziell) für die Durchführung eines Arbeitspaketes bzw. aller Arbeitspakete verbraucht werden. Weiterhin muss definiert werden, welche qualitätssichernden Verfahren und Tests durchgeführt werden sollen, um die dem Kunden zugesicherten Eigenschaften eines Produktes sicher zu erhalten. Eine Analyse des zu erstellenden Endprodukts führt zu den Aktivitäten, die durchgeführt werden müssen. Diese müssen definiert und ihnen sodann personelle Ressourcen zugeordnet werden. Es ist auch wichtig, die Reihenfolge von Arbeitspaketen, die es abzuarbeiten gilt, in ihrer Abhängigkeit zueinander festzulegen. Termine müssen vereinbart und im allgemeinen Konsens auch eingehalten werden.


Abb. 6.94: Schematischer Überblick über den PRINCE 2Prozess PL [1]

■ ■ ■

219

Abb. 6.95: Die Planung liegt im Zentrum allen Handelns

IP (Initiieren des P rojektes)

Projektplan

SU (Vorbereiten eines P rojektes)

SB

PPLL (P (Planen) lanen)

Initiierungsphasenplan

(Managen von P rojektphasenübergängen)

Phasenplan, Ausnahmeplan

MP (Managen der P roduktlieferung)

Gruppenplan

Planen ist ein fortlaufender Prozess, der abhängig vom jeweiligen Informationsstand und den äußeren Einflüssen ist. Um möglichst den effektivsten Weg zu beschreiten, ist es somit notwendig, die Planungsprozesse wiederholt zu durchlaufen. Am Ende des PRINCE 2-Prozesses PL sollte ein Plan entstanden sein, welcher allen, die innerhalb des Projektes eingebunden sind, ein gemeinsames Verständnis über die gemeinsam zu erbringende Arbeit vermittelt. Beim Planen (planning, PL) in den unterschiedlichen Projektphasen werden allgemeine Planungsschritte durchgeführt. Tabelle 6.9: PRINCE 2-PLProzess mit seinen Subprozessen PL1 bis PL7

Subprozesse des Planen PRINCE 2-PLProzesses

Planning

PL1 PL2

Designing a Plan Defining and Analysing Products Identifying Activities & Dependencies Estimating Scheduling Analysing Risks Completing a Plan

PL3 PL4 PL5 PL6 PL7

Entwerfen eines Planes Definieren und Analysieren von Produkten Identifizieren von Aktivitäten und Abhängigkeiten Abschätzen des Aufwandes Terminieren von Aktivitäten Analysieren von Risiken Vervollständigen eines Planes

6.4.8.1 PL1 (Entwerfen eines Planes) Innerhalb des Subprozesses PL1 wird eine anfängliche Struktur des durchzuführenden Projektes vorgegeben, damit alle Beteiligten sich ein grundsätzliches Bild der anstehenden Aktivitäten machen

220

■ ■ ■

6 PRINCE 2

Prozessbeziehungen und Erzeugnisse von PL 1 Input

SU6,IP2, SB1, SB6, MP1

Projekt-Qualitätsplan, Projektentwurf oder Projektleitdokument (project quality plan, project brief or project initiation document)

Output Planungsentwurf (plan design)

PL2

PL1

Abb. 6.96: Schematische Darstellung des PL1-Subprozesses

Entwerfen eines Plans (designing a plan)

SU5 Firmenstandards

Projektlösungsansatz (project approach )

Verantwortlich für diesen Prozess ist der Lenkungsausschuss sowie der Projektleiter.

Firmen-Planungsstandards (company planning standards )

können. Die anfängliche Struktur geht einher mit grundsätzlichen Entscheidungen, die teilweise noch bis Ende des Projektes ihre Auswirkungen haben. Das Festlegen einer Schätzmethode für entstehende Aufwände beim Realisieren der Projektarbeitspakete, das genutzte Planungstool, qualitätssichernde Standards, Methoden des Riskmanagements sowie vorgesehene Projekt-Kontrollmechanismen sind grundlegende Entscheidungen. Eine triviale, aber auf die Laufzeit eines Projektes nicht unerhebliche Definition ist die der normalen Arbeitszeit von 8 Stunden/Tag. Wird also eine Programmerstellung mit 40 Stunden geschätzt, so sind 5 Tage Arbeitszeit einzurechnen. Vergessen wird in den meisten Arbeitsorganisationen, dass derjenige, der das Programm erstellen soll, nicht nur an diesem Programm arbeitet, sondern dass er, je länger er Mitarbeiter einer Firma ist, auch Telefonauskünfte zu früheren Projekten geben und an diversen projektfremden Meetings teilnehmen muss. Des Weiteren vergisst man oft beim Planen, dass der vorgesehene Mitarbeiter auch Urlaub hat bzw. krank werden kann. Wartezeiten, wie sie immer wieder einmal auftreten können, bringen ein Projekt des Öfteren in Bedrängnis, da diese selten eingeplant werden. Werden externe Dienstleister mit eingebunden, so sind Zeiten für den erhöhten Anteil an Kommunikations- und Verwaltungsaufwand selten innerhalb einer Aufwandsschätzung enthalten. Das gleiche ist bei zu entwickelnden Testprogrammen und Testapparaturen der Fall, die oft die Basis bilden für entsprechend aussagekräftige Qualitätstests. Oft bekommt der Dienstleister ein Projekt von einem externen Kunden erst dann, wenn man vorher ideale Voraussetzungen des Projektverlaufes ansetzt. Dass diese nicht eingehalten werden können, liegt auf der Hand. Konventionalstrafen sind dann direkt mit einzukalkulieren. Das Aufteilen eines Projektes in Phasen ist schon vorher innerhalb des Subprozesses IP erfolgt. Der Projektplan wird wahrscheinlich je nach Komplexität in unterschiedlichen Verfeinerungsstufen existieren. Diese zu definieren, bleibt dem Gefühl der Planer überlassen.


■ ■ ■

221

Da meist ein Projekt in der einen oder anderen Projektphase auf Schwierigkeiten stößt und der Projektleiter dem Lenkungsausschuss (projekt board) einen überarbeiteten Phasenplan (exception plan) vorlegen muss, sollte man sich überlegen, in welche Detailtiefe die einzelnen Phasenpläne und der Projektplan gehen soll. Ist er zu fein, so wird der Aufwand, diesen immer wieder neu zu aktualisieren, sehr hoch. Sind in den Plänen Fehler und die Detailtiefe groß, so ist der Zeitverlust auch groß. Besonderes Augenmerk ist auf die vom Lenkungsausschuss vorgegebenen Phasentoleranzen (Budget, Endtermin) zu legen. Diese sind allen Projektbeteiligten von Anfang an mitzuteilen. Abb. 6.97: Jede Projektphase hat ihre eigene Planungsphase

Projektplan

Projektende stage n stage 3 stage 2 stage 1 stage 0 Projektanfang

Stage Plan

Exception Plan

Team Plan

Oft wird ein Teil des zur Verfügung stehenden Projektbudgets (Risikomarge) zurückgelegt für notwendige Budget-Änderungen. Bei größeren Projekten wird neben dem Phasenplan (stage plan) ein Teameinsatzplan (team plan) mit den detaillierten Angaben auf Entwicklerteamebene definiert. Ist das zu planende Projekt Teil eines größeren Vorhabens, sind Rahmenparameter der anderen Teilprojekte mit zu berücksichtigen. Der inoder externe Kunde ist in die Planung mit einzubeziehen. Nicht selten setzt ein externer Kunde Firmenstandards ein, die sich von dem des Dienstleisters unterscheiden. Eingangsprodukte sind:

x Projektlösungsansatz (project approach) x Projektqualitätsplan (quality plan) x Firmenstandards bezüglich Planung (company planning standards) x Projektleitdokument (project initiation document; PID)

222

■ ■ ■

6 PRINCE 2


x Planungsentwurf (plan design) Verantwortlich für die Durchführung des Subprozesses ist: x Lenkungsausschuss mit Hilfe des Projektleiters

6.4.8.2 PL2 (Definieren und Analysieren von Produkten) Durch den produktorientierten Ansatz von PRINCE wird innerhalb des Subprozesses PL2 sichergestellt, dass das Ausgangsprodukt den Erfordernissen des inoder externen Kunden aus technischer (Produktbeschreibung) und aus firmenspezifischer (business case) Sicht entspricht. Dabei plant und definiert man im Einzelnen die Punkte Produkterstellung, Produktqualität, und Produktverwendung, um am Ende das gewünschte Endprodukt zu erhalten. Prozessbeziehungen und Erzeugnisse von PL 2 Input

PL1

Projektlösungsansatz, ProjektQualitätsplan (project approach, project quality plan)

Output

PL2

Produktstrukturplan, ProduktablaufDiagramm (product breakdown structure, product flow diagram)

PL3


Definieren und analysieren von Produkten (defining and analysing products) Verantwortlich für diesen Prozess ist der Projektleiter in Zusammenarbeit mit Kunden, Nutzern und Gruppenleitern mit zugeordenetn Entwicklern.

Produktcheckliste (product checklist)

Produktbeschreibung (product description)

PL7

CS1

Ein Produktstrukturplan (product breakdown structure) erfasst alle Einzelprodukte in ihrer logischen Erstellungsreihenfolge, die als Ganzes das Endprodukt bilden. Aus diesen kann dann ein Projektzeitplan abgeleitet werden. Der Produktstrukturplan besteht aber nicht nur aus den zu erzeugenden Fachprodukten (business products), die durch den inoder externen Kunden beauftragt wurden, sondern auch aus Management- (management products) und Qualitäts-Produkten (quality products), die zur Erstellung dieser Fachprodukte notwendig sind. Weiterhin sind neben der genauen fachlichen Endproduktspezifikation auch die Gesichtspunkte des Kontroll- und Steuerungsprozesses sowie des qualitätssichernden Verfahrens zu planen. Aus dem Risikoprotokoll (risk log) des Projektes geht hervor, ob bestimmte


■ ■ ■

223

Risiken des Projektes ein besonderes Verfahren des Prüfens (Monitoing) und des Benachrichtigens (Reporting) bedürfen. Der Produktstrukturplan ist während der Projektlaufzeit ständigen Veränderungen unterworfen, die den jeweiligen Wissensstand wiedergeben. Viele Änderungen sind auch auf Kundenwünsche während der Projektlaufzeit zurückzuführen, die aber separat beauftragt werden müssen. Neben dem Produktstrukturplan (product breakdown structure) ist eine Produktcheckliste (product checklist) anzufertigen, die zu diversen projektsichernden Maßnahmen herangezogen wird, sowie eine Produktbeschreibung (product description), die neben einer genauen Beschreibung die notwendigen Qualitätsmerkmale enthält. Um zu erkennen, in welcher Reihenfolge die Einzelprodukte zu entwickeln sind, wird ein Produktablaufdiagramm (product flow diagram) angefertigt. Abb. 6.99: Viel Schreibkram, der sich lohnt

In diesen Planungsprozess sind alle wesentlichen Ansprechpartner des Kunden und des Dienstleisters involviert, um das zu entwickelnde Produkt möglichst genau zu spezifizieren. Diese Spezifikation sollte dem inoder externen Kunden zur Gegenzeichnung vorlegt werden. Stellt sich am Ende eines Projektes heraus, dass wesentliche Teilprodukte vergessen wurden, so ist dies nicht einzig und allein das Verschulden des Dienstleisters. Eingangsprodukte sind: x Projektlösungsansatz (project approach) x Projektqualitätsplan (quality plan) Ausgangsprodukte sind:

x Produktbeschreibung (product description) x Produktstrukturplan (product breakdown structure)

224

■ ■ ■

6 PRINCE 2

x Produktcheckliste (product checklist) x Produktablaufdiagramm (product flow diagram) Verantwortlich für die Durchführung des Subprozesses ist: x Projektleiter unter Mitwirkung des Kunden, Nutzers sowie der Entwicklungsabteilung des Dienstleisters

6.4.8.3 PL3 (Identifizieren von Aktivitäten und Abhängigkeiten) Hat man erst einmal definiert, wie das Endprodukt als Ganzes aussieht und aus welchen Teilen es besteht, muss nun ermittelt werden, welche Aktivitäten (list of activities) mit jedem Teilprodukt verbunden sind und wie diese durchgeführt werden müssen. Auch sind die gegebenen inoder externen Abhängigkeiten und Anforderungen (constraints), die damit verbunden sind, zu berücksichtigen. Ein Beispiel für eine Anforderung (constraint) ist, dass ein Teilprodukt „C“ erst dann entwickelt werden kann, wenn die Teilprodukte „A“ und „B“ vorhanden sind. Ab diesem Schritt wird auch klar, welcher Ressourcenbedarf (personell, finanziell, technisch, infrastrukturell) sich somit aus der Erstellung aller Teilprodukte und des Endproduktes ergibt. Prozessbeziehungen und Erzeugnisse von PL 3 Input

PL2

Produktablaufdiagramm, ProduktbeSchreibung (product flow diagram, product dscriptions)

PL3 Identifizieren von Aktivitäten und Abhängigkeiten

Output Aktivitätenliste, AktivitätenAbhängigkeiten (list of activities, activity dependencies)

PL4

Aktivitätenabhängigkeiten (activity dependencies)

PL5


(identifying activities & dependencies)

CS5

Verantwortlich für diesen Prozess ist der Projektleiter mit der Unterstützung von allen Mitarbeitern mit ProjektkontrollAufgaben sowie den Gruppenleitern derEntwicklergruppen.


.

Stellt sich heraus, dass ein einzelnes Produkt zu groß ist, um genaue Aktivitäten abschätzen zu können, so wird es in kleinere Teilprodukte zerlegt. Beim Durchforsten des Risikoprotokolls (risk log) ergeben sich eventuell weitere Aktivitäten und Teilprodukte, die helfen, das Risiko möglichst klein zu halten, sowie Aktivitäten, die die Produktqualität sicherstellen. Bei der Analyse der Abhängigkeiten (activity dependencies) und Aktivitäten kann es klug sein, Abstimmungsprozesse (in- und externe) direkt mit einzuplanen, die dann natürlich zu Wartezeiten


■ ■ ■

225

Abb. 6.101: Alle Aktivitäten und Abhängigkeiten müssen gefunden werden

Projekt Anforderungen

Endprodukt

zwischen zwei Aktivitäten führen können. Auch sollte die Möglichkeit untersucht werden, Teilprodukte parallel (zeitgleich) bzw. überlappend erstellen zu können. Eingangsprodukte sind: x Produktbeschreibung (product descriptions) x Produktablaufdiagramm (product flow diagram) x Risikoprotokoll (risk log) Ausgangsprodukte sind:

x Aktivitätenliste (list of activities) x Aktivitätenabhängigkeiten (activity dependencies) Verantwortlich für die Durchführung des Subprozesses ist: x Projektleiter mit Unterstützung aller Mitarbeiter mit Projektkontroll-Aufgaben sowie den Leitern der Entwicklergruppen.

6.4.8.4 PL4 (Abschätzen des Aufwandes) Innerhalb des Subprozesses wird über die vorher identifizierten zu erstellenden Teilprodukte eines Projektes eine Aufwandschätzung (personell, zeitlich, infrastrukturell) durchgeführt. Diese Tätigkeit ist eine der schwierigsten und basiert mehr oder weniger auf ErfahAbb. 6.102: Schematische Darstellung des PL4-Subprozesses

Prozessbeziehungen und Erzeugnisse von PL 4 Output

Input

PL3

Aktivitätenliste, Aktivitätenabhängigkeiten (list of activities, activity dependencies)

PL4 Abschätzen des Aufwands (estimating) Verantwortlich für diesen Prozess ist der Projektleiter in Zusammenarbeit mit den Entwicklern der Entwicklungsabteilung.

226

■ ■ ■

6 PRINCE 2

Aufwandschätzwerte (activity estimates)

PL5

rungswerten. Wichtig ist es auch, bei bestimmten Aktivitäten einen Expertenrat einzuholen bzw. die Annahmen und Bedingungen, die zur Aufwandsabschätzung führten, zu dokumentieren. Von der Aufwandsabschätzung kann es abhängen, ob man einen Auftrag bekommt bzw. das Projekt erfolgreich mit Gewinn abgeschlossen werden kann. Mit verschiedenen, in der Praxis angewandten Verfahren, wie nachfolgend aufgelistet, versucht man möglichst genaue Schätzwerte zu ermitteln. x Empirische Schätzverfahren (Expertenbefragung, z. B. nach Delphi-Methode) x Algorithmische Schätzverfahren (z. B. Function Point Verfahren) x Multiplikatormethode (z. B. Lines of Code) x Gewichtungsmethode (Kennzahlenmethode) x Relationsmethode oder Analogie zu Referenzprojekten Bei allem Eifer, den Aufwand möglichst genau zu bestimmen, sollte man allerdings auch bedenken, dass sich der Projektaufwand des Öfteren der noch verfügbaren Zeit anpasst (Gesetz von Parkinson). Abb. 6.103: Aufwände abzuschätzen grenzt an Hellseherei

Ist der Aufwand über die pure Erstellung der einzelnen Teilprodukte beendet, so sollten die Grundlagen der Schätzung und die geschätzte Fehlertoleranz innerhalb des Phasenplans unter dem Punkt „Annahmen“ niedergeschrieben werden. Zusätzlich zu dem puren Erstellen der Teilprodukte werden Pauschalsätze für die Projektleitung (1015%), das Qualitätsmanagement (510%), Konfigurationsmanagement (510%) und die Dokumentationserstellung (1015%) hinzugefügt. Sind die Aufwände für ein Teilprodukt hoch, so ist häufig auch die Entwickleranzahl hoch. Dadurch ergibt sich, wie in Abb. 6.104


■ ■ ■

227

Abb. 6.104: Ansteigender Kommunikationsbedarf bei größeren Entwicklergruppen

dargestellt, ein größerer Aufwand für interne Kommunikation und Projektleitung. Auch muss bedacht werden, dass zur Erstellung mancher Teilprodukte besonderes Wissen oder Fähigkeiten gebraucht werden, die nicht immer in einer Firma vorhanden sind. Dieses Problem wird meist gelöst durch externe Schulungen, Mitarbeiteranwerbung oder durch Vergeben an externe Dienstleister (Freiberufler, Dienstleisterfirmen). Dies ist an sich nicht besonders erwähnenswert, bedeutet aber, dass sich diese Aufwände immens steigern können, so dass dem Rechnung getragen werden muss. Auch ist innerhalb früherer Erfahrungsberichte (lessons learned report) vermerkt, an welchen Stellen in früheren Fällen falsch geschätzt wurde. Hier lohnt es sich, von den Erfahrungen anderer zu profitieren. Manchmal ist es auch ein Erfahrungswert, ein Projekt besser nicht zu bekommen. Eingangsprodukte sind:

x Aktivitätenliste (list of activities) x Aktivitätenabhängigkeiten (activity dependencies) Ausgangsprodukte sind: x Aufwandsschätzwerte (aktivity estimates) Verantwortlich für die Durchführung des Subprozesses ist: x Projektleiter und die Gruppenleiter der Entwicklungsabteilung

228

■ ■ ■

6 PRINCE 2

6.4.8.5 PL5 (Terminieren von Aktivitäten) Nachdem die Aktivitäten, Arbeitspakete und Teilprodukte identifiziert und auf ihren Arbeitsaufwand hin geschätzt wurden, muss nun versucht werden, eine zeitliche Reihenfolge und Terminierung der Durchführung festzulegen. Bei diesem Subprozess kann es passieren, dass zu den bestehenden Risiken des Risikoprotokolls (risk log) noch zeitliche Risiken hinzugefügt werden müssen. Bestehende interne Ressourcen müssen innerhalb dieses Zeitplans untergebracht werden, wobei Warte- und Urlaubszeiten sowie zeitliche Bindung von Personalressourcen bei anderen Projekten zu berücksichtigen sind. Abhängigkeiten verschiedener in Beziehung stehender Aktivitäten muss Rechnung getragen werden. Belegung von benötigten Infrastrukturen, wie z. B. Serversystemen, Entwicklungssystemen, Rechenkapazitäten, ergeben sich konkret aus den definierten Zeitplänen. Manchmal ergeben sich aus den zeitlichen Abhängigkeiten Mehrkosten oder eine Verschiebung des Endzeitpunktes der Fertigstellung des Endproduktes. Die Erstellung von Zeitplänen erfolgt üblicherweise mittels eines Planungstools. Oft ergibt sich aus den ersten Versionen eines Zeitplans direkt ein „Kritischer Pfad“ (Critical Path), der von der Projektleitung besonders kontrolliert werden muss. Oft ist es auch so, dass zwar eine Zuordnung von Aktivitäten zu internen Ressourcen vorgenommen werden kann, dass dies aber bedeuten würde, dass diese Ressource mehr als 24 Stunden pro Tag aktiv sein müsste. Solche Engpässe zu identifizieren, sind Hauptaufgaben des PRINCE 2-Subprozesses PL5. Alternativen (Freiberufler, externe Vergabe) müssen in diesem Zusammenhang geprüft werden und geben oft auch einen guten Überblick über Qualifizierungs- oder Schulungsbedarf innerhalb einer Firma. Notwendige Schulungen sind häufig nicht zu den Terminen zu erhalten, zu denen es angebracht wäre, und stellen oft schon die erste Verzögerung innerhalb eines Projektes dar. Sind Aktivitäten und personelle Ressourcen nicht direkt zuordenbar, so kann man sich damit behelfen, die entsprechenden fachlichen Anforderungen (skill) erst einmal niederzuschreiben und später eine konkrete Zuweisung vorzunehmen. Die realistische Einschätzung der effektiven projektspezifischen Arbeit einer personellen Ressource sollte bei der Planung bei 3,5 bis 4 Tagen pro Woche liegen. Der Rest wird mit Urlaubs-, Krankheitstagen und anderen notwendigen projektfremden Tätigkeiten angefüllt sein. Eine intelligente Einfügung von Kontrollpunkten erlaubt es, Abweichungen innerhalb des Zeitplans frühzeitig zu erkennen. Engpässe von Ressourcen, welcher Art auch immer, sollten dem Lenkungsausschuss mitgeteilt werden. Sind alle benötigten Ressourcen ermittelt, können die dadurch entstehenden Kosten abgeschätzt


■ ■ ■

229


Prozessbeziehungen und Erzeugnisse von PL 5 Input

PL3

Aktivitätenabhängigkeiten (activity dependencies)

PL4

Aufwandsschätzwerte (activity estimates)

DP4

Zur Verfügung stehende Ressourcen (resources availability)

Output

PL5

Projektzeitplan (schedule)

PL6

Abschätzen des Aufwands (scheduling) Verantwortlich für diesen Prozess ist der Projektleiter in Zusammenarbeit mit den Gruppenoder Teamleitern.

werden. Als vorteilhaft bei der Kostenabschätzung hat es sich erwiesen, realistische exemplarische Verzögerungen durchzuspielen und den damit verbundenen Einfluss auf das Kostenrisiko des Projektes zu untersuchen. Eingangsprodukte sind:

x Schätzwerte des Aufwandes (activity estimates) x Aktivitätenabhängigkeiten (activity dependencies) x Zur Verfügung stehende Ressourcen (resources availability) Ausgangsprodukte sind: x Projektzeitplan (schedule) Verantwortlich für die Durchführung des Subprozesses ist: x Projektleiter in Zusammenarbeit mit den Gruppen- oder Teamleitern.

6.4.8.6 PL6 (Analysieren von Risiken) Nachdem nun verschiedene Subprozesse eine Verfeinerung der Information über ein Projekt bzw. eine Projektphase ermöglicht haben, kristallisieren sich eventuell weitere mögliche Risiken heraus. Diese werden innerhalb des Subprozesses PL6 weiter analysiert. Ziel soll es sein, bestehende Risiken zu erfassen, die daraus folgenden Änderungen an Aufwand und Terminen abzuleiten und dann die erste Version des Projektphasenplans freizugeben. Besonders ein im Subprozess PL5 gefundener „Kritischer Pfad“ (critical path) sollte auf seine Auswirkungen hin untersucht werden. Da die Vorgehensweise bei einem effektiven Riskmanagement wichtig ist, gibt es bestimmte Verfahren, die nachfolgend aufgelistet

230

■ ■ ■

6 PRINCE 2

Prozessbeziehungen und Erzeugnisse von PL 6 Output

Input

PL5

Projektzeitplan (schedule)

PL6

Überprüfter Plan (assessed plan)

PL7


Analysieren von Risiken (analysing risks)

CS5


Verantwortlich für diesen Prozess ist der Projektleiter mit der Unterstützung vom Lenkungsausschuss sowie, allen Mitarbeitern mit ProjektkontrollAufgaben

sind und die zu einer schnellen und effektiven Herausarbeitung der kritischen Punkte samt Lösungsansätzen führen sollen: x Einfaches Riskassessment mit Risikomatrix x FMEA (Failure mode and effect analysis) x SSADM (Structured systems analysis and design methologies) x CPM (Critical Path method) x RISKMAN (European Risk Management Method) x CRAMM (CCTA´s Risk Analysis and Management Methodology) Gegenmaßnahmen (countermeasures) sollten zu bestehenden Projektrisiken aufgelistet werden, um diese bei einer Eskalation parat zu haben. Diese können entweder die Wirkung der Risiken mindern helfen oder diese neutralisieren. Eine organisatorische Gegenmaßnahme

Abb. 6.107: Risikomanagement wird bei PRINCE 2 ernst genommen


■ ■ ■

231

zu bestehenden Risiken liegt darin, diese Risiken in kürzeren Zeitabständen zu kontrollieren und eine Verantwortlichkeit zur ständigen Kontrolle bestimmter Risiken zuzuweisen. Definieren von Pufferzeiten, die mit bestimmten kritischen Komponenten und Aktivitäten verbunden sind, verhindern das zu frühe Binden von Ressourcen. Oft liegt das Risiko eines Teilproduktes darin, dass nach der Fertigstellung festgestellt wird, dass die benötigte Leistungsfähigkeit nicht vorhanden ist und Tuningmaßnahmen zu einer Überziehung von zeitlichen und finanziellen Toleranzwerten führen. Ein weiteres Risiko, welches nicht in der Hand einer Firma liegt, ist die Vergabe von Arbeitspaketen an externe Firmen oder Freiberufler. Diese haben oft ihre eigenen Prioritäten und Ziele, die nicht immer mit denen der eigenen Firma übereinstimmen. Deswegen sind hier eine regelmäßige Überprüfung des Fertigungsstandes und eine vertraglich vereinbarte Konventionalstrafe bei Lieferverzug ein Muss. Ein weiteres mögliches Risiko bei Fremdvergabe von Teilprodukten liegt auch in der Lieferung derselben, aber in mangelnder Qualität. Oft passiert es in der Praxis auch, dass wichtige Personalressourcen aus einem Projekt herausgenommen werden, um in anderen Projekten Feuerwehreinsätze durchzuführen „Koste es, was es wolle“, was dann auch sicherlich der Fall sein wird. Notwendige Schulungsmaßnahmen können sich mit wesentlichen Punkten des Projektplanes überschneiden. Persönliches Know-how einzelner beim Projekt beteiligter Mitarbeiter sollte mittels eines Vertreteransatzes breiter gestreut werden. Im Falle einer plötzlichen Krankheit ist somit sichergestellt, dass Arbeiten vom Vertreter übernommen werden können. Abb. 6.108: Instrumente zur Risikoeindämmung

Risiken Identifizieren

Risikoüberwachung

Risiko Analyse Risiken Analysieren

Risikokontrolle

Risiko Management

Risikoalternativplanung

Risikovorsorge Risiken Abschätzen

232

■ ■ ■

6 PRINCE 2

Abb. 6.109: Beispielhafte Risikomatrix

Auch muss davor gewarnt werden, zeitliche Risiken nur mit Überstunden abdecken zu wollen. Dies ist zwar in befristetem Maße sinnvoll, kann aber über längere Zeit zu mehr Fehlern führen als denen, die man eigentlich beseitigen wollte.


■ ■ ■

233

Risiken kommen aber nicht nur durch die tägliche Arbeit an einer Projektphase zum Vorschein, sondern auch durch Einflüsse außerhalb des Projektes. Diese sind vom Lenkungsausschuss eines Projektes zu behandeln und Informationen darüber dem Projektleiter frühzeitig zur Verfügung zu stellen. Jegliche Annahmen, die für die Durchführung eines Produkts notwendig sind, sind automatisch Risiken und müssen als solche zur weiteren Kontrolle vermerkt werden. Technische Annahmen, die sich nicht realisieren lassen, z. B. beim Einsatz neuartiger Entwicklungsarchitekturen oder -sprachen, können ein Projekt zum Neuanfang zwingen. Abb. 6.110: Risikoverlauf und Projektfortschritt

Risikopotential


Ist ein Projekt Teil eines größeren Vorhabens, so können externe, nicht beeinflussbare Risiken das Projekt beeinflussen oder bedrohen. Je größer ein Vorhaben ist, umso größer ist die Wahrscheinlichkeit, dass es niemals beendet wird. Hier gilt der Grundsatz, lieber kleinere autonome Teilprojekte durchzuführen und in den Betrieb zu überführen als ein großes Vorhaben, das an seiner unübersichtlichen, langen Projektlaufzeit und nicht überschaubaren Risiken scheitert. Eingangsprodukte können sein: x Risikoprotokoll (risk log) x Projektzeitplan (schedule) Ausgangsprodukte können sein: x Aktualisiertes Risikoprotokoll (risk log) x Überprüfter Plan (assessed plan) Verantwortlich für die Durchführung des Subprozesses ist: x Projektleiter mit Unterstützung des Lenkungsausschusses sowie aller Mitarbeiter mit Projektkontroll-Aufgaben.

234

■ ■ ■

6 PRINCE 2

6.4.8.7 PL7 (Vervollständigen eines Planes) Um einen Plan (Projektplan, Phasenplan, Ausnahmeplan) vom Lenkungsausschuss genehmigt zu bekommen, ist es erforderlich, diesen in eine ansprechende Form zu bringen, damit er für den Betrachter klar ersichtlich und selbsterklärend ist. Erläuternde Textpassagen und Zusammenfassungen zu wesentlichen Punkten (Annahmen, Risiken, zu erstellende Produkte, zugrunde liegende Ziele des Plans) erleichtern das schnellere Verständnis. Wird der Plan (Projektplan, Phasenplan, Ausnahmeplan) mit den zugebilligten Plantoleranzen durch den Lenkungsausschuss genehmigt, wird der Plan eingefroren (baseline) und dient später als Vergleich mit dem aktuellen Zustand. Ein weiterer wichtiger Punkt ist das Herausarbeiten von Toleranzgrenzwerten dieser Projektphase. Prozessbeziehungen und Erzeugnisse von PL 7 Input

PL2

Produktcheckliste (product checklist)

PL6

Überprüfter Plan (assessed plan)

Output

PL7

Überprüfter Plan zur Genehmigung, überarbeitete Produktcheckliste (completed plan for approval, updated product checklist)

Vervollständigen eines Planes (completing a plan) Verantwortlich für diesen Prozess ist der Projektleiter.

DP2 or DP3


IP2

Phasenplan (stage plan)

SB1


SB6


Die zugebilligten Plantoleranzwerte (Zeit, Kosten) sind abhängig von der Größe eines Projektes oder seiner Komplexität und sollten nicht zu eng sein, damit nicht „normale“ Ereignisse dazu zwingen, den Lenkungsausschuss zu benachrichtigen und einen Ausnahmeplan anzufertigen. Sie werden meist innerhalb des Lenkungsausschusses mit dem Projektleiter diskutiert, damit eine gemeinsame Sicht der Dinge erreicht wird, wo sich alle Parteien wiederfinden. Da der „harmonische“ Ablauf eines Projektes durch falsch gewählte Plantoleranzwerte gestört werden kann, ist es sicherlich gut, erfahrenes Personal im Vorfeld der Lenkungsausschusspräsentation um Durchsicht des aufgestellten Plans auf Vollständigkeit, vorausgesetzte Projektannahmen und verdeckte Risiken hin zu bitten.


■ ■ ■

235

Eingangsprodukte sind: x Kontrollierte Projektpläne (assessed plan) x Produktchecklisten (product checklist) Ausgangsprodukte sind: x Aktualisierte Produktchecklisten (updated product checklist) x Überprüfter Phasenplan zur Genehmigung (completed stage plan for approval) x Überprüfter Ausnahmeplan (completed exception plan for approval) x Überprüfter Projektplan (completed project plan for approval) Verantwortlich für die Durchführung des Subprozesses ist: x Projektleiter

6.5 PRINCE 2 und DSDM Die britische Regierung hat des Öfteren bei Auschreibungen von Softwareprojekten die Anwendung von PRINCE 2 und DSDM fest vorgeschrieben. DSDM beinhaltet von sich aus schon Prozesse, die ein notwendiges Management sicherstellen sollen, um qualitativ gute Ergebnisse in agiler Softwareentwicklung zu erzielen. In manchen Fällen ist es aber besser, das Projektmanagement durch die entsprechenden Prozesse von PRINCE 2 durchzuführen und die Belange der Softwareentwicklung mit den entsprechenden DSDM-Prozessen sicherzustellen. Abb. 6.112: Einsatz von DSDM unter PRINCE 2

236

■ ■ ■

6 PRINCE 2

Pre-project Starting up a project

Post project

Starting up a project

Closing a project

Initiating a project

Abb. 6.113: DSDM im Einsatz [33]

Feasibility Study Business Study Managing stage boundaries

Directing a project

Managing product delivery

Controlling a stage

FMI

Key PRINCE2 Process

Implementation Closing a project

All phases DBI

DSDM Phase

Verwendet man PRINCE 2 zusammen mit DSDM, so ist es interessant, in welchem Kontext PRINCE 2- und DSDM-Subprozesse genutzt werden. Die Abb. 6.113 gibt einen Überblick, wie PRINCE 2 und DSDM miteinander verzahnt werden können. DSDM ist wie im Kapitel 4 schon beschrieben, ein Vorgehensmodell um hauptsächlich Software zu entwickeln. PRINCE 2 dagegen ermöglicht das Projektmanagement von größeren Projekten. Verbindet man beide Vorgehensmodelle mit ihren Stärken miteinander, so werden Synergieeffekte frei, die helfen, die spezifischen Belange von Software-Entwicklungsprojekten zu erfüllen und den Aufwand für das Projektmanagement zu reduzieren. Der Widerspruch, der beim Verbinden beider Vorgehensmodelle sichtbar wird, ist, dass PRINCE 2 eingesetzt wird, um bei einem Projekt Zeit und Kosten zu kontrollieren, und DSDM den Ansatz vertritt, die zu entwickelnden Funktionalitäten dem Zeit- und Kostenrahmen anzupassen. Möchte man beide Vorgehensmodelle verbinden, so muss sichergestellt sein, dass Mangementprodukte und zugeordnete Rollen sich nicht überlappen. Beim Start eines Projektes werden sich PRINCE 2-Planungsprozesse mit der DSDMspezifischen Durchführbarkeits-Studie (feasibility study, FMI) und Geschäftsprozessanalyse (business study, DBI) überlappen. Weiterhin wird jede PRINCE 2-Projektphase mehrere Iterationen von FMI und DBI enthalten um das Endergebnis einer geplanten PRINCE 2Projektphase zu erhalten. Die innerhalb von PRINCE 2 vom Lenkungsausschuss (project borad) definierten Projekttoleranzen sind dann mit der Vorgabe von zu realisierenden „Must have“-Funktionalitäten gleichzusetzen. Sind diese nicht innerhalb von Zeit und Kosten zu realisieren, so muss der Lenkungsausschuss informiert werden.

6.5 PRINCE 2 und DSDM

■ ■ ■

237

Grundsätzlich muss bei der Kombination beider Vorgehensmodelle darauf geachtet werden, dass ein spezifisches Tailoring auf die durchzuführenden Maßnahmen am Beginn des Projektes durchgeführt wird um das Maximum der Vorteile beider Vorgehensmodelle zu erhalten.

6.6 PRINCE 2 und SSADM bzw. UML SSADM (Structured Systems Analysis and Design Method) wurde im Auftrag der britischen Regierung von dem Beratungsunternehmen LBMS (Learmonth and Burchett) in Zusammenarbeit mit der CCTA (Central Computer Telecommunications) ungefähr Anfang 1980 entwickelt und war seit 1983 zusammen mit PRINCE 2 von britischen Regierungsstellen bei neuen Projekten vorgeschrieben. Innerhalb des britischen Standards BS7738 wurde SSADM normiert. SSADM wurde im Laufe der Zeit dem Entwicklungsstand angepasst. Heute wird SSADM von UML (Unified Modeling Language) abgelöst. SSADM umfasst die folgenden Arbeitsschritte: x Definieren der Anforderungen x x x x

Dialogdesign Datenflussmodellierung Logische Datenmodellierung Geschäftssystembeschreibung

x Funktionsanforderungen x Relationale Datenanalyse x Spezifikationsprototyping x Entity-Event-Modellierung x Technische Systembeschreibung x Logische Datenbank-Prozessspezifikation x Physisches Datendesign x Physische Prozessspezifikation SSADM ist eine Methode, die bei einem Projekt die Systementwicklung von Informationssystemen von der Anforderungsanalyse bis zum Feinentwurf begleitet. Der Schwerpunkt von SSADM liegt in der Definition der Anforderungen mittels Datenfluss- und Datenmodellierung mit dem Schwerpunkt auf datenbankgestützte Informationssysteme.

238

■ ■ ■

6 PRINCE 2

6.7 PMMM (Project Management Maturity Modell) und P2MM (PRINCE 2 Maturity Modell) Um den Reifegrad von eingesetzten Firmen, ProjektmanagementFrameworks und Vorgehensmodellen beurteilen zu können, definierte das OGC (Office of Government Commerce) im Jahre 1994 das Project Management Maturity Modell (PMMM). Dies ist ein allgemeines Reifegradmodell für das Projektmanagement und dient als offizieller Standard zur Zertifizierung von Projektmanagementprozessen. PMMM enthält: x Vorschläge, um die eingesetzten Projektmanagementprozesse zu verbessern. x Leitfäden und Fragenkataloge zur Durchführung eines Assessments der eigenen firmeninternen Projektmanagementprozesse. x Unabhängig festgelegte „benchmarks“, um einen Vergleich von unterschiedlich eingesetzten Projektmanagementmethoden zu ermöglichen. Eine Zertifizierung nach PMMM ist im Allgemeinen über eine Zeitperiode von drei Jahren gültig, dann muss ein erneutes PMMMAssessment durchgeführt werden. Das PRINCE 2 Maturity Modell (P2MM) ist ein Reifegradmodell für PRINCE 2-Projektmanagement-Frameworks. Hiermit lässt sich überprüfen, ob die in einer Firma definierten PRINCE 2-Prozesse dem PRINCE 2-Standard genügen.

6.8 PRINCE 2-Zertifizierung und Schulungen Mittlerweile gibt es die verschiedensten Ausbildungskurse, die PRINCE 2 zum Gegenstand haben und verschiedene Zertifizierungsprogramme anbieten. Nachfolgend finden Sie eine Auswahl sowie weitere Hintergrundinformationen über die angebotenen Schulungsmaßnahmen. Da PRINCE 2 in der letzten Zeit viele Befürworter gefunden hat, gibt es verschiedene unabhängige Prüfungsinstitute und PRINCE 2Kursanbieter in Deutschland, wie die QRP Management Methods

6.7 PMMM (Project Management Maturity Modell) und P2MM (PRINCE 2 Maturity Modell)

■ ■ ■

239

PRINCE2

Abb. 6.114: Verschiedene Schulungen führen zu PRINCE 2Zertifizierungen

Zertifikation

Foundation (Zertifikat)

Practitioner-Level (Zertifikat)

International GmbH (www.qrpmmi.de) und arxes AG (www.arxes.de), beide in Köln, oder auch die Firma Maxpert (www.maxpert.de) in Ratingen. Weitere Adressen von Firmen, die PRINCE 2-Ausbildungskurse durchführen, stehen im Anhang. Folgende Schulungen werden durch die oben genannten Firmen angeboten: x PRINCE 2 Foundation (Prüfungs-Zertifikat) x PRINCE 2 Practioner-Level (Prüfungs-Zertifikat) Innerhalb der „PRINCE 2 Foundation Certificate“-Fortbildungsmaßnahme werden die Grundlagen von PRINCE 2 vermittelt, so dass der Teilnehmer ein Rüstzeug mitbekommt, um Abläufe, Rollen und Verantwortungsbereiche unter PRINCE zu verstehen. Spezifische PRINCE 2-Begriffe sind nach der Foundation-Schulung bekannt. Innerhalb der Practitioner (Fachmann, Praktiker)-Level-Examination-Fortbildungsmaßnahmen werden die Grundlagen spezieller Projektmanagementprozesse von PRINCE 2 vermittelt, so dass der Teilnehmer ein Rüstzeug mitbekommt, um diese Projektmanagementprozesse nach PRINCE 2 bereitzustellen oder in eine Firma einzuführen.

240

■ ■ ■

6 PRINCE 2

7 Nach der Abnahme (Servicemanagement eines neuen DV-Verfahrens)

Dort, wo PRINCE 2 aufhört, nämlich bei der Lieferung des Endproduktes, fängt die Aufgabe von ITIL an. ITIL stellt sicher, dass ein geliefertes IT-Verfahren die Pflege und den Service bekommt, die notwendig sind, um die damit unterstützten Geschäftsprozesse möglichst ohne größere Unterbrechungen durchführen zu können. Leider beschreibt weder PRINCE 2 noch ITIL den Übergang in die Nutzung des neuen IT-Verfahrens in einer Firma oder öffentlichen Institution. Ein Mittel, dies zu gewährleisten, ist das Betriebskonzept.

7.1 Die ITIL-Struktur (Die sieben Hauptbereiche von ITIL) Das „Best Practices Framework“ ITIL besteht seit dem Jahre 2002 aus sieben Hauptbereichen, manchmal auch Sets oder Module genannt, mit über 20 Einzelprozessen, die fast alle Aspekte eines heutigen IT-gestützten Geschäftsalltags umfassen und den Rahmen vorgeben, wie ein optimaler IT-Service innerhalb einer Firma aussehen könnte und wie dieser implementiert werden kann. ITIL baut eine Brücke zwischen den geschäftlichen Anforderungen einer Firma hin zur IT-Technologie. Im Einzelnen sind dies die folgenden Bereiche: x Business Perspective (die geschäftliche Perspektive) x Service Delivery (Planung und Lieferung von IT-Service) x Service Support (Unterstützung und Betrieb des IT-Services) x Security Management x ICT Infrastructure Management (Management der Infrastruktur)

7.1 Die ITIL-Struktur (Die sieben Hauptbereiche von ITIL)

■ ■ ■

241

x Applications Management (Management der Anwendungen) x Planning to Implement Service Management Allgemein bekannt sind in der Öffentlichkeit die beiden BasisHauptbereiche Service Support und Service Delivery sowie das Security Management, da sie das Tagesgeschäft im IT-Service abdecken. Diese werden im nachfolgenden Kapitel kurz erläutert. Abb. 7.1: Die sieben Module von ITIL

ICTInfrastructure Management (Management der Infrastruktur) Security Management (Management der ITSicherheit) Service Delivery (Planung und Lieferung von ITService)

Business Perspective (Geschäftliche Perspektive)

Application Management (Management der Anwendungen)

ITIL

Planing to Implement Service Management (Einführen von Service Management) Service

Support (Unterstützung und Betrieb des ITService)

Meist geht dabei aber der Blick auf die notwendige IT- und TKInfrastruktur verloren. ITIL gibt hier mit dem ICT Infrastructure unterstützende Hilfe. Auch der ITIL-Hauptbereich „Application Management“, der sich mit dem Software-Lebenszyklus (Lifecycle), angefangen bei Entwicklung, Test, Implementation bis zum Ausmustern der Software, beschäftigt, nimmt sich eines vernachlässigten Bereichs des IT-Alltags an.

7.1.1 Business Perspective Innerhalb des ITIL-Moduls „Business Perspective“ wird der Bereich behandelt, der sich mit dem IT-Service aus der Sicht der Geschäftsleitung beschäftigt. Es wird z. B. die Beziehung zwischen der ITOrganisation einer Firma und ihren externen IT-Suppliern bzw. Facilities-Management-Unternehmen vom Managementstandpunkt

242

■ ■ ■

7 Nach der Abnahme (Servicemanagement eines neuen DVVerfahrens)

Abb. 7.2: Die ITIL-Struktur im allgemeinen Kontext

Planing to Implement Service Management

Service Support

The Business Perspective

ICT Infrastructure Management

Service Delivery

Security Management

The Technology

The Business

Service Management

Applications Management

aus betrachtet. Auch Outsourcing von IT-Dienstleistungen oder das Business Continuity Management fällt in diesen Hauptbereich. Alle ITIL-Hauptbereiche dienen der Sicherstellung von qualifizierten und kosteneffektiven IT-Dienstleistungen, welche die Geschäftsprozesse eines Unternehmens wirkungsvoll unterstützen.

7.1.2 Planning to Implement Service Management Der Hauptbereich „Planning to Implement Service Management“ befasst sich mit der Planung, Einführung und fortlaufenden Verbesserung der ITIL-Prozesse. Dabei muss der Ist-Zustand erfasst und ein Ziel-Zustand definiert werden. Um eine kontinuierliche Verbesserung der ITIL-Prozesse durchführen zu können, ist eine laufende Analyse und Überprüfung der Ergebnisse notwendig.

7.1.3 Application Management Das ITIL-Modul „Application Management“ beschäftigt sich mit dem Planen, Entwickeln, Testen, Implementieren und Außerbetriebnehmen von in einem Unternehmen eingesetzten Applikationsprogrammen. Über den gesamten Lebenszyklus einer Applikation wird versucht, ein für das Unternehmen sinnvolles Management dieser geschäftsprozessabbildenden Programme durchzuführen. Definierte Standards zu Abnahme, Veränderung und Test runden das Tätigkeitsprofil des Applikations-Managements ab.


■ ■ ■

243

7.1.4 ICT Infrastructure Management Im ITIL-Modul ICT Infrastructure Management (Management der Infrastruktur) werden alle Aspekte abgehandelt, die sich mit der ITInfrastruktur und deren Überwachung befassen. Auch die kontrollierte Integration neuer IT-Verfahren bzw. IT-Infrastrukturen in ein Unternehmen sowie das Management von dezentral eingesetzten ITVerfahren gehört zum ICT Infrastructure Management.

7.1.5 Security Management Alle bisher beschriebenen Prozesse sind dem taktischen, strategischen Teil des IT-Geschäfts einer Firma zugehörig, so auch das Security Management. Aufgabe des Security Managements ist neben der Definition einer Firmen-Security-Policy die Aufstellung eines Security Plans, in dem alle Maßnahmen definiert sind, die die Datensicherheit einer Firma oder öffentlichen Institution sicher stellen sollen. Datensicherheit bedeutet hierbei das Sicherstellen der Vertraulichkeit, Integrität und Verfügbarkeit firmeninterner Daten. Auch muss die Authentizität dieser Daten oder eines Individuums, das die Daten lesen und verändern will, durch Prüfungsverfahren des Security Managements nachgewiesen sein. Um dieses

Abb. 7.3: Bestandteile von ITIL und zugrunde liegende Prozesse

Service Level Management

SD

SD Contingency Vertrieb Planning

Availability Management

Service Delivery

Release Management Incident Management

Configuration Management

Problem Management

Financial Management

Change Management

Capacity Management

ITIL

Security Management

Planning to Implement Service ICT Management

Infrastructure Management Applications Management

244

■ ■ ■


Service Support

Ziel zu erreichen, muss das Security Management mittels Audits überprüfen, ob die eingeführten Sicherheitsmaßnahmen eingehalten werden, sowie Schulungen in diesem Bereich durchführen. Es muss eine Analyse bzw. Auswertung sowie Klassifikation von erfolgten Angriffen, wie z. B. durch Softwareviren oder Hackversuche, vornehmen. Durch Auswahl entsprechender Firewall- und Antiviren-Software versucht das Security Management den Einfluss von unbefugtem Eindringen und Softwareviren auf zugrunde liegende DV-Verfahren zu minimieren. Es verfolgt und identifiziert den Ursprung solcher Angriffe. Weiterhin überprüft es, ob die gesetzlichen Rahmenbedingungen bei den firmenspezifischen Geschäftsprozessen eingehalten werden. Es überprüft die Verantwortlichkeit und sichert mit organisatorisch-technischen Anweisungen das Unternehmens-Know-how.

7.1.6 ITIL Service Management (Service Delivery, Support) im Überblick Ein Basis-IT-Service-Management nach ITIL besteht hauptsächlich aus den beiden Bereichen Service Support und Service Delivery und beinhaltet die 10 wichtigsten Serviceprozesse. Innerhalb des ServiceSupport-Bereiches werden die Service-Prozesse behandelt, die den direkten Nutzersupport und die Betriebsunterstützung betreffen und das tägliche Geschäft abhandeln. Hier fallen die Bearbeitung der vom Nutzer gemeldeten Störungen hinein sowie das Upgraden von Applikationssoftware und Betriebssystemkomponenten, möglichst ohne fühlbare momentane und zukünftige Unterbrechung des normalen Arbeitsablaufes. Dieses lässt sich nur gewährleisten, wenn Änderungen getestet sind und auch auf gesicherte Softwareversionen zurückgegriffen werden kann. Der Bereich Service Delivery handelt die Service-Prozesse ab, die planend oder steuernd in die notwendige ITDienstleistung oder IT-Infrastruktur eingreifen. Hierzu gehören auch die eindeutige Zuordnung der Kosten zu den Kostenverursachern sowie eine optimale Auslastung und Qualität der genutzten DVVerfahren bzw. deren zugrunde liegender IT-Ressourcen. Die Service-Delivery-Prozesse handeln grundlegende Absprachen mit den Nutzern der DV-Verfahren, wie z. B. Erreichbarkeit von Supportpersonal innerhalb von SLA (Service Level Agreements), aus und ergreifen vorbeugende bzw. taktische Maßnahmen für Ausnahmesituationen, wie z. B. softwarebasierende Virenattacken oder Erdbeben.


■ ■ ■

245

7.1.6.1 Service Support Der Service Support soll nach ITIL-Philosophie für die Nutzer eines DV-Verfahrens zentral von einer Stelle abrufbar sein. Dies wird meist mit einem Service Desk realisiert, wo Anfragen, Störungen sowie Wünsche der Nutzer zentral entgegengenommen und bearbeitet werden. Der Nutzersupport wird mit dem Service-Prozess Incident Management und teilweise (reaktives Problemmanagement) mit dem Problem-Management-Prozess abgehandelt, wobei das Problem Management auch die generelle Betriebsunterstützung (proaktives Problemmanagement) betrifft, die der Nutzer nicht direkt bemerkt. Probleme werden idealerweise möglichst beseitigt, bevor sie überhaupt auftreten, sowie Software-Updates erst aufgespielt, wenn sie auf Herz und Nieren getestet wurden (Change- und Release Management). All diese IT-Dienstleistungen lassen sich aber erst durchführen, wenn alle Komponenten eines DV-Verfahrens erfasst und beschrieben sind. Dies ist Aufgabe des Configuration Managements. Nachfolgend sind die Service-Prozesse aufgelistet, die dem Service Support zugeordnet sind, sowie eine kurze Einführung, die einen Überblick über die jeweils zugrunde liegende Problematik verschaffen soll, bevor wir uns detailliert mit den einzelnen IT-Service-Prozessen auseinandersetzen. x Incident Management sowie Service Desk x Problem Management x Configuration Management x Change Management x Release Management Incident Management sowie Service Desk Das Incident Management beschreibt einen standardisierten Prozess über den Umgang mit einer Störungsmeldung oder Hilfeanforderung zu einer Applikationsanwendung. Die Störungsbeseitigung soll möglichst schnell erfolgen und beseitigt meist nicht die Ursache eines Problems oder Fehlers. Meist ist das Incident Management verbunden mit einem Service Desk oder Customer Help Desk. Das Incident Management wird meist innerhalb des First-Level Support abgehandelt. Incident Management behandelt die Schnittstelle zwischen den Nutzern eines DV-Verfahrens und der IT-Abteilung, die den entsprechenden Support abdeckt. Der Call-Incident-Prozess behandelt die Bearbeitung von Störungen (Incidents) und erfasst (record) diese. Die Störungen werden klassifiziert und abgearbeitet. Als

246

■ ■ ■


Service Support


Incident Management (Service Desk) Release management (Software control and distribution)

Problem Management

Abb. 7.4: Service Support im Überblick

Change Management

Unterstützung/ Information

Schnittstelle oder zentrale Anlaufstelle fungiert das Service Desk. Das Service Desk nimmt eine Ausnahmestellung innerhalb des ITIL Service Support Frameworks ein, bei dem es sich nicht um einen Dienstleistungsprozess, sondern um ein zentrales Instrument für ein erfolgreiches Service Support handelt. Das Service Desk fungiert als die Schnittstelle zwischen Nutzer und IT-Dienstleister innerhalb einer Firma. Hier fließen Informationen in beide Richtungen. Informationen sind lebenswichtig. Deshalb ist die Art und Weise, wie die Übermittlung stattfindet, von elementarer Bedeutung. Durch Einsatz einer ITIL-konformen-Software, meist auf Telefonbasis mit CTI (Computer Telephony Integration oder Computerized Telephone Integration)-Schnittstelle sowie einer oft mit integrierter Remote-Access-Software ausgestatteten Software, die es erlaubt, auf den Rechner eines Nutzers per Remoteverbindung zuzugreifen, stellt das Service Desk den Dreh- und Angelpunkt für sämtliche alltäglichen Wünsche und Sorgen eines neuzeitlichen computerisierten Arbeitsplatzes dar. Meist enthält die Service-Desk-Software einen Zugang zu der CMDB (Configuration Management Database)-Datenbank, in der alle Komponenten oder Assets einer Firma sowie deren Schnittstellen zu anderen Assets oder Komponenten beschrieben sind. Ein gutes Service Desk ist integraler Bestandteil eines guten CRM (Customer Relationship Management) einer Firma.


■ ■ ■

247

Problem Management Im Gegensatz zum Incident Management wird innerhalb des Problem-Management-Prozesses beschrieben, wie die Ursache eines Problems gefunden werden kann, oder wie überhaupt festgestellt werden kann, dass ein grundsätzliches Problem mit der Komponente eines DV-Verfahrens vorliegt. Das Problem Management wird meist innerhalb des Second- bis Third-Level-Supports abgehandelt, manchmal unter Zuhilfenahme anderer Dienstleister oder Firmen, die entsprechend koordiniert werden müssen. Das Problem Management bearbeitet momentan vorliegende Fehler (Reactive Problem Management) und analysiert die in der Vergangenheit aufgetretenen Fehler oder Fehlermuster, um grundsätzliche Ursachen und Probleme zu ermitteln (proactive Problem management). Configuration Management Das Configuration Management einer IT-Organisation, manchmal auch Asset Management genannt, hat die Aufgabe, alle Komponenten, ihre Schnittstellen und die Beziehung zu anderen Komponenten zu ermitteln, zu beschreiben und zu überprüfen, ob die Informationen noch auf dem neuesten Stand sind. Grundlage des Configuration Managements ist eine Datenbank CMDB (Configuration Management Database), in der all diese Informationen dokumentiert und abrufbar sind. Diese Informationen stellen die Grundlage für die Arbeit anderer ITIL-konformer Serviceprozesse, wie das Incidentund das Change Management bzw. das Financial Management dar. Durch Analyse der CMDB lassen sich, je nach Aufgabenstellung, Entscheidungsvorlagen generieren. So kann z. B. die Fehlerhäufigkeit eines DV-Verfahrens oder ISP (Internet Service Provider) die Notwendigkeit deutlich machen, das DV-Verfahren abzuschreiben bzw. den ISP zu wechseln. Abb. 7.5: Geschäftsziele sind nur durch den Einsatz von IT-Verfahren erreichbar. Dies macht die intelligente Steuerung eines Unternehmens bezüglich der IT-Ressourcen notwendig.

248

■ ■ ■

Firmenstrategie

{ Geschäftsziele

Taktisches Vorgehen und Planung

{

ITIL-Bereich Service Delivery

Tägliches Operatives Handeln

{

ITIL-Bereich Service Support


Change Management Innerhalb des Change Managements werden Veränderungen (Changes) an bestehender Applikationssoftware oder an IT-Komponenten mittels eines ITIL-konformen Prozesses durchgeführt. Diese sollen bewirken, dass alle Beteiligten vor einer Veränderung informiert sind, Zuständigkeiten zugeordnet werden und dass den Veränderungen eine Priorität zugewiesen werden kann. Sind RFCs (Request for Change) vorgesehen, so muss das Change Management dafür sorgen, dass die von Risiken bereinigten Änderungen termingerecht durchgeführt werden. Sollten wider Erwarten durch den durchgeführten RFC Fehlerzustände eintreten, so muss der vom Configuration Management im Vorfeld erarbeitete Back-Out-Plan durchgeführt werden. Das Change Management arbeitet mit den Informationen, die in der CMDB (Configuration Management Database) niedergelegt sind. Release Management Aufgabe des Realease Mangements ist es, RFCs zu planen, zu erstellen, zu testen, zu implementieren (Roll Out) sowie unterschiedliche Patch- und Versionsstände zu verwalten. Die Versionsstände sind innerhalb einer DSL (Definitive Software Library) zu speichern, so dass bei Fehlerzuständen alte Versionsstände wieder genutzt werden können. Besonders bei Applikationssoftware-Veränderungen, die an hunderten von Arbeitsplatzrechnern vorgenommen werden müssen, ist eine automatische, zeitnahe und aktuelle Softwareverteilung von ausgetesteter Software notwendig. Dies erleichtert auch eine zentrale Lizenzverwaltung sowie die finanztechnische Verwaltung. Auch das Training oder eine betriebliche Dokumentation der Nutzung veränderter Funktionalitäten innerhalb eines Releases sind Aufgabe des Release Managements.

7.1.6.2 Service Delivery Der Service Support soll nach ITIL-Philosophie für die Nutzer eines DV-Verfahrens eine abgestimmte Leistung zur Verfügung stellen. Diese Leistungen zu spezifizieren, ist Aufgabe des Service Level Managements innerhalb des Service Delivery. Um Leistungen gerecht verrechnen zu können, ist das Financial Management in einer Firma von wichtiger Bedeutung. Was passiert, wenn DV-Verfahren längerfristig ausfallen? Welche Alternativmöglichkeiten gibt es, um weiterhin geschäftsfähig zu bleiben? Diese Frage stellt sich das Contingency Management und zeigt Lösungsmöglichkeiten auf. Innerhalb des Availability Managements versucht man, die Verfügbarkeit zu erhöhen bzw. die „Down Time“ eines DV-Verfahrens zu verkleinern.


■ ■ ■

249

Hierbei übernehmen Backup- und Recovery-Verfahren, angepasst an ein DV-Verfahren, eine wesentliche Aufgabe. Aber auch das Design eines DV-Verfahrens ist von existentieller Wichtigkeit, da sich Schwächen im Design meist im gesamten Lebenszyklus (Live Cycle) eines DV-Verfahrens bemerkbar machen. Beim Capacity Management nach ITIL wird versucht, den Anforderungen bezüglich Auslastung und Antwortzeit- bzw. Transaktionszeit-Verhalten der Nutzer eines DV-Verfahrens gerecht zu werden. Die einzelnen ServiceProzesse des Bereiches Service Delivery unter ITIL werden nachfolgend kurz erklärt. Es sind die Prozesse: x Service Level Management x Continuity Management x Availability Management x Capacity Management x Financial Management Service Level Management Das Service Level Management stellt sicher, dass die Anforderungen des Nutzers interner DV-Verfahren ermittelt, niedergeschrieben und auch von jedem nachgelesen werden können. Es regelt im Vorfeld des Einsatzes eines neuen DV-Verfahrens, welche Eskalationsvorgänge eingeleitet werden sollen, bevor es überhaupt einmal dazu gekommen Abb. 7.6: Service Delivery im Überblick

Service Delivery

Contingency Planning

Availability Management Financial Management (Cost management for IT service) Service Level Management

Capacity Management

Sicherstellung des Service

250

■ ■ ■


ist. Vorstellungen der unterschiedlichen Abteilungen, die miteinander arbeiten sollen, manifestieren sich innerhalb eines SLA (Service Level Agreement) oder OLA (Operational Level Agreement). Innerhalb eines SLA sind Ansprechpartner genannt für alle Wechselspiele des Lebens eines DV-Verfahrens. Auch die Service- und Reaktionszeiten, innerhalb derer eine Störung anfänglich bearbeitet werden soll, sind wesentliche Bestandteile solch eines Dokumentes.

a M

n a g

t

e m e n

se zes Pro

Me nsc hen

Continuity Management Das Continuity Management soll sicherstellen, dass bei Total- oder Teil-Ausfall von Funktionalitäten eines DV-Verfahrens entsprechende Ersatzkomponenten bzw. Ersatzsysteme, wenn auch eingeschränkt, vorhanden sind, die diese Funktionalitäten wieder zur Verfügung stellen. Ist ein DV-Verfahren als Ganzes über längere Zeit ausgefallen, so werden vorbereitete Pläne des Continuity Management wirksam, wie z. B. Ersatzsysteme anderer Firmen anzumieten oder die Leistungen eines DV-Verfahrens als Ganzes von anderen Firmen übernehmen zu lassen. Weiterhin erstellt das Continuity Management Analysen und Vorgangsweisen darüber, wie Ausfälle von DV-Verfahren vermieden werden können, sowie Wiederanlaufpläne und Pläne dazu, wie ein eventueller Produktionsausfall aufgeholt werden kann. Denkt man an einen Brand im Rechenzentrum, der nicht schnell genug bemerkt bzw. gelöscht wurde, so wird einem die Herausforderung, technisch wie logistisch, die dieser ITILProzess an die Verantwortlichen stellt, klar. Abb. 7.7: Effektives Management der natürlichen Ressourcen mittels ITIL-Ansatz

ITIL Service Support Service Delivery

Technologie Availability Management Es stellt sicher, dass die Verfügbarkeit eines IT-Services bzw. eines DV-Verfahrens sowie die benötigte Infrastruktur, wie z. B. Netzwerk, so hoch wie möglich sind. Risikoanalysen, eventuell als Audit, von


■ ■ ■

251

internem oder externem Personal sollen die Schwachstellen identifizieren helfen. Aus den gewonnenen Erkenntnissen werden entsprechende Maßnahmen vom Availability Management eingeleitet. Es sorgt für die Überwachung (Monitoring) externer Dienstleister, zur Verfügung gestellter Serviceleistungen, wie z. B. Übertragungsbandbreite, und setzt technische Verfahren ein, wie z. B. Load Balancer bzw. ISP-Load Balancer, die gegen externe, nicht verschuldete Fehler schützen. Auch die Erstellung und Einhaltung von Backup- und Recovery-Plänen bzw. die Erstellung von verfügbarkeitserhöhenden proaktiven Maßnahmen gehört zu dem Aufgabengebiet des Availability Managements. Wahrscheinlich ist dieser ITIL-Prozess der vom Anwender am wenigsten beachtete, aber einer mit dem größten Nutzen für eine von der Firma zu erbringende Dienstleistung. Capacity Management Das Capacity Management soll die kostenoptimierte und rechtzeitige Bereitstellung von Ressourcen oder Infrastrukturkomponenten sicherstellen, die zum Erreichen der geschäftlichen Belange einer Firma erforderlich sind. Typische Beispiele für eine Ressource sind z. B. Bandbreite eines ISP (Internet Service Provider), Festplattenspeicherplatz oder Rechenleistung eines Serversystems. Aber auch die ausreichende Wartung eines DV-Verfahrens ist ein Aspekt und Einsatzgebiet des Capacity Managements. Durch Analysen des Capacity Managements sind fundierte Voraussagen über den weiteren Verbrauch bestehender Ressourcen möglich. Diese wiederum sorgen dafür, dass zu den entsprechenden Zeitpunkten die Ressourcen gekauft werden und damit der ITOrganisation zur Verfügung stehen, was sich nicht nur auf die eingesetzten technischen Ressourcen, sondern auch auf das benötigte Servicepersonal bezieht. Somit sorgt das Capacity Management für eine Verkleinerung der Risiken, die durch Kapazitätsengpässe verursacht werden. Es sorgt für einen effektiven Gebrauch bestehender Ressourcen und schafft durch Bereitstellung entsprechender Analysen eine verbesserte Planungsgrundlage. Abb. 7.8: Wahlspruch in Zeiten von kleineren IT-Budgets

Der eine wartet, dass die Zeit sich wandelt, der andere packt sie kräftig an und handelt. Dante

252

■ ■ ■


Financial Management Das Financial Management hat die undankbare Aufgabe, die effektiven Kosten eines IT-Services zu ermitteln und sie den Kostenverursachern zuzuordnen. Da die Geschäftsleitung einer Firma die Gewinnspanne erhöhen will, ist sie auf Zahlenmaterial des Financial Managements angewiesen, um ein abstrahiertes Bild des Unternehmens zu erlangen. Weiterhin geben finanzielle Analysen der Geschäftsleitung Auskunft darüber, welche Bereiche optimiert werden müssen und welche strategischen Anschaffungen in der Zukunft notwendig werden. Auch die Höhe der Kosten, die durch externe Dienstleistungen angefallen sind, führt meist zu der Standardfrage, ob diese Leistung nicht intern erbracht werden könnte. Weiterhin lassen sich durch eine genaue Kostenaufstellung die berechneten internen und externen Kostensätze auf den neuesten Stand bringen.

7.2 Betriebskonzept Wird ein neues DV-Verfahren innerhalb einer Firma eingeführt (Rollout), so ergeben sich immer wieder die gleichen Schwierigkeiten. Es gibt zwar IT-Service-Abteilungen mit entsprechendem Personal, aber wie das neue DV-Verfahren in den normalen Tagesablauf integriert wird, wer zuständig ist, welche Anforderungen es gibt bezüglich Wartung und wann diese Wartung durchgeführt wird, wer die Nutzer dieses neuen DV-Verfahrens schult: all dies liegt im Dunkeln. Incident Management

Problem Management Service Level Management


Abb. 7.9: Eingliedern eines neuen DV-Verfahrens in eine bestehende IT-Organisation mittels Betriebskonzept

Change Management

Availability Management

Release Management Contingency Management

Financial Management

7.2 Betriebskonzept

■ ■ ■

253

Meist erkennt man erst nach einem vollständigen Ausfall des DVVerfahrens, dass keine Havariemöglichkeiten eingeplant wurden und auch kein Backupkonzept erstellt wurde. Es fehlen also die Informationen und die technischen Mittel, wie Backupscripte, um diese DV-Verfahren ordnungsgemäß betreiben zu können. Oft wurden auch keine entsprechenden Entwicklungskosten für all diese Dinge bereitgestellt, weil man einfach davon ausgeht, dass die entsprechenden IT-Abteilungen dies schon irgendwie handhaben werden. Dabei vergisst man jedoch, dass diese IT-Abteilungen weder genügend personelle Ressourcen haben, um mal gerade eben all die Dinge zu implementieren, die ihrer Meinung nach notwendig sind, noch ist das Personal entsprechend ausgebildet, dies zu tun. Das Personal hat Erfahrung im Betreiben und Warten von DVSystemen, aber sie sind keine Entwicklungsingenieure. Dies ist bei ITIL-basierenden IT-Supports nicht anders und ein Schwachpunkt innerhalb des ITIL-Standardansatzes. Dies wurde schon von verschiedenen Professoren in der Lehre und Verantwortlichen in der Praxis bemerkt, wenn auch manchmal ziemlich spät. Um dieses Missverständnis zwischen den IT-Serviceabteilungen und der Projektabteilung, die für die Beschaffung des neuen DVVerfahrens verantwortlich ist, aufzulösen, ist das Erstellen eines Betriebskonzepts für ein neues DV-Verfahren unumgänglich. Ein allgemeines Problem bei der Einführung eines neuen DVVerfahrens in eine bestehende Arbeitsorganisation liegt auch darin, dass man nicht genau abschätzen kann, wie viel Manpower an welchen Stellen der IT-Organisation zusätzlich benötigt wird und welche besonderen Erwägungen und Einflusskriterien diese neuen DVVerfahren mit sich bringen. Das Betriebskonzept ist das Resultat eines Assessments über die gegenwärtige Situation eines neuen DV-Verfahrens bezüglich seiner Kompatibilität für eine bestehende IT-Organisation. Innerhalb des Betriebskonzeptes ist eine kurze Beschreibung des neuen DV-Verfahrens mit seinen Grundfunktionalitäten, eine Aufgaben-beschreibung sowie eine Auflistung interner und externer Schnittstellen enthalten (technisch und organisatorisch). Das Betriebskonzept beschreibt auf der Basis der ermittelten Kennparameter des DV-Verfahrens die firmeninternen Organisationsstrukturen und Verantwortlichkeiten, um die Geschäftsprozesse der Firma in technischer Hinsicht zu gewährleisten (Normalbetrieb und Havariefälle). Die entsprechenden Arbeitsmaßnahmen werden dabei den beteiligten ITAbteilungen zugeordnet.

254

■ ■ ■


7.2.1 Inhaltliche Ziele des Betriebskonzepts Das Betriebskonzept hat das Ziel, Kennparameter des DV-Verfahrens zu ermitteln, so dass entsprechende organisatorische Maßnahmen getroffen sowie die erforderlichen Ressourcen für einen ordnungsgemäßen Betrieb zur Verfügung gestellt werden können. Dadurch können die anstehenden Arbeiten den beteiligten IT-Abteilungen zugeordnet und die erforderlichen Ressourcen dem gewünschten neuen DV-Verfahren zur Verfügung gestellt werden. Es soll ermittelt werden, welche Kosten im Betriebshaushalt für DVVerfahren in den nächsten 5 Jahren anfallen, und auf momentane Risiken (zeitlich, technisch, personell, rechtlich) aufmerksam gemacht werden. Ein Ausblick auf die Zukunft ermöglicht es, Aufschluss über den notwendigen Investitions- bzw. Betriebshaushalt zu erhalten. Wieviel Mehrarbeit entsteht durch ein neues DV - Verfahren ?

Arbeitsaufgaben durch neues DVVerfahren

Abb. 7.10: Schätzungen der Mehrarbeit durch Einführen eines neuen DV-Verfahrens

Personentage und Planstellen je Abteilung

Bestandteil dieses Konzeptes ist weiterhin ein Backup- und Havariekonzept, um im Fehlerfall geeignete Mechanismen zur Hand zu haben, die eine möglichst schnelle Wiederherstellung des produktiven Betriebes ermöglichen. Es enthält ein Schulungskonzept, um die späteren Nutzer und Betreuer in das DV-Verfahren einzuweisen und somit die Akzeptanz des DV-Verfahrens zu erhöhen. Es klassifiziert die publizierten Daten entsprechend dem Datenschutzaspekt. Das Betriebskonzept hat die Aufgabe, die notwendigen Wartungs- und Pflegearbeiten, die vorhandenen Lücken sowie den dazugehörigen Personaleinsatz, der sich daraus ergibt, zu ermitteln.

7.2 Betriebskonzept

■ ■ ■

255

Das Betriebskonzept beschreibt auf der Basis der ermittelten Kennparameter des DV-Verfahrens die firmeninternen Organisationsstrukturen und Verantwortlichkeiten, um die Geschäftsprozesse der Firma in technischer Hinsicht zu gewährleisten (Normalbetrieb und Havariefälle). Die entsprechenden Arbeitsmaßnahmen werden dabei den beteiligten IT-Abteilungen zugeordnet. Das Betriebskonzept zwingt die verschiedenen Abteilungen einer Firma (Anwenderabteilungen und Serviceabteilung), sich an einen Tisch zu setzen und über das neue DV-Verfahren in einer menschlichen Art und Weise zu reden. Durch den standardisierten Ansatz werden die notwendigen Gesprächsthemen so vorgegeben, dass alle Beteiligten zu Wort kommen und ihre Vorstellungen äußern können. Abb. 7.11: Projektphase eines neuen DV-Verfahrens innerhalb einer Firma

Integration eines neuen DV-Verfahrens in die bestehende Firmenstruktur

Konzept

Entwurf

Realisierung

Test

Einführung

Konzeptpapier

Grobkonzept Pflichtenheft/ Feinkonzept Abnahmetests und Probebetrieb Betriebskonzept

Das Betriebskonzept schafft Transparenz der Tätigkeiten innerhalb der jeweils anderen Abteilung und bringt die beteiligten Menschen zusammen. Am Ende des sicher langwierigen Abstimmungsprozesses sind alle notwendigen Maßnahmen und Prozesse für die effektive Nutzung dieses DV-Verfahrens definiert, Verhaltensregeln für Ausnahmesituationen und Verantwortlichkeiten festgelegt und eventuell durch verschiedene persönliche Kontakte sogenannte „kleine Dienstwege“ entstanden. Mögliche inhaltliche Punkte eines Betriebskonzeptes: x Überblick über das neue DV-Verfahren sowie Ermittlung des Ist-Zustandes

256

■ ■ ■


x Einsatz, räumliche Zuordnung der dem DV-Verfahren zugeordneten Komponenten und Datenschutzaspekte x Aufzählung technischer Schnittstellen und Nutzung der technischen Infrastruktur der Firma x Mengengerüst (Anzahl Server, Datenbankinstanzen, Webserver, zu wartendes Speichervolumen usw.; wie viele Nutzer sollen mit dem neuen DV-Verfahren arbeiten, eventuell Schätzzahlen) x Art und Versionen der eingesetzten Software x Einordnung des DV-Verfahrens bezüglich seiner Verfügbarkeit (Mission) x Involvierte Abteilungen und deren Ansprechpartner, Nutzersupportplan (Hotline, Rufbereitschaft) x Erreichbarkeit, Systemüberwachung und Wartungsfenster x Benachrichtigung der Nutzer und Hausabteilungen bei Störungen x Erforderliche Remote-Zugänge x Havariemaßnahmen x Eskalationsvorgang bei Störungen (17:0008:00) x Beschreibung der geschätzten Arbeitsaufgaben mit Anteilen Personentage, um den Betrieb des neuen DV-Verfahrens sicherzustellen, untergliedert nach Abteilungen sowie Planstellen, die dem neuen DV-Verfahren zugeordnet sind x Benchmarks für spätere SLAs (Service Level Agreements x Externe Wartung und Wartungsvertragsnehmer (Kontaktadressen, Wartungsdaten, Kosten) x Kontaktadressen zu den externen Schnittstellen des DV-Verfahrens x Monitoring und Fehlererfassung x Schulungskonzept x Schulungsunterlagen für CMS-User x Backup- und Datensicherungskonzept x Datensicherungsplan x Havariekonzept x Workflow im Havariefall x Desasterplan x Havarieübungen

7.2 Betriebskonzept

■ ■ ■

257

x Krisenstab x Testsystem x Patch- und Change Management x Incident-, Problem- und Configuration Management x Dokumentation und Verantwortlichkeit sowie Überprüfung, ob Systeme und Kabel ausreichend beschriftet wurden (verkleinert MTTR) x Kennparameter und Schwachstellen- bzw. Risikoanalyse des neuen DV-Verfahrens im Überblick (zeitlich, personell, technisch) x Kennparameter des neuen DV-Verfahrens im Überblick x Ausblick auf den zukünftigen Ausbau des DV-Verfahrens und die daraus abzuleitenden Ziele Bei Gesprächen mit den verschiedenen Abteilungen einer Firma, die dem Erstellen des Betriebskonzeptes dienen, werden die unterschiedlichsten Anforderungen erfasst, die als Grundlage von späteren SLAs zwischen den Anwendern und den betreibenden Fachabteilungen dienen können. Das Betriebskonzept wird regelmäßig aktualisiert und eventuell an neue technische Bedingungen angepasst. Jede Fachabteilung informiert die für das Erstellen des Betriebskonzepts verantwortlichen Mitarbeiter über Änderungswünsche. Abb. 7.12: Aus dem Mengengerüst lassen sich Aufwand und Kosten des Betriebes abschätzen

7.2.2 Mengengerüst Das alte Prinzip, „Ross und Reiter“ zu nennen für eine spätere Verantwortlichkeit, ist innerhalb eines modernen IT-gestützten Verfahrens nicht mehr ausreichend. Hier müssen weitere technisch beding-

258

■ ■ ■


te Kennwerte vorher ermittelt oder geschätzt werden, um diese in die bestehende Arbeitsorganisation zu überführen. Viele Kennparameter eines IT-Services lassen sich nur von einem genauen Mengengerüst ableiten. Deswegen ist das Mengengerüst eine Grundlage des Betriebskonzeptes. Aus dem Mengengerüst erklären sich nachvollziehbar der Arbeitsaufwand und die Kosten für die Pflege und Wartung. Beispieldaten für ein Mengengerüst sind: x Wie viele Nutzer sollen mit dem DV-Verfahren arbeiten? x Wie hoch ist das Datenaufkommen? x Zu wartendes Speichervolumen? x Wieviele Server und Datenbanken sind innerhalb des DV-Verfahrens enthalten bzw. erforderlich? x Welche Netzwerkbandbreite mit welchen Qualitätsanforderungen? Ableitbare Arbeitspakete aus diesem Mengengerüst sind z. B., dass jeder Server und jedes Datenbanksystem Backup-Prozeduren braucht, die es erlauben, Datenbestände zu restaurieren. Weiterhin ist die Personalunterstützung abschätzbar, die dafür notwendigen Speichermedien einzulegen und diese Speichermedien zu verwalten. Auch sind Pflegemaßnahmen für jedes einzelne Serversystem und die angrenzende Peripherie durchzuführen. Die Anzahl der Nutzer eines neuen DV-Verfahrens lässt den Schulungsbedarf erahnen sowie die Personalstärke eines späteren optimalen IT-Services. Aus diesen Beispielen kann man die Nützlichkeit eines genauen Mengengerüstes ersehen.

7.2.3 Zuständigkeitsmatrix Die nach ITIL definierten Serviceprozesse müssen den einzelnen Abteilungen zugeordnet werden, die die entsprechenden Serviceprozesse innerhalb einer Firma abbilden. Diese Zuständigkeiten können von DV-Verfahren zu DV-Verfahren, je nach Eigenheit des Systems, variieren. Deswegen ist die Zuständigkeitsmatrix innerhalb des Betriebskonzepts der Punkt, an dem dies das erste Mal festgelegt wird. Tabelle 7.1 zeigt den Inhalt einer beispielhaften Zuständigkeitsmatrix.

7.2 Betriebskonzept

■ ■ ■

259

Tabelle 7.1: Beispielhafte Zuständigkeitsmatrix

Prozess

Verantwortlich für die Umsetzung

Zuarbeit

Dokumentation

IT-Planungsabteilung RZ

RZ, IT-Hotline, Pro- Alle 3 Monate blemmanagement Problemmanagement Alle 3 Monate

IT-Hotline

AnwenderabteiAlle 6 Monate lungen RZ, IT-PlanungsAlle 6 Monate abteilung, IT-Hotline

Change-/Patchmanagement Incident-/Problemmanagement Availability- und Continuity Management Datenschutz / Security-Management / Mitbestimmung Schulung

RZ

Prüfungszeitraum

IT-Planungsabteilung

Justitiariat

Alle 6 Monate

Problemmanagement / IT-Planungsabteilung

Anwenderabteilungen

Alle 6 Monate

Innerhalb der Zuständigkeitsmatrix kann ein Zeitraum festgelegt werden, in dem entweder überprüft werden soll, ob sich die Dokumentation eines DV-Verfahrens verändert hat oder die ServiceProzesse für dieses DV-Verfahren angepasst werden müssen. Dies ermöglicht die Anpassung des Service-Prozesses an die zeitlichen Gegebenheiten der abgebildeten Geschäftsprozesse einer Firma.

7.2.4 Erreichbarkeit, Wartungsfenster sowie Eskalationsvorgang bei Störungen 7.2.4.1 Erreichbarkeit Die Erreichbarkeit eines IT-Services ist von ebenso großer Bedeutung wie der IT-Service an sich. Sie richtet sich nach den Erfordernissen einer Firma. Früher wurden DV-Verfahren meist in einem Zeitfenster von 7:00 bis 19:00 Uhr genutzt. Dies ist heute im Zeitalter von Globalisierung und eBusiness anders; 7 u 24-Stunden-Betrieb ist notwendig. Jede Firma muss daher definieren, ob ein Schichtdienst für wesentliche IT-Serviceleistungen notwendig ist oder aber eine Ruferreichbarkeit für schwere Fehler im Anschluss an die normalen Dienstzeiten ausreichend ist. Dies hat neben der rein menschlich-sozialen auch eine

260

■ ■ ■


Mo.-Fr.

Hotline RZ Incident Management

8:30

Sa.-So.

8:30

Hotline Ruferreichbarkeit

17:00

Wachdienst Ruferreichbarkeit

24:00

8:30

Wachdienst Ruferreichbarkeit

Hotline Ruferreichbarkeit

17:00

Unterstützung

Abb. 7.13: Schematische Darstellung der Anwenderunterstützung im zeitlichen Bezug

Unterstützung

8:30

Kostenkomponente. Oft findet sich die Erreichbarkeitsanforderung als eine der zu vereinbarenden Kennparameter innerhalb des Betriebskonzeptes oder eines SLAs wieder, die zwischen den Anwenderabteilungen und der IT-Serviceabteilung vereinbart werden. Da meist eine zentrale Telefonnummer als Störungsannahme dient, muss diese nach den Kernarbeitszeiten z. B. zum Wachdienst entsprechend umgeleitet werden. Je nach Dringlichkeit wird dann dort entschieden, ob der entsprechende Mitarbeiter, der die Ruferreichbarkeit übernommen hat, angerufen wird, und ob er, sofern sich die Störung nicht per Remote Access beseitigen lässt, den Fehler vor Ort zu beseitigen versucht. Ruferreichbarkeit ist oft mit einer festgelegten Reaktionszeit verbunden.

7.2.4.2 Wartungsfenster So interessant und lebensnotwendig die Kommunikation zwischen den Anwendern und der IT-Serviceabteilung ist, so überrascht ist man, wenn es darum geht, ein Wartungsfenster für ein neues DVVerfahren zu vereinbaren. Dies ist in etwa so, als ob man einem dreijährigen Kind ein gerade überreichtes Geschenk wieder entwendet. Normen werden außer Kraft gesetzt. Übrig bleiben dann meist Zeiten, in denen andere gerne schlafen oder sich um ihre Familien kümmern. Oft ist es auch notwendig, für diese Zeit externen Kunden im Vorfeld und während der Wartungsarbeiten eine Benachrichtigung zukommen zu lassen. Information über Wartungsfenster und die daraus entstehenden Folgen ist in diesem Falle existentiell, um das Verständnis und die Zufriedenheit der Kunden zu erhalten.

7.2 Betriebskonzept

■ ■ ■

261

7.2.4.3 Eskalationsvorgang bei Störungen Jedes DV-Verfahren, das die Geschäftsprozesse einer Firma abbildet, hat seine Eigenheiten, wenn es zu einem längeren Ausfall kommt. Hier müssen unterschiedliche inoder externe Personen oder Stellen benachrichtigt oder Ersatzlösungen in einen einsatzbereiten Zustand versetzt werden. Um diesen Fall möglichst nicht kopflos und emotionsgeladen über sich ergehen zu lassen, muss im Vorfeld rational festgelegt werden, wie man sich verhält. Alle zu informierenden Stellen, Entscheidungsträger, Kunden, Wartungsvertragsnehmer mit ihren Kontaktadressen werden im Vorfeld innerhalb des Betriebskonzepts ermittelt und technische Konzepte bereitgestellt, um einer solchen Situation gewachsen zu sein. Abb. 7.14: Eskalationsvorgang bei Störung

Teil oder Totalausfall des DV-Verfahrens

Reparatur innerhalb von 1 Stunde

Information der ITAbteilung an die Anwenderabteilungen

nein

Information

ja Reparatur innerhalb von 2 Stunden

nein

Information und Entscheidung der Leitung der Anwenderabteilung

ja Inbetriebnahme des Havariesystems

Alle Dienste des DV-Verfahrens wieder funktionsfähig

Oft wird dem Anwender beim Durchspielen einer größeren Störung erst klar, was dies bedeutet, und es resultiert daraus des Öfteren eine Veränderung des DV-Verfahrens bezüglich des Systemdesigns und seiner Verfügbarkeit.

262

■ ■ ■


7.2.5 Havarie- und Backupkonzept Wesentlicher Bestandteil des Betriebskonzeptes ist ein Havarie- und Backupkonzept, in dem die Maßnahmen und Selbstheilungskräfte eines DV-Verfahrens beschrieben sind. Angefangen bei Anweisungen, wie Standbysysteme in Betrieb genommen werden, bis zum Relozieren von Clusterdiensten sollte hier detailliert aufgeschlüsselt werden, wer was wann durchführen muss. Wesentliche Telefonnummern und Ansprechpartner sind ebenso von existenzieller Bedeutung wie Hintergrundinformationen über abgeschlossene Wartungsverträge. Im Havarie- und Backupkonzept ist ein Datensicherungsplan enthalten. Aus diesem geht hervor, welche Serversysteme und Datenbanken wann und in welchem Turnus gesichert werden. Rechner Typ Backup-Laufwerk Server 1 Server 2 Server 3

Datenbank 1

Datenbank 2

Kapazität Backupdes Back- Turnus up-Laufwerks

Digital TZ88 20/40 GB DLT SUN DLT 35/70 GB 40/80 GB

Beschreibung, was gesichert wird

Wochenturnus Wochenturnus Wochenturnus

Alle Filesysteme werden gesichert Alle Filesysteme werden gesichert Nur die Filesysteme /root und /opt werden gesichert Da der Datenbankrechner als zentrales Element des DV-Verfahrens 1 die Verfügbarkeit in hohem Maße beeinflusst, ist hier auch die Notwendigkeit eines häufigen Backupturnus gegeben. Gesichert werden müssen hier neben den Inhalten der Datenbank auch das Betriebssystem und die Datenbank-Binarys. Weiterhin werden die Archivlog-Dateien der Datenbank noch auf den Server 2 kopiert. Die Adress-Datenbank wird nur in größeren Abständen verändert

ADIC DS9800D DLT DLT 8000

40/80 GB

täglich

DLT 8000

40/80 GB

Wochenturnus

7.2 Betriebskonzept

Tabelle 7.2: Datensicherungsplan des DV-Verfahrens 1

■ ■ ■

263

Auch die Angabe, in welchem Datensafe und in welchem Turnus Datensicherungen an einen zweiten Standort ausgelagert werden sollen, um z. B. größere Brandkatastrophen oder andere Desaster zu überstehen, sind Informationsbestandteile des Datensicherungsplanes. Beim Einführen eines neuen DV-Verfahrens sollte ein Havariekonzept erstellt werden, damit die Auswirkungen von potentiellen Bedrohungen abgemildert werden können. Abb. 7.15: Externe Bedrohungen eines DV-Verfahrens Erdbeben

Explosion

Sturm

Datenbank

Datenbankserver

Arbeitsplatsclient

Blitzeinwirkung Brand Festplattenarray Datenbankserver

Überschwemmung

Das Havariekonzept sollte folgende Punkte enthalten: x Notablaufplan, Beschreibung von Kommunikationsmitteln bzw. -wegen sowie Liste von Mitarbeitern (in- und extern), die benachrichtigt werden müssen. (Wer ist wann wie zu benachrichtigen?) x Contigency- sowie Desaster-Recovery-Plan aufstellen (Maßnahmen zur Risikoreduzierung und Wiederherstellung, auch Alternativpläne) x Krisenmanagement-Team zusammenstellen x Erstellung eines Datensicherungs- und Backup-Konzeptes (Datensicherung und Wiederherstellung) x Erstellung von Wiederanlaufplänen sowie Plänen für das Aufholen des Produktionsrückstandes x Regelmäßige Tests und Training

264

■ ■ ■


x Weiterentwicklung und Anpassung des Havarie- bzw. DesasterRecovery-Plans. x Aufstellen eines Serviceplans und Festlegung von Havarieübungszeitpunkten Innerhalb des beschriebenen Krisenstabes sollten technische und organisatorische Schlüsselpersonen enthalten sein. Diese sollten in der Lage sein, relativ schnell technische bzw. organisatorische Hilfsmaßnahmen einzuleiten.

7.2.6 Wartungsverträge Auch Wartungsverträge mit ihren Ansprechpartnern, Laufzeiten und Kosten sind wichtige Informationen, die das Betriebskonzept in übersichtlicher Form präsentiert. Laufzeiten von Wartungsverträgen sind eine immer wieder diskutierte Angelegenheit, aus der nicht selten Engpässe beim Support entstehen. Wartungs Reaktiverträge onszeiten

Ansprechpartner

Schätzkosten

Bemerkung

Hardware

4 Stunden

0,00 EURO

Bis 2006 entstehen der Firma keine Kosten.

Betriebssystem

2 Stunden

Ca 10.000 Euro

Es besteht ein Wartungsvertrag, der bis 2005 gültig ist.

Applikationssoftware

4 Stunden

Tel: Fax: E-Mail: Service-URL: Login/Passwort Tel: Fax: E-Mail: Service-URL: Login/Passwort Tel: Fax: E-Mail: Service-URL: Login/Passwort

Datenbank 2 Stunden

Tel: Fax: E-Mail: Service-URL: Login/Passwort

Tabelle 7.3: Überblick über externe Wartungsvertragsbeziehungen

0,00 EURO

Die Applikationssoftware ist in der Gewährleistungsphase, ab dem Jahre 2005 ist ein Wartungsvertrag vorgesehen. Es besteht ein Ca 25.000 EURO Wartungsvertrag, der bis 2005 gültig ist.

7.2 Betriebskonzept

■ ■ ■

265

7.2.7 Kennparameter bzw. Schwachstellenanalyse eines neuen DV-Verfahrens Des Öfteren scheitern Projekte daran, dass am Anfang eines Projektes zu viele Anforderungen gestellt werden, deren Realisierung zuviele Ressourcen verbraucht, die dann am Ende fehlen. Übrig bleibt, nachdem die Gelder aufgebraucht sind, ein DV-Verfahren, das instabil ist und viele Fehler aufweist. Deswegen sollte die erste Version des Betriebskonzepts noch eine Schwachstellenanalyse (Tabelle 7.4) des Ist-Zustandes umfassen, anhand derer die Geschäftsführung einer Firma erkennen kann, welche grundsätzlichen Schwachstellen noch existieren, bevor dieses DV-Verfahren produktiv eingesetzt werden kann. Dies hat sich oft als vorteilhaft erwiesen, da das Betriebskonzept meist von den IT-Serviceabteilungen bzw. von einem Außenstehenden geschrieben wird, der von den internen Belangen der Planungsabteilungen, die das neue DV-Verfahren geplant haben, nicht berührt wird. Abb. 7.16: Die Schwachstellenanalyse ist Grundlage der weiteren Strategie

Die ermittelten Kennparameter werden der Übersicht wegen innerhalb einer Matrix niedergeschrieben, so dass das höhere Management bzw. die Geschäftsführung einen schnellen Überblick über den Stand der Integration des neuen DV-Verfahrens in die ITOrganisation der Firma erhält. Beispielmatrix Kennparameter eines DV-Verfahrens einer fiktiven Firma vor Einführung eines neuen DV-Verfahrens:

266

■ ■ ■


Kenndaten

Abdeckung

Abteilungen

Bemerkung

Service7 Tage, 24 Std. abdeckung nach (bei

PRINCE 2: Das Projektmanagement-Framework GERMAN

Java 2 - Das Buch German

The Leopard Prince (Prince 2)

The Leopard Prince (Prince 2)

Das praktische Pendelbuch GERMAN

Das Genom GERMAN

Das erste Zeitalter GERMAN

Das J2EE Codebook GERMAN

Das Treibhaus (German Edition)

German Zdv314 Das Machinengewehr

Das Einsame Herz GERMAN

Das vergessene Volk (Das schwarze Auge) GERMAN

Clockwork Prince (Infernal Devices #2)

1 2 Prince vol. 1

Java 2 Kompendium GERMAN

Satellitenkommunikation, 2.Auflage GERMAN

Das Schwarze Auge Roman 55. Blutrosen. Aranische Nächte, 2. - GERMAN

ITIL: Das IT-Servicemanagement Framework, 2.Auflage GERMAN

Das Ende (2 of 2)

Das Ende (2 of 2)

PostgreSQL. Das offizielle Handbuch GERMAN

Das Access 2003-Entwicklerbuch German

Das Erziehungssystem der Gesellschaft german

Dionysos und das Dionysische German

Das Recht der Gesellschaft german

Energieausweis - Das große Kompendium GERMAN

Wirtschaft - das Fureinander-Leisten German

Das AutoCAD 3D Praxisbuch GERMAN

Das Auftragsrisiko im Griff GERMAN

Das Java 6 Codebook GERMAN

MySQL - Das offizielle Handbuch GERMAN

PRINCE 2: Das Projektmanagement-Framework GERMAN

Java 2 - Das Buch German

The Leopard Prince (Prince 2)

The Leopard Prince (Prince 2)

Das praktische Pendelbuch GERMAN

Das Genom GERMAN

Das erste Zeitalter GERMAN

Das J2EE Codebook GERMAN

Das Treibhaus (German Edition)

German Zdv314 Das Machinengewehr

Das Einsame Herz GERMAN

Das vergessene Volk (Das schwarze Auge) GERMAN

Clockwork Prince (Infernal Devices #2)

1 2 Prince vol. 1

Java 2 Kompendium GERMAN

Satellitenkommunikation, 2.Auflage GERMAN

Das Schwarze Auge Roman 55. Blutrosen. Aranische Nächte, 2. - GERMAN

ITIL: Das IT-Servicemanagement Framework, 2.Auflage GERMAN

Das Ende (2 of 2)

Das Ende (2 of 2)

PostgreSQL. Das offizielle Handbuch GERMAN

Das Access 2003-Entwicklerbuch German

Das Erziehungssystem der Gesellschaft german

Dionysos und das Dionysische German

Das Recht der Gesellschaft german

Energieausweis - Das große Kompendium GERMAN

Wirtschaft - das Fureinander-Leisten German

Das AutoCAD 3D Praxisbuch GERMAN

Das Auftragsrisiko im Griff GERMAN

Das Java 6 Codebook GERMAN

MySQL - Das offizielle Handbuch GERMAN

Recommend Documents