Projektmanagement

Martin
Ja, hallo und herzlich willkommen beim Sandpapier, die Folge Nummer 4. Der Sandpapier ist unsere wöchentliche Gesprächsrunde zu den Themen und Experimenten und Herausforderungen, die uns so als Softwareentwickler im Alltag begegnen. Das heutige Thema soll unser Verständnis von Projektmanagement sein. Und ich habe mir wie immer zwei Gäste eingeladen. Das sind der Tobias Gruber. Tobias, willkommen zurück. Vielen Dank für's Zuschauen und bis zum nächsten Mal.

Tobias
Hallo Martin, schön, dass ich wieder dabei sein darf.

Martin
Und heute mit Manuel, Manuel Lehner, unserem Büro, DJ und Softwareentwickler bei Sandstorm. Hey, Manu.

Manuel
Hi, grüß dich.

Martin
Hey, und ich bin euer Host Martin Penkert. Wir wollen heute über Projektmanagement sprechen und wir verstehen uns ja so als agiles Projektmanagement Team. Nun ist das Wort Projekt ein ziemlich großes Wort. Was versteht ihr denn so darunter? Was ist denn für euch so ein typisches Projekt?

Manuel
Also ich würde mal versuchen darauf eine Antwort zu geben, weil ich habe so das Gefühl, so ein richtig typisches Projekt, das gibt es eigentlich gar nicht. Die Projekte, die ich bei Sandstorm bisher miterlebt habe, die waren ziemlich unterschiedlich, also sowohl von der Dauer des Projektes als auch so vom Scope und Technologien und so weiter. Das erste Projekt, was ich miterlebt habe, war so ein eher, wo ich sage, das könnte so ein typischeres Durchschnittsprojekt sein. Das waren so mehrere Monate, so ein bis zwei Quartale höchstens. Dann hatte ich auch mal eins, das waren nur so ein, zwei Wochen, so ein ganz kurzes. Ich glaube, solche Projekte gibt es eher weniger oder wir bemühen uns auch eher größere Projekte zu machen. Und aktuell bin ich eigentlich jetzt schon seit mehreren Jahren in einem Projekt, das auch schon seit über zehn Jahren existiert oder wo wir als Sandstorm seit fünf Jahren, glaube ich, dabei sind und ich jetzt seit ungefähr drei Jahren.

Martin
Okay, das finde ich spannend in dem Projekt, wo du jetzt so lange bist. Wie groß ist denn euer Team dort? Das Entwickler und …

Manuel
sind ungefähr zehn Leute, also es gibt so ein paar Fluktuationen, aber zehn Entwickler sind so ungefähr so und von unserer Sandstorm-Seite sind wir zu zweit aktuell in dem Projekt. Der Rest vom Team sitzt woanders und die Zusammenarbeit aber remote funktioniert ziemlich gut.

Martin
Und aus deiner Erfahrung heraus ist das eher typisch, dass wir quasi ein Teil eines größeren Entwicklerteams sind, oder ist das eher ungewöhnlich?

Manuel
Das ist eigentlich gewöhnlich, also das gibt es schon öfters.

Martin
Okay, ich habe das auch ganz ähnlich erlebt. Also ich bin da jetzt auch seit einem Dreivierteljahr in einem Projekt dauerhaft und bin da auch eingebettet in ein größeres Team. Auch wenn ich manchmal ein bisschen das Gefühl habe, ich stemme das alleine. Tatsächlich ist es aber so, dass ich mich eigentlich auch ganz wohlfühle, dass wir quasi noch Entwickler aus anderen Teams aus anderen Unternehmen mit dabei haben und auch von Kunden direkt mit Entwicklern sprechen können. So als längster Sandstormer von uns, Tobias, wie hast du denn so Projekte bei Sandstorm bisher erlebt? Was ist denn für dich ein typisches Sandstorm-Projekt?

Tobias
Ja, ich stünde dem Manu eigentlich ziemlich zu, dass es das typische Sandstorm-Projekt gar nicht gibt. Ich würde, wenn ich über die letzten Jahre gucke, sagen, vor vier, fünf Jahren noch waren Sandstorm-Projekte kleiner, also eher im Bereich ein, zwei Mann-Monate, Personen-Monate. Viel mit Technologien rund um das NEOS Open Source Project, in dem wir seit vielen Jahren gut verwurzelt sind. Und das hat sich durchaus verbreitert. Also wir machen heute Projekte, die ein größeres Volumen haben, wo auch zwei Leute für eine Weile zusammen dran arbeiten können. Die Projekte laufen auch gerne mal ein Jahr und länger. Und der Technologie-Stack, mit dem wir arbeiten, der hat sich über die Zeit immer weiter verbreitert. So dass ich sagen würde, heute ein Projekt, was so sechs Monate läuft für zwei Leute, das ist das, was richtig Spaß macht.

Martin
Wie ist denn das, wir haben beim letzten Mal, als es um Remote-Kultur ging und um Verantwortung für Projekte tragen, ganz kurz das Thema angerissen, Projektmanager sein. Ich habe das Gefühl, wir haben gar keine Projektmanager, wir kennen das gar nicht. Wie seht ihr das? Habt ihr das anders erlebt? Ich habe manchmal, als ich frisch zu Sandstorm kam, hatte ich so ein bisschen das Gefühl, der Manu ist so ein fitter Projektmanager, der macht das. Manu, was bedeutet das für dich, Projektmanager zu sein?

Manuel
Ja, also das ist tatsächlich so, dass es den typischen Projektmanager als Rolle in unseren Teams eigentlich nie gibt, sondern Projektmanagement entsteht so im Optimalfall aus dem gesamten Team heraus. Also das ist eigentlich was, was nie so von von oben herabkommen sollte, also von dem ein Projektmanager, der quasi sein Team dirigiert, sondern das ist besser, wenn das ganze Team da mitwirkt.

Martin
Aber irgendjemand muss ja den Hut aufhaben, oder?

Manuel
Ja, also das stimmt. Man muss vor allen Dingen miteinander reden, wenn man jetzt sich über irgendwelche Verantwortlichkeiten abstimmt. Ich kenne das aus meiner Zeit von Force Sense Storm, dass es wirklich so war, dass es einen Projektmanager gab, der den Entwicklern gesagt hat, was sie machen müssen. Die brauchten sich dann um nichts anderes zu kümmern, als um die Aufgaben, die sie auf den Tisch gelegt bekommen haben. Bei Sense Storm habe ich jetzt mehr gelernt, in diese Manager of One-Rolle reinzuwachsen und quasi auch für bestimmte Sachen Selbstverantwortung zu übernehmen. Das fühlt sich auch viel besser an, weil man da sich selbst auch viel besser einbringen kann.

Tobias
Das hat auch einen ganz interessanten Effekt tatsächlich, dass der Manu zum Beispiel, du bist da so ein schönes Beispiel für, du machst dir echt Gedanken darüber, welche Teile vom Projektmanagement sind denn für mich sinnvoll und welche würde ich nur machen, weil sie halt dazugehören. Und dann merkt man ganz schnell, hey, ein Controlling vom Projektbudget und vom Fortschritt und eine mittelfürstige Planung mit dem Kunden, wie viel Kapazität braucht ihr denn, welche Features stehen an, das ist total wichtig für euch. Aber zum Beispiel einen wöchentlichen schriftlichen Statusreport zu erstellen, weiß ich nicht, ob du das schon mal gemacht hast. Ich kenne das aus meiner Zeit von FourSense Storm, dass das ganz wichtig war, dass der pünktlich abgeliefert wurde.

Martin
Du hast eben das Stichwort Manager of One in den Raum gestellt. Da würde ich gerne noch mal ein bisschen tiefer drauf eingehen. Das ist ja was, was man bei uns im Onboarding relativ früh mitkriegt. Ich kenne das ursprünglich von Peter Drucker, der darüber mal ein Buch geschrieben hat, Managing oneself. Das kann ich an der Stelle auch vor allem den Hörern sehr ans Herz legen. Ist ein ganz kleines Büchlein. Aber was da drin steht, ist für uns ziemlich essentiell. Tobias, willst du vielleicht noch ein bisschen auf das Manager of One eingehen?

Tobias
Der Begriff selbst, den haben wir entlehnt aus dem Buch von den Basecamp Leuten. Mir fehlt der Titel nicht ein, nicht Remote, sondern das andere. Rework, heißt das. Rework, genau. Da kam das drin vor und geht bei uns darum, wir wünschen uns Sensstormer als Personen, die in der Lage sind, ihre Arbeit selber zu priorisieren und zu strukturieren. Und sich auch neue Arbeiten suchen, also dieses Thema sich selbst managen. Was steht denn jetzt als nächstes an? Was muss ich weglassen, weil ich mich auf eine bestimmte Aufgabe fokussieren muss? Ich sollte für mich selbst eine gewisse Planung im Blick haben, beispielsweise wenn ich in zwei Wochen in Urlaub gehe, dass ich mit einem Kunden mal darüber spreche, dass das passiert, dass es im Team abgesprochen ist. Das gehört für uns alles zu diesem Bereich, Manager of One dazu.

Martin
Ich habe jetzt öfter mal Manager of One Plus gehört. Ergibt das nur in meinem Kopf Sinn oder hat das auch für euch eine Bedeutung? Oder habe ich das irgendwie weiterentwickelt? Sagen wir mal, in welchem Kontext? Na ja, Manager of One Plus ist quasi Manager of One, das bin ich. Und Plus ist quasi mein Einfluss aufs Projekt, dass ich also nicht nur mich selbst und meinen eigenen Schedule managere, sondern das auch im Vorhinein schon quasi meinen eigenen Plan auf die Bedürfnisse des Projekts anzupassen weiß, weil ich sozusagen in der Lage bin, ja, mein Circle of Influence mitzumanagen. Ergibt das Sinn, was weiß ich meinen?

Tobias
Ja, finde ich total gut und das drückt genau dieses Reingehen für mich in die Rolle des Projektmanagers aus, dass du sagst, okay, ich habe mich selbst im Blick als Person und jetzt übernehme ich diese Rolle, was Manu vor uns meinte, und ich übernehme da zusätzliche Aufgaben mit, weil ich es kann und weil ich weiß, dass es notwendig ist. Nämlich, wenn ich weiß, Manu, du bist gerade zu zweit in dem Projekt, da sollten wir unseren Urlaub wahrscheinlich abstimmen und wir sollten beim Kunden darüber reden, wie deren Release und Sprintplanung ist, damit wir darauf Rücksicht nehmen können und auch das Thema Controlling, wie viel Budget braucht denn das Gesamtprojekt, nicht nur ich alleine. In dem Kontext macht das schon Sinn, was du gesagt hast als Konzept. Ob ich mit dem Wording so glücklich bin, weiß ich noch nicht, das muss noch ein bisschen wirken in mir.

Martin
Okay, ich dachte, ich hätte es von dir.

Tobias
Wir hatten das in einem anderen Kontext, das vielleicht ein Thema für eine andere Podcast-Folge mal besprochen, als es darum ging, Führungskultur bei Sandstorm weiter auszubauen. Ich glaube, da haben wir schon mal besprochen. Das kann sein.

Martin
Das ist vielleicht tatsächlich noch mal ein interessanter Podcast. Für mich ganz wichtig, ich überlege mir gerade. Typischerweise ist es ja so, wir haben unsere Entwickler und lass die bloß nicht mit dem Kunden sprechen, weil die sollen ja entwickeln und die haben sowieso keine Sozialkompetenz. Jetzt, wenn wir keine Projektmanager haben, wer spricht denn dann eigentlich mit dem Kunden? Wie sind das bei euch, Manuel, im Projekt? Wer spricht denn bei euch mit dem Kunden?

Manuel
Na, also wir als Entwickler sprechen natürlich direkt mit dem Kunden, das wäre eigentlich nur eine zusätzliche Barriere, wenn da jetzt noch jemand dazwischen wäre. Also das gehört dazu, finde ich, also das ist eigentlich was ganz Normales, man kann so auch viel besser die Probleme vom Kunden verstehen, wenn die quasi von ihm ungefiltert direkt zum Entwickler kommen und andersrum. Also wir sprechen quasi innerhalb des Teams direkt mit dem Kunden in unserem Projekt.

Tobias
Das ist mir auch schon untergekommen, dass wir das anders handhaben als andere, wo es ganz explizit auch immer den Projektmanager als Person gibt. Und meine Erfahrung, wenn ich so über die letzten ein, zwei Jahre gucke, ist, das kann in bestimmten Projekten total gut funktionieren, wo die Kundenbeziehung gut passt. Das Projekt sozusagen, die Erwartungshaltung wurde abgeglichen auf beiden Seiten. Der Kunde hat das Gefühl, der bekommt einen guten Gegenwert für die Entwicklung, die wir leisten. Und das Geld, was er natürlich am Ende des Tages auch dafür bezahlt. Und dann ist dieser ganz kurze Kontakt von Entwickler zu Entwickler im Zweifelsfall wahnsinnig wertvoll, weil er ganz viel von dieser stillen Post rausnimmt, die sonst manchmal existieren kann. Wir haben aber auch die Erfahrung gemacht, dass es, gerade wenn es um kleinere Projekte geht, die man irgendwo mal so einschiebt, wo man jemandem helfen will, wo einer sagt, hey, wir brauchen da mal Support, ihr kennt euch doch gut mit Technologie-Exceptionen aus, dass es da durchaus hilfreich sein kann, das nicht bei einem bestimmten Entwickler zu parken, der sich eigentlich voll auf ein bestimmtes Projekt versucht zu konzentrieren. Und eine andere Situation, wo es auch total hilft, einen extra Projektmanager zu haben, ist, wenn es im Projekt krieselt. Das haben wir auch gemerkt, da kann das eine extreme Belastung für den Entwickler sein, das auch noch zusätzlich diese zweite Ebene mit dem Kunden aushalten muss.

Martin
Okay, was passiert denn, wenn so ein Projekt krieselt? Weil wir haben die zweite Ebene nicht.

Tobias
Was meine, was ich jetzt als Tobias sagen würde, ist, ich hoffe mir, dass der Sensstormer dann die Hand hebt und sagt, oh, hier ist gerade irgendwas los. Ich würde gern mal mit niemand anderem darüber sprechen und dann mal die Situation zu schildern, zu gucken, okay, was, was sagt denn ein Außenstehender dazu und möchte ich Hilfe von dem Außenstehenden haben, indem der sich einschaltet als, ja, beispielsweise Projektmanager und sagt, hier, ich nehme jetzt mal diese Kommunikation, diesen, diese emotionale Ebene auf, damit das nicht eine Person, also damit nicht eine Person beides machen muss, entwickeln und den Kunden managen.

Martin
beantwortet meine Frage. Was ist das? Das beantwortet meine Frage tatsächlich. Ich würde das noch mal kurz zusammenfassen. Anstelle des dedizierten Projektmanagers haben wir das Team insgesamt, wo wir dann sagen können, ok, du hast zwar keine Ahnung von dem Projekt, aber es geht hier auch nicht ums Projekt, sondern wenn es kriselt, geht es ja in den meisten Fällen um Kommunikation, um Blockaden, die aufzulösen sind. Und es ist manchmal einfach nur hilfreich, wenn quasi jemand anders, der in der Lage ist, sozialkompetent zu kommunizieren, an der Stelle übernimmt und sagt, ich entlaste jetzt hier die belastete Beziehung dadurch, dass ich als neutrale Dritter dazwischendrete. Ist das ungefähr das, was du gemeint hast? Ja, das tut es gut. Okay, was wir ziemlich dogmatisch machen, ist Scrum. Tobias, ich gebe gleich noch mal an dich zurück. Du bist du bist unser Dogmatiker, dafür bekannt, dass du Scrum besonders hart vertrittst. Was bedeutet denn Scrum für dich?

Tobias
Hör ich da eine gewisse Ironie raus, Martin? Scrum kommt natürlich auch in unserem Onboarding vor, weil wir, also jeder, der irgendwo Software bei uns entwickelt, hat das schon mal gehört. Und auch bei den großen Kunden ist mittlerweile, also überall hört man Scrum und agile Entwicklungsmethodik. Selbst bei den öffentlichen Ausschreibungen, die wir uns angucken, wird mittlerweile von agilen Methoden gesprochen, also da irgendwas muss da dran sein. Ich habe mich versucht, mit den Hintergründen zu beschäftigen, also was steckt denn hinter Agile, was ist damit gemeint? Und da ganz spannend ist das agile Manifest, auf dessen Gedanken ja auch Scrum irgendwo aufbaut. Ja, Scrum ist eine agile Implementierung, ist ein Framework, an das man sich halten kann, was meiner Erfahrung nach einem unstrukturierten Team ermöglicht, eine vernünftige Performance hinzubekommen. Deswegen ist der Untertitel vom Buch Scrum Doing Twice the Work in Half the Time ja auch quasi viermal so schnell werden in den Projektumsetzungen. In unserer täglichen Arbeit versuchen wir, aus Scrum Elemente rauszunehmen, die für uns passen und hilfreich sind und das zu kombinieren mit anderen Einflüssen, also einmal dem agilen Grundgedanken natürlich. Und jetzt kürzlich erst zum Beispiel von Shape Up inspiriert, was wieder von den Basecamp Leuten veröffentlicht wurde und da was rauszubauen, was für die konkrete Kundensituation passt. Und das kann mal mehr Framework sein, mal weniger. Je nachdem, wie groß auch das Team ist, braucht man ein bisschen mehr Prozess und ein bisschen mehr Struktur oder ist da freier?

Martin
Du hast gerade Shape Up erwähnt. Was haben wir denn da rausgenommen und implementiert?

Tobias
Also bis jetzt würde ich sagen, ein ganz wichtiger Punkt, den wir adaptiert haben, ist das Thema Shaping, also das Planen von konkreten Aufgaben einmal aus dem Blickwinkel, was ist es mit dem Wert zu investieren, um eine bestimmte Funktionalität beispielsweise umzusetzen und auch das drüber nachdenken, was ist denn das eigentliche Problem, was wir haben, was wir versuchen zu lösen, wie groß sollte die Lösung sein, dafür brauche ich natürlich dieses Budget, was es mir wert ist, zu investieren und dann tatsächlich diese richtige Mischung aus abstrakt, sodass die Leute, die es dann umsetzen, noch genügend Entscheidungsfreiräume haben und konkret, dass sie aber möglichst nicht mehr falsch abbiegen können, weil darüber haben wir schon gesprochen und dieses Shaping, das machen wir mittlerweile immer öfter und das funktioniert ziemlich gut tatsächlich und was zweites, was wir jetzt rausnehmen, ist diese Idee vom Cooldown, dass wir das ganz explizit in unserer Projektplanung berücksichtigen, dass Leute auch mal nach dem Projekt eine Abklingenphase haben.

Martin
Warum, glaubst du, ist das wichtig?

Tobias
Das kommt so ein bisschen aus der Richtung Scrum tatsächlich, wo von von den Begrifflichkeiten im Scrum, man denkt in Sprints. Was ein Sprint ist, das kennt jeder aus dem Sport, das ist möglichst schneller Lauf über eine kurze Strecke und dann lässt man es eigentlich auslaufen. Dann muss man wieder runterfahren, aber in der Softwareentwicklung haben wir uns irgendwie darauf eingestellt, dass wir sagen Sprint, Sprint, Sprint, Sprint, Sprint, Sprint, Sprint, Sprint und das kann natürlich nicht funktionieren, wenn ich das mal öfter in den Sportkontext übertrage. Ich kann keinen Marathon laufen, in dem ich Sprinte. Da muss ich mir meine Kraft schon ein bisschen einteilen und gerade wenn wir was ich eingangs erwähnte Projekte haben, die auch mal Monate laufen, dann brauchen wir auch Phasen, wo mal kein Projekt gerade zu bearbeiten ist, wo dieser psychologische Druck, ja ich arbeite gerade an dem Projekt, weil ich muss das voranbringen, wo der einfach mal für eine gewisse Phase auch weg ist. Und die Leute, die sich mit Themen beschäftigen können, auch diese Lust haben und auch das im Arbeitskontext tun können und sagen, hey das lange Projekt ist jetzt abgeschlossen, ich möchte es noch mal Revue passieren lassen in meinem Kopf, ich will mir noch mal ein paar Sachen aufschreiben, ich will vielleicht von einem Open Source Projekt hier mal die Doku ergänzen, weil ich da drüber geschleudert bin, als ich das gemacht habe. Ich habe sowieso Lust, mich mal einem Open Source Projekt zu engagieren und das ist alles, was Zeit finden soll und das Experiment werden wir jetzt starten, das in diesem Cool Down mal zu machen. Ich würde Richtung Manu mal fragen, du hast, du erlebst ja auch in dem großen Projekt, in dem du schon eine ganze Weile bist, Scrum als Methodik, wie sind da deine Erfahrungen mit?

Manuel
Genau, also in dem Projekt nutzen wir Scrum ziemlich streng und ich denke, das ist vor allen Dingen für größere Teams ein sehr hilfreiches Tool, um halt so Struktur ins Chaos zu bringen. Auf der anderen Seite denke ich mir auch manchmal, dass sehr viel Projektmanagement-Overhead entsteht, weil Meetings vorgesehen sind und dann deshalb auch gemacht werden und es gibt halt viele Meetings, also das Framework ist sehr streng, aber es wird auch eingehalten und das ist gut. Ich finde die Arbeit in Sprints ziemlich hilfreich, dass man so kleine abgeschlossene Zeitanheit bearbeitet, wo man auch kleinere Ziele verfolgen kann und die vor allen Dingen dann am Ende von so einem Sprint auch mal auswerten kann und gucken, wie erfolgreich war das und sich daraus auch wieder verbessern oder optimieren kann. Und in unserem Projekt haben wir daraufhin auch manche Methoden von Scrum so ein bisschen angepasst oder optimiert, weil das ist ja immer projektabhängig, was sehr gut funktioniert und wo man vielleicht sich da optimieren kann, um gewissen Overhead vielleicht sogar einzusparen. Zum Beispiel gibt es auch so Retrospektiven immer am Ende von Sprints, die ich ziemlich cool finde, weil wir hatten ja vorhin das Thema, was ist, wenn es mal krieselt, das ist zum Beispiel so ein Format, das ist dafür vorgesehen, dass man mal so Sachen aussprechen kann im Team, wenn man mit irgendwas unzufrieden war, das ist schön, dass es dafür auch halt so Plätze gibt. Ich hoffe, das hat euch gefallen und wir sehen uns beim nächsten Mal wieder. Tschüss.

Martin
Passiert das auch? Also wird tatsächlich auch, ich sag mal hier, soziale Unzufriedenheit angesprochen und abgebaut? In deiner Erfahrung.

Manuel
Ja, also doch auf jeden Fall. Es hat so immer was dann mit dem Projekt zu tun und was man da in seiner Arbeit verbessern kann, aber da haben wir schon echt viel Frust nicht nur abbauen können, sondern konkret auch Sachen halt besser gemacht.

Tobias
in dem Projekt, wo du jetzt seit drei Jahren, glaube ich, da unterwegs bist, hilft das auch total, dass es diesen konkreten Punkt gibt, wo wir auch tatsächlich Unternehmensübergreifende, der Kunde und wir zusammen als Entwicklungsteam darüber sprechen. Und das passiert halt alle zwei Wochen. Da hilft Scrum tatsächlich, dass es diesen Punkt gibt, wo Unzufriedenheit angesprochen werden kann. Wenn wir in Projekten sind, wo wir beispielsweise nicht mit einem Entwicklerteam auf Kundenseite zusammenarbeiten, dann ist in Reprospektiven zum Beispiel was, was wir häufiger nicht machen. Und wenn wir dann mal mit dem Kunden auf dieser Metaebene sprechen, so hey, wie zufrieden bist du denn? Gibt es Dinge, die dich an der Zusammenarbeit mit uns stören oder nerven? Dann kommt meistens ein super wertvolles Feedback und wir fragen uns jedes Mal wieder, warum machen wir das eigentlich nicht häufiger?

Martin
Da kann ich auch ein bisschen aus meinem Projektalltag berichten. Also ich habe das auch nach ungefähr einem Vierteljahr immer wieder mal kleinere Missverständnisse. Und dann haben wir auch genauso alle zwei Wochen Retrospektive. Also wir machen quasi zwei wöchentliche Sprints. Und am Ende dieser zwei Wochen machen wir aber nicht. Wir machen quasi nichts anderes außer der Retrospektive. Also das Team entscheidet weiterhin quasi am laufenden Bahn selbst, welche Tickets jetzt reinkommen und welche Projekte jetzt umgesetzt werden und so weiter. Und wir treffen uns tatsächlich ausschließlich für die Retrospektive. Und das hat das gesamte Projektgefüge irgendwie neu sortiert und gut ausgerichtet. Neu ausgerichtet, auf eine sehr gute Art und Weise.

Tobias
Das ist tatsächlich, also mit dem Kunden mal reden und fragen, wie zufrieden ist er denn auf dieser Metaebene. Am anderen Ende des Projektes sitzen auch Menschen. Und die haben auch Befindlichkeiten und denen sind bestimmte Dinge wichtig und die sind bestimmten Zwingen unterworfen in ihren Organisationen. Und mein Gefühl ist, je länger wir mit Kunden zusammenarbeiten und die über mehrere Projekte auch begleiten und die kennenlernen, desto mehr spielt sich das natürlich auch ein die Zusammenarbeit und macht auch immer mehr Spaß über die Zeit.

Martin
ich habe noch ein thema was ich gerne mit euch besprechen möchte und zwar habe ich hier auf meinem laptop so einen sticker drauf kleben da steht drauf fight old school business realist und real ist so ganz komisch geschrieben r.a. e.l habt ihr eine idee worauf ich hinaus will

Tobias
Ich habe das schonmal gehört.

Martin
Also, das ist ja ein Ansatz, den wir auch fahren und den ich erst bei Senstorm kennengelernt habe. Der aber gar nicht von Senstorm kommt, sondern von einer befreundeten Agentur von Zeitgeist. Und das ist dieses Real. Wir machen Projekte Real. Was heißt das denn? Das klingt erst mal ziemlich nach einem Basswirt.

Tobias
Ich glaube, deswegen wurde auch dieses Akronym gebildet, damit man einen schönen Begriff hat, mit dem man was assoziieren kann. Und als ich das das erste Mal vom Sven Dietz gehört habe, da bin ich auch fast vom Stuhl gekippt, da habe ich so gedacht, boah, das was der da sagt, das will ich eigentlich auch so machen. Also keinen Vertrag mit dem Kunden haben, wirklich Handschlags-Business machen können. Mit dem Kunden-Stunden-Satz vereinbaren, dann werden Stunden geleistet, dann wird dem Kunden gezeigt, hier das sind die Stunden, die wir aufgewendet haben, das ist die Rechnung dazu, ist das in Ordnung für dich? Und dann keine Diskussion, wenn der Kunde meint, das ist es nicht wert, dann soll er die Rechnung kürzen und dann muss man nicht anfangen, über fünf Minuten auf der Rechnung zu pfeilschen. Und da gehört noch eine ganze Menge mehr dazu und da gibt es auch schon einiges an Podcasts und ich denke mal, wir können da eine ganze Folge drüber machen über das Thema real und das würde sich auch lohnen, weil es echt spannende Ansätze sind und wir haben wie bei so vielen Sachen auch, was ich ja schon erwähnt habe, Scrum, Agile, ShapeUp, das gehört und versucht für uns zu adaptieren und da sind ganz verschiedene Sachen rausgekommen. Das fängt an in der Projekt-Aquise bei uns, dass wir manchmal sagen, hey, wir bauen jetzt einfach mal einen Prototypen und zeigen dem Kunden und sagen, mir das hat, weiß ich nicht, vier Tage Aufwand waren das jetzt, sollen wir einfach weitermachen. Und dann kann der Kunde sagen, hey, ja, ihr habt das tatsächlich verstanden und ihr habt Lust darauf und das geht voran und okay, cool, das mache ich mit euch, auch mal so einfach in Vorleistung zu gehen oder diese Art der Abrechnung, dass wir sagen, Kunde, lass uns über ein Budget sprechen, was dir ein bestimmtes Thema wert ist und wir zeigen dir ganz transparent, welche Aufwände wir hatten, wofür wir Zeit aufgewendet haben und du bezahlst das, womit du einverstanden bist und man denkt erstmal, oh Gott, oh Gott, oh Gott, kürzen dann die Kunden nicht ständig die Rechnung, aber nee, das ist nicht der Fall. Sogar nicht? Ich glaube, es ist in der Vergangenheit einmal vorgekommen bei uns bisher und wir machen das seit fast zwei Jahren, würde ich sagen.

Martin
Okay, ich denke, das klingt tatsächlich nach einem Thema für eine ganz eigene Folge. Habt ihr beiden denn noch ein Thema zum Thema Projektmanagement, dass ihr unbedingt loswerden wollt, was wir jetzt noch nicht besprochen haben?

Tobias
Ich gebe zu, ich habe mir zum Spicken mal unseren Blogpost dazu aufgemacht und das Inhaltsverzeichnis ist ziemlich lang. Wir haben schon über einiges gesprochen, richtig. Ich glaube, wir machen nochmal eine neue Folge oder eine weitere Folge, weil das Thema Risiko, Priorisierung, kritischer Pfad, Schätzen, ja, das sind alles spannende Themen. Und ich glaube, jede Agentur findet da irgendwie eigene Lösungen für und lasst uns darüber sprechen. Also ich werde gerne einen neuen Folge machen.

Martin
Ok, sehr gerne. Manuel, letzte Worte.

Manuel
Also ich denke, Projektmanagement, Methoden, man kann nie pauschal beantworten, für welches Projekt man welche Methoden einsetzen kann. Das ist immer abhängig vom Team, vom Kunden, vom Projekt, der Dauer, vom Scope und man kann sich ja vielleicht auch so von verschiedenen Methoden, wie wir es jetzt schon besprochen hatten, so das Beste rausziehen für sich und vielleicht so einen optimalen Mix finden, ist wirklich immer sehr individuell.

Martin
Vielen Dank. Vielen Dank euch beiden, dass ihr heute dabei wart.

Manuel
Ja, sehr gerne. Vielen Dank.

Martin
Und ich freu mich auf die nächste Woche. Bis dahin.