Projektmanagement ist das Betriebssystem für Innovation

Heute durfte ich an der Konferenz Digitale Zukunft@Mittelstand des DIHK teilnehmen.
Es ging dabei zunächst ganz allgemein um Digitalisierung und was Digitalisierung für die Industrie bzw. den deutschen Mittelstand und Maschinenbau bedeutet. Zum einen wurden Randbedingungen, die notwendig sind um Digitalisierung voran zu treiben oder erst ermöglichen, vor allem mit der Politik diskutiert. Dominierend waren natürlich Themen wir Breitbandausbau, Datensicherheit und Bildung.

PMMB009: Meine Top-10-Projektsprüche - Da werde ich hellhörig

In den vergangenen 15 Jahren, in denen ich in Projekten arbeite, sind mir eine Menge Situationen und auch Sprüche begegnet, die bei mir hängen geblieben sind. Dabei sind einige Wahrheiten, aber auch einige Glaubenssätze, die nicht unbedingt geeignet sind um gutes Projektmanagement zu unterstützen.

In dieser Episode teile ich die 10 Projektsprüche mit Dir, die ich am besten finde und erkläre Dir, was ich dazu denke.

Meine Top-10-Projektsprüche:

10. „Probleme sind Rudeltiere.“

9. „Die wissen schon, was sie tun müssen.“

8. „Wenn jeder nur machen würde, was er soll…“

7. „Wir haben eine Software fürs Projektmanagement.“

6. „Wir sitzen hier zu viel in Meetings und arbeiten zu wenig.“

5. „Ich kann aber erst arbeiten, wenn xy fertig ist.“

4. „Wir planen hier nicht… das trifft eh nie ein.“

3. „Das planen wir nicht ein. Sonst wird das Projekt zu teuer/ dauert zu lange…“

2. „Das Arbeitspaket ist zu 70% erledigt“

1. „Ich habe keine Zeit meine Planung zu aktualisieren“

Meine Top-10-Projektsprüche – Da werde ich hellhörig

Du hast dich vielleicht etwas gewundert und dich gefragt, was kommt denn in dieser Episode auf mich zu? Der Titel ist ja vielleicht etwas merkwürdig, es geht um meine Top 10 Projektsprüche, bei denen ich hellhörig werde, wenn sie meinen Projekten begegnen.

Und ja, es wird auch ein Beitrag werden, der vielleicht etwas anders ist, als die, die wir die vergangenen Male hatten.

Ich habe neulich Abend beim Aufräumen etwas Zeit damit verbracht, mal durch meine alten Kunden und mal durch die Projekte zu blättern, die ich in den letzten 15 Jahren so alle machen durfte. Und da kommen natürlich ganz schön viele Erinnerungen hoch. Erinnerungen an Situationen, an Anekdoten, an Sachen, die gut funktioniert haben; an Sachen, an Situationen, wo wir auch einfach mal gescheitert sind.

Also viele spannende und manchmal auch lustige Situationen. Und natürlich sind mir in dieser Zeit auch ganz schön viele gute und manchmal auch weniger gute Sprüche, Sätze, begegnet, die ich mir irgendwann mal begonnen habe, einfach aufzuschreiben und die ich heute ganz gerne mit dir teilen möchte. Sozusagen meine ganz persönliche Top 10 der Projektsprüche.

Da sind schon einige Wahrheiten dabei. Aber natürlich auch der eine oder andere Glaubenssatz, der jetzt nicht unbedingt förderlich ist, der nicht unbedingt gutes Projektmanagement zu unterstützen. Das heißt, diese Episode ist zum einen so ein bisschen für mich gedacht, um mal so ein bisschen in der einen oder anderen Erinnerung zu schwelgen, zum anderen aber für dich. Weil ich ganz gerne diese Sätze nutzen möchte, um meine Sicht darauf mit dir zu teilen, wie denn gutes Projektmanagement sein sollte. Und ich glaube, das kann man ganz gut transparent machen, wenn man mal durch diese Sprüche durchgeht. Das ist eine tatsächliche Top 10. Das heißt, wir werden uns hoch hangeln. Wir starten mit meiner Nummer 10 und enden mit der Nummer 1.  Ja, es fiel mir sehr oft schwer jetzt, da tatsächlich eine Reihenfolge reinzubringen, aber am Ende des Tages ist es mir doch gelungen.

Probleme sind Rudeltiere

Also meine Nummer 10, die ist relativ jung und ist in einem Projekt entstanden, das ich noch gar nicht solange betreue. Der Satz zur Nummer 10 ist: Probleme sind Rudeltiere.

Was dahinter steckt, ist; wir waren einfach in der Situation, in einem Projekt und haben es aufgeplant. Hatten glaube ich, eine schöne Transparenz; sind gut vorangekommen, konnten die Arbeitspakete gut verfolgen. Und ja, es lief eben wie am Schnürchen. Und innerhalb von einer Woche sind dann zwei, drei relativ gravierende, schwerwiegende, technische Probleme auf den Tisch gekommen. Und das hat dann mein Systementwickler so zu diesem Satz veranlasst, zu sagen: „Probleme scheinen ja Rudeltiere zu sein“. Und da hat er ein Stück weit recht.

Ich habe mich dann mal so ein bisschen mit der Situation auseinandergesetzt, wie kam es denn dazu? Und es gibt so eine Beobachtung, dass ich denke – und da neigen wir als Projektleiter immer mal wieder dazu -, dass in Phasen im Projekt, in denen es gut läuft, in denen es rund läuft; in denen wir im Prinzip nur dabei sein müssen und das Team so am Arbeiten ist und die Themen im Prinzip nur Stück für Stück abarbeitet, wir gelegentlich mal im Kopf so ein klein wenig träge werden. Und die Risiken, die weiterhin im Projekt stecken – in dem Fall waren es technische Risiken – mal so ein bisschen außer Acht lassen, vielleicht ein kleines bisschen bequem werden.

Und dann Dinge die am Horizont hochkommen, die unser Projekt negativ beeinflussen können, nicht so sehr im Griff haben, wie wir es tun würden, wenn wir dann vielleicht etwas alarmierter werden. Und dann erscheint das tatsächlich so, dass Probleme zu Rudeltieren werden, weil dann tauchen sie nämlich auch geballt auf. Also meine Nummer 10: Probleme sind Rudeltiere.

Die wissen schon, was sie tun müssen

Kommen wir zur Nummer 9. Und den Satz höre ich ganz oft, wenn ich neu in Projekte reinkomme und mal so ein bisschen frage: Wo habt Ihr denn die Planung, welche Arbeitspakete gibt es denn? Wer muss denn was, bis wann machen? Und da höre ich ganz oft meine Nummer 9, da fällt dann so ein Satz, wie: Die wissen schon, was sie tun müssen, fatalerweise gelegentlich auch mal von Projektleitern.

Was steckt denn da dahinter? Sehr oft meint die Person die diesen Satz sagt: „Die wissen schon, was sie tun müssen“, verweigert damit im Prinzip die Planung. Der sagt: „Na ja, das ist deren Tagesgeschäft, die wissen schon alles, was sie tun müssen, das muss ich gar nicht aufschreiben. Das müssen wir gar nicht in einem Plan niederschreiben, das passt schon“. Das ist eine sehr gute Entschuldigung, eine sehr gute, ich würde fast sagen, Ausrede, eine Planung nicht tun zu müssen.

Selbstverständlich ist es so, dass meine Experten im Projekt sehr oft relativ genau wissen, was sie denn zu tun haben. Was sie aber nicht wissen und das können sie gar nicht wissen, weil das in jedem Projekt sehr oft anders ist; wie das, was sie zu tun haben, sich denn einbettet, in die anderen Arbeitspakete. Wie es zusammenhängt, mit anderen Dingen, die wir im Projekt machen müssen. Und um diese Zusammenhänge klarzumachen, macht das aus meiner Sicht Sinn, auch die Dinge die eh klar sind (vermeintlich eh klar sind), mal aufzuschreiben, runter zu planen und so in einen Kontext zu bringen.

Und ja, das ist jetzt so meine private, persönliche Erfahrung. Sehr oft stelle ich fest, wenn ich mit denen spreche, die eh wissen was sie tun müssen, dass es gar nicht so wirklich klar ist, was denn ihre nächsten Schritte im Projekt sind. Und sehr oft ist das dann tatsächlich auch ein Grund, warum Projekte so ein bisschen in der Sackgasse stecken.

Also bitte, liebe Projektleiter da draußen, bitte verschanzt euch nicht hinter dieser Behauptung, dass die anderen eh schon wissen würden, was sie zu tun haben und dass dann auch alles gut wird. Es ist eure Verantwortung, die Dinge klarzumachen, es ist eure Verantwortung, die Dinge zusammenzubringen und in einen Kontext zu bringen.

Wenn jeder nur machen würde, was er soll…

Und dann sind wir auch schon bei der Nummer 8, den ich auch sehr oft höre. Meistens in Projekten, in denen – wie soll ich sagen? – ja, die Stimmung vielleicht etwas angespannt ist. In Projekten, die etwas kritischer sind, die hinter ihren Zeitplan geraten sind und so weiter und so fort.

Die Nummer 8 heißt nämlich: Wenn einfach nur jeder mal machen würde, was er soll…  Ich ergänze den Satz: dann wird schon alles gut.

Wenn einfach nur jeder mal machen würde, was er soll. Das hat meistens so ein bisschen einen anklagenden Unterton; ich mache ja alles, aber die anderen tun es nicht. Wenn man dann mal guckt, was da so ein bisschen die Hintergründe sind, dann ist es sehr ähnlich wie mit der Nummer 9. Sehr oft weiß ich nämlich gar nicht was ich tun soll, als Teammitglied, weil wir das im Projekt noch gar nicht ausgehandelt haben. Ich kenne meine Arbeitspakete nicht oder ich kenne sie nur teilweise. Ich weiß gar nicht, wie denn so die Verbindungen zu anderen Arbeitspaketen sind und so weiter und so fort. Und deswegen kann ich das vielleicht gar nicht so wirklich tun, was denn da der Projektleiter oder andere von mir erwarten.

Ich glaube, es ist unsere Aufgabe als Projektleiter, hier für Klarheit, für Transparenz, für gemeinsames Wissen zu sorgen. Das heißt, dafür zu sorgen, dass jeder weiß, was er denn tun soll. Das auch mit ihm abzustimmen, dass er das tut, was wir da von ihm erwarten. Und dann auch nachzufolgen, dass er das tatsächlich tut. Also das sind diese drei Schritte, die da sehr oft fehlen. Und ja, es ist unsere Aufgabe als Projektleiter, dafür zu sorgen. Das war meine Nummer 8: Wenn jeder nur machen würde, was er soll.

Wir haben eine Software fürs Projektmanagement

Meine Nummer 7 hatte ich in der Vergangenheit sehr oft. Ich glaube, da hat sich so ein bisschen Wissen hinzu addiert in den vergangenen Jahren, die Nummer 7 ist: Wir haben hier eine Software für das Projektmanagement. Verbunden mit diesem Blick hinterher; ich weiß gar nicht, warum wir einen Projektleiter brauchen, wir haben doch eine Software.

Und diesen Satz höre ich in den letzten Jahren eher seltener, weil ich glaube, dass sich da einfach eine Erkenntnis breitgemacht hat. Ich glaube, das ist der größte Blödsinn, den man tatsächlich sagen kann.

Eine Software macht kein Projektmanagement, sondern eine Software unterstützt maximal das Projektmanagement; macht es effizient, macht es einfacher, Listen zu erstellen, Termine zu verfolgen, zu filtern, zu selektieren zuzuordnen und so weiter und so fort.

Projektmanagement ist aber eine Methode, ist eine Vorgehensweise, setzt sich aus verschiedenen Instrumenten zusammen, die die Software dann gerne unterstützen darf. Aber eine Software alleine, macht kein gutes Projektmanagement. Bitte behaltet das im Kopf. Die Software wird nicht euer Problem lösen, sondern sie wird nur euch unterstützen, die Probleme die ihr habt, effizient zu bearbeiten. Deswegen meine Nummer 7: Wir haben eine Software für Projektmanagement.

Wir sitzen hier zu viel in Meetings und arbeiten zu wenig

Nummer 6 hingegen, höre ich sehr, sehr oft und das ist so ein bisschen der Klassiker. Der Klassiker der Menschen, die zu viele Projekte haben. Nummer 6 heißt nämlich: Wir sitzen hier zu viel in Meetings und arbeiten zu wenig.

Da muss ich sagen; ja, da steckt viel Wahres drin. Ich nehme das auch sehr oft wahr, weil, wenn ich gerade frisch in Unternehmen komme, die Teammitglieder verbringen irre viel Zeit in, ja, ich würde mal fast sagen, sinnlosen Besprechungen; und haben diese Zeit natürlich nicht, um an ihren eigentlichen Arbeitspaketen zu arbeiten.

Gleichzeitig möchte ich an der Stelle eine kleine Einschränkung machen. Projektmanagement hat mit Personen zu tun und hat damit zu tun, dass wir gemeinsam ein Ergebnis abliefern. Und in dem Moment, in dem ich mit Personen zu tun habe, brauche ich Kommunikation. Und ich bin immer noch der Meinung, trotz digitaler Methoden, Chats, Video und so weiter und so fort, ist weiterhin die effizienteste Art miteinander zu kommunizieren, gemeinsam in einem Raum zu sitzen und Dinge zu besprechen. Also auf gut Deutsch; ein Meeting, eine Besprechung zu haben.

Das ist bei allem was ich kenne, weiterhin aus meiner Sicht, die beste Option. Dennoch würde ich unterschreiben, dass wir zu viel in Meetings sitzen. Und das liegt daran, dass unsere Meetings zu wenig zielgerichtet sind, dass wir zu viel Zeit in Meetings verbringen, bei denen wir eigentlich keinen wirklichen Beitrag haben, bei denen keine wirkliche Information für uns übrig bleibt. Und das gilt es tatsächlich zu verhindern.

Ich werde demnächst mal noch einen Beitrag machen zu dem ganzen Thema Projektkommunikation. Da gehe ich dann nochmal detaillierter drauf ein, aber vielleicht schon mal so ein klein wenig vorneweg; schaut, dass eure Meetings effizient sind, dass sie extrem themenbezogen sind. Ich glaube, wir sitzen zu lange in Meetings, aber in zu wenigen. Was ich damit genau meine, erkläre ich dir dann in diesem Beitrag. Das war meine Nummer 6: Wir sitzen hier zu viel in Meetings und arbeiten zu wenig.

Ich kann aber erst arbeiten, wenn xy fertig ist

Nummer 5 ist auch so ein kleiner Klassiker, meine Nummer 5 heißt: Ich kann aber erst los arbeiten, wenn XY geliefert hat oder fertig ist.

Also dieses Warten auf den anderen und damit verbunden, ein klein wenig auch die Entschuldigung: Du kannst mich noch gar nicht fragen, wo ich stehe und wann ich fertig bin, weil XY muss tatsächlich erst mal fertig sein. Ja, es gibt Fälle in denen das stimmt, in denen ich tatsächlich ein Arbeitsergebnis brauche, um mit meinem Arbeitspaket tatsächlich erst losgehen zu können.

Wir sind aber nun mal heute in einer Situation, dass wir kürzere Entwicklungszyklen haben, dass wir sehr enge Marktfenster haben, um mit unseren Technologien und mit unseren Produkten am Markt zu sein und wir es uns in der Regel nicht erlauben können, ich sage mal, sequenziell Dinge abzuarbeiten. Sondern wir sind mehr oder weniger gezwungen, in einen Arbeitsmodus zu gehen, in dem wir die Dinge parallel bearbeiten, indem wir Arbeitspakete parallel hochziehen. Indem wir es gewohnt sind, mit ersten Entwürfen weiterzuarbeiten, mit dem vollen Wissen, dass sich dieser Entwurf in einigen Stellen nochmal ändern wird und ich einen Teil meiner Arbeit wiederholen muss.

In der Summe wird es dadurch aber schneller werden. Das heißt; jawohl, manchmal gilt diese Nummer 5: Ich kann aber erst arbeiten, wenn XY fertig ist. In vielen Fällen gilt sie aber nicht. Und ich glaube, es ist unsere Aufgabe als Projektleiter, hier immer einen cleveren Weg und auch einen Mittelweg zu finden, Dinge parallel zu bearbeiten. An Arbeitspaketen parallel zu arbeiten, ohne jetzt hier zu sehr auf die sequenzielle Abarbeitung zu zielen. Auch dazu werde ich demnächst mal noch einen Beitrag machen, weil ich glaube, das ist ganz wichtig. Das ist einer der Kerndinge, wie ich meine Projekte beschleunigen kann. Also meine Nummer 5, wir sind genau in der Mitte: Ich kann aber erst arbeiten, wenn XY fertig ist.

Wir planen hier nicht… das trifft eh nie ein

Nummer 4 mag ich ganz besonders, auch wieder so ein Klassiker im Projektmanagement, Nummer 4 heißt: Wir planen hier nicht… das trifft eh nie ein.

Und das kann ich unterschreiben und zwar den zweiten Teil des Satzes: Das trifft eh nie ein. Korrekt. Ich kenne kein Projekt, in dem die Planung des Projektes, so wie wir sie am Anfang des Projektes mal aufgesetzt haben, eins zu eins, zu 100 Prozent so eingetreten ist. Das geht gar nicht.

Weil: Projekte beinhalten Risiken, Projekte verändern sich, Projekte haben eine gewisse Laufzeit, wir lernen Dinge hinzu; Anforderungen daran, ändern sich. Das heißt – und ich glaube, das ist etwas, was man als Projektleiter wirklich verinnerlichen muss -, Änderungen im Projekt ist der Normalzustand. Dass sich Dinge ändern, dass sich Anforderungen ändern, dass sich der Weg ans Ziel permanent ändert, das ist der Normalzustand im Projekt.

Und um damit solide umzugehen, brauche ich eine Planung. Weil, erst wenn ich mir überlegt habe, wie ich denn diesen Weg gehen möchte, kann ich erkennen, dass ich einen anderen brauche, weil sich vielleicht eine Anforderung geändert hat und ich kann viel besser diskutieren, an welcher Stelle ich etwas ändern muss. Und um diese Diskussion sauber führen zu können, brauche ich eine Planung.

Von daher meine Nummer 4: Wir planen hier eh nicht, das trifft eh nie ein. Kann ich unterschreiben. Den zweiten Teil, den ersten nicht. Weil, erst wenn ich wirklich gut plane, kann ich auf die Änderungen auch wirklich gut eingehen.

Das planen wir nicht ein. Sonst wird das Projekt zu teuer/ dauert zu lange…

Die Nummer 3 erlebe ich leider auch immer wieder und ich schiebe den Satz mal vorneweg und erkläre dann, was ich damit meine: Das planen wir mal nicht ein, sonst wird das Projekt zu teuer oder alternativ, dauert zu lange oder was weiß ich.

Also die aktive Aufforderung, bestimmte Inhalte im Projekt, Arbeitspakete, Teilprojekte, nicht zu berücksichtigen, die Kosten dafür nicht zu berücksichtigen, die erforderlichen Ressourcen damit nicht zu berücksichtigen; auch die damit einhergehende Dauer der Bearbeitung nicht zu berücksichtigen, damit ein Projekt bestimmte Vorgaben erfüllt, also unter einer bestimmten Budgetgrenze zum Beispiel bleibt.

Ich glaube, das ist eine der größten Lügen. Ja, ich würde fast sogar sagen, Management-Lügen, die wir im Projektgeschäft immer wieder, leider immer wieder finden.

Das heißt, das bewusste Verschließen der Augen vor Kosten, vor Dauern, auch vor Risiken, die damit natürlich einhergehen, um Projekte zu ermöglichen. Ich glaube, es ist unfair allen Beteiligten gegenüber. Wir sollten in unseren Projekten Transparenz haben, wir sollten wissen um was es geht, wir sollten am Anfang klar haben, was wir alles erledigen müssen, damit das Projekt auch zum Ziel kommt, damit es umgesetzt werden kann.

Und wir sollten auch Transparenz über die Konsequenz, über die Folgen haben. Das hat nämlich sonst etwas von – ja, ihr kennt das – duschen, aber nicht nass werden. Wenn ein Projekt eine bestimmte Zielsetzung hat, dann gehen damit ein paar Arbeitspakete einher, die kosten Geld. Dafür brauche ich Personal und die haben eine gewisse Dauer.

Und nur, weil ich sie nicht einplane, heißt es nicht, dass ich sie nicht brauche. Weil ich werde diese Arbeitspakete, wenn ich sie am Anfang nicht auf mein Blatt Papier schreibe, werde ich sie nicht machen müssen, sondern sie werden hochknallen sozusagen. Also bitte liebe Projektleiter, lasst euch nicht ins Bockshorn jagen, wenn ihr Sätze hört, wie meine Nummer 3: Das planen wir mal nicht ein, sonst wird das Projekt zu teuer oder dauert zu lange. Da dürft ihr aus meiner Sicht wirklich auf die Barrikaden gehen. Es ist unsere Aufgabe, unsere Verantwortung auch als Projektleiter, hier für Transparenz zu sorgen.

Das Arbeitspaket ist zu 70% erledigt

Meine Nummer 2 ist etwas, das ich auch immer wieder gerne höre, meine Nummer 2 lautet: Das Arbeitspaket oder die Aufgabe – darfst du ersetzen – ist zu 70 Prozent erledigt.

Ja, also solche Sätze lassen mich meistens etwas verloren zurück. Weil ich wirklich nicht weiß, was ich damit anfangen soll. Ist 70 Prozent viel oder wenig? Sind die verbleibenden 30 Prozent kritisch oder unkritisch? Ist der Großteil der Arbeit – und ich meine jetzt nicht die verstrichene Dauer, sondern den Großteil der geistigen Arbeit, ist der erledigt und fehlt nur noch ein kleines Fitzelchen oder wie ist das denn zu interpretieren?

Aus meiner Sicht sind Arbeitspakete entweder erledigt oder nicht erledigt.

Und wenn ich in meinen Projektteamsitzungen Arbeitspakete verfolge, versuche ich – es klappt nicht immer – versuche ich das aber genauso zu handhaben. Weil Sätze wie: Die Konstruktion ist zu 70 Prozent erledigt, helfen wirklich keinem weiter. Sondern ich möchte wissen, ist es erledigt; ja oder nein? Da bin ich sehr digital dann unterwegs.

Und die zweite Frage ist, wann wird es denn zu 100 Prozent erledigt sein? Und jetzt müssen wir natürlich diskutieren, was bedeutet 100 Prozent? Weil auch ihr kennt das Pareto-Prinzip; es muss nicht immer alles bis ins letzte erledigt sein, um weiter arbeiten zu können. Also diese Diskussion muss man natürlich führen. Aber wenn ich die geführt habe und meine 100 Prozent festgelegt habe, dann interessiert mich tatsächlich nur noch, ob das Arbeitspaket erledigt ist oder nicht. Und bis wann es denn erledigt ist.

Also deswegen hellhörig werden, bei der Nummer 2: Das Arbeitspaket ist zu 70 Prozent erledigt.

Ich habe keine Zeit meine Planung zu aktualisieren

So, und jetzt kommen wir zur Nummer 1. Und die kennt ihr wahrscheinlich, die habt ihr auch schon alle mal gehört. Und ich wette, ihr habt sie auch schon gesagt. Ich schließe mich da auch nicht aus, auch mir ist das schon passiert. Meine Nummer 1 ist: Ich habe keine Zeit, meine Planung zu aktualisieren.

Und jetzt grinst ihr euch wahrscheinlich  in euch rein, weil euch dieser Satz auch schon begegnet ist und weil ihr ihn tatsächlich schon gesagt habt. Sehr oft zu hören in Projekten die kritisch sind, in denen echt viel los ist; in denen Zeit Mangelware ist, Geld keins mehr übrig ist. Der Kunde vor der Tür steht, teilweise mit eigenen Teams schon da ist und wir dann einfach sagen: Ja, wir müssen arbeiten, wir haben keine Zeit um zu planen beziehungsweise unsere Planung zu aktualisieren.

Ich halte das an der Stelle für fatal und ich glaube, dass wir als Projektleiter hier die Aufgabe haben, auch wenn uns der Satz tatsächlich mal rausrutscht, so ein bisschen gedanklich auf die Seite zu treten und zu überlegen; was tun wir denn da eigentlich?

Einer der wesentlichen Dinge, damit Projekte vorangehen, dass sie schnell vorangehen, ist; dass alle Teammitglieder an den richtigen Dingen arbeiten. Und um das sicherzustellen, brauche ich eine Planung. Und gerade in kritischen Projekten, in denen Zeit Mangelware ist, ist es meine Erfahrungen, dass leider sehr, sehr viel Energie, sehr viel Zeit, sehr viel Leistung auf Dinge verbracht wird, die vermeintlich wichtig sind.

Wenn ich mir aber mal meine Planung, meinen Weg ans Ziel angucken würde, stelle ich fest, dass es nicht notwendig ist. Das heißt, wenn ich eine gute Planung habe, die aktuell ist, auf die ich mich verlassen kann, die meinen jetzigen Stand des Projektes widerspiegelt, kann ich deutlich bessere Entscheidungen treffen. Ich kann deutlich schnellere Entscheidungen treffen und ich kann viel besser entscheiden, an was gearbeitet werden soll und was nicht.

Und aus diesem Grund – bitte hier, da rede ich euch jetzt so ein bisschen ins Gewissen – schaut, dass wenn euch dieser Satz über die Lippen geht: „Ich habe keine Zeit, meine Planung zu aktualisieren“, diesen halben Schritt auf die Seite geht, vielleicht abends eine Stunde extra investiert. Ihr werdet sie in den folgenden Wochen mehrfach ausgezahlt bekommen. Das war meine Nummer 1: Ich habe keine Zeit, meine Planung zu aktualisieren.

So, das war jetzt so ein kleiner Ausschnitt der Sprüche, die ich da auf meiner Liste hatte. Ich gehe davon aus, du hast dich in der einen oder anderen Situation, in der einen oder anderen Geschichte wiedergefunden. Ich auch, im Übrigen.

Meine Fragen zum Nach- und Weiterdenken

Und ja, vielleicht zum Abschluss auch hier nochmal meine Fragen an dich zum Weiterdenken:

  • Welchen dieser Sätze hast du denn schon mal verwendet und in welcher Situation?
  • Und was hast du daraus gemacht?

Intro- und Outromusik

Die Musik für Intro und Outro wurde freundlicherweise von pinningmerkaba unter dem Titel Urbana-Metronica (wooh-yeah mix) unter einer Creative Common Lizenz (CC-BY 3.0) zur Verfügung gestellt.

PMMB008: Das Projektumfeld im Griff behalten

Projekte werden von Menschen gemacht, beeinflussen Menschen und werden von Menschen beeinflusst. Grund genug, sich als Gedanken zu machen, welche Personen sich in meinem Projektumfeld befinden und wie sie sich zu meinem Projekt positionieren. Stakeholder nennt man diese Personen.

In dieser Episode erfährst Du, wie man die Stakeholder in einem Projekt finden kann und wie man erkennt, wie sie das Projekt beeinflussen können.

In dieser Episode erfährst Du:

  • Was sind Stakeholder und was ist Stakeholdermanagement?
  • Warum ist es so wichtig, sich um Stakeholder zu kümmern?
  • Meine 4 Schritte, mit denen ich meine Stakeholder im Griff behalte
  • Tipps und Tricks beim Umsetzen
  • Meine Fragen an Dich zum Weiterdenken

In der Episode beschreibe ich das Stakeholder-Portfolio. Hier siehst Du, wie solch ein Portfolio aussehen kann.

Beispiel Stakeholder-Portfolio

Beispiel Stakeholder-Portfolio

Das Projektumfeld im Griff behalten

Nachdem wir uns ja in den letzten Podcast-Episoden mit den Phasen im Projektmanagement beschäftigt haben, geht es heute wieder etwas mehr um die Menschen. Projekte leben von Menschen, Projekte werden von Menschen durchgeführt und sie beeinflussen auch Menschen und sie werden auch von Menschen beeinflusst.

Projekte werden von Menschen beeinflusst

Grund genug also, sich hierüber mal ein paar Gedanken zu machen und der Fachbegriff im Projektmanagement dafür, für solche Menschen und für solche Personengruppen, ist Stakeholder. Das hast du vielleicht schon mal gehört. Ich werde da gleich auch noch mal genauer drauf eingehen.

Und so sprechen wir in dieser Episode über Stakeholder-Management.

Wie habe ich die Episode für dich aufgebaut? Wir werden zunächst mal im ersten Schritt uns anschauen, was sind denn eigentlich Stakeholder und was ist Stakeholder-Management? Im zweiten Schritt werden wir uns mal anschauen, warum es denn so wichtig ist, sich um die Stakeholder zu kümmern. Und im Hauptteil geht es dann darum, die vier Schritte mal auseinander zu nehmen, die erforderlich sind, um Stakeholder sozusagen im Griff zu behalten. Dann wird es natürlich wieder Tipps und Tricks von mir geben, die es dir vielleicht etwas leichter machen mit Stakeholdern umzugehen. Und ganz zum Schluss gibt es auch meine Fragen zum Weiterdenken. Das kennst du ja schon.

Was sind eigentlich Stakeholder?

Ja, dann steigen wir doch also mal direkt ein. Was sind denn eigentlich Stakeholder? Und was ist Stakeholder-Management?

Stakeholder zunächst mal vorne weg, ist ein Begriff, der aus dem Englischen kommt und Teilhaber heißt. Es gibt leider kein wirklich schönes deutsches Wort dafür. Wenn du eines hast, lass es mich gerne wissen.

Wikipedia sagt dazu,

als Stakeholder wird eine Person oder eine Gruppe bezeichnet, die ein berechtigtes Interesse am Verlauf oder Ergebnis eines Prozesses oder Projektes hat.

Gabler Wirtschaftslexikon verwendet einen anderen Begriff. Gabler sagt oder spricht hier im Zusammenhang mit Stakeholdern von Anspruchsgruppen. Ich glaube, beides passt ganz gut. Es geht also um Menschen, die in irgendeiner Form betroffen sind, interessiert am Projekt sind oder tatsächlich sogar am Projekt echt beteiligt sind. Also Menschen, die sich im Umfeld eines Projektes befinden, die Interesse am Ausgang, vielleicht sogar auch am Verlauf eines Projektes haben.

Ob das jetzt nun ein berechtigtes oder ein unberechtigtes Interesse ist, das sei zunächst mal daran hingestellt. Zunächst mal haben sie ein Interesse.

Stakeholder sind nicht Shareholder

Ganz wichtig, einfach um den Begriff auch noch mal abzugrenzen, wir reden hier nicht von Shareholdern. Wir reden von Stakeholdern, nicht von Shareholdern. Shareholder sind nämlich Anteilseigner. Bei Unternehmen sind es zum Beispiel die Inhaber oder eben auch die Aktionäre. Da kommt der Begriff Shareholder her. Also an der Stelle bitte nicht verwechseln.

Was ist Stakeholdermanagement?

Was ist dem entsprechend dann Stakeholder-Management? Für mich zunächst mal ein sehr technisches, vielleicht auch bürokratisches Wortmonster.

Im Prinzip geht es darum, die Menschen, die sich im Projektumfeld befinden, sich mit denen zu beschäftigen, sie nicht außer Acht zu lassen, sie im Blick zu haben und vielleicht eine Vorgehensweise und einen Prozess zu haben, mit denen umzugehen, um auch besser zu verstehen, was die denn eigentlich wollen.

Warum sollten wir uns um Stakeholder kümmern?

Da kommen wir auch schon zum zweiten Punkt, warum es denn so wichtig ist, sich um Stakeholder zu kümmern. Sehr oft ist es doch auch so, dass Personen im Projektumfeld unterschiedliche Interessen und auch Sichtweisen haben. Und diese unterschiedlichen Interessen sollten wir in unseren Projekten kennen und vielleicht auch berücksichtigen.

Und ich glaube, es gibt wirklich ein paar gute Gründe, sich über die Menschen im Projektumfeld Gedanken zu machen.

Zum einen, wenn wir uns vielleicht mal anschauen, was das denn so sein könnte? Zum einen gibt es da vielleicht Gegner, also Menschen, die jetzt nicht gerade dein Projekt unterstützen und dem vielleicht eher so sogar entgegenstehen.

Das sind Risiken, die von diesen Menschen ausgehen können. Ich glaube, es macht Sinn, dass wir diese Risiken kennen und ein Stück weit vielleicht auch damit umgehen können. Und auch Gegner deines Projektes können Projekte tatsächlich behindern bis zum Stopp oder Abbruch.

Dann gibt es auf der anderen Seite auch sowas, wie Befürworter und Unterstützer. Und ich glaube, da gibt es ganz viele Möglichkeiten und Chancen, die in diesen Personen im Umfeld liegen. Die können dein Projekt nämlich beschleunigen, die können es unterstützen, die können Ihnen manchmal den wichtigen Kontakt besorgen und so weiter. Also glaube ich, ganz viele Möglichkeiten, die da eben drin sind.

Kenne die Menschen in Deinem Projektumfeld

Wenn man die Menschen in seinem Projektumfeld gut kennt, hat man eine gute Chance, Marketing für das Projekt zu machen. Und ja, sind wir ehrlich, selbstverständlich hängt der Projekterfolg des Projektes von der Arbeit ab, die das Projektteam gemeinsam macht. Aber eben auch vom Marketing, das um ein Projekt herum gemacht wird.

Und gerade am Anfang des Projektes macht es aus meiner Sicht Sinn, dann wenn du vielleicht an deinen Projektzielen arbeitest, besser zu verstehen, wer denn alles Interesse an deinem Projekt hat und auch deren Sicht auf die Dinge und die Ziele besser zu verstehen, um sie auch vielleicht ja dann im Projekt berücksichtigen und vielleicht sogar einbeziehen zu können.

4 Schritte für gutes Stakeholdermanagement

Wie geht man also vor? Ich habe die Erfahrung gemacht, dass es vier Schritte gibt, die da Sinn machen, um eben Stakeholder oder Menschen im Projektumfeld so ein bisschen einzubeziehen. Wir gehen zunächst mal die vier Schritte durch und ich würde dir dann Schritt für Schritt erklären, was ich damit meine.

Der erste Schritt ist, die Stakeholder zunächst mal zu identifizieren.

Im zweiten Schritt werden wir die Stakeholder dann bewerten und auch so ein Stück weit einordnen.

Wir werden sie im dritten Schritt analysieren und

wir werden im vierten Schritt dann im Prinzip so eine kleine Verfolgung oder Nachverfolgung noch haben.

1. Stakeholder Identifizieren

Beginnen wir mit dem ersten Schritt. Stakeholder identifizieren. Also hier geht es zunächst mal darum, wirklich zu sammeln, wer sind denn eigentlich die Stakeholder in meinem Projekt? Wer sind denn die Personen, die ein Interesse an meinem Projekt haben? Und wenn ich jetzt wieder an Projekte im Maschinenbau denke, dann fallen mir da zumindest mal der Auftraggeber ein, aber auch die Abteilungs- und Teamleiter, die Personen in mein Projekt entsenden.

Selbstverständlich die Geschäftsführung, der Inhaber des Unternehmens, aber auch meine Teammitglieder, die in meinem Team mitarbeiten. Der Kunde ist mit Sicherheit ein Stakeholder, auch wenn es dort verschiedene Personengruppen gibt, die durchaus noch unterschiedliche Interessenslagen haben können. Personen, die unser Produkt, unsere Maschine später bedienen. Also ich würde mal sagen, die Anwender sind Stakeholder mit Sicherheit.

Aber auch unsere Lieferanten und gegebenenfalls deren Lieferanten. Also Sublieferanten sind Personen, die da Interesse haben an unserem Projekt und gegebenenfalls, hängt natürlich wieder vom Projekt ab, sind es vielleicht auch mal Systempartner. Also andere Unternehmen, mit denen wir zusammenarbeiten, gerade auch in unserem Projekt.

Ich sammele also in der Regel einfach auf einem Flipchart oder auf einer Pinnwand und meistens ist das dann bei mir eine Sammlung mit so Moderationskarten und auf jeder Karte steht eben ein Name. Manchmal mache ich das dann aber auch mit einer Mindmap. Wenn ich keine Pinnwand, kein Flipchart, zur Hand habe, geht es auch ganz gut auf einem Schreibtisch oder einem Blatt Papier, hängt einfach auch davon ab, wie viel Personen da dabei sind.

Darauf komme ich aber auch später noch mal darauf zurück. Was mir ganz wichtig ist, bitte ganz konkrete Namen aufschreiben und nicht einfach Rollen. Also auf einer Karte sollte nicht stehen Abteilungsleiter, sondern ganz konkret der Name Müller, Meier, Schulze, weil nämlich verschiedene Personen, die vielleicht die gleiche Rolle, also zum Beispiel Abteilungsleiter haben, durchaus unterschiedliche Interessen und auch Positionierungen zum Projekt haben. Und das macht eben Sinn, das zu unterscheiden.

Fragen, die mir beim Identifizieren und beim Sammeln helfen, sind zum Beispiel, wer ist denn am Ergebnis des Projektes interessiert? Und wer liefert einen ganz konkreten Beitrag zum Projekt? Wer kann den Projektverlauf beeinflussen und wer trifft Entscheidungen für das Projekt? Wer will, dass das Projekt umgesetzt wird und wer will vielleicht nicht, dass das Projekt umgesetzt wird? All das sind Fragen, die ich immer so im Hinterkopf habe beziehungsweise auch meinen Teammitgliedern dann in der Moderation stelle, um so ein bisschen das Hirn anzukurbeln, um da eine wirklich gute Sammlung zusammen zu kriegen.

Als Ergebnis habe ich dann also eine Liste oder eine Mindmap mit Namen, die vor mir liegen. Das sind zunächst mal meine Stakeholder. Und mir ging es dann am Anfang sehr oft da so, dass ich etwas erschlagen war von der Menge. Weil wenn man sich tatsächlich mal Gedanken macht, wer denn da so alles Interesse, berechtigt oder unberechtigt, an meinem Projekt hat, dann kommt man sehr schnell mal auf 30 bis 40 Namen. Und dann kommt natürlich auch gleich die Frage auf, wie sollen wir denn das schaffen? Wie sollen wir denn mit denen allen umgehen?

Für mich sind da zwei Punkte wichtig, zwei Punkte zu sagen. Erstens. Diese Stakeholder existieren egal, ob du sie aufschreibst und damit identifizierst oder nicht. Die haben einen Einfluss auf dein Projekt. Ebenfalls egal, ob du sie aufschreibst oder nicht. Und ich denke, dass es Sinn macht diese Stakeholder zu kennen, denn die Alternative ist doch, den Kopf in den Sand zu stecken, also die Augen zu schließen und dann hätten wir wieder einen Blindflug im Projekt. Und ich glaube, das kann keiner wirklich wollen, der erfolgreiche Projekte umsetzen möchte.

Und der zweite Punkt ist, vielleicht gleich so als Entwarnung vorneweg: Keine Angst, wir müssen uns nicht um alle Stakeholder kümmern, zumindest nicht um alle im gleichen Maße.

2. Stakeholder bewerten und einordnen

Und genau aus diesem Grund gehen wir jetzt nämlich gleich auch weiter zum zweiten Schritt, Stakeholder bewerten und einordnen.

Worum geht es beim Bewerten und Einordnen der Stakeholder? Das Ziel ist zunächst einmal besser zu verstehen, wo denn die einzelnen Stakeholder stehen, wie sie sich zu unserem Projekt positionieren.

Dazu verwende ich normalerweise ein ganz einfaches Instrumentarium, um das besser herausarbeiten und auch visualisieren zu können, es ist sozusagen ein kleines Portfolio.

Stelle dir ein Diagramm vor. Das Diagramm hat zwei Achsen und diese Achsen helfen mir einfach meine Gedanken besser zu sortieren und vielleicht auch eine gezieltere Diskussion zu führen. Es gibt eine horizontale Achse und auf dieser Achse trage ich die Macht beziehungsweise den Einfluss dieser Person ein. Von null bis, sagen wir mal, zehn. Eigentlich braucht man keine Zahl, aber manchmal hilft es so ein bisschen in der Diskussion. Wenn ich keine Zahlen anschreibe, dann ist es eher so eine qualitative Diskussion.

Auf der vertikalen Achse trage ich dagegen die Einstellung der Person gegenüber meinem Projekt auf. Die vertikale Achse ist also die Einflussachse bei null. Nach oben trage ich dann alle ein, die eine positive Einstellung zu meinem Projekt haben und meistens schreibe ich dann an diese Achse ein lächelndes Smiley rein. Und nach unten die Personen, die eine negative Einstellung zu meinem Projekt haben, die das Projekt nicht möchten, die vielleicht auch gute Gründe haben, dass es nicht funktioniert. Da mache ich dann meistens so ein böses Smiley hin.

Falls du es dir jetzt gerade noch nicht vorstellen kannst, kein Problem, schaue einfach oben nach.

Im nächsten Schritt ordne ich jetzt nun jede Person, also jeden Stakeholder, den wir vorher gemeinsam gesammelt haben, in diesem Portfolio ein. Wie viel Einfluss hat er auf das Projekt? Wie viel Macht kann er ausüben, wenn er das denn will? Wie steht er denn zum Projekt? Findet er es gut, unterstützt er das gerne oder ist eher im Lager der Gegner einzusortieren? Oder ist er vielleicht sogar eher neutral? Also es ist ihm mehr oder weniger egal?

Es geht hier weniger um so eine exakte mathematische Bewertung und Positionierung, sondern eher um so eine Relation zueinander und um Ausprägungen, also eher so um Abstände. Wer befindet sich wo? Wer ist am äußersten Ende der Machtskala? Wer steht ganz oben in der Einstellung zu unserem Projekt. Und wer sind so die ganz großen Gegner.

Und so bekomme ich nun ein ganz grafisches, visuelles Bild von der Position meiner Stakeholder. Und ganz am Ende des Schrittes lege ich dann noch Prioritäten fest, weil ich mir ja gesagt habe, ich kann mich nicht um alle Personen kümmern. Das kostet einfach auch zu viel Zeit. Und meistens haben die Personen mit hohem Einfluss und einer sehr negativen Einstellung zum Projekt da eben eine sehr hohe Priorität, weil diejenigen, die sind, die mein Projekt killen können, zum Abbruch bringen können.

Personen mit eher weniger Einfluss haben meistens, wenn ich ehrlich bin, dann eine geringere Priorität. Die beobachte ich eher so ein bisschen. Es sei denn, es gibt da viele Einzelne, die eine sehr negative Einstellung haben, die haben nämlich zusammen dann irgendwann auch wieder einen größeren Einfluss. Am Ende dieses Schrittes, das Bewerten und Einordnen, steht also ein Portfolio, aus dem ich erkennen kann, wie wir die einzelnen Stakeholder bewertet haben, welche Priorität dann später für die Analyse haben.

3. Stakeholder analysieren

Und es ist auch schon der dritte Schritt, die Stakeholder zu analysieren. Bei der Analyse der Stakeholder geht es nun darum, besser zu verstehen, was die eigentlich denn wollen. Was treibt die um? Um dann in einem zweiten, kleinen Schrittchen auch festzulegen, welche Maßnahmen können wir denn einleiten, damit wir hier vielleicht mit dieser eventuellen kritischen Einstellung umgehen können.

Und da arbeite ich mich jetzt einfach wieder meinen Prioritäten entlang. Also die Stakeholder mit der höchsten Priorität bearbeite ich eben als aller erstes, weil ich natürlich auch meine Zeit effizient einsetzen möchte. Stakeholder, die eher auf der Beobachtungsliste stehen, die ich dort draufgesetzt habe, die schaue ich mir in diesem Schritt eher dann nicht mehr an.

Die Analyse mache ich meistens oder anhand so einer kleinen Tabelle. In der ersten Spalte trage ich dann die Stakeholder ein, also die Namen. Meistens auch noch die Rolle dahinter, also z.B. Abteilungsleiter, Auftraggeber, Kunde und so weiter und so fort. Und in der nächsten Spalte überlege ich mir dann, welche Ziele hat denn dieser einzelne Stakeholder. Was möchte der? Was ist ihm wichtig? Und welche Erwartungen hat er denn an das Projekt. Und dann überlege ich mir, also ich als Projektleiter auch gemeinsam mit meinem Team, was hätten wir denn gerne von diesem Stakeholder?

Das könnte zum Beispiel sein, ich hätte gerne Unterstützung. Oder ich hätte gerne schnelle Entscheidungen. Oder ich hätte gerne mehr Personal von ihm. Oder manchmal ist es auch einfach nur die Anwesenheit in bestimmten Situationen, bestimmten Präsentationen. Und das trage ich dann in die nächste Spalte in meiner Tabelle ein. Also was ist meine Erwartung an den Stakeholder?

Und ganz zum Schluss überlege ich mir dann, was könnte denn eine geeignete Maßnahme sein, damit ich diesen Stakeholder in Richtung meiner Erwartung bringe. Und das sind dann meistens Dinge, wie regelmäßige Informationen, zum Beispiel eine Einbindung in den Lenkungskreis, Integration von ganz bestimmten Mitarbeitern, Schlüsselmitarbeitern in meinem Projektteam, Berücksichtigung von bestimmten Dingen, Vorgehensweisen im Projektplan.

Das heißt, ich überlege mir ganz bewusst, was kann ich den tun? Was kann ich aktiv tun, um diesen Stakeholder mit seinen Zielen zu berücksichtigen und ihn so zu behandeln, dass er möglichst dorthin kommt, wo ich ganz gerne, wo ich ihn unterstützend in meinem Projekt wahrnehme?

Und natürlich ordne ich diese Aufgaben, die ich da gefunden habe, wieder einer Person zu, die das zu erledigen hat. Manchmal, sehr oft ist es der Projektleiter, weil das sehr oft Tätigkeiten sind, wo ich sage, da schmieren wir das Getriebe mit ein bisschen Öl. Manchmal ist es aber auch zum Beispiel der Auftraggeber oder einfach ein Teammitglied.

Als Ergebnis habe ich jetzt einfach eine ganz konkrete Liste mit Aufgaben, die abgearbeitet werden können und die mir dann einfach dabei helfen mein Projektumfeld deutlich besser im Griff zu behalten.

Die Betrachtung, die ich eben beschrieben habe, die mache ich nicht nur einmal, sondern ich beginne immer wieder im Projektverlauf meine Stakeholder zu beobachten und das ist auch gleichzeitig jetzt schon der vierte Schritt.

4. Nachverfolgung

Ich hatte ja gesagt, zum Abschluss verfolgen wir die Stakeholder nicht im Sinne eines Stalkings, sondern eher im Sinne eines kontinuierlichen Prozesses. Ich würde es auch Stakeholder-Monitoring nennen.

Das heißt, in regelmäßigen Abständen schaue ich mir mein Portfolio an, das ist diese Sicht der Stakeholder auf mein Projekt und überlege mir, hat sich denn daran etwas verändert und was?

Personen gewinnen im Laufe der Zeit an Einfluss oder sie verlieren und manchmal ändern sie auch ihre Sichtweise auf das Projekt, zum Beispiel weil wir Maßnahmen ergriffen haben.

Aber auch Ziele und Erwartungen an das Projekt verändern sich im Laufe der Zeit. Ich überprüfe also immer mal wieder, hat sich hier etwas verändert und passe dann gegebenenfalls meine Maßnahmen an oder leite auch mal neue ein.

Gelegentlich ist es auch so, dass Stakeholder, die zu Beginn noch auf meiner Beobachtungsliste standen, also keine Maßnahme bekommen haben, mehr und mehr ins Blickfeld kommen, sodass ich mich auch mehr um die kümmern muss. Dann kommen natürlich neue Aufgaben hinzu und andere sind unter Umständen auch nicht mehr erforderlich. Die Verfolgung der Stakeholder gehört für mich zu den ganz normalen Tätigkeiten, die ich dann im Rahmen meines fortlaufenden Projektmanagements erledige, ähnlich wie ich Termine und Kosten verfolge oder wie ich eben auch meine Teamsitzungen mache.

Jetzt hast Du meine vier Schritte kennengelernt, die ich in der Regel so anwende, um mein Projektumfeld im Griff zu behalten und ich hatte dir ja noch so ein paar Tipps und Tricks versprochen, die es vielleicht etwas leichter machen, damit auch umzugehen.

Wie erstellt man eine Stakeholderanalyse?

Beginnen wir mal immer, die erste Frage, die kennst du schon aus den vergangenen Episoden, im Team oder alleine?

Eine Stakeholder-Analyse kann man auch gut alleine machen, zumindest das Sammeln der Stakeholder und auch das Festlegen der Maßnahmen. Beim Bewerten und Einordnen hilft es dann aber ganz oft, verschiedene Blicke auf die Dinge zu haben. Und da macht es natürlich Sinn, das auch im Team zu machen. Grundsätzlich versuche ich die Analyse auch im Team zu machen, weil das mir einfach diese unterschiedlichen Sichtweisen wiederbringt.

Weil Themen hochkommen, an die ich vielleicht zunächst einmal gar nicht dran denke. Und es hilft auch, gerade beim Festlegen der Maßnahmen, der Aufgaben, wenn die Personen, die es später tun sollen, dann auch beim Festlegen dabei sind.

Stakeholder sind Menschen

Ein Punkt ist mir ganz wichtig. Wir reden bei Stakeholdern über Menschen. Und gerade bei der Diskussion, bei der Einordnung im Portfolio reden wir über Einfluss, Macht und Einstellung. Und ich glaube, da ist es ganz wichtig, dass gerade in dieser Diskussion, dass du darauf achtest, dass es hier einen sehr wertschätzenden Umgang miteinander gibt. Ich habe nämlich schon sehr oft erlebt, dass da über einzelne Stakeholder sehr abfällig gesprochen wird und ich glaube, das ist der Sache nicht dienlich. Wir sitzen zusammen und reden über andere Menschen und ihre Sicht auf die Dinge, ihre Sicht auf unser Projekt. Und noch mal, ganz wichtig, achte bitte darauf, dass hier ein wertschätzender Umgang stattfindet.

Auch wichtig: Wenn eine Person eine negative Einstellung, also ein Stakeholder, eine negative Einstellung zu unserem Projekt hat, heißt das nicht, dass er ein schlechter Mensch ist. Er hat lediglich andere Ziele, andere Erwartungen und das ist völlig legitim, dass er die hat. Und es ist unsere Aufgabe, das ein Stück weit zu berücksichtigen und auch damit umzugehen. Und unser Ziel ist ja seine Sicht auf unser Projekt zu verändern und in unserem Sinne zu verbessern.

Meine Erfahrungen für Dich

Es gibt noch so ein paar Erfahrungen, die ich gemacht habe, die ich dir gerne mitgeben möchte. Also das Sammeln der Stakeholder funktioniert, aus meiner Sicht, am besten auf Papier oder mit Moderationskarten. Das ist kreativer, da passiert mehr im Kopf. Das ist aktiver und das ist einfach besser, als wenn zehn Menschen gemeinsam auf eine Leinwand, auf ein Beamerbild starren.

Ich glaube, ich habe es in den vergangenen Episoden schon mehrmals gesagt, ich glaube, es gibt nichts Schlimmeres, als solch eine Situation. Da entsteht nichts Neues. Wenn ich die Namen auf die Karten geschrieben habe, dann fällt es mir auch leichter, gleich die Einordnung zu machen, weil ich die Karten an der Pinnwand so lange verschieben kann, bis sie an der richtigen Stelle sind.

Auch da ist so eine digitale Lösung, meistens nicht richtig gut. Das Sammeln der Erwartungen und der Ziele und auch das Festlegen der Maßnahmen, das hingegen funktioniert dann am besten wieder, wenn ich mit so einer Tabelle zum Beispiel in Excel arbeite und dann übertrage ich den ganzen Kram dann einfach wieder.

Dann arbeite ich dann gerne wieder mit dem Rechner, zumal es auch einfach eine sehr gute Grundlage ist, die Stakeholder dann Schritt für Schritt zu verfolgen.

Und ganz wichtig, so ein letzter Tipp: Versuche es in deinen Ablauf einzuplanen. Ich habe für mich so eine kleine Checkliste, die ich jede Woche, jeden Monat oder auch einmal im Quartal quasi abarbeite. Die mir sicherstellt, dass ich an alle Dinge denke, die ich mir regelmäßig anschauen soll. Und da steht zum Beispiel das Thema Terminplanung drauf. Da steht drauf, dass ich meine Projektkosten regelmäßig aktualisiere und auf dieser Liste steht selbstverständlich auch die Stakeholder-Analyse. Und damit stelle ich sicher, dass ich in meiner regelmäßigen Management-Projekt-Verfolgungsarbeit die Stakeholder nicht vergesse.

Meine Fragen zum Nach- und Weiterdenken

Und jetzt sind wir auch schon bei meinen Fragen an dich zum Weiterdenken. Die Fragen haben ja immer so ein bisschen die Idee, das, was wir heute gemeinsam besprochen haben noch mal ein bisschen in deinem Kopf widerhallen zu lassen. Und die Frage ist für dich:

Wer sind denn in deinem Projekt die wesentlichen Stakeholder und wie stehen die denn zu deinem Projekt und welchen Einfluss haben die?

Was könntest du tun, um diese Einstellung zu deinem Projekt zu verändern?

Ich bin sehr gespannt auf deine Überlegungen hierzu!

Intro- und Outromusik

Die Musik für Intro und Outro wurde freundlicherweise von pinningmerkaba unter dem Titel Urbana-Metronica (wooh-yeah mix) unter einer Creative Common Lizenz (CC-BY 3.0) zur Verfügung gestellt.

Darauf solltest Du beim Projektstart achten

Sehr viele Projekte werden nicht richtig gestartet und leiden dann im weiteren Verlauf sehr darunter, dass grundsätzliche Dinge zu Beginn nicht geklärt wurden. Dabei hilft ein guter Projektstart dem Projektleiter und dem Projektteam erfolgreich im Projekt zu sein.