Twoja firma potrzebuje nowej aplikacji do zarządzania bazą klientów. Wszystkie wymagania spisane, dostawca wybrany, wdrożenie za pasem. Wszystko wygląda idealnie: w terminie i w budżecie. Po wdrożeniu oddajesz z dumą nowe oprogramowanie do użytku w firmie i teraz, to dopiero się zaczyna…

Ukryte defekty

Jeżeli byłeś wcześniej kierownikiem projektu IT w firmie na pewno to znasz, jeżeli nie, ucz się na cudzych błędach.

Większość projektów informatycznych we współczesnych organizacjach ma następującą strukturę:

  1. Określenie problemu
  2. Analiza możliwych rozwiązań
  3. Wybranie najlepszego rozwiązania
  4. Wstępna analiza biznesowa wymagań wobec oprogramowania
  5. Wybór dostawcy
  6. Szczegółowa analiza biznesowa
  7. Implementacja
  8. Testy
  9. Wdrożenie

To również punkt widzenia wykonawcy i zazwyczaj jego zobowiązania kończą się na punkcie dziewiątym.

Doświadczeni kierownicy projektów wiedzą jednak, że w tym procesie zawsze istnieją dodatkowe kroki:

  1. Pilot
  2. Adaptacja
  3. Szkolenie
  4. Wdrożenie na pełną skalę
  5. Adaptacja
  6. Adaptacja
  7. Adaptacja…

Od punktu 8 zaczyna się stresująca część projektu i przerzucanie się winą za niespełnione wymagania biznesowe oraz kwestią kto za to zapłaci, kto pokryje koszty dostosowania oprogramowania. Wykonawca jest zabezpieczony zaakceptowaną dokumentacją wymagań biznesowych, a częstą przyczyną wprowadzania zmian w oprogramowaniu nie jest niepoprawna implementacja tych wymagań, a w ogóle pominięte wymagania, których wcześniej najzwyczajniej w świecie nie dało się przewidzieć.

Tak powinien wyglądać Twój projekt:

Wykonawca zna wymagania, czasami tempo jego pracy odbiega od pierwotnego planu, ale ostatecznie projekt mieści się w czasie i budżecie.

Tak wygląda w rzeczywistości:

W trakcie realizacji projektu sprawdzana jest realizacja znanych wymagań biznesowych. W tym samym czasie zaciągamy dług związany z pominięciem nieznanych wymagań biznesowych i tego, że tworzymy rozwiązanie, które może w niektórych przypadkach być nieoptymalne w niektórych sytuacjach lub dla niektórych pracowników.

A tak zaraz po wdrożeniu:

Od momentu wdrożenia, rzeczywiści użytkownicy korzystają z naszych owoców pracy, przychodzą z uwagami do sposobu funkcjonowania narzędzia, a niekiedy wręcz uważają, że nie mogą wykonywać za pomocą tego rozwiązania swojej pracy. Część tych uwag oczywiście wiąże się z niezrozumieniem działania nowego rozwiązania, ale pozostałe uwagi wydają Ci się uzasadnione i pot zaczyna pojawiać się na Twoim czole wraz z myślą “dlaczego to nie wyszło wcześniej?!”

Jak temu zapobiec?

Takiej sytuacji można uniknąć jedynie w przypadku niewielkich i powtarzalnych wdrożeń (np. takich z minimalną potrzebą dostosowania – tzw. projekty “z pudełka”). Natomiast im bardziej skomplikowane rozwiązanie i potrzeba dostosowania ostatecznego rozwiązania pod konkretne potrzeby firmy, tym mniejsze prawdopodobieństwo uniknięcia takiej sytuacji. I nie oznacza to, że brakuje Ci kompetencji, bądź robisz coś źle. Nigdy nie wyeliminujesz tego ryzyka do zera.

Jednym z rozwiązań mających na celu minimalizację ryzyka jest to, aby przestać traktować projekt jako monolityczne wdrożenie, podchodzić do jego budowy iteracyjnie i zbierać uwagi w trakcie rozwoju aplikacji poprzez szereg znacząco mniejszych wdrożeń. Zmniejsza to liczbę problemów, ale zawsze ostatecznie wydłuży szacowany czas realizacji i na pewno wpłynie negatywnie na budżet. I chociaż jest to rekomendowany sposób pracy nad złożonymi rozwiązaniami, to nie da się uniknąć późniejszych zmian – im szybciej to zaakceptujesz, tym łatwiej będzie zaplanować ostateczny budżet projektu. Pamiętaj, że tylko 20% projektów w przedsiębiorstwach kończy się w terminie i w budżecie.

Jaki zapas?

Minimalny zapas jaki należy założyć na obsługę powdrożeniową projektu to 30% inicjalnego kosztu projektu, a im bardziej złożony projekt i jego ostateczna forma niepewna, tym ten zapas powinien być większy (nawet 100% pierwotnego kosztu projektu).

Po założeniu takiego zapasu często pojawia się pokusa, aby w trakcie realizacji, a przed wdrożeniem, wykorzystać tę część budżetu na dodanie jakichś funkcji bądź ich modyfikację, bo “wydaje się”, że lepiej zrobić coś więcej niż pierwotnie się wydawało. Podchodź do tego bardzo ostrożnie. Ważne jest, aby oddać pierwszą wersję aplikacji najszybciej jak to możliwe, aby móc zebrać pierwsze wrażenia i przystąpić do procesu adaptacji rozwiązania pod faktyczne i rzeczywiste potrzeby przedsiębiorstwa. Jeżeli zużyjesz znaczną część budżetu na zmiany przed wdrożeniem aplikacji, wpakujesz się w jeszcze większe tarapaty – nie dość, że jeszcze bardziej skomplikujesz aplikację (co zwiększy znowu koszty późniejszych zmian), to dodatkowo zmniejszysz swoje późniejsze pole manewru.

Pamiętaj, że wdrożenie najczęściej nie kończy pracy nad rozwiązaniem, dopiero teraz będziesz mógł poznać prawdziwe potrzeby użytkowników i niekiedy solidnie się zaskoczysz…

Jeżeli chcesz wiedzieć więcej, skorzystaj z naszych szkoleń z praktycznego zarządzania projektami IT.

Bądź na bieżąco

Jeżeli chcesz otrzymywać informację o naszych szkoleniach (również bezpłatnych), zostaw nam swój adres e-mail: