W przypadku większych projektów polecam utworzenie macierzy śledzenia wymagań. Dowiedz się więcej tutaj:

Macierz śledzenia wymagań w zarządzaniu projektami (przykład + szablon)

Proces nr 2: Jak sprawdzić wymagania i zdefiniować zakres

Oto wymaganie :

„Witryna pmbasics101.com powinna mieć możliwość zbierania wiadomości e-mail i wysyłania w zamian dokumentu PDF.”

Co jest potrzebne, aby spełnić ten wymóg?

1. Wybierz dostawcę usług pocztowych.
2. Utwórz konto.
3. Zaprojektuj formularz do zbierania wiadomości e-mail.
4. Zaimplementuj zaprojektowany formularz.
5. Zainstaluj wtyczkę od dostawcy usług pocztowych.
6. Prześlij dokument PDF.
7. Aktywuj formularz.
8. Przetestuj formularz.

To tylko lista wymaganych działań. Gdybym miał ją poprawnie umieścić jako element dostarczalny i pakiety robocze, skończyłoby się to następująco:

1. Email Opt -w formularzu
   1.1 Raport o dostawcach usług pocztowych
   1.2 Zatwierdzony projekt formularza
   1.3 Formularz zgody na środowisko testowe
   1.4 Raport z testu

Tak, jak to zrobić przechodzisz z tego jednozdaniowego wymogu do faktycznego zakresu pracy?

A) Możesz znaleźć kogoś, kto ma odpowiednie doświadczenie lub wiedzę

Może to być interesariusze, klienci lub konsultanci, eksperci merytoryczni lub inne strony.

Twoim celem jest więc pozyskanie ich od zespołu projektowego lub po prostu skontaktowanie się z nimi w celu komunikacji. Mogą już znaleźć rozwiązanie.

W przeciwnym razie możesz uzyskać wskazówki lub poradę. Jest to podstawowa technika, którą będziesz szeroko stosować.

B) Wykonaj analizę produktu

Ma ona zastosowanie, gdy chcesz stworzyć produkt, a nie usługę lub wynik.

Ta technika koncentruje się na rozkładaniu wartości produktu. Podobnie jak WBS z lunetą.

Ponadto należy przeanalizować produkt z ergonomicznego i funkcjonalnego punktu widzenia; a następnie podjąć decyzje dotyczące materiałów lub procesów, które będą zgodne z wymaganiami dotyczącymi wydajności.

25 Przykłady analizy produktu

Podsumowując, Twoim celem jest zdefiniowanie namacalnych produktów.

C) Użyj techniki generowania alternatyw

Ta technika działa dobrze, gdy masz doświadczenie w naturze projektu.

Więc musisz znaleźć najlepsze rozwiązanie spełniać wymagania. W większości przypadków użyjesz burzy mózgów, aby znaleźć alternatywy.

Jaki jest cel?

Musisz jasno określić, co jest, a co nie jest częścią zakresu projektu.

Proces nr 3: Zarządzaj zakresem projektu za pomocą oprogramowania PM

Z pewnością możesz śledzić zakres projektu w dowolnej dostępnej aplikacji. Na przykład Dysk Google, Evernote lub MS Word wystarczą.

Jednak korzystanie ze zintegrowanego oprogramowania do zarządzania projektami, aby wszystko było w jednym miejscu, przynosi poważne korzyści.

Najlepiej trzeba umieć powiązać wymagania z rezultatami projektu.

Następnie, od wyników do konkretnych zadań z szacunkami, powiązanymi ryzykami i defektami.

Na przykład mogę polecić Paymo. To jedna z najlepszych aplikacji do użytku osobistego i do małych projektów. Dodatkowo ma świetne możliwości śledzenia czasu i fakturowania.

Proces nr 4: Jak kontrolować zakres projektu

Na początku nie wystarczy określić 100% zakresu projektu . To 100% ZMIENI SIĘ w trakcie trwania projektu.

Potrzebujesz więc sposobu na monitorowanie, kontrolowanie i wprowadzanie zmian w zakresie.

Lekarstwo jest dobrze znane. Jest to struktura podziału pracy.

Cóż, potrzebujesz również przejrzystego przepływu pracy, aby wprowadzić zmiany we wszystkich obszarach projektu, gdy zmieni się ilość pracy.

Jest to jednak kwestia zintegrowanego procesu zarządzania zmianą.

Więc jaki jest haczyk?

Potrzebujesz wysokiej jakości WBS. Co więcej, potrzebujesz prostego sposobu na opisanie zakresu projektu. Dlatego potrzebujesz również Deklaracji zakresu projektu. Omówimy to poniżej.

Jeśli prowadzisz projekt zwinny, jasno określony zakres przyrostu lub iteracji jest jeszcze ważniejszy. Nie myśl, że zwinność chroni Cię przed dokładnym dokumentowaniem pracy do wykonania. Utrzymuj porządek w Backlogu Sprintu i Historiach użytkowników. Zastosuj prostą zasadę: „Nowicjusz powinien zrozumieć, co należy zrobić z opisu historii użytkownika”.

Jak zweryfikować zakres

Od czasu do czasu musisz uzyskać formalną podpisanie, że produkt spełnia oczekiwania interesariuszy.

Niezwykle ważne jest, aby robić to w sposób ciągły przez cały czas trwania projektu.Nawet jeśli prowadzisz projekt oparty na planie, nic nie powinno powstrzymywać Cię przed dostarczaniem przyrostów produktów do przeglądu.

Dlaczego tego potrzebujesz?

Nie chcesz mieć wszystkiego prośby o zmianę, wszystkie wady i „drobne zmiany w projekcie” na końcu.

Pozbawisz się możliwości faktycznego włączenia zmiany do projektu.

Im bliżej zamknięcia projektu, tym mniej czasu i zasobów pozostanie. Ponadto interesariusze będą mniej skłonni do negocjowania zmian w zakresie, harmonogramie lub budżecie. Ponadto będą wywierać większą presję na zespół, aby weź to, czego potrzebują.

Po prostu stwierdź oczywiste:

Bardzo ważne jest, aby od samego początku mieć jasno opisany i zatwierdzony zakres projektu.

Kiedy element dostarczony nie spełnia oczekiwań, będą poprawki.

Twoim obowiązkiem jest udowodnienie, czy korekta jest żądaniem zmiany i dlatego powinna zostać prawidłowo zintegrowana. W przeciwnym razie jest to wada, i musisz to naprawić. Czasami na własny koszt.

W jaki sposób faktycznie sprawdzasz zakres z klientami?

W każdym projekcie możesz skorzystać ze spotkania demonstracyjnego podobnego do Scruma.

Po prostu przygotować krótką prezentację produktu. Wyjaśnij aktualny stan i postęp projektu. Następnie wskaż znane usterki i części będące w toku.

Zbierz również informacje zwrotne od klienta. Później możesz dostarczyć wszelką pomocniczą dokumentację i raporty wymagane przez Twoje zasady.

Podsumowanie:

Stale zbieraj opinie od interesariuszy. Negocjuj warunki wprowadzenia nowych wniosków o zmianę. Aktualizuj projekt Scope Baseline.

Pobierz mój szablon zarządzania zakresem projektu

Nie wymyślaj koła! Może to być kosztowne.

Po prostu kliknij poniższy przycisk i pobierz mój szablon do wypełnienia pustych pól. Zawiera przewodnik po wszystkim, co musisz wiedzieć o zarządzaniu zakresem.

Dlaczego cały zakres Linia bazowa jest krytyczna dla Twojego projektu?

Zazwyczaj projekt się rozpoczyna i otrzymujemy wymagania w różnych formach.

Na przykład: e-maile, pliki PDF, spotkania, makiety, raporty o błędach, cokolwiek .

I oczywiście nie przygotowujemy Karty Projektu ani niczego podobnego. Zła praktyka!

W większości przypadków nawet nie omawiamy uzasadnienia biznesowego projektu.

Zwykle tworzymy strukturę podziału pracy.

Jednak jest używany tylko wewnętrznie i nigdy nie trafia do klienta. Następnie rozkładamy pracę na czynności i szacujemy projekt. Używamy techniki szacowania oddolnego.

Teraz następuje pierwsze sprawdzenie oczekiwań:

Przedstawiamy szacunki dla projektu.

Widzisz, najwyraźniej jest brak przejrzystości tutaj. Klient nie wie, jaką pracę faktycznie oszacowaliśmy.

Jeśli oszacowanie jest zbliżone do oczekiwań klienta, nie będzie zagłębiał się w szczegóły. Dzieje się tak, ponieważ jest gotowy wydać już tyle pieniędzy i czasu. Nie chce tracić cennego czasu.

Oto prawda:

Wiele organizacji i kierowników projektów ukrywa nieefektywność za takimi cichymi umowami.

To jest temat na osobny post, ale jest główną przyczyną wielu twoich problemów.

Co dalej?

Rozpoczynamy realizację projektu! Prędzej czy później klient poprosi o dodanie kolejnej pracy.

Potem znajdziemy część niezidentyfikowanej pracy. Później pojawią się problemy z jakością. Zjedzą dużo czasu.

Podsumowując, przekazujemy dostawę, aby dowiedzieć się, że zrobiliśmy coś złego.

I wtedy klient informuje nas, że zapomniałem o czymś i należy to dodać jak najszybciej.

Uwierz mi, doświadczasz tego więcej niż raz.

Definicja linii bazowej zakresu

”Linia bazowa zakresu to zatwierdzona wersja opisu zakresu, struktury podziału pracy (WBS) i związanego z nim słownika WBS, który można zmienić tylko za pomocą formalnej procedury kontroli zmian i jest używany jako podstawa do porównania. ” -PMBOK® Guide

Co to jest Oświadczenie dotyczące zakresu projektu?

Definicja deklaracji zakresu projektu

Deklaracja zakresu projektu to narracyjny opis produktu i zakresu projektu.

Jest używany jako pisemne potwierdzenie tego, co i jak powstanie Twój projekt.

Co jest kluczem do wartościowej deklaracji zakresu projektu?

Uważam, że musisz używać terminów i języka zrozumiałego dla każdego interesariusza. Ta część planu bazowego projektu jest przeznaczona głównie dla klienta.

OK, co powinno być uwzględnione?

Uzasadnienie projektu

Jest to krótki opis potrzeby firmy. Czasami wystarczy jedno zdanie. Reszta powinna pozostać w karcie projektu.

Zakres produktu

Jest to opis cech, cech i funkcjonalności produktu lub usługi, które będziesz wytwarzać.

Pamiętaj, że zebrałeś wymagania od różnych interesariuszy. Nie zakładaj więc, że wszyscy śledzą każde wymaganie. Ponadto nie zawsze jest jasne, ile pracy potrzeba, aby spełnić wymagania.

Jest to główne miejsce, w którym można dopasować oczekiwania kluczowych interesariuszy.

Musisz pokazać ilość i złożoność pracy wymaganej do spełnienia różnych wymagań. Dlatego włóż najwięcej wysiłku w tę sekcję.

Kryteria akceptacji

Są to warunki, które muszą zostać spełnione, zanim elementy projektu zostaną zaakceptowane.

Możesz dołączyć akceptowalny poziom i liczbę defektów również tutaj.

Elementy dostarczane

Jest to opis wszystkich elementów dostarczanych przez projekt.

Może obejmować produkt lub usługi, dokumentacja projektowa, podręczniki produktu, materiały edukacyjne dotyczące Twojego produktu itp.

Wyłączenia projektu

Tutaj musisz określić, co jest poza zakresem projektu.

Dość często część interesariuszy chce czegoś konkretnego. Druga część interesariuszy lub klient tego nie wspiera.

Dlatego jest to sytuacja konfliktowa. Po rozwiązaniu konfliktu i podjęciu decyzji o usunięciu czegoś z zakresu projektu, umieść to tutaj.

Podaj konkretny i bardzo jasny opis. Oszczędza to czas w przyszłości.

Po pierwsze, nie będziesz musiał ponownie sprawdzać tych wykluczeń projektów. Interesariusze mogą próbować uwzględnić je później w trakcie realizacji projektu.

Jednak jeśli coś nie zmieni się dramatycznie, nie powinieneś tracić czasu na przeglądanie wykluczeń.

Po drugie, jeśli nie jest to jasno określone, ktoś może nadal oczekuję, że to dostarczysz. Nie karm fałszywych oczekiwań. Na końcu łatwiej będzie przekazać projekt.

Ograniczenia

Wszystko, co ogranicza cię do wydajnego dostarczenia produktu, powinno być tutaj określone.

Założenia

To niejasności, których nie można w tej chwili wyjaśnić.

Podczas planowania musisz zaakceptować niektóre z nich. W przypadku, gdy założenie okaże się nieważne, będziesz mieć prawo do zmiany planu projektu.

Klient powinien zatwierdzić oświadczenie o zakresie projektu. W rzeczywistości jest to formalne i wzajemne porozumienie.

Ponadto oświadcza, że zobowiązujesz się do dostarczenia opisanych wyników przy określonym założeniu i z jasnymi ograniczeniami. Z drugiej strony klient zgadza się zaakceptować określony wynik.

Nie oznacza to, że nie możemy zmienić zakresu projektu. Nie. Oznacza to, że aby dokonać zmiany – musimy zmienić umowę.

Zorganizuj zakres projektu za pomocą WBS

WBS jest obowiązkową częścią zakresu odniesienia we wszystkich projektach. Duży czy mały. Zwinne lub oparte na planie.

Istnieje już kompletny przewodnik po strukturze podziału pracy w PM Basics. Nie będę tego tutaj powtarzał.

Jest tylko jeden kluczowy punkt, na który chcę zwrócić uwagę:

Elementy dostarczane opisane w Deklaracji zakresu projektu powinny trafiać do WBS w obecnej postaci. Utrzymuj spójność wyników w całym projekcie.

Umieść wszystko, co wiesz, w słowniku WBS

Słownik WBS to dokument opisujący pracę, jaką należy wykonać dla każdego pakietu roboczego.

Jako nowoczesny PM powiedziałbym, że powinno to być częścią systemu śledzenia zadań. Większość oprogramowania do zarządzania projektami umożliwia przechowywanie tych informacji w jednym miejscu.

Dlatego nie sugerowałbym tworzenia oddzielnego dokumentu. Utrzymanie Słownika WBS to dużo pracy. Poszukaj zintegrowanych rozwiązań.

Możesz dołączyć dowolne informacje określające komponent w WBS. Na przykład Słownik WBS może zawierać:

• Opis pracy
• Założenia i ograniczenia
• Odpowiedzialne osoby lub organizacje
• Kamienie milowe
• Powiązane działania
• Wymagane zasoby
• Kosztorys lub budżet
• Kryteria akceptacji
• Odwołuje się do innej dokumentacji

Wszystko, co odpowiada Twoim potrzebom i pomaga zintegrować WBS z innymi procesami.

Podsumowanie

„Nie ma wiatru, który wieje dobrze dla żeglarza, który nie wie, gdzie jest port.”

Nie możesz doprowadzić projektu do pomyślnego wyniku, nie wiedząc, co należy zrobić.

Jeszcze raz chcę to podkreślić.

Nawet jeśli jesteś w środowisku Agile, a zakres nie jest jasno zdefiniowany dla całego projektu, nadal musisz zaplanować sposób definiowania, zarządzania, śledzenia i zmiany zakresu projektu.

Oba na poziomie iteracji i ostateczny wynik projektu.

Polecam również przeczytanie:

• Polecany artykuł: Jak zostać kierownikiem projektu IT bez doświadczenia
• Następny w seria: Kompletny przewodnik po tworzeniu solidnej struktury podziału pracy
• Poprzednia część serii: Macierz śledzenia wymagań w zarządzaniu projektami (np. ample + Szablon)