Co oznacza gotowość projektu
Gotowość projektu odpowiada na operacyjne pytanie: czy zespół może bezpiecznie rozpocząć delivery?
To nie jest ponowna kwalifikacja leada, która odpowiada, czy warto angażować się w szansę. To także nie jest estymacja. Dobry lead może nie być gotowy do startu, a zaakceptowany budżet może opierać się na decyzjach, których nikt jeszcze nie podjął.
Projekt nie musi mieć rozstrzygniętego każdego detalu. Ważne niewiadome muszą jednak być widoczne, mieć właścicieli i nie mogą uniemożliwiać pierwszej sensownej pracy.
1. Zakres ma użyteczną granicę
Zespół powinien rozumieć cel, zawartość pierwszego etapu oraz rzeczy, które świadomie pozostają poza zakresem.
Sprawdź:
- Czy cel projektu jest opisany przez oczekiwany rezultat?
- Czy wiadomo, co obejmuje pierwszy release lub milestone?
- Czy istotne wyłączenia są zapisane?
- Czy istnieje prosty sposób zatwierdzania zmian zakresu?
- Czy aktualny zakres nadal odpowiada estymacji?
Jeśli zakres zmienił się po wycenie, wróć do kalkulatora estymacji zadań zamiast traktować poprzednią liczbę jak zobowiązanie.
2. Wymagania pozwalają podjąć pierwsze decyzje
Nie potrzebujesz kompletnej specyfikacji. Potrzebujesz jasności wystarczającej do rozpoczęcia pierwszej pracy bez zgadywania krytycznych zachowań biznesowych.
Powinny być znane: rezultat dla użytkownika lub biznesu, kryteria akceptacji pierwszych elementów, ważne przypadki brzegowe oraz sposób wyjaśniania kolejnych pytań. Gdy interesariusze oczekują różnych rezultatów, problemem jest brak decyzji, nie brak dokumentu.
3. Wiadomo, kto podejmuje decyzje
Ktoś musi odpowiadać na pytania, zatwierdzać kompromisy i odbierać pracę. Sama lista interesariuszy nie wystarczy, jeśli nikt nie ma ostatniego słowa.
Ustal:
- kto odpowiada za decyzje produktowe,
- kto akceptuje rezultat,
- kto może zatwierdzić zmianę zakresu, budżetu lub terminu,
- jak szybko zespół może oczekiwać odpowiedzi.
Brak drobnego szczegółu nie zawsze jest blokerem. Brak właściciela ważnej decyzji często nim jest.
4. Dostępy i zależności są konkretne
Wypisz wejścia potrzebne do pierwszego etapu: repozytoria, hosting, pliki projektowe, analitykę, treści, dane, konta, API, dostawców i zgody.
Każdy element powinien mieć właściciela i termin. „Klient dostarczy dostęp” staje się planem dopiero wtedy, gdy wiadomo do jakiego konta, z jakimi uprawnieniami i kto ma to zrobić.
Przewodnik po blokerach projektu pomoże odróżnić zależność możliwą do zaplanowania od przeszkody, która uniemożliwia pracę.
5. Istnieje minimalny setup delivery
Przed kickoffem zespół powinien wiedzieć, gdzie zapisuje zadania i decyzje, jak wygląda review, jakie środowiska są dostępne oraz co znaczy „done” dla pierwszego etapu.
Minimum to zwykle:
- nazwany właściciel po stronie delivery i klienta,
- jedno źródło prawdy o zakresie i decyzjach,
- kanał komunikacji i oczekiwany czas odpowiedzi,
- dostęp do pierwszego środowiska pracy,
- sposób review i akceptacji,
- widoczna lista ryzyk, założeń i zależności.
Decyzja: start, ostrożny start albo stop
Startuj, gdy pierwszy rezultat jest jasny, kluczowe decyzje mają właścicieli, potrzebne dostępy działają, a pozostałe niewiadome można rozwiązywać w toku pracy.
Wystartuj ostrożnie, gdy praca może ruszyć, ale konkretne ryzyko albo zależność może zmienić plan. Zapisz warunek i termin ponownej oceny.
Zatrzymaj start, gdy zespół nie może wykonać użytecznej pracy, nikt nie może podjąć koniecznej decyzji albo krytyczna zależność nie ma właściciela i daty.
Po pozytywnej decyzji przejdź do checklisty startu projektu, aby zaplanować pierwszy tydzień bez zbędnej ceremonii.