sobota, 26 listopada 2011

Poprawianie sprawności operacyjnej

Dzisiaj będzie z trochę innej perspektywy niż zwykle. Wyobraźmy sobie taki przypadek:
Jest sobie firma, w której wszelkie zmiany wprowadzane są dzięki projektom. Firma  wprowadza zmiany zarówno do swojej oferty, produktu jak i działania poprzez uruchamianie i realizowanie projektów. Firma ma jednak podwójny problem. Po pierwsze same projekty na warstwie operacyjnej nie są doskonałe. Zwykle kończą się dostarczeniem zakresu w zakładanym budżecie, ale gorzej bywa z czasem a jeszcze gorzej z jakością procesową (zgodności z procedurami, wymiana informacji, raportowanie, itp.). Drugim problemem firmy jest to, że wdrażanie kolejnych projektów nie przekłada się na wskaźniki biznesowe firmy. Mimo wysiłków, inwestycji w projekty, zakańczania projektów i wprowadzania zmian wskaźniki biznesowe albo pozostają na tym samym poziomie (a przecież gospodarka się rozwija) albo wręcz spadają.
Pytanie: czy opisanej wyżej sytuacji warto pracować nad poprawą efektywności procesów zarządzania projektami?

TAK - patrząc się przez pryzmat efektywności operacyjnej. Przecież jest dużo do zrobienia, zwłaszcza na warstwie proceduralnej. To może przełożyć się na polepszenie efektywności rozumianej jako zakańczanie projektów na czas, czyli innymi słowy szybsze zakańczanie projektów. Dodatkowo poprawa jakości procesowej poprzez standaryzację zwykle dobrze wpływa na efektywność operacyjną.

NIE - patrząc się przez pryzmat teorii ograniczeń na całość organizacji to na daną chwilę efektywność organizacyjna nie jest ograniczeniem systemu. System, jakim jest ta firma, nie służy do tego, aby sprawnie realizować projekty, tylko do tego, aby sprawnie zarabiać pieniądze. Z dostępnych informacji wynika natomiast, że problemem nie jest operacyjne działanie, tylko fakt, że projekty nie przynoszą spodziewanych rezultatów biznesowych. Dlatego aby osiągnąć cel, czyli poprawić zdolność organizacji do zarabiania pieniędzy, należy zająć się stroną biznesową projektów a nie operacyjną. Zajmowanie się stroną operacyjną nie jest w tej sytuacji potrzebne, bo nie wpływa na ograniczenie. Takie podejście jednak zupełnie nie bierze pod uwagę ludzkiej strony organizacji - co zrobić jeżeli przyjdzie ktoś z super pomysłem jak usprawnić część operacyjną? Powiedzieć mu wprost: nie, nie potrzebujemy usprawnień? Jaki to ma wpływ na motywację?

TAK - warto poprawić efektywność operacyjną, bo przez to uwolnimy zasoby do prac nad ważniejszymi rzeczami. Być może jest tak, że duża część zasobów firmy jest tak pochłonięta bieżącymi ("pilnymi") sprawami i walką z teraźniejszością, że po prostu nie ma czasu zaprząc uwagi do prac strategicznych i zobaczenia szerszej perspektywy. Dopiero poprawienie sprawności operacyjnej sprawi, że znajdzie się czas na ważne rzeczy. W tym podejściu ukryte jest założenie, że te same osoby mogą rozwiązać problemy operacyjne jak i strategiczne. Jeżeli nad oboma zagadnieniami miałyby pracować inne osoby, to takie podejście nic nie da.

NIE - jeżeli niektóre z projektów przynoszą efekty odwrotne do zamierzonych (wskaźniki biznesowe spadają) to poprawiając sprawność operacyjną tylko przyspieszymy tempo tego spadania, bo szybciej będziemy wdrażać projekty, które mają negatywne skutki. Dlatego nie ma sensu zwiększać efektywności zanim nie upewnimy się, że efekty będą pozytywnie wpływały na organizację. Z drugiej strony posiadanie sprawnej organizacji operacyjnej umożliwi bardzo szybkie osiągnięcie wyników w momencie kiedy część strategiczna zostanie naprawiona.

Co więc zrobić? Prawdopodobnie ilu ekspertów, tyle możliwych odpowiedzi na zadane pytanie. Dużo zależy od kontekstu konkretnej organizacji i tego, jak szeroko się ją analizuje. Moim zdaniem w takiej sytuacji należałoby najpierw uzdrowić sytuację strategiczno/biznesową, nie hamując (ani nie wzbudzając) jednak inicjatyw poprawy operacyjnej. Dopiero po uzdrowieniu sytuacji strategicznej sprawdzić czym zająć się w drugiej kolejności. Być może będzie to zarządzanie projektami, a być może coś zupełnie innego, co okaże się dopiero po zakończeniu działań strategicznych.

niedziela, 6 listopada 2011

Zarządzanie ryzykiem w agile/SCRUM

Większość literatury i metodyk opisujących agile pomija zupełnie temat zarządzania ryzykiem. Jednak ryzyko jest wpisane w projekty z samej ich definicji - jeżeli projekt jest przedsięwzięciem innowacyjnym, to muszą być z nim związane ryzyka. Aby uniknąć wątpliwości przyjmijmy definicję, że ryzyko to jakiekolwiek przyszłe, niepewne wydarzenie, które może mieć wpływ na zakres, czas, zasoby bądź jakość projektu.

Najprościej jest powiedzieć, że agile ma zarządzanie ryzykiem wbudowane w samą metodykę ze względu na krótkie iteracje, dostarczanie działających wersji produktu, stały kontakt z klientem oraz retrospekcje obejmujące zakres, technologię i procesy. Dokładając do tego możliwość poprawnego priorytetyzowania funkcjonalności (te z wysokim ryzykiem jako pierwsze) dostajemy system, który powinien "samodzielnie" poradzić sobie z ryzykiem. Jeżeli ryzyko się zmaterializuje to dzięki krótkiej iteracji będzie można szybko zmienić plan i dostosować zakres do nowej sytuacji. Dzięki wybraniu najbardziej ryzykownych funkcjonalności jako pierwszych będziemy mogli szybko sprawdzić wykonalność całego projektu, itd. (napiszę osobny post na temat tego jak działa to wbudowane w metodykę zarządzanie ryzykiem).

Działania w ramach metodyki agile mogą znacząco ograniczyć ryzyka związane z technologią i niepewnością dotyczącą zakresu produktu. Niestety nie są to jedyne ryzyka, które mogą pojawić się w trakcie realizacji projektu. W szczególności w większych organizacjach i projektach do tych dwóch kategorii ryzyk dochodzi wiele innych związanych np. z finansowaniem inwestycji, integracją z innymi elementami systemu, wdrożeniem systemu na środowiskach produkcyjnych, sytuacją rynkową organizacji czy nawet polityką wewnętrzną. Takimi ryzykami nie zarządzimy tylko dzięki krótkim iteracjom i skupianiu się na dostarczaniu wartości dla klienta. Tego typu ryzyka są zupełnie pomijane w większości literatury dotyczącej agile. Czas więc odkurzyć metody zarządzania ryzykiem rodem z PMI. Co tam znajdujemy?

Pominąwszy procesy związane z identyfikacją ryzyk czy ich jakościową oceną (ilościowa w moim odczuciu nie współgra z duchem projektów agile) pojawia się proces pod nazwą Planowanie Odpowiedzi na Ryzyka. Do każdego z ryzyk można zastosować cztery ogólne strategie: akceptacji (nic nie robię, jak się zdarzy to trudno), unikania (podejmuję aktywne działania, aby ryzyko się nie spełniło), minimalizacji skutków (czekam na ryzyko i mam gotowy plan jak ograniczyć jego skutki jak już zaistnieje) oraz przeniesienia/transferu (płacę komuś żeby się o to martwił - ubezpieczenia). Niezależnie od metody, którą prowadzimy projekt, w przypadku wybrania dla zarządzenia ryzykiem strategii innej niż akceptacja, należy dostosować plan projektu do wybranej strategii zarządzania ryzykiem. W przypadku agile również takie akcje należy podjąć. Jeżeli chcemy unikać jakiegoś ryzyka to działania prowadzące do tego unikania powinny zostać zapisane i przydzielone do realizacji w możliwie najbliższej iteracji. Dzięki temu ryzyko będzie miało mniejsze prawdopodobieństwo zaistnienia. Jeżeli wybieramy strategię minimalizacji skutków to założeniem tej strategii jest opracowanie planu co zrobić zanim ryzyko się zmaterializuje. W tym wypadku przełożenie tego na agile polega na posiadaniu "na boku" zestawu funkcjonalności/karteczek, które wejdą do realizacji jeżeli dane ryzyko się zmaterializuje. O tym czy dany zestaw działań minimalizujących zrealizować czy nie powinno się oczywiście decydować w ramach zwykłego planowania iteracji. Jeżeli natomiast wybieramy strategię transferu ryzyka to takie działanie również pociąga za sobą konieczność wykonania działań, zwykle jednak nie są to działania na poziomie zespołu projektowego.

Co ciekawe ze względu na specyfikę ryzyk, o których tutaj rozmawiamy (nie produkt i nie technologia) bardzo często plany dotyczące radzenia sobie z nimi będą w małym stopniu angażować zespół projektowy a dużo większym np. product ownera. Niemniej jednak takimi ryzykami też trzeba zarządzać w metodykach agile. Zarządzać to znaczy planować, przydzielać odpowiedzialności i później nadzorować ich realizację. Czasami może się to niestety sprowadzić do tego, że będziemy musieli mieć inny niż iteracyjny sposób zarządzania tymi zadaniami (z tego powodu, że zaangażowane osoby nie pracują w takim rygorze).

I tak na koniec: w metodyce PMI w obszarze dotyczącym zarządzania ryzykiem, pierwszy proces, który się pojawia to Zaplanuj Zarządzanie Ryzykiem. Co polecam zrobić dla wszystkich ryzyk, w każdym projekcie, w tym również w tych prowadzonych metodykami agile.