Projekty informatycznie znacznie się różnią od innych projektów. To powoduje, że zarządzanie projektami IT przez osoby nie mające pojęcia o programowaniu i technicznych zawiłościach ich utrzymywania jest bardzo trudna. Ilość stosowanych obecnie metod i ich założenia, oraz odsetek projektów IT, które kończą się niepowodzeniem zdaje się to tylko potwierdzać.
Uwielbiam Informatykę właśnie za to – że jest tak niedostępna dla nie-informatyków, a zarządzenie projektami, które w swoim założeniu ma to naprawić paradoksalnie – jeszcze bardziej to komplikuje 🙂 Żeby była jasność, nie krytykuję PM ale próba ujarzmienia projektów IT za pomocą kolejnych metodyk i zbioru zasad którzy mają stosować programiści nie posiadający matematycznej dyscypliny nie ma za bardzo sensu.
Początkowe fazy projektu
W projektach IT kontakt z klientem i zarządzenie wymaganiami jest wyjątkowo istotne. Większość niepowodzeń w projektach informatycznych jest wynikiem niedostatecznego zrozumienia klienta. W projektach nie-IT ten problem jest zazwyczaj mniejszy. To powoduje że rola planowania i rozwoju samego projektu zajmuje najwięcej pracy a implementacja jest bardzo prosta.
W przypadku nieinformatycznych projektów (np. budowlanych) to implementacja jest najdroższym etapem realizacji projektu zaś planowanie i projekt pochłania znacznie mniej kosztów.
Testowanie
W przypadku projektów informatycznych (a tym bardziej projektów dotyczących wytworzenia oprogramowania), wiele uwagi poświęca się testowaniu. Istnieją nawet metodyki (mowa o Test-Driven Development) które polegają najpierw na pisaniu testu dla nieistniejącej funkcjonalności a dopiero potem przystępuje się do jej implementowania i refaktoryzacji kodu.
W projektach nieinformatycznych testowanie oczywiście występuje ale nie jest punktem wyjściowym rozwoju projektów lub nie pochłania tak znacznych środków.
Złożoność
Potrzeba planowania jest wynikiem dużo większej złożoności projektów informatycznych od innych. Poziom skomplikowania projektów polegających na wytworzeniu oprogramowania powoduje, że utrudnione jest harmonogramowanie i kosztorysowanie. Pojawiające się w trakcie realizacji projektu nowe i z pozoru mało znaczące wymagania mogą wymagać sporych nakładów pracy. Bardzo trudno jest dokładnie określić szczegółowe wymagania dotyczące projektów oprogramowania przed rozpoczęciem realizacji. Z tego powodu podejście adaptacyjne (Agile) najlepiej sprawdza się przy dalszym opracowywaniu szczegółowych wymagań dla projektu w trakcie jego realizacji zamiast próbować definiować je z góry.
W przypadku projektów nieinformatycznych (które dużo łatwiej jest zaplanować) łatwiej jest zapanować i określić wpływ poszczególnych wymagań na cały projekt.
Unikalność
Projekty informatyczne są unikalne. W praktyce oznacza to, że ciężko jest wykorzystać doświadczenia i efekty prac powstałe w skutek tworzenia projektu dla jednego klienta by potem móc je wdrożyć w projekcie dla kolejnego klienta.
Automatyzacja i tworzenie niejako szablonów i matryc jest łatwiejsze w przypadku projektów nieinformatycznych.
Niepewności i konieczność zarządzania ryzykiem
Złożoność i unikalność poruszana w poprzednich punktach powoduje, że projekty informatyczne są obarczone znacznie większym ryzykiem niż inne projekty i zwiększonym poziomem niepewności.
W projektach nieinformatycznych możliwość zaplanowania daje większą kontrolę nad projektem a to powoduje zazwyczaj mniejsze ryzyko i prawdopodobieństwo poniesienia nieprzewidzianych strat.
Nienamacalność postępów i niematerialny efekt końcowy
To co wyraźnie odróżnia projekty informatyczne od innych to brak możliwości zaprezentowania wyraźnych i namacalnych postępów realizacji. W projektach informatycznych istnieje coś takiego jak wdrożenie. Dopiero po wdrożeniu można zaprezentować postęp prac.
W przypadku np. projektu budowlanego widzimy jak budynek stopniowo powstaje i znacznie łatwiej jest określić postępy osobom nie zaangażowanym bezpośrednio w realizację projektu.
Elastyczność rozwiązań, upgrade i kolejne wersje
Od projektów informatycznych wymaga się pewnego rodzaju elastyczności. Potrzeba integracji z innymi usługami i systemami oraz możliwość rozbudowy w przyszłości jeżeli zajdzie taka potrzeba.
W przypadku projektów nie-informatycznych nie ma potrzeby wykonywania i wdrażania nowych wersji.
Utrzymanie i brak wyraźnego punktu zakończenia pracy nad projektem
Utrzymanie jest charakterystycznym etapem projektów informatycznych. W projektach nieinformatycznych nie ma potrzeby utrzymywania zrealizowanych projektów lub jest ono znacznie mniej istotne.