IT Project
Zarządzanie organizacją i Projektami IT
Metodyka - parę nieoczywistych rzeczy
Właściwie dobrana metodyka do planowanego Projektu oraz konsekwentne (ale nie literalne) jej stosowanie, wydatnie pomaga zaoszczędzić czas, pieniądze, uniknąć chaosu i osiągnąć cele Projektu. Dlatego rzecz będzie o metodyce. Na co zwrócić uwagę, a czego nie znajdziecie w popularnych metodykach. Artykuł głównie dla osób odpowiadających za delivery.
Na początek małe uporządkowanie pojęć:
- Metodologia – nauka o metodach badań naukowych, ich skuteczności i wartości poznawczej (wiki).
- Metodyka – zbiór metod, ustandaryzowane dla wybranego obszaru podejście do rozwiązywania problemów. Metodyka abstrahuje od merytorycznego kontekstu danego obszaru, a skupia się na metodach realizacji zadań, szczególnie metodach zarządzania (wiki)
Piszę o tym, bo często spotykam się z zamiennym stosowaniem tych pojęć, co jest błędem. Po tym łatwo rozpoznać interpretatora metodyki od tego, który faktycznie wie o czym mówi.
Ale wracając do głównego tematu. Z perspektywy projektów IT, metodyka to sposób działania prowadzący do osiągniecia celów Projektu. Na rynku jest wiele metodyk. Z mojej perspektywy to co najistotniejsze, to to, że każda z nich podkreśla, że jest to przede wszystkim zestaw best practices, a nie gotowy przepis na realizację Projektu. Odpowiedzialnością PMa jest dobranie zestawu dobrych praktyk do konkretnego Projektu, aby mógł optymalnie zrealizować Projekt. Natomiast odpowiedzialnością organizacji w której pracuje jest dostarczenia mu wsparcia w postaci standardów, wzorców dokumentów oraz wyszkolonego w tych standardach zespołu. Jednak absolutnie nie oznacza to, że co Projekt to coś nowego, nowa metodyka, nowe metody pracy i jakaś rewolucja! Jak w każdej dziedzinie aktywności człowieka, trzeba myśleć realnie, optymalnie i być pozytywnie kreatywny w działaniu, aby z jednej strony nie stracić przyjętych w danej firmie standardów i metodyk i nie zaskakiwać zespołów projektowych ciągłymi zmianami, a z drugiej strony nie zgubić specyfiki danego Projektu.
Jeszcze jedna istotna uwaga. W niniejszym artykule chodzi przede wszystkim o aspekty związane z metodykami. Dlatego nie będę pisał o konieczności zdefiniowania celów, budżetów, harmonogramów dla Projektu, bo to są oczywiste rzeczy.
Na początku artykułu napisałem o "właściwym dobrania metodyki do planowanego Projektu". Głównie mam tu na myśli wzięcie pod uwagę takich aspektów jak:
- Klient - branża, stopień jego przygotowania do projektu, wew. uwarunkowania Klienta, jego faktycznych critical deadlines oraz czy dla niego dane rozwiązanie IT jest krytyczne, ma pracować w trybie ciągłym, czy nie itd.
- zakres Projektu - im większy tym więcej testów, im większa migracja lub liczba interfejsów tym większa konieczność powołania dedykowanych osób dla tych tematów, tym więcej uwagi na politykę, komunikację i synchronizację między zespołami,
- czas realizacji Projektu - im krótszy tym mniej "demokracji" w Projekcie, więcej (niestety) mikrozarządzania i odwrotnie
- wielkość zespołu projektowego - im większy zespół tym więcej procedur i zarządzania przez struktury projektowe, a mniej "Agile" (w tym złym znaczeniu tj. własnej fantazji i kreatywności w działaniu) na Projekcie
- doświadczenie zespołu projektowego - im większe tym bardziej wspieramy działania zespołu i bardziej nadajemy ton tym działaniom niż bezpośrednio zarządzamy zadaniami.
Reasumując. Nie chodzi o zmianę przyjętych standardów metodyki, ale o większe lub mniejsze rozbudowania jej elementów (z zastosowaniem best practices w tych tematach) na potrzeby konkretnego Projektu. Ktoś może powiedzieć, że powyższe punkty to banały, ale pokażcie mi ilu PMów tak naprawdę uwzględnia to w swoim działaniu?
Kontynuując rozważania. Z mojej perspektywy wydzielam dwa rodzaje metodyk stosowanych równocześnie w Projektach IT:
- Metodyka organizacji Projektu – czyli zestaw działań organizacyjnych pozwalających na bezpieczne, kontrolowane i optymalne zrealizowanie Projektu zgodnie z Umową. Ten rodzaj metodyk powinien wspierać zespoły projektowe w realizacji ich zadań oraz pozwalać na kontrolę Projektu i ocenę stanu Projektu, w każdym momencie jego trwania.
- Metodyka produktowa – czyli zestaw działań mających na celu przygotowanie i wdrożenie danego rozwiązania IT (np. wdrożenie D365, wdrożenie CRM itd.) zgodnie z zaleceniami Producenta i/lub doświadczeniem Dostawcy.
Ktoś zapyta, a po co takie rozróżnienie? Odpowiadam. Po to, aby metodyką organizacji Projektu zapewnić maksymalną standaryzacje realizacji Projektów i aby zespoły nie musiały się uczyć co Projekt nowych zachowań organizacyjnych w Projekcie (tzn. układu repozytoriów, zadań, procedur, rejestracji godzin itd.). Natomiast metodyką produktową należy zapewnić zakres informacji niezbędnych do wdrożenia konkretnego Produktu zgodnie z wymaganiami Klienta. Dzięki temu można tworzyć standardy metodyk organizacji, które uwzględniają standardy realizacji konkretnych Produktów. Przy tym podejściu można ten sam Produkt wdrożyć różnymi metodykami organizacyjnymi i odwrotnie, właściwie dobierając metodykę do planowanego Projektu oraz szukając optymalniejszych sposobów realizacji. Dlatego mam pewien dysonans jak metodyka produktowa próbuje ogarniać zagadnienia organizacji i odwrotnie, bo to nie służy, ani jedej ani drugie metodyce, a już tym bardziej Projektowi.
W dalszej części artykułu chciałbym skupić się na metodyce organizacji Projektu. Dlatego nie będę pisał o zarządzaniu zmianą, rejestrze ryzyka, problemów itd., bo to czytelnik wie albo może znaleźć w metodykach takich jak Prince2, PMBoK, DSDM czy innych. To co może być interesujące, to to, o czym nie wiele mówią te metodyki, a z perspektywy mojego doświadczenia jest istotnym ich uzupełnieniem:
- Otwarcie Projektu po stronie Dostawcy
Zwykle w metodyce nie uwzględnia się Fazy właściwego przygotowania Projektu po stronie Dostawcy, zanim oficjalnie ruszy Projekt u Klienta. Brak tej fazy zwykle prowadzi do uruchomienia Projektu w warunkach „partyzancki”, bez zweryfikowanego budżetu, celów, przygotowania własnego zespołu, dokonania formalności w księgowości, w kontrolingu itd., a co najgorsze bez transferu wiedzy między poprzedzającym Projektem, a tym uruchamianym (np. brakiem przekazania ustaleń formalnych wynikających z Umowy, ustaleń nieformalnych wynikających z relacji z Klientem, specyfiki realizacji Projektu)
Często osoby zarządzające po stronie Dostawcy twierdzą, że są to „drobiazgi”, które można uzupełniać w trakcie Projektu. Czyli innymi słowy, leć PMie z Projektem, a skrzydła dorobimy potem … 😊, no chyba że wcześniej się rozbijesz... no to będzie Twoja wina, że nie dość energicznie machałeś rękami (to tak pół żartem pół serio). A ja się pytam ile kosztuje to zamieszanie związane z brakiem powyższych działań potem na Projekcie? Ile kosztuje niezadowolenie Klienta, że na etapie np. presales przekazywał informację, a tu na Projekt przyszły osoby jakby z innej planety (ups…) i pytają o rzeczy jakby Dostawca pierwszy raz spotkał się z Klientem ? Od Klienta oczekuje się przygotowania do Projektu, ale od Dostawcy to już nie koniecznie?
Otwarcie Projektu to są koszty wew. Projektu. One zwracają się podczas realizacji Projektu , choćby w tym, że bardzo dużo informacji i pracy włożonej wcześniej może zostać wykorzystane podczas realizacji Projektu. Co w oczywisty sposób zmniejsza koszty realizacji Projektu. No i zwiększa zaufanie i zadowolenie Klienta, że jest słuchany i poważnie traktowany - to pewnie przede wszystkim.
- Zamknięcia Projektu
W praktyce, zwykle uwaga Dostawcy na Projekt kończy się z dniem wystawienia ostatniej faktury. Jednak takie podejście to strata tego co najcenniejsze dla rozwoju organizacji Dostawcy, czyli szansy na doskonalenie, ale też utrzymania „porządku w papierach”. Zamknięcie Projektu powinno być wyciagnięciem wniosków końcowych z Projektu, zgłoszeniem rekomendacji dla nowych Produktów, wskazaniem nowych Usług, wskazaniem zmian w metodyce i organizacji Dostawcy itd. Projekt nie powinien być wyłącznie źródłem przychodu, ale też powinien budować lepszą organizację i przyszłe, lepsze Projekty oraz portfolio rekomendacji dla Dostawcy. Na to musi się znaleźć czas i zasoby.
Zamkniecie Projektu to są koszty wew. Projektu związane z doskonaleniem organizacji Dostawcy , marketingiem oraz inwestycjami.
- System punktów podsumowujące działania w Projekcie
Metodyka powinna mieć zaszyte takie punkty w Projekcie, w których jest dokonywane podsumowanie z Klientem tego co udało się już zrealizować, co można i powinno być zmienione po obu Stron w Projekcie oraz przekazywane jest co będzie realizowane do kolejnego punktu kontrolnego. Takie podejście bardzo poprawia komunikację w Projekcie. Buduje partnerską relacje z Klientem na bazie wspólnie prowadzonych działań doskonalących w Projekcie. To są również miejsca na przemyślenie razem z Klientem i zmian w metodyce realizacji danego Projektu.
To są koszty Projektu, komunikacji i inwestycji w relacje z Klientem.
- System punktów kontrolingowych, audytów i improvementowych
Jeśli ustanowione zostały standardy i opisane zasady obowiązujące w Projekcie (tzw. zwykle opisane w dokumencie wew. Dostawcy Project Governance) to naturalne jest, aby okresowo sprawdzać czy są one przestrzegane i podejmowane działania naprawcze. Dlatego Projekty powinny podlegać okresowym audytom przez niezależnych audytorów pod kątem stanu Projektu, zgodności z Umową, przyjętymi standardami. Jednak głównym celem audytów jest utrzymanie jakości na Projektach i dotrzymania obietnicy danej Klientowi, że otrzyma to na co Strony się umówiły.
To samo dotyczy działań doskonalących. Można je zrealizować na koniec Projektu, ale w dużych Projektach powinny one być zsynchronizowane z punktami audytami oraz cyklicznymi spotkaniami z zarządem Dostawcy na bazie danych kontrolingowych (a obowiązkowo przed krytycznymi spotkaniami Komitetu Sterującego).
To są koszty jakości dostarczanej przez organizację Dostawcy.
- Marketing wokół realizowanego Projektu
W Polsce miałem przyjemność kilka razy spotkać się z tym w dużych Projektach. Na zachodzie to właściwie jakby standard. Z grubsza chodzi o to, że o toczącym się Projekcie, cała organizacja Klienta powinna być informowana cyklicznie np. raportem. Co udało się zrobić, gdzie jest projekt, co jest planowane w najbliższej przyszłości. To też dobry moment na podziękowania za zaangażowanie osobom po stronie Klienta i Dostawcy itd. takie dowartościowanie zespołu. Takie działanie przygotowuje organizację Klienta na D-day, czyli Start Produkcyjny. To też stała promocja i kreowanie wizerunku Projektu po stronie Klienta, a czasem i Dostawcy.
To zwykle nie są koszty Dostawcy, ale bardzo duży zysk Dostawcy związany z atmosferą wokół Projektu, która albo może pomagać albo szkodzić Projektowi, więc warto Klienta wesprzeć w tym działaniu.
- Właściwe zbieranie danych w Projekcie
Często jest tak, że koszt analizy, implementacji, testów oraz usuwania błędów (tzw. BUG) czy to konfiguracji, modyfikacji interfejsu itd. są wrzucone do swoich "worka" kosztów (sumarycznie i oddzielnie). Takie podejście zamazuje obraz gdzie tak naprawdę poszło najwięcej energii podczas realizacji Projektu, na co należałoby zwrócić szczególną uwagę i od razu reagować, jaka była historia zmian itd. Zilustruję to na przykładzie Modyfikacji. Analiza Modyfikacji była żywiołowa i krótka, a koszt mały. Potem implementacja szybka, a koszt mniej więcej zakładany po analizie, przyszło do testów i wychodzi, że jest dużo błędów nawrotów i poprawek i znów testów. Nie przemyślana i niedotestowana Modyfikacja, potem narobiła "bałaganu" na systemie produkcyjnym lub kolejny upgrade systemu "zaciął się" na niej i trzeba było ją poprawić. Pytanie jaki jest koszt tej Modyfikacji? Nie do ustalenia jeśli patrzymy z punktu widzenia "worków" kosztów (analizy, implementacji, testów itd.). Niestety na Projekcie musi być mechanizm zbierania tych kosztów pod jedną Modyfikacją. Brak takiego systemu to też brak informacji zwrotnej do optymalizacji kosztów, doskonalenia i dalej systemu motywacyjnego (tak, jego, bo przecież liczba błedów, testów oraz jak potem pracuje Modyfikacja jest funkcją dobrze wykonanej pracy konsultanta i developera oraz nadzorującego ich Architekta). No i jest to też kłopot potem dla serwisu, który powinien znać "historię choroby", aby kontynuować prace i wiedzieć na co szczególnie zwrócić uwagę.
Na pierwszy rzut oka wydaje się, że powyższe punkty są na wyrost i jest tego dużo (by nie powiedzieć za dużo), ale zawsze przypominam, że róbmy wszystko z głową i wyczuciem. Należy dostosować powyższe tematy do wielkości Projektu i jego potrzeb. To co mogę z pewnością powiedzieć, to to, że im większy i bardziej złożony Projekt tym, te punkty stają się ważniejsze.
W systemie zarządzania IMS4POs powyższe aspekty zostały uwzględnione. Osobną kwestią jest, czy i jak będą użyte w danym Projekcie, co z tego trafi jako standard dostawcy, a co będzie do decyzji PMa, czy będzie wykorzysta w swoim Projekcie.
Zapraszam do współpracy.
Ostatnie wpisy
Zaproszenie
Jeśli interesuje Ciebie jakaś tematyka, która warta jest opisania w blogu lub chciałbyś się podzielić własnym tekstem lub przemyśleniami, proszę skontaktuj się ze mną, prześlij propozycję teksu. Ten blog może być forum wymiany myśli na temat zarządzania organizacją, czy też Projektem IT.
Zaproszenie
Jeśli interesuje Ciebie jakaś tematyka, która warta jest opisania w blogu lub chciałbyś się podzielić własnym tekstem lub przemyśleniami, proszę skontaktuj się ze mną, prześlij propozycję teksu. Ten blog może być forum wymiany myśli na temat zarządzania organizacją, czy też Projektem IT.