Narzędzia efektywnego zarządzania mniejszymi projektami

Tytuł tego postu to jednocześnie tytuł mojego wystąpienia na seminarium PMI we Wrocławiu 24 marca. Poniższą treść można traktować jako handout tej krótkiej prezentacji.

Na początek zdefiniujmy sobie co to jest ten “mniejszy projekt”. Metodą Alberta Einsteina mniejszy projekt to dla mnie projekt, dla zarządzania którym użycie MS Project jest zbyt skomplikowane / powoduje zbyt duży narzut zarządczy. W organizacjach takich jak je znam jest realizowanych wiele, bardzo wiele projektów, z których znacząca część to projekty małe. Ot choćby zmiana jednej czy drugiej procedury obsługi klienta, zorganizowanie spotkania dla klientów czy też wydanie nowej wersji katalogu firmowego. Tego typu aktywności często charakteryzują się wszystkimi cechami projektu, z tą właściwością, że ich złożoność jest o kilka rzędów wielkości mniejsza od złożoności projektu budowy nowego biurowca czy stworzenia systemu informatycznego. W związku z tym narzędzia informatyczne konstruowane z myślą o zarządzaniu projektami wielkości budowy biurowca nie mogą być wykorzystywane w sposób efektywny do tych mniejszych projektów. Głównie ze względu na swoje skomplikowanie, które powoduje, że narzut czynności zarządczych, które trzeba wykonać jest nieproporcjonalny do wielkości projektu.

Dla takich mniejszych projektów efektywne narzędzia wspierające zarządzanie nimi powinny być też mniejsze i zdecydowanie inaczej konstruowane. Na czym powinny się skupiać? Według PMI, i jest to niewątpliwie prawda, znacząca większość czasu pracy kierownika projektu jest poświęcona na komunikowanie się. W tym w szczególności na komunikowanie się z zespołem projektowym na temat poszczególnych zadań, ich statusów oraz postępu prac. W związku z tym jeżeli mówimy o efektywnym zarządzaniu projektami to podstawową funkcją, którą muszą wspierać narzędzia jest komunikacja.

Takimi właśnie narzędziami są pojawiające się ostatnimi czasy platformy internetowe oparte o technologi szumnie nazywane Web 2.0. Wiele z tych narzędzi było wręcz pisane jako nie-MS Project z nastawieniem na obsługę projektów mniejszych. Co ciekawe znacząca większość tych narzędzi kładzie nacisk właśnie na aspekty komunikacji w zespole i stara się rozwiązać ten problem poprzez udostępnienie wspólnej dla wszystkich interesariuszy platformy komunikacyjnej. Narzędzia te mają ze sobą wiele wspólnego. Do wspólnych cech zaliczyć należy przede wszystkim (oprócz dostępu przez internet z dowolnego miejsca na świecie a często także z dowolnego urządzenia mobilnego) nastawienie na maksymalne uproszczenie funkcjonalności i uczynienie doświadczenia użytkownika z pracy z narzędziem jak najbardziej pozytywnym. Poza tym, twórcy tych narzędzi garściami czerpią ze Steva Jobsa i zazwyczaj umieszczają w nich tylko i wyłącznie niezbędne funkcje, co czyni te narzędzia prostymi i efektywnymi w użyciu. Przykładowymi, choć istnieje o wiele więcej, narzędziami tego typu są BaseCamp i ActiveCollab.

Narzędzia te zbudowane są wokół koncepcji realizacji projektu poprzez osiąganie kolejnych kamieniu milowych, które to znowu są osiągane poprzez realizację zestawów zadań. Choć różni się to w szczegółach pomiędzy narzędziami to większość z nich pozwala na zdefiniowanie dla projektu dat osiągnięcia kamieni milowych. Następnie dla danych kamieni tworzy się listy zadań, przypisując odpowiedzialności do członków zespołów. Realizacja zadań jest wspomagana poprzez udostępnienie miejsca na dyskusje (coś w rodzaju forów internetowych), przechowywanie plików oraz inne dodatki zależne od konkretnego narzędzia. Śledzenie postępu przez kierownika odbywa się poprzez skondensowane dashboard’y prezentujące na jednym ekranie przeglądarki stan tego co dzieje się w projekcie. Jest to zwykle bardzo ciekawie zorganizowane, bo pokazuje stan komunikacji (co, kto, kiedy powiedział/wysłał/zaraportował) a nie jakiś wyimaginowany procentowy stan zaawansowania pracy. Takie podejście powoduje umieszczenie w jednym miejscu wszystkich informacji z realizacji projektu a także bardzo dobry pogląd na to, co się z tym projektem od strony wymiany tejże informacji dzieje.

Narzędzia te oczywiście mają także wady. Zaliczyć należy do nich głównie fakt, że czasami, zwłaszcza w sytuacjach kiedy bardzo zależy nam na czasie, mimo wszystkich uproszczeń ich użycie jest zbyt skomplikowane. Głownie dlatego, że mimo najnowszej technologii powiedzenie czegoś w bezpośredniej rozmowie jest nadal najbardziej efektywną formą komunikacji i nigdy chyba nie dorobimy się innej równie efektywnej. Drugą dużą wadą jest dla mnie to, że mimo wprowadzenia centralnego miejsca przechowywania informacji większość z tych narzędzi nie zapewnia kontroli wersji notatek, które tam się znajdują. To znaczy, że jeżeli ktoś wprowadzi jakąś informację to później można ją edytować i nie pozostawia to żadnego śladu. Takie zachowanie może wprowadzić szybko chaos komunikacyjny, zwłaszcza jeżeli osoby nie pracują w tej samej lokacji fizycznej. Kolejną wadą, czy też w tym przypadku raczej cechą, jest to że trzeba być bardzo świadomym wybierając to a nie inne narzędzie. Nie do każdego projektu one się nadają i realizacja nie każdego może być aż tak uproszczona. Ze względu na brak możliwości wymuszania sekwencji wykonywania zadań bardzo duża część projektów nie będzie mogła być efektywnie zarządzana.

Na koniec wypada tylko dodać, że jest to kolejna klasa narzędzi, którą warto znać. I używać wtedy i tylko wtedy kiedy ma to sens i jest właściwe dla danej sytuacji. Zdrowy rozsądek musi w pracy kierownika projektów odgrywać rolę pierwszoplanową.

Dyspozytor vs. Delegujący

Jak wiadomo instytucję szefa wymyślono między innymi po to, aby zarządzać zestawami zadań zbyt dużymi do zrealizowania przez jedną osobę. Istnieją dwie metody w ramach których szef może podzielić się swoim zadaniem. Umownie nazwijmy to byciem dyspozytorem bądź delegującym. Dyspozytor to osoba, która przekazuje konkretną instrukcję do wykonania. Rozdziela pracę rozumianą jako zadania do wykonania. To znaczy każdy z członków zespołu otrzymuje listę rzeczy do wykonania a następnie rozliczany jest z tego czy postąpił zgodnie z przekazaną instrukcją.

Delegowanie natomiast to zupełnie inne podejście. Zamiast przekazywać zadania przekazuje się odpowiedzialność. Czyli określa się pożądany cel i jego parametry jakościowe, natomiast nie przekazuje się wprost instrukcji jakie zadania i w jakiej kolejności należy wykonać, aby określony cel uzyskać. W tym podejściu zakłada się, że sposób dojścia do celu najlepiej znany jest osobom faktycznie wykonującym daną pracę a nie menedżerom. Rolą menedżera jest przekazać odpowiedzialność, zapewnić pracownikowi środowisko, w którym może wykonywać swoją pracę bez przeszkód a następnie odebrać prace sprawdzając czy założone cele zostały osiągnięte.

W metodach zwinnych zarządzania projektami tak naprawdę możliwa jest do zastosowania tylko i wyłącznie metoda druga. Próba zastosowania metody pierwszej (dyspozytora) prowadzi bardzo szybko do powstania wąskich gardeł zarządczych na poziomie kierowników. W środowiskach agile za dużo rzeczy dzieje się zbyt szybko, aby kierownik mógł panować nad nimi na poziomie zadań do wykonania. Jeżeli chcemy aby w naszym środowisku osiągać szybko rezultaty to jedyną opcją jest przekazywanie odpowiedzialności. Fakt, menedżer traci kontrolę nad sposobem wykonywania pracy i musi swoim ludziom zaufać. Ale jednocześnie zyskuje możliwość osiągnięcia końcowego rezultatu wielokrotnie szybciej niż przy użyciu bardziej tradycyjnej metody dyspozytorskiej.

Należy tylko pamiętać, aby razem z odpowiedzialnością wydelegować uprawnienia. Najgorszą sytuacją, którą można zafundować swoim podwładnym jest dać im odpowiedzialność za coś, ale bez uprawnienia do decydowania o wszystkich zasobach i środkach potrzebnych do wykonania danej pracy. Stawiamy wówczas pracowników przed koniecznością wykonania pracy na którą nie mają wpływu. Nie mogą więc sami decydować o jej sukcesie bądź porażce. Taka sytuacja prowadzi wprost do dużej i narastającej frustracji osób zaangażowanych w projekty.

Last but not least wypadałoby jeszcze pamiętać o różnicach kulturowych. Ci z Was, którzy mieli przyjemność pracować z Hindusami dokładnie wiedzą, że zastosowanie znajduje tylko i wyłącznie jedna z opisywanych metod.

Zespoły - na co zwrócić uwagę

Projekty realizowane metodami agile/zwinnymi wymagają zupełnie innych zespołów niż takie realizowane metodami tradycyjnymi. Jak wiadomo zespół powinien być maksymalnie 10-12 osobowy, idealnie przebywać w jednym miejscu fizycznym, sam się zarządzać + parę innych cech, bardzo często wymienianych w literaturze. Ja natomiast dzisiaj napiszę o tych czynnikach, które mogą być potencjalnym zagrożeniem dla sprawnego działania zespołu realizującego projekt przy użyciu metod zwinnych. Na te czynniki powinno się zwrócić szczególną uwagę podejmując decyzję o realizowaniu projektu metodami zwinnymi.

Po pierwsze należy to jasno powiedzieć, choć może nie jest to twierdzenie politycznie poprawne: skuteczność zespołu pracującego metodami zwinnymi zależy w dużym stopniu od kultury miejsca pracy. Chodzi tu zarówno o kulturę organizacyjną jak i kulturę państwa/narodu, którego przedstawicielami są osoby uczestniczące w projekcie. Kultura musi wspierać prace grupowe i jednocześnie deprymować lansowanie się jednostek kosztem grupy. Praca metodami zwinnymi jest pracą grupową i na to poradzić nic nie można. I tak jak z innymi zajęciami grupowymi (na przykład sport) często zdecydowanie lepszy jest zespół składający się z osób o przeciętnych zdolnościach, ale zdolnych do współpracy od zespołu składającego się z geniuszy, którzy nie potrafią ze sobą porozmawiać, bo każdy chce tylko udowodnić swoją wyższość. To jaki charakter pracy jest uprawiany w danej organizacji zależy właśnie od kultury organizacji. I niestety zmiana tego jest bardzo trudna.

Po drugie zespoły pracujące metodami zwinnymi powinny w czasie trwania projektu móc pracować tylko i wyłącznie nad tym projektem. To niestety jest bardzo trudne do zrobienia w przypadku organizacji posiadających silną strukturę macierzową. Taka struktura zakłada bowiem, że w każdy członek zespołu projektowego ma jeszcze swojego przełożonego "liniowego", który w znaczącej większości przypadków decyduje o takich rzeczach jak awanse czy podwyżki. To oznacza, że praktycznie w każdej sytuacji niejasnej pracownicy będą słuchać swojego przełożonego liniowego a nie osób z projektu. W tradycyjnie zarządzanych projektach powoduje to duże problemy i jest m.in. jedną z przyczyn notorycznych opóźnień. W projektach zarządzanych metodami zwinnymi takie podejście jest całkowicie destrukcyjne i projekty praktycznie nie mogą się toczyć. Projekt zwinny bardzo podobny jest do wspomnianego już kiedyś przypadku operacji w szpitalu. Na czas operacji cały zespół ma być tylko i wyłącznie na sali operacyjnej. Przecież nikt nie wyobraża sobie, że nagle anestezjolog wyjdzie z sali i zajmie się sporządzaniem raportu, którego akurat bardzo potrzebuje jego przełożony "liniowy". Ciekawe, że w projektach, takie zachowanie jest uważane za coś normalnego.

Po trzecie i ostatnie (na dzisiaj) należy sobie zdawać sprawę, że zupełnie inna jest rola kierownika projektu w projekcie zarządzanym metodami tradycyjnymi a zupełnie inna jest ta rola w projektach zarządzanych metodami zwinnymi. Do tego stopnia, że niektórzy puryści zajmujący sie agile twierdzą wręcz, że w tych metodach stanowisko kierownika projektu istnieć nie powinno i nazywają je inaczej (np. SCRUM Master). Tak naprawdę nie ważne jak się ono nazwa, ważne jest, że osoba wyznaczona do kierowania powinna mieć zupełnie inne umiejętności i na co innego zwracać uwagę niż w projektach tradycyjnych. Typowym przykładem jest kwestia rozdziału zadań i podejmowania decyzji. W metodach tradycyjnych zwyczajowo to kierownik projektu podejmuje wszystkie decyzje sam, podobnie on rozdziela zadania do wykonania. Takie podejście jest zaprzeczeniem metod zwinnych. Tutaj zadaniem kierownika jest tak pokierować (przewodzić) pracy zespołu, aby decyzje były podjęte wspólnie a zadania rozdzielone na zasadzie swobodnego wyboru przez członków zespołu. To oznacza również, że kierownik stosujący zwinne metody zarządzania musi być ekspertem w dziedzinie, której dotyczy projekt. W odróżnieniu od tradycyjnego podejścia, gdzie parafrazując pewną bardzo znaną książkę "nawet pielęgniarka może poprowadzić projekt budowlany, byleby miała dobrze zdefiniowany system zarządzania projektami". W metodach zwinnych takie podejście gwarantuje porażkę.

Metody zwinne w organizacji "stabilnej" cz. 1

Ostatnimi czasy metody zwinne zarządzania projektami stają się coraz bardziej popularne. Metody te najlepiej sprawdzają się w środowiskach bardzo dynamicznych, w projektach, w których występuje duża doza niepewności. Okazuje się jednak, że duża część firm działających w bardziej stabilnych środowiskach również wdraża zarządzanie zwinne. Jakie są powody tego? Na pewno swoista „moda”, ale czy tylko? Ze względu gwałtownie narastający charakter zjawiska napiszę w kilku postach, jakie mogą być powody, dla których organizacje pracujące w środowisku stabilnym wdrażają zwinne zarządzanie projektami.

Uzasadnienia nie będą w żadnej logicznej kolejności, dlatego na pierwszy ogień pójdzie powód bardzo ważny dla większości osób zaangażowanych we wdrożenia zwinnego zarządzania projektami, choć z drugiej strony być może mniej interesujący dla kierownictwa. Otóż skutkiem wprowadzenia zwinnych metod zarządzania projektami, jest to, że zespołom realizującym projekty pracuje się... przyjemniej.

Przyjemność ta wynika z kilku czynników. O jednym pisałem już kiedyś, przy okazji omawiania tematyki zmian w projekcie – w projektach zarządzanych metodami zwinnymi zespół pracuje nad zestawem funkcjonalności, które nie mają prawa się zmienić (w danej iteracji). To powoduje duży spokój psychiczny zespołu, jako że jasno określone są reguły, na podstawie których dokonywane są zmiany i nikt nie zaskakuje członków zespołu. Wbrew pozorom stabilność (choćby w ramach jednej iteracji) jest jednym z podstawowych wymogów zachowania przyjemności z wykonywania pracy.

Kolejnym bardzo dobrze wpływającym na pracę czynnikiem jest fakt, że ze swojej natury zespoły pracujące zgodnie z metodami zwinnymi są zespołami relatywnie małymi położonymi w jednej fizycznej lokacji. Bardzo częsta komunikacja między członkami zespołu powoduje dobrą atmosferę pracy choćby dlatego, że wszelkie niezrozumienia są błyskawicznie usuwane a problemy są komunikowane przynajmniej raz dziennie podczas spotkań. Poza tym w takim zespole ze względu na charakter spotkań (zarówno codziennych jak i podsumowujących iterację) każda z osób czuje się dowartościowana, bo jej zdanie jest brane pod uwagę.

Uwaga. Powyższe jest prawdą tylko o ile osoby zajmujące się koordynacją zespołów posiadają odpowiednie umiejętności komunikacyjne!!!

Praca w projektach zwinnych jest przyjemna również dlatego, że każdy z członków zespołu ma poczucie odpowiedzialności i szybką nagrodę w postaci osiągnięcia sukcesu – działający produkt na koniec iteracji. Mała wielkość zespołu w połączeniu z krótkimi iteracjami oraz tym, że na koniec każdej iteracji trzeba dostarczyć produkt wzbogacony o konkretną wartość dodaną dla klienta powoduje, że każdy z członków zespołu jest zaangażowany w dostarczanie tej wartości. Krótki czas realizacji sprawia, że każdy widzie efekty swojej pracy podczas prezentacji dla klienta. Człowiek natomiast skonstruowany jest tak, że lubi jak mu coś wychodzi.

Jak to się ma do zarządzania firmą jako całością? Ma się, gdyż jeżeli pracownikom pracuje się przyjemniej to pomaga im to pracować efektywnie. Poza tym pracownicy, którzy mają przyjemną atmosferę w pracy zwykle rzadziej myślą o zmianie pracodawcy. Jeżeli idzie to w parze z efektywnością (a idzie) to oczywistym jest, że lepiej mieć pracownika zadowolonego niż zdegustowanego.

Wielkość zespołu zwinnego

Temat wielokrotnie poruszany, tym razem doczeka się mojego komentarza. Zwykło sie uważać, że zespół pracujący metodami zwinnymi nie powinien mieć więcej niż 10-12 osób (maksymalna górna granica). Mało kto jednak pisze dlaczego tyle a nie więcej. Co prowadzi, do usilnych prób implementowania metod zwinnych w większych zespołach.

Historię trzeba zacząć od zasad podstawowych. Jedną z wartości zarządzania zwinnego jest "people and interactions over processes and tools", czyli "ludzie i interakcje ponad procesy i narzędzia". Czy to oznacza, że narzędzia i procesy nie są ważne? Nie. Narzędzia i procesy są ważne (zarządzanie zwinne to też proces) ale ważniejsi od nich są ludzie i interakcje miedzy nimi. Każdy kto pracował nad jakimkolwiek bardziej złożonym problemem w grupie ludzi doskonale wie, że choćby nie wiadomo jak dokładne były procesy i narzędzia zawsze zdarzają się sytuacje, kiedy lepiej pójść do kogoś do pokoju i wyjaśnić coś w 2 minuty zamiast (zgodnie z procesem) robić eskalację przez zarząd. Oczywiście mówimy tu o projektach a nie o np. produkcji leków - w przypadku produkcji leków raczej trzeba dokumentować, bo się kończy jak w Jelfie.

Interakcje między ludźmi są najszybszą znaną formą przekazywania informacji. Jakiekolwiek narzędzie spowalnia przekaz informacji, gdyż wymusza zakodowanie informacji do postaci akceptowalnej przez narzędzie (np. zapisanie) a następnie odkodowania przez osobę, która to odbiera (odczytanie). Dlatego w projekty realizowane zwinne cechują się często dużo wyższą efektywnością niż realizowane metodami tradycyjnymi. Po prostu to co jest oczywistością, czyli bezpośrednie przekazywanie informacji zostało tam wbudowane w metodykę zamiast jak to proponuje wiele innych metod udawać, że da się lepiej komunikować przy użyciu narzędzi - głównie dokumentów tworzonych tonami w niektórych projektach.

Dobrze, więc skoro jest tak dobrze się komunikować bezpośrednio to skąd ograniczenie na wielkość zespołu? Jak to w życiu bywa wszystko w nadmiarze szkodzi. Utrzymywanie efektywnego zespołu polegającego na komunikacji interpersonalnej oznacza w skrócie, że członkowie zespołu muszą mieć możliwość swobodnego rozmawiania każdy z każdym i wymiany informacji. Problem w tym, że ilość kanałów komunikacyjnych w zespole rośnie wykładniczo w stosunku do liczby osób w tym zespole. I tak dla zespołu 5 osobowego mamy 10 kanałów komunikacyjnych, dla 8 osób kanałów jest 28, dla 10 osób 45, dla 12 osób 66 kanałów. I tu jest granica, której przekraczać nie należy. Przy 15 osobowym zespole jest już ponad 100 kanałów komunikacyjnych - ponad dwukrotny wzrost w stosunku do 10 osobowego zespołu. Czas poświęcony na dogadywanie się pomiędzy członkami zespołu zaczyna przewyższać wszelkie zyski z wykorzystania szybkich metod komunikacyjnych.

Do wszystkiego należy podchodzić w sposób zgodny z rosądkiem. Ostatnio słyszałem o przypadku firmy X, gdzie wdrożono zwinne zarządzanie projektami a zespoły "po optymalizacji" liczą 20 osób (190 kanałów komunikacyjnych w zespole). Wydaje mi się, że to będzie jeden z tych nielicznych przypadków, kiedy na koniec stwierdzone zostanie, że metody tradycyjne były lepsze. A może to nie stare metody były lepsze, tylko wprowadzenie nowych nieprofesjonalne?