Pomóc dostawcy i sobie

Podpisy złożone na kontrakcie z dostawcą to dopiero początek pracy nad projektem. O jego powodzeniu decyduje przede wszystkim odpowiednia kontrola.

Podpisy złożone na kontrakcie z dostawcą to dopiero początek pracy nad projektem. O jego powodzeniu decyduje przede wszystkim odpowiednia kontrola.

Zatrudniłeś najlepszych konsultantów do analizy projektu. Stworzyłeś zapytanie ofertowe mające kilkadziesiąt stron, w którym zapisałeś szczegółowo wszystkie oczekiwania wobec dostawców. Spędziłeś tygodnie na analizie odpowiedzi i wreszcie wybrałeś dostawcę. Myślisz, że możesz spokojnie czekać na efekty jego pracy? To błąd!

Prawdziwa praca zaczyna się właśnie teraz. Jednym z jej najważniejszych elementów jest szczegółowy opis zadań realizowanych w trakcie projektu. Dopiero jego stworzenie pozwoli na przełożenie zapisów kontraktowych na konkretne działania dostawców. Pomoże w ponownej analizie podjętych wcześniej założeń. I pozwoli wykryć przynajmniej część potencjalnych pułapek, na które może się natknąć zespół realizujący projekt.

Analiza za analizą

Jeszcze raz dobrze zdefiniuj cele i wymagania. Upewnij się, że w planie projektu przewidziano czas na analizę procesów, definicję wymagań i inne związane z tym zadania. Sprawdź, czy zaplanowano czas na dyskusję dotyczącą bezpieczeństwa, ról pełnionych przez użytkowników systemu, konwersję danych i testy. Dopóki nie masz stuprocentowej pewności co do wymagań wobec systemu (a tej możesz nie mieć nigdy), musisz być przygotowany na dodatkową pracę koncepcyjną.

Wielu menedżerów definiując stopień zaangażowania w realizację poszczególnych zadań posługuje się "regułą czterdziestu godzin". Sprowadza się ona do tego, że na każde z zadań można poświęcić nie więcej niż standardowy tydzień pracy. Niestety niewolnicze przywiązanie do tej zasady przynosi więcej szkody niż pożytku. Spotkania zespołu projektowego lubią się przeciągać, przedstawicielom dostawcy zdarza się nie odebrać telefonu, każda niewielka zmiana założeń wymaga kontrasygnaty jednego z dyrektorów. W ten sposób z przysłowiowych czterdziestu robi się sześćdziesiąt godzin. Projekt jeszcze na dobre się nie zaczął, a już mamy pierwsze opóźnienia.

Trudny temat alokacja

Rozsądnie przydzielaj zasoby do poszczególnych zadań. Jeśli projekt realizacji systemu oparty jest na modelu kaskadowym, oszacuj procentowo czas poświęcony na każdą z faz (analizę, projektowanie, przygotowanie, testowanie i implementację). Jeśli dostawca przygotowuje prototyp systemu, oszacuj czas poświęcony na osiągnięcie pierwszych założonych efektów.

Oczywiście byłoby idealnie, gdyby te liczby znajdowały odzwierciedlenie w rzeczywistości. Jeśli firma zdefiniowała już swoje wymagania, nie zapisuj w planie kolejnych godzin poświęconych na analizy. I odwrotnie. Jeśli wciąż do końca nie wiadomo, co chcemy osiągnąć, nie zakładaj z góry, że analizy pochłoną 5% czasu. To nierealne!

Na etapie alokacji zasobów kierownik projektu musi pozostać nieugięty. Niestety wiele organizacji wykazuje skłonność do nadmiernych oszczędności. Po co delegować do projektu dwóch programistów, skoro zapisane zadania mógłby zrobić jeden? Niestety, właśnie takie podejście prowadzi do opóźnień. W nadmiernie przeciążonym zespole szybko pojawiają się symptomy wypalenia. I gdy wreszcie w projekcie pojawia się prawdziwy problem, ludziom zaczyna brakować energii na jego rozwiązanie.

Dobre kamienie milowe

Jednym z gwarantów sukcesu wielomiesięcznych projektów jest dobre zdefiniowanie "kamieni milowych". Kolejne etapy powinny być oddawane sukcesywnie, najlepiej częściej niż co trzydzieści dni. W ten sposób nie tracimy z oczu głównego celu, jakim jest realizacja projektu. Równocześnie jednak mamy czas na szczegółową analizę prac. Stosunkowo szybko możemy zidentyfikować i rozwiązać potencjalne problemy. Im wcześniej zdiagnozujemy źródła problemów, tym mniejsze ryzyko porażki. Osiągnięcie kolejnych "kamieni milowych" to także świetna okazja do analizy prac dostawcy.

Zakończenie kolejnych etapów powinna podsumowywać formalna prezentacja i przegląd efektów prac. Przeforsowanie tego pomysłu nawet w swoim zespole może być trudne. Wielu członków zespołu uzna to za stratę czasu. Bronić się będą także dostawcy, którzy zdają sobie sprawę, że takie spotkania w szerokim gronie mogą obnażyć niedociągnięcia popełnione w trakcie realizacji projektu. To jednak tylko kolejny argument za regularnymi spotkaniami. Tym bardziej, że taki model pracy niesie ze sobą szereg innych korzyści. Pozwala ujrzeć wdrażany system jako całość, co w przypadku ciągnących się miesiącami projektów nie jest bez znaczenia. Dzięki temu sami lepiej poznamy tworzone rozwiązanie i łatwiej nam będzie przygotować organizację na nieuchronną zmianę modelu działania.

Najważniejsze są liczby

Przy definiowaniu zadań posługuj się liczbami. Im mniej w dokumentacji barwnych opisów, tym mniejsze ryzyko nieporozumienia z dostawcą i otoczeniem projektu. Tym łatwiejsze także rozstrzyganie wszelkich sporów. Oczywiście nikt nie jest doskonały. Przynajmniej część z zapisów będzie miała charakter szacunkowy. Nawet nieprecyzyjne dane dają jednak podstawę do dalszych rozstrzygnięć.

Oczekuj nieoczekiwanego

Podczas każdego projektu zdarzają się rzeczy nieoczekiwane. Choroba najważniejszego specjalisty od rozwoju oprogramowania. Nagła zmiana prezesa. Awaria systemu transakcyjnego, której usunięcie wyłącza z projektu cały dział IT na miesiąc. Takie rzeczy się zdarzają. Dlatego trzeba mieć w zanadrzu "plan awaryjny" na wypadek nieoczekiwanych trudności. Oczywiście nie można przewidzieć wszystkich ewentualnych zagrożeń. Można jednak zawczasu przygotować kilka w miarę uniwersalnych sposobów rozwiązania sytuacji kryzysowej.

Gdzie szukać wykwalifikowanych specjalistów? Kto mógłby przejąć prowadzenie projektu w sytuacji gdy dotychczasowy dostawca zaczyna zawodzić? Przygotowanie zawczasu odpowiedzi na te i inne pytania zabezpieczy nas przed niespodziankami. Bo takie na pewno się zdarzą.

Do opracowania wykorzystano artykuł "How to Help Your Vendor Deliver" z amerykańskiej edycji Computerworld.


TOP 200