Zum Hauptinhalt springen
31.01.2022 | Nils Mohr, Marcel Weissinger, Hans Christian Jünger

Scrum Real Estate – Agile Arbeitsweise 
im Bauwesen

Forschung und Entwicklung

Scrum baut auf die kollektive Intelligenz der am Projekt beteiligten Personen. Mit Scrum bieten sich Potenziale zur Verbesserung von dynamischen Projektabläufen im Projektmanagement von Bau- und Immobilienprojekten an. Doch wie ist die agile Arbeitsweise zu organisieren, und worauf ist zu achten. 
Eine wissenschaftliche Betrachtung des Instituts für Baubetriebslehre derUniversität Stuttgart mit konkretem Beispiel.

Bau- und Immobilienprojekte werden mit steigender Anzahl der Projektbeteiligten und umfangreicheren Regularien komplexer. Agile Managementansätze, wie das Rahmenwerk Scrum, können entscheidende Vorteile bieten, um frühzeitig auf unvorhergesehene Einflüsse zu reagieren. Scrum trägt dazu bei, die Gruppendynamik zu aktivieren und Vertrauen im Team zu schaffen. Entscheidend für den Projekterfolg ist nicht ausschließlich die Methodik, sondern die Denkweise der Projektbeteiligten, die mit Scrum freigesetzt wird. Das Rahmenwerk selbst ist sinnbildlich als Trainingsablauf zu verstehen, der einen kooperativen und lösungsorientierten Teamgedanken bei den Beteiligten verankert. Im Rahmen der Forschungsarbeit geführte Experteninterviews zeigen auf, dass in der Bau- und Immobilienbranche ein Kulturwandel zwingend notwendig ist.

Abbildung 1: Ablauf Sprint20, Bild: Institut für Baubetriebslehre, Uni Stuttgart

Die Entwicklung von starren Strukturen hin zu agilen Vorgehensweisen wird auch in der Baubranche unumgänglich sein. Scrum bietet die Chance, Bau- und Immobilienprojekte mit steigenden, dynamischen und komplexen Anforderungen, gemessen an den vereinbarten Qualitäten, Terminen, und Kosten, erfolgreich abzuwickeln. Synergien zu kooperativen Vertragsmodellen im Bauen wie beispielsweise Integrative Projektabwicklung (IPA) bestehen und sind zu untersuchen. Durch die strukturierte Vorgehensweise entwickeln die Projektbeteiligten ein Verständnis für Prozesse. Detaillierte Prozessplanungen unterstützen die Zielerreichung eines Projekts. Im Ergebnis wirkt sich dies positiv auf die Wirtschaftlichkeit von Projekten und insbesondere auf die Art und Weise der Zusammenarbeit von Planern, Ausführenden und Bauherren aus. Dies kann zur Steigerung der Produktivität auf Baustellen beitragen.

Einleitung

Rund ein Drittel der in 2020 dazu untersuchten Projekte waren mit wesentlichen Änderungen und kontinuierlichem Wachstum des Projektumfangs während der Projektlaufzeit konfrontiert.1 Gleichzeitig führen komplexe Aufgabenstellungen und stetige Veränderungen der Anforderungen im Planungs- und Bauprozess oftmals zum Scheitern des magischen Dreiecks im Bauwesen (Qualitäten, Termine und Kosten). Bauprojekte haben zur Erfüllung dieser drei Ziele und zur Steigerung der Produktivität im Vergleich zu anderen Branchen ein großes Optimierungspotenzial. Um auf die dynamischen Veränderungen der Bau- und Immobilienprojekte reagieren zu können, haben sich bis dato agile Managementansätze wie beispielsweise Lean Construction etabliert. In der Softwareentwicklung und in weiteren Branchen gehört das agile Rahmenwerk „Scrum“ zum Arbeitsalltag.2 Scrum baut auf die kollektive Intelligenz der am Projekt beteiligten Personen. Dies soll den Wert eines Projekts maximieren. Aufgrund der Erfolge auch außerhalb der Softwareentwicklung bieten sich mit Scrum Potenziale zur Verbesserung von dynamischen Projektabläufen im Projektmanagement von Bau- und Immobilienprojekten.3 Die Einsatzmöglichkeiten von Scrum für die Planung und Steuerung von Bauprozessen in der Bauindustrie sind aufzuzeigen.

Abbildung 2: Stacey-Matrix15, Bild: Institut für Baubetriebslehre, Uni Stuttgart

Scrum – Allgemein

„Scrum“ stammt aus dem englischen und bedeutet ins Deutsche übersetzt „Gedränge“.4 Es beschreibt einen bestimmten Spielzug im Rugby, bei dem sich die Spieler nach einer Freistoßsituation dicht gedrängt um den Spielball platzieren. Die Analogie zu Scrum als Managementmethode besteht darin, dass beim Rugby durch den kollektiven Einsatz der Mannschaft versucht wird, die unvorhersehbare Situation und den kommenden Spielzug zu beherrschen.5 Im Mittelpunkt steht das kooperative, selbstverantwortliche und selbstorganisierte Verhalten des Teams. Damit Wissen und Erfahrungen bestmöglich eingesetzt werden können, sind Aufgabenstellungen und Vorgehensweisen zur Bearbeitung im Team festzulegen. Verantwortung wird nicht delegiert, sondern dem interdisziplinär zusammengesetzten Team übertragen. Das Rahmenwerk Scrum baut auf drei Säulen auf, die sich an den Grundsätzen des Lean Thinking orientieren:

  • Transparenz,
  • Überprüfung und
  • Anpassung.6

Mit Transparenz verfolgt Scrum ein einheitliches Verständnis von Begriffen, Inhalten, Zielen und Qualitäten, um mögliche Missverständnisse zu vermeiden. Der Ist-Zustand wird regelmäßig dem geplanten oder prognostizierten Soll-Zustand eines Projekts oder einer Aufgabe gegenübergestellt. Nach der Analyse des Ist-Zustands folgt die Anpassung der geplanten Tätigkeiten. Analog zum Prozess des Knowledge Discovery in Databases (KDD) findet in Scrum ein iterativer Prozess statt. Die gewonnenen Erkenntnisse sollen in die zukünftigen Prozesse einfließen (vgl. Predictive Analytics).7Komplikationen des vorausgegangenen Prozessschritts (sog. Sprints) können Auswirkungen auf den nachfolgenden Sprint haben und sind in der weiteren Vorgehensweise zu berücksichtigen. Im übergeordneten Scrum Guide (Regelwerk für Scrum) werden drei Rollen definiert, um ein Projekt effizient zu gestalten. Diese bilden in ihrer Gesamtheit das sog. Scrum Team:8

  • Development Team
  • Product Owner
  • Scrum Master

Das Development Team ist für die Umsetzung der Aufgaben verantwortlich. Um alle dazu notwendigen Kompetenzen abzudecken, ist es interdisziplinär aufgestellt und handelt weitestgehend eigenverantwortlich. Der Product Owner trägt die Verantwortung für das Erreichen der Projektziele unter Einhaltung des Projektbudgets. Er definiert die Qualität, mit der Anforderungen umgesetzt werden sollen und priorisiert die zu erledigenden Arbeitspakete. Während der Product Owner für wesentliche Entscheidungen zuständig ist, unterstützt der Scrum Master das Team bei der richtigen Umsetzung von Scrum. Er führt das Team durch die Scrum Ereignisse und trägt zur kontinuierlichen Verbesserung der Prozesse bei.9

Anwendungsfelder von Scrum

Das optimale Einsatzfeld von Scrum befindet sich in Projekten mit komplexen Aufgabenstellungen.10 Als komplex gelten Projekte, deren genaues Ziel oder genaue Anforderungen sowie deren Lösungsweg zu Projektbeginn in Teilen unklar sind. Zudem tragen zu erwartende Veränderungen der Anforderungen und die steigende Anzahl der Projektbeteiligten zur Komplexität von Projekten bei.11 Nach Malik ist „die Zahl der möglichen verschiedenen Zustände, die ein System aufweisen oder annehmen kann“ maßgebend für Komplexität.12 Zusammengefasst lassen sich komplexe Systeme u. a. durch folgende Kriterien identifizieren:13

  • Vielzahl von unterschiedlichen Elementen mit vielfältigen Beziehungen (Eigendynamiken)
  • Veränderliche Wirkungsverläufe
  • Hohe Vielfalt an Verhaltensmöglichkeiten
  • Verzögerung (Auswirkungen einer Aktion nicht direkt sichtbar)
  • Nichtlinearität (soziales Verhalten nicht linear und vorhersagbar)

In Ergänzung hierzu wird auf Stacey- Matrix in Abbildung 2 verwiesen. Diese stellt den Zusammenhang zwischen der Klarheit des Projektziels und der Kenntnis der Vorgehensweise her.14

Aus Befragungen einer wissenschaftlichen Arbeit geht hervor, dass Bau- und Immobilienprojekte regelmäßig den beschriebenen Komplexitätsbereich erreichen.16

Zusammenfassend kann der Einsatz von Scrum bei Bauprojekten abhängig von der vorzufindenden Komplexität bestätigt werden. Insbesondere Projekte mit einem dynamischen Umfeld und vielen Unsicherheiten können von agilen Vorgehensweisen wie Scrum profitieren. Auf Veränderungen der Anforderungen kann reagiert werden.17 Die Synergien und weiterführenden Mehrwerte in Bauprojekten durch Scrum sind darzulegen.

Scrum – Projektablauf

Scrum durchläuft iterative Zyklen, welche als Sprints bezeichnet werden. Ein Sprint umfasst eine Reihe von Ereignissen, die terminiert sind und nacheinander durchlaufen werden (vgl. Abbildung 3). Zur Projektinitiierung werden die Grundlagen sowie der übergeordnete Ablauf des Projekts anhand der Anforderungen des Kunden analysiert und abgeschätzt. Aus den Anforderungen werden Arbeitspakete abgeleitet und im sog. Product Backlog gesammelt. Das Product Backlog ist die Auflistung der zu bearbeitenden Anforderungen und Aufgaben, aus der sich Prioritäten und Abhängigkeiten der einzelnen Einträge ableiten lassen. Übertragen auf Bauprojekte, sind diese Zielvereinbarungen des Bauherrn denkbar: „10-geschossiger Büro-Neubau mit hohem Standard für rund 400 Arbeitsplätze mit Foyer.“

Da sich Bauprojekte von der Softwareentwicklung durch komplexe Vernetzungen und das Zusammenwirken vieler unterschiedlicher Projektbeteiligter unterscheiden, ist eine Vielzahl von Experten erforderlich, die den Product Owner beim Erkennen von Abhängigkeiten der Arbeitspakete unterstützen. Das Product Backlog kann zu Beginn nicht vollständig sein, da sich mit Voranschreiten des Projekts aus der Bearbeitung einzelner Arbeitspakete regelmäßig weitere Pakete ergeben. Neben den weiteren Informationen, die über den Projektverlauf generiert werden, sind Änderungswünsche des Kunden anzuführen. Die Fortschreibung der Arbeitspakete ist insbesondere für den Auftraggeber (AG) von Bedeutung. Zum Projektstart hat der AG im Vergleich zu den Auftragnehmern (AN) mehr Kenntnisse. Über den Projektverlauf verlagert sich das Projektwissen auf die AN (vgl. Principal Agent Dilemma). Durch Transparenz und Kommunikation in Scrum soll dieses Dilemma vermieden werden.

Hohe Agilität in Verbindung mit terminlichen Prognosen erfolgt bei Scrum für Bauprojekte über einen Zeitplan auf Meilensteinebene. Dieser dient als grobes Gerüst und Zielsetzung des Projekts. Er wird Bestandteil der Kundenanforderungen und muss im Zuge des Sprint Reviews regelmäßig verifiziert werden. Die Einbeziehung des Meilensteinplans in die Prozessabläufe ist ein wesentlicher Unterschied zur Softwareentwicklung. Er dient bei Bauprojekten als Leitplanke und erhöht die Akzeptanz der Methodik in der Umsetzung bei den Beteiligten.19 Erkannte Effizienzsteigerungen in Bauabläufen durch die Beteiligten sollen fortlaufend miteinbezogen werden.

Abbildung 3: Projektablauf mit Scrum18, Bild: Institut für Baubetriebslehre, Uni Stuttgart

Sprint Planning

Jeder Sprint ist als eigenes, kleines Projekt zu verstehen, dessen allgemeiner Ablauf in Abbildung 1  visuell dargestellt ist. Im Sprint Planning wird die Vorgehensweise des gestarteten Sprints geplant. Das Scrum Team definiert in einem Workshop die Arbeitspakete für den jeweiligen Sprint. Für jedes Arbeitspaket muss eindeutig definiert werden, was bis wann und von wem erledigt wird, damit der Sprint störungsfrei ablaufen kann. Die „Definition of Done“ bestimmt, zu welchem Zeitpunkt ein Arbeitspaket bzw. Ereignis tatsächlich abgeschlossen ist (= einheitliches Verständnis). Unterschiedliche Auffassungen über die Zielerreichung werden vermieden.

Zur übersichtlichen Abwicklung des Sprint Plannings eignet sich die Verwendung eines Visualisierungsboards, dem sogenannten Scrum Board. Die Visualisierung von Informationen ist ein einfaches und einflussreiches Instrument, dessen Wirkung von Projektbeteiligten oftmals unterschätzt wird. Es kann sowohl digital als auch analog geführt werden. Eine digitale Version (bspw. ConceptBoard, Miro, Mural) des Scrum Boards bietet allen Projektbeteiligen jederzeit Einblicke, ohne an Besprechungen vor Ort teilnehmen zu müssen. Auf Baustellen bietet sich die Integration in einen „Big Room“-Container an. Auf dem Board werden die Arbeitspakete im sogenannten Sprint Backlog gesammelt, durch Notizen ergänzt und durch farbliche Kennzeichnung thematisch Planern oder Gewerken zugeordnet (vgl. auch Kanban).21 Die farblich hervorgehobene Thematisierung (z. B. Unterscheidung nach Gewerken) hilft dabei, Zusammenhänge und Schnittstellen einfacher und früher zu erkennen. Es spiegelt neben den Aufgabenpaketen deren Leistungsstand wider. Die visuelle Darstellung fördert die Übersichtlichkeit zu den Tätigkeiten im Sprint Backlog für alle Projektbeteiligten. Das Überwachen und Kontrollieren einzelner Tätigkeiten von Arbeitnehmern werden dabei nicht verfolgt und widersprechen dem Grundgedanken von Scrum.

Sprint

Der Sprint ist der Ausführungsprozess und somit der wertschöpfende Teil von Scrum. Die geplanten Aufgaben wie beispielsweise Ideen, Planung und Produktion werden herausgearbeitet. Ein Teil des Endprodukts entsteht.22 Im Sinne des Lean Gedankens ist der Sprint so effizient wie möglich zu gestalten.

Der Zeithorizont eines Sprints sollte nicht zu lange gewählt werden, da sich ansonsten die Agilität und Flexibilität des Teams reduzieren. Ist der Sprint zu kurz, können keine hochwertigen Ergebnisse erarbeitet werden. Die Dauer eines Sprints soll daher auf maximal einen Monat begrenzt werden. Die Sprintdauer während des Projekts sollte nicht verändert werden. Dies gewährleistet kontinuierliche und stetige Prozesse im Bauprojekt. Langfristige Ziele sollen schneller erreicht werden können.23 Möglicherweise werden durch die festgelegte Sprintdauer nicht alle Mitglieder des Development Teams dauerhaft ausgelastet sein. In der Regel begleiten Planer, Ingenieure, Architekten und auch Projektsteuerer mehrere Projekte parallel, wodurch es unmöglich ist, einem Projekt ständig zur Verfügung zu stehen. Daher ist es sinnvoll, dass die Beteiligten festgelegte Projekttage nutzen, an denen sie sich mit dem Projekt befassen. Diese sollten innerhalb des Scrum Teams abgestimmt werden, sodass einzelne, aufeinanderfolgende Wochentage entstehen, an denen das Team gemeinsam arbeiten kann. Dieser Aspekt unterscheidet sich beispielsweise von Scrum-Einsatz in der Softwarebranche (Fokus auf ein Projekt). Um dem Scrum Team Räumlichkeiten zur Verfügung zu stellen, wird auf der Baustelle ein Raum eingerichtet, der als Projektsteuerungsraum zum Mittelpunkt des Teams wird (vgl. Big Room).

Daily Scrum

Das Daily Scrum dient als täglicher, kurzer Informationsaustausch des Scrum Teams. Durch das regelmäßige Zusammenkommen der Projektbeteiligten und die gemeinsame inhaltliche Abstimmung im Team wird die Zusammenarbeit gefördert.24 Erkennen die Mitglieder des Development Teams bei ihrer Arbeit Anpassungsbedarf der Aufgabenpakete oder Hindernisse, werden diese im Daily Scrum angesprochen. Ziel ist es, Schnittstellen zwischen Planern zu erkennen und zu berücksichtigen. Die tägliche Abstimmung sollte maximal 15 Minuten dauern. Während des Daily Scrums sind Diskussionen oder Dialoge zu vermeiden. Mögliche Diskussionen werden durch den Scrum Master unterbunden. Themen, die einer ausführlicheren Besprechung bedürfen, werden am Scrum Board markiert und gesondert in Einzelgesprächen bilateral diskutiert.

Die konsequente Durchführung der Daily Scrums reduzieren die Notwendigkeit weiterer, oftmals umfangreicher, Besprechungen.25 Gründe hierfür sind das wachsende Vertrauen in die Leistungsfähigkeit sowie das gesteigerte Vertrauenslevel im Team. Der kurzzyklische Austausch zu relevanten Themen und Lösungen entwickelt eine hohe Akzeptanz von Scrum und aktiviert das Gemeinschaftsgefühl.26

Sprint Review

Jeder Sprint verfolgt das Ziel, mindestens ein fertiges Inkrement zu erarbeiten. Dies entspricht einem zu erwartenden und potenziell lieferfähigen Ergebnis, welches dem Kunden am Ende des Sprints in einem vierstündigen Sprint Review präsentiert wird. Das Scrum Team prüft, ob die geschaffenen Ergebnisse den vereinbarten Anforderungen an Funktion und Qualität entsprechen. Inkremente können auch in Form von Planungs- und Ausführungsqualitäten, gewonnenem Wissen oder Risikominderung existieren. Neben dem Scrum Team nehmen der Bauherr und bei Bedarf weitere ausgewählte Stakeholder am Sprint Review teil. Als mögliche Stakeholder können etwa Nutzer und Betreiber des geplanten Gebäudes oder städtische Behörden genannt werden. Arbeitet das Planungsteam in einem BIM-Modell, kann z. B. die Weiterentwicklung des Modells anhand einzelner Ausschnitte hervorgehoben und veranschaulicht werden. Der Bauherr hat auf Grundlage der Ergebnisse und neuer Erkenntnisse die Möglichkeit, seine Anforderungen anzupassen, die im anschließenden Sprint Planning berücksichtigt werden. Neben den geschaffenen Inhalten bewertet das Team im Sprint Review die eigene Performance. Dies erfolgt mithilfe von Kennzahlen bzw. Key Performance Indikators (KPI), wie etwa der Anzahl erfüllter Arbeitspakete.27

Sprint Retrospektive

Nach dem Sprint Review findet als letztes Sprint-Event die Retrospektive statt. Diese soll die Qualität und Effektivität der Zusammenarbeit innerhalb des Teams und im Projekt kontinuierlich steigern.28 Im Vordergrund stehen die Zusammenarbeit und das Teamklima. Die Dauer der Sprint Retrospektive ist auf höchstens drei Stunden festgelegt.29 Die Teilnehmer der Retrospektive sind Vertreter des Scrum Teams, der Bauherr und gegebenenfalls ausgewählte Stakeholder.30

Ziel der Retrospektive ist es, konkrete Maßnahmen zu erarbeiten, die das Team im nächsten Sprint umsetzen kann. Weiterhin werden eventuell nicht abgeschlossene Aufgabenpakete aus dem Sprint Backlog analysiert. Es wird hinterfragt, warum diese nicht vollständig abgeschlossen werden konnten. Unabhängig der betroffenen Personen steht die Kausalität im Fokus der Betrachtung. Fehler werden vom Team akzeptiert und als Möglichkeit der Weiterentwicklung genutzt (vgl. folgendes Beispiel):

„Ein Fliesenleger konnte nur 80 Prozent seines geplanten Arbeitspakets erreichen. Dies kann mehrere Gründe haben:

  • Das Material ist nicht in ausreichender Menge verfügbar und innerhalb des Sprints konnte kein Nachschub besorgt werden (Lieferkettenproblematik).
  • Ein vorgelagertes Gewerk bzw. eine AG-Vorleistung blockiert die eigene Leistungsausführung (sog. Ursache-Wirkungskette).
  • Die Leistung des eigenen Teams wurde überschätzt etc.“

Durch die Reflexion der eigenen Leistung werden Verbesserungsmaßnahmen abgeleitet. Diese tragen dazu bei, die Prognosegenauigkeit für den nächsten Sprint zu steigern. Neben der Anpassung der Arbeitsweise werden in der Sprint Retrospektive der Zeitplan und das Budget geprüft. Diese können durch unvorhergesehene Entwicklungen oder Veränderungen der Kundenanforderungen beeinflusst werden. Notwendige Anpassungen des vorgesehenen Meilensteinplans und Veränderungen des Budgets werden mit dem Kunden gemeinsam festgelegt.31 Die Ergebnisse der Retrospektive sollen eine kontinuierliche Produktivitätssteigerung des Teams fördern.


Wie schneidet der traditionelleProjektablauf versus Scrum ab? Lesen Sie hier dazu mehr. Dort gibt es auch weitere Ausführungen zu einer konkreten Anwendung von Scrum mit Link zu einem digitalen Dashboard, über dessen Sprint Performance sowie sämtliche Literaturverweise.

Werden Sie Autor*in der Build-Ing.

Möchten Sie die Fachzeitschrift Build-Ing. mitgestalten?
Dann schreiben Sie uns unter der E-Mail-Adresse aldina.hasanovic@hussmedien.de!
______________________________

1 Vgl. o. V. (2020), Project Management Institute, S. 27
2 Vgl. Demir (2019), S. 41
3 Vgl. López-Gónzalez u. a. (2021), S. 17
4 Vgl. Nesensohn (2018) S. 326
5 Vgl. Goll/Hommel (2015), S. 82
6 Vgl. Fiedler (2018), S. 230
7 Vgl. Weissinger u. a. (2021), S. 17 f.
8 Vgl. Fischbach/Steinbrecher (2020), S. 122
9 Vgl. Fischbach/Steinbrecher (2020), S. 126
10 Vgl. Fiedler (2018), S. 237
11 Vgl. Van Ooyen (18. 6. 2021), Internetquelle
12 Malik (2000), S. 38
13 Schwerdtner u. a. (2019), S. 18 ff.
14 Vgl. Angermeier (18. 6. 2021), Internetquelle
15 Eigene Darstellung in Anlehnung an Mainproject Hybrid (18. 6. 2021), Internetquelle
16 Vgl. Mohr (2021), S. 36
17 Vgl. Demir (2019), S. 44
18 Eigene Darstellung in Anlehnung an Kuster u. a. (2019), S. 20
19 Vgl. Mohr (2021), S. 57
20 Scrum.org (1. 7. 2021), Internetquelle
21 Vgl. Demir/Theis (8. 3. 2021), Internetquelle
22 Vgl. Fiedler (2018), S. 231
23 Vgl. Mohr (2021), S. 60
24 Vgl. Schwaber/Sutherland (2020), S. 10
25 Vgl. Fiedler (2018), S. 232 f.
26 Vgl. Fiedler (2018), S. 232 f.
27 Vgl. Fiedler (2018), S. 232
28 Vgl. Schwaber/Sutherland (2020), S. 11
29 Vgl. Schwaber/Sutherland (2020), S. 10 f.
30 Vgl. Fiedler (2018), S. 233
31 Vgl. Fiedler (2018), S. 233

© Bild: Institut für Baubetriebslehre, Uni Stuttgart
Autoren

Nils Mohr (M. Sc.) studierte­ Wirtschaftsingenieurwesen an der Universität Stuttgart. Im Rahmen seiner Abschlussarbeit am Institut für Baubetriebslehre beschäftigte er sich mit den Anwendungsmöglichkeiten und Potenzialen von Scrum in der Baubranche. Aktuell ist er als Junior Projekt Manager bei PHOENIX Living GmbH in den Bereichen Projektentwicklung und Projektmanagement tätig. (Bild:Dennis Engelbert, Institut für Baubetriebslehre, Uni Stuttgart)
phoenix-living.de


Marcel Weissinger (M.Sc.) ist akademischer Mitarbeiter am Institut für Baubetriebslehre der Universität Stuttgart. Zu seinen Forschungsschwerpunkten zählen digitale Methoden und Technologien sowie deren Auswirkungen auf die Bauprozesse. Zuvor war er als Berater im Baubetrieb und Projektmanagement tätig.( Bild:Dennis Engelbert, Institut für Baubetriebslehre, Uni Stuttgart)
uni-stuttgart.de


Univ.-Prof. Dr.-Ing. Hans Christian Jünger ist Leiter des Instituts für Baubetriebslehre der Universität Stuttgart. Er forscht und lehrt u. a. zum Thema Digitalisierung in der Bauwirtschaft sowie den damit einhergehenden Technologien. Zuvor war er bei diversen Großprojekten für verschiedene international tätige Unternehmen in leitenden Positionen beschäftigt und verantwortlich für die Themen Digitalisierung, Lean Construction und BIM. (Bild: Institut für Baubetriebslehre, Uni Stuttgart)
ibl.uni-stuttgart.de

Kommentare
  • Keine Kommentare
Diesen Artikel teilen
Anzeige
Gratis Probeheft bestellen!