Kilka ostatnich rozmów na temat tego, jak poradzić sobie z projektami w organizacji zainspirowało mnie do napisania uproszczone (jak zwykle krok po kroku) poradnika na temat wdrażania zarządzania portfelem projektów z perspektywy decydenta. Rodzaj swoistego executive summary.
Adresatem poniższego poradnika są decydenci w organizacjach, którzy odpowiadają za to, by projekty dobrze się toczyły: prezesi, dyrektorzy, menadżerowie biur projektów. Wprowadzanie metodyki jest inicjatywą złożoną i trudno jest zdefiniować jedno dobre podejście. Istotne jest, aby działania w obszarze zarządzania projektami za punkt wyjścia miały ważny problem biznesowy. Wdrażanie metodyki dla samego wdrażania nie ma sensu i wiele firm świetnie sobie radzi bez formalnych metod zarządzania projektami.
Przykładowe problemy z projektami mogą być takie, jak poniżej:
- Nie wiem, jakie projekty są realizowane w firmie – wszyscy mówią, że robią jakiś projekt, a firma już straciła kontrolę co chcemy robić, a czego nie.
- Projekty się spóźniają – tyle tematów jest pilnych, a projekty ciągle są opóźnione. Jaki byśmy termin nie postawili, i tak nie zostanie dotrzymany. Szczególnie irytujące są spóźnienia tematów najbardziej priorytetowych i to mimo powiedzenia ludziom, jak są dla mnie ważne.
- Marża na projektach jest zbyt niska i nie obejmuje wszystkich kosztów – w ofercie wyceniamy klientowi realizację na dobrej marży, a w trakcie projektu tysiące rzeczy wychodzi, które tą marżę pochłaniają. Duża część projektów zamyka się na poziomie niemal zerowego dochodu, a gdyby doliczyć koszty organizacyjne, reklamacyjne itp. to okazałoby się, że jest jeszcze gorzej.
- Ważne dla mnie projekty nie posuwają się naprzód mimo, że ludzie są ciągle zajęci tematami, które są nieistotne dla firmy – zamiast się rozwijać skupiamy się na sprawach bieżących.
- Ciągle ktoś z kimś się kłóci w projektach i często muszę interweniować – i to dyskutują o nieistotnych dla firmy problemach, a wysłanie mówienie wszystkim, że komunikacja jest dla nas najważniejsza nie przynosi skutku.
- Klienci narzekają na jakość dostarczanych prac w projektach – ten problem wstawiłem prowokacyjnie. Moim zdaniem zarządzanie jakością za wyjątkiem naprawdę dużych i drogich projektów jest bardziej domeną procesów produkcyjnych niż zarządzania projektami. Czyli jakość wytwarzania powinna być zarządzana na poziomie ogólnofirmowym. W taki sposób definiuje to też PRINCE2. Jeżeli robimy dużo projektów informatycznych, to zapewnienie jakości powinno być częścią prac działu IT. Jeżeli robimy projekty konstrukcyjne, to jest to obszar zainteresowania działu produkcji.
Jeżeli identyfikujesz któryś z wymienionych problemów u siebie w organizacji, to ten tekst może okazać się użyteczny.
Wdrażanie zarządzania projektami powinno być przeprowadzone na kilku poziomach jednocześnie: postaw, wiedzy, procesów i narzędzi. Ludzie muszę chcieć pracować efektywniej i czuć potrzebę takiej pracy, a ostatecznie nawet protestować, gdy ktoś chce pracować w projekcie wbrew ogólnie przyjętym zasadom, np. gdy chce uruchomić projekt bez opracowania planu. Ludzie muszą wiedzieć, co należy robić, jakie techniki stosować, jakich terminów używać. I tu uwaga: w organizacji rozkład umiejętności projektowych może być bardzo nierównomierny. Niektórzy mogli nigdy nie zetknąć się tym zagadnieniem, a inny przyszli z bardziej zaawansowanych firm lub hobbystycznie interesują się tematem i posiadają całkiem sporą wiedzę. Na pewno wszyscy uczestnicy projektów powinni znać podstawowe pojęcia, wiedzieć, czym jest projekt i jakie dawać zwrotne informacje kierownikowi projektu. Natomiast kierownicy projektów i menadżerowie powinni dysponować nieco większą wiedzą dotyczącą co najmniej zarządzania ludźmi, planowania i kontroli. Jeżeli chodzi o procesy, to ważne jest, by pracownicy wiedzieli, jak poprawnie postępować w różnych sytuacjach i czego się spodziewać. Na przykład, kiedy i komu zgłosić przekroczenie terminu, w jakiej formie zapisane są wymagania klienta, kto ma prawo wysłać zlecenie na produkcję. W końcu narzędzia są potrzebne, gdy praca manualna jest zbyt uciążliwa. Stwierdzenie prawdziwe zarówno dla młotka, jak i MS Projecta. Zwykle potrzeba użycia narzędzi pojawia się, gdy procesy projektowe po pierwsze są ustabilizowane, po drugie osiągają skalę, która uzasadnia pokrycie kosztów wdrożenia.
Zarządzanie projektem zakłada jedną ważną rzecz: Najpierw planujemy,
a dopiero później zaczynamy działać.
Zasada planuj-działaj rodzi wiele istotnych konsekwencji dla pracy w projektach:
- Każda praca wykonywana ma wcześniej przygotowany plan, np. datę startu i końca, liczbę przewidzianych osobodni, zakres działań itd.
- Zawsze możemy przeanalizować jak zakładaliśmy, że będzie w porównaniu do rzeczywistej sytuacji.
- Na początku projektu, gdy pojawia się problem, zmiana, siadamy i zaczynamy planować, a dopiero później działamy. Działanie bez planu mści się.
- Plany są konsultowane z tymi, którzy je będą wykonywali.
Bez planu nie można mówić o zarządzaniu projektem. Wręcz planowanie jest jedną z cech definicji projektu (projekt to przedsięwzięcie które jest stopniowo opracowywane). Jeżeli istnieje schemat planowania, super, można pominąć jeden z kroków wdrożenia zarządzania projektami. Jeżeli nie, to warto poświęcić chwilę z wybranymi pracownikami i uzgodnić, jakie informacje powinny znaleźć się w planie projektu.
Warto pamiętać, że planowanie zawsze zaczyna się od celów i zakresu projektu. Najpierw musimy wiedzieć, co i po co chcemy zrobić, aby odpowiedzieć na pytanie, jak, za ile, kiedy.
Najbardziej typowe elementy planu projektu to:
- Cele – dokąd zmierzamy i po co;
- Koncepcja – jak sobie wyobrażamy wykonać zakres projektu, jak to będzie działać;
- Zakres – lista elementów (produktów), które zamierzamy dostarczyć w ramach projektu;
- Harmonogram lub główne kroki – oznaczenie na osi czasu, kiedy dostarczymy poszczególne elementy projektu;
- Budżet – lista pozycji do kupienia, niekiedy liczba osobodni do zarezerwowania na projekt;
- Zespół projektowy – kto będzie jaką rolę pełnił w projekcie, a przede wszystkim kto będzie sponsorem i kierownikiem projektu.
Kroki wdrażania zarządzania projektowego
Metodyka zarządzania projektami to zbiór zasad, które powinny doprowadzić do szczęśliwego końca większości projektów. Wiodące metodyki to PMBOK (Project Management Body of Knowledge), PRINCE2, istnieje też szereg szczegółowych metodyk związanych z różnymi dziedzinami działalności przedsiębiorstw, np. produkcją oprogramowania. Metodyka mówi, co powinien robić sponsor projektu, jakie informacje powinien zawierać plan projektu, jakie obowiązki kierownik projektu. Jednak metodykę od procedury firmowej różni to, że abstrahuje ona od konkretnego biznesu i organizacji. Natomiast firma powinna opracować własne standardy działania inspirowane zasadami metodyki (procesy projektowe), na bazie których będą pracowali ludzie. Czyli metodyka mówi, że teoretycznie kierownik projektu planuje projekt, natomiast procesy projektowe konkretyzują, że najpierw musi pójść do klienta i zebrać wymagania w postaci dokumentacji funkcjonalnej, następnie zatwierdzić tą dokumentację z technologiem w aspekcie wykonalności projektu itd.
Zatem pierwszy krok wdrażania procesów projektowych to ustalenie po co w ogóle zabieramy się za tą trudną dziedzinę. Czyli należy zdefiniować, jaki problem chcemy rozwiązać, przykłady podane zostały powyżej.
Dalej możemy działać dwutorowo:
- Ludzie – z jednej strony zadbać o ludzi w projektach, a dokładniej ich postawy i umiejętności.
- Procesy – z drugiej strony zorganizować procesy administracji projektami.
Ciąg dalszy nastąpi…
