Auf dem hervorragenden Blog von WOLF PROZESSMANAGEMENT – TRAINING GmbH habe ich diese 12 Gebote gefunden, die als Orientierung in der Projektarbeit dienen sollen. Ich habe mir alle 12 Punkte genauer angeschaut und kann grundsätzlich zu keinem Punkt sagen er sei nicht sinnvoll – ABER ich möchte doch aus meiner Sicht noch einige Anmerkungen machen – hier zunächst die 12 Punkte:
Hier kurz meine Reflexion zu einigen Punkten bzw. meine Erfahrung dazu:
zu 4. Persönlichkeiten meint an der Stelle sicherlich auch weniger die Kompetenzen und fachlichen Anforderungen an ein Teammitglied sondern insbesondere werden hier die “weichen” Faktoren angesprochen. Die Aussage klingt vernünftig und würde ich zunächst so zustimmen ABER im täglichen Projektleben dürften viele Kollegen wenig damit anfangen können – warum?
Diese Fragen müssen sich Projektleiter und/oder auch Führungskräfte nicht nur bei der Projektzusammenstellung stellen, sondern sind allgemeine Fragen der Mitarbeiterführung. Einen Lösungsansatz bietet das Modell von Dr. Belbin, dass ich hier in einer tabellarischen Aufstellung kurz erwähnen möchte:
zu 6. Ein spannender Punkt – die Visualisierung bsp. bei Online-Projekten werden entweder im Design-Konzept entwickelt oder bei der Abbildung von Funktionen über Mockups realisiert, die meist durch die Entwickler selbst erstellt werden. Beides pragmatisch, beides wichtig – allerdings ist mir dann noch aufgefallen das ja auch der Entwicklungsprozess gemeint sein könnte – das man beispielsweise mit Flussdiagrammen darstellt. Dabei kann ich grundsätzlich sagen – nicht immer ist es notwendig ein Flussdiagramm zu erstellen aber immer dort wo neben der funktionalen Visualisierung auch der Prozess und die Abhängigkeiten deutlich wurden hat das für mehr Transparenz und Verständnis gesorgt. Guter Tipp.
zu 9. Sicherlich gibt es in vielen Projekten eine Dead-Line und Liefertermine sind einzuhalten – ABER haben wir nicht allzu häufig erlebt das zu Beginn des Projekts “krampfhaft” versucht wurde die Dead-Line zu errechnen um dann schmerzlich festzustellen das man Sie nicht halten kann? Gerade in der Softwareentwicklung (wenn es sich nicht um eine Standrad-Webseite handelt) gibt es Risiken und Variablen die nicht beim Projektstart in vollem Umfang planbar sind. Deshalb favorisiere ich hier den “agilen” Ansatz bei dem man von Sprint zu Sprint aufgrund (Inspect&Adapt) mehr und mehr in die Lage ist, ein Release-Datum nennen zu können. Hinzu kommt das Change Requests und Optimierungen in der Softwareentwicklung auch nach einem Release nicht nur normal sind, sondern sogar gewünscht. Damit ist nicht gemeint den Lieferumfang im Bezug auf die Dead-Line zu relativieren – sondern es geht darum das der Kundenwunsch höher zu bewerten ist als eine Dead-Line (beides bedingt ja einander) – möchte der Kunde noch Änderungen zur Verbesserung (gemeinsame Bewertung) des Produkts durchführen sollte er immer Gehör finden – kaum noch ein Projektleiter und Dienstleister kann es sich leisten hier abzuwinken und auf die Dead-Line zu verweisen. Ein Lösungsansatz ist hier das Arbeiten mit einem Product-bzw. Sprint Backlog bei der der Kunde entscheidet welche Features in einen Sprint mit aufgenommen werden und welche quasi aus der Liste fallen.
zu 11. Deshalb schätze ich das Projektmanagement mit Scum – gerade die Scrum-Review-Meetings (Kunde sitzt mit am Tisch) und Scrum Retrospektiven ist der Lerneffekt recht hoch. Auch und gerade weil der Kunde meist recht deutlich macht, was Ihm nicht gefällt bzw. wo es noch klemmt. Diese Feedbacks werden dann noch in der Retrospektive ausgewertet und im nächsten Sprint so gut es geht in die Umsetzung gebracht.