Professionelles Projektmanagement in der Praxis Veranstaltung 2 – Teil 1 (04.05.2009): Projektinitialisierung SS 2009 V2-Programm auf Overhead-Projektor Tafel: Der Mensch behält 10% von dem, was er hört 20 % von dem, was er sieht 50 % von dem, was er hört und sieht 90 % von dem, was er selbst ausführt KONSEQUENZ: Learning by doing

Agenda Organisatorisches Vortrag „Business-Plan“ (Hr. M. Wolf) Vortrag: PM-Stellenangebote (Team 1) Projekt-Initialisierung Von der Idee zum Projektauftrag: Zielsetzung, Umfeldanalyse, Wirtschaftlichkeitsbetrachtung, Projektantrag/-auftrag, Stakeholdermanagement, Kickoff Ideen für „Innovative Unternehmen“ (Aufgabe 1; alle PLs) Arbeitstechniken II Analyse, Problemlösung, Entscheidungen, Zeitplanung, Präsentation Aufgabe 2: Projektantrag mit Business-Plan erstellen

Termine 2009 (Stand: 04.05.2009) Projektdokumentation MS 1: MS 2: V2 Aufgabe 1 V3 2 V4 3 V5 4 V6 5 MS 1: Abnahme „Planung und Aufgaben- Verteilung“ MS 2: Prototyp Abschluss- Präsentation 04.05. 11.5. 25.5. 8.6 22.6. 13.7. 18.5. 15.6. V1 20.04. V7 Abgabe Projekt- Doku 6.7. Projektdokumentation Vorträge können auch auf Englisch gehalten werden x: Präsentation PL V: Vortrag aktuelles PM-Thema AP: Abschluss-Präsentation

Organisatorisches Feedback zur Aufgabe 1 Insgesamt recht originelle Ideen Dateien immer an Dozenten und Assistenten schicken! Bitte angegebenen Dateinamens-Konventionen beachten! Bitte im Betreff der Mail immer die Team-Nummer angeben

Vortrag „Business Plan“ Referent: Herr Markus Wolf (Netzwerk Nordbayern)

Kein Projekt ohne Businessplan

Eigenbewertung, Teambewertung und Videoanalyse zur Steigerung der Präsentationskompetenz Eigenbewertung (direkt im Anschluß an den Vortrag) Persönlicher Auftritt Blickkontakt Verständlichkeit des Vortrags Lesbarkeit der Folien Stimme Gesamteindruck Eigen- Bewertung Bewertung durch das Projektteam (direkt im Anschluß an den Vortrag) Möglichst zeitnah Angemessen Offen Korrekt und wahr Brauchbar; keine Pauschalaussagen Team- Bewertung 1. Ab sofort soll nach jedem Vortrag vom Vortragenden eine Selbstbewertung durchgeführt werden. Sehen Sie die Bewertung als ideale Chance, besser zu werden. Nur wenn Sie selbst erkennen, was Sie besser machen können und/oder wenn Sie von anderen entsprechendes Feedback bekommen, haben Sie die Chance besser zu werden. 2. Darüber hinaus soll ergänzend durch das jeweilige Projektteam eine Fremdbewertung durchgeführt werden. Kriterien: .... 3. Videoanalyse direkt nach der Vorlesung 4. Die Bewertungen verbleiben bei den Referenten. Videoanalyse aufgenommener Vorträge im Video Lab (A205) – direkt nach der Vorlesung (ab ca. 17:00 Uhr)

Stellenangebote „Projektmanagement“ Analyse von Stellenausschreibungen Arbeitsmaterial 4 SZ-WE-Ausgaben von 2009 Internet (z.B. Jobpilot.de, WueWoWas.de, JobScout24.de) Andreas Gutjahr: IT-Jobscout 2009 - Projektmanager profitieren von der Krise. Presseinformation vom 24.03.2003, PPI AG, Hamburg Ergebnisse der Vorjahre; Vortrag vom SS08 Vortragsinhalte Projektmanagement-Stellen (SZ) Gesamtzahl PM-Stellen / Stellen Gesamtzahl PM-Stellen mit PM-Zertifikatsanforderungen (GPM-IPMA oder PMI) Verteilung der PM-Stellen auf die verschiedenen Branchen PM-Stellenbezeichnungen, PM-Aufgaben, Skills Sonstige Stellen mit PM-Anforderungen (SZ) Anzahl der Stellen, für die Projektmanagement-Skills gefordert sind, ... PM-Stellen im Internet IT-Jobscout 2009: Wichtigeste Aussagen für Projektmanager Termin: 04.05.2009

Wie kommt man zu einem Projekt? Welche Vorarbeiten sind zu leisten? Workshopteil Welche Anlässe gibt es für Projekte? neuer Auftrag neue Ideen gewinnbringende Innovationen Gesetzesänderungen Umstellung der Infrastruktur aktuelle Anlässe, Wettbewerber Welche Arbeiten sind im Rahmen der Initialisierungsphase durchzuführen? Team zusammenstellen Informationen/Wissen sammeln Machbarkeit überprüfen Zielsetzung Rechtslage prüfen Marktanalyse

Hauptaufgaben der Projekt-Initialisierungsphase Projekt- auftrag ... ... Projektidee Festlegung des Projektziels Projektumfeld- und Stakeholder-Analyse Business Case und Wirtschaftlichkeitsbetrachtung Einrichtung der Projektorganisation: Auftrageber, Projektleiter, Projektmitarbeiter, Lenkungsausschuss Projektantrag a Projektauftrag a Kickoff Kritische Erfolgsfaktoren (Praxistipps) Praxis-Beispiele Ziel der Projektinitialisierung: Eindeutiger Projektauftrag Eine sorgfältige Projektinitialisierung ist von überragender Bedeutung für den Projekterfolg Wenn Sie bei der Diplomarbeit bereits nach wenigen Tagen feststellen: Ich habe das falsche Thema gewählt oder die Zeit reicht nicht zur Bewältigung der gestellten Themas, so haben Sie in der Initialisierungsphase etwas falsch gemacht. Änderungen, die durch eine mangelhafte Projektdefinition bedingt sind, werden umso aufwändiger, je später sie entdeckt und im Projekt durchgeführt werden. (vgl. Fehler bei der Programmierung; Design-Fehler -> Codierungsfehler; Fehler im Test entdeckt –> Fehler im praktischen Einsatz) Wird ein Projekt schlecht oder falsch gestartet, so leiden alle Betroffenen darunter, und zwar vom Anfang bis zum Projektende: „Sage mir, wie ein Projekt beginnt und ich sage dir, wie es endet.“ Zum Glück weiß man heute, wie ein guter Projektstart gestaltet werden muß und welche potentiellen Fehler dabei zu vermeiden sind. Sogar im Bereich des “Extreme Programming“ und der „agilen Vorgehensweise“ gibt es Ansätze, den Start zu optimieren, z.B. durch Ansätze wie „Planning Game“ oder „inkrementelle Planung“. DIN 69905: Das Projektziel ist die Gesamtheit der Einzelziele, die durch das Projekt erreicht werden sollen.

Anlässe für ein Projekt Idee oder Verbesserungsvorschlag, z.B. aus Betrieblichem Vorschlagswesen (BVW) Anfrage / Auftrag eines Kunden Konsequenz eines anderen Projektes Reaktion auf Marktentwicklung Maßnahme zur Erreichung eines definierten Unternehmensziels (aktives Projektportfolio-Management) Gesetzliche Änderungen Nutzung technischer Neuerungen Prüfberichte (z.B. Wirtschaftsprüfer, Revisor, Datenschutzbeauftragter) Kostensenkungsprogramm Unternehmenskrise Firmenfusion Was kann der Auslöser/der Anlass für ein Projekt sein? (Bedarf, Zwänge, Wünsche, Ideen) In dieser frühen Phase finden bereits erste Gespräche über Sinn und Nutzen statt. Auch erste Kontakte zu den Entscheidungsträgern und den wichtigsten Personen, die für die Projektdurchführung denkbar sind, kommen zustande.

Von der Idee zum Kickoff Projektantrag Priorisierungs- gremium Projektauftrag Kick off zur Ent- scheidung Geneh- migung Idee Projektziel Vorarbeiten und Analysen Problem Kundenauftrag Neue Geschäftsidee Idee/Vision/Kundenanforderung Verschiedene Quellen: Betriebliches Vorschlagswesen Unternehmensplanung Planungen der Fachabteilungen -> Projektantrag Wird von der zuständigen Fachabteilung erstellt und beim Projektbüro eingereicht -> Priorisierungsgremium Projektantrag entscheidet über die Umsetzung des Projektantrags. Nach Genehmigung des Projektantrags wird vom zukünftigen Projektleiter ein -> Projektauftrag erstellt. Betriebliches Vorschlagswesen

Projektzielklärung ist unabdingbar Todsünde im PM: „Unklares oder unzureichend definiertes Projektziel“ Projekt- Krise Unklarer Projekt-auftrag früher oder später „Machen Sie mal!“ „So habe ich mir das aber nicht vorgestellt“ Projektleiter ist verantwortlich für die genaue Zielklärung: „Was wollen wir mit dem Projekt erreichen?“ Klare Zielsetzung und Auftragsklärung: ein zentrales Erfolgskriterium im Projekt Die exakte Definition des Ziels am Beginn eines Projektes ist ein entscheidender Erfolgfaktor für das Gelingen des Projektes Ideal: Für jeden Mitarbeiter gibt es mindestens ein individuelles (abgeleitetes) Ziel, zu dem er sich „bekennt“

Ergebnisziele / Lieferobjekte (Funktionalitäten, Qualität) Zielkategorien „Harte“ Ziele Ergebnisziele / Lieferobjekte (Funktionalitäten, Qualität) Terminziele Kostenziele „Weiche“ Ziele (Project Excellence Modell (GPM)) Zufriedenheit der Kunden Zufriedenheit der Projektmitarbeiter Zufriedenheit der sonstigen Stakeholder (Lieferanten, Umwelt, ...) Kostenziele: Einhaltung des Budgets Erstellungskosten für das zu entwickelnde Produkt (Bsp: Swatch-Target-Costs: 40 US$) Muss-Ziele (Pflicht): Ziele, die unbedingt erreicht werden müssen (z.B. Gesetze, Sicherheitsvorschriften, Normen) Kann-Ziele (Kür): Zielerreichung stellt keine unabdingbare Voraussetzung für den Projekterfolg dar

Ziele müssen SMART vereinbart werden S = Spezifisch Was soll genau erreicht werden? Das „S“ wird vielfach als auch synonym für „schriftlich fixiert und präzisiert“ verwendet. Ziele sind immer positiv zu formulieren M = Messbar Welches sind die Messkriterien? An welchem Zielmaßstab soll die Zielerreichung gemessen und kontrolliert werden? A = Attraktiv oder aktiv beeinflussbar Ist das Ziel anspruchsvoll und herausfordernd? Oftmals wird das „A“ auch gleichgesetzt mit „akzeptabel“ oder „aktiv beeinflussbar“. Das bedeutet, dass der Projektleiter, mit dem das Ziel ja vereinbart wird, auch in der Lage sein muss, die Zielerreichung mit den ihm zur Verfügung stehenden Mitteln aktiv zu beeinflussen. R = Realisierbar oder realistisch erreichbar Ist das gesteckte Ziel unter Berücksichtigung der gegebenen Umstände und der vorhandenen Ressourcen erreichbar? T = Terminiert Ist eine Frist gesetzt, innerhalb der das genannte Ziel erreicht werden soll? Ggf. bietet sich die ergänzende Vereinbarung von terminierten Zwischenzielen an. Schon zu Beginn eines Projektes ist es wichtig, ein klares Verständnis zu entwickeln, was das Projekt erreichen soll. So können Missverständnisse und Mehraufwände frühzeitig verhindert werden. Ggf. ist eine strukturierte Darstellung (Zielhierarchie) oder vorgegebene Form (Lastenheft) hilfreich.

Ziele müssen messbar sein bzw. gemacht werden Ziele müssen quantitativ messbar sein, damit am Ende des Projektes eine objektive Überprüfung stattfinden kann, ob das Projekt „erfolgreich“ war Vorgehen: Relevante Zielgrößen (Kennzahlen) ermitteln und festlegen Zahlen oder zumindest Größenordnungen, Zahlenintervalle, Minimal- oder Maximalwerte hierfür vereinbaren Falsche Zieldefinition Richtige Zieldefinition Die Rationalisierung der Büro-Organisation ist abgeschlossen Durch die neue Büro-Organisation werden 4.000 €/Monat eingespart Die Anwender sind mit dem neuen Programm zufrieden Die Anwender haben das Programm in einer Zufriedenheitsumfrage mindestens mit der Note „gut“ bewertet Die Fehlerhäufigkeit wird deutlich verringert Die Fehlerhäufigkeit wird von 42 Stk./ Monat auf 28 Stk./Monat verringert Die Durchlaufzeit wird erheblich verkürzt Die Durchlaufzeit wird von bisher 6 Tagen auf zukünftig 4 Tage verkürzt Ziele messbar machen heißt, aus schwammigen Zielen konkrete Ziele machen. Operationalisierung / Konkretisierung der Projektziele

Ziele messbar machen! Schwammige Ziele Messbare Ziele Workshopteil Man soll leicht an Informationen kommen Das Unternehmen soll Profit machen Website schneller machen Mehr Leistung eines technischen Gerätes Einfachere Bedienung Das neue Unternehmen soll Zeit sparen Viele Nutzer Messbare Ziele Durchschnittliche Anzahl der Klicks <= 5, um auf die gewünschte Information zu kommen Das Unternehmen soll im ersten Geschäftsjahr einen Gewinn von €100.000 erzielen Max. Wartezeit eines ISDN-Nutzers soll nicht mehr als 200ms betragen Nach Stiftung Warentest Verbesserung der Note auf 2,0 ... Workshop: Erstellen Sie eine messbare Zieldefinition für Ihr Projekt. Zunächst als schwammiges, dann als messbares Ziel: Erfassung durch Assistenten am Laptop Beispiel: Internet-Auftritt: Falsch: Die Website wird häufig aufgerufen Richtig: Die Website wird laut Statistik pro Monat von mindestens 1.000 unterschiedlichen Nutzern für mehr als 10 Minuten aufgerufen. Gretchenfragen: Woran kann man den Erfolg Ihres Projektes messen? An welchen messbaren Größen können Sie feststellen, ob Sie ihr Projektziel erreicht haben? Wann hat sich das Projekt gelohnt?

Zielhierarchie gibt einen Gesamtüberblick der Ziele Verbesserung der Transportverhältnisse in der Innenstadt Globalziel Zeitziele Finanz- und Kostenziele Funktionsziele Soziale Ziele Zielklassen Zielunter- klassen Termine Kosten Transport- leistung Komfort Lärm- reduktion Operationale Zielformulierung Projektstart und -ende Betriebs- kosten pro Std. Projekt- kosten Personen pro Stunde Sitz-/ Stehplatz- verhältnis Projektziele werden häufig als Zielhierarchie gegliedert. Ausgehend vom Hauptziel werden in weiteren Ebenen nach der Top-Down-Methode die Teilziele für den Projektgegenstand und für den Projektablauf definiert. Basis für die Zielhierarchie des Projektgegenstandes ist der Projektstrukturplan. Für jedes einzelne Element des Projektstrukturplanes können die Ziele individuell festgelegt werden. Gefordertes Maß der Ziel- erreichung Meilenstein- termine < x € pro Stunde < y Mio. € mind. x Personen pro Stunde max. 1:2 im Berufs- verkehr Quelle: ProjektManager, S. 144

Zielkonflikte feststellen und Zielpriorisierung vornehmen Konkurrenz-Beziehung von Zielen Die zunehmende Erfüllung eines Zieles kann nur durch Abstriche bei einem anderen Ziel erreicht werden ITSM-Zielkonflikt (Beispiel) Qualität des IT-Services ständig verbessern Reduktion der Kosten Häufiger Zielkonflikt bei Softwareprojekten Schnelle Produktfertigstellung Hohe Produktqualität Häufige Konsequenz: Reduktion der Testzeit a Schlechtere Produktqualität und zusätzliche Kosten für Nachbesserungen Lösung: Zielpriorisierung vornehmen Beispiele: „Qualität vor Zeit“, „Time-to-market“, „Design-to-Cost“-Ansatz

Mit Nicht-Zielen den Projektumfang abgrenzen Zur Abgrenzung des Projektumfangs müssen auch die „Nicht-Ziele“ gelegt werden „Nicht-Ziele“: Was NICHT Bestandteil des Projektes ist Abgrenzung erhöht die Entscheidungssicherheit für alle Beteiligten: schafft Klarheit und vermeidet unnötige Konflikte (aufgrund unausgesprochener Erwartungen) Beispiel Ziel: Die zu entwickelnden Module sollen wiederverwendbar sein Nicht-Ziel: Die wiederverwendbaren Module werden NICHT weiterentwickelt und auch NICHT gepflegt

Praxisbeispiel: Ziele im Projekt NIMBUS Folie 4 des Projektantrags Zielabgrenzung Folie 5 des Projektantrags

Leistungsziel-Beschreibungen: Lasten- und Pflichtenheft Anforderungen des Auftraggebers Vom Auftragnehmer abgeleitete Leistungsziele Lastenheft Gesamtheit der Anforderungen des Auftraggebers (AG) an die Lieferungen und Leistungen des Auftragnehmers (AN) Pflichtenheft enthält die vom Auftragnehmer (AN) erarbeiteten Reali- sierungsvorgaben zur Umsetzung des Lastenheftes Das Modell Auftraggeber / Auftragnehmer hat sich in der Praxis als sehr erfolgreiches Grundprinzip durchgesetzt. Die Anforderungen des Kunden an das Projekt und die detaillierte Darstellung der daraus abgeleiteten Leistungsziele müssen schriftlich festgehalten werden. Dazu dienen Lastenheft und Pflichtenheft. Auftraggeber und Lieferant können unterschiedlichen Firmen angehören, müssen aber nicht. Auftraggeber (i.a. auch Geld- geber des Projektes) spezifiziert das benötigte Ergebnis Auftragnehmer (= Lieferant) stellt das benötigte Ergebnis her

Der Prozess vom Lastenheft zum Vertrag mit Pflichtenheft Auftraggeber Auftragnehmer Lastenheft Forderungen aus Auftraggebersicht Forderungen werden in Spezifikationen umgesetzt Angebot mit Pflichtenheft Spezifikation der Realisierung Prüfung und Genehmigung der Spezifikationen Die Anforderungen des Kunden an das Projekt und die detaillierte Darstellung der daraus abgeleiteten Leistungsziele müssen schriftlich festgehalten werden. Dazu dienen Lastenheft und Pflichtenheft Vertrag mit Pflichtenheft (genehmigt) Spezifikation der Realisierung Projektvorgaben

Muster-Gliederung: Pflichtenheft für SW-Entwicklung* Zusammenfassung Problembeschreibung Kurzbeschreibung der Leitungsmerkmale Technische Anforderungsanalyse Projektanforderungsanalyse Lösungsalternativen und Aufwände Requirement-Katalog Erster Systementwurf Gesamtsystem Funktionsgruppen Schnittstellen zu Benutzern Schnittstellen zu anderen Personengruppen Lösungsalternativen und Aufwände Abnahmebedingungen Softwaresystem Bibliotheksinhalte Rapid Prototype (bei Bedarf) Randbedingungen Wie sieht so ein Pflichtenheft aus? Muster-Gliederung *) Quelle: ProjektManager, Seite 147

Das Projektumfeld beeinflusst das Projekt und wird seinerseits vom Projekt beeinflusst Markt Gesetzgeber Betroffene Abteilungen Anwender Geschäfts- führung Auftrag- geber Projekt- team Andere Projekte Internes Umfeld Partner Kunden Projekt Politik Umwelt Projekte sind keine einsame Inseln, sondern immer in ein Umfeld (eine Umwelt) eingebettet. Diese Umfeld beeinflusst die Arbeit im Projekt gewaltig und hat nachhaltigen Einfluss auf den Projekterfolg. Ziel der Projektumfeldanalyse ist, alle möglichen Einflüsse auf das Projektfrühzeitig zu identifizieren und ihre Auswirkungen auf die Zielerreichung zu analysieren. Das Projektumfeld ist die Umgebung, in der das Projekt entsteht und durchgeführt wird und die das Projekt beeinflusst und/oder von dessen Auswirkungen betroffen ist. Wird das Projektumfeld von Anfang an in die Projektarbeiten einbezogen, so können potentielle Störungen im Vorfeld erkannt und proaktiv verhindert werden. Lieferanten Wettbewerber externes Umfeld Umfeldanalyse: Identifikation und Analyse der wichtigsten Einflussbereiche auf das Projekt

Generelle Projektumfeld-Elemente Unternehmen Kunde Gesellschaft Technik Markt Firmenleitung Auftraggeber Betroffener Technische Entwicklung Arbeitsmarkt Geldgeber Arbeitspartner Meinungs-beeinflusser Produktions-faktoren Absatzmarkt Führung Nutzer Interessens-vertreter Umwelt Lieferant Mitarbeiter Kommunikation Behörde Ressourcen Kapitalmarkt Organisation Politik Rahmen-bedingungen Wettbewerb Kultur Recht, Gesetze andere Projekte Ethik/Moral Mit Hilfe der Umfeldanalyse sollen die möglichen Einflüsse auf das Projekt festgestellt werden. Umfeldgruppen Markt und Wettbewerb Technik und Umwelt Gesellschaft, Gesetze, Normen und Vorschriften Stakeholder Quelle: N. Hillebrand: Projektumfeldanalyse effizient gemacht, PROJEKTMANAGEMENT 2/2000, S. 26-31

Schritte einer Umfeldanalyse Identifikation und Beschreibung der Umfeldelemente Analyse der Einflüsse der Umfeldelemente und Bewertung der Wirkungsstärke auf das Projekt (Kraftfeldanalyse) a Rangskala möglicher Einflüsse: hoher, mittlerer, geringer, kein Einfluss Entwicklung von Maßnahmen für die stärksten Einflüsse Fördermaßnahmen für die Chancen Abwehrmaßnahmen für die Risiken Kontrolle der Wirksamkeit der getroffenen Maßnahmen Typische Nicht-Stakeholdereinflüsse: Währungsveränderungen, technischer Fortschritt Die wichtigsten Umfeldelemente sind in der Regel die Stakeholder des Projektes Stakeholderanalyse Stakeholdermanagement

Stakeholdermanagement Ziel: Potentielle Widerstände geistig vorwegnehmen a Akzeptanz erreichen Stakeholder: Person oder Personengruppe, die aktiv am Projekt beteiligt am Projekt interessiert das Projektergebnis beeinflussen kann vom Projektergebnis betroffen ist (vgl. PMBoK, ProjektManager) Stake: Anspruch, Interesse, Erwartung oder Forderung Stakeholdermanagement Ermittlung der Anforderungen und Erwartungen der Stakeholder Berücksichtigung dieser Anforderungen bei der Projektplanung und -durchführung Entwicklung von Strategien und Maßnahmen Aktive und proaktive Betreuung der Projektstakeholder, insbesondere der einflussstarken Entscheider Im Rahmen der Umfeldanalyse spielt erfahrungsgemäß die Analyse der Stakeholder eine herausragende Rolle. Projekte scheitern grundsätzlich nicht an der Technik sondern sehr häufig an menschlichen Problemen. Der Widerstand der Menschen im Projektumfeld hat schon so manches Projekt zum Scheitern gebracht. Dabei spielen die sog. „soft skills“ eine besondere Bedeutung. Das Stakeholdermanagement ist in den letzten Jahren zu einem wichtigen Element der Projektarbeit geworden. Unter dem Begriff „Stakeholder“ versteht man die Personen oder Personengruppen, die am Projekt beteiligt, am Projektablauf interessiert oder von den Auswirkungen des Projekts betroffen sind. Ein „stake“ ist ein Anspruch, ein Interesse, eine Erwartung oder eine Forderung. Achtung: Stakeholder haben unterschiedliche Interessen! Projektleiter versucht, diese möglichst „unter einen Hut zu bringen“ und damit den Wert des Projektes zu steigern. Aber nicht immer lassen sich die verschiedenen Interessen miteinander vereinbaren (-> Zielkonflikte).

Stakeholderanalyse: Basis des Stakeholdermanagements Identifikation der Stakeholder des Projektes Welche Prozesse werden wesentlich verändert? Wer ist durch das Projekt betroffen oder am Projekt beteiligt? Übersicht Projekt- beteiligte/ -betroffene Konsequenzen für das Projekt Analyse der Stakeholder Interesse an den Projektergebnissen Ängste / Erwartungen Betroffenheit durch das Projekt Einfluss/Macht auf das Projekt Stakeholder- matrix Eine frühzeitige und gründliche Stakeholderanalyse stellt die Basis des Stakeholdermanagements dar. Diese Stakeholderanalyse erfolgt i.w. in drei Schritten: Identifikation Analyse Maßnahmenplan Stakeholdermanagement ist in hohem Maße ein gelungenes Kommunikations- und Beziehungsmanagement. Ableitung von Maßnahmen 1. Beteiligung im Projekt (Partizipation) 2. Kommunikationskonzept

Stakeholder-Matrix schafft einen Gesamtüberblick synonym: Interessenmatrix Tipps: Setzen Sie sich frühzeitig mit den potentiellen Widerständen proaktiv auseinander! Konzentrieren Sie sich auf die priorisierten Stakeholder (Key-Stakeholder) mit hoher Macht/Einfluss auf das Projekt und hohem Interesse/Betroffenheit!

Visualisierung durch Stakeholder-Portfolio hohe Unterstützung Auftrag- geber Vorstand Anwender geringer Einfluss hoher Einfluss IT- Abt. Betriebs- rat Die Analyse der Stakeholder erfolgt in drei Schritten: Betroffenheit durch das Projekt / Interesse am Projekt: Was ändert sich für den Stakeholder durch das Projekt? Macht / Einfluss: Wie groß ist der direkte/indirekte Einfluss auf das Projekt? Reaktion: Mit welchen Reaktionen (positiv/negativ/neutral) ist zu rechnen? Ist mit Ablehnung/Widerständen zu rechnen? Oben rechts sind die sog. „Key Stakeholder“ (Hauptanspruchsgruppen) des Projektes. Orga- Abt. starke Widerstände

Ableitung von Maßnahmen für die priorisierten Stakeholder Maßnahmen zur Verringerung der Widerstände (Ängste) Pro-kontra-Argumente herausarbeiten „Botschaften“ für Zielgruppen erarbeiten Vertrauensbasis schaffen ehrliche und klare Kommunikation evtl. Partizipation in der Projektarbeit - Maßnahmen zur Stärkung der Förderung lückenlose Information der Förderer persönlichen Draht aufbauen Einbeziehung von Meinungsbildnern und Multiplikatoren + Zweckmäßig ist eine „klare Botschaft für alle“, die überzeugend die Notwendigkeit des Projektes vermittelt. Diese Kernbotschaft wird zielgruppenspezifisch ergänzt durch Informationen, die auf die Interessen der einzelnen Gruppen/Personen und die Auswirkungen des Projektes auf diesen Personenkreis eingehen.

Stakeholdermanagement: Überwachung und Steuerung Stakeholderanalyse ist eine projektinterne Analyse Sie geht nicht nach außen! Stakeholderanalyse ist eine Momentaufnahme Sie muss daher in sinnvollen Abständen wiederholt werden (häufig in Verbindung mit Risikomanagement) Prozess Gibt es neue Stakeholder? Haben sich bisherige Stakeholderpositionen wesentlich verändert? Waren die durchgeführten Maßnahmen erfolgreich? Welche neuen Maßnahmen sind zu veranlassen? Stakeholdermanagement dient auch zur Risikoerkennung- und minimierung. Unterschied: SM – RM: Einstellung von Personen sind im Gegensatz zu den Risiken kaum quantifizierbar.

Praxisbeispiel Stakeholderanalyse im Projekt NIMBUS Mit Stakeholdermanagement die Ängste, Bedürfnisse und Wünsche proaktiv angegangen

Praxisbeispiel Beteiligungslösungen Kommunikationsplan Kommunikation vor Projektstart Beteiligungslösungen Anwendervertreter im LA und im Kernteam Datenschutzbeauftragter im Kernteam GPR-Vertreter im LA Kommunikationsplan Der Erfolg großer Projekte ist nicht nur abhängig von guter fachlicher Arbeit, sondern insbesondere vom richtigen Umgang mit den Anforderungen, Ängsten/Bedenken und Bedürfnissen der Stakeholdern.

Stakeholder eines neuen SW-Produktes Workshopteil Anwender Programmierer Investoren Administratoren Einkauf / IT-Beschaffung Qualitätssicherer Support Marketing / Vertrieb Vorstand des Entwicklers Vorstand des Kunden Das Identifizieren und Dokumentieren der Stakeholder ist kein einmaliger Prozess. Die Stakeholderliste muss immer wieder geprüft und ggf. aktualisiert werden. Werden wichtige Stakeholder vergessen, so verursachen deren Anforderungen im Projektverlauf einen überproportional hohen (Änderungs-)Aufwand. Ergebnisse SS08: Management Entwickler Käufer Anwender(gruppen) Betriebspersonal Controller Personalrat Trainer Sicherheitsbeauftragter Datenschutzbeauftragter Ergonomiebeauftragter Innenrevision Externe Firmen (Hardware, Provider, Basissoftware)

Praxistipp zu Ziele und Stakeholdermanagement Nehmen Sie wichtige Interessen Ihrer Stakeholder in die Zielmenge des Projektes auf! Warum?

Wirtschaftlichkeitsbetrachtung Projekte sind Investitionsvorhaben Es werden grundsätzlich nur solche Projekte durchgeführt, die sich wirtschaftlich rechnen Bei konkurrierenden Projekten werden – aufgrund knapper Ressourcen - die mit der besten Wirtschaftlichkeit priorisiert Wirtschaftlichkeitsbetrachtung Nutzen Quantifizierbarer Nutzen (€) Nicht-quantifizierbarer Nutzen Kosten Reine Projektkosten Investitionskosten Betriebskosten Quantifizierbarer Nutzen: Berechnete Wirtschaftlichkeit der Lösung Nicht-quantifizierbarer Nutzen: Beurteilung nicht direkt quantifizierbarer Effekte (i.s. einer Nutzwertanalyse) Curry-Wurst-Beispiel für Milchmädchenrechnung Lebensdauer realistisch einschätzen Nutzen tritt häufig erst mit zeitlicher Verzögerung ein: Umstellungs-/ Einführungsaufwand, geringere Produktivität/ Mehraufwand in der Startphase u.ä. Einsparungspotentiale müssen auch realisiert werden!

Methoden der Wirtschaftlichkeitsberechnung Finanzmathematische Verfahren Für die Durchführung einer Wirtschaftlichkeitsbetrachtung gibt es heute verschiedene Methoden, die i.w. in 3 Klassen eingeteilt werden können. Eine genaue Darstellung der Methoden sprengt den Rahmen der Vorlesung. Statische Verfahren (der Zeitfaktor bleibt unberücksichtigt) Kostenvergleichsrechnung: Aus mehreren Alternativen wird die kostengünstigste ermittelt; relative Vorteilhaftigkeit einer Lösung gegenüber einer anderen Rentabilitätsrechnung: prüft die Rentabilität einer Investition; Ist das Projekt überhaupt sinnvoll? Ziel: Höchste Rendite Amortisationsrechnung: berechnet die Amortisationsdauer, d.h. den Zeitraum (Break-Even), ab wann die Investition Gewinne abwirft. Es wird i.a. die Lösung mit der kürzesten Amortisationsdauer ausgewählt. Dynamische Verfahren (Finanzmathematische Verfahren): werden relativ selten eingesetzt Kapitalwertmethode (Barwertmethode): wird verwendet, wenn sich die Ein- und Auszahlungen einer Investition im Zeitablauf ändern. Annuitätenmethode Interne Zinsfussmethode: Es wird der Diskontierungszinsfuß gesucht, der zu einem Kapitalwert von Null führt. Bewertungsverfahren Kosten-Nutzen-Analyse: reine monetäre Betrachtung Nutzwertanalyse: Variation der Kosten-Nutzen-Analyse, die die Nutzwerte der einzelnen Funktionen in die Bewertung einbezieht Hauptproblem: Verfügbarkeit zuverlässiger Daten a Genauigkeit nicht übertreiben!

WiBe21*: Software-unterstützte Wirtschaftlichkeitsbetrachtungen Wirtschaftlichkeitsbetrachtungen werden methodisch einheitlich (standardisiert) durchgeführt a Vergleichbarkeit gesichert Ergebnis: begründete, transparente und nachvollziehbare Aussagen zur Wirtschaftlichkeit des Projektes WiBe21*: Methodik: Kapitalwert und Nutzwertanalyse Softwareprodukt, das die Anwendung der Methodik unterstützt *) empfohlen vom Bundesministerium des Innern (BMI) WiBe21: Systematik Entscheidungsbasis Bestandteile der WiBe sind: 1. Kapitalwert (WiBe KN) verrechnet den monetären Nutzen gegen die Aufwände Teilkapitalwert WiBe KN/h: betrachtet nur die haushaltswirksamen Beiträge zum Kapitalwert Teilkapitalwert WiBe KN/n: betrachtet nur die nicht haushaltswirksamen Beiträge zum Kapitalwert. 2. Dringlichkeitswert wird an Hand eines festen Kriterienkataloges ermittelt 3. Qualitativ-strategischer Wert: wird an Hand eines festen Kriterienkataloges ermittelt Anmerkung: Betriebskosten sind synonym zu Projektfolgekosten. Dringlichkeitswert Qualitativ-strategischer Wert Kapitalwert (€) Kennzahlen Genehmigung/Ablehnung des Projektvorschlags

Auf dem Weg zum Projektantrag Projektziele Projektumfeldanalyse mit Interessenmatrix Aufbau der Projekt-Organisation: Leiter, Team, Teilprojekte?, Kernteam?, Lenkungsausschuss Grobplan erstellen Business Case (Nutzen) Aufwände Erforderliche Ressourcen a Projekt-Budget aufstellen Für den Projektantrag sind grobe Angaben zu den wichtigsten Projektgrößen (Ergebnisse, Termine, Kosten) erforderlich Wirtschaftlichkeitsbetrachtung Terminplanung Projektrisiken Qualitätsplanung Kommunikationsplanung Projektantrag

Projektantrag Markanten Projektnamen wählen Projektziel Beginn- und Ende-Termin, Meilensteine Projektorganisation Auftraggeber, Projektleiter, Lenkungsausschuss Liste möglicher Projektmitarbeiter Betroffene Fachabteilungen Wirtschaftlichkeitsbetrachtung Erwarteter Nutzen (quantitativ (€), nicht-quantitativ) Ressourcen/Kosten: Mitarbeiter-Ressourcen, Investitionen, Betriebskosten Potentielle Risiken Mögliche Qualitätsmängel, Zeitverzögerungen, Kostenüberschreitungen Mögliche Gefährdungen des Projektes

Beispiel: IT-Infrastrukturprojekt Praxisbeispiel: Projektantrag NIMBUS (separater Foliensatz)

Projektauftrag Ziele und Inhalte werden zwischen Auftraggeber (z.B. Vorstand oder Verantwortlicher eines Geschäfts-bereichs) und Auftragnehmer (Projektleiter) abgestimmt Projektantrag geht zur Genehmigung an „Priorisierungs-gremium“ Nach Zustimmung zum Projektantrag und Freigabe der Mittel/Ressourcen wird dieser zum Projektauftrag Unterzeichnung durch Auftraggeber und Auftragnehmer (= Projektleiter) Projektauftrag ist die vertragliche Basis des Projektes

Kickoff-Veranstaltung Formaler Projektstart: Erstes Treffen des PL mit dem gesamten Projektteam Hauptziel: Klarheit schaffen Jeder kennt die Projektziele und damit die Kriterien, an denen der Projekterfolg gemessen wird Jeder kennt das geplante Vorgehen mit Zwischenterminen und Meilensteinen Jeder hat das Projekt als Ganzes verstanden Jeder kennt seine Rolle im Projekt Vorstellung / Kennenlernen der Teammitglieder Vorstellung des Projektauftrages und der Projektprozesse Projektziele, -inhalte und –termine Commitment zu den Zielen Rahmenbedingungen Spielregeln der Zusammenarbeit

Praxisbeispiel: NIMBUS-Kickoff (Agenda) 10:00 Begrüßung / Anpfiff (AG) Prämierung des Erfinders des Projektnamens (Hr. E.) 10:15 Projektvorstellung im Überblick (PL) 10:40 Vorstellung der Teilprojekte (alle TPL; jeweils ca. 10 Minuten) 11:50 Diskussion (alle; Anregungen, Erwartungen, Wünsche) 12:00 Mittagspause 13:00 Projekt-Rahmenbedingungen und Spielregeln der Zusammenarbeit (PL) 13:20 Meeting der Teilprojekte (alle; zusätzliche Räumlichkeiten sind reserviert) 15:00 Meeting des Kernteams (Raum 160) 16:30 Ende

Spielregeln der Zusammenarbeit (NIMBUS-Kickoff)