Założenia to przekleństwo

Czasami warto jest się przyjrzeć głębiej powodom, dla których podejmowane są działania uważane przez wszystkich za oczywiste. Dla przykładu pierwsza z brzegu rzecz czyli planowanie. Wszyscy wiemy, że to jest ważne, jest podstawą pracy itd. Projekty z definicji są działaniami, które są innowacyjne, które zawierają w sobie pewien element niepewności. Dlatego też musimy je planować a nie działać automatycznie jak to się robi w przypadku procesów. Plan jest następnie realizowany, po czym, w dużej części przypadków, następuje brutalne zderzenie z rzeczywistością, które dla planu okazuje się być nie do przeżycia. Zwykle w wyniku nieprzewidzianych zdarzeń muszą nastąpić poważne zmiany w planie jak i w samych produktach projektu.

Interesujące jest co dzieje się dalej. W większości środowisk, z którymi miałem do czynienia podejmuje się natychmiastowe działania naprawcze skupiające się wokół generalnego twierdzenia "musimy lepiej planować". Przez "lepiej" w tym wypadku określa się zwykle dogłębniej, dokładniej i bardziej szczegółowo. Generalnie bardziej kosztownie. I tu pojawia się pytanie następujące. Jakie założenie stoi za twierdzeniem, że więcej zasobów poświęconych na planowanie automatycznie przekłada się na lepszą realizacje tychże planów w przyszłości?

Jak dla mnie założenia za tym twierdzeniem są następujące "planując dłużej uzyskujemy większą kontrolę nad przyszłością" oraz "dłuższe planowanie powoduje zmniejszenie liczby zmian w przyszłości". Czy te założenia są prawdziwe? Wątpię. Czy to oznacza, że planowanie jest zbędne. Oczywiście nie. Oznacza tylko, że nigdy nie możemy oczekiwać, że maksymalne wydłużenie analizy i planowania spowoduje automatyczny sukces naszego projektu. Tak się nie dzieje. Od pewnego momentu mimo przeznaczania coraz większych nakładów na planowanie "uzysk" dokładności jest minimalny. A im działanie jest bardziej innowacyjne tym to "wypłaszczenie" następuje szybciej.

Co z tym zrobić? Może zamiast brnąć w taki system oparty na błędnym założeniu skonstruować system, który dostosowuje się do rzeczywistości. Czyli zadać sobie pytanie "jak powinien wyglądać mój system realizacji projektów jeżeli założę, że zmiany na pewno nastąpią". Jeżeli uda się taki system zbudować i wprowadzić w życie to zamiast walczyć z rzeczywistością otrzymamy organizację potrafiącą w danej rzeczywistości idealnie zarządzać.

P.S. Oczywiście powyższe wywody nie dotyczą pewnej klasy systemów, np. takich gdzie gra idzie o życie ludzkie (projektowania samolotów).

Metody realizacji projektów

Poniżej moje autorskie, przygotowane w konkretnym celu i dla konkretnej okazji, o której tutaj nie będę pisał, porównanie metod realizacji projektów. Można używać do woli, pod warunkiem podania źródła.

Metoda ścieżki krytycznej + EVM
Motywacja historyczna:
W dużych projektach rządowych chciano wiedzieć, na którym ciągu zadań powinien skupiać się kierownik, aby zapewnić realizację projektu w czasie.

Typowe rezultaty wdrożenia metody:

• Projekt zobrazowany jako lista prac do wykonania na osi czasu
  
• Ustalona odpowiedzialność za zadania
• Zmniejszone ryzyko opóźnienia projektu
• Możliwość formalizacji planowania i zarządzania projektami
• Iluzja pełnej kontroli (daty rozpoczęcia i zakończenia każdego zadania)
  
• Realna możliwość oceny efektywności prac zakończonych (EVM)
  

Typowe przeszkody we wdrożeniu

• Metoda tak stara, że teoretycznie nie powinno być, ale:
• Wymusza dużą formalizację projektów
• Nie daje szybkich wygranych
• Generowane są dane a nie informacje
• Łatwo skupić się na przerzucaniu formularzy zamiast zarządzaniu projektem
  

Łańcuch krytyczny (CCPM)
Motywacja historyczna:
Dla przedsiębiorstw komercyjnych kluczowe stało się realizowanie projektów w pierwotnie planowanym terminie przy ograniczonej liczbie zasobów


Typowe rezultaty wdrożenia metody:

• Projekt zobrazowany jako sieć połączonych zadań
• Ustalona odpowiedzialność za zadania
• Minimalne choć bardzo intensywny proces nadzorowania projektów
  
• Brak przeciążenia zasobów
• Maksymalizacja prawdopodobieństwa oddania projektu na czas (do 95%)
  
• Możliwość proaktywnego nadzorowania realizacji

Typowe przeszkody we wdrożeniu

• Brak jest jasnego uzasadnienia biznesowego wdrożenia
• Wymaga zmiany kultury pracy i mierników
• Pełne wdrożenie wymaga zgody wszystkich szczebli i działów
• Metoda na tyle skomplikowana, że wymaga wdrożenia zintegrowanego systemu IT
  
• Postrzeganie jako wdrożenia tylko systemu IT
• Metoda nieodporna na zmiany sieci projektu w trakcie trwania

Metody zwinne (agile)
Motywacja historyczna:
Branża informatyczna zauważyła, że konieczność planowana całości projektu przed jego rozpoczęciem nie sprawdza się w środowisku, gdzie zmiany bardzo łatwo się wprowadza – zastosowano podejście radykalnie różne od dotychczasowych


Typowe rezultaty wdrożenia metody:

• Projekt rozpisany jako lista funkcjonalności produktu
• Szybkie dostarczanie najbardziej wartościowych funkcji
• Nowe wersje dostarczane regularnie
• Łatwe dostosowywanie produktu do zmian
• Można pracować mimo braku pełnego planu
• Zdrowe relacje w zespołach
  
  

Typowe przeszkody we wdrożeniu

• Zbyt proste – wszyscy myślą, że zrozumieli
• „Cieńka czerwona linia” między chaosem a agile
• Wyższe szczeble zarządzania chcą „ciężkich” procesów
• Kierownicy produktu nie trzymają się założeń
• Wymaga zmiany kultury pracy i mierników

Na koniec drobna uwaga:

Odpowiedzialnością każdego specjalisty, w tym kierownika projektów, jest znać jak najwięcej różnych narzędzi i stosować te, które najlepiej spełnią cele postawione w danej sytuacji. Jak to kiedyś ujął mój kolega "chroń mnie Panie przed człowiekiem, który przeczytał tylko jedną książkę".

PMO w sposób zwinny

Rok temu opublikowałem tutaj posta na temat wprowadzania zmian w organizacjach metodami zwinnymi:
http://www.wlochowicz.com/blog/2008/05/zwinne-zarzdzanie-zmian-w-organizacji.html

Natomiast parę dni temu znalazłem na PM Hut posta na temat... wprowadzania PMO w organizacji własnie dzięki metodom agile. Cytat:

If you’re building a PMO and have a 3 year plan – drop it now! [...] As you’ve guessed by the article title I am going to suggest that we steal a technique from the software development industry. While I am not an agile expert by any means, there are some very successful practices that you can employ while building and growing your PMO.

Czyli da się. Jest to możliwe nawet do wprowadzania zmian tak rozległych jak PMO w organizacji.

Całość do przeczytania na PM Hut:
http://www.pmhut.com/the-agile-project-management-office-pmo

Narzędzia efektywnego zarządzania mniejszymi projektami

Tytuł tego postu to jednocześnie tytuł mojego wystąpienia na seminarium PMI we Wrocławiu 24 marca. Poniższą treść można traktować jako handout tej krótkiej prezentacji.

Na początek zdefiniujmy sobie co to jest ten “mniejszy projekt”. Metodą Alberta Einsteina mniejszy projekt to dla mnie projekt, dla zarządzania którym użycie MS Project jest zbyt skomplikowane / powoduje zbyt duży narzut zarządczy. W organizacjach takich jak je znam jest realizowanych wiele, bardzo wiele projektów, z których znacząca część to projekty małe. Ot choćby zmiana jednej czy drugiej procedury obsługi klienta, zorganizowanie spotkania dla klientów czy też wydanie nowej wersji katalogu firmowego. Tego typu aktywności często charakteryzują się wszystkimi cechami projektu, z tą właściwością, że ich złożoność jest o kilka rzędów wielkości mniejsza od złożoności projektu budowy nowego biurowca czy stworzenia systemu informatycznego. W związku z tym narzędzia informatyczne konstruowane z myślą o zarządzaniu projektami wielkości budowy biurowca nie mogą być wykorzystywane w sposób efektywny do tych mniejszych projektów. Głównie ze względu na swoje skomplikowanie, które powoduje, że narzut czynności zarządczych, które trzeba wykonać jest nieproporcjonalny do wielkości projektu.

Dla takich mniejszych projektów efektywne narzędzia wspierające zarządzanie nimi powinny być też mniejsze i zdecydowanie inaczej konstruowane. Na czym powinny się skupiać? Według PMI, i jest to niewątpliwie prawda, znacząca większość czasu pracy kierownika projektu jest poświęcona na komunikowanie się. W tym w szczególności na komunikowanie się z zespołem projektowym na temat poszczególnych zadań, ich statusów oraz postępu prac. W związku z tym jeżeli mówimy o efektywnym zarządzaniu projektami to podstawową funkcją, którą muszą wspierać narzędzia jest komunikacja.

Takimi właśnie narzędziami są pojawiające się ostatnimi czasy platformy internetowe oparte o technologi szumnie nazywane Web 2.0. Wiele z tych narzędzi było wręcz pisane jako nie-MS Project z nastawieniem na obsługę projektów mniejszych. Co ciekawe znacząca większość tych narzędzi kładzie nacisk właśnie na aspekty komunikacji w zespole i stara się rozwiązać ten problem poprzez udostępnienie wspólnej dla wszystkich interesariuszy platformy komunikacyjnej. Narzędzia te mają ze sobą wiele wspólnego. Do wspólnych cech zaliczyć należy przede wszystkim (oprócz dostępu przez internet z dowolnego miejsca na świecie a często także z dowolnego urządzenia mobilnego) nastawienie na maksymalne uproszczenie funkcjonalności i uczynienie doświadczenia użytkownika z pracy z narzędziem jak najbardziej pozytywnym. Poza tym, twórcy tych narzędzi garściami czerpią ze Steva Jobsa i zazwyczaj umieszczają w nich tylko i wyłącznie niezbędne funkcje, co czyni te narzędzia prostymi i efektywnymi w użyciu. Przykładowymi, choć istnieje o wiele więcej, narzędziami tego typu są BaseCamp i ActiveCollab.

Narzędzia te zbudowane są wokół koncepcji realizacji projektu poprzez osiąganie kolejnych kamieniu milowych, które to znowu są osiągane poprzez realizację zestawów zadań. Choć różni się to w szczegółach pomiędzy narzędziami to większość z nich pozwala na zdefiniowanie dla projektu dat osiągnięcia kamieni milowych. Następnie dla danych kamieni tworzy się listy zadań, przypisując odpowiedzialności do członków zespołów. Realizacja zadań jest wspomagana poprzez udostępnienie miejsca na dyskusje (coś w rodzaju forów internetowych), przechowywanie plików oraz inne dodatki zależne od konkretnego narzędzia. Śledzenie postępu przez kierownika odbywa się poprzez skondensowane dashboard’y prezentujące na jednym ekranie przeglądarki stan tego co dzieje się w projekcie. Jest to zwykle bardzo ciekawie zorganizowane, bo pokazuje stan komunikacji (co, kto, kiedy powiedział/wysłał/zaraportował) a nie jakiś wyimaginowany procentowy stan zaawansowania pracy. Takie podejście powoduje umieszczenie w jednym miejscu wszystkich informacji z realizacji projektu a także bardzo dobry pogląd na to, co się z tym projektem od strony wymiany tejże informacji dzieje.

Narzędzia te oczywiście mają także wady. Zaliczyć należy do nich głównie fakt, że czasami, zwłaszcza w sytuacjach kiedy bardzo zależy nam na czasie, mimo wszystkich uproszczeń ich użycie jest zbyt skomplikowane. Głownie dlatego, że mimo najnowszej technologii powiedzenie czegoś w bezpośredniej rozmowie jest nadal najbardziej efektywną formą komunikacji i nigdy chyba nie dorobimy się innej równie efektywnej. Drugą dużą wadą jest dla mnie to, że mimo wprowadzenia centralnego miejsca przechowywania informacji większość z tych narzędzi nie zapewnia kontroli wersji notatek, które tam się znajdują. To znaczy, że jeżeli ktoś wprowadzi jakąś informację to później można ją edytować i nie pozostawia to żadnego śladu. Takie zachowanie może wprowadzić szybko chaos komunikacyjny, zwłaszcza jeżeli osoby nie pracują w tej samej lokacji fizycznej. Kolejną wadą, czy też w tym przypadku raczej cechą, jest to że trzeba być bardzo świadomym wybierając to a nie inne narzędzie. Nie do każdego projektu one się nadają i realizacja nie każdego może być aż tak uproszczona. Ze względu na brak możliwości wymuszania sekwencji wykonywania zadań bardzo duża część projektów nie będzie mogła być efektywnie zarządzana.

Na koniec wypada tylko dodać, że jest to kolejna klasa narzędzi, którą warto znać. I używać wtedy i tylko wtedy kiedy ma to sens i jest właściwe dla danej sytuacji. Zdrowy rozsądek musi w pracy kierownika projektów odgrywać rolę pierwszoplanową.

Innowacja zarządcza

Wśród wszystkich innowacji, które może wprowadzić firma jest jeden typ, który zajmuje miejsce szczególne. Tym typem są tak zwane innowacje zarządcze (mangement innovation).

Mianem innowacji zarządczej określa się innowację polegającą na odejściu od tradycyjnych paradygmatów zarządzania w danej branży lub danym rynku. W wyniku takiej innowacji powstają nowe procesy, praktyki czy też struktury zarządzania pozwalające firmie działać w sposób odmienny od całej konkurencji. Celem takiej innowacji jest to, aby firma po przekształceniach miała znaczącą przewagę konkurencyjną nad innymi uczestnikami rynku.

Przykłady? Każda firma pracująca w systemie projektowym jak ognia unika kar umownych za opóźnienie końca projektu. A co by się stało, gdyby pojawiła się firma, która sama dobrowolnie będzie chciała wpisywać takie kary do umów i to w kwocie znacznie przekraczającej to co do tej pory chciał zamawiający? Większość firm produkcyjnych produkuje pod prognozy sprzedaży, zwykle w perspektywie 6-12 miesięcy. Co by się stało, gdyby dostawca nie wymagał od sklepu prognoz sprzedaży, a i tak zawsze zapewniał mu dostępność towaru? “Wszyscy wiedzą”, że aby zacząć prace nad systemem informatycznym trzeba wcześniej dokładnie zdefiniować wymagania. A co by się stało, gdyby stworzyć proces, który tego nie wymaga? Jaką siłę na rynku miałyby takie firmy? Jak na ich oferty reagowaliby klienci?

Piękno innowacji zarządczej polega na tym, że zbudowana na jej podstawie przewaga konkurencyjna jest niezwykle trudna do skopiowania przez innych uczestników rynku. Z zewnątrz wszystko wygląda bowiem prosto i logicznie, tym niemniej dzięki temu, że jest to odejście od paradygmatu konkurencja nie może skopiować innowacji tylko poprzez skopiowanie praktyk czy procesów. Konkurencja musiałaby również zmienić swój paradygmat zarządzania. A to jest bardzo trudne. I wielu się nie udaje. Najlepszym przykładem są tutaj amerykańskie i zachodnioeuropejskie firmy produkcyjne, które próbują skopiować TPS (Toyota Production System). Niestety, mimo że TPS jest dość dokładnie opisany jego skopiowanie, rozumiane jako uzyskanie takich samych efektów biznesowych, idzie bardzo opornie i nawet jeżeli teraz możemy już mówić o jakichś sukcesach to zajęło to jakby nie patrzeć kilkanaście lat.

Tak więc innowacja zarządcza pozwala zbudować relatywnie trwałą przewagę konkurencyjną. Na tyle trwałą, aby można było bez pośpiechu przygotować kolejną innowację. Niestety ceną za taki komfort jest fakt, że innowacja zarządcza jest niesamowicie trudna do opracowania a jeszcze trudniejsza do wdrożenia. Dokładnie z tych samych powodów dla których tak trudno skopiować ją konkurencji. No ale cóż, tylko odważni i wytrwali zdobędą szczyty...

Jeżeli to kogoś zainteresowało to jedynym znanym mi systematycznym procesem pozwalającym na szukanie i weryfikację pomysłów na innowacje zarządcze są narzędzia myślowe oparte o TOC. Zaś implementacje takich innowacji można znaleźć opisane w Strategy & Tactic Trees opublikowanych przez Goldratt Institute Inc.

Organizacja a miary

Poniższy tekst po redakcji będzie stanowił wstęp do skróconej wersji książki "Finanse do góry nogami".

Jednym z często poruszanych problemów zarządzania jest tzw. zarządzanie zmianą. Ten aspekt zarządzania najczęściej poruszany jest w kontekście kłopotów, które sprawia wprowadzenie zmian w zachowaniach ludzkich. Taki pogląd opiera się na popartej doświadczeniem obserwacji, że wprowadzenie dowolnej zmiany na poziomie zarządu czy kierownictwa firmy jest bardzo proste, wymaga zwykle jednego lub dwóch spotkań i ustalenia pożądanego kierunku. Natomiast dokonanie tego samego na poziomie zachowań wszystkich pracowników organizacji niespodziewanie staje się bardzo trudne. Pracownicy „nie chcą” się zachowywać zgodnie z wprowadzonymi zasadami.

Doświadczenie wielu organizacji stanowi jednak, że wbrew pozorom pokonanie tego pozornego oporu przed zmianą jest dość proste. Prostota wynika z zauważenia, że zachowania osób będących w organizacji są sterowane poprzez miary, które organizacja stosuje. Z tego powodu nie można oczekiwać prawdziwych zmian w organizacji, jeżeli nie zmieni się systemu miar. Z drugiej zaś strony, i to jest kluczowe spostrzeżenie, jeżeli zmieni się miary to organizacja dostosuje się do nich i zmiany będą albo samoistne albo bardzo łatwe do przeprowadzenia.

Na przykładzie zmian w organizacjach dotyczących wprowadzenia nowoczesnych metod zarządzania w miejsce zastałych wyodrębniono bardzo często popełniany błąd prowadzący wprost do zniweczenia całego procesu wprowadzania zmiany. Błędem tym jest skupienie się podczas wprowadzania zmiany tylko i wyłącznie na zmianie przekonań wyższego kierownictwa oraz na wprowadzeniu konkretnych praktyk nowego sposobu zarządzania. Zwykle polega to na przekonaniu przez konsultanta zarządu do nowej koncepcji oraz sprzedaniu odpowiedniej ilości segregatorów zawierających instrukcje jak swoją pracę mają wykonywać pracownicy. To jednak jest za mało aby odnieść sukces we wprowadzaniu zmiany – głównie ze względu na pojawiający się od razu „opór przed zmianą”. Odniesienie sukcesu gwarantuje tylko wprowadzenie rozwiązania całościowego, czyli oprócz zmiany przekonań i wprowadzenia praktyk powinno zmienić się także miary obowiązujące w organizacji. Prawidłowo przeprowadzony proces zaczyna się od zmiany przekonań kierownictwa. Te przekonania powinny posłużyć do zdefiniowania systemu miar w organizacji, który pozwoli mierzyć dostosowanie się organizacji do nowego sposobu zarządzania. Miary te jednocześnie powinny być tak skonstruowane, aby wspierać stosowanie nowych praktyk. Wdrożenie zaś praktyk to ostatnie co powinno zostać zrobione w procesie wprowadzania nowych metod zarządzania.

Pominięcie środkowego elementu powyższego procesu (czyli definiowania systemu miar) powoduje, że nowe praktyki stają często w sprzeczności ze stosowanym systemem miar. Ze względu zaś na to, że każdy z nas lubi jak się go docenia i jak uzyskuje dobre wyniki to podświadomie będzie starał się tak działać, aby wyniki w nadal stosowanym systemie pomiarowym były dobre. To zaś powoduje, że nie ma wsparcia dla nowych praktyk i są one bardzo szybko zastępowane starymi nawykami. Tymczasem zmiana stosowanych miar powoduje, że nawet jeżeli stare nawyki dalej pozostają, to nie są one wspierane przez system. Często wystarczy sama zmiana sposobu pomiaru, aby całkowicie zmienić zachowania w organizacji. Etap dystrybuowania segregatorów z nowymi instrukcjami można wtedy pominąć.

Rachunkowość przerobowa stanowi obecnie najprostszy i najskuteczniejszy system miar wspierający zmiany systemów zarządzania w organizacjach. Doświadczenia praktyków wskazują, że najbardziej pozytywną zmianą dla organizacji jest wprowadzenie nowego wskaźnika produktywności dla firmy, wyrażonego stosunkiem T/OE (przerób/koszty operacyjne). Ta miara zastępuje tradycyjny miernik efektywności kosztowej w firmie. Wskaźnik zdefiniowany w nowy, prosty sposób jasno uzmysłowia wszystkim w organizacji, że zwiększanie kosztów operacyjnych jest dobre – o ile zwiększa to przerób w sposób jeszcze bardziej znaczący. Zastosowanie takiego miernika, podobnie jak innych mierników rachunkowości przerobowej, bardzo szybko prowadzi do nastawienia całej organizacji na realizację jej celu głównego, czyli zarabiania pieniędzy teraz i w przyszłości.

Dyspozytor vs. Delegujący

Jak wiadomo instytucję szefa wymyślono między innymi po to, aby zarządzać zestawami zadań zbyt dużymi do zrealizowania przez jedną osobę. Istnieją dwie metody w ramach których szef może podzielić się swoim zadaniem. Umownie nazwijmy to byciem dyspozytorem bądź delegującym. Dyspozytor to osoba, która przekazuje konkretną instrukcję do wykonania. Rozdziela pracę rozumianą jako zadania do wykonania. To znaczy każdy z członków zespołu otrzymuje listę rzeczy do wykonania a następnie rozliczany jest z tego czy postąpił zgodnie z przekazaną instrukcją.

Delegowanie natomiast to zupełnie inne podejście. Zamiast przekazywać zadania przekazuje się odpowiedzialność. Czyli określa się pożądany cel i jego parametry jakościowe, natomiast nie przekazuje się wprost instrukcji jakie zadania i w jakiej kolejności należy wykonać, aby określony cel uzyskać. W tym podejściu zakłada się, że sposób dojścia do celu najlepiej znany jest osobom faktycznie wykonującym daną pracę a nie menedżerom. Rolą menedżera jest przekazać odpowiedzialność, zapewnić pracownikowi środowisko, w którym może wykonywać swoją pracę bez przeszkód a następnie odebrać prace sprawdzając czy założone cele zostały osiągnięte.

W metodach zwinnych zarządzania projektami tak naprawdę możliwa jest do zastosowania tylko i wyłącznie metoda druga. Próba zastosowania metody pierwszej (dyspozytora) prowadzi bardzo szybko do powstania wąskich gardeł zarządczych na poziomie kierowników. W środowiskach agile za dużo rzeczy dzieje się zbyt szybko, aby kierownik mógł panować nad nimi na poziomie zadań do wykonania. Jeżeli chcemy aby w naszym środowisku osiągać szybko rezultaty to jedyną opcją jest przekazywanie odpowiedzialności. Fakt, menedżer traci kontrolę nad sposobem wykonywania pracy i musi swoim ludziom zaufać. Ale jednocześnie zyskuje możliwość osiągnięcia końcowego rezultatu wielokrotnie szybciej niż przy użyciu bardziej tradycyjnej metody dyspozytorskiej.

Należy tylko pamiętać, aby razem z odpowiedzialnością wydelegować uprawnienia. Najgorszą sytuacją, którą można zafundować swoim podwładnym jest dać im odpowiedzialność za coś, ale bez uprawnienia do decydowania o wszystkich zasobach i środkach potrzebnych do wykonania danej pracy. Stawiamy wówczas pracowników przed koniecznością wykonania pracy na którą nie mają wpływu. Nie mogą więc sami decydować o jej sukcesie bądź porażce. Taka sytuacja prowadzi wprost do dużej i narastającej frustracji osób zaangażowanych w projekty.

Last but not least wypadałoby jeszcze pamiętać o różnicach kulturowych. Ci z Was, którzy mieli przyjemność pracować z Hindusami dokładnie wiedzą, że zastosowanie znajduje tylko i wyłącznie jedna z opisywanych metod.

Obciążenie systemu

Ludzie instynktownie rozumieją, że jeżeli obciążymy serwer do 100% jego mocy spowoduje to nagły spadek wydajności, drastyczne zwiększenie czasu oczekiwania na odpowiedź oraz ogólnie rozumiany brak stabilności. Jednocześnie tak bardzo dziwią się jak Google może utrzymać krótki czas reakcji na zmiany na rynku, bardzo dużą wydajność pracy oraz stabilność, pozwalając swoim programistom na 20% pracy na rzecz zadań nie związanych z ich aktualnymi projektami.

Przecież to jest to samo. Tak jak serwer, aby utrzymać maksymalną wydajność i krótki czas odpowiedzi nie powinien być przeładowany pracą na więcej niż 80% tak samo pracownik, aby utrzymać maksymalną wydajność i krótki czas reakcji nie powinien być przeładowany powyżej 80% swojego czasu. Co ciekawe jeżeli obciążenie serwera zaczyna w zwykłej firmie oscylować w okolicach 80% to zwykle dyrektor działu IT natychmiast występuje z wnioskiem o zakup nowego serwera. Z drugiej strony jeżeli pracownik jest obciążony na 80% to w zwykłej firmie dyrektor (nawet ten sam) zwykle... dorzuci mu jeszcze jeden projekt. A potem bardzo się będzie dziwił, że czas oczekiwania na efekt gwałtownie rośnie a wydajność spada. Gdzie tu logika?

(temat zaczerpnięty z książki “Implementing Lean Software Development”)

Budowanie dla utrzymania

W nawiązaniu do tego, co kiedyś napisałem o wyzwaniach związanych z tworzeniem dokumentacji wdrożeniowej i utrzymaniowej oprogramowania napiszę jeszcze o jednym pokrewnym rozwiązaniu. W znanym tekście “The New New Product Development Game”* autorzy jako jeden z głównych powodów znaczącej poprawy efektywności producentów stosujących opisywane nowe metody tworzenia produktów podali korzystanie z zespołów wielofunkcyjnych. W szczególności w skład zespołów opracowujących nowe produkty wchodziły osoby z produkcji, czyli te, które później będą odpowiedzialne na wytworzenie w setkach tysięcy sztuk pomysłów inżynierów. Idea, która za tym stała była prosta i oczywista - często to, co jest optymalne z punktu widzenia inżyniera projektującego nowy produkt, wcale nie jest optymalne z punktu widzenia osoby, która ten produkt będzie musiała wykonać w tysiącach sztuk. Celem tworzenia takich zespołów miało być projektowanie takich nowych produktów, które nie tylko będą spełniały marzenia inżynierów (i marketingowców), ale jednocześnie będą proste w produkcji. Stąd zaangażowanie osób za nią odpowiedzialnych w rozwój produktu od samego początku projektu.

Przekładając to co zostało napisane na temat produkcji na rozwój oprogramowania wydaje się, że odpowiednikiem produkcji (wytwarzania) jest tutaj (wbrew pozorom) wdrożenie/utrzymanie. Sytuacja wygląda bowiem tak, że zespół rozwoju projektuje nowy system, który później trafia do zespołów wdrożeniowych i utrzymaniowych, które muszą zadbać o to, aby produkt działał bezbłędnie u każdego z klientów firmy. Podobnie jak produkcja w fabryce, tak wdrożeniowcy wytwarzają gotowe, działające u klient produkty firmy software’owej, oczywiście na bazie produktu stworzonego przez inżynierów odpowiedzialnych za rozwój.

Ciągnąc tą analogię dalej w niektórych projektach warte zainteresowania jest włączenie osób odpowiedzialnych za wdrożenia i utrzymanie (maintenance) do zespołów wytwarzających produkt, czyli zespołów rozwijających nowe oprogramowanie. Taka koncepcja wygląda na pierwszy rzut oka dość karkołomnie, ale im dłużej się nad tym zastanawiam tym większy ma sens. Wiadomo, że włączenie tych osób do zespołu spowoduje, że system będzie inaczej zaprojektowany. Zarówno te osoby, które muszą system zainstalować u klienta jak i te, które potem muszą odpowiadać na klienckie zapytania i/lub radzić sobie z błędami zgłaszanymi przez klienta będą miały mnóstwo pomysłów na usprawnia. Oczywiście jedną ze strategii jest je po prostu zbyć, ale... Ale tak naprawdę to one wystawiają swoją głowę klientowi na ścięcie i to od efektywności ich pracy zależy postrzeganie firmy przez organizację klienta. I nawet pomijając to jaki jest cel tej gry, to jak wiadomo każdemu z nas pensje tak naprawdę płaci... klient naszej firmy.

* Tekst znany jest głównie z tego, że w nim jako w pierwszym w literaturze pojawiło się określenie SCRUM na zespół pracujący zgodnie z metodami “lekkimi” - pojęcie agile jeszcze wtedy nie istniało. Sam artykuł ukazał się w Harvard Business Review, ale jak to kogoś interesuje to można go sobie wygooglać w formie PDFa. W tytule nie ma błędu.

Kosmiczne agilowe innowacje

W pierwszy dzień Świąt na TVN24 wyemitowano bardzo ciekawy reportaż dotyczący oryginalnego konceptu i historii przyznania X Prize. Dla niezorientowanych: nagrodę XPrize w wysokości USD 10 mln ufundował wówczas nieznany biznesmen a miała ona być przyznana pierwszej drużynie, której uda się skonstruować komercyjny statek kosmiczny, który w ciągu 2 tygodni dwukrotnie wyniesie na niską orbitę (100 km) dwie osoby. Miało to otworzyć drogę do kosmicznej turystyki. Nagrodę zdobył w 2004 roku zespół pod kierownictwem konstruktora Burta Rutana. Reportaż cały był arcyciekway, ja zwrócę uwagę na dwie rzeczy.

Jednym z zespołów startujących do XPrize, któremu nie udało się wtedy wygrać, był Armadillo Aerospace. Jego kierownik opowiadał o tym jak przygotowywali się do stworzenia pojazdu. Po pierwsze zespół składał się z ludzi o różnych zainteresowaniach i umiejętnościach, ale wspólnie stanowili całość, która była w stanie zaprojektować i zbudować pojazd. Po drugie pracowali i pracują głównie społecznie, bez znaczącego wsparcia finansowego, więc musieli wymyśleć jak najbardziej efektywny sposób pracy. Sposób ten polegał na tym, że co tydzień budowali prototyp, przeprowadzali próbę oraz następnie zbierali dane i wyciągali wnioski. W następnym tygodniu od nowa. Coś Wam to przypomina? I neich mi ktoś jeszcze raz powie, że agile to tylko software a i to nie każdy. Pewnym wytłumaczeniem skąd metody agile w projektowaniu pojazdów kosmicznych niech będzie fakt, że szefem firmy jest niejaki John Carmack- współtwórca Id Software (Wolfenstein, Doom, Quake, ...). Co ciekawe metody się sprawdzają. Zespół co prawda nie wygrał oryginalnej XPrize, ale za to dwa miesiące temu skasował nagrodę za tzw. poziom pierwszy Northrop Grumman Lunar Lander Challenge. I jako jedyny podszedł to poziomu drugiego, na razie niestety bez rezultatu (szczegóły w wideo na podanej stronie).

Moja druga obserwacja z całego tego reportażu jest natomiast zupełnie inna. Reportaż otworzył mi oczy na to jakie gospodarcze znaczenie miała X Prize. Powstało kilkadziesiąt firm, setki ludzi podjeło wyzwanie i stanęło do walki o nagrodę. Ilość wytworzonej w ten sposób wiedzy, innowacji i produktów naprawdę wysokiej technologii jest nie do przecenienia. Oczywiście były i sukcesy jak i porażki - parę firm zbankrutowało, parę innych bardzo słabo sobie radzi. Jednak patrząc się na całość nie mogę odeprzeć wrażenia, że skutki były więcej niż pozytywne. To wszystko zostało spowodowane przez sumę 10 mln dolarów amerykańskich, czyli mniej więcej 30 mln PLN. To tyle, ile mniej więcej kosztuje wyremontowanie 1 km ulicy w mieście. I znowu pojawia się u mnie to pytanie: dlaczego u nas tak nie można??? Czy nas naprawdę nie stać na te 30 mln, czy też chodzi o co innego? Za wskazówkę niech świadczy fakt, że w Google Lunar X Prize starują obok drużyn z USA taże Włosi, Niemcy, Duńczycy, Szwajcarowie, ale także... Malezyjczycy i ..... Rumuni. Polacy nie :-(

Wdrożenia nowych metod - zadanie domowe

W środowisku osób zajmujących się wdrożeniami systemów zarządzania projektami (chodzi tu o systemy rozumiane jako zestawy procesów a nie oprogramowanie) do rangi anegdoty kultowej urosło podobno prawdziwe zdanie, wypowiedziane przez jednego z konsultantów pod koniec długiego i kosztownego projektu wdrażania nowej metody zarządzania projektami w pewnej firmie (XXX - nazwa metody zarządzania projektami):

“Jak na dziś to wszyscy już rzygają tym naszym XXX, w związku z czym wdrożenie uważam za w pełni zakończone sukcesem!!!”

Hmm. Przypadek wręcz kliniczny, który przypomniał mi się w ramach kolejnej rundy rozważań nad pewnym nieudanym wdrożeniem metod agile. Pytanie brzmi następująco. Jeżeli wdrażamy coś (cokolwiek) nowego w organizacji i jako efekt dostajemy aktywne niezaangażowanie osób do których adresowane było wdrożenie tego czegoś, to o czym to świadczy? Hipoteza jest taka, że po prostu nie odrobiliśmy pracy domowej i wdrożyliśmy rzecz, która jest absolutnie niepotrzebna z punktu widzenia osób zaangażowanych lub mimo, że rzecz jest potrzebna, to sposób jej wdrożenia jest nieadekwatny. Przez rzecz niepotrzebna rozumiem nie pozwalająca jednostkom na osiąganie lepszych rezultatów. Rezultatów mierzonych w sposób taki w jaki się je mierzy dla każdego konkretnego człowieka w tej konkretnej organizacji. Innymi słowy, mówiąc kolokwialnie z wprowadzonej przez nas zmiany człowiek “nic nie będzie miał”.

Oczywiste pytanie to czy każdy musi z tego wdrażanego rozwiązania coś mieć. Jasne, że tak! Bo skoro organizacja jako całość ma na danej nowości zyskać, to dlaczego nie mieliby zyskać poszczególni uczestnicy tej organizacji? Wszyscy uczestnicy. Z jakiego powodu tak często zakładamy, że wdrożenie czegoś nowego musi być robione przeciw ludziom a nie z ludźmi? Czy naprawdę jeżeli wdrażamy coś nowego to musi być tak, że ktoś będzie "rzygał" tym rozwiązaniem? Moja hipoteza jest taka, że absolutnie nie. Jeżeli rozwiązanie jest dobre dla całości organizacji, to musi być sposób, aby skonstruować je tak, aby było dobre dla wszystkich osób w nią zaangażowanych (odwrotnie nie działa). Powtarzam wszystkich. Tylko trzeba ten sposób znaleźć, dokładnie analizując sytuację.

Przed wdrożeniem trzeba odrobić pracę domową i zobaczyć jak zmiany proponowane przez agile mogą pomóc wszystkim innym interesariuszom projektów w organizacji. Ta pomoc musi zwłaszcza być sprawdzona w odniesieniu do miar, którymi mierzona jest efektywność pracy poszczególnych kierowników. Chodzi o to, aby tak skonstruować system zarządzania, że wprowadzenie nowych reguł spowoduje z punktu widzenia poszczególnych jednostek zmiany pozytywne. Bo na przykład będzie łatwiej osiągać właściwe cele lub choćby prezentować wyniki. Jeżeli nie zadbamy o to, aby wszystkim ważnym interesariuszom było łatwiej to osiągniemy efekt podobny do wyrażonego w przytoczonym cytacie. I osoby aktywnie niezaangażowane we wdrożenie, powodujące realne zagrożenie jego powodzenia.

Stąd, jak już kiedyś pisałem, jednym z większych błędów jakie można zrobić przy wdrażaniu agile jest wdrożenie samych tylko procedur. Trzeba zmienić jeszcze także inne elementy organizacji. A to jak je zmienić i na jakie, tak aby spowodować z jednej strony akceptację, a z drugiej zakładany efekt biznesowy to już jest zadanie domowe dla tych, którzy agile wdrażać będą. I gwarantuję dwie rzeczy:

1. nie jest to proste
2. nie ma gotowych rozwiązań (porównaj).

Innowacje organizacyjne

Na początek trochę teorii i rozważań "podstawowych".

Świat jest przez nas opisywany za pomocą pewnych reguł. Stałych i niezmiennych. Te reguły określają to w jaki sposób działa świat (np. masy się przyciągają). Na podstawie reguł, które naszym zdaniem opisują świat, tworzymy pewnego typu metody i procedury, które są niczym innym jak zastosowaniem tychże reguł do konkretnego środowiska (np. szklankę stawiamy na stole a nie obok stołu - bo spadnie, co wynika wprost ze wspomnianej wcześniej reguły).

Przy takim spojrzeniu na organizacje działające w świecie rzeczywistym możemy założyć, że są dwie metody wprowadzania innowacji w organizacji. Pierwszy to zmiana metod i procedur. Po prostu jak chcemy wprowadzić coś nowego to zaczynamy od tego, że zmieniamy sposób działania ze starego na nowy. Następnie sprawdzamy czy nowy sposób działa lepiej czy gorzej, oczywiście względem pewnego konkretnego wskaźnika, który powinniśmy wyznaczyć zanim cokolwiek zaczniemy zmieniać. Ten sposób nazywa się często z angielska learning-by-doing.

Jest też drugi sposób wprowadzania innowacji, który o ile dobrze kojarzę nazywa się learning-by-understanding. Ten sposób zakłada, że zanim zaczniemy zmieniać cokolwiek w metodach i procedurach powinniśmy przeanalizować reguły, które rządzą danym kawałkiem rzeczywistości. W tym zwłaszcza upewnić się, czy to co wydaje się nam regułą opisującą daną rzeczywistość na pewno nią jest. Można tu zastosować metodę naukową. Dopiero jak mamy wystarczająco dobre reguły, to na ich podstawie konstruujemy metody i procedury. Tak aby wypełniały te zidentyfikowane reguły w konkretnym środowisku.

Powyższe uwagi są uwagami ogólnymi, ale jak najbardziej stosują się do agile a tak konkretnie do wdrażania metod zwinnych w organizacjach. Wielkim błędem jest wdrażanie metod "bo tak wszyscy robią", czy z innych tego typu powodów. A tak niestety często się dzieje. Niestety. To jest typowe podejście zmiany procedur i metod oraz później modlenia się o rezultaty. Stosując nielubiane przez mnie porównania wojskowe jest to podobne do radzieckiego "rozpoznania bojem". Ze względu na historycznie przetestowany poziom strat własnych podejście jest bardzo niezalecane. Zalecane jest za to sprawdzenie jakie reguły obowiązują w danym wycinku rzeczywistości, w którym porusza się dana organizacja. Dopiero na tej podstawie można skonstruować zestaw metod i procedur, które wdrożone przyniosą dokładnie taki efekt jak spodziewany.

To, co opisałem powyżej jest jedną z przyczyn dla której nie słyszałem o udanym wdrożeniu metod zwinnych, które było przeprowadzone ściśle według książki. Po prostu książki opisują pewną wiedzę ogólną a każda z organizacji działa w trochę innym otoczeniu, więc zestaw praktyk i metod musi być inny (choć reguły mogą, ale nie muszą, być takie same). I stąd właśnie do wdrożenia metod zwinnych często firmy potrzebują pomocy z zewnątrz - aby ktoś bezstronny "obejrzał" daną organizację i pomógł zdefiniować właściwe działania.

Jak upowszechnić ideę, czyli dlaczego zostanie tylko SCRUM

Witam po dłuższej przerwie wakacyjnej. W każdym razie żyję i teraz już postaram się wrócić do zwykłej częstotliwości pisania.

Na początek temat tylko z pozoru odległy od głównej tematyki tego bloga. W trakcie wakacji kilkukrotnie powróciło do mnie zagadnie czynienia nowej idei popularną. Chodzi o sytuację, kiedy mamy nową (innowacyjną) ideę i chcemy ją upowszechnić. Niektórzy puryści powiedzą w tym momencie, że to nic trudnego, po prostu trzeba tą ideę sprzedać używając „zwykłych” metod marketingu i sprzedaży, postępując podobnie jak z każdym innym produktem. Być może mają rację. A nawet mają ja na pewno. Ale ja się zacząłem zastanawiać nad czymś innym. Jaka powinna być konstrukcja systemu, w którym krąży rzeczona idea, aby tenże system był w stanie w sposób najbardziej skuteczny upowszechnić tą właśnie ideę wśród firm (uwaga to ważne: mówimy o upowszechnieniu wśród organizacji komercyjnych).

Czyli sytuacja wyjściowa jest następująca: mamy nową, dobrą ideę, czyli na przykład agile project management i chcemy, żeby koncepcja ta przedostała się do świata firm i była tam używana. Jaki system zbudować, aby to było możliwe?

Jeden z modeli takowego systemu, który służy upowszechnianiu idei został mi zasugerowany przez Marka Kowalczyka. Po drobnych zmianach system ten, nazwany przeze mnie „modelem guru”, wygląda mniej więcej tak:

W centrum tego modelu stoi „guru” – osoba, która jest niekwestionowanym autorytetem jeżeli chodzi o daną koncepcję, czy też ideę, najczęściej jej twórca. Osoba ta najczęściej przekazuje swoje idee poprzez książkę swojego autorstwa, która zawiera jedynie właściwą wykładnię tego, co jest treścią idei. Książka najczęściej nie jest jedna, tylko robi się z tego cykl, każda następna prezentująca kolejną odsłonę idei. Książka jest głównym nośnikiem marketingowym, pozwalając dotrzeć do masowego odbiorcy za bardzo sensowne pieniądze (dla odbiorcy). Te osoby, które po przeczytaniu książki zainteresuje idea są następnie zachęcane do odbywania spotkań z „guru” lub osobami przez niego wskazanymi, na których to spotkaniach można zgłębić kolejne tajniki wiedzy. Całą tą machinę aktywnie wspiera sieć społeczna zbudowana wokół idei. Sieć taka zwykle opiera się o jakąś formę portalu webowego lub sieć stowarzyszeń/klubów w których spotykają się osoby zainteresowane tą właśnie ideą. Sieć ta ma zwykle jakiś sposób na wyróżnienie swoich członków spośród innych ludzi. Takim sposobem są na przykład wszystkiego typu gadżety reprezentujące idee: teczki, koszulki, kubki, zakładki do książek, etc. Zwykle sprzedawane po cenach absurdalnie wysokich.

Model powyższy został w praktyce zaimplementowany i sprawdza się znakomicie w pewnych przypadkach. Przykładami „guru” i stojących za nimi idei rozpowszechnianych w takim modelu są między innymi: Stephen Covey (7 nawyków skutecznego działania), Robert Kiyosaki (Bogaty Ojciec), Anthony Robbins (The Power Within) czy w końcu David Allen (GTD). Wymienione przykłady dowodzą, że model ten działa i w oparciu o niego można skonstruować sprawnie działający mechanizm szerzenia idei i (przy okazji) zarabiania pieniędzy.

Wymieniony model ma jednak dość znaczącą wadę. Otóż nigdzie nie ma dowodów na to, że pozwala on w sposób efektywny sprzedawać idee do firm. Wszystkie wymienione koncepcje są nakierowane na sprzedaż dla jednostek a nie dla organizacji. Mimo, że może nawet wystąpić sytuacja kiedy to firma płaci za seminarium GTD czy dowolne inne to nadal cały czas ta idea jest sprzedawana poszczególnym osobom w ramach organizacji. Czy ktoś kiedyś słyszał, żeby firma działała według 7 nawyków, aby według GTD albo czegoś podobnego? Nie. Firmy działają według Lean, CMMI, SixSigma, ISO, PMI czy Prince2 . W tym momencie mnie tknęło. Następnym logicznym pytaniem jest bowiem: czy te wszystkie koncepcje też mają wspólny model wokół którego się obracają? Analiza wykazała: mają.

„Model standardu” jest drugim modelem upowszechniania idei, który sporządziłem próbując dokonać reverse engineeringu na koncepcjach odnoszących największe sukcesy w firmach. Takich, które zostały już wielokrotnie wdrożone i które są znane większości osób zaangażowanych w daną działkę przemysłu. „Model standardu” prezentuje się w sposób następujący:

Zgodnie z nazwą w centrum modelu jest standard. Koniecznie spisany, dostępny albo za darmo, albo (częściej) w postaci płatnego wydawnictwa. Standard ten jest oficjalnie opracowany i utrzymywany przez pewną organizację, która jest zwykle pomysłodawcą idei. Ta sama organizacja zajmuje się certyfikacją, która jest kolejnym elementem modelu. Organizacja, która wymyśliła ideę rości sobie prawo do oceniania i certyfikowania z zakresu propagowanej idei. Odbywa się to zwykle dwutorowo. Po pierwsze organizacja może przetestować i certyfikować poszczególne osoby/organizacje pod kąte tego jak dobrze znają one dany standard. W ten sposób powstają wszystkie dyplomy, certyfikaty, stopnie dojrzałości itp. Drugi zakres działania organizacji certyfikującej jest jeszcze ciekawszy: dotyczy certyfikacji organizacji, które mogą propagować standard dalej. Czy organizacja, która wymyśliła pierwotną ideę, daje swoistą licencję innym organizacjom na propagowanie tej właśnie idei. Zauważyłem zresztą, że bardzo rzadko ta organizacja, która wymyśliła ideę sama dostarcza np. wiedzę z jej zakresu. Ona wynajmuje do tego „niezależnych”, certyfikowanych dostawców. Cudzysłów jest dlatego, że ci dostawcy są w 100% zależni od organizacji certyfikującej, gdyż brak ich uznania, cofnięcie certyfikatu w większości wypadków skutkowałby natychmiastowym wypadnięciem z rynku. Na koniec jako element propagowania idei jest jeszcze coś takiego jak sieć kontrahentów. Chodzi tu o to, że organizacje certyfikujące poprzez swoich „niezależnych” dostawców często wymuszają na przedsiębiorstwach, że w momencie implementacji standardu będą „namawiać” swoich partnerów do przyjęcia tego samego standardu. „Właśnie wdrożyliśmy ISO i aby utrzymać wymaganą jakość oczekujemy, że za 6 miesięcy wszyscy nasi dostawcy też wdrożą ISO”. Działa rewelacyjnie, zwłaszcza jak pierwszym podmiotem, który tak mówi jest organizacja rządowa udzielająca zleceń (przypadek PMI, Prince2 czy CMMI).

Jaki jest powód tego, że „model standard” jest znacznie skuteczniejszy w sprzedawaniu idei do firm niż „model guru”? Według mnie klucz leży w modelu potrzeb Maslowa a konkretnie w drugiej kluczowej potrzebie każdego człowieka, czyli potrzebie bezpieczeństwa. W tym wypadku bezpieczeństwa zawodowego menedżera, który podejmuje decyzje o wdrożeniu danej idei. W przypadku „modelu guru” idea taka nie jest dla niego bezpieczna, gdyż opiera się o konkretnego, jednego człowieka. Czy jakikolwiek wysoki szczeblem menedżer pozwoli, żeby jego firma opierała się o idee jednej jednostki, jednego człowieka? Nie. Zupełnie inaczej natomiast wygląda sytuacja, kiedy mamy wdrożyć znany na rynku standard wspierany przez „niezależną” instytucję certyfikującą i „niezależnych” dostawców wiedzy. Zresztą tych dostawców jest wielu w odróżnieniu od „modelu guru”, gdzie zwykle dostawca jest jeden (firma założona przez twórcę idei).

I tak na koniec. Dlaczego piszę o tym na tym właśnie blogu? Otóż próbowałem przeanalizować sobie w jaki sposób próbuje się upowszechniać koncepcje agile project management. Wydaje mi się, że do tej pory wszystkie koncepcje agile były upowszechniane w sposób przypominający „model guru”. Dwa najbardziej jaskrawe przypadki to Alistair Cockburn z jego metodami Crystal oraz Ken Schwaber i SCRUM. Upowszechnianie idei w ten sposób jakoś szło. Ken Schwaber, Mike Cohn oraz Esther Derby, jako jedyni spośród „guru” agilowych, zdecydowali się jednak powołać Scrum Alliance. „Niezależną” organizację trzymającą pieczę nad standardem oraz certyfikującą „niezależnych” dostawców. Jeżeli moje rozważania są poprawne oznacza to, że prędzej czy później, ale raczej prędzej SCRUM upowszechni się jako jedyna słuszna metoda zwinnego zarządzania projektami.

Zespoły - na co zwrócić uwagę

Projekty realizowane metodami agile/zwinnymi wymagają zupełnie innych zespołów niż takie realizowane metodami tradycyjnymi. Jak wiadomo zespół powinien być maksymalnie 10-12 osobowy, idealnie przebywać w jednym miejscu fizycznym, sam się zarządzać + parę innych cech, bardzo często wymienianych w literaturze. Ja natomiast dzisiaj napiszę o tych czynnikach, które mogą być potencjalnym zagrożeniem dla sprawnego działania zespołu realizującego projekt przy użyciu metod zwinnych. Na te czynniki powinno się zwrócić szczególną uwagę podejmując decyzję o realizowaniu projektu metodami zwinnymi.

Po pierwsze należy to jasno powiedzieć, choć może nie jest to twierdzenie politycznie poprawne: skuteczność zespołu pracującego metodami zwinnymi zależy w dużym stopniu od kultury miejsca pracy. Chodzi tu zarówno o kulturę organizacyjną jak i kulturę państwa/narodu, którego przedstawicielami są osoby uczestniczące w projekcie. Kultura musi wspierać prace grupowe i jednocześnie deprymować lansowanie się jednostek kosztem grupy. Praca metodami zwinnymi jest pracą grupową i na to poradzić nic nie można. I tak jak z innymi zajęciami grupowymi (na przykład sport) często zdecydowanie lepszy jest zespół składający się z osób o przeciętnych zdolnościach, ale zdolnych do współpracy od zespołu składającego się z geniuszy, którzy nie potrafią ze sobą porozmawiać, bo każdy chce tylko udowodnić swoją wyższość. To jaki charakter pracy jest uprawiany w danej organizacji zależy właśnie od kultury organizacji. I niestety zmiana tego jest bardzo trudna.

Po drugie zespoły pracujące metodami zwinnymi powinny w czasie trwania projektu móc pracować tylko i wyłącznie nad tym projektem. To niestety jest bardzo trudne do zrobienia w przypadku organizacji posiadających silną strukturę macierzową. Taka struktura zakłada bowiem, że w każdy członek zespołu projektowego ma jeszcze swojego przełożonego "liniowego", który w znaczącej większości przypadków decyduje o takich rzeczach jak awanse czy podwyżki. To oznacza, że praktycznie w każdej sytuacji niejasnej pracownicy będą słuchać swojego przełożonego liniowego a nie osób z projektu. W tradycyjnie zarządzanych projektach powoduje to duże problemy i jest m.in. jedną z przyczyn notorycznych opóźnień. W projektach zarządzanych metodami zwinnymi takie podejście jest całkowicie destrukcyjne i projekty praktycznie nie mogą się toczyć. Projekt zwinny bardzo podobny jest do wspomnianego już kiedyś przypadku operacji w szpitalu. Na czas operacji cały zespół ma być tylko i wyłącznie na sali operacyjnej. Przecież nikt nie wyobraża sobie, że nagle anestezjolog wyjdzie z sali i zajmie się sporządzaniem raportu, którego akurat bardzo potrzebuje jego przełożony "liniowy". Ciekawe, że w projektach, takie zachowanie jest uważane za coś normalnego.

Po trzecie i ostatnie (na dzisiaj) należy sobie zdawać sprawę, że zupełnie inna jest rola kierownika projektu w projekcie zarządzanym metodami tradycyjnymi a zupełnie inna jest ta rola w projektach zarządzanych metodami zwinnymi. Do tego stopnia, że niektórzy puryści zajmujący sie agile twierdzą wręcz, że w tych metodach stanowisko kierownika projektu istnieć nie powinno i nazywają je inaczej (np. SCRUM Master). Tak naprawdę nie ważne jak się ono nazwa, ważne jest, że osoba wyznaczona do kierowania powinna mieć zupełnie inne umiejętności i na co innego zwracać uwagę niż w projektach tradycyjnych. Typowym przykładem jest kwestia rozdziału zadań i podejmowania decyzji. W metodach tradycyjnych zwyczajowo to kierownik projektu podejmuje wszystkie decyzje sam, podobnie on rozdziela zadania do wykonania. Takie podejście jest zaprzeczeniem metod zwinnych. Tutaj zadaniem kierownika jest tak pokierować (przewodzić) pracy zespołu, aby decyzje były podjęte wspólnie a zadania rozdzielone na zasadzie swobodnego wyboru przez członków zespołu. To oznacza również, że kierownik stosujący zwinne metody zarządzania musi być ekspertem w dziedzinie, której dotyczy projekt. W odróżnieniu od tradycyjnego podejścia, gdzie parafrazując pewną bardzo znaną książkę "nawet pielęgniarka może poprowadzić projekt budowlany, byleby miała dobrze zdefiniowany system zarządzania projektami". W metodach zwinnych takie podejście gwarantuje porażkę.

Zwinne zarządzanie zmianą w organizacji

Parę tygodni temu obyłem inspirującą rozmowę z pewnym ciekawym człowiekiem. Rozmawialiśmy na temat projektu wprowadzenia zmian organizacyjnych w bardzo dużej firmie. Zmiany miały być na wielką skalę. Na tyle wielką, że projekt musiał być realizowany w etapach. Na sam koniec rozmowy poprzez tematykę etapów zeszło na metody skutecznego zarządzania takim projektem. Jedną z rozważanych hipotez stało się użycie metod zwinnych do zarządzania tymże projektem.

Na pierwszy rzut oka pomysł wydaje się być totalnie pozbawiony sensu. Podstawowym założeniem wszystkich metod zwinnych (wszystkiego co nazywa się agile) jest iteracyjne dostarczanie działającego produktu. Działającego produktu. A my mówimy o projekcie wprowadzenia zmian organizacyjnych. Więc nie spełniamy podstawowego założenia. Drugim założeniem bardzo ważnym dla metod zwinnych jest koncentracja na przepływie wartości dodanej dla klienta, której emanacją są definicje funkcjonalności. Dlatego w projektach zwinnych nie definiuje się struktury podziału pracy tylko strukturę podziału funkcjonalności produktu końcowego. Bo to ukończona funkcjonalność niesie wartość dodaną a nie praca wykonana. Znowu więc na pierwszy rzut oka nijak ma się to do wprowadzania zmian organizacyjnych w firmach. A na drugi rzut oka?

Załóżmy przez chwilę, że organizację jako całość traktujemy jako produkt. Klientem na ten produkt jest właściciel organizacji lub jego przedstawiciel (zarząd). Tenże produkt przynosi właścicielowi korzyści biznesowe (zwykle wyrażone dość konkretnie w pieniądzach). Aby te korzyści przynosić tenże produkt posiada zestaw funkcjonalności, pewnych działań realizowanych przez organizację, które to działania, każde z nich, ma pewną wartość dla klienta. Jeżeli by tej wartości nie miało to klient (właściciel) już dawno wyrzuciłby to działanie ze swojego produktu (organizacji).

Przy takim spojrzeniu nie ma przeszkód, aby zarządzać projektem zmian organizacyjnych przy użyciu metod zwinnych. Klient (właściciel) definiuje jakie nowe funkcjonalności powinien mieć produkt (organizacja). Na przykład organizacja powinna mieć dedykowany dział wsparcia klienta albo organizacja powinna zarządzać projektami według metod zwinnych. To jest funkcjonalność, której brakuje a która z punktu widzenia właściciela przyniosłaby realny wzrost wartości całej organizacji. Teraz taką funkcjonalność można potraktować tak jak w projektach zwinnych: rozbić na mniejsze, nadać priorytety i wspólnie z klientem zastanowić się co wdrażamy najpierw. A następnie powołany zespół projektowy ds. zmian organizacyjnych zacząłby takie zmiany wdrażać. Produktem dostawy po każdej iteracji byłaby cała organizacja, która wykazywałaby działające kolejne elementy zdefiniowanej funkcjonalności.

Takie podejście do tematu zmian organizacyjnych po krótkim zastanowieniu wydaje się być obiecujące. Nie dość, że wydaje się być możliwe do wdrożenia to ma jeszcze dwie ważne cechy. Po pierwsze traktując organizację jako produkt z określonymi funkcjonalnościami spowodujemy, że definiując co trzeba zmienić będziemy się patrzeć na funkcjonalności właśnie a nie działania, które mamy przeprowadzić. Podobnie jak w przypadku zwinnych projektów przestajemy rozmawiać o działaniach a zaczynamy się skupiać na efektach, które te działania mają przynieść. Dzieje się tak, gdyż właściciel podobnie jak klient chce efektów a nie działań. Druga ważna sprawa wynika wprost z poprzedniej. Skupienie się na efektach oznacza, że będziemy musieli rozważać wartość biznesową każdego z nich. (każdej nowej funkcjonalności, którą będzie miała mieć organizacja). A analiza wartości biznesowej wprowadzanych zmian jest czymś, co w przypadku tradycyjnie zarządzanych projektów zmian organizacyjnych rzadko się zdarza. Potencjalnie uzyskujemy bardzo dużo.

Powyższe to czysta spekulacja, ale czy to zadziała? Zgodnie z duchem zasad projektów zwinnych teoretyczna negacja jest zabroniona. Trzeba by przeprowadzić eksperyment. Szukam chętnych. Adres email w informacji o mnie po prawej stronie.

Przejrzystość – przykład

W nawiązaniu do posta o przejrzystości.

Znany mi jest przypadek projektu, w którym kierownik wyższego szczebla miał zwyczaj idąc po kawę wchodzić do pokoju projektowego, patrzyć się na ścianę na której były te wszystkie informacje po czym bez słowa wychodzić z pokoju. Takie „nawiedzenia” zdarzały się mniej więcej co dwa dni. Co z tego? Otóż jednocześnie ten sam kierownik (który był jednocześnie sponsorem – płacił za projekt) nigdy nie pytał kierownika projektu o status. Nauczył się sam go odczytywać i te dwie minuty raz na dwa dni mu starczały. Z kierownikiem projektu spotykali się tylko podczas demonstracji na koniec iteracji. Obaj: kierownik projektu i sponsor byli z tego bardzo zadowoleni. Pierwszy miał święty spokój a drugi czuł się najlepiej poinformowanym sponsorem w firmie. Wniosek: radiatory informacji się sprawdzają.

Metody zwinne w organizacji "stabilnej" cz. 3

Dzisiaj kolejny powód, dla którego organizacje stabilne wdrażają zwinne metody zarządzania projektami. Powodem tym jest przejrzystość prac, którą zapewniają metody zwinne.

Przejrzystość prac jest widoczna na dwóch ogólnych poziomach. Po pierwsze przejrzyste jest to co kto robi i jaki jest stopień zaawansowania prac. Podczas codziennych spotkań zespołu uczestnicy projektu opowiadają nad czym pracowali wczoraj i co będą robić dzisiaj, co skutkuje bardzo szybkim rozpowszechnianiem się informacji. Prowadzi to do jasnej sytuacji na temat tego, jakie jest aktualne zajęcie wszystkich członków zespołu. Innym, jeszcze ciekawszym narzędziem są wszelkiego typu „radiatory informacji” wykorzystywane przez zespoły do graficznej prezentacji zaawansowania prac. To temat na osobny post, ale w skrócie narzędzia te są „analogowe” (np. tablica z żółtymi karteczkami) a nie elektroniczne i mogą zawierać najważniejsze informacje zarządcze dotyczące projektu: co zostało zrobione, co jest robione, co będzie robione, a także informacje o tym jak aktualny status ma się do planu. Wszystko to jest przedstawione wizualnie. To narzędzie jest genialne w swojej prostocie a jednocześnie przekazuje zadziwiająco dużo informacji.

Drugim poziomem przejrzystości jest przejrzystość w stosunku do klienta. W tradycyjnych metodach zarządzania projektami często jest tak, że klient nie ma najmniejszej wiedzy, co się dzieje w projekcie, za który przecież płaci, aż do dnia ostatecznego odbioru produktu. Techniki zwinne zakładają inne podejście. Po pierwsze klient musi być zaangażowany cały czas. W każdej chwili zespół pracujący nad projektem ma prawo zapytać się klienta o uszczegółowienie wymagań lub potwierdzić, że wymagania zostały zaimplementowane poprawnie. Takie zaangażowanie samo w sobie daje klientowi wgląd w to, nad czym aktualnie pracuje zespół projektowy i wystarcza, aby klient nie miał pretensji, co do stopnia informowania go o stanie projektu. Jednak techniki zwinne mają jeszcze jedno potężne narzędzie: krótkie iteracje zakańczane działającą wersją produktu. Po każdej z iteracji klient może wypróbować nowe funkcjonalność stworzone podczas tej iteracji. W związku z tym klient ma cały czas poczucie, że wie, za co płaci. Wie też, kiedy pojawią się kolejne funkcjonalności do przetestowania (na koniec aktualnej iteracji). To z punktu widzenia klienta zapewnia pełną przejrzystość i pozwala na utrzymanie bardzo dobrych relacji z dostawcą. Uwaga!!! Trzeba być jednak świadomym, że taka sytuacja nie powstanie od razu i jej wypracowanie będzie wymagało włożenia odpowiednio dużej ilości czasu w ustalanie zasad współpracy z klientem.

Inną stroną przejrzystości prac jest to, o czym wspomniał jakiś czas temu w komentarzach Marcin (tutaj). Przejrzystość może być bowiem bardzo niewygodna dla tych, którzy mówiąc delikatnie „nie lubią” pracować. Częste sprawdzanie postępu prac i konieczność wyraźnego informowania o tym co się zrobiło powoduje, że nie ma mowy o ukrywaniu się przez kilka dni nic nie robiąc. Poza ewidentnym pokazaniem szefom, że taki pracownik jest zbędny w środowiskach pracujących według metod zwinnych pojawia się bardzo silna presja ze strony grupy. Podczas wspomnianych codziennych spotkań wszyscy współpracownicy słyszą i widzą kto pracuje mało. Doświadczenie wskazuje też, że da się wyczuć kto po prostu się obija a kto rzeczywiście tworzy mało bo ma jakieś problemy. Osoby ewidentnie się obijające są pod bardzo dużą presją grupy aby zabrać się do pracy.

I w ten sposób ujawnia się jeszcze jedna duża zaleta metod zwinnych: znacząco wzrasta wydajność zespołów pracujących przy użyciu tych metod w porównaniu do zespołów stosujących metody tradycyjne. Rzecz nie do przecenienia w biznesowym świecie nastawionym na efektywność prac. Co więcej wzrost tej efektywności nie ma żadnego negatywnego wpływu na atmosferę prac. Wręcz przeciwnie ma wpływ pozytywny.

Wdrażanie metod zwinnych

Metody zwinne jak wielokrotnie wskazywałem na tym blogu i w każdych innych źródłach są niezwykle proste. Pełen proces zarządzania projektem zwinnym przy odrobinie szczęścia można zapisać na kilku kartkach A4. To prowadzi do przekonania, że wdrożenie metod zwinnych w firmie jest równie proste. Ostrzegam. Wcale tak nie jest.

Główny problem polega na tym, że aby poprawnie zarządzać projektami nie zmienić i wystarczy wdrożyć samych procesów zarządczych. W większości wypadków natomiast zmiana sposobu realizacji projektów polega mniej więcej na tym, że pewnego pięknego dnia szef daje pracownikom książkę lub zbiór instrukcji i mówi „od dziś tak będziemy pracować”. Niestety tak się nie da. Być może w ten sposób można zmienić metodę zarządzania projektami z PMI na Prince2 lub odwrotnie. Natomiast jest to zdecydowanie za mało, aby przestawić firmę na zarządzanie zwinne.

Wdrożenie zarządzania zwinnego musi być skupione nie na zmianie samych procesów, ale na zmianie przynajmniej trzech elementów w firmie:

1. Procesu – tak, to jest ważne, aby wszyscy zainteresowani wiedzieli, według jakiego procesu pracują i co jest od nich wymagane. Ten element jest najprostszy – jest to czysta wiedza, którą trzeba sobie po prostu przyswoić. Są do tego książki, są szkolenia, nie ma problemu.
2. Umiejętności ludzi – zarządzanie zwinne niesie za sobą konieczność używania zupełnie innego zestawu umiejętności, zwłaszcza w obszarze międzyludzkim, niż tradycyjne zarządzanie projektami. Ze względu na bardzo duże znaczenie komunikacji międzyludzkiej i odstąpienie od dokumentowania najmniejszych szczegółów uzyskuje się z jednej strony dramatyczny wzrost wydajności, z drugiej zaś duże pole do psucia stosunków między ludźmi. Tylko osoby posiadające odpowiednie umiejętności będą mogły z sukcesem prowadzić projekty zwinne. Nabycie tych umiejętności nie jest już takie proste jak zmiana procesu. Umiejętności z definicji oznaczają, że coś się umie zrobić – to już jest praktyka a nie teoria.
3. Kultura pracy (tzw. kultura organizacyjna) – rzecz ostania, ale bardzo ważna, aby zarządzanie zwinne pokazało wszystkie swoje zalety i zapewniło oczekiwany wzrost efektywności. Kultura pracy, czyli zestaw postaw prezentowanych przez wszystkich pracowników organizacji. Tutaj musi nastąpić wielka zmiana. Choćby dlatego, aby "szefostwo" nie wymagało na początku dokładnego planu całego przedsięwzięcia a z drugiej strony sprzedaż nie próbowała usilnie sprzedać klientowi efektu końcowego drugiej iteracji (w momencie kiedy wersja produktu miała pojawić się po iteracji ósmej). Kulturę pracy zmienić najtrudniej. Nie można tego zrobić oddolnie, zawsze musi to przyjść od strony wyższej kadry kierowniczej. Podkreślam to, gdyż jest to jasna wskazówka, że bez zaangażowania i przekonania wyższego kierownictwa wdrożenie metod zwinnych nigdy nie zakończy się pełnym sukcesem a metody te nie pokażą swojego pełnego potencjału.

Podsumowując wypada mi tylko powtórzyć, że jeżeli ktoś twierdzi, że można „wdrożyć agile” poprzez danie do przeczytania książki programistom i kierownikom projektów to się bardzo grubo myli. Przeprowadzenie wdrożenia metod zwinnych tylko na jednej płaszczyźnie zamiast na wszystkich w pesymistycznym przypadku może spowodować w organizacji więcej szkody niż pożytku.

Metody zwinne w organizacji "stabilnej" cz. 1

Ostatnimi czasy metody zwinne zarządzania projektami stają się coraz bardziej popularne. Metody te najlepiej sprawdzają się w środowiskach bardzo dynamicznych, w projektach, w których występuje duża doza niepewności. Okazuje się jednak, że duża część firm działających w bardziej stabilnych środowiskach również wdraża zarządzanie zwinne. Jakie są powody tego? Na pewno swoista „moda”, ale czy tylko? Ze względu gwałtownie narastający charakter zjawiska napiszę w kilku postach, jakie mogą być powody, dla których organizacje pracujące w środowisku stabilnym wdrażają zwinne zarządzanie projektami.

Uzasadnienia nie będą w żadnej logicznej kolejności, dlatego na pierwszy ogień pójdzie powód bardzo ważny dla większości osób zaangażowanych we wdrożenia zwinnego zarządzania projektami, choć z drugiej strony być może mniej interesujący dla kierownictwa. Otóż skutkiem wprowadzenia zwinnych metod zarządzania projektami, jest to, że zespołom realizującym projekty pracuje się... przyjemniej.

Przyjemność ta wynika z kilku czynników. O jednym pisałem już kiedyś, przy okazji omawiania tematyki zmian w projekcie – w projektach zarządzanych metodami zwinnymi zespół pracuje nad zestawem funkcjonalności, które nie mają prawa się zmienić (w danej iteracji). To powoduje duży spokój psychiczny zespołu, jako że jasno określone są reguły, na podstawie których dokonywane są zmiany i nikt nie zaskakuje członków zespołu. Wbrew pozorom stabilność (choćby w ramach jednej iteracji) jest jednym z podstawowych wymogów zachowania przyjemności z wykonywania pracy.

Kolejnym bardzo dobrze wpływającym na pracę czynnikiem jest fakt, że ze swojej natury zespoły pracujące zgodnie z metodami zwinnymi są zespołami relatywnie małymi położonymi w jednej fizycznej lokacji. Bardzo częsta komunikacja między członkami zespołu powoduje dobrą atmosferę pracy choćby dlatego, że wszelkie niezrozumienia są błyskawicznie usuwane a problemy są komunikowane przynajmniej raz dziennie podczas spotkań. Poza tym w takim zespole ze względu na charakter spotkań (zarówno codziennych jak i podsumowujących iterację) każda z osób czuje się dowartościowana, bo jej zdanie jest brane pod uwagę.

Uwaga. Powyższe jest prawdą tylko o ile osoby zajmujące się koordynacją zespołów posiadają odpowiednie umiejętności komunikacyjne!!!

Praca w projektach zwinnych jest przyjemna również dlatego, że każdy z członków zespołu ma poczucie odpowiedzialności i szybką nagrodę w postaci osiągnięcia sukcesu – działający produkt na koniec iteracji. Mała wielkość zespołu w połączeniu z krótkimi iteracjami oraz tym, że na koniec każdej iteracji trzeba dostarczyć produkt wzbogacony o konkretną wartość dodaną dla klienta powoduje, że każdy z członków zespołu jest zaangażowany w dostarczanie tej wartości. Krótki czas realizacji sprawia, że każdy widzie efekty swojej pracy podczas prezentacji dla klienta. Człowiek natomiast skonstruowany jest tak, że lubi jak mu coś wychodzi.

Jak to się ma do zarządzania firmą jako całością? Ma się, gdyż jeżeli pracownikom pracuje się przyjemniej to pomaga im to pracować efektywnie. Poza tym pracownicy, którzy mają przyjemną atmosferę w pracy zwykle rzadziej myślą o zmianie pracodawcy. Jeżeli idzie to w parze z efektywnością (a idzie) to oczywistym jest, że lepiej mieć pracownika zadowolonego niż zdegustowanego.

Metody zwinne a struktura organizacyjna

Czy struktura organizacji może mieć wpływ na zdolność do działania z wykorzystaniem metod zwinnych? Mogłoby się wydawać, że nie bo co ma struktura organizacji do metod wykorzystywanych w konkretnym projekcie. A jednak...

Dla uproszczenia przyjmijmy, ze mamy cztery podstawowe struktury organizacyjne:

• Liniowa - organizacja dzieli się na działy, które realizują poszczególne elementy projektu. Każdy dział dostaje do realizacji ten kawałek projektu który odpowiada jego specjalizacji. Cała władza skupia się w rękach kierowników liniowych.
  
• Macierzowa słaba - do organizacji liniowej wprowadza się koordynatorów projektów, którzy koordynują pracę osób w poszczególnych działach. Ich zadaniem jest jednak jedynie koordynacja prac, bez możliwości realnego wpływania na pracowników. Bezpośrednimi przełożonymi pracowników są kierownicy liniowi.
  
• Macierzowa silna - różni się od macierzowej słabej tym, że pojawia się pełnowartościowy kierownik projektu, który ma odpowiedzialność za projekt ale również uprawnienia do władzy na członkami zespołu projektowego. Kierownicy liniowy pełnią funkcje pomocnicze dbając o zapewnienie personelu, bieżące zarządzanie kompetencjami, sprawy formalne itp.
  
• Projektowa - organizacja całkowicie projektowa nie posiada struktur liniowych a tylko pulę pracowników, z których wybiera się członków zespołów projektowych. Kierownik projektu ma pełną odpowiedzialność i uprawnienia do zwierzchnictwa nad członkami zespołu projektowego.
  

Którą należałoby wybrać dla realizacji projektów metodami zwinnymi? Zanim się na to pytanie odpowie najpierw kilka słów o tym czym powinien charakteryzować się zespół pracujący nad projektem metodami zwinnymi. Poniżej tylko cechy właściwe dla tej dyskusji:

1. Zespół jest interdyscyplinarny - skupia ludzi o różnych umiejętnościach ale jednocześnie każdy członek zespołu może wchodzić w różne role
   
2. Zespół ponosi pełną odpowiedzialność za wykonywaną pracę
3. Zespół ma wszelkie uprawnienia potrzebne do wykonywania zadanej pracy
4. Kluczowy członkowie zespołu pracują tylko i wyłącznie nad jednym projektem
   

W przypadku organizacji o strukturze liniowej żadna z tych cech nie mogłaby być spełniona. Nie ma interdyscyplinarności - w ramach jednego zespołu linowego osoby posiadają prawie identyczne umiejętności. Zespół nie może ponosić pełnej odpowiedzialności za całość prac, bo z definicji wykonuje tylko ten jej kawałek za który odpowiada komórka organizacyjna w której pracuje. Zespół nie ma uprawnień do wykonywania całej pracy a jedynie tego kawałka, który dotyczy ich części organizacji. Ponieważ organizacja jest liniowa a nie projektowa najczęściej pracuje "nad zagadnieniem", które jest w wielu projektach. Cecha czwarta też nie jest spełniona. W takich warunkach nie można prowadzić projektu metodami zwinnymi!!!

W przypadku organizacji macierzowej słabej cecha pierwsza ma się trochę lepiej. Zespół pochodzi z różnych działów, więc jest interdyscyplinarny. Cecha druga jednak nie jest już spełniona, gdyż nadal zespół nie posiada odpowiedzialności - posiadają ją kierownicy liniowi. Podobnie z uprawnieniami - mimo iż jest zespół projektowy to nie ma on możliwości podejmowania decyzji, która leży w gestii kierowników liniowych. Co do cechy czwartej to w tej strukturze organizacyjnej często jest możliwe osiągnięcie stanu kiedy członkowie zespołu projektowego pracują nad jednym i tylko jednym projektem.

Wszystkie cechy zespołu zwinnego są możliwe do osiągnięcia tylko w organizacjach projektowych i macierzowych silnych. Macierzowe silne muszą być na tyle silne, aby rola kierowników liniowych faktycznie ograniczała się tylko do spraw administracyjnych. Trzeba mieć możliwość traktować ich jako wsparcie administracyjno-logistyczne. Jeżeli w rękach kierowników liniowych pozostanie możliwość podejmowania (blokowania) decyzji to okaże się, że zespół zwinny nie będzie miał ani uprawnień ani odpowiedzialności za projekt.

Co z tego wszystkiego wynika? Otóż jeżeli jakaś organizacja będzie chciała wdrożyć zwinne zarządzanie projektami to musi się też zastanowić nad tym, czy jednocześnie nie należy zmienić struktury organizacyjnej. Bardzo często może to powodować spięcia. Przejście z organizacji liniowych czy macierzowych słabych do bardziej zorientowanych projektowo oznacza bowiem, że kierownicy liniowi tracą część swojej władzy. To zaś zawsze jest dla ludzi trudne...