Dlaczego projekty IT
się przeciągają?

Problemy z utrzymaniem harmonogramu w projektach IT i wieczne spóźnienie rodzi się już na etapie planowania, a straty potrafią być nie do odrobienia. Zrozumienie powstawania opóźnień pomoże w doborze odpowiedniego dostawcy, sposobu współpracy i ograniczy ryzyko wykraczania poza harmonogram i budżet.

Spis treści:

• #1 Problemy procesu sprzedażowego
• #2 Specyfikacja projektu IT
• #3 Zapas i plan B
• #4 Metodyka vs życie
• #5 Ekspercki zespół

W zależności od tego, kogo zapytasz, projekty IT przeciągają się z powodu: źle ustalonych celów na etapie procesu sprzedaży, słabej jakości specyfikacji technicznej, braku komunikacji dostawca-klient, niskiej jakości specjalistów lub ich braku.

Prawda oczywiście leży pośrodku, a problemy z dotrzymaniem harmonogramu są, niestety, często uznawane za zło konieczne.

Opóźnienia to przede wszystkim wzrost budżetu. Według badania The State of Project Management prowadzonego przez Wellingone w 2020 roku, aż 57% respondentów przyznało, że przekroczyło budżet projektu.

W książce Wieczne opóźnienie Marcina Dąbrowskiego, praktyka pracy z projektami IT, autor zaczyna od wypunktowania, że problemy z opóźnieniami w projektach są nierozerwalnie połączone z procesem sprzedaży i, poniekąd, konfliktem interesu pomiędzy sprzedawcą, zespołem deweloperów i właścicielami firm.

Dołóżmy do tego, że adopcja zwinnych metodologii nadal jest niepełna – tylko 53% respondentów badania instytutu PMI określiło, że używa jednej lub więcej technik Agile (najczęściej daily standup).

Z drugiej strony… ślepe zawierzanie metodologii może być czynnikiem wpływającym negatywnie na harmonogram. Zwłaszcza jeśli 3-osobowy team wdrażający proste rozwiązanie połowę czasu spędza na uzupełnianiu Jiry.

Jeśli od zawiłości kręci ci się w głowie, to spokojnie – poniżej konkretny przegląd tematu, wraz z proponowanymi rozwiązaniami.

#1 Problem procesu sprzedażowego

Zacznijmy od procesu sprzedażowego, często pomijanego przy omawianiu problemów z budżetem i harmonogramem projektów IT. To podczas podpisywania pierwszych umów ustalane są zakresy, czas i koszt, które mają decydujący wpływ na to, jak projekt jest realizowany.

Niestety ukryty konflikt interesu i myślenie życzeniowe sprawia, że harmonogram jest nierealny od samego startu.

1. Celem sprzedawcy pod stronie dostawcy jest sprzedaż i realizacja swoich KPI. Sprzedawca nie otrzymuje prowizji od dostarczenia produktów w harmonogramie.
2. Celem klienta jest znalezienie najlepszej oferty, często najlepsza = najtańsza, oferuje najwięcej za najmniej.

Dodajmy do tego CEO firmy, który chce złapać dużego klienta, więc przymyka oko na nierealne terminy zaproponowane przez dział handlowy. Katastrofa pisana jest od startu, a będzie zmagać się z nią zespół projektowy już po podpisaniu umowy, ku niezadowoleniu obydwu stron.

Rozwiązanie: określ wspólny cel dla działu sprzedaży, dostawcy i klienta. Celem powinno być dostarczenie możliwie najlepszego produktu.

Jeżeli każda ze stron weźmie sobie za cel dostarczenie produktu, to nierealne harmonogramy i wyceny stają się wrogiem numer jeden i dla klienta i dla dostawcy.

Wielkość firmy ma znaczenie

Na tym etapie warto zwrócić uwagę na wielkość i specjalizacje firmy, z którą planuje się współpracę. Mały klient zgubi się u dużego, korporacyjnego dostawcy, a wspólne zorientowanie się na cel będzie trudne.

by Sławomir Wilusz

Najważniejszy jest dobry, bezpośredni kontakt od samego startu. Dbamy o to, żeby dokładnie zrozumieć potrzeby naszych partnerów, ale także, żeby wyjaśnić im możliwości i ograniczenia.

To wszystko musi nastąpić jeszcze przed finalnym podpisaniem umowy.

by Sławomir Wilusz

#2 Specyfikacja projektu IT

Kolejną piętą Achillesa jest specyfikacja techniczna projektu – zrobiona po łebkach, w ramach wypełniania życzeniowego myślenia obydwu stron lub bez ekspertyzy ze strony dostawcy. W procesie okazuje się, że dodanie prostego modułu zamiast miesiąca zajmuje cztery.

Przygotowanie specyfikacji projektu jest niezbędne dla określenia zakresu pracy, harmonogramu i budżetu. Dobrej jakości specyfikacja to:

1. Jasny i zwięzły język. Unikaj żargonu technicznego lub niejasnych terminów, które mogą prowadzić do nieporozumień. Specyfikacja ma być zrozumiała dla obydwu stron.
2. User stories. Możesz wykorzystać user stories, aby opisać, jak system będzie wykorzystywany przez użytkowników.
3. Wymagania funkcjonalne i niefunkcjonalne. Rozróżnij pomiędzy wymaganiami funkcjonalnymi (co system powinien robić) a wymaganiami niefunkcjonalnymi (cechy lub ograniczenia systemu). Pomaga to w skutecznym priorytetyzowaniu i zarządzaniu wymaganiami.
4. Unikaj niejednoznaczności. Upewnij się, że każde wymaganie jest jednoznaczne i jasno zdefiniowane. Użyj konkretnych i mierzalnych kryteriów, aby zdefiniować oczekiwane zachowanie systemu.
5. Uwzględnij założenia i ograniczenia. Udokumentuj wszelkie założenia lub ograniczenia, które mogą wpływać na wymagania lub proces rozwoju.
6. Przegląd i walidacja. Regularnie przeprowadzaj przeglądy i walidacje SRS z interesariuszami, w tym programistami, testerami i użytkownikami końcowymi. Pomaga to zidentyfikować ewentualne luki lub niezgodności w wymaganiach i zapewnia, że wszyscy mają wspólne zrozumienie systemu.
7. Kontrola wersji. Utrzymuj kontrolę wersji dokumentu SRS, aby śledzić zmiany i aktualizacje. Pomaga to zarządzać ewolucją wymagań w czasie i zapewnia, że wszyscy interesariusze pracują z najnowszą wersją.
8. Organizacja dokumentu. Organizuj dokument SRS w logiczny i uporządkowany sposób, używając nagłówków, pod nagłówków i numeracji dla łatwej nawigacji. Ułatwia to czytelnikowi znalezienie konkretnych wymagań i zrozumienie ogólnej struktury dokumentu.

Rozwiązanie: przygotuj dokładną specyfikację projektu, wspierając się wiedzą ekspertów.

#3 Zapas i plan B

Ostatnio pisaliśmy o naszych praktykantach realizujących projekt AI, w którym dane podzielone są w określonych proporcjach już na starcie. Dane dla projektów AI są kluczowe, tak jak budżet jest kluczowy dla projektów IT.

O budżecie warto myśleć w podobny sposób i przed uruchomieniem projektu warto go podzielić. Jeśli wydasz 100% budżetu na wczesne MVP, to siłą rzeczy ciężko będzie dalej pracować.

• Budżet. Dokładne rozplanowanie budżetu z zapasem zwiększy prawdopodobieństwo sukcesu.
• Harmonogram. Dokładnie zaplanowany harmonogram z zapasem sprawi, że zrealizowany zostanie zaplanowany zakres, a budżet nie zostanie rozdmuchany przez opóźnienia.

Rozwiązanie: planuj budżet i harmonogram z zapasem.

#4 Metodyka vs życie

Zwinne metodyki tworzenia projektów cyfrowych od lat są złotym standardem, mimo – jak zostało wspomniane wyżej – niepełnej adopcji w branży IT. Kurczowe trzymanie się metody, bez dostosowania jej do potrzeb danego projektu, może być zgubne.

Efekty uboczne wynikające ze ślepego wdrażania zwinnych metod to:

1. Próba dostosowania cyklu produkcyjnego do dwutygodniowych iteracji.
2. ”Projekt jest agile” = brak harmonogramu i presji czasowej.
3. Trzymanie się sztywno wybranej metodyki, nawet jeśli projekt można wykonać lepiej innym sposobem.
4. Organizacja nie jest gotowa na zwinne metody, ale mimo to je organizuje.

W praktyce, najlepsze rozwiązanie do zarządzania projektem to takie, które sprawi, że projekt zostanie dostarczony na czas i w ramach danego budżetu (wracamy do myśli przewodniej, czyli celu).

Zrozumienie po obydwu stronach faktu, że nie ma złotego rozwiązania na proces produkcyjnie, ułatwi wspólne wybranie metody, która będzie dostosowana do projektu.

Rozwiązanie: dobierz metodę do projektu.

Sposób współpracy

Warto wspomnieć, że bardzo ważny jest także sposób współpracy. Istnieją różne modele, które w uproszczeniu można podzielić na:

• Fixed Price. Cena i zakres ustalone są na początku i nie ulegają zmianie.
• Time & Material. Klient rozlicza się za czas pracy specjalistów.

#5 Ekspercki zespół

Na finisz ostatni z czynników wpływający na opóźnienia, czyli zespół ekspertów. Zakładając, że projekt był dobrze zaplanowany od startu, głównym ogniwem w jego realizacji zostaje zespół specjalistów budujących produkt.

Wysokiej jakości specjaliści to:

1. Efektywność w pracy, bardzo ważna przy rozliczeniu godzinowym.
2. Mniejsza ilość poprawek.
3. Szybkie rozwiązywanie problemów.
4. Transfer wiedzy i dzielenie się doświadczeniem.

Świetnym pomysłem jest zatrudnianie ekspertów wyspecjalizowanych w danych technologiach i mających doświadczenie z realizacją projektów o skali odpowiadającej twoim potrzebom.

Przykładowo: nawet doświadczone firmy będące podwykonawcami dla dużych korporacji mogą nie wiedzieć, z jakimi problemami walczą startupy (i w drugą stronę).

Rozwiązanie: Szukaj firm, które mają doświadczenie w twojej branży i specjalistów na pokładzie.

Czynnik ludzki

Z powyższego wynika jedno: problemy z opóźnieniami generują ludzie. Przez życzeniowe myślenie, brak ekspertyzy i konkurujące interesy. Właśnie z tego powodu angażujemy się w proces planowania projektu już na najwcześniejszych fazach, a CEO Fingoweb dostępny jest dla wszystkich naszych partnerów.

Nasz ponad 50-osobowy zespół składa się z doświadczonych ekspertów, a ponad 10-letnie doświadczenie sprawia, że znamy pain pointy partnerów i wiemy, jak sobie z nimi radzić.

Otrzymaj wycenę