Frameworks für das IT Management. Erste Auflage

Transkript

1 Frameworks für das IT Management Erste Auflage

2 22 PRINCE2 - PRojects IN Controlled Environments PRINCE2 (Akronym von PRojects IN Controlled Environments, zu deutsch etwa Projekte in kontrollierten Umgebungen ) ist eine Projektmanagement-Methode für jede Art von Projekten. Copyright-Inhaber: Office of Government Commerce (OGC), Großbritannien: Verbreitung: PRINCE2 ist der De-Facto-Best-Practice-Standard für Projektmanagement in Großbritannien und wird verbreitet in den Niederlanden und Australien genutzt. Ausgehend von diesen Zentren wurden bisher in großem Umfang in aktuell über fünfzig Ländern der Welt Prüfungen zur Methode abgenommen. Ursprung / Geschichte: PRINCE2 ist eine Weiterentwicklung einer IT-Projektmanagement-Methode aus dem Jahre 1975 namens PROMPT II (Project Organization, Management and Planning Techniques), die von einer Gruppe von ehemaligen IBM- Projektmanagern entwickelt wurde. Diese wurde von der CCTA (Central Computer and Telecommunications Agency, nun Teil des OGC) im Jahre 1979 übernommen wurden Ergänzungen vorgenommen und die Methode in PRINCE2 umbenannt. Die Methode wurde 1996 so überarbeitet, dass sie auf jede Art von Projekten anwendbar ist. Wann: Aktuell ist die neueste Version 2005 Mitglieder des Komitees: OGC, APM Group, ISEB, Vertreter akkreditierter Schulungsorganisationen, APM, Leitende Prüfer, Leitende Gutachter Zertifizierungsinstitutionen: Zwei Zertifikate werden für die Methode angeboten, Foundation und Practictioner. Über Personen haben allein in Großbritannien die Foundation-Prüfung und die Practictioner-Prüfung abgelegt. In der übrigen Welt haben über Personen die Prüfungen abgelegt. Anzahl zertifizierter 70+ Organisationen: Von Colin Bentley 22.1 Ursprung/Geschichte PRINCE2 ist eine Weiterentwicklung einer IT-Projektmanagement-Methode aus dem Jahre 1975 namens PROMPT II (Project Organization, Management and Planning Techniques), entwickelt von einer Gruppe ehemaliger IBM-Projektmanager. Sie wurde von der CCTA (Central Computer and Telecommunications Agency) im Jahre 1979 übernommen wurden

3 242 Frameworks für das IT Management Ergänzungen vorgenommen und die Methode in PRINCE2 umbenannt. Die Methode wurde im Jahre 1996 so überarbeitet, dass sie für jede Art von Projekten anwendbar ist. Sie ist Eigentum des OGC. Die meisten britischen Regierungsbehörden setzen sie als Standard-Methode für Projektmanagement ein und eine Reihe von öffentlichen und privaten Unternehmen fordern, dass ihre Projektmanager Inhaber der beiden PRINCE2-Zertifikate sind Wo wird PRINCE2 eingesetzt? Die Methode gehört dem britischen Office of Government Commerce, Teil des Schatzamts Ihrer Majestät. Sie beschäftigt sich intensiv mit den Aufgaben des Projektmanagers, der Teammanager und derjenigen Mitglieder des Senior Managements, die in die Entscheidungsprozesse des Projekts involviert sind. Es ist der De-Facto-Best-Practice-Standard für Projektmanagement in Großbritannien und darüber hinaus in den Niederlanden und in Australien weit verbreitet. Ausgehend von diesen Zentren wurden bis dato weltweit in über fünfzig Ländern Prüfungen zur Methode abgenommen. Kürzlich wurde ein Büro in China eröffnet, um dem wachsenden Interesse dort und in den übrigen Ländern des Fernen Ostens Rechnung zu tragen Beschreibung und Hauptgrafiken PRINCE2 ist eine skalierbare und flexible Projektmanagement-Methode, die für den Einsatz in Projekten jeder Art und Größe geeignet ist. Sie wurde aus den Erfahrungen professioneller Projektmanager abgeleitet und über Jahre des Einsatzes in verschiedensten Kontexten hinweg verfeinert. Es gibt zwei Grundprinzipien von PRINCE2, welche die Basis für das weitere Verständnis der Methode bilden: Ein Projekt sollte sich an seinem Business Case orientieren Ein Projekt sollte nicht gestartet werden, solange nicht ein solider Business Case für das Projekt vorliegt. Über den gesamten Lebenszyklus des Projekts sollte in regelmäßigen Intervallen eine Überprüfung dahingehend erfolgen, ob das Projekt noch verfolgt werden sollte; das Projekt sollte gestoppt werden, wenn seine Rechtfertigung nicht mehr existiert. PRINCE2 ist produktbasiert PRINCE2 fokussiert auf die Produkte (Dokumente), die im Rahmen des Projekts hervorgebracht werden, nicht auf die Aktivitäten, welche diese hervorbringen. Dies hat Einfluss auf seine Methode der Planung, viele seiner Steuerungsmaßnahmen und seinen Ansatz zur Qualitätssicherung. Ein Schlüsselansatz der Methode ist die strikte Unterscheidung des Managements der Entwicklungsprozesse von den Techniken, die im Entwicklungsprozess genutzt werden. Die Methode besteht aus acht Prozessen, acht Komponenten und drei Techniken, die im Folgenden diskutiert werden. Abbildung 20.1 zeigt, wie sich diese in die Gesamtsicht der PRINCE2- Methode einfügen. Abbildung 20.2 zeigt die Standard-Projektorganisation von PRINCE2. Diese sollte auf individuelle Projekte angepasst werden, wobei mehrere der Rollen, wo dies angemessen erscheint, kombiniert oder aufgeteilt werden können.

4 PRINCE2 - PRojects IN Controlled Environments 243 DP Lenken eines Projekts Organisation Qualität Risikomgt. Business Case Pläne SU Vorbereiten eines Projekts Business Case IP Initiieren eines Projekts Konfigurationsmanagement Steuerungsmittel Business Case Risikomgt Steuerungsmittel Änderungssteuerung Konfigurationsmanagement Steuerungsmittel Mgnt. of Risk Qualität Business Case CS Steuern einer Phase Änderungssteuerungsansatz Qualitätsprüfung Qualitätsprüfung MP Managen der Produktlieferung Änderungssteuerungsansatz Pläne Business Case Mgnt. of Risk Organization Steuerungsmittel Pläne Steuerungsmittel Risikomgt Steuerungsmittel Qualität SB Managen der Phasenübergänge Qualität Änderungssteuerung Konfigurationsmanagement Pläne Qualität Änderungssteuerung Risikomgt Änderungssteuerung CP Abschließen eines Projekts Prozess Komponente Technik Pläne PL Planen Produktbasierte Planung Abbildung 22.1 PRINCE2-Prozesse, -Komponenten und Techniken (basierend auf einer Quelle des OGC) Es werden zwei Zertifikate zur Methode angeboten, Foundation und Practicioner. Allein in Großbritannien haben über Personen die Foundation-Prüfung und Personen die Practictioner-Prüfung abgelegt. In der übrigen Welt haben über Personen die Prüfungen abgelegt Prozesse PRINCE2 bietet eine Reihe von Prozessen, die einen gesteuerten Start, gesteuerten Fortschritt und einen gesteuerten Abschluss für jede Art von Projekt bieten: Vorbereiten eines Projekts Initiieren eines Projekts Lenken eines Projekts Steuern einer Phase Managen der Produktlieferung Managen der Phasenübergänge Abschließen eines Projekts Planen Die Prozesse erklären, was wann passieren und welche Rolle es ausführen sollte. Jedes Projekt, das unter PRINCE2 durchgeführt wird, sollte sich in irgendeiner Form mit jedem dieser Prozesse befassen. Allerdings liegt der Schlüssel eines erfolgreichen Einsatzes dieses Prozessmodells darin,

5 244 Frameworks für das IT Management Vier Ebenen Lenkungsausschuss Kunde Auftraggeber Lieferant Teammanager Lieferantenvertreter Unternehmens- oder Programm-Management Projektleitung (trifft Entscheidungen) Projektunterstützung Projektmanagementteam (PMT) Benutzervertreter Projektsicherung Projektmanager Tägliches Management Teammanagement Abbildung 22.2 Die PRINCE2-Organisationsstruktur (basierend auf einer Quelle des OGC) es auf die Bedürfnisse des jeweiligen Projekts hin anzupassen. Man sollte sich jedem Prozess mit der folgenden Frage nähern: Wie streng sollte dieser Prozess auf dieses Projekt übertragen werden? Lenken eines Projekts (DP - Directing a Project) Dieser Prozess zielt auf das Senior Management-Team ab, welches für das Projekt verantwortlich ist und aus den Hauptentscheidungsträgern besteht. Diese sind üblicherweise sehr beschäftigte Personen und sollten nur in den Prozess der Entscheidungsfindung eines Projekts eingebunden werden. PRINCE2 hilft ihnen dabei, dies zu erreichen, indem es die Philosophie des Managements by Exception verfolgt. Der DP-Prozess behandelt die Schritte, die vom Senior Management- Team (dem Lenkungsausschuss) über das gesamte Projekt hinweg vom Start bis zum Abschluss des Projekts unternommen werden sollten und besteht aus fünf Unterprozessen: Autorisieren der Vorbereitung eines Projektplans und eines Business Case für das Projekt; Genehmigen der Weiterverfolgung des Projekts; An neuralgischen Punkten des Projekt-Lebenszyklus überprüfen, ob das Projekt weiterhin gerechtfertigt ist; Verfolgen des Projektfortschritts und Geben von Hilfestellungen im Bedarfsfalle; Sicherstellen, dass das Projekt zu einem kontrollierten Abschluss kommt. Vorbereiten eines Projekts (SU - Starting Up a Project) Dies soll ein sehr kurzer Prozess vor Projektbeginn sein mit fünf Zielen: Zusammenstellung und Ernennung des Projektmanagement-Teams; Sicherstellung, dass die Ziele des Projekts bekannt sind;

6 PRINCE2 - PRojects IN Controlled Environments 245 Gesteuerter Start Gesteuerter Fortschritt Gesteuerter Abschluss Lenkungsausschuss Projektstart (DPI) Projektinitiierung Phasen Projektmanager Arbeitspaket Teamstatusbericht Abgeschlossenes Arbeitspaket Arbeitspaket-Toleranzen Offene Punkte Kommunikationsplan Phasenabschlussbewertung Projektstatusbericht Phasenabschlussbericht Phasentoleranzen Ausnahmebericht Ausnahmebewertung (DP3) Erfahrungsbericht Projektrevisionsplan Projektabschlussbericht Projektabschluss (DPS) Risikoprotokoll Qualitätsprotokoll Liste der offenen Punkte Tägliches Protokoll Erfahrungsprotokoll Teammanager Abbildung 22.3 Projekt-Steuerungsmittel Entscheidung über den Ansatz, der innerhalb des Projekts verfolgt werden soll, um zu einer Lösung zu gelangen; Definieren der Qualitätserwartung des Kunden; Planung der benötigten Arbeiten, um den PRINCE2- Vertrag zwischen dem Kunden und dem Lieferanten zu entwerfen. Initiieren eines Projekts (IP - Initiating a Project) Dieser Prozess bereitet die Informationsgrundlage dafür vor, ob eine hinreichende Berechtigung zur Weiterverfolgung des Projekts vorliegt, etabliert eine gute Managementbasis für das Projekt und erstellt einen detaillierten Plan für möglichst große Bereiche des Projekts, wie das Management im Vorfeld autorisieren kann. Das hier erarbeitete Managementprodukt ist das Projektleitdokument (Projekt Initiation Document) und bildet die Basis, anhand derer der Projektfortschritt und der Projekterfolg gemessen werden wird. Steuern einer Phase (CS - Controlling a Stage) Dieser Prozess bildet den Kern der Arbeit des Projektmanagers am Projekt. Es ist der Prozess, in welchen das tägliche Management der Projektentwicklungsaktivitäten gehandhabt wird. Er beschreibt die Verteilung der Arbeit sowie die Aktivitäten der Überwachung und Steuerung durch den Projektmanager, der in die Sicherstellung dessen, dass die Phase auf Kurs bleibt, und auf unerwartete Ereignisse reagiert, eingebunden ist. Innerhalb einer Phase wird es viele Zyklen der folgenden Aktivitäten geben:

7 246 Frameworks für das IT Management Autorisieren von zu leistender Arbeit; Erheben von Informationen über den Fortschritt der Arbeit; Ausschauen nach Veränderungen; Review der aktuellen Lage; Berichten; Notieren nützlicher Erfahrungen für den Erfahrungsbericht; Durchführen jedweder notwendiger Aktionen. Der Prozess deckt diese Aktivitäten ab, zusammen mit den laufenden Aktivitäten des Risikomanagements und der Änderungssteuerung. Managen der Produktlieferung (MP - Managing Product Delivery) Dieser Prozess stellt einen Steuerungsmechanismus zur Verfügung, mit dem der Projektmanager Details über zu leistende Arbeit mit Teams von Spezialisten abstimmen kann. Dies ist insbesondere dann wichtig, wenn ein oder mehrere Teams von Drittanbietern beteiligt sind, die PRINCE2 einsetzen oder auch nicht. Jede individuelle Arbeitseinheit, die zwischen einem Projektmanager und einem Teammanager abgestimmt wird (einschließlich Zieldatum, Qualitätsund Berichtsanforderungen) wird Arbeitspaket genannt. Der MP-Prozess deckt ab: Sicherstellen, dass die einem Team zugeteilte Arbeit autorisiert und abgestimmt ist; Planung der Teamarbeit; Sicherstellen, dass die Arbeit geleistet wird; Sicherstellen, dass die Produkte den vereinbarten Qualitätskriterien entsprechen; Berichte über die Fortschritte und die Qualität an den Projektmanager; Abnahme der fertig gestellten Produkte erreichen. Managen der Phasenübergänge (SB - Managing Stage Boundaries) Die Ziele dieses Prozesses sind: Berichten über das Ergebnis und die Leistung der gerade beendeten Phase; Planung der nächsten Phase; Aktualisierung des Projektplans; Aktualisierung des Business Case; Aktualisierung der Risikoeinschätzung; Zustimmung des Lenkungsauschusses, mit der nächsten Phase fortzufahren, erreichen. Falls eine größere Abweichung von der Phasen-Planung abzusehen ist, kann der Projektlenkungsausschuss den Projektmanager auffordern, einen Ausnahmeplan vorzulegen. Dieser Prozess deckt die hierfür notwendigen Schritte ebenfalls ab. Abschließen eines Projekts (CP - Closing a Project) Dieser Prozess beschreibt die Aktivitäten des Projektmanagers, die notwendig sind, um die Erlaubnis des Lenkungsausschusses zum Abschluss des Projekts einzuholen, entweder an seinem natürlichen Ende oder auf Grund einer Entscheidung des Lenkungsausschusses, das Projekt vorzeitig zu stoppen. Die Ziele sind: Einschätzung des Grades der Erreichung der bei Projektstart gesetzten Ziele; Bestätigung der Zufriedenheit des Kunden mit den Produkten; Bestätigung, dass Regelungen zu Wartung und Support getroffen wurden (sofern zutreffend);

8 PRINCE2 - PRojects IN Controlled Environments 247 Empfehlungen für anschließende Aktionen; Sicherstellung, dass alle während des Projekts gemachten Erfahrungen festgehalten wurden, um zukünftigen Projekten zugute zu kommen; Bericht, ob die Aktivität des Projektmanagements selbst ein Erfolg waren oder nicht; Vorbereitung eines Plans, um zu überprüfen, ob die geforderten Leistungen des Produkts erreicht wurden. Planen (PL Planning) Das Planen ist ein wiederholbarer Prozess, der von vielen anderen Prozessen genutzt wird, wann immer ein Plan benötigt wird. Der Prozess greift auf die PRINCE2-Technik der produktbasierten Planung zurück und behandelt die folgenden Aspekte: Entwurf des Plans; Definition und Analyse der Produkte des Plans; Identifizierung der notwendigen Aktivitäten und Abhängigkeiten; Abschätzung des notwendigen Aufwands; Planung des Ressourceneinsatzes; Analyse von Risiken; Schreiben von Text, um den Plan, seine Annahmen und die Qualitätsschritte zu beschreiben Komponenten PRINCE2 hat acht Komponenten, um seine Philosophie zu verschiedenen Projektaspekten wie Organisation, Risiko und Plänen, warum sie gebraucht werden und wie sie eingesetzt werden können, zu erklären. Zu den acht Komponenten gehören: 1. Business Case 2. Organisation 3. Pläne 4. Steuerungsmittel 5. Risikomanagement 6. Qualität in einer Projektumgebung 7. Konfigurationsmanagement 8. Änderungssteuerung. Die Philosophie ist durch die Prozesse implementiert. Business Case PRINCE2 basiert auf der Prämisse, dass ein brauchbarer Business Case ein Projekt antreiben sollte. Der grundlegende Inhalt ist definiert und mit den Punkten in den Prozessen verbunden, an denen der Business Case aktualisiert oder zu Rate gezogen werden sollte. Organisation PRINCE2 bietet die Struktur eines Projektmanagementteams sowie eine Definition der Rollen, Verantwortlichkeiten und Beziehungen aller am Projekt beteiligten Mitarbeiter. Abhängig von der Größe und Komplexität eines Projekts können einige der beschriebenen Rollen kombiniert oder geteilt werden.

9 248 Frameworks für das IT Management Pläne PRINCE2 bietet eine Reihe von Ebenen des Planens, welche auf die Größe und Befürfnisse eines Projekts zugeschnitten werden können, und einen eher auf Produkten und nicht auf Aktivitäten basierenden Planungsansatz. Steuerungsmittel PRINCE2 verfügt über eine Reihe von Steuerungsmitteln, die die Bereitstellung von wichtigen entscheidungsrelevanten Informationen erleichtern, was es der Organisation erlaubt, Problemen zuvorzukommen und Entscheidungen zur Problemlösung zu treffen. Für das gehobene Management basieren die PRINCE2-Steuerungsmittel auf dem Konzept des Management by Exception, das heißt, dass der Projektmanager nach der Vereinbarung eines Plans die Erlaubnis haben sollte, diesen zu verfolgen, solange nicht prognostiziert wird, dass etwas schief läuft. Risiko Risiko ist ein über die gesamte Lebensdauer des Projekts hinweg zu berücksichtigender kritischer Faktor. PRINCE2 definiert die neuralgischen Punkte, zu denen Risiken geprüft werden sollten, umreißt eine Herangehensweise an die Analyse und das Management von Risiko und verfolgt diese über alle Prozesse hinweg. Qualität PRINCE2 erkennt die Bedeutung von Qualität an und enthält einen Qualitätsansatz für die Management- und die technischen Prozesse. Er beginnt mit der Etablierung der Qualitätserwartungen des Kunden, verfolgt diese durch Festlegung der einzusetzenden Standards und Qualitätsprüfungsmethoden, und überprüft, dass diese genutzt werden. Konfigurationsmanagement Die Verfolgung von Komponenten eines fertigen Produkts und dessen Versionen zur Veröffentlichung wird Konfigurationsmanagement genannt. Es stehen viele Methoden des Konfigurationsmanagements zur Verfügung. PRINCE2 versucht nicht, eine Neue zu erfinden, sondern definiert die grundlegenden Einrichtungen und Informationsanforderungen für eine Konfigurationsmanagementmethode und wie sie sich mit anderen PRINCE2-Komponenten und Verfahren in Beziehung setzen soll. Änderungssteuerung PRINCE2 betont den Bedarf für eine Änderungssteuerung und setzt dies durch ein Änderungssteuerungsverfahren durch, ergänzt durch eine Bestimmung der Prozesse, welche die Änderungssteuerung verwenden Techniken PRINCE2 bietet drei Techniken. Der Einsatz der meisten von ihnen ist optional: Produktbasierte Planung Qualitätsprüfungstechnik Änderungssteuerungsansatz. Die Organisation hat vielleicht bereits ein Verfahren, das diese Anforderung zufrieden stellend abdeckt, wie Qualitätsprüfung oder Änderungssteuerung. PRINCE2 arbeitet erfolgreich mit

10 PRINCE2 - PRojects IN Controlled Environments 249 solchen betriebseigenen Verfahren zusammen. Dies ist ein sehr wichtiger Teil der PRINCE2- Methode. Sie zu verstehen und zu nutzen bringt große Vorteile und es sollte jede Anstrengung unternommen werden, um sie zu nutzen. Produktbasierte Planung ist grundlegend für PRINCE2. Dafür gibt es zwei Gründe: Zunächst liefert ein Projekt Produkte, nicht Aktivitäten, warum also sollte auf einer niedrigeren Ebene begonnen werden? Der zweite Grund dreht sich um Qualität. Die Qualität eines Produkts kann gemessen werden. Die Qualität einer Aktivität kann nur anhand der Qualität ihres Ergebnisses (dem Produkt) gemessen werden. Die produktbasierte Planung hat drei Komponenten: Produktstrukturplan Produktbeschreibung Produktflussdiagramm. Produktstrukturplan Die meisten Planungsmethoden beginnen einen Plan damit, dem Nachdenken über die zu unternehmenden Aktivitäten und deren Auflistung in einer hierarchischen Struktur namens Projektstrukturplan. Diese Aktivitäten hängen jedoch davon ab, welche Produkte (Dokumente) von dem Projekt hervorgebracht werden müssen, daher ist der richtige Ausgangspunkt für ein Projekt die Auflistung der Produkte. Tatsächlich ist es möglich, dass durch den sofortigen Wechsel zur tieferen Ebene der Aktivität wichtige Produkte und damit wichtige Aktivitäten übersehen werden. Ein Produktstrukturplan ist eine Produkthierarchie, deren Produktion im Plan aufgezeigt werden muss An der Spitze der Hierarchie steht das finale Endprodukt, zum Beispiel ein Computersystem, eine neue Yacht, oder eine in ein neues Gebäude umgezogene Abteilung. Dieses wird auf der nächsten Ebene in seine Hauptbestandteile heruntergebrochen. Jeder Bestandteil wird dann in seine Teile heruntergebrochen und dieser Prozess schreitet solange fort, bis der Planer den für den Plan notwendigen Detailgrad erreicht hat. Produktbeschreibung Für jedes signifikante Produkt wird eine Beschreibung erstellt. Ihre Erstellung zwingt den Planer, zu berücksichtigen, ob genügend Informationen über das Produkt für die Planung seiner Produktion bekannt sind. Es ist ebenfalls der erste Zeitpunkt, zu dem die Qualität des Produkts bedacht wird. Die Qualitätskriterien zeigen, wie viel und welche Art der Qualitätskontrolle notwendig ist. Der erste Schritt bei der Projektplanung sollte das Schreiben einer Produktbeschreibung für das Endprodukt sein. Demzufolge ist es der Zweck hiervon, eine Anleitung zu bieten: für den Planer, wie viel Aufwand notwendig sein wird, das Produkt zu erstellen für den Autor des Produktes dazu, was notwendig ist anhand der das fertig gestellte Produkt gemessen werden kann. Diese Beschreibungen sind eine wichtige Checkliste, die bei einer Qualitätsprüfung der zugehörigen Produkte einzusetzen ist.

11 250 Frameworks für das IT Management Produktflussdiagramm Das Produktflussdiagramm (PFD) ist ein Diagramm, das die Reihenfolge, in der die Produkte erstellt werdem müssen und dessen Abhängigkeiten untereinander zeigt. Es wird nach dem Produktstrukturplan erstellt. Ein PFD benötigt nur drei Symbole; ein Rechteck für die vom Projekt zu erstellenden Produkte, eine Ellipse für Produkte, die bereits verfügbar sind oder von einer projektexternen Quelle bezogen werden und ein Pfeil, um die Abhängigkeit zu zeigen Ansatz/How-To Die Methode kann kostenfrei eingesetzt werden, auch wenn das OGC sich die Eigentumsrechte vorbehält. Die Methode versucht nicht, Verfahren wie Netzplantechnik oder Gantt-Charts, die bereits frei verfügbar sind, zu behandeln, zeigt aber die Schnittstellen zu solchen Verfahren. Die Methode deckt alle Projektgrößenordnungen ab, ein Verständnis der Methode ist jedoch erforderlich, um ihre Flexibilität und Skalierbarkeit zu nutzen Relevanz für das IT Management Da die Methode ursprünglich von einer Gruppe von IT-Managern für die IT entwickelt wurde, ist sie immer noch sehr relevant für das Management von IT-Projekten. Sie bietet einen herausragenden Ansatz für die Planung und Organisation eines Projekts und beschreibt die Erstellung eines Business Case, oft ein schwacher Bereich in IT-Projekten. Die Phase Abschließen eines Projekts ist ebenso sehr relevant, da viele IT-Mitarbeiter mehr daran interessiert sind, zum nächsten innovativen Projekt überzugehen, anstatt ein Projekt formell abzuschließen und offene Enden aufzulösen. Das Konzept eines Arbeitspaket- Vertrags zwischen dem Projektmanager und einem Teammanager führt zu einer ansonsten oft fehlenden Disziplin in IT-Projekten Stärken und Schwächen Die Methode bietet einen disziplinierten Ansatz des Projektmanagements durch die Kombination seiner Prozesse und Komponenten. Sie legt dar, welche Information für den Beginn eines Projektes notwendig ist und berücksichtigt das Zusammentreffen der notwendigen Entscheidungsträger des Projekts, wodurch die Verbindung zwischen dem Projektmanager und dem gehobenen Management, welches den Geldgeber repräsentiert, etabliert wird jene, die das Endprodukt einsetzen werden und jene, die dieses Produkt liefern. Die Kapitel der Methode zu den Steuerungsmitteln, zu Risiken und zur Qualität sind besonders stark, da sie Details zu Zeitplanung, Produkten, beteiligten Rollen und einer vollständigen Struktur, wie diese Aspekte der Methode anzuwenden sind, bieten. Steuerungsmittel werden für das gehobene oder das Programm-Management, den Lenkungsausschuss und den Projektmanager beschrieben. Ein vollständiger Risikomanagement-Ansatz wird bereitgestellt, der die Thematik von der Identifizierung eines Risikos über dessen Bewertung, Formulierung einer geeigneten Antwort hin zur Mittelbereitstellung, Überwachung und Steuerung einer Maßnahme gegen das Risiko behandelt. Die Behandlung von Qualität beginnt bereits vor dem offiziellen Projektbeginn, deckt die Etablierung notwendiger Qualitätsstandards und Rollen, die Qualitätsplanung

12 PRINCE2 - PRojects IN Controlled Environments 251 und überwachung, die Reaktion auf jedwede Qualitätsprobleme sowie die Verknüpfung zur Änderungssteuerung, Konfigurationssteuerung und gemachten Erfahrungen ab. PRINCE2 erlaubt: durch das Unternehmen gesteuertes Management von Änderungen hinsichtlich ihren Investitionen und Rendite aktive Beteiligung der Anwender des Endprodukts über dessen gesamte Entwicklung hinweg, um sicherzustellen, dass das Unternehmensprodukt den funktionalen, Umwelt-, Dienstleistungs- und Managementanforderungen der Anwender entspricht wirksame Steuerung der Projektressourcen aktives Risiko- und Qualitätsmanagement über die Lebensdauer des Projekts hinweg aktive Kontrolle aller Produkte und Produktänderungen einen gesteuerten Start, gesteuerten Fortschritt und einen gesteuerten Abschluss. PRINCE2 ist keine vollständige Antwort auf Projektmanagement. Es enthält keine Methoden wie Führung oder irgendwelche Soft Skills, Netzplantechnik oder Gantt-Charts. Der angegebene Grund für diese Auslassung ist, dass solche Verfahren bereits weithin verfügbar sind, Gegenstand persönlicher Wahl und ohne Konflikte zur Methode oder zu diesen Verfahren in PRINCE2 integriert werden können. Einige Personen behaupten, das eine Schwäche von PRINCE2 darin liegt, dass es Programme nicht abdeckt, dies geschieht jedoch beabsichtigt, da PRINCE2 ein Schwesterprodukt, Managing Successful Programmes (MSP), welches Programmbetrachtungen berücksichtigt, hat. Obwohl PRINCE2 richtigerweise feststellt, dass der Business Case der Schlüsselaspekt eines Projektes ist, fehlt es dem Business Case-Kapitel an Detailtiefe zur Beurteilung von Investitionen Querverweise/Beziehungen PRINCE2 ist ein Schwesterprodukt des De-Facto-Best-Practice-Produkts für Programm- Management MSP (Managing Successful Programmes). Es gibt kein Problem beim Einsatz in Verbindung mit PMBoK. Sie teilen die gleichen Glaubensgrundsätze. PMBoK stellt in allgemeinen Begriffen dar, was in einem Projekt geschehen soll. PRINCE2 bietet eher einen präskriptiverem Ansatz zum Wann, Wie und Wer der Implementierung dieser Sachverhalte. PRINCE2 ist eine Projektmanagementmethode und von Natur aus normativ. PMBoK ist im Gegensatz dazu eine Sammlung von Wissen und deskriptiv. Allgemein ausgedrückt, wo PMBoK die Best-Practice-Inputs, -Outputs, -Werkzeuge und -Verfahren beschreibt, beschränkt sich PRINCE2 auf einen allgemeinen Satz von Managementprodukten und verweist neben den in ihrem eigenen Handbuch eingeschlossenen drei allgemeinen Verfahren nicht auf irgendwelche spezifische Werkzeuge oder Verfahren. Auf der anderen Seite gibt PRINCE2 den (Unter-) Prozessen wesentlich mehr Gestalt und ist in dieser Hinsicht strukturierter als PMBoK. Weiterhin ist PRINCE2 hinsichtlich der Rollen, Verantwortlichkeiten, Autoritäten und Aufgaben der einzelnen Rollen (wer muss was tun) präskriptiv, PMBoK dagegen

13 252 Frameworks für das IT Management nicht. PMBoK beschränkt sich selber auf die Aussage, dass Rollen definiert und abgestimmt werden müssen. Beide Frameworks beschränken sich selbst auf Projektmanagement. Beide Frameworks definieren (Unter-) Prozesse und eine Reihe von Wissensbereichen (in PRINCE2 Komponenten genannt). Beide Frameworks definieren Input- und Output-Dokumente für jeden Unterprozess. Beide Frameworks bieten Umrisse von Managementprodukten: in PMBoK in den Wissensbereichen, in PRINCE2 in separaten Kapiteln. Beide Frameworks behaupten, dass sie auf Best Practices basieren, was in beiden Fällen korrekt ist. In PMBoK bilden die Wissensbereiche das Herz der Methode, in PRINCE2 sind es die Prozesse. In PMBoK werden die Prozesse auf 35 Seiten und die Wissensgebiete auf 200 Seiten beschrieben. In PRINCE2 werden die Prozesse auf 170 Seiten und die Komponenten auf 90 Seiten beschrieben. PMBoK hat fünf Prozesse und PRINCE2 acht. Während die PMBoK-Prozesse sich in jeder Phase wiederholen, definiert PRINCE2 die Prozesse für das gesamte Projekt, einige Prozesse jedoch können mehr als einmal anwendbar sein. Auf der Basis des gegebenen Satzes von Prozessen kann bei PRINCE2 ein Prozessfluss für das Projekt definiert werden. Das Prozesskapitel in PMBoK ist auf die Definition der Prozesse und Unterprozesse sowie auf die Auflistung der zugehörigen Input- und Output-Dokumente pro Unterprozess beschränkt. Der Rest wird in den Wissensbereichen behandelt. In PRINCE2 formen die Prozesse das Herz der Methode. PRINCE2 definiert für jeden Unterprozess die grundlegenden Prinzipien: Kontext Prozessbeschreibung Skalierbarkeit Verantwortlichkeiten Hauptkriterien Hinweise und Tipps Input- und Outputdokumente werden beschrieben. PMBoK hat neun Wissensbereiche einschließlich Integration, Geltungsbereich, Kommunikation und Beschaffung. PRINCE2 hat acht Komponenten einschließlich Buisness Case, Steuerungsmittel, Änderungsmanagement und Konfigurationsmanagement. In PRINCE2 ist Kommunikation in den Steuerungsmitteln und Integration in den Prozessen enthalten. Beschaffung ist nicht in PRINCE2 beschrieben, da PRINCE2 Beschaffung als eine Spezialisten- und nicht als eine Managementaktivität betrachtet. Der Business Case ist das wichtigste Steuerungsinstrument eines PRINCE2-Projekts. In den PMBoK-Wissensbereichen werden ebenfalls die Unterprozesse sowie jeweils deren Inputs, Outputs, eingesetzte Methoden und Verfahren beschrieben. In den PRINCE2-Komponenten ist der Gegenstand beschrieben, eher darauf konzentriert, was zu tun ist und von wem, da die Inputund Outputdokumente bereits in den Unterprozessen beschrieben sind. 1 1 Wir danken Bert Hedeman, Autor des MSP-Kapitels für die Ausführung der Querverweise zwischen PRINCE2 und PMBoK.

14 PRINCE2 - PRojects IN Controlled Environments Links und Literatur Bücher und Artikel zu PRINCE2 Bentley, C. (1997). PRINCE2 Revealed. Oxford: Butterworth-Heinemann Ltd. Bentley, C. (2000). The Essence of PRINCE2. Waterlooville: Hampshire Training Consultants. Bentley, C. (2000). Managing Projects the PRINCE2 Way. Waterlooville: Hampshire Training Consultants. Bentley, C. (2005). Practical PRINCE2. London: TSO. Hedeman, B., H. Fredriksz, & G. Vis van Heemst (2005). Project Management based on PRINCE2. An introduction. Zaltbommel: Van Haren Publishing for itsmf Webseiten zu PRINCE2 - ein Shop für alle offiziellen OGC- Publikationen, einschließlich MSP aus einer Hand. - die APM-Gruppe bietet im Namen des OGC Akkreditierung und Qualifikationen zu Best-Practice-Produkten des OGC wie PRINCE2. Die Webseite enthält weiterhin eine Liste aller für PRINCE2 akkreditierten Schulungsorganisationen. Informationen zu Schulungsmöglichkeiten Die PRINCE2-Webseite der APM Group. die britische Anwendergruppe.

15 IV Impressum Titel: Eine Veröffentlichung von: Redaktion: Verlag: Frameworks für das IT Management itsmf International Jan van Bon (Chefredakteur) Tieneke Verheijen (Redakteurin) Van Haren Publishing, Zaltbommel, ISBN(13): Auflage: Design und Layout: Druck: Originalversion in Englische Sprache Frameworks for IT Management Erste Ausgabe, erste Auflage, September 2006 Erste Ausgabe, zweite Auflage, November 2006 Deutsche Übersetzung: Erste Ausgabe, erste Auflage, September 2007 CO2 Premedia, Amersfoort - NL Wilco, Amersfoort - NL Für weitere Informationen über Van Haren Publishing senden Sie bitte eine an: info@vanharen.net Das itsmf International hat durch ihr International Publications Executive Sub Committee (IPESC), das sich aus einem Ausschuss von Mitgliedern globaler itsmf-landesverbände zusammensetzt, diesem Buch die formale Befürwortung des itsmf International zuteil werden lassen. itsmf International 2006 Alle Rechte vorbehalten. Kein Teil dieses Werkes darf in irgendeiner Form, sei es durch Druck, Fotokopie, Mikrofilm oder in einem anderen Verfahren ohne vorherige schriftliche Genehmigung des Verlages reproduziert oder verarbeitet, übersetzt, vervielfältigt oder verbreitet werden. Obwohl diese Veröffentlichung mit großer Sorgfalt zusammengestellt wurde, übernehmen weder die Autoren noch die Herausgeber oder der Verlag eine Haftung für Schäden, die infolge von eventuellen Fehlern oder Unvollständigkeiten in dieser Veröffentlichung entstehen. HINWEISE AUF EINGETRAGENE WARENZEICHEN PRINCE2, M_o_R and ITIL sind Registered Trade Marks und Registered Community Trade Marks des Office of Government Commerce und sind im U.S. Patent and Trademark Office registriert. CobiT ist ein eingetragenes Warenzeichen der/des Information Systems Audit and Control Association (ISACA)/IT Governance Institute (ITGI). Das PMBoK ist ein eingetragenes Warenzeichen des Project Management Institute (PMI). etom ist ein eingetragenes Warenzeichen des TeleManagement Forum.