Pomińmy drobny fakt, że jest to dla dostawcy dodatkowa praca - a więc i koszt - nie ujęta w zakresie projektu. Konsekwencją jest fakt, że tak powstały dokument nie może być rzetelny. Plan jakości stawia na pewno wymagania do spełnienia, kryteria akceptacji są niedookreślone, uzasadnienie biznesowe oczywiste lub niemierzalne, ryzyka do zaniedbania, zaś o tolerancjach się nie wspomina. Początkowo wydaje się to wygodne dla wszystkich: napisaliśmy te wymagane przez centralę papiery i mamy z głowy. Niestety, to się później zemści w postaci problemów z podejmowaniem istotnych decyzji oraz z ostatecznym odbiorem pracy (o tym za chwilę).

Komitet Sterujący zamiast rozpatrywać przewidywane zagrożenia, będzie stawiany przed faktami dokonanymi. Trudno będzie śledzić aktualność Uzasadnienia Biznesowego i oceniać zasadność proponowanych zmian. Leżący na półce DIP pozostaje dokumentem martwym. Nikt do niego nie zagląda, nikt się do niego nie odwołuje. Praktycznie los projektu zależy od decyzji podejmowanych operacyjnie przez Kierowników Projektu i od ich relacji.

3. Planowanie

Planowanie to proces dający najwięcej okazji do pomyłek, których skutki są wprost wymierne w kosztach projektu. Problemy te - oraz ich finansowe konsekwencje - zwykle są udziałem dostawcy, choć nie zawsze wynikają wyłącznie z jego winy.

Często utożsamiamy plan projektu z harmonogramem, pomijając etap planowania opartego na produktach. Harmonogram taki może nie zawierać istotnych zadań, które, poniewczasie, okażą się konieczne. Nie przewiduje się także czasu potrzebnego na akceptację pracy przez klienta czy przewidywanych urlopów. Nie uwzględnia się rezerwy na ryzyko, optymistycznie zakładając, że decyzje będą słuszne, nikt nie zachoruje, zaś elementy budowanego systemu zadziałają poprawnie już przy pierwszym uruchomieniu. W dodatku bezkrytycznie przyjmuje się, że wszyscy będą efektywnie pracować ze stuprocentową wydajnością i zawsze będą dostępni w przewidzianych terminach. To tym bardziej zadziwiające, że dobrze wiemy, jak bardzo życie odbiega od tego ideału - wystarczy przypomnieć sobie, jak często rozprawiamy o tym na korytarzach, w kuchniach i palarniach.

Z drugiej strony trzeba zauważyć, że harmonogramy powstają zwykle na etapie, który dostawca nazywa "ofertowaniem", zaś klient "wyborem systemu". Presja na to, aby plan przyszłego projektu pokazywał krótki czas realizacji i niskie koszty, jest ogromna. Co więcej, zdarza się, że zapytanie ofertowe jawnie wskazuje wymagany termin realizacji projektu - całkowicie nierealny. Oto przykład: dostajemy dwa tygodnie na złożenie oferty, dwa tygodnie klient daje sobie na wskazanie krótkiej listy dostawców i kolejne dwa na ostateczny wybór. Jednocześnie wymagany termin zakończenia projektu to dwa miesiące od daty zapytania ofertowego! Przy tym wszystkim wyłaniająca się z zapytania złożoność systemu skłania do wniosku, że wdrożenie powinno trwać kilka miesięcy, a może nawet rok. Takie oferty powstają, są składane, rozpatrywane i któraś z nich wygrywa. Powstaje kontrakt zawierający w treści harmonogram przepisany oczywiście wprost z oferty.