Zrozumienie utraty kontroli nad projektami IT jest ważne. Oto kilka cech wskazujących na utratę lub bliską utratę kontroli nad projektem. Zazwyczaj spełnienie 3 poniższych warunków wymaga restartu projektu.
Inżynierowie projektów chcą na bieżąco kontrolować swoje projekty. Czasem jest to bardzo ciężkie zadania zwłaszcza w przypadku dużych projektów programistycznych.
Oprogramowanie jest trudne zarówno w pokazaniu jak i zrozumieniu. Wiele projektów w ten sposób może wymknąć się spod kontroli nawet gdy kadra kierownicza świadoma jest prioblemów.
Projekty mogą być "spalone" z wielu powodów, najczęściej jednak jest to brak restartu projektu, gdy przyjął on złą drogę. Wiadomym jest, że trudno zastopować projekt nawet gdy powstają istotne problemy i nie są planowane ich rozwiązania. Przykładowo gdy projekt wymagający restartu pochłonął już 2 mln. dolarów trudno podjąć decyzję o jego wstrzymaniu i ponownym uruchomieniu nawet, jeśli ostateczny jego koszt będzie mniejszy a czas krótszy. Dlatego też uzmysłowienie tego faktu jest ważne.
Poniżej przedstawiamy wspólne cechy projektów poza kontrolą, które mogą pomóc w określeniu, czy Twój projekt chyli się ku upadkowi. Jeżeli do Twojego projektu pasuje pojedyńcza cecha, to jeszcze nie powód do zmartwienia. Jednak gdy już przynajmniej trzy cechy charakteryzują projekt, warto zrobić restart.
1. Brak projektanta lub grupy projektantów. Bez kontroli nad projektem, utrzymującej porządany kierunek rozwoju, małe zmiany są akumulowane i zbyt często powodują zmianę kierunku całego projektu, prowadząc w złe decyzje lub ślepe zaułki.
2. Brak harmonogramu projektu. Jeśli nikt nie zna rzeczywistego harmonogramu projektu, lub jeżeli harmonogram ten wydaje się opóźniony projekt jest poza kontrolą i nie będzie zakończony na czas zgodnie z planowaną funkcjonalnością.
3. Harmonogramy są utrzymywane w arkuszach kalkulacyjnych, albo listy zadań są utrzymywane w dokumentach i prezentacjach. Taka forma oznacza niemożność korzystania z odpowiednich narzędzi do pracy a istnieje wiele specjalistycznych narzędzi wspierania projektów, które ograniczają czas i wysiłki potrzebne na zarządzanie projektem. Innym wskaźnikiem nie stosowania odpowiednich narzędzi jest manualne wykonywanie procesów instalacji, ktualizacji i poprawek, które to moga być zautomatyzowane przez skrypty i komendy poleceń.
4. Podejście "porażka nie wchodzi w grę". Mimo, że jest to dobre motto dla misji, to jednak prowadzi to do dziwnych zachowań w projektach informatycznych. Jeśli wystąpił błąd, ludzie nie zgłaszają ich przez co Kierownicy projektów nie są świadomi nawet błachych problemów. Podobne bezproduktywne motta to "za pierwszym razem" i "nie ma żadnych problemów, są tylko nowe możliwości".
5. Brak kontroli lub w ogóle zarządzania konfiguracją. Jeśli dużo czas traci się na próby odnalezienia potrzebnych informacji i potwierdzenia, że znalezione informacje są najbardziej aktualnymi, konieczny jest leprzy nadzór nad wynikami poszukiwań. Dla członków zespołów najlepszą metodą wymiany informacji i plików są udostępnianie plików, e-maile i napędy USB. Brak jest jednak zcentralizowanej bazy informacji.
6. Brak dokumentacji, testerów lub kontrolerów kodu. Gdy projekt jest opóźniony a zasoby przeznaczone na projekt są coraz uboższe, system opinii to jedno z pierwszych zadań, które są pomijane. Jest to krótkowzroczne zachowanie i będzie prowadzić do wielu problemów w późniejszej fazie, gdzie będzie konieczność usuwania dużej ilości błędów.
7. Dokumentacja i kontrola dokumentów nie są aktualne. Udostępnianie części dokumentacji dla poszczególnych członków zespołów powoduje, że dokumentacja traci integrację i często poszczególne osoby posiadają już nieaktualne dokumentacje.
Na podstawie powyższych cech widać, że najważniejsze w projekcie są projekt, kontrola i narzędzia.