Brak analizy wymagań a pełzanie zakresu
Konsekwencją rozpoczęcia prac na nie zamkniętych wymagań bywa ich pełzanie, czyli postępujące zmiany zakresu. Pełzanie zakresu jest jedną z najczęstszych patologii projektowych, czyli fundamentalnych źródeł ich niepowodzenia. Projektów nie patologii, bo te ostatnie mają się świetnie.
Wyobraźcie sobie, że zamówiliście w stoczni statek, stocznia entuzjastycznie zamówienie przyjęła i zaczęła kleić kadłub, budować kabinę, kupować takielunek, bo jako krytyczny postawiliście warunek oddania łodzi przez lipcem. Wszak zamierzacie zabrać ją na wakacje. Po miesiącu szkutnik pojawia się u was, dumnie prezentując zdjęcia nieukończonego kadłuba i coś wam zaczyna zgrzytać. Niepojące wrażenie, że ten kadłub jest za szeroki i brakuje dwóch pozostałych, wszak oczywistym jest, że chodziło wam o trimaran. Jednak zapał szkutnika zaraża i was, i postanawiacie nie robić z tego afery. Po prostu zgłaszacie drobne zmiany tu i tam. Mówicie, że przydałyby się wsporniki, że może dałoby się ten kadłub trochę zwęzić. W końcu rzucacie niewinną uwagę, że można by rozpiąć siatkę między kadłubami. I wtedy, na miesiąc przed wakacjami, stoczni zapala się żółta lampka. Jakimi kadłubami? Może to przejęzyczenie w e-mailu. Ponieważ jest mało czasu do końca projektu, lampka z żółtej zostaje przełączona na zieloną, a siatki postanawia się rozpiąć na tym jednym kadłubie. Wygląda to dziwacznie, ale skoro klient chce, to kto mu zabroni. Ty z kolei jesteś zadowolony, bo zgłosiłeś oficjalnie kwestię trzech kadłubów (trimaran ma ich aż trzy) e-mailem, a dostawca nie zaoponował. I wreszcie spotykacie się na koniec czerwca, wpadacie sobie w ramiona. Dostawca odsłania z dumą swoje dzieło, a twoja szczęka z hukiem uderza o deski pokładu.
Powyższy fragment pochodzi z książki na temat prowadzenia firmy projektowej, którą właśnie piszę o roboczym tytule Project Inc.
Zdjęcie tytułowe zapożyczono z Wikipedii
