Cykl życia projektu – Faza planowania

W literaturze i Internecie dużo jest informacji na temat cyklu życia projektu, zarówno w kontekście projektów informatycznych jak i ogółem. Najczęściej spotkać można opis:

• Planowanie
• Analiza
• Projektowanie
• Implementacja

Bądź cykl życia projektu wg N. Mingusa odnoszący się ogólnie do projektów (niekoniecznie informatycznych):

• Faza planowania
• Faza pracy
• Faza ewaluacji

W danym wpisie chciałbym skupić się na pierwszym etapie projektu, wgłębić się w nią i opisać w szczegółach jak z doświadczenia i obserwacji powinna wyglądać dana faza.

Pierwszy krok

Pierwszym krokiem projektu powinno być złożenie karty projektu przez właściciela biznesowego projektu (czytaj sponsora) lub jego przedstawiciela. Karta projektu powinna zawierać przede wszystkim takie informacje jak:

• Nazwa projektu i jego opis,
• Oczekiwana data komercyjnego startu projektu,
• Przedstawienie wymagań na wysokim poziomie ogólności,
• Przedstawienie mierników związanych z projektem,
• Wskazanie interesariuszy projektu.

Karta projektu powinna zostać zweryfikowana i w przypadku braku pytań/uwag zaakceptowana. Akceptacja odnosi się do zrozumienia potrzeby biznesowej, a nie jest związana z potwierdzeniem realizacji projektu w proponowanym terminie komercyjnego uruchomienia.

Kolejny krok

Następnym krokiem jest przeanalizowanie potrzeby biznesowej przez analityka i przygotowanie odpowiedniego dokumentu. Dokument powinien składać się z następujących części:

• zrozumienie i opis potrzeby i wymagań z nią związanych na ogólnym poziomie szczegółowości, zarówno w kontekście funkcjonalnym, niefunkcjonalnym jak i prawnym;
• przygotowanie wariantowych wysokopoziomowych koncepcji rozwiązania (we współpracy z przydzielonym Architektem Rozwiązania), związanych z możliwościami realizacyjnymi. Przy czym koncepcja rozwiązania musi jednoznacznie przedstawiać zakres projektu;
• oszacowanie kosztów wdrożenia każdego z proponowanych wariantów, w odpowiednim przedziale kosztów, wraz z szacunkowym kosztem utrzymania rozwiązania;
• przedstawienie metodyki wdrożenia wraz z możliwymi terminami wdrożenia (np. termin edycji), wraz z datą, do której należy podjąć odpowiednią decyzję, aby „załapać się” na daną ścieżkę wdrożeniową.  Przy czym przedstawienie danej ścieżki wdrożeniowej nie oznacza automatycznego przyjęcia projektu do zakresu np. Edycji, bardziej ma charakter informacyjny, pokazujący możliwości wdrożenia.

Dokument następnie powinien zostać przeczytany przez właściciela projektu lub jego przedstawiciela i innych interesariuszy. Właściciel projektu/jego przedstawiciel może wybrać jedną ze ścieżek realizacji, zlecić modyfikację koncepcji lub przygotowanie zupełnie nowej propozycji. Ewentualnie zgłosić nowe wymagania/zmienić kierunek analizy.

Jeżeli chodzi o długość danej fazy, to przygotowanie dokumentu analitycznego może zostać ubrane w ramy czasowe, natomiast cała faza nie powinna mieć narzuconych ograniczeń czasowych. Właściciel projektu musi posiadać pewność, że przygotowana koncepcja spełnia jego potrzeby. Zespół projektowy musi dokładnie wiedzieć jaki jest zakres projektu i koncepcja rozwiązania.

Jak to działa w praktyce?

Przejdźmy teraz do przykładów praktycznych.

Przykład I

Przykład nr I – Właściciel biznesowy chce wdrożyć nową usługę, spodziewam się, że usługa startowo będzie niszowa, wolumen będzie niewielki, zyski małe. Natomiast prognozuję, że usługa w miarę działania powinna bardzo dynamicznie zwiększać swój wolumen. Kluczowym aspektem dla mnie jest brak wydawania znaczącej ilości gotówki na wdrożenie usługi na rynek.

Analityk przygotowujący dokument analityczny zaproponował mi następujące koncepcje rozwiązania:

• całkowite procesowanie usługi poza systemowo (np. obsługa mailowa), ewidencja danych w bazie Excel. Koszt wdrożenia usługi wynosi X z podziałem kosztów na przygotowania i prowadzanie analizy przygotowującej procesy i procedury, szkoleń pracowników itd., w analizie analityk nie dotyka natomiast kosztów marketingowych. Dodatkowo analiza pokazuje, że koszty Opex obsługi danego procesu wyniosą Y FTE, wdrożenie usługi na rynek jest możliwe za Z tygodni;
• częściowe procowanie usługi w systemie a częściowe poza systemem, ewidencja kluczowych danych w systemie. Koszt wdrożenia usługi wyniesie 2X z podziałem kosztów na przygotowanie i przeprowadzenie analizy, wdrożenie zmian w systemie, szkolenia pracowników., w analizie analityk nie dotyka oczywiście kosztów marketingowych. Dodatkowo analiza pokazuje ze koszty Opex obsługi danego procesu wyniosą 0,8Y FTE, a wdrożenie usługi na rynek jest możliwe za 2Z tygodni
• pełne procesowanie usługi i ewidencja danych w systemie. Koszt wdrożenia usługi wyniesie 3X z podziałem kosztów na przygotowanie i przeprowadzenie analizy, wdrożenie zmian w systemie, szkolenia pracowników., w analizie analityk nie dotyka oczywiście kosztów marketingowych. Dodatkowo analiza pokazuje ze koszty Opex obsługi danego procesu wyniosą 0,5Y FTE, a wdrożenie usługi na rynek jest możliwe za 3Z tygodni;

Widzimy w danym przykładzie, że nie zawsze wszystkie zaproponowane rozwiązania muszę mieć charakter systemowy, w szczegółowych przypadkach, gdy jasno z karty projektu wynika, że kluczowe jest poniesienie jak najmniejszych kosztów na wdrożenie, analityk może nie zaproponować w ogóle rozwiązania systemowego. Właściciel biznesowy po analizie powinien zdecydować która koncepcja rozwiązania odpowiada mu najbardziej.

Przykład II

Przykład nr 2 – Właściciel biznesowy składa kartę projektu na wdrożenie Platformy BPM. Analityk w danym przypadku musi porównać dostępne narzędzia na rynku, oczywiście posiłkując się przeróżnym rankingami i zestawieniami. Porównać platformy pod kątem:

• funkcjonalnym,
• kosztowym (zarówno koszt licencji jak i koszt utrzymania),
• porównać pracochłonność wprowadzania procesów i zmian w procesach,
• niefunkcjonalnym (szybkość działania, częstotliwości podnoszenia wersji platformy, częstotliwość wydawania poprawek),

Zwykle w wyniku danego zestawienia właściciel biznesowy może przy pomocy analityka stworzyć wagi na poszczególne kategorie, w wyniku czego dokona wyboru finałowej trójki, dla której będą wykonywane dodatkowe szczegółowe analizy.

Podsumowanie

Podsumowując, mimo że na pierwszy rzut oka wydaje się, że opisana propozycja wydłuża proces D&D to w rzeczywistości nie jest to do końca prawda, ponieważ:

• dokument analityczny zastępuje zwykle proces myślowy, który odbywa się w głowach biznesu, gdzie biznes odpowiada sobie na pytanie co chce osiągnąć i jaki ma cel. Dzięki wykonaniu analizy można podjąć dużo bardziej świadomą decyzję, mając pewność gruntownego przemyślenia tematu przed rozpoczęciem fazy analizy;
• przystępując do fazy analizy szczegółowej mamy pewność jaki jest zakres projektu i koncepcja rozwiązania, analityk ma możliwość obrony przed próbą „wrzutu” zagadnienia do zakresu projektu;
• eliminowane w pierwszej fazie są projekty, na których brak jest uzasadnienia ekonomicznego.

***

Więcej o zarządzaniu projektami dowiesz się również z innych artykułów naszych ekspertów.