Der Begriff Projektmanagement ist Teil der täglichen Kommunikation in Unternehmen. Insbesondere in Zeiten der Digitalisierung sprießen Modewörter wie agiles Projektmanagement, hybrides Projektmanagement, klassisches Projektmanagement, SCRUM, und Co wie buchstäbliche Pilze aus dem Boden. Doch was verbirgt sich hinter dem Begriff, warum gibt es bei Sandstorm keine separaten Projektmanager und wie funktioniert das Ganze überhaupt?
Nun, seit über 10 Jahren meistern wir Projekte für unsere Kunden. In der Zusammenarbeit beobachten wir immer wieder echte Freude, Spaß und eine selten gesehene Leichtigkeit auf beiden Seiten. Langjährige und wiederkehrende Kunden sind nur ein positiver Effekt davon. Da fragen wir uns natürlich: Woran liegt das?
Spoiler! Eine einfache Antwort haben wir nicht gefunden. Unsere Prinzipien reflektieren wir ständig und können sie so mittlerweile gut artikulieren. (Wohlgemerkt hat es knapp 10 Jahre gedauert, um unsere Erfahrungen in diesen Artikel zu gießen ;-)) Jedes unserer Projektmanagement-Artefakte für sich genommen, mag logisch und selbstverständlich klingen. Doch nur die Kombination und konsequente Umsetzung sorgt für unglaublich produktive Ruhe, Gelassenheit und Vertrauen auf beiden Seiten.
Dieser Artikel stellt die wichtigsten Prinzipien unserer Projekt(management)-Philosophie im Detail vor. Der Übersichtlichkeit halber mit Inhaltsverzeichnis ;-)
Bevor wir eintauchen, noch eine kurze Geschichte zur Einstimmung.
Es war einmal Sandstorm Projektmanagement...
...vor nicht allzu langer Zeit, als wir mit unserem Kunden im Kick-Off-Workshop unseres bisher größten Projekts saßen. Zum Ende des Workshops, nachdem wir die Planung besprochen hatten, spürte ich eine Erwartungshaltung beim Kunden wachsen. Diese hatten wir in den vergangenen Stunden durch Fragen und direkte Antworten selbst aufgebaut. In dieser schwebenden Situation musste ich folgendes Statement loswerden:
"Obwohl wir heute den Eindruck vermittelt haben, dass wir alles verstanden haben, sollte euch das Folgende bewusst sein:
Wir werden im Laufe des Projekts dumm-erscheinende, naive Fragen stellen. Wir werden die scheinbar gleichen Dinge fünfmal fragen. Nicht, weil wir zu blöd sind,sondern weil wir sicher gehen wollen, dass Frage und Antwort zu einander passen und auf dem selben Verständnis der Realität aufbauen.
Wir werden Deadlines reißen. Bei einem Projekt dieser Größe gibt es Unbekannte, die wir heute noch nicht kennen und die uns überraschen werden. Alles, was wir euch heute versprechen können, ist, dass wir euch sofort informieren werden, wenn dies absehbar ist, um gemeinsam eine Lösung finden.
Unsere Software wird Bugs enthalten. Und wir werden euch so früh wie möglich mit Zwischenständen konfrontieren, bei denen ihr die Hände über dem Kopf zusammenschlagen werdet. Wir wollen so früh wie möglich euer Feedback, ob das, was wir entwickeln, auch eurem Ziel entspricht. Dazu gehört auch, dass ihr Bugs finden werdet, denn keine Software ist fehlerfrei."
Die während des Statements zunehmend entgleisenden Gesichtszüge bedürfen sicher keiner Beschreibung. Solch eine direkte Aussage war man von externen Dienstleistern nicht gewohnt. Nach kurzer Stille, in der die Informationen sackten, entspannte sich das Gespräch deutlich.
RE.A.L inspiriert
Als ich Sven Ditz (Gründer von sitegeist) zum ersten Mal über seinen, später RE.A.L. genannten, Ansatz habe sprechen hören, war ich nachhaltig beeindruckt (Vortrag von Sven Ditz: Do the RE.A.L Thing: No Waste Projects).
Keine Verträge? Alles nach Aufwand abrechnen? Keine Diskussionen mit dem Kunden über halbe Stunden auf der Rechnung? Den Kunden beim Pitch so überzeugen, dass er andere Anbieter gar nicht mehr hören will?
Das alles klang zu schön, um wahr zu sein. Sven erzählte es so überzeugend, dass ich diese Methodik bei Sandstorm unbedingt ausprobieren wollte.
Diese neuen Gedanken fielen bei mir auf fruchtbaren Boden: Ich hatte bereits einige Jahre Projektmanagement-Erfahrung in einem internationalen Konzern gesammelt. Gantt-Charts, Powerpoint Statusberichte, Executive Summaries und Contract Changes waren mir wohl vertraut. Zusätzlich hatte ich einige Bücher gelesen, die das Thema aus ganz anderer Richtung betrachteten, z.B. The 7 Habits of Highly Effective People oder Critical Chain Project Management. Meine Sandstorm-KollegInnen ließen durch gemeinsame Reflexion ihre Perspektiven und Erfahrungen einfließen.
Das Ergebnis: unsere Sandstorm Projektmanagement-Philosophie
Win-Win or No Deal
Alle unsere Projekte stehen unter der Prämisse Win-Win or No Deal. Sowohl unsere Kunden, als auch wir müssen vom gemeinsamen Arbeiten profitieren. Darauf zielen wir von der ersten Minute des Kennenlernens ab und richten unsere Kommunikation darauf aus. Wir erwarten nicht, dass alle unsere Kunden diese Herangehensweise teilen. Nachdem wir sie jedoch transparent gemacht haben, tritt i.d.R. eine Veränderung auf Kundenseite ein und man spürt ehrlichen Respekt.
Bis jetzt hat sich jeder auf das Ziel der Win-Win Situation eingelassen. Die klare Kommunikation und Haltung, dass "No Deal" auch eine Option ist, ist für viele Kunden neu, da sie es gewohnt sind, dass Dienstleister das Projekt unbedingt haben wollen und bereit sind beinahe alles dafür zu tun. Die Option verändert die Spielregeln des Gesprächs. Es ist nun Verhandlung auf Augenhöhe.
Unser Beharren darauf, eine Win-Win Situation für beide Parteien zu kreieren, zeigt dem Kunden, dass uns seine Interessen ebenso wichtig sind wie unsere. Unter Win-Win verstehen wir, einen Mehrwert für den Kunden zu kreieren, für den er mehr als glücklich ist den angebotenen Preis zu zahlen (siehe auch Schätzungen). In seinen Augen sind wir für die Erreichung seiner Ziele die wirtschaftlichste Option.
Ein weiterer Win für beide Seiten besteht darin, dass die Zusammenarbeit Spaß macht und alle Involvierten etwas während des Projekts lernen. Sandstormer lieben die Herausforderung und wenn sie in Projekten neues lernen. Die Herausforderung spornt uns an.
Big Picture
Es ist uns wichtig, von Anfang an das sogenannte "Big Picture" des Kunden zu verstehen. Welches Problem möchte unser Kunde für seine(n) Kunden lösen? Was ist sein Geschäftsmodell? Wie hilft ihm das Projekt, seine Ziele zu erreichen?
Während dieses Verständnisprozesses kommt es oft genug vor, dass wir von einem gemeinsamen Projekt abraten.
Wieso? Oftmals ist eine Standardsoftware die wirtschaftlichere Alternative. Auch im Hinblick auf diese Lösungsmöglichkeit wollen wir beraten. Uns ist wichtig, dass sich der Kunde für eine Individualentwicklung entscheidet, weil seine Anforderungen von keiner Standardlösung abgedeckt werden. Dies ist bei wertschöpfenden Kernprozessen oft der Fall, aber nur selten bei Randprozessen. Dort sollte sich ein Unternehmen, unserer Meinung nach, gut überlegen, ob es eine Software an seine Prozesse anpasst oder andersrum.
Wenn wir meinen, das Problem des Kunden verstanden zu haben, überlegen wir, wie wir es mit möglichst geringen Kosten lösen können. Dies hat mehrere Vorteile für uns: Entscheidungen für günstigere Projekte fallen schneller, die Risiken sind kleiner und leichter zu identifizieren, kleinere Projekte sind i.d.R. schneller abgeschlossen und generieren den Mehrwert früher. Darüber hinaus stärkt es unsere Vertrauenswürdigkeit, wenn der Kunde realisiert, dass seine Interessen wirklich an erster Stelle stehen und wir nicht versuchen, möglichst viel Geld mit ihm zu verdienen.
Schätzungen
Die Glaskugel
Projekte zu schätzen ist eine Wissenschaft für sich - leider keine exakte. Auch wenn die fixe Zahl dies unter dem Angebot suggeriert. Eine Schätzung ist immer eine (bestenfalls gute) Mischung aus Erfahrung, unvalidierten Annahmen, Wunschdenken, Glaskugel-Lesen und Risikopuffer.
Eine Wahrheit, die wir unseren Kunden immer wieder in Erinnerung rufen: Projekte sind per Definition einmalige und vorher noch nie durchgeführte Unternehmungen. Dieses konkrete Projekt wurde mit diesem Scope, diesen Beteiligten und unter diesen Bedingungen noch nie gemacht. Niemand kann also vorher sagen, wie viel es exakt kosten wird. Wie viel genau ein Projekt mit uns gekostet haben wird, wissen wir (leider) erst am Ende.
Der Wert von Schätzungen
Ob No Estimates, Raw Estimates oder Detailed Estimates, für uns ist das gründliche Nachdenken über die Anforderungen und wie wir sie umsetzen können entscheidend. Währenddessen fallen uns Anforderungen auf, in denen Risiko steckt oder wir entdecken Annahmen, die wir validieren müssen. Unser Ziel ist es, uns so detailliert mit dem Projekt auseinandergesetzt zu haben, dass wir bei Beauftragung direkt mit der Umsetzung beginnen können.
Mittlerweile sind wir dazu übergegangen, unsere Schätzungen komplett transparent zu machen. Auch Festpreisangebote enthalten unsere Detailschätzung. Kunden sehen direkt unseren kalkulierten Risikopuffer. Im Extremfall erstellen wir die Schätzung im Kennenlerngespräch direkt mit dem Kunden. So können wir Annahmen, die uns während der Schätzung bewusst werden, direkt validieren oder widerlegen. Das Ergebnis ist eine inhaltlich, also von den zu bewältigenden Aufgaben, passende Schätzung.
Agil und Lean
"Planning is useful. Blindly following plans is stupid." (Jeff Sutherland)
Lean bedeutet für uns nicht nur das Weglassen von Verschwendung (Muda), sondern auch die Fokussierung auf das Wesentlich, das Wertschöpfende. Dieser Methodik folgend entfällt damit das Pflichtenheft in der Softwareentwicklung. Unsere Schätzung und ein grobes technisches Konzept reichen meist aus, um dem Kunden schriftlich unser Projektverständnis zu vermitteln. Den zeitlichen Aufwand, der in die Erstellung eines Pflichtenheftes samt Korrekturschleifen fließt, investieren wir lieber in die Projektumsetzung.
Dies trifft ebenso auf schriftliche Projektstatus-Reports und viele weitere Elemente des klassischen Projektmanagements zu (viele davon enden auf -plan ;-) wie bspw. Projektstrukturplan, Projektablaufplan, Ressourcenplanung, Claim Management und und und...)
Agil, also das Arbeiten in Iterationen zwischen denen die Richtung geändert werden kann, setzen wir während des Projekts mit SCRUM um. Wir streben eine Balance zwischen Lean und Agil an: detailliertes Projektverständnis und gleichzeitig keine Zeit mit Dokumentation und Pflege von veralteten Information vergeuden. Wir planen also so viel wie nötig und so wenig wie möglich, um eine belastbare Schätzung erstellen zu können. Alles weitere ist dann Teil des Projekts.
Festpreis-Schätzungen
Wie bereits oben erwähnt, gibt es bei uns nur eine Schätzung. Um aus einer Aufwandsschätzung eine Schätzung für ein Festpreisangebot zu machen, addieren wir einen kundenspezifischen Risikopuffer. Transparent - als Teil der Schätzung.
Die Natur einer Festpreis-Schätzung liegt in der Risikoübertragung auf den Dienstleister. Gelingt die Umsetzung zügig, kann er eine hohe Marge einfahren, ist der Aufwand höher, sinkt die Marge und wird im Extremfall sogar zum Verlustgeschäft. Dem Kunden kann es egal sein, er zahlt den vereinbarten Preis. Entweder zahlt also der Kunde mehr, als er eigentlich müsste oder der Dienstleister bekommt weniger, als er Aufwand hatte (alle Schuldfragen bewusst ausgeklammert). Für uns klingt das nicht nach einer Win-Win-Situation.
Es gibt einen dritten Weg. Bei Festpreisprojekten ist dem Kunden sehr wichtig, dass das eingeplante Budget nicht überschritten wird. Privat kennen wir das, wenn wir bspw. Handwerker beauftragen und einen Kostenvoranschlag verlangen/bekommen.
Um dieser Angst entgegenzuwirken, nehmen wir dieses Budget als Limit für unsere Entwicklung. Das Projekt priorisieren wir entsprechend unserer Methodik und erledigen immer die Aufgabe, die den höchsten Mehrwert erzeugt. Die tatsächlichen Entwicklungsaufwände ziehen wir dann vom Budget ab und beenden die Entwicklung, wenn das Budget verbraucht ist. Das Ergebnis ist ein Projekt, das in-Budget abgeschlossen wird, darin den höchsten Mehrwert für den Kunden generiert hat und wir haben durch die "Abrechnung" nach Aufwand unsere kalkulierte Marge verdient.
Von Wahrscheinlichkeiten und selbsterfüllenden Prophezeiungen...
Wer bis hierhin gelesen hat, ist bestimmt nicht mehr überrascht, dass wir gern nach Aufwand abrechnen. Warum erklären wir im Detail weiter unten (Abrechnung nach Aufwand). Hier möchte ich noch auf die Auswirkung und Effekte von Schätzungen eingehen.
Da sich eine Schätzung immer auf eine Aufgabe bezieht, die in genau dieser Form noch nie gemacht wurde, hat die Schätzung zusätzlich zu ihrer ersten Dimension "Wert" noch die zweite Dimension "Eintrittswahrscheinlichkeit". Eine Aufgabe hat außerdem immer eine Minimaldauer, sie kann von niemandem schneller erledigt werden. Die Verteilung der Zeiten, in denen eine Aufgabe von verschiedenen Leuten erledigt wird, folgt nun nicht einer Gauss-Verteilung, sondern einer Verteilung mit langen Verteilungsenden (Heavy-Tailed-Distribution).
Habe ich nun die Aufgabe eine Festpreis-Schätzung zu erstellen, werde ich mit einer hohen Eintrittswahrscheinlichkeit (80% oder 90%) schätzen. Damit wird die geschätzte Zeit aber nicht nur 30% oder 40% höher, als bei einer Eintrittswahrscheinlichkeit von 50%, sondern eher 100% und mehr.
Dieser Effekt verstärkt sich außerdem durch die selbsterfüllende Prophezeiung, dass eine Aufgabe, den ihr zur Verfügung stehenden Raum ausfüllt. Ist eine Aufgabe mit zwei Tagen geschätzt und bereits nach anderthalb Tagen fertig, dann tendieren (viele) Entwickler dazu, ihre Lösung aus Sportsgeist und intrinsischer Motivation heraus zu optimieren. "Es ist ja noch Budget übrig". Das dieses Budget für andere Aufgaben verwendet werden kann, die länger als geschätzt dauern, ist in diesem Moment nicht bekannt. Beide Effekte verstärken sich gegenseitig und führen zu hohen Schätzungen, die dann tatsächlich eintreten.
Eine andere Herangehensweise ist, mit einer Eintrittswahrscheinlichkeit von 50% zu schätzen. Ist beim Kunden ausreichend Vertrauen entstanden, versteht er, dass wir unsere Schätzungen nicht reißen, weil wir ihm mehr Stunden in Rechnung stellen wollen, sondern weil die Aufgabe so lang gedauert hat. Im Durchschnitt fährt der Kunde mit dieser Schätzmethode deutlich besser, da selbst eine gerissene 50% Schätzung selten an eine 90% Schätzung herankommt.
Risiko, Priorisierung und kritischer Pfad
Während der Schätzung entsteht bei uns das technische Konzept für ein Projekt. Darin beschreiben wir, unseren Lösungsansatz für die kritischen Teile, welche Technologien wir einsetzen wollen und wie die Architektur der Anwendung aussieht.
Risiken und Priorisierung
Die erste Komponente unserer Priorisierungen Beim Durchdenken der Kundenanforderungen und unseres Lösungsansatzes stoßen wir auf Teile, die potentielle Risiken darstellen können. Das können ein technische Risiken sein, bspw. für uns unbekannte Technologien oder Schnittstellen. Dies können aber auch Prozessrisiken sein, wenn unsere Arbeit bspw. auf der Zulieferung von Dritten aufbaut. Die Themen mit dem größten Risiko planen wir an den Beginn des Projekts. So erfahren wir frühestmöglich, ob es tatsächlich eintritt und ob unsere Mitigationsstrategie (Strategie zur Minderung/Abschwächung) effektiv ist. Im schlechtesten Fall, wissen wir so nach sehr wenig verbrauchtem Budget, dass eine grundlegende Annahme unserer Lösung falsch war und können das weitere Vorgehen mit unserem Kunden besprechen. Oft haben wir, basierend auf den neuen Erkenntnissen, bereits eine alternative Lösung parat.
Die Reihenfolge ist die zweite Komponente unserer Priorisierung. Sie ist in Aufgaben zwangsläufig enthaltene. So können wir bspw. das Styling von Frontend-Komponenten erst durchführen, wenn ein Designvorschlag vorliegt. Ein sinnvolles Design wiederum können wir erst erstellen, wenn wir die Anforderungen an die User-Experience verstanden haben, und so weiter und so fort.
Die dritte Komponente ist die Priorisierung der Funktionalitäten durch unseren Kunden. Uns ist bekannt, dass jede Anforderung unseres Kunden per Definition wichtig ist. Dennoch kann ein Entwickler stets nur an einer Aufgabe gleichzeitig arbeiten. Damit er nicht raten muss, welche Aufgabe als nächstes zu bearbeiten ist, ist es wichtig, dass unser Kunde die Aufgabenliste priorisiert hat. Drei mal Priorität 1 trifft es dabei nicht. Sondern eine einspaltige Liste. Bei zwei scheinbar gleich-wichtigen Aufgaben zu entscheiden, welche nun vor der anderen bearbeitet werden soll, ist schwierig. Und eine der wichtigsten Aufgaben des Kunden.
Der kritische Pfad
Alle drei Komponenten ergeben zusammen den kritischen Pfad des Projekts: wir planen die Aufgaben mit dem höchsten Risiko an den Projektanfang, ergänzen sie um die notwendigen Vorarbeiten und ordnen die vom Kunden priorisierten Funktionalitäten auf dem technischen Grundgerüst an.
Erfolgt diese Planung vollständig vor Projektbeginn? Nein, nicht vollständig. Meistens muss der Kunde nicht vor Projektbeginn jede Funktionalität in eine Reihenfolge bringen. Diese Feinplanung erfolgt rollierend während des Projekts für die nächste absehbare Zukunft - meist zwei bis vier Wochen.
Diese Vorgehensweise hat den Vorteil, dass wir, abgestimmt mit dem Kunden, immer an der gerade wichtigsten Aufgabe arbeiten. So vermeiden wir effektiv Placebo-Fortschritt im Projekt. Was wir mit Placebo-Fortschritt meinen, illustriert folgendes Gedankenexperiment: Einmal angenommen, wir würden zu Beginn des Projekts ein optisch ansprechendes User Interface entwickeln, welches jedoch über keinerlei Funktionalität verfügt. Wesentlich später im Projektverlauf stellen wir plötzlich fest, dass die von uns vorgesehene Datenbanklösung für das Projekt ungeeignet ist. Das Problem daran ist nun, dass für die UI-Entwicklung bereits ein Großteil des Budgets verbraucht wurde und wir nun vor einer großen technischen Herausforderung stehen. Diese wird sehr wahrscheinlich das Projekt verzögern und ebenfalls das Budget überschreiten.
Deshalb gehen wir die Punkte mit dem, unserer Meinung nach, größten Risiko zu erst an. Dies führt dazu, dass die gefühlte Entwicklungsgeschwindigkeit im Projekt immer schneller wird. Anfangs werden die Themen mit dem größten Risiko behandelt und das technische Grundgerüst erstellt. Hier sieht der Kunde i.d.R. sehr wenig Fortschritt, insbesondere im Bereich UI. Steigen wir nach Abschluss dieser Phase auf die Entwicklung von Funktionalitäten um, nimmt die gefühlte Geschwindigkeit stark zu, da der Kunde nun seine Funktionalitäten sieht.
Eisberge
Es kommt hin und wieder vor, dass wir eine Aufgabe falsch einschätzen. Entweder, weil wir sie über- oder unterschätzen, oder weil wir das Risiko an einer anderen Stelle vermuten. Wir nennen diese Aufgaben Eisberge, weil man ihre wahre Größe erst erahnen kann, wenn man direkt davor steht.
Eisberge sind für beide Seiten frustrierend. Zum einen ärgert sich der Kunde, da eine Aufgabe deutlich länger dauert als angenommen. Zum anderen ärgern wir uns, weil wir den Eisberg übersehen haben und nun mehr Aufwand hineinstecken müssen, als angenommen. Da wir, wenn wir nach unserer Methode vorgehen, aber per Definition an der aktuell am höchsten priorisierten Aufgabe arbeiten, ist es oftmals vom Kunden gewollt, dass wir den Eisberg überwinden.
Abrechnung nach Aufwand
Das Versprechen vom Festpreis
Im klassischen Projektmanagement ist das Abrechnungsmodell der Festpreis. Ein Projekt wird so lange geschätzt und geplant, bis alle Unklarheiten restlos beseitigt sind. Das Ergebnis ist ein Pflichtenheft, welches die Anforderungen und die daraus resultierende Anwendung im Detail beschreibt. Es folgt die Umsetzung dieses Plans. Am Ende steht die Anwendung, die sich der Kunde laut Pflichtenheft gewünscht hat und der Dienstleister erhält nach Abnahme die vereinbarte Vergütung, mit der er seine Zielmarge einfährt. Soweit die Theorie.
Unserer Erfahrung nach sehen Kunden im klassischen Projektmanagement nach Festpreismodell folgenden Vorteile:
das Risiko, dass das Projekt teurer wird als geplant, trägt der Dienstleister
der detaillierte Plan lässt den Zieltermin realistisch erscheinen
die Anforderungen sind durch die detaillierte Planung vollständig bekannt
Die Realität sieht leider oft anders aus: Die Anforderungen waren wider Erwarten nicht vollständig bekannt oder haben sich während der Projektlaufzeit geändert. Der ursprüngliche Zieltermin wurde aufgrund verschiedener Faktoren auf Kundenseite verschoben. Das Projekt wurde am Ende dennoch teurer als geplant.
Um die im Projekt auftretenden Risiken zu managen, preisen klassische Dienstleister diese mit einem Risikopuffer ein. Zusätzlich werden Prozesse wie Scope-Control und Contract Change Management etabliert. Man kann natürlich noch eine Schippe drauflegen und den Risiken mit noch mehr Planung begegnen. Oder man erwartet sie und baut sie in die Projektsteuerung ein. Wie man das Blatt auch wendet, dieser Projektmanagement-Overhead ist und bleibt unserer Meinung nach nicht wertschöpfend.
Abrechnung nach Aufwand
Kein Auftraggeber, jemals: "es wird so viel kosten, wie es kostet". Eine belastbare Schätzung ist also zwingend notwendig. Wenn unser Kunde und wir uns einig sind, dass wir das Projektziel verstanden haben, frieren wir das Projektbudget ein. Mehr als diese Summe wollen wir nicht kosten.
Jetzt haben wir ein Budget, den kritischen Pfad und arbeiten angelehnt an SCRUM. Aufgrund unseres Wunsches nach Transparenz, zeigen wir unserem Kunden tagesgenau unsere tatsächlichen Aufwände mittels einer eigens entwickelten Controlling-App namens Exply. Diese tatsächlichen Aufwände werden für einige Aufgaben höher, für andere niedriger sein, als geschätzt. Wir möchten diese tatsächlichen Aufwände abrechnen. Der tatsächliche Aufwand ist die Größe, auf der unser Kunde Entscheidungen treffen soll.
Im Projektverlauf controllen wir unsere tatsächlichen Aufwände gegen das Projektbudget und können so jederzeit sagen, wie viel Budget noch zur Verfügung steht. Da wir die Detailplanung rollierend mit dem Kunden machen und dieser durch die SCRUM-Methodik permanent über den Projektfortschritt informiert ist (bspw. via Dailys), ist das verbrauchte Budget und der geschaffene Mehrwert für beide Seiten zu jeder Zeit transparent.
Rechnungskürzung
Da wir unsere Aufwände vollständig transparent machen, kommt es vor, dass ein Kunde mit bestimmten Aufwänden nicht einverstanden ist. In so einem Fall soll der Kunde die Rechnung einfach kürzen - ohne Diskussion.
Natürlich möchten wir verstehen, warum der Kunde so denkt, um daraus für die Zukunft zu lernen. Aber das Diskutieren um halbe Stunden ist kräftezehrend und führt, wenn es häufiger auftritt, zu Demotivation. Wenn für solche Diskussionen dann noch "das Management" auf beiden Seiten benötigt wird, ist es um die Wirtschaftlichkeit geschehen.
Transparenz
Die Grundlage für viele gute Entscheidungen sind Informationen. Vorhandene Informationen allen Projektmitgliedern, die diese benötigen könnten, zur Verfügung zu stellen, ist für uns zwingend logisch. Transparenz ist der Standard bei Sandstorm. Das heißt, wir kommunizieren intern und mit unseren Kunden offen über Erkenntnisse und Probleme, die die Projektzielerreichung beeinflussen können.
Aufgrund dieser Herangehensweise konfrontieren wir unseren Kunden so früh wie möglich mit Zwischenständen der zu entwickelnden Software.
Dies hat aus unserer Sicht eine Reihe von Vorteilen:
unser Kunde kann direkt an seinem Produkt Feedback geben
er erfährt direkt, was die gemeinsame Priorisierung bewirkt
und erhält ein Gefühl für unsere Entwicklungsgeschwindigkeit und wie sich diese verändert
Unsere Kunden haben sich bisher jedes Mal schnell daran gewöhnt, dass wir ihnen Anwendungen gezeigt haben, die absolut unfertig aussehen und nur einen Bruchteil der gewünschten Funktionalität bieten. Dies hilft uns enorm dabei an einem frühen Zeitpunkt festzustellen ob wir Anforderungen falsch interpretiert haben, oder der Kunde diese ändern muss. In diesem frühen Entwicklungsstand hält sich der Anpassungsaufwand der Anwendung noch sehr im Rahmen und ist deutlich geringer, als wenn dies erst zur Endabnahme geschieht.
Zu den Informationen, die wir transparent mit unseren Kunden teilen, gehören auch ALLE projektbezogenen Aufwände. Nicht nur die Stunden, die wir dem Kunden in Rechnung stellen wollen, sondern auch alle Stunden, die wir NICHT in Rechnung stellen wollen und auch alle Stunden, die wir in projektspezifisches Lernen investiert haben. Da wir als Anspruch an uns selbst formuliert haben, "die harten Nüsse in Projekten zu knacken", kommt es recht häufig vor, dass wir im Projektverlauf etwas Neues lernen dürfen, was wir für den erfolgreichen Projektabschluss benötigen. Diesen Aufwand wollen wir unseren Kunden genauso zeigen, wie Aufwände für Qualitätsmanagement, Pair Programming, Testing und Dokumentation. Stunden, die wir nicht abrechnen wollen, können zum Beispiel entstehen, wenn wir für einen Kollegen beim Projekt-Onboarding grundsätzliche Dinge, die nichts mit dem konkreten Projekt zu tun haben, durchgehen.
Einsicht in diese Daten haben unsere Kunden jederzeit über unser Controlling-Tool Exply und bekommen diese vor der Rechnungsstellung zur Freigabe.
Projektmanager*in
Keine Person, sondern eine Rolle
Der Projektmanager als Teil des Projektmanagements hat in jedem Projekt die zentrale Rolle. Wichtig ist hier das Wort "Rolle". Bei Sandstorm gibt es keine Position "Projektmanager".
Dies hat verschiedene Gründe. Wir wollen, dass:
die Projektmanagement-Rolle von einer Person zur anderen weitergegeben werden kann, ohne dass Privilegien oder Status daran hängen,
die Person, die die Planung macht, auch die Umsetzung machen könnte,
die Person, die Zusagen gegenüber dem Kunden macht, weiß, was diese für das Entwicklungsteam bedeuten.
So soll eine hohe Qualität unseres Projektmanagements sichergestellt, eine realistische Planung durchgeführt und die Bildung von Flaschenhälsen verhindert werden.
Kommunikation, Kommunikation, Kommunikation
Die Rolle des Projektmanagers ist eine Führungsaufgabe. Für uns bedeutet dies, dass sie nicht einfach zusätzlich zu bestehenden Commitments obendrauf kommt. Sie wird stattdessen oberste Priorität, da sie andere Teammitglieder befähigt, effektiv zu sein. Gutes Projektmanagement ist eine Multiplikator-Funktion.
Im Zentrum der Arbeit des Projektmanagers steht die Kommunikation. Mit dem Team, dem Kunden, internen Teams, anderen Kunden-Teams, den Stakeholdern, und jedem anderen, der für den Projekterfolg notwendig ist. Es ist meine persönliche Erfahrung, dass die Kommunikationsfähigkeiten des Projektmanagers maßgeblich für den Projekterfolg sind.
Er ist dafür verantwortlich, dass :
allen Projekt-Teammitgliedern das Projektziel klar ist,
Fragen und Probleme, in- und extern, frühestmöglich kommuniziert werden,
und unser Kunde uns als vertrauenswürdig wahrnimmt.
Dies bedeutet, die maximale Fläche zum Kunden zu schaffen, indem die technischen Experten auf beiden Seiten direkt miteinander kommunizieren können und notwendige Entscheidungen des Kunden zielstrebig herbeigeführt werden. Bei Sandstorm nimmt der Projektmanager die Aufgaben des Scrum Masters wahr, da er füreffektive Meetingsverantwortlich ist. Also Meetings, die als wertvoll empfunden werden, weil sie Fragen und Prioritäten klären, falsche Annahmen aufdecken und Erwartungshaltungen transparent machen. Des Weiteren weiß unser Projektmanager, wie Eskalationswege im Projekt aussehen, falls dies notwendig sein sollte. Er weiß, wen er sich von außerhalb des Projekts zur Unterstützung heranziehen, bzw. an wen er den Kunden weiterleiten kann, falls ein Problem auf "Managementebene" geklärt werden muss.
Ein kleines Rechenbeispiel zum Thema Kommunikation:
Ein Projektteam mit 6 Mitgliedern trifft sich jeden Tag für 15 Minuten zum Daily (siehe unten). Macht in Summe: 0,25h x 6 Personen x 5 Tage = 7,5h/Woche. Wenn in diesen Meetings nur einmal pro Woche eine falsche Annahme auffällt, die ein Teammitglied davor bewahrt, 2 Tage in die falsche Richtung zu entwickeln, hat sich der Aufwand bereits doppelt amortisiert. Und dies berücksichtigt den Produktivitäts- und Motivationsverlust noch nicht, der entsteht, wenn man 2 Tage Arbeit wegwerfen muss. Für uns eine klare Sache.
Verantwortung
Die Projektmanagement-Rolle beinhaltet bei Sandstorm eine Reihe von Verantwortungen:
Planung und Kommunikation
Teamzusammensetzung
Controlling
Die Zusammensetzung des Teams ist explizit aufgeführt, da Sandstormer gern möglichst viel in vielen Bereichen wissen, aber natürlich nicht alles Wissen können. Darüber nachzudenken, für welche Projektteile welche Fähigkeiten und Erfahrungen von anderen Teammitgliedern benötigt werden und diese bei der Kapazitätsplanung zu bedenken, ist folglich extrem wichtig, um einen entspannten Projektablauf zu ermöglichen.
SCRUM
Die Scrum Methodik, ich möchte fast Philosophie schreiben, ist eine zentrale Säule unseres Projektmanagements. In der Software-Branche müsste man sich schon ziemlich anstrengen, um nicht mit Scrum in Berührung zu kommen.
Obwohl Scrum für uns ein so elementarer Teil unseres Projektmanagements ist, wurde noch kein Sandstormer* in Scrum zertifiziert. Basierend auf dem Buch "Doing Twice the Work in Half the Time" von Jeff Sutherland, eigener Projekterfahrung und unserem gesunden Menschenverstand haben wir eine zweiteilige Schulung entwickelt, die jeder Sandstormer während des Onboardings erhält.
Der erste Teil behandelt die allgemein unter Scrum verstandenen Rollen, Artefakte und Prozesse. Also Product Owner, Backlog, Sprint, Daily, Inkrement, Definition of Done usw. Wenn der Sandstormer Zeit hatte, diese Begriffe in einem Projekt zu erfahren, folgt der zweite Teil. Die zugrunde liegenden soziologischen, psychologischen und biologischen Konzepte, deren Verständnis Scrum erst richtig effektiv machen.
Mit diesem Verständnis von Scrum, unserem Wissen über die Kundenkultur und den Kontext des konkreten Projekts gehen wir bereits in der Angebotsphase offen auf den Kunden zu, um die für ihn passende Scrum-Ausprägung auszuwählen. Also wie viel Prozess und wie viele Formalitäten notwendig sind, um effektiv zusammen arbeiten zu können.
* Christoph hatte in seiner Zeit vor Sandstorm die Scrum Master Zertifizierung absolviert.
Retro
Besonders hervorhebenswert ist die Retrospektive. Ein regelmäßiges Meeting, in dem gemeinsam mit dem Kunden die Zusammenarbeit reflektiert wird. Es erfordert Mut, den Kunden immer wieder um Kriti.. äh konstruktives Feedback zu bitten, sich gänzlich anzuhören und sich nicht persönlich angegriffen zu fühlen. Das dabei entstehende Vertrauen ist enorm, wenn der Kunde dieses regelmäßige Format nutzt, um Feedback zu geben und wir es umsetzen.
Noch schwieriger, als Feedback zu erhalten, ist es, dem Kunden Feedback zu geben. Persönlich. Im direkten Gespräch. Mit Zuhörern. Da ist kommunikatives Geschick gefragt, um den Kunden nicht vor den Kopf zu stoßen oder bloß zu stellen. Einmal etabliert, ist es aber die beste Möglichkeit, um Probleme und notwendige Veränderungen auf der Meta-Ebene direkt anzusprechen. Dabei geht es bspw. um die Kommunikation im Projekt und wie diese verbessert werden kann.
Planung, Teamgröße und Multitasking
Der größte Nutzen von Planung im Projektmanagement steckt im Nachdenken über das Problem. Je besser wir es verstanden haben, desto besser passt die Lösung für den Kunden. Das Denken in Sprints hilft uns dabei, soviel zu planen wie nötig, ohne das Große Ganze aus dem Auge zu verlieren. Der Sprint-Rhythmus hilft uns außerdem, regelmäßig aus den technischen Tiefen "aufzutauchen", um uns anschließend wieder voll auf die aktuelle Aufgabe zu konzentrieren.
Jeff Sutherland zitiert in seinem Buch verschiedene Studien, die den Zusammenhang zwischen Teamgröße und Geschwindigkeit untersucht haben. Das Ergebnis: Teams werden ab 9 Teammitgliedern deutlich langsamer. Mehr Personen machen Projekte also nicht schneller, im Gegenteil. Ursache ist der mit jeder Person hinzukommende Kommunikationsaufwand, der überproportional steigt. Also: lieber ein kleines cross-funktionales Team, als ein großes bestehend aus mehreren Silos.
Wir versuchen Multitasking zu vermeiden. Wenn möglich, soll ein Teammitglied zu einem Zeitpunkt nur an einem Projekt arbeiten. Diesem Idealzustand sind wir mal näher, mal ferner. Aber wir wissen, dass er erstrebenswert ist, weil die Kosten für häufiges Wechseln des Projektkontextes immens sind.
Sutherland führt folgende Daten an:
Anzahl paralleler Projekte
% der Zeit verfügbar je Projekt
Verlust wegen Kontextwechseln
1
100%
0%
2
40%
20%
3
20%
40%
4
10%
60%
5
5%
75%
Bei drei Projekten, die ein Teammitglied parallel bearbeitet, verpufft fast die Hälfte der Arbeitszeit in Kontextwechseln. Aus unserer Erfahrung kommt es aus vornehmlich aus zwei Gründen zu Multitasking: wir lassen uns leicht ablenken und wir können nicht nein sagen. Nein-sagen heißt, dem Kunden zu erklären, warum es sinnvoll ist, dass sein Projekt erst in 4 Wochen beginnt, weil bis dahin noch ein anderes Projekt abgeschlossen wird.
Controlling
Kein Projekt ohne Controlling. Die primäre Messgröße für uns ist jedoch nicht der Umsatz mit einem Kunden, sondern wie viel Mehrwert wir geschaffen haben. Wie zufrieden ist der Kunde, nimmt er das Projekt ab, wird er wieder ein Projekt mit uns machen, mit welchen Fragen kommt er zu uns, empfiehlt er uns weiter, hat es Spaß gemacht? All dies sind, unserer Meinung nach, deutlich bessere Indikatoren für unseren zukünftigen Erfolg, als die Höhe der letzten Rechnung.
Mehrwert-Controlling
Bei unserer bevorzugten Abrechnung nach Aufwand wird der Kunde, mindestens monatlich, mit unseren tatsächlichen Aufwänden konfrontiert und muss entscheiden, ob er diese als gerechtfertigt ansieht. Auch dies ist eine im Projektmanagement-Prozess verankerte Feedbackschleife. Es wird nicht konkreter, als für getane Arbeit bezahlt zu werden ;-)
Diese Review zeigt unseren Kunden auch, wie groß sein persönlicher Hebel bei den Projektkosten ist: Wie oft wurden Entscheidungen geändert, wie viel Zeit wurde in Meetings verbracht, wie viel Zeit wurde für das Hinterherlaufen nach fehlenden Informationen verwendet und wie viel um Infrastrukturprobleme zu lösen.
Finanz-Controlling
Nichtsdestotrotz müssen natürlich auch die Finanzen stimmen. Die Controlling-Rolle muss also in jedem Projekt besetzt sein. Bei kleinen Projekten macht dies das Teammitglied selbst, in größeren meistens der Projektmanager. Auch hierfür nutzen wir natürlich unser Controlling-Tool Exply. Kernthemen sind:
Welches Budget ist vereinbart und wie ist es aufgeteilt?
Wie sind die Abrechnungsmodalitäten: Fixpreis oder Time & Material, monatliche Abrechnung oder nach Meilensteinen, Stundensatz?
Welches Zahlungsziel ist vereinbart und wie muss die Rechnung zum Kunden?
Die Kür
Die Kombination aus Mehrwert- und Finanz-Controlling ist die Kür. Wie viel Budget, in Form von aufgewendeten Stunden, wurde schon verbraucht und wie viel geschaffener Mehrwert steht dem gegenüber? Dazu noch ein Gefühl, wie die aktuelle Geschwindigkeit ist und ob das Budget wie geplant ausreichen wird. Da kann fast nichts mehr schiefgehen ;-)
Work in Progress
Getreu unserem Motto "Challenge the Status Quo" entwickelt sich auch unsere Projektmanagement-Methodik stetig weiter und wird konstant hinterfragt. Basierend auf unseren Erfahrungen schulen wir uns gegenseitig und versuchen noch früher auf Indikatoren zu hören, die auf Probleme hindeuten. Es lohnt sich immer, Vermutungen anzusprechen. Im "schlimmsten" Fall zeigen wir unserem Kunden damit, dass uns sein Projekt wirklich am Herzen liegt. Im besten Fall haben wir tatsächlich ein tiefer liegendes Problem angesprochen, bevor es unkontrolliert ausgebrochen ist. Definitiv der bessere Weg!
