Doświadczenia z projektu

Każdy projekt, również budowa piramidy z klocków Lego, funkcjonuje w pewnym środowisku, w którym nieuniknione są zmiany. Mogą być to trudne do przewidzenia zmiany, dotyczące funkcjonalności produktu, zmiany wywołane czynnikami wewnętrznymi lub zewnętrznymi, np. związane z sytuacją finansową firmy lub sytuacją ekonomiczną kraju, czy też warunkami pogodowymi (u nas często zmieniał się poziom Nilu, co uniemożliwiło transport kamieni drogą wodną lub lądową), przypadki losowe dotyczące członków zespołu projektowego sytuacji całego kraju (nas dopadła wojna, strajk pracowników, katastrofy budowlane). Z gry wyciągnęliśmy ważny wniosek: cały czas należy zarządzać ryzykiem, oceniać je i zabezpieczać się na wypadek najbardziej prawdopodobnych nieszczęść.

Wzbogaceni doświadczeniem i po analizie błędów z pierwszego etapu zabawy, uczestnicy naszego projektu nauczyli się przewidywać zdarzenia i przygotowywać się na nie, co pozwoliło nam uniknąć wielu opóźnień i strat finansowych. Bardziej świadomie planowaliśmy też nasze działania i podział zasobów. Okazało się też, że wręcz modelowo zareagowaliśmy na problemy jakościowe w projekcie. Pierwszy etap zaowocował pomyłkami związanymi z brakiem kontroli ze strony nadzorującego realizację projektu członka zespołu. Fundamentom naszej piramidy groziło zawalenie, a cała konstrukcja powstała nie w tym miejscu co trzeba. "Zazwyczaj po jednej lub dwóch wpadkach jakościowych zespół zaczyna przykładać coraz większą wagę do jakości" - powiedział w podsumowaniu Robert Gontkiewicz, członek zarządu CTPartners, który prowadził grę i wcielił się w rolę Faraona. Po dotkliwych finansowo problemach wynikających z zaniedbania kwestii jakości, zespół odpowiadający za budowę zaczął lepiej współpracować z osobą odpowiedzialną za nadzór. W efekcie Faraon nie miał do końca realizacji projektu żadnych zastrzeżeń, jeśli chodzi o jego jakość.

Symulacja ma to do siebie, że nie wszystko da się przewidzieć. Nie wszystko jest też w instrukcji, wiele zależy od uczestników gry. Okazało się, że choć nikt nam tego nie sugerował, intuicyjnie zastosowaliśmy kilka, zalecanych przez metodyki zarządzania projektami, działań. Choć raczej działaliśmy w modelu agile niż bardziej "poukładanej" metodyki PRINCE2.

Nadzór zaczął np. analizować poziom Nilu w poszczególnych cyklach projektu. Tworzone na kartce papieru wykresy były źródłem pomocy dla sekcji odpowiadającej za transport, która bardziej świadomie planowała działania. Pokazało nam to, jak ważna jest analiza danych archiwalnych i poprzednich doświadczeń.

Zespoły projektowe dostosowały też do swoich potrzeb procedury biurokratyczne. Nie oznaczało to jednak całkowitej rezygnacji z nich, gdyż - jak przyznali w podsumowaniu uczestnicy projektu - widzieli wiele korzyści z raportowania stanu realizacji zadań. I tak np. dział transportu postanowił, że będzie raportował jako jeden dział, a nie podwójnie jako Sekcja Nilu i Sekcja dróg. Dzięki takim działaniom, bieżącemu usprawnianiu pracy oraz analizie popełnianych błędów, udało nam się wybudować Piramidę. I to wszystko w założonym czasie, budżecie i zgodnie z zaplanowanymi parametrami jakościowymi.