Die Wahl der Vorgehensweise im IT-Projektmanagement: ein kritischer Erfolgsfaktor! interpm 2012

Transkript

1 im IT-Projektmanagement: ein kritischer Erfolgsfaktor! interpm 2012 Michael Schneegans, amendos gmbh

2 Inhalt 01 Fallbeispiel Projekt 1: System-Einführung 02 Fallbeispiel Projekt 2: System-Weiterentwicklung 03 Lessons Learned 04 Wahl der Projektmanagement-Vorgehensweise 05 Ausblick für das IT-Projektmanagement 06 Organisatorische Einbettung 2

3 IT Business Organisatorische Rahmenbedingungen des IT-Projektmanagements im Fallbeispiel externe Kunden Operative Zentrale Marketing Standort 1 Standort n Vertrieb IT-Projektmanager SW- Netzwerk DB-Admin. Telekomm. Entwicklung Externe Dienstleister 3

4 Portfolio der IT-Projekte des IT-Projektmanagements im Fallbeispiel 4

5 Abnahme Abnahme Projekt 1: System-Einführung klassische Vorgehensweise Auftrag (Ticket) Planung Konzept Umsetzung Nachbereitung ca. 1,5 Jahre 5

6 Projekt 2: System-Weiterentwicklung klassische Vorgehensweise Produktmanager, Vertrieb, CEO, Kundenwünsche Changes Auftrag (Ticket) Planung Konzept Umsetzung Druck 6

7 Projekt 2: System-Weiterentwicklung nach Turnaround agile Vorgehensweise Team Product Owner Sprint Backlog Marketing, Vertrieb, CEO, Kunden, Product Backlog Produktinkrement Scrum Master 7

8 Lessons Learned Beide Projekte konnten mit der ihnen angemessenen Projektmanagement-Vorgehensweise zum Erfolg geführt werden. Es gibt bei dem gegebenen Projektportfolio nicht die richtige Projektmanagement-Vorgehensweise. Für jedes einzelne Projekt ist die angemessenste Vorgehensweise zu wählen und ggf. projektspezifisch anzupassen. Die richtige Wahl der Vorgehensweise ist erfolgskritisch für das Projekt! 8

9 Die richtige Wahl treffen Kriterienkatalog Projekt grob einschätzen Kriterium/Ansatz Spricht eher für klassisch Spricht eher für agil (Scrum) Projekttyp Investitions- und Organisationsprojekt (Software-)Entwicklungsprojekt Ziele Auftraggeber Team Externe Dienstleister Stakeholder SMART formulierbar; über Projektverlauf konstant; Klar in seinen Zielvorstellungen; denkt in Prozessen; ist eher für den klassischen Ansatz; Braucht klare Führung; räumlich verteilt, virtuell; eher groß; (teilweise) durch Linienaufgaben gebunden; Viele Dienstleister mit vielen Abhängigkeiten untereinander; brauchen klare Arbeitspaketdefinitionen und Terminvorgaben; Viele Stakeholder, die die Business Requirements festlegen (hoher Abstimmungsbedarf und Zeitaufwand); Termine müssen gehalten werden; Unscharf; Vision; häufige Änderungen sind zu erwarten; Neigt zum häufigen Ändern von Prioritäten und Zielvorstellungen; für agilen Ansätze aufgeschlossen; Kann eigenständig arbeiten und sich selbst organisieren; kann lokal konzentriert werden; eher klein; Keine oder wenige Dienstleister mit geringen Abhängigkeiten untereinander; agilen Ansätzen gegenüber aufgeschlossen; Vertragskontext lässt agiles Vorgehen zu; Wenige Stakeholder; Qualität wichtiger als Termin; Aktivitäten der Stakeholder weitgehend unbeeinflusst vom Projekt; Dokumentation Rechtliche Anforderungen erfordern hohe Dokumentationsqualität; zukünftige Weiterentwicklung und Pflege haben hohen Stellenwert; Es existieren keine externen Zwänge (Normen, Gesetze, ); für zukünftige Zwecke weniger wichtig; 9

10 Die richtige Wahl treffen Betrachtung des Fallbeispiels Projekt 1: System-Einführung klassische Vorgehensweise erfolgreich Projekt 2: System-Weiterentwicklung klassische Vorgehensweise führte zur Krise; erst agile Vorgehensweise führte zum Erfolg (nach Turnaround) 10

11 Die richtige Wahl treffen Entscheidung quantifizieren Falsche Wahl der Projektmanagement-Vorgehensweise ist ein Risiko für das Projekt (Projektkrise) Risikowert = Eintrittswahrscheinlichkeit x Tragweite Pragmatischer Ansatz: Kriterien aus Katalog mit Verfeinerung und Gewichtung Eintrittswahrscheinlichkeit Risiko-Workshop mit zwei Experten ( klassischer & agiler PM) Schätzung auf Skala 1-5 (Risiko sehr gering bis sehr hoch ) Tragweite 1 (= geringe Auswirkungen), 2 (= Gefährdung magisches Dreieck ), 3 (= Projektkrise) Vergleich liefert Indikation, welche Vorgehensweise bei einem gegebenen Projekt weniger riskant ist 11

12 Die richtige Wahl treffen Bewertung mit Gewichtung Gewicht I Gewicht II Kriterium Unterkriterium Beschreibung gegebenes Projekt Projekttyp 10% Projekttyp 100% Produktentwicklung in einem neu zu gewinnenden Markt Ziele 20% 100% 12,5 5 8 SMART? 50% unternehmerische Vision , konstant? 50% viele Changes zu erwarten Auftraggeber 20% 100% 9,4 4,3 5 klar in Zielvorstellungen? 50% nein, Ziele entwickeln sich im Verlauf des Projekts , denkt in Prozessen? 10% ja , ,1 Aufgeschlossenheit für 20% indifferent Vorgehensweise? , ,4 Erwartungen an 10% schnell entwickelte, vorzeigbare Vorgehensweise? Produkte , ,4 kann wechseln? 10% ja , ,4 Team 20% 100% 4 5,5-2 Führung? Selbstorganisation? 50% braucht Führung ,5 räumlich verteilt? 20% nein , ,4 Größe? 20% , ,4 Einbindung in 10% freigestellt Linienaufgaben/andere Projekte? , ,2 ext. Dienstleister 10% 100% 2,6 2,6 0 Anzahl? 30% , ,9 Abhängigkeiten untereinander? 40% keine , ,2 Bedarf an Vorgaben 10% flexibel (Aufgaben/Termine)? , ,3 Aufgeschlossenheit für 10% offen für beide Ansätze Vorgehensweise? , ,1 Vertragskontext? 10% keine Einschränkungen , ,1 Stakeholder 15% 100% 6,75 4,75 2 Anzahl? 25% wenige , ,75 Einfluss auf Requirements? 25% hoch (Erwartungen externer Kunden) , ,5 erwartete Abstimmungsbedarfe? 25% mittel , Erwartungen an Termin, Budget, 25% schnell entwickelte, vorzeigbare , ,5 Qualität? Produkte Dokumentation 5% 100% 6,5 3,5 3 rechtliche Anforderungen? 50% keine , ,5 Stellenwert für zukünftige 50% gering Weiterentwicklungen? Prüfung 100% 100% 12 Bewertung Eintrittswahrscheinlichkeit "negativer Einfluss auf Projekt" (1-5) "klassisches" Vorgehen Tragweite bei negativer Auswirkung (1-3) Risikowert (EW x T) Risikowert (gewichtet) Eintrittswahrscheinlichkeit "negativer Einfluss auf Projekt" (1-5) agiles Vorgehen Tragweite bei negativer Auswirkung (1-3) Risikowert (EW x T) Risikowert (gewichtet) Delta (rot, minus: pro "klassisch", schwarz, positiv: pro agil)

13 Weiterentwicklung Ausblick für das IT-Projektmanagement Weiterer Ausbau der Wahlmöglichkeiten Auswahlmethodik optimieren Mittelfristig Transfer auf das gesamte Unternehmen 13

14 Optimierung der Auswahlmethodik projektspezifischer Kombinator 14

15 Optimierung der Auswahlmethodik Mehrdimensionale Betrachtung 15

16 Vielfalt von PM-Vorgehensweisen Für und Wider Strengths Weaknesses Wahlmöglichkeiten zwischen Vorgehensweisen Optimalste Vorgehensweise liefert optimalstes Projektergebnis Risikominimierung Es kann nicht jeder alles können Know-how muss teilw. erst aufgebaut werden Einbindung Kunden wird aufwändiger (höherer Erklärungsbedarf) Einbindung Team wird aufwändiger Ressourcenmanagement wird komplexer Opportunities Threats Kompetenzgewinn (IT als Ganzes) Kompetenzgewinn (jeder einzelne IT-PM) Motivationssteigerung Kompetentere Außendarstellung Methoden-Wildwuchs: Jeder macht, was er will Aushebeln der Dokumentationsstandards Vertreterregelung funktioniert nicht mehr chaotischere Außendarstellung 16

17 Organisatorische Einbettung 17

18 Thank you for your attention. Michael Schneegans IT-Projektmanager und Senior Consultant Phone: +49 (0) amendos gmbh Grüner Deich Hamburg, Germany Phone: +49 (0) Fax: + 49 (0)