Nie ma innej możliwości. Żeby przygotować harmonogram projektu i sprawdzić, jakie koszty musimy ponieść, potrzebna jest nam najpierw wiedza o tym, co dokładnie powstanie w wyniku projektu. Sprawdź jakie kroki musisz wykonać, żeby zdefiniować zakres projektu.
W tym artykule skupiam się na podejściu klasycznym do zarządzania projektami. W podejściu zwinnym definiowanie zakresu wygląda inaczej i poświęcę mu osobny artykuł.
Wymagania
Projekt jest tworzony po to, żeby dostarczyć produkt lub usługę, która pozwoli organizacji otrzymać korzyści biznesowe zdefiniowane w uzasadnieniu biznesowym. A zatem, żeby spełnić pewne wymagania.
Wymagania w projekcie możemy podzielić na wymagania:
- biznesowe, wynikające z potrzeb organizacji, która realizuje ten projekt,
- oczekiwania (wszystkich!) interesariuszy co do produktu,
- jakościowe produktu,
- zwiazane z wdrożeniem produktu,
- dotyczące zarządzania projektem.
Warto podkreślić fakt, że mówiąc o wymaganiach, możemy mieć na myśli:
- zarówno wymagania funkcjonalne i niefunkcjonale produktu lub usługi (zakres produktu), dla której powołany został ten projekt,
- jak i wymagania związane z projektem, jako takim (zakres projektu).
Definiowanie wymagań
Definiowanie wymagań odbywa się na początku projektu i możemy w tym procesie wyróżnić 3 etapy:
- zbieranie wymagań z wykorzystaniem takich narzędzi, jak ankiety, wywiady, burze mózgów, badania fokusowe, warsztaty facylitowane, prototypowanie, przegląd standardów rynkowych czy danych historycznych z poprzednich projektów,
- analizę otrzymanych danych,
- podjęcie decyzji o tym, które wymagania wejdą w zakres projektu, a które nie.
W rezultacie powstaje macierz śledzenia wymagań (RTMX – Requirements Traceability Matrix), w której oprócz szczegółowej informacji o każdym wymaganiu, znajdują się również kryteria akceptacji, które pozwolą stwierdzić, czy dane wymaganie zostało wprowadzone czy też nie.
Czy zwróciłeś uwagę, na stwierdzenie „podjęcie decyzji o tym, które wymagania wejdą w zakres projektu, a które nie”? Nie wszystkie wymagania zostaną zrealizowane przez projekt. Decyzję podejmujemy biorąc pod uwagę takie czynniki, jak:
- uzasadnienie biznesowe,
- priorytety poszczególnych wymagań,
- ryzyka związane z wymaganiami,
- założenia i ograniczenia projektu.
Bardzo ważne jest, żeby dla wymagań, które nie znajdą się w zakresie projektu, podać powody takiej decyzji. Dzięki temu unikniemy w przyszłości (podczas realizacji projektu) próby zmian zakresu.
Dekompozycja zakresu
Dekompozycja jest techniką, która pozwala podzielić zakres projektu na małe elementy. Te dzielimy na jeszcze mniejsze. Proces kontynuujemy tak długo, aż otrzymamy elementy, którymi jesteśmy w stanie zarządzać.
W dekompozycji powinien wziąć udział cały zespół projektowy.
| Dekompozycja w PRINCE2 | Dekompozycja w PMBOK |
| Produkt dzielimy na mniejsze produkty, te na jeszcze mniejsze. W efekcie otrzymujemy strukturę wszystkich produktów, jakie muszą powstać w trakcie trwania projektu. Struktura ta nosi nazwę struktura podziału produktów (PBS – Product Breakdown Structure) | W pierwszym kroku rodukt dzielimy na mniejsze elementy kierując się fazami projektu lub działami, które będą zaangażowane w projekt. W kolejnych krokach kontynuujemy podział. W rezultacie otrzymujemy grupy zadań. Struktura ta nosi nazwę struktura podziału pracy (WBS – Work Breakdown Structure). |
Zakres projektu – kolejne kroki
Mając zdefiniowany zakres projektu, możemy przystąpić do definiowania harmonogramu projektu i określenia budżetu projektu. Może się okazać, że przy tym zakresie, jaki masz, projekt będzie za drogi lub potrwa zbyt długo. Wówczas musisz wrócić do zakresu i dokonać w nim takich zmian, żeby zbalansować oczekiwania związane z zakresem, budżetem i terminem zakończenia projektu.
Pamiętaj! „Gotowy” zakres musi zostać zatwierdzony (razem z harmonogramem i budżetem). W trakcie trwania projektu zakres może być zmieniany tylko poprzez formalny proces.
