Wprowadzenie
Poza kontekstem biznesowym i systemowo-projektowym, warto zastanowić się nad całokształtem przedsięwzięcia informatycznego. Faza inicjacji projektu to fundamentalny etap, który decyduje o powodzeniu całego przedsięwzięcia i określa kierunek dalszych prac.
Znaczenie i cele fazy inicjacji
W fazie inicjacji należy bezwzględnie ustalić priorytetowe cele użytkownika. Warto pamiętać, że po stronie klienta mamy do czynienia z wieloma różnymi użytkownikami przyszłego systemu. Jako główne grupy powinno się wyróżnić zleceniodawcę (sponsora) oraz bezpośrednich użytkowników. Praktyka pokazuje, że często cele i spojrzenia na system tych dwu grup użytkowników mogą być różne. Trzeba starać się uwzględnić kryteria obydwu stron, należy jednak pamiętać, że system będzie oceniany głównie przez przyszłych użytkowników.
Ważnym elementem fazy inicjacji jest jasne określenie celów przedsięwzięcia z punktu widzenia klienta zamawiającego. Nie zawsze są one oczywiste, co często powoduje nieporozumienia pomiędzy klientem a wykonawcą. W fazie inicjacji powinny zostać określone przede wszystkim cele biznesowe przyszłego projektu.
Na tym etapie nie jest jeszcze podjęta decyzja o rozpoczęciu całościowych prac nad przedsięwzięciem. Niemożliwe jest też (ze względu choćby na ograniczenia czasowe i brak odpowiednich zasobów) zdefiniowanie szczegółowych celów realizowanych przez przyszły system. Cele identyfikowane na etapie studium osiągalności, jak wskazuje nazwa, powinny pomóc w podjęciu decyzji strategicznych, a więc m.in. decyzji o tym, czy dany projekt zostanie przekazany do dalszych prac.
Z tego też względu cele powinny być zdefiniowane na odpowiednim poziomie ogólności i koncentrować się na strategicznych biznesowych korzyściach dla klienta. Cele wyróżnione w fazie inicjacji powinny zostać zapisane w odpowiednim dokumencie. Dokument taki stanowi ważny punkt odniesienia dla całości przyszłych potencjalnych prac nad systemem. Nie wolno też zapominać o formalnej akceptacji dokumentu z celami strategicznymi przez obie strony — wykonawcę i klienta.
Równie ważne jak zdefiniowanie strategicznych celów przedsięwzięcia jest określenie ograniczeń klienta (np. finansowych, infrastruktury, zasobów ludzkich, czasu wdrożenia itd.). Cele oraz wstępnie zidentyfikowane potrzeby biznesowe powinny być opisane w dokumencie Wizja lub zamodelowane w dowolnym narzędziu CASE. Warto jest też połączyć modele z dokumentem.
Definicje kluczowych pojęć
Dla lepszego zrozumienia procesu wytwarzania oprogramowania, poniżej zamieszczam kluczowe pojęcia:
Cel biznesowy
Stan lub warunki, jakie musi spełnić organizacja, by osiągnąć plan zdefiniowany w wizji. Przykład: Przyspieszenie procesu podpisania umowy sprzedaży o 30% w ciągu najbliższego roku.
Potrzeba biznesowa
Określa na wysokim poziomie abstrakcji elementy, czynniki, zdarzenia i działania związane z realizacją celu biznesowego. Przykład: Ograniczenie czynności sprzedaży w procesie przygotowania umowy do niezbędnego minimum.
Wizja
Dokument opisujący główne cele i założenia projektu, zazwyczaj definiowany przez sponsora projektu, jednak może być również opracowany przez innych interesariuszy. Określa „coś konkretnego”, czemu ma służyć projekt w rozumieniu funkcjonowania organizacji.
Architekt biznesowy
Osoba, która odpowiada za zrozumienie rzeczywistych potrzeb (na poziomie całej organizacji) pomiędzy poszczególnymi liniami biznesowymi w odniesieniu do ogólnej strategii biznesowej. Innymi słowy, architekt biznesowy to osoba, która zna sposób działania firmy i jest w stanie określić cel zmiany oraz wpływ (impakt) zmiany na procesy biznesowe.
Analityk biznesowy
Osoba, która identyfikuje procesy biznesowe, które będą ulegać zmianie, określa szczegółowe cele zmiany, dostrzega potrzeby biznesowe i identyfikuje wstępne wymagania biznesowe.
Interesariusz
Osoba lub grupa osób, która może wpływać na system lub na którą system ma wpływ. Interesariuszami mogą być np.: sponsor projektu, użytkownicy, klienci, partnerzy biznesowi, działy organizacji.
Modyfikacja
Utworzenie nowej lub korekta istniejącej funkcjonalności systemu (albo jego parametrów).
Metodyka wytwarzania oprogramowania
Zestaw pojęć, notacji, modeli, języków, technik i sposobów postępowania służący do analizy dziedziny stanowiącej przedmiot projektowanego systemu.
Portfolio projektów
Zbiór projektów lub programów oraz innych prac zgrupowanych razem w celu ułatwienia skutecznego zarządzania tymi pracami dla osiągnięcia celów strategicznych firmy.
Kierownik projektu
Specjalista w dziedzinie zarządzania projektami, odpowiedzialny za planowanie, realizację i zamykanie projektu. Podstawowym zadaniem kierownika projektu jest zapewnienie osiągnięcia założonych celów projektu oraz wytworzenie produktu spełniającego określone wymagania jakościowe.
Punkt funkcyjny
Miara rozmiaru oprogramowania oparta na ilości funkcjonalności biznesowych dostarczanych użytkownikowi końcowemu, stosowana do oszacowania wielkości projektu informatycznego.
Narzędzie CASE
Computer-Aided Software Engineering – oprogramowanie wspomagające procesy analizy, projektowania i wytwarzania systemów informatycznych. Narzędzia CASE umożliwiają m.in. tworzenie i zarządzanie modelami, generowanie kodu i dokumentacji.
Diagram Gantta
Graficzna metoda planowania i kontroli projektu, przedstawiająca zadania w postaci poziomych odcinków na osi czasu. Pozwala na wizualizację zależności między zadaniami oraz monitorowanie postępów prac.
Business Case (Uzasadnienie biznesowe)
Dokument zawierający ekonomiczne uzasadnienie realizacji projektu, prezentujący koszty i korzyści związane z wdrożeniem rozwiązania. Stanowi podstawę do podjęcia decyzji o uruchomieniu projektu przez sponsorów lub decydentów.
Rejestr ryzyk
Zbiór zidentyfikowanych ryzyk dotyczących projektu, wraz z informacją o ich statusie, historii i środkach przeciwdziałania. Zawiera opis potencjalnych zagrożeń, ich prawdopodobieństwo, wpływ oraz strategie mitygacji.
Mitygacja ryzyka
Proces ograniczania negatywnego wpływu zidentyfikowanych zagrożeń na projekt poprzez działania zapobiegawcze, przeniesienie odpowiedzialności, akceptację lub unikanie ryzyka.
Studium osiągalności
Wstępna analiza projektu oceniająca jego wykonalność pod względem technicznym, organizacyjnym, finansowym i czasowym. Pomaga w podjęciu decyzji o rozpoczęciu lub zaniechaniu realizacji projektu.
Konkretyzacja zakresu przedsięwzięcia
Na etapie inicjacji warto jest pójść krok dalej i doprecyzować cały zakres przedsięwzięcia w takim stopniu, w jakim to będzie możliwe. Należy:
- Przygotować wysokopoziomowy model procesów biznesowych – Zidentyfikować kluczowe procesy, których dotkną zmiany. Idealnie nadaje się tutaj język Archimate lub notacja BPMN.
- Określić obszary biznesowe podlegające zmianie – Identyfikując procesy, zastanów się jakie obszary Twojego biznesu będą podlegały zmianie. Jeśli masz przygotowane modele to dobrze. Jeśli ich nie masz, wypisz te obszary choćby na kartce papieru.
- Stworzyć mapę systemów – Do zidentyfikowanych obszarów biznesowych dopisz wszystkie systemy, które twoim zdaniem w nich uczestniczą i je wspierają. W ten sposób powstanie mapa systemów i mapa procesów, które w ramach danej inicjatywy mogą ulec zmianie.
- Uwzględnić inne inicjatywy w organizacji – Tak zidentyfikowane systemy i procesy należy zderzyć z planem rozwoju organizacji i portfolio projektów. Jeśli twoja organizacja nie ma biura zarządzania projektami, nie ma portfolio projektów, to musisz sprawdzić, jakie jeszcze inicjatywy toczą się w organizacji. Jeśli chociaż jedna z nich dotyka wcześniej zidentyfikowanego systemu lub procesu biznesowego, musisz to odnotować.
Zmiana, czy to procesu biznesowego, czy systemów informatycznych, wynikająca z kilku inicjatyw w tym samym czasie to olbrzymie ryzyko, które musisz wziąć pod uwagę. Ponadto to działanie jest konieczne, by sprawdzić ile inicjatyw się toczy, ile tematów musi ogarnąć IT. Liczba zmian w danej organizacji jest zamknięta – w momencie, w którym inicjatyw jest zbyt dużo, albo zwiększamy zasoby IT (ludzie, zespoły), albo minimalizujemy liczbę zmian.
Mówiąc o zasobach, mam tu na myśli ludzi, sprzęt, czas, pieniądze. Moim zdaniem nie ma nic gorszego od IT, które bierze na siebie wszystkie projekty wrzucone przez biznes, a po kilkunastu miesiącach biznes ma pretensje, że na drobną zmianę czeka wiele miesięcy. Oczywiście sytuacje takie są bardzo złożone i nie należy ich upraszczać.
Trzy kluczowe kroki w fazie inicjacji
Krok 1: Określenie celu zmiany
Warto jest jasno określić, dlaczego zmiana ma być wprowadzona, np.:
- Pojawiły się skargi klientów
- Utracono możliwość zysku
- Pojawiły się nowe możliwości na rynku
- Wprowadzenie nowej regulacji do działania systemów organizacji do konkretnej daty
- Skrócenie czasu obsługi wniosków o 10% począwszy od określonego terminu
- Zwiększenie sprzedaży produktów X, aby osiągnąć sprzedaż na określonym poziomie
Krok 2: Określenie stanu obecnego
Poznanie aktualnego stanu działania organizacji jest potrzebne, aby ustalić co powinno ulec zmianie i na co planowana zmiana wywrze wpływ (pośrednio lub bezpośrednio). Wiedzę tę można pozyskać z aktualnie istniejących repozytoriów, utrwalić ją lub zaktualizować w ramach analizy zgłoszonej potrzeby.
Chodzi o to, że jeżeli chcemy wdrożyć jakąkolwiek zmianę, to musimy mieć jakąś ramkę, stan zamknięty na daną chwilę. Musi być jakiś punkt startu, punkt bazowy, który będzie dla nas odniesieniem dla wprowadzonych zmian.
W ocenie stanu obecnego kluczową rolę pełni architekt biznesowy, a także bardzo często analityk biznesowy:
- Architekt biznesowy dokonuje analizy architektury biznesowej
- Analityk biznesowy identyfikuje procesy biznesowe, które będą ulegać zmianie, szczegółowe cele zmiany, dostrzega potrzeby biznesowe, identyfikuje wstępne wymagania biznesowe
Krok 3: Określenie wizji biznesowej
W tym kroku powstaje wizja biznesowa, czyli opis tego, co stanie się z naszym biznesem lub jego fragmentem po wprowadzeniu zmiany. Architekt biznesowy może pomóc w stworzeniu opisu stanu docelowego.
Kluczowe decyzje projektowe
Najważniejsze decyzje, które należy podjąć w fazie inicjacji to:
- Wybór modelu, zgodnie z którym będzie realizowane przedsięwzięcie (np. kaskadowy, iteracyjny, zwinny).
- Wybór technik stosowanych w fazach analizy i projektowania.
- Wybór środowiska (środowisk) implementacji.
- Wybór narzędzi CASE i innych narzędzi do zarządzania projektem i utrzymywania dokumentacji.
- Określenie stopnia wykorzystania gotowych komponentów.
- Podjęcie decyzji o współpracy z innymi producentami lub zatrudnieniu ekspertów.
Analiza ograniczeń projektu
Niezmiernie ważna dla powodzenia dalszych prac jest również wiedza o ograniczeniach, z którymi trzeba się liczyć planując, a później realizując projekt. Należy rozważyć następujące kwestie:
Jak duży będzie projekt?
Należy oszacować rozmiar projektu (np. w punktach funkcyjnych) oraz dopasować do niego wielkość pozostałych zasobów potrzebnych do jego wytworzenia, jak na przykład wielkość zespołu projektowego i czas realizacji.
Jaka będzie dostępność zasobów?
Należy zebrać informacje o dostępnym budżecie, formach finansowania przedsięwzięcia, planowanych przepływach gotówkowych i dostępności personelu.
Jakie są ograniczenia czasowe?
Należy ustalić najważniejsze terminy w projekcie, takie jak termin dostarczenia prototypu, termin dostarczenia produktu, czas wdrożenia itp. Konieczne jest też przypisanie odpowiednich priorytetów do poszczególnych terminów, gdyż nie każde z zidentyfikowanych ograniczeń musi mieć taki sam wpływ na powodzenie projektu. Na przykład data przekazania systemu wspierającego wybory do samorządów jest ograniczeniem kluczowym – dostarczenie choćby jeden dzień po terminie powoduje, że system staje się bezużyteczny.
Jakie są niezbędne warunki wstępne dla rozpoczęcia projektu?
Należy zebrać informacje o warunkach, których spełnienie oznacza rozpoczęcie realizacji projektu. Rozpoczęcie projektu może być uzależnione na przykład od:
- zakończenia restrukturyzacji przedsiębiorstwa
- powodzenia innego projektu
- podjęcia lub nie decyzji politycznych (np. uchwalenia przez Sejm ustawy)
- zaistnienia pewnych regulacji prawnych (np. przepisów wykonawczych)
Jaka jest dostępność oprogramowania i narzędzi?
Należy zebrać informacje o dostępnym środowisku infrastruktury wspierającej działanie przyszłego systemu, określić potrzeby inwestycyjne w tym zakresie oraz możliwości zmiany lub modernizacji tego środowiska.
Jaka jest dostępność technologii oraz know-how?
Należy ustalić jakie technologie są dostępne, czy nie występuje konieczność zakupu pewnych technologii, przeszkolenia personelu itp.
Jaka jest dostępność specjalistów?
Należy oszacować, jacy specjaliści będą niezbędni do realizacji projektu (np. eksperci dziedzinowi) oraz ustalić, gdzie i kiedy mogą być dostępni. Dobrzy eksperci są poszukiwani i najczęściej mają dużo zleceń.
Dokumentacja związana z przygotowaniem projektu
Ramowy harmonogram przedsięwzięcia
Jednym z elementów prac w fazie inicjacji jest zaproponowanie wstępnego, szkieletowego podziału zadań oraz przypisanie im czasów i terminów realizacji. Planowanie rozpoczyna się od przygotowania listy zadań, które powinny być wykonane w celu realizacji przedsięwzięcia.
Zadania te grupuje się w odpowiednią hierarchię oraz przyporządkowuje wstępnie do zasobów potrzebnych do ich wykonania. Zadania wykonywane w czasie projektu pozostają między sobą w określonych związkach przyczynowo-skutkowych. Niektóre z nich mogą być rozpoczęte dopiero po zakończeniu wcześniejszych, inne mogą być wykonywane równolegle, a zakończenie niektórych zadań może być uzależnione od zakończenia innych. Zależności tego typu wraz z czasem realizacji zadań przedstawia się najczęściej na wykresie zwanym diagramem Gantta.
Za opracowanie harmonogramu odpowiada kierownik projektu, który powinien pojawić się, gdy wizja biznesowa uzyska wstępną akceptację.
Rejestr ryzyk
Rejestr ryzyk to zapis zidentyfikowanych ryzyk dotyczących danego projektu, wraz z informacją o ich statusie, historii i środkach przeciwdziałania. Jest wykorzystywany do gromadzenia i przechowywania informacji o wszelkich zagrożeniach i szansach związanych z projektem.
Opracowanie rejestru ryzyk ma na celu zmitygowanie (zneutralizowanie) w maksymalnym stopniu sytuacji, które mogą negatywnie wpłynąć na projekt. Rejestr ryzyk jest utrzymywany przez cały cykl życia projektu. Chodzi o to, aby przewidzieć wcześniej sytuacje, które mogą uniemożliwić realizację projektu. W tym celu:
- identyfikuje się ryzyka
- nadaje im priorytety
- planuje działania, które mają pozwolić na ich neutralizację
Uzasadnienie biznesowe (Business Case)
Uzasadnienie projektu jest uzupełnieniem wizji biznesowej, gdyż zawarta w wizji propozycja zmiany opisana jest w kategoriach kosztów i korzyści. To istotny dokument, zwłaszcza z punktu widzenia sponsorów projektu. Uzasadnienie biznesowe powinno pozwolić określić, ile organizacja zarobi/zyska po wdrożeniu zmiany. Gdy zestawimy oszacowane koszty z potencjalnymi zyskami, otrzymujemy uzasadnienie realizacji potrzeby biznesowej.
Struktura projektu
Ostatnim ważnym dokumentem, który powinien powstać w fazie inicjacji, jest struktura projektu określająca odpowiedzialności poszczególnych zespołów, a także lista produktów projektowych, które te zespoły wytworzą.
Podsumowanie
Do najważniejszych rezultatów fazy inicjacji należą:
- Dokument Wizja biznesowa – opis potrzeb biznesowych, celów, a także wpływu zmian na organizację
- Wstępny kosztorys
- Wstępny harmonogram projektu
- Wstępny rejestr ryzyk
- Uzasadnienie biznesowe (Business Case)
- Struktura zespołów projektowych
Potrzeby i wymagania klienta powinny wynikać z celów wyższego poziomu reprezentujących sposób realizacji z ogólną strategią biznesową i misją organizacji. Każda dojrzała organizacja ma wyraźnie określone i zrozumiałe dla swoich członków cele i strategię biznesu. Projekty inicjowane są po to, by dostarczyć produktów i usług umożliwiających osiągnięcie tych celów.
Oznacza to, że każdy projekt powinien służyć czemuś konkretnemu w rozumieniu funkcjonowania organizacji – to coś jest określone przez wizję wyrażającą główne cele i założenia projektu.
Warto podkreślić, że w małych zmianach lub projektach zwinnych nie zawsze jest konieczne tworzenie obszernych dokumentów. Często wystarczy jedna lub dwie strony A4. Przy dużych projektach dokumentacja będzie bardziej rozbudowana, ale przy zwinnym i rozsądnym podejściu wyniki analiz da się zapisać w zwięzłej formie. Najważniejsze jest, aby powyższe zagadnienia zostały przemyślane, a nie sama objętość powstałej dokumentacji.
Spis treści:
