strefa pmi nr 4, marzec 2014

ISSN 2353-3137

Kanban: stop starting,start finishing

Publikacja wydawana przez Project Management Institute www.pmi.org.pl marzec 2014 nr 4

Agile czy nie Agile oto jest pytanie

Fot.

: Shu

tter

stoc

k.co

m

Mariusz Chrapko

Krzysztof Maus

s. 45TEMAT NUMERU

Transformacja agile w firmies. 67

Dr Jerzy Stawicki

s. 1819

Pawe Brodziski

Efektywny czy zajty?s. 89, 22

TEMAT NUMERU

WWW.CYKLOPIA.COM

IDENTYFIKACJAWIZUALNA

logowizytwki

KREACJAGRAFICZNA

ulotki, plakaty, katalogikartki okolicznociowe

ilustracje, itp.

KREACJAWWW

strony WWWmailingi

newslettery

PMI WWW.PMI.ORG.PL

Redaktor Naczelny: Wojciech Danowski

Marketing i Kontakt z Biznesem: Wojciech Danowski

Fotografie: PMI PC Oddzia Gdask, Szymon Pawowski, Aleksandra Skowron, Agnieszka Krogulec, Shutterstock.com

Projekt Graficzny: Cyklopia Studio

Redakcja Strefy PMI:

3

Drodzy Czytelnicy!

"Zdolno uczenia si szybciej od swojej konkuren-cji moe by jedyn dugotrwa przewag, jak nad nimi posiadasz." Arie de Gaus

Oddaj Wam do rk nowy numer naszej gazety. Jak zwykle staralimy si zadowoli wszystkich czytelnikw, wic tematyka artykuw jest rno-rodna. Tym razem mamy artykuy, ktre spodo-baj si mionikom Agile artyku napisany przez Krzysztofa Malusa oraz tekst o wdraaniu zwin-nych metod w przedsibiorstwie, ktrym podzieli si z nami Mariusz Chrapko. Mamy te artyku Jerzego Stawickiego powicony metodzie Kanban. Polecamy rwnie wywiad Szymona Pawowskiego o PMO oraz Efektywny czy zajty? Pawa Brodziskiego. Dla ciekawych zdobycia umiejtnoci mikkich artyku Katarzy-ny Janas Co nas kreci, co nas...motywuje? i artyku Tomasza Ndzi Facylitacja w projektach.

W wydaniu elektronicznym zamiecilimy fragment ksiki Mariusza Chrapko Scrum. O zwinnym zarzdzaniu projektami.

Zapraszam do lektury oraz [email protected]

Zwinne zarzdzanie

Spis TreciOd redakcji | Spis Treci

TEMAT NUMERUAgile czy nie Agile oto jest pytanie

Krzysztof Maus

TEMAT NUMERUTransformacja agile w firmie

Mariusz Chrapko

TEMAT NUMERUEfektywny czy zajty?

Pawe Brodziski

Facylitacja w projektachTomasz Ndzi

Trzecia Edycja wydarzenia.New Trends in Project Management

How to Create a World-Class PMO?Szymon Pawowski

Co nas krci, co nas... motywuje?Katarzyna Janas

TEMAT NUMERUKanban: stop starting, start finishing

Dr Jerzy Stawicki

Wolontariusz rokuWywiad z Aleksandr Skowron

przeprowadzi Grzegorz Mdrek

s. 3

s. 45

s. 67

s. 89, 22

s. 1011

s. 1213

s. 1415

s. 1617

s. 1819

s. 2021

Agile czy nie Agile oto jest pytanieKrzysztof Maus

Rysunek 1

Fot.

: Shu

tter

stoc

k.co

m

4

TEMAT NUMERU

PMI WWW.PMI.ORG.PL

Obawiam si, e nawet tak klasyczne pytanie w odniesieniu do Agilowych (czyli zwin-nych) metod stosowanych w zarzdzaniu projektami wywoa zdziwienie, a nawet pro-testy ju na starcie. Przecie metodyki Agi-lowe okrzyknito ju gono rewelacyjnym remedium na wszelkie kopoty w zarzdzaniu projektami i przeciwstawiono je tradycyjnym podejciom opartym na tzw. Waterfall. Uwaa si, e metodyki takie jak PRINCE2 s bardzo trudne i niemoliwe do zastosowania w organizacji, dlatego naley je porzuci. Co innego podejcie Agile. Zwinne podejcie w obiegowym przekonaniu da si wprowadzi do organizacji bez wikszego wysiku, co w naturalny sposb zintegruje wszystkich uczestniczcych w pracach projektowych i szybko zaowocuje skutecznie wykonywany-mi projektami.

W ostatnim okresie faktycznie pojawiaj si liczne gosy podczas spotka, wykadw, ar-tykuw internetowych i prasowych oraz innych wystpie, ktre na zasadzie argu-mentw ad ignorantum namawiaj do stoso-wania Agile i tylko Agile przeciwstawiajc go np. PRINCE2 i pomijajc inne warstwy adu. Trzeba przyzna, e te obietnice a-twych sukcesw porywaj wielu, w tym czsto informatykw, ktrzy chcieliby ua-twi sobie relacje z zawsze niesfornym biz-nesem.

Poniewa stosuj zasad: Amicus Plato, sed magis amica veritas (co si wykada, e nie-zalenie od okolicznoci trzeba mwi prawd), wic pragn przypomnie czym jest ad kadej organizacji i pokaza, gdzie jest w tym adzie waciwe miejsce dla Agile. Zatem w czym moe nam pomc Agile, a jakich obszarw to podejcie absolutnie nie jest w stanie obsuy.

Rysunek 1 prezentuje uproszczon map adu kadej organizacji: maej, redniej i tak duej jak cae pastwo.

Kada organizacja realizuje swoj strategi przy pomocy zwykej dziaalnoci biznesowej (rutynowej operacyjnej), gdzie osigane s korzyci. To ze strony zwykej dziaalnoci biznesowej przychodzi zapotrzebowanie na zmiany. Celem tych zmian jest dostosowanie do zmieniajcej si strategii, dogonienie lub przegonienie konkurencji. To dlatego mamy

w organizacji inicjatywy zmiany przybierajce ksztaty programw i projektw, w sumie razem budujcych zaplanowany portfel.

Projekty mog by samodzielne lub wchodzi w skad programw. Organizacja projektu nato-miast moe obejmowa jeden lub wicej zespo-w, ktre dostarczaj produkty specjalistyczne (np. informatyczne, marketingowe itd.).

Zarzdzanie projektem, programem i portfe-lem to sfera adu kadej organizacji. Rysunek 2 pokazuje, ktra metodyka lub po-radnik pomoe we wprowadzeniu adu na od-powiednich poziomach zarzdczych.

I tak MoP wspomaga zarzdzanie portfelem organizacji, MSP daje ramy do zarzdzania programem, a PRINCE2 jest podstawow metodyk zarzdzania projektem. PRINCE2 poza wyznaczeniem roli Kierownika Zespou nie obejmuje wewntrznego rodowiska pracy zespou ani inynierii wytwarzania pro-duktu. AgilePM potrafi wspomc budowanie adu w warstwie zarzdzania niewielkich pro-jektw oraz w warstwie zwizanej z zarz-dzaniem zespoem, ale nie wchodzi w specja-listyczn warstw dostarczania produktw. Na ten obszar produkcji oprogramowania

ukierunkowane s XP oraz Lean, natomiast SCRUM tworzy kultur pracy zespou specja-listycznego.

Metodyki zwinne mona czy ze sob oraz metodykami zarzdzania projektami. Bardzo czsto spotkamy si ze rodowiskiem, gdzie warstwa zarzdzania projektem bdzie pod kontrol PRINCE2, zarzdzanie zespoem przebiega bdzie w oparciu o AgilePM lub SCRUM, a wytwarzaniu oprogramowania przewodzi bdzie XP. W miejscu, gdzie koczy si wadza PRINCE2 szczeglnie cenne jest wanie podejcie do budowania zespou zoonego z uytkownikw i specjali-stw technicznych. Za te sugestie i techniki pracy zespow zoonych z rnych intere-sariuszy trzeba ceni Agile najbardziej, w tym jako recept na zakoczenie wzajem-nej wojny wiata IT z biznesem.

To wszystko, co proponuj nam rne podej-cia Agilowe jest wprost bezcenne w zwal-czaniu odwiecznej niekoczcej si wojny wiata IT z tzw. biznesem.

Jednake Agile to nie wszystko. Nie mona go traktowa w izolacji od pozostaych warstw adu. Sam Agile bez wsparcia warstw wyszych nie bdzie efektywny. Spjrzmy, co si stanie, gdy bdziemy chcieli pomin ktr z warstw adu.

Czy mona zrezygnowa z programu? Nie. Gdy bowiem sprbujemy potraktowa inicja-tyw wymagajc adu programu jako pro-jekt, nieuchronnie przegramy. Przykadem ta-kiego niepowodzenia w skali kraju jest klska inicjatywy wprowadzenia elektronicznych (chipowych) dowodw osobistych pod nazw PL-ID, ktra zostaa potraktowana jako pro-jekt informatyczny, a bezwzgldnie powin-na zosta przeprowadzona jako program.

Czy mona zrezygnowa z portfela? Nie. Ty-powymi objawami braku waciwego zarz-

dzania portfelem jest uruchamianie projek-tw niepotrzebnych (tzw. projektw pupil-kw) lub nawet bdcych midzy sob w sprzecznoci. Innym objawem jest urucha-mianie pakietu inicjatyw niemoliwych do re-alizacji z powodu braku zasobw.

adna metodyka Agilowa sama nie wspo-maga zarzdzania programem i portfelem, cho oczywicie w programie i portfelu mog znale si niewielkie projekty zarzdzane przy pomocy AgilePM.

Due zdziwienie budz te wypowiadane konkluzje, e tradycyjne podejcia do zarz-dzania projektami jak PRINCE2 uniemoli-wiaj jakoby zastosowanie podejcia Agile. Wic albo PRINCE2 albo Agile. W mojej ocenie PRINCE2 jako metodyka zarzdzania projektami jest znakomicie przygotowana do poczenia si z zespoami specjalistycznymi stosujcymi podejcie Agile co najmniej po-przez:

stosowanie zasady delegowania, gdzie Kierownik Projektu udziela Kierownikowi Zespou kontrolowanych uprawnie do samodzielnego zarzdzania zespoemproponowanie a 6-ciu tolerancji, jakie mona delegowa zespoom: czas, budet, jako, zakres, ryzyko, korzyci (jak wiadomo w podejciu Agile czas, budet i jako s stae, ale mona zmienia zakres kontrolujc go przy pomocy priorytetw)elastyczny proces Zarzdzanie Dostarcza-niem Produktw stanowicy interfejs pomidzy projektem a zespoem.

Twierdz zatem, e w swojej elastycznoci PRINCE2 zawiera opcj Agile, ale gdyby kto w dalszym cigu przeciwstawia PRIN-CE2 nowoczesnym podejciom zwinnym, to prosz o konkretne argumenty merytoryczne.

Wreszcie obali trzeba mit o tym, e Agile wprowadzi si sam do organizacji. Niestety, same szkolenia i konferencje nie spowoduj,

e wszyscy uczestnicy zastosuj si do pryn-cypiw Agile. Tak samo, jak w przypadku wszystkich warstw adu, i tutaj musi by od-grnie nadane wacicielstwo metodyki czyli musi by kto, kto ustali reguy, bdzie wspiera korzystajcych w ich przestrzeganiu i zadziaa jako policjant, gdyby ustalone reguy byy naruszane. Tym kim moe by zbudowane w organizacji z uprawnienia za-rzdu P3O (Biura Portfeli, Programw i Pro-jektw), ktre potrafi zapewni, e wdroenie Agile bdzie odbywa si w synergii z wpro-wadzaniem adu wszystkich warstw P3. Wielu dobrych ekspertw Agile podkrela zreszt, e do Agile organizacja musi doro-sn i to wymaga rozoonych w czasie dzia-a. Nie mona obiecywa natychmiasto-wych korzyci.

Pora zatem na podsumowanie:w podejciach Agilowych jest ogromna sia i warto dla organizacji

Agile nie pokrywa wszystkich niezbd-nych poziomw adu P3 i dlatego promowanie Agile w izolacji jest bardzo szkodliweprzeciwstawianie Agile tradycyjnej metodyce projektowej takiej jak PRINCE2 jest cakowicie nieuzasadnioneAgile nie wdroy si sam, gdy powinien zosta formalnie przyjty i wdroony w organizacji wraz z innymi warstwami adu.

Quod erat demostrandum (czyli co byo do wy-kazania). By dyskusjom o Agile nada kon-struktywne ramy do rozwaa z entuzjazmem ale i cum grano salis (dosownie ze szczypt soli czyli z pewn doz rezerwy).

PORTFEL

PROGRAM

PROJEKT

ZESP

DOSTARCZANIEPRODUKTW

MoP

MSP

PRINCE2

SCRUMAgilePM

XPLean

Rysunek 2

5

Obawiam si, e nawet tak klasyczne pytanie w odniesieniu do Agilowych (czyli zwin-nych) metod stosowanych w zarzdzaniu projektami wywoa zdziwienie, a nawet pro-testy ju na starcie. Przecie metodyki Agi-lowe okrzyknito ju gono rewelacyjnym remedium na wszelkie kopoty w zarzdzaniu projektami i przeciwstawiono je tradycyjnym podejciom opartym na tzw. Waterfall. Uwaa si, e metodyki takie jak PRINCE2 s bardzo trudne i niemoliwe do zastosowania w organizacji, dlatego naley je porzuci. Co innego podejcie Agile. Zwinne podejcie w obiegowym przekonaniu da si wprowadzi do organizacji bez wikszego wysiku, co w naturalny sposb zintegruje wszystkich uczestniczcych w pracach projektowych i szybko zaowocuje skutecznie wykonywany-mi projektami.

W ostatnim okresie faktycznie pojawiaj si liczne gosy podczas spotka, wykadw, ar-tykuw internetowych i prasowych oraz innych wystpie, ktre na zasadzie argu-mentw ad ignorantum namawiaj do stoso-wania Agile i tylko Agile przeciwstawiajc go np. PRINCE2 i pomijajc inne warstwy adu. Trzeba przyzna, e te obietnice a-twych sukcesw porywaj wielu, w tym czsto informatykw, ktrzy chcieliby ua-twi sobie relacje z zawsze niesfornym biz-nesem.

Poniewa stosuj zasad: Amicus Plato, sed magis amica veritas (co si wykada, e nie-zalenie od okolicznoci trzeba mwi prawd), wic pragn przypomnie czym jest ad kadej organizacji i pokaza, gdzie jest w tym adzie waciwe miejsce dla Agile. Zatem w czym moe nam pomc Agile, a jakich obszarw to podejcie absolutnie nie jest w stanie obsuy.

Rysunek 1 prezentuje uproszczon map adu kadej organizacji: maej, redniej i tak duej jak cae pastwo.

Kada organizacja realizuje swoj strategi przy pomocy zwykej dziaalnoci biznesowej (rutynowej operacyjnej), gdzie osigane s korzyci. To ze strony zwykej dziaalnoci biznesowej przychodzi zapotrzebowanie na zmiany. Celem tych zmian jest dostosowanie do zmieniajcej si strategii, dogonienie lub przegonienie konkurencji. To dlatego mamy

w organizacji inicjatywy zmiany przybierajce ksztaty programw i projektw, w sumie razem budujcych zaplanowany portfel.

Projekty mog by samodzielne lub wchodzi w skad programw. Organizacja projektu nato-miast moe obejmowa jeden lub wicej zespo-w, ktre dostarczaj produkty specjalistyczne (np. informatyczne, marketingowe itd.).

Zarzdzanie projektem, programem i portfe-lem to sfera adu kadej organizacji. Rysunek 2 pokazuje, ktra metodyka lub po-radnik pomoe we wprowadzeniu adu na od-powiednich poziomach zarzdczych.

I tak MoP wspomaga zarzdzanie portfelem organizacji, MSP daje ramy do zarzdzania programem, a PRINCE2 jest podstawow metodyk zarzdzania projektem. PRINCE2 poza wyznaczeniem roli Kierownika Zespou nie obejmuje wewntrznego rodowiska pracy zespou ani inynierii wytwarzania pro-duktu. AgilePM potrafi wspomc budowanie adu w warstwie zarzdzania niewielkich pro-jektw oraz w warstwie zwizanej z zarz-dzaniem zespoem, ale nie wchodzi w specja-listyczn warstw dostarczania produktw. Na ten obszar produkcji oprogramowania

ukierunkowane s XP oraz Lean, natomiast SCRUM tworzy kultur pracy zespou specja-listycznego.

Metodyki zwinne mona czy ze sob oraz metodykami zarzdzania projektami. Bardzo czsto spotkamy si ze rodowiskiem, gdzie warstwa zarzdzania projektem bdzie pod kontrol PRINCE2, zarzdzanie zespoem przebiega bdzie w oparciu o AgilePM lub SCRUM, a wytwarzaniu oprogramowania przewodzi bdzie XP. W miejscu, gdzie koczy si wadza PRINCE2 szczeglnie cenne jest wanie podejcie do budowania zespou zoonego z uytkownikw i specjali-stw technicznych. Za te sugestie i techniki pracy zespow zoonych z rnych intere-sariuszy trzeba ceni Agile najbardziej, w tym jako recept na zakoczenie wzajem-nej wojny wiata IT z biznesem.

To wszystko, co proponuj nam rne podej-cia Agilowe jest wprost bezcenne w zwal-czaniu odwiecznej niekoczcej si wojny wiata IT z tzw. biznesem.

Jednake Agile to nie wszystko. Nie mona go traktowa w izolacji od pozostaych warstw adu. Sam Agile bez wsparcia warstw wyszych nie bdzie efektywny. Spjrzmy, co si stanie, gdy bdziemy chcieli pomin ktr z warstw adu.

Czy mona zrezygnowa z programu? Nie. Gdy bowiem sprbujemy potraktowa inicja-tyw wymagajc adu programu jako pro-jekt, nieuchronnie przegramy. Przykadem ta-kiego niepowodzenia w skali kraju jest klska inicjatywy wprowadzenia elektronicznych (chipowych) dowodw osobistych pod nazw PL-ID, ktra zostaa potraktowana jako pro-jekt informatyczny, a bezwzgldnie powin-na zosta przeprowadzona jako program.

Czy mona zrezygnowa z portfela? Nie. Ty-powymi objawami braku waciwego zarz-

dzania portfelem jest uruchamianie projek-tw niepotrzebnych (tzw. projektw pupil-kw) lub nawet bdcych midzy sob w sprzecznoci. Innym objawem jest urucha-mianie pakietu inicjatyw niemoliwych do re-alizacji z powodu braku zasobw.

adna metodyka Agilowa sama nie wspo-maga zarzdzania programem i portfelem, cho oczywicie w programie i portfelu mog znale si niewielkie projekty zarzdzane przy pomocy AgilePM.

Due zdziwienie budz te wypowiadane konkluzje, e tradycyjne podejcia do zarz-dzania projektami jak PRINCE2 uniemoli-wiaj jakoby zastosowanie podejcia Agile. Wic albo PRINCE2 albo Agile. W mojej ocenie PRINCE2 jako metodyka zarzdzania projektami jest znakomicie przygotowana do poczenia si z zespoami specjalistycznymi stosujcymi podejcie Agile co najmniej po-przez:

stosowanie zasady delegowania, gdzie Kierownik Projektu udziela Kierownikowi Zespou kontrolowanych uprawnie do samodzielnego zarzdzania zespoemproponowanie a 6-ciu tolerancji, jakie mona delegowa zespoom: czas, budet, jako, zakres, ryzyko, korzyci (jak wiadomo w podejciu Agile czas, budet i jako s stae, ale mona zmienia zakres kontrolujc go przy pomocy priorytetw)elastyczny proces Zarzdzanie Dostarcza-niem Produktw stanowicy interfejs pomidzy projektem a zespoem.

Twierdz zatem, e w swojej elastycznoci PRINCE2 zawiera opcj Agile, ale gdyby kto w dalszym cigu przeciwstawia PRIN-CE2 nowoczesnym podejciom zwinnym, to prosz o konkretne argumenty merytoryczne.

Wreszcie obali trzeba mit o tym, e Agile wprowadzi si sam do organizacji. Niestety, same szkolenia i konferencje nie spowoduj,

e wszyscy uczestnicy zastosuj si do pryn-cypiw Agile. Tak samo, jak w przypadku wszystkich warstw adu, i tutaj musi by od-grnie nadane wacicielstwo metodyki czyli musi by kto, kto ustali reguy, bdzie wspiera korzystajcych w ich przestrzeganiu i zadziaa jako policjant, gdyby ustalone reguy byy naruszane. Tym kim moe by zbudowane w organizacji z uprawnienia za-rzdu P3O (Biura Portfeli, Programw i Pro-jektw), ktre potrafi zapewni, e wdroenie Agile bdzie odbywa si w synergii z wpro-wadzaniem adu wszystkich warstw P3. Wielu dobrych ekspertw Agile podkrela zreszt, e do Agile organizacja musi doro-sn i to wymaga rozoonych w czasie dzia-a. Nie mona obiecywa natychmiasto-wych korzyci.

Pora zatem na podsumowanie:w podejciach Agilowych jest ogromna sia i warto dla organizacji

Agile nie pokrywa wszystkich niezbd-nych poziomw adu P3 i dlatego promowanie Agile w izolacji jest bardzo szkodliweprzeciwstawianie Agile tradycyjnej metodyce projektowej takiej jak PRINCE2 jest cakowicie nieuzasadnioneAgile nie wdroy si sam, gdy powinien zosta formalnie przyjty i wdroony w organizacji wraz z innymi warstwami adu.

Quod erat demostrandum (czyli co byo do wy-kazania). By dyskusjom o Agile nada kon-struktywne ramy do rozwaa z entuzjazmem ale i cum grano salis (dosownie ze szczypt soli czyli z pewn doz rezerwy).

Krzysztof MausTrener wiodcy i konsultant OMEC w zakresie budowy biur portfeli, programw i projektw (P3O). Od kilkunastu lat zarzdza projektami w firmach z bran telekomunikacyjnej, informatycznej i mediowej oraz w administracji publicznej. Akredyto-wany trener PRINCE2, AgilePM, MSP i P3O, certyfikowany project i programme manager. Tumacz polskiej wersji podrcznika P3O - Biura Portfeli, Programw i Projektw.

6 PMI WWW.PMI.ORG.PL

Mariusz Chrapko

Transformacja agile w firmie

Coraz wicej firm w Polsce wdraa zwinne metody pracy. I dobrze. Mam jednak nieod-parte wraenie, e w wielu firmach, na tym caa przygoda ze zwinnoci si koczy. W caym naszym myleniu o agile, wci postrzegamy go jako skrzynk narzdzio-w zestaw metod i praktyk, ktre wy-starczy wdroy w organizacji, bo wtedy rozwi si wszystkie nasze problemy. Bo tak byo zawsze. Egh to znaczy, tak miao by zawsze. Wystarczy wspomnie o takich narzdziach jak: CMMI, ISO/IEC 15504, czy ITIL. Wdraamy wic Scruma. Formujemy interdyscyplinarne zespoy, ktre same bd zarzdza swoj prac. Definiujemy nowe role: Scrum Master, Waciciel Produktu. Wszyscy zaczynaj uywa ezoterycznego jzyka: jest jaki backlog, s sprinty. Wow! Mamy Scruma! Jestemy agile! Mija rok i nic. Impas.

Zmieni DNA zarzdzaniaJeeli mylicie, e wdroenie agile w firmie to tylko implementacja konkretnych metod i praktyk, moecie si rozczarowa. Bo agile to przede wszystkim wiat wartoci, ktre funduj okrelony wiatopogld w firmie.

Thomas Kuhn, amerykaski fizyk i filozof nauki, prbujc wyjani, jak wyglda postp w nauce, posuy si pojciem pa-radygmatu. Wedug niego paradygmat to co wicej ni sposb mylenia to caa wizja wiata i niewzruszone poczucie, ktre problemy warto rozwizywa i ktre w ogle s rozwizywalne. Filozofia agile to zupenie nowy paradygmat zarzdzania. To bardzo konkretny, inny od dotychczasowe-go, sposb mylenia. Jego wdroenie wymaga zmiany DNA zarzdzania.

Adaptacja, czy transformacja?

Mylc o wdroeniu agile w firmie trzeba odrni dwa pojcia: adaptacj od trans-formacji.

Adaptacja to wdroenie konkretnych metod i praktyk agile, bez zmiany sposobu funkcjonowania firmy. Innymi sowy, mo-ecie mie Scruma, ale wszystko bdzie po staremu. Zespoy bd pracowa w krtkich cyklach wytwrczych, spoty-ka si na codziennych stand-upach, regu-larnie pokazywa wyniki swojej pracy klientowi, namyla si na popraw proce-

su etc. Na koniec, i tak wszystko moe wzi w eb. Bo nie bdzie odpowiedniego gruntu, na ktrym metody te bd mogy si rozwija i przyczynia si do wzrostu firmy.

Z adaptacj w firmie jest troch tak jak ze wspinaczk wysokogrsk. Nasz organizm ma bardzo due zdolnoci adaptacyjne. Ale wysoko w grach, gwnym problemem jest brak yciodajnego tlenu. Z kadym kolejnym metrem wspinaczki jest go coraz mniej. Dla-tego tak wana jest odpowiednia aklimaty-zacja. Himalaista musi stosowa si do pewnych regu, eby nie polec w starciu z gr. Ale to jego organizm si adaptuje. Gra pozostaje nieruszona. Podobnie jest z adaptacj w firmie. Wdraamy konkretne metody i sposoby pracy, ale nie zmieniamy sposobu funkcjonowania firmy.

eby firma moga naprawd poczu korzy-ci z wdroenia agile, musi wstpi na ciek transformacji. Zwinna transforma-cja polega na wprowadzeniu gbokiej, fundamentalnej zmiany w sposobie funk-cjonowania firmy tak, aby moga ona spro-sta nowym wyzwaniom. Transformacja polega na metamorfozie przeobraeniu. Mwi si, e motyle, to owady, u ktrych

TEMAT NUMERU

dokonuje si przeobraenie zupene. Naj-pierw s jajeczka, z ktrych pniej wyklu-wa si gsienica (larwa). Z czasem gsieni-ca zmienia si w poczwark, z ktrej final-nie wyania si motyl. Transformacja skada si z okrelonych etapw. Kada kolejna odsona jest metamorfoz fazy poprzedniej. Jeeli mylicie o wdroeniu agile ( jeeli mylicie na serio), transforma-cja jest waciw drog.

Zwinna transformacja. Trudna? Niemoliwa?

Niektrzy twierdz, e transformacja jest trudna, inni, e wrcz niemoliwa. Zga-dzam si i z pierwszym, i z drugim twier-dzeniem, chocia moja zgoda wymaga pewnego uzasadnienia.

Transformacja jest trudna. Pewnie, e jest. Najwiksza trudno polega chyba na tym, eby dostrzec pilno zmiany w firmie, a potem t zmian so-lidnie zaplanowa. Z dostrzeganiem pil-noci zmiany jest troch tak jak z upra-wianiem sportu. Pamitam, jak siedzia-em kiedy na kanapie z pilotem w rku, patrzyem za okno i powtarzaem sobie (wzbudzaem pilno): No tak, trzeba by zacz biega. Jest wiosna. Wszyscy biegaj. Ja te zaczn. Ale moe jutro. Tak. Jutro zaczn. Na pewno. Mija jutro i pojutrze. I nic. Uwiadomienie sobie faktu, e trzeba w firmie co zmieni, jest chyba najtrudniejsze. Planowanie wdroenia zmiany przychodzi zdecydo-wanie atwiej.

Transformacja jest niemoliwa. I tak, i nie. Nigdy si z tym nie zgodz, e wdraanie agile ma sens tylko w maych i rednich przedsibiorstwach. Bo te due s ju tak zdegenerowane, e zmiana ich DNA zarzdzania si po prostu nie uda. Owszem. W duych or-ganizacjach wprowadzanie zmian jest wolniejsze, czasem mniej spektakular-ne, moe bardziej irytujce (sic!). Ale nie niemoliwe (w sensie wykonawczym). Mog si jednak zgodzi z tym, e nie-moliwo transformacji polega na tym, e w dzisiejszych, turbulentnych cza-sach, w ktrych przetrwanie firmy zaley od jej zdolnoci adaptacji do zmieniajcych si warunkw otoczenia transformacja w gruncie rzeczy jest niemoliwa. Bo nie jest to proces jedno-razowy. Wymaga cigej uwagi i ci-gych dziaa cigej transformacji.

Etapy transformacjiProces transformacji agile w firmie mona podzieli na nastpujce etapy. Nie pole-cam opuszczania ktregokolwiek z etapw. To tylko pozornie przyspieszy wasze wdro-enie i nigdy nie przynosi dobrych rezulta-tw.

Ustalenie status quo. Kade wdroenie zaczyna si od dokadnego ogldu po-dwrka. To taki firmowy remanent. Chcemy zorientowa si na czym, tak na-prawd stoimy. Bierzemy pod lup wszyst-kie procesy, narzdzia, ale take problemy, z ktrymi nasza firma si mierzy. To jest moment budowania pewnego poziomu wiadomoci o naszej organizacji. Na razie nie planujemy adnych konkretnych dzia-a, nie szukamy szczegowych rozwi-za. Oczywicie, przy okazji analizy w wa-szych gowach bd si pojawia rnego rodzaju pomysy. Sprbujcie je na ten moment zaparkowa.

Opracowanie wizji i strategii dziaa-nia. Zbudowalicie ju pewn wiadomo o sposobie funkcjonowania swojej organi-zacji. Teraz czas na warsztaty strategiczne (tak je przynajmniej nazywam). Zanim za-czniecie si warsztatowa, pomylcie o wizji wdroenia. Pomylcie o tym, dokd chcielibycie, eby transformacja was za-prowadzia. Zastanwcie si, co chcecie osign. I nie bdcie przy tym zbyt am-bitni. Wiem, z dowiadczenia, e zbyt wy-growane ambicje, czsto zabijaj inicja-tyw. Jak jest wizja, moecie zacz warsztaty. To ten bogosawiony czas w organizacji, kiedy projektujecie rozwi-zania.

Wdroenie zmiany. Tutaj s trzy moli-woci: 1) Moecie uruchomi jeden lub kilka projektw pilotaowych i zobaczy, jak zmiana zachowuje si na maej prbie, 2) Wdroy zmian metod na Pana Kleksa, czyli Caa naprzd ku nowej przygodzie!, lub 3) zastosowa podejcie mieszane. Jak obserwuj, wiele firm prefe-ruje go najbardziej. Uruchamiamy kilka projektw pilotaowych, po czym zmiana wdraana jest w kolejnych iteracjach w caej firmie.

Utrwalenie wynikw w kulturze firmy. To jest etap najczciej pomijany przy wdroeniach agile, ale, w ostatecznym rozrachunku chyba najwaniejszy. Zmiany maj charakter trway, jeeli pracownicy zaczynaj o nich mwi jako o wasnym

stylu pracy. eby to si stao, zmiany musz przenikn do krwiobiegu firmy. Dopki te nowe zachowania nie stan si organicznym elementem spoecznych norm i wsplnych wartoci, bardzo szybko mog ulec degradacji z chwil, gdy presja wprowadzania zmiany stanie si sabsza. Ten punkt dotyczy transformacji osobistej.

Wszystko rozbija si o kultur

Transformacja, koniec kocw, sprowadza si do bardzo konkretnej i wytonej pracy nad kultur organizacyjn firmy. To praca nad jej systemem operacyjnym. Kultura or-ganizacyjna przejawia si w wyznawanych wartociach, dominujcych stylach przy-wdztwa, jzyku i symbolach, a take spo-sobach postpowania i stosowanych pro-cedurach. To jest rzeczywisto, od ktrej zaley, czy jestemy agile, czy nie. Kon-kretne metody i praktyki agile (Scrum, XP, FDD, Kanban), do ktrych przywizujemy tak du wag s tylko jej czci skado-w.

Fot.

: Shu

tter

stoc

k.co

m

PMI WWW.PMI.ORG.PL 7

Coraz wicej firm w Polsce wdraa zwinne metody pracy. I dobrze. Mam jednak nieod-parte wraenie, e w wielu firmach, na tym caa przygoda ze zwinnoci si koczy. W caym naszym myleniu o agile, wci postrzegamy go jako skrzynk narzdzio-w zestaw metod i praktyk, ktre wy-starczy wdroy w organizacji, bo wtedy rozwi si wszystkie nasze problemy. Bo tak byo zawsze. Egh to znaczy, tak miao by zawsze. Wystarczy wspomnie o takich narzdziach jak: CMMI, ISO/IEC 15504, czy ITIL. Wdraamy wic Scruma. Formujemy interdyscyplinarne zespoy, ktre same bd zarzdza swoj prac. Definiujemy nowe role: Scrum Master, Waciciel Produktu. Wszyscy zaczynaj uywa ezoterycznego jzyka: jest jaki backlog, s sprinty. Wow! Mamy Scruma! Jestemy agile! Mija rok i nic. Impas.

Zmieni DNA zarzdzaniaJeeli mylicie, e wdroenie agile w firmie to tylko implementacja konkretnych metod i praktyk, moecie si rozczarowa. Bo agile to przede wszystkim wiat wartoci, ktre funduj okrelony wiatopogld w firmie.

Thomas Kuhn, amerykaski fizyk i filozof nauki, prbujc wyjani, jak wyglda postp w nauce, posuy si pojciem pa-radygmatu. Wedug niego paradygmat to co wicej ni sposb mylenia to caa wizja wiata i niewzruszone poczucie, ktre problemy warto rozwizywa i ktre w ogle s rozwizywalne. Filozofia agile to zupenie nowy paradygmat zarzdzania. To bardzo konkretny, inny od dotychczasowe-go, sposb mylenia. Jego wdroenie wymaga zmiany DNA zarzdzania.

Adaptacja, czy transformacja?

Mylc o wdroeniu agile w firmie trzeba odrni dwa pojcia: adaptacj od trans-formacji.

Adaptacja to wdroenie konkretnych metod i praktyk agile, bez zmiany sposobu funkcjonowania firmy. Innymi sowy, mo-ecie mie Scruma, ale wszystko bdzie po staremu. Zespoy bd pracowa w krtkich cyklach wytwrczych, spoty-ka si na codziennych stand-upach, regu-larnie pokazywa wyniki swojej pracy klientowi, namyla si na popraw proce-

su etc. Na koniec, i tak wszystko moe wzi w eb. Bo nie bdzie odpowiedniego gruntu, na ktrym metody te bd mogy si rozwija i przyczynia si do wzrostu firmy.

Z adaptacj w firmie jest troch tak jak ze wspinaczk wysokogrsk. Nasz organizm ma bardzo due zdolnoci adaptacyjne. Ale wysoko w grach, gwnym problemem jest brak yciodajnego tlenu. Z kadym kolejnym metrem wspinaczki jest go coraz mniej. Dla-tego tak wana jest odpowiednia aklimaty-zacja. Himalaista musi stosowa si do pewnych regu, eby nie polec w starciu z gr. Ale to jego organizm si adaptuje. Gra pozostaje nieruszona. Podobnie jest z adaptacj w firmie. Wdraamy konkretne metody i sposoby pracy, ale nie zmieniamy sposobu funkcjonowania firmy.

eby firma moga naprawd poczu korzy-ci z wdroenia agile, musi wstpi na ciek transformacji. Zwinna transforma-cja polega na wprowadzeniu gbokiej, fundamentalnej zmiany w sposobie funk-cjonowania firmy tak, aby moga ona spro-sta nowym wyzwaniom. Transformacja polega na metamorfozie przeobraeniu. Mwi si, e motyle, to owady, u ktrych

dokonuje si przeobraenie zupene. Naj-pierw s jajeczka, z ktrych pniej wyklu-wa si gsienica (larwa). Z czasem gsieni-ca zmienia si w poczwark, z ktrej final-nie wyania si motyl. Transformacja skada si z okrelonych etapw. Kada kolejna odsona jest metamorfoz fazy poprzedniej. Jeeli mylicie o wdroeniu agile ( jeeli mylicie na serio), transforma-cja jest waciw drog.

Zwinna transformacja. Trudna? Niemoliwa?

Niektrzy twierdz, e transformacja jest trudna, inni, e wrcz niemoliwa. Zga-dzam si i z pierwszym, i z drugim twier-dzeniem, chocia moja zgoda wymaga pewnego uzasadnienia.

Transformacja jest trudna. Pewnie, e jest. Najwiksza trudno polega chyba na tym, eby dostrzec pilno zmiany w firmie, a potem t zmian so-lidnie zaplanowa. Z dostrzeganiem pil-noci zmiany jest troch tak jak z upra-wianiem sportu. Pamitam, jak siedzia-em kiedy na kanapie z pilotem w rku, patrzyem za okno i powtarzaem sobie (wzbudzaem pilno): No tak, trzeba by zacz biega. Jest wiosna. Wszyscy biegaj. Ja te zaczn. Ale moe jutro. Tak. Jutro zaczn. Na pewno. Mija jutro i pojutrze. I nic. Uwiadomienie sobie faktu, e trzeba w firmie co zmieni, jest chyba najtrudniejsze. Planowanie wdroenia zmiany przychodzi zdecydo-wanie atwiej.

Transformacja jest niemoliwa. I tak, i nie. Nigdy si z tym nie zgodz, e wdraanie agile ma sens tylko w maych i rednich przedsibiorstwach. Bo te due s ju tak zdegenerowane, e zmiana ich DNA zarzdzania si po prostu nie uda. Owszem. W duych or-ganizacjach wprowadzanie zmian jest wolniejsze, czasem mniej spektakular-ne, moe bardziej irytujce (sic!). Ale nie niemoliwe (w sensie wykonawczym). Mog si jednak zgodzi z tym, e nie-moliwo transformacji polega na tym, e w dzisiejszych, turbulentnych cza-sach, w ktrych przetrwanie firmy zaley od jej zdolnoci adaptacji do zmieniajcych si warunkw otoczenia transformacja w gruncie rzeczy jest niemoliwa. Bo nie jest to proces jedno-razowy. Wymaga cigej uwagi i ci-gych dziaa cigej transformacji.

Etapy transformacjiProces transformacji agile w firmie mona podzieli na nastpujce etapy. Nie pole-cam opuszczania ktregokolwiek z etapw. To tylko pozornie przyspieszy wasze wdro-enie i nigdy nie przynosi dobrych rezulta-tw.

Ustalenie status quo. Kade wdroenie zaczyna si od dokadnego ogldu po-dwrka. To taki firmowy remanent. Chcemy zorientowa si na czym, tak na-prawd stoimy. Bierzemy pod lup wszyst-kie procesy, narzdzia, ale take problemy, z ktrymi nasza firma si mierzy. To jest moment budowania pewnego poziomu wiadomoci o naszej organizacji. Na razie nie planujemy adnych konkretnych dzia-a, nie szukamy szczegowych rozwi-za. Oczywicie, przy okazji analizy w wa-szych gowach bd si pojawia rnego rodzaju pomysy. Sprbujcie je na ten moment zaparkowa.

Opracowanie wizji i strategii dziaa-nia. Zbudowalicie ju pewn wiadomo o sposobie funkcjonowania swojej organi-zacji. Teraz czas na warsztaty strategiczne (tak je przynajmniej nazywam). Zanim za-czniecie si warsztatowa, pomylcie o wizji wdroenia. Pomylcie o tym, dokd chcielibycie, eby transformacja was za-prowadzia. Zastanwcie si, co chcecie osign. I nie bdcie przy tym zbyt am-bitni. Wiem, z dowiadczenia, e zbyt wy-growane ambicje, czsto zabijaj inicja-tyw. Jak jest wizja, moecie zacz warsztaty. To ten bogosawiony czas w organizacji, kiedy projektujecie rozwi-zania.

Wdroenie zmiany. Tutaj s trzy moli-woci: 1) Moecie uruchomi jeden lub kilka projektw pilotaowych i zobaczy, jak zmiana zachowuje si na maej prbie, 2) Wdroy zmian metod na Pana Kleksa, czyli Caa naprzd ku nowej przygodzie!, lub 3) zastosowa podejcie mieszane. Jak obserwuj, wiele firm prefe-ruje go najbardziej. Uruchamiamy kilka projektw pilotaowych, po czym zmiana wdraana jest w kolejnych iteracjach w caej firmie.

Utrwalenie wynikw w kulturze firmy. To jest etap najczciej pomijany przy wdroeniach agile, ale, w ostatecznym rozrachunku chyba najwaniejszy. Zmiany maj charakter trway, jeeli pracownicy zaczynaj o nich mwi jako o wasnym

stylu pracy. eby to si stao, zmiany musz przenikn do krwiobiegu firmy. Dopki te nowe zachowania nie stan si organicznym elementem spoecznych norm i wsplnych wartoci, bardzo szybko mog ulec degradacji z chwil, gdy presja wprowadzania zmiany stanie si sabsza. Ten punkt dotyczy transformacji osobistej.

Wszystko rozbija si o kultur

Transformacja, koniec kocw, sprowadza si do bardzo konkretnej i wytonej pracy nad kultur organizacyjn firmy. To praca nad jej systemem operacyjnym. Kultura or-ganizacyjna przejawia si w wyznawanych wartociach, dominujcych stylach przy-wdztwa, jzyku i symbolach, a take spo-sobach postpowania i stosowanych pro-cedurach. To jest rzeczywisto, od ktrej zaley, czy jestemy agile, czy nie. Kon-kretne metody i praktyki agile (Scrum, XP, FDD, Kanban), do ktrych przywizujemy tak du wag s tylko jej czci skado-w.

Mariusz ChrapkoAutor bestsellerowej ksiki Scrum. O zwinnym zarzdzaniu projektami. Prowadzi bloga o nowych trendach w zarzdzaniu (mariuszchrapko.com). Na co dzie pomaga liderom oraz czonkom zespow projektowych w procesie transformacji biznesowej. Jest praktykiem zarzdzania, ktry wierzy w osiganie niezwykych rezultatw poprzez "zwykych" ludzi. Prowadzi coaching, dziaania doradcze i szkolenia na rnych szczeblach organizacyjnych. Jest ekspertem w dziedzinie wdraania i adaptacji metody Scrum w duych organizacjach. Z zamiowania filozof i politolog. Prowokuje. Zmusza do mylenia odwrotnego, innego ni powszechne. Gosi kryzys starej szkoy zarzdzania i potrzeb zmiany dotychczasowego paradygmatu. W wolnych chwilach gra jazz na fortepianie i obaskawia swoje dwa brytyjskie koty.

1.

2.

3.

4.

TEMAT NUMERU

pracy w zespoach. Zacznijmy jednak od symptomw. Jednym ze standardowych sygnaw, e co jest nie tak s rosnce kolejki zada czekajcych na realizacj ko-lejnego etapu procesu.

Typowym przykadem w projektach infor-matycznych s zadania dla ktrych etap developmentu jest zakoczony i czekaj na testy. Czy takie zadanie mona traktowa jako zakoczone? Nie, w kocu najprawdo-podobniej bd potrzebne poprawki do znalezionych bdw.

Jeli przyjrzymy si temu jak wyglda re-alizacja zada w dowolnym momencie pro-cesu takich kolejek zada znajdziemy wiele. Dlaczego?

Odpowiedzi jest jeden z bardzo po-wszechnych paradygmatw zarzdzania denie do 100% utylizacji ludzi. Przecie jeeli mwimy o tzw. knowledge work, zwykle jedyny istotny koszt to koszt pracy. To nie linia produkcyjna z kosztow-nymi maszynami gdzie czowiek jest tylko dodatkiem. Tutaj lini produkcyjn jest czowiek.


Wikszo z nas za kadym razem, kiedy zesp zaczyna realizacj nowego projektu ma przed oczami tak sam wizj. Sprawna realizacja zada, stabilny i systematyczny progres ukoczonych zada i efektywna praca wszystkich czonkw zespou.

Co ciekawe, nawet w sytuacjach zblio-nych do ideau, kiedy mamy du elastycz-no na etapie tworzenia zespou, jest to bardzo rzadki widok. Najczciej postpy trudno nazwa zadowalajcymi i to mimo intensywnego wysiku czonkw zespou starajcych si jak najlepiej realizowa swoje zadania.

To jeden z tych momentw kiedy, zamiast wywiera presj na zesp, warto si za-trzyma i zada sobie pytanie: dlaczego?

Dlaczego zesp specjalistw sprawdzo-nych w innych projektach majcych do dobrze zdefiniowany zakres zada ma takie problemy w ukoczeniu czegokolwiek?

100% utylizacjiOdpowied kryje si w bardzo powszech-nym, niestety, podejciu do organizacji

Jeeli zatem koszt ludzi jest gwn ska-dow oglnych kosztw projektu powinni-my chcie tak zorganizowa prac aby ludzie byli maksymalnie wykorzystywani. W ten sposb osigniemy maksymaln efektywno. Brzmi sensownie, prawda?

I to wanie cay problem brzmi sensow-nie, mimo e absolutnie nie znajduje po-twierdzenia w rzeczywistoci.

Aby zbliy si do 100% utylizacji ludzi, kady z czonkw zespou musi mie kolej-k zada czekajcych na niego. Kiedy skoczy biece zadanie, zawsze bdzie czekao na niego kolejne, dziki temu b-dziemy minimalizowa przestoje.

Problem w tym e to rwnie oznacza bardzo du liczb zada, ktre s rozpo-czte a nie zakoczone tak zwanych prac w toku. Oczywicie zakadam tutaj, e prace w toku definiujemy patrzc przez pryzmat caego procesu, a nie konkretnego jego etapu. Innymi sowy zadanie zaczyna by w toku kiedy rozpoczyna si pierwszy z etapw prac analiza, projektowanie, czy cokolwiek to jest w danym kontekcie a koczy si kiedy zesp nie planuje robi z nim ju niczego wicej.

Jaki jest efekt duej iloci prac w toku? Prost konsekwencj jest czste prze-czanie kontekstu, co ma tragiczne skutki dla efektywnoci pracy.

Fot.

: Shu

tter

stoc

k.co

m Koszt przeczania kontekstu

Gerald Weinberg wskazuje1, e koszt prze-czania kontekstu to 20% czasu dla ka-dego kolejnego zadania, nad ktrym pracu-jemy rwnolegle. Okazuje si, e nie tak trudno doprawdzi do sytuacji, w ktrej marnujemy blisko poow dostpnego czasu pracy. (Zobacz Rysunek 1).

Argument, ktry czsto sysz kiedy przy-wouj opracowanie Geralda Weinberga w kontekcie duej iloci prac w toku jest taki, e przecie kady z czonkw zespou w danym momencie skupia si nad jednym zadaniem. Pozostae zadania niejako ocze-kuj na swj czas. Przeczanie kontekstu odbywa si zatem w znacznie mniejszej skali ni sugerowaoby to proste porwna-nie iloci zada w toku i liczby czonkw zespou.

Prawdopodobnie byoby tak, gdybymy byli maszynami. Niestety nasz mzg ma tendencj aby sam sobie przerywa bie-c prac mylami o zadaniach, ktre pozo-

stawilimy niezakoczone. Przypomnijcie sobie sytuacje, w ktrych, robic co zu-penie niezwizanego nagle pomylelicie o rachunku, ktrego zapomnielicie zapa-ci, emailu, na ktry mielicie odpisa, albo jakim nierozwizanym problemie. To efekt Zegarnik (bo tak nazw nosi to zachowa-nie naszego mzgu) w akcji.

Dokadnie to samo dzieje si w kontekcie naszej codziennej pracy. Wracamy mylami do zada, nad ktrymi obecnie nie pracuje-my jednoczenie obciajc nas samych kosztem przeczania kontekstu.

Jest to zreszt bardzo spjne z wynikami bada na temat multitaskingu2 prowadzo-nych przez Eyala Ophira na uniwersytecie Stanford. Wskazuje on, e gwne rdo kosztu przeczania kontekstu to fakt, e nasz mzg zajmuje si myleniem o zada-niach, ktrych w danym momencie aktyw-nie nie wykonujemy.

Przeczanie kontekstu to nie tylko nisza efektywno pracy. To rwnie nisza jako. Wspomniane badania Eyala Ophira wskazay rwnie, e osoby zajmujce si paroma rze-czami jednoczenie czciej si myl.

Domy do tego kluczowy dla biznesu pa-rametr time to market, okrelajcy ile czasu potrzeba aby dostarczy wynik prac na rynek. Jeeli przeanalizujemy go pod ktem jego zwizku z przeczaniem kon-tekstu bardzo jasno zobaczymy jak moli-wo skupienia si na jednym zadaniu przekada si na efektywno caego pro-cesu. (Zobacz Rysunek 2).

W pierwszym z zaprezentowanych powy-ej scenariuszy systematycznie przecza-my si midzy kolejnymi zadaniami. W drugim, rozpoczynamy kolejne zadanie dopiero po zakoczeniu wczeniejszego. Nie tylko cakowity czas pracy jest krtszy w drugim przypadku, ale take moment dostarczenia poszczeglnych zada dra-stycznie si rni.

Co wicej, w drugim scenariuszu tym z ograniczon liczb zada w toku moemy wykorzysta informacje zwrotne z realizacji pierwszego zadania przy reali-zacji kolejnych. Dajemy sobie szanse na usprawnienia. W pierwszym scenariuszu takiej moliwoci nie dostajemy.

Ograniczanie prac w toku

Od szczytnego celu, czyli efektywnej pracy, przeszlimy przed 100% utylizacj i jej smutne konsekwencje, czyli intensyw-ne przeczanie kontekstu wraz ze wszyst-kimi zwizanymi kosztami. Sprbujmy zatem odwrci cay tok mylowy jaki bdzie efekt jeli ograniczymy ilo prac w toku?

Najbardziej typowym obecnie podejciem do ograniczania prac w toku jest okrelenie limitw dla kadego kolejnego etapu na-szego procesu. Jednoczenie unikamy sy-tuacji wprowadzenia nielimitowanych ko-lejek zada w przypadku gdy s one prze-kazywane do kolejnego etapu. Limit taki bdzie zatem dotyczy np. wszystkich zada w developmencie, niezalenie od tego czy development jeszcze trwa czy ju zosta zakoczony a zadanie oczekuje na testy. (Zobacz Rysunek 3).

Nie potrzeba nadmiernej kreatywnoci aby wyobrazi sobie sytuacj, w ktrej wpro-wadzone limity uniemoliwi rozpoczcie pracy nad kolejnym zadaniem. Wyobramy sobie, e programista reprezentowany przez zielony awatar na powyszej tablicy

Pawe Brodziski

Efektywny czy zajty?

zakoczy wanie prace nad zadaniem F. W normalnej sytuacji zaczby prace nad kolejnym zadaniem, G lub F, jednak w tym przypadku wprowadzony limit uniemoli-wia to.

Sytuacj tak, a dokadniej czas w ktrym czonek zespou jest zablokowany przez limit prac w toku, nazywamy slack time. Slack time zgodnie z typowym postrzega-niem zarzdzania zespoem oznacza czas zmarnowany. Obnia on utylizacj pracow-nikw i spowalnia tempo rozpoczynania nowych zada.

Interesujce jest to, e obie te rzeczy ograniczenie utylizacji i nisze tempo roz-poczynania zada s do pewnego stop-nia podane jeli chcemy optymalizowa efektywno prac caego zespou. Innymi sowy, slack time pomaga nam podnie efektywno zespou. Dzieje si tak w duej mierze dziki unikniciu kosztw zwizanych z przeczaniem kontekstu.

W kocu miar tego jak efektywny jest nasz proces nie jest to jak szybko zaczyna-my kolejne zadania, ale jak sprawnie je koczymy. Jeli uyjemy takiej wanie miary okae si, e sytuacja, w ktrej cz czonkw zespou od czasu do czasu nie zajmuje si w ogle prac projektow powoduje, e produktywno zespou wzrosa!

Jak waciwie ustali limity? Przyjrzymy si teorii ogranicze3. Proces jako cao bdzie jedynie tak wydajny jak jego najwol-niejszy etap. Jeeli zatem wskie gardo w naszym procesie jest gdziekolwiek in-dziej ni na jego najwczeniejszym etapie, to limity prac w toku s nam potrzebne po to aby nie zasypa wczeniejszych etapw procesu nadmiarem zada.

Jednoczenie, sensowne limity prac w toku bd dopasowane do wydajnoci naszego wskiego garda. Biorc pod uwag jak zmienne s zadania w projektach informa-tycznych wskazanie waciwych limitw wycznie na bazie analizy samego procesu jest niemoliwe. Dochodzimy do tego eks-perymentalnie. Innymi sowy, powinnimy tak dugo zmienia limity a przepyw zada bdzie najsprawniejszy.

Podejcie to ma rwnie tak zalet, e przygotowuje nas do dalszych zmian limi-tw w sytuacji kiedy nasz proces ewoluuje. W kontekcie knowledge work proces jest znacznie bardziej elastyczny ni ma to miejsce w przemyle. Czsto drobne zmiany wprowadzane przez poszczegl-

nych czonkw zespou mocno zmieniaj dynamik pracy i powoduj, e wskie gardo znajdzie si w innymi miejscu. Czasem podobny efekt wywoa po prostu zmiana specyfiki wykonywanych zada.

W kadym z takich przypadkw limity prac w toku powinny by dostosowane do nowej sytuacji. Dziki temu, e znamy ju mechanizm ewolucyjnego dopasowywania ich, nie powinno to nastrczy specjalnych trudnoci.


Jak zmierzy efektywno pracy? Naja-twiej zliczy koczone zadania w czasie. Jeeli na etapie definiowania zada przyj-mujemy jakie wagi lub rozmiar moemy to rwnie uwzgldni. Oba te podejcia s mocno uproszczone, bo nie mwi o war-toci ktr dostarczamy klientowi lub uytkownikowi najlepiej byoby zatem przyj jak miar dostarczonej wartoci. O to jest jednak zwykle bardzo trudno.

Niezalenie jednak, ktrej z tych miar uy-jemy bdziemy w stanie bardziej lub mniej dokadnie powiedzie jaka jest i jak zmienia si produktywno zespou.

Majc tak metryk moemy do bez-piecznie przeprowadzi eksperyment z ograniczaniem prac w toku. Okae si, e wbrew intuicji wikszoci menaderw optymalizacja zajtoci ludzi wcale nie pomaga w byciu efektywnym. Wrcz prze-ciwnie, skupienie si na efektywnoci i optymalizowanie tego parametru z pomoc

ogranicze prac w toku doprowadzi do tego, e utylizacja ludzi spadnie.

Nie do, e efekty pracy zespou bd lepsze to jeszcze jego czonkowie dostan czas, ktry mog wykorzysta na przykad na rozwj wasnych umiejtnoci.

Efektywny wcale nie oznacza cigle zajty i vice versa.

Gerald Weinberg: Quality Software Management: Vol. 1 Systems Thinking

Eyal Ophir, Cliord Nass, Anthony D. Wagner: Cognitive control in media multitaskers

Eliyahu M. Goldratt: The Goal: The Process of Ongoing Improvement

pracy w zespoach. Zacznijmy jednak od symptomw. Jednym ze standardowych sygnaw, e co jest nie tak s rosnce kolejki zada czekajcych na realizacj ko-lejnego etapu procesu.

Typowym przykadem w projektach infor-matycznych s zadania dla ktrych etap developmentu jest zakoczony i czekaj na testy. Czy takie zadanie mona traktowa jako zakoczone? Nie, w kocu najprawdo-podobniej bd potrzebne poprawki do znalezionych bdw.

Jeli przyjrzymy si temu jak wyglda re-alizacja zada w dowolnym momencie pro-cesu takich kolejek zada znajdziemy wiele. Dlaczego?

Odpowiedzi jest jeden z bardzo po-wszechnych paradygmatw zarzdzania denie do 100% utylizacji ludzi. Przecie jeeli mwimy o tzw. knowledge work, zwykle jedyny istotny koszt to koszt pracy. To nie linia produkcyjna z kosztow-nymi maszynami gdzie czowiek jest tylko dodatkiem. Tutaj lini produkcyjn jest czowiek.


Wikszo z nas za kadym razem, kiedy zesp zaczyna realizacj nowego projektu ma przed oczami tak sam wizj. Sprawna realizacja zada, stabilny i systematyczny progres ukoczonych zada i efektywna praca wszystkich czonkw zespou.

Co ciekawe, nawet w sytuacjach zblio-nych do ideau, kiedy mamy du elastycz-no na etapie tworzenia zespou, jest to bardzo rzadki widok. Najczciej postpy trudno nazwa zadowalajcymi i to mimo intensywnego wysiku czonkw zespou starajcych si jak najlepiej realizowa swoje zadania.

To jeden z tych momentw kiedy, zamiast wywiera presj na zesp, warto si za-trzyma i zada sobie pytanie: dlaczego?

Dlaczego zesp specjalistw sprawdzo-nych w innych projektach majcych do dobrze zdefiniowany zakres zada ma takie problemy w ukoczeniu czegokolwiek?

100% utylizacjiOdpowied kryje si w bardzo powszech-nym, niestety, podejciu do organizacji

Jeeli zatem koszt ludzi jest gwn ska-dow oglnych kosztw projektu powinni-my chcie tak zorganizowa prac aby ludzie byli maksymalnie wykorzystywani. W ten sposb osigniemy maksymaln efektywno. Brzmi sensownie, prawda?

I to wanie cay problem brzmi sensow-nie, mimo e absolutnie nie znajduje po-twierdzenia w rzeczywistoci.

Aby zbliy si do 100% utylizacji ludzi, kady z czonkw zespou musi mie kolej-k zada czekajcych na niego. Kiedy skoczy biece zadanie, zawsze bdzie czekao na niego kolejne, dziki temu b-dziemy minimalizowa przestoje.

Problem w tym e to rwnie oznacza bardzo du liczb zada, ktre s rozpo-czte a nie zakoczone tak zwanych prac w toku. Oczywicie zakadam tutaj, e prace w toku definiujemy patrzc przez pryzmat caego procesu, a nie konkretnego jego etapu. Innymi sowy zadanie zaczyna by w toku kiedy rozpoczyna si pierwszy z etapw prac analiza, projektowanie, czy cokolwiek to jest w danym kontekcie a koczy si kiedy zesp nie planuje robi z nim ju niczego wicej.

Jaki jest efekt duej iloci prac w toku? Prost konsekwencj jest czste prze-czanie kontekstu, co ma tragiczne skutki dla efektywnoci pracy.

Koszt przeczania kontekstu

Gerald Weinberg wskazuje1, e koszt prze-czania kontekstu to 20% czasu dla ka-dego kolejnego zadania, nad ktrym pracu-jemy rwnolegle. Okazuje si, e nie tak trudno doprawdzi do sytuacji, w ktrej marnujemy blisko poow dostpnego czasu pracy. (Zobacz Rysunek 1).

Argument, ktry czsto sysz kiedy przy-wouj opracowanie Geralda Weinberga w kontekcie duej iloci prac w toku jest taki, e przecie kady z czonkw zespou w danym momencie skupia si nad jednym zadaniem. Pozostae zadania niejako ocze-kuj na swj czas. Przeczanie kontekstu odbywa si zatem w znacznie mniejszej skali ni sugerowaoby to proste porwna-nie iloci zada w toku i liczby czonkw zespou.

Prawdopodobnie byoby tak, gdybymy byli maszynami. Niestety nasz mzg ma tendencj aby sam sobie przerywa bie-c prac mylami o zadaniach, ktre pozo-

stawilimy niezakoczone. Przypomnijcie sobie sytuacje, w ktrych, robic co zu-penie niezwizanego nagle pomylelicie o rachunku, ktrego zapomnielicie zapa-ci, emailu, na ktry mielicie odpisa, albo jakim nierozwizanym problemie. To efekt Zegarnik (bo tak nazw nosi to zachowa-nie naszego mzgu) w akcji.

Dokadnie to samo dzieje si w kontekcie naszej codziennej pracy. Wracamy mylami do zada, nad ktrymi obecnie nie pracuje-my jednoczenie obciajc nas samych kosztem przeczania kontekstu.

Jest to zreszt bardzo spjne z wynikami bada na temat multitaskingu2 prowadzo-nych przez Eyala Ophira na uniwersytecie Stanford. Wskazuje on, e gwne rdo kosztu przeczania kontekstu to fakt, e nasz mzg zajmuje si myleniem o zada-niach, ktrych w danym momencie aktyw-nie nie wykonujemy.

Przeczanie kontekstu to nie tylko nisza efektywno pracy. To rwnie nisza jako. Wspomniane badania Eyala Ophira wskazay rwnie, e osoby zajmujce si paroma rze-czami jednoczenie czciej si myl.

Domy do tego kluczowy dla biznesu pa-rametr time to market, okrelajcy ile czasu potrzeba aby dostarczy wynik prac na rynek. Jeeli przeanalizujemy go pod ktem jego zwizku z przeczaniem kon-tekstu bardzo jasno zobaczymy jak moli-wo skupienia si na jednym zadaniu przekada si na efektywno caego pro-cesu. (Zobacz Rysunek 2).

W pierwszym z zaprezentowanych powy-ej scenariuszy systematycznie przecza-my si midzy kolejnymi zadaniami. W drugim, rozpoczynamy kolejne zadanie dopiero po zakoczeniu wczeniejszego. Nie tylko cakowity czas pracy jest krtszy w drugim przypadku, ale take moment dostarczenia poszczeglnych zada dra-stycznie si rni.

Co wicej, w drugim scenariuszu tym z ograniczon liczb zada w toku moemy wykorzysta informacje zwrotne z realizacji pierwszego zadania przy reali-zacji kolejnych. Dajemy sobie szanse na usprawnienia. W pierwszym scenariuszu takiej moliwoci nie dostajemy.

Ograniczanie prac w toku

Od szczytnego celu, czyli efektywnej pracy, przeszlimy przed 100% utylizacj i jej smutne konsekwencje, czyli intensyw-ne przeczanie kontekstu wraz ze wszyst-kimi zwizanymi kosztami. Sprbujmy zatem odwrci cay tok mylowy jaki bdzie efekt jeli ograniczymy ilo prac w toku?

Najbardziej typowym obecnie podejciem do ograniczania prac w toku jest okrelenie limitw dla kadego kolejnego etapu na-szego procesu. Jednoczenie unikamy sy-tuacji wprowadzenia nielimitowanych ko-lejek zada w przypadku gdy s one prze-kazywane do kolejnego etapu. Limit taki bdzie zatem dotyczy np. wszystkich zada w developmencie, niezalenie od tego czy development jeszcze trwa czy ju zosta zakoczony a zadanie oczekuje na testy. (Zobacz Rysunek 3).

Nie potrzeba nadmiernej kreatywnoci aby wyobrazi sobie sytuacj, w ktrej wpro-wadzone limity uniemoliwi rozpoczcie pracy nad kolejnym zadaniem. Wyobramy sobie, e programista reprezentowany przez zielony awatar na powyszej tablicy

zakoczy wanie prace nad zadaniem F. W normalnej sytuacji zaczby prace nad kolejnym zadaniem, G lub F, jednak w tym przypadku wprowadzony limit uniemoli-wia to.

Sytuacj tak, a dokadniej czas w ktrym czonek zespou jest zablokowany przez limit prac w toku, nazywamy slack time. Slack time zgodnie z typowym postrzega-niem zarzdzania zespoem oznacza czas zmarnowany. Obnia on utylizacj pracow-nikw i spowalnia tempo rozpoczynania nowych zada.

Interesujce jest to, e obie te rzeczy ograniczenie utylizacji i nisze tempo roz-poczynania zada s do pewnego stop-nia podane jeli chcemy optymalizowa efektywno prac caego zespou. Innymi sowy, slack time pomaga nam podnie efektywno zespou. Dzieje si tak w duej mierze dziki unikniciu kosztw zwizanych z przeczaniem kontekstu.

W kocu miar tego jak efektywny jest nasz proces nie jest to jak szybko zaczyna-my kolejne zadania, ale jak sprawnie je koczymy. Jeli uyjemy takiej wanie miary okae si, e sytuacja, w ktrej cz czonkw zespou od czasu do czasu nie zajmuje si w ogle prac projektow powoduje, e produktywno zespou wzrosa!

Jak waciwie ustali limity? Przyjrzymy si teorii ogranicze3. Proces jako cao bdzie jedynie tak wydajny jak jego najwol-niejszy etap. Jeeli zatem wskie gardo w naszym procesie jest gdziekolwiek in-dziej ni na jego najwczeniejszym etapie, to limity prac w toku s nam potrzebne po to aby nie zasypa wczeniejszych etapw procesu nadmiarem zada.

Jednoczenie, sensowne limity prac w toku bd dopasowane do wydajnoci naszego wskiego garda. Biorc pod uwag jak zmienne s zadania w projektach informa-tycznych wskazanie waciwych limitw wycznie na bazie analizy samego procesu jest niemoliwe. Dochodzimy do tego eks-perymentalnie. Innymi sowy, powinnimy tak dugo zmienia limity a przepyw zada bdzie najsprawniejszy.

Podejcie to ma rwnie tak zalet, e przygotowuje nas do dalszych zmian limi-tw w sytuacji kiedy nasz proces ewoluuje. W kontekcie knowledge work proces jest znacznie bardziej elastyczny ni ma to miejsce w przemyle. Czsto drobne zmiany wprowadzane przez poszczegl-

Rysunek 1

Rysunek 2

nych czonkw zespou mocno zmieniaj dynamik pracy i powoduj, e wskie gardo znajdzie si w innymi miejscu. Czasem podobny efekt wywoa po prostu zmiana specyfiki wykonywanych zada.

W kadym z takich przypadkw limity prac w toku powinny by dostosowane do nowej sytuacji. Dziki temu, e znamy ju mechanizm ewolucyjnego dopasowywania ich, nie powinno to nastrczy specjalnych trudnoci.


Jak zmierzy efektywno pracy? Naja-twiej zliczy koczone zadania w czasie. Jeeli na etapie definiowania zada przyj-mujemy jakie wagi lub rozmiar moemy to rwnie uwzgldni. Oba te podejcia s mocno uproszczone, bo nie mwi o war-toci ktr dostarczamy klientowi lub uytkownikowi najlepiej byoby zatem przyj jak miar dostarczonej wartoci. O to jest jednak zwykle bardzo trudno.

Niezalenie jednak, ktrej z tych miar uy-jemy bdziemy w stanie bardziej lub mniej dokadnie powiedzie jaka jest i jak zmienia si produktywno zespou.

Majc tak metryk moemy do bez-piecznie przeprowadzi eksperyment z ograniczaniem prac w toku. Okae si, e wbrew intuicji wikszoci menaderw optymalizacja zajtoci ludzi wcale nie pomaga w byciu efektywnym. Wrcz prze-ciwnie, skupienie si na efektywnoci i optymalizowanie tego parametru z pomoc

ogranicze prac w toku doprowadzi do tego, e utylizacja ludzi spadnie.

Nie do, e efekty pracy zespou bd lepsze to jeszcze jego czonkowie dostan czas, ktry mog wykorzysta na przykad na rozwj wasnych umiejtnoci.

Efektywny wcale nie oznacza cigle zajty i vice versa.

Gerald Weinberg: Quality Software Management: Vol. 1 Systems Thinking

Eyal Ophir, Cliord Nass, Anthony D. Wagner: Cognitive control in media multitaskers

Eliyahu M. Goldratt: The Goal: The Process of Ongoing Improvement

CD. NA STR. 22

WprowadzenieTrzy kolejne wersje PMBOKGuidea wymie-niaj facylitacj jako technik pracy grupo-wej, ktra pozwala na zbudowanie zespou, dystrybuowanie informacji, oraz identyfiko-wanie ryzyk.

Facylitacja kieruje si swoimi prawami, eby bya skuteczna, a nasz artyku opowie o nich, by wyjani jak moe by ona stosowana w projektach.

Technika ta staje si coraz bardziej popularna poniewa pozwala doj zespoowi do samo-dzielnej decyzji, jednak z udziaem osoby, ktra potrafi odpowiednio pokierowa rozmo-w tak, by uczestnicy nie zrobili sobie nawza-jem krzywdy.

Zgodnie z jedn z definicji facylitacja to kade dziaanie, ktre powoduje, e zadanie jest atwe dla innych lub zadania, ktre s wspierane przez innych. Celem facylitacji jest zapewnienie, eby spotkania i warsztaty byy zaprojektowane, oraz prowadzone w sposb skuteczny.

Kim jest facylitator?Facylitator to osoba wykwalifikowana w wy-korzystaniu odpowiednich do zadania: proce-su, modeli, technik i narzdzi.

Wrd nich znajduj si:

Parafrazowanie wg. modelu Feedback,

Model czteropolwki,

Sytuacja, Propozycja, Oczekiwane Rezultaty (SPO),

Model Process Iceberg,

Symptom, Przyczyna, Dziaanie (SCA),

Alegorie,

Opowiadanie Historii.

W zwizku z tym, takie dziaanie ju nie wy-glda na atwe zwaszcza, e trzeba wzi pod uwag, e od facylitatora dodatkowo oczeku-je si bezstronnoci, a to moe nie by takie atwe, jeli sam jest zaangaowany (w prac lub emocjonalnie) w rezultaty.

Za co odpowiada facylitator?

W facylitacji stawia si mocny nacisk na roz-rnienie odpowiedzialnoci za proces od od-powiedzialnoci za zadanie.

Podobnie jak w przypadku zarzdzania pro-jektami, proces oznacza pewne dziaania pro-wadzce do okrelonego rezultatu. Standardy takie jak PMBOKGuide lub PRINCE2 nie definiuj zawartoci tego, co w procesie jest

przetwarzane - podobnie w podrczniku fa-cylitacji nie definiuje si zawartoci tego, co mamy osign. Podrcznik okrela to jako Zadanie. Kilka zrealizowanych zada cznie pozwala nam na osignicie celu. W przypad-ku zarzdzania projektami moe tym celem by: zrealizowanie projektu w ramach ograni-cze trjkta projektu. A zadania w, ktrych nam facylitacja moe pomc to np. identyfi-kowanie ryzyk.

Podobnie jak w przypadku zarzdzania pro-jektami rwnie w facylitacji naley uwzgld-ni interesariuszy, zwaszcza, e warsztat moe by realizowany w oparciu o rne for-maty. Formatem nazywamy sposb wykorzy-stania zasobw w trakcie spotkania i tak:

Grupa oznacza, e interesariusze zaangaowani bd pracowali razem,

Kady znaczy, e kady bdzie pracowa sam,

Wszyscy do jednego bdzie powodo-wa, e wszystkie osoby bd razem pracoway nad jednym problemem,

Jeden do wszystkich jedna osoba pracuje w imieniu osb pozostaych, np. gdy ma najwiksze dowiadczenie.

Spord wszystkich interesariuszy w facylita-cji wymienia si dwch kluczowych. Za zada-nie odpowiada Lider zadania, a za proces od-powiada facylitator. W zwizku z tym od Lidera zadania oczekujemy wiedzy specjali-stycznej z zakresu zadania, a od facylitatora


Tomasz Ndzi

Facylitacja w projektach

Fot.

: Shu

tter

stoc

k.co

m

tej wiedzy ju si nie spodziewamy, poniewa jego rol jest panowanie nad sposobem pro-wadzenia spotkania. Taka wiedza specjali-styczna mogaby nawet by przeszkod, gdyby Facylitator chcia si zaangaowa w merytoryczne rozwizywanie problemu.

W kontekcie zarzdzania projektami w zwiz-ku z tym raczej nie oczekiwalibymy od Kie-rownika Projektu penienia roli facylitatora, ale moemy spodziewa si, e przyjmie on/ona rol Lidera zadania. Rwnie w podrczniku DSDM Atern (najbardziej kompleksowej me-todzie agile) znajdziemy wyran sugesti, e facylitator to oddzielna i niezalena od Kie-rownika Projektu rola.

Skuteczny facylitator powinien (za Facylita-cja wiedza, umiejtnoci, sztuka czy magia, Tony Mann, Jolanta Marszewska):

by zorientowany na zmiany,

by odwany w podejmowaniu ryzyka,

by zorientowany na generowanie pomysw,

by elastyczny,

by szybki w reagowaniu i dziaaniu,

by zorientowany na proces,

by Niezauwaalnym katalizatorem,

by ekstrawertykiem,

by w stanie zachowa spokj w stresie,

posiada niski poziom stresu,

posiada szeroki zakres wiedzy biznesowej.

Szacowanie czasu i kosztu facylitacji

Oprcz znalezienia takiego specjalisty od pro-wadzenia spotka musimy take w jaki

sposb oszacowa czas konieczny do prze-prowadzenia warsztatw.

Tutaj pojawia si jednak pewne ryzyko:

1. O ile z zagadnieniami, ktre s pewne (tzn. pytanie na ktre trzeba udzieli odpowied jest jasne, a odpowied jest atwa do uzyska-nia od uczestnikw warsztatu), to atwiej jest rwnie oszacowa konieczny czas, a sama realizacja nie powinna odbiega od zaoe.

2. W przypadku kiedy mamy do czynienia ze zoonoci (tzn. pytanie jest jasne, ale odpo-wied nie jest jeszcze znana) to czas pierwot-nie szacowany moe w trakcie realizacji warsztatu wyduy si nawet 2,5 krotnie.

3. Ostatecznie kiedy mamy do czynienia z niepewnoci (pytanie/problem/zagadnie-nie nie jest znane i naley najpierw je/go zro-zumie, by znale odpowied lub rozwiza-nie) to faktyczny czas samego warsztatu moe wyduy si nawet 4,25 razy.

Dodatkowo rol facylitatora jest odpowiednie zarzdzanie zotym trjktem facylitacji. Tak jak w przypadku trjkta projektu, gdzie w zalenoci pomidzy sob pozostaj za-kres-czas-koszt tak w przypadku facylitacji mamy zalene od siebie zadanie-czas-doj-rzao grupy lub zadanie-czas-proces. To oznacza, e czas realizacji zaleny jest od za-dania (co znamy z zarzdzania projektami jako zakres), oraz od dojrzaoci grupy/proce-su czyli trudnoci realizacji danego zadania. Poziom trudnoci moe jednak oszacowa tylko dowiadczony facylitator.

Oznacza to, e Kierownik Projektu, podobnie jak w przypadku szacowania innych zada w projekcie, powinien raczej skorzysta z pomocy facylitatora ju na etapie planowa-nia, by mc uwzgldni waciwy czas i koszt. Za takim rozwizaniem przemawia rwnie

konieczno uwzgldnienia wymaga organi-zacyjnych dotyczcych lokalizacji jak i wypo-saenia warsztatw co rwnie bdzie wpy-wao na budet.

Moe si jednak okaza, e takie zasoby w projekcie wcale nie bd potrzebne. Facyli-tacja nie jest lekiem na kady problem. Moe si okaza, e pomimo tego, e jej zastosowa-nie jest kuszce to w przypadkach, gdy zada-nie jest pewne lub zoone, a zesp wie jak poradzi sobie z problemem to facylitator, wcale nie bdzie potrzebny. Wtedy stosowa-nie facylitacji bdzie przypomina strzelanie z armaty do muchy.

PodsumowanieDowiadczony facylitator (podobnie jak do-wiadczony Kierownik Projektu) posuguje si procesem tak by inni mogli zrealizowa cele przed nimi postawione. To od wprawy i dowiadczenia facylitatora (tak jak w przy-padku Kierownika Projektu) zaley jak spraw-nie radzi sobie on z dobraniem odpowiednich narzdzi i dopasowaniem procesu do wyma-ga zadania.

Jak wida facylitacja wyglda (podobnie jak zarzdzanie projektami) na dziedzin sam w sobie. Wyglda wic na to, e rol Kierow-nika Projektu jest raczej pozyskanie i zmoty-wowanie odpowiednio dowiadczonego spe-cjalisty by rezultaty byy co najmniej zado-walajce. Wydaje si jednak, e to jest to, co dowiadczeni Kierownicy Projektw robi najlepiej.


WprowadzenieTrzy kolejne wersje PMBOKGuidea wymie-niaj facylitacj jako technik pracy grupo-wej, ktra pozwala na zbudowanie zespou, dystrybuowanie informacji, oraz identyfiko-wanie ryzyk.

Facylitacja kieruje si swoimi prawami, eby bya skuteczna, a nasz artyku opowie o nich, by wyjani jak moe by ona stosowana w projektach.

Technika ta staje si coraz bardziej popularna poniewa pozwala doj zespoowi do samo-dzielnej decyzji, jednak z udziaem osoby, ktra potrafi odpowiednio pokierowa rozmo-w tak, by uczestnicy nie zrobili sobie nawza-jem krzywdy.

Zgodnie z jedn z definicji facylitacja to kade dziaanie, ktre powoduje, e zadanie jest atwe dla innych lub zadania, ktre s wspierane przez innych. Celem facylitacji jest zapewnienie, eby spotkania i warsztaty byy zaprojektowane, oraz prowadzone w sposb skuteczny.

Kim jest facylitator?Facylitator to osoba wykwalifikowana w wy-korzystaniu odpowiednich do zadania: proce-su, modeli, technik i narzdzi.

Wrd nich znajduj si:

Parafrazowanie wg. modelu Feedback,

Model czteropolwki,

Sytuacja, Propozycja, Oczekiwane Rezultaty (SPO),

Model Process Iceberg,

Symptom, Przyczyna, Dziaanie (SCA),

Alegorie,

Opowiadanie Historii.

W zwizku z tym, takie dziaanie ju nie wy-glda na atwe zwaszcza, e trzeba wzi pod uwag, e od facylitatora dodatkowo oczeku-je si bezstronnoci, a to moe nie by takie atwe, jeli sam jest zaangaowany (w prac lub emocjonalnie) w rezultaty.

Za co odpowiada facylitator?

W facylitacji stawia si mocny nacisk na roz-rnienie odpowiedzialnoci za proces od od-powiedzialnoci za zadanie.

Podobnie jak w przypadku zarzdzania pro-jektami, proces oznacza pewne dziaania pro-wadzce do okrelonego rezultatu. Standardy takie jak PMBOKGuide lub PRINCE2 nie definiuj zawartoci tego, co w procesie jest

przetwarzane - podobnie w podrczniku fa-cylitacji nie definiuje si zawartoci tego, co mamy osign. Podrcznik okrela to jako Zadanie. Kilka zrealizowanych zada cznie pozwala nam na osignicie celu. W przypad-ku zarzdzania projektami moe tym celem by: zrealizowanie projektu w ramach ograni-cze trjkta projektu. A zadania w, ktrych nam facylitacja moe pomc to np. identyfi-kowanie ryzyk.

Podobnie jak w przypadku zarzdzania pro-jektami rwnie w facylitacji naley uwzgld-ni interesariuszy, zwaszcza, e warsztat moe by realizowany w oparciu o rne for-maty. Formatem nazywamy sposb wykorzy-stania zasobw w trakcie spotkania i tak:

Grupa oznacza, e interesariusze zaangaowani bd pracowali razem,

Kady znaczy, e kady bdzie pracowa sam,

Wszyscy do jednego bdzie powodo-wa, e wszystkie osoby bd razem pracoway nad jednym problemem,

Jeden do wszystkich jedna osoba pracuje w imieniu osb pozostaych, np. gdy ma najwiksze dowiadczenie.

Spord wszystkich interesariuszy w facylita-cji wymienia si dwch kluczowych. Za zada-nie odpowiada Lider zadania, a za proces od-powiada facylitator. W zwizku z tym od Lidera zadania oczekujemy wiedzy specjali-stycznej z zakresu zadania, a od facylitatora Fo

t.: w

ww

.sxc

.hu

tej wiedzy ju si nie spodziewamy, poniewa jego rol jest panowanie nad sposobem pro-wadzenia spotkania. Taka wiedza specjali-styczna mogaby nawet by przeszkod, gdyby Facylitator chcia si zaangaowa w merytoryczne rozwizywanie problemu.

W kontekcie zarzdzania projektami w zwiz-ku z tym raczej nie oczekiwalibymy od Kie-rownika Projektu penienia roli facylitatora, ale moemy spodziewa si, e przyjmie on/ona rol Lidera zadania. Rwnie w podrczniku DSDM Atern (najbardziej kompleksowej me-todzie agile) znajdziemy wyran sugesti, e facylitator to oddzielna i niezalena od Kie-rownika Projektu rola.

Skuteczny facylitator powinien (za Facylita-cja wiedza, umiejtnoci, sztuka czy magia, Tony Mann, Jolanta Marszewska):

by zorientowany na zmiany,

by odwany w podejmowaniu ryzyka,

by zorientowany na generowanie pomysw,

by elastyczny,

by szybki w reagowaniu i dziaaniu,

by zorientowany na proces,

by Niezauwaalnym katalizatorem,

by ekstrawertykiem,

by w stanie zachowa spokj w stresie,

posiada niski poziom stresu,

posiada szeroki zakres wiedzy biznesowej.

Szacowanie czasu i kosztu facylitacji

Oprcz znalezienia takiego specjalisty od pro-wadzenia spotka musimy take w jaki

sposb oszacowa czas konieczny do prze-prowadzenia warsztatw.

Tutaj pojawia si jednak pewne ryzyko:

1. O ile z zagadnieniami, ktre s pewne (tzn. pytanie na ktre trzeba udzieli odpowied jest jasne, a odpowied jest atwa do uzyska-nia od uczestnikw warsztatu), to atwiej jest rwnie oszacowa konieczny czas, a sama realizacja nie powinna odbiega od zaoe.

2. W przypadku kiedy mamy do czynienia ze zoonoci (tzn. pytanie jest jasne, ale odpo-wied nie jest jeszcze znana) to czas pierwot-nie szacowany moe w trakcie realizacji warsztatu wyduy si nawet 2,5 krotnie.

3. Ostatecznie kiedy mamy do czynienia z niepewnoci (pytanie/problem/zagadnie-nie nie jest znane i naley najpierw je/go zro-zumie, by znale odpowied lub rozwiza-nie) to faktyczny czas samego warsztatu moe wyduy si nawet 4,25 razy.

Dodatkowo rol facylitatora jest odpowiednie zarzdzanie zotym trjktem facylitacji. Tak jak w przypadku trjkta projektu, gdzie w zalenoci pomidzy sob pozostaj za-kres-czas-koszt tak w przypadku facylitacji mamy zalene od siebie zadanie-czas-doj-rzao grupy lub zadanie-czas-proces. To oznacza, e czas realizacji zaleny jest od za-dania (co znamy z zarzdzania projektami jako zakres), oraz od dojrzaoci grupy/proce-su czyli trudnoci realizacji danego zadania. Poziom trudnoci moe jednak oszacowa tylko dowiadczony facylitator.

Oznacza to, e Kierownik Projektu, podobnie jak w przypadku szacowania innych zada w projekcie, powinien raczej skorzysta z pomocy facylitatora ju na etapie planowa-nia, by mc uwzgldni waciwy czas i koszt. Za takim rozwizaniem przemawia rwnie

konieczno uwzgldnienia wymaga organi-zacyjnych dotyczcych lokalizacji jak i wypo-saenia warsztatw co rwnie bdzie wpy-wao na budet.

Moe si jednak okaza, e takie zasoby w projekcie wcale nie bd potrzebne. Facyli-tacja nie jest lekiem na kady problem. Moe si okaza, e pomimo tego, e jej zastosowa-nie jest kuszce to w przypadkach, gdy zada-nie jest pewne lub zoone, a zesp wie jak poradzi sobie z problemem to facylitator, wcale nie bdzie potrzebny. Wtedy stosowa-nie facylitacji bdzie przypomina strzelanie z armaty do muchy.

PodsumowanieDowiadczony facylitator (podobnie jak do-wiadczony Kierownik Projektu) posuguje si procesem tak by inni mogli zrealizowa cele przed nimi postawione. To od wprawy i dowiadczenia facylitatora (tak jak w przy-padku Kierownika Projektu) zaley jak spraw-nie radzi sobie on z dobraniem odpowiednich narzdzi i dopasowaniem procesu do wyma-ga zadania.

Jak wida facylitacja wyglda (podobnie jak zarzdzanie projektami) na dziedzin sam w sobie. Wyglda wic na to, e rol Kierow-nika Projektu jest raczej pozyskanie i zmoty-wowanie odpowiednio dowiadczonego spe-cjalisty by rezultaty byy co najmniej zado-walajce. Wydaje si jednak, e to jest to, co dowiadczeni Kierownicy Projektw robi najlepiej.

Tomasz NdziPRINCE2/AgilePM/M_o_R/P3O Approved Trainer

Prezes Zarzdu w skills sp. z o. o.Przedstawiciel BPUG PolskaCountry Head IIC

Od 1994 roku zwizany z zarzdzaniem projektami. By Kierownikiem Projektu dla IBM Polska, oraz Kierownikiem Projektu i Programu dla NASK. Od 2004 roku przeszkoli z zarzdzania projektami ponad 5000 osb z ponad 500 firm rnych bran. Po jego szkoleniach certyfikat z PRINCE2 zdobyo blisko 800 osb.Posiada certyfikat NM Practitioner Coach Diploma i NM Executive&Corporate Coach, oraz akredytacj Accredited Practitioner Coach (IIC).

Trzecia Edycja wydarzeniaNew Trends in Project Management

bw przeprowadzenia spotka o metodyce Scrum, podziale odpowiedzialnoci i rl w zespole Scrum, Scrum Artifacts oraz jak przewodzi samoorganizujcym si zespo-om i wiele innych.

Uczestnicy konferencji otrzymaj niepo-wtarzaln szans, jak jest nieograniczo-ny dostp do sesji prowadzonych zarwno przez PMI jak i firm Intel oraz prelegentw specjalistw w obszarze zarzdzania projektami. Jednoczenie mog oni samo-dzielnie ukada plan swojego uczestnic-twa w poszczeglnych prelekcjach i warsz-tatach, dowolnie komponujc i czc elementy poszczeglnych cieek.

Tegoroczna edycja konferencji to 3 bloki tematyczne oraz 2 bloki warsztatowe, prowadzone zarwno przez najwikszych praktykw jak i teoretykw zarzdzania projektami. Konferencja obejmuje takie za-gadnienia jak: przywdztwo i podejmowa-nie ryzyka, przyspieszanie rozwoju produk-tu, samoorganizujce si zespoy oraz ska-lowanie w gr. Nasze wydarzenie nie mo-goby si take odby bez poruszenia te-


Project Management Institute Gdask Branch oraz Intel Corporation maj zaszczyt zaprosi Pastwa na trzeci ju edycj konferencji New Trends in Project Management, tym razem w poczeniu z konferencj Agile & Lean Development do tej pory znan w rodowisku spoecznoci firmy Intel.

Konferencja odbdzie si 22-23 maja 2014 w Hotelu Sheraton w Sopocie, a poprzedzi j m.in. szkolenie Certified Scrum Master training. Zostanie ono przeprowadzone przez Christopha Mathisa. W trakcie szko-lenia uczestnicy bd mieli szans posze-rzy swoj wiedz na temat celu i sposo-

matyki nowych trendw w zarzdzaniu projektami. Nie zabraknie tu konferencyj-nych saw takich jak David Snowden, Kevin Murphy czy Alan Gladman. Bd take mieli Pastwo okazj wyprbowa nowo-czesne rozwizania informatyczne dla pro-ject managerw i biur projektowych.

Dla naszych uczestnikw przygotowalimy nie tylko bogaty wachlarz prelekcji i warsz-tatw. Z myl o stworzeniu warunkw sprzyjajcych integracji uczestnikw, pro-gram po raz pierwszy zostanie urozmaico-ny o takie formy networkingowe jak Pecha-Kucha, Speed Mentoring oraz Wolrds Cafe. Panel dyskusyjny z naszymi wyjtkowymi ekspertami w rolach gw-nych bdzie dodatkow moliwoci na wymian dowiadcze w obszarze nowych trendw w zarzdzaniu projektami oraz metodologii Agile & Lean.

Gboko wierzymy, e udzia w NTPM 2014 Agile and Lean Development to moli-wo zdobycia nowych umiejtnoci, podniesienia kwalifikacji, wymiany do-wiadcze i networkingu. Tegoroczna konferencja jest dla nas szczeglnie wana, poniewa po raz pierwszy wspor-ganizujemy j z firm Intel. Takie rozwiza-nie zwiksza grup odbiorcw konferencji, wzbogaca program oraz pozwala na inte-gracj brany IT i innych obszarw.

Wicej informacji o konferencji znajd Pastwo na stronie www.ntpm.pl.

PRELEGENCI I TRENERZYWrd naszych prelegentw i trenerw znajd si m. in.:

Dave Snowden jest zaoycielem i dyrek-torem ds. nauki i rozwoju Cognitive Edge. Midzynarodowy charakter jego pracy obejmuje spojrzenie na zoone kwestie dotyczce strategii, podejmowania decyzji indywidualnych oraz na szczeblu organiza-cji, zarwno z punktu widzenia dziaa rz-dowych jak i przemysu. Jego artyku na temat Przywdztwa z Boone (wspautor), stanowi okadk the Harvard Business Review w listopadzie 2007 roku i otrzyma nagrod Akademii Zarzdzania za najlepszy artyku praktykujcy tego samego roku. Dave jest rwnie gwnym projektantem oprogramowania Sense Maker, pocztko-wo opracowanego w obszarze zwalczania terroryzmu i obecnie aktywnie rozwijane-go przez rzd i przemys.

Kevin Murphy rozpocz prac w firmie Intel w 2000 roku pracujc na stanowi-skach zwizanych inynieri, zarzdza-niem i planowaniem strategicznym. Kevin zaoy i zarzdza Centrum Rozwoju Pro-duktu i Motoryzacji oddzia firmy Intel w Karlsruhe w Niemczech. Obj stanowi-sko Dyrektora ds. Inynierii i kieruje prac zespou ekspertw wytwarzajcych roz-wizania dla pierwszej platformy motory-zacyjnej Intela. Kevin uzyska tytu Dokto-ra na Uniwersytecie w stanie Arizona oraz tytu MBA na Uniwersytecie w stanie San Francisco. Jest autorem wielu patentw w obszarze transmisji szerokopasmowej, technologii interfejsu dla zaawansowane-go uytkownika oraz telewizji cyfrowej.

Jorgen Hesselberg jest dyrektorem Agile Enterprise Transformation w McAfee. Po-siada ponad 15 lat dowiadczenia w two-rzeniu rodowisk (spoecznoci) organiza-cyjnych. Jest take pasjonatem w kreowa-niu wiata lepszym miejscem do pracy po-przez metodologi agile, Lean i mylenie zoonych systemw. Zanim wstpi w sze-regi McAfee, Jorgen sta na czelethe enter-prise transformation eorts w NAVTEQ, Nokia and Nokia Xpress. Jest czstym pre-legentem podczas midzynarodowych kon-ferencji, a take autorem wielu white papers i aktywnym dziaaczem w lokalnej spoecznoci agile. Jest dyrektorem pro-gramu Agile Alliances Supporting Agile Adoption.

NOWOCI PROGRAMOWE I WARSZTATY

Zapraszamy do wzicia udziau w sesjach o rnorodnych formach:

Certified Scrum MasterSzkolenie CSM zostanie poprowadzone przez Christopha Mathisa. Program szkole-nia obejmowa bdzie nastpujce zagad-nienia: spotkania Scrum (cel i sposb ich prowadzenia), role w Scrum (poszczeglne odpowiedzialnoci oraz ich zalenoci), wymagania Agile, wzrost produktu (Pro-duct increment), jak przewodzi samoor-ganizujcym si zespoom, a take jak wspiera Product Ownera w celu uzyska-nia znakomitego produktu.

Koloseum, Massawa i Scrum Droid

Te docenione przez wielu warsztaty zdoby-y kilka nagrd PMI Awards. W trakcie tych sesji uczestnicy bd mieli okazj wcieli si w rne role i spojrze na zasady i na-rzdzia projektowe w ujciu praktycznym. Pomog one rwnie uwiadomi sobie faktyczne funkcjonowanie procesw i po-dzia rl oraz odpowiedzialnoci. W ten sposb atwiej jest zaadaptowa je do re-aliw przedsibiorstwa i unikn ryzyka poraki przy wdraaniu metodyk PMBOK czy Scrum.

Pecha-kuchaJest to rewolucyjny, a jednak prosty format prezentacji, w ktrej prezentujcy przed-stawia 20 slajdw, w tym na kady slajd przeznaczone jest 20 sekund. Autorami tej formy prezentacji s Astrid Klein oraz Mark Dytham z Klein Dytham architecture. Pecha-Kucha zostaa wynaleziona specjal-nie dla prezentujcych, ktrzy uwielbiaj mwi. Jej sesje stwarzaj szans na od-krycie niespodziewanych pomysw w za-rzdzaniu projektami, wymian wiedzy lub po prostu wasnych ciekawych projektw.

Speed MentoringCelem szkolenia jest stworzenie przychyl-nych warunkw na nawizanie nowych znajomoci biznesowych. Po okreleniu rl, jakie powinien spenia mentor i mentee uczestnicy sprecyzuj oczekiwania wzgl-dem szkolenia oraz efekty, jakich si spo-dziewaj. Grupa uczestnikw zostanie po-dzielona dwuosobowe zespoy, ktre bd wymienia si midzy sob wiedz i do-wiadczeniem w obszarze zarzdzania pro-jektami i metodologii Agile & Lean.

bw przeprowadzenia spotka o metodyce Scrum, podziale odpowiedzialnoci i rl w zespole Scrum, Scrum Artifacts oraz jak przewodzi samoorganizujcym si zespo-om i wiele innych.

Uczestnicy konferencji otrzymaj niepo-wtarzaln szans, jak jest nieograniczo-ny dostp do sesji prowadzonych zarwno przez PMI jak i firm Intel oraz prelegentw specjalistw w obszarze zarzdzania projektami. Jednoczenie mog oni samo-dzielnie ukada plan swojego uczestnic-twa w poszczeglnych prelekcjach i warsz-tatach, dowolnie komponujc i czc elementy poszczeglnych cieek.

Tegoroczna edycja konferencji to 3 bloki tematyczne oraz 2 bloki warsztatowe, prowadzone zarwno przez najwikszych praktykw jak i teoretykw zarzdzania projektami. Konferencja obejmuje takie za-gadnienia jak: przywdztwo i podejmowa-nie ryzyka, przyspieszanie rozwoju produk-tu, samoorganizujce si zespoy oraz ska-lowanie w gr. Nasze wydarzenie nie mo-goby si take odby bez poruszenia te-


Project Management Institute Gdask Branch oraz Intel Corporation maj zaszczyt zaprosi Pastwa na trzeci ju edycj konferencji New Trends in Project Management, tym razem w poczeniu z konferencj Agile & Lean Development do tej pory znan w rodowisku spoecznoci firmy Intel.

Konferencja odbdzie si 22-23 maja 2014 w Hotelu Sheraton w Sopocie, a poprzedzi j m.in. szkolenie Certified Scrum Master training. Zostanie ono przeprowadzone przez Christopha Mathisa. W trakcie szko-lenia uczestnicy bd mieli szans posze-rzy swoj wiedz na temat celu i sposo-

matyki nowych trendw w zarzdzaniu projektami. Nie zabraknie tu konferencyj-nych saw takich jak David Snowden, Kevin Murphy czy Alan Gladman. Bd take mieli Pastwo okazj wyprbowa nowo-czesne rozwizania informatyczne dla pro-ject managerw i biur projektowych.

Dla naszych uczestnikw przygotowalimy nie tylko bogaty wachlarz prelekcji i warsz-tatw. Z myl o stworzeniu warunkw sprzyjajcych integracji uczestnikw, pro-gram po raz pierwszy zostanie urozmaico-ny o takie formy networkingowe jak Pecha-Kucha, Speed Mentoring oraz Wolrds Cafe. Panel dyskusyjny z naszymi wyjtkowymi ekspertami w rolach gw-nych bdzie dodatkow moliwoci na wymian dowiadcze w obszarze nowych trendw w zarzdzaniu projektami oraz metodologii Agile & Lean.

Gboko wierzymy, e udzia w NTPM 2014 Agile and Lean Development to moli-wo zdobycia nowych umiejtnoci, podniesienia kwalifikacji, wymiany do-wiadcze i networkingu. Tegoroczna konferencja jest dla nas szczeglnie wana, poniewa po raz pierwszy wspor-ganizujemy j z firm Intel. Takie rozwiza-nie zwiksza grup odbiorcw konferencji, wzbogaca program oraz pozwala na inte-gracj brany IT i innych obszarw.

Wicej informacji o konferencji znajd Pastwo na stronie www.ntpm.pl.

PRELEGENCI I TRENERZYWrd naszych prelegentw i trenerw znajd si m. in.:

Dave Snowden jest zaoycielem i dyrek-torem ds. nauki i rozwoju Cognitive Edge. Midzynarodowy charakter jego pracy obejmuje spojrzenie na zoone kwestie dotyczce strategii, podejmowania decyzji indywidualnych oraz na szczeblu organiza-cji, zarwno z punktu widzenia dziaa rz-dowych jak i przemysu. Jego artyku na temat Przywdztwa z Boone (wspautor), stanowi okadk the Harvard Business Review w listopadzie 2007 roku i otrzyma nagrod Akademii Zarzdzania za najlepszy artyku praktykujcy tego samego roku. Dave jest rwnie gwnym projektantem oprogramowania Sense Maker, pocztko-wo opracowanego w obszarze zwalczania terroryzmu i obecnie aktywnie rozwijane-go przez rzd i przemys.

Kevin Murphy rozpocz prac w firmie Intel w 2000 roku pracujc na stanowi-skach zwizanych inynieri, zarzdza-niem i planowaniem strategicznym. Kevin zaoy i zarzdza Centrum Rozwoju Pro-duktu i Motoryzacji oddzia firmy Intel w Karlsruhe w Niemczech. Obj stanowi-sko Dyrektora ds. Inynierii i kieruje prac zespou ekspertw wytwarzajcych roz-wizania dla pierwszej platformy motory-zacyjnej Intela. Kevin uzyska tytu Dokto-ra na Uniwersytecie w stanie Arizona oraz tytu MBA na Uniwersytecie w stanie San Francisco. Jest autorem wielu patentw w obszarze transmisji szerokopasmowej, technologii interfejsu dla zaawansowane-go uytkownika oraz telewizji cyfrowej.

Jorgen Hesselberg jest dyrektorem Agile Enterprise Transformation w McAfee. Po-siada ponad 15 lat dowiadczenia w two-rzeniu rodowisk (spoecznoci) organiza-cyjnych. Jest take pasjonatem w kreowa-niu wiata lepszym miejscem do pracy po-przez metodologi agile, Lean i mylenie zoonych systemw. Zanim wstpi w sze-regi McAfee, Jorgen sta na czelethe enter-prise transformation eorts w NAVTEQ, Nokia and Nokia Xpress. Jest czstym pre-legentem podczas midzynarodowych kon-ferencji, a take autorem wielu white papers i aktywnym dziaaczem w lokalnej spoecznoci agile. Jest dyrektorem pro-gramu Agile Alliances Supporting Agile Adoption.

NOWOCI PROGRAMOWE I WARSZTATY

Zapraszamy do wzicia udziau w sesjach o rnorodnych formach:

Certified Scrum MasterSzkolenie CSM zostanie poprowadzone przez Christopha Mathisa. Program szkole-nia obejmowa bdzie nastpujce zagad-nienia: spotkania Scrum (cel i sposb ich prowadzenia), role w Scrum (poszczeglne odpowiedzialnoci oraz ich zalenoci), wymagania Agile, wzrost produktu (Pro-duct increment), jak przewodzi samoor-ganizujcym si zespoom, a take jak wspiera Product Ownera w celu uzyska-nia znakomitego produktu.

Koloseum, Massawa i Scrum Droid

Te docenione przez wielu warsztaty zdoby-y kilka nagrd PMI Awards. W trakcie tych sesji uczestnicy bd mieli okazj wcieli si w rne role i spojrze na zasady i na-rzdzia projektowe w ujciu praktycznym. Pomog one rwnie uwiadomi sobie faktyczne funkcjonowanie procesw i po-dzia rl oraz odpowiedzialnoci. W ten sposb atwiej jest zaadaptowa je do re-aliw przedsibiorstwa i unikn ryzyka poraki przy wdraaniu metodyk PMBOK czy Scrum.

Pecha-kuchaJest to rewolucyjny, a jednak prosty format prezentacji, w ktrej prezentujcy przed-stawia 20 slajdw, w tym na kady slajd przeznaczone jest 20 sekund. Autorami tej formy prezentacji s Astrid Klein oraz Mark Dytham z Klein Dytham architecture. Pecha-Kucha zostaa wynaleziona specjal-nie dla prezentujcych, ktrzy uwielbiaj mwi. Jej sesje stwarzaj szans na od-krycie niespodziewanych pomysw w za-rzdzaniu projektami, wymian wiedzy lub po prostu wasnych ciekawych projektw.

Speed MentoringCelem szkolenia jest stworzenie przychyl-nych warunkw na nawizanie nowych znajomoci biznesowych. Po okreleniu rl, jakie powinien spenia mentor i mentee uczestnicy sprecyzuj oczekiwania wzgl-dem szkolenia oraz efekty, jakich si spo-dziewaj. Grupa uczestnikw zostanie po-dzielona dwuosobowe zespoy, ktre bd wymienia si midzy sob wiedz i do-wiadczeniem w obszarze zarzdzania pro-jektami i metodologii Agile & Lean.

Fot.

: PM

I PC

Odd

zia

Gda

sk


The interview conducted by Szymon Pawowski

How to Create a World-Class PMO?

Interview with Jane Holden and Rose Ann Radosevic, 2013 PMO of the Year Award Winner, Canada Health Infoway

Could you tell us a couple of words about Canada Health Infoway, the way the business is done and the beginnings of the PMO in Infoway.

Jane Holden: Canada Health Infoway is an independent, not-for-profit corporation that is funded by the national government of Canada, but we work in partnership with all of the thirteen provinces and territories, so we really are almost like a cooperative in that sense. Because our core business is investing in projects and most of our executives come from project backgrounds, they already were quite convinced that there would be the need for a PMO. So we were lucky we did not need to do the usual convincing that a lot of PMO Directors have to do to get authoriza-tion to establish a PMO. It was accepted as a fact of life at Infoway that we needed a PMO, in the same way that we needed a fi-nancial system and a telephone system. It was that basic.

Did you implement the PMO on your own, or did you have some consultancy, benchmarks or other external know-how?

Jane Holden: We did it ourselves, because of our own professional backgrounds. I came from a long background in project manage-ment and consulting myself. I worked at a number of other organizations including PricewaterhouseCoopers, so I was pretty ex-perienced already. Similarly I hired Rose Ann about six months after I joined Infoway and she also had experience in establishing a PMO in a much larger company, a major na-tional Canadian retailer. So, yes, we did it ourselves.

How would you describe the main value your PMO provides to the organization?

Jane Holden: I think we bring value to sev-eral areas of the organization but especially to the senior management. By having a pro-cess framework in place, we increase the likelihood that our investments will be suc-cessful. Our framework has built in enough structure and due diligence at the beginning of the project lifecycle that we only let really qualified projects get through that filter. So weve had very few project cancellations. Even on a project that was qualified, if the

risk profile is not looking good and we need to take some corrective action, our reports and our processes flag that very early to senior management and allow them time to take action.

During your presentation Ive seen that you show us some data comparing your project results to the results in the health care industry and in IT generally, and it seems that your performance is pretty good. What do you think is the main factor for this success?

Jane Holden: I think there are a lot of factors. One is our due diligence process which has very clear requirements about what consti-tutes an acceptable project for investment. We are careful to make sure that we only invest in projects that have really solid foun-dations. We also have detailed investment program strategies which have to be ap-proved by our Board of Directors, so weve done a lot of research ahead of time to un-derstand what are the right investments for us. So we are not approving one-o projects - all our projects are part of a unified program approach. Another factor in our success is our responsibility to be very transparent. Be-cause we are publicly funded, we have to be transparent and accountable, and we are subject to many audits. We also receive something called access to information re-quests. I dont know if you have this in Poland, but we certainly do in Canada, where any member of the public can file a request to ask for information about us. So we know that we have a lot of eyes looking at us, so

we make sure that we are very careful about what we decide to invest in.

So, could you tell us some best prac-tices in implementing your PMO for Polish project managers and PMO sta.

Jane Holden: The top one is senior manage-ment support. You must have at least one and preferably all of the senior management team who are strong believers in the PMO and are willing to put some of their personal credibility on the line to visibly and vocally support the PMO. If you dont have the sup-port of at least one influential person in the senior management team, you need to stop until you get that. And the way you get that is to figure out, as a PMO director, how can the PMO help that individual be more suc-cessful. And if you are able to achieve that, what will happen is that individuals peers at the senior management table will want to leverage the PMOs help as well. Of course, as I said earlier, we were lucky that we didnt have tha

strefa pmi nr 4, marzec 2014

Leadership & Management