|
 |
|
 Zaprezentowany tekst |
Zarządzanie projektami Zarządzanie projektami w erze e-biznesu
Cz. V - Kontrakty Fixed Price, a może Optional Scope?
Największą wartością pracy nad projektem jest dostarczenie wartości klientowi i spełnienie potrzeb użytkownika. Jak już wiemy z poprzednich artykułów jest to główny paradygmat ruchu Agile. Kryterium sukcesu w Agile jak pamiętamy jest założenie, że projekt może się wydłużyć, kosztować mniej lub więcej albo mieć zupełnie inne "scope" po to tylko aby dostarczyć wartość.
Zupełnie inny łańcuch wartości mamy stosując prowadzenie kontraktu metodą "fixed – price" lub "optional – scope". “Customers can now have what they want at the project end, after they’ve learned, instead of getting what they wanted at the project start.” Tradycyjne podejście typu fixed price to kontrakty, w których ustalamy budżet, harmonogram i zakres. W tych kontraktach klient specyfikuje czego oczekuje, co chce, producent (wykonawca) określa termin realizacji i koszt, w ramach których zobowiązuje się do dostarczenia klientowi wymaganego systemu, produktu.
W typowych projektach określany jest zakres, czas i zasoby, trudniej jest określić jakość. Dzięki fixed price możemy zdefiniować granice zapłacenia pewnej kwoty, za uzyskanie konkretnej korzyści przez klienta, wybierając jedne funkcjonalności, a rezygnując z innych. Aplikacja ma być w „zakontraktowanej cenie i czasie”. Aby zabezpieczyć dwie strony kontraktu, musimy założyć cztery zmienne kierowania projektem:
Fixed Price Contracts określa wartości dla trzech z tych zmiennych:
Jest niezwykle trudne usztywnić zakres, koszt i czas projekcie. Usztywnienie wszystkich czterech zmiennych jest niemożliwe.
Co się dzieje w typowych projektach gdy zbliża się deadline?
Tę metodę kontraktu wybiera się wtedy gdy produkt pracy daje się dobrze zdefiniować. Stąd – uogólniając, jeśli cokolwiek w projekcie da się dobrze zdefiniować, określić zakres, może to służyć jako podstawa do wybrania „fixed price contracts”. A może Optional Scope Contracts? Możemy również spróbować sprecyzować budżet, czas i jakość którą chcemy osiągnąć. Szczegółowy zakres (wymagania) dopracowywane są w trakcie trwania krótkiego kontraktu. Ta bardzo rzadka konstrukcja prowadzenia projektu to kontrakty typu „optional – scope”.
Czego tak naprawdę potrzebują użytkownicy?
Kontrakty „optional scope” to umowy na:
Przykład: Zapłacimy czteroosobowemu zespołowi 50 tys. za pracę przez następne 3 miesiące. Zbudowana aplikacja, której zakres zostanie dookreślony, powinna spełniać normy jakości wymienione w załączniku do Umowy. W realizacjach kontraktów „optional scope” mamy do czynienia z krótkimi iteracjami, które pozwalają oszacować nam funkcjonalność. Projekt stosujący krótkie iteracje daje menadżerowi również wiarygodną informację dotyczącą wydajności zespołu. Istotne w kontraktach „optional scope jest radzenie sobie ze stanem kryzysowym w projekcie. Jeśli nie możemy porozumieć się z klientem, a konflikt zaostrza się nie dając satysfakcjonującego rozwiązania obu stronom to powinniśmy w miarę szybko zrezygnować z kontraktu i oddać klienta konkurencji. Brak porozumienia oznacza straty obu stron, nie wspomnieć o prawnikach i odszkodowaniach za np. nie dotrzymanie Umowy. Dlatego tak ważna jest edukacja klienta jeszcze zanim podpiszemy kontrakt, przewidywanie możliwych scenariuszy kryzysowych i sugerowanie ich rozwiązania. Otwartość i współpraca pomiędzy klientem a wykonawcą podczas kontraktu pozwala projekt zakończyć sukcesem. Źródła:
|
|
|
|