22 l projekt MA N A G E M E N T aktuell 1/ 2009 16 WISSEN 1 Einleitung Die Unterstützung von Geschäftsprozessen durch Anwendungen muss zugleich gezielt und flexibel gestaltet werden. Zu den Zielen der IT-Unterstützung gehören Verbesserungen der Produktivität der Benutzer und der Effizienz der Ressourcennutzung. Dabei muss die IT-Unterstützung der Geschäftsprozesse flexibel sein, um auf geänderte Kundenanforderungen oder Marktsituationen schnell durch Anpassungen der Geschäftsprozesse reagieren zu können. Zur Verfolgung dieser Ziele hat die Entwicklung und Inbetriebnahme geeigneter Anwendungen effektiv, methodisch und zügig zu erfolgen, um die Qualität der IT-Unterstützung zu sichern und um Anwendungen zeitnah geänderten Geschäftsprozessen anzupassen. Jedoch liegen zum Zeitpunkt der Inbetriebnahme neuer Anwendungen häufig folgende Probleme vor: ❑ Projekte der Anwendungsentwicklung liefern Ergebnisse verspätet ab, sodass Zeitdruck herrscht, um ursprüngliche Zeitplanungen noch einzuhalten. ❑ Anwendungen erfüllen die an sie gestellten Anforderungen nicht vollständig. ❑ Die Inbetriebnahme von Anwendungen bedeutet schwerwiegende Eingriffe in die Routinen des IT- Betriebs und gefährdet deren Stabilität und Zuverlässigkeit. Die Inbetriebnahme neuer Anwendungen stellt insbesondere eine Herausforderung dar, weil die Anwendungen in die technischen Umgebungen einzupassen sind, in denen sie betrieben werden sollen. Wenn die dafür notwendigen Abstimmungen zwischen Entwicklungs- und Betriebsverantwortlichen nicht oder nicht vollständig gelingen, wird zusätzlicher Arbeits- und Zeitaufwand notwendig, um die Betriebsbereitschaft der Anwendungen herzustellen. Daher sollten alle Anforderungen, die aus Sicht des IT-Betriebs an Anwendungen zu stellen sind, möglichst während des Entwicklungsprojekts vollständig identifiziert und umgesetzt werden, um Zusatzaufwand bei der Inbetriebnahme der Anwendungen zu vermeiden [1, 2]. Unterschiedliche Organisationsgrundsätze erschweren jedoch die Abstimmung zwischen Verantwortlichen für Entwicklungsprojekte und IT-Betrieb. Die Entwicklung von Anwendungen wird traditionell in Projektform organisiert, um Synergien aus interdisziplinärer Zusammenarbeit und Spezialisierungseffekte zu nutzen. Dagegen ist der laufende IT-Betrieb von Anwendungen auf Routine ausgelegt, um eine dauerhafte, stabile und zuverlässige Unterstützung der Geschäftsprozesse zu gewährleisten. Dabei stehen aktuell unter dem Begriff „IT-Service- Management“ (ITSM) alle Aktivitäten der Planung, Steuerung und Kontrolle im IT-Betrieb auf dem Prüfstand, um IT-Abteilungen kundenorientiert auszurichten und deren Effektivität, Effizienz und Transparenz zu steigern. Als De-facto-Standard dafür gilt das Ausrichten der betrieblichen Organisation nach der Information Technology Infrastructure Library (ITIL). ITIL wird als Georg Disterer und Matthias Rose Prototyp zur Koordination von Anwendungsentwicklung und IT-Betrieb Die Anwendungsentwicklung und der IT-Betrieb sind organisatorische Bereiche, die inhaltlich primär über nicht funktionale Anforderungen verknüpft werden. In diesen Anforderungen wird formuliert, welche technischen Randbedingungen und Beschränkungen in Projekten zur Anwendungsentwicklung einzuhalten sind, um die reibungslose Inbetriebnahme der Anwendungen sowie deren stabilen und effizienten Betrieb zu sichern. Allerdings sind nicht funktionale Anforderungen häufig vage und missverständlich formuliert. In der Folge treten bei Inbetriebnahme und Betrieb neuer Anwendungen Probleme auf. Daher sollte die Koordination zwischen Projekten der Anwendungsentwicklung und dem Betrieb verstärkt werden. Dafür werden ITIL(= Information Technology Infrastructure Library)-konforme Prozesse basierend auf Quality Gates vorgeschlagen und ein Prototyp zur Steuerung und Kontrolle der Koordination vorgestellt. Die Autoren befassen sich mit nicht funktionalen Anforderungen, die in der Praxis oft vage und missverständlich formuliert sind. Damit sind zum Beispiel Ziele wie Zuverlässigkeit, Korrektheit oder Stabilität eines Systems gemeint. Um nach der Entwicklung einen reibungslosen und stabilen Betrieb zu gewährleisten, plädieren Disterer und Rose für eine stärkere Koordination zwischen der Anwendungsentwicklung und dem Systembetrieb und schlagen ITIL (= Information Technology Infrastructure Library)-konforme Prozesse basierend auf Quality Gates (Meilensteine, zu denen anhand von vorher festgelegten Kriterien Ergebnisse geprüft werden) vor. ITIL ist ein De-facto-Standard im Bereich Service Management und beinhaltet eine umfassende und öffentlich verfügbare fachliche Dokumentation zur Planung, Erbringung und Unterstützung von IT-Serviceleistungen. Außerdem stellen sie einen Prototyp zur Steuerung und Kontrolle der Koordination vor +++ Für eilige Leser +++ Für eilige Leser +++ Für eilige Leser +++ PM_1-09_1-64: Inhalt 19.12.2008 13: 36 Uhr Seite 16 Referenz- oder Rahmenwerk angesehen, nach dem Abläufe im IT-Betrieb prozessorientiert und zielgerichtet auszurichten sind. Die organisatorische Trennung zwischen Entwicklungsprojekten und IT-Betrieb und der Einsatz unterschiedlicher Organisationsgrundsätze geschehen gezielt, um durch vertikale Arbeitsteilung erhebliche Nutzenpotenziale zu erschließen und auf unterschiedliche Rahmenbedingungen von Entwicklungsprojekten und IT-Betrieb zu reagieren. Allerdings entstehen durch die Trennung auch sogenannte „funktionale Silos“ [3, S. 12], sodass bei Inbetriebnahme von Anwendungen zwei Organisationen mit unterschiedlichen Grundsätzen und Zielen aufeinanderstoßen: Eine in Projektform organisierte Anwendungsentwicklung und der in einer Routineorganisation etablierte IT-Betrieb. An der Schnittstelle zwischen Anwendungsentwicklung und IT-Betrieb treffen somit unterschiedliche Organisationsdogmen und verschiedene Vorgehensmodelle aufeinander, die inhaltlich abgestimmt und zeitlich zu synchronisieren sind [4, S. 13]. So sollten aus Sicht der Anwendungsentwicklung neu entwickelte oder geänderte Anwendungen möglichst zügig in Betrieb genommen werden, um Termine einzuhalten und den betrieblichen Nutzen der Anwendung früh auszulösen. Für den IT-Betrieb haben Sicherheit, Stabilität und Kontinuität des laufenden Betriebs höchste Priorität. Spätestens bei der Inbetriebnahme von Anwendungen müssen die Unterschiede zwischen den Bereichen überwunden und die Anwendungen friktionsfrei in Betrieb genommen werden. Vorgeschlagen wird daher eine Systematisierung nicht funktionaler Anforderungen durch die Erstellung eines entsprechenden Katalogs sowie eine dezidierte Koordination zwischen Entwicklungsprojekten und IT-Betrieb. Die Steuerung und Kontrolle der Zusammenarbeit sollte mit Quality Gates erfolgen. Vorgestellt werden ITIL-konforme Prozesse für beide Ansätze sowie ein Prototyp zur Steuerung und Kontrolle der Koordination. 2 Anforderungen an Anwendungen In der Anwendungsentwicklung ist der Begriff „Anforderung“ gemäß der Fachterminologie der IEEE wie folgt definiert: Eine Anforderung ist eine Bedingung oder eine Fähigkeit, die ein Benutzer benötigt, um ein Problem zu lösen oder um ein Ziel zu erreichen. Anforderungen sind danach Bedingungen oder Fähigkeiten, die ein System erfüllen muss, um eine Spezifikation, einen Kontrakt oder einen Standard zu erfüllen [5, S. 62]. Die Ermittlung und Verfolgung von Anforderungen sind in der Anwendungsentwicklung dem Anforderungsmanagement (Requirements Management) zugeordnet. Das Anforderungsmanagement beinhaltet „alle Prozesse, die zur Erhebung, Strukturierung und Verwaltung von Anforderungen notwendig sind“ [6, S. 17]. Anforderungen sind grundsätzlich in funktionale und nicht funktionale Anforderungen zu differenzieren (Abb. 1). Funktionale Anforderungen beschreiben die funktionalen Aspekte von Anwendungen im Sinne von „… was sollen die Anwendungen können“ und sind direkt vom angestrebten Nutzen und vom Einsatzzweck der Anwendungen abhängig. In der Regel werden diese Anforderungen von den Fachabteilungen bzw. Benutzern der Anwendung benannt, damit Anwendungen die Geschäftsprozesse in den Fachabteilungen unterstützen. Anforderungen beschreiben hinsichtlich der Geschäftsprozesse die Erfassung, Aufbereitung, Verarbeitung, Speicherung und Weitergabe von Informationen. Die Sicherstellung und Überprüfung der Erfüllung funktionaler Anforderungen erfolgen unter Beteiligung der Fachabteilungen und Benutzer. Dabei werden Vorgehensweisen wie Benutzerbeteiligung, Einsatz von Prototypen sowie systematische Abnahmetests eingesetzt. Nicht funktionale Anforderungen legen technische und methodische Bedingungen von Anwendungen fest, damit diese später im Betrieb störungsfrei, stabil und wirtschaftlich betrieben werden können. Sie beschreiben projekt MA N A G E M E N T aktuell 1/ 2009 l 17 Abb. 1: Funktionale und nicht funktionale Anforderungen PM_1-09_1-64: Inhalt 19.12.2008 13: 36 Uhr Seite 17 somit, wie Anwendungen die funktionalen Anforderungen erfüllen sollen. Nicht funktionale Anforderungen werden daher auch als „Constraints“, „Qualitätsattribute“ oder „Management and Operational Requirements“ bezeichnet; darunter werden etwa Forderungen bezüglich der Wartbarkeit, der Stabilität und des Datenschutzes verstanden. Die Spezifikation und Überprüfung nicht funktionaler Anforderungen ist nicht einfach, da sie oftmals nur allgemein, eher unpräzise und vage beschrieben werden. Das Beispiel der Forderungen nach Wartbarkeit und Stabilität von Anwendungen zeigt, dass nicht funktionale Anforderungen teilweise nicht hinreichend spezifiziert werden können, da kaum geeignete Metriken bekannt sind. Folglich geschieht die Überprüfung eher subjektiv und damit verbleibt Raum für (Fehl-)Interpretationen der Anforderungen [6, S. 13; 7, S. 154-157]. Zudem ist die Zuständigkeit für nicht funktionale Anforderungen nicht immer offensichtlich. Daher wurden in der Vergangenheit nicht funktionale Anforderungen während der Entwicklung häufig übergangen und nicht hinreichend berücksichtigt, sodass sie erst bei der Inbetriebnahme stringent aufgegriffen werden konnten [6, S. 16 und S. 98]. Zwei Lösungsansätze werden die Überführung von Anwendungen aus Entwicklungsprojekten in den Betrieb verbessern: die systematische Verwaltung und Verfolgung nicht funktionaler Anforderungen, die in einem Katalog zu erfassen und zu pflegen sind, sowie die gesteuerte und kontrollierte Koordination zwischen Projekten der Anwendungsentwicklung und dem IT-Betrieb basierend auf Quality Gates. 3 Katalogisierung nicht funktionaler Anforderungen Für einen stabilen und wirtschaftlichen Betrieb von Anwendungen sind nicht funktionale Anforderungen kritisch. Bei der Überleitung einer Anwendung aus dem Entwicklungsprojekt in den Betrieb und bei der Inbetriebnahme treten Störungen auf, wenn nicht funktionale Anforderungen bei der Entwicklung nicht entsprechend berücksichtigt sind. Daher ist eine systematische Verwaltung und Verfolgung nicht funktionaler Anforderungen zu etablieren, um damit deren rechtzeitige und vollständige Berücksichtigung während der Entwicklung zu sichern [8, S. 103]. Die Prüfung, ob Anforderungen gemäß ihrer Spezifikation umgesetzt wurden, kann in der Regel nur durch jene Stakeholder erfolgen, die die Spezifikation der Anforderungen erstellt haben. Bei nicht funktionalen Anforderungen ist jedoch nicht immer offensichtlich, wer sie spezifizieren und überprüfen sollte. So werden zum Beispiel die Skalierbarkeit und Wartbarkeit einer Anwendung von vielfältigen Einflussgrößen aus verschiedenen Verantwortungsbereichen des IT-Betriebs bestimmt. Zudem stellen Funktionen im Unternehmen wie zum Beispiel Risikomanagement, Portfoliomanagement, Datenschutz, Revision und Personalvertretung nicht funktionale Anforderungen, um ihre Ansprüche an Anwendungen zu formulieren. Damit liegen für nicht funktionale Anforderungen „sehr heterogene[n] Interessengruppen mit divergierenden Partikularinteressen“ [8, S. 105] vor. Für die systematische Verwaltung nicht funktionaler Anforderungen wird der Prozess „Katalog nicht funktionaler Anforderungen erstellen/ pflegen/ anpassen“ (Abb. 2) vorgeschlagen, um mit diesem Katalog eine wichtige Eigenschaft nicht funktionaler Anforderungen zu nutzen: Sie beschreiben die Betriebsumgebung von Anwendungen und sind somit für verschiedene Entwicklungsprojekte wiederverwendbar. Der Prozess „Katalog nicht funktionaler Anforderungen erstellen/ pflegen/ anpassen“ ist in drei Teilprozesse untergliedert, die im Folgenden skizziert werden: „Katalog nicht funktionaler Anforderungen“ initial erstellen: Dafür sind alle nicht funktionalen Anforderungen eines Unternehmens oder einer Betriebsumgebung zu erheben und zu dokumentieren. Die Erhebung erfolgt durch eine Befragung aller relevanten Organisationseinheiten des Unternehmens (z. B. IT-Betrieb, Personalvertretung, Datenschutz). Die nicht funktionalen Anforderungen werden spezifiziert und den jeweilig Verantwortlichen (Stakeholder) aus den Organisationseinheiten zugeordnet, die dann auch für die Prüfungen auf Erfüllung der Forderungen zuständig sind. Ihnen obliegt es, Prüfpunkte sowie die benötigten Prüfunterlagen (Pläne, Entwürfe, Testergebnisse …) festzulegen. 22 l projekt MA N A G E M E N T aktuell 1/ 2009 18 WISSEN Abb. 2: Prozess „Katalog nicht funktionaler Anforderungen erstellen/ pflegen/ anpassen“ PM_1-09_1-64: Inhalt 19.12.2008 13: 36 Uhr Seite 18 „Katalog nicht funktionaler Anforderungen“ pflegen und verwalten: Jede Änderung an nicht funktionalen Anforderungen ist im Katalog zu dokumentieren. Die benannten Verantwortlichen sind für die Erfassung der Änderungen verantwortlich. Damit ist gewährleistet, dass den Entwicklungsprojekten alle Änderungen bekannt sind und dass entsprechende Maßnahmen eingeleitet werden können. So werden z. B. Änderungen an der Betriebsumgebung über den Katalog den Verantwortlichen für Entwicklungsprojekte zur Kenntnis gebracht. Daher ist dieser Teilprozess eng mit dem Change-Management-Prozess im IT-Betrieb zu koppeln, da nach ITIL alle Änderungen der Betriebsumgebung diesen Prozess durchlaufen müssen. „Katalog nicht funktionaler Anforderungen“ projektspezifisch anpassen: Zum Start jedes Entwicklungsprojekts erfolgt eine Abstimmung zwischen der Projektleitung und den Verantwortlichen für nicht funktionale Anforderungen. Dabei ist festzulegen, welche der Anforderungen für das jeweilige Projekt relevant sind. Somit wird von dem allgemeinen Katalog eine projektspezifische Liste nicht funktionaler Anforderungen abgeleitet. Mit dem Prozess „Katalog nicht funktionaler Anforderungen erstellen/ pflegen/ anpassen“ wird gewährleistet, dass nicht funktionale Anforderungen eines Unternehmens in einem Katalog dokumentiert und jeweiligen Verantwortlichen zugeordnet sind. Dieser Katalog wird beim Beginn einer Anwendungsentwicklung an die Projektspezifika angepasst und stellt die Grundlage sowohl für das Projekt zur Anwendungsentwicklung als auch für die vorbereitenden Arbeiten des Anwendungsbetriebs dar. Für die parallel laufenden Arbeiten der Entwicklung von Anwendungen und der Vorbereitung ihres Betriebs ist eine Koordination und Synchronisation vorzusehen. 4 Koordination von Entwicklung und Betrieb In den Vorgehensmodellen zur Anwendungsentwicklung und zum IT-Betrieb sollen Prüfungen und Abnahmen direkt vor der Inbetriebnahme durch verschiedene Beteiligte sicherstellen, dass Anwendungen im Entwicklungsprojekt anforderungsgemäß erstellt wurden. Diese Prüfungen auf Erfüllung nicht funktionaler Anforderungen sind nicht trivial und kritisch, denn später entdeckte Abweichungen oder Fehler führen zu Nacharbeiten, die unter Zeitdruck durchzuführen sind, um vereinbarte Termine zur Inbetriebnahme zu halten. Beispielsweise können Systemkomponenten (Version des Datenbankreleases oder der Java-Umgebung) des Entwicklungsergebnisses nicht (mehr) zu den Komponenten des Betriebs passen, wenn während der Entwicklung Änderungen auf einer der beiden Seiten vorgenommen, aber nicht kommuniziert wurden. 4.1 Notwendigkeit der Koordination Nicht funktionale Anforderungen sind den Entwicklungsprojekten frühzeitig zu übermitteln, um eine störungsfreie Inbetriebnahme von Anwendungen zu gewährleisten. Frühzeitig bedeutet hier, dass Anforderungen und deren Änderungen zeitlich so an Projekte heranzutragen sind, dass sie mit möglichst geringem Aufwand zu erfüllen sind. Daher bedarf es frühzeitiger Signale, wenn Anforderungen aufgestellt oder geändert werden oder wenn erkennbar wird, dass Anforderungen in der Entwicklung nicht (vollständig) berücksichtigt werden. Die systematische Verwaltung nicht funktionaler Anforderungen (Abschnitt 3) ist also zu ergänzen um eine Verfolgung der Anforderung während der Laufzeit von Entwicklungsprojekten. In einschlägigen Referenzmodellen wird nur wenig Vorsorge getragen, dass frühzeitige Signale als Bestätigung einer anforderungskonformen Anwendungsentwicklung erzeugt werden. So wird nach dem Microsoft Operation Framework (MOF) ein „Release Readiness Review“ direkt vor Inbetriebnahme einer Anwendung durchgeführt. Erst zu diesem Zeitpunkt wird die Einhaltung nicht funktionaler Anforderungen überprüft. Gerade in komplexen und heterogenen Betriebsumgebungen besteht damit die Gefahr, dass erst dann Abweichungen oder Mängel bezüglich nicht funktionaler Anforderungen aufgedeckt und mit hohem Aufwand und unter Zeitdruck zu beheben sind. CMMI legt mit den Entwicklungsprozessen „Anforderungsentwicklung“, „Technische Umsetzung“, „Produktintegration“, „Verifikation“ und „Validation“ fest, dass Anforderungen mit Stakeholdern aufgenommen, spezifiziert und kontrolliert werden sollen. Auch wenn die Prozesse iterativ durchlaufen und „Verifikation“ und „Validation“ parallel zu den anderen Prozessen ausgeführt werden sollen, bleibt offen, wie eine frühzeitige Prüfung der Anforderungserfüllung und eine Koordination und Synchronisation zwischen den Prozessen der Entwicklung und des IT-Betriebs erfolgen soll. Auch ITIL (Version 2) lässt weitgehend offen, wie nicht funktionale Anforderungen rechtzeitig, vollständig und präzise an Entwicklungsprojekte herangetragen werden sollen und wie deren Berücksichtigung zu kontrollieren ist. Dies wird u. a. in der Zuordnung der Phasen im ITIL Application Lifecycle deutlich: Die Phasen „Requirements“, „Design“ und „Build“ werden der Anwendungsentwicklung und die Phasen „Deploy“, „Operate“ und „Optimize“ dem IT-Betrieb PM_1-09_1-64: Inhalt 19.12.2008 13: 36 Uhr Seite 19 zugeordnet. Zur konkreten Ausgestaltung der Schnittstelle zwischen Entwicklung (Aktivität „Build“) und Betrieb (Aktivität „Deploy“) werden keine konkreten Hinweise gegeben, die Überleitung von Anwendungen wird lediglich dem Verantwortungsbereich des Service Managements zugeschrieben. Im Release Management werden die für die Inbetriebnahme notwendigen Anforderungen formuliert, die während der Entwicklung zu berücksichtigen sind. In ITIL-Version 3 ist die Bedeutung und Schwierigkeit einer störungsfreien Übernahme von Anwendungen aus der Entwicklung in den IT-Betrieb erkannt und explizit als Phase „Transition“ im Lebenszyklusmodell aufgegriffen worden. Damit wird die Notwendigkeit einer systematischen und verlässlichen Überleitung von Anwendungen aus der Entwicklung (Design) in den Betrieb (Operation) betont. Als Ziel für die Phase Transition ist die Planung und Durchführung aller Tätigkeiten festgelegt, die notwendig sind, um ein Release zusammenzustellen, zu testen und zu implementieren, sodass die Anforderungen aller Stakeholder erfüllt werden. Dafür sind die Prozesse „Transition Planning and Support“, „Testing and Validation“, „Release and Deployment Management” und „Evaluation“ vorgesehen (Abb. 3). Projekte der Anwendungsentwicklung und des IT-Betriebs werden im Wesentlichen über zwei Dokumente verknüpft. Das Service Design Package (SDP) enthält die Beschreibungen aller notwendigen Komponenten eines Systems, Service Acceptance Criteria (SAC) stellt mit den Akzeptanzkriterien die Verbindung zu den funktionalen und nicht funktionalen Anforderungen dar. Die Einhaltung der Akzeptanzkriterien aus dem SAC wird zu den Evaluierungspunkten E1, E2 und E3 überprüft (Abb. 3). Vor allem mit den Evaluierungspunkten E1 und E2 werden die umfassenden Prüfprozesse bei der Überführung einer Anwendung entzerrt. Dennoch sind Prüfungen zum Zeitpunkt E2 kritisch, da bei negativem Ausgang die Termine der Inbetriebnahme unmittelbar gefährdet werden. Gerade bei umfangreichen Projekten und in komplexen und heterogenen Betriebsumgebungen ist eine einmalige und retrospektive Prüfung nicht funktionaler Anforderungen kaum ausreichend. Vielmehr ist anzustreben, dass zwischen Verantwortlichen der Entwicklungsprojekte und des IT-Betriebs frühzeitige Abstimmungen zu den nicht funktionalen Anforderungen stattfinden, um frühe Signale zu Abweichungen oder Mängeln aufzudecken. Dabei nehmen Verantwortliche des IT- Betriebs eine prospektive Bewertung der Entwicklungsergebnisse vor und stehen somit auch in der Mitverantwortung für den Projekterfolg. Ein derartiges Vorgehen entspricht der Forderung nach der Einbeziehung („Involvement“) des IT-Betriebs und anderer Stakeholder in den Entwicklungsprozess, die in den ITIL-Unterlagen zur Phase „Service Operation“ oft und deutlich ausgesprochen, jedoch in den entsprechenden Unterlagen kaum aufgegriffen wird. Zudem wird der Kreis jener Stakeholder, für die von ITIL „involvement … at the earliest possible stage“ [10, S. 29-30] gefordert wird, erweitert um Verantwortliche des IT-Betriebs. Diese frühzeitigen Abstimmungen sind organisatorisch zu steuern, damit die Arbeiten von Anwendungsentwicklung und IT-Betrieb koordiniert und synchronisiert werden. 22 l projekt MA N A G E M E N T aktuell 1/ 2009 20 WISSEN Abb. 3: Phase „Transition“ zwischen Entwicklung und Betrieb in ITIL V3 [9, S. 31] PM_1-09_1-64: Inhalt 19.12.2008 13: 36 Uhr Seite 20 4.2 Quality Gates in IT-Projekten In der Betriebswirtschaftslehre sind Quality Gates für Entwicklungs- und Innovationsprojekte seit Längerem bekannt und etabliert. Der Einsatz von Quality Gates basiert auf der Annahme, dass eine hohe Qualität des zu entwickelnden Produkts nur mit einer hohen Prozessqualität bei der Entwicklung zu erreichen ist. Daher wird zur Sicherung der Prozessqualität eine dezidierte Prozesslenkung eingesetzt, um die Abstimmung und Synchronisation verschiedener Disziplinen mit einem relativ strengen Ablaufmodell durchzusetzen. So sollen Fehler und Unklarheiten nach einer Strategie der „Prävention und Reaktion“ [11, S. 6] frühzeitig erkannt und behoben werden können. Die Ablaufregeln zur Zusammenarbeit und Abstimmung sollen sicherstellen, dass zu festgelegten Zeitpunkten der Stand der Entwicklung und die Erfolgschancen der Fortentwicklung von allen Beteiligten so klar und unmissverständlich wie möglich beurteilt werden. Die Frühzeitigkeit wird dabei angestrebt durch die Definition von Zeitpunkten im Verlauf der Entwicklung („Gates“), zu denen sich alle Beteiligten über den Zwischenstand abzustimmen haben. Die Klarheit und Unmissverständlichkeit der Abstimmung wird angestrebt, indem alle Beteiligten ausdrücklich einer Fortsetzung der Entwicklung zustimmen müssen, andernfalls wird die Entwicklung gestoppt (Abb. 4). Quality Gates sind damit „rigide Entscheidungspunkte“ [12, S. 1544], zu denen alle Beteiligten einer projekt MA N A G E M E N T aktuell 1/ 2009 l 21 Abb. 4: Ablaufprinzip von Quality Gates ! " # $ % & ' ( ) * $ % + , ' ( ' ( -. . . "/ 0 " " ' ( # ' ( $ ' 1 2 1 3 45 2 65789 : 89 88 ; 8<=6 6> 2 . ? : 89 88 ; 8<; 76 2 <@ A $ 2 """$ $ ! " Anzeige PM_1-09_1-64: Inhalt 19.12.2008 13: 36 Uhr Seite 21 Fortsetzung der Entwicklung ausdrücklich zustimmen bzw. widersprechen müssen. Dieser Druck zur positiven Stellungnahme oder ausdrücklichen Ablehnung soll Fehler und Unklarheiten frühzeitig und sicher aufdecken. Spätere Reklamationen mit Hinweisen wie „… hättet ihr uns doch früher gefragt …“ oder „ … wir wussten ja nicht, was ihr vorhabt …“ sollen ausgeschlossen werden. Quality Gates dienen somit als Synchronisationspunkte für nebenläufige, nicht unabhängige Prozesse. Die Kriterien, nach denen die Beteiligten Freigaben zur Fortsetzung der Entwicklung erteilen bzw. verweigern, werden zu Beginn eines Entwicklungsprojekts festgelegt. Diese frühe Offenlegung der Kriterien sichert, dass Entscheidungen zu Fortsetzung oder Abbruch von Projekten transparent, konsistent und nachvollziehbar getroffen werden. Die Kriterien zur Freigabeentscheidung werden dabei spezifisch für jedes Gate festgelegt, um eine möglichst feingranulare Prüfstruktur zu erhalten. Bei einer eingeschränkten Zustimmung zur Fortsetzung eines Entwicklungsprojekts können Vorbehalte verfolgt werden, indem sie als spezieller Prüfauftrag für das nächste Gate vorgesehen werden. Quality Gates können - müssen aber nicht - mit den Meilensteinen des Projektcontrollings übereinstimmen. 4.3 Prozess „Freigabe koordinieren“ mit Quality Gates Durch den Einsatz von Quality Gates in Projekten zur Anwendungsentwicklung stimmen sich Verantwortliche der Entwicklungsprojekte und Beteiligte aus dem IT- Betrieb rechtzeitig und regelmäßig zu nicht funktionalen Anforderungen ab. Mit dieser Ablaufsteuerung werden Fehlentwicklungen frühzeitig aufgedeckt, um noch ausreichend Zeit und Ressourcen zur Korrektur zu besitzen. Die Beteiligten erhalten eine definierte Rolle in den Projekten, indem sie zu den festgelegten Zeitpunkten der Quality Gates ausdrücklich eine Freigabe zur Fortsetzung der Entwicklung erteilen oder versagen müssen. Basierend auf dem Ablaufmodell Quality Gates ist ein Prozess zu etablieren, um Entscheidungs- und Eskalationsmechanismen zur Freigabeerteilung festzulegen. Zudem sind die Planung, Durchführung und Überwachung der Freigaben zu regeln sowie Gespräche zwischen Beteiligten bei Missverständnissen oder Abweichungen zu initiieren und zu begleiten. Dies erfolgt durch den Prozess „Freigabe koordinieren“, der dem „Katalog nicht funktionaler Anforderungen erfassen/ pflegen/ anpassen“ folgt (siehe Kapitel 3). Im Prozess „Freigabe koordinieren“ wird jedem Stakeholder die Rolle eines Statuslieferanten zugeteilt, der mit der Erteilung oder dem Versagen einer Freigabe zur Weiterentwicklung eine wichtige Statusinformation an das Projekt liefert. Mit dem Begriff „Statuslieferant“ wird betont, dass ein Stakeholder eine Freigabe zu liefern hat und somit in die Verantwortung für den Projekterfolg eingebunden ist. Weiterhin wird im Prozess „Freigabe koordinieren“ die Steuerung und Ausführung der Prozessaktivitäten der Rolle des Freigabekoordinators zugeordnet. Anhand der Liste nicht funktionaler Anforderungen und des Projektplanes legen Projektleitung und Freigabekoordinator gemeinsam die Termine für die Quality Gates fest, die dann allen Statuslieferanten mitgeteilt werden. Rechtzeitig zum jeweiligen Quality Gate übermitteln die Statuslieferanten ihre Prüfergebnisse in Form eines Freigabestatus, für den vier verschiedene Standardformen vorgesehen sind: ❑ Freigabeprüfung hat Bedenken ergeben: Der Statuslieferant meldet Bedenken an, dass der aktuelle Stand der Anwendungsentwicklung zu Störungen bei Inbetriebnahme oder im Betrieb führen kann. ❑ Freigabe: Der Stauslieferant hat keinerlei Beanstandungen, alle Anforderungen sind erfüllt. ❑ Freigabe mit Vorbehalt: Der Statuslieferant bringt Beanstandungen vor, die Entwicklung kann fortgesetzt werden, jedoch sind Auflagen zu beachten. ❑ Keine Freigabe: Der Statuslieferant sieht erhebliche Mängel, die zu Störungen bei Inbetriebnahme oder im Betrieb führen können. Im Falle der Meldungen „Keine Freigabe“ oder „Freigabeprüfung hat Bedenken ergeben“ sind Freigabemeetings zu koordinieren, um zu klären, ob (im günstigsten Fall) Missverständnisse in der Interpretation von Zwischenergebnissen der Anwendungsentwicklung vorliegen. Andernfalls ist zwischen dem Statuslieferanten und Verantwortlichen des Entwicklungsprojekts zu analysieren, ob die bestehenden Bedenken durch Nacharbeiten zu beheben sind. In diesem Fall kann eine „Freigabe mit Vorbehalt“ ausgesprochen werden und die Ergebnisse der Nacharbeiten sind als Auflagen für das folgende Quality Gate zu dokumentieren. Wenn weder Missverständnisse vorliegen noch eine Freigabe mit Vorbehalt notwendiger Nacharbeiten ausgesprochen werden 22 l projekt MA N A G E M E N T aktuell 1/ 2009 22 WISSEN Abb. 5: „Freigabe koordinieren“ PM_1-09_1-64: Inhalt 19.12.2008 13: 36 Uhr Seite 22 kann, gilt die Freigabe als nicht erteilt. Für diesen Fall sind Eskalationsmechanismen vorzusehen, etwa dass die Bereichs- oder Unternehmensleitung über Fortsetzung oder Abbruch des Entwicklungsprojekts zu entscheiden hat (Abb. 5). Der Teilprozess „Freigabe koordinieren“ ist so lange zu durchlaufen, bis das letzte zu einem Entwicklungsprojekt definierte Quality Gate erfolgreich absolviert ist. 5 Prototyp zur Koordination Zur Unterstützung des vorgestellten Koordinationsprozesses wurde ein Prototyp entwickelt, der folgende Aufgaben unterstützt: ❑ Abbildung und Durchsetzung des Ablaufprinzips von Quality Gates für Projekte, ❑ Verwaltung und Übersicht der Termine für die Quality Gates eines Projekts, ❑ Verwaltung und Übersicht der Anforderungen, die zum Zeitpunkt eines Quality Gates durch Statuslieferanten zu überprüfen sind, ❑ Verwaltung und Übersicht der Statuslieferanten, die Anforderungen zum Zeitpunkt eines Quality Gates überprüfen sollen und ggf. Freigaben aussprechen, ❑ Durchsetzung der Termine der Quality Gates gegenüber den Statuslieferanten, ❑ Übersicht über Termin- und Statussituation bzgl. der Quality Gates für mehrere Projekte (Multiprojektmanagement). Nach dem Ablaufprinzip werden die Projekte zu jeder der nicht funktionalen Anforderungen symbolisch an eine Ampel herangeführt, auf der die Stellungnahmen der projekt MA N A G E M E N T aktuell 1/ 2009 l 23 [Eskalation] Entscheidung durch Geschäftsführung „Rot“ „Rot“ [Freigabe [Freigabe verweigert] [Freigabe verweigert] [Abstimmung] [Eskalation] [mit Auflagen] [Projekt abgebrochen] Freigabemeeting zur Abstimmung „Rot/ Grün“ [Abstimmung] [Vorbehalt angemeldet] [Vorbehalt angemeldet] [ g verweigert] [mit Auflagen] Freigabemeeting zur Abstimmung zwischen Freigabekoordination, Statuslieferanten und Projektleitung „Blau“ „Weiß“ „Gelb“ [in Bearbeitung] [mit Auflagen] [Quality Gate mit Vorbehalt passiert, Auflagen sind zu füll ] Abstimmung: Zwischeninformationen einholen, Gespräch zw. Statuslieferanten und Projektleitung erfüllen] „Grün“ [Freigabe erteilt] [Freigabe erteilt] [Vorbehalt geklärt] [Vorbehalt geklärt] [Quality Gate erfolgreich passiert] p ] Status Bezeichnung Zustand Wer ist verantwortlich? „Weiß“ kein Status Ausgangszustand Freigabekoordination „Blau“ In Bearbeitung Zwischenzustand Statuslieferant „Rot/ Grün“ Vorbehalt/ Bedenken angemeldet Zwischenzustand Statuslieferant g „Rot“ keine Freigabe Endzustand Freigabekoordination „Gelb“ Freigabe mit Vorbehalt Endzustand Statuslieferant „Grün“ Freigabe Endzustand Statuslieferant Abb. 6: Zustandsdiagramm für Ampelsignale Statuslieferanten für Fortsetzung oder Abbruch der Entwicklung signalisiert werden. Die möglichen endgültigen Signalzustände der Ampel sind dabei „Grün“ (Freigabe für Fortsetzung), „Gelb“ (Freigabe für Fortsetzung mit Auflagen) und „Rot“ (keine Freigabe für Fortsetzung). Zulässige Zwischenzustände der Ampel sind „Blau“ (Freigabeprüfungen in Bearbeitung) und „Rot/ Grün“ (Freigabeprüfung mit ersten Vorbehalten/ Bedenken). Die sachlogisch möglichen Übergänge, Zwischenzustände und endgültigen Zustände der Signale sind im Zustandsdiagramm (Abb. 6) dargelegt. Ein Quality Gate kann nur erfolgreich durchschritten werden, wenn alle Statuslieferanten zu den Prüfungen des Gates die Freigaben (Farbe „Grün“) oder Freigaben mit Vorbehalt (Farbe „Gelb“) erteilt haben. Verweigert ein Statuslieferant die Freigabe (Farbe „Rot“), dann wird das Entwicklungsprojekt der Bereichs- oder Unternehmensleitung zur Entscheidung über den Abbruch der Entwicklung oder eine Freigabe mit Auflagen vorgelegt. Vor Aufnahme der Prüfungen zu einem Quality Gate liegt kein Status vor (Farbe „Weiß“). Ein Statuslieferant signalisiert, wenn er die Bearbeitung im Rahmen eines Quality Gates aufgenommen hat (Farbe „Blau“). Wenn Prüfungen Bedenken, Vorbehalte oder Ähnliches ergeben, dann signalisiert der Statuslieferant, dass er der Fortsetzung der Entwicklung nicht vorbehaltlos zustimmen kann (Farbe „Rot/ Grün“). Diese Statusmeldung löst eine Feinabstimmung zwischen Projektverantwortlichen und Statuslieferanten aus, die zu einem der drei endgültigen Ampelzustände (Grün/ Gelb/ Rot) führen muss. Der Prototyp unterstützt die Freigabekoordination bei der Steuerung und Kontrolle des Verfahrens. Die Frei- „Rot / Grün“ PM_1-09_1-64: Inhalt 19.12.2008 13: 36 Uhr Seite 23 gabekoordination beauftragt die Statuslieferanten mit Prüfungen und Freigabeentscheidungen rechtzeitig vor den Quality Gates, verfolgt die zeitgerechte Erteilung der Freigaben und wertet diese aus. Der Prototyp unterscheidet für Projekte, Quality Gates, Status, Statuslieferanten und Anforderungen drei Darstellungsebenen: ❑ Multiprojekt: für alle Projekte deren Quality Gates und aktuellen Freigabestatus; ❑ Einzelprojekt: für ein Projekt dessen Quality Gates und aktuellen Freigabestatus sowie die beteiligten Statuslieferanten; ❑ Einzelfreigabe: für eine Freigabe den zuständigen Statuslieferanten und dessen Anforderung sowie den aktuellen Freigabestatus. Ein Beispiel mit fiktiven Projekten in Abb. 7 zeigt die Statusübersicht für alle Projekte und dient vor allem dem Multiprojektmanagement. Die Projekte sind im Zeitverlauf in Zeilen dargestellt, für die Projekte sind die jeweils festgelegten Quality Gates und deren aktueller Status durch Ampelsignale ausgewiesen. So hat das Projekt „Transition“ (Nr. 007) die ersten beiden Quality Gates erfolgreich passiert, zu dem anstehenden dritten Quality Gate liegt noch kein Status vor. Ebenso hat das Projekt „Orpheus“ (Nr. 113) die ersten beiden Gates erfolgreich passiert, zu dem anstehenden dritten Gate haben die Statuslieferanten mit der Aufnahme der Freigabeprüfungen begonnen. Für das Projekt „Mosaik“ (Nr. 277) hat (mindestens) ein Statuslieferant zum Zeitpunkt des zweiten Gates einer Fortsetzung nicht zugestimmt. Daraufhin hat die Bereichs- oder Unternehmensleitung entschieden, das Projekt abzubrechen und ein Folgeprojekt mit geänderten Aufgabenstellungen und Rahmenbedingungen zu beauftragen. Im Projekt „FL/ TS“ (Nr. 112) sind die ersten Gates erfolgreich durchschritten, zu dem anstehenden vierten Gate liegt noch kein Status vor. Die Situation zum Projekt „K4“ (Nr. 876) wird im Folgenden detailliert dargestellt. Ausweislich der Übersicht zu allen Projekten (Abb. 7) sind zu diesem Projekt die ersten Gates erfolgreich durchschritten und zum nunmehr anstehenden vierten Gate hat (mindestens) ein Statuslieferant Vorbehalte/ Bedenken zur Fortsetzung geäußert. In Abb. 8 ist die Übersicht zum Projekt „K4“ wiedergegeben. In der Zeile „Gesamtstatus“ sind die vorliegenden Freigabeentscheidungen aller Statuslieferanten zu einem Ampelsignal aggregiert. Dieses Signal entspricht der Darstellung zu diesem Projekt in der Übersicht zu allen Projekten. Für den Gesamtstatus für ein Quality Gate wird nur „Freigabe“ signalisiert („Grün“), wenn die Meldungen aller Statuslieferanten „Freigabe“ signalisieren. Wenn nur ein Statuslieferant keine Freigabe ausspricht, bestimmt sein Signal den Gesamtstatus. In der Projektübersicht sind die zuständigen Statuslieferanten und deren Meldungen im Zeitverlauf des Projekts zeilenweise dargestellt. Da nicht alle Statuslieferanten zu jedem Gate eine Freigabe zu erteilen haben, sind manche Felder leer, um zu signalisieren, dass nach den Festlegungen bei Projektbeginn zu diesem Gate von diesem Statuslieferanten keine Freigabe zu liefern ist. Im Beispiel von Projekt K4 hat der Statuslieferant für den Bereich „Netzwerk“ (Nr. S. 551) am vierten Gate Bedenken zu seinem Bereich der nicht funktionalen Anforderungen angemeldet („Rot/ Grün“). Daher wird eine Feinabstimmung in Form eines Freigabemeetings zwischen den Projektverantwortlichen und dem Statuslieferanten notwendig, um eine Entscheidung zur Freigabe herbeizuführen. Details zu den Vorbehalten des Statuslieferanten werden im sogenannten Status- oder Freigabeticket (Abb. 9) deutlich, das einen Arbeitsauftrag eines Statuslieferanten darstellt. Für jeden Statuslieferanten und jedes Gate, zu dem er Freigabeentscheidungen zu treffen hat, werden derartige Tickets von der Freigabekoordination angelegt. Sie dienen der Benachrichtigung zur Fälligkeit der Freigabeentscheidungen und der Dokumentation der Entscheidung sowie deren Begründung. So ist mit dem Prototyp vorgesehen, dass die Freigabekoordination etwa zwei Wochen vor einem Quality Gate die Tickets als Arbeitsauftrag per E-Mail versendet und die Statuslieferanten nach ihren Prüfungen die Statustickets ausgefüllt an die Freigabekoordination zurücksenden. 22 l projekt MA N A G E M E N T aktuell 1/ 2009 24 WISSEN Abb. 8: Übersicht zum Projekt K4 Abb. 7: Statusübersicht über alle Projekte Vorbehalt / Bedenken Vorbehalt / Bedenken Vorbehalt / Bedenken PM_1-09_1-64: Inhalt 19.12.2008 13: 36 Uhr Seite 24 Im Beispielprojekt K4 wird von der Freigabekoordination ein Meeting arrangiert, in dem der Statuslieferant nach der Feinabstimmung mit Projektverantwortlichen seine Bedenken insoweit klären kann, dass er eine Freigabe mit Vorbehalt („Gelb“) ausspricht. Im Beispiel besteht der Vorbehalt darin, dass bis zum nächsten Gate eine Simulation der Netzwerkbelastung durchzuführen ist. Der Freigabestatus sowie der Vorbehalt werden im Freigabeticket dokumentiert (Abb. 10). Die Statusänderung im Projekt K4 wird im Prototyp automatisch an die Darstellungsebenen für das Einzel- und Multiprojektmanagement übergeben und die entsprechend aktualisierten Übersichten werden angezeigt (Abb. 11). 6 Zusammenfassung Die Inbetriebnahme neuer Anwendungen stellt einen gravierenden Eingriff in den IT-Betrieb dar, da damit Stabilität und Effizienz des Betriebs gefährdet werden. Nicht funktionale Anforderungen dienen der Formulierung der technischen Randbedingungen und Beschränkungen, die neue Anwendungen einhalten müssen. Sie sind allerdings häufig zu vage und missverständlich, als dass sie in Entwicklungsprojekten hinreichend berücksichtigt werden können. Daher treten bei der Inbetriebnahme und im späteren Betrieb neuer Anwendungen Störungen auf, deren Behebung zu Terminüberschreitungen und zu erhöhten Aufwendungen führt. Um dem entgegenzuwirken, sind die nebenläufigen Prozesse der Anwendungsentwicklung und des IT-Betriebs zu koordinieren und Synchronisationspunkte zu etablieren. Dazu werden das Ablaufprinzip von Quality Gates und darauf basierend ein Prozess sowie ein Prototyp zur Koordination vorgeschlagen. Mit dem Prozess „Freigabe koordinieren“ werden von allen Beteiligten Entscheidungen zur Fortführung eines Projekts zur Anwendungsentwicklung an den Quality Gates stringent eingefordert. Dabei wird von den Statuslieferanten eine prospektive Beurteilung von (Zwischen-) Ergebnissen der Entwicklung erstellt und geprüft, ob ein stabiler und effizienter Betrieb einer Anwendung erreichbar ist. So werden Vertreter des IT-Betriebs als Statuslieferanten in die Verantwortung für den Projekterfolg eingebunden. projekt MA N A G E M E N T aktuell 1/ 2009 l 25 Abb. 9: Freigabeticket mit Vorbehalt/ Bedenken Abb. 10: Freigabeticket für Freigabe mit Vorbehalt Anzeige Vorbehalt / Bedenken Vorbehalt / Bedenken PM_1-09_1-64: Inhalt 19.12.2008 13: 36 Uhr Seite 25 Im Gegenzug erhalten Entwicklungsprojekte frühzeitige Signale aller Statuslieferanten, damit Fehlentwicklungen rechtzeitig entgegengewirkt werden kann. Der vorgeschlagene Prozess stellt eine Ergänzung des Prozesses „Transition Planning and Support“ nach ITIL (V3) dar. Der Prototyp zur Koordination unterstützt bei der Aufnahme und Dokumentation nicht funktionaler Anforderungen und bei den Freigaben zur Fortführung von Entwicklungsprojekten. Mit dem Prototyp können Vorteile bei der Projektsteuerung erzielt werden, da die Ergebnisse von Freigaben und Beurteilungen bzw. Prüfungen visualisiert werden. Risiken in Entwicklungsprojekten sind für Management, Projektverantwortliche und Statuslieferanten frühzeitig erkennbar, sodass geeignete Gegenmaßnahmen ergriffen werden können. Alternative Umsetzungen der IT-Unterstützung der Freigabekoordination - etwa mit gängigen Ticketsystemen - sind möglich. ■ Literatur [1] Disterer, G./ Rose, M.: Die Überleitung von Neuentwicklungen in den Betrieb bleibt problematisch. In: Information Management & Consulting 4/ 2007, S. 86-88 [2] Disterer, G./ Rose, M.: Übergang aus Entwicklungsprojekten in den Betrieb. In: Höhn, R., Petrasch, R., Linssen, O. (Hrsg.): Vorgehensmodelle und der Product Life-Cycle - Projekt und Betrieb von IT-Lösungen. Proc. 15. Workshop der Fachgruppe WI-VM der Gesellschaft für Informatik GI. Shaker, Aachen 2008, S. 19-30 [3] Böhmann, T./ Krcmar, H.: Grundlagen und Entwicklungstrends im IT-Servicemanagement. In: Handbuch der modernen Datenverarbeitung HMD 237/ 2004, S. 7-21 [4] Greb, T./ Kneuper, R./ Stender, J.: CMMI und ITIL - Zusammenarbeit von Entwicklung und IT Service Management. In: IT Service Management 2/ 2006, S. 11-18 [5] IEEE Standard 610.12-1990. IEEE Standard Glossary of Software Engineering Terminology. New York, IEEE 1990 [6] Ebert, C.: Systematisches Requirements Management. DPunkt, Heidelberg 2005 [7] Sommerville, I.: Software Engineering. 8. Auflage, Pearson, München 2007 [8] Ebert, C.: Trends im Requirements Management. In: Handbuch der modernen Datenverarbeitung. HMD 248/ 2006, S. 92-106 [9] OGC Office of Government Commerce (Hrsg.): Service Design. TSO, London 2007 [10] OGC Office of Government Commerce (Hrsg.): Service Transition. TSO, London 2007 [11] Fauth, G./ Winkelbauer, W./ Pfeifer, T./ Prefi, Th.: Den Anlauf im Griff - Quality Gates in der Produktion sichern Markenqualität. In: Qualität und Zuverlässigkeit, 6/ 1999, S. 756-760 [12] Spath, D./ Scharer, M./ Landwehr, R./ Förster, H./ Schneider, W.: Tore öffnen - Quality-Gate-Konzept für den Produktentstehungsprozess. In: Qualität und Zuverlässigkeit, 12/ 2001, S. 1544-1549 Schlagwörter Anwendungsentwicklung, Entwicklungsprojekte, Koordination, Inbetriebnahme, IT-Betrieb, ITIL, nicht funktionale Anforderungen, Quality Gates Kompetenzelemente der NCB 3.0 4.1.2 Interessierte Parteien, 4.1.3 Projektanforderungen und Projektziele Autor Prof. Dr. Georg Disterer lehrt Wirtschaftsinformatik an der Fakultät für Wirtschaft und Informatik der Fachhochschule Hannover und arbeitet auf den Gebieten Informationsmanagement, Projektmanagement, Wissensmanagement. Autor Matthias Rose, Dipl.-Wirt.-Inf. (FH), ist wissenschaftlicher Mitarbeiter am Kompetenzzentrum Information Technology and Management (CC_ITM) der Fachhochschule Hannover. Anschrift der Autoren Fakultät für Wirtschaft und Informatik Fachhochschule Hannover Ricklinger Stadtweg 120 D-30459 Hannover E-Mail: georg.disterer@fh-hannover.de, matthias.rose@fh-hannover.de 22 l projekt MA N A G E M E N T aktuell 1/ 2009 26 WISSEN Abb. 11: Freigabe mit Vorbehalt in der Statusübersicht über alle Projekte Haftungsausschluss Die Inhalte dieser Zeitschrift werden von Verlag, Herausgeber und Autoren nach bestem Wissen und Gewissen erarbeitet und zusammengestellt. Eine rechtliche Gewähr für die Richtigkeit der einzelnen Angaben kann jedoch nicht übernommen werden. Gleiches gilt auch für die Websites, auf die verwiesen wird. Es wird betont, dass wir keinerlei Einfluss auf die Inhalte und Formulierungen dieser Seiten haben und auch keine Verantwortung für sie übernehmen. Grundsätzlich gelten die Wortlaute der Gesetzestexte und Richtlinien sowie die einschlägige Rechtsprechung. PM_1-09_1-64: Inhalt 19.12.2008 13: 36 Uhr Seite 26