PRISMA

Vom Kunden gestellte Vorleisungen, die zur Verrichtung der Arbeit benötigt werden

3-5

• Plattform
  • Auf der der Service betrieben wird
• Servebetreiber (User)
  • Der den Service betreibt
• Service für den Service
  • Zum Warten des Services

• Resposible
  • Setzt um
• Accountable
  • Nimmt ab
• Supported
• Consulted
  • Asked before done
• Informed
  • Informed after done

Return on Investment

Definiert immer einen Zeitraum

• Sicherheit
• Bequemlichkeit
• Profit
• Prestige (Machtgewinn)

Stakeholderzufriedenheit

• Aufgewandte Arbeit * kalkulatorischer Stundensatz
• (Kein Projekt ohne Kalkulation - ob intern oder extern)

• Operational Expenditures
• Betriebskosten

• Capital Expenditures
• Anschaffungskosten

• Install
  • Systemaufbau am Arbeitsplatz des Anwenders
  • Erstinstallation und Bereitstellung von Hardware- und/oder Softwarekomponenten
• Move
  • Umzug des Arbeitsplatzsystems an einen anderen Standort
  • Wechsel auf ein anderes Arbeitsplatzsystem
  • Wechsel des Endanwenders
• Add
  • Hinzufügen von neuer Hardware
  • Nachinstallation von Software
  • Anpassungen im Vertrags- und Lizenzmanagement
• Change
  • Änderung der bestehenden Hardwarekonfiguration
  • Aktualisierung von Betriebssystemen und installierter Software
  • Anpassungen von Einstellungen an der Software
  • Deinstallationen von nicht benötigten Softwareapplikationen
• Remove
  • Kontrolle der zu deinstallierenden Geräte
  • Sichere Löschung vorhandener Datenträger
  • Erstellen eines Löschberichts
  • Abbau der definierten Systemgruppe
  • Vorbereitung zum Rücktransport, zur Einlagerung oder zur Entsorgung
• Dispose
  • Abtransport und umweltgerechtes Recycling
  • Hardware-Refresh (Wiederaufbereitung/ Prüfung der Hardware) und Rückführung zum Kunden

• Ein Underpinning Contract (Vertrag mit Drittparteien, UC) ist ein Vertrag zwischen einem Service Provider und einem externen Dienstleister über die Erbringung eines unterstützenden Service, mit dessen Hilfe der Service Provider einen Kundenservice anbieten kann.
• Underpinning Contracts müssen deshalb mit den auf die Kunden ausgerichteten Service Level Agreements in Übereinstimmung stehen.

• Zweck
  • Zweck
    • Welche Absicht steht hinter dem Projekt? (auch Herausforderung und/oder Ursache)
    • Warum ist das Projekt wichtig und bedeutsam – und für wen?
    • Inwiefern wird das Projekt die Zukunft verändern – und für wen?
• Inputfaktoren
  • Budget
    • Wieviel Geld wird benötigt / ist verfügbar?
  • Team
    • Wer ist dabei / sollte dabei sein? (Kernteam / erweitertes Team / externe Partner / Projektleiter)
  • Ressourcen
    • Welche Ressourcen werden benötigt? (z.B. Arbeitsräume und Arbeitsmittel)
• Transformationsfaktoren
  • Umfeld
    • Bekannte Kräfte, Bedingungen, Ereignisse und Menschen, die das Projekt beeinflussen.
    • Wer/was unterstützt das Projekt?
    • Wer/was behindert das Projekt?
  • Meilensteine
    • Welche Etappenziele sind wichtig? (Termine für Zwischenergebnisse, wichtige Entscheidungen sowie sicht- und messbare Erfolge)
  • Chancen und Risiken
    • Welche unsicheren Ereignisse würden, im Falle ihres Eintretens, den Projekterfolg gefährden bzw. beflügeln? (Sicher eintretende Ereignisse sind als Umfeld-Bedingungen zu berücksichtigen).
• Outputfaktoren
  • Qualität
    • Was macht die Kunden wirklich glücklich bezogen auf:
      • das Ergebnis des Projekts?
      • die Meilensteine auf dem Weg dorthin?
      • die Art der Information/Mitarbeit im Projekt?
  • Ergebnis
    • Was soll das Projekt für die Kunden liefern? Ist es am ehesten ein neues Produkt, ein neuer Service, oder neue Erkenntnisse und Wissen?
  • Kunde
    • Wer ist der Kunde? Menschen, die
      • das Projekt finanzieren (Sponsoren)
      • das Projekt starten und beenden (Eigentümer)
      • die Projektergebnisse erhalten (Empfänger)
    • Bei mehreren Kunden sollte nach absehbaren Konflikten zwischen diesen Kunden(-gruppen) Ausschau gehalten werden.
• Zeit
  • Zeit
    • Wann startet das Projekt? Und was wird dafür benötigt? (z.B. Vorbereitungen, Dokumente, Freigaben)
    • Wann ist das Projekt abgeschlossen? Und was wird dafür benötigt? (z.B. Dokumente, Freigaben)
    • Wie flexibel sind Start- und Endtermine des Projekts?
    • Wie flexibel sind Meilensteintermine?

• Bei einer Projektplanung nach Critical Chain erhalten die einzelnen Vorgänge keine Pufferzeiten mehr, sondern werden nach ihrer optimistischen Dauer oder sogar minimalen Dauer geplant.
• Die zeitlichen Puffer (z.B. Differenz zwischen optimistischer Dauer und pessimistischer Dauer) werden kumuliert und an das Ende des Projekts als gemeinsamer Puffer angehängt.
• Dabei ist der gemeinsame Puffer nicht notwendigerweise die Summe aller Einzelpuffer, sondern kann nach statistischen Gesetzmäßigkeiten verkürzt werden.

Die „Theory of Constraints“ (TOC/Engpasstheorie) besagt, dass der Erfolg eines Systems durch ein einzelnes Element bestimmt wird. Beseitigt man diesen Engpass (engl. Constraint), so schafft man neues Wachstum innerhalb des Systems.

• Muss in die Risikoanalyse mit aufgenommen werden
• Vermeiden ist nicht wahrscheinlich
• Also Auswirkungen vermindern
  • Z.B. Schadenersatzklausel in den Lieferantenvertrag einfügen

"Selbstverständliche" Risiken werden nicht mit in der Risikoanalyse aufgenommen

• Maßnahmenstrategie "Akzeptieren" nur wenn von z.B. der Premortem Analyse Teilnehmern abstruse "Kardinalsrisiken" aufgenommen wurden (die sowieso akzeptiert werden)
  • Durch iterativer Eigenschaft der Risikoanalyse kann hieraus ein Mehrwert entstehen
  • Falls das Risiko eintritt, sollte es auch dokumentiert sein
• 3 Maßnahmen immer präsentieren
  • Do nothing
  • Do the minimum
  • Do the best

• Risikoidentifikation - Name des Risikos oder ID-Nummer
• Risikobeschreibung - Kurze Übersicht über das Risiko
• Risikokategorie - Entsprechende Einstufung
• Risikowahrscheinlichkeit - Mit welcher Wahrscheinlichkeit tritt das Risiko ein
• Risikoanalyse - Potenzielle Auswirkungen des Risikos
• Risikominimierung - Risikoreaktionsplan
• Risikopriorität - Risikostufe verglichen mit anderen
• Risikoverantwortlichkeit - Für die Lösung verantwortliche Person
• Risikostatus - Fortschritt beim Risikoreaktionsplan

• Program evaluation and review technique (auch: 3 Punkt Schätzung)
• Zweck: Aufwandsschätzung
• Ablauf:
  • Dauer schätzen
    • Mindestdauer schätzen
    • Normaldauer schätzen
    • Maximaldauer schätzen
  • Mittel kalkulieren
    • (Mindestdauer + (4 * Normaldauer) + Maximaldauer) / 6

• Portfolio
  • Portfoliomanager sind konstant damit betraut, Veränderungen in der Unternehmensumgebung wahrzunehmen, sie zu durchleuchten und entsprechende Anpassungen in der Umsetzung der Unternehmensstrategie vorzunehmen.
• Projekt/ Programm
  • Dies kann wiederum Auswirkungen auf Programme und einzelne Projekte haben. Vor allem Projektmanager müssen darauf achten, Änderungen in ihr Projekt zu implementieren. Ein Konfigurations-Managementsystem kann dabei helfen, eine Vielzahl an Änderungen zu kontrollieren.

• Projekt
  • Entlang des Projektlebenszyklus ist es die Aufgabe des Projektmanagers, High-Level-Anforderungen in detaillierte Planungen umzusetzen.
• Programm
  • Innerhalb von Projektprogrammen werden übergeordnete Pläne ausgearbeitet, die Planungen auf Projektniveau beeinflussen können, um beispielsweise Ressourcen entlang mehrerer Projekte effizient zu verteilen.
• Portfolio
  • Im Rahmen des Portfoliomanagements werden die nötigen Prozesse gestaltet, die zur Zielerreichung entlang der Projekte und Programme nötig sind. Eine besondere Herausforderung ist dabei die Gestaltung der Kommunikation innerhalb des Portfolios.

• Projekt
  • Die Aufgaben eines Projektmanagers sind klar abgegrenzt: Er ist für die Organisation und Führung des Projektteams sowie die Zielerreichung seines Projektes verantwortlich.
• Programm
  • Programmmanager stellen eine übergeordnete Projektführung dar. Sie haben gegenüber den Programmmitarbeitern und Projektmanagern eine Führungsverantwortung wahrzunehmen.
• Portfolio
  • Natürlich haben auch Portfoliomanager eine Führungsverantwortung gegenüber ihren Portfoliomitarbeitern, greifen aber vor allem in die Führung von Projekten und Programmen ein, da diese häufig eine Reporting-Verantwortung gegenüber dem Portfoliomanagement haben.

• Projekt/ Programm
  • Innerhalb von Projekten und Programmen wird der Erfolg vor allem an der Erfüllung der Produkt- und Projektqualität gemessen, ob zeitliche Beschränkungen sowie das Budget eingehalten wurden und in welchem Umfang die Anforderungen erfüllt wurden, die an das Projekt/ Programm gestellt worden waren.
• Portfolio
  • Im Rahmen von Projektportfolios wird der Erfolg jedoch über den Investitionserfolg gemessen sowie über die Gewinnrealisierung entlang des Portfolios. Finanzwirtschaftliche Kenngrößen stehen hierbei im Vordergrund.

• Projekt/ Programm
  • Im Projekt- sowie Programmmanagement übernimmt das Controlling klassische Aufgaben. Es soll sichergestellt werden, dass das Projekt oder das Programm ein Erfolg wird, dass es die Anforderungen erfüllt und dass Terminpläne und das Budget eingehalten werden. Programme legen dabei den Fokus auf eine projektübergreifende Kontrolle bezüglich der Terminpläne, des Budgets und der Ziele des Projektprogramms.
• Portfolio
  • Im Rahmen des Portfoliomanagements muss vor allem der Einfluss strategischer Veränderungen überprüft werden. Ressourcenallokation entlang des Portfolios, Risiken sowie die Leistungsergebnisse der einzelnen Projekte und Programme müssen dabei ständig überwacht werden.

• Ziel
  • Projektergebnis (Output)
• Zweck
  • "Weg zum Nutzen"
• Nutzen
  • Immer geschäftlich - Monetärer Mehrwert

• Kontaktliste
• Logbuch
• Kaufmännische Dokumentation
• Lieferanten
• Technische Dokumentation
• PM Dokumentation

Organisationsentwicklung ist ein geplanter, systematischer und langfristiger Prozess der Veränderung und Weiterentwicklung eines Unternehmens (einer Organisation) unter größtmöglicher Beteiligung aller Betroffenen. Die Themen der OE umfassen unter anderem Strategieentwicklung, Change-Management (das planvolle Management von Veränderungsprozessen) sowie gezielte Kulturveränderung.
Durch den Prozess der Organisationsentwicklung soll das Unternehmen insgesamt effizienter und erfolgreicher werden.

• IST Aufnahme
• SOLL Konzept
• Prof of Concept
• Einrichtung /Konfiguration
• Rollout
• Funktionstest
• Dokumentationserstellung
• Abnahme

• Auswahl der Produkte und Aktivitäten, die im konkreten Projekt benötigt werden, und das Weglassen von Aspekten, die nicht benötigt werden
• Kein "one size fits all"

• Ist der Stakeholder ein Entscheider? Ist die Person jemand, der nein sagen kann, wenn alle andren ja sagen?
• Immer im Lenkungsausschuss:
  • Geschäftsführer / IT-Leiter der Auftraggeberorganisation
• Muss der Betriebsratvorsitzende in den Lenkungsausschuss?
  • Nein, besser restriktiv behandeln
• Sollte ein Vertreter der Key-User Group in den Lenkungsausschuss?
  • Ideal: ja | in der Praxis eher selten

• Erwartungen (z.B. an funktionale Anforderungen)
• Wirtschaftlichkeit

• Trennen von Sach- und die Beziehungsebene
  • So kommt es im Konfliktfall oft dazu, dass die Beteiligten ihre Emotionen mit der objektiven Sachlage des Problems vermischen. Deswegen sollten Führungskräfte zuerst die menschliche Situation ansprechen, bevor es um die Klärung der Sachlage geht.
• Konzentration auf Interessen
  • Interessen beider Parteien müssen herausgearbeitet werden. Ganz gleich, ob es sich dabei um Wünsche, Motive, Ängste oder Bedenken handelt – Menschen offenbaren diese selten und bestehen lieber auf die eigene Position. Zur Konfliktlösung ist es wichtig, dass mit Mitarbeitern über deren Beweggründe gesprochen und gemeinsam konstruktiv auf die jeweiligen Interessen eingegangen wird.
• Entwicklung von Optionen
  • Bereits im Vorfeld zum konfliktlösenden Gespräch nach Möglichkeiten suchen, die beider Parteien einen gegenseitigen Nutzen bieten. Also Ideen entwickeln, die die Interessen aller Beteiligten befriedigen. Auf der Grundlage kann dann im gemeinsamen Gespräch eine optimale Lösung erzielt werden. Hilfreich ist es auch, durch eine gute Vorbereitung mit Entscheidungsalternativen aufwarten zu können.
• Anwendung neutraler Bewertungskriterien
  • Lösung eines Konfliktes müssen mit fairen Maßstäben bestimmt werden. Deswegen legt das Harvard-Konzept viel Wert auf neutrale und objektive Bewertungskriterien. Das können beispielsweise gesetzliche Richtlinien aus dem Arbeits- oder Steuerrecht sein, das interne Unternehmensleitbild, ein Jahreszielplan oder eine Expertenmeinung.

• Entscheiden
• Managen
• Liefern

• Aufbauorganisation
  • Legt die Rahmenbedingungen fest
    • Welche Aufgaben werden von welchen Personen und/oder Sachmitteln übernommen
    • Mit welchen Rechten werden Personen ausgestattet
• Ablauforganisation
  • Regelt die innerhalb dieses Rahmens ablaufenden Arbeits- und Informationsprozesse

• Der Umsatz von projektorientierten Unternehmen kann sehr starken Schwankungen unterliegen. Extrembeispiel hierfür sind die Werften.
• Es gibt keine vorgezeichneten Karrierewege für die Angestellten
• Unternehmensabteilungen oder Business Units werden zu Ressourcenpools oder internen Dienstleistern.
• Die Unternehmen sind entweder sehr klein oder sehr groß mit weitgehend selbstständig arbeitenden Organisationseinheiten. Zusammenarbeit findet projektbezogen statt.

Ein Project Management Office hilft, den Überblick über die gesamte Projektlandschaft zu bewahren. Es betreibt also Multiprojektmanagement. Das PMO ordnet Informationen über alle Projekte, Programme und Portfolios eines Unternehmens. Somit können Unternehmensprozesse besser bewertet werden.

• Projektportfoliomanagement: Projekte werden nach ihrem Nutzen für das Unternehmen bewertet. Es werden nur Projekte gestartet, die auch bewältigt werden können.
• Multiprojektmanagement: Das PMO bringt Transparenz in den Status der laufenden Projekte. Das erleichtert dem Management, Entscheidungen zu treffen.
• Entwicklung und Implementierung von Methoden und Prozessen: Eine Standardisierung der Methoden und Prozesse in den Projekten eines Unternehmens beschleunigt die Kommunikation, erleichtert die Strukturierung und ermöglicht einheitliche Statusberichte.
• Etablierung und Durchführung eines Ressourcenmanagements: Das PMO macht die verfügbaren Ressourcen transparent. Das erleichtert die Steuerung und Optimierung.
• Anforderungsmanagement: Das PMO sorgt dafür, dass die Anforderungen vollständig und verständlich formuliert und dokumentiert werden. Auch die Priorisierung von Projekten wird vom PMO zur Entscheidung in einem entsprechenden Gremium vorbereitet.
• Professionalisierung des Projektgeschäfts: Das PMO sorgt dafür, dass in allen Projekten ein einheitliches „Lessons-Learned“ durchgeführt wird und die gewonnenen Erkenntnisse in zukünftige Projekte einfließen. Strukturelle Probleme können somit in Zukunft vermieden werden.

• Im Gegensatz zum Project Management Office arbeitet eine Projektassistenz bzw. ein Project Office (PO) genau einem einzigen Projekt zu. Die Projektassistenz ist eng an den Projektmanager angebunden und soll diesen direkt entlasten.
• Nach Abschluss des Projekts wird das Project Office wieder aufgelöst. Der zuständige Projektassistent wendet sich neuen Projekten zu.
• Die Projektassistenz entlastet Projektmanager in operativen und administrativen Aufgaben. Diese können sich somit auf ihre Kernaufgaben Management, Mitarbeiterführung und Problemlösung konzentrieren.
• Ein Projektassistent hilft also beim Aufbau und der Durchführung des operativen Projektmanagements. Er verfolgt Statusreports und übernimmt Teile des Projektcontrollings.
• Das Projektbüro verwaltet die Projektkommunikation und organisiert Meetings und Workshops. Das Projektbüro kann außerdem Projektunterlagen erstellen und diese an die Projektmitarbeiter verteilen.
• Ein Projektassistent beschränkt sich jedoch nicht auf die Planung und Vorbereitung von Meetings: Sofern dies vom Projektmanagement gewünscht wird, kann ein erfahrener Projektassistent diese auch eigenständig durchführen. Das ermöglicht der Projektleitung, sich auf das Wesentliche zu konzentrieren.