Artikel-Schlagworte: „ITIL“

Service Management Efficiencies – Sorting through the Frameworks, Process Models and Standards

Hier gibt es einen interessanten aufgezeichneten Webcast zu dem Thema – http://isaca.brighttalk.com/node/848

Besonders gut finde ich die Slides von Ivor Macfarlane (IBM Tivoli) – http://isaca.brighttalk.com/node/850/redirect/PDF – How many frameworks does it take to manage a service? ITIL, ISO/IEC20000, COBIT, ETOM, TOGAF, eSCM …….

Mainstream ITSM
–  ITIL

• What you should (could) do
• Increasingly bigger picture

Wie schreibt er so schön bzgl ITIL & Co – ist nicht Best Practise ein furchtbarer Name? Erinnert an ein Kochbuch.

Ja stimmt, es sind Kochbücher, aber auch bei Kochbüchern, sofern es nicht um Backen geht, sind die Gerichte oft viel besser, wenn man sich vom Kochbuch nur inspirieren lässt, hernach aber sein eigenes Gericht zaubert.

Wie wäre es also mit Freestyle kochen? Gut, zugegeben es erfordert etwas, dass nicht mehr alltäglich ist den gesunden Menschenverstand. Denn im Prinzip steht im ITIL Framework nicht viel mehr, als das was man durch Logik auch ersinnen würde.

Und wie sagt er noch so schön – „vertraue Deinem Urteil“

You are (probably) the greatest living expert on your job

• Read everything (you can) but:
• Don’t have to do everything you read
• Don’t take things too seriously
• Don’t forget why you are doing things

Natürlich gibt es auch spezifische Frameworks, wie z.B. eTom für die Telekommunikationsindustrie, aber auch eTom passt perfekt zu ITIL.

Sein Fazit dazu wäre „Bringing it all together with common purpose“.

Und ja eine gesunde Mischung, aus dem was am Besten zu der spezifischen Kultur passt, funktioniert naturgemäss am Besten.

Wie sagt er so schön – Favoriten kombinieren, mixen.

Natürlich kommt er auch zum Business – IT Alignment, obwohl er in der nächsten Folie eine schöne Zeichnung hat, welche aufzeigt dass dies noch zu kurz greift – denn der Kunde wird immer wichtiger – gerade in Zeiten des Web 2.0

Hier ein paar gute Kombinationen der Frameworks

COBIT und ITIL
ITIL und eTOM
TOGAF und COBIT

Wo starten? Ich erlaube ich mir nochmals Ivor Macfarlane zu zitieren

Rarely are starting of course
Common sense in place (exceptions of course)
That common sense drives consistency

Wie soll man darauf sehen? Nun in dem man sich erst mal klar macht, was Governance eigentlich bedeutet, und dies wäre nicht anderes als Management des Managements.

Des weiteren – von unten nach oben oder von oben nach unten

• Strategie
• Taktik
• Operations

Weiters finde ich auch gut, dass er darauf hin weißt, dass die Guidance, also de facto die Guidlines nicht zu eng gefasst sein dürfen. Und das man sich vor falschen Annahmen hüten solle – eine Welt in die andere tragen, kann funktionieren, muss es aber nicht unbedingt.

Noch besser ist allerdings sein Fazit:

How many frameworks does it take to manage a service?

• Need = none at all
• How many can help?
• = as many as is useful to you.

Aber was schreibe ich hier so viel – downloaden und lesen, oder gegebenenfalls mich kontaktieren.

In diesem Sinne allen einen schönen Feiertag und verbleibe mit besten Grüßen,
Ihre Jutta Staudach
info<at>jutta-staudach.de

mehr Infos zum Service Management Lebenszyklus – hier – Servicemanagement-Lebenszyklus_rev_1.pdf

Fragen? Call – +49.171.3833409

Business Change Manager Fredi Schlau hatte bereits vor Wochen bemerkt, dass Universalbank Bad Bank das Privatkundengeschäft veräussert hat, – zu wenig ROI (Return on Investement) Omas Rentenfond in Kooperation mit Vertrauensversicherung Budapest wurde wohl doch zu wenig nach gefragt.

Projektmanagerin Bonnie Techhie hat alle Papiere, Change Request für den Go-Life und Changeover, als auch alle Änderungen in der CMDB beisammen, auch die nötigen Lizenzen sind in Place, der Softwarecode in Escrow – CEO Unwissend strahlt – sämtliche Governance und Compliance Framworks in Place, auch mit IT Outsourcing Dienstleister Rechenzentrum Super Schnell sind die SLA’s pico bello defininiert, die Bankenaufsicht hat den Audit abgewunken – alles in bester Ordnung (denn den Datenzugriff in Staat Sonnenschein – nun der betrifft Staat Sonnenschein)

Rechenzentrum Super Schnell ist bekannt für seine effizienten und effektive Implemntation des ITIL Frameworks, die Mitarbeiter im Incident, Problem- Change und Release Management als auch zu allererst im Service Desk sind allererster Sahne – da kann doch nichts schief gehen – Morgen läuft die New good all inclusive Bank.

Denkt CEO Unwissend, das denkt er – denn Papier ist geduldig und Frameworks / Tools sind Enabler – ersetzen keinen gesunden Menschenverstand.

Business Change Manager Fredi Schlau hat per Agentur eine grosse Kampagne lanciert, dass Morgen New good all inclusive Bank samt Super Schnell Portal Life geht und es haben sich auch bereits 50% Neukunden ausgehend vom Altkundebestand angemeldet.

Dumm nur das Bonnie Tecchie grad mal mit 60% des Altkundebestandes auf der neuen Infrastruktur kalkuliert hat.

Es kommt wie es kommen muss – erstens ist das Image und die Reputation der Good Bank am Tag 21 nach Go-Life nachdem immer noch nichts funktioniert – nicht einmal die Filialen, da die Mitarbeiter weder eingeschult wurden, noch die Funktionen dort vorfinden, wo sie sein sollten, ausserdem hat Staat Sonnenschein bei der Regierung von Good Bank interveniert und die Bankenaufsicht droht mit Schliessung.

Aber sogar der Business Continuity Test – besser gesagt das Disaster Recovery hat funktioniert – high available sind Bonnie Tecchies Systeme auch die SLA’s wären theoretisch einhaltbar gewesen, wenn …………………

Mittlerweile hat Universalbank Bad Bank eingesehen, dass man das Privatkundengeschäft benötigt, um die Kunden im Wealth Management an sich zu binden und kauft Good Bank

Die neue Bank heisst White Bank ………

CEO Unwissend und seine Mannschaft sitzt mittlerweile auch auf Insel Aussteigerparadies und weint – bitterliche Tränen – wir haben doch alle Prozesse und Frameworks, Compliance und Governance eingehalten – WARUM?

ein Schelm der sich böses dabei denkt – alle Ähnlichkeiten mit lebenden & toten Personen, als auch Unternehmen sind rein zufällig und keinesfalls gewollt.

Ihre Jutta Staudach,

Tools und Frameworks kann man lernen, Verstand schenkt der Herr ……..

Risikomanagement Risk Management Industriestandards Industry Frameworks

IT Services: Capability Maturity Model (CMM)

IT Services CMM Website findet der geneigte Leser hier http://sites.google.com/site/itservicecmmwebsite/

Capability Maturity Model
aus Wikipedia, der freien Enzyklopädie

Capability Maturity Model (Reifegradmodell)® (kurz CMM®) ist ein Reifegradmodell zur Beurteilung der Qualität („Reife“) des Softwareprozesses (Softwareentwicklung, Wartung, Konfiguration etc.) von Organisationen sowie zur Bestimmung der Maßnahmen zur Verbesserung desselben.

CMM wurde Ende 2003 durch Capability Maturity Model Integration® (kurz CMMI®) ersetzt, um dem Wildwuchs diverser CM-Modelle (jede Entwicklungs-Disziplin entwickelte ein eigenes Modell) entgegenzuwirken und ein neues, modulares und vor allem vereinheitlichtes Modell zu erstellen.

Andere populäre Modelle sind ITIL für die Infrastruktur und Spice für Reifegradbestimmung und Assessment der Software-Prozesse.

COBIT

CoBit Website http://www.isaca.org/Knowledge-Center/COBIT/Pages/Overview.aspx

CobiT
aus Wikipedia, der freien Enzyklopädie
(Weitergeleitet von Cobit)

CobiT (Control Objectives for Information and Related Technology) ist das international anerkannte Framework zur IT-Governance und gliedert die Aufgaben der IT in Prozesse und Control Objectives (oft mit Kontrollziel übersetzt, eigentlich Steuerungsvorgaben, in der aktuellen deutschsprachigen Version wird der Begriff nicht mehr übersetzt). CobiT definiert hierbei nicht vorrangig, wie die Anforderungen umzusetzen sind, sondern primär darauf, was umzusetzen ist.

Cobit ist nicht inkompatibel zu anderen Frameworks wie ITIL oder ISO 9000.

COSO

COSO Website findet der Leser hier http://www.coso.org/default.htm

Auszug aus Wikipedia

Das COSO-Modell (1992/94)

COSO hat 1992 einen heute von der SEC anerkannten Standard für interne Kontrollen, das COSO-Modell[1], publiziert. Dieses Kontrollmodell dient der Dokumentation, Analyse und Gestaltung des internen Kontrollsystems, beschränkt sich allerdings stark auf die Finanzberichterstattung.

Die Bestandteile des internen Kontrollsystems nach dem COSO-Modell sind:

* Kontrollumfeld
* Risikobeurteilung
* Kontrollaktivitäten
* Information und Kommunikation
* Überwachung

Das COSO ERM-Framework (2004)

Im Jahr 2004 hat COSO eine Ergänzung zu seinem ursprünglichen Modell, das COSO ERM – Enterprise Risk Management Framework veröffentlicht. Das COSO ERM fügt zusätzliche Elemente ein:

* Internes Kontrollumfeld
* Zielsetzung
* Ereignisidentifikation
* Risikobeurteilung
* Risikoreaktion
* Kontrollaktivitäten
* Information und Kommunikation
* Monitoring

IT Service Management ITSM

IT-Service-Management
aus Wikipedia, der freien Enzyklopädie

IT-Service-Management (ITSM) bezeichnet die Gesamtheit von Maßnahmen und Methoden, die nötig sind, um die bestmögliche Unterstützung von Geschäftsprozessen (GP) durch die IT-Organisation zu erreichen. ITSM beschreibt insofern den Wandel der Informationstechnik zur Kunden- und Serviceorientierung. Von Bedeutung ist die Gewährleistung und Überwachung der Business Services, also die für den Kunden sichtbaren IT-Services. Auf diese Weise können kontinuierlich die Effizienz, die Qualität und die Wirtschaftlichkeit der jeweiligen IT-Organisation verbessert werden.

Mit dieser Definition ist der Begriff in das folgende Umfeld einzuordnen:

* Business Service Management (BSM): Die Verbindung zwischen Prozessmanagement und ITSM.
* IT-Service-Management (ITSM): Methoden, die nötig sind, um die bestmögliche Unterstützung von Geschäftsprozessen (GP) durch die IT-Organisation zu erreichen.
* Prozessmanagement (auch Geschäftsprozessmanagement, GPM): Die Definition der Prozesse des Business, die durch die IT unterstützt werden.
* Serviceorientierte Architektur (SOA): Ein Managementkonzept für eine dienstorientierte Architektur der ICT.

Normen / Frameworks / Standards

Mit der BS 15000 existiert in Großbritannien eine Norm, mit der einzelne IT-Service-Management-Prozesse spezifiziert sind. Auf Basis des BS 15000 kann ein Unternehmen sein IT-Service-Management zertifizieren lassen. Die BS 15000 wurde im Dezember 2005 in die internationale Norm ISO/IEC 20000:2005 überführt. Daneben gibt es weitere Frameworks und Standards. Diese sind zum Teil firmenspezifische Vorgaben oder branchenorientierte Lösungen. Beispiele dafür sind:

* IT Infrastructure Library (ITIL)
* enhanced Telecom Operations Map (eTOM)
* Microsoft Operations Framework (MOF) von Microsoft

Von „http://de.wikipedia.org/wiki/IT-Service-Management“

National Institute of Standards and Technology (NIST)

Gegründet 1901

National Institute of Standards and Technology
aus Wikipedia, der freien Enzyklopädie
(Weitergeleitet von NIST)

National Institute of Standards and Technology

Das National Institute of Standards and Technology (NIST) ist eine Bundesbehörde der Vereinigten Staaten mit Sitz in Gaithersburg (Maryland) und in Boulder (Colorado). Der frühere Name der Behörde war von 1901 bis 1988 The National Bureau of Standards (NBS). Die Position des Behördenleiters (Director) wird derzeit von Patrick Gallagher besetzt.

Das NIST gehört zur technologischen Administration des Handelsministeriums und ist für Standardisierungsprozesse zuständig. Aus diesen ist der Verschlüsselungsalgorithmus DES wie auch AES hervorgegangen. Weiterhin werden die Federal Information Processing Standards (FIPS) veröffentlicht, die für US-Behörden gelten.

NIST-F1 ist der Name der NIST-Atomuhr, die zur Koordinierten Weltzeit beiträgt. Sie hat eine theoretische Abweichung von einer Sekunde in 60 Millionen Jahren.[3]

Das NIST gibt unter anderem auch die für massenspektrometrische Messungen heute unverzichtbare Sammlung zur Substanzidentifizierung durch das stoffspezifische Massenspektrum, die NIST/EPA/NIH Mass Spectral Library (Data Version: NIST 08, Software Version 2.0f) heraus.

Das deutsche Gegenstück ist die Physikalisch-Technische Bundesanstalt (PTB).

Das NIST hat im Jahr 2009 ein Budget von 819 Millionen US-Dollar (plus zusätzlichen 610 Millionen US-Dollar aus dem American Recovery and Reinvestment Act [4]) zur Verfügung [5][6]. Beim Institut sind 2.900 Mitarbeiter beschäftigt. Es beauftragte in den 1970er Jahren u. a. die Boulder-Gruppe mit der Messung der Lichtgeschwindigkeit und der Neudefinition des Meters.

PMBOK (PMI)

Project Management Body of Knowledge
aus Wikipedia, der freien Enzyklopädie
(Weitergeleitet von PMBOK)

Der Guide to the Project Management Body of Knowledge (PMBoK Guide) ist ein weit verbreiteter Projektmanagement-Standard und zentrale Referenz des US-amerikanischen Project Management Institute, von dem er auch herausgegeben und unterhalten wird.

In der Einführung bezeichnet sich das Werk als „Zusammenfassung des Wissens der Fachrichtung Projektmanagement“. Gemeint ist das Wissen über die Vorgehensweisen, die weithin als bewährte Praxis (PMBoK: „best practice“) anerkannt werden. Die beschriebenen Methoden sind auf Projekte aus verschiedenen Anwendungsbereichen anwendbar, dazu gehören u.a. Bauwesen, Software-Entwicklung, Maschinenbau und Automobilindustrie.

Der PMBoK Guide ist prozessorientiert, d. h. er verwendet ein Modell, nach dem Arbeit durch Prozesse erledigt wird. Ein Projekt wird durch das Zusammenspiel vieler Prozesse durchgeführt. Anhand der Prozesse strukturiert das PMBoK das gesammelte Methodenwissen. Für jeden Prozess werden Input, Output und Werkzeuge und Verfahren beschrieben.

Das American National Standards Institute (ANSI) und das Institute of Electrical and Electronics Engineers (IEEE)[1] erkennen das PMBOK als Standard an. Es wurde (neben Englisch) in elf Sprachen übersetzt.

Der PMBoK Guide ist die Basis für die Zertifizierungsprüfung zum Project Management Professional (PMP) und für die Eingangslevel-Zertifizierung Certified Associate in Project Management (CAPM).

Es werden insgesamt 42 Prozesse definiert (vierte Ausgabe), die in die folgenden fünf Prozessgruppen eingeordnet werden:

* Initiierung

Prozesse zur formalen Autorisierung des Projekts. Ergebnisse sind der Projektauftrag (Beauftragung des Projektleiters) und das vorläufige Scope Statement.

* Planung

Festlegung des Projekt-Umfangs (Ergebnis: Scope Statement) und Festlegung, wie in den einzelnen Wissensgebieten geplant wird (Ergebnis Projektmanagementplan als „Meta-Plan“), dazu Durchführung der Planung (Ergebnisse: Projektstrukturplan, Terminplan, Kostenplan, Beschaffungsplan, Risikoplan, …).

* Ausführung

Sicherstellen, dass die Aktivitäten ausgeführt werden, wie sie geplant wurden. Wichtigstes Ergebnis ist natürlich der eigentliche Liefergegenstand des Projekts. Auch Prozesse wie Qualitätssicherung, Projektteam aufbauen und Anbieter auswählen zählen zu dieser Prozessgruppe.

* Überwachung und Steuerung

Die zugehörigen Prozesse sammeln und bewerten Informationen zur Projekt-Performance entsprechend der Planung im Projektmanagementplan. Auch Risiko-Überwachung gehört zu dieser Prozessgruppe. Wichtige Ergebnisse sind Vorschläge für Korrekturmaßnahmen oder vorbeugende Maßnahmen.
Der Prozess Integrierte Änderungssteuerung regelt die Abwicklung von Änderungsanträgen (Change Requests, CRs).

* Abschluss

Die beiden Prozesse dieser Gruppe sind Vertragsbeendigung (besonders Verträge mit Kunden und Lieferanten) und Projektabschluss (dabei wird der Projektauftrag als geschlossen erklärt).

Eine Matrix ordnet jeden Prozess eindeutig einer Prozessgruppe und einem Wissensgebiet zu. Dabei wurde für jeden Prozess die Prozessgruppe gewählt, in der der größte Teil der Aktivitäten des Prozesses stattfindet.
Wissensgebiete

Der Abschnitt über die Wissensgebiete bildet den Schwerpunkt des PMBoK Guide. Jeweils ein Kapitel widmet sich einem Wissensgebiet. Alle 42 Prozesse werden detailliert beschrieben. Dabei werden für jeden Prozess Inputs, Outputs und Methoden und Werkzeuge beschrieben.

Die Wissensgebiete, denen die Einzelprozesse aus den Prozessgruppen jeweils eindeutig zugeordnet sind, heißen:

* Integrationsmanagement

Das Wissensgebiet Integrationsmanagement in Projekten umfasst die Prozesse und Vorgänge, die benötigt werden, um die verschiedenen Prozesse und Projektmanagementvorgänge in den Projektmanagementprozessgruppen zu identifizieren, zu definieren, zu kombinieren, zu vereinheitlichen und zu koordinieren. Im Projektmanagementkontext umfasst Integration Merkmale der Vereinheitlichung, Konsolidierung und Gliederung sowie integrative Aktionen, die entscheidend sind für den Abschluss von Projekten, die erfolgreiche Erfüllung der Anforderungen von Kunden und anderer Stakeholder und den Umgang mit Erwartungen.

* Inhalts- und Umfangsmanagement

Das Inhalts- und Umfangsmanagement in Projekten beinhaltet die erforderlichen Prozesse, um sicherstellen, dass das Projekt alle erforderlichen Arbeiten, aber auch nur diese, umfasst, um es erfolgreich zu beenden. Hierbei geht es vorrangig um die Definition und Steuerung dessen, was im Projekt eingeschlossen ist und was nicht.

* Terminmanagement

Zielt auf die Einhaltung des Zeitrahmens und sollte alle beteiligten Zielgruppen einbinden. Der Projektplan dient dabei v.a. auch als Kommunikationsmedium.

* Kostenmanagement

Zielt auf Budgeteinhaltung. Hierfür ist der Kostenverlauf zu erfassen. Gegebenenfalls sind Gegenmaßnahmen einzuleiten.

* Qualitätsmanagement

Erfordert Standardisierung von PM-Prozessen, Dokumentation der Arbeiten und Ergebnisse, sowie ein geeignetes Maßnahmenmanagement

* Personalmanagement

Personalmanagement in Projekten umfasst die Prozesse, die das Projektteam organisieren und managen. Das Projektteam besteht aus den Mitarbeitern, die zugewiesene Rollen und Verantwortlichkeiten haben, um das Projekt fertig stellen zu können.

* Kommunikationsmanagement

Kommunikationsmanagement in Projekten ist das Wissensgebiet, in dem die Prozesse angewendet werden, die für das rechtzeitige und sachgerechte Erzeugen, Sammeln, Verteilen, Speichern, Abrufen und Verwenden von Projektinformationen notwendig sind.

* Risikomanagement

Risikomanagement in Projekten umfasst die Prozesse bezüglich der Durchführung der Risikomanagementplanung, Identifizierung, Analyse, Maßnahmen sowie Überwachung und Steuerung bei einem Projekt; die meisten dieser Prozesse werden im Verlauf des Projekts aktualisiert. Ziele des Risikomanagements in Projekten sind die Steigerung der Wahrscheinlichkeit und der Auswirkungen positiver Ereignisse sowie die Verringerung der Wahrscheinlichkeit und der Auswirkungen von Ereignissen, die für das Projekt ungünstig sind.

* Beschaffungsmanagement

Beschaffungsmanagement in Projekten beinhaltet die Prozesse für den Kauf oder Erwerb der Produkte, Dienstleistungen und Ergebnisse, die von außerhalb des Projektteams für die Durchführung der Arbeit benötigt werden. Beschaffungsmanagement in Projekten umfasst das Vertragsmanagement und die Prozesse zur Änderungssteuerung, die zum Managen der von autorisierten Projektteammitgliedern ausgegebenen Verträge oder Bestellungen erforderlich sind. Beschaffungsmanagement in Projekten umfasst außerdem die Verwaltung aller Verträge, die von einer externen Organisation (dem Käufer) ausgegeben wurden, der das Projekt von der Trägerorganisation (dem Verkäufer) erwirbt, sowie die Verwaltung vertraglicher Verpflichtungen, die dem Projektteam durch den Vertrag auferlegt werden.

Die einzelnen Aufgabenfelder treten im Projektverlauf an verschiedenen Stellen auf.

Supply-Chain Operations Reference Model (SCOR)

5 Schlüsselbereiche und 3 Prozesse – mehr Details gibt es hier www.supply-chain.org

Zusammenfassung:

Jutta Staudach

Risikomanagement, Projektmanagementberatung Düsseldorf

Projektmanagement Zertifikate PMP CAMP IPMA Level D IPMA Level C

Viele Fragen sich, welche Projektmanagement Zertifizierung ist für mich die Richtige? Auf Prince2 bin ich bereits früher eingegangen, es bietet, wie auch ITIL ein klassisches Best Practice Framework.

Die PMP-Prüfung misst die Umsetzung und Anwendung von Wissen, Kenntnissen, Tools und Methoden in der Projektmanagement-Praxis. Das PMP Examen beinhaltet einen Anteil der Fragen aus den folgenden einzelnen Teilbereichen wie Initialisierung, Planung, Ausführung, Überwachung, Steuerung, Abschluß sowie fachliche und soziale Verantwortung.

Die Prüfung besteht aus 200 Multiple Choice Fragen, von denen 25 als Testvorbereitung dienen. Diese Fragen sind zufällig an beliebigen Stellen in die Prüfung eingestreut und beeinflussen die Punktzahl nicht. Sie werden lediglich als effektive und legitime Mittel eingesetzt, um die Anzahl zukünftiger Prüfungsfragen zu erhöhen.

Der Geprüfte verfügt über 4 Stunden Zeit. Der Prüfung voraus geht eine 15-minütige Computer-Einführung, welche nicht in die Prüfungszeit eingerechnet wird.

Die Certified Associate in Project Management (CAPM) Zertifizierungsprüfung
Bewerber müssen eine dreistündige Prüfung bestehen, die 150 Fragen umfasst und auf dem „PMBOK Guide“ als Quelle beruht. Die Fragen wurden von Personen aus aller Welt zusammengestellt. Diese Personen sind im Besitz der CAPM-Zertifizierung und werden regelmässig „überwacht“, um zu gewährleisten, dass die Prüfung weiterhin eine zuverlässige und gültige Beurteilung der Bedingungen sowie Praktiken des Projektmanagements darstellt.

Folgende Voraussetzungen werden an den Kandidaten für die CAPM oder PMP-Zertifizierung gestellt:
PMP Kandidaten ohne Hochschulabschluß: 7.500 Stunden Projektmanagementerfahrung; 60 Monate (ohne Überschneidungen) Projektmanagementerfahrung in den letzten 8 Jahren; 35 Stunden Projektmanagement-Weiterbildung.
PMP Kandidaten mit Hochschulabschluß: 4.500 Stunden Projektmanagementerfahrung; 36 Monate (ohne Überschneidungen) Projektmanagementerfahrung in den letzten 8 Jahren; 35 Stunden Projektmanagement-Weiterbildung
Zulassungsanforderungen zur Certified Associate in Project Management (CAPM) Zertifizierung:
Hochschulreife/Fachhochschulreife
1.500 Stunden Arbeit in einem Projektteam oder 23 Kontaktstunden in der Projektmanagement-Ausbildung.

Dabei kann der CAPM mit IPMA Level D und der PMP mit IPMA Level C verglichen werden.

Jutta Staudach
PRojektmanagement Düsseldorf

ITIL Umsetzung Prince2 Projekt

Wie bereits die Computerwoche vom 19. Oktober 2009 beschrieb, lässt sich ITIL V3 Umsetzung trefflich als Prince2 Projekt realisieren.

Da die Einführung von ITIL V2, und noch mehr die von ITIL V3 ziemlich komplex ist, erhöht sich die Erfolgswahrscheinlichkeit durch die Einsetzung einer Best Practise Methode wie Prince2. Denn Herzstück eines Prince2 Projektes ist die Project Initiation Documentation, welche unter andem den Business Case enthält. Dieser ist die Rechtfertigung des Vorhabens indem er die Kosten, dem Nutzen gegenüber stellt und von Executive (Sponsor) des Projektes abgesegnet wird.

Weiterer Pluspunkt ist die Steuerung über Phasen, wobei die Milestones nicht mit technischen Meilensteinen zu verwechseln sind.

Prince2 lebt auch mit der Philosophie „Management by Exception“ – heisst gewisse Toleranzen sind bereits in der PID mit abgesegnet. ITIL widerum beschreibt vortrefflich wie mit Changes umgegangen werden soll. Heisst viel unnötiger Aufwand wird erspart. Anders bei einem richtigen RfP (Request for Change), welcher so Komplex ist, dass er die Toleranzen sprengt.

Weiterer Vorteil des Einsatzes von Prince2 bringt die Fokussierung auf das (End-)Produkt und nicht wie bei PMI auf das Delivery. Auch ist das Qualitätsmanagement auf die vom Kunden (Business) erwartete Qualität und nicht die best mögliche fokussiert.

ITIL V3 wiederum bietet bereits alles, was für die Konfigurations- und Änderungssteuerung von Nöten ist „out of the box“. Hier macht sich die gemeinsame Herkunft der OGC (Office of Goverment Commerce) nutzbringend bemerkbar.

Den ganzen Artikel und mehr zum Thema ITIL und Prince2 gibt es bei der Computerwoche.