Wdrożenia ERP – cz. III. Case nr 2: „pieniądz robi projekt”

Wpis gościnny dr hab. inż. Andrzeja Zalewskiego

Kolejny z serii wpisów gościnnych dr hab. inż. Andrzeja Zalewskiego na temat wdrożenia ERP. Wpisy te pierwotnie opublikowane były na grupie FB, dzięki uprzejmości autora prezentujemy je również na łamach Rudej Strony Zarządzania.

Case nr 2: „pieniądz robi projekt”

Tytuł tego posta to taka wprawka aforysty. Ale dziś chciałem opowiedzieć o projektach, które łączą trzy a właściwie cztery rzeczy:

1. oczekiwanie konkretnego rezultatu przez zamawiającego
2. ograniczony budżet,
3. budowa ERP od zera zamiast wdrożenia gotowego produktu,
4. agile/zwinne prowadzenie projektu.

Dziś skupię się na kwestii budżetu i oczekiwanego rezultatu.

Rzecz dzieje się w trzech firmach z różnych branż usługowych, na tyle jednak już odrośniętych, by odczuć potrzebę uporządkowania zarządzania firmą.

ETAP I. MIODOWY MIESIĄC

Wszystkie te firmy zamawiają system ERP w zaprzyjaźnionej firmie informatycznej, będą go budować od zera. Ich szefowie znają się od jakiegoś czasu, ufają sobie, mają za sobą jakaś udaną współpracę. Podpisują więc jakąś niedbale skleconą Umowę, ustalają jakąś kwotę za całość (!), podzieloną na płatności w ratach i do pracy. Mają działać zwinnie, „jechać” kolejnymi sprintami do sukcesu. Atmosfera jest dobra, widoczne zaangażowanie obu stron.

ETAP II. KŁOPOTY

Budżet projektu jest nie do końca realistyczny.

Miodowy miesiąc mija, w pewnym momencie zamawiający dostrzega, że do opracowania finalnie użytecznego systemu jest długa, wcale nie prosta droga. Zaczyna mieć wrażenie, że wykonawca idzie drogą na skróty, że nie wykonuje systemu, który w pełni odpowiadałby jego potrzebom.

Widzi, że wydał już znaczne pieniądze, a efektu nie widać.

Zaczynają się narady, narasta nerwowość, groźby, pierwsze wstrzymane wypłaty…

ETAP III. SPÓR

Wykonawca działa pod coraz większą presją, robi błędy, czuje że nie jest w stanie sprostać zadaniu w terminie. Potrzebuje też pieniędzy, które musi wypraszać u Zamawiającego…

Zamawiający denerwuje się coraz bardziej, widząc wypływający – nie mały – pieniądz i brak spodziewanych efektów.

Pojawiają się prawnicy… Zaczyna się przekonywanie, że system jest w porządku, ma niewielkie usterki (wykonawca) oraz, że system się do niczego nie nadaje (zamawiający)… oczywiście nikt nikogo nie przekona.. próbują więc przekonać Sąd… i to jest ten moment, w którym to, co zostało z projektu trafiło w moje ręce.

WNIOSKI (oczywiste, ale jakoś nie dostrzegane na początku projektu):

1. Budżet „robi projekt” – finalnie jest kluczowy dla wykonawcy i zamawiającego – niestety, w biznesie, wszystko się finalnie sprowadza do pieniądza;
2. Syndrom wrażenia braku postępu jest typowy w niedoszacowanych projektach – im bardziej projekt jest niedoszacowany tym szybciej się on ujawnia;
3. Jak widać pokazanie, że prace przybierają realny kształt (zob. metodyki zwinne / Agile) ma sens – pozwala pozbyć się niepokoju o brak efektów w stosunku do wydatków;
4. W pewnym momencie ktoś zacznie nerwowo spoglądać na wydatki – niestety nie należy myśleć, że „jakoś to będzie” ;
5. Problem przypomina dylemat więźnia: właściwie we wszystkich opisywanych przypadkach projekt można by uratować, gdyby udało się przywrócić zaufanie między wykonawcą a zamawiającym i niedrastycznie zwiększyć budżet. Ale przywrócenie zaufania nie jest proste w kontekście tego co w poz. 2 i 4 oraz słów wypowiedzianych często w emocjach…
6. Trzeba się troszczyć o zaufanie, aby nie wygasło.
7. Dobre relacje między zamawiającym a wykonawcą przed nie gwarantują sukcesu w projekcie o nierealnych założeniach budżetu <–> zakres.
8. Jak chcesz stracić przyjaciela – zrób z nim projekt?

O autorze

Andrzej Zalewski, dr hab.

Informatyk pracujący na Politechnice Warszawskiej, gdzie uczy algorytmiki oraz zarządzania projektami informatycznymi w firmach. Udziela się również jako ekspert i biegły w dziedzinie inżynierii oprogramowania. Kieruje Studiami Podyplomowymi Zarządzanie Zasobami IT oraz Zarządzanie projektami.