szczerość, spójność…

…i inne pierdoły, tak bardzo zbędne w biznesie :/

Historia z zeszłego tygodnia: spotkanie przed spotkaniem, uzgadniamy plan gry, mamy zastrzeżenia do obu dostawców, ale przecież zależy nam na sukcesie projektu. Dlatego wejdziemy tam, tupniemy nóżką, zmobilizujemy firmę X i firmę Y, a potem wszystko wróci “on track”.

Wchodzimy na salę i już po pięciu minutach widać, że gramy zupełnie inny odcinek – najeżdżamy już tylko na Xów i nie reagujemy, kiedy jeden z Ygreków w kluczowym momencie stwierdza: Nie, nie może pan dokończyć zdania. W efekcie Xy wycofują się z projektu…

Antrakt. Wracamy do gabinetu na tyłach biura, zamykają się drzwi, spoglądamy po sobie i nagle wszyscy pytają: What the fuck?! Chyba nikt nie spodziewał się takiego obrotu sprawy. Ja – bo inny był plan; oni – ponieważ nie prześledzili prostego łańcucha przyczynowo-skutkowego. Robimy więc przegrupowanie. Teraz drugi dostawca będzie musiał wziąć na siebie cały ciężar projektu. Wciąż mamy do nich zastrzeżenia i trzeba je wyraźnie wyartykuować, a później zapytać, jak mają zamiar to dalej pociągnąć.

Wracamy na salę i znowu aktorzy grają po swojemu. Nikt nie pamięta o tym, że Ygreki też popełnili błędy (i to naprawdę sporo)…

OK, mogę być lekko tendencyjny, skoro Xy przyprowadziłem ja, a Ygreki to faworyci “the powers that be”, ale to i tak tylko kolejny gwóźdź do trumny.

Od dupy strony

Co z tego, że system będzie robił laskę, skoro użytkownikami są same kobiety?

Chyba wpiszę to sobie jako jeden z punktów “lessons learned” po zakończeniu projektu. Kolega dzisiaj bardzo ładnie podsumował podejście, które przy każdej okazji krytykuję. Bo co z tego, że się narobimy, co z tego, że porównamy system X z systemem Y, skoro nawet nie wiemy, po co robimy całe zamieszanie?

Może najpierw określmy, czy ma być taniej/szybciej/wygodniej, a później zastanawiajmy się, czy dane rozwiązanie spełnia wymagania? Skąd mamy wiedzieć, czy osiągneliśmy cel, skoro nie wiemy, dokąd zmierzaliśmy?

ćwiczenia z asertywności

Na Boga! Nie po to cywilizacja po tysiącleciach mroku i zacofania wymyśliła metodyki projektowe, żeby je teraz ot-tak porzucać tylko dlatego, że komuś zależy na czasie! Czy naprawdę tak trudno zrozumieć, że wypunktowanie na flipcharcie ośmiu produktów to trochę za mało, żeby wycenić pracę?

Nie, nie wycenimy Ci tego. Nie, to nie wystarczy, że od godziny o tym rozmawiamy. Nie obchodzi mnie też, że się obrazisz i trzaśniesz drzwiami-to Twój problem, że reagujesz emocjonalnie. Masz to spisać i uzgodnić ze wszystkimi działami, inaczej nie mamy o czym rozmawiać.

A tak poza tym, czy ktoś w ogóle zatwierdził ten projekt? No właśnie…

Zarządzanie zmianą

Kto słyszał o zarządzaniu zmianą? Ręka do góry!

Tak myślałem – sami ITILowcy i kierownicy projektów. Nikt z Państwa – członków zarządów – się nie zgłosił. A szkoda, bo Wam też by się to przydało…

Wbrew pozorom stosunkowo łatwo zmianę wprowadza się na poziomie infrastruktury IT lub konkretnego projektu (nie tylko informatycznego). Zazwyczaj mamy jakiś plan: harmonogram, architekturę lub konfigurację. Wiemy, jaki jest stan faktyczny. Mamy przećwiczone formularze, może nawet procedurę. Mamy w końcu Change Advisory Board lub Komitet Sterujący. Innymi słowy – wiemy, co robimy, jak i dlaczego; mamy również gwarancję, że po drodze spojrzy na to wystarczająco wiele osób, aby na koniec dnia być pewnym, że podążamy właściwą ścieżką.

Dla odmiany, zmiana wprowadzana na poziomie Zarządu pozbawiona jest wielu narzędzi, do których przyzwyczajeni są kierownicy średniego szczebla. Zarząd lubi formularze i procedury, ale pod warunkiem, że nie musi ich wypełniać. Zarząd bywa kontrolowany, ale tylko na poziomie strategii; zmiany na poziomie operacyjnym przechodzą poniżej zasięgu radarów rad nadzorczych. Obrona przed chaosem wymaga wiele samodyscypliny, której niestety często brakuje…

A przecież zmiana inicjowana przez najwyższe kierownictwo firmy najczęściej bezpośrednio dotyka pracowników – obejmuje obszar nie zawsze dający się opisać, z natury dynamiczny. Stąd kluczowe staje się pełne zrozumienie przyczyny, celu i zasięgu zmiany. Niezbędne – jak w przypadku każdego złożonego systemu – przewidzenie skutków, zarówno pożądanych, jak i ubocznych. Wszystko to w celu zagwarantowania (albo przynajmniej zwiększenia prawdopodobieństwa) sukcesu.

Oczywiście – nie chodzi o sformalizowanie działalności Zarządu poprzez narzucenie im sztywnych ram jakiejkolwiek metodyki. Wystarczy, żeby czasem zapytali o zdanie; od czasu do czasu zadali sobie pięć razy pytanie “Dlaczego?” i podzielili się wątpliwościami; żeby w końcu pomyśleli o dobrej komunikacji…

Lessons learned

— Jak bardzo po Projekcie X jesteśmy mądrzejsi przed Projektem Y? – zapytał na spotkaniu podsumowującym Projekt X właściciel biznesowy usługi.

Na ile jesteśmy mądrzejsi?! My? Gościu! W ciągu ostatniego miesiąca ani razu nie pojawiłeś się na żadnym spotkaniu, palcem nie kiwnąłeś, żeby nam pomóc. Ty nie jesteś ani odrobinę mądrzejszy…

metodyka vs. real-life

Pracownik mojego zespołu wybiera się na szkolenie z PMI. W pierwszej kolejności zastanowiło mnie, dlaczego akurat PMI, a nie np. PRINCE2, ale to są akurat preferencje osobiste lub związane z polityką firmy (wdrożoną metodyką projektową).

Inne pytanie to to, na ile takie szkolenie (a później certyfikat) z konkretnej metodyki faktycznie przygotowuje do prowadzenia projektów – codziennego zmagania się konfliktami, opóźnieniami, budżetem, itd.? Mamy jednego PMP w firmie i szczerze mówiąc nie widzę tej wartości… Dla mnie prowadzenie projektu to przede wszystkim komunikacja i ciągłe negocjacje; metodykę najchętniej zostawiłbym w kompetencjach biura projektów (Project Office).

Ale… chce się człowiek szkolić – niech idzie.

Obiecanki-cacanki

Milionowe kontrakty, projekty na już-teraz-zaraz-rzućcie wszystko… Ileż to ich widzieliśmy? Ileż razy musieliśmy faktycznie rzucać wszystko, żeby po sześciu miesiącach po wdrożeniu okazało się, że zamiast milionów są ledwie setki? Nie przeszkadza to, by kolejny projekt prowadzić w podobny sposób (“na hurrraaa!”).

A ja bym tylko chciał, żeby ktoś od czasu do czasu pomyślał o kosztach i jakości.

Priorytety

“Priorytety mają to do siebie, że są same najważniejsze” — powiedział kiedyś ktoś, kogo przez długi czas uważałem za swojego zawodowego mentora i przewodnika. Bardzo podoba mi się to powiedzenie, tym bardziej, że co chwilę poznajemy jego prawdziwość.

Priorytety są istotnym elementem “biurowej dżungli”. Właściwie określone pozwalają oddzielić sprawy ważne od tylko pilnych, albo ważne dla pana Zenka od ważnych dla całego przedsiębiorstwa. Jestem całym sercem za przyznawaniem priorytetów , ale…

Diabeł tkwi w szczegółach. Przede wszystkim priorytety nie mogą być uznaniowe, nie powinny zależeć od widzimisię pracowników. Oczywistym jest, że w takim systemie każdy będzie promował swoje, za każdym razem zgłaszając projekt lub żądanie zmiany z najwyższym priorytetem. Dlatego potrzebny jest obiektywny system z jasnymi i precyzyjnymi kryteriami.  Najprostszym kryterium jest oczywiście zysk, wyrażony w twardej walucie. Nie zgadzam się ze sceptykami, wg których pewnych rzeczy nie da się zmierzyć. Jeśli nowa inicjatywa ma np. prowadzić wyłącznie do poprawy wizerunku, to zawsze możemy próbować ten wizerunek przeliczyć na liczbę nowych klientów, wzrost obrotów z istniejącymi klientami, zmniejszenie kosztów w innym obszarze, itd.

Następne niebezpieczeństwo to właściwe kryteria i odpowiednie wartości progowe. Sam system to dopiero hardware dobrego priorytetu. Software w tym przypadku to dobrze dobrany algorytm i jego parametry. Zbyt niskie wartości progowe (np. kategoria “Zysk”, w której 1000 zł oznacza najwyższy priorytet, a 100 zł najniższy przy typowym kontrakcie w wysokości 800 zł) to gwarancja “samych najwyższych priorytetów”.

Przy nieodpowiednich parametrach szybko może okazać się, że organizacja zajmuje się tylko ważnymi projektami. Na pierwszy rzut oka może to wyglądać na pozytywny przejaw; jednak po dokładniejszym zbadaniu sprawy może okazać się, że “priorytet pierwszy” to bardzo ogólna kategoria, zawierająca projekty pilne, ważne oraz takie, do których po kilku tygodniach nikt już się nie przyznaje.

Używajcie więc priorytetów, ale róbcie to z głową. A ja zabieram się za rewizję własnych progów i parametrów.

Zaczynam rewolucję. Dość mam projektów prowadzonych metodą “na hurra!”, na zasadzie “mamy fajny pomysł, więc zróbmy to!” W ten sposób w ciągu kilku miesięcy doprowadziliśmy do sytuacji, w której każdy pracuje nad piętnastoma projektami. Kogokolwiek zapytam, każdy zgodnie odpowiada “Za dużo tego, bracie, za dużo…”

Wystartowaliśmy projekt pod tytułem “Optymalizacja projektów” :) Jeśli się uda, będzie to oznaczało kompletną zmianę kursu w tej organizacji. Dotychczas to zarząd mówił, co mamy robić; chcę doprowadzić do sytuacji, w której my (kierownicy projektów) będziemy mówili, kiedy i co możemy zrobić. Nie chodzi bynajmniej o to, by torpedować inicjatywy szefów (w końcu uwielbiam ich również za to, że mają tysiąc nowych pomysłów na minutę), ale żeby w końcu normalnie pracować.