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.


sobota, 22 października 2011

Kontrakty - co zrobić z fixed?

Ostatnimi czasu pokazało się kilka dość ciekawych postów na temat kontraktów agile, na przykład tutaj. Ja sam też kiedyś ten temat poruszałem tutaj. Od tego czasu wiele się jednak zmieniło, warto więc dołożyć trochę uwag wzbogaconych doświadczeniem.

Oczywiście idealną sytuacją jest kiedy możemy pozwolić sobie na zaawansowany i opierający się na zaufaniu kontrakt typu Capped T&M czy Cost Targeted. Niestety w dużej części  przypadków w świecie realnym jest tak, że z różnych powodów jedynym akceptowanym przez zamawiającego kontraktem jest fixed price (stała cena za wykonane prace). Takie ustawienie sprawy teoretycznie od razu wyklucza podejście agile, bo w tym momencie pierwsze co robi dostawca to domaganie się zdefiniowania fixed scope (stały zakres). Jak już mamy stały zakres i stałą cenę to gdzie tu miejsce na agile? Miejsca jest wbrew pozorom dość dużo.

Pierwsza rzecz to podejście iteracyjne do wykonywania projektu. Ten element jest dość często pomijany, natomiast wbrew pozorom bardzo ważny dla zamawiających. Chodzi o ograniczanie ryzyka. Jeżeli nie można wyeliminować ryzyka kontraktu (jest stała cena, więc i tak pojawią się koszty) to można chociaż próbować ograniczyć ryzyko produktowe. Czyli spróbować zapobiec sytuacji, kiedy klient dostanie coś, czego (w jego przekonaniu) wcale nie zamawiał. Z punktu widzenia zamawiającego jest ważne czy produkt projektu zobaczy dopiero raz, na samym końcu projektu czy będzie go widział często, mogąc go testować w trakcie. Zgodnie bowiem z panującym powszechnie przekonaniem klienta interesuje tylko efekt końcowy, ale przy okazji chciałby on osiągnąć go przy optymalnym ekonomicznie ryzyku. Dlatego wbrew powszechnie panującym przekonaniom klienta interesuje to, w jaki sposób dostawca realizuje projekt i jak ta realizacja wpływa na ogólne ryzyko całego projektu. Agile natomiast zmniejsza to ryzyko.

Kolejnym tematem jest wciągnięcie klienta w projekt. Zgodnie z wartościami agile interakcje między ludźmi są ważniejsze niż procesy i narzędzia. I to działa niezależnie od typu kontraktu. Znane mi są przypadki, kiedy dostawcy w sposób aktywny ograniczali dostęp zespołu wykonawczego do klienta. Co więcej kontakt z klientem ograniczał się do regularnych spotkań "na szczycie". Innymi słowy każda informacja przekazana przez klienta przechodziła przez trzy osoby zanim trafiła do programisty. Skutki można dość łatwo przewidzieć. Wszyscy działali w najlepszej wierze a klient i tak dostał nie to co chciał i za co myślał, że zapłacił. Tak więc komunikacja, komunikacja i jeszcze raz komunikacja. Oraz aktywne włączenie klienta w prace.

Trzecia natomiast rzecz to elastyczność w przejściu w tryb "variable scope". To najlepiej wytłumaczyć na przykładzie. Załóżmy, że realizujemy kontrakt typu fixed (stała cena, stały zakres). W połowie projektu klient orientuje się, że chce zmienić jedno z wymagań. Zwykle dlatego, że w jakiś sposób zmieniły się warunki prowadzenia biznesu. Co w takim wypadku może zrobić dostawca? Pierwsza opcja to przyjąć i wycenić "change request" (żądanie zmiany). Bardzo często po stawkach wyższych niż oryginalny projekt (jak to wpływa na jego wizerunek w oczach klienta?). Druga opcja to przyjść do klienta i powiedzieć mu, że może zrealizować tą zmianę w ramach obecnego kontraktu, ale konsekwencją jej zrealizowania będzie nie zrealizowanie całego wcześniej zakontraktowanego zakresu. Takie podejście to właśnie dążenie do projektu "variable scope". Oczywiście na wszelkie tego typu zmiany muszą istnieć później odpowiednie dokumenty (bo to w końcu zmiana warunków kontraktu). Zapewne zależy to od klienta, ale takie podejście może się spotkać z zaskakująco dobrym przyjęciem. Oczywiście również dlatego, że najważniejsze z punktu widzenia klienta funkcjonalności zostały zrealizowane na początku projektu, więc konsekwencje zmiany zakresu nie będą miały na nie wpływu, prawda?

sobota, 8 października 2011

Back

Od ostatniego postu minęło prawie dwa lata... Przez ten okres czas, który wcześniej przeznaczałem m.in. na pisanie tego bloga, pochłaniało mi coś zupełnie innego. Tak dokładnie to cały mój wolny czas pochłonięty był studiami Franklin University MBA. Generalnie bardzo polecam z dwóch powodów. Po pierwsze studia są realizowane w całości w języku angielskim, przez amerykańskich wykładowców, z amerykańskich książek i według amerykańskiego programu. Innymi słowy można się poczuć jak student amerykańskiej uczelni (a podejście mają zupełnie inne niż nasze uczelnie). Po drugie to studia studiami, ale najważniejsze w nich i tak jest poznanie wielu bardzo ciekawych osób, wymiana doświadczeń i uczenie się od siebie. Często dające nieporównywanie więcej niż książki i słuchanie wykładowców. Natomiast uczciwie trzeba też powiedzieć, że takie studia to potężne obciążenie czasowe odbijające się na życiu prywatnym. Amerykanie szacują, że skończenie ich wymaga wkładu około 6-8 godzin dodatkowej pracy co tydzień. Wydaje się, że to jeszcze nie jest aż tak duża tragedia, natomiast należy pamiętać, że zostało to policzone z założeniem, że językiem ojczystym studenta jest angielski. W przypadku gdy tak nie jest czas ten się wydłuża...

 Aby jednak odnieść się do tematyki tego bloga taka refleksja dotycząca innowacyjności. Studia MBA niewątpliwie są interesujące i dają dużo wiedzy, jednak dość ewidentnie widać, że większość z niej dotyczy "tradycyjnych" biznesów. Produkcja, dystrybucja, sprzedaż (w fizycznych sklepach) - takie elementy są bardzo dobrze zbadane, opisane i istnieje ogrom wiedzy pozwalającej na doskonalenie stosowanych tam systemów. Natomiast nie ma bezpośredniego przełożenia tej wiedzy na nowe technologie i nowe media. To nie wynika nawet ze "starości" samej koncepcji studiów czy też niewiedzy wykładowców. Czytając amerykańskie książki akademickie wydawane w roku 2010 czy też 2011 zaskoczony byłem tym jak mało jest tam modeli i teorii znajdujących bezpośrednie zastosowanie w firmach nowych mediów czy nowych technologii. Raczej należało wszystkie teorie przekładać na te realia wykonując dość dużą pracę koncepcyjną. Na szczęście w źródłach reagujących szybciej niż podręczniki akademickie (np. amerykańskie edycje HBR) widać, że coraz częściej autorzy interesują się właśnie zwinnymi firmami nowych technologii. Co też będzie wpływało na kolejne posty na tym blogu :)

Mam dużą nadzieję, motywację i plan, żeby posty na tym blogu znów pojawiały się regularnie. Może nie aż tak często jak kiedyś, ale regularnie.