Die Präsentation wird geladen. Bitte warten

Die Präsentation wird geladen. Bitte warten

Vom Pflichtenheft zur fertigen Software

Ähnliche Präsentationen


Präsentation zum Thema: "Vom Pflichtenheft zur fertigen Software"—  Präsentation transkript:

1 Vom Pflichtenheft zur fertigen Software
Teil 1 AEW1 - Simulieren und Schneiden von Projekten in der Anwendungsentwicklung Teil 2 AEW2 - Multiprojektmanagement in der Anwendungsentwicklung Boris Brandwirth (AEW1) & Jörg Ozimek (AEW2) | JBFOne | Version

2 Ziel dieses Vortrags Teil 1 - Simulieren und Schneiden von Projekten in der Anwendungsentwicklung Sie haben einen Überblick, wie die Anwendungsentwicklung ein Projektportfolio erstellt Sie entwickeln ein Gefühl dafür, was in der FIDUCIA IT AG unter Industrialisierung der Softwareentwicklung verstanden wird Sie haben ein Verständnis, wie in der FIDUCIA IT AG die Komponentenorientierung in der Projektdefinition berücksichtigt wird Teil 2 - Multiprojektmanagement in der Anwendungsentwicklung Sie haben einen Überblick, wie die Anwendungsentwicklung Projekte abwickelt Sie entwickeln ein Gefühl dafür, was unter Industrialisierung der Softwareentwicklung verstanden wird Sie haben ein Verständnis über die Komplexität des Multiprojektmanagements Sie betrachten die Projektleiter mit anderen Augen :-)

3 Agenda Teil 1 - Simulieren und Schneiden von Projekten
Wer ist AEW1 Schätzen und Simulieren Der optimale Projektschnitt und die Beauftragung

4 Agenda Teil 1 - Simulieren und Schneiden von Projekten
Wer ist AEW1 Schätzen und Simulieren Der optimale Projektschnitt und die Beauftragung

5 AEW1: 4 Leiter + 59 Produktspezialisten und ein AM-Boardmanager
AEW Anwendungsentwicklung Gernot Nolte AEW1 Produktentwicklung Joachim Föhrenbacher AEW2 Projekt- entwicklung Harry Riethmüller AEW3 Professional Services Herbert Ziefle AEW4 Application Management 1 Martin Gabriel AEW5 Application Management 2 Steffen Unterreiner AEW6 Architektur Gerd Müller AEW7 Qualitäts-management Rainer Heger AEW1KB (KA*) Kernbank Ingo Radmacher AEW2PA (KA) Projektentwicklung 1 Frank Schneider AEW3PA (KA) Prof. Services 1 Paul Keller AEW4ZK (M) Zahlungsverkehr/ Kunde Thomas Hantschk AEW5AC (KA) Analytisches CRM Stefan Luthardt AEW6AE (KA*) Application Engineering Erik Bechberger AEW7QR (KA*) Qualitäts- und Releasemanagement Wolfgang Hübner AEW1EK (M) Endkunden Stefan Ptascheck AEW2PB (M) Projektentwicklung 2 Jörg Ozimek AEW3PB (KA) Prof. Services 2 Holger Kübler AEW4FB (M*) Fusion Bankorganisation Christian Thomas AEW5BA (M) Vertriebsbank Bankarbeitsplatz Ralf Kohl AEW6SE (M*) Software Engineering Thomas Irlbacher AEW7PI (KA*) Planungs-, Vertrags- Infrastruktur Mgmt Martin Mattenschläger AEW1SV (KA*) Steuerung und Vertrieb Boris Brandwirth AEW2 (M) Projektentwicklung GenoSysWP Werner Kreidenweis AEW3PC (M) Prof. Services 3 Ulrich Sanberger AEW4KT (KA) Kontenverwaltung Bernhard Knittel AEW5BM (KA) Banksteuerung Meldewesen Klaus Ulmer AEW6TA (M*) Technische Architektur Sven-Ulfert Jansen AEW3PD (M) Prof. Services 4 Anna Katreniak AEW4KK (KA) Kontokern Bernhard Knittel AEW5EK (M) Vertriebsbank Endkunde Sven Herrmann 17 PS 20 PS 22 PS - (M) Standort München - (KA) Standort Karlsruhe - (KA*)/(M*) standortübergreifende Abteilung, Sitz des Abteilungsleiters in KA/M Bereich Hauptabteilungen

6 AEW1: Manage the business
Produkt- entwicklung AEW1 Architektur, Software Engineering, Performance Engineering (AEW6) Anforderungsmanagement-Board Projekteentwicklung AEW2 Professional Services (AEW3) PMM Application Management (AEW4/5) ITB Zentraliserter Bereich – daher Standardisierung möglich!!! Qualitätsmanagement, Infrastruktur, Test, Integration, Planung (AEW7) manage IT change the business run the business 6

7 Die Mission von AEW1 und unsere Kernaufgaben
Mission: Bewertung und Transformation von Anforderungen in ein optimiertes Projektportfolio und die fachliche Entwicklung von Produkten, Bündeln, Domains und Kanälen Die Kernaufgaben von AEW1 sind: Zentraler Ansprechpartner für Produktmanagement für die Neu- und Weiterentwicklung von Produkten Abstimmung der Entwicklungsplanungen mit Produktmanagement und weiteren Auftraggebern Bewertung von Anforderungen seitens Produktmanagement und weiterer Auftraggeber (Projektportfolio-Management) Gremienarbeit (Produktteam, AM-Board, AGR usw.) Gesamtverantwortung für fachliche Entwicklung von Produkten/Bündeln/ Domains und Kanälen Mitarbeit in Projekten (Poolfunktion) Third-Level-Funktion beim Incident Management für das Applicationmanagement Nur die Mission vorstellen! 7

8 Wer sind die Hauptdarsteller bei der Schätzung und Bündelung?
Produktspezialist (PS) Domain Architect (DA) Strategischer Blick auf sein(e) Produkt(e) Fachlich und (technisch) Baustellenliste pflegen Gemeinsame Aufgaben mit dem DA Diskutiert mit dem DA die Weiterentwicklung der Produkte unter Berücksichtigung der aSA Reviewpartner im Rahmen der Q-Gates Kommunikation/Vernetzung Strategischer Blick auf seine Domäne Fachlich und technisch Baustellenliste pflegen Abstimmung mit AEW6 Z. B. Bebauungsplan, … Gemeinsame Aufgaben mit dem PS Diskutiert mit dem PS die Weiterentwicklung der Produkte (mit dem übergreifenden Blick auf die Domäne und die Gesamtarchitektur) Sicherstellen eines optimalen Produkt-/ Projektportfolios für seine Domäne Reviewpartner für LK/FK für Produkte in seiner Domäne Kommunikation/Vernetzung Bleibt drinnen – aber ich gehe nicht darauf ein! 8

9 Agenda Teil 1 - Simulieren und Schneiden von Projekten
Wer ist AEW1 Schätzen und Simulieren Der optimale Projektschnitt und die Beauftragung

10 Kurzübersicht über die Phasen eines Pflichtenhefts

11 Einsatz eines standardisierten Schätzverfahrens
Über alle Requests hinweg wird das gleiche Schätzverfahren verwendet Basis jeder Schätzung sind der Konstruktionsaufwand oder die fachlichen Funktionen Anhand diverser Standardparameter werden die entsprechenden Zuschläge berechnet (z. B. beeinflusst die PFH- Qualität die Höhe des Risikopuffers) Die Schätzzuschläge unterscheiden sich je Projektkategorie (z.B. BAP, eBanking, FBI, agree SB, etc.) Der Projekt-Aufwand wird brutto (inkl. Risiko) und netto ausgewiesen

12 Simulation mit dem Tool imatch
Über ein spezielles Tool simulieren wir die Machbarkeit eines Releases sowie „Störungen“ auf ein Release Vor einer Releasezusage werden die Gesamtaufwände auf Skillebene mit den vorhandenen Skills verglichen und somit mögliche Handlungsfelder identifiziert Analog wird jede ungeplante Anforderung so auf Machbarkeit geprüft. Die endgültige Entscheidung bzgl. der Machbarkeit liegt bei den verantwortlichen Leitern  imatch ist nur ein unterstützendes Tool

13 Agenda Teil 1 - Simulieren und Schneiden von Projekten
Wer ist AEW1 Schätzen und Simulieren Der optimale Projektschnitt und die Beauftragung

14 Kurzübersicht über die Phasen eines Pflichtenhefts

15 Motivation zur Bündelung von internen Aufträgen zu Projekten
Synchronisation der Ausbringungen zu einem Produkt Vermeidung von Parallelentwicklungen zu einem Objekt (Versionierungskonflikt) Integrierte und komponentenorientierte Softwareentwicklungen führen zwangsläufig dazu, dass aus unterschiedlichen Entwicklungsaufträgen heraus parallel Erweiterungen an Komponenten erforderlich sind Reduzierung von Overheadkosten: Projektleitung Aufbau Testumfelder Reviews usw. Vermeidung von redundanten Entwicklungen

16 Bündelung von Projekten aus fachlicher Sicht (i/ii)
Anforderungsebene PH VRC- Version 5.x PH Kond.- Bausteine PH Kredit PH BuV PH … Projektebene Kredit VR-Control Konditions- bausteine Beratung u. Verkauf Anwendungs-/Komponentenebene VR- Control Produkt Kontover- waltung IKESA DWH Modell- rechnung Hier muss ich die Farben noch anpassen! Die Problematik, dass unterschiedliche Projekte parallel Änderungen an einer Komponente vornehmen, muss durch optimierte Projektbündelung gelöst werden 16

17 Festlegungen zum Projektzuschnitt durch AEW1
AEW1 schneidet Projekte anhand der SW-Architektur des Systems und sinnvoller Umsetzungseinheiten. Anforderungen werden gebündelt, der Zuschnitt eines Projekts ist damit potentiell losgelöst vom Schnitt des Pflichtenhefts (Produktmanagement fachliche Kundensicht vs. AEW SW- Architektursicht) Damit gibt es in jedem Release (Teil-)Projekte, die alle Anforderungen zu einem bestimmten Themenkomplex abdecken (z.B. Person, Konto …) Durch den Schnitt der Projekte (Pflichtenheft-übergreifend) werden Redundanzen vermieden und Synergien geschaffen Grundlage hierfür sind die Lösungsskizzen, die die Produktspezialisten im Rahmen einer ersten Anforderungsbewertung erstellt haben

18 Wie erkennt ein Produktspezialist die internen Aufträge?
Über die aufgeführten Abhängigkeiten im Pflichtenheft  Das Pflichtenheft ist eines der wichtigsten Artefakte für ein erfolgreiches Projekt Über die Kapitel „Lösungsweg“ und „Anwendungsfälle“ in der Lösungsskizze Über die Erfahrung der Produktspezialisten Über einen ständigen Austausch mit anderen Produktspezialisten

19 Bündelung von Projekten aus fachlicher Sicht (ii/ii)
Anforderungsebene PH VRC- Version 5.x PH Kond.- Bausteine PH Kredit PH BuV PH … Projektebene Kredit VR-Control Konditions- bausteine Beratung u. Verkauf IKESA Release DWH Release Anwendungs-/Komponentenebene VR- Control Produkt Kredit IKESA DWH Modell- rechnung Externer Auftrag per Pflichtenheft Umsetzung in anderen Projekten (interner Auftrag) Umsetzung im Projekt

20 Vereinfachtes Beispiel – vier Pflichtenhefte zur Umsetzung beauftragt
Wert des Request bzgl. Aufwand in Personenmonate Schätzung über ein standardisiertes Verfahren  Geschätzt werden die internen Aufträge Die Puzzle-Folien gehen ganz schnell oder mach ich garnicht. 20

21 Vereinfachtes Beispiel – vier Pflichtenhefte zur Umsetzung beauftragt
Interne Aufträge Interne Aufträge Interne Aufträge Interne Aufträge 4 6 3 5 7 2 1 8 30 10 Die Summe der internen Aufträge ergibt den Aufwand des Requests in Personenmonaten 21

22 Vereinfachtes Beispiel
Produkt Inhalt Budget Plichtenheft ….. Request 1 Request 2 Request 3 Request 4 18 PM 12 PM 20 PM 50 PM 18 PM 12 PM 20 PM 50 PM Interne Aufträge Interne Aufträge Interne Aufträge Interne Aufträge 4 6 3 5 7 2 1 8 30 10 Interne Auftragsbündel Interne Auftragsbündel Interne Auftragsbündel Interne Auftragsbündel 6 30 2 4 10 7 6 4 5 5 1 8 5 2 2 3 15 PM 29 PM 22 PM 34 PM

23 Die internen Auftragsbündel entsprechen dem umzusetzendem Projekt
Vereinfachtes Beispiel Produkt Inhalt Budget Plichtenheft ….. Request 1 Request 2 Request 3 Request 4 18 PM 12 PM 20 PM 50 PM 18 PM 12 PM 20 PM 50 PM 50 PM Interne Auftragsbündel Interne Auftragsbündel Interne Auftragsbündel Interne Auftragsbündel 6 30 2 4 10 7 6 4 5 5 1 8 5 2 2 3 15 PM 29 PM 22 PM 34 PM Die internen Auftragsbündel entsprechen dem umzusetzendem Projekt Zu jedem Produktmanagement-Request gibt es genau einen verantwortlichen Projektleiter

24 Wie erkennt man, welche interne Aufträge zu einem Projekt gehören?
Über die zentrale Notes-DB „Planportfolio“ erkennen die Produktspezialisten und die Projektleiter, welche interne Aufträge (zum von AEW1 definierten) Projektauftrag gehören In der Schätzphase gibt es für jeden internen Auftrag genau einen verantwortlichen Produktspezialisten

25 Wie erkennt man, in welchem Projekt welcher Request umgesetzt wird?
Über die zentrale Notes-DB „Planportfolio“ erkennt man die Verteilung der internen Aufträge eines Requests zu den verschiedenen Projekten Für jeden Produktmanagement-Request gibt es genau einen verantwortlichen Projektleiter

26 Ihre Fragen Teil 2

27 Wer ist AEW2? AEW2 ist die auf Projekte und auf Projektmanagement spezialisierte Hauptabteilung in der Anwendungsentwicklung Die Kernaufgaben von AEW2 sind das Umsetzen und Managen aller kundenorientierten und strategischen Projekte das operative Multiprojektmanagement die Weiterentwicklung des Projektmanagementstandards und der Projektkultur im Unternehmen Beratung rund um das Projektmanagement und das Coaching von Projektleitern Zentraler Ansprechpartner für Dritt-Kunden

28 AEW2: Change the business zusammen mit AEW3
Produkt- entwicklung AEW1 Architektur, Software Engineering, Performance Engineering (AEW6) Anforderungsmanagement Board Projekteentwicklung AEW2 Professional Services (AEW3) PMM Application Management (AEW4/5) ITB Qualitätsmanagement, Infrastruktur, Test, Integration, Planung (AEW7) manage IT change the business run the business

29 AEW2: 4 Multiprojektmanager (MPM) + 50 Projektleiter (PL/TPL)
AEW Anwendungsentwicklung Gernot Nolte AEW1 Produkt-entwicklung Joachim Föhrenbacher AEW2 Projekt- entwicklung Harry Riethmüller AEW3 Professional Services Herbert Ziefle AEW4 Application Management 1 Martin Gabriel AEW5 Application Management 2 Steffen Unterreiner AEW6 Architektur Gerd Müller AEW7 Qualitäts-management Rainer Heger AEW1KB (KA*) Kernbank Ingo Radmacher AEW2PA (KA) Projektentwicklung 1 Frank Schneider AEW3PA (KA) Prof. Services 1 Paul Keller AEW4ZK (M) Zahlungsverkehr/ Kunde Thomas Hantschk AEW5AC (KA) Analytisches CRM Stefan Luthardt AEW6AE (KA*) Application Engineering Erik Bechberger AEW7QR (KA*) Qualitäts- und Releasemanagement Wolfgang Hübner AEW1EK (M) Endkunden Stefan Ptascheck AEW2PB (M) Projektentwicklung 2 Jörg Ozimek AEW3PB (KA) Prof. Services 2 Holger Kübler AEW4FB (M*) Fusion Bankorganisation Christian Thomas AEW5BA (M) Vertriebsbank Bankarbeitsplatz Ralf Kohl AEW6SE (M*) Software Engineering Thomas Irlbacher AEW7PI (KA*) Planungs-, Vertrags- Infrastruktur Mgmt Martin Mattenschläger AEW1SV (KA*) Steuerung und Vertrieb Boris Brandwirth AEW2 (M) Projektentwicklung GenoSysWP Werner Kreidenweis AEW3PC (M) Prof. Services 3 Ulrich Sanberger AEW4KT (KA) Kontenverwaltung Bernhard Knittel AEW5BM (KA) Banksteuerung Meldewesen Klaus Ulmer AEW6TA (M*) Technische Architektur Sven-Ulfert Jansen AEW3PD (M) Prof. Services 4 Anna Katreniak AEW4KK (KA) Kontokern Bernhard Knittel AEW5EK (M) Vertriebsbank Endkunde Sven Herrmann 8 PLs 13 PLs 6 PLs 23 PLs 4 MPMs - (M) Standort München - (KA) Standort Karlsruhe - (KA*)/(M*) standortübergreifende Abteilung, Sitz des Abteilungsleiters in KA/M Bereich Hauptabteilungen

30 Wandel im Projektumfeld: Standardisierung, Professionalisierung, Industrialisierung
Früher: Viele Abteilungsleiter führen wenige Projektleiter. Das ermöglicht eine enge und individuelle Führung, auch der Projektmitarbeiter Freiheitsgrade und individuelle Auslegung im Projektmanagement. Projektmanagement ist eine individuelle „Ingenieurskunst“ Mitgestaltung des Projektauftrags durch den Projektleiter und Abteilungsleiter mit dem Ziel „Spitzenleistungsprodukte“ Mitarbeiter arbeiten festgelegt auf spezialisierte Fachgebiete, es gibt keine Trennung zwischen Projekten und Wartung, das Staffing erfolgt durch den Abteilungsleiter Die projektbegleitende Qualitätssicherung erfolgt durch AEW7 Heute: Wenige Multiprojektmanager führen viele Projektleiter. Die Projektleiter führen selbständig und mit fachlicher Führungsverantwortung die Projekte Die Vielzahl an Projekten erfordert eine Standardisierung und Vereinheitlichung durch einen Projektwegweiser, Projektmanagement wird eine industrialisierte „Ingenieursleistung“ Zentrales Anforderungsmanagement über AEW1: Anforderungen werden vor dem Projekt inhaltlich, aufwandsmäßig und terminlich zugesagt Zentrales Staffing und Destaffing über AEW3, teilweise auch auch mit Fluktuation zwischen den Projekten Zentrales und intensives Controlling durch AEW2. AEW7 führt stichprobenweise Quality Gates und Audits durch

31 Multiprojektmanagement in AEW2 Was bedeutet das in Zahlen?
Parallele Projekte pro Monat In AEW2 laufen zu jedem Zeitpunkt über 100 Projekte Im Jahr werden über 200 Projekte bearbeitet Der Projekt-Aufwand pro Monat beträgt immer zwischen 300 und 350 Personenmonaten Dies wird geleistet durch ca. 400 bis 500 Projekt- mitarbeiter (= reale Menschen) pro Monat Ein einzelner Multiprojektmanager (AEW2- Führungskraft) steuert dabei etwa 40 Projekte/Projektleiter parallel Diese Menge, das zur Steuerung notwendige Multitasking der Multiprojektmanager und die wirtschaftlichen Rahmenbedingungen erfordern: Standardisierung Vereinheitlichung Industrialisierung Projektaufwand in Personenmonaten pro Monat

32 Multiprojektmanagement in AEW2 Wie managt man 100 parallele Projekte?
Schaffung geeigneter Rahmenbe-dingungen 1 Lerne aus Erfolgen und Misserfolgen 6 Das Projekt richtig starten 2 100+ parallele Projekte ? Managing der Risiken und des Projekt-aufrags 5 Dem Projektleiter vertrauen 3 Konsequentes Controlling 4

33 Lerne aus Erfolgen und Misserfolgen
6 Schaffung geeigneter Rahmenbe-dingungen 1 Das Projekt richtig starten 2 Dem Projektleiter vertrauen 3 Managing der Risiken und des Projekt-aufrags 5 Konse-quentes Controlling 4 100+ parallele Projekte ? Wie managt man 100 parallele Projekte? Geeignete Rahmenbedingungen schaffen! AEW2 ist Bestandteil einer Prozesskette. Grundprämisse für eine gute Projektarbeit sind deshalb gute Prozessergebnisse der beteiligten AEW-Abteilungen von AEW1-AEW7 AEW1: optimales Portfoliomanagement/Releaseplanung, gute Projektbeauftragung AEW3: rechtzeitige Bereitstellung geeigneter Projektmitarbeiter AEW4/5: Unterstützung und rechtzeitige Übernahme der Projektergebnisse AEW6: technische Standards und Frameworks AEW7: Releasemanagement

34 Lerne aus Erfolgen und Misserfolgen
6 Schaffung geeigneter Rahmenbe-dingungen 1 Das Projekt richtig starten 2 Dem Projektleiter vertrauen 3 Managing der Risiken und des Projekt-aufrags 5 Konse-quentes Controlling 4 100+ parallele Projekte ? Wie managt man 100 parallele Projekte? Geeignete Rahmenbedingungen schaffen! Standardisierung und Professionalisierung des Projektmanagements durch den „agree-Projektwegweiser“: ein Wegweiser für die Projektmanagement-Methodik von Projektleitern für Projektleiter entwickelt aus der Praxis für die Praxis im Vorgehensmodell VGM 5.0 verankert Optimieren der Projektmanagement-Tools MS Project, MS Excel, Pavone und der verwendeten Projektmanagement-Artefakte (Templates) Optimieren des Zusammenspiels zwischen den Tools(„Tool Chain“) „Man muss die Dinge so einfach wie möglich machen. Aber nicht einfacher.“ Albert Einstein agree Projekt- Wegweiser FIDUCIA Vorgehensmodell NPS Planungssystem agree Projekt- Wegweiser „Projekt“ Rea- lisierung PIT GIT AT RIAT Pilot Konzeption Submodell Projektmanagement Submodell Entwicklung u. Qualitätsmanagement Projektleiter

35 Querschnittliche Themen
Der agree Projektwegweiser beschreibt das VGM-Submodell PjM für AEW-Projektleiter und orientiert sich am PMI®-Standard Aufgabenbereiche Initiierung Planung Durchführung, Steuerung & Überwachung Abschluss Integration Inhalt und Umfang Termin Kosten Personal Qualität Kommunikation Risiko Beschaffung Vertrag Themen Prozessmanagementprozessgruppe Wissensgebiet ANIMIERT ! Aufgaben Querschnittliche Themen Projekt- Wegweiser Glossar 35 35

36 Der Projektwegweiser definiert die Projektmanagement-Aufgaben des AEW-Projektleiters nach Aufgabenbereichen Aufgabenbereiche (PjM Aufgabenbereiche bzw. PMI® Projektmanagementprozessgruppen) Initiierung Planung Durchführung, Steuerung & Überwachung Abschluss Integration Inhalt und Umfang Termin Kosten Personal Qualität Kommunikation Risiko Beschaffung Vertrag Themen/Aspekte (PMI® Wissensgebiete) Formale Prüfung Freigabe einholen Abschluss Projektleiter- vereinbarung initialer Projektplan Breiteneinsatz Grobe Mach- barkeit prüfen Grob-planung Fein-planung Ausführen Fort schreibung Prüfen Handeln Staffing Querschnittliche Themen = Aufgaben

37 Wie managt man 100 parallele Projekte? Das Projekt richtig starten!
Lerne aus Erfolgen und Misserfolgen 6 Schaffung geeigneter Rahmenbe-dingungen 1 Das Projekt richtig starten 2 Dem Projektleiter vertrauen 3 Managing der Risiken und des Projekt-aufrags 5 Konse-quentes Controlling 4 100+ parallele Projekte ? Wie managt man 100 parallele Projekte? Das Projekt richtig starten! Den richtigen Projekleiter finden Sicherstellen eines eindeutigen, klaren und machbaren Projektauftrags als formale Hürde für den Auftraggeber Durch den Projektleiter: formale Prüfung grobe Machbarkeitsprüfung Stakeholder Analyse Risikoanalyse Sicherstellen der notwendigen Keyplayer Klare Projektorganisation und geregelte Verantwortungen im Projektteam Ergebnis ist die „Projektleitervereinbarung“ als Commitment des Projektleiters zu seinem Projekt „Sage mir, wie Dein Projekt beginnt und ich sage Dir, wie es endet." Gero Lomnitz „Nur wer sein Ziel kennt, findet den Weg.." Laotse Projektleitervereinbarung

38 Lerne aus Erfolgen und Misserfolgen
6 Schaffung geeigneter Rahmenbe-dingungen 1 Das Projekt richtig starten 2 Dem Projektleiter vertrauen 3 Managing der Risiken und des Projekt-aufrags 5 Konse-quentes Controlling 4 100+ parallele Projekte ? Wie managt man 100 parallele Projekte? Der Projektleiter leitet das Projekt! Der Projektleiter hat die volle Verantwortung für sein Projekt und muss es – möglichst selbstständig – managen Der Multiprojektmanager ist „nur“ sein Trainer Prinzipien: (Selbst-)Verantwortung Vertrauen Der Projektleiter ist methodensicherer Planer und Steuerer durchsetzungsfähiger und belastbarer Führer sozialkompetenter Partner Projektarbeit ist Teamwork „Project Management - Plan your work, work your plan.” Jim R. Sherman „Das Leben ist kein Ponyhof.” Bernd Stromberg „Menschen machen Projekte.” sd&m © Warner Bros

39 Wie managt man 100 parallele Projekte? Konsequentes Controlling
Lerne aus Erfolgen und Misserfolgen 6 Schaffung geeigneter Rahmenbe-dingungen 1 Das Projekt richtig starten 2 Dem Projektleiter vertrauen 3 Managing der Risiken und des Projekt-aufrags 5 Konse-quentes Controlling 4 100+ parallele Projekte ? Wie managt man 100 parallele Projekte? Konsequentes Controlling Der Multiprojektmanager hat die Gesamt-Verantwortung für alle Projekte und alle Projektleiter. Daraus ergibt sich auch die Verpflichtung zum Controlling Controlling ist in AEW2 ein Steuerungsinstrument und kein Kontrollinstrument (engl. „to control“ = „steuern“, „regeln“) Basis für das AEW2-Controlling ist der „Projektmonitor“, ein Status-Cockpit über alle Projekte mit Möglickeit zum Drill-Down in einen Statusbericht mit über 100 Attributen Der Projektmonitor wird alle 2 Wochen zentral durch ein Projektcontrolling-Team (PMO) im Gespräch mit dem PL aktualisiert. Adressat ist der Multiprojektmanager „Projekt“ PMO Submodell Projektmanagement Submodell Entwicklung u. Qualitätsmanagement Konzeption Rea- lisierung PIT GIT AT RIAT Pilot Projektleiter

40 Qualitätssicherungs- verantwortlicher (QSV) Produktspezialist (PS)
Konsequentes Controlling: AEW2-Projektmonitor Datenquellen = technische Werte + Einschätzungen Multiprojektplan-DB MPP Projektleiter (PL) Qualitätssicherungs- verantwortlicher (QSV) Produktspezialist (PS) Staffing iMatch alle 14 Tage für jedes Projekt zentral durch das PMO (Projektcontrolling-Team) Basis für die Jour Fixe des Multiprojektmanagers mit dem Projektleiter

41 Konsequentes Controlling: AEW2-Projektmonitor Der Cockpit-View bietet Übersicht über alle Projekte
Drill-Down in Projektbericht mit 110 Details pro Projekt

42 Konsequentes Controlling Gesamtüberblick Projektcontrolling und - Berichtswesen
Vorstand Controlling-Runde - regelmäßig monatlich - alle Keyprojekte HAL-Jour Fixe Portfolio-Jour Fixe - regelmäßig wöchentlich und im Eskalationsfall AEW-BL AEW-intern Controllingrunden Folien AL-Jour Fixe / FK-Meeting - regelmäßig alle 1-2 Wochen und im Eskalationsfall AEW2-HAL AEW7-HAL AEW2-intern PL-Jour Fixe - regelmäßig alle 1-4 Wochen für jedes Projekt und im Eskalationsfall Multiprojekt- Manager (MPM) AEW2-AL AEW7-AL PMO-Jour Fixe - regelmäßig wöchentlich und im Eskalationsfall AEW2- Projekt- monitor QG-/Audit- Bericht Keyprojekt- Controller Projektcontrolling- Team (PMO) - Risiko-Monitor - MTA QS-Plan CR-Log Projektplan EVA Staffingplan Auditor QG-Prüfer PMO-Controlling-Gespräche - regelmäßig alle 2 Wochen - für jedes Projekt Projekt- leiter Keyprojekt- Bericht QSV Keyprojekt-Controlling - regelmäßig monatlich nur für Keyprojekte Projektinternes Eigencontrolling, speziell durch den QSV PS projektintern Quality Gates / Audits - nur für ausgewählte Projekte

43 Lerne aus Erfolgen und Misserfolgen
6 Schaffung geeigneter Rahmenbe-dingungen 1 Das Projekt richtig starten 2 Dem Projektleiter vertrauen 3 Managing der Risiken und des Projekt-aufrags 5 Konse-quentes Controlling 4 100+ parallele Projekte ? Wie managt man 100 parallele Projekte? Managen der Risiken und des Projektauftrags Der Projektleiter managt seine Risiken, d. h. er sorgt dafür, dass die Risiken möglichst nicht eintreten und dass der Multiprojektmanager die wichtigsten Risiken kennt Risiken werden solidarisiert und mitteln sich über alle Projekte wieder aus Der Multiprojektmanager unterstützt den Projektleiter Sponsoring bei Budgetproblemen aus dem Risikopuffer Projektübergreifendes Umpriorisieren von Keyplayern Bewahren eines machbaren und klaren Projektauftrags durch Change-Request-Verfahren (CR-Logbuch, AM-Board) Schutz des Projekts vor ungeplanten Außenstörungen jeglicher Art Einhalten wirtschaftlicher Rahmenbedingungen „Wer alles rein lässt, kann nicht ganz dicht sein.” PL-Weisheit „Einer für alle - Alle für einen.” Die 3 Musketiere Projektleiter

44 Lerne aus Erfolgen u. Misserfolg
6 Schaffung geeigneter Rahmenbe-dingungen 1 Das Projekt richtig starten 2 Dem Projektleiter vertrauen 3 Managing der Risiken und des Projekt-aufrags 5 Konse-quentes Controlling 4 100+ parallele Projekte ? Wie managt man 100 parallele Projekte? Lernen aus Erfolgen und Misserfolgen Kontinuierliche Prozessverbesserung aus dem Controlling-Prozess von den Projektleitern Erkennen von Optimierungspotential und Übernehmen in die Rahmenbedingungen, in den Projektwegweiser und ins AEW2-Projektcontrolling „Wer einen Fehler gemacht hat und ihn nicht korrigiert, begeht einen zweiten.“ Konfuzius „Niemand plant, zu versagen, aber die meisten versagen beim Planen.” Lee Iacocca

45 ZDF … Zahlen – Daten – Fakten Anzahl paralleler Projekte pro Monat
BACKUP

46 ZDF … Zahlen – Daten – Fakten Projektaufwand pro Monat (in Personenmonaten)
BACKUP

47 ZDF … Zahlen – Daten – Fakten Projektgrößen der Projekte, aufgeteilt nach FIDUCIA-Standort
BACKUP

48 ZDF … Zahlen – Daten – Fakten Projektlaufzeit der Projekte, aufgeteilt nach FIDUCIA-Standort
BACKUP

49 ZDF … Zahlen – Daten – Fakten Nach PL: Maximale Anzahl Parallelprojekte und Aufwand pro Monat
BACKUP maximaler geleiteter Aufwand im Kalendermonat beim Projektleiter maximale Anzahl geleitete parallele Projekte im Kalendermonat beim Projektleiter die einzelnen Projektleiter Projektleiter 1 .. n

50 ZDF … Zahlen – Daten – Fakten Aktuell im AEW2-Projektmonitor bei 177 erfassten Projekten
BACKUP Ampeln 25 gelbe und 3 rote PL-Ampeln 15 gelbe und 1 rote QSV-Ampeln 12 gelbe und 2 rote PMO-Ampeln PIT und GIT durchgeführte Testfälle 17 offene Prio 1 Bugs, 120 offene Prio 2 Bugs 712 von AM übernommene automatisierte Regressionstestfälle, 455 neue und geänderte Regressionstestfälle Inhaltliche Change Requests von PMM / AEW1: 268 CRs Zusammenarbeitspläne mit AM abgestimmt: 131 ZAPs

51 Ihre Fragen

52 Jörg Ozimek Dipl. Informatiker
Fragen? – Diskussion? Boris Brandwirth Dipl.-Math. Oec. Leiter Steuerung und Vertrieb (AEW1SV) Anwendungsentwicklung Telefon: / Jörg Ozimek Dipl. Informatiker Leiter Projekte München (AEW2PB) Anwendungsentwicklung Telefon: 089 /

53 Ihr IT-Partner Vielen Dank


Herunterladen ppt "Vom Pflichtenheft zur fertigen Software"

Ähnliche Präsentationen


Google-Anzeigen