Na proces podsumowania projektu winno składać się kilka kroków. Najważniejsze z nich to: zbieranie danych, wyciąganie wniosków oraz tworzenie zaleceń na przyszłość. Jednym z najistotniejszych czynników decydujących o jakości wniosków stanowiących podsumowanie retrospektywy jest otwartość dyskusji. "Wszyscy muszą mieć świadomość, że za wyrażenie nawet najbardziej krytycznej opinii nic im nie grozi" - podkreśla Daniel Spica. Wartość retrospektywy podsumowującej przebieg projektu wynika głównie z zaangażowania różnych stron i możliwości stworzenia bardziej ogólnego obrazu przyczyn problemów, które występowały w miarę realizacji projektu. Dodatkowe korzyści wynikają z faktu, że to w gestii uczestników podsumowania leży zaproponowanie usprawnień na przyszłość. Dzięki temu, tworzony jest transparentny zasób praktycznej wiedzy, który powinien być dostępny dla całej organizacji. W ten sposób można zminimalizować ryzyko powtarzania tych samych błędów w przyszłości.

Klucz do sukcesu

Projekty IT obarczone są dodatkowym ryzykiem, rzadko spotykanym w przypadku innych zmian prowadzonych w reżimie projektowym. Często zdarza się, iż wdrożenie określonego rozwiązania jest mylnie identyfikowane jako cel całego projektu. Typowym przykładem niewłaściwej definicji celu jest wdrożenie systemu klasy CRM. Sam w sobie, jako system wspierający zarządzanie relacjami z klientami, niewiele zmienia - wymaga bowiem zasadniczych zmian organizacyjnych. "Największym problemem przy wdrożeniu systemu CRM jest brak właściwie zdefiniowanego celu projektu. Często jest on błędnie postrzegany jako wdrożenie pewnej technologii. Tymczasem, to ważna zmiana organizacyjna" - mówi Jacek Mamot, prezes zarządu firmy K2 Consulting. Według niego, wiele firm boryka się również z problemem nazbyt ogólnie określonego celu. "Wizja dużych projektów jest na tyle atrakcyjna, że wiele osób decyduje się na taką inwestycję. Natomiast, jeśli ktoś faktyczne chce osiągnąć korzyści wynikające z wdrożenia systemu IT, to niestety musi przebić się przez liczne przeszkody. Dlatego właśnie zarządom jest o wiele łatwiej podejmować decyzje na dużym stopniu ogólności" - mówi Jacek Mamot. Tymczasem, złe lub zbyt ogólne określenie zakresu projektu wymusza doprecyzowanie celu już w trakcie realizacji projektu. Często w miarę takiego doprecyzowania okazuje się też, że firma organizacyjnie nie jest gotowa na wdrożenie konkretnego rozwiązania oraz że cały projekt niesie ze sobą duże ryzyko.

Cel projektu powinien być, przede wszystkim, jednoznacznie określony. Nie może być bowiem w różny sposób interpretowany przez różnych interesariuszy projektu. "Trzeba uświadomić decydentom, że to nie szef IT ustala cel projektu i jego poparcie nie gwarantuje sukcesu. Zazwyczaj trudno jest też wytłumaczyć członkom zarządu, że zanim zaczniemy ustalać specyfikację systemu, musimy określić zakres zmian biznesowych" - mówi Jacek Mamot. Odpowiednio sformułowany cel projektu powinien być również mierzalny. Wiele osób zapomina o tym, że cel projektu sam w sobie musi być możliwy do realizacji, określony w czasie i uzasadniony ekonomicznie. Niespełnienie tych warunków prowadzi w prosty sposób do sztucznych komplikacji całego projektu. W efekcie, sztucznie mnożone są dodatkowe projekty, mające na celu rozwiązanie doraźnych problemów pojawiających się w miarę realizacji źle wyspecyfikowanego projektu. Często okazuje się również, że dzięki doprecyzowaniu celu pierwotnego projektu, jego osiągnięcie jest możliwe nawet bez realizacji pierwotnego projektu - zwykle w sposób tańszy, ale wymagający konkretnych zmian organizacyjnych.