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.

Sich nicht im Detail verlieren: Design Thinking für IT-Entwicklungsprojekte

IT- Entwickler arbeiten gerne genau: Jedes Detail muss stimmen, damit das Endprodukt alle Anforderungen erfüllt. Bei der Entwicklung hat gerade der kreative Entwickler gerne noch eine spontane Idee, wie das Produkt noch besser wird - und weil er gerade eh dabei ist, wird die vermeintlich kleine Änderung direkt noch mit programmiert - mehr ist schließlich besser.

Der kaufmännisch orientierte Projektleiter hat dafür wenig Verständnis: Er lebt im Dreieck zwischen Kosten, Leistung und Zeit. Mehr Leistung muss nicht sein, dauert länger und überhaupt muss mehr Leistung mit dem Kunden abgesprochen und bestenfalls vorab bepreist sein. Ein Spannungsfeld zwischen Entwickler und Projektleiter entsteht - was hilft dagegen?

Zieldefinition

Der klassische Projektleiter definiert vor Projektbeginn Ziele oder Anforderungen, Prozesse, Usecases, Customerjourneys etc. - bestenfalls zusammen mit dem Auftraggeber und dem Projektteam. Je länger das Projekt dauert, desto mehr neigen diese initialen Bemühungen zumindest beim Projektteam in Vergessenheit zu geraten. Dazu ist es natürlich hilfreich, die entsprechenden Projektunterlagen auf einem Projektlaufwerk abzulegen und die finale Version dem Team vorzustellen. Jetzt ist jeder formell informiert… Der Stress im laufenden Projekt, Auslastung aus anderen Projekten, mangelndes Verständnis für vermeintlich sinnlose bürokratische Dokumente und weitere Engpässe sorgen jedoch dafür, dass das Projektteam sich nicht mehr damit beschäftigt. Die Ziele können im Projektmeeting wieder herausgekramt und noch einmal verdeutlicht werden - echt jetzt!? Wir versinken hier im Chaos, der Projektleiter fordert Fortschritte ein, alle machen Überstunden, und jetzt wird die Meetingzeit noch auf eine Präsentation von Zielen von vor 6 Monaten verwendet, die eh nicht mehr aktuell ist? 

Der agile Projektleiter definiert die Ziele pro Sprint, also in einem kürzeren Zeitraum von 2 bis 4 Wochen. Auch dabei sind die Entwickler nicht vor spontanen Eingebungen sicher - der Entwickler kann beim Daily Standup vergessen, von seiner tollen Idee zu berichten, im Optimalfall stellt er sie am Ende des Sprints vor, im schlimmsten Fall crasht etwas bei einem späteren Sprint. Aus der Rolle des Servant Leaders heraus ist der Scrummaster nicht direkt befugt, den Rückbau einer spontan im Sprint realisierten Idee einzufordern - falls der kreative Programmierer seine Idee vorstellt, das Dev Team sie als gut empfindet und voller Überzeugung dem Product Owner vorstellt, kann es passieren, dass auch der Product Owner überzeugt wird. Dies animiert das Scrumteam natürlich, in weiteren Sprints wieder kreativ zu werden - es besteht die Gefahr, dass der Kunde am Ende etwas in weiten Teilen anderes erhält, als das, was er bestellt hat.

In beiden Systemen, klassisch und agil, ist die Zielverfolgung somit stark von der Selbstdisziplin und Kommunikationsbereitschaft der Projektbeteiligten abhängig, da kein Projektleiter seine Projektmitarbeiter detailliert anleiten und überwachen kann und möchte. 

Design Thinking und Design Sprint

Ein zumindest langfristig ausgelegter Besserungsansatz kann im Design Thinking liegen - das hört sich immerhin schonmal modern an und kann daher auch gut verkauft werden. Die aus meiner Sicht in diesem Kontext wesentlichen Kernaspekte (bzw. Ziele) beim Design Thinking und beim Design Sprint sind: 

Es soll schnell ein marktfähiger Prototyp entwickelt werden. 

Das ist unterm Strich natürlich auch nur alter Wein in neuen Schläuchen - ein kluger klassischer Projektleiter arbeitet auf dieses Ziel natürlich genauso hin wie ein Scrummaster in jedem einzelnen Sprint. Warum also meine ich, dass dieser Ansatz helfen kann?

Die Maxime: “schnell einen marktfähigen Prototypen entwickeln” kann in einem klassischen Projekt als (Ober) Ziel aufgenommen werden. Somit muss sich erstmal kein Projektleiter völlig umgewöhnen. In einem agilen Projekt kann der Satz über dem Taskboard aufgehangen werden und/ oder in jedem einzelnen Sprint verankert werden. Der Formalität ist damit genüge getan.

Der Nutzen dieses einen Satzes kann jedoch wesentlich besser dorthin transportiert werden, wo das Projekt eigentlich stattfindet: In die Köpfe der Projektmitarbeiter bzw. des Scrumteams. Er kann kurz und knackig als Mantra verankert werden und die Menschen somit ohne hohen Zeitaufwand fokussieren. Im klassischen Projekt zu Projektbeginn bei der Vorstellung der Zielhierarchie als ganz wichtiges Ziel betont und fortlaufend in jedem Projektmeeting.  Im Daily Standup bei der eingehenden Frage des Scrum Masters: Was wollen wir heute tun, um schnell einen marktfähigen Prototypen zu entwickeln? Das alles kostet sehr wenig Zeit, den einen Satz können sich alle Projektmitarbeiter schnell merken und leichter verinnerlichen als eine eventuell umfangreiche Zielhierarchie oder diverse Taskkärtchen. “Prototyp” ist zumindest noch ein nicht so abgenutztes Wort wie “Ziel” - Ziele haben wir irgendwo alle, Ziele sind weit entfernt und an Zielen muss man ja auch nicht jeden Tag dringend mit vollem Nachdruck arbeiten - das macht man eher langfristig, wenn mal zwischendurch Zeit ist. Ein Prototyp ist fresh, innovativ, spacig und ohne Schnörkel - den geht man doch viel lieber an als ein langweiliges Ziel, oder?

Da auch die Idee des Prototypen mittlerweile schon etwas etablierter ist, wurde schon die nächste Sau gefunden, die durchs Dorf getrieben werden kann: Das Minimum Viable Product (MVP) -  ein Minimalprodukt mit Basisfeatures - wieder ein neuer Schlauch für unseren alten Wein. Dieser Anglizismus mitsamt moderner Abkürzung ist jedoch erklärungsbedürftig und dürfte vom durchschnittlichen Projektteam nicht intuitiv verstanden werden - ein “Prototyp” weckt hingegen direkt bildhafte Assoziationen. Somit eignet sich das MVP gut für Berater, um erklärende Präsentationen zu halten und dafür Stunden schreiben können, nicht jedoch für die breite Masse um ein gemeinsames Verständnis zu erlangen.  

Konnten Sie bereits ein Projektteam (agil oder klassisch) zu hoher Selbstdisziplin führen? Wie haben Sie es geschafft? Welche Erfahrung haben Sie mit Zieldefinitionen und Design Thinking oder Design Sprints? Welches Modewort sollen wir verwenden, wenn auch der “Prototyp” irgendwann abgenutzt ist? Schreiben Sie ihren Kommentar.