Arbeitsauslastung messen vs. Ergebnisse messen

 

Lesen Sie das Transkript:

Wir testen derzeit, unsere Podcasts mit einem Softwareprogramm zu transkribieren. Bitte entschuldigen Sie eventuelle Tippfehler, da der Bot nicht immer 100% korrekt ist.

Galen Low: Überraschungsquiz: Ihr Projekt ist zur Hälfte abgeschlossen, alle Kennzahlen sehen gut aus. Ihr Dienstleister hat die vereinbarte Anzahl an Stunden geleistet und die Geschwindigkeit sowie Auslastung Ihres Teams entsprechen genau der Planung.

Trotzdem verfehlt das Produkt in Fokusgruppen und Benutzertests weiterhin das Ziel. Die Technologie, auf die Ihr Executive Sponsor so gepocht hat, ist schnell veraltet, was Änderungen erschwert. Und die Moral Ihres Teams ist niedrig: Wenn Sie nach Lösungen fragen, zucken alle nur mit den Schultern und sagen, sie hätten in der vorgegebenen Zeit das erledigt, was verlangt wurde.

Wie kann Ihr Projekt also „gesund“ sein, wenn das Ergebnis nicht den beabsichtigten Wert schafft?

Falls Sie feststellen, dass Ihre Projektkennzahlen eher Beschäftigung als Wert messen, hören Sie weiter zu. Wir tauchen in die praktischen Mechanismen ein, wie Projektteams Wert messen können, und schauen uns Ideen an, wie man den Anreiz vom Zeitaufwand hin zu Wertschöpfung verlagern kann.

Hallo zusammen, danke fürs Einschalten. Mein Name ist Galen Low vom Digital Project Manager. Wir sind eine Community von Digitalprofis mit der Mission, uns gegenseitig zu qualifizieren, selbstbewusst und vernetzt zu machen, damit wir den Wert des Projektmanagements in der digitalen Welt steigern können. Wenn Sie mehr darüber erfahren möchten, besuchen Sie thedigitalprojectmanager.com.

Heute sprechen wir über den Unterschied zwischen der Messung von Projektgesundheit und -fortschritt versus der Messung von Projekterfolg. Reicht es, Teamgeschwindigkeit und Kostenleistung zu verfolgen? Oder ist es unsere Verantwortung als Projektleiter:innen, auch Projektergebnisse und deren Impact zu messen?

Bei mir ist heute Fred Fowler—ein Level-3-zertifizierter Scrum Master, der mehrere Bücher zur Scrum-Methodik veröffentlicht hat, Organisator der Silicon Valley Professional Scrum Meetup-Gruppe mit etwa 2.000 Mitgliedern, führt eine ähnliche Scrum-Community in Shanghai, China, und hat die erste Silicon Valley Scrummit-Konferenz organisiert. Mit anderen Worten: Jemand, der sich wirklich auskennt mit Scrum.

Willkommen Fred!

Fred Fowler: Hallo! Danke, dass ich bei euch sein darf.

Galen Low: Schön, dass du hier bist.

Fred Fowler: Ich stelle mich gerne als „scrummy guy“ vor. Manche sagen, ich bin sogar „scrumcious“.

Galen Low: Das ist besser, als wenn ich sage, Fred „scrum-of-the-earth“.

Fred Fowler: Es gibt viele Möglichkeiten, mit dem Wort Scrum zu spielen. Man kann scrumbagen und was weiß ich noch alles. Na egal, far away.

Galen Low: Genau. Sehr cool. Du hast einen spannenden Hintergrund und ich denke, er verleiht unseren Zuhörern viel Kontext zu deiner Sichtweise auf Projektmetriken. Wenn ich richtig nachvollziehe, hast du als Programmierer begonnen, bist dann in die Politik gewechselt, warst Bürgermeister und hast dich als CIO wiedergefunden, bevor du dich darauf konzentriert hast, mit deiner seltenen Level-3-Scrum-Master-Zertifizierung anderen zu helfen.

Kannst du uns ein wenig über deinen Werdegang erzählen und wie deine Erfahrungen deine heutige Sichtweise geprägt haben?

Fred Fowler: Ich würde sagen, meine Karriere war wie in einer Flipperkugel.

Angefangen als Programmierer 1980. In uralten Zeiten arbeitete ich an einem so großen und schweren Rechner, dass man spezielles Equipment brauchte, um ihn zu bewegen—er war weniger leistungsfähig als ein heutiges Telefon. Dennoch haben wir damit eine Sparte eines Halbleiterunternehmens betrieben, und ich habe dort meine Fähigkeiten erworben.

Ich bin weitergezogen, denn es war das frühe Silicon Valley—das bedeutete viel freiwillige Volatilität. In meinen ersten acht Berufsjahren arbeitete ich für fünf verschiedene Firmen; es war einfach unglaublich turbulent. Schließlich sagte ich: Ich brauche Sicherheit, ich arbeite besser selbständig.

Dann wurde ich Berater und arbeitete in zehn Jahren für 60 verschiedene Firmen. Immer das gleiche Ziel: Technologielösungen für Geschäftsprobleme finden. Das ist im Kern das Wichtigste. Bei einer Firma, für die ich beriet, wurde mir eine unwiderstehliche Festanstellung angeboten. Ich leitete deren IT, wurde CIO und setzte viele Methoden um, die sich als Scrum-Praktiken herausstellten—ohne, dass mir damals klar war, dass sie so heißen. Menschen ermächtigen, Probleme zu lösen und Arbeit über den Return-on-Investment zu rechtfertigen.

Damals machte ich viele Projekte, die meine Sicht darauf prägten, wie man Vorhaben organisiert. Vieles, worauf ich stolz bin. Die Firma hatte schwer daran gearbeitet, mithilfe eines prominenten Dreibuchstaben-Computerunternehmens eine Website auf die Beine zu stellen und für eine ziemlich enttäuschende E-Commerce-Lösung ein Viertelmillion Dollar gezahlt. Ich sah großes Verbesserungspotenzial. Also organisierte ich ein Projekt, stellte Scrum-ähnliche Linien auf.

Wir hatten zwei verschiedene Technologietypen: ein IBM-Minikomputer als Backend (AS/400), und für das Frontend reiste ich nach China, fand dort ein kleines, ambitioniertes Unternehmen, das den Frontend-Teil übernommen hat. Das US-Team machte den Backend-Part. Unsere Hauptaufgabe war, die zwei Plattformen miteinander zu verbinden.

Das erwies sich als einfach. So ersetzten wir eine Entwicklung für eine Viertelmillion Dollar durch eine Website, die innerhalb von sechs Monaten 40% des Firmenumsatzes brachte – und das für 14.000 Dollar. Es war simpel: Kompetente Leute freisetzen, Problem lösen lassen.

Teams können auf verschiedenen Kontinenten sitzen—wichtig ist nur das Schnittstellenmanagement.

Galen Low: Da haben wir es: Schlanke Teams, Datenkontrakt und los geht's.

Fred Fowler: Genau. Und entscheidend war, zu erkennen, was man eigentlich messen sollte.

Viele bekommen Panik bei Offshore-Teams: Wie kontrollieren wir, was sie tun? Viele wollen dann Tools, um zu messen, wie viel gearbeitet und wie beschäftigt Menschen sind. Man möchte permanent Beschäftigung sicherstellen.

Aber raten Sie: Das spielt keine Rolle! Es ist unerheblich, ob Offshore-Leute beschäftigt sind. Wichtig ist einzig, was tatsächlich geliefert wird – der Wert dessen, was geliefert wird. Das sollte man messen. Aufhören, Stoppuhren auf Leute anzusetzen, das ist zweitrangig!

Zum Beispiel: Ein Team mit über 200 Leuten arbeitet zwei Jahre lang acht bis zehn Stunden täglich gegen ein zehnköpfiges Team, das ein Jahr lang normale Stunden einlegt—wer liefert mehr Wert? Tatsächlich haben die 200 Leute healthcare.gov gebaut, das als katastrophales Beispiel in die Geschichte einging: Ein 200-Mann-Projekt, gemessen an Beschäftigung; danach ein kleines Team, das in kurzer Zeit echten Mehrwert geliefert hat.

Galen Low: Lass uns da einhaken. Du hast die Gründe angesprochen, warum Beschäftigung gemessen wird. In meiner Agentur-/Beratungserfahrung dreht sich alles um abrechenbare Stunden, Auslastung, Bugs, abgehakte Aufgaben.

Warum neigen wir dazu, Beschäftigung zu messen?

Fred Fowler: Ganz einfach: Es ist leicht zu messen. Alles, was Sie brauchen, ist eine Uhr, um Beschäftigung zu erfassen. Um Fristen einzuhalten, ein Kalender. Es ist leicht. Es ist auch die Basis für Vergütung.

Abrechenbare Stunden wurden erwähnt – das ist ein großer Irrglaube. Die Zeit der Menschen ist ihnen selbst wertvoll, aber für Sie zählt, was sie in dieser Zeit leisten. Es wäre viel sinnvoller, einen guten Maßstab dafür zu haben, was mit dieser Zeit geschaffen wird.

Wenn ich mit Unternehmen spreche, sage ich: Findet heraus, wie viel das, was ihr erstellen wollt, wert ist, teilt es in sinnvolle Einheiten, macht es messbar und messt Fortschritt an der Wertschöpfung. Im Lean-Ansatz gibt es das Konzept des Minimal Viable Product (MVP).

Man entwickelt erst einmal minimal, was nötig ist, um etwas dem Kunden zu geben. Warum ist das ein gutes Konzept? Weil ein Produkt, sobald es in Kundenhänden ist, Wert hat—der Kunde kann selbst diesen Wert beziffern. Und daran kann man bemessen, ob der Wert den Aufwand rechtfertigt.

Kostet eine App 500.000 Dollar und wird 3 Millionen Mal à 2 Dollar verkauft, hat man 6 Millionen umgesetzt. Das ist ein gutes Geschäft! Bei nur 25.000 Downloads hingegen, entstehen auf 500.000 Dollar Kosten nur 50.000 Dollar Wert. Gleich viel Aufwand, aber der Wert unterscheidet sich. Der Wert ist entscheidend!

Galen Low: Zum MVP hast du einen wichtigen Punkt angesprochen. Oft messen wir Beschäftigung auch aus Misstrauen heraus. Wir glauben, wenn wir die Zeit kontrollieren, wissen wir wenigstens, dass gearbeitet wird.

Aber es misst keinen Wert. Ich höre häufig: „Wir brauchen aber abrechenbare Stunden, das ist der Vertrag, die Vergütung.“ Das Schöne am MVP ist: Bringt etwas raus, tätigt die Investition, dann kann der Kunde entscheiden, ob es Wert hat. Manche wollen vor der Investition wissen, ob sie sich lohnt—das ist aber in der Realität selten möglich.

Wie siehst du das Thema Zeit-für-Geld-Modell? Ist es ein notwendiges Übel oder sollten wir versuchen, uns davon zu lösen?

Fred Fowler: Es ist in gewisser Weise ein notwendiges Übel. Dennoch muss die Gegenüberstellung von Kosten und Nutzen erfolgen. Hier ist etwas am Scrum-Framework interessant: In Scrum erstellt man in jedem Sprint etwas Fertiges, das dem Kunden übergeben werden kann.

Warum ist das wichtig? Weil nur dann Wert entsteht—wenn das Ergebnis fertig und nutzbar für den Kunden ist.

Und genau daran misst man Wert: Wieviel ist ein Kunde bereit, dafür zu zahlen? Scrum verlangt alle zwei Wochen ein wertvolles Produktinkrement, das man mit den Herstellungskosten vergleichen kann. So weiß man frühzeitig, ob man auf Kurs für ein 6-Million-Dollar-Produkt mit 500.000 Dollar Einsatz ist – oder für ein 50.000-Dollar-Produkt mit 500.000 Dollar Kosten. Es geht um messbaren, keinen geschätzten Wert.

Scrum legt Wert darauf, Entscheidungen anhand messbarer Tatsachen zu treffen, nicht auf Vermutungen. Am wichtigsten ist es, Wert zu messen!

Galen Low: Kannst du kurz beschreiben, wie Wert gemessen wird? Wenn Beschäftigung messen wenig bringt, welche Metriken sollten Teams also heranziehen, zum Beispiel ein Scrum-Team? Und wie wird von Sprint zu Sprint evaluiert, ob ein Produktinkrement Wert hat?

Fred Fowler: Im Scrum-Framework ist die Wertmessung hauptsächlich Aufgabe einer einzigen Rolle: des Product Owners. Scrum teilt Verantwortung auf in Product Owner, Entwickler:innen und Scrum Master.

Der Product Owner soll den Wert der Teamarbeit maximieren. Das geht nur, wenn man Wert messen kann; sonst weiß man nicht, ob etwas besser wird.

Es gibt vier Wege, Wert zu steigern. Am häufigsten: Erlös steigern. Entwickeln Sie zum Beispiel eine App und verkaufen sie 3 Millionen Mal à 2 Dollar – dann ist deren Wert 6 Millionen Dollar. Zweite Möglichkeit: Kosten senken. Produzieren Sie eine Million Artikel jährlich und sparen 50 Cent pro Stück, ist das eine halbe Million Wert. Dritte Möglichkeit: Risiko verringern.

Als CIO habe ich das gemacht. Unsere Zentrale hatte eine kritische Datenleitung, die jährlich von Bauarbeiten gekappt wurde und dem Unternehmen 1 Million Dollar Tagesausfall verursachte. Das Risiko betrug 1 Million pro Jahr. Es war sinnvoll, das Rechenzentrum für 50.000 Dollar umzuziehen und so das Risiko zu eliminieren: 50.000 Dollar gegen 1 Million Dollar jährlichen Verlust.

Galen Low: Nur 50K für den Umzug? Großartig.

Fred Fowler: Ja, wir mieteten einfach Racks in einem Rechenzentrum – ganz einfach, hohe Sicherheit, beste Verbindung. Risiko reduziert, Wert geschaffen.

Der vierte Weg, Wert zu steigern, ist Opportunitätserhöhung. Wenn Sie bei Ausschreibungen mehr Aufträge gewinnen, steigert das den Wert nachweisbar. Sie können leicht kalkulieren, ob sich die Maßnahme lohnt.

Galen Low: Der Product Owner misst also Wert, trifft auf dieser Basis Entscheidungen, aber entwickelt das Team daran orientiert? Wird das Feedback nach jedem Sprint weitergegeben?

Fred Fowler: Genau. Für jede der vier Wertformen misst der Product Owner und legt fest, woran das Team arbeiten soll. Man kann Wert aber nur messen von Dingen, die es tatsächlich gibt; der Product Owner muss daher Vermutungen anstellen, was wertvoll werden könnte, und das Team daran setzen. Dann sehen wir, ob Kunden bereit sind, dafür zu zahlen oder ob Kosten gespart werden. Man misst den Wert nachträglich – darauf basieren zukünftige Investitionsentscheidungen.

Der Product Owner trifft Investitionsentscheidungen. Ob er gute Arbeit macht, zeigt sich an der Rendite: Erbringt ein Sprint für 50.000 Dollar auch mindestens diesen Wert? Das Team sollte mitdenken, denn warum sollte jemand 50.000 Dollar zahlen, wenn der Wert geringer ist? Product Owner und Team sitzen da im selben Boot.

Galen Low: Ein sehr prägnanter Punkt: Zu oft sind wir im Mindset „Ich habe 80 Stunden gearbeitet, das ist ja wohl den Preis wert!“ Aber so ist das nicht – das ist Zeit gegen Geld, nicht Wert.

Fred Fowler: Ganz genau. Entwickler:innen sollten verstehen, dass auch sie daran interessiert sind, wertvolle Arbeit zu leisten.

Product Owner ist eine betriebswirtschaftliche Rolle, Entwickler:innen eine technische. Der Product Owner beschreibt, was wünschenswert wäre, die Entwickler:innen sagen, was möglich ist. Im Dialog findet man heraus, was praktisch und wertvoll ist. Scrum ist der Rahmen für diese Aushandlung.

Galen Low: Partnerschaft ist da ein gutes Wort. Viele sehen das zunächst nicht so. Oft herrscht das Dienstleister-Denken: „Der Product Owner sagt an, wir machen das.“ Dabei ist Scrum eigentlich Empowerment: Kompetenz fördern, Verhandlung zwischen Wunsch und Machbarkeit – damit am Ende ein praktisches, wertgenerierendes Produkt entsteht, das nicht das Budget sprengt.

Fred Fowler: Absolut. Entwickler:innen können übrigens oft zum Wert beitragen, indem sie innovative, pragmatische Lösungen vorschlagen. Beispiel: Für eine Login-Funktion könnte das Team „Sign in with Google“ vorschlagen – das ist schneller und günstiger als eine Eigenentwicklung. Entwickler:innen sollten in Wert-Kategorien denken, nicht nur ausführen, was gefordert wird.

Galen Low: Ich erwische mich selbst dabei, oft Geschwindigkeit oder Arbeitsauslastung zu messen. Wie sieht die Wertdiskussion in Scrum-Teams konkret aus? Wird nachgerechnet „Wir dachten, das Feature sei X Wert, aber der Markt ist anderer Meinung“? Optimiert das Team dann gezielt den Wert oder werden eher Richtungswechsel vorgenommen?

Fred Fowler: Meist hängt es an der Vergütungsart. Bei Stundenlohn sind alle motiviert, alles so aufwendig wie möglich zu machen. Das ist leider Realität in vielen Projekten—viele Menschen, viele Meetings, viele Reports, viel throwaway Code. Nach Jahren und Millionen wurden oft nur Aktivitäten erzeugt, aber kein Wert.

Was wäre die richtige Vergütungsform? Zunächst zahlt man Marktsätze, um talentierte Leute zu gewinnen. Aber dann sollte das Team am erzeugten Wert beteiligt werden. Erschafft ein Team etwa 100.000 Dollar Wert, sollten z.B. 20% davon direkt ans Team gehen—und das Team entscheidet selbst über die Aufteilung. Das motiviert alle zur Wertschöpfung.

Galen Low: Das ist vergleichbar mit Gewinnbeteiligung für Teams. Sehr spannende Herangehensweise: Grundgehalt plus Bonus, abhängig vom erzeugten, messbaren Wert durch die Product Owner.

Fred Fowler: Es synchronisiert die Anreize. Das Scrum-Framework bringt die Verantwortung dorthin, wo fähige Leute sie tragen können. Die Product Owner dürfen investieren—aber die Ergebnisse werden gemessen. Die Entwicklungsteams entscheiden, wie sie es umsetzen—niemand schreibt genau vor, was zu tun ist. So übernimmt das Team selbst Verantwortung für das Ergebnis.

Galen Low: Unsere Branche fördert Accountability leider wenig, es herrscht oft Kommando-Abarbeitung.

Fred Fowler: Richtig. Wenn Teams sich ihre Aufgaben nicht selbst wählen, können sie auch nichts daraus lernen, Fehler wiederholen sich. Scrum verlangt daher selbstorganisierte, crossfunktionale Teams—nur dann können keine Finger auf andere gezeigt werden.

Und nur diejenigen, die es tatsächlich tun müssen, verstehen die Herausforderungen. Wie oft wurden Sie schon vor „unmöglichen“ Aufgaben gestellt? Mir ist das oft passiert.

Galen Low: Das ist wirklich witzig!

Es ist wirklich eine Balance zwischen Empowerment und Verantwortung. Das entwickelt sich nicht von heute auf morgen.

Fred Fowler: Genau, es braucht drei Dinge: Befähigung, Verantwortung und Fähigkeit. Product Owner:innen müssen den Mut haben, große Summen für wertschaffende Produkte zu investieren. Entwickler:innen müssen das Produkt eigenverantwortlich umsetzen können. Die größte Herausforderung für Scrum Master ist es, die Teams an diese Verantwortung heranzuführen.

Ein Vergütungssystem, das für den geschaffenen Wert belohnt, hilft dabei: Werden keine guten Ergebnisse erzielt, gibt es keinen Bonus. Nur messbare Wertschöpfung wird belohnt.

Galen Low: Eine klare Aussage: Wert messen und Wert belohnen.

Fred Fowler: Ganz genau. Noch ein Punkt: Ein Produkt sollte einen messbaren Wert haben. Kann man diesen Wert nicht messen, handelt es sich nicht um ein Produkt; rationale Entscheidungen über die Entwicklung sind dann unmöglich.

Ich war zum Beispiel in einer Firma, die drei Produktbestandteile hatte: Frontend (Website), APIs als mittlere Schicht, Backend (Verarbeitung). Es gab drei Product Owner, einen je Schicht—ständig Konflikte zwischen ihnen, Features wurden teils jahrelang verzögert, weil kein PO dafür verantwortlich war oder es keine Auswirkungen auf seine Vergütung hatte.

Dabei kann man den Wert nur an der gesamten Wertkette messen. Daher sollte es einen einzigen Product Owner für das gesamte Produkt geben. Dann sind rationale Prioritäten- und Investitionsentscheidungen möglich.

Galen Low: Oft verhindert Politik Wertschöpfung.

Fred Fowler: Ja, völlig richtig. Wenn der Wert von Beschlüssen nicht messbar ist, sind die Entscheidungen zufällig. Es fehlen rationale Gründe.

Galen Low: Wir sprechen von der minimalen, nutzbaren Erfahrung als Ziel. Teams, die meinen, Scrum nicht zu können, weil sie keine Inkremente oder MVPs liefern, sollten einfach den Fokus auf produktorientierte Arbeit richten—also wertorientierte Slices statt technische Layer.

Fred Fowler: Ich habe dazu mit Jeff Sutherland gesprochen, einem Mitbegründer von Scrum. Er bestätigt: Ein Produkt ist etwas, das produziert und dessen Wert objektiv gemessen werden kann. Ist das nicht möglich, ist man Teil eines größeren Ganzen—das eigentliche Produkt ist dann die Bezugsgröße für alle Entwicklungsentscheidungen.

Galen Low: Letzte Frage zum Abschluss: Funktioniert die Fokussierung auf Wert und Impact über Beschäftigungsgrad auch bei anderen Methoden als Scrum? Was rätst du diesen Menschen?

Fred Fowler: Andere Methoden? Ja. Scrum baut auf darunterliegenden Prinzipien auf, Agilität ist eine Schicht darüber. Scrum ermöglicht Produktentwicklung ohne Rezept—klassisches PMI/Waterfall setzt dagegen auf umfassende Planung und vordefinierte Rezepte.

Der Haken: Die äußeren Umstände ändern sich immer. Roman Pichler, ein bekannter Autor über Scrum, beschreibt in seinem Buch eine zweijährige Medical Project-Replattform nach Waterfall, die am Ende zum Zeitpunkt der Abgabe schon veraltet war—bei perfektem Plan und Kostenkontrolle.

Scrum empfiehlt: Rezepte sind nicht hilfreich. Machen Sie Inkremente, kontrollieren Sie fortlaufend den Wert und lernen Sie daraus. Aber: Auch Scrum selbst ist streng genommen nur ein Rezept. Das wahre Fundament liegt tiefer: Fokussieren Sie sich auf Teams, die Verantwortung für Entscheidungen übernehmen—sowohl im Business wie in der Produktentwicklung. Teams müssen in der Lage sein, Ergebnisse selbstständig zu liefern und sich zu organisieren. Und dann braucht es eine Methode, um den Wertzuwachs zu messen.

Das ist die Basis von Scrum – und der Erfolg aller Methoden. Mein Rat: Messen Sie Wert statt Aktivität, messen Sie Ergebnisse statt Outputs. Egal welches Framework—entscheidend ist, dass Sie Wertschöpfung messen, lernen und sich weiterentwickeln. Das ist der Schlüssel zum Projekterfolg.

Galen Low: Das war's! Sehr cool.

Fred, erzähl doch noch, wo man mehr über deine Meetup-Gruppe und deine Bücher erfahren kann?

Fred Fowler: Seit 2015 leite ich ein Scrum-Meetup – die „Advanced Scrum Case Studies“-Gruppe.

Alle zwei Wochen treffen wir uns online, ich stelle einen Case vor, meist rund um Scrum oder Projektmanagement (z. B. Offshore-Teams, Wertmessung). Wer interessiert ist, kann gerne beitreten: Suchen Sie einfach nach „Silicon Valley Professional Scrum Meetup“ auf Meetup – dann finden Sie unsere Advanced Scrum Case Studies. Ich würde mich freuen! Aus der Gruppe ist viel spannendes Material hervorgegangen – ich habe ca. 60 Cases gesammelt und in einem Band namens „Advanced Scrum Case Studies“ veröffentlicht. Das Buch ist bei Amazon und auf meiner Webseite erhältlich: www.siliconvalleyscrum.com.

Enthalten sind 15 ausgewählte Fälle; Band 2 ist in Arbeit. Ich habe über 60 Fälle als Vorrat und es kommen ständig neue dazu.

Galen Low: Super cool! Ich wusste nicht, dass das Buch direkt auf die Meetup-Diskussionen zurückgeht.

Fred Fowler: Genau, dem ist so!

Galen Low: Fred, vielen Dank für deinen Besuch in der Sendung heute – ich habe deine Geschichten, deine Perspektive und den Diskurs zur Vergütung sehr genossen. Ich glaube, das wäre eine ganz eigene Episode! Ich hoffe, alle Zuhörer:innen nehmen viel Mehrwert daraus mit. Danke dir!

Fred Fowler: Danke! Es hat mir sehr viel Spaß gemacht.

Galen Low: Was denken Sie?

Ist es realistisch, Projektteams an der Wertschöpfung statt an gearbeiteten Stunden oder erledigten Tasks zu orientieren? Oder sind wir zu sehr vom Geld-für-Stunden-Modell abhängig?

Erzählen Sie uns Ihre Geschichte: Welche Kennzahlen haben für Ihre Projekte am besten funktioniert? Welche Veränderungen oder Ergebnisse haben Sie durch Einblick in Ihre Projektdaten erlebt?

Hinterlassen Sie Ihre Gedanken in den Kommentaren unten!

Und wenn Sie Ihre Fähigkeiten als strategische Projektleitung ausbauen möchten, kommen Sie in unsere Community!

Besuchen Sie thedigitalprojectmanager.com/membership für Zugang zu einer unterstützenden Gemeinschaft, die Wissen teilt, komplexe Herausforderungen löst und gemeinsam die Branche weiterentwickelt.

Von praxisfertigen Templates über monatliche Trainings, die Zeit und Energie sparen, bis hin zum Austausch in Slack, Live-Events und Mastermind-Gruppen: Ein Mitglied unserer Community zu sein, bedeutet, über tausend Menschen an der eigenen Seite zu haben, wenn Sie Ihre Karriere in Digitalprojekten gestalten.

Und falls Ihnen die heutige Folge gefallen hat, abonnieren Sie uns und bleiben Sie auf thedigitalprojectmanager.com in Kontakt.

Bis zum nächsten Mal – danke fürs Zuhören!