Klątwa optymizmu

projekt

Co łączy wciąż powstające lotnisko w Berlinie, najnowocześniejszy amerykański lotniskowiec atomowy Gerald Ford oraz każdy dedykowany projekt informatyczny? Przekroczony budżet i deadline. I najciekawsze, że przyczyny są we wszystkich przypadkach takie same. Nie pomoże amerykańska technologia, ani niemiecka perfekcyjna organizacja. Z takimi projektami po prostu tak jest. Pogódź się i spraw, by twój bufor bezpieczeństwa w planowaniu solidnie utył.

Klątwa optymizmu

Pierwszą z nich jest oparcie planu kosztów i harmonogramu o niepełne, lub zbyt optymistyczne założenia. Zabieramy się za robienie czegoś, czego nie mamy możliwości przewidzieć/zaplanować w każdym szczególe, więc planujemy na podstawie niepełnych danych. Ot, rozpoczęliśmy sobie projekt w nadziei, że te drobne szczególiki, które będziemy ustalać zajmą dokładnie tyle czasu ile myślimy. Błąd, zajmą na pewno więcej i zjedzą więcej zasobów niż zakładasz. Zwyczajnie dlatego, że odkładając ich zdefiniowanie na później, odkładasz także uświadomienie sobie ile ich właściwie jest. Podświadomie mamy też tendencję do zakładania, że te przyszłe decyzje o szczegółach będą nam przychodzić do głowy sprawnie, niejako z automatu i od razu będą dobre. Taka mała pułapka, odkładamy myślenie o szczegółach na później, bo wydają się nam trywialne – „my tu, Panie, teraz o grubych funkcjonalnościach myślimy. Zmieniamy świat na lepsze”. Niestety potem gdy oglądamy rezultaty wdrażania tych szybkich ustaleń, często dochodzimy do wniosku, że należy je poprawić/zmienić. Tym sposobem powiększa to i tak ten nieprzewidywalny margines błędu.

Najnowsze na pewno nie jest sprawdzone

Druga przyczyna tkwi w samej istocie budowania czegoś nowego od podstaw.  Im dany projekt trwa dłużej, tym silniej wpływa to na jego efektywność. Im bardziej chcemy zbudować coś nowatorskiego, doskonałego, innowacyjnego, tym większą mamy skłonność do wybierania najnowszych składowych, rozwiązań, pomysłów do tejże budowy. Ma to dwojaki efekt. Po pierwsze, najnowsze nie zawsze oznacza najbardziej stabilne. Często świeżutkie rozwiązania mają swoje choroby wieku dziecięcego, brakuje im frontowego ostrzelania, nie zostały sprawdzone w realnym działaniu na wszystkie strony. Dlatego często choć bardzo obiecujące – generują nam nieco więcej zabawy niżbyśmy sobie tego życzyli. Po drugie, mamy ogromną skłonność by wykorzystać coś nowego, jeśli takowe pojawi się w trakcie realizacji naszego projektu.  Coś, co mogłoby naszym zdaniem jeszcze bardziej unowocześnić, porzucić stare plany i ruszyć z podniesionym czołem na spotkanie bardzo atrakcyjnego w swym opakowaniu nieznanego – nowego.

Opóźnienie w budowie najnowocześniejszego atomowego lotniskowca świata, USS Gerald Ford, wynosi już ponad dwa lata. Koszt budowy przekroczył już plan o ponad 2 miliardy dolarów. Prace trwają nadal. Sekretarz Floty, czyli cywilny nadzorca US Navy, Ray Mabus powiedział w wywiadzie z breakingdefense.com – „Ford jest podręcznikowym przykładem tego, jak nie budować okrętów, podstawowym problemem było to, że zaczęto go fizycznie budować zanim na dobre zakończono prace badawcze i projektowe. W efekcie trzeba było wprowadzać dużo poprawek w już gotowych elementach”.

Pytanie, czy dotyczy to tylko budowy okrętów? Moim zdaniem nie. Mamy do czynienia z taką sytuacją w praktycznie każdym dedykowanym projekcie IT (lub w ogóle w każdym projekcie) wchodzącym cokolwiek w nowy obszar poza doświadczeniem członków zespołu realizacyjnego. Nie oznacza to broń Boże, że nie należy takich projektów podejmować, jednak zawsze musimy budować bufor większy, niż nam się wydaje. Nawet w pesymistycznych scenariuszach planowania.

Możemy to zrobić jeszcze lepiej, czyli dużo gorzej

Nowe lotnisko Berlin Brandenburg miało kosztować 1,5 miliarda Euro i zostać otwarte w 2007 roku. Kosztowało już 6 miliardów, jest opóźnione już o 9 lat. Aktualnie mówi się o otwarciu w 2019-tym, a część ekspertów twierdzi, że nie zostanie ukończone nigdy. Liczba wad wykazanych w ostatniej kontroli to 66 tysięcy. Dlaczego? Historia budowy tego lotniska to historia wszystkich błędów projektowych w jednym miejscu. Skupmy się na jednym wątku wielokrotnych zmian projektów. Za każdym razem gdy wprowadzamy w projekt duże zmiany w trakcie realizacji, gdzieś na świecie ginie mały wychuchol. Często razem z nim ginie też sam projekt. Jeśli zabieramy się na początku za projektowanie jakiejś kompletnej całości, jest ona w miarę spójna. Jeśli kończymy podstawowy proces budowy naszego projektu, a następnie myślimy o kierunku strategicznych zmian, to naturalne. Jeśli jednak w trakcie realizacji projektu zaczynamy wprowadzać w plany kluczowe zmiany, podczas gdy inne części projektu dopiero czekają na zrealizowanie według starych planów, a część jest już zrealizowana i trzeba ją burzyć, to najczęściej fundujemy sobie co najmniej rozjechanie się z budżetem i harmonogramem. Zaczyna się chaos. Na berlińskim lotnisku wyburzano i budowano od nowa 6 tysięcy ścian, ponieważ musiano zmienić system przeciwpożarowy,  ponieważ dodawano nowe elementy budynków lub całe budynki nie przewidziane pierwotnie. W efekcie system przeciwpożarowy wciąż nie działa, bo adaptacja nie udała się do końca. Brzmi znajomo? Ile razy w historii projektów z którymi mieliście do czynienia zmiany w jednym z modułów niezbyt pozytywnie wpływały na działanie innych, czy często wychodziło to dopiero po pewnym czasie? Załóżmy śmiało! Tak będzie za każdym razem. Rzeczy nieprzemyślane, nieprzemyślanymi będą i kosztować będą więcej niż zaplanowano, powiada Księga Software House’ów.

Musimy, biorąc się za projekt dedykowany, nowy, mieć tę świadomość, że popełnimy błędy. Nie mamy najmniejszych szans ich nie popełnić. Planując ryzyko, oprócz bufora na ryzyka o których wiemy, musimy także utworzyć bufor na ryzyka nieznane. Przyda się na pewno!

 

Share on FacebookShare on Google+Tweet about this on TwitterShare on LinkedIn