Projekte, die (k)einer will oder Manchmal zu groß, um erfolgreich zu sein

Transkript

1 Projekte, die (k)einer will oder Manchmal zu groß, um erfolgreich zu sein Viele Projekte tragen falsche Namen oder erschweren durch ihre Größe die Steuerbarkeit und damit den Projekterfolg PRINCE2 und MSP sind eingetragene Warenzeichen des Cabinet Office..Reproduktion und Verwendung dieser Unterlagen in jedweder Form ist ohne ausdrückliche, schriftliche Erlaubnis der QRP Management Methods International GmbH nicht gestattet. Sofern Rechte Dritter an Warenzeichen bestehen, werden diese beim erstmaligen Auftreten ausgewiesen.

2 Beispiele aus dem Alltag Kommen Ihnen folgende Situationen bekannt vor? Der Fachbereich arbeitet im Projekt Einführung CRM nur zögerlich mit Dem Projekt Releasewechsel ERP-System werden plötzlich Ressourcen entzogen Das Projekt Einführung Barcode im Lager leidet unter vielen Änderungswünschen Im Projekt Optimierung Geschäftsprozesse werden nur sehr zögerlich Entscheidungen getroffen Der Lenkungsausschuss für das Projekt Einführung ERP-System besteht aus 20 Entscheidern. Dadurch sind Termine für gemeinsame Meetings schwer koordinierbar. Die Lösung zur automatisierten Einbuchung von Aufträgen wird schleppend abgenommen und anschließend nicht verwendet. Projekt A stehen die notwendigen Ressourcen nicht zur Verfügung weil sich Projekt B um 3 Monate verzögert. 2

3 Was ist passiert? Es hapert an der Kommunikation o Mitarbeiter und Entscheider sind nicht über die wirklichen Projektziele und -nutzen im Bilde. o Technische Experten entwickeln das Projekt und hängen die Benutzer ab. Das Projekt ist zu groß Große Projekte mit zahlreichen Teilprojekten leiden häufig unter erschwerter Steuerbarkeit Abhängigkeiten zwischen Projekten sind unklar Isoliertes Management nur der einzelnen Projekte führt ohne Management der Abhängigkeiten zueinander zu Qualitätsdefiziten und Verzögerungen 3

4 Offene Fragen Wie können die Entscheidungsebenen und die Mitarbeiter mit den Projektzielen und dem damit verbundenen Nutzen vertraut gemacht werden? Wie können Entscheidungsprozesse für Projekte beschleunigt und Entscheidungen in Projekten schnell und sicher getroffen werden? Wie kann Akzeptanz aller Betroffenen für die Projektziele geschaffen werden? Wie können Projekte auf managebare Größen skaliert werden? Wie können Ressourcen projektübergreifend gesteuert werden? Wie können projektübergreifende Abhängigkeiten gemanagt werden? 4

5 Tagesgeschäft als Nutzer für Veränderungen Nur mit optimalen Informationen aus dem Tagesgeschäft/Betrieb können zielgerichtet Veränderungsvorhaben beschlossen und durchgeführt werden. Ziel ist, den Veränderungsprozess ins Tagesgeschäft zu bringen, um die zukünftigen Anforderungen des Marktes angemessen bedienen zu können nicht technische Lösungen einzuführen die sind nur Mittel zum Zweck! Jede Veränderung hat idealerweise einen Nutzen für das Tagesgeschäft Die Verantwortung für die Umsetzung der Veränderung liegt beim Tagesgeschäft Bild 1: Veränderungen versus Betrieb. 5

6 führt zu den wirklichen Projektnamen! will keiner Einführung CRM Releasewechsel ERP-System wollen alle Einheitliche und vollständige Kundeninformationen in Vertrieb und Marketing Sicherung Wartungsfähigkeit Einführung Barcode im Lager Senkung Fehlerrate im Versand um 10% Optimierung Geschäftsprozesse Automatisierte Einbuchung Rechnungsdurchlauf innerhalb 36 Stunden Lieferfähigkeit innerhalb 24h Der Fokus auf technische Umsetzungen gefährdet den Blick auf die notwendigen Prozesse und die beteiligten Menschen und vernebelt den angestrebten Nutzen als Treiber des Projekts 6

7 Schaffen von Akzeptanz Klares Kunden-Lieferantenverhältnis führt zu eindeutigen Abnahmekriterien und zu einem definierten Auftrag und damit zu klaren Rollen und Verantwortlichkeiten. Kunden-/Benutzerseite liefert Nutzen und beschreibt messbare Abnahmekriterien, auf die Lieferanten verpflichtet sind Beschreibung des Projektes mit den Worten der späteren Anwender/Nutzer bringt Klarheit bei allen Beteiligten und hilft zu verstehen, warum eine bestimmte Lösungsoption gewählt wurde. Eine gemeinsame Sprache von Kunden und Lieferanten sichert das gemeinsame Verständnis für Art, Umfang, Komplexität und Notwendigkeit der Arbeiten. Im Projektverlauf ist der Nutzen der Veränderung das Ziel, nicht die technische Umsetzung 7

8 Wie Projekte skalieren und Abhängigkeiten managen? Nicht nur die Frage "Machen wir die richtigen Dinge?" sondern auch Machen wir die Dinge richtig? stellen: Größe der Projekte und Arbeitspakete an den Reifegrad von Kunden und Lieferanten anpassen. Steuerbarkeit und Messung des Arbeitsfortschritts über kleinere Einheiten mit konkreten Abnahmen und Teilabnahmen sichern Ermittlung und Management der Abhängigkeiten zwischen den einzelnen Projekten durch speziell ausgebildete Mitarbeiter 8

9 Traditioneller Ansatz Großprojekt ERP Einführung Lenkungsgremium Finanzen Technik Entwicklung Geschäftsführung Vertrieb Marketing Logisitik NL-Leiter: Nord, West, Mitte Hardware- Lieferant Beratungshaus Betriebsrat ERP- Lieferant Ext. Softwareentwicklung IT- Projektleiter Teilprojekt A Teilprojekt B Teilprojekt C Teilprojekt D Teilprojekt Teilprojekt 9

10 Wo sind die Risiken oder: machen wir die richtigen Dinge richtig? Großer Lenkungsausschuss ist gemeinsam kaum verfügbar Probleme in Teilprojekten werden nicht bekannt Teilprojekte bekommen Eigendynamik, da messbare Abnahmekriterien fehlen Abhängigkeiten der Teilprojekte untereinander werden nicht oder mangelhaft gemanagt, da die Komplexität zu groß für den Projektleiter ist Agenda der Meetings des Lenkungsgremiums ist sehr lang Inhalte der Agenda sind nicht für alle Mitglieder des Lenkungsgremiums transparent und interessant Entscheider verlieren das Interesse, da der Nutzen für sie nicht erkennbar ist 10

11 Empfehlung: Durchführung als Programm (MSP) Managing Successful Programmes unterstützt mit seinen Strukturen das leitende Management bei der Entscheidungsfindung. Großprojekte/Programme werden in steuerbare Einheiten gegliedert, in denen jedes Projekt klare Zielvorgaben und Handlungsspielräume sowie messbare Zwischenergebnisse hat. Gleichartige Informationsverdichtung und aufbereitung für die jeweilige Entscheidungsebene über alle Projekte Übergreifendes Management von Ressourcenkonflikten Übergreifendes Management von Abhängigkeiten Autorität und Verantwortung sind in jeder Ebene klar geregelt. 11

12 Optimierter Ansatz Großprojekt ERP Einführung Programm-Ausschuss Finanzen Technik Entwicklung Geschäftsführung Vertrieb Marketing Logisitik NL-Leiter: Nord, West, Mitte Hardware- Lieferant Beratungshaus Betriebsrat ERP- Lieferant Ext. Softwareentwicklung IT- LA LA LA LA LA Projektmanager Projekt A Projektmanager Projekt B Projektmanager Projekt C Projektmanager Projekt D Teilprojekt Projekt Projektmanager 12

13 Optimierter Ansatz Großprojekt ERP Einführung Programme Board Beauftragung aller Projekte Change Manager Senior- Responsible- Owner Programm- Manager Management der Abhängigkeiten, Ressourcenkonflikte, Outputs Berichte LA LA LA LA LA LA Projektmanager Projektmanager Ausfallsichere Ausgebildete IT-Infrastruktur Mitarbeiter Abhängigkeiten Projektmanager Erweiteres Gebäude Projektmanager Überarbeitetes Vertriebskonzept Teilprojekt 13

14 Das Team im Programmmanagement (MSP) Ein Programm besitzt immer einen SRO (Senior Responsible Owner) als obersten Schirmherrn und Verantwortlichen des Programms. In der Regel handelt es sich hierbei um ein Mitglied der Geschäftsführung bzw. des Vorstands. Es gibt den Programm-Ausschuss (Programme Board) mit dem SRO als Vorsitzendem und dem Programme Manager sowie den Business Change Managern, die für die Umsetzung des Nutzens in Ihren Bereichen zuständig sind. Optional: Auftraggeber der darunterliegenden Projekte Möglicherweise weitere Funktionen des Unternehmens (z. B. Finanzen, Risikomanagement, Generalunternehmer, etc.). 14

15 Kernfunktionen von Programmmanagement (MSP) Multiprojekt-Steuerung Transition-Management, d.h. Steuerung, Koordination und Ausführung der technischen und organisatorischen Umsetzungen Nutzenrealisierung nach Projektende 15

16 Welche Mehrwerte bietet Programmmanagement (MSP)? Die Einrichtung von MSP verlangt nach einer angemessenen Investition. Diese setzt sich zusammen aus den Kosten für: Personal (Gehälter, Rekrutierung, etc.) Infrastruktur (Büros, Konferenzräume, etc.) Tools (z.b. Projekt-, Programm- und Risikomanagement-Tools) Ausbildung/Entwicklung Beratung (Planung, Bewertung, Workshops, etc.) 16

17 Welche Mehrwerte bietet Programmmanagement (MSP)? Dem stehen als zentrale Vorteile gegenüber: Governance: MSP unterstützt vorhandene Governance- Einrichtungen durch Strukturen und Verantwortlichkeiten und sorgt für Effektivität. Der Nutzen besteht in der Vorbereitung optimaler Investitionsentscheidungen im Sinne der Unternehmensstrategie. Transparenz: Der Informationsbedarf der Entscheidungsebene wird optimal gedeckt. Dies führt z. B. zu schnellen Reaktionszeiten der Führungsebene, um Schäden zu begrenzen und Chancen zu nutzen. Umsetzungsunterstützung: Vermeidung von Mehrfachaufwänden und Sicherstellung von Methodenkompetenz erhöht die Qualität 17

18 Welche Mehrwerte bietet Programmmanagement (MSP)? Wiederverwendbarkeit: Gemachte Erfahrungen werden systematisch dokumentiert und ausgewertet. Durch Lessons Learned und die Verwendung von Best Practices kann die Wiederholung von Fehlern wirksam unterbunden und können Prozessabläufe beständig optimiert werden. Nachvollziehbarkeit: Dokumentation der Entscheidungen und Maßnahmen zur Unterstützung der Governance. Nutzenrealisierung: Das Programm ist um die Zeitdauer der Nutzenerzielung länger als die dazu gehörigen Projekte 18

19 MSP: Ausbildung und Zertifizierung MSP-Foundation-Zertifizierung Es handelt sich um einen einstündigen Multiple-Choice-Test der Basisbegrifflichkeiten ohne Zuhilfenahme von Materialien (closed book). Die zweite Ausbildungsstufe ist der sog. "Practitioner". Neben den Bereichen "Wissen" und "Verständnis" werden zusätzlich die Bereiche "Anwendung" und "Beurteilung" abgefragt. Der Practitioner-Test dauert zweieinhalb Stunden. Er ist ebenfalls ein Multiple-Choice-Test, bei dem der MSP-Leitfaden benutzt werden darf. Dritte Stufe ist der Advanced Practitioner. Zielgruppe sind Personen, die bei einer MSP-Einführung oder im Programm als Berater tätig sind. Um die Tests zu bestehen genügt es, jeweils 50% der Fragen richtig zu beantworten. 19

20 Blick in die Zukunft Bei einem steigenden Anteil der Projektwirtschaft an der Wertschöpfung eines Unternehmens ist es nicht die Frage ob, sondern wann derartige Strukturen eingerichtet werden müssen. So sollte man umgekehrt betrachten, welche Folgen es haben kann, wenn ein Unternehmen kein MSP einrichtet: o Das leitende Management weiß nicht, ob die aktuellen Projekte die strategischen Ziele des Unternehmens unterstützen. o Niemand weiß, wie viele Projekte im gesamten Unternehmen aktiv sind. o Projekte werden von verschiedenen Stellen im Unternehmen unkoordiniert gestartet, weil einzelne Mitarbeiter es für richtig halten ("Bereichs- Egoismus"). o Projekte finden kein Ende. o Ressourcen werden verschwendet, weil sie nicht priorisierten Projekten oder Programmen zugeordnet sind. o Aus Fehlern wird nicht gelernt, das Rad wird immer wieder neu erfunden. Einleitung 20

21 Herzlichen Dank! 21