Die GPM Toolbox: 10 Werkzeuge, 10 Regeln (3/3)
Und hier nun Teil 3:
KnowHow
Der „New-Economy-Ansatz“:
Mangelndes Wissen kann durch genug Einsatz kompensiert werden
Die „IT-Beratungsfirma Methode“:
Wir lernen auf Kosten den Kunden im laufenden Projekt
Besser: Vor Projektstart notwendige Skills klären und Grundlagen erarbeiten.
Dinge, die man gesehen haben sollte:
Risikomanagement
Verschiedene Methoden zur Aufwandsabschätzung von Projekten
Richtig telefonieren
Selbstorganisation
Wissensmanagement
Regel 7: Mitarbeitervorträge
Alle 4-6 Wochen wird ein Nachmittag für Vorträge reserviert
Die Themen werden 2-3 Wochen vorher besprochen und verteilt
Die Vorträge werden Als Folien/Texte archiviert
Die Themen sollten so aufbereitet werden, dass sie alle Anwesenden verstehen (klingt simpel? ist es nicht!)
Werkzeug 7: Wissenspool installieren
– Dies kann ein einfaches gemeinsam genutztes Laufwerk sein
– oder ein Wiki
Koordination
Die meisten Methoden definieren Rollen (Architekt, Projektleiter, Stakeholder etc.). Die „Unified Method“ kennt > 40 Rollen (Extreme Programming >10) Wir nutzen auch ein Rollenmodell, haben aber nur 5 Rollen
Die Rollen:
Projektleiter
– Verantwortlich für den Projekterfolg
– Koordiniert die Kommunikation mit den Kunden
Anforderungsmanager
– Verantwortlich für die Verwaltung der Anforderungen
QS-Verantwortlicher
– Verantwortlich für Qualität
– Gleicht die Lieferung mit Anforderungen ab
– Sein Veto entscheidet über die Auslieferung
– Darf nicht gleichzeitig Projektleiter sein
Lösungsarchitekt (nur für Projekte mit IT Anteil)
– Erstellt die Lösungsarchitektur
Umsetzer (Entwicklung, Grafik.)
– Verantwortlich für die Umsetzung eines Features
Regel 8: Rollen definieren
– Für jedes Projekt Rollen festlegen
– Eine Person kann maximal 3 Rollen ausfüllen
– Rollen leben: Ein QS Manager wird nicht nur benannt, er wird auch gefragt!
Regel 9: Aufwandsabschätzung als Teamarbeit
– Aufwände und Zeitpläne werden nicht „nur“ vom PM erstellt.
– Jeder Feature-Owner ist für die termingerechte Lieferung seines Features verantwortlich
– Eine gute Möglichkeit zur Aufwandsabschätzung ist Planning Poker
Regel 10: Risikomanagement nicht vergessen!
– Schönwetterprojekte kann jeder
– Immer „Plan B“ in der Schublade haben:
– Was kann passieren? Wie können wir reagieren?
Werkzeug 8: Projekt-Laufzettel
– Jedes Projekt bekommt einen Laufzettel
– Der Laufzettel steht eine Stufe über der Feature-Liste und hält die Informationen zusammen
– Der Laufzettel definiert, welche Daten zum Start einer Phase notwendig sind und welche Ergebnisse eine Phase liefert
Werkzeug 9: Projektplanungstool
– Hier gibt es keine Empfehlung, da die Vorlieben extrem unterschiedlich sind.
– Manche Leute mögen MS-Project, andere nehmen lieber Excel.
Werkzeug 10: Das wichtigste PM Tool überhaupt!
– Papier&Bleistift
‹ Die GPM Toolbox: 10 Werkzeuge, 10 Regeln (2/3) Premiere ›
Zu deinem Rollenmodell: Findest du’s nicht gefährlich, den Projektmanager für den Projekterfolg verantwortlich zu machen, die einzelnen Umsetzer aber nur für ihren Teil? Das sorgt normalerweise dafür, dass hinterher jeder auf den anderen zeigt, seine erfolgreichen Unittest rausholt, aber für Integration keiner verantwortlich ist.
Ein anderer Klassiker: Toll konzipiertes Feature, lässt sich aber leider nicht umsetzen (oder nur mit Riesenaufwand). Kann man das dem Konzepter vorwerfen? In deinem Modell nicht, der hat ja seinen Job gemacht und sogar eine Abnahme vom Kunden! Dem Projektmanager? Auch nicht, der kann die Umsetzbarkeit ja oft gar nicht nicht beurteilen. Dem Umsetzer? Nur, wenn du ihm die Möglichkeit gibst, den Konzepter ggf. zu überstimmen. Und damit ist er eben nicht mehr nur für sein Feature verantwortlich., sondern auch für die Konzeptqualität, also für den Erfolg des Features und in der Summe aller Features für den Projekterfolg.
Guter Punkt.
Das kann nur dann funktionieren, wenn die Kommunikation funktioniert und die jeder über seinen Tellerrand hinausblickt.
Jeder muss sich für den Gesamterfolg verantwortlich fühlen.
Das aber bewirkt, dass Du mit meinem Rollenmodell keine bel. großen Projekte steuern kannst. Ab einer gewissen Komplexität musst Du wieder Unterprojekte bilden.
Stimmt, aber das Bilden von Unterprojekten ist sowieso eine gute Idee. Teams über 10 Personen funktionieren eigentlich nie wirklich gut. Das weiß man nicht erst seit agilen Methoden, aber die haben sich auf Teamgrößen von 7 plusminus 2 festgelegt. Größere (und sogar VIEL größere) Projekte werden dann eben von mehreren Teams bearbeitet – genau weil Kommunikation nur innerhalb eine begrenzt großen Teams funktionieren kann, Kommunikation aber ein Schlüsselkriterium ist – letztlich für Zusammenarbeit von Menschen.
Blogring für gpm…
Verwandte Blog-Einträge…