Software Development

Cykl życia projektu – Faza planowania

Maj 9, 2016 0
Podziel się:

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 (nie koniecznie 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.

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.

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.

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

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 prognozuje ż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 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.

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.
Oceń ten post

Imię i nazwisko (wymagane)

Adres email (wymagane)

Temat

Treść wiadomości

Zostaw komentarz