RÓWNIEŻ NA BLOGU:

Celem tego wpisu jest zachęcenie użytkowników do stosowania systemu wspomagającego zarządzanie firmą projektową do zarządzania projektami i ułatwienie rozpoczęcia tego procesu. Istnieje bezpośrednia zależność pomiędzy tym co chcemy kontrolować w trakcie realizacji projektu, a tym w jaki sposób definiujemy zadania. Im większy poziom oczekiwanej kontroli tym bardziej szczegółowo powinny być definiowane zadania. Powstaje zatem pytanie:

Jak szczegółowo definiować zadania w projekcie?

W inżynierii proces sprawdzania dokumentacji jest integralną częścią procesu projektowego. Kontrola zatem nie powinna być słowem budzącym grozę, niepopularnym. Dlatego też, dobrą sugestią, którą uznaję za dobrą praktykę, jest takie definiowanie WBS projektu inżynierskiego, by w ramach poszczególnych zadań można było zidentyfikować poszczególne opracowania i przeprowadzić w udokumentowany sposób proces ich sprawdzania. Specjalnie użyłem słowa opracowania, gdyż niekoniecznie należy tworzyć osobne zadania dla każdego rysunku. Tak jak zawsze należy kierować się zdrowym rozsądkiem. Posłużę się przykładem, dokumentacja wykonawcza instalacji rurociągowej odpowiedzialnej za napełnianie i osuszanie, składającej się z obwiązania wokół zbiornika, kolektora zaworowego, stacji pomp i filtrów składa się z rzutów pokazujących rozmieszczenie instalacji w przestrzeni (może to być model 3D), listy materiałowej i rysunków izometrycznych niezbędnych do prefabrykacji rurociągów w warsztacie. Proces projektowania może przebiegać w sposób następujący: przez 2 tygodnie w narzędziu BIM tworzony jest model 3D i wykonywana jest koordynacja obiektu, następnie opracowany jest plan montażowy, dokonywany jest podział instalacji na odcinki, generowana jest automatycznie lista materiałowa i gdy przebieg oraz koordynacja jest zatwierdzona projektant przystępuje do zautomatyzowanego generowania rysunków izometrycznych, co może zająć w zależności od skali instalacji od kilku godzin do kilku dni. W opisanym powyżej przypadku wyróżniłbym 3 opracowania dla których przygotowałbym 3 zadania:

• Zadanie 1 Wykonanie modelu 3D w aplikacji BIM 2 tygodnie

• Zadanie 2 Wykonanie rysunku planu montażowego i listy materiałowej

• Zadanie 3 Wykonanie katalogu rysunków odcinków izometrycznych do prefabrykacji

Wszystkie wskazane powyżej zadania tworzą razem zbiór informacji niezbędnych do wykonania obiektu. Mogę zatem utworzyć z nich grupę, co będzie szczególnie zasadne jeśli na przykład będę chciał zarządzać całym pakietem dokumentów lub wyświetlić wszystkie związane z instalacją napełniania i osuszania dokumenty. Mogę w ramach planu utworzyć atrybut np.: „Instalacja napełniania i osuszania” i przez jego przypisanie do dokumentów w przyszłości rozbudowywać grupę. Na przykład jeśli okaże się, że w toku realizacji projektu konieczne będzie wykonanie programu testów instalacji, to program testów będzie kolejnym dokumentem, którego przygotowanie może okazać się kolejnym zadaniem.

Określając zadania powinniśmy myśleć także o ich terminach, oczywiście w umowie określamy termin przekazania, więc tzw. Deadline jest oczywisty, nic nie stoi jednak na przeszkodzie by zadania kończyć wcześniej i można to robić, jeśli niesie to z sobą zyski dla organizacji. Kolejnym istotnym elementem planowania jest określenie daty rozpoczęcia realizacji zadania. Nie ma lepszego przykładu braku planowania niż zadania wpisane do systemu w ten sposób, ze data rozpoczęcia każdego zadania w projekcie rozpoczyna się w dniu rozpoczęcia projektu, a data zakończenia każdego zadania w dniu zakończenia projektu. Takie podejście oznacza, że firma interesuje się tylko rejestracją czasu pracy, a planowanie i nadzór nad realizacją projektu odbywa się, miejmy nadzieję, poza systemem. Jeśli jednak inżynier ma zadania zdefiniowane w projekcie w ten sposób, a jego praca projektowa realizowana jest „od powstania do powstania”, ma do czynienia ze spiętrzeniami pracy i w okresie tuż przed zakończeniem projektu on lub ktoś inny, próbuje nadrobić wszelkie opóźnienia na ostatniej prostej, to delikatnie mówiąc w obszarze zarządzania projektami i zasobami „może być jeszcze w organizacji miejsce na poprawę”.

Coraz częściej wraz z zawarciem umowy przygotowywany jest harmonogram Gantta, pokazujący dla każdej z ujętych w HRF czynności daty rozpoczęcia i zakończenia oraz zależności pomiędzy poszczególnymi elementami. Daty rozpoczęcia to często terminy przekazania danych wejściowych przez klienta lub daty zakończenia czynności poprzedzających. Harmonogram załączony do umowy zdefiniowany w ten sposób, może być dobrym impulsem i informacją wejściową do przygotowania planu projektu, trzeba jednak pamiętać, ze najczęściej HRF zawiera tylko najważniejsze elementy i docelowy WBS projektu powinien być praktycznie zawsze bardziej szczegółowy. Są oczywiście branże jak np.: okrętownictwo, offshore, energetyka w których harmonogramy rzeczowo finansowe stanowią praktycznie kompletne WBS, jednak w innych branżach, takich jak budownictwo kubaturowe, przemysłowe czy infrastruktura nie jest to sytuacja powszechna.

Zdefiniowanie WBS to pierwszy krok do stworzenia planu otwierającego realizację projektu. Warto pamiętać, że WBS może zmieniać się wraz z rozwojem projektu, jednocześnie w ramach jednego projektu wielobranżowego można dopuścić różne poziomy szczegółowości podziału zadań w różnych branżach.

Jakie są najczęstsze błędy w budowie WBS?

Wspomniany wcześniej brak planowanie i stosowanie systemów zarządzania do zbierania godzin na zadania, których czas realizacji jest równy czasowi realizacji projektu lub jego fazy. Myślę, że można to uznać za grzech pierworodny kierowników projektu.

Kolejne podejście, pozornie wyglądające na plan, to przydzielenie zadań dla poszczególnych branż w ramach etapów. Mimo, że po wydrukowania zadań jest dużo i pozornie wygląda to jak zaplanowany harmonogram, to w rzeczywistości jedyną różnicą w stosunku do ‘grzechu pierworodnego” jest wprowadzenie możliwości śledzenia budżetu w etapach dla poszczególnych branż.

Nie twierdzę oczywiście, że jest to podejście złe, oba opisane powyżej sposoby mogą mieć swoje uzasadnienie, ale dają one szansę na zarządzanie systemowe procesem projektowania. Koncentrują się one na tym, żeby zbierać w toku realizacji projektu godzin, czyli kosztów i kontroli dat końcowych, których niestety najczęściej firmy stosujące takie podejście nie dotrzymują.

Kolejny duży błąd to pomijanie relacji między zadaniami. Nie chodzi mi tutaj o niestosowanie zależności, poprzedników i następników. Te rozwiązania nie są doskonałe i rzadko uwzględniają specyfikę projektowania inżynierskiego, w którym nawet zależne od siebie zadania są realizowane „na zakładkę”. Mam na myśli całkowite ignorowanie wzajemnych relacji w planowaniu, czego jedynym uzasadnieniem może być tylko to, że osoba planująca nie ma merytorycznej wiedzy na temat przebiegu procesu projektowania lub w jakimś, na przykład branżowym, obszarze projektu.

Zaplanowanie projektu to pierwszy krok to praktycznej realizacji cyklu PDCA, mam nadzieję, że wskazówki w tym wpisie są pomocne, zachęcam także do dyskusji i kontaktu. W kolejnym wpisie poruszę temat delegowania zadań pracownikom do realizacji.

Design and implementation of Spectrum Marketing | 2023 All rights reserved.

Get to know the Wayman system

Social media

Contact

email: contact@wayman.pl

phone: +48 663 466 517

Wayman Sp. z o.o.

Piotra Skargi 14/2, Gdynia

Pawia 9 (High5ive), Cracow

Poland