Realistyczna skala kroków w projekcie - ważna przesłanka powodzenia

Projekty są trudne, ryzykowne i często wzbudzające lęk w ludziach biznesu. Ważni prezesi zwykle budowali swoje kariery w pracy raczej operacyjnej niż projektowej. Dowozili cele miesięczne i kwartalne, a nie projektowe.

Dla wielu receptą na zarządzenie projektem jest obudowanie go w liczne komitety, zespoły robocze, harmonogramy, metodologie. Otaczająca biurokracja stwarza złudne poczucie kontroli.

Wiele z tych formalizmów jest pomocnych, jednak żadne rozbudowane dokumenty i plany nie zastąpią racjonalnego, ogarnialnego spojrzenia na sedno i konsekwencję zmiany, której chcemy dokonać.

Ogólnie dobrym zwyczajem jest zarządzać tym, co jest w zakresie realnej widoczności albo przynajmniej do wyobrażenia.

Poczucie kontroli nad projektem jest wtedy, gdy potrafimy wyobrazić sobie pierwsze chwile po uruchomieniu nowego systemu lub procesu.

Czy zmiana która wówczas nastąpi będzie do opanowania? Czy jeżeli coś pójdzie nie tak, będziemy w stanie zatrzymać pędzący pociąg? Czy będą wówczas plany B? Czy mamy wystarczająco dużo zasobów - sprzętu, wydajności, ludzi, aby obsłużyć każdy dzwoniący telefon z prośbą o wsparcie?

Biznesy, w których pracowałem zazwyczaj nie miały super złożonych procesów operacyjnych (w końcu zazwyczaj był to po prostu handel), miały natomiast potencjalnie ogromny wolumen transakcyjny.

Przykładem niech będzie wdrożenie/rollout nowego systemu sprzedażowego (SAP SD) i magazynowego (SAP WM). Mamy 12 magazynów, każdy obsługuje po 1000-1500 klientów (sklepów). Wyobraźmy sobie wdrożenie big-bang.

W realu - załóżmy, że uruchomimy chociażby jeden cały magazyn na raz a tu wtem! - lekki problem w wydajnością systemu. 10% opóźnionych dostaw. Błędy powiedzmy, w 5% danych podstawowych wymagające uzgodnień przed wysyłką towaru. Nagle okazuje się, że pierwszego dnia (a raczej w nocy, bo biznes dystrybucyjny pracuje nocami) jest 150 rozzłoszczonych nieobsłużonych klientów, urywające się telefony i maile. Wiadomo, przy wdrożeniach nieco krwi musi się polać. Naszym, jako zarządzających zadaniem jest oszacowanie, czy ilość tego będzie do ogarnięcia.

Z takich ćwiczeń myślowych powstają podejścia do uruchomienia dzielące uruchomienie na małe, możliwie odwracalne kawałeczki, a następnie dopiero na plan rozpędzania tego wdrożenia stopniowo na pełną skalę biznesu.

Wydaje się oczywiste. Często jednak „myślenie grupowe” zespołu projektowego preferuje różnego rodzaju Big Bangi. Przygotowanie Big Bangu pozwala uniknąć budowy architektury tymczasowej, w której współistnieją równoległe światy odchodzący i przychodzący wraz z ich integracją w okresie przejściowym.

Tak, tylko to jest jedna rzecz. Projekty nie są wartością samą w sobie.

Kiedyś w firmie ExxonMobil był duży miedzynarodowy projekt globalnego wdrożenia ERP. Co miesiąc mieliśmy spotkanie całego zespołu o nazwie „Employee Forum” (nie pytajcie skąd ta nazwa, to chyba była część starej korporacyjnej kultury). Forum to było raczej jednokierunkowe - odgórno - dodolne, celem spotkania był przekaz od kierownictwa do każdej osoby na projekcie, gdzie jesteśmy. Jakie mamy priorytety, co przed nami itd. Lista priorytetów zawsze zaczynała się od jednej niezmiennej pozycji. BIEŻĄCE OPERACJE MUSZĄ DZIAŁAĆ. Wsparcie aktualnych procesów na produkcji ma zawsze priorytet na celami projektowymi. Projekt to jest ogon przyczepiony do psa, którym są operacje.

Metodyki

Mój pierwszy dłuższy epizod zawodowy to praca w Accenture. Firmy konsultingowe zawsze mają grube tomiska procedur i metodyk. W 1998 nazywało się to Business Integration Methodology (dla podkreślenia że nie jesteśmy tylko firma od technicznych wdrożeń systemów, ale skupiamy się celach biznesowych dla klientów), potem weszło nieco odmienne Accenture Delivery Method, cokolwiek. Człowiek mógł być serio przytłoczony tymi księgami opisującymi zadania i praktyki przypisane do kolejnych etapów, listą produktów i formularzy do wypełnienia.

To co często jest robione źle, to że takie opasłe tomiska nie przychodzą z czymś na kształt - (wracamy do tytułu) „Quick Start Guide”. Człowiek stykający się pierwszy raz z takimi podręcznikami nie widzi lasu pośród otaczających go drzew. I zwykle nie ma najważniejszego ostrzeżenia w podtytule - „NIE UŻYWAJCIE TEGO W CAŁOŚCI”. Podręczniki metody zawierają sumę wszystkich możliwych produktów z najróżniejszych aplikowalnych projektów, które mogą być w danej metodyce realizowane.

Najważniejszym zadaniem szefa projektu jest ustawienie właściwej selekcji podzbioru metodyki, która jest minimalnie wystarczająca, aby ogarnąć ten jeden projekt. Tak przy okazji, połowa projektów jest do ogarnięcia za pomocą doprawdy kilku rodzajów dokumentów, w tym wysokopoziomowego planu i issue listy z paroma kolumnami.

Planuj od cut-over wstecz

Niedawno w jednej firmie zastałem taki obrazek.

Firma jest w trakcie wdrożenia ERP. W sumie to robią to z powodu niezawinionego długu technologicznego, aktualny stary ERP jest dzieckiem pożartej przed laty przez akwizycję nieistniejącej już amerykańskiej firmy przez inną amerykańską firmę. Aktualny licencjodawca motywuje do wymiany na swoją aktualną ofertę. Ten nowy, aktualnie oferowany ERP nie ma wiele wspólnego z poprzednim, w szczególności serce logiki i model danych są całkiem inne.

Nieważne, czy jesteście związani z ERP Microsoft, czy klientem SAP sprawa jest podobna. Wprawdzie S/4 jest w głębi kodu wcale nie tak odległe od starego dobrego ECC, jednak faworyzowane teraz scenariusze deplopmentu w chmurze znacząco ograniczają to, co klienci lubili najbardziej. A klienci lubili użycie solidnej platformy ERP do budowania przez lata własnych rozszerzeń. Często to te specyfiki procesowe właśnie „robiły różnicę”. Dostawcy ERP zaś promują wdrożenia „vanilla” (najbardziej popularne kłamstwo fazy blueprint), bo to im to upraszcza landscape infrastruktury chmurowej. Efektem jest, że klienci potem uważają, że ERP już nie jest źródłem przewagi konkurencyjnej, bo wszystko musi być jak w każdej innej firmie. Urażeni dostawcy - pretensje miejcie sami do siebie, że sprowadzacie swoje produkty do rangi commodity.

Wracając do klienta, mamy więc implementację całkiem od nowa. Dodatkowo wdrożenie nie „przewozi” się na karku jakiegoś większego projektu biznesowego. Szkoda, bo nadałoby to całej organizacji i zarządowi motywację do parcia z wizją atrakcyjnego business case jako realnej nagrody. A bez tego, mamy wysiłek motywowany tylko technicznie a jednocześnie dotykający biznes. To fatalna asymetria - jest szansa na porażkę przy jakichkolwiek perturbacjach przy uruchomieniu, a jeśli jakimś cudem będzie wszystko gładko (co nigdy się w 100% nie udaje), to w sumie nikt specjalnie nie podziękuje, no bo po prostu będzie zwyczajnie a nie jakiś sukces biznesowy.

Projekt, jak przystało na takie likwidacje długu technologicznego, a z potencjalnym (negatywnym) wpływem na operacje (i budżet) nosi znamiona wielokrotnego kopnięcia puszki do przodu. Zaczął się rok temu, start produkcyjny ma być za rok. Sam przeciągły harmonogram nie napawa optymizmem co do żwawej mobilizacji zespołu, no trudno sobie w dzisiejszych czasach wyobrazić ciągłą mobilizację trwającą dwa lata i to nad jakimś niebiznesowym celem.

W trakcie trwania projektu, niedość że puszka była kopana do przodu to jeszcze, bingo - zespół zaproponował kuszące uproszczenia sprowadzające się do uruchomienia wszystkiego na raz big-bangiem.

Psychologicznie to świetny mechanizm pozwalający upiec dwie pieczenie na jednym ogniu. Nie dość, że przytłoczeni złożonością, skreślamy jednym ruchem wszelkie wyzwania myślowe związane z architekturami pośrednimi pomiędzy etapami uruchomienia, to co więcej - w ogóle pierwszy go-live przesuwa się w bezpieczne rejony pt „za dwa lata”, a my możemy teraz zagłębić się w prace projektowe niezakłócone myśleniem o jakimś tam produkcyjnym funkcjonowaniem systemu.

Do tego dochodzą zazwyczaj racjonalizacje typu „mamy w planie szczegółowe testy” etc.

Powiedzmy szczerze - patrząc z zewnątrz obarczeni jesteśmy ryzykiem pobieżnej oceny. Czy warto mówić, że coś tu nie gra? W przeszłości uczestniczyłem z ramienia spółki nadzorującej w różnych Komitetach Sterujących wdrożeń w spółkach córkach. Kierownicy tych projektów śmiało toczyli wizję takich podejść do uruchomienia. Pułapką "ważniaka" z KS jest to, że kierownicy ci teoretycznie w tym siedzą na co dzień, no przecież muszą wiedzieć, co robią. Więc - może nie warto wychylać głowy, udawać Kasandry, bo - może moje obawy są niesłuszne? Może to ma szanse się udać? Parę razy tak myślałem i parę razy byłem w błędzie.

Zataczając koło i stosując metodę powtórzeń, podsumowanie:

Najprostsze pytanie weryfikujące realność planu agresywnego szerokiego uruchomienia jest pytaniem o pierwszy dzień "po" - ile procesów, ile działów firmy zacznie pracować znienacka inaczej - ilu użytkowników lepiej lub gorzej przeszkolonych siądzie przed nowymi ekranami, zobaczy nie do końca znajome sobie dane (wiadomo - z konwersjami nigdy nie jest na 100% idealnie) i czy będziesz miał wówczas wystarczająco dużo zasobów - ludzi, wsparcia, czasu, aby ręcznie naprawiać to, co będzie źle. Czy też zostaniesz znienacka przytłoczony tysiącem telefonów z 20 biur i zatrzymanymi procesami biznesowymi wcześniej nie wygrzanymi w mniejszej skali.

Jeśli odpowiedź jest negatywna - przepraszam - nie jest ważne, że big-bang wydaje się prostszy w przygotowaniu - proszę wrócić do planu i wymyśleć coś innego.

W mojej karierze, najważniejsze przełomy otwierające możliwość pchania projektów do przodu polegały na wymyśleniu, jak można to coś podzielić na mniejsze kawałki.

Procesy magazynowe wdrażaliśmy strefami w magazynie, potem magazynami. My - zespół projektowy mieliśmy dwa systemy - stary i nowy po kroku rolujący do przodu. Ale każdy magazynier w swojej strefie widział tylko jeden. Doprawdy magazynier nie musi wiedzieć, że są dwa równoległe światy, jeśli na swojej zmianie jest zawsze tylko w jednym z nich - starym lub nowym.

Procesy sprzedażowe - płatnikami - każdy klient widział tylko jeden moment przejścia, ale my mogliśmy ich wpuszczać do systemu takimi transzami, jakie były dla nas do ogarnięcia. Najważniejsze jak w każdym zarządzaniu - nigdy nie stracić kontroli - ty wyznaczasz skalę kroków, które jesteś w stanie wykonać.

Gdy już będziesz miał swoje małe kawałki cut-over - planuj wstecz jak je dostarczysz - jakąkolwiek metodykę wyznajesz.