Ku mojemu zaskoczeniu dość często dostaję pytania o możliwość zaangażowania się w roli analityka np. na rok na warunkach: 100% czasu na miejscu u klienta a wynikiem ma być specyfikacja wymagań na oprogramowanie, którego realizacja jest planowana na np. kolejne 5 lat. Nie ma to moim zdaniem żadnego sensu i nie angażuje się w takie projekty. Ale po kolei.

Już w roku chyba 2003 robiłem analizę ryzyka dużych i długich projektów, celem była ocena prawdopodobieństwa i kosztów wprowadzania zmian do zakresu projektu. Jak nie trudno się domyśleć, jest to – zmiany zakresu – najbardziej niechciana rzecz w każdym projekcie. Materiał ten był prezentowany na jednej z konferencji dotyczących wdrażania systemów ERP.

Co spowodowało moje zainteresowanie tym problemem? To co każdy w tej branży widział chyba najmniej raz w życiu: różnica pomiędzy pierwotną specyfikacją a ostatecznym produktem. W dużych projektach często te dwa stany nie mają z sobą zbyt wiele wspólnego! Więc pojawia się pytanie: po co robić wielką analizę i dokumentację skoro większość tej dokumentacji, rozdział po rozdziale, ląduje w koszu za sprawą “zarządzania zmianą”?

Jakie są najczęstsze problemy w nieudanych projektach? 70%  to zmiany zakresu projektu, (Raport Jama Sofware ? O wymaganiach).

Popatrzmy na to:

Analiza i specyfikowanie wymagań to tak na prawdę prognoza mówiąca, że to co teraz projektujemy będzie w przyszłości, w dniu oddania do użytku, potrzebne w takiej formie w jakiej właśnie to projektujemy. Jak wiemy, prognozy są tym większym błędem obarczone i bardziej w przyszłość wybiegają. Powyższy diagram to typowy megaprojekt. Linia przerywana obrazuje pewną hipotetyczną granicę, powyżej której ryzyko błędnej prognozy przekracza np. 50% (czyli klasyczny rzut monetą).

Innymi słowy, rozpoczynając megaprojekt mamy niemalże pewność, że jego zakres ulegnie zmianie czyli cała praca powyżej tej linii przerywanej pójdzie do kosza (na koszt sponsora projektu ;)).

W naturalny sposób nasuwa się wniosek: nie należy robić nic ponad tę przerywaną linię. Wtedy otrzymamy taki diagram:

Robimy tylko to co z ryzykiem bliskim zera zostanie zaimplementowane bez zmian. Jak? Pierwszy etap to analiza problemu i projektowanie architektury całości – model komponentów. Jest to jakaś logika systemu na dość wysokim poziomie abstrakcji ale dająca się przetestować. Stanowi ona podstawę dalszej pracy nad każdym komponentem osobno (kolejne etapy). Uszczegóławianie  wymagań odkładamy “na ostatni moment”. W ten sposób “kwartał po kwartale” doprecyzowujemy wymagania na kolejny etap i realizujemy go. Co  zyskujemy? Nie wyrzucamy do kosza nadmiernie szczegółowej i rozległej dokumentacji wymagań, nie ponosimy koszów projektowania czegoś co może “wylecieć” z zakresu za pół roku z powodów np. zmian na rynku, możemy w dowolnym momencie zmienić kolejne planowane komponenty, usunąć jedne i opracować nowe bez ryzyka zbędnych kosztów.

Pierwszy etap ma pewną cechę: tworzy (taki ma cel) jeden wspólny model wszystkich projektów dla danej organizacji o wdzięcznej nazwie Architektura Korporacyjna. Kolejne konkretne komponenty architektury IT to kolejne projekty, cechujące się zrozumianym umiejscowieniem w całości organizacji i wiarygodnym, spójnym z całością zakresem.

Dlatego z reguły nie mają sensu:

1. wdrożenia departamentowe oderwane od reszty (np. Dział Handlowy sobie funduje sam system CRM),
2. projekty trwające dłużej niż trzy kwartały (ostatni kwartał to kolejne planowanie budżetu na kolejny rok czyli planowanie zmian),
3. mega projekty ERPII czyli “all in one” dla firmy w ramach jednego projektu.

Więc jak zjeść słonia by się nie udławić? Powoli i po kawałku… I nie zapominajmy, że wyzwaniem może być nie tyle nowe oprogramowanie co zmiana nawyków ludzi… a nie ma nic gorszego niż planowanie nowego oprogramowania dla starych nawyków bo po co to robić?

Pamiętajmy, że zarządzanie zakresem projektu jest tym kosztowniejsze im więcej szczegółów ten zakres posiada. Projekt o 30 wymaganiach vs. projekt o 300 wymaganiach to nie projekt o 10-krotnie większym koszcie, ta różnica będzie znacznie większa (pomijam to jak w ogóle zdefiniujemy wymaganie).

Tak więc przeciętny projekt to dla analityka praca na nie więcej niż kwartał (mniej więcej). Jak ja opisać wymagania na systemy ERP?  Nie są to setki szczegółowych wymagań, bo to nie ma sensu. To opis architektury korporacyjnej wraz z zestawem celów biznesowych dla każdego potencjalnie kupowanego modułu (podsystemu) oraz wymagania jako testy pokazujące realizację tych celów. Tych testów (wymagań) będzie raczej 30 niż 300, zaś ewentualne dedykowane funkcjonalności są projektowane “na ostatni moment” jeżeli okaże się, że żaden rynkowy produkt ich nie oferuje a nam na prawdę są one potrzebne.

P.S.

Stale mnie nurtuje pytanie: dlaczego tak często są ogłaszane przetargi na megaprojekty i są składane oferty na mega wdrożenia, skoro to co napisałem nie stanowi żadnego odkrycia? 🙂