Projekty, nie tylko te informatyczne charakteryzują się jedną wspólną cechą. Często się nie udają. Niekwestionowanym liderem są tutaj projekty wdrożeniowe, gdzie na podstawie różnych danych, pełnym sukcesem poszczycić się może wąskie grono 20-30% kandydatów. Pozostały odsetek to wdrożenia przepchnięte na siłę, wdrożenia częściowe i totalne klapy.
Aby nie realizować powyższego scenariusza chciałbym tutaj wspomnieć o dwu bardzo ważnych rzeczach, które pomogą zminimalizować prawdopodobieństwo porażki i zapobiec poważnym konsekwencjom.
I. Dobra analiza przed wdrożeniowa/projektowa
Bez niej mamy bardzo duże szanse, że się nam nie uda. Często takie założenie towarzyszy projektowi od początku. Podjęta decyzja może nie mieć zaplecza realizacyjnego i jest z góry skazana na porażkę.
Jeżeli jednak mamy zaplecze i dążność do sukcesu należy zacząć właśnie od analizy. Przede wszystkim zamapować żywe procesy, które będziemy odzwierciedlać w systemie IT, wykonać analizy potrzeb biznesowych i potrzeb użytkowników, przegryźć się przez SWOT, stworzyć macierze RACI, stworzyć harmonogramy, określić możliwe rozwiązania i alternatywy, milestony, skalowalność, określić budżet [+20%], zidentyfikować ryzyka, określić kryteria sukcesu, zdefiniować działania przedwdrożeniowe – działania socjologiczne i techniczno-organizacyjne, zdefiniować działania powdrożeniowe – propozycje szkoleń, propozycje sprawdzanie skuteczności wdrożenia, serwis wdrożonych rozwiązań, określić możliwości rozwoju/rozbudowy wdrażanych rozwiązań w perspektywie kilku lat.
Analizę można oczywiście rozszerzyć o konkretne skojarzone z potrzebami miary, wskaźniki, cele.
Taka analiza to dobry punkt wyjścia. Proponuję ją wykonywać zawsze dwuetapowo. W pierwszym etapie określić ogólne założenia m.in. budżetowe, czasowe. Będzie nam to niezbędne do wyłonienia wykonawcy. Wykonawca z kolei powinien rozbudować analizę o pozostałe, szczegółowe dane.
II. Analiza ryzyka i scenariusze powrotu.
Pewnie wielu z Was widziało macierz ryzyka. Określa ona obszar w jakim ryzyka związane z projektem są dla nas akceptowalne a jakie nie. Jeżeli mamy zidentyfikowane ryzyka, często w różnych kategoriach, możemy spróbować je usystematyzować i się nimi zająć jak należy tzn. minimalizować, eliminować, koordynować ryzyka o dużym impakcie i prawdopodobieństwie [ten obszar ustalamy indywidualnie].
Niezależnie od tego czy wiemy już jak radzić sobie ze zidentyfikowanymi ryzykami jest duża szansa, że w trakcie reazlizacji projektu pojawią się ryzyka, których nie braliśmy pod uwagę np. założyliśmy jako część finansowania dochody ze sprzedaży produktu który został w trakcie projektu zakwestionowany przez uokik. Oczywiście mogło się to wpisać w uogólnione ryzyko utraty finansowania jednak mogło ono być określone jako mało prawdopodobne. Abstrahując od powodów często z nieprzewidzianych powodów i ryzyk musimy projekt zaniechać, odroczyć, przemodelować. Tutaj niezbędne stają się opracowane scenariusze powrotu. Są to scenariusze właśnie z planem awaryjnym zwykle zawierające odpowiedź na to jak przywrócić system do stanu pierwotnego [sprzed wdrożenia] Wyobraźmy sobie sytuację gdy tematem projektu jest zmiana infrastruktury. Bez scenariusza awaryjnego może się zdarzyć, że w przypadku awarii zostaniemy na lodzie, stare servery już dawno u żyda, za kable ze ścian piją już złomiarze.
Jeżeli jednak określiliśmy prawidłowo scenariusz powrotu stworzymy sobie możliwość przywrócenia funkcjonalnie starej infrastruktury [lub jej części] do działania.
Oczywiście powyższe nie jest panaceum na wszystko, a na pewno nie wyczerpuje tematu. Można by się długo rozwodzić nad zarządzaniem procesowym, dobrymi praktykami np ITIL’owymi, funkcji BRM’a ale to już zupełnie inne historie, które opowiem może innym razem.
niemastresu 