VDI Inhouse Seminar Agiles Projektmanagement in der TGA

Worum ging es im VDI-Inhouse-Seminar zum agilen Projektmanagement?

Roman: Moin moin aus Hamburg und herzlich willkommen zum einzigen Podcast mit dem Thema Projektmanagement in der TGA. Sören, du und ich sitzen an der Bar zur Reflektion von Seminaren — das ist immer das Ziel.

Sören: Genau. Und du kommst heute vom ersten Inhouse-Seminar, das du vorletzte Woche gegeben hast, zum Thema agiles Projektmanagement. Ein Büro hat dich kontaktiert und gefragt, ob du das Thema agiles Projektmanagement im Speziellen beleuchtest. Erzähl mal, wie du die zwei Tage gestaltet hast.

Roman: Ein Teilnehmer hat sich bei mir gemeldet und wollte ein Inhouse-Seminar machen. Der VDI, der Verein Deutscher Ingenieure, für den wir die Seminare machen, bietet diese Inhouse-Seminare an. Im Auftrag des VDI Wissensforums bin ich nach Süddeutschland gefahren. Das Büro möchte ich anonym lassen.

Sören: Bei der Agilität in der Baubranche kennt man hauptsächlich Kanban und Scrum. Kanban findet Anwendung, ist über die Software auf den Rechnern schon fest im Prozess integriert. Aber mit allem, was darüber hinausgeht, tut sich das Bauen noch schwer.

Was kam bei der Arbeit an Rollen und Domänen heraus?

Roman: Das tut sich schwer. Das Thema Kanban kam auf, dazu haben wir mehrere Übungen gemacht und mehrere Softwares verglichen. Vor allem das Thema Scrum haben wir nicht nur angeschaut, wir haben es gemacht — wir haben zwei Sprints durchgeführt. Es war hochspannend.

Angefangen haben wir mit dem Thema Rollen und Domänen — das ist auch im VDI-Grundlagenseminar drin, gar nicht auf Scrum bezogen. Ich habe alle 15 Teilnehmer nach ihren Rollen gefragt. Wir arbeiten interaktiv mit einem Mural-Board; alle haben Bilder von sich eingefügt, ihre Rollen beschrieben und benannt, wo die Grenzen ihrer Rollen liegen und wo es Probleme mit der Rollendefinition gibt.

Wir haben länger über Bauüberwachung und Bauleitung diskutiert — wo ist der Unterschied? Da gab es schon Klarheit, die Begriffe wurden etwas anders benutzt. Es ging Richtung Projektleitung: Was heißt eigentlich Projektleitung? Das ist nicht einheitlich definiert, dieses Thema haben alle. Was hat das mit agilem Projektmanagement zu tun? Vor allem die Frage des Multiprojektmanagements: Gerade als Fachplaner mit Expertenrollen ist man immer in einem halben Dutzend Projekten gleichzeitig.

Sören: Auch in unterschiedlichen Rollen.

Roman: In unterschiedlichen Rollen und Projekten. Den Überblick zu bewahren, ist eigentlich unmöglich. Jeder hat das im Kopf und switcht automatisch zwischen den Rollen — manchmal aber auch nicht. Ich komme von der Baustelle aus Projekt A, fahre ins Büro und muss eine Frage zum Systemplan von Projekt B beantworten, und dann sitze ich bei Projekt C zur Vorplanung. Irgendwann platzt der Kopf. Wir haben diese Rollen aufgeschrieben und diskutiert, wo sie gut definiert sind und wo nicht. Am Ende des ersten Tages haben wir die Rollen zusammengeführt und sauber definiert, welche Herrschaftsgebiete die einzelnen Rollen haben. Dabei sind komplett neue Gruppen im Unternehmen entstanden, die sich jetzt regelmäßig treffen.

Sören: Ihr seid also durchgegangen, wie jeder das Verständnis von seinem eigenen Job hat — fast wie Stellenbeschreibungen.

Roman: Ja, so Stellenbeschreibungen. Da könnte es hingehen, aber es ging mehr um die Frage, welche Rollen es bei agilen Projekten gibt.

Wie erklärt das Skateboard-Beispiel inkrementelle Wertschöpfung?

Roman: Zum agilen Projektmanagement haben wir uns erst mit dem Unterschied zwischen Wasserfall und Agil beschäftigt. Klassisch ist die HOAI ein Wasserfall: Ich schließe Leistungsphasen nacheinander ab.

Sören: Eins nach dem anderen, strukturiert.

Roman: Und dann der Unterschied: Agil bedeutet, ich widme mich rollierend in Zyklen den Themen und vertiefe sie immer weiter — ein Beispiel ist Leistungsphase 2. Dann haben wir die inkrementelle Wertschöpfung erläutert, dabei kam immer wieder das Beispiel des Skateboards. Nicht inkrementell wäre wie beim Auto: Ich habe einen Reifen, dann zwei, dann ein Fahrwerk — aber nichts davon kann ich zwischendrin benutzen, erst das fertige Auto. Inkrementell könnte ich aus zwei Reifen erst ein Skateboard bauen, dann einen Roller, dann ein Fahrrad, dann ein Motorrad und am Ende ein Auto — und alles dazwischen ist nutzbar. Es gibt sogar ein Spielzeug, Invento, aus dem man mit einem Set 26 Modelle bauen kann; die Kinder freuen sich auch über das Skateboard, nicht nur über das Auto.

Das war eine gute Einleitung: Gerade in Leistungsphase 2 sollte man agil arbeiten und erst ein kleines Skateboard bauen, das man schon sehen kann. Noch agiler wäre, schon die Aufgabenstellung in Leistungsphase 1 agil zu machen und immer wieder zu fragen: Wir haben so verstanden, dass wir das tun sollen — gib uns Feedback, sollen wir wirklich dieses System planen oder ein anderes? Genauso eine vorgezogene Schlitz- und Durchbruchsplanung könnte man agil machen: schon in Leistungsphase 3 als Sonderleistung anbieten, weil die Tragwerksplaner früh ein sauberes Modell brauchen.

Sören: Also abweichend vom HOAI-Geschehen statisch relevante Durchbrüche früher angeben — man zieht das ganze Thema vor.

Roman: Man zieht es vor, einfach als Sonderleistung. Ich habe von anderen Büros gehört, die das machen: Sie liefern in Leistungsphase 3 schon ein vollständiges Modell, wenn der Kunde es will. Das kostet Geld und ist Aufwand. Und natürlich kam wieder das Beispiel der Technikzentrale — die agile Technikzentrale.

Sören: Für alle, die es noch nicht gehört haben: Mit Blick auf Scrum im Bauen schaut man sich lokal in kurzen Iterationsschleifen eine Thematik an.

Roman: Genau, so ist es. Ich versuche vor allem, unfertige, aber halbwegs vollständige Modelle zu zeigen — alle Gewerke sind drin, aber es sind Zwischenstände. Ich arbeite mich an Zwischenständen ab.

Wie liefen die zwei Scrum-Sprints am echten Projekt ab?

Roman: Dann haben wir agile Prinzipien beleuchtet und sind zu einem von mir für die TGA-Fachplanung entwickelten Scrum-Prozess gekommen, den ich hier erstmals richtig durchentwickelt habe. Der fließt aus meiner Sicht künftig ins Grundlagenseminar ein. Wir haben zwei neue Rollen: den Projektleiter als Kundenvertreter — bei Scrum ist das der Product Owner. Bitte dazu die Scrum-Folge hören, ich kann das nicht alles wiederholen. Der Projektleiter spielt die Rolle des Kunden und macht klar: Ich will das und das sehen. Dann lässt er das Team unter Führung eines Fachplanungskoordinators diese Anforderungen in Sprints abarbeiten.

Am zweiten Tag wurde das genau durchgearbeitet. Wir haben die zwei Sprints an einem echten Projekt gemacht — das Büro hatte ein sehr renommiertes Projekt akquiriert — und das in zwei Gruppen, also insgesamt vier Sprints. Die eine Gruppe sollte für die Leistungsphasen 1 und 2 eine Sprintplanung machen: Lieber Bauherr, das bekommst du zu sehen, das sind die einzelnen Präsentationen. Die andere Gruppe machte es für die Leistungsphasen 3 und 4. In Leistungsphase 1 und 2 ging es vor allem um Informationen von externen Beteiligten — Objektplanern, Bauherr. In Leistungsphase 3 und 4 ging es um Dinge, die man wiederholen muss; es wurde mit Pufferzeiten gerechnet, weil man zum Beispiel noch kein vollständiges Brandschutzkonzept hat.

Das war eine große Erkenntnis: Wir machen schon jetzt eine echte Planung der Planung als TGA-Planer für ein renommiertes Projekt. Wir haben den Sprint ein zweites Mal durchgeführt, nachdem es Feedback vom Product Owner gab. Der Product Owner — ich selbst — sagte: Ich bin jetzt der Bauherr, und zwar nicht nur Vertreter, sondern auch TGA-Sachverständiger, ich kenne mich aus. Im zweiten Sprint haben wir eine wahnsinnige Qualität erreicht: In Leistungsphase 3 und 4 die Pufferzeiten, in Leistungsphase 2 eine komplette Schnittstellenliste — wir brauchen vom Küchenplaner sämtliche Informationen, vom Energieberater für die Elektroplanung das GEG, für die HLS-Planung die Anforderungen an die Sanierung, U-Werte und so weiter. Das Büro wird jetzt mit dem Architekten sprechen und dann auf den Bauherrn zugehen: Das ist unsere Planung der Planung. So proaktiv ist kaum einer von uns bisher an ein Projekt herangegangen.

Sören: Ihr habt euch also an einem konkreten Beispiel die Arbeitspakete und Themenblöcke vorgenommen und in einer kurzen Intensivübung bearbeitet?

Roman: Genau, es gab zwei Sprints: Der eine hat 30 Minuten gedauert, der zweite 40. In diesen 30 plus 40 Minuten wurde in zwei getrennten Teams eine komplette Planung der Planung für die Leistungsphasen 1 bis 4 erarbeitet — mit klarer Reihenfolge: erst die Heizlasten, dann die Fernwärmeversorgung, dann Kälteversorgung, dann Luftversorgung und so weiter, jeweils mit der Information, was von außen gebraucht wird. Mit diesem Ergebnis aus anderthalb Stunden Arbeit treten sie in zwei Wochen beim Bauherrn auf und sagen: Das brauche ich, das bekommst du, und das ist mein Terminplan. Den Termin 30.07. kann ich wahrscheinlich halten, brauche aber folgende Infos vom Architekten zu diesem Zeitpunkt.

Was ist der Kern des agilen Projektmanagements in der TGA?

Sören: Diese zeitliche Begrenzung ist das Goodie — dass die Planung der Planung vollständig hinkam.

Roman: Das war eine Vorgabe vom Projektleiter als Kundenvertreter: Zum 30.07. will ich eure Vorplanung sehen. Das Team hat ohne den Kundenvertreter die Schritte so erarbeitet, dass zum Termin alle Informationen vorliegen. Das ist der Kern des agilen Projektmanagements: Der Projektleiter ist nicht der Mikromanager, sondern der Anforderungssteller. Er sagt: Ich bin Kunde, ich will das und das. Und er hatte einen höheren Standard und Anspruch als der Kunde am Ende.

Sören: Weil er weiß, was die Leute können.

Roman: Er weiß, was die Leute können, und er ist TGA-Profi. Eine gute TGA-Planung besteht für ihn aus dem und dem. Die meisten Bauherren sind keine TGA-Profis, das ist auch nicht ihre Rolle. Wir haben gesagt: Setz dich als Projektleiter auf die Seite des Bauherrn und lass dein Team auf der anderen Seite antreten. Dann machst du einen Schulterschluss mit dem Bauherrn, schaust dir die Zwischenergebnisse an und gibst auch Kritik. So wirst du als Projektleiter zum Kundenversteher. Das ist die Essenz: sichtbare Zwischenergebnisse und auf Kundenseite sitzen. Das war ein komplettes Umdenken, am Schluss gab es große Begeisterung. Die Planung der Planung war für vier Leistungsphasen abgeschlossen und kann präsentiert werden.

Sören: Auch mit zeitlicher Komponente dahinter.

Roman: Mit zeitlicher Komponente und konkreten Themen, alles erarbeitet. Kritik kam von mehreren Seiten, die ich voll verstehe: Das ist ein großes, renommiertes Projekt, an dem fast alle arbeiten. Bei einem kleinen Teilprojekt, einer Heizungssanierung, macht diese Zerstückelung keinen Sinn — der Aufwand ist für ein kleines Projekt mit wenig Gewerken zu groß.

Sören: Du kannst ja nicht Scrum aus Projekt 1 mit Scrum aus Projekt 2 mischen.

Roman: Das wird zu viel. Genau diese These hatten wir aber schon. Ich habe mir heute noch einmal unsere Podcast-Folge zum Thema agiles Projektmanagement angehört — ich glaube, das war Folge 8 — und dachte: Stimmt. Die These war: große Projekte, viele Planer, viel zu integrieren, sichtbare Zwischenlösungen — das ist die richtige Anwendung für agiles Projektmanagement. Genau das kam jetzt beim Inhouse-Seminar auch heraus, und das Büro hat trotzdem mitgenommen, dass es sein großes Projekt komplett durchgeplant hat.

Welche Kanban-Software eignet sich, und wo ist die Grenze bei MS Teams?

Roman: Dabei habe ich noch viel zu Scrum und Kanban gelernt. Ich habe Microsoft Teams und den MS Planner vorgestellt — das hatten wir auch in Folge 8 erläutert; der Planner ist Kanban. Das gibt es auch von anderen Herstellern: Es gibt Asana, das habe ich auch verglichen. Sie haben alle ähnliche Preisvorstellungen, das ist gut vergleichbar.

Sören: Auch was das Leistungsbild angeht.

Roman: Kanbanize kann zum Beispiel mehr: Da kannst du Projekte zusammenführen, Asana kann das inzwischen auch. Der Planner ist zwar in das 365-Paket integriert, hat aber harte Grenzen. Bei Microsoft Teams selbst gab es eine Grenze etwa bei 40 Jahren: Die unter 40 sagten, super, ich will MS Teams, Chat-Nachrichten, Videotelefonate mit einem Klick, alles in Teams-Kanälen. Die über 40 sagten eher: Dann muss ich den ganzen Tag auch noch Chat-Nachrichten lesen und schreiben, auf der Baustelle und am Telefon.

Sören: Das Kanalisieren von Informationen wird damit ganz wichtig.

Roman: Das stelle ich auch bei uns im Büro fest. Es ist diskussionswürdig, aber ein bisschen wie die Frage, ob ich weiter Kutsche fahre oder jetzt Auto — es ist der nächste Schritt.

Sören: Da brauchst du eine Art Regeln oder Leitplanken, wie in einer digitalen Welt kommuniziert wird.

Roman: Ja, genau. Interessantes Ergebnis des Inhouse-Seminars: Wir haben an einem konkreten Projekt agiles Projektmanagement geübt, und es hat sich gezeigt, dass Scrum geht — dass Scrum für komplexe, integrationswürdige Projekte richtig gut funktioniert. Wir hatten Aha-Erlebnisse, weil wir Dinge wirklich konkret erarbeitet haben. Die steigen jetzt in zwei Wochen ein und präsentieren das alles.

Sören: Wir werden schon wieder angeschaut, der Blick geht zum zweiten Mal auf die Uhr. Wir verzichten auf die Runde und schleichen uns raus. Wie immer mit Paypal. Vielen Dank, bis bald.