ZCOPE Blog

Checkliste für gute Moderation

Das ist ein Gastbeitrag von Mag. (FH) Markus Scheffknecht, Bereichsleiter Marketing bei Meusburger Georg GmbH & Co KG.

Checkliste für gute Moderation

Bei Start und Landung angeschnallt: Wie beim „Fliegen“ sind Anfang und Ende eines Meetings wichtig. Die freundliche Beratung und persönliche Begrüßung und Wertschätzung der Teilnehmer steht am Anfang!

Konferenzprinzip FILO (First in, Last out):

• Agenda: Zeitbudget, Struktur und Ziel der Sitzung klären
• Gleichen Informationsstand bei allen Beteiligten gleich zu Beginn schaffen und möglichst viel Zeit für die Entscheidungsphase einplanen
• Veranstalterrolle wahrnehmen (Räumlichkeiten organisieren,…)
• Nicht bis zu letzten Minute was Anderes machen
• Ankommende Teilnehmer begrüßen, sich einstimmen

Protokollfunktion: Protokoll öffentlich (am Flipchart, Beamer,…) und simultan führen. Abschließend die Punkte nochmals durchgehen, Commitment erreichen. Anschließend aufräumen (Fotoprotokolle).

• Quantitatives Ergebnisprotokoll mit meßbaren Zielen
• Maßnahmen (Wer, Was, Wann)
• Offene Punkte-Liste

Wer schreibt, der bleibt: Schriftlichkeit bedeutet den Zwang zu einer Struktur und zur Konzentration auf das Wesentliche. Transparenz erzeugen, Schwafeln verhindern.

Rolle des personifiziertes Fragezeichens einnehmen:

• Wer fragt, der führt
• Offene W-Fragen stellen (Wer, was wie, womit, wann, wodurch,…)
• Frageliste vorbereiten
• Wer anlassorientiert aufsteht, bekommt Moderationsfunktion. Plätze bzw. Anlässe schaffen!

Betriebswirtschaftliches Know How einbringen:

• Gespür für Zahlen, ökonomische Logik prüfen
• Sachlich richtige Fragen stellen gibt Akzeptanz
• Als Coach und Trainer wirken: Wissen weiter geben

Angenehme Atmosphäre schaffen: Moderator kommt von moderat: (Ab)wertungen und Pauschalkritik vermeiden, Beziehungsebene beachten, gezieltes Lob spenden, für gute Stimmung sorgen.

Das Ergebnis auf sich wirken lassen: Stolz auf das Geleistete sein!

Gastbeiträge auf dem ZCOPE Blog

Neben unseren „Veteranen“ Stefan Hagen und Patrick Fritz werden wir zukünftig immer mal wieder einzelne Artikel von Personen veröffentlichen, die in irgendeiner Form an Projekten beteiligt sind: bei uns sollen alle Stakeholder zu Wort kommen. Den Anfang machte Christian Gaisberger, der in seiner Funktion als Entwickler seit zehn Jahren an einer Vielzahl an Projekten beteiligt war und ist.

10 Wege, einen guten Software-Entwickler zu vertreiben

Das ist ein Gastbeitrag von Christian Gaisberger, seit 10 Jahren Entwickler für Webanwendungen. Er führt Projekte für Großunternehmen aus verschiedenen Branchen durch und wechselt nicht nur im Rahmen seines Studiums immer wieder einmal auf die Seite des Projektmanagers.

1 Bezeichne den Prototyp, an dem er vier Wochen gearbeitet hat, ohne weitere Diskussion als völlig unbrauchbar und gib das Projekt heimlich an einen seiner Teamkollegen weiter.
Besonders effektiv ist diese Maßnahme, wenn beide zusätzlich noch gut befreundet sind.

2 Zermürbe ihn mit Anforderungsänderungen bis er jede Eigeninitiative aufgibt. Danach lasse ihn mit einem Projekt ohne jede Spezifikation völlig alleine zurechtkommen.

3 Antworte auf jedes seiner Probleme mit „Du schaffst das schon!“ oder mit „Es läuft doch alles super!“. Das gibt ihm das Gefühl, dass alle seine Probleme unwichtig sind und er
nichts weiter als ein Querulant und Schwächling ist – ohne dass Du als demotivierend bezeichnet werden kannst.

4 Negiere bereits gegebene schriftliche Anweisungen, behaupte ursprünglich das Gegenteil angeordnet zu haben und bezichtige ihn der plumpen Fälschung. Softwareentwickler sind ja schließlich fachlich in der Lage E‐Mails zu fälschen.

5 Setze ihm einen halb so alten Berufsoptimisten als Teamleiter vor die Nase, obwohl er eigentlich die Position schon längst verdient hätte und wiederholt übergangen wurde. Bitte ihn für die Maßnahme mit hochrotem Kopf und einem verlegenen Gesicht um Verständnis. Das wird ihm ein schlechtes Gewissen verpassen und er wird sich fragen, wieso er überhaupt nur dran denken konnte, diesen unverdienten Posten an sich zu reißen.

6 Gib ihm ein herausforderndes Projekt, damit er sich als Projektleiter beweisen kann. Hängt er sich dann voll rein, nimm es ihm nach zwei Wochen ohne Vorwarnung mit der
Begründung wieder weg, er sei ohnehin nur die Urlaubsvertretung gewesen.

7 Bestehe darauf, dass das neue Content Management System auf den Sharepoint Server installiert wird, obwohl er wiederholt davor gewarnt hat. Wenn es schief geht, beschwere Dich, warum er nicht gleich davor gewarnt hat.

8 Beschneide sein Budget für einen Ersatz für den aus dem letzten Loch pfeifenden Mailserver, den er seit einem Jahr verlangt. Mit dem Geld veranstaltest du stattdessen eine Eröffnungsparty für eine neue Niederlassung, auf die dann kein Mensch kommt, weil der Ort auf den Plakaten fehlt. Vergiss nicht, die Party als Riesenerfolg schön zu reden.
Wenn der Mailserver schließlich dann doch zusammenkracht, gib ihm die alleinige Schuld. Nach einem Jahr feuere alle Mitarbeiter und schließe die Niederlassung.

9 Gib ihm den Auftrag, ein Web‐Formular nicht als Pop-up zu gestalten. Warte eine Woche. Ändere Deine Anweisung auf „Pop-up“. Warte wieder eine Woche. Ändere Deine
Meinung wieder auf „Nicht Pop-up“. Ist er ein alter Hase, kennt er das Spiel bereits und wird erst jetzt mit der Umsetzung beginnen. Warte wiederum eine Woche. Ändere Deine
Anweisung abermals. Mach‘ ihn zur Schnecke, weil das Formular nicht Deinen Vorstellungen entspricht. Besonders wirkungsvoll ist dies bei Anfängern, die sind nämlich noch formbar.

10 Wenn obige Maßnahmen Erfolg hatten und der Entwickler kündigt, schenke ihm bei seiner Abschiedsfeier nichts. Schließlich soll man ihn für sein illoyales Verhalten dem
Unternehmen gegenüber nicht auch noch belohnen. Auch wenn er vielleicht einige Jahre dabei war und die Abschiedsgeschenke für die früheren Kollegen organisiert hat.

Simplify your Projects!

Gastbeitrag Stefan Hagen:

Das Motto meines PM Blog lautet: “Simplify your Projects!” Heute möchte ich kurz erläutern, warum ich für einfaches, pragmatisches und “unternehmerisches” Projektmanagement bin.

In der Praxis stoße ich immer wieder auf zwei Extremsituationen. Entweder sind Unternehmen im Projektmanagement extrem überorganisiert oder extrem unterorganisiert.

1) Zuerst zu den Überorganisierten. In diesen Unternehmen haben die Techniker, Methodiker und Qualitätsmanager das Projektmanagement übernommen. Diese Aussage ist übrigens nicht abwertend gemeint. Aber es ist ganz einfach Fakt, dass bestimmte “PM Kulturen” in Unternehmen durch ein überaus formalisiertes und standardisiertes Projektmanagement gekennzeichnet sind. Ohne Formular, Verfahrensanweisung oder Bewilligung läuft hier gar nichts. Ich kann nur sagen: In so einem Unternehmen würde ich niemals arbeiten wollen. Der Motivations-Killer schlechthin für innovative Teams.

2) Nun zu den Unterorganisierten. Häufig sind in diesen Organisationen die leitenden Führungskräfte bis hin zum Geschäftsführer / zur Geschäftsführerin sehr pragmatisch und praxisorientiert unterwegs. Und das ist in ganz vielen Situationen auch gut so. Aber eben nicht in allen. Denn gerade bei komplexen und riskanten Projektvorhaben ist es elementar wichtig, ein Mindestmaß an Systematik, Disziplin und Methoden anzuwenden. Ich betone: ein Mindestmaß. Soviel wie nötig, nicht soviel wie möglich.

Die zweitgenannten Unternehmen sind häufig einfacher zu “therapieren”. Denn wenn man sich nicht ganz dumm anstellt, kann man die Mitarbeiter recht rasch davon überzeugen, dass ein pragmatisches, schlankes Projektmanagement mit ganz elementaren Spielregeln einfach Sinn macht. “Simplify your Projects” eben.

Was zeichnet eine solche Projektmanagement Philosophie aus?

• Denke nach, dann HANDLE!
  
• Reagiere schnell auf Veränderungen, LERNE!
• KOMMUNIZIERE kontinuierlich und aktiv!
• SCHÜTZE Dein Team vor Angriffen von außen!
• Lass Widersprüche zu und sorge für EMOTIONEN!

Die Projektmanager, die diese Grundregeln befolgen, sind in erster Linie gute Manager. Denn Projektmanagement ist nichts Mystisches, nichts wirklich Schwieriges.

Schalte den Hausverstand ein, wende einfache aber wirkungsvolle Methoden an, sorge für effiziente und effektive Meetings, kommuniziere unaufhörlich, schaffe Transparenz und Klarheit, schaffe vor allem auch Verbindlichkeit und HANDLE! Geh’ die Dinge und Probleme aktiv an. Denn durch Zuschauen, Pläne zeichnen und schöne Reden schwingen ist noch kein Projekt ein Erfolg geworden.

Agiles Projektmanagement

Nach längerer Zeit melde ich mich wieder mal mit einem kleinen Gastbeitrag in der ZCOPE Community.

Wie Sie wissen, basiert ZCOPE auf einem agilen Projektmanagement-Verständnis. Damit sind u.a. folgende Prinzipien verbunden:

• Kommunikation und Interaktion stehen im Zentrum
• Einfachheit und Pragmatismus statt Bürokratismus und blinder Methodengläubigkeit
• soviel Planung und Dokumentation wie nötig, nicht soviel wie möglich
• kontinuierliche Weiterentwicklung des Projekts und deren Inhalte (iteratives Vorgehen), kontinuierliche Änderungen
• schnell funktionierende Lösungen erarbeiten

Sind diese (agilen) Prinzipien nur in Softwareentwicklungsprojekten anwendbar? Nein. Ich meine, dass diese Prinzipien auf sehr viele Projektarten übertragbar sind. Entscheidend ist jeweils, dass Sie die richtige Mischung zwischen stabilen Rahmenbedingungen und agilem, flexiblen Vorgehen finden. Ich möchte dies am Beispiel eines Innovations- oder Produktentwicklungsprojekts kurz erläutern.

A) Bei Innovationsprojekten macht es nach wie vor Sinn, sich an erprobte Stage-Gate-Modelle anzulehnen. Klare Milestones, klare Entscheidungskriterien, klare Prozesse.

B) Eine Detaillierungsebene tiefer sind die verschiedenen Dimensionen des Projekts (häufig deckungsgleich mit den involvierten Fachabteilungen) zu planen, vergleichbar mit dem RUP-Vorgehensmodell (Rational Unified Process).

Übertragen auf ein Innovationsprojekt könnte dies bedeuten, dass die Dimensionen Ideengenerierung, Businessplanung, Design, Konzeption & Spezifikation, Technik etc. über den gesamten Projektverlauf in unterschiedlichen Intensitäten vorkommen.

C) Wiederum eine Ebene tiefer folgt nun das klassische agile, iterative Vorgehen, welches aus einem an den PM Prozess des Project Management Institute angelehnt sein könnte.

Hier geht es darum, auf der operativen Ebene Inhalte, Ziele, Spezifikationen, Aufgaben, Kommunikationsimpulse etc. immer wieder zu initiieren, zu planen, umzusetzen, begleitend zu steuern und zu überwachen und schlussendlich abzuschließen.

Diese Systematik lässt sich meines Erachtens auf Innovations- und Produktentwicklungsprojekte sehr gut umlegen. Denn gerade in der Kombination von traditionellen, stärker auf Stabilittät ausgerichteten Vorgehensmodellen und agilen Methoden, Prinzipien und Prozessen liegt die große Chance.

Stefan Hagen
PM-Blog.com