utworzone przez Marcin Żmigrodzki
Wiedza jest ważna. To truizm. Jednak w projektach wiedza ma szczególny wymiar.
Poniżej opiszę, jakie są główne sposoby zarządzania wiedzą w projektach, które można napotkać lub których nie można napotkać, ale zaleca je metodyka.
Dobrze obrazuje to poniższy wykres przyrostu wiedzy w trakcie projektu.
Wiedza w projekcie przyrasta sukcesywnie, im więcej zakresu jest wykonane i im więcej czasu upłynie. Na końcu wiemy zdecydowanie więcej, niż na początku. Główne wyzwanie polega na tym, że większość decyzji podejmujemy na początku, gdy musimy zgadywać.
Drugi aspekt funkcjonowania wiedzy to rosnąca zmienność projektu w czasie, co symbolicznie ilustruje poniższy diagram.
Jeżeli na pionowej osi zaznaczylibyśmy trafność prognoz, na przykład terminu, kosztu, pracochłonności, różnych aspektów jakościowych, a na poziomej czas projektu, to okazałoby się, że błąd prognoz rośnie w czasie. Rośnie aż do sytuacji, gdy projekt wymyka się spod kontroli. W wynika to z faktu, że po drodze pojawia się szereg czynników środowiskowych, które pozostają poza kontrolą oraz z tego, że poprzednie etapy sprzedają swoje problemy następnym. Jeden dzień opóźnienia na etapie planowania, staje się pięcioma albo więcej dniami opóźnienia na etapie odbiorów.
Zatem, w jaki sposób zarządza się wiedzą w projektach w praktyce. Podzieliłbym to na dwa sposoby: formalny i nieformalny.
Formalny to taki, w którym istnieje jakaś procedura, sposób postępowania, której należy przestrzegać. Wiedza projektowa uzyskuje tu namacalną formę. W ramach tego podejścia wyróżniłbym dwie kolejne kategorie: ilościowe oraz jakościowe.
Jakościowe formalne to podejście zalecane przez PRINCE2, PMBOK Guide i oznacza ono tyle, że po projekcie należy siąść i spisać raport poprojektowy. Warto w nim opisać przebieg projektu, wnioski, dobre praktywki, problemy etc. dla potomnych. Takie podejście zakłada, że z projektu na projekt będą gromadziły się raporty, tworząc obszerną bibliotekę. A następnie każdy kolejny kierownik projektu będzie z niej korzystał, aby ustrzec się podobnych błędów. Moim zdaniem to nie działa, ale fajnie brzmi.
Ilościowe formalne to podejście, w którym ktoś z boku przygląda się różnym projektom. Gromadzi dane o nich na wybrany temat. Na przykład, gdy dla firmy ważne jest pilnowanie kosztów, to zbiera dane o planach i wykonaniach kosztów w różnych projektach. Ma je pogrupowane na rozmaite sposoby, jak data, rodzaj klienta, rodzaj kosztu, wielkość, etap, osoba decydująca o koszcie, miejsce i wiele innych. Następnie, gdy taki analityk już uzbiera dość danych, to zaczyna się przez nie przekopywać. Poszukuje powtarzających się zależności i czynników środowiskowych na przestrzeni wielu projektów. Na tej podstawie wyciąga wnioski i proponuje modyfikację procesów projektowych. Przykładowo może ustalić, że koszt materiału A zawsze jest o 10% niższy, gdy zamawia go doświadczony kierownik projektu. To oznacza, że warto by przeszkolić pozostałych kierowników, aby uzyskać oszczędności na poziomie 10%. Takie podejście, moim skromnym zdaniem, może naprawdę świetnie działać. Wymaga niestety dużych ilości danych z projektów oraz sprytnego analityka, który raz na jakiś czas siądzie do nich i zada sobie pytanie „co tu się powtarza?”.
Nieformalne podejście ostatnio stało się popularne pod nazwa retrospektywa. Jednak nie jest to wcale nowa filozofia postępowania. W armiach różnych krajów przykładowo od tysięcy lat istniała praktyka omawiania ostatniej operacji, dzisiaj nazywana After Action Review. w obszarze zarządzania produkcją od kilkudziesięciu lat znany jest termin koła jakości. Tak czy siak, idea, by grupa ludzi jadących na tym samym wózku na chwilę odłożyła narzędzia lub maczugi i zastanowiła się, w jaki sposób zoptymalizować swoją pracę jest atrakcyjna. Wszystko jedno, czy chodzi o większą produktywność kolejnego sprintu, eliminację defektów, czy zabijanie wroga. Moim zdaniem, retrospektywa może być niesłychanie skuteczna.
O tym dlaczego uważam, że formalne jakościowe zarządzanie wiedzą w praktyce słabo działa, a retrospektywa czy analiza danych dobrze, napiszę w kolejnym wpisie.
Ps.
Tematyka zarządzania wiedzą w projektach jest mi szalenie bliska z racji napisanego doktoratu oraz systemu zarządzania wiedzą, który onegdaj projektowałem i koordynowałem realizację w ramach nieistniejącej już firmy Pyton.
utworzone przez Marcin Żmigrodzki
Czy stanęliście kiedyś przed wyzwaniem, albo zleceniem szefa pod tytułem „zrób raport z tego projektu, żebym wiedział, o co w nim chodzi”? W organizacjach, w których powszechnie jest stosowany jakiś standard, sprawa jest oczywista. Z archiwum wyjmuje się jakiś stary raport z podobnego projektu, zmienia nazwę, aktualizuje cyferki, wstawia swoje nazwisko i gotowe. Ważne też, aby wstawić aktualną datę, żeby raport wyglądał na autentyczny.
A powaznie mówiąc, gdy mamy standardy naszą wiedzę o projekcie wtłaczamy w ten standard i wysyłamy takiego powerpoint, word, excel, ekran w systemie do zarządzania projektami lub inny rodzaj raportu.
Ale gdy nie dysponujemy standardem, ale patrzymy na owe standardy krytycznie warto wiedzieć, w jaki sposób można monitorować projekty. Poniżej postanowiłem dokonać przegląd typowych metod i posortować je od najmniej wiarygodnych i najprostszych do najbardziej zaawansowanych, ale i dających obiektywne i rzetelne informacje
(więcej…)
utworzone przez Marcin Żmigrodzki
Jednym z powszechnych źródeł pojawiania się nieprzewidzianej pracy w projektach, a w konsekwencji opóźnień i przekraczania budżetu jest fast tracking. PMBOK Guide stwierdza pobłażliwie, że jest to jedna z technik kompresji harmonogramu, która podnosi ryzyko. Moim zdaniem to tak, jakby powiedzieć, że muchomory wyglądają smacznie, ale podnoszą ryzyko.
(więcej…)
utworzone przez Marcin Żmigrodzki
Projekt Książka rozwija się systematycznie. Z dumą ogłaszam, że mam już 3 rozdziały. Udało mi się też opracować strukturę całej powieści. Będzie ona składać się z 7 rozdziałów. Każdy będzie poświęćony innemu czynnikowi generującemu koszty i opóźnienia w projektach.
Pragnę też publicznie podziękować beta testerom, którzy na ochotnika zgłosili się do czytania roboczych wersji tekstów. Otrzymałem tuziny uwag i większość z nich znacząco poprawiła jakość mojego dzieła.
Roboczy tytuł, jaki przyszedł mi do głowy (no dobra Adam podpowiedział) Project Inc. Historia firmy projektowej. Gdyby ktoś miał lepszy pomysł, to oczywiście z przyjemnością wysłucham propozycji.
Mam nadzieję, że do września uda się stworzyć całą treść w wersji conajmniej roboczej. I przez jesień zostanie mi czas na cyzelowanie języka, postaci i zdarzeń.
utworzone przez Marcin Żmigrodzki
Czy wasza firma ma wdrożonego PMBOK®? Takie pytanie kilka razy napotkałem w rozmowach kuluarowych i oficjalnych. Poniższy tekst jest adresowany raczej do początkujących, bo posiadacze PMP® bo wielomiesięcznym przebijaniu się przez opasłą książkę mają tą wiedzę w jednym palcu. I każdy z nich wie, czym jest ITTO oraz w jaki sposób environmental factors wpływają na procesy oraz jak lessons learned przekształcają się w organizational process asets.
Otóż PMBOK Guide® można wdrożyć w taki sam sposób, jak można wdrożyć w firmie Wikipedię. Innymi słowy jest to błędnie postawione wyzwanie.
Jak PMBOK® Guide może wspomóc organizację? Książka zawiera kilkaset stron wypełnionych tzw. dobrymi praktykami. Czym są owe praktyki? To techniki, metody, zagadnienia z biznesu i nauki, które grupa kierowników projektów uznała za warto włożenia do tejże książki. Bardzo często o pojawieniu się danej praktyki nie decyduje jej wartość, a popularność w biznesie. Jednak żadna organizacja na świecie nie stosuje wszystkich kilkuset praktyk. Zatem można by zaryzykować stwierdzenie, że nikt nie wdrożył PMBOK® Guide.
Z drugiej strony wszystkie organizacje stosują różne powtarzalne nawyki. Czasem jest to zrobienie listy zadań na najbliższy miesiąc, innym razem cotygodniowe spotkanie, na którym omawia się problemy firmowe, jeszcze innym razem burza mózgów, albo wyjazd integracyjny na którym pije się i strzela z kulek z farbą. Wszystkie wymienione w tym akapicie zdarzenia są wspomniane przez PMBOK® Guide jako dobre praktyki pod mądrymi nazwami activity list, check list, meeting, brainstorming, team building. Zatem każda organizacja można powiedzieć, że wdrożyła PMBOK® Guide. Paradoks? Nie. Po prostu mówienie o wdrożeniu encyklopedii gdziekolwiek jest niezasadne.
W takim razie, co można zrobić z mądrościami zawartymi w książce? Można wybrać pojedyncze z nich i zastosować w projektach firmowych. Następnie przyjrzeć się, czy dają nam wartość, czy jesteśmy na nie gotowi, czy umiemy z nich korzystać i podjąć decyzję o kolejnych praktykach, które chcielibyśmy użyć lub wycofać się z niektórych.
Dobrą metaforą będzie marsz po polu minowym. Wyobraźmy sobie, że zespół projektowy ma zadanie przejść na drugą stronę pola minowego. Wdepnięcie w pułapkę powoduje ich zatrzymanie. Zespół nie ma mapy min ani planów, jak reagować na eksplozje. Więc co chwila się potyka.
Zespół maszeruje sobie i potyka się o różne sytuacje (metaforycznie pokazane jako bomby). Przy każdej eksplozji traci czas, pieniądze, może i jakość, ale wędruje sobie dalej.
Zespół niejako bojem odkrywa, którą droga da się przejść, a która jest zaminowana.
Jeżeli w organizacji realizowany jest kolejny projekt, to na nowo musi odkrywać mapę pola minowego. Widać to po czerwonej marszrucie drugiego projektu na obrazku poniżej.
Autorzy PMBOK® Guide założyli, że wiele projektów wykłada się na podobnie rozmieszczonych minach takich, jak na przykład pełzające wymagania, brak jasnego podziału odpowiedzialności, słaba kontrola kosztów, nieświadomość wpływu zależności między zadaniami na czas projektu itd. I uznali, że gdyby je spisać, to by mogło pomóc kolejnych generacjom kierowników projektów. Innymi słowy stworzyli mapę z zaznaczonymi bombami oraz instrukcjami, jak sobie z nimi poradzić. Mapa nie jest powiązana z określonym projektem prowadzonym w twojej firmie, czytelniku, jednak zakłada, że istnieją grząskie miejsca, które można napotkać w bardzo wielu projektach również w twoim.
Przypomina to metaforycznie mapę pola minowego z zaznaczonymi najczęściej spotykanymi minami oraz dodaną instrukcją, jak je rozbroić. W zależności od tego, którą drogą będzie podążał twój projekt, takie dobre praktyki mogą okazać się użyteczne.
Główna trudność w stosowaniu zapisów tej książki polega na tym, że tych min i instrukcji rozbrajania jest tak dużo oraz w tym, że trzeba umieć zidentyfikować, z jaką miną mamy do czynienia zanim ona wybuchnie i być w stanie skutecznie przeprowadzić procedurę z dobrej praktyki. I tego uczą się kandydaci na PMP®.
PMBOK, PMP, PMI-ACP, CAPM, PMI-RMP, PMI-SP, PgMP, PfMP, PBA are registered marks of the Project Management Institute, Inc.
utworzone przez Marcin Żmigrodzki
Założenia początkowe naszego modelu są następujące. Osoba, która wycenia prace nie wykonuje ich. To może być kierownik projektu, szef działu, sponsor, handlowiec. Po drugie zakładamy, że ta osoba nie otrzymuje informacji zwrotnej na temat rzeczywistej pracochłonności prac w projekcie. Czyli zakładamy, że ta osoba nie uczy się na błędach. Dla uproszczenia dalszych analiz przyjmijmy, że błąd estymacji pracy jest stały i na przykład wynosi 50%. To oznacza, że zadanie wycenione na 10 osobodni faktycznie zajmuje 15, ale pracownik, który podał ta wartość, już o tym nie wie. Tą dodatkową pracę będziemy pokazywali po wykonaniu pracy planowanej. Dla lepszej wizualizacji praca planowa będzie zielona, a dodatkowa – żółta.
Pewne zjawiska w zarządzaniu swój wpływ wykazują dopiero na przestrzeni czasu i ich wpływ na pojedynczy projekt jest pozornie oczywisty. Z tego powodu w dalszej części będziemy zajmowali się modelem pokazującym kilka projektów realizowanych w wyimaginowanej firmie na przestrzeni lat. Nasza firma posiada 3 działy A, B, C i każdy z nich dysponuje ograniczonymi zasobami. A ma 10 ludzi, B – 20, C – 10, będziemy ją przeliczali na osobodni miesięcznie, czyli A – 200, B – 400, a C – 200. Załóżmy też, że w każdym projekcie 30% wykonuje dział A, 50% – B, a 20% – C i że zadania A, B, C powinny następować po sobie. W wypadku, gdyby musiały się nakładać pojawi się zjawisko fast tracking, co będzie powodowało powstanie dodatkowej pracochłonności na poziomie 30% pracy zrównoleglonej.
Tutaj potrzebne jest słowo wyjaśnienia. Fast traking to sytuacja, gdy zadania normalnie następujące po sobie zrównolegla się, aby przyśpieszyć ich wykonanie. Efektem jednak jest ryzyko, że pewną pracę trzeba będzie zrealizować ponownie. Przykładowo przed skończeniem programowania aplikacji ruszają jej testy. Może się okazać, że część testów trzeba będzie powtórzyć, bo programowanie może stworzyć nowe błędy pod koniec. Albo malowanie ścian przed zakończenie montażu parapetów. Instalacja końcowy parapetów może wybrudzić ściany i coś trzeba będzie pomalować na nowo. Przyjęliśmy, że taka nałożona na siebie praca obciążona będzie dodatkową pracochłonnością na poziomie 10%.
W pracy pojawia się często jeszcze jedno zjawisko – wielozadaniowość. To sytuacja, gdy człowiek nie może dostatecznie skupić się na jednym zadaniu, bo oczekuje się od niego, że w tym samym czasie będzie pracował nad kilkoma. Wielozadaniowość ma drastyczny wpływ na efektywność prac, co wynika z ograniczonej pojemności naszych umysłów, konieczności poświęcenia czasu na skoncentrowanie się na nowym zadaniu, spadku motywacji, frustracji, większego ryzyka popełniania błędów. Niektóre opinie mówią, że wielozadaniowość może odpowiadać za 40% czasu. Załóżmy, że w naszej firmie nie jest aż tak drastycznie i obciążenie wielozadaniowością zwiększa o 20% pracochłonność zadań, w momentach gdy są robione równolegle przez ten sam zespół
Poniżej można zobaczyć przykładowy portfel składający się z siedmiu projektów, który spełnia powyższe złożenia. Na zielono w trzech dolnych wierszach zaznaczono, w których miesiącach nie wykorzystuje się pełnej dostępności ludzi w poszczególnych zespołach A, B, C.
Jak widać bardzo trudno jest zaplanować portfel prac, który idealnie wypełniałby czas ludzi. Wówczas dopycha się go mniejszymi projektami w tzw. okienkach. Widać to po „poszarpanych” harmonogramach projektów #6 i #7. Widać też, że prace są zaplanowane do lipca drugiego roku.
Teraz dodajmy błąd estymacji do powyższego planu i zobaczmy, jak projekty zaczną się opóźniać. Zakładamy, że firma chce realizować projekty w kolejności powyższej od #1 do #7.
Jak widać na powyższym obrazku, po dodaniu pracochłonności wynikającej z błędów szacowania pojawiła się ekstra praca. W dolnych trzech wierszach pokazałem wpływ nowej pracy na limity zasobów. Na czerwono widać, w których miesiącach założono za dużo pracy w stosunku do zatrudnionych ludzi. Organizacja oczywiście nie widzi w styczniu, jakie błędy estymacji zawarła w swoim planie rocznym. Odkrywa je krok po kroku, gdy pracuje nad kolejnymi zadaniami. Skoro odkryje, że gdzieś ludzie jeszcze siedzą nad zadaniem mimo, że dawno powinni je skoczyć, to firma odsuwa następne zadania w czasie. Nazywamy to bilansowaniem zasobów. Alternatywnie może zlecić robienie kilku zadań równolegle, wówczas ludzie wpadają w wielozadaniowość.
Załóżmy, że w naszym przypadku kadra menadżerska w reakcji na wzrost pracochłonności podjęła następujące decyzje uwidocznione na poniższym diagramie. Jednak priorytetem dla nich było nie opóźnianie zaplanowanych startów projektów.
Menadżerowie częściowo zdecydowali się opóźniać zadania, a częściowo zmusili ludzi do trybu wielozadaniowości. Kolorem czerownym zaznaczono dodatkową pracochłonność wynikającą właśnie z multitaskingu (20% dodatkowej pracy) i fasttrackingu (10% dodatkowej pracy).
Nasz plan portfela mocno się porozsuwał. Zaś w poszczególnych projektach następujące po sobie zadania zrównolegliły się. Przykładowo w projekcie #5 zadanie A zaczyna się miesiąc wcześniej, ale potem pół roku trwa równolegle z zadaniami B i C. Typowy fast tracking. Wartości w czerwonych polach pokazują, jak wzrosła pracochłonność dzięki temu oraz wielozadaniowości. Można też zauważyć, że im projekt rozpoczynany później, tym bardziej ma poszarpany harmonogram z przerwami w wykonywaniu zadań oraz bardziej jest rozciągnięty w czasie. Wynika to z tego, że choć powinniśmy przykładowo robić zadanie B w projekcie #6, to z powodu zaległych zadań w projektach #3, #4, #5 nie można było do tego usiąść.
Z perspektywy pojedynczego pracownika taka praca coraz mniej przypomina organizacyjnie pojedyncze przedsięwzięcie, a coraz bardziej gaszenie pożarów. Przykładowo zespół C w maju pierwszego roku zajmuje się tylko projektem #1, ale już w maju roku drugiego zespół C jest zaangażowany w projekt #3, #4 i #5, i przełącza się między tymi tematami.
Efektem takiego pełzającego wzrostu pracochłonności jest większe obciążenie ludzi. Gdyby ich spytać, co robią w danej chwili, to przez większość czasu są obciążeni na 100%. Jednak gdyby spojrzeć na plan portfela, to wszystko jest spóźnione. Paradoks? Nie, brak wiarygodnych planów oraz powielanie błędów przydzielania prac (przez wielozadaniowość, fast tracking). Poniższy wykres pokazuje planowane i rzeczywiste obciążenie ludzi praca w procentach.
Ludzie nie tylko non stop coś robią (niebieska linia), ale i uporają się zadaną robotą o jedną trzecią później. Pomarańczowa linia planu schodzi do zera w dwudziestym miesiącu, zaś wykonania – niebieska w dwudziestym dziewiątym.
Czas na podsumowanie.
Wniosek 1. Nie zawsze, gdy ludzie twierdzą, że są wiecznie przeciążeni pracą, oznacza to dobre kompetencje menadżerskie. Czasem jest wręcz odwrotnie. Czasem z dobrego planu wynika, że w danej chwili wybrany zespół nie ma nic do roboty w projektach.
Wniosek 2. Niedoszacowanie, fast tracking i multitasking generują coraz większe zamieszanie im później projekt jest realizowany. W naszej symulacji harmonogramy projektów zaczęły się rozsypywać po około dziesięciu miesiącach, a po dwóch latach zapanował zupełny chaos. Wyobraźmy sobie tą firmę za pięć lat.
Wniosek 3. Brak informacji zwrotnej odnośnie realności estymacji tylko pogłębia błędy. Bo zamiast zatrzymać i przeplanować z gruntu projekty, próbuje się gasić pożary, wpadając w kolejne pułapki wielozadaniowości i fast trakingu.
Wniosek 4. Raporty pokazują zwykle jedynie pola zielone (planowane wyceny). Pola żółte (wykonania) rzadziej są śledzone, do tego wymagane jest wiarygodne raportowanie. Natomiast pola czerwone (spadek efektywności prac wskutek błędów menadżerskich) już zupełnie są ukrywane.
