Źle zdefiniowany projekt IT

Źle zdefiniowany projekt IT to zmora PM-ów i zespołów projektowych. Dzisiaj przyjrzymy się 5 najczęściej spotykanym błędom, które są utrapieniem kierowników projektu, skutecznie przeszkadzając im w efektywnym wykonywaniu ich pracy.

Źle zrozumiany projekt

Jest to klasyczny problem z projektami, na który lekarstwem miały być metodyki zwinne, ale nie uprzedzajmy.

Na poniższym obrazku (niestety autor nieznany, a obrazek jest kolejną kopią samego siebie w odmętach Internetu) w humorystyczny sposób zostały zobrazowane wszystkie ważniejsze problemy w definicji projektu, a właściwie produktów, które projekt powinien dostarczyć. Większość z tych problemów powinien nam rozwiązać Analityk Biznesowy lub zwinna metodyka zarządzania projektami (jeśli jest możliwa do wdrożenia, ale o tym w jednym z kolejnych artykułów). Oczywiście „powinna” nie jest jednoznaczne z „rzeczywiście rozwiąże”.

Niestety nie da się systemowo rozwiązać wszystkich problemów wynikających ze złego zrozumienia potrzeb i wynikającego z nich błędnego opisania produktów. Nawet najlepszy Analityk Biznesowy, nie zdefiniuje właściwie produktu, którego nie potrafi opisać Klient, nieświadom sowich potrzeb. Żadna metodyka nie uchroni nas przed brakiem testów i refleksji na kolejną wersją produktu. Możemy tylko dołożyć wszystkich starań by zminimalizować ten problem, odpowiednio definiując i przypisując właściwe role w projekcie, a w szczególności Kierownika Projektu i Analityka Biznesowego, którzy mają umocowanie wystarczające do wymuszenia zmian w definicji produktów i założeń projektowych.

Projektem ustanowiono powtarzalny proces

Wydawałoby się, że to sprawa marginalna, tymczasem w branży nagminnie projektem ustanawia się powtarzalną inicjatywę, która w firmie o profilu nieinformatycznym byłaby codziennym procesem produkcyjnym (dostarczenie kolejnego produktu). Typowe przykłady takiego nieporozumienia to: dostarczenie serwerów lub maszyn wirtualnych na konkretne potrzeby, wytworzenie fragmentu oprogramowania, który służy typowym celom, takim jak kolejny front-end, czy obsługa kont użytkowników, monitoring bezpieczeństwa i patchowanie oraz aktualizacja wersji systemów.

Procesy powtarzalne nie udają się jako projekty, ponieważ zwykle nigdy się nie kończą definitywnie (wymagany jest cykliczny „maintenance”), potrafią angażować wiele osób, zwykle zależnych od siebie w ściśle określonej kolejności, na stosunkowo krótki czas, co wymusza przesadne rozbudowanie zespołu projektowego o osoby, które są w nim alokowane na niewielki okres czasu (o tym, jakie to rodzi problemy, napiszemy w jednym z kolejnych artykułów).

Dość szybko uświadamiamy sobie, że mamy przed sobą kandydata na produkcję, a nie projekt, gdy spróbujemy przygotować dla niego Uzasadnienie Biznesowe – nasz analityk utknie na RoI, za to bardzo dobrze rozpisze ryzyko, które nie da się minimalizować inaczej niż przez procedury standaryzujące powtarzalność pewnego procesu.

W takich przypadkach zamiast ustanawiać projekt, powinniśmy zastanowić się raczej nad zespołem utrzymującym produkt, może DevOps lub podobne rozwiązanie zależnie od potrzeb i możliwości.

Inicjatywa jest zbyt mała na projekt

Wydawałoby się, że projekt nie może się nie udać, bo jest zbyt mały, tymczasem w praktyce dzieje się tak nader często.

Zbyt mała inicjatywa oznacza, że zespół projektowy będzie chwilową zbieraniną specjalistów, którzy nie będą mieli czasu, ani ochoty, na współpracę, ponieważ ich czasowe zaangażowanie w projekt będzie niewielkie. Z tego względu będą oni taki projekt odbierać raczej jako zaburzenie ich codziennej pracy, niechciane zadania dodatkowe zwykle powodujące irytację. Osoby zaangażowane nigdy nie staną się w pełni zespołem projektowym, nie będą dość zmotywowane do pracy nad powierzonymi zadaniami. Co więcej zwykle organizacja będzie im przeszkadzać w pracy przy tym mini projekcie, obarczając zadaniami o wyższych priorytetach.

Jeśli również Kierownik Projektu, będzie tylko częściowo zaalokowany w tym temacie, mamy gotową receptę na porażkę.

Aby zapobiec takim sytuacjom, możemy próbować poniższych rozwiązań:
– grupować inicjatywy, powiązane ze sobą w spójną całość, którą można zarządzać jako projektem,
– stworzyć lub wynająć zespół dedykowany do takich zadań, wraz z osobą odpowiedzialną za koordynację jego prac i właściwą współpracę z naszą organizacją.

Jeśli żadne z powyższych nie jest możliwe do realizacji, powinniśmy przynajmniej zadbać o rolę kierowniczą (np. Kierownika Projektu), która będzie w stanie odpowiednio zarządzić wszystkim wspomnianymi problemami. Dość często takie inicjatywy występują okresowo, wymagają odpowiedniej wiedzy i zaangażowania, optymalnym wydaje się krótkoterminowe zakontraktowanie takiej roli i tu idealnym rozwiązaniem wydaje się usługa PMaaS.

To jest program, nie projekt

Z mojego doświadczenia wynika, że równie często projektami ustanawia się inicjatywy zbyt małe, jak i zbyt duże. Im dłużej projekt trwa, tym więcej pojawia się zmiennych, które w konsekwencji prowadzą do któregoś z powodów, dla których projekty IT kończą się niepowodzeniem. Twórcy metodyk zarządzania projektami doskonale zdawali sobie z tego sprawę i przygotowali rozwiązania systemowe w postaci programów.

Zamiast powoływać jeden wielki projekt i narazić się na problemy wynikające z jego skomplikowania i wypływu zmieniającego się środowiska wewnątrz oraz na zewnątrz firmy, lepiej (czyli bezpieczniej i efektywniej) jest ustanowić jeden program, w ramach którego będzie realizowanych kilka mniejszych projektów mniej lub bardziej zależnych od siebie.

Niestety praktyka pokazuje, że programy stały się pewną patologią i obserwowana jest praktyka zupełnie odwrotna: projekty grupuje się w programy, żeby łatwiej było je raportować, zupełnie pomijając powyższe korzyści, a generując kolejne problemy takim podejściem.

Po czym poznać, że nasz projekt powinien być programem? Oto kilka takich symptomów:
– zagadnienie jest zbyt duże, by dało się efektywnie zarządzać przez jedną osobę,
– oszacowany czas trwania jest tak długi, że nie jesteśmy w stanie ocenić, jak w chwili dostarczenia ostatnich produktów będzie wyglądała nasza firma lub środowisko zewnętrzne (rynek),
– nie jesteśmy w stanie zdefiniować wszystkich podstawowych produktów,
– rejestr ryzyka jest dłuższy niż uzasadnienie biznesowe i spis założeń razem wziętych.

Oczywiście metodyki takie jak PMI mówią o tym, że projekt trwa około dwóch lat, zespól stanowi około 200 osób, itd. Owszem, ale ile projektów IT zakończyło się sukcesem (w terminie i zgodnie z budżetem) będąc zarządzanych zgodnie z tą metodyką?

Dostaliśmy kota w worku

Ostatnia grupa źle definiowanych projektów, nad którą chcemy się jeszcze pochylić, to projekty, w których jest więcej niewiadomych niż założeń.

Niestety, często bywa tak, że Kierownik Projektu dostaje „gotowca”, czyli handlowcy coś sprzedali, Zarząd klepnął i wybrał „biedaka”, który teraz to „dowiezie”. Problem polega na tym, że nikt nie napisał Uzasadnienia Biznesowego, wymagania klienta to lista losowo wybranych życzeń bez żadnych kryteriów, a tzw. „szczegóły techniczne” ustali Zespół Projektowy, w trakcie trwania rzeczonego projektu.

Mógłby ktoś powiedzieć, że to przerysowany nierealny przykład, ale niestety i tak mi się w karierze zdarzało. Powyższy przykład odnosi się do klientów zewnętrznych i był (i chyba dalej jest) usankcjonowaną patologią w jednej znanej mi firmie (i prawdopodobnie innych mi nieznanych). Podobnych przykładów dotyczących klientów wewnętrznych znamy jeszcze więcej i zdarzyły się praktycznie w każdej firmie.

Czasem inicjatywy tak ustanowienie („mamy taki a taki budżet, zróbmy coś fajnego”) przynoszą niespodziewane efekty, ale zwykle są totalnym fiaskiem, które jest „zamiatane pod dywan” na setki różnych sposobów.

Remedium jest bardzo proste i zdawało by się oczywiste: zanim projekt zostanie formalnie powołany, należy przygotować i ocenić jego Uzasadnienie Biznesowe, o czym już w kolejnym artykule.

Przemek Jarocki

Project Manager w HOSTERSI

Pytania? Skontaktuj się z nami

Zobacz również:

Czy projekt IT może skończyć się sukcesem?

Wysoka dostępność serwisu. Jak ją ustalić i wyliczyć?

Chmura obliczeniowa nie taka straszna. Wprowadzenie do Amazon Web Services

Wsparcie DevOps – dlaczego jest mi potrzebne?

Czy warto zatrudniać własnego administratora?