Strona używa cookies (ciasteczek). Dowiedz się więcej o celu ich używania i zmianach ustawień. Korzystając ze strony wyrażasz zgodę na używanie cookies, zgodnie z aktualnymi ustawieniami przeglądarki.    X

Pełzanie zakresu - projekt IT nad przepaścią

Ostatnio kilku blogerów rozpisywało się odnośnie zarządzania projektami IT, problemami w biznesie itp.

W swoim wpisie chciałbym opisać pewną patologię, która może zdarzyć się w każdym projekcie IT. Bez względu na to, czy to duże, czy małe przedsięwzięcie.

Pełzanie zakresu

Pełzanie zakresu (scope creeping) jest zjawiskiem, które może zrujnować każdy projekt. Jest to nic innego, jak sukcesywne dodawanie małych zmian w projekcie. Owe poszerzenia zakresu teoretycznie nie wnoszą wiele zmian w projekcie. Nie są również, z założenia, pracochłonne.

Jednakże, jeśli tych zmian będzie coraz więcej i nikt nie będzie mógł nad nimi zapanować, koszty projektu wzrosną, a nawet może on zostać anulowany.

Wzrost wymagań

Przed rozpoczęciem prac, klient i wykonawca spotykają się, aby ustalić wspólny cel, czas realizacji, harmonogram, budżet itp.

Niestety, w miarę tworzenia projektu, klient staje się coraz bardziej wymagający, chcący dodać malutkie zmiany, "nie wpływające" na projekt.

Im projekt sie rozwija, tym klient lepiej wie czego chce. Widzi co ma konkurencja. Dodatkowo mając wstępnie przyjęty zakres prac i ogólny zarys wizji całości, może bardziej sprecyzować swoje wymagania.

Wszelkie zmiany są zawsze małe i nieistotne z punktu widzenia klienta. Jednakże ich ilość, może stać się plagą i doprowadzić do posypania się harmonogramu i bałaganem w zarządzaniu projektem.

Między młotem, a kowadłem

Kierownik projektu jest w dość niezręcznej sytuacji. Nie może odmówić dla klienta, gdyż np. projekt jest duży i zleceniodawca mógłby uciec do konkurencji. Często zmiany są faktycznie niewielkie, więc korekta harmonogramu/budżetu nie jest teoretycznie potrzebna. Nic nie wskazuje na to, iż zmiany mogą stać się w przyszłości największą bolączką w zarządzaniu danym projektem.

Wart zwrócić uwagę na osoby z wewnątrz, które nieświadomie, "sabotują" projekt. Często taką role odgrywają handlowcy i/lub osoby odpowiedzialne za kontakt z klientem. Ich rady/podpowiedzi, dla klienta stają się inspiracją do poszerzania zakresu funkcjonalnego, motorem do zmian i dodawania "nic nieznacznych zmian".

Antidotum

Jak walczyć z pełzaniem zakresu:
- jasno zdefiniowane planowanie projektu,
- klient powinien być zaangażowany w proces planowania jak najwcześniej,
- określenie dopuszczalnych poziomów zmian, definicja stopnia ważności zmian,
- dokładna analiza każdej nowej zmiany,
- stworzenie dokumentacji, notatek ze spotkań.

Podsumowanie

Pełzanie zakresu to bardzo powszechny problem w projektach IT. Walka z omawianym zjawiskiem nie jest prosta i stanowi wyznanie dla nawet doświadczonych kierowników. Mając nawet małą jednoosobową firmę, warto przeanalizować, czy dany projekt, nie staje się obciążony pełzaniem wymagań i próbować przeciwdziałać.

Dziękuję i Pozdrawiam

Powiązane

http://en.wikipedia.org/wiki/Scope_creep - pełzanie zakresu (scope creeping) (wiki)

http://octigo.pl/2011/07/zarzadzanie-projektami/pelzania-w-projekcie/ - Pełzania w projekcie (Marcin Żmigrodzki)
 

hobby inne

Komentarze

0 nowych
Jaahquubel_   12 #1 28.09.2011 11:02

Historyjka z sufitu, ale w temacie.
Handlowiec do PM-a:
- Klient przysłał propozycję zmiany, jest drobna, ale bardzo ważna.
PM do dewelopera:
- Klient przysłał CR-a. Wyceń go.
Deweloper do siebie:
- O szlag! Drobna zmiana?! To jest na cztery tygodnie roboty! A i tak jeszcze pewnie coś zmienią...
Deweloper do PM-a:
- 25 dni pracy.
PM do dewelopera:
- Dobra, zaczynaj.
PM do handlowca:
- Zmiana będzie zrobiona za 15 dni.
Handlowiec do klienta:
- No, stary, to tak, jak ci obiecałem, będziesz to miał na koniec tego tygodnia.

tfl   8 #2 28.09.2011 11:36

SC jest zawsze winna kierownika działu lub osoby odpowiedzialnej bezposrednio za projekt (jesli osoba ta nie jest wlasnie kierownik dzialu). Nie moge sie zgodzic z teza, ze ta osoba nie moze odmowic klientowi. Zwlaszcza przy argumentacji, ze "projekt jest duzy". Tym bardziej w takich momentach osoba odpowiedzialna za projekt ma obowiazek poinformowac klienta, ze zmiana moze pociagnac za soba znaczne konsekwencje.

Sam creeping nie powinien wystepowac w metodologii, ktora opisalem (a poczulem sie wywolany do tablicy w pierwszym akapicie). Scrum master, jesli wypelnia swoje zadania nie moze do niego dopuscic. Jesli ta czesc zespolu dziala zle, to sie ja wymienia. Bo, przez analogie, nie jezdze samochodem, w ktorym pompa paliwowa zle dziala.

@Jaahquubel_

Tak nieco ironicznie, nieco inna historia -

Klientka do obslugi stacji:
-95 do pelna.
Obsluga stacji:
-Alez prosze pani! To jest diesel!
-Jestem klientem i moge sobie wymagac, chce 95 do pelna. Jest w podobnej cenie.
-Po tym wszystkim, droga pani silnik bedzie do remontu.
-Ale to moja decyzja.
-To prosze mi tutaj spisac oswiadczenie, ze jest pani swiadoma swojej decyzji i nie bedzie sobie pani roscic pretensji.


Mniej wiecej tak sobie wyobrazam dobra rozmowe project managera z klientem, ktory guzik wie tym czego chce.

djfoxer   17 #3 28.09.2011 12:16

@tfl
Są projekty, gdzie klient jest w uprzywilejowanej pozycji (np. niezadowolony z poprzedniej naszej aplikacji i to jest jedyna szansa na odzyskanie dobrego imienia) i odmówić klientowi wówczas nie można, ktoś nad PM jest jeszcze wyżej. To raczej już są rzeczy związane z zarządzaniem całej firmy, jak do tego podchodzi.

Ja dodam tylko coś co komuś w jakiejś firmie się zdarzyło:

Handlowiec (z zewnętrznej firmy, zleceniodawcy) do PM/Developera, po przedstawieniu argumentacji, że zmiana jest bezcelowa i tak zostanie pewnie w późniejszym czasie cofnięta:
"To wy to zróbcie wszystko, żeby im pokazać, że to nie ma sensu i później to usuniecie"!!
Nóż w kieszeni się otwiera....

parasite85   7 #4 28.09.2011 12:24

Moim zdaniem takie problemy jak napisałeś wynikają z błędów na samym początku. Wszak analiza SI obejmuje takie sprawy jak zbadanie firmy klienta (wykorzystywanych systemów, uprawnień, używanych formularzy, itp), analizę SWOT i najważniejsze - wywiady z pracownikami klienta (tymi którzy de facto będą pracować w danym systemie). Oczywistym jest, że błędy w fazie analizy są najtrudniejsze do naprawienia (czyt. najbardziej kosztowne i czasochłonne). Dobry analityk SI to podstawa jakiegokolwiek projektu.

  #5 28.09.2011 21:52

@parasite85
Ale 80% klientów tak na prawdę nie wie czego chce. I nawet jeżeli analityk zrobi swoje, klient zaakceptuje szkielet aplikacji oraz precyzyjną "idiotoodporną" analizę z obrazkami i schematami, aby dziecko z zerówki zrozumiało, to klient ZAWSZE zmieni swoje wymagania, niezależnie od metodyki prowadzenia projektu. Niektóre z metodyk minimalizują ryzyko nieplanowanych opóźnień, inne - na zasadzie "załóżmy, że tym razem nic takiego się nie stanie" prowadzą do bólu oczu developerów. I kłopotów z przewodem pokarmowym ich przełożonych. Czasami analityk nie wiele może zdziałać, np w przypadku budowy systemu integrującego się z systemem klienta, którego to część jest dopiero w budowie. I uwierz mi, zbudowanie stabilnego API nawet dla największych firm na rynku jest często niemożliwe z powodu burdelu jaki mają po swojej stronie. Lepiej za wczasu przygotować się na "lekko" "pływające" API.

A do pierwszych komentarzy i samego artykułu - polecam książkę Roberta C. Martina - "Clean Coder", zwłaszcza rozdział 2'gi "Saying No", dla mnie bomba :)

  #6 29.09.2011 10:40

Zgadzam się w całej rozciągłości, a handlowców nienawidzę, mam prawo.

  #7 31.10.2014 09:23

W zasadzie każdy rodzaj projektu wymaga stosowania narzędzi informatycznych. Czemu by nie korzystać z takiej możliwości jeśli jest? Ja korzystam z intuicyjnego programu do zarządzania projektami http://pmcompass.pl, który oferuje tworzenie wykresu Gantta, zarządzanie czasem pracy pracowników oraz obsługę dokumentacji.