Die Suche nach dem Sinn: Der Nutzen von Projekten

 

Wenn Sie diesen Beitrag lesen, dann werden Ihre Projekte besser. 

Was bewirkt dieser Satz in Ihnen? Denken Sie sich: Och nöö, nicht noch so ein dummes Werbeversprechen? Weckt er Hoffnung in Ihnen? Oder Motivation, diesen Beitrag bis zum Ende zu lesen? Ich hoffe ehrlich gesagt auf Hoffnung und Motivation, denn obwohl der eingangs postulierte Satz zwar Plump formuliert ist, sollte er Ihnen etwas mitgeben: Die Aussicht auf einen konkreten Nutzen für Sie - und deshalb hoffe ich, dass Sie weiterlesen.

Wie sieht es mit dem Nutzen von unseren Projekten aus? Wem nutzen sie wann? Haben Sie da mal drüber nachgedacht?

Spätestens seit dem Meister der Produktpräsentationen und der Verkaufsargumente Steve Jobs wissen wir, dass dem Kunden einen Nutzen geben müssen. Der Kunde ist somit ein wichtiger Stakeholder, um das aufs Projektmanagementdeutsch herunter zu brechen. 

Hand auf´s Herz: Taucht der Endkunde in Ihren Stakeholderanalysen überhaupt auf? Ich frage, weil er häufig vergessen wird. Und wenn wir uns Mühe geben, an den Endkunden zu denken, dann taucht er im Quadranten niedrig/ niedrig auf- folglich hat er am Projekt wenig Interesse, wenig Einfluss aufs Projekt, wenig Macht, oder wie auch immer Sie Ihre Achsen beschriften wollen - der Endkunde hat wenig vom Projekt selbst.

Jaa, aber der Endkunde sehnt sich doch nach dem Projektergebnis? Bleiben wir beim Beispiel von Steve Jobs und dem IPhone: Das Produkt ist prinzipiell ja schon eine tolle Sache - wir, die Kunden wussten davon jedoch nichts, bis es auf den Markt kam. Demzufolge war uns allen das entsprechende Produktentwicklungsprojekt völlig egal. Wir wären sogar glücklicher gewesen, wenn das Entwicklungsprojekt eher begonnen hätte und schneller abgeschlossen gewesen wäre, denn: Niemand mag Projekte. Wenn wir in einem Projekt ein Produkt entwickeln, entsteht durch das Produkt (hoffentlich) ein vorzeigbarer Kundennutzen - klar, denn der Kunde soll am Ende schließlich kaufen.  Dazu ist es wichtig, dass vor Projektbeginn die entsprechenden Anforderungen klar definiert sind - und es hat sich als sehr hilfreich erwiesen, den Kunden als Stakeholder ins Projekt einzubeziehen, um ihm sein Dasein im untersten Quadranten der Stakeholderanalyse etwas schmackhafter zu gestalten, beispielsweise durch Design- Thinking- das wirkt sich dann auch extrem positiv aufs Projektergebnis aus, munkelt man.

In IT- Digitalisierung- und Organisationsprojekten sieht es wesentlich schlechter für den Endkunden aus: Fragestellungen wie: Möchtest du, lieber Kunde, dass wir ein CRM- System einführen? Würde der Kunde selbst im Zuge des Design- Thinkings wahrheitsgemäß nur mit "Ist mir völlig egal" beantworten können. Selbst wenn wir spezifischer fragen: "Möchtest du, dass wir deine Beschwerden und Anliegen zielgerichteter bearbeiten können" - welche andere Antwort außer "Ja, na klar" sollten wir uns erhoffen? Bei derartigen Projekten ist der Kundennutzen stark indirekt und wir investieren in einen Nutzen für das Unternehmen, nicht primär für den Kunden. IT- Digitalisierungs- und Organisationsprojekte sind somit folglich eine betriebswirtschaftliche Selbstbefriedigung, die zunächst viel Geld kostet und danach dem Unternehmen selbst hilft, wettbewerbsfähig zu bleiben, effizienter zu arbeiten etc. Nichtsdestotrotz sind solche Projekte natürlich wichtig, das schreibe ich voller Überzeugung als IT- Projektmanager.

Halten wir fest, dass wir zur Erstellung von Nutzen für den Endkunden diesen so weit es geht ins Projekt einbeziehen sollen - in Form von Umfragen oder Design- Thinking vor Projektbeginn, Produktpräsentationen während des Projektes oder in Form von Newslettern, Aushängen und unter Nutzung sonstiger Kommunikationskanäle.

Noch mehr? Klar... Widmen wir uns nun der größten Gruppe an Stakeholdern in unseren Projekten: Dem Projektteam, also denjenigen Kästchen, die im Organigramm in unterschiedlichen Formen unter dem Projektmanager stehen. Da das Projektteam letztendlich die Arbeit im Projekt erledigt, sind sie eine extrem wichtige Stakeholdergruppe.

Und nun kommen wir zum 2. Teil, dem eigentlichen Kern der Sache: Dem Nutzen für das Projektteam. Das Projektteam taucht ebenfalls in den wenigsten Stakeholderanalysen auf - meist in Form eines Vorgesetzten, auf den wir zugehen müssen, damit er jemanden für´s Projekt abstellt. Und das ist wörtlich gemeint, den viele Projektmitarbeiter fühlen sich dann auch im Projekt wie abgestellt: Der Projektleiter predigt irgendwelche High- Level- Ziele, die erfüllt werden müssen, stellt enthusiastisch einen Ablaufplan vor, fordert Ergebnisse ein, welche die Projektmitarbeiter irgendwie auf den letzten Drücker halbherzig realisieren, weil das Projekt eine zusätzliche Belastung für sie ist. Nutzen? Fehlanzeige! Die fühlen sich eher be-nutzt oder ausge-nutzt.

Und gerade diesen Mißstand können wir als Projektleiter sehr einfach ändern - ich rede nicht nur von der obligatorischen Projektabschussparty am Ende des Projektes und dem halbherzigen Bauchpinseln in Form einer Lessons- Learned- Session zum Projektende. 

Der Nutzen für das Projektteam geht eng einher mit deren Motivation. Die Frage, wie wir Nutzen schaffen kann also in Einklang mit der Frage beantwortet werden, wie wir Motivation schaffen. Und diese Frage können wir zunächst einfach anhand der Stakeholderanalyse beantworten: Machen wir die Projektmitarbeiter betroffen, wecken wir ihr Interesse, erhöhen wir ihren Einfluss - also ziehen wir sie in den Hoch/ hoch Quadranten der Stakeholderanalyse, um ihre Motivation zu wecken. Diesen Gedanken verfolgen ebenfalls die agilen Methoden wie SCRUM. Aber wie schaffen wir das?

Naheliegend ist einer der einfachsten Wege: Fragen wir die Projektmitarbeiter zu Projektbeginn doch einfach: "Welchen Nutzen schafft das Projekt für euch?" und "Was müssten wir im Projekt noch tun, um einen Mehrwert für euch zu schaffen?" 

Ich verspreche, dass ein kurzes Brainstorming von 10 Minuten und eine kurze Diskussion von 20 Minuten hier bereits Wunder wirken - die Projektmitarbeiter fühlen sich eingebunden, wertgeschätzt, motiviert. Natürlich müssen wir die Ergebnisse dann noch in Form von Zielen im Projekt verankern. Die genannten Fragen sollen keinesfalls leere Floskeln sein, um zum Schein Nutzen zu schaffen, sondern sie müssen im Projekt verankert werden - dafür muss der Projektleiter sorgen. 

Die Verankerung der Antworten der Projektmitarbeiter im Projekt gibt den Projektmitarbeitern einen höheren Einfluss, weckt (hoffentlich) deren Interesse, gibt ihnen mehr Macht - tadaaa, schon sind die Projektmitarbeiter zu einem wichtigen Stakeholder aufgestiegen, sind relevant für das Projekt geworden - und somit in der Stakeholderanalyse mindestens in einen "hoch" Quadranten aufgestiegen. 

Eventuell ist es nicht einmal notwendig, weitere Ergebnisziele ins Projekt aufzunehmen - möglich sind auch Vorgehensziele. Ein Beispiel: Motivation und Nutzen können auch durch Teamarbeit entstehen auf dem Weg, die Ziele des Top-Managements zu erfüllen. "Ich wünsche mir regelmäßige Zusammenarbeit mit den Kollegen aus anderen Bereichen" wäre ein Beispiel - die Fokussierung auf Teamwork im Projekt, anstelle der Arbeit des Einzelnen. Immerhin heißt es ja auch "Projektteam" -  in diesem Fall kann der Projektleiter helfen, den Teamgedanken gezielt zu stärken.

Auch während des Projektes lohnt es sich, das Projektteam aktiv einzubinden und echtes Interesse an den Befindlichkeiten des Teams zu haben und in Richtung des Projektauftraggebers zu vermitteln. Damit meine ich, dass ein guter Projektleiter nicht nur Ziele von Oben nach Unten durchdrückt ohne Rücksicht auf Verluste, sondern Befindlichkeiten des Projektteams zum Auftraggeber trägt und in der Königsdiziplin der Kommunikation Ideen hat, wie man Ziele von Oben und Befindlichkeiten von Unten im Win-Win vereint. Konsensfindung ist das Stichwort und eine kreative Eigenschaft, die der täglichen Arbeit des  Projektleiters Mehrwert verschafft.

Was den Projektmitarbeitern hilft, hilft oftmals auch dem Kunden - und wenn wir letzteren schon nicht befragen, so helfen uns evtl. die Projektmitarbeiter, mehr Kundennutzen zu erzeugen. 

Wie schaffen Sie Nutzen für Ihre Projekte, insbesondere im Projektteam? Wie sorgen Sie für Motivation im Projektteam? Lassen Sie es mich in Ihren Kommentaren wissen.

Warum ist die Stakeholderanalyse unsinnig?

 

Ein klassischer Projektmanager führt vor Projektbeginn eine Stakeholderanalyse durch - so steht es geschrieben und so machen wir es. Halt- warum machen wir das genau? Die gängigen Definitionen der Stakeholderanalyse geben darauf Antwort - natürlich um die beteiligten Interessensgruppen zu identifizieren...

Aaah... Die Identifikation der Stakeholder kann also nur und ausschließlich erfolgen, indem wir eine Matrix zeichnen und als Zeilen- und Spaltenbeschriftungen dann optional "Interesse", "Einstellung zum Projekt",  "Einfluss" oder noch schlimmer "Macht" eintragen? Hat jemand mal versucht, hier "Wichtigkeit" und "Größe des Autos" abzutragen? Das wären zugegebenermaßen sehr unkonventionelle Beurteilungsdimensionen, allerdings sind die zur reinen Identifikation von Personen nicht weniger geeignet, ja sogar wesentlich bildhafter, oder? Hilfreiche Faustregel dazu: Wichtige Leute fahren dicke Autos und sind somit im Bereich "Hoch/Hoch" anzusiedeln, weniger wichtige Leute können ohne Sorge im Feld "Niedrig/Niedrig" einquartiert werden. 

Kommen wir zum Ernst der Lage zurück - die reine Identifikation von Stakeholdern ist ein kreativer Prozess, welcher auch im Rahmen der klassischen Stakeholderanalyse als Brainstorming abgehalten wird - optimalerweise natürlich im Kreis des Projektteams, denn damit so ein Brainstorming wirklich effizient ist, macht der Projektleiter das am besten nicht völlig alleine. Ich gehe sogar so weit zu behaupten, dass für das Brainstorming überhaupt keinerlei Beurteilungsdimensionen benötigt würden - das Projektteam hat an dieser Stelle erfahrungsgemäß die wichtigsten unternehmensinternen Stakeholder deutlich vor Augen, und der Endkunde wird sowieso prinzipiell fast nie als Stakeholder genannt (achte Sie mal drauf). Feertiig - Stakeholder identifiziert, diesmal ganz ohne Beurteilungsdimensionen oder halt anhand ihrer Automobile. Nun können wir stolz zum Projektauftraggeber rennen und uns unser Fleißkärtchen abholen - Stakeholderanalyse gewünscht, Stakeholderanalyse geliefert.

Ach nein, da war doch noch was... Weiterführende Definitionen der Stakeholderanalyse in der einschlägigen Fachliteratur suggerieren, dass die Stakeholder nicht nur identifiziert, sondern auch noch benachrichtigt oder sogar einbezogen werden müssen - es muss also Kommunikation erfolgen...

Aktionen fallen manchmal schwer, Kommunikation mindestens ebenso - daher macht die klassische Stakeholderanalyse es uns an dieser Stelle leicht und stellt uns Normstrategien zur Kommunikation zur Verfügung. Diese sind mehr oder weniger aussagekräftig betitelt mit: repressiv, diskursiv, partizipativ und restriktiv... Das liest sich jetzt sehr toll in der Fachliteratur, manch einer mag sogar klug genug sein, diese Wörter auswendig zu lernen - aber intuitiv verständlich sind sie nicht, oder? Die Normstrategien haben natürlich den Vorteil, dass ich mich auf etwas berufen kann, wenn die Kommunikation schief läuft - in diesem Fall dient die Stakeholderanalyse dann jedoch nur als geduldiger Sündenbock, nicht als wertvolles Managementinstrument. Sind die vier knapp umschriebenen Normstrategien überhaupt noch zeitgemäß, oder kann der geneigte Projektleiter es sogar wagen, die entsprechenden Stakeholder zu fragen, wie und in welcher Frequenz sie am liebsten individuell einbezogen oder informiert werden wollen?

Überhaupt ist das Vorgehen bis hier nicht wirklich rund, wenn wir einmal drüber nachdenken: Wir sammeln in einem Brainstorming alle Stakeholder, sortieren sie anhand irgendwelcher Kriterien in Felder ein und kommunizieren dann mit diesen Menschen gruppenweise gleich anhand von wohlklingenden Normstrategien, weil wir unterstellen, dass uns im kreativen Prozess natürlich keine Fehler unterlaufen und dass dieses Brainstorming zu 100% exakt ist? 

An dieser Stelle muss ich noch einen Exkurs zu der Beurteilungsdimension "Macht" sowie zur Erweiterung der Stakeholderanalyse auf mehr als vier Felder einführen:

Warum ist die Beurteilungsdimension "Macht" völlig kontraproduktiv? Die Stakeholderanalyse sollte vorzeigbar sein - ich halte es für eine tolle Idee, diese beim Kickoff im größeren Kreis und natürlich auch unter Anwesenheit des Lenkungskreises und des Projektauftraggebers zu zeigen. Der Lenkungskreis besteht der Erfahrung nach aus hochrangigen Unternehmensvertretern - und nun stellen Sie sich vor, der Lenkungskreis besteht aus 2 Personen: Vorstand Herr Dr. Dr. X, über 60 Jahre alt, fährt ein sehr dickes Auto zur Demonstration seiner Macht, hat die letzten 40 Jahre intensiv und hauptsächlich damit verbracht, Macht aufzubauen. Dann noch Frau Y, ebenfalls Vorstandsmitglied, Mitte 40, fachlich sehr stark und die treibende Kraft hinter ihrem Projekt. Weil Frau Y Ihnen als fachkundiger Ansprechpartner während der Initiierungs- und Planungsphase zur Verfügung stand, steht Frau Y bei Ihnen zwar genau wie Herr Dr. Dr. X im Hoch/Hoch- Feld der Stakeholderanalyse - aber halt 2 cm weiter oben als Herr Dr. Dr. X - mit anderen Worten: Sie haben Frau Y als 2 cm mächtiger eingeschätzt als Herrn Dr. Dr. X! Ich verspreche Ihnen, dass sie den Zeitplan für den restlichen Kickoff getrost vergessen können, weiterhin werden sie sehr bald degradiert oder müssen das Unternehmen verlassen - Herr Dr. Dr. X wird eine ausufernde Diskussion darüber führen, dass die Stakeholderanalyse falsch ist, höchstwahrscheinlich ohne offen zuzugeben, dass er gerne in der Machteinschätzung über Frau Y stehen würde.

Aus diesem Grund tuen Sie sich selbst den Gefallen und verwenden sie "Macht" generell nicht als Beurteilungsdimension - in diesem Beispiel wäre sogar wiederum alles gut gewesen, wenn sie die Größe des Autos als Kriterium verwendet hätten - Herr Dr. Dr. X fährt ja wie beschrieben ein dickes Auto, Frau Y macht sich daraus nichts und wählt öffentliche Verkehrsmittel, dafür weist sie auch direkt, kurz und freundlich darauf hin, wenn sie sich in der Stakeholderanalyse falsch eingruppiert sieht - und schon geht der Kickoff wie geplant weiter.

Der allgemeine Trend geht dahin, die 4- Felder- Matrix der Stakeholderanalyse zu erweitern, nach dem Motto: Mehr ist besser! Wenn wir uns schwer tun, eine Beurteilungsdimension nur mit "Hoch" oder "Niedrig" zu bewerten, dann führen wir doch einfach noch ein "Mittel" ein, oder wir verschlimmbessern die Skala weiter mit numerischen Ausprägungen - dann können wir direkt "1 bis 5" oder auch "1 bis 9" bewerten. Der Bewertungsprozess ist natürlich weiterhin ein Brainstorming, welches intuitiv abläuft und daher lediglich subjektive Einschätzungen liefert - diese werden nicht umso genauer, je weiter wir differenzieren bzw. je mehr Unterteilungen wir der zugrundeliegenden Skala hinzufügen. Mein wichtigster Kritikpunkt an diesem Vorgehen ist jedoch: Bei diesen Erweiterungen werden im Ergebnis nicht entsprechend mehr Normstrategien hinzugefügt - wenn das Ergebnis dieses vermeintlich  genaueren Vorgehens jedoch wiederum nur 4 Normstrategien sind, wofür sollen wir dann die Skala erweitern? 

Ich möchte Ihnen zum Abschluss gerne mein Vorgehen zu einer sinnvollen Stakeholderanalyse darstellen, welche einen praxisrelevanten Nutzen ohne viel Schnickschnack bietet:

1. Brainstorming im Kreis des bis zu diesem Zeitpunkt bekannten Projektteams
• Beim Projektstartworkshop. Die Beurteilungsdimensionen "Einfluss & Interesse" können zur Hilfestellung verwendet werden, sind aber nicht dringend notwendig. Der Projektleiter sollte darauf achten, dass der Endkunde und alle externen Dienstleister als Stakeholder genannt werden - die werden meistens vergessen.
• Beim Brainstorming sollte Zeitdruck hergestellt werden - nach der Vorstellung der Aufgabenstellung kann der Projektleiter dem Team 10 bis 15 Minuten Zeit geben, um alle wichtigen Stakeholder zu erfassen. Die Erfahrung zeigt, dass die Ergebnisse bei längeren Zeiträumen nicht besser werden. Falls der Zeitdruck für das Team zu groß wird und eine Blockade einsetzt, so kann der Zeitrahmen bei Bedarf verlängert werden.
2. Benachrichtigung bzw. Befragung der neu bekannt gewordenen Stakeholder
• Im schnellsten Fall mit einer kurzen Mail: "Sie wurden als wichtiger Interessensträger im Projekt XY identifiziert- möchten Sie aktiv am Projekt teilnehmen, einen Vertreter ins Projekt entsenden oder regelmäßig informiert werden? Gerne können wir auch ein individuelles Vorgehen vereinbaren". Geht auch als Massenmail, ist effizient und individuell - bye, bye Normstrategie.
3. Regelmäßige Überprüfung und Kommunikation zu neu identifizierten Stakeholdern
• Macht kein Mensch in dieser systematischen Form, gehört aber eigentlich dazu.

Welche Erfahrungen haben Sie mit der Stakeholderanalyse gesammelt? Halten Sie die klassische Stakeholderanalyse für nützlich? Wie viele Felder hat Ihre Stakeholderanalyse und welche Beurteilungsdimensionen verwenden Sie? Fahren Sie ein dickes Auto? 

Schreiben Sie Ihre Gedanken dazu gerne als Kommentar.