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:

  1. Starten Sie Ihr Projekt erst, wenn eine mit dem Auftraggeber abgestimmte Auftragserteilung mit entsprechenden Befugnissen vorliegt
  2. Erarbeiten Sie sich mit Experten(innen) in einer Planungsklausur alle für das Projekt relevanten Daten (Spielregeln, Projektergebnis, Terminplan, Kalkulation, Kommunikationsablauf, Berichtswesen, Änderungen)
  3. Binden Sie rechtzeitig die wichtigsten Interessensgruppen und Betroffenen des Projekts ein.
  4. Achten Sie darauf, dass Ihr Team mit unterschiedlichen Persönlichkeiten ausgestattet ist.
  5. Besetzen Sie Ihr Team so, dass die wichtigsten Fachdisziplinen für die Realisierung des Vorhabens mitarbeiten.
  6. Bevor jemand zu arbeiten beginnt, hat dieser seine Arbeit visuell vorzubereiten.
  7. Arbeiten Sie nach dem 4-Augenprinzip, um Fehler aller Art rechtzeitig zu erkennen und abzustellen.
  8. Nutzen Sie Meilensteine wie „Auftrag liegt vor“, „Planung geprüft“, „Konzept freigeben“ und „Projekt abgeschlossen“ mit entsprechenden Fachergebnissen zur Absicherung des Projekts.
  9. Richten Sie für Änderungen während des Projekts einen Redaktionsschluss ein, ab diesem Termin keine Änderungen mehr erfolgen.
  10. Schaffen Sie die Möglichkeit, dass alle Beteiligten auf einer gemeinsamen Plattform arbeiten und ihre fachlichen Ergebnisse dokumentiert den anderen Mitstreitern zur Verfügung stellen.
  11. Nutzen Sie Projektbesprechungen und Meilenstein-Freigaben immer wieder aus den Situationen zu lernen und diese Erkenntnisse gleich in die nächsten Schritte anzuwenden.
  12. Halten Sie Ihren Auftraggeber und Ihre Führung auf dem Laufenden z. B. durch eine Ampeldarstellung und Meilenstein- und Kosten-Trendanalyse.

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?

  1. Im Allgemeinen ist es ja ganz einfach – da wir alle unterschiedliche Persönlichkeiten sind – haben wir ja quasi immer die richtige Projektbesetzung !? – Dem ist natürlich nicht so – also woran erkennt man die “richtigen” Persönlichkeiten?
  2. Außerdem könnte man ganz allgemein sagen,  bevor man die Ziele und Aufgaben des Projekts nicht kennt, sollte man das Team noch nicht zusammenstellen. Das trifft aber nur auf eine bestimmte Art von Projekten zu, bei denen alle Teammitglieder quasi erst rekrutiert werden. Bei Projekten in kleineren Agenturen wo man von 10-20 Mitarbeitern spricht – wird da die Relevanz doch eher gering sein.
  3. Nicht jeder weiss welche Faktoren welchen Einfluss auf das Projekt haben – wie besetzte ich also ein Team optimal wenn es um Soft Skills geht?
  4. Woher weiss ich als Projektleiter wer welche  – zum Vorteil des Projekts – Soft Skills hat – dabei rede ich nicht von einer subjektiven Beurteilung.

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.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert

%d Bloggern gefällt das: