Jak sobie radzić z ciągłymi zmianami w projekcie?

Jak sobie radzić z ciągłymi zmianami w projekcie?

Jak sobie radzić z ciągłymi zmianami w projekcie

Czy jesteś ostatnim, który nie wie jak sobie radzić z ciągłymi zmianami?

Zmiana w projekcie to…

  • Zło – bo rozwala misterny plan i dodaje stresu
  • Dobro – bo dzięki temu projekt może być lepszy
  • Zagrożenie – bo nasz zespół ma już konkretną robotę
  • Szansa – bo możemy przy zmianie ugrać coś dla siebie

Czym dla Ciebie jest zmiana? A może jeszcze czymś innym? Jak okiełznać tego potworka?

Sztywnie, czy elastycznie?

To tak tendencyjny akapit, że szkoda gadać :). Oczywiście, że nikt nie lubi „sztywnych”. To takie niefajne jest. Bzdurne trzymanie się przepisów podczas, gdy można przecież inaczej. Świat mówi, że musisz być elastyczny i otwarty na zmianę. A niby dlaczego? Dlatego, że komuś nie chciało się pomyśleć wcześniej i na Ciebie chce zwalić koszt nieróbstwa? A może dlatego, że się boi (o tym pisałem już tutaj) ? A może jednak ma rację?

Ani sztywnie, ani elastycznie – inteligentnie!

Zmiany mogą wyjść Ci na korzyść, jeżeli zgłębisz trochę ich naturę. Spójrzmy na nie z 4 perspektyw w spontanicznie wymyślonym przeze mnie modelu KAWA. Bez kawy nie bierz się za zmiany 😉 :

KTO je zgłasza. Ważne, bo nie każdemu możesz powiedzieć „bujaj się” bezpośrednio. Czasem trzeba to ubrać w dyplomatyczny sposób 😉

ADAPTACJA:  Jak mają dopasować projekt do nowej sytuacji – korekty kursu, zapobieganie wypadnięciu z kursu, poprawki błędów, zmiany do projektu

WPŁYW Jaki mają na projekt – każda zmiana to taki mały projekt i trzeba ją potraktować 12 pytaniami (12 pytań KISS PM™)

AKTUALNA SYTUACJA: W jakiej jesteś sytuacji obecnie – spokojnie z luzem zasobów, obłożony pracą na maksa, blisko fuck-up’u

To po kolei, co robić ze zmianą:

  1. Każdą potraktować 12pytaniami – bo to będzie mini projekt i jak zadasz pytania-killery – dlaczego? po co? to spora szansa, że wytniesz głupie pomysły bez robienia zamieszania
  2. Jeżeli zgłasza
    1. Ktoś dużo ważniejszy od Ciebie – pomóż w odpowiedzi na 12 pytań, najlepiej na zasadzie „Chcę dobrze zrozumieć co mam zrobić, mam kilka pytań…” i jedziesz. Później przygotuj rekomendację dla zmiany –  poniżej masz możliwe rekomendacje
    2. Ktoś nie tak ważny – poproś o odpowiedź na 12 pytań, bo będziesz i tak musiał przedstawić je sponsorowi projektu (80% ludzi zrezygnuje)
  3. Rekomendacje

Możliwe opcje

GO (ma sens, wdrażamy i niesie to ze sobą następujące konsekwencje dla czasu, kosztu, zakresu i ryzyka projektu),

HOLD (na razie nie wdrażamy bo nie ma mocy, ale jak będą to wdrożymy),

RECYCLE (coś w zmianie jest, ale trzeba jeszcze spojrzeć na nią ponownie, to szansa na jej wycofanie),

KILL (nie wdrażamy bo szkodzi projektowi)

Korekta kursu (corrective action) – raczej – GO (ma sens, wdrażamy i niesie to ze sobą następujące konsewkencje dla czasu, kosztu, zakresu i ryzyka projektu)

Zapobieganie wypadnięciu z torów (preventive action) – raczej GO, ale pod warunkiem, że niesie ze sobą widoczną korzyść

Poprawka błędów (defect repari) – raczej GO, chociaż też można rozważyć HOLD (poprawić po wdrożeniu produktu), a nawet KILL jeżeli z tymi błędami można żyć (nie wszystko musi być perfect)

Zmiana (change request) – rekomendowane HOLD jako wersja 2 naszego przedsięwzięcia lub KILL (na to rzadziej ktoś chce się zgodzić, ale ja zazwyczaj staram się wprowadzać zmiany tylko te, których koszt ktoś naprawdę jest gotów pokryć).

Odpowiedzi na 12 pytań się nie kleją – RECYCLE lub KILL. Tu naprawdę warto oszczędzać sobie czas i nie rozważać każdego „genialnego pomysłu”. Jak są genialne to często poczekają do wersji 2.0.

Twoja sytuacja może zmieniać podejście do zmiany

  1. Jeżeli masz luzy – to możesz przyjąć zmianę łatwiej, ale upewnij się, że nie robisz jej za darmo! Zmiany kosztują. Nawet jeżeli nie wystawisz rachunku w walucie upewnij się, że druga strona wie jak wielką przysługę robisz. To się przyda
  2. Jeżeli masz zawał roboty, ale projekt jest pod kontrolą – wszystkie zmiany na HOLD albo KILL. Bezwzględnie i pokazuj zagrożenie dla projektu. Im szybciej skończysz tym szybciej poprawisz. Nie daj się wywrócić pod koniec projektu!
  3. Jeżeli masz fuck-up to bierz zmianę! 🙂 – To już blisko czarnych technik, ale dzięki takiej zmianie jesteś w stanie rozładować trochę problem, przegrupować siły, przeplanować projekt i „spozycjonować” zamieszanie tym, że przecież „reagujesz na zmianę”. Zamiast stryczka będzie bohater ;).

Zanim powiesz „NIE” pomyśl. Tak naprawdę, to zawsze mówisz „TAK”, niech druga strona oceni, czy naprawdę chcę tej zmiany i jest gotowa ponieść jej koszty.

O czym jeszcze warto pamiętać? Jeżeli masz dużo zgłaszanych zmian to prowadź sobie tzw. Rejestr Zmian (Change log). Nawet w Excelu. Bo dzięki temu będziesz mógł pokazać ile razy ktoś Ci rozsypał wieżę z klocków (kiedyś miałem tak, że 2 tygodnie nie zrobiliśmy nic bo tylko ocenialiśmy zmiany a dostaliśmy po głowie za to, że nic nie robimy. Pokazałem wtedy na co przepaliliśmy ten czas i zmiany się uspokoiły).

Spodziewam się gromów po tym wpisie, chociaż i tak nie opisałem wszystkiego. Wiem, że są branże, które żyją z „change requestów” i „prac dodatkowych”. Ale to już trochę inna bajka ;).

Do zapamiętania na koniec? Zmiany są jak wiatr. Po prostu są. Przyzwyczaj się do nich, albo naucz się stawiać żagle 🙂

aaa

Mariusz Kapusta
Mariusz Kapusta
Ekspert zarządzania projektami z ponad 17 letnim doświadczeniem, trener i przedsiębiorca. Od prawie 9 lat jest też właścicielem firmy Leadership Center. Autor książki „Zarządzanie projektami krok po kroku” i twórca metody 12 pytań, które w bardzo prosty sposób uczą zarządzania projektami. Z pasją tworzy gry symulacyjne dla managerów. Triathlonista i maratończyk. Wielbiciel Rozwoju Osobistego, czemu daje wyraz na mariuszkapusta.pl

Dodaj komentarz

Twój adres email nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *