Temat nieudanych wdrożeń wraca jak bumerang, regularnie pojawiają się artykuły w prasie, wnioski, a kolejne projekty powielają te same błędy. Czy może chodzi o to, by te projekty były takie złe?

W jednym z poprzednich wpisów na podobny temat (Policja znów ma …) napisałem:

Hegel napisał kiedyś, że “historia uczy ludzi, że historia niczego ludzi nie nauczyła”. Lubię tę sentencję bo jest prawdziwa, codziennie obserwuję coś co ją potwierdza. Jak nazwać firmy i urzędy, które wiedzę, że nie mają żadnych kompetencji do analizy wymagań i stale to jednak robią? Jak nazwać firmy, które z uporem maniaka składają wiążące oferty na podstawie tak źle opisanych wymagań? Jak nazwać kierowników projektów IT tych firm i urzędów, którzy jedyne co robią to wliczają każdy zły projekt w statystykę ryzyka, zamiast po prostu w końcu zmienić metodę pracy na lepszą, skoro dotychczasowe są złe – co widać?

Wczoraj miałem referat na konferencji o wdrożeniach systemów ERP, po mnie miał referat Pan Kowalczyk z firmy Mandarine. Wygłosił bardzo ciekawy referat na temat zarządzania projektami ([[zarządzanie projektami metodą ścieżki krytycznej]]). Nie licząc prezentowanego opisu metod zarządzania projektami (polecam ;)), wskazał na coś bardzo ważnego: wymagań (etapów projektu) powinna być rozsądna – relatywnie mała – ilość (nie da się zarządzać tysiącami wymagań) oraz, każda praca powinna być poprzedzana jej planowaniem. Nic dodać nic ująć. Ja w swoim referacie mówiłem, że planowanie to także projektowanie poprzedzające pracę (zanim zaczniesz programować, zaplanuj co zaprogramujesz – projektuj). W przeciwnym wypadku, pojawia się w projekcie coś dziwnego jako zadanie:  realizacja czegoś, o czym nie wiemy czym ma być (bo przecież nie ma projektu).

Kolejny problematyczny etap, konsekwencja braku projektu, a wcześniej dobrze określonych wymagań,  to odbiór produktu. Jeżeli wymagania nie stanowią zarazem testu ich spełnienia (znowu przypomnę, że słowo wymaganie oznacza warunek lub warunki jakie musi coś spełniać, by było przydatne do określonego celu), to odbiór produktu projektu staje  czymś dziwnym. W toku dyskusji o tym na pewnym forum napisałem:

Wydaje mi się, sedno tkwi w tym stwierdzeniu: “rzecz, na którą staram się zwrócić uwagę to fakt, iż akceptacja odbioru niekoniecznie jest tożsama z udanym wdrożeniem w skali całego przedsiębiorstwa.” [słowa przedmówcy, przyp. mój]. Bo tu pojawia się “co jest wymaganiem”, czyim wymaganiem i wymaganiem wobec czego. Wymaganie “koszty obsługi sprzedaży mają spać do poziomu 10%” rodzi dopiero potrzebę zaprojektowania rozwiązania. Tym rozwiązaniem może być uproszczenie organizacji procesu fakturowania albo zakup narzędzia do fakturowania (zamiast druczków i kalkulatora, komputer i program). Na tym etapie należy sprawdzić, które rozwiązanie daje największe szanse powodzenia realizacji celu. Poważnym błędem wielu zarządzających i sponsorów projektów, jest zakładanie a priori, że oprogramowanie pomaga.

Jeżeli jednak okaże (analiza) się, że zakup programu ma pomóc, to należy opisać wymagania jakie taki program musi spełnić (wymagania wobec produktu). Te wymagania są podstawą do wyboru gotowego, dostępnego na rynku oprogramowania, lub decyzji o napisaniu dedykowanego, jeżeli poszukiwania nie dadzą pozytywnego rezultatu (ale etap szukania gotowego powinien dla zasady mieć miejsce). Dedykowane rozwiązanie wymaga jego zaprojektowania, to można (zalecane) zrobić przed wyborem wykonawcy lub zlecić wybranemu wcześniej wykonawcy. Wariant drugi naraża nas jednak na utratę panowania nad projektem bo wykonawca będzie forsował metody budujące mu marże a potem sam sobie świadczy nadzór autorski. Wbrew pozorom, angażowanie audytora projektu, który nie jest autorem dokumentacji wymagań nie wnosi nic, a komplikuje cały proces: taki audytor może jedynie ocenić zgodność działań projektowych z dokumentacją wytworzoną przez  (audytowanego) wykonawcę, a w przypadku sporu i tak tu “władzę” ma autor projektu a nie audytor.

I teraz: ogłoszenie przetargu na całość na początku tej drogi jest jak widać idiotyzmem bo nie mamy żadnej wiedzy by ocenić wynik pracy a dostawca żadnej by cokolwiek sensownie wyceniać. Pominięcie jakiegokolwiek z tych w/w opisanych etapów to podnoszenie ryzyka projektu, co mam na dzieję widać. Każde wymaganie może być zero jedynkowe na każdym z tych etapów, wystarczy chcieć i umieć. Owszem, można je dzielić na biznesowe itp… ale to tylko sztuczne podziały, po prostu podczas realizacji mamy już tylko etap i jego wymagania. (Nieudane wdrożenie systemu biznesowego – czyli uczmy się na błędach innych | LinkedIn).

I tylko tu pojawia się pytanie jak w filmie MIŚ: a może to faktycznie ma być drogie i nieprzydatne a ja zupełnie bez sensu jestem tym zdziwiony?