Stanowisko
Kierownik projektu
Ile razy w tygodniu składacie status projektu od nowa, pytając te same osoby? Jeśli kilka razy, to znaczna część tygodnia idzie na opisywanie pracy, a nie na jej prowadzenie.
Rozmowa wstępna
Cztery pytania, od których byśmy zaczęli
Ile razy w tygodniu składacie status?
Dla zespołu, dla klienta, dla zarządu, na komitet. Każdy w innym układzie, każdy z tych samych danych.
Kto zauważa pierwszy, że projekt zaczyna się opóźniać?
Jeśli kierownik projektu dwa tygodnie po fakcie, to ryzyko wychodzi jako problem, a nie jako ryzyko.
Kiedy zapada decyzja o zmianie zakresu?
Jeśli nieformalnie, w rozmowie, bez zapisu skutku dla terminu, to zakres rośnie, a termin zostaje ten sam.
Co zostaje po projekcie, gdy zespół się rozejdzie?
Jeśli tylko dokumentacja produktu, to następny projekt powtórzy te same błędy.
Zdejmujemy składanie statusu, zostawiamy prowadzenie projektu
Zbieranie postępu, przygotowanie raportów, pilnowanie ryzyk i rejestr zmian dają się odciążyć. Ocena sytuacji projektu i decyzje zostają przy kierowniku.
- Status składa się z pracy, nie z ankiety. - Postęp pochodzi z tego, co zespół i tak robi w narzędziach, a kierownik nadaje mu interpretację.
- Raport dla różnych odbiorców ma jedno źródło. - Ten sam stan w trzech układach, zamiast trzech ręcznych wersji, które po tygodniu się rozjeżdżają.
- Zmiana zakresu ma policzony skutek. - Dołożenie zadania pokazuje wpływ na termin, zanim zapadnie decyzja.
Zakres
Co da się odciążyć w prowadzeniu projektu
Dwadzieścia przykładowych zadań. Każde ma punkt zatwierdzenia po stronie człowieka. Poniżej wybrane, a zakres dopasowujemy do Waszej metodyki.
Plan i zakres
- Zestawienie zakresu z podziałem na etapy
- Powiązanie zadań z osobami i terminami
- Sygnał o zadaniu bez właściciela
- Zależności między zadaniami i ich skutki (ocena: kierownik)
Status i raportowanie
- Postęp zbierany z narzędzi używanych przez zespół
- Projekt raportu w układzie dla zarządu (treść: kierownik)
- Projekt raportu w układzie dla klienta
- Zestawienie zmian od poprzedniego raportu
- Sygnał o zadaniu bez postępu dłużej niż uzgodniono
Ryzyka i problemy
- Rejestr ryzyk projektu z właścicielem i działaniem
- Sygnał o terminie zagrożonym przez zależność
- Wskazanie zadań na ścieżce krytycznej
- Eskalacja problemu wedle uzgodnionych progów (decyzja: kierownik)
Zmiany zakresu
- Rejestr wniosków o zmianę
- Policzony wpływ zmiany na termin i pracochłonność
- Decyzja o przyjęciu zmiany z zapisem (decyzja: sponsor)
- Zestawienie zakresu pierwotnego wobec aktualnego
Zamknięcie projektu
- Porównanie planu z wykonaniem
- Zestawienie problemów i ich przyczyn
- Wnioski przechodzące do kolejnych projektów (zatwierdzenie: kierownik)
Dzień pracy
Dzisiaj
- Status zbieracie, pytając zespół na spotkaniu i na komunikatorze
- Raport dla zarządu składacie ręcznie, w innym układzie niż dla klienta
- O opóźnieniu dowiadujecie się, gdy ktoś je zgłosi
- Zmiany zakresu uzgadniane są w rozmowie, bez policzonego skutku
- Ryzyka żyją w rejestrze, do którego nikt nie zagląda
- Po projekcie wnioski zostają w pamięci kilku osób
Z asystą AI
- Postęp pochodzi z narzędzi, nie z pytania zespołu
- Raporty w różnych układach mają jedno źródło
- Zadanie bez postępu zgłasza się samo
- Zmiana zakresu pokazuje wpływ na termin przed decyzją
- Ryzyko z zagrożonym terminem sygnalizuje się wcześniej
- Wnioski po projekcie są zapisane i dostępne następnemu zespołowi
- Rzetelność statusu
raport opisuje stan, a nie wrażenie z piątku
postęp pochodzi z pracy zespołu
- Czas raportowania
kierownik prowadzi projekt zamiast go opisywać
raporty mają jedno źródło i projekt treści
- Wczesne wykrycie ryzyka
opóźnienie bywa widoczne, zanim stanie się problemem
brak postępu i zagrożone zależności są sygnalizowane
- Wiedza po projekcie
następny projekt nie powtarza tych samych błędów
wnioski są zapisane, nie zapamiętane
Zaczynamy od źródła statusu, bo to ono decyduje, ile czasu zajmuje raportowanie.
- Krok 1
Postęp z narzędzi zespołu
Status składany z tego, co już istnieje, zamiast z ankiety.
- Krok 2
Raporty w kilku układach
Jedno źródło, różne widoki dla zarządu, klienta i zespołu.
- Krok 3
Ryzyka i sygnały o zagrożeniach
Brak postępu, zagrożone zależności, ścieżka krytyczna.
- Krok 4
Zmiany zakresu i wnioski
Policzony skutek zmiany i wnioski po zamknięciu. Na końcu, bo wymaga wiarygodnego planu.
Częste pytania
Pytania, które padają na pierwszym spotkaniu
Czym to się różni od pracy scrum mastera?
Kierownik projektu odpowiada przed sponsorem za zakres, termin i budżet - i ma do tego umocowanie. Scrum master odpowiada za to, żeby zespół mógł pracować, i nie ma nad nim władzy. Stąd inne narzędzia: tu raport i decyzja o zmianie zakresu, tam usuwanie przeszkód i rozmowa. W firmach, w których jedna osoba pełni obie role, zwykle wygrywa raportowanie, bo ono ma termin.
Co z projektami prowadzonymi poza IT?
Mechanika jest ta sama: zakres, zależności, status, zmiany, zamknięcie. Różni się źródło postępu - w projekcie budowlanym albo wdrożeniowym pochodzi z innych miejsc niż z repozytorium kodu. To jest kwestia projektowa, nie przeszkoda.
Czy do prowadzenia projektów potrzeba będzie mniej osób?
Projekt prowadzi się decyzjami, a nie raportami - i to jest praca, której nikt nie zdejmie. Odciążamy składanie statusu, czyli połowę tygodnia spędzaną na opisywaniu cudzej pracy. Kierownik, który tego nie robi, prowadzi projekt zamiast go dokumentować. Ilu projektów to dotyczy, zależy od Waszego portfela.
Czy to podlega AI Act?
Prowadzenie projektów nie jest zastosowaniem wysokiego ryzyka. Granica przebiega przy danych o postępie przypisanych do osób: zestawienia prowadzimy na poziomie zadań i etapów, bo dane o tempie pracy poszczególnych członków zespołu to już obszar oceny pracowników.
Zostało pytanie, którego tu nie ma? Umów rozmowę
Następny krok
Ile godzin tygodniowo poświęcacie na składanie statusów?
Pokażemy Wam, jak wygląda prowadzenie projektu, w którym status pochodzi z pracy zespołu, a zmiana zakresu ma policzony skutek.