Anlass für die Überarbeitung ist die Lehrveranstaltung “Methodenwerkstatt Projektmanagement“, die ich in diesem Semester bereits zum zweiten Mal unterrichte. Ohne lange Umwege, hier zum…

Download FHV Projekthandbuch 8.0

Ich bin jedenfalls heiß darauf und möchte das Tools sobald wie möglich probieren!

Wir brauchen keine Spielregeln, wird sind doch Erwachsen und wissen wie wir uns benehmen müssen. Ein schöne Annahme, die aber leider so gar nicht stimmt. Ein Beispiel gefällig? Stellt euch mal für eine kurzen Augenblick vor in einem Fußballspiel gäbe es keine Regeln. Das Tor der Heimmannschaft ist natürlich um vieles kleiner. Gelbe oder rote Karten für schwere Fouls gehören der Vergangenheit an. Gezählt wird erst ab dem dritten Tor. Ich glaube ihr wisst was ich meine. Wieso sollte das in einem Workshop oder Projekt anders sein? Deshalb möchte ich euch an dieser Stelle einen Vorschlag für drei konkrete Spielregeln aus der Praxis machen:

1. Unterschiede sind erwünscht. Was wäre ein Workshop oder ein Projekt in dem jeder Teilnehmer derselben Meinung ist? Noch schlimmer wenn keine Meinungen geäußert werden, vielleicht weil der Chef mit in der Runde sitzt.
2. Vertrauen. Vertrauen ist der Grundsatz für eine produktive Zusammenarbeit. Macht die Arbeit an gemeinsamen Zielen überhaupt Sinn, wenn ich den Anwesenden kein Vertrauen entgegen bringen kann?
3. Aktive Teilnahme. Wie das Wort Teilnehmer schon sagt, ich NEHME TEIL an etwas. Das heißt nicht, ich sitze bei, ich höre bei oder ich liege bei.

Ich bitte euch um eure Kommentare. Welche Regeln fehlen in der Aufzählung?

Letzte Woche war ich in Sachen Teamentwicklung auf Weiterbildung. Dabei habe ich das Modell von David Kantor kennen gelernt, das ich euch gerne weiter geben möchte:

Nach Kantor sind in einem effektiven Gespräch alle oben erwähnten Positionen präsent und im Gleichgewicht. Wenn zum  Beispiel nur Anhänger/Unterstützer in einem Team vorhanden sind, wird es schwierig eine gemeinsame Richtung zu finden. Wenn hingegen nur treibende Kräfte/Initiatoren im Spiel sind, wird niemals etwas ausgeführt werden.

Kennt ihr folgende Situation? Ein Kunde erzählt euch sein Problem. Bei euch macht es klick, der Fall ist doch sonnenklar. Es kann doch nur diese eine Lösung geben. Würde der Kunde bei eurem Kollegen anfragen, wäre die Lösung wahrscheinlich eine völlig andere. Wir sind es gewohnt Lösungen auf einer bestimmten Ebene zu suchen. Diese Ebene muss jedoch nicht zwangsläufig die richtige für den Kunden sein. Folgende Ebenen gilt es zu unterscheiden:

1. Persönlichkeit: Das Verhalten von Mitarbeiter Max Mustermann führt immer wieder zu Problemen im Unternehmen. Indikator für diese Problemebene ist, wenn das Verhalten in anderen Kontexten (Familie, Freundeskreis, frühere Arbeitsstelle) ebenfalls auftritt.
2. Rollenkompetenz und Rollenidentität: Max Mustermann kommt erstmals in die Rolle des Projektleiters. Leider hat er sein Team absolut nicht im Griff. In anderen Kontexten tritt das problematische Verhalten nicht auf, jedoch in der neuen Rolle des Projektleiters schon.
3. Informelles System: Immer wenn neue Ideen aufkommen, werden diese “systematisch” nieder gemacht. Wir haben hier einfach keine Kultur, um Innovationen zu entwickeln. Hier gilt es das Unternehmen als ganzes zu verstehen und gezielt zu beeinflussen.
4. Strukturelle Rahmenbedingungen: Hierbei spielen Aspekte der Aufbau- und Ablauforganisation eine zentrale Rolle. Der Auftraggeber hängt dem Projektleiter zwar die Verantwortung für eine Aufgabe um, aber Macht etwas zu entscheiden hat er nicht.
5. Fachliche Fragestellung: Ein neues EDV-System wird eingeführt. Weil aber niemand geschult wurde, entsteht unnötig Stress. Wenn das Verhalten nur im Zusammenhang mit einer besonderen Aufgabenstellung in Erscheinung tritt, ist auf Ebene der Fachkompetenz zu suchen.

Natürlich treten Probleme nicht immer nur auf einer Ebene auf. Es fühlt sich zumindest so an, als würde ALLES mit ALLEM zusammenhängen. Was ist aber für den Kunden wirklich wichtig, um in der aktuellen Situation weiter zu kommen?

1. Projektabschlussbericht: Abschlussberichte zu schreiben scheint so aufregend zu sein wie Wäsche waschen. Zugegeben, ich schreibe ebenfalls ungern Berichte. ABER Lessons Learned sollten auf alle Fälle dokumentiert werden.
2. Prozessbericht: Ich traue mich zu wetten viele von euch haben dokumentierte Prozesse (ISO & Co). Werden diese Prozesse aber auch gemessen bzw. gesteuert? Eher nicht, sonst wären die Zugriffszahlen höher
3. Business Process Reengineering: Die Idee des “Grüne Wiese” Ansatzes wird uns sicherlich noch in alle Ewigkeit begeistern. Wie wäre es wenn ich das Unternehmen wie mit Lego Klötzen neu bauen könnte? Leider hinkt die Realität den überhöhten Erwartungen beim NEU designen der Prozesse immer wieder hinter her.
4. Total Cycle Time (TCT): Eine weitere Methode zur Prozessoptimierung, die sich neben den Platzhirschen KAIZEN und KVP niemals richtig durchsetzen konnte.
   
5. Zukunftsanalyse bzw. Szenario-Technik: Das spielen mit möglichen Zukunftsszenarien ist eine reizvolle Angelegenheit. Leider sind die Methoden nicht sonderlich einfach in der Anwendung. Schnell und Einfach sollte es gehen!
6. Projektfortschrittbericht: Das leidige Thema mit den Berichten. Wer schreibt die schon gerne. Wer liest die schon gerne. Wobei sicherlich niemand bestreitet, dass sie wichtig wären. Vor allem wenn ein Projekt in Schieflage gerät.
7. Wertkurve: Eigentlich ein recht geschicktes Werkzeug, um Angebote geschickt zu gestalten und am Markt zu platzieren. Leider ein wenig off-topic für eine Seite mit dem Schwerpunkt Projekt- und Prozessmanagement.
8. Projektkostenplan: Auf den ersten Blick kaum vorstellbar. Dennoch sind Kostenpläne offensichtlich ein Pflicht die gerne unter den Tisch gekehrt wird. Vielleicht weil Kosten häufig schwer einschätzbar sind? Vielleicht weil man gerne auf Schätzungen festgenagelt wird?
9. Benchmarking: Wie stehe ich im Vergleich zu meinen Mitbewerbern da? In meiner Wahrnehmung eher ein Werkzeug für die großen Spieler im Konzert. Für KMUs eher weniger relevant bzw. recht schwer in der Durchführung. Ein Besuch auf der Branchenmesse soll auch schon geholfen haben.
10. Value Chain Analysis: Wohl mehr Modell als eigentliche Methode. Die Wertschöpfungskette des Unternehmens ist ein schönes gedankliches Modell. Doch was kann ich damit konkret tun? Was ist der offensichtliche Nutzen der Übung?

————————————————————————————————————————————
Update 24.11.2010: Sämtliche PM-Tools nun auch auf Englisch zum kostenlosten Download unter Free PM-Tools.

Beim letzten Workshop ist mir am Eingang zum Seminarraum der Hirschmann Besprechungsknigge aufgefallen:

1. Ich erscheine pünktlich und bin vorbereitet.
2. Mein Handy ist lautlos geschaltet wenn ich es dabei habe.
3. Ich bin konzentriert und bringe mich aktiv zum Thema ein.
4. Ich spreche nur für mich selbst – „Ich-Form” statt „wir” oder „man”.
5. Ich bewerte keine Personen – ich bewerte Sachverhalte.
6. Ich fasse mich kurz und drücke mich verständlich aus.
7. Ich höre anderen zu und lasse sie ausreden.

Wie sehen die Spielregeln für wertschätzende und effiziente Meetings in deinem Unternehmen aus? Ergänzungen per Kommentar sind ausdrücklich erwünscht!

• Ken Schwaber: “Scrum, But …“. Der SCRUM Guru spricht zu seinen Jüngern.
• Boris Gloger und Oliver Zeiler: “Scrum bei der ImmobilienScout GmbH. Implementierungsstrategie und Erfolge, Probleme und deren Lösungen“. Boris Gloger ist ein bekannter SCRUM Coach/Trainer/Evangelist, vor allem durch sein aktuelles Buch. Im Vortrag sind die Lessons Learned zum Schluss hin lesenswert.
• Alexander Kriegisch: “Product Burndown Chart 2.0 – besseres agiles Reporting“. Herr Kriegisch zeigt auf, wie ein erweitertes Burndown Chart aussehen sollte. Insbesondere zur Kommunikation mit dem Management.
• Jan Ebert und Reines Vicups: “SCRUM und professionelles Anforderungsmanagement – ein Widerspruch oder nur eine Frage der Vorgehensweise?“. Scrum sagt wann Anforderungen erhoben werden sollten, aber nicht WIE. Hier eine mögliche Antwort die mir gut gefällt.
• Hans Peter Korn: “Teambuilding für agile Teams – OHNE etwas von Teamdynamiken verstehen zu wollen“. SCRUM geht nicht einfach so, es benötigt auch das richtige Team dazu. Hierzu einige wichtige Perspektiven.
  

Die GPM stellt einen sogenannten Methodenwürfel zur Verfügung. Sämtliche Methoden werden in einen Würfel gepackt und nach drei Dimensionen gruppiert:

• Projektphasen: Initialisierung, Definition, Planung, Steuerung und Abschluss.
• Prozessgruppen: Ablauf & Termine; Information, Dokumentation & Kommunikation; Kosten & Finanzen; Organisation; Qualität; Ressourcen; Risiko; Projektstruktur; Verträge & Nachforderungen; Ziele.
• Methodenart: Kreativitätsmethoden, Analysemethoden, Prognosemethoden, Entscheidungsmethoden, Kommunikationsmethoden, Planungsmethoden, Steuerungsmethoden.

Aktuell kann über die genannten Auswahlkriterien auf 43 Methoden zugegriffen werden. Einige Methoden sind mir bei näherer Betrachtung besonders aufgefallen:

• Blogs: Über Blogs im Projektmanagement habe ich ja bereits häufiger berichtet, z.B. “Blogs im Projektmanagement – Quo vadis?“. Bin auf jeden Fall ein großer Fan
• Enterprise 2.0: Hierbei ist mir nicht ganz klar was DIE Methode ist. Eigentlich wird “nur” eine Sammlung von Web 2.0 Tools geboten, wie z.B. Doodle oder Mindmeister.
• Staggering: Das Ziel der Methode ist es den Engpass in einem Projekt so zu planen, dass er möglichst produktiv eingesetzt werden kann.

Grundsätzlich begrüße ich die Initiative der GPM mit dem Methodenwürfel sehr. Ich bezweifle jedoch stark das der Methodenwürfel die “Komplexität in der Planung” verringert. Ja, ich bekomme einen guten Überblick der vorhandenen Methoden. Welche Methode ich jedoch in welcher Reihenfolge anwenden muss bleibt völlig offen. Für Profis ist das kein Problem, wenn der eigene Methodenkasten lediglich erweitert oder verfeinert wird. Für alle die jedoch erst auf dem Weg dahin sind, wird sich der Nutzen in Grenzen halten. In diesem Fall empfehle ich ein standardisiertes und zudem kostenloses Projekthandbuch, auch oder gerade weil es die Planungsfreiheit erheblich einschränkt!

Projektmanagement RT von Eberhard Huber:

• Zusammenfassung Projektmanagement – Checklisten

Komplexitätsmanagement in Projekten und Unternehmen von Peter Addor:

• Lessons Learned ist tot, es leben die Learning Stories

MacPM.net:

• Post-Mortem-Fragen im Projektmanagement
• Projekte per Ishikawa-Diagramm strukturieren

PM- Blog von Stefan Hagen:

• Projektstrukturplan (PSP) – Plan der Pläne
• 30 Minuten Projektplan (Version 2.0)
• SWOT-Analyse im Projektmanagement

PM-Beratung von Andreas Heilwagen:

• Aufgabenliste und Zeitinventur (Template/Vorlage) – Woher bekomme ich mehr Zeit?
• Lessons Learned (Template/Vorlage) – was können wir zukünftig besser machen?
• Funktionendiagramm (Template/Vorlage) – Kompetenzen, Aufgaben, Rollen

Danny Quick – IT in Unternehmen:

• Tipps zur Wiki-Einführung