Cześć, dzień dobry. Witam was w podcastzie IT i Biznes. Nazywam się Grzegorz Tabor i na co dzień prowadzę trzy firmy, w tym firmę programistyczną, agencję doradczo-rekrutacyjną i SaaS do monitoringu cen konkurencji dla e-commerce.Podcast IT i Biznes kieruję do właścicieli firm oraz menedżerów, którzy na co dzień współpracują w swoich firmach często i dużo z szeroko pojętym IT i chcieliby realizować owe projekty IT bardziej świadomie i skuteczniej. Odcinek 48. Czarne łabędzie.

Co mają wspólnego z dużymi projektami IT i jak nie stać się jednym z nich? Ponad połowa realizowanych projektów przekracza budżet średnio o 46%. W tym odcinku przyglądamy się zjawisku czarnych łabędzi w projektach IT, mającym ogromny wpływ na sukces całych przedsięwzięć. Jakie kroki warto podjąć, aby zminimalizować ryzyko niepowodzeń? Poznasz cztery kluczowe strategie, jak ograniczyć ryzyko już na samym początku oraz jedną super ważną zasadę, jak podejść do dużych projektów IT, by zwiększyć szansę na powodzenie.

Nie przedłużając, serdecznie zapraszam do części głównej dzisiejszego odcinka. Cześć, dzień dobry. Jeśli myślisz, że programowanie to tylko kod, technologia i frameworki, to dziś cię trochę zaskoczę, bo dzisiaj pogadamy przewrotnie o czarnych łabędziach.

I nie, nie chodzi mi tu ani o perę, ani o ptaki, tylko o zjawiska, które potrafią wywrócić projekt IT do góry nogami. Zastanowimy się, co czarne łabędzie mają wspólnego z projektami technologicznymi i co ważniejsze, dlaczego nie chcesz mieć z nimi do czynienia. No i na początek może wyjaśnimy sobie w ogóle, czym są te czarne łabędzie.

Teorię czarnego łabędzia stworzył filozof Nassim Nicholas Taleb. Opisuje ona rzadkie, nieprzewidywalne zdarzenia o ogromnym wpływie. I chociaż ta koncepcja dotyczy wielu dziedzin, od finansów po historię, to w projektach IT najczęściej pojawia się w kontekście, no właśnie, porażki.

I to nie jest tylko taka akademicka teoria, bo im bardziej technologia staje się kluczowym elementem przewagi konkurencyjnej, a dziś, tak szczerze, to już dotyczy niemal każdej branży, to tym większe są konsekwencje błędów, opóźnień, czy po prostu źle zaplanowanych projektów IT. I żeby tutaj nie być gołosłownym, spójrzmy na jedno z ciekawszych badań, które w ostatnim czasie wpadło do naszej weryfikacji w Innovation. McKinsey wspólnie z Uniwersytetem Oksforskim przeanalizowali setki dużych projektów informatycznych.

Jakie były wyniki? Takie trzy najważniejsze. Ponad połowa projektów IT przekroczyła budżet średnio aż o 45%, przeciętnie opóźniły się te projekty o 7% i, co jest super istotne, dostarczyły te projekty aż o 56% mniej zakładanej wartości. Czyli, tak w dużym uproszczeniu, każdy projekt przekroczył budżet średnio prawie o połowę, opóźnił się stosunkowo niedużo, ale zakres tego projektu był aż o połowę mniej większy niż był zakładany.

Czyli każdy dodatkowy rok trwania projektu zwiększał jego koszty średnio o około 15%. Czyli im bardziej przeciągasz wdrożenia w czasie, tym szybciej topnieje Twój budżet, tym szybciej topnieje Twoja cierpliwość. No i umówmy się, także zaufanie zespołu, no bo zespół już nie dowierza w to, że faktycznie dany projekt zostanie ukończony, jeżeli wdrożenie się przeciąga, przeciąga o kolejne miesiące.

No i OK, skąd się biorą te czarne łabędzie? Mam tutaj kilka obserwacji, którymi chciałbym się dzisiaj z Wami podzielić, a na koniec wrócimy sobie jeszcze do tego badania, o którym wspomniałem, bo uważam, że ono też przynosi ważne wnioski, no i jednak jest to badanie, więc możemy się odwołać już do konkretów na jakiejś określonej próbce danych. Jaki jest najczęstszy błąd? Jak myślicie? Myślę, że przede wszystkim to, że podchodzimy do tworzenia oprogramowania jak do rewolucji, a nie jak do ewolucji, bo bardzo często chcemy stare zamienić na nowe. Chcemy wdrożyć jakieś usprawnienie nie do końca do procesu, który jeszcze nie do końca został zdefiniowany.

Chcemy wdrożyć automatyzację i jaja w miejscach, gdzie niekoniecznie one w ogóle pasują albo są potrzebne, albo gdzie zwrot tej inwestycji będzie na tyle duży, że warto to po prostu zrobić. I zamiast planować rozwój systemów krok po kroku, bardzo często chcemy wszystko naraz. Kiedy zastanawiamy się nad priorytetami zadań, to bardzo często okazuje się, że nie potrafimy wybrać czegoś o najważniejszym priorytecie, bo nagle okazuje się, że kiedy zaczynamy robić priorytetyzację, to wszystko jest najważniejsze.

No i wtedy dochodzimy do sytuacji, w której mamy wielką implementację, która ma rozwiązać wszystkie problemy albo większość problemów i trochę też oczekujemy, że zmieni ona biznes w cudzysłowie z dnia na dzień. Tylko, że to tak nie działa. No bo zamiast tego, żeby gdzieś tam wszystko dawać na najwyższy priorytet, warto sobie zmapować, co naprawdę ma się zadziać w firmie.

Stworzyć sobie taką realistyczną roadmapę, nie tylko w formie wizji w PowerPoint, ale też po prostu w ramach właśnie roadmapy podzielonej na określone etapy i podzielić projekt na mniejsze, łatwiejsze do zarządzania właśnie etapy. Takie, które będzie można elastycznie wdrażać i co najważniejsze, modyfikować, jeśli zajdzie taka potrzeba. Bo jak idziesz drogą wielkiej zmiany, to popatrz, co się dzieje.

Przyjmijmy, że zaczynając projekt startujesz od miejsca takiego punktu zero. W tym miejscu masz wizję, jak coś powinno wyglądać, działać i funkcjonować bądź mniej więcej wiesz, jaki problem chcesz rozwiązać. Ale często ta wizja jest jeszcze na papierze z myślą, że jak będziemy mieć system to zaczniemy działać według nowych zasad.

Czyli na przykład będziemy mieli lepszy proces, bardziej usprawniony. Tylko, że zanim ten system zostanie wdrożony mija na przykład pół roku albo i więcej. Bo projekty IT większe potrafią trwać od pół roku wzwyż tak naprawdę.

A czas w projektach IT bywa niestety największym wrogiem. Bo przez te sześć miesięcy wzwyż może się wydarzyć tak naprawdę wszystko. Twoja firma może zacząć rosnąć dynamiczniej niż zakładałaś no i z tego się trzeba cieszyć.

Ale to będzie wpływało na wdrażany projekt i te dotychczasowe założenia mogą przestać być aktualne. Może zmienić się rynek. Pojawi się inflacja, wojna czy pandemia.

Cokolwiek na co nie mamy tak naprawdę wpływu. Ale co będzie miało wpływ jako czynnik zewnętrzny na projekt, który jest wdrażany. Może też pojawić się coś, czego dziś zwyczajnie nie przewidujesz.

Jak na przykład AI, które w ciągu ostatnich kilku miesięcy potrafiło zmienić podejście do obsługi klienta, zarządzania danymi. Czy na przykład formę, w jakiej zaczynamy wyszukiwać dane w internecie. Czyli nowa technologia, z którą trzeba się z nas znajomić i którą też trzeba w swojej strategii IT uwzględnić w odpowiednim miejscu.

I co wtedy, kiedy jedna z tych trzech rzeczy się wydarzy? Projekt, który miał odpowiadać na twoje potrzeby, nagle zwyczajnie może ich nie spełniać. Albo nie być wystarczająco dobry, żeby zapewnić ci przewagę konkurencyjną. A ty już będziesz w tym projekcie głęboko, bez marginesu na zmiany.

I to będzie właśnie błędne. I to właśnie jest prosta droga do tytułowego czarnego łabędzia. Do sytuacji, w której wszystko działa na zasadzie albo wszystko, albo nic.

Wracając do badania, o którym wspomniałem na początku tego odcinka. Też trochę, aby o wnioski, które przedstawię opierały się nie tylko na moich wewnętrznych odczuciach i obserwacjach, ale też przede wszystkim na danych. Jeśli jesteś w komfortowej sytuacji i masz możliwość traktowania kosztów projektu jako inwestycji.

Czyli to jest coś dodatkowego, bez czego twoja firma przeżyje. I nawet jeżeli pojawi się porażka, to ona zaboli. Ale firma to przetrwa.

No to powiedzmy, że w porządku. W sensie ryzyko jest o tyle mniejsze. Ale niestety nie każdy ma ten komfort.

I jak wynika z tego przetoczonego badania. Aż 17% projektów informatycznych kończy się tak źle, że może zagrozić istnieniu całej firmy. Czyli prawie co piąty projekt informatyczny, który kończy się źle, może zagrozić istnienie całej firmy.

I właśnie te nieprzewidziane zdarzenia o dużym wpływie to są te nasze czarne łabędzia. I duże projekty, które stają się czarnymi łabędziami to często te, gdzie przekroczenie budżetu wynosi ponad 200%. Więc pytanie brzmi, jak zarządzać projektami, żeby nie wylądować w tych 17%, które mogłyby zagrozić naszej firmie.

I wracając do wniosków z tego badania, bo będziemy się do tego tutaj w tym odcinku cały czas odwoływać, co jest szalnie ważne, pojawia się czteroelementowa strategia dla dużych projektów IT. I to już będą rzeczy, które my faktycznie wdrażamy również u naszych klientów. Co bardzo fajnie się pokrywa z tym właśnie badaniem.

Pierwsza sprawa. Zarządzanie strategią nie tylko budżetem i harmonogramem projektu. To podejście do współpracy, które stosujemy odbiega od tego, co się zazwyczaj spotyka na rynku.

Zanim w ogóle zaczniemy rozmawiać o tym, co byśmy zrobili, na jakich technologiach i za ile, najpierw się poznajemy. Brzmi prosto, może nawet banalnie, ale dla nas i naszym zdaniem to absolutnie kluczowy moment. I nie chodzi tu o szybkie spotkanie na Google Meet się czy na Teams się, gdzie każdy powie sobie cześć i poleci dalej.

My zazwyczaj po prostu przyjeżdżamy do ciebie i na żywo poznajemy twoją firmę. Serio. Chcemy zobaczyć, jak działa twoja firma, jak wygląda jej struktura, kto za co odpowiada.

Rozmawiamy też z osobami, które w takim standardowym procesie decyzyjnym czy na przykład w analizie przedwdrożeniowej dotyczącej tego jednego konkretnego projektu, pewnie by się nie pojawiły. A często to właśnie te osoby mają najwięcej do powiedzenia, również jako użytkownicy końcowi aplikacji, które są dla ciebie wdrażane. Bo to te aplikacje i ci użytkownicy na co dzień pracują z procesami, które technologia ma później wspierać albo zmienić.

A po co to wszystko? No i tu może cię to zaskoczy, ale właśnie wtedy najczęściej okazuje się, że projekt, z którym do nas przychodzisz, wcale nie musi wyglądać tak, jak sobie go wyobrażałeś. I to jest okej, bo często po prostu brakuje tego przełożenia z celów biznesowych na konkretne rozwiązania technologiczne, ale w tej kolejności. I właśnie na tym etapie, przy kawie, tablicy i kilku pytaniach, robimy to po to, żeby wyciągnąć z tego to, co naprawdę ma znaczenie, co faktycznie będzie wspierać twój biznes.

I dzięki tego typu sytuacji, gdzie spotykamy się na żywo, jesteśmy w stanie na początek spojrzeć na wszystkie istniejące w twojej firmie systemy, procesy, ale przede wszystkim też cele z lotu ptaka i zaprojektować taką architekturę, jeżeli chodzi o twoje systemy IT, i taką road mapę, jeżeli chodzi o projekty, że dzięki temu i dobrze podzielić je na etapy i trafnie je zaadresować względem twoich celów biznesowych i wtedy dopiero skupić się na pojedynczych projektach, czyli takich etapach i te konkretne projekty, etapy zapinać w budżet i w termin. Wtedy ma to pełną po prostu całość względem tego, czego twoja organizacja potrzebuje, a nie tylko takie punktowe uszczypnięcie czy naciśnięcie na coś, co w danej chwili najbardziej zabolało, ale niekoniecznie będzie miało największe przełożenie na twój biznes w danym momencie. Druga sprawa, zewnętrzne spojrzenie i kluczowe talenty.

Opanowanie technologii i treści projektu to jedno, ale żeby naprawdę to miało sens, potrzebujesz do tego odpowiednich ludzi z odpowiednimi kompetencjami, zarówno wewnątrz twojej firmy, jak i na zewnątrz. I tu od razu zapraszam cię do poprzedniego odcinka podcastu, czyli numer 47, bo właśnie tam mówiłem o tym, dlaczego nie warto zamykać się w swojej bańce. Serio.

Czasem rozmowa z kimś z zewnątrz, na przykład z doświadczonym CTO czy z analitykiem biznesowym, ale z zewnątrz może kompletnie zmienić twój kierunek myślenia, oczywiście na korzyść. I dlaczego to takie ważne? Może się okazać, że ty albo twój zespół nie widzicie prostszego, tańszego albo po prostu lepszego rozwiązania. I to nie dlatego, że coś robicie źle, tylko po prostu jeżeli ciągle jesteście we własnym podwórku, czy jesteście w swoim sosie, jak to się mówi, to łatwo wpaść w pułapkę idealnego projektu.

Wszystko musi być dopięte na ostatni guzik, każdy szczegół dopracowany, nawet jeśli finalnie dana funkcja będzie używana w 1% przypadków. I tu zwyczajnie w świecie możecie po prostu nie zauważać innych rozwiązań, będąc cały czas w swojej bańce. Tylko tyle, aż tyle.

Super ważna sprawa. Trzeci aspekt. Budowanie efektywnych zespołów.

I ten aspekt to nie tylko kwestia doboru kompetencji technicznych, ale też dostosowania motywacji ludzi do tego, co chcę osiągnąć jako całość w projekcie. I to jest temat, który widzę coraz częściej. I też mam wrażenie, że sama branża zaczyna go weryfikować.

Chodzi o to, że programiści i ogólnie ludzie techniczni coraz częściej muszą otwierać się na te bardziej miękkie biznesowe tematy. No i uważam, że dobrze, bo dzisiaj już nie wystarczy, że ktoś potrafi przełożyć wymagania biznesowe na kod 1 do 1. Jasne, to jest oczywiście ważne, ale równie ważne jest to, żeby ta osoba, która te wymagania przekłada rozumiała przede wszystkim, dlaczego coś robimy, jaki ma to cel biznesowy i czy przypadkiem nie da się tego zrobić inaczej, prościej czy też lepiej. I kompetencje miękkie to w ogóle dziś jedna z najbardziej poszukiwanych rzeczy, bo ich się nie da nauczyć z tutoriala na YouTubie.

To jest już pewna cecha osobowości, którą oczywiście można rozwijać, ale jest to na pewno trudniejsze niż zdobycie kompetencji twardych, przynajmniej moim zdaniem. I to właśnie w zespole robi ogromną różnicę, bo kiedy ktoś potrafi nie tylko napisać kod, ale też zakwestionować pewne założenia, wejść w rozmowę, dopytać, czy to na pewno ma sens i myśleć o tym z perspektywy biznesowej, to wtedy faktycznie spełnia się technologią te cele biznesowe, po prostu. I to nie po to, żeby robić podgórkę, te pytania i dopytywanie, czy to ma sens, tylko po to, żeby dowieść coś, co naprawdę będzie działało i co będzie miało faktycznie wartość przekładającą się na korzyść dla Twojego biznesu.

I ostatnia, ale naprawdę bardzo ważna kwestia, to strategia to nie tylko dobra opieka na starcie projektu, ale też przede wszystkim odpowiedzialność za to, jak kończymy projekt, czyli krótkie cykle dostaw i porządna, rygorystyczna kontrola jakości. I tu wracamy do tego, o czym wspominałem na początku. Nie czekamy z wszystkim do samego końca, tylko rozbijamy nawet już projekt w ramach całej roadmapy i strategii na mniejsze etapy, które systematycznie są dowożone i weryfikowane zarówno po naszej stronie, jak i stronie klienta, w jaki sposób to działa i czy działa dobrze.

Tak, żeby na bieżąco potwierdzać sobie, że zarówno kierunek, w jakim idziemy, cały czas jest słuszny i zgodny z tym, jak wygląda w danym chwili Twoja firma, ale po drugie też dlatego, żeby zwyczajnie świecie weryfikować jakość. Jakość to jest w ogóle temat rzeka. Zresztą w ogóle nagrałem o tym cały odcinek, więc jeżeli nie słuchałeś bądź nie słuchałaś, to serdecznie Cię zapraszam.

Odcinek 43. Tam opowiadam m.in. o testach, o tym, co leży po Twojej stronie jako osoby zlecającej projekt, a co powinien ogarniać zespół, czy to Twój wewnętrzny, czy software house. Więc jako rozszerzenie tego obecnego odcinka serdecznie Cię zapraszam również do odcinka 43, gdzie o tych odpowiedzialnościach opowiadam trochę więcej.

I podsumowując dzisiejszy odcinek, mam nadzieję, że nie przestraszyłem Cię ani nie zniechęciłem Cię do rozpoczęcia nowego projektu IT, bo absolutnie nie to było moim celem. To nie jest tak, że nie mamy wpływu na to, które projekty zakończą się sukcesem, a które staną się tym tytułowym czarnym łabędziem. Owszem, jest mnóstwo zmiennych, które mogą wpłynąć na końcowy rezultat, ale odpowiednie przygotowanie i podejście minimalistyczne minimalizują ryzyko i dają Ci większą kontrolę.

A wracając do budżetu i harmonogramu, czy powinny być pomijane? Tu zdecydowanie nie, ale tu też pojawia się ważne pytanie. No bo jeśli wybierając firmę do realizacji projektu skupisz się tylko na najniższej cenie, to przede wszystkim zastanów się, dlaczego ta firma oferuje taką cenę. Dlaczego firma A wycenia projekt na określoną kwotę, a firma B proponuje coś za połowę tej ceny.

Może firma B nie uwzględnia wszystkich zmiennych i nie przewiduje potencjalnych trudności, które mogą pojawić się w trakcie realizacji. To jest bardzo istotne, bo właśnie dlatego wiele projektów nie kończy się w zakładanym budżecie. Po prostu przez to, że pewne rzeczy nie zostały przewidziane i w tym budżecie zwyczajnie w świecie uwzględnione.

A nawet jeśli dodatkowy koszt nie okaże się bolesny, to pamiętaj, że może to wpłynąć na końcową jakość i terminowość projektu. Kluczem do sukcesu w tym aspekcie i do tego, żeby projekt IT zakończył się z sukcesem jest balans, odpowiednia cena, dobra jakość, realistyczne założenia i odpowiedzialność na każdym etapie każdej ze stron biorących udział w tym projekcie. Mam nadzieję, że te wskazówki pomogą Ci podejść do nowego projektu IT z większym spokojem i pewnością, że wiesz na co zwrócić uwagę i wiesz jak minimalizować ryzyko.

Ale gdybyś chciał, bądź gdybyś chciała skonsultować swój projekt albo po prostu porozmawiać o nowym pomyśle, czy to biznesowym, czy pomyśle na jakieś usprawnienia, chętnie umówimy się na kawkę online lub na kawkę na żywo po to, żeby o tych potrzebach porozmawiać i doradzić jak można je rozwiązać. Dzięki bardzo za wysłuchanie dzisiejszego odcinka. Mam nadzieję, że żaden z Waszych projektów nie będzie w tych projektach, które określiliśmy tutaj mianem czarnego łabędzia i życzę Wam serdecznie udanego tygodnia.

Dzięki raz jeszcze za wysłuchanie odcinka i do usłyszenia za tydzień we wtorek. Cześć.