1. pl
  2. en

Uważasz artykuł za ciekawy?

Chcesz się z nami skontaktować?

NAPISZ!

Twój e-mail:
Treść wiadomości:
Wyślij
Wyślij
Formularz został wysłany - dziękujemy.
Proszę wypełnić wszystkie wymagane pola!
Zapisz się do newslettera:
Wyślij
Wyślij
Formularz został wysłany - dziękujemy.
Proszę wypełnić wszystkie wymagane pola!

BIM

15 kwietnia 2020

Co zrobić żeby BIM był Agile? Zwinny BIM 10/10

Autor: Krzysztof Knapik

 

Jak uwolnić kreatywność zespołów BIM, poprawić komunikację i wykorzystać zmiany do budowania przewagi konkurencyjnej?

 

W poprzednich wpisach z cyklu zwinny BIM przybliżyliśmy podstawy Building Information Modeling (BIM) oraz zwinnych metod zarządzania (Agile) wraz z podaniem tłumaczenia zasad Agile na język BIM. Są już zrealizowane pierwsze inwestycje, które z powodzeniem łączą porządek informacyjny jaki daje BIM ze zwinnością jaki daje Agile. Takim przykładem może być Projekt Kampusu Szpitala El Camino Medical Group w Mountain View (Kalifornia) [1].

 

W tym wpisie inspirując się powyższym przykładem poszukam odpowiedzi na pytania:

  1. Czy Agile może być uzupełnieniem dla BIM?
  2. W jakim zakresie zasady BIM i Agile są tożsame?
  3. Jak uwolnić kreatywność zespołów BIM, poprawić komunikację i wykorzystać zmiany do budowania przewagi konkurencyjnej?
  4. Które elementy zarządzania projektami budowlanymi można zmienić, aby w większym stopniu skorzystać ze zwinności którą umożliwia zastosowanie BIM?

 

Już w 21 kwietnia organizujemy szkolenie AGILE BIM on-line dla wszystkich zainteresowanych tematyką zwinnych metod w BIM

Formularz zapisów dostępny na stronie terminarza TUTAJ

 

 

Ze względu na szeroki zakres zagadnień które można omówić odpowiadając na powyższe pytania, skupię się na trzech obszarach:

  • podziale ról i obowiązków, 

  • organizacji pracy oraz 

  • komunikacji, w tym przede wszystkim na spotkaniach.

Istnieje wiele odmian Agile, jedną z najpopularniejszych jest Agile Scrum, dlatego dalsze, bardziej szczegółowe rozważania oprę i ograniczę do tej odmiany [2] [3].

 

Role w projekcie

 

W Agile Scrum zostały wydzielone 3 role:

  • Zespół projektowy który powinien mieć wszystkie niezbędne zasoby i umiejętności (różne, uzupełniające się kompetencje) i który odpowiada za zaplanowanie, organizację i wykonanie pracy. Zespoły składające się ze specjalistów doskonale wiedzą jak i kiedy powinny wykonać pracę aby osiągnąć założony cel. Oznacza to, że powinny mieć możliwość samoorganizowania się, aby najlepiej skorzystać ze swojej wiedzy i uwolnić kreatywność

  • Product Owner odpowiada za kontakt z klientem i reprezentuje jego punkt widzenia. Podejmowanie decyzje co do rozwoju produktu i wykorzystaniu czasu Zespołu projektowego.

  • Scrum Master odpowiada za wprowadzenie Scrum w życie,  zrozumienie i przestrzeganie zasad oraz usuwanie przeszkód.

 

W projektach budowlanych (zadaniach inwestycyjnych) ról jest zdecydowanie więcej, ale w obrębie zespołu projektowego BIM rolę odpowiadającą “Scrum Mastera” może przyjąć “BIM koordynator”. Jest to osoba odpowiedzialna między innymi za przestrzeganie standardów, wspieranie zespołu i dostarczenie modelu o ustalonych parametrach jakości. Rolę zbliżoną do “Product Ownera” może przyjąć “Kierownik Projektu lub BIM Manager”. Podstawowa różnica polega na tym, że w tradycyjnie zarządzanych projektach budowlanych, w tym również w tych realizowanych w BIM, zespoły projektowe mają narzucony przez przełożonych plan, podział i organizację pracy, co może powodować niepełne wykorzystanie ich potencjału. Zmiana struktury zespołu na samoorganizujący jest możliwa ponieważ specjaliści doskonale znają się na swojej pracy i sami potrafią wybrać optymalną drogę aby osiągnąć założony cel. Kierownictwo powinno stworzyć i pielęgnować odpowiednie środowisko pracy, motywować zespół i sprawować bardziej subtelną kontrolę.

 

 

Planowanie, podział pracy i wymiana informacji

 

Charakterystyczną cechą Scrum są tzw sprinty, czyli iteracje (powtarzalne cykle czasowe, zwykle od tygodnia do czterech tygodni) o długości określonej przez zespół dopasowanej do naturalnego cyklu pracy firmy lub specyfiki projektu. Scrum bazuje na pracy zespołu, który na koniec każdego sprintu powinien dostarczyć skończony produkt. Gwarantuje to zespołowi pozyskanie informacji zwrotnej od zamawiającego,  a Product Owner’owi, że gdy projekt będzie zmierzał w złym kierunku nie straci więcej czasu niż długość sprintu.

 

Każdy sprint powinien składać się z:

  • Planowanie Sprintu,  czyli wyznaczenie celów i sposobów ich osiągania,

  • Codzienne kontrolowanie pracy według dowolnych metod obranych przez zespół,

  • Przegląd Sprintu, czyli podsumowanie i przedstawienie efektów danego dnia,

  • Przegląd, propozycje ulepszeń, korekty i nowe koncepcje.

  • Tak zdefiniowany sprint sam w sobie może być traktowany jako indywidualny projekt, a to oznacza zmniejszenie zakresu prac do wykonania i zakończenia określonym terminie.

 

Product Owner tworzy listę swoich potrzeb w  Backlogu Produktu w kolejności od najważniejszej do najmniej ważnej. Na początku Sprintu Zespół ustala co i w jaki sposób jest w stanie dostarczyć z Backlogu Produktu. To spotkanie zwane Planowaniem Sprintu (Sprint Planning) nie powinno trwać dłużej niż jeden dzień. Plan, nazywamy Backlogiem Sprintu, jest tworzony przez zespół,więc to zespół jest za niego odpowiedzialny i wie jak go zrealizować. Bardzo ważnym elementem tego procesu są krótkie codzienne spotkania zwane Codziennym Scrumem lub Stand up meeting (Daily Scrum) i nie powinny przekraczać 15 minut. W trakcie trwania Sprintu Zespół przygotowuje się również do następnych Sprintów poprzez przeglądnięcie, omówienie i uporządkowanie Backlogu Produktu. Na to Porządkowanie Backlogu Produktu (Product Backlog Refinement) Zespół najczęściej poświęca 5-10% całego czasu ze Sprintu.

 

Organizacja Przestrzeni Wymiany Danych CDE i jej podział na Work in Progress (WIP), Shared i Published jest oparta na zbliżonym rozwiązaniu. Pojawia się tu iteracyjne dodawanie informacji oraz jest zaplanowana przestrzeń do pozyskiwania informacji zwrotnej od Zamawiającego i innych uczestników projektu (zadania inwestycyjnego). Różnice które mogę się tu pojawić w stosunku do zasad Scrum to dłuższe okresy iteracji bez otrzymania informacji zwrotnej oraz tendencja do długiego utrzymywania zadań w stanie “prawie skończone”. W tradycyjnie zarządzanych projektach budowlanych zespoły nie mają możliwości samodzielnego planowania swojej pracy, nie ma też zwyczaju odbywania codziennych krótkich 15 minutowych spotkań. W większości przypadków w tradycyjnie zarządzanych projektach jest tylko jeden typ spotkania - “spotkanie”, które jest długie, dotyczy dużego zakresu spraw, a uczestnicy angażują się w minimalnym zakresie aby go jakoś przetrwać [4]. W projektach realizowanych zgodnie z BIM jest możliwa zmiana organizacji pracy zespołu, w tym również rodzajów i intensywności spotkań.

 


Kampus Szpitala El Camino Medical Group w Mountain View (Kalifornia), źródło: www.dpr.com

 

Dobrym przykładem, o którym już wspomniałem na początku wpisu, jest Projekt Kampusu Szpitala El Camino Medical Group w Mountain View (Kalifornia). [1] 

Budynek szpitala o pow. ok 23 000m2 (wraz z parkingiem ok 40 000m2) i o wartości ok 100 mln USD dzięki połączeniu BIM i zwinnych metod zarządzania (Agile):

  • Zrealizowano 6 miesiecy przed terminem (przy założeniu tradycyjnych metod)

  • Oddano do użytku poniżej założonego budżetu

  • Na budowie nie pojawiła się ani jedna kolizja (w projekcie skoordynowanym w BIM usunięto wszystkie kolizje międzybranżowe)

  • oceniono poprawę wydajności pracy na 15-30%

 

Projektanci pracowali pod dużym reżimem czasowym, np modelerzy MEP mieli obowiązek codziennie przez 15 minut przerwać pracę żeby sprawdzić między sobą i z szefem zespołu postępy prac oraz określić czy są wstanie spełnić zobowiązania z cotygodniowych spotkań koordynacyjnych. Zespół inżynierów MEP pracował w trybie procesu zwinnego (częste krótkie spotkania “twarzą w twarz” na żywo lub online, aby na bieżąco weryfikować stan projektu i podejmować działania korygujące).

 

Na podstawie doświadczeń z tego projektu można wyróżnić 4 rodzaje spotkań których zakres i forma odpowiadała spotkaniom charakterystycznym dla Agile:

  • Spotkanie inaugurujące (Kick-off meeting)

  • Codzienne odprawy (Daily Stand-up Meeting)

  • Cotygodniowe spotkania koordynacyjne (Weekly Coordination Meeting) 

  • Spotkanie podsumowujące (Sing-off meeting)

 

Sposób planowania zadań i priorytetów nazwany w metodzie Scrum Backlog to z technicznego punktu widzenia nic innego jak tablica, która umożliwia rozmieszczanie zadań, przypisanie ich do określonych osób i przesuwanie do odpowiednich kolumn. Najprostsza struktura to np. “Do zrobienia” “Praca w Toku” Wykonane”.  Istnieją proste w obsłudze programy tj. Asana, Jira, Trello, Smatrsheet i wiele innych. Tego typu rozwiązania są z powodzeniem stosowane w projektach BIM.

 

Projekt Kampusu Szpitala El Camino Medical Group w Mountain View (Kalifornia) wykonany w technollogii BIM, źródło: www.dpr.com

 

Transparentność i podążanie za zmianą

 

Aby Agile Scrum zadziałał, powinien być oparty na trzech filarach:

 

  • Przejrzystość (Transparency) -  która pozwala wszystkim zobaczyć co się dzieje w projekcie i zmniejsza niebezpieczeństwo ukrywania lub przesuwania na później problemów. Jeżeli Zespół mówi, że ukończył pracę, to znaczy, że naprawdę ukończył i można ją udostępnić. Jeżeli pojawiają się opóźnienia lub jest w organizacji jest jakiś problem (np. członkowie różnych działów nie współpracują ze sobą), to są one widoczne dla Product Ownera i może on natychmiast podjąć działania zaradcze. 

  • Inspekcja (Inspect), analiza tego co się dzieje w zespole, projekcie i organizacji, która pozwala szybko zauważyć problemy ale również okazje do usprawnień.  

  • Adaptacja (Adapt), czyli możliwość zmiany planów i dostosowania całego procesu do rzeczywistości (np. zmiana zakresu, technologii, sposobu działania zespołu itp)

 

W projektach budowlanych wykonywanych zgodnie z BIM model 3D oraz zaproponowana w normach PN-EN ISO 19650-1,  PN-EN ISO 19650-1 (oraz wcześniejszych BS 1192:2007+A2:2016 i PAS 1192-2:2013)  wspólna przestrzeń wymiany danych CDE umożliwia pełną transparentność projektu. Project Manager (BIM Manager) ma możliwość śledzenia postępów projektu, analizować co się dzieje w projekcie oraz reagować na problemy i opóźnienia.

 

W tradycyjnie zarządzanych projektach budowlanych częstym problemem w wykorzystaniu zwinności jakie daje BIM jest sztywne trzymanie się planów i harmonogramów opracowanych na początku. Wynika to najczęściej z zapisów kontraktów i powoduje próbę naginania rzeczywistości oraz pomijanie wpływu zmieniających się uwarunkowań zewnętrznych na możliwość realizacji założonego planu. Jak pokazuje doświadczenie projektu Kampusu Szpitala El Camino Medical Group w Mountain View (Kalifornia) [1] możliwe jest przy zachowaniu niezmienionych dwóch podstawowych parametrów, tzn czasu przeznaczonego na poszczególne etapy oraz założonego budżetu, uwolnienie kreatywności zespołów w reagowaniu na zmiany poprzez dostosowywanie planów i  zakresów działań, aby osiągnąć założony końcowy efekt.

 

Niniejszy cykl na pewno nie wyczerpuje tematyki związanej wykorzystaniem Agile w projektach (zadaniach inwestycyjnych) wykonywanych zgodnie z metodyką BIM, ale wskazał trendy związane z poszukiwaniem zwiększenia produktywności w branży budowlanej oraz wybrane obszary w których możliwe są ulepszenia.

 

Podsumowując:

  • W wielu obszarach metodyka BIM i Agile mają bardzo zbliżone zasady, a zwinne metody zarządzania mogą wspierać projekty (zadania inwestycyjne) wykonywane zgodnie z BIM

  • Organizacja Przestrzeni Wymiany danych CDE, transparentność którą ona tworzy  oraz podział jej na Work in progress, Shared i Published (wg norm BS 1192:2007+A2:2016) jest rozwiązaniem zbliżonym do zasad Agile mówiących o konieczności dzielenia pracy na mniejsze serie, przedstawiania skończonych efektów pracy klientowi w celu uzyskiwania informacji zwrotnej.

  • Uwolnienie kreatywności zespołów (złożonych przecież ze specjalistów architektów, inżynierów, menedżerów którzy doskonale znają swoją pracę) poprzez zwiększenie ich samoorganizacji i umożliwienie twórczego podejścia do rozwiązywania problemów jest możliwa poprzez zmianę sposobu zarządzania zespołami.

  • Zmniejszenie ilości zadań “prawie skończonych” i uzyskiwanie informacji zwrotnej w krótkich cyklach publikowania wyników pracy “skończonej” poprawi wydajność i jakość pracy zespołów.

  •  Poprawa komunikacji to nie tylko CDE, ale też efektywne pozyskiwanie informacji zwrotnej i dostosowywanie planów o bieżącej sytuacji. Bardzo pomocne są krótkie 15 minutowe codzienne spotkania w których można zorientować się jakie jest zaawansowanie prac, jakie są problemy jak również dopasowywać plany do aktualnej sytuacji.

 

 

Literatura

[1] https://www.dpr.com/projects/camino-medical-group-medical-office-building

[2] https://agilemanifesto.org/iso/pl/principles.html

[3] Krystian Kaczor, “SCRUM i nie tylko. Teoria i praktyka w metodach Agile.” Wydawnictwo Naukowe PWN, 2019

[4] Patrick Lencioni “Death by Meeting: A Leadership Fable About Solving the Most Painful Problem in Busines”, John Wiley & Sons, 2004

 

autor: Krzysztof Knapik

 

 

 

 

© 2024 by Grupa4BIM